文 | 呂毅，鏈家網平臺架構師

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

基于ROLAP技術的報表平臺

鏈家網大數據部門成立之初，面對著零散的數據需求，最早期的辦法是配置定時任務跑腳本，將結果通過郵件方式發送給需求方。2015年期間，隨著運營數據需求的增加、希望查閱數據的人員增多，郵件的方式不方便人員間信息傳遞，并且查找歷史數據也不方便，在技術上也因數據相關人太多導致郵件發送阻塞。

因此，考慮到運營數據需求、公司核心指標需求相對固定，并且維度可枚舉，特在2015年基于ROLAP技術方案，搭建了早期的報表系統。

圖1 鏈家網早期的報表系統

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

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

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

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

鏈家網大數據平臺的誕生

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

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

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

AdHoc系統：解決數據探索性需求，基于SQL查詢，查詢速度要求高;

地動儀：解決報表需求，承接較固化報表需求、公司級報表需求;

BI產品：解決數據分析需求，支持多維查詢，支持數據分析中常用的下鉆、上卷等功能;

數據API：解決數據API需求，大數據API統一出口，支持各部門的格式化數據獲取。

結合數據產品層面的規劃，大數據平臺在技術工作上做了重新規劃，技術工作上劃分出了四個部分：平臺服務、數據管理、工具鏈與集群。

其中平臺服務包含報表系統、BI系統與大數據API;大數據工具鏈包括OLAP引擎、即席查詢AdHoc系統、調度系統三部分;大數據集群層面除集群性能、穩定性工作外，還包括集群安全、集群資源隔離兩部分;貫穿服務、工具鏈、集群三層的數據管理部分，更加關注數據治理，內含元數據管理、指標管理、數據權限管理三大數據管理工作。技術工作劃分情況如圖2：

圖2 鏈家網大數據平臺

大數據平臺的建設過程，是由下而上逐步完成的。首先要有Hadoop集群，在有HDFS與Hive后，才能開展數據接入工作，才能基于集群建設工具鏈;當工具鏈部分的OLAP引擎構建好，才有上層BI、報表系統和數據API，只有AdHoc能力構建好，才能提供基于SQL的數據探索平臺，工具鏈中特別需要建設好調度系統，才能在實現好數據ETL任務的同時，管控數據流向與數據關系。

最后則是服務層面的建設，重心在于迎合需求的同時，服務做得更加易用。數據管理系統會穿插于整個大數據平臺中。

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

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

大數據平臺內部工作，完全可以簡單劃分為集群與服務兩部分，為何要在它們之間構建一層工具鏈層呢?由圖1可以看到，原大數據架構中，因產品層面單一，數據從收集入HDFS后，數據流向單一，均由Oozie調度任務從Hive獲取數據，并向上推送。

考慮到平臺服務層面的多個產品形態，數據流向也需擴展才能滿足產品所需能力，而數據流的管理與集群工作強制規劃在一起，太過生硬。故全新開辟一層工具鏈層，通過借助集群能力，通過或使用開源或自研，來擴展數據轉換與輸出的能力，提供更多種的數據流形式，以滿足上層數據服務需求。

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

圖3 大數據工具鏈數據流向規劃

數據探索類需求

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

1. 數據樣本：2000萬行數據集、7000萬行數據集;
2. SQL樣例：簡單SQL(select count)、復雜SQL(線上真實SQL);
3. 機器資源：
4. Hive：3臺機器;
5. Spark：4個節點;
6. Presto：3個節點，每節點最大內存4G。

通過多次測試結果顯示，在處理速度方面，Presto < Spark SQL < Hive，大部分情況下，Presto時間開銷上遠少于Hive SQL，速度優勢稍微好于Spark SQL。考慮到公司內探索性數據查詢需求由人發起，數量可控，Presto技術選型完全滿足我們對響應速度的要求。

故采用Presto引擎搭建AdHoc平臺，AdHoc的Web界面我們通過自研，除基礎的數據查詢功能外，實現了數據導出、轉發、生成報表等功能，其中生成報表功能與調度系統打通，將數據探索工作成果進一步延伸，由AdHoc發起的調度任務，則是使用MapReduce離線運算。關于Presto UI部分，Airbnb開源的Airpal界面簡潔清晰，也是不錯的選擇。

圖4 Airbnb開源的基于Presto的UI界面

數據分析類需求

數據分析性需求按照工作方式細分，還可以分為非技術人員使用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郵箱&rdquo;，這樣的需求，整個過程沒有產生HDFS文件的必要，但在使用Oozie時，我們不得不在每一步執行完后在HDFS中創建文件以便傳遞信息。

我們已經可預見未來數據任務需求會有所增加，隨之而來的數據任務種類也將會擴充，若不做調度系統上的改變，大數據平臺的數據任務能力，將會受限于Oozie的使用場景，這與平臺設計理念不符，工具應當更好的支持平臺建設，而非阻礙平臺發展。

所以在那時，我們決定自研大數據調度系統，在參考了行業內一些調度系統解決方案的同時，我們梳理了現有的任務種類與可能的未來需求，逐步排期的實現調度系統必須的兩大環節：調度環節、執行環節，并且抽象的設計了他們之間的傳輸協議，為未來擴展新型執行單元提供了可能。

圖5 調度系統前端功能

圖6 調度系統后端能力

工具鏈作為數據驅動紐帶，工具化的為上層平臺服務提供各類能力，上層平臺服務包裝大數據平臺能力，開放給用戶使用。圍繞著工具鏈的建設，大數據平臺較改造前的數據加工模式，提供了更豐富的上層數據服務。

通過Apache Kylin技術構建MOLAP引擎，與原有的ROLAP引擎相輔相成，搭配基于Presto的AdHoc服務，提供了一站式的快速數據查詢、分析平臺，并且提供了統一的大數據API，為公司各業務線、數據分析團隊、數據應用方提供高可用穩定的數據格式化出口。隨著調度系統的逐漸成熟，工具鏈層面的建設逐漸完善，平臺化的大數據服務，整體較從前有全面的改善。鏈家網的大數據工作逐漸從報表階段，步入了平臺化自助服務的階段。

技術挑戰

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

工具鏈中的技術挑戰還有不少，但我們清晰的發展路線，讓我們有堅定的信心去逐個攻克，也歡迎有志之士加入，一同建設鏈家網大數據平臺。

大數據平臺的規劃

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

在建設鏈家網大數據平臺期間，我們與百度、美團、滴滴和Kyligence有著良好的溝通交流，他們在大數據平臺上的沉淀與經驗在平臺設計規劃階段，對我們的幫助很大，我們也將會在建設鏈家網大數據平臺的同時，通過技術分享的方式與行業內大數據相關的朋友分享交流，幫助營造行業內大數據領域共同進步的良好氛圍。