文 | 呂毅，鏈家網(wǎng)平臺架構(gòu)師

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

基于ROLAP技術(shù)的報表平臺

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

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

圖1 鏈家網(wǎng)早期的報表系統(tǒng)

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

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

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

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

鏈家網(wǎng)大數(shù)據(jù)平臺的誕生

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

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

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

AdHoc系統(tǒng)：解決數(shù)據(jù)探索性需求，基于SQL查詢，查詢速度要求高;

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

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

數(shù)據(jù)API：解決數(shù)據(jù)API需求，大數(shù)據(jù)API統(tǒng)一出口，支持各部門的格式化數(shù)據(jù)獲取。

結(jié)合數(shù)據(jù)產(chǎn)品層面的規(guī)劃，大數(shù)據(jù)平臺在技術(shù)工作上做了重新規(guī)劃，技術(shù)工作上劃分出了四個部分：平臺服務、數(shù)據(jù)管理、工具鏈與集群。

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

圖2 鏈家網(wǎng)大數(shù)據(jù)平臺

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

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

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

建設大數(shù)據(jù)平臺樞紐——工具鏈

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

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

對于工具鏈層面的設計，我們按照數(shù)據(jù)流向設計了下圖中的工具鏈結(jié)構(gòu)：

圖3 大數(shù)據(jù)工具鏈數(shù)據(jù)流向規(guī)劃

數(shù)據(jù)探索類需求

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

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

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

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

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

數(shù)據(jù)分析類需求

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

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

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

Apache Kylin項目的一些特性，匹配我們的數(shù)據(jù)需求以及我們當時的現(xiàn)狀。數(shù)據(jù)需求已經(jīng)梳理清晰，要快、要多維查詢，Kylin項目對于已創(chuàng)建了Cube并構(gòu)建好數(shù)據(jù)的數(shù)據(jù)集上，提供亞秒級的快速查詢。并且Kylin還提供工具方便構(gòu)建Cube、提供API方便對接上游BI產(chǎn)品。

另一方面我們當時的現(xiàn)狀是，海量數(shù)據(jù)庫方面我們擁有穩(wěn)定且調(diào)優(yōu)過的HBase集群，這恰巧是Apache Kylin所依賴的數(shù)據(jù)庫選型。綜合這些情況，我們通過調(diào)研Kylin系統(tǒng)自身能力、Kylin與Sarku的對接情況，以及有Apache Kylin研發(fā)團隊成員現(xiàn)場交流，逐步啟動了基于Kylin的MOLAP引擎構(gòu)建。預計不久我們將以Kylin為基礎，為BI產(chǎn)品、數(shù)據(jù)API兩項數(shù)據(jù)平臺服務提供數(shù)據(jù)查詢能力，以滿足公司內(nèi)的多維數(shù)據(jù)分析需求。

通過MOLAP建設，與原有地動儀ROLAP相輔相成，面向公司內(nèi)有數(shù)據(jù)分析訴求的同事，提供更全面的數(shù)據(jù)分析平臺。

調(diào)度系統(tǒng)

調(diào)度系統(tǒng)，是大數(shù)據(jù)工具鏈的核心環(huán)節(jié)，乃至是大數(shù)據(jù)平臺化的基礎。數(shù)據(jù)ETL任務完全基于任務調(diào)度在有計劃地執(zhí)行，數(shù)據(jù)任務的關系、數(shù)據(jù)血緣也需要基于調(diào)度系統(tǒng)的能力來自動化構(gòu)建。

在鏈家網(wǎng)大數(shù)據(jù)平臺建設之初，最先對原有的Oozie調(diào)度系統(tǒng)進行調(diào)研分析，發(fā)現(xiàn)Oozie與Hadoop集群綁定太過緊密，任務間的狀態(tài)傳遞必須依賴HDFS中的文件狀態(tài)來傳遞任務狀態(tài)，這導致一些數(shù)據(jù)任務需要我們用Hack的手段處理。

例如我們的任務是定時“先將Hive數(shù)據(jù)導到MySQL，再運行一個遠程服務器腳本對MySQL統(tǒng)計數(shù)據(jù)，再將腳本統(tǒng)計的結(jié)果發(fā)送到xxx@lianjia.com郵箱”，這樣的需求，整個過程沒有產(chǎn)生HDFS文件的必要，但在使用Oozie時，我們不得不在每一步執(zhí)行完后在HDFS中創(chuàng)建文件以便傳遞信息。

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

所以在那時，我們決定自研大數(shù)據(jù)調(diào)度系統(tǒng)，在參考了行業(yè)內(nèi)一些調(diào)度系統(tǒng)解決方案的同時，我們梳理了現(xiàn)有的任務種類與可能的未來需求，逐步排期的實現(xiàn)調(diào)度系統(tǒng)必須的兩大環(huán)節(jié)：調(diào)度環(huán)節(jié)、執(zhí)行環(huán)節(jié)，并且抽象的設計了他們之間的傳輸協(xié)議，為未來擴展新型執(zhí)行單元提供了可能。

圖5 調(diào)度系統(tǒng)前端功能

圖6 調(diào)度系統(tǒng)后端能力

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

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

技術(shù)挑戰(zhàn)

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

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

大數(shù)據(jù)平臺的規(guī)劃

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

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