大資料平臺架構設計探究

本文首發於 vivo網際網路技術 微信公眾號 
連結： https://mp.weixin.qq.com/s/npRRRDqNUHNjbybliFxOxA
作者：劉延江

近年來，隨著IT技術與大資料、機器學習、演算法方向的不斷髮展，越來越多的企業都意識到了資料存在的價值，將資料作為自身寶貴的資產進行管理，利用大資料和機器學習能力去挖掘、識別、利用資料資產。如果缺乏有效的資料整體架構設計或者部分能力缺失，會導致業務層難以直接利用大資料大資料，大資料和業務產生了巨大的鴻溝，這道鴻溝的出現導致企業在使用大資料的過程中出現資料不可知、需求難實現、資料難共享等一系列問題，本文介紹了一些資料平臺設計思路來幫助業務減少資料開發中的痛點和難點。

本文主要包括以下幾個章節:

1. 本文第一部分介紹一下大資料基礎元件和相關知識。

2. 第二部分會介紹lambda架構和kappa架構。

3. 第三部分會介紹lambda和kappa架構模式下的一般大資料架構

4. 第四部分介紹裸露的資料架構體系下資料端到端難點以及痛點。

5. 第五部分介紹優秀的大資料架構整體設計

6. 從第五部分以後都是在介紹透過各種資料平臺和元件將這些大資料元件結合起來打造一套高效、易用的資料平臺來提高業務系統效能，讓業務開發不在畏懼複雜的資料開發元件，無需關注底層實現，只需要會使用SQL就可以完成一站式開發，完成資料迴流，讓大資料不再是資料工程師才有的技能。

一、大資料技術棧

大資料整體流程涉及很多模組，每一個模組都比較複雜，下圖列出這些模組和元件以及他們的功能特性，後續會有專題去詳細介紹相關模組領域知識，例如資料採集、資料傳輸、實時計算、離線計算、大資料儲存等相關模組。

二、lambda架構和kappa架構

目前基本上所有的大資料架構都是基於lambda和kappa架構，不同公司在這兩個架構模式上設計出符合該公司的資料體系架構。lambda 架構使開發人員能夠構建大規模分散式資料處理系統。它具有很好的靈活性和可擴充套件性，也對硬體故障和人為失誤有很好的容錯性，關於lambda架構可以在網上搜到很多相關文章。而kappa架構解決了lambda架構存在的兩套資料加工體系，從而帶來的各種成本問題，這也是目前流批一體化研究方向，很多企業已經開始使用這種更為先進的架構。

Lambda架構

Kappa架構

三、kappa架構和lambda架構下的大資料架構

目前各大公司基本上都是使用kappa架構或者lambda架構模式，這兩種模式下大資料整體架構在早期發展階段可能是下面這樣的：

四、資料端到端痛點

雖然上述架構看起來將多種大資料元件串聯起來實行了一體化管理，但是接觸過資料開發的人會感受比較強烈，這樣的裸露架構業務資料開發需要關注很多基礎工具的使用，實際資料開發中存在很多痛點與難點，具體表現在下面一些方面。

1. 缺乏一套資料開發IDE來管理整個資料開發環節，長遠的流程無法管理起來。

2. 沒有產生標準資料建模體系，導致不同資料工程師對指標理解不同計算口徑有誤。

3. 大資料元件開發要求高，普通業務去直接使用Hbase、ES等技術元件會產生各種問題。

4. 基本上每個公司大資料團隊都會很複雜，涉及到很多環節，遇到問題難以定位難以找到對應負責人。

5. 難以打破資料孤島，跨團隊跨部門資料難以共享，互相不清楚對方有什麼資料。

6. 需要維護兩套計算模型批計算和流計算，難以上手開發，需要提供一套流批統一的SQL。

7. 缺乏公司層面的後設資料體系規劃，同一條資料實時和離線難以複用計算，每次開發任務都要各種梳理。

基本上大多數公司在資料平臺治理上和提供開放能力上都存在上述問題和痛點。在複雜的資料架構下，對於資料適用方來說，每一個環節的不清晰或者一個功能的不友好，都會讓複雜鏈路變更更加複雜起來。想要解決這些痛點，就需要精心打磨每一個環節，將上面技術元件無縫銜接起來，讓業務從端到端使用資料就像寫SQL查詢資料庫一樣簡單。

五、優秀的大資料整體架構設計

提供多種平臺以及工具來助力資料平臺：多種資料來源的資料採集平臺、一鍵資料同步平臺、資料質量和建模平臺、後設資料體系、資料統一訪問平臺、實時和離線計算平臺、資源排程平臺、一站式開發IDE。

六、後設資料-大資料體系基石

後設資料是打通資料來源、資料倉儲、資料應用，記錄了資料從產生到消費的完整鏈路。後設資料包含靜態的表、列、分割槽資訊(也就是MetaStore)。動態的任務、表依賴對映關係；資料倉儲的模型定義、資料生命週期；以及ETL任務排程資訊、輸入輸出等後設資料是資料管理、資料內容、資料應用的基礎。例如可以利用後設資料構建任務、表、列、使用者之間的資料圖譜；構建任務DAG依賴關係，編排任務執行序列；構建任務畫像，進行任務質量治理；提供個人或BU的資產管理、計算資源消耗概覽等。

可以認為整個大資料資料流動都是依靠後設資料來管理的，沒有一套完整的後設資料設計，就會出現上面的資料難以追蹤、許可權難以把控、資源難以管理、資料難以共享等等問題。

