常見的大資料平台架構設計思路
本文主要包括以下幾個章節:
- 本文第一部分介紹一下大資料基礎元件和相關知識。
- 第二部分會介紹lambda架構和kappa架構。
- 第三部分會介紹lambda和kappa架構模式下的一般大資料架構
- 第四部分介紹裸露的資料架構體系下資料端到端難點以及痛點。
- 第五部分介紹優秀的大資料架構整體設計
- 從第五部分以後都是在介紹通過各種資料平台群組件将這些大資料元件結合起來打造一套高效、易用的資料平台來提高業務系統效能，讓業務開發不再畏懼複雜的資料開發元件，無需關注底層實作，隻需要會使用SQL就可以完成一站式開發，完成資料回流，讓大資料不再是資料工程師才有的技能。
一、大資料技術棧
大資料整體流程涉及很多子產品，每一個子產品都比較複雜，下圖列出這些子產品群組件以及他們的功能特性，後續會有專題去詳細介紹相關子產品領域知識，例如資料采集、資料傳輸、實時計算、離線計算、大資料儲存等相關子產品。
二、lambda架構和kappa架構
目前基本上所有的大資料架構都是基于lambda和kappa架構，不同公司在這兩個架構模式上設計出符合該公司的資料體系架構。lambda 架構使開發人員能夠建構大規模分布式資料處理系統。它具有很好的靈活性和可擴充性，也對硬體故障和人為失誤有很好的容錯性，關于lambda架構可以在網上搜到很多相關文章。而kappa架構解決了lambda架構存在的兩套資料加工體系，進而帶來的各種成本問題，這也是目前流批一體化研究方向，很多企業已經開始使用這種更為先進的架構。
Lambda架構
Kappa架構
三、kappa架構和lambda架構下的大資料架構
目前各大公司基本上都是使用kappa架構或者lambda架構模式，這兩種模式下大資料整體架構在早期發展階段可能是下面這樣的：
四、資料端到端痛點
雖然上述架構看起來将多種大資料元件串聯起來實行了一體化管理，但是接觸過資料開發的人會感受比較強烈，這樣的裸露架構業務資料開發需要關注很多基礎工具的使用，實際資料開發中存在很多痛點與難點，具體表現在下面一些方面。
缺乏一套資料開發IDE來管理整個資料開發環節，長遠的流程無法管理起來。沒有産生标準資料模組化體系，導緻不同資料工程師對名額了解不同計算口徑有誤。大資料元件開發要求高，普通業務去直接使用Hbase、ES等技術元件會産生各種問題。基本上每個公司大資料團隊都會很複雜，涉及到很多環節，遇到問題難以定位難以找到對應負責人。難以打破資料孤島，跨團隊跨部門資料難以共享，互相不清楚對方有什麼資料。需要維護兩套計算模型批計算和流計算，難以上手開發，需要提供一套流批統一的SQL。缺乏公司層面的中繼資料體系規劃，同一條資料實時和離線難以複用計算，每次開發任務都要各種梳理。
基本上大多數公司在資料平台治理上和提供開放能力上都存在上述問題和痛點。在複雜的資料架構下，對于資料使用方來說，每一個環節的不清晰或者一個功能的不友好，都會讓複雜鍊路變得更加複雜起來。想要解決這些痛點，就需要精心打磨每一個環節，将上面技術元件無縫銜接起來，讓業務從端到端使用資料就像寫SQL查詢資料庫一樣簡單。
五、優秀的大資料整體架構設計
提供多種平台以及工具來助力資料平台：多種資料源的資料采集平台、一鍵資料同步平台、資料品質和模組化平台、中繼資料體系、資料統一通路平台、實時和離線計算平台、資源排程平台、一站式開發IDE。
六、中繼資料-大資料體系基石
中繼資料是打通資料源、資料倉庫、資料應用，記錄了資料從産生到消費的完整鍊路。中繼資料包含靜态的表、列、分區資訊(也就是MetaStore)。動态的任務、表依賴映射關系；資料倉庫的模型定義、資料生命周期；以及ETL任務排程資訊、輸入輸出等中繼資料是資料管理、資料内容、資料應用的基礎。例如可以利用中繼資料建構任務、表、列、使用者之間的資料圖譜；建構任務DAG依賴關系，編排任務執行序列；建構任務畫像，進行任務品質治理；提供個人或BU的資産管理、計算資源消耗概覽等。
可以認為整個大資料資料流動都是依靠中繼資料來管理的，沒有一套完整的中繼資料設計，就會出現上面的資料難以追蹤、權限難以把控、資源難以管理、資料難以共享等等問題。
很多公司都是依靠hive來管理中繼資料，但是個人認為在發展一定階段還是需要自己去建設中繼資料平台來比對相關的架構。
關于中繼資料可以參考餓了麼一些實戰:https://www.jianshu.com/p/f60b2111e414
七、流批一體化計算
如果維護兩套計算引擎例如離線計算Spark和實時計算Flink，那麼會對使用者造成極大困擾，既需要學習流計算知識也需要批計算領域知識。如果實時用Flink離線用Spark或者Hadoop，可以開發一套自定義的DSL描述語言去比對不同計算引擎文法，上層使用者無需關注底層具體的執行細節，隻需要掌握一門DSL語言，就可以完成Spark和Hadoop以及Flink等等計算引擎的接入。
八、實時與離線ETL平台
ETL 即 Extract-Transform-Load，用來描述将資料從來源端經過抽取（extract）、轉換（transform）、加載（load）至目的端的過程。ETL 一詞較常用在資料倉庫，但其對象并不限于資料倉庫。一般而言ETL平台在資料清洗、資料格式轉換、資料補全、資料品質管理等方面有很重要作用。作為重要的資料清洗中間層，一般而言ETL最起碼要具備下面幾個功能:支援多種資料源，例如消息系統、檔案系統等支援多種算子，過濾、分割、轉換、輸出、查詢資料源補全等算子能力支援動态變更邏輯，例如上述算子通過動态jar方式送出可以做到不停服釋出變更。
九、智能統一查詢平台
大多數資料查詢都是由需求驅動，一個需求開發一個或者幾個接口，編寫接口文檔，開放給業務方調用，這種模式在大資料體系下存在很多問題：這種架構簡單，但接口粒度很粗，靈活性不高，擴充性差，複用率低.随着業務需求的增加，接口的數量大幅增加，維護成本高企。同時，開發效率不高，這對于海量的資料體系顯然會造成大量重複開發，難以做到資料和邏輯複用，嚴重降低業務适用方體驗。如果沒有統一的查詢平台直接将Hbase等庫暴露給業務，後續的資料權限運維管理也會比較難，接入大資料元件對于業務适用方同樣很痛苦，稍有不慎就會出現各種問題。
通過一套智能查詢解決上述大資料查詢痛點問題
十、數倉模組化規範體系
随着業務複雜度和資料規模上升，混亂的資料調用和拷貝，重複建設帶來的資源浪費，資料名額定義不同而帶來的歧義、資料使用門檻越來越高。以筆者見證明際業務埋點和數倉使用為例，同一個商品名稱有些表字段是good_id,有些叫spu_id，還有很多其他命名，對于想利用這些資料人會造成極大困擾。是以沒有一套完整的大資料模組化體系，會給資料治理帶來極大困難，具體表現在下面幾個方面：
資料标準不一緻，即使是同樣的命名，但定義口徑卻不一緻。例如，僅uv這樣一個名額，就有十幾種定義。帶來的問題是：都是uv，我要用哪個？都是uv，為什麼資料卻不一樣？造成巨大研發成本，每個工程師都需要從頭到尾了解研發流程的每個細節，對同樣的“坑”每個人都會重新踩一遍，對研發人員的時間和精力成本造成浪費。這也是目标筆者遇到的困擾，想去實際開發提取資料太難。沒有統一的規範标準管理，造成了重複計算等資源浪費。而資料表的層次、粒度不清晰，也使得重複存儲嚴重。
是以大資料開發和數倉表設計必須要堅持設計原則，資料平台可以開發平台來限制不合理的設計，例如阿裡巴巴的OneData體。一般而言，資料開發要經過按照下面的指導方針進行：
有興趣的可以參考阿裡巴巴的OneData設計體系。
十一、一鍵內建平台
很簡單的就能将各種各式資料一鍵采集到資料平台，通過資料傳輸平台将資料無縫銜接到ETL平台。ETL通過和中繼資料平台打通，規範Schema定義，然後将資料轉換、分流流入到實時與離線計算平台，後續任何針對該資料離線和實時處理，隻需要申請中繼資料表權限就可以開發任務完成計算。資料采集支援多種各式資料來源，例如binlog、日志采集、前端埋點、kafka消息隊列等
十二、資料開發IDE-高效的端到端工具
高效的資料開發一站式解決工具，通過IDE可以完成實時計算與離線計算任務開發，将上述平台全部打通提供一站式解決方案。資料開發IDE提供資料內建、資料開發、資料管理、資料品質和資料服務等全方位的産品服務，一站式開發管理的界面，通過資料IDE完成對資料進行傳輸、轉換和內建等操作。從不同的資料存儲引入資料，并進行轉化和開發，最後将處理好的資料同步至其他資料系統。通過高效率的大資料開發IDE，基本上讓大資料工程師可以屏蔽掉各種痛點，将上述多種平台能力結合起來，讓大資料開發可以向寫SQL一樣簡單。
關于資料開發工具可以參考阿裡雲的DataWorks。
解決端到端難點還需要其他若幹能力輔助，這裡就不再叙述，有興趣的同學可以自行研究。
十三、其他
完整的資料體系研發還包括告警與監控中心、資源排程中心、資源計算隔離、資料品質檢測、一站式資料加工體系，這裡就不再繼續讨論了。
文章來源：https://www.bemore.cn/常見的大資料平台架構設計思路