資料倉儲經過多年的發展，倉庫架構設計也隨之多次調整，框架調整的過程中，
寫入層上，lambda 沒有對資料寫入進行抽象，而是將雙寫流批系統的一致性問題反推給了寫入資料的上層應用；
儲存上，以 hdfs 為代表的master dataset 不支援資料更新，持續更新的資料來源只能以定期拷貝全量 snapshot 到 hdfs 的方式保持資料更新，資料延遲和成本比較大；
計算邏輯需要分別在流批框架中實現和執行，而在類似 storm 的流計算框架和hadoop mr 的批處理框架做 job 開發、除錯、問題調查都是比較複雜的；
結果檢視需要支援低延遲的查詢分析，通常還需要將資料派生到列存分析系統，並保證成本可控。
傳統倉庫的架構設計
管理的公共資料除了資料共享以外，還可以作為資料質量管理的基礎，關於資料質量平台，就是通過一系列的檢查邏輯檢查資料的合理性，完備性，規範性；目前一般關於這部分的檢查都在使用資料倉儲的資源來進行的，比如分配到stg層，pdm層甚至集市層驗證資料質量，這樣導致的後果是比較占用資料倉儲的資源。關於資料質量這塊其實最大的問題還是換行符，特殊字元等等的檢測，乙個比較好的拆分是使用etl伺服器的資源計算資料質量的情況。
stg儲存當天的資料，stgfull儲存當前全量的資料；
stg和stgfull經過整合進入pdm模型，在金融系統一般採用正規化建模，分成幾大主題分類管理。
模型處理後進入公共計算層cds，cds主要做公用的計算，比如指標管理平台可以以cds為基礎，模型提供的是通用的資料整合服務，cds提供更加精細的業務資料計算。
倉庫對外就是各種的應用系統和bi報表之類的平台，關於倉庫對外的介面，需要討論一下，傳統倉庫對外一般通過批量檔案進行交換。但是倉庫的優點是適合計算不適合導數之類的工作，如果倉庫裡面大範圍的導數會很吃資源，需要集中管理起來。
此外還有資料管控平台和元資料管理系統，元資料管理系統可以通過etl採集各個源的元資料再整合倉庫內部的元資料形成統一的元資料管理；
老胡點評：
傳統大資料架構其定位是為了解決傳統bi的問題。這樣做的優點是簡單、易懂，但是缺點也非常的明顯，對業務支撐的靈活度不夠，對於存在大量報表或複雜鑽取的場景，需要太多的手工定製化，同時該架構依舊以批處理為主，缺乏實時的支撐。
流式架構
流處理加工後的資料，部分以訊息的形式直接推送給了消費者。部分儲存供重複使用。
這樣的架構沒有etl過程，資料的實效性非常高。但是由於不存在批處理，因此對於資料的歷史統計無法很好的支撐。對於離線分析僅僅支撐視窗之內的分析。
老胡點評：
純流式的架構比較激進，但是也有適用適用場景，比如預警、監控、對資料有有效期要求的情況等等。
lambda架構
lambda的資料通道分為兩條分支：實時流和離線。實時流依照流式架構，保障了其實時性，而離線則以批處理方式為主，保障了最終一致性。
lambda 架構的實時和批量部分具有相同的計算邏輯，並且在查詢階段合併batch view和real-time view的計算檢視並展示給使用者。
但是批處理相對簡單不易出現錯誤，而流處理相對不太可靠，因此流處理器可以使用近似演算法，快速產生對檢視的近似更新，而批處理系統會採用較慢的精確演算法，產生相同檢視的校正版本。
老胡點評：
為了保證不斷變化的歷史資料和實時資料的查詢需求，lambda 架構使用合併批處理檢視和流處理檢視的方式，很巧妙的滿足了相關需求。
這種方法既有實時又有離線，全面的覆蓋了各個場景，這種方式有乙個缺點就是相同的指令碼要維護兩套，不管開發測試，兩套保持一致。
另外在資料的寫入方面，顯然一邊是增量，一邊是全量，這種可能需要上層應用進行控制；
當需要全量計算時，重新起乙個流計算例項，從頭開始讀取資料進行處理，並輸出到乙個結果儲存中。
當新的例項完成後，停止老的流計算例項，並把老的一引起結果刪除。
針對一些開放的分析需求，具有很好的適用性。
但它依然沒有解決儲存和展示的問題，特別是在儲存上，使用類似 kafka 的訊息佇列儲存長期日誌資料，資料無法壓縮，儲存成本很大。
lambda 直接支援批處理，因此更適合對歷史資料有很多 ad hoc 查詢的需求的場景，比如資料分析師需要按任意條件組合對歷史資料進行探索性的分析，並且有一定的實時性需求，期望盡快得到分析結果，批處理可以更直接高效地滿足這些需求。
典型大資料架構的情況和問題
kafka作為訊息中介軟體，更多的作為實時批量的源，flink或者spark stream 作為實時批量元件。
hbase、cassandra主要提供點查詢能力，比如指標視覺化相關，但是只有點查而缺少分析能力。
為解決資料分析問題，元件druid和clickhouse則提供分析功能。
drill或者presto可以設計為了對實時資料和離線資料做乙個聯邦查詢。
但以上的每個儲存產品都形成了乙個又乙個的資料孤島。
資料倉儲分層架構設計
大資料資料倉儲是基於hive構建的資料倉儲，分布檔案系統為hdfs，資源管理為yarn，計算引擎主要包括mapreduce tez spark等，分層架構如下 1 資料 層 日誌或者關係型資料庫，並通過flume sqoop kettle等etl工具匯入到hdfs，並對映到hive的資料倉儲表中。2...
資料倉儲分層架構設計
這應該是資料倉儲同學在設計資料分層時首先要被挑戰的問題，類似的問題可能會有很多，比如說 為什麼要做資料倉儲？為什麼要做元資料管理？為什麼要做資料質量管理？當然，這裡我們只聊一下為什麼要做設計資料分層。作為一名資料的規劃者，我們肯定希望自己的資料能夠有秩序地流轉，資料的整個生命週期能夠清晰明確被設計者...
資料倉儲 資料倉儲部署
1 首先用下面的語句查詢是否有要建立的表空間 hospdw tab 和 hospdw idx 如果沒有，則把d database zyhip改為對應的路徑，有的話直接建立使用者 select tablespace name,file name,round bytes 1024 1024 0 size...