資料倉庫學習筆記（二）
這一系列主要是美團18年一年的大資料相關的文章分享，倒序。 從中可以看到美團的實時資料系統架構從Storm到Flink的轉變和選擇。
美團點評基於 Flink 的實時數倉建設實踐
source: tech.meituan.com/2018/10/18/…
關鍵詞
實時數倉，Flink,Spark-Streaming,Storm
初期架構
問題
- 資料指標越來越多，“煙囪式”的開發導致程式碼耦合問題嚴重。
- 需求越來越多，有的需要明細資料，有的需要 OLAP 分析。單一的開發模式難以應付多種需求。
- 缺少完善的監控系統，無法在對業務產生影響之前發現並修復問題。
新架構
技術選型
儲存引擎
| 方案 | 優勢 | 劣勢 |
|---|---|---|
| MySQL | 1. 具有完備的事務功能，可以對資料進行更新。2. 支援 SQL，開發成本低。 | 1. 橫向擴充套件成本大，儲存容易成為瓶頸； 2. 實時資料的更新和查詢頻率都很高，線上單個實時應用請求就有 1000+ QPS；使用 MySQL 成本太高。 |
| Elasticsearch | 1. 吞吐量大，單個機器可以支援 2500+ QPS，並且叢集可以快速橫向擴充套件。2. Term 查詢時響應速度很快，單個機器在 2000+ QPS時，查詢延遲在 20 ms以內。 | 1. 沒有原生的 SQL 支援，查詢 DSL 有一定的學習門檻；2. 進行聚合運算時效能下降明顯。 |
| Druid | 1. 支援超大資料量，通過 Kafka 獲取實時資料時，單個作業可支援 6W+ QPS；2. 可以在資料匯入時通過預計算對資料進行彙總，減少的資料儲存。提高了實際處理資料的效率；3. 有很多開源 OLAP 分析框架。實現如 Superset。 | 1. 預聚合導致無法支援明細的查詢；2. 無法支援 Join 操作；3. Append-only 不支援資料的修改。只能以 Segment 為單位進行替換。 |
| Cellar | 1. 支援超大資料量，採用記憶體加分散式儲存的架構，儲存價效比很高；2. 吞吐效能好，經測試處理 3W+ QPS 讀寫請求時，平均延遲在 1ms左右；通過非同步讀寫線上最高支援 10W+ QPS。 | 1. 介面僅支援 KV，Map，List 以及原子加減等；2. 單個 Key 值不得超過 1KB ，而 Value 的值超過 100KB 時則效能下降明顯。 |
實時計算引擎
| 專案/引擎 | Storm | Flink | spark-streaming |
|---|---|---|---|
| API | 靈活的底層 API 和具有事務保證的 Trident API | 流 API 和更加適合資料開發的 Table API 和 Flink SQL 支援 | 流 API 和 Structured-Streaming API 同時也可以使用更適合資料開發的 Spark SQL |
| 容錯機制 | ACK 機制 | State 分散式快照儲存點 | RDD 儲存點 |
| 狀態管理 | Trident State狀態管理 | Key State 和 Operator State兩種 State 可以使用，支援多種持久化方案 | 有 UpdateStateByKey 等 API 進行帶狀態的變更，支援多種持久化方案 |
| 處理模式 | 單條流式處理 | 單條流式處理 | Mic batch處理 |
| 延遲 | 毫秒級 | 毫秒級 | 秒級 |
| 語義保障 | At Least Once，Exactly Once | Exactly Once，At Least Once | At Least Once |
實時資料產品實踐——美團大交通戰場沙盤
source: tech.meituan.com/2018/05/24/…
關鍵詞
Storm，實時資料
問題
- 實時倉庫建設不足，維度及指標不夠豐富，無法快速滿足不同業務需求。
- 實時資料和離線資料對比不靈活，無法自動化新增對比基期資料，且對比資料無法預先生產。
- 資料監控不及時，一旦資料出現問題而無法及時監控到，就會影響業務分析決策。
建設中的挑戰
- 如何在保證資料準確性的前提下實現多實時流關聯；實時流出現延遲、亂序、重複時如何解決。
- 流式計算中通常需要將多個實時流按某些主鍵進行關聯得到特定的實時資料，但不同於離線資料表關聯，實時流的到達是一個增量的過程，無法獲取實時流的全量資料，並且實時流的達到次序無法確定，因此在進行關聯時需要考慮儲存一些中間狀態及下發策略問題。
- 實時流可複用性，實時流的處理不能只為解決一個問題，而是一類甚至幾類問題，需要從業務角度對資料進行抽象，分層建設，以快速滿足不同場景下對資料的要求。
- 中臺服務如何保證查詢效能、資料預警及資料安全。
- 實時資料指標維度較為豐富，多維度聚合查詢場景對服務層的效能要求較高，需要服務層能夠支援較快的計算能力和響應能力；同時資料出現問題後，需要做好及時監控並快速修復。
- 如何保證產品應用需求個性化。
- 實時資料與離線資料對比不靈活，需要提供可配置方案，並能夠及時生產離線資料。
總體解決方案
資料架構
實時處理流程
中臺服務-效能相應優化
中臺服務-資料降級方案
美團點評運營資料產品化應用與實踐
source: tech.meituan.com/2018/02/11/…
問題
- 取數門檻高，找不到切合的資料，口徑複雜不易計算，對運營人員有一定的技能要求，人力成本增大；
- 資料處理非常耗時，缺少底層離線數倉模型建設和預計算*支撐，Ad-hoc平臺查詢緩慢；
- 資料不一致，不同渠道口徑不一致，缺少對雜亂指標的統一管理；
- 資料反饋形式不友好，缺少資料視覺化的形式，無法呈現趨勢，繼而影響業務人員對多維、降維、對比等情況的進一步分析操作。
方案及整體架構
首先，構建了一個針對境內旅遊運營側全域的公共底層資料，將不同平臺促銷系統的資料按業務整合到一起，同時劃分不同活動主題，按事件再向上聚合，做專題的資料支撐，統一資料出口。然後通過多維預計算引擎對事實資料進行預計算，構建數倉與應用的管道，從而節省計算成本，並且提升了資料互通和消費的效率，最後建設統一的資料服務中臺，搭配不同端的Web應用。通過豐富的視覺化效果，及多樣的分析對比操作，快速、全面地支撐運營業務。
數倉架構
多維預計算層
預計算層是連線資料和應用之間的管道，是應用層垂直模組的專項支援。它是在Fact層資料之上的預聚合，強依賴於數倉模型中事實和維度的構建以及預關聯。預計算採用Kylin引擎構建Cube聚合組，來解決取數門檻和資料處理耗時等問題，同是提供多維分析的能力，不但提供了新的Ad-Hoc(Query Engine)平臺，在提高查詢響應的同時，又能為產品帶來更流暢的互動，增強使用者體驗。例如：建立一個交易資料cube，它包含日期（datakey）、使用者（userid）、付款方式（paytype）、購買城市（city）。為滿足不同消費方式在不同城市的應用情況和檢視使用者在不同城市的消費行為，建立以下兩個聚合組，包含的維度和方式如圖所示：
中臺服務層
資料視覺化
基於echarts做開發，完成趨勢對比，降維操作，指標對比，多維查詢等。
美團點評基於Storm的實時資料處理實踐
source: tech.meituan.com/2018/01/26/…
問題
- 資料量的不穩定性，導致對機器需求的不確定性。使用者的行為資料會受到時間的影響，比如半夜時刻和用餐高峰時段每分鐘產生的資料量有兩個數量級的差異。
- 上游資料質量的不確定性。
- 資料計算時，資料的落地點應該放到哪裡來保證計算的高效性。
- 如何保證資料在多執行緒處理時資料計算的正確性。
- 計算好的資料以什麼樣的方式提供給應用方。
設計框架
還是比較了Storm,Flink和Spark Streaming，最終選擇了Storm
