工業級數倉分層及高併發鬆耦合大數據平臺架構深刻剖析-DW商業環境實戰

時間 2019-11-08

標籤工業級數分層併發耦合數據平臺架構深刻剖析商業環境實戰欄目系統架構简体版

原文原文鏈接

1：數據分層重要性

屏蔽業務的影響，沒必要改一次業務就須要從新接入數據（進行業務解耦）。node
減小重複開發，開發一些通用的中間層數據，可以減小極大的重複計算（抽取通用數據，造成維度）算法
一個複雜的任務分解成多個步驟來完成，每一層只處理單一的步驟，比較簡單和容易理解。並且便於維護數據的準確性，當數據出現問題以後，能夠不用修復全部的數據，只須要從有問題的步驟開始修復。（數據分層開發以及有步驟修復）sql
清晰數據結構：每個數據分層都有它的做用域，這樣咱們在使用表的時候能更方便地定位和理解。（STAGE ，ODS ，DWD，DWS做用域各司其職）數據庫

2：工業級數據倉庫分層規劃與質量監控

優雅地把數據DWD層和輕度彙總層放在同一個層級上，同時獨立出來了維表和臨時表。apache

STAGE 層（與業務系統數據保持一致，多數據源的臨時存儲） STAGE 層做爲數據緩衝層，主要負責採集不一樣類型的業務系統數據並保存必定期限內的相關業務數據，完成不一樣類型數據源的統一臨時存儲，同時避免 ETL 操做對業務系統性能形成影響，STAGE 層數據在數據結構、數據之間的邏輯關係上都與業務系統基本保持一致。緩存
ODS 數據層（與業務系統數據保持一致，進行數據清洗及規範化，保證不一樣源數據的最終數據一致性，獲得業務要求的指標數據表） ODS（Operational Data Store）層數據來源於 STAGE 層，它的數據通過了對 STAGE 層數據的清洗，包括編碼表去重、去空、垃圾數據過濾、數據類型規則化等。安全
DWD 數據層（添加代理鍵，造成關聯體系，可單獨對外提供查詢服務）把 ODS 數據表結構改變成項目主題數據倉庫的表結構，對 DWD 層的全部表添加了代理鍵，標準化了業務系統編碼類型不統一的問題，創建了數據倉庫維度表和事實表的關聯體系，也爲緩慢變化維的實現奠基了基礎。數據結構
DWS：輕度彙總層（數據彙總，可與DWD進行並行存在） DWS：輕度彙總層，從ODS層中對用戶的行爲作一個初步的彙總，抽象出來一些通用的維度：時間、ip、id，並根據這些維度作一些統計值，好比用戶每一個時間段在不一樣登陸ip購買的商品數等。這裏作一層輕度的彙總會讓計算更加的高效，在此基礎上若是計算僅7天、30天、90天的行爲的話會快不少。咱們但願80%的業務都能經過咱們的DWS層計算，而不是ODS。架構

ODS -> DWS: 不必通過 dwd。我舉個例子，你的瀏覽商品行爲，我作一層輕度彙總，就直接放在 dws 了

DWD -> DWS: 若是所須要的資料表，要從好多表湊成一份，咱們從四五份我的資料表中湊出來了一份完整的資料表放在了 dwd 中。而後在 app 層，咱們要出一張畫像表，包含用戶資料和用戶近一年的行爲，咱們就直接從dwd中拿資料，而後再在 dws 的基礎上作一層統計，就成一個app表了。固然，這不是絕對，dws 和 dwd 有沒有依賴關係主要看有沒有這種需求。
DWC 數據層（數據推送到業務系統，如經過消息隊列進行解耦） DWC（Data Warehouse Center）層主要管理固化報表的數據存儲，數據主要來源於 DWD 層，根據前臺所需數據創建物理模型，使用 ETL 抽取 DWD 層數據推送給 DWC 層，這樣顯著減小前臺應用直接關聯 DWD 層查詢明細數據的成本，提升平臺數據獲取的速度。
TMP：臨時表（臨時表關聯） TMP每一層的計算都會有不少臨時表，專設一個DWTMP層來存儲咱們數據倉庫的臨時表。
DM 數據層（數據主題） DM（Data Mart）層即數據集市，將指標與維度創建物理模型組成數據集市，這是 OLAP 的數據基礎。該層實現了合併不一樣系統的數據源來知足面向主題的業務需求，它的建模是終端用戶驅動的，也是由業務需求驅動的。按主題，維度及 KPI 指標對 DM 層進行模型設計、建模，DM 層數據是將 DWD 層數據進行進一步整合、轉換、彙總、計算等 ETL 操做處理獲取的。

