鍊家網大資料平台樞紐——工具鍊

聲明：本文為《程式員》原創文章，未經允許不得轉載，更多精彩文章請訂閱2017年《程式員》。

作者：呂毅，鍊家網平台架構師。目前負責鍊家網大資料平台，之前曾負責鍊家網基礎服務平台建設。

責編：郭芮，關注大資料領域，尋求報道或投稿請聯系[email protected]。

鍊家網于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方面進行測試對比：

資料樣本：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有着良好的溝通交流，他們在大資料平台上的沉澱與經驗在平台設計規劃階段，對我們的幫助很大，我們也将會在建設鍊家網大資料平台的同時，通過技術分享的方式與行業内大資料相關的朋友分享交流，幫助營造行業内大資料領域共同進步的良好氛圍。

訂閱2017年程式員（含iOS、Android及印刷版）請通路 http://dingyue.programmer.com.cn

【訂閱咨詢】QQ：2251809102 電話：[phone]

想了解更多大資料相關資訊？立即掃碼關注吧。