如果你用過Uber，你一定會注意到它的操作是如此的簡單。你一鍵叫車，隨后車就來找你了，***自動完成支付，整個過程行云流水。但是，在這簡單的流程背后其實是用Hadoop和Spark這樣復(fù)雜的基礎(chǔ)大數(shù)據(jù)架構(gòu)來支撐的。

Uber 在現(xiàn)實世界和虛擬世界的十字路口有令人羨慕的一席之地。這令每天在各個城市穿行的數(shù)十萬司機大軍趨之若鶩。當(dāng)然這也會一個相對淺顯的數(shù)據(jù)問題。但是，就像 Uber數(shù)據(jù)部門的主管 Aaron Schildkrout所說：商業(yè)計劃的簡單明了帶給Uber利用數(shù)據(jù)優(yōu)化服務(wù)的巨大機會。

“這本質(zhì)上來說是一個數(shù)據(jù)問題”，Schildkrout 最近在一個Uber和Databricks的演講記錄中說道。“因為事情是如此淺顯，我們想讓用車體驗變得自動化。在某種程度上，我們正在嘗試為全世界的載客司機提供智能、自動化、實時的服務(wù)并且支撐服務(wù)的規(guī)?；?rdquo;

不論是Uber在峰時計價、幫助司機規(guī)避事故還是為司機尋找***盈利位置，這一切 Uber 的計算服務(wù)都依賴于的數(shù)據(jù)。這些數(shù)據(jù)問題是一道數(shù)學(xué)和全球目的地預(yù)測的真正結(jié)晶。他說：”這使得這里的數(shù)據(jù)非常振奮人心，也驅(qū)動我們斗志昂揚地用Spark解決這些問題”

Uber 的大數(shù)據(jù)之道

在Data bricks的演講中，Uber 工程師描述了(顯然是***公開演講)一些在應(yīng)用擴展和滿足需求上公司遇到的挑戰(zhàn)。

作為負責(zé)Uber 數(shù)據(jù)架構(gòu)的總負責(zé)人，Vinoth Chandar說道：Spark 已經(jīng)是”必備神器了”。

在舊的架構(gòu)下，Uber依賴于Kafka的數(shù)據(jù)流將大量的日志數(shù)據(jù)傳輸?shù)紸WS的S3上，然后使用EMR來處理這些數(shù)據(jù)。然后再從EMR導(dǎo)入到可以被內(nèi)部用戶以及各個城市總監(jiān)使用的關(guān)系型數(shù)據(jù)庫中。

Chandar說道：”原來的 Celery+Python的ETL架構(gòu)其實運轉(zhuǎn)得挺好的，但是當(dāng)Uber想要規(guī)模化時就遇到了一些瓶頸”。隨著我們擴展的城市越來越多，這個數(shù)據(jù)規(guī)模也不斷增加，在現(xiàn)有的系統(tǒng)上我們遇到了一系列的問題，尤其是在數(shù)據(jù)上傳的批處理過程。

Uber 需要確保最重要的數(shù)據(jù)集之一的行程數(shù)據(jù)，這里成百上千的真實準(zhǔn)確的消費記錄將會影響到下游的用戶和應(yīng)用。Chandar 說道：”這個系統(tǒng)原來并不是為了多數(shù)據(jù)中心設(shè)計的。我們需要用一系列的融合方式將數(shù)據(jù)放到一個數(shù)據(jù)中心里面。”

解決方案演化出了一個所謂的基于Spark的流式IO架構(gòu)，用來取代之前的Celery/Python ETL 架構(gòu)。新系統(tǒng)從關(guān)系型數(shù)據(jù)倉庫表模型將原始數(shù)據(jù)攝取做了必要的解耦。Chandar說：”你可以在HDFS上獲取數(shù)據(jù)然后再依賴于一些像Spark這樣的工具來處理大規(guī)模的數(shù)據(jù)處理。”