3 工業級數倉平臺承載千萬級別流量架構

3.1 設計準則

摒棄Mysql數據庫集羣（線上8主8從，32核+128G+SSD固態硬盤）承載高併發數據接入。
計算與存儲分離，層次要清晰。
kv存儲對高併發的支撐能力至少是MySQL的數倍甚至數十倍，好比Redis每秒承載幾萬併發，Hbase高性能的讀取和寫入性能。
Spark SQL計算引擎的深刻使用。
MQ削峯填谷以及流量控制，減輕kv存儲存儲壓力。
Spark 的廣播變量的使用以及cache靜態數據緩存。
MQ消費者流量控制系統重點實現數據校驗、過濾無效數據、切分數據分片、數據同步的冪等機制、100%保證數據落地到kv集羣的機制保障

3.2 高併發數據接入架構設計

3.3 高可用工業數據接入架構設計

異步轉同步 ->限流算法 ->選擇性丟棄流量
開啓限流開關 –> 臨時擴容Spark Slave集羣 -> hash算法分發數據->小時級粒度(磁盤+內存雙存儲)
計算任務重分配 + 主備切換機制+YARN資源Fair隊列調度（或K8s集羣資源調度）
緩存集羣AutoLoadCache 解決方案+ JVM本地緩存 + 限流機制
冷數據高頻查詢緩存（T+1模式下離線日誌高頻用戶分析）
MQ要求消費者配置副本機制和Ack應答機制。
MQ要求在高併發狀況下，須要考慮千兆帶寬和萬兆帶寬對集羣規模的規劃。
MQ要求在執行限流操做時，還須要考慮數據持久性對集羣規模的規劃。

4: 工業級數據質量管理

數據異常若是由客戶方發現的而不是你，那麼它帶來的負面影響會超過你以前作的全部業務帶來的正面影響。

規則引擎（通用模板創建）

數據落地監控
數據掉0監控：實際擴展一下就是數據量閾值監控，少於某個量就告警
重複數據監控：不少表必定要監控重複數據的，這點相當重要。
關鍵指標監控
數據同比環比監控

數據對帳 Kafka數據落地，必需要有一個監控機制來知道咱們的數據落地狀況，離線數據一樣須要數據對帳，對帳方法有不少，好比能夠和業務庫來對比。
性能監控

查詢性能，好比es的某個索引，在不一樣時間段的查詢響應速度，同理presto、hive、kylin這些的查詢都須要注意一下，這點能夠經過任務監控來觀察。
數據讀寫影響，機器故障影響，在寫入數據的時候其實會影響讀數據的，須要監控一下，並作相應調整。

數據質量4要素數據質量的評估，能夠從完整性、準確性、一致性和及時性來考慮。

5: Kylin+BI平臺的高可用系統架構設計

Kylin 可擴展: 指能夠對其主要依賴的三個模塊作任意的擴展和替換，Kylin 的三大依賴模塊分別是數據源（Hive）、構建引擎（MR）和存儲引擎（HBase）
Layered Cubing構建算法: 四維 Cube 須要五輪的 MapReduce 來完成：第一輪 MR 的輸入是源數據，這一步會對維度列的值進行編碼，並計算 ABCD 組合的結果。接下來的 MR 以上一輪的輸出結果爲輸入，向上聚合計算三個維度的組合：ABC、BCD、ABD和ACD；依此類推，直到算出全部的維度組合。問題是不能充分利用系統的資源以及緩存中間計算結果，存在shuffle過程，重點是穩定
Fast Cubing 構建算法：最大化利用 Mapper 端的 CPU 和內存，對分配的數據塊，將須要的組合全都作計算後再輸出給 Reducer；由 Reducer 再作一次合併（Merge），從而計算出完整數據的全部組合。配置方式kylin_job_conf_inmem.xml，包含了 MR 任務的配置項，當 Cube 構建算法是 Fast Cubing 時，會根據該文件的設置調整構建任務中的 MR 參數

