哈希游戏- 哈希游戏平台- 哈希游戏官方网站例如，这是一份记录双十一当天用户的访问记录，如果想要将其数据全量同步到结果表中，全量计算需要在次日凌晨启动作业，读取整个表的数据并写入结果表。而增量计算会将任务拆解为更小的处理单元，例如每五分钟处理前五分钟新增的数据，每次执行的结果与已有结果数据合并，最终会生成和全量计算一致的结果。因此，全量计算与增量计算的主要区别在于，对于一个计算目标，处理方式是一次性的还是多次的，处理的是全量数据还是增量数据。

　　Flink 的流计算其实也是一种增量计算，不过它的目标是实时的、亚秒级的数据时效性。为此它会通过逐条记录（Per Record）的方式处理数据，并且会运行一个长期作业来连续消费新增数据。这种执行模式下，流计算需要解决一些额外的问题，例如各条记录间的关联关系，包括内部聚合和外部 Join，Flink 为此引入了状态管理机制。同时，为确保长期运行的作业在故障重启后的数据正确性，Flink 引入了 Checkpoint 机制。总的来说，为了支持流计算正常运行，需要引入一些额外的机制和开销。

　　对于批计算来说，当时效性需求较低时，例如在天级别的场景下，其成本相对较低。然而，随着时效性需求的提高，成本会急剧上升。这是因为如果对批作业有较高的新鲜度要求，可能需要进行重复计算。例如，如果按天进行分区，但需要小时级的新鲜度，那么在第一个小时需要计算 0 点到 1 点的数据，第二个小时需要计算 0 点到 2 点的数据，以此类推，直到计算 0 点到 24 点的数据。大量的数据重复计算会导致成本升高。另一种提高批计算结果时效性的方式，是将批处理的数据划分为更细的数据分区。这样，每次处理一个分区，比如五分钟的数据分区，是否就能实现五分钟的新鲜度呢？这种方式存在一定的限制，比如不能进行跨越多个分区的数据关联，否则无法达到分区粒度的新鲜度。此外，将数据分区切得过细，也会导致迟到数据更容易错过对应分区的计算，从而影响最终结果的准确性。

　　增量计算的另一个优势在于它能够灵活支持时效性的变更。比如，原先设置为五分钟执行一次，可以灵活的修改为十分钟或半小时，甚至再改回三分钟，这通常只需调整调度间隔即可。而流计算和批计算之间的时效性切换就会比较麻烦。例如，从流计算转为批计算时，需要重复处理最新的数据分区，以确保没有数据丢失。而从批计算转为流计算时，需要重建流作业的状态，这可能需要等待几分钟甚至几十分钟，直到流状态重建完成，才能继续处理数据。

　　增量计算相较于批计算的优势在于它能够提供更高的时效性。增量计算面向的是增量数据，因此随着时效性的提高，需要处理的数据量也相应减少，时效性可以得到保障，成本也不会急剧上升。增量计算的第二个优势在于可以将计算分散到平时进行，而不像传统批计算常在零点或其他高峰期集中进行，导致大量作业同时竞争资源，给高优作业带来破线的风险。而增量计算通过将计算任务分散到全天，可以提前发现潜在风险，并降低风险出现的概率。此外，增量计算还可以支持低成本的回刷订正。例如，当发现少量数据存在错误并进行修正时，增量计算可能仅需处理这些被修正的数据，并将更新结果重新合并到最终结果表中，以形成正确的数据集。相比之下，全量批处理需要对整个分区的数据进行全量的覆写订正。

　　相较于流计算，增量计算能够以较低成本支持近实时数据产出。首先，它不需要长期占用资源。增量计算的资源可以按需分配，仅在执行时使用，任务完成后即可释放。其次，增量计算面向已知数据，在执行时数据已到达，因此可以了解数据的特性并进行查询优化。而流计算是作业先行运行，数据随后到达，因此难以根据数据特征进行针对性的优化。增量计算的第三个优势在于，它具备批量处理的执行性能优势，包括更高的 IO 效率，会产生更少的回撤，能更好地支持向量化计算。最后，增量批计算无需像流计算一样构建内置状态，对于双流 Join 这种重状态的场景，可以很大程度的节省计算和存储的开销。通过这些方面的差异，增量计算在近实时场景下，相比流计算能够达成更低的成本。