因此，取而代之的是在一個關(guān)系模型中從多個分布式數(shù)據(jù)中心聚合行程數(shù)據(jù)，公司新的架構(gòu)使用Kafka從本地數(shù)據(jù)中心來提供實時數(shù)據(jù)日志，并且加載他們到中心化的Hadoop集群中。接著，系統(tǒng)用Spark SQL 將非結(jié)構(gòu)化的JSON轉(zhuǎn)化為更加結(jié)構(gòu)化的可以使用Hive來做SQL分析的Parquet文件。

他說：”這解決了一系列我們遇到的額外問題，而且我們現(xiàn)在處在一個利用Spark和Spark Streaming 將系統(tǒng)變得長期穩(wěn)定運行的節(jié)點上。我們也計劃從訪問和獲取原始數(shù)據(jù)也都用Spark任務(wù)、Hive、機器學(xué)習(xí)以及所有有趣的組件，將Spark的潛能徹底釋放出來。”

Paricon 和 Komondor

在 Chandar 給出了 Uber 涉險進入Spark的概況之后，另外兩名 Uber 工程師，Kelvin Chu 和 Reza Shiftehfar 提供了關(guān)于 Paricon 和 Shiftehfar 的更多細節(jié)。而這其實是Uber 進軍Spark的兩個核心項目。

雖然非結(jié)構(gòu)化數(shù)據(jù)可以輕松搞定，Uber最終還是需要通過數(shù)據(jù)管道生成結(jié)構(gòu)化數(shù)據(jù)，因為結(jié)構(gòu)化數(shù)據(jù)在數(shù)據(jù)生產(chǎn)者和數(shù)據(jù)使用者之間生成的”契約”可以有效避免”數(shù)據(jù)破損”。

這就是為什么Parino 會進入這個藍圖，Chu說道，Parino 這個工具是由4個 Spark為基礎(chǔ)的任務(wù)組成的：轉(zhuǎn)移、推斷、轉(zhuǎn)化并且驗證。”因此不論誰想要改變這個數(shù)據(jù)結(jié)構(gòu)，他們都將進入這個系統(tǒng)，并且必須使用我們提供的工具來修改數(shù)據(jù)結(jié)構(gòu)。然后系統(tǒng)將運行多個驗證和測試來確保這個改變不會有任何問題。”

Paricon 的一大亮點是所謂的”列式剪枝”。我們有許多寬表，但是通常我們每次都不會用到所有的列,因此剪枝可以有效節(jié)約系統(tǒng)的IO。他說道：”Paricon 也可以處理一些”數(shù)據(jù)縫合”工作。一些Uber的數(shù)據(jù)文件很大，但是大多數(shù)都是比HDFS區(qū)塊來得小的，因此我司將這些小數(shù)據(jù)縫合在一起對齊HDFS文件大小并且避免IO的運轉(zhuǎn)失常。加之Spark的”數(shù)據(jù)結(jié)構(gòu)聚合”功能也幫助我們用Paricon 工作流工具直觀簡化的方式處理Uber數(shù)據(jù)。”

與此同時， Shiftehfar 為Komondor、Spark Streaming內(nèi)建的數(shù)據(jù)攝取服務(wù)提供了架構(gòu)級別的諸多細節(jié)。而數(shù)據(jù)源是”烹飪”的基礎(chǔ)，原始非結(jié)構(gòu)數(shù)據(jù)從Kafka流入HDFS然后準(zhǔn)備被下游應(yīng)用消費。

在 Komondor 之前，它是用來為每個獨立應(yīng)用確保數(shù)據(jù)準(zhǔn)確性的工具(包括獲取他們正在處理的數(shù)據(jù)的上游數(shù)據(jù))并且在必要的時候做數(shù)據(jù)備份?，F(xiàn)在通過 Komondor 可以自動處理或多或少的數(shù)據(jù)。如果用戶需要加載數(shù)據(jù)，使用 Spark Streaming 就相對簡單得多。

為了處理每天***的事件和請求正在重金投入 Spark 并且打算撬動更多的 Spark技術(shù)棧,包括使用MLib和GraphX庫做機器學(xué)習(xí)和圖計算。更多細節(jié)，可以觀看下面演講的整個視頻。