[譯] 解密 Uber 數據團隊的基礎數據架構優化之路

概述

若是你用過Uber，你必定會注意到它的操做是如此的簡單。你一鍵叫車，隨後車就來找你了，最後自動完成支付，整個過程行雲流水。可是，在這簡單的流程背後實際上是用Hadoop和Spark這樣複雜的基礎大數據架構來支撐的。

Uber 在現實世界和虛擬世界的十字路口有使人羨慕的一席之地。這令天天在各個城市穿行的數十萬司機大軍趨之若鶩。固然這也會一個相對淺顯的數據問題。可是，就像Uber數據部門的主管 Aaron Schildkrout所說：商業計劃的簡單明瞭帶給Uber利用數據優化服務的巨大機會。

「這本質上來講是一個數據問題」，Schildkrout 最近在一個Uber和Databricks的演講記錄中說道。「由於事情是如此淺顯，咱們想讓用車體驗變得自動化。在某種程度上，咱們正在嘗試爲全世界的載客司機提供智能、自動化、實時的服務而且支撐服務的規模化。」

不管是Uber在峯時計價、幫助司機規避事故仍是爲司機尋找最優盈利位置，這一切 Uber 的計算服務都依賴於的數據。這些數據問題是一道數學和全球目的地預測的真正結晶。他說：」這使得這裏的數據很是振奮人心，也驅動咱們鬥志昂揚地用Spark解決這些問題」

Uber 的大數據之道

在Data bricks的演講中，Uber 工程師描述了（顯然是首次公開演講）一些在應用擴展和知足需求上公司遇到的挑戰。

做爲負責Uber 數據架構的總負責人，Vinoth Chandar說道：Spark 已是」必備神器了」。
在舊的架構下，Uber依賴於Kafka的數據流將大量的日誌數據傳輸到AWS的S3上，而後使用EMR來處理這些數據。而後再從EMR導入到能夠被內部用戶以及各個城市總監使用的關係型數據庫中。

Chandar說道：」原來的 Celery+Python的ETL架構其實運轉得挺好的，可是當Uber想要規模化時就遇到了一些瓶頸」。隨着咱們擴展的城市愈來愈多，這個數據規模也不斷增長，在現有的系統上咱們遇到了一系列的問題，尤爲是在數據上傳的批處理過程。

Uber 須要確保最重要的數據集之一的行程數據，這裏成百上千的真實準確的消費記錄將會影響到下游的用戶和應用。Chandar 說道：」這個系統原來並非爲了多數據中心設計的。咱們須要用一系列的融合方式將數據放到一個數據中內心面。」

解決方案演化出了一個所謂的基於Spark的流式IO架構，用來取代以前的Celery/Python ETL 架構。新系統從關係型數據倉庫表模型將原始數據攝取作了必要的解耦。Chandar說：」你能夠在HDFS上獲取數據而後再依賴於一些像Spark這樣的工具來處理大規模的數據處理。」

所以，取而代之的是在一個關係模型中從多個分佈式數據中心聚合行程數據，公司新的架構使用Kafka從本地數據中心來提供實時數據日誌，而且加載他們到中心化的Hadoop集羣中。接着，系統用Spark SQL 將非結構化的JSON轉化爲更加結構化的可使用Hive來作SQL分析的Parquet文件。

他說：」這解決了一系列咱們遇到的額外問題，並且咱們如今處在一個利用Spark和Spark Streaming 將系統變得長期穩定運行的節點上。咱們也計劃從訪問和獲取原始數據也都用Spark任務、Hive、機器學習以及全部有趣的組件，將Spark的潛能完全釋放出來。」

Paricon 和 Komondor

在 Chandar 給出了 Uber 涉險進入Spark的概況以後，另外兩名 Uber 工程師，Kelvin Chu 和 Reza Shiftehfar 提供了關於 Paricon 和 Shiftehfar 的更多細節。而這實際上是Uber 進軍Spark的兩個核心項目。

雖然非結構化數據能夠輕鬆搞定，Uber最終仍是須要經過數據管道生成結構化數據，由於結構化數據在數據生產者和數據使用者之間生成的」契約」能夠有效避免」數據破損」。

這就是爲何Parino 會進入這個藍圖，Chu說道，Parino 這個工具是由4個 Spark爲基礎的任務組成的：轉移、推斷、轉化而且驗證。」所以不論誰想要改變這個數據結構，他們都將進入這個系統，而且必須使用咱們提供的工具來修改數據結構。而後系統將運行多個驗證和測試來確保這個改變不會有任何問題。」

Paricon 的一大亮點是所謂的」列式剪枝」。咱們有許多寬表，可是一般咱們每次都不會用到全部的列,所以剪枝能夠有效節約系統的IO。他說道：」Paricon 也能夠處理一些」數據縫合」工做。一些Uber的數據文件很大，可是大多數都是比HDFS區塊來得小的，所以我司將這些小數據縫合在一塊兒對齊HDFS文件大小而且避免IO的運轉失常。加之Spark的」數據結構聚合」功能也幫助咱們用Paricon 工做流工具直觀簡化的方式處理Uber數據。」

與此同時， Shiftehfar 爲Komondor、Spark Streaming內建的數據攝取服務提供了架構級別的諸多細節。而數據源是」烹飪」的基礎，原始非結構數據從Kafka流入HDFS而後準備被下游應用消費。

在 Komondor 以前，它是用來爲每一個獨立應用確保數據準確性的工具（包括獲取他們正在處理的數據的上游數據）而且在必要的時候作數據備份。如今經過 Komondor 能夠自動處理或多或少的數據。若是用戶須要加載數據，使用 Spark Streaming 就相對簡單得多。

爲了處理天天百萬級的事件和請求正在重金投入 Spark 而且打算撬動更多的 Spark技術棧,包括使用MLib和GraphX庫作機器學習和圖計算。更多細節，能夠觀看下面演講的整個視頻。

Spark and Spark Streaming at Uber

參考資料

• spark meetup at uber slides

相關閱讀

• [譯]解密 Uber 數據部門的數據可視化最佳實踐

• [譯]解密 Uber 數據科學團隊路徑選擇算法的優化之路

英文原文做者： Alex Woodie 譯者： Harry Zhu
英文原文地址: http://www.datanami.com/2015/10/05/how-uber-uses-spark-and-hadoop-to-optimize-customer-experience/
更優閱讀體驗可直接訪問譯文地址：http://www.javashuo.com/article/p-ksxvuxvp-ed.html
做爲分享主義者(sharism)，本人全部互聯網發佈的圖文均聽從CC版權，轉載請保留做者信息並註明做者 Harry Zhu 的 FinanceR專欄:https://segmentfault.com/blog/harryprince，若是涉及源代碼請註明GitHub地址：https://github.com/harryprince。微信號: harryzhustudio商業使用請聯繫做者。