本文想讨論以下幾個問題：
- 在現有的Data Engineering體系下面，數倉到底指什麼？
- OLAP在Data Engineering 中處在什麼位置？
- 為什麼會有資料湖？
抛開各種模組化的方法論和數倉的實施方案不談，DW所提供的能力主要有兩個：
- 資料集中統一存儲
- 倉庫模組化，用資料刻畫業務，為分析決策服務
資料來源多樣化
分析的主體大部分是行為資料 ，随着移動網際網路的普及和發展，資料分析的主體由原有的交易類資料向行為資料轉變，也就是說目前所分析的資料大部分是使用者行為資料，尤其是當移動裝置普及到一定程度之後，APP數量下降，大家都在存量市場上競争，對使用者行為習慣的把握變的更加重要，典型的是Growth Hack的一系列工具。基礎設施也與以往有所不同，早年間提到DW大家談論的更多是GP，Vertica 等OLAP資料庫，但現在的DW基礎設施指的是一系列基礎設施跟工程方案的集合，它包括：
- 行為資料采集上報
- Streaming ETL
- DataSync （RDBMS -> Hive）
- 資料治理
- 血緣關系
- 資料品質
- 中繼資料中心，資料地圖
- 名額體系
- 模組化工具，等等
- 模型建設
- Hadoop生态的基礎元件
在目前的Data Engineering體系下，底層基礎設施并非是個資料庫，他主要包括以下幾個元件：分布式檔案系統，批量計算引擎，資源排程。從存儲的角度來說，HDFS是一個Read On Schema的系統，一方面HDFS對一些原始資料的寫入更加友好，缺點也很明顯分析能力不足，是以各種 SQL On Hadoop的計算引擎也就應運而生，但無論如何計算引擎解決的是批量計算如何加速的問題。一份資料多個引擎，資料遷移的成本是極高的，直到今天大多數資料平台的狀況依然是這樣。
好了，現在然我們可以談談OLAP引擎了，OLAP引擎——以多元資料模型為基礎的，為分析型workload而優化的Database，是以OLAP Server本質上就是一個DW。說回我們上文提到的分析能力的不足，OLAP引擎與各種計算引擎（Presto，Hive，Spark SQL，MapReduce）的本質差別就是他有自己的存儲，是個真正意義上的資料庫，是以查詢響應速度比計算引擎普遍要好。在現有Data Engineer體系下面OLAP引擎更像是一個「存儲的加速層」，他彌補的是底層基礎設施上面能力的不足——實時寫入的能力，查詢分析的速度問題。但前面我們提到DW的功能之一就是資料要集中存儲，引入OLAP引擎之後，哪些資料存儲在OLAP哪些資料放在HDFS？這更像是一個成本和權衡的問題。可以從兩個角度來分析這個問題
- 從倉庫模組化和分析的角度來看，大部分網際網路/移動網際網路公司都是用次元模組化，多半會把次元退化掉，最後傳遞的模型，如果更友善分析，一定是一張張能夠串聯業務過程且資料粒度相同的寬表。是以DW（DWD，DWS）及其之上層的表适合導入OLAP引擎，當然具體的還要看業務情況，不同業務單元是否要做關聯分析。
- 從OLAP引擎提供的能力特性來說，MOLAP，ROLAP，HOLAP，各有場景上的側重，拿ClickHouse和Druid舉例來說，他們對Join的支援都是有限的（Druid不支援），而Doris則不然。如果是以星型模型或星座模型為基礎的多事實關聯分析，還想要OLAP引擎之上對接BI産品，并且保證查詢性能。這是很難的。
DataLake 解決了什麼問題
DataLake并不是什麼新概念了，其原本要解決的問題是将半結構化，非結構化的資料統一存儲，但在Hadoop體系下面成長起來的工程師對這件事兒是無感的，為什麼HDFS不是個天生的"湖"麼？什麼資料都可以往裡面塞。是以在Hadoop體系下狹義的DataLake更多的指的是各種Table Format（Hudi，Iceger 等等），這些Table Format底層依賴行列存儲格式，同時依賴HDFS提供的原子操作，讓原本的檔案系統具備了資料庫的能力。同時原有的Lamdba架構也沒有必要維護兩套資料加工鍊路了，讓架構更加精簡。
那麼有了這些能力上的變化，Lake一方面加強了資料的實時性，一方面讓所謂的“實時數倉”不在割裂了。實時數倉也是個非常奇怪的詞彙，想想為什麼？很多企業做所謂的實時數倉隻是把流量數量單獨存儲（Kafka->ClickHouse）。數倉的資料不集中，是不便于分析的。如果不得已這樣做，就必須有一個聯邦查詢引擎來彌補，看出來了麼？傳遞業務價值的數倉工程師不了解底層的基礎設施是不行的，基礎設施提供了怎樣的能力，如何利用好底層的能力，如何模組化做設計，等等……。同時即便架構已經變得精簡了，資料處理環節依賴關系也足夠複雜，我隻是想算個數兒而已，沒辦法算個數兒就是這麼難。
使用者的問題解決的怎麼樣？
到目前為止但凡是上了規模的公司，他們的Bigdata部門一直被以下的問題困擾。
- 技術成本和業務收益的關系很難說清楚，需要一種可持續控制TOC（Total Ownership Cost）的方法
- 傳遞資料的能力一直很差
哪些業務的收益是資料能力的提升導緻的？一旦上了規模資料部門的工程師做到不拖後腿如實産出，就很不錯了，除此之外根本談不上什麼業務價值。業務增長導緻存儲計算成本增加，資料能力提升又促進業務朝更好的方向發展，這本應該是個良性的過程。目前資料被用起來仍然很難。
總結：圍繞Hadoop體系做資料建設，已經有成功案例，但也有其曆史原因，從個人角度來看，更像是在某個技術風潮下作的決定，随着諸多Hadoop開源項目的退役，以及Cloud 被越來越多的大企業（國有企業，銀行，保險）所接受，成本更低，更具業務附加值的産品會逐漸走到前面來。不信？看看Snowflake和Databricks，但這一定有很長的路要走，對于更多的OLAP廠商來說，短期内如何跟開源生态融和如何降低遷移成本仍然是要考慮的問題。
作者:Zhen Pang
出處:https://zhuanlan.zhihu.com/p/379978263