634
Uber數據基礎架構現在及未來
優步是全球領先的移動互聯網創業公司,通過創新科技為乘客和合作司機高效即時匹配,提供安全、高效、可靠、便利的出行選擇，他的使命是“使出行如自來水一樣可靠，每個人在任何地方都能享用”。為了履行這一承諾，優步依賴於在每個層麵做出數據驅動的決策。
優步目前的業務廣泛分布於75個國家或地區，超過500個城市，基於分析可以充分了解一個城市人們出行的特點(熱點區域、主要交通流向等)。大部分的決策都得益於更快的數據處理能力，其底層核心在於構建了強大的Hadoop大規模數據處理平台。下麵對Hadoop在優步的發展過程做一個初步介紹。
2014年以前數據架構比較簡單，數據主要有日誌和DB數據組成，采集到數據倉庫後再做進一步加工，然後直接服務商業應用或即席查詢分析等，架構如下：
此架構的中心是一個數據倉庫，用於將各種數據源收歸一處，經統一建模處理後再提供服務給上層業務或數據分析人員使用。傳統的數據倉庫建設可初略分為3個環節，數據采集、維度建模、數據服務。
首先簡要介紹數據采集過程中的技術，分為兩類：
日誌采集與處理方案較多，下麵對常見的做一個對比：
由此可見，優步選擇kafka的原因也就一目了然。
DB數據采集
在數據加載到數據庫的過程中，分為全量加載（更新）和增量加載（更新）。全量加載是首先全表刪除後再從源表進行數據加載的方式；增量加載是目標表僅更新源表變化的數據。常用的方式有：
- 係統日誌分析方式
- 觸發器方式
- 時間戳方式
- 全表比對方式
- 源係統增量（delta）數據直接或者轉換後加載。
優步在數據處理方麵選用了部分amazon的雲計算解決方案，采用AmazonS3，它具有簡單的Web 服務接口，可用於在 Web 上的任何位置存儲和檢索任意數量的數據。它能夠提供99.999999999% 的持久性，並且可以在全球大規模傳遞數萬億對象。可作為分析的批量存儲庫或“數據湖”。
另外數據在存儲到 S3 中後，會自動采用成本更低、存儲期限更長的雲存儲類進行存檔。計算方麵采用了Amazon EMR，它是可用於運行 AWS上托管的 Hadoop 群集，各完成多種類型的數據加工處理任務。
數據建模是專門用於分析型數據庫、數據倉庫、數據集市建模的方法，除了在數據庫中常見的ER建模和關係建模，還包括專門針對數據倉庫的維度建模技術，包括幾種模型：星形模型、雪花模型、混合模型。
2015年前的優步從服務器數量、計算任務量、數據量等幾個方麵來看Hadoop規模仍然較小。由於其業務高速發展，到如今已經有非常大的變化，由上千台服務器組建的Hadoop集群，每天處理10W+計算任務，PB級的數據存儲，數據處理框架不僅采用spark，同時hive和Presto也廣泛應用。新架構與2014年相比，最大的變化在於計算和存儲引擎的統一，規模現實大幅度增漲。
Hadoop集群規模從2014年初期的幾個節點，到2015年增長到百餘節點和PB級數據容量，2016年發展到千餘節點，預計2017年可發展到5000節點、100PB存儲的規模。
在集群規模和業務高速發展的過程中，優步解決了一些自身麵臨的個性化需求，包括：
1. Strict Schema Management：由於大量使用數據的人員主要通過SQL來加工數據，而SQL允許用戶在高層的數據結構上工作，所有SQL語句都接受集合作為輸入，返回集合作為輸出，因此需要嚴格、統一管理數據的結構信息或數據模型。
2. 多種大數據處理工具協同：麵向不同類型的數據用戶提供多種數據處理工具，如Hive、Presto、Spark等，普通用戶可直接使用hive/presto完成常規的數據處理與分析，利用spark可完成更深入的數據挖掘與圖計算等。
隨著優步業務的全球化拓展，對應的服務與底層的計算與存儲引擎也需要有全球化的能力，資源的全球化管理也將成為重中之重，下麵簡要介紹幾個資源管理框架的特點與應用。
Mesos和YARN之間的主要區別圍繞著優先級的設計以及調度任務的方式。Mesos的設計初衷是作為整個數據中心的一個可拓展的全局資源管理器。YARN出於管理Hadoop規模的需求。在YARN出現之前，資源管理(功能)集成在Hadoop MapReduce V1架構中，為了有助於MapReduce的擴展而將其移除(轉移到YARN中實現)。MapReduce的Job Tracker並不能在超過上千台的機器中有效調度MapReduce任務。YARN在下一代Hadoop生命周期中被創造，主要圍繞著資源拓展。
Mesos的調度策略，Mesos決定了哪些資源可用，它把分配請求返回給一個應用調度器(應用調度器和執行器被稱作“框架”)。這些分配請求被框架接受或者拒絕。這個模型被認為是非單體模型，因為它是一個“兩級”調度器，調度算法是可拔插的。
Mesos允許任何實現任何調度算法，每個算法都能根據自己的策略進行接收或是拒絕分配請求，並且可以容納成千上萬種調度程序以多租戶的方式運行在同一個集群。
Mesos的兩級調度模型允許每個框架(自己)決定使用哪種算法來調度運行的工作。Mesos扮演仲裁者，在多個調度器上來調度資源，解決衝突，並且確保資源基於業務策略被公平地分發。分配請求到來時，框架會執行任務來消費那些提供的資源。或者框架可以選擇拒絕請求並且等待下一個分配請求。多年的操作係統和分布式係統的實踐發展證明，這種模型的好處在於它具有良好的擴展性。它已被Google和Twitter證明。
YARN的調度策略，當job請求到達YARN資源管理器，YARN評估所有可用的資源然後調度job。YARN以一種整體的方式，直接決定job運行的位置。在MapReduce架構演變的過程中，重申強調YARN的出現十分重要。
在Hadoop任務的資源規模伸縮需求的驅動下，YARN把資源管理的模型從MR的Job Tracker中獨立出來，在Resources Manager組件中實現。YARN既不是為長時間運行的服務而設計，也不是為滿足短期交互/快速響應式請求(像簡短而快速的Spark任務)，盡管它可能調度其他種類的工作任務，但這並不是一個理想的模型。
MapReduce的資源需求、執行模型和架構需求不同於長時間運行的服務，如Web服務器、SOA應用程序或是像Spark和Storm那樣的實時任務。同時，YARN為了易於無狀態的腳本任務重啟而設計。它並不能處理像分布式文件係統或數據庫那樣的有狀態的服務。然而YARN的整體的調度器理論上可以處理不同類型的工作負載(通過把新的算法合並到調度代碼)，對於支持日益複雜的調度算法，這並不是一個輕量級的模型。
當你把如何管理數據中心作為整體來評估時，一方麵使用Mesos來管理數據中心的所有資源，另一方麵使用YARN來安全的管理Hadoop任務，但它並不具有管理整個數據中心的能力。數據中心運營商傾向於把集群劃分為的不同區域(Hadoop集群和非Hadoop集群)來應對這兩個場景。在同一個數據中心使用Mesos和YARN，為了受益於資源管理器，目前需要創建兩個靜態分區。此時意味著當指定資源被Hadoop的YARN管理時，Mesos就無法起作用。這也許過於簡化了，盡管這麼做確實有效。但本質上，我們是想避免這種情況。
能否讓企業和數據中心受益於YARN和Mesos的協調工作?答案是肯定的。一些著名的公司——eBay、MapR和Mesosphere共同合作了一個項目叫做Myriad。這個開源軟件項目既是一個Mesos框架，又是一個YARN調度器，這就使得Mesos能夠管理YARN的資源請求。當一個任務到達YARN時，它會通過Myriad調度器調度它，使請求與Mesos提供的資源匹配。
相應的，Mesos也會將它傳遞給Mesos工作節點。之後，這個Mesos節點會把這個請求與一個正在執行YARN節點的管理器的Myriad執行器關聯。Myriad在Mesos資源啟動YARN節點管理器，啟動之後，Mesos資源會告訴YARN資源管理器哪些資源可用。這時YARN就可以隨意地使用這些資源。Myriad為Mesos的可用資源池和YARN的任務(需要用到Mesos中資源)之間架起了一座無縫連接的橋梁。
優步在 Mesos 上設計了全新統一資源調度係統Peloton，用來更有效和彈性地管理計算資源，並且為不同團隊提供了分層的的最大最小公平算法，不久的將來可能開源。
原文發布時間為：2017-09-05
本文作者： 春陽
本文來自雲棲社區合作夥伴“中生代技術”，了解相關信息可以關注“中生代技術”微信公眾號
最後更新：2017-09-07 13:03:08