Flink SQL 常用调优

Flink SQL JDBC你踩过的坑

title: Flink实时数仓第二篇【数据接入2】 今天说下我在数据接入过程中遇到的一个奇葩的数据一致性的问题，就是在flink删除hbase数据的时候，返回了上一版本的数据，而不是直接删除。 环境 centos7.4 jdk1.8 flink 1.12.1 hbase 1.4.13 hadoop 2.7.4 zookeeper 3.4.10 问题 通过mysql-cdc和hbase-1.4 connector，直接将数据写入hbase，两个sql如下： // create mysql-cdc ta

ttl FOR SYSTEM_TIME AS OF Processing Time Temporal Join lookup join lookup cache Flink查询缓存 lookup.cache.max-rows lookup.cache.ttl

作者：腾讯云流计算 Oceanus 团队流计算 Oceanus 简介流计算 Oceanus 是大数据产品生态体系的实时化分析利器，是基于 Apache Flink 构建的具备一站开发、无缝...

介绍 Hbase Connector 提供了对 Hbase 集群的读写支持。Oceanus 已经提供了内置的flink-connector-hbaseConnector 组件。 使用范围 仅适用于 hbase-1.4.x。 示例 用作数据源（Source） CREATETABLEdim_hbase ( rowkey STRING, cf ROW < school_name STRING >, PRIMARYKEY(rowkey...

通过上述调优策略的实施，我们成功提升了Flink SQL作业的性能。

`execution.checkpointing.externalized-checkpoint-retention`: 外部化检查点的保留策略。- `execution.checkpointing.tolerable-failed-checkpoints`: 允许的连续失败检查点的最大数量。- `execution.checkpointing.max-concurrent-checkpoints`: 并发生成检查点的最大数量。如果设置为`true`，则检查点将在作业的所有任务完成之前生成。

LocalGlobal 优化将原先的 Aggregate 分成 Local + Global 两段聚合，即 MapReduce 中的 Combine + Reduce 处理模式。第一阶段在上游节点本地攒一批数据进行聚合（localAgg），并输出这次微批的增量值（Accumulator）。第二阶段再将收到的 Accumulator 合并（Merge），得到最终的结果（GlobalAgg）。

以上修改后，我们还把checkpoint的间隔时长从10分钟调整为5分钟了，因为现在每分钟从Kafka中消费的数据更多了，如果继续是10分钟的checkpoint间隔时长，则每次做checkpoint时需要写入到HDFS的数据量也会更大，做checkpoint花费的时间也会更久，任务背压的时间也就更长，任务反而不稳定。为了进一步验证我们的想法，我们创建了一个测试任务，消费我们的Kafka，消费的数据直接写入到blackhole连接器中，这样就可以测出Kafka的读取性能而不受其他算子或者网络的影响。

下载改JAR包，把它加到Flink下的lib路径下，然后重启sql-client；上传相关的依赖包，这几个包在网上很容易找到。进入Flink的lib目录。启动 Flink客户端。

使用FlinkSQL读取&写入到JDBC(MySQL)

需要注意的是，BEGIN STATEMENT SET 和 COMMIT 语句是 Flink SQL 的扩展语法，它们可能在某些特定的 Flink 版本或环境中才可用。通过设置适当的检查点间隔，可以在容忍一定故障的同时，控制检查点的频率和资源使用。如果在 BEGIN STATEMENT SET 和 COMMIT 之间的任何一条语句执行失败，整个事务将回滚，即已经执行的语句会被撤销。使用这个语句的好处是可以根据作业的需求和资源情况调整这些属性，以获得最佳的性能和资源利用率。

作者：腾讯云流计算 Oceanus 团队流计算 Oceanus 简介 流计算 Oceanus 是大数据产品生态体系的实时化分析利器，是基于 Apache Flink 构建的具备一站开发、...

<br />从蒙牛与伊利的731事件到现在QQ与360的干架，“同行是冤家”果真不错，根本原因是自身的利益。为自己获取利益是常理，但有一个前提条件就是不损害其他人利益情况下，即使总体资源有限，此多彼少，那得必须凭借自身实力通过正常手段来获取。所谓自私，个人认为自私本身并不是什么贬义，它是天性使然，亚当斯密认为人的所有决策的最终依据就是自私。大到国家政策，小到普通百姓个人行为，无一例外。 需要注意的是，因为自私产生的行为在实际行为中必须要有一定的外在约束力，其中前面提到的凭借自身实力通过正常手段为条件就是约束

作为一种特定领域语言，SQL 的设计初衷是隐藏底层数据处理的复杂性，让用户通过声明式语言来进行数据操作。而Flink SQL 由于其架构的特殊性，在实现层面通常需引入状态后端 配合 checkpoint 来保证计算结果的最终一致性。目前 Flink SQL 生成状态算子的策略由优化器根据配置项 + SQL 语句来推导，想要在处理有状态的大规模数据和性能调优方面游刃有余的话，用户还是需要对 SQL 状态算子生成机制和管理策略有一定了解。

本章着重探讨 Flink SQL 调优。介绍设置空闲状态保留时间的重要性与方法，避免状态爆炸。阐述 MiniBatch 微批处理的原理、开启方式、适用场景及注意事项，其能提升吞吐、减少数据输出量。LocalGlobal 优化则通过两阶段聚合降低热点，需先开启 MiniBatch 且有相关注意点。Split Distinct 针对 COUNT DISTINCT 热点问题提供自动打散功能，也有特定开启要求与限制。多维 DISTINCT 使用 Filter 可减少状态大小和访问，总结了常用调优参数的设置代码。

大数据SQL调优专题——Flink执行原理

本文介绍了Flink SQL作业在生产环境中的部署与监控实践。主要内容包括：1) 高可用集群架构设计，涉及Zookeeper配置、检查点设置和状态后端优化；2) 资源分配策略，涵盖内存管理、并行度和网络缓冲区配置；3) 作业部署方式，包含SQL Client、REST API和编程式提交；4) 监控体系构建，重点说明了吞吐量、状态大小和水位线延迟等关键指标的采集方法；5) 健康检查与告警机制，通过SQL实现自动化监控和异常检测。这些实践方案为Flink SQL作业的稳定运行提供了全面保障。

状态管理不仅影响应用的性能，还关系到系统的稳定性和资源的有效利用。如果状态管理不当，可能会导致性能下降、资源耗尽，甚至系统崩溃。本文为您介绍SQL作业大状态导致反压的调优原理与方法。作为一种特定领域语言，SQL的设计初衷是隐藏底层数据处理的复杂性，可以通过声明式语言来进行数据操作。而Flink SQL由于其架构的特殊性，在实现层面通常需要引入状态后端配合系统检查点（Checkpoint）来保证计算结果的最终一致性。