調優必填項：

#KYLIN配置
     kylin.query.force-limit 默認是沒有限制，推薦設置爲 1000；
     kylin.storage.hbase.hfile-size-gb 能夠設置爲 1，有助於加快 MR 速度；
     kylin.storage.hbase.min-region-count 能夠設置爲 HBase 節點數，強制數據分散在 N 個節點；
     kylin.storage.hbase.compression-codec 默認沒有進行壓縮，推薦在環境運行狀況下配置壓縮算法。

     #Hadoop配置
     yarn.nodemanager.resource.memory-mb 配置項的值不小於 8192MB
     yarn.scheduler.maximum-allocation-mb 配置項的值不小於 4096MB
     mapreduce.reduce.memory.mb 配置項的值不小於 700MB
     mapreduce.reduce.java.opts 配置項的值不小於 512MB
     yarn.nodemanager.resource.cpu-vcores 配置項的值不小於 8
     
     //運行在yarn-cluster模式，固然能夠配置爲獨立 Spark 集羣：spark://ip:7077
     kylin.engine.spark-conf.spark.master=yarn
     kylin.engine.spark-conf.spark.submit.deployMode=cluster 
     
     //啓動動態資源分配
     kylin.engine.spark-conf.spark.dynamicAllocation.enabled=true
     kylin.engine.spark-conf.spark.dynamicAllocation.minExecutors=2
     kylin.engine.spark-conf.spark.dynamicAllocation.maxExecutors=1000
     kylin.engine.spark-conf.spark.dynamicAllocation.executorIdleTimeout=300
     kylin.engine.spark-conf.spark.shuffle.service.enabled=true
     kylin.engine.spark-conf.spark.shuffle.service.port=7337
     
     //內存設置
     kylin.engine.spark-conf.spark.driver.memory=2G
     
     //數據規模較大或者字典較大時，調大 executor 內存
     kylin.engine.spark-conf.spark.executor.memory=8G 
     kylin.engine.spark-conf.spark.executor.cores=4
     //心跳超時
     kylin.engine.spark-conf.spark.network.timeout=600
     //分區大小
     kylin.engine.spark.rdd-partition-cut-mb=100
複製代碼

Count_Distinct 度量：

近似實現：基於 HyperLogLog 算法，可接受的錯誤率（從9.75% 到 1.22%），低錯誤率須要更多存儲；
  精確實現：基於 Bitmap（位圖）算法，對於數據型爲 tinyint、smallint 和 int 的數據，
            將把數據對應的值直接打入位圖；對於數據型爲 long，string 和其餘的數
            據，將它們編碼成字符串放入字典，而後再將對應的值打入位圖。
            返回的度量結果是已經序列化的位圖數據，而不只是計算的值。
複製代碼

EXTEND_COLUMN 優化設置，解決存在對某個 id 進行過濾，但查詢結果要展現爲 name 的狀況。
聚合組（Aggregation Group）
必要維度（Mandatory Dimension）
層級維度（Hierachy Dimension）
聯合維度（Joint Dimension）

Rowkeys編碼，推薦的順序爲：Mandatory 維度、where 過濾條件中出現頻率較多的維度、高基數維度、低基數維度。這樣作的好處是，充分利用過濾條件來縮小在 HBase 中掃描的範圍，從而提升查詢的效率

dict：適用於大部分字段，默認推薦使用，但在超高基狀況下，可能引發內存不足的問題；
  boolean：適用於字段值爲true, false, TRUE, FALSE, True, False, t, f, T, F, yes, no, YES, NO, Yes, No, y, n, Y, N, 1, 0；integer：適用於字段值爲整數字符。
  date：適用於字段值爲日期字符，支持的格式包括yyyyMMdd、yyyy-MM-dd、yyyy-MM-dd HH:mm:ss、yyyy-MM-dd HH:mm:ss.SSS，其中若是包含時間戳部分會被截斷；
  fix_length：適用於超高基場景，將選取字段的前 N 個字節做爲編碼值，當 N 小於字段長度，會形成字段截斷
複製代碼

