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