舉重若輕的人人車移動端資料平臺

關於人人車資料平臺，水永老師主要分享了4部分內容：

第一部分，整體的架構；

第二部分，Web IDE的實時計算平臺；

第三部分，對於離線結果的BI報表平臺；

第四部分，移動端的資料驅動實踐。

整體架構

1. 資料門戶中涵蓋幾個平臺：

BI報表、後設資料管理、實時計算平臺、自助取數平臺、資料工單平臺、監控平臺。

2. 資料平臺的發展歷程：

後設資料管理平臺、BI報表平臺、實時計算平臺、監控平臺、自助取數平臺、資料工單平臺、統一資料許可權平臺

3. 大資料平臺的整體架構：

One data，如圖，最左邊是資料來源，有日誌、埋點、MySQL、SDK，最後統一落在Hadoop上。避免資料煙囪，降低計算、儲存成本，保障資料指標口徑一致，各種場景下看到的資料一致性，為上層建立了統一的資料服務層One service奠基。

One service，資料的下游使用方很多，不可能讓每個使用的人直接查表，庫。在這種狀態下定義一個Service層，也就是api層，對外暴露查詢服務。這些是service層以下的引擎，底層有很多的引擎，對上層應用來說是無感知的。比如時序資料庫Druid，包括SQL on Hadoop模式的Presto，spark SQL。還有一些列式儲存的資料庫，比如ClickHouse。資料的使用通過資料後設資料平臺申請，按表級別粒度管控。Service層保證資料的一致性，不論是查Druid，還是ClickHouse，拿到的資料是一樣的。如果是小量資料則是restful api，大批量資料則是下載任務。

One meta，統一的後設資料管理，包含資料地圖，指標管理，許可權管控。後設資料可能是最後一塊要攻克的高地了，後設資料是資料的資料，即資料的骨架。承載底層資料生產的血緣、上層應用報表/指標。使用資料第一步，申請許可權，賬號。在指標百科中可以看到自己使用的資料指標在哪個儀表盤中，在BI平臺的儀表中申請許可權，大大提高資料分發使用的效率。有句話說的好，後設資料做得好，產品技術下班早。

4. 資料的流向

如圖，左側是它的分層，從資料來源到計算層，到資料通道，到引擎。從下往上，左側虛線是離線的資料，右側實線，是實時的資料。

首先資料從資料來源落到自己的Hadoop叢集上。再往上是SQL on Hadoop模式，零延遲，可以快速查到資料。再往上，實時部分，使用Spark Streaming去做Kafka通道的轉換，支撐訂單預估，風險評估等。

Lambda架構很理想，但在資料的一致性和準確性的挑戰上，大大增加了複雜度。對離線資料和實時資料上的應用和資料流進行拆分，業務分離，對不同的領域用專業的方案去解決。

實時計算平臺

實時計算平臺是基於Apache Spark構建的一站式、高效能實時大資料處理平臺，提供了一整套Web IDE用於編寫SQL，語法檢測、除錯、釋出、監控。對於只會寫SQL的BI同學來說，提供SQL語義的流式資料分析能力，可大幅降低流資料分析門檻。BI同學無需關注實現細節（將SQL轉化為Spark流式任務），只需選取輸入輸出表，根據需求編寫SQL即可實現一個實時計算任務。平臺當前支援MySQL、Kafka兩種資料來源，並支援異構資料來源join,及多流join（限定場景），支援使用者自定義UDF，同時為了應對不同的場景需要，支援了三種端到端的訊息傳輸語義：At-least-once、At-most-once、Exactly-once。

1. 計算引擎選型

實時計算常用的3個選型：Storm，Spark Streaming，Flink。

通過如上表格可對三者進行比較，首先淘汰的是Storm，因為它不支援使用SQL。

那剩下的就是Spark和Flink了，兩者都基於記憶體計算，而且都支援SQL，尤其Spark在SQL方面做了深層次的優化。

雖然兩者在流式計算方面做的都比較好。但兩者還是有區別的，Spark當前支援兩種引擎Streaming和Structured Streaming。Spark Streaming是Micro Batch模式，Structured streaming 即支援Micro Batch模式，又支援continuous模式（以流方式處理）。Flink Streaming以流的方式處理流資料。Spark和Flink當前都可以滿足我司在實時方面的需求，鑑於Spark社群更加活躍，更加穩定，而且在SQL優化方面做的比較好，最終選擇Spark作為計算引擎。

2. 實時計算平臺整體架構

實時計算資料流如上圖所示自左至右。資料來源從左側打點開始，業務RD在前端和後端會由不同的語言打點。通過統一的log打點平臺(log.renrenche.com)接受打點過來的資料。資料收集上來之後，開始資料平臺接入。資料上來以後做一個解壓和還原，還原之後進入到Kafka相應Topic中。實時計算平臺將Kafka topic作為資料來源，抽象為View進行使用。BI同學編寫SQL時可直接作為表查詢使用，輸出結果可根據實際需要選擇輸出到Mysql或者Kafka中。 進入到Mysql的資料可直接用於業務需要進行展示，進入Kafka的資料可通過同步工具，同步到ES或者druid中進行報表展示或者實時預警。

3. 實時資料管理

資料採集端有很多Client進行打點，將資料收集上來，這些資料如何管理？我們強調一個資料工單的平臺，其最大的好處是，在下拉單選頁面申請一個data job（業務線-部門-功能-xx），並填寫其用途，下游消費方。當下遊拿到這個data job時，可以在平臺上查到Schema，這個Schema就是後續的一個基礎。

4. 流與表的轉換

資料處理有一個非常核心的概念就是流和表，在實時裡就是一個流，在離線裡面就是一個表。Kafka完美的詮釋了流和表，因為Kafka既能為資料定義Schema，同時具有一個永續性以及可重放性，所以它能夠完美被Spark Streaming/ Structured讀取和解釋。平臺根據Topic對應的Schema，會將其生成一個base view。拿到這個base view之後對於使用者來說，將這個流變成了一個表。有了表之後，就可以讓使用者進行SQL實現一個實時任務，可以對錶進行聚合等離線常規操作。也可以異構表join，多流join等操作，底層流join由Spark Structured引擎支援。

計算之後的結果要被下游使用，又回寫入到kafka中去，誰讓kafka是最好的資料通道。實時的特點就是時序性，資料應用一個引擎最好的方式選擇一個時序資料庫，我們選擇了Druid。

5. Web IDE

左側上方的是目錄樹，方便進行專案管理。左中是資料來源，包括Mysql和Kafka，亦可以自行新增資料來源。左下是管理的UDF，引入進入專案即可使用，為了優化引入的jar包，亦可自行新增自定義UDF。右側是主介面，寫完SQL即可進行除錯、排錯，以及構造資料驗收，遮蔽掉實時環境、DataSet、DStream、RDD等概念。IDE中包含，除錯，監控，檢視血緣關係功能，對於非實時開發的同學而言，是極低的理解和使用成本，完全可以WEB IDE上自行完成一個實時任務開發。

6. 除錯

自動從資料來源Mysql/Kafka中取前幾條，填充到每一個欄位中去，得到構造資料，亦可以手工自定義資料，即可除錯和結果檢視。整個過程是與生產環境隔離，在docker環境完成，任務與任務之間相互隔離。

7. 監控

根據Spark暴露出來的API實現監控流資料的狀態，可時刻監控資料流入以及除錯延遲資訊。

8. 血緣關係

方便BI同學進行表間依賴關係的梳理，表有型別三種型別：真實表、匿名錶、臨時表，尤其排查複雜的SQL時，此處一目瞭然。

9. 引數配置

Web IDE 意味著線下IDE的功能都要有，包括可以配置引數，比如配置資訊，優化引數等，UDF的配置。對於各個引數要有預設引數。

10. 開發-除錯-釋出

手動提交實時任務時都是使用spark-submit，但這種方式並不適合進行自動化提交（依賴客戶端環境、上線速度慢、不便檢視任務狀態），最終確定基於YARN-API進行提交。所有的控制都在一個API中，無需上傳依賴jar，上線速度快，也方便檢視任務當前狀態，同時YARN-API是更友好的API介面。這樣就可以很輕易的去封裝每個引數。

封裝YARN-API的過程中包括了除錯和釋出。在Docker容器中編譯除錯，驗收通過後釋出上線，接入生產環境MySQL和Kafka資料。

11. 最後總結下實時計算平臺的特點：

BI報表平臺

我們的目標是，構建一個小白級拖拽，所見即所得，包含移動端的資料平臺。而在技術上需要考慮幾個大難點：

低延時。包括資料更新低延時、資料查詢低延時，在靈活的報表平臺上，資料預構建類的引擎幾乎不用考慮，需要精心管理索引的成本亦高，能在千萬記錄級別百餘欄位的資料基礎上，亞秒或秒級別。

高併發。低延時的一個剋星。沒有大記憶體，MPP架構就難以施展能力。即使有大記憶體，複雜度和高併發下，同樣也難以通過benchmark。

同步中全量增量的資料一致性。全量和增量同步還需要考慮主鍵去重、分割槽去重，一般的OLAP引擎資料寫入都是append模式，幾乎不支援update和delete。

1. 技術選型

在這些眼花撩亂的資料引擎中，各自有著自己特性，在不同的業務體系中，總有他們發揮的場景。我們需要一些標準評估哪個引擎更適合自身的業務場景，POC產品原型驗證以及TPC benchmark壓測。

自古磨刀不誤砍柴工，梳理清楚業務場景才能在對每一個引擎做POC時高效靠譜，不至於貿然上船而到後期騎虎難下。若能轉化成SQL場景，則在TPC-DS/TPC-H壓測下更能科學判斷一款引擎的場景能力。前者POC是定性分析，決定引擎能不能；後者TPC是定量分析，決定引擎到底有多強。

2. 一見鍾情ClickHouse

人人車的BI平臺選擇了ClickHouse，支援較高的併發，支援億級別量級查詢，支援增量、全量同步，支援冪等性去重，支援更新update和刪除delete，亞秒級延時，支援SQL。用自身業務的sql跑壓測，4臺測試機就跑出了10qps/30併發，已經是一見鍾情了。

列式資料引擎ClickHouse，有很多特別適合BI場景的特性。在我們使用SQL的時候往往查詢的列是很少的，列式資料庫可以讓我們在做聚合等操作時，只需要取出少量的列，可以大大減少記憶體與外存之間的資料交換。

ClickHouse效能確實太強悍了，在一臺4核8G的機器上，對一億七千條資料count，跑了3秒多。在第一次沒有任何快取的情況下，多維度group by+order by跑了9秒多。在我們看來ClickHouse如同AK47，簡單可靠，效能強悍，手動性強。換言之大部分需要自己配置，如分散式和副本集，資料去重冪等性。Clickhouse已經支援update/delete，方便做資料的更新，但在大資料的效能要求下，ReplacingMergeTree在實踐中仍然是更好的選擇。

3. BI 資料架構

ClickHouse借用Zookeeper實現叢集管理，高效管理副本和分片。副本可以提高叢集的穩定性，分片用於做效能的擴充套件。ClickHouse的副本，不僅可以提高穩定性，還可以提高效能。發來的請求可以均勻的落在副本上，壓測過程在幾乎效能隨之線性增長。

4. BI 報表平臺

單表查詢，選擇一個表，左側列出所有欄位，亦可自定義配置欄位名。拖拽欄位到維度和數值上，右側即會高亮顯示可用圖表型別。亦可增加對比軸，資料來源過濾，圖內篩選器，圖表生成後前端方便使用者自行篩選城市，時間等。

圖表編輯生成後，三端（PC、Android、IOS）同步原樣展示。

5. 高階功能

生成合表。除了單表查詢外，還可以自己寫SQL join/union生成新的表，儀表盤中的圖表可以在合表的基礎上輸出。適合一些有能力的分析師對數倉的主題表做深度關聯分析。

合表的血緣關係，上游的表是否生成，是否同步完成，以及被哪些合表作為源表使用，被哪些圖表使用。另外高階使用者可以根據自己的許可權從資料倉儲中查詢資料，已經在全家桶中AD-HOC打通。

6. 最後總結BI報表平臺特點：

資料驅動

我們線下有兩萬多人，包括銷售，評估師等，線上有上千人，包括運營，產品等。線上做資料分析和線下執行完全不是一個思路，線上的總部可以在web上在幾十個儀表盤關注幾百個指標，但是線下人員一個手機。

其次，要分清線下管理的難點和本質。線下評估師銷售面對的是各色各樣的人，還要跟黃牛鬥爭，直面金錢的誘惑（飛單），讓員工每天在一個開放的空間裡做人性的考驗，這種商業模式是不明智的。不要嘗試與線下鬥智鬥勇，猶如秀才帶兵打仗，如果沒有一個有力的管理抓手，將會在無數次學習中成長。

如果管理抓手剛好又能跟資料結合，實現對線下的業務管理和資料管理，這就是資料驅動。

資料驅動一直是經常聽說，但一直沒有親眼看到的東西，尤其在這種複雜的業務場景中。線上總部資料分析在PC端，做更全面深度分析，制定出與戰略相匹配的業務指標，且與業績直接掛鉤。並且特別為線下提供掌上資料移動端（Android，iOS），使得線下隨時隨地只關注和自己業績相關指標。考核什麼就會得到什麼，使線下人員的注意力聚焦自己每天業績，各層級管理人員資料彙總，無論是在資料流通和人員調動上，管理抓手更為高效。

作者介紹：

吳水永，人人車大資料平臺負責人，DevOps開源專案walle-web.io作者。2016年1月加入人人車，從0到1搭建起BI 報表平臺、實時計算平臺、後設資料管理、Ad-Hoc、ETL、資料工單化等大資料平臺，並結合大資料和營銷實現平臺化使用者增長、全渠道營銷。

本文來自吳水永在 DataFun 社群的演講，由 DataFun 編輯整理。