「数仓」早已经不是原来的「数仓」了

本文想讨论以下几个问题：

1. 在现有的Data Engineering体系下面，数仓到底指什么？
2. OLAP在Data Engineering 中处在什么位置？
3. 为什么会有数据湖？

抛开各种建模的方法论和数仓的实施方案不谈，DW所提供的能力主要有两个：

1. 数据集中统一存储
2. 仓库建模，用数据刻画业务，为分析决策服务

数据来源多样化

分析的主体大部分是行为数据 ，随着移动互联网的普及和发展，数据分析的主体由原有的交易类数据向行为数据转变，也就是说目前所分析的数据大部分是用户行为数据，尤其是当移动设备普及到一定程度之后，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？这更像是一个成本和权衡的问题。可以从两个角度来分析这个问题

1. 从仓库建模和分析的角度来看，大部分互联网/移动互联网公司都是用维度建模，多半会把维度退化掉，最后交付的模型，如果更方便分析，一定是一张张能够串联业务过程且数据粒度相同的宽表。所以DW（DWD，DWS）及其之上层的表适合导入OLAP引擎，当然具体的还要看业务情况，不同业务单元是否要做关联分析。
2. 从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）。数仓的数据不集中，是不便于分析的。如果不得已这样做，就必须有一个联邦查询引擎来弥补，看出来了么？交付业务价值的数仓工程师不了解底层的基础设施是不行的，基础设施提供了怎样的能力，如何利用好底层的能力，如何建模做设计，等等……。同时即便架构已经变得精简了，数据处理环节依赖关系也足够复杂，我只是想算个数儿而已，没办法算个数儿就是这么难。

总结：围绕Hadoop体系做数据建设，已经有成功案例，但也有其历史原因，从个人角度来看，更像是在某个技术风潮下作的决定，随着诸多Hadoop开源项目的退役，以及Cloud 被越来越多的大企业（国有企业，银行，保险）所接受，成本更低，更具业务附加值的产品会逐步走到前面来。不信？看看Snowflake和Databricks，但这一定有很长的路要走，对于更多的OLAP厂商来说，短期内如何跟开源生态融和如何降低迁移成本仍然是要考虑的问题。