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