前綴
常用數據收集和遷移：
flume，canal，sqoop，datax，waterdrop等
常用任務調度：
azkaban，oozie，dophinscheduler，airflow
常用部署運維：
cloudera manager, ambari，SaltStack等
常用監控告警：
Alertmanager+Prometheus，zabbix，openfalcon等
常用安全和權限：
Kerberos，ranger等
數據存儲：
HDFS，HBase，Kudu等
數據計算：
MapReduce, Spark, Flink
交互式查詢：
Impala, Presto
在線實時分析：
ClickHouse，Kylin，Doris，Druid，Kudu等
資源調度：
YARN，Mesos，Kubernetes
所謂的大數據中台就是封裝上述技術，實現平台化的一站式數據集成、計算、存儲、數據治理、數據透出使用的一站式平台。
最新的概念： 像數據治理，數據地圖，元數據管理，數據資產，數據血緣，數據湖等更新潮的概念。
所謂的大數據中台其實就是使用上述技術，把這些數據做成服務化，WEB方式配置化解決問題。
具體演繹流程如下：
數據庫階段 ---> 傳統數倉 ---> 大數據平台 ----> 大數據中台
數倉建模體系
Bill Inmon 提出的建模方法自頂向下（頂指數據的來源，在傳統數據倉庫中，就是各個業務數據
庫），基於業務中各個實體以及實體之間的關系，構建數據倉庫。比如之前數倉中講到的：商品
表，用戶表，交易表，兩個實體表，一個關系表。 從數據源開始構建，適用於應用場景比較固定的業務，比如金融領域。冗余數據少
Ralph Kimball 建模與 Bill Inmon 正好相反，是一種自底向上的模型設計方法，從數據分析的需求
出發，拆分維度和事實。那么用戶、商品就是維度，庫存、用戶賬戶余額是事實。適合於變化速度比較快的業務，比如互聯網。
數據中台產生背景
- 傳統數倉模型，煙囪式開發，效率低。而且產生各種數據指標不一致問題
- 數據開發周期太長，一個數據開發需求甚至要一周時間
- 機器開銷太大， 每個月賬單成指數級增長。
數據中台建設好之后，主要解決以下問題： 煙囪式開發 數據孤島 數據割裂
數據中台是指通過數據技術對海量數據進行采集、計算、存儲和處理，同時統一標准和口徑，形成全域級、可復用的數據資產中心和數據存儲能力中心，形成大數據資產層，進而為客戶提供高效的服務。
數據中台吸收了傳統數據倉庫、數據湖、大數據平台的優勢，同時又解決了數據共享的難題，通過數據應用，實現數據價值的落地。
阿里大中台、小前台模式
阿里數據和業務中台雙中台結構
數據中台主要解決的問題
- 指標口徑不一致：主要原因：業務口徑不一致、計算邏輯不一致、數據來源不一致。要實現一致，就務必確保對同一個指標，只有一個業務口徑，只加工一次，數據來源必須相同。
- 數據重復建設，需求響應時間長：解決數據復用的問題，要確保相同數據只加工一次，實現數據的共享。
- 取數效率低：面對幾千甚至上萬張表，運營，開發或者分析師想要快速找到想要的數據，以及做到精准理解這些數據意義，都非常的困難。所以需要構建一個全局的企業數據資產目錄，實現數據地圖的功能，快速找到數據
- 數據質量差：沒有數據稽核任務，運營不相信數據。存儲數據鏈路，及時發現數據質量問題，並恢復數據。
- 數據成本線性增長：大企業煙囪式開發，導致一個企業擁有很多小數倉，不同數倉可能開發相同任務，導致資源浪費，而且也做不到淘汰低價值數據任務。所以解決方案的核心：解決數據重復建設，打通數據孤島。
數據中台如何解決
OneData 就是所有數據只加工一次。
OneService 數據即服務，強調數據中台中的數據應該是通過 API 接口的方式被訪問。
API 接口一方面對應用開發屏蔽了底層數據存儲，使用統一標准的 API 接口查詢數據，提高了數據接入的速度。另一方面，對於數據開發，提高了數據應用的管理效率，建立了表到應用的鏈路關系。
oneservice 如何實現？
-
屏蔽底層數據來源的不同：不同的數據來源，統一的數據出口
-
實現包括權限，日志，監控等管控能力的數據網關：權限控制，統計分析，流量控制，成本控制等
-
給用戶屏蔽底層的物理數據模型，提供數據邏輯模型：動態拼接多張相同粒度的數據結構，簡化接入復雜度
-
提供無狀態的，高性能和穩定可靠的數據服務
-
由一個團隊，負責所有指標的管控，明確每個指標的業務口徑，數據來源和計算邏輯，消除指標二義性，確保任何一個指標的意義和計算邏輯，在全公司都只有一個唯一的相同口徑。
-
數據服務化，提高了數據應用接入和管理的效率。
-
對於非技術人員，數據中台提供了可視化的取數平台。你只需要選取指標、通過獲取指標系統中每個指標的可分析維度，然后勾選，添加篩選過濾條件，點擊查詢，就可以獲取數據。
-
構建了企業數據地圖，你可以很方便地檢索有哪些數據，它們在哪些表中，又關聯了哪些指標和維度
-
數據只能加工一次，強調數據的復用性
-
成本控制，研發了一個數據成本治理系統，從應用維度、表維度、任務的維度、文件的維度進行全面的治理。比如，某個任務產出的數據指標，在過去 30 天內都沒有被訪問過，所以這個任務是沒有作用沒有意義的
自助取數平台可以參考如下設計：
什么樣的企業適合構建數據中台？
數據中台的構建需要非常大的投入：一方面數據中台的建設離不開系統支撐，研發系統需要投入大量的人力，而這些系統是否能夠匹配中台建設的需求，還需要持續打磨。
建設數據中台需要考慮的因素如下：
- 企業是否有大量的數據應用場景：所以當你的企業有較多數據應用的場景時（一般有 3 個以上就可以考慮）
- 經過了快速的信息化建設，企業存在較多的業務數據的孤島，就是存在多個業務小數倉
- 當你的團隊正在面臨效率、質量和成本的苦惱時
- 當你所在的企業面臨經營困難，需要通過數據實現精益運營，提高企業的運營效率的時候
- 企業規模也是必須要考慮的一個因素，數據中台因為投入大，收益偏長線，所以更適合業務相對穩
定的大公司，並不適合初創型的小公司。
技術架構
中台要想做成的關鍵：
- 一把手牽頭，全員共識；
- 總體規划，分步實施；
- 找准切入點，解決具體業務問題
元數據中心
元數據划為三類：數據字典、數據血緣和數據特征。
數據字典：描述的是數據的結構信息：表結構信息，主要包括像表名，字段名稱、類型和注釋，表的數
據產出任務，表和字段的權限等
數據血緣：指一個表是直接通過哪些表加工而來。數據血緣一般會幫我們做影響分析和故障溯源。比如
說有一天，你的老板看到某個指標的數據違反常識，讓你去排查這個指標計算是否正確，你首先需要找
到這個指標所在的表，然后順着這個表的上游表逐個去排查校驗數據，才能找到異常數據的根源。
數據特征：主要是指數據的屬性信息：存儲空間大小，數倉分層，訪問熱度，主題分類，關聯指標等
元數據技術
開源的有 Netflix 的 Metacat、Apache 的 Atlas；
商業化的產品有 Cloudera Navigator。
關於開源的這兩款產品，Metacat 擅長管理數據字典，Atlas 擅長管理數據血緣。
Metacat 介紹：https://github.com/Netflix/metacat，最大的優勢：多數據源的可擴展架構
只需要定義一個 connector就能接入各種存儲，對於元數據沒有通過WEB平台維護，而是通過直連數據源的方式，不會存在保存2份元數據
Apache Atlas 介紹：http://atlas.apache.org/
血緣采集，一般可以通過三種方式：
- 通過靜態解析 SQL，獲得輸入表和輸出表； 不准確
- 通過實時抓取正在執行的 SQL，解析執行計划，獲取輸入表和輸出表； 比較理想 Atlas 采取的方案
- 通過任務日志解析的方式，獲取執行后的 SQL 輸入表和輸出表。血緣是執行后產生，確保是准確的，但是時效性比較差
對於 Hive 計算引擎，Atlas 通過 Hook 方式，實時地捕捉任務執行計划，獲取輸入表和輸出表，推送給
Kafka，由一個 Ingest 模塊負責將血緣寫入 JanusGraph 圖數據庫中。然后通過 API 的方式，基於圖查
詢引擎，獲取血緣關系。對於 Spark，Atlas 提供了 Listener 的實現方式。
元數據中心架構設計
功能模塊分為 數據血緣、數據字典和數據特征
元數據中心統一對外提供了 API 訪問接口，數據傳輸、數據地圖、數據服務等其他的子系統都可以通過
API 接口獲取元數據。另外 Ranger 可以基於元數據中心提供的 API 接口，獲取標簽對應的表，然后根
據標簽更新表對應的權限，實現基於標簽的權限控制。
元數據設計要點：
- 元數據中心設計上必須注意擴展性，能夠支持多個數據源，所以宜采用集成型的設計方式。
- 數據血緣需要支持字段級別的血緣，否則會影響溯源的范圍和准確性。
- 數據地圖提供了一站式的數據發現服務，解決了檢索數據，理解數據的“找數據的需求”。
指標管理
定義不一致，口徑不一致，計算邏輯就不一致。所以構建數據中台，需要提供全局一致的指標口徑，輸
出完備統一的指標字典。
指標管理常見問題：
- 相同指標名稱，口徑不一致：比如 "新用戶銷售額，7日UV"
- 相同口徑，指標名稱不一樣：比如 "優惠券抵扣金額" 和 "優惠券消費金額"
- 不同限定詞，描述相同事實過程的倆個指標，相同事實部分口徑不一致
- 指標口徑描述不清晰：比如 "關單金額"
- 指標命名難於理解：比如 "轉化率" 和 "ROI"
- 指標數據來源和計算邏輯不清晰
如何構建指標系統：
- 提供一個易於維護的規范標准化指標管理系統，具備查詢，增刪等功能。
- 數據中台團隊必須要有一個專門負責指標管理的人或者小組（一般不超過 3 個人），最好是數據產品經理來負責，如果你的公司沒有這個職位，也可以讓分析師承擔。
- 提供一個完備的指標創建流程：提交指標需求，需求評審，模型設計和數據開發，驗證，上線，應用接入
- 不同的兩個指標描述的相同業務過程中的相同事實部分口徑不一致，是指標梳理過程中最常見的問題，需要通過拆分原子指標和派生指標的方式解決。
模型設計
就是分層設計好，避免每次計算都從 ODS層開始拖數計算。
構建可復用模型的標准：數據模型可復用，完善且規范
統計明細層完善度：統計 DWD 層表被跨層引用次數即可，次數越多，證明完善度越好
DWS/ADS/DM 層完善度：能滿足多少查詢需求。
數據質量
根源：
- 業務系統變更，包括表結構變更（加減字段），源系統環境變更（擴容 agent沒有采集日志），源數據格式異常（JSON 格式改了）；
- 數據開發 Bug + 數據開發任務變更：忘了修改數據源（測試線上環境混用），寫死數據分區，數據格式異常
- 物理資源不足：YARN 上多租戶爭搶資源導致數據延遲產出
- 基礎設施不穩定：NameNode 高可用失效導致數據讀寫功能異常
如何提高數據質量？ - 添加稽核校驗任務：確保數據的完整性、一致性和准確性
- 建立全鏈路監控：可以基於血緣關系建立全鏈路數據質量監控。
- 通過智能預警，確保任務按時產出：延遲產出，異常任務等立即報警
- 通過應用的重要性區分數據等級，加快恢復速度
如何衡量數據質量
一切皆可量化
- 某個時間點以前核心任務的產出完成比，超過規定時間，沒有完成產出則稽核校驗失效
- 基於稽核規則，計算表級別的質量分數。對於低於質量分數的表，分發到響應責任人進行改進。
- 需要立即介入的報警次數。超過規定次數的需要立即介入
- 數據產品 SLA。數據應用中的所有指標在規定時間內產出。如果沒有，則計算不可用時間，不可用時間越短，證明SLA越好
成本控制
支撐好業務，獲得業務部門的認可
精簡架構，控制成本，為公司省錢
成本陷阱
數據上線容易，下線難，什么沒有下線機制。
低價值的數據應用消耗了大量的機器資源。
煙囪式的開發模式導致數據加工重復
數據傾斜導致資源分配利用不均衡
未設置數據生命周期，導致過期數據長期占用磁盤資源。
調度周期設置不合理，未形成閑忙搭配得當。
任務指定資源參數配置不當
數據為壓縮存儲
如何解決
- 全局資產盤點 基於數據血緣建立全鏈路的數據資產視圖。
1.1 一張表的成本 = 每個加工任務的計算資源成本 * m + 上有依賴表的存儲資源成本 * n
1.2 數據價值計算：給使用人數，使用頻率，數據應用數，老板等因素加權計算 - 發現問題
2.1 持續產生成本，但是已經沒有使用的末端數據（“沒有使用”一般指 30 天內沒有訪問）：沒有使用，卻消耗了資源
2.2 數據應用價值很低，成本卻很高，這些數據應用上游鏈路上的所有相關數據：低價值產出
2.3 高峰期高消耗的數據：高成本的數據 - 治理優化
3.1 對於第一類問題，應該對表進行下線
3.2 對於第二類問題，我們需要按照應用粒度評估應用是否還有存在的必要，如果沒有，則刪除。
3.3 對於第三類問題，主要是針對高消耗的數據，又具體分為產出數據的任務高消耗和數據存儲高消耗，分配到非高峰期運行即可。 - 治理效果評估
4.1 最簡單粗暴的標准：省了多少錢
4.2 下線了多少任務和數據；這些任務每日消耗了多少資源；數據占用了多少存儲空間。
4.3 將上述節省資源換算成錢，這就是你為公司省的錢
數據服務
主要解決問題：
1、數據接入效率低
之前需要對接各種存儲， 主要是存儲特性決定的， 現在是直接對接服務， 服務封裝了各種存儲。
2、數據服務解決的問題
存儲數據復用
服務復用
數據服務具備穩定性，限流等，最終實現共享數據的能力
3、不確定數據應用在哪里
數據服務鏈接了數據和應用的鏈路
下線數據的話能很快知道這些數據在那些服務中使用
4、數據部門的字段更變導致數據應用變更
底層表變更修改邏輯模型即可，不必再報錯
解決方案
接口規范化定義
數據網關
鏈路關系的維護
數據交付
提供多樣中間存儲
邏輯模型
API 接口
API 測試
基於相同主鍵的物理模型，可以構建邏輯模型，邏輯模型解決了數據復用的難題，提高了接口模型的發布效率；
IAAS
安裝 Amabari 和 HDP 的 CentOS7 集群; 主要解決Hadoop system 不好維護的問題。不管是 Hadoop V1 或者 V2
的安裝，又或者 Spark/YARN 等的集成，都不是幾行簡單的命令可以完成的，而是需要手工修改很多的
集群配置，這進一步增加了業務開發者的學習和使用難度。有了 Ambari，這些都不再是難題。