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

凱新的技術社群發表於2019-01-04
大資料架構

版權宣告：本套技術專欄是作者（秦凱新）平時工作的總結和昇華，通過從真實商業環境抽取案例進行總結和分享，並給出商業應用的調優建議和叢集環境容量規劃等內容，請持續關注本套部落格。QQ郵箱地址：1120746959@qq.com，如有任何技術交流，可隨時聯絡。

1：資料分層重要性

  • 遮蔽業務的影響，不必改一次業務就需要重新接入資料（進行業務解耦）。

  • 減少重複開發，開發一些通用的中間層資料，能夠減少極大的重複計算（抽取通用資料，形成維度）

  • 一個複雜的任務分解成多個步驟來完成，每一層只處理單一的步驟，比較簡單和容易理解。而且便於維護資料的準確性，當資料出現問題之後，可以不用修復所有的資料，只需要從有問題的步驟開始修復。（資料分層開發以及有步驟修復）

  • 清晰資料結構：每一個資料分層都有它的作用域，這樣我們在使用表的時候能更方便地定位和理解。（STAGE ，ODS ，DWD，DWS作用域各司其職）

2：工業級資料倉儲分層規劃與質量監控

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

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

  • 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 高併發資料接入架構設計

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

3.3 高可用工業資料接入架構設計

  • 非同步轉同步 ->限流演算法 ->選擇性丟棄流量
  • 開啟限流開關 –> 臨時擴容Spark Slave叢集 -> hash演算法分發資料->小時級粒度(磁碟+記憶體雙儲存)
  • 計算任務重分配 + 主備切換機制+YARN資源Fair佇列排程（或K8s叢集資源排程）
  • 快取叢集AutoLoadCache 解決方案+ JVM本地快取 + 限流機制
  • 冷資料高頻查詢快取（T+1模式下離線日誌高頻使用者分析 ）
  • MQ要求消費者配置副本機制和Ack應答機制。
  • MQ要求在高併發情況下，需要考慮千兆頻寬和萬兆頻寬對叢集規模的規劃。
  • MQ要求在執行限流操作時，還需要考慮資料永續性對叢集規模的規劃。

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

4: 工業級資料質量管理

資料異常如果由客戶方發現的而不是你，那麼它帶來的負面影響會超過你之前做的所有業務帶來的正面影響。

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

  • 規則引擎（通用模板建立）
  1. 資料落地監控
  2. 資料掉0監控：實際擴充套件一下就是資料量閾值監控，少於某個量就告警
  3. 重複資料監控：很多表一定要監控重複資料的，這點至關重要。
  4. 關鍵指標監控
  5. 資料同比環比監控

  • 資料對賬 Kafka資料落地，必須要有一個監控機制來知道我們的資料落地情況，離線資料同樣需要資料對賬，對賬方法有很多，比如可以和業務庫來對比。

  • 效能監控

  1. 查詢效能，比如es的某個索引，在不同時間段的查詢響應速度，同理presto、hive、kylin這些的查詢都需要注意一下，這點可以通過任務監控來觀察。
  2. 資料讀寫影響，機器故障影響，在寫入資料的時候其實會影響讀資料的，需要監控一下，並做相應調整。
  • 資料質量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 單節點部署模式

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

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 模式）。

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

  • 任務引擎高可用 從 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儲存。
    工業級數倉分層及高併發鬆耦合大資料平臺架構深入剖析-DW商業環境實戰

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
複製程式碼

5.5: 工業資料計算平臺與業務系統解耦設計

  • 訊息中介軟體削峰填谷

  • 手動流量開關配合資料庫運維操作

  • 多系統同時訂閱資料（廣播模式fanout）

  • 實時資料計算限流控制，把訊息系統作為資料儲存中間引擎，通過設定不同的消費速度進行資料的流入管控。

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

6:工業資料查詢平臺的架構優化（資料庫叢集方案優化）

版權宣告：本套技術專欄是作者（秦凱新）平時工作的總結和昇華，通過從真實商業環境抽取案例進行總結和分享，並給出商業應用的調優建議和叢集環境容量規劃等內容，請持續關注本套部落格。QQ郵箱地址：1120746959@qq.com，如有任何技術交流，可隨時聯絡。

6.1 純MySQL分庫分表及冷熱資料儲存弊端

  • 如果完全用MySQL資料庫叢集方案來承載是很不靠譜的，資料量是不斷增加，而且增速很快，每天都新增幾千萬，再強悍的分庫分表方案都是不合適的。
  • 為對冷資料的查詢，一般都是針對大量資料的查詢，比如使用者會選擇過去幾個月，甚至一年的資料進行分析查詢，此時如果純用MySQL必定是災難性的。

6.2 查詢平臺資料儲存優化（冷熱資料分層）

6.2.1 冷資料的查詢基本都是200毫秒以內的響應速度
  • 冷資料全部採用ES+HBase來進行儲存，ES中主要存放要對冷資料進行篩選的各種條件索引，比如日期以及各種維度的資料，然後HBase中會存放全量的資料欄位。
6.2.2 熱資料實現負載高併發的每秒十萬級別的查詢，
  • 熱資料快取(Redis及Codis)叢集（優先查詢快取）。
  • 熱資料資料庫叢集（其次查詢），主庫與從庫同步，分庫分表方案，實現基於Mysql熱資料查詢。

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

  • 90%以上的高併發查詢都走快取叢集，剩下10%的查詢落地到資料庫叢集

7 工業領域資料分析業務模型

  • 車輛熱區分佈
  • 車輛行駛區域模型
  • 充電區域模型
  • 車輛補貼預測計算
  • 每一輛車輛閒置率計算排序
  • 單臺車按月進行執行強度計算，進行多月份對比展示
  • 所有車輛進行執行強度排序，輔助排程。
  • 每一輛上個月每天平均行駛里程
  • 每一輛車上個月總執行天數
  • 維保預測
  • 每一臺車每個月總耗電量成本（充電），結合運營商力度，評估電池效能
  • 每一臺車平均每天的耗電量
  • 每一臺車綜合質量係數 = 1/月綜合故障次數
  • 每一臺車百公里耗電量
  • 每一臺車綜合成本系數 =上個月百公里回饋電量/上個月最高百公里回饋電量
  • 汽車載重分佈、滿載率分佈
  • 車速分佈統計和經濟性駕駛分析

8 總結

工業級大資料平臺的系統要求非常高，對於高併發的場景猶如家常便飯，這也是我為什麼花費大量筆墨來解析我主導的工業大資料倉儲的主要原因，到目前為止，這個架構是我最成功的平臺案例。包含了幾乎主流的大資料元件。當然還有Kylin，今天收到Kylin團隊的邀請，希望未來能夠為國產的優秀開源專案做一點貢獻。

版權宣告：本套技術專欄是作者（秦凱新）平時工作的總結和昇華，通過從真實商業環境抽取案例進行總結和分享，並給出商業應用的調優建議和叢集環境容量規劃等內容，請持續關注本套部落格。QQ郵箱地址：1120746959@qq.com，如有任何技術交流，可隨時聯絡。

秦凱新 於深圳

相關文章