非常感謝分享，學習了。

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

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

　　基於ROLAP技術的報表平臺

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

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

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

　　早期的報表系統，由資料開發工程師提交資料任務，通過配置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：

　　圖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方面進行測試對比：

　　資料樣本：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介面簡潔清晰，也是不錯的選擇。

　　圖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統計資料，再將指令碼統計的結果傳送到[email protected]郵箱”，這樣的需求，整個過程沒有產生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有著良好的溝通交流，他們在大資料平臺上的沉澱與經驗在平臺設計規劃階段，對我們的幫助很大，我們也將會在建設鏈家網大資料平臺的同時，通過技術分享的方式與行業內大資料相關的朋友分享交流，幫助營造行業內大資料領域共同進步的良好氛圍。