　　接下来谈谈为什么选择使用 Flink 来实现增量计算。首先，我们有了一个典型的需求场景：Flink Materialized Table。它希望能够提供一种类似数据库 Materialized View 的，简单且一体化的数据运维方式。用户只需编写一个 SQL 查询，无需担心底层是使用流计算还是其他方式，也无需自己构建复杂的 Workflow，Flink 就能够自动生成一个结果表，并自动刷新以满足声明的数据新鲜度。

　　此外，由于增量执行计划是动态生成的，甚至与每次消费的数据有关，因此每次生成的计划可能不同。这使得用户很难直接在 SQL 上通过一些 Hint 进行有效优化。因此，它会更加依赖于 Flink 的自适应优化能力进行优化。这包括自动负载均衡能力，有效缓解非单 Key 热点问题，避免数据倾斜导致的长尾问题。此外，还有对 Skewed Join 的自动优化，能够解决 Join 算子的数据倾斜问题。另外，Flink 还支持了自适应的Broadcast Join。通常来说，Broadcast Join 的处理性能优于Hash Join和 Sort Merge Join。在增量计算场景下，由于增量数据相对较少，很多时候能满足 Broadcast Join 的适用条件，从而带来更好的执行性能。

　　需要特别指出的是，目前我们使用Apache Paimon作为 Source 和 Sink 的存储。这是因为 Paimon 具备增量计算必须的能力。一方面，在读取数据时，它既支持增量数据读取，也支持 Time Travel 功能，即能够获取某个具体时间点的全量数据。另一方面，在写入数据时，Paimon 既提供了性能更优的 Append 表，在一些纯新增的场景下，可以获得更好的写入性能；Paimon 也支持可更新的主键表，能够支持更复杂的合并操作，从而支持一些更复杂的增量处理场景。

　　在生成增量执行计划时，我们希望能够复用上述两个优化步骤。因此，在生成 Logical RelNode Tree 之后插入了一步，尝试以它为基础来生成一个 Incremental Logical RelNode Tree。在这个过程中，最关键的是需要生成一个增量的结果。如图所示，原始的查询拓扑会生成一个结果集 R，增量执行计划则需要生成一个 delta R。为此，需要从结果集 R 开始，进行一个类似递归的向前查找和改写的过程。具体来说，delta R 会依赖于 Sink 去消费一个 IR1 的增量数据，而 IR1 的增量又依赖于 Filter 去消费另一个 IR2 的增量数据，如此递归下推，直到 Source。通过这种方式就完成了整个执行计划的改写。

　　当然，前面的例子相对简单，看起来可能只是做了一个简单的算子替换，但实际上并非如此。事实上，我们需要的并不是仅仅做算子替换，而是基于原有的关系图来仿照和组合出一个整体的增量计划。现在来看一个复杂一点的例子，这是一个关于 Inner Join 的场景，即 A 和 B 进行 Join 操作，然后将全量结果写入结果表中。为了进行增量计算，首要目标是生成一个 delta R。而这个 delta R 会依赖于增量的 Sink 来产生输出。

　　改造方法参照了图中下方的关系代数：对于 A 和 B 进行 Join 后的结果的增量，可以将其表达为两个 Join 结果的 Union，分别是 A 的增量与 B 在上一时间点的全量数据进行 Inner Join 的结果，以及 A 在最新时间点的全量数据与 B 的增量进行 Inner Join 的结果。delta Inner Join 会依赖于四种不同的输入，分别是 A 数据的增量、B 数据在上一时间点的全量数据、A 数据在最新时间点的全量数据，以及 B 数据的增量。

　　Runtime Filter 是 Flink 1.18 中引入的一项优化能力，专门面向 Join 操作。当 Join 操作的一端输入较小时，Runtime Filter 可以根据该输入包含的所有 Join Key 来构建一个过滤器，并将这个过滤器推送到 Join 的另一端。在 Join 的另一端，这个过滤器可以提前过滤掉不需要的数据，从而大大减少 Join 操作需要消费和处理的数据量，提高执行效率。

　　进一步来说，过滤器可以继续下推，越靠近 Source，就能越早地过滤掉不需要的数据。甚至可以将过滤器下推到 Source 内部，使得 Source 从一开始就能判断哪些文件可能是不需要读取的，从而避免先将它们的数据扫描进来再进行过滤。这样一来，就可以将最终读取的数据量控制在增量的量级。当然，这是比较理想的情况。最终的过滤效果还会依赖于另一侧大表的数据是否基于 Join Key 进行了良好的Clustering。

