鏈家網大數據平台建設，平台樞紐——工具鏈

本文將介紹鏈家網的大數據平台建設，作者呂毅——鏈家網平台架構師，目前負責鏈家網大數據平台，之前曾負責鏈家網基礎服務平台建設。

正文

鏈家網於2015年成立大數據部門，開始構建基於Hadoop的技術體系，初期大數據部門以運營數據報表需求、公司核心指標需求為主。隨著2015年鏈家網發力線上業務，toB與toC業務齊頭並進，數據需求量激增的情況也隨之在2016年突顯，數據量增至PB級。我們開始思考如何改變現狀，如何高效支撐未來可預見的眾多數據需求。

基於ROLAP技術的報表平台

鏈家網大數據部門成立之初，面對著零散的數據需求，最早期的辦法是配置定時任務跑腳本，將結果通過郵件方式發送給需求方。2015年期間，隨著運營數據需求的增加、希望查閱數據的人員增多，郵件的方式不方便人員間信息傳遞，並且查找歷史數據也不方便，在技術上也因數據相關人太多導致郵件發送阻塞。因此，考慮到運營數據需求、公司核心指標需求相對固定，並且維度可枚舉，特在2015年基於ROLAP技術方案，搭建了早期的報表系統。

早期的報表系統，由數據開發工程師提交數據任務，通過配置Oozie定時任務，定時的基於Hive數據做ETL過程，將報表系統所需的數據推入關係型資料庫（MySQL）中。該系統從接收需求到報表系統里看到數據，需要比較長的一段時間過程，涵蓋過程如下：

溝通需求，由數據開發工程師理解數據需求；

• 對接數據，將數據源對接入HDFS；
• 構造數據，將數據加工處理到Hive中，逐層由STG到ODG，再到DW層；
• 數據任務，數據開發工程師根據需求方需求、DW層數據，編寫基於Oozie的調度任務；
• 發布任務，將Oozie調度任務發布到線上，定時執行，數據運行結果將被推送到MySQL；
• 數據展示，由自研的報表系統，根據需求方展示需求，添加維度篩選能力，開發一些對結果數據的再加工程序，部署上線。

流程過程較長，角色間傳遞信息較多，前後依賴太強，都是制約當時報表系統快速產出數據的根本問題。該系統在之後的迭代中，通過增加選取MySQL數據、自助勾選維度，實現了自助報表系統，命名為「地動儀」並服務至今。然而，流程長、傳遞信息多、依賴強的問題依舊沒有根本解決，對於逐漸增多的數據分析需求，更不能及時響應。

地動儀在一定程度上解決了郵件方式的弊端，提供Web界面化的查詢，支持歷史查詢和多人使用。但對於非訂製化需求、數據探索需求、數據分析需求支持的力度並不好。我們開始規劃更好的數據分析平台服務。

鏈家網大數據平台的誕生

大數據工作劃分，通常分為大數據應用、大數據平台兩大部分。常見的大數據應用形態有數據挖掘、數據分析、個性化推薦、數據報表等，大數據應用形式相對更多樣，可以根據業務不同而有具體的大數據應用產品。大數據平台，在一家公司中則應相對統一，以方便做好公司統一的數據接入規範、統一的數據管理機制、統一的數據處理能力等，做好數據管控。

因此，在對歷史大數據架構進行梳理後，鏈家網將原有大數據部門工作細化，將大數據應用交由業務線團隊或其他技術團隊承擔，便於業務線開展多樣化的數據工作，同時將大數據部門聚焦於構建公司統一的大數據平台，負責公司內各部門數據相關需求的統一規劃與實現，建設公司統一的數據倉庫與數據服務。至此，鏈家網大數據平台團隊誕生，我們開始著手建立平台，支持好未來公司內對數據使用上的各類需求。

在2016年中期，通過梳理各部門數據需求，將數據需求分類為：數據探索需求、報表需求、數據分析需求、數據API需求這四類。為滿足這些數據需求，我們相應規划了下面這些數據產品：

• AdHoc系統：解決數據探索性需求，基於SQL查詢，查詢速度要求高；
• 地動儀：解決報表需求，承接較固化報表需求、公司級報表需求；
• BI產品：解決數據分析需求，支持多維查詢，支持數據分析中常用的下鑽、上卷等功能；
• 數據API：解決數據API需求，大數據API統一出口，支持各部門的格式化數據獲取。

