介紹
丟擲問題
有脫機數倉了，做實時數倉，是否能兼顧到以前的指標體系，是不是可以直接替代？
類似於畫像體系是否可以在此基礎上進行構建？
實時數倉是否可以是實時平台的基礎？
架構有沒有明確的定義？
儲存框架
框架優勢
劣勢mysql
事務查詢、儲存的效能瓶頸
elasticsearch
吞吐量大，快速橫向擴充套件，查詢速度快
使用成本相對略高，複雜操作效能較低
druid
超大資料量、通過kafka獲得實時資料；資料匯入預計算
預聚合導致的明細查詢差；無多表操作；不支援單資料的修改
cellar
超大資料量，記憶體+分布式儲存；吞吐效能好
僅支援kv、map、list；kv的值大小限制
計算框架
專案flink
spark streaming
apitable api和flink sql
流api和spark sql
容錯機制
state快照儲存，檢查點
rdd儲存點
狀態管理
鍵控狀態，operator狀態
有updatestatebykey等api
處理模式
單條流式處理
批處理延遲
毫秒級秒級
語義保障
exactly once，at least once
at least once
基本層級處理
資料抽取→ods（kafka）→flink →dwd（kafka） → flink →dws（多維明細寬表）（kafka）→ads（kafka）→ druid/es
dim（mysql/hive/tair）
層級資料&框架
ods實時資料：kafka
dwd事實明細資料：kafka
dws明細多維彙總：kafka
ads應用資料：es、druid、mysql、tair
數倉基石 應用
優勢標籤體系實時化管理
排程任務壓力攤平
資料質量分散保證
實時應用
架構分析
lambda處理框架
冗餘消費優化
場景優化，根據具體業務邏輯以及計算邏輯做好數倉主題劃分以及topic劃分。
排除重複消費，同一批資料做到消費一次，重複利用。
資料安全保證
資料一致性問題，就是實時eos。
上下游對接不同層級kafka，具體操作
資料積壓問題
鏈路監控
框架本身處理的優化實時熱點問題
介紹實施
聚合操作
實時數倉 Lambda架構
在某些場景中，資料的價值隨著時間的推移而逐漸減少。所以在傳統大資料脫機數倉的基礎上，逐漸對資料的實時性提出了更高的要求。其中lambda架構是較早的解決方案，使用流處理和批處理兩種架構進行資料處理。其中流處理部分負責實時資料的處理，但流處理因為資料可靠性並不高，所以需要批處理部分定期進行運算稽查。流...
脫機數倉與實時數倉案例
資料倉儲是乙個面向主題的 subject oriented 整合的 integrate 相對穩定的 non volatile 反映歷史變化 time variant 的資料集合，用於支援管理決策。資料倉儲是伴隨著企業資訊化發展起來的，在企業資訊化的過程中，隨著資訊化工具的公升級和新工具的應用，資料量...
突然火了的實時數倉
去年開始，實時數倉的概念突然火了。也許是傳統的脫機數倉搞了很多年，技術相對成熟了，因此大家都把注意力放到了挑戰性更高的實時上來 也許是隨著存量市場競爭的到來，對於速度的要求越來越快，t 1已經不能滿足資料的獲取要求了，實時的構建需求也就應運而生了。總之，時效性開始大於分析性。文字簡單介紹實時數倉的一...