很多公司都是依靠hive來管理後設資料，但是個人認為在發展一定階段還是需要自己去建設後設資料平臺來匹配相關的架構。

關於後設資料可以參考餓了麼一些實戰:

七、流批一體化計算

如果維護兩套計算引擎例如離線計算Spark和實時計算Flink，那麼會對使用者造成極大困擾，既需要學習流計算知識也需要批計算領域知識。如果實時用Flink離線用Spark或者Hadoop，可以開發一套自定義的DSL描述語言去匹配不同計算引擎語法，上層使用者無需關注底層具體的執行細節，只需要掌握一門DSL語言，就可以完成Spark和Hadoop以及Flink等等計算引擎的接入。

八、實時與離線ETL平臺

ETL 即 Extract-Transform-Load，用來描述將資料從來源端經過抽取（extract）、轉換（transform）、載入（load）至目的端的過程。ETL 一詞較常用在資料倉儲，但其物件並不限於資料倉儲。一般而言ETL平臺在資料清洗、資料格式轉換、資料補全、資料質量管理等方面有很重要作用。作為重要的資料清洗中間層，一般而言ETL最起碼要具備下面幾個功能:

1. 支援多種資料來源，例如訊息系統、檔案系統等

2. 支援多種運算元，過濾、分割、轉換、輸出、查詢資料來源補全等運算元能力

3. 支援動態變更邏輯，例如上述運算元透過動態jar方式提交可以做到不停服釋出變更。

九、智慧統一查詢平臺

大多數資料查詢都是由需求驅動，一個需求開發一個或者幾個介面，編寫介面文件，開放給業務方呼叫，這種模式在大資料體系下存在很多問題：

1. 這種架構簡單，但介面粒度很粗，靈活性不高，擴充套件性差，複用率低.隨著業務需求的增加，介面的數量大幅增加，維護成本高企。

2. 同時，開發效率不高，這對於海量的資料體系顯然會造成大量重複開發，難以做到資料和邏輯複用，嚴重降低業務適用方體驗。

3. 如果沒有統一的查詢平臺直接將Hbase等庫暴露給業務，後續的資料許可權運維管理也會比較難，接入大資料元件對於業務適用方同樣很痛苦，稍有不慎就會出現各種問題。

透過一套智慧查詢解決上述大資料查詢痛點問題

十、數倉建模規範體系

隨著業務複雜度和資料規模上升，混亂的資料呼叫和複製，重複建設帶來的資源浪費，資料指標定義不同而帶來的歧義、資料使用門檻越來越高。以筆者見證實際業務埋點和數倉使用為例，同一個商品名稱有些表欄位是good_id,有些叫spu_id，還有很多其他命名，對於想利用這些資料人會造成極大困擾。因此沒有一套完整的大資料建模體系，會給資料治理帶來極大困難，具體表現在下面幾個方面：

1. 資料標準不一致，即使是同樣的命名，但定義口徑卻不一致。例如，僅uv這樣一個指標，就有十幾種定義。帶來的問題是：都是uv，我要用哪個？都是uv，為什麼資料卻不一樣？

2. 造成巨大研發成本，每個工程師都需要從頭到尾瞭解研發流程的每個細節，對同樣的“坑”每個人都會重新踩一遍，對研發人員的時間和精力成本造成浪費。這也是目標筆者遇到的困擾，想去實際開發提取資料太難。

3. 沒有統一的規範標準管理，造成了重複計算等資源浪費。而資料表的層次、粒度不清晰，也使得重複儲存嚴重。

因此大資料開發和數倉表設計必須要堅持設計原則，資料平臺可以開發平臺來約束不合理的設計，例如阿里巴巴的OneData體。一般而言，資料開發要經過按照下面的指導方針進行：

有興趣的可以參考阿里巴巴的OneData設計體系。

十一、一鍵整合平臺

很簡單的就能將各種各式資料一鍵採集到資料平臺，透過資料傳輸平臺將資料無縫銜接到ETL平臺。ETL透過和後設資料平臺打通，規範Schema定義，然後將資料轉換、分流流入到實時與離線計算平臺，後續任何針對該資料離線和實時處理，只需要申請後設資料表許可權就可以開發任務完成計算。資料採集支援多種各式資料來源，例如binlog、日誌採集、前端埋點、kafka訊息佇列等

十二、資料開發IDE-高效的端到端工具

高效的資料開發一站式解決工具，透過IDE可以完成實時計算與離線計算任務開發，將上述平臺全部打通提供一站式解決方案。資料開發IDE提供資料整合、資料開發、資料管理、資料質量和資料服務等全方位的產品服務，一站式開發管理的介面，透過資料IDE完成對資料進行傳輸、轉換和整合等操作。從不同的資料儲存引入資料，並進行轉化和開發，最後將處理好的資料同步至其他資料系統。透過高效率的大資料開發IDE，基本上讓大資料工程師可以遮蔽掉各種痛點，將上述多種平臺能力結合起來，讓大資料開發可以向寫SQL一樣簡單。

關於資料開發工具可以參考阿里雲的 。

解決端到端難點還需要其他若干能力輔助，這裡就不再敘述，有興趣的同學可以自行研究。

十三、其他

完整的資料體系研發還包括告警與監控中心、資源排程中心、資源計算隔離、資料質量檢測、一站式資料加工體系，這裡就不再繼續討論了。