数据湖与实时数仓应用实践( 四 ) _数据湖

文章插图
分布式数据湖中的核心理念是 Fabric，它能够实现统一的数据视图，而这是通过统一的元数据服务来实现的。这个元数据服务不仅可以管理数据湖内的数据，还可以管理企业内其他各种数据存储的元数据。此外，权限管控也非常重要，因为如果源数据管理没有权限控制，数据的安全性就无法得到保障。

文章插图
在 FastData 团队中负责构建近实时的数仓，是我们的一个重要工作。我们采用了 Apache 的 Iceberg 来做底层的表格式存储。从数据源到 ODS 层，我们使用 Flink CDC 技术将数据源拉进来，之后从 ODS 层到下面的 DWD 层或 DWS 层，需要让数据快速地流动起来。为了实现这个目标，我们需要Iceberg这一层支持 CDC 技术，也就是说通过使用Flink这种流式读取 Iceberg 的 Connector，可以快速地感知上游 Iceberg 表的数据变化和schema变化，并将这些变化及时地同步给下一层。这样，数据和 DML 就可以不需要人工操作便自动地流动起来。除了 Append 数据之外，还有 delete 数据和 update 数据，这些数据都需要通过整个链路不停地往下游流动，以便产生的指标能够跟着业务数据的变化而变化。我们已经做到了这一点，但是 Iceberg 的 changlog 产生是依赖于上游表的 commit 操作。commit 的频率越高，时效性越好，但是会产生更多的杂乱无章的文件，对后台的自动化运维提出了较高的要求。commit 的时间越长，拉的时间越长，对文件是更好，但是时效性就差了一些。因此，我们需要根据业务的实际时效要求做出合理的配置。

文章插图
自动化表运维方面，因为数据湖与传统的 Hive 表格有所不同，数据湖支持行级别和列级别的更新，因此会产生各种各样的删除文件和小文件。同时，数据湖也支持实时写入，这会导致更多的小文件和删除文件。如果不及时整理这些文件，直接查询的效果将非常差。为了解决这个问题，我们使用了异步合并和读时合并 MOR 等技术来提高性能。在后台，我们必须确保这些工作得到良好的处理。
在 FastData 内部，我们致力于让用户完全无需关心这些工作。就像使用传统的 Hive 表格一样，用户只需要专注于他们的数据业务，写入和读取数据即可。后续的维护工作由系统自动完成，用户无需进行操作。

文章插图
物化视图是一种常见的空间换时间的策略，通常在 MPP 中也会使用，例如 StarRocks 也使用了这种策略。物化视图的一个特点是对于那些查询相对固定的query，查询加速的效果比较好，因为它的命中率较高。
在 Fastdata 内部，我们基于 Trino 实现了物化视图。然而，社区版的物化视图基本上无法使用。首先，它的刷新需要手动刷新数据，全量刷新是不可行的。例如，如果我的基表有上亿条数据，如果我做了一个聚合查询生成一个物化视图，如果要全量刷新，代价太大了。因此，我们在这个基础上做了一些优化工作。例如，我们现在可以自动刷新，第二刷新可以做增量刷新。增量刷新意味着，当基表发生任何变更时，例如添加了一行或删除了某一行数据，这种变更很快就能体现在物化视图中。在后台，我们通过使用 Iceberg 的CDC 技术来实现实时监控基表的变化。一旦感知到变化，就会触发增量计算。我们使用Flink 来进行增量计算，然后将结果同步到物化视图中。
三、FastData 实时智能湖仓平台实践案例

文章插图
FastData 已经在多个行业中积累了一些客户案例。尤其在能源和商品流通领域，特别是新零售方面，得到了广泛应用，并取得了一定的成果。

文章插图
在能源领域，我们的平台主要解决两个核心问题。首先，利用 Hadoop 技术来处理各个油田的数据。由于油田分布广泛，每个油田都有自己的数据管理系统，因此我们的平台能够将这些数据整合起来，并提供更快速的数据采集速度，从T+1天级别提升到分钟级别。
其次，我们通过建立分布式数据湖（Lakehouse）来解决数据管理的问题。以前，各个油田的数据是相互独立的，没有统一的管理方式。现在我们的平台允许各个油田建立自己的数据湖，并将数据注册到总部。这样，总部就可以随时进行数据分析，了解各个油田当天的生产经营情况。同时，数据仍然保留在各个油田的本地存储中，实现了数据的集中管理和分散存储，解决了这两个核心痛点问题。