近年來，隨着IT技術與大數據、機器學習、算法方向的不斷髮展，越來越多的企業都意識到了數據存在的價值，將數據作爲自身寶貴的資產進行管理，利用大數據和機器學習能力去挖掘、識別、利用數據資產。
如果缺乏有效的數據整體架構設計或者部分能力缺失，會導致業務層難以直接利用大數據大數據，大數據和業務產生了巨大的鴻溝，這道鴻溝的出現導致企業在使用大數據的過程中出現數據不可知、需求難實現、數據難共享等一系列問題，本文介紹了一些數據平臺設計思路來幫助業務減少數據開發中的痛點和難點。
我調研了10家公司，寫出了這篇文章。
一、大數據技術棧
大數據整體流程涉及很多模塊，每一個模塊都比較複雜，下圖列出這些模塊和組件以及他們的功能特性，後續會有專題去詳細介紹相關模塊領域知識，例如數據採集、數據傳輸、實時計算、離線計算、大數據儲存等相關模塊。
二、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來管理元數據，但是個人認爲在發展一定階段還是需要自己去建設元數據平臺來匹配相關的架構。
七、流批一體化計算
如果維護兩套計算引擎例如離線計算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體。一般而言，數據開發要經過按照下面的指導方針進行：
