本文介绍了如何在传媒场景下，通过Arctic与Spark结合，实现离线空闲算力的复用，降低实时计算资源开支。通过Hive+Spark方案，实现了传统离线数仓生产链路的调度，并通过Arctic的表水位感知确保数据就绪。此方案减少了Flink实时计算任务的维护成本，提升了任务稳定性，并在多个BU中得到应用，开源后受到社区关注。
针对提供下游数据报表展示的场景，一般需要走预计算的流程将结果持久化下来，对数据就绪和计算耗时的敏感度都较高，而且查询逻辑相对复杂，Trino/Impala 集群规模相对较小，执行容易失败，导致稳定性欠佳。这个场景下我们使用了集群部署规模最大的 Spark 引擎来处理，在不引入新的资源成本的情况下，做到了离线计算资源的复用。
数据就绪方面，通过 Arctic 表水位感知方案，可以做到较低的分钟级就绪延迟。
计算方面，Arctic 对 Spark Connector 提供了一些读取优化，用户可以通过配置 Arctic 表的 read.split.planning-parallelism 和 read.split.planning-parallelism-factor 这两个参数值，来调整 Arctic Combine Task 的数量，进而控制计算任务的并发度。由于 Spark 离线计算的资源相对灵活和充足，我们可以通过上述调整并发度的方式来保证在 2~3 分钟内完成业务的计算需求。
（3）Hive + Spark 满足传统离线数仓生产链路的调度
Arctic 支持将 Hive 表作为 Basestore，Full Optimize 时会将文件写入到 Hive 数据目录下，以达到更新 Hive 原生读取内容的目的，通过存储架构上的流批一体来降低成本。因此传统的离线数仓生产链路，可以直接使用对应的 Hive 表来作为离线数仓链路的一部分，时效性上相较于 Arctic 表虽缺少了 MOR，但通过 Hiv
最低0.47元/天 解锁文章
576
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
