-
1 # 會說科技
-
2 # 真IT小叮噹
想要知道實時資料倉庫怎麼做，我們首先得知道，為什麼要用實時資料倉庫，也就是說我們得明白公司也好，企業也罷，他們要求我們做實時資料倉庫的價值何在？
目前的資料倉庫大都是T+1離線分析資料，即運營人員今天看昨天的資料報表，當客戶為店鋪或者商品做活動並且想看當前的活動效果就只能等到明天來檢視資料。而阿里每年的雙11，幾分鐘完成上億的交易量，他們更想知道的是雙11這個活動帶來的實際效益，當前最新的訂單量、銷售額等。
實時資料倉庫該怎麼做？
1.隨著大家對資料及時性的要求越來越高，實時計算應景產生。常見的開源實時計算框架有storm、s4、spark等。使用過storm開發過實時需求的小夥伴都知道，storm對於單資料流的處理無論是開發難度或者處理執行效率都相當不錯，即使有好多同樣的任務跑也可以應付。
2.實時通用寬表也常被用在實時需求中，大量的實時需求將在通用層得以計算實現。一般的做法就是ODS----明細表---通用寬表---彙總表---應用層。
3.另外實時資料倉庫相比較離線數倉，實時性要求更高，因此在做實時資料倉庫時應注意縮短資料流，簡化資料層次，將ods和明細表合併等。
4.一定要與客戶溝通好。一定要明確客戶對我們實時資料倉庫的實時性要求級別。客戶能忍受的延遲是分鐘級還是秒級等。
5.資料庫最忌諱資料不一致的情況。實時資料倉庫也不例外，要是打算做實時資料倉庫，一定要保證資料的準確一致性，不能丟資料，也不能出現髒資料的情況，寧可多存一些，也不要漏資料，出現數據丟失的被動局面。
6.實時資料倉庫一定要保證易用性
對於實時資料的增、刪、改，要使得下層使用這個寬表時簡單易用，方便呼叫與查詢，不然實時的意義何在？
-
3 # 種豆大叔
想要做實時資料倉庫，必須得了解數倉的構成以及如何選擇對應的數倉元件。
源資料（data）、資料抽取轉換載入（etl）、聯機查詢分析（olap）是數倉構成的三大內容。下面一一解釋：
DATA源資料，包括各部門各業務庫中的資料或者系統訪問日誌，或者其他形式儲存的外部資料等等。可以使用maxwell或者flume來進行資料採集，具體根據資料來源的儲存形式來決定，比如如果是日誌形式，可以使用flume；如果是mysql儲存可以使用maxwell。
ETL上面所說的資料採集便是ETL中的一個步驟，即"E"（Extract，資料抽取）這個步驟。一般採集的資料會先放進kafka中，然後透過Spark Streaming或者Flink或者Storm等流式資料處理框架進行簡單資料處理（T：Transform）後加載（L：Load）到olap系統中。
Spark Streaming、Flink、Storm對比如下，可根據企業自身情況進行選擇：
OLAP實時數倉使用者使用的地方，一個高效的資料查詢系統是必須的，而且得和ETL工具很般配，下面介紹兩款:
Druid：是一個大資料實時查詢、分析，高容錯，高效能的開源分散式系統。專門為OLAP而構建，支援各種過濾、聚合；快速的互動式查詢，響應在毫秒級別；高可用以及高擴充套件性，可支援億級處理數和TB級資料。
Kudu：是應對快速變化資料的快速分析型資料庫。高CPU利用率，高IO效率，支援資料原地更新。與Impala緊密整合，使用Cloudera Manager輕鬆維護和管理，OLAP工作的快速處理
-
4 # 帆軟軟體
雖然我是做報表和BI的，但是報表和BI的效果要好，資料底層很重要，資料架構也很重要，這就不可避免地會涉及到資料倉庫。
先放幾張圖吧：
想要建立實時資料倉庫，你肯定得知道：
1、啥是資料倉庫
2、和資料庫有什麼區別
3、實時的和傳統的有哪些不同
4、實時數倉的架構是什麼
5、怎麼做
這些問題，其實在上面的圖裡，都抽象地有，哪個問題要解釋清楚，都得花長篇大論說清楚，我以前的文章裡都有寫過，可以去看看。
-
5 # C2P工業雲企業管理
所謂的實時資料倉庫首先要保障倉庫的數字化和資訊化，資訊時代，倉庫管理一定要跟上企業發展要求，用現代化技術管理倉庫，讓倉庫產品資料一目瞭然。
我們先來分析一下企業倉庫需要分析展現的實時資料：企業產品什麼時間入庫？入庫數量是多少？產品質量怎麼檢測並跟進？產品怎麼自動上架？上架以後怎麼實時找到我們所需要的產品？哪些產品需要優先出庫？出庫的規則是什麼······這些問題都需要我們去管理。
我推薦用【C2P工業雲庫存軟體】實時管理倉庫並分析資料。C2P工業雲庫存自動配置三步入庫、三步出庫、自動上架功能，滿足大部分企業需求，模組方便企業對線上倉庫進行現代化管理，透過複式分錄智慧庫存系統追蹤每一庫存流動，實現全面自動補貨，瞭解倉庫情況。C2P工業雲把庫存、生產、質檢三者融為一體，能更好的把控產品質量。工業雲軟體有專門技術人員1對1進行輔導，企業上手即用，徹底解決庫存太亂的難題。如果你也想體驗一下我們的庫存管理，可以直接搜尋C2P工業雲，
或者訪問我們的官網 http://openc2p.cn。
想直接體驗工業雲的功能可以登入 <http://demo.rongbiz.com>
帳號：demo，密碼：demo。
-
6 # 派可資料
3.1.1 Lambda架構
3.1.2 Kappa架構
3.1.3 實時olap變體架構
3.1.4 常見架構對比
ps:lambda架構
開發割裂感：
• 表結構不同
• sql語法不同
資源浪費：
• 重複計算
• 重複儲存
叢集維護：
• 元件不同
• 計算引擎不同
資料一致性
3.2 實時數倉架構
3.2.1 方案一
優點：
￮ 便於資料回溯、重算和資料質量驗證。
缺點：
￮ 透過批處理重算，需要維護兩套程式碼，開發和維護成本高。
￮ 需要兩套計算資源
適用場景：
￮ 超大規模歷史資料計算，且這種場景比較頻繁。
￮ 對資料質量要求極高，需要比對實時和離線的計算結果，甚至利用離線去修正實時的計算結果。
3.2.2 方案二
優點：
￮ 無需維護兩套程式碼，開發迭代速度快。
￮ 資料回溯和重算方便，重算時間根據需求回溯的時間範圍定。
￮ 只需流計算資源，資源佔用小
缺點：
￮ ODS\DWD部分資料“不可見”，原始資料和中間資料不便於查詢（解決方案：可透過重新消費指定時間範圍的資料查詢，或匯入需要的資料到olap引擎）
￮ 依賴業務端反饋問題（解決方案：設計資料質量監控指標，實時監控報警）
適用場景：
ODS\DWD查詢不頻繁等
3.2.3 方案三
相對於方案二：
￮ 增加ODS層落地hive，排查分析原始資料比較方便，恢復歷史資料的時候可獲取hive資料寫入kafka，然後按原流處理的邏輯重新處理即可，只需修改資料來源為歷史資料對應的topic。
￮ 需新增kafka寫入hive邏輯
￮ 需新增從hive讀取資料寫入kafka
￮ 需新增整條鏈路歷史資料對應的topic
回覆列表
資料倉庫是對企業各類資料的彙總和規範化，能夠遮蔽各業務系統之間的差異，提供統一的資料出口。通常情況下，資料倉庫都要包括貼源層、明細層、彙總層和集市層或者貼源層、模型層、集市層等幾個層次，並最終透過介面等方式提供資料給下游應用文系統使用。
其中，貼源層是對源系統資料的直接複製，不做加工處理，往往透過卸數或者資料同步的方式實現，其他層次是基於貼源層資料跑批和逐步彙總抽象得來。
目前，大多還是離線資料倉庫，往往是T+1延遲，即T+1日凌晨解除安裝源系統T日日終的資料，然後跑批，將資料入模型入集市，並最終提供給下游應用系統，可以基於大資料平臺，也可以基於Teradata等傳統資料倉庫來做。
而所謂實時資料倉庫就是能夠提供實時的資料介面，延遲在支撐實時查詢、實時報表等業務場景。要做到實時，一個是保障源系統資料入ODS的實時性，即構建實時ODS，往往透過OGG/CDC等資料同步方案實現，實時監控源系統資料庫變化日誌並實時同步至資料倉庫。二是要確保資料模型和集市的效率，這時候TD等傳統資料倉庫就不太合適了，要在大資料平臺上建模和跑批。
現在完全實時的資料倉庫還是比較困難的，一般還是離線數倉和實時ODS混搭，屬於離線的就按日跑批，需要實時的就實時同步，這樣能夠提升效率，簡化業務模型。