大數據平臺架構設計探究

本文首發於 vivo互聯網技術微信公衆號
連接：https://mp.weixin.qq.com/s/npRRRDqNUHNjbybliFxOxA
做者：劉延江html

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

本文主要包括如下幾個章節:算法

本文第一部分介紹一下大數據基礎組件和相關知識。數據庫
第二部分會介紹lambda架構和kappa架構。微信
第三部分會介紹lambda和kappa架構模式下的通常大數據架構架構
第四部分介紹裸露的數據架構體系下數據端到端難點以及痛點。app
第五部分介紹優秀的大數據架構總體設計運維
從第五部分之後都是在介紹經過各類數據平臺和組件將這些大數據組件結合起來打造一套高效、易用的數據平臺來提升業務系統效能，讓業務開發不在畏懼複雜的數據開發組件，無需關注底層實現，只須要會使用SQL就能夠完成一站式開發，完成數據迴流，讓大數據再也不是數據工程師纔有的技能。機器學習

1、大數據技術棧

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

2、lambda架構和kappa架構

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

Lambda架構

Kappa架構

3、kappa架構和lambda架構下的大數據架構

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

4、數據端到端痛點

雖然上述架構看起來將多種大數據組件串聯起來實行了一體化管理，可是接觸過數據開發的人會感覺比較強烈，這樣的裸露架構業務數據開發須要關注不少基礎工具的使用，實際數據開發中存在不少痛點與難點，具體表如今下面一些方面。

缺少一套數據開發IDE來管理整個數據開發環節，長遠的流程沒法管理起來。
沒有產生標準數據建模體系，致使不一樣數據工程師對指標理解不一樣計算口徑有誤。
大數據組件開發要求高，普通業務去直接使用Hbase、ES等技術組件會產生各類問題。
基本上每一個公司大數據團隊都會很複雜，涉及到不少環節，遇到問題難以定位難以找到對應負責人。
難以打破數據孤島，跨團隊跨部門數據難以共享，互相不清楚對方有什麼數據。
須要維護兩套計算模型批計算和流計算，難以上手開發，須要提供一套流批統一的SQL。
缺少公司層面的元數據體系規劃，同一條數據實時和離線難以複用計算，每次開發任務都要各類梳理。

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

5、優秀的大數據總體架構設計

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

6、元數據-大數據體系基石

元數據是打通數據源、數據倉庫、數據應用，記錄了數據從產生到消費的完整鏈路。元數據包含靜態的表、列、分區信息(也就是MetaStore)。動態的任務、表依賴映射關係；數據倉庫的模型定義、數據生命週期；以及ETL任務調度信息、輸入輸出等元數據是數據管理、數據內容、數據應用的基礎。例如能夠利用元數據構建任務、表、列、用戶之間的數據圖譜；構建任務DAG依賴關係，編排任務執行序列；構建任務畫像，進行任務質量治理；提供我的或BU的資產管理、計算資源消耗概覽等。

能夠認爲整個大數據數據流動都是依靠元數據來管理的，沒有一套完整的元數據設計，就會出現上面的數據難以追蹤、權限難以把控、資源難以管理、數據難以共享等等問題。

不少公司都是依靠hive來管理元數據，可是我的認爲在發展必定階段仍是須要本身去建設元數據平臺來匹配相關的架構。

關於元數據能夠參考餓了麼一些實戰:https://www.jianshu.com/p/f60b2111e414

7、流批一體化計算

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

8、實時與離線ETL平臺

ETL 即 Extract-Transform-Load，用來描述將數據歷來源端通過抽取（extract）、轉換（transform）、加載（load）至目的端的過程。ETL 一詞較經常使用在數據倉庫，但其對象並不限於數據倉庫。通常而言ETL平臺在數據清洗、數據格式轉換、數據補全、數據質量管理等方面有很重要做用。做爲重要的數據清洗中間層，通常而言ETL最起碼要具有下面幾個功能:

支持多種數據源，例如消息系統、文件系統等
支持多種算子，過濾、分割、轉換、輸出、查詢數據源補全等算子能力
支持動態變動邏輯，例如上述算子經過動態jar方式提交能夠作到不停服發佈變動。

9、智能統一查詢平臺

大多數數據查詢都是由需求驅動，一個需求開發一個或者幾個接口，編寫接口文檔，開放給業務方調用，這種模式在大數據體系下存在不少問題：

這種架構簡單，但接口粒度很粗，靈活性不高，擴展性差，複用率低.隨着業務需求的增長，接口的數量大幅增長，維護成本高企。
同時，開發效率不高，這對於海量的數據體系顯然會形成大量重複開發，難以作到數據和邏輯複用，嚴重下降業務適用方體驗。
若是沒有統一的查詢平臺直接將Hbase等庫暴露給業務，後續的數據權限運維管理也會比較難，接入大數據組件對於業務適用方一樣很痛苦，稍有不慎就會出現各類問題。

經過一套智能查詢解決上述大數據查詢痛點問題

10、數倉建模規範體系

隨着業務複雜度和數據規模上升，混亂的數據調用和拷貝，重複建設帶來的資源浪費，數據指標定義不一樣而帶來的歧義、數據使用門檻愈來愈高。以筆者見證明際業務埋點和數倉使用爲例，同一個商品名稱有些表字段是good_id,有些叫spu_id，還有不少其餘命名，對於想利用這些數據人會形成極大困擾。所以沒有一套完整的大數據建模體系，會給數據治理帶來極大困難，具體表如今下面幾個方面：

數據標準不一致，即便是一樣的命名，但定義口徑卻不一致。例如，僅uv這樣一個指標，就有十幾種定義。帶來的問題是：都是uv，我要用哪一個？都是uv，爲何數據卻不同？
形成巨大研發成本，每一個工程師都須要從頭至尾瞭解研發流程的每一個細節，對一樣的「坑」每一個人都會從新踩一遍，對研發人員的時間和精力成本形成浪費。這也是目標筆者遇到的困擾，想去實際開發提取數據太難。
沒有統一的規範標準管理，形成了重複計算等資源浪費。而數據表的層次、粒度不清晰，也使得重複存儲嚴重。

所以大數據開發和數倉表設計必需要堅持設計原則，數據平臺能夠開發平臺來約束不合理的設計，例如阿里巴巴的OneData體。通常而言，數據開發要通過按照下面的指導方針進行：

有興趣的能夠參考阿里巴巴的OneData設計體系。

11、一鍵集成平臺

很簡單的就能將各類各式數據一鍵採集到數據平臺，經過數據傳輸平臺將數據無縫銜接到ETL平臺。ETL經過和元數據平臺打通，規範Schema定義，而後將數據轉換、分流流入到實時與離線計算平臺，後續任何針對該數據離線和實時處理，只須要申請元數據表權限就能夠開發任務完成計算。數據採集支持多種各式數據來源，例如binlog、日誌採集、前端埋點、kafka消息隊列等

12、數據開發IDE-高效的端到端工具

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

關於數據開發工具能夠參考阿里雲的DataWorks。

解決端到端難點還須要其餘若干能力輔助，這裏就再也不敘述，有興趣的同窗能夠自行研究。

十3、其餘

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

更多內容敬請關注 vivo 互聯網技術 微信公衆號

注：轉載文章請先與微信號：labs2020 聯繫。