　　首先，Flink 它会在作业执行之前确定每个 Source 要处理到的执行位点。这是为了确保在处理过程中，不会出现由于全量数据和增量数据各自确定执行位点而导致的数据不一致问题。在作业执行成功并完成时，Flink 会把这些执行位点持久化记录下来。与流处理的 Checkpoint 相比，由于记录是一次性的，并且不需要进行 Barrier 对齐，因此处理会更加轻量。最后，这些执行位点会在下一次增量计算的 Planning 阶段被加载和利用，用于在作业执行前确定这一次要处理的数据范围。

　　第三个配置则是关于作业执行时需要处理的数据范围，这包括一个起始时间节点和一个结束时间节点。这里的配置分别是 Auto 和 Latest 。其中，Auto 指的是如果在 Checkpoint 中能够找到之前的执行位点，系统就会自动使用该位点作为起始位点；如果找不到，则会从最早的数据开始处理。而 Latest 则是指使用生成执行计划的时间节点，作为这一次处理的终止位点。通过这种配置方式，可以比较简单地实现以下目标：在每一次增量调度时，无需再修改配置，系统就能从上一次的位点处理到当前最新的数据，从而实现无缝的增量数据衔接。

　　但在观察这个执行计划时，发现它实际上是一个全量的执行计划。这是因为在初次执行时，没有任何位点信息记录，所以无论是全量还是增量计算，都需要对所有数据进行处理，因此处理的数据量是一样的。然而，在大多数情况下，全量执行计划的效率会更高一些。因此，在这种情况下会采用全量计算。不过与普通的全量执行不同的是，这个全量作业的执行还需要进行 Source 位点确定以及 Checkpoint 记录等工作，来支持后续的增量计算。

　　本文整理自京东物流高级数据开发工程师梁宝彬在Flink Forward Asia 2024的分享，聚焦实时湖仓的探索与建设、应用实践、问题思考及未来展望。内容涵盖京东物流通过Flink和Paimon等技术构建实时湖仓体系的过程，解决复杂业务场景下的数据分析挑战，如多维OLAP分析、大屏监控等。同时，文章详细介绍了基于StarRocks的湖仓一体方案，优化存储成本并提升查询效率，以及存算分离的应用实践。最后，对未来数据服务的发展方向进行了展望，计划推广长周期数据存储服务和原生数据湖建设，进一步提升数据分析能力。

　　本文基于哔哩哔哩资深开发工程师丁国涛在Flink Forward Asia 2024云原生专场的分享，围绕Flink On K8S的实践展开。内容涵盖五个部分：背景介绍、功能及稳定性优化、性能优化、运维优化和未来展望。文章详细分析了从YARN迁移到K8S的优势与挑战，包括资源池统一、环境一致性改进及隔离性提升，并针对镜像优化、Pod异常处理、启动速度优化等问题提出解决方案。此外，还探讨了多机房容灾、负载均衡及潮汐混部等未来发展方向，为Flink云原生化提供了全面的技术参考。

　　本文整理自抖音集团数据工程师陆魏与流式计算工程冯向宇在Flink Forward Asia 2024的分享，聚焦抖音生活服务业务中的实时数仓技术演变及Paimon湖仓实践。文章分为三部分：背景及现状、Paimon湖仓实践与技术优化。通过引入Paimon，解决了传统实时数仓开发效率低、资源浪费、稳定性差等问题，显著提升了开发运维效率、节省资源并增强了任务稳定性。同时，文中详细探讨了Paimon在维表实践、宽表建设、标签变更检测等场景的应用，并介绍了其核心技术优化与未来规划。

　　本文总结了阿里妈妈数据技术专家陈亮在Flink Forward Asia 2024大会上的分享，围绕广告业务背景、架构设计及湖仓方案演进展开。内容涵盖广告生态运作、实时数仓挑战与优化，以及基于Paimon的湖仓方案优势。通过分层设计与技术优化，实现业务交付周期缩短30%以上，资源开销降低40%，并大幅提升系统稳定性和运营效率。文章还介绍了阿里云实时计算Flink版的免费试用活动，助力企业探索实时计算与湖仓一体化解决方案。

　　本文整理自阿里云高级技术专家胡一博老师在Flink Forward Asia 2024数据集成（二）专场的分享，主要内容包括：1. Hologres介绍：实时数据仓库，支持毫秒级写入和高QPS查询；2. 写入优化：通过改进缓冲队列、连接池和COPY模式提高吞吐量和降低延迟；3. 消费优化：优化离线场景和分区表的消费逻辑，提升性能和资源利用率；4. 未来展望：进一步简化用户操作，支持更多DDL操作及全增量消费。Hologres 3.0全新升级为一体化实时湖仓平台，提供多项新功能并降低使用成本。