今天聊聊数据湖和“三剑客”，吐槽一下数据湖被夸大的增量功能_数据湖三剑客

开篇我先说一下我的观点：数仓实现不了的增量数据湖也实现不了，数据湖能实现的增量数仓也可以实现。

在谈数据湖之前，我们先问问chatGPT到底什么是数据湖。

从数据湖的定义上看，可以说数据湖的第1条和第2条只是抄袭了一遍“大数据”的定义。当年大数据技术兴起的时候，我们也是这样定位大数据平台和大数据数仓的。结构化数据和非结构化数据都要存起来，从中挖掘重要价值。然而十多年的发展经历告诉我们，非结构化数据几乎可以等同于垃圾堆，与其去垃圾堆里面找黄金，不如将垃圾先分类（将结构化数据归纳整理成半结构化或者结构化数据），然后再去从中找有价值的东西。所以再炒作一次半结构化数据和非结构化数据，意义不太大。第3条主要是讲数据湖不需要预先定义模式，其实这个也比较扯，等于从Hive数仓回退到Hadoop MR开发时代。没有模式的数据毫无疑问就是垃圾，不可能挖掘出有价值的东西。如果不需要模式，数据资产就不会这么火。第4条弹性计算主要是说对象存储和存算分离，这个主要解决了存储的扩张性，缓解数据仓库时代ODS占用过多存储、数据价值又不高的问题，这点我还是支持的。第5点，提供灵活的数据访问，这个主要是可以同时对接Spark引擎和Presto引擎，这点Hive数仓也可以满足，并无新意。

根据我个人的理解，数据湖诞生的根源在于数据仓库的ODS占用了太多存储（一般来说，超过50%），但是数据价值密度比较低，而HDFS又强制3副本存储数据，导致历史数据既不能删除，又浪费存储空间。这个时候，以S3为代表的对象存储就很有价值了。至于半结构化和结构化的数据，如果是视频或者图片，那么对象存储确实更友好了（对象存储对小文件支持更好）；如果是日志数据，那保存到HDFS也比较麻烦，所以希望可以增量写入数据湖。但是，这些其实都是低价值密度的数据，真没有太多分析的必要性。也正是因为人无法分析这些数据，所以就需要交给AI了。

接下来，我还是结合业界的技术实践来聊聊数据湖技术。首先有请ChatGPT给我们介绍一下数据湖“三剑客”。（我直接问数据湖三剑客，他居然回答是“数据存储、数据处理和数据查询”。）

这里说到了数据仓库的一个痛点，增量数据更新问题。这也是数据湖一直宣称的亮点，也确实是数据仓库的痛点。但是，真是的情况是，数据湖也只能做到ODS层的增量或者最多DWD层的增量，有更复杂逻辑的情况下，数据湖也是无能为力的。因为在两个以上表的关联中，我们是很难准确区分增量数据的。所以截至目前，数据湖也只是做到了ODS层到DWD层的增量加工，再往上或者更多层次的加工也无能为力。而实际情况是，只要我们在接口数据上定义了数据更新时间，或者通过CDC日志同步数据库变更日志，我们在数据仓库里面一样可以实现增量。

这里展开说一下，为什么两个以上表的关联，无法实现准确实现增量逻辑。以零售业务为例，假设有订单信息表A、订单商品表B，我们在ODS层可以分别取到两个表的增量数据，如果要得到DWD层的增量，需要用同时读取订单信息表和订单商品表中变动的订单并进行关联，可以是A表的增量数据关联B表的增量union all历史全量 + B表的增量数据关联A表的增量union all历史全量，这样可以计算出DWD层的增量。但是在我们加入了店铺信息表C以后，这个变更数据就变得更复杂了。2个union all的查询变成了3个union all（A增*B全*C全+A全*B增*C全+A全*B全*C增）相加再去重，代码变得非常冗余，而且第三个关联存在数据倾斜。而实际的业务场景还会加入商品信息表D。经过这样一番操作，增量计算的数据量可能远超全量计算，代码的复杂程度也大大提升。【这个案例也可以应用到FlinkSQL上，同理，FlinkSQL永远无法做到100%的准确性和维度一致性】。

当然，这种情况也不是无解的。在Hive为基础的年代，为了提升查询性能，只能开发大宽表（这就是传说中的“以空间换时间”）。近几年引入了ClickHouse，大幅提升了查询性能，但是多表关联依然无法满足时效要求。但是Doris雄起了，我们的数据仓库可以重回星型模型，我们在DWD处理订单信息表A和订单商品表B的关联，在DWS完成基于DWD表的指标加工，然后直接交给Doris查询引擎关联店铺维度和商品维度表，这样就可以实现数据的增量加工，同时确保维度数据的一致性。Doris更是提供了Unique Key模型，可以按照主键自动对数据去重，省去了数据去重工作量。

还有一种处理数据增量的方案，就是从业务的角度砍断历史数据。例如成交超过3个月的数据业务上认为是不能再退货的，就强制每次增量更新3个月的数据，这样也可以实现低成本的增量数据处理。当然，这种情况，数仓和数据湖都可以实现。

第二大两点是实时数据和批流一体。事实上，实时ODS只需要数据库能对接Kafka或者FlinkCDC就可以实现，实时DWD通常通过FlinkSQL来简化逻辑实现。在这点上，数据湖能实现的，数据仓库也可以实现。但是“批流一体”就是建立在流数据100%准确的基础上，上文已经说过了，增量数据都无法做到100%准确，流数据就更加不可能了。同样的道理，我们借助Doris强大的多表关联性能，可以在ODS层和DWD层借助Flink实现基本准确的实时数据，在上层借助Doris的关联查询也可以实现一致性维度实时结果。在这种情况下，Doris实时数仓的数据准确性和查询性能都是要高于数据湖“三剑客”的。

第三大亮点是表结构可以修改和支持更新删除。其实这个Hive数仓一样可以做到，只不过稍微费劲一点。刚开始使用Hive的同学会觉得不能更新和删除比较麻烦，但是用久了以后这个就不是问题。我们可以通过insert overwrite的方式变相实现实现更新和删除，所以并不影响数仓的开发。Doris对修改和删除的支持力度还有待加强，这里就不展开了。

最后一点是时间旅行和事务隔离，站在数仓的角度这个功能其实没有太大作用。通常情况下，我们只需要知道最新数据即可，对过去的数据及其变更并不关心。如果有关心过程的，我们也会在业务系统中保留事务变更日志。

这样一圈对比下来，我们可以总结一下数据湖的亮点和功能。

第一大亮点，是借助S3对象存储实现存储空间的无限扩展，解决存储资源紧张问题。这个也是Hive生态需要解决的方案，为什么Hive不能基于对象存储建表，把历史数据迁移到对象存储中呢？很高兴的是Doris2.0已经实现这一功能，冷热数据分离，冷数据自动迁移到对象存储。再次点赞！

第二大亮点是无模式（方便扩展的模式）数据对AI的支持。当前的人工智能已经超越了对结构化数据的统计分析，在大模型场景下，这些非结构化的数据可以给AI提供更丰富的素材。这方面笔者不是太懂，暂且认同。

其它亮点，例如时间旅行、事务隔离、支持删改，这些我觉得对数据仓库来说作用不是太大。

只能说数据湖找出来数据仓库的弱点，但是并没有解决掉这个弱点。所以数据湖只能作为数据仓库的一个锦上添花的功能存在。与其说我们需要引入数据湖，不如说数据仓库平台需要引入对象存储。

根据ChatGPT告诉我的知识，AWS就已经支持了将Hive构建在S3对象存储上了。

另外，小米也分享过冷热分离方案，也是将历史数据备份到对象存储上，既可以保证随时可查询，又能大幅降低存储成本。

好了，今天的分析就到这里了。欢迎大家购买我的新书《Doris实时数仓实战》，里面有关于Doris实时数据处理更详细的解读。最后感谢ChatGPT提供的素材，有了他，吐槽就不会太尬了。