ShardBy 設置：建議選擇基數較大的列做爲 ShardBy 列，以使得數據能夠均勻分佈；

5.1 單節點部署模式

5.2 集羣部署模式

Kylin 實例是無狀態的服務，運行時的狀態信息存儲在 HBase metastore 中。出於負載均衡的考慮，您能夠啓用多個共享一個 metastore 的 Kylin 實例，使得各個節點分擔查詢壓力且互爲備份，從而提升服務的可用性。

Kylin 集羣模式部署若是您須要將多個 Kylin 節點組成集羣，請確保他們使用同一個 Hadoop 集羣、HBase 集羣。而後在每一個節點的配置文件 $KYLIN_HOME/conf/kylin.properties 中執行下述操做：

配置相同的 kylin.metadata.url 值，即配置全部的 Kylin 節點使用同一個 HBase metastore。
配置 Kylin 節點列表 kylin.server.cluster-servers，包括全部節點（包括當前節點），當事件變化時，接收變化的節點須要通知其餘全部節點（包括當前節點）。
配置 Kylin 節點的運行模式 kylin.server.mode，參數值可選 all, job, query 中的一個，默認值爲 all。 job 模式表明該服務僅用於任務調度，不用於查詢；query 模式表明該服務僅用於查詢，不用於構建任務的調度；all 模式表明該服務同時用於任務調度和 SQL 查詢。
注意：默認狀況下只有一個實例用於構建任務的調度（即 kylin.server.mode 設置爲 all 或者 job 模式）。

任務引擎高可用從 v2.0 開始, Kylin 支持多個任務引擎一塊兒運行，相比於默認單任務引擎的配置，多引擎能夠保證任務構建的高可用。
使用多任務引擎，你能夠在多個 Kylin 節點上配置它的角色爲 job 或 all。爲了不它們之間產生競爭，須要啓用分佈式任務鎖，請在 kylin.properties 裏配置：
```
kylin.job.scheduler.default=2
  kylin.job.lock=org.apache.kylin.storage.hbase.util.ZookeeperJobLock
複製代碼
```

5.3 讀寫分離部署模式

經過架構圖能夠看到Kylin會訪問兩個集羣的HDFS，建議兩個集羣的NameService務必不能相同，尤爲是集羣啓用NameNode HA時，相同的NameService會致使組件在跨集羣訪問HDFS時因沒法區分NameService而出現問題。
搭建兩個Hadoop環境當作Hadoop集羣，一個集羣部署HDFS、Hive、MR、YARN做爲計算集羣，負責Cube構建。一個集羣部署HDFS、YARN、HBase負責Cube存儲。

53.4 備份Kylin的元數據

從Kylin的配置文件kylin.properties中查看到：

## The metadata store in hbase
      kylin.metadata.url=kylin_metadata@hbase
      表示Kylin的元數據被保存在HBase的kylin_metadata表中
複製代碼

備份Kylin的元數據

/bin/metastore.sh backup
      這將備份元數據到本地目錄KYLIN_HOME/metadata_backps下面，目錄的命名格式爲：
      KYLIN_HOME/meta_backups/meta_year_month_day_hour_minute_second
      好比個人Kylin的家目錄爲/var/lib/kylin/kylin，那麼備份數據的目錄爲：
      /var/lib/kylin/kylin/meta_backups/meta_2018_01_04_11_50_32
複製代碼

恢復元數據

首先reset當前Kylin的元數據存儲，這將清理掉全部存儲在HBase中的Kylin元數據，確保在此以前作過備份。
```
./bin/metastore.sh reset
複製代碼
```
上傳備份的元數據到Kylin的元數據中
```
./bin/metastore.sh restore$KYLIN_HOME/meta_backups/meta_xxxx_xx_xx_xx_xx_xx 
複製代碼
```

從Kylin元數據中清理掉無用的資源

（1）首先，執行檢查，這是安全的操做，不會修改任何內容：
  ./bin/metastore.sh clean
  將須要被刪除的資源(resources)羅列出來
  
  （2）添加「--delete true」參數，這樣就會清理掉哪些無用的資源。
      切記，在這個命令操做以前，必定要備份Kylin元數據： 
  ./bin/metastore.sh clean --delete true
複製代碼