的实时数仓方案可以做到实时报表产生这得益于Iceberg技术： 支持流式写入-增量拉取 流式写入其实现在基于Flink就可以实现无非是将checkpoint间隔设置的短一点比如分钟就意味每分钟生成的文件就可以写入到HDFS这就是流式写入。但是这里有两个问题第一个问题是小文件很多但这不是最关键的第二个问题才是最致命的就是上游每分钟提交了很多文件到HDFS上下游消费的Flink是不知道哪些文件是最新提交的因此下游Flink就不知道应该去消费处理哪些文件。
这个问题才是离线数
仓做不到实时的最关键原因之一离线数仓的 沙特电话号码数据 玩法是说上游将数据全部导入完成了告诉下游说这波数据全部导完了你可以消费处理了这样的话就做不到实时处理。数据湖就解决了这个问题。实时数据链路处理的时候上游Flink写入的文件进来之后下游就可以将数据文件一致性地读走。这里强调一致性地读就是不能多读一个文件也不能少读一个文件。上游这段时间写了多少文件下游就要读走多少文件。我们称这样的读取叫增量拉取。 解决小文件多的问题 数据湖实现了相关合并小文件的接口Spark/Flink上层引擎可以周期性地调用接口进行小文件合并。
支持批量以及流式
的Upsert（Delete）功能 批量Upsert/Delete功能主要用于离线数据修正。流式upsert场景上文介绍了主要是流处理场景下经过窗口时间聚合之后有延迟 芬兰电话号码列表 数据到来的话会有更新的需求。这类需求是需要一个可以支持更新的存储系统的而离线数仓做更新的话需要全量数据覆盖这也是离线数仓做不到实时的关键原因之一数据湖是需要解决掉这个问题的。 支持比较完整的OLAP生态 比如支持Hive/Spark/Presto/Impala等OLAP查询引擎提供高效的多维聚合查询性能。目前Iceberg部分功能还在开发中有一些功能还不完善但是整体实时数仓的发展会大致朝着这个方向行进。