結合數據產品層面的規劃，大數據平台在技術工作上做了重新規劃，技術工作上劃分出了四個部分：平台服務、數據管理、工具鏈與集群。其中平台服務包含報表系統、BI系統與大數據API；大數據工具鏈包括OLAP引擎、即席查詢AdHoc系統、調度系統三部分；大數據集群層面除集群性能、穩定性工作外，還包括集群安全、集群資源隔離兩部分；貫穿服務、工具鏈、集群三層的數據管理部分，更加關注數據治理，內含元數據管理、指標管理、數據許可權管理三大數據管理工作。技術工作劃分情況如圖2：

大數據平台的建設過程，是由下而上逐步完成的。首先要有Hadoop集群，在有HDFS與Hive後，才能開展數據接入工作，才能基於集群建設工具鏈；當工具鏈部分的OLAP引擎構建好，才有上層BI、報表系統和數據API，只有AdHoc能力構建好，才能提供基於SQL的數據探索平台，工具鏈中特別需要建設好調度系統，才能在實現好數據ETL任務的同時，管控數據流向與數據關係。最後則是服務層面的建設，重心在於迎合需求的同時，服務做得更加易用。數據管理系統會穿插於整個大數據平台中。

大數據平台中銜接服務與集群的樞紐——工具鏈，正是整個平台能力的傳送帶，它肩負著將大數據能力輸送到上層服務層的重任，也承擔著上層多項服務被使用時的數據能力支持。

建設大數據平台樞紐——工具鏈

大數據平台內部工作，完全可以簡單劃分為集群與服務兩部分，為何要在它們之間構建一層工具鏈層呢？由圖1可以看到，原大數據架構中，因產品層面單一，數據從收集入HDFS後，數據流向單一，均由Oozie調度任務從Hive獲取數據，並向上推送。考慮到平台服務層面的多個產品形態，數據流向也需擴展才能滿足產品所需能力，而數據流的管理與集群工作強制規劃在一起，太過生硬。故全新開闢一層工具鏈層，通過藉助集群能力，通過或使用開源或自研，來擴展數據轉換與輸出的能力，提供更多種的數據流形式，以滿足上層數據服務需求。

對於工具鏈層面的設計，我們按照數據流向設計了下圖中的工具鏈結構：

數據探索類需求

數據探索類需求，即數據查詢需求，若都基於Hive採用MapReduce運算，速度上會大大影響用戶的使用體驗，然而即席查詢AdHoc技術方面，Facebook開源的基於內存計算的Presto進入了我們的視野，考慮到Presto與Hive均為Facebook開源技術，在SQL兼容性方面通用性更強，特對Hive、Presto、Spark在SQL on Hadoop方面進行測試對比：

引用

數據樣本：2000萬行數據集、7000萬行數據集；

SQL樣例：簡單SQL（select count）、複雜SQL（線上真實SQL）；

機器資源：

Hive：3台機器；

Spark：4個節點；

Presto：3個節點，每節點最大內存4G。

通過多次測試結果顯示，在處理速度方面，Presto < Spark SQL < Hive，大部分情況下，Presto時間開銷上遠少於Hive SQL，速度優勢稍微好於Spark SQL。考慮到公司內探索性數據查詢需求由人發起，數量可控，Presto技術選型完全滿足我們對響應速度的要求。故採用Presto引擎搭建AdHoc平台，AdHoc的Web界面我們通過自研，除基礎的數據查詢功能外，實現了數據導出、轉發、生成報表等功能，其中生成報表功能與調度系統打通，將數據探索工作成果進一步延伸，由AdHoc發起的調度任務，則是使用MapReduce離線運算。關於Presto UI部分，Airbnb開源的Airpal界面簡潔清晰，也是不錯的選擇。

數據分析類需求

數據分析性需求按照工作方式細分，還可以分為非技術人員使用Web工具分析數據、技術型人員直連Hadoop集群提交分析任務兩種類型。前者更多是運營、研究院、產品線數據PM等角色使用，後者則是做數據挖掘、推薦的工程師們在使用，對於工程師們，我們內網開放集群運算能力，供工程師們提交任務，通過集群中的資源隔離保障大家的任務高效運行。工具鏈中，則更關注前者的分析類場景，如何方便地滿足。

非技術人員的數據分析需求，相對於比較固話的數據報表型需求，指標、維度的組合上希望靈活性更高，並且有著下鑽、上卷分析數據的需求，更多維的查詢數據。因為分析工作一般是連續查詢數據，所以對於查詢速度也有一定的期望。

鑒於此，我們考慮通過預置數據的方式，通過空間換時間，來解決查詢速度問題。對於多維查詢需求，我們考慮通過構建多維Cube方案解決。這正是MOLAP解決數據查詢問題的方式，而MOLAP方案的有限技術選型中，我們更看好Apache Kylin項目。

Apache Kylin項目的一些特性，匹配我們的數據需求以及我們當時的現狀。數據需求已經梳理清晰，要快、要多維查詢，Kylin項目對於已創建了Cube並構建好數據的數據集上，提供亞秒級的快速查詢。並且Kylin還提供工具方便構建Cube、提供API方便對接上游BI產品。另一方面我們當時的現狀是，海量資料庫方面我們擁有穩定且調優過的HBase集群，這恰巧是Apache Kylin所依賴的資料庫選型。綜合這些情況，我們通過調研Kylin系統自身能力、Kylin與Sarku的對接情況，以及有Apache Kylin研發團隊成員現場交流，逐步啟動了基於Kylin的MOLAP引擎構建。預計不久我們將以Kylin為基礎，為BI產品、數據API兩項數據平台服務提供數據查詢能力，以滿足公司內的多維數據分析需求。

通過MOLAP建設，與原有地動儀ROLAP相輔相成，面向公司內有數據分析訴求的同事，提供更全面的數據分析平台。

調度系統

調度系統，是大數據工具鏈的核心環節，乃至是大數據平台化的基礎。數據ETL任務完全基於任務調度在有計劃地執行，數據任務的關係、數據血緣也需要基於調度系統的能力來自動化構建。

在鏈家網大數據平台建設之初，最先對原有的Oozie調度系統進行調研分析，發現Oozie與Hadoop集群綁定太過緊密，任務間的狀態傳遞必須依賴HDFS中的文件狀態來傳遞任務狀態，這導致一些數據任務需要我們用Hack的手段處理，例如我們的任務是定時「先將Hive數據導到MySQL，再運行一個遠程伺服器腳本對MySQL統計數據，再將腳本統計的結果發送到xxx@lianjia.com郵箱」，這樣的需求，整個過程沒有產生HDFS文件的必要，但在使用Oozie時，我們不得不在每一步執行完後在HDFS中創建文件以便傳遞信息。

我們已經可預見未來數據任務需求會有所增加，隨之而來的數據任務種類也將會擴充，若不做調度系統上的改變，大數據平台的數據任務能力，將會受限於Oozie的使用場景，這與平台設計理念不符，工具應當更好的支持平台建設，而非阻礙平台發展。所以在那時，我們決定自研大數據調度系統，在參考了行業內一些調度系統解決方案的同時，我們梳理了現有的任務種類與可能的未來需求，逐步排期的實現調度系統必須的兩大環節：調度環節、執行環節，並且抽象的設計了他們之間的傳輸協議，為未來擴展新型執行單元提供了可能。

工具鏈作為數據驅動紐帶，工具化的為上層平台服務提供各類能力，上層平台服務包裝大數據平台能力，開放給用戶使用。圍繞著工具鏈的建設，大數據平台較改造前的數據加工模式，提供了更豐富的上層數據服務。通過Apache Kylin技術構建MOLAP引擎，與原有的ROLAP引擎相輔相成，搭配基於Presto的AdHoc服務，提供了一站式的快速數據查詢、分析平台，並且提供了統一的大數據API，為公司各業務線、數據分析團隊、數據應用方提供高可用穩定的數據格式化出口。隨著調度系統的逐漸成熟，工具鏈層面的建設逐漸完善，平台化的大數據服務，整體較從前有全面的改善。鏈家網的大數據工作逐漸從報表階段，步入了平台化自助服務的階段。

技術挑戰

當然，在建設大數據工具鏈的過程中，依然還有不少技術問題需要攻堅。例如Presto中還未完全兼容Hive SQL語法，需要涉及到Presto SQL解析器部分的調整工作，又例如Kylin如何能夠根據指標系統中的指標自動構建Cube，需要考慮打通指標系統與Kylin系統，或通過自動化的程序來避免數據開發人員的重複操作。工具鏈中的技術挑戰還有不少，但我們清晰的發展路線，讓我們有堅定的信心去逐個攻克。

大數據平台的規劃

目前大數據工具鏈的技術問題，在陸續解決的同時，我們的平台服務、集群、數據管理相關的工作也都在緊鑼密鼓的進行中。整體大數據平台長線的一些工作，也在逐漸規劃著，例如自動化構建數據血緣、調度系統中任務DAG實時關係圖、MOLAP與ROLAP的融合、數據API的全自助服務等技術問題。相信未來半年到一年的大數據平台發展過程中，在將平台服務包裝的更為優秀的同時，將會積累更多實用的技術沉澱，促成公司、團隊、個人共同成長與進步。
推薦閱讀：