├── CSDN - Flink K8S Operator 实践 ├── CSDN-20220705.png ├── Flink K8s Operator 解析与实践.md ├── alluxio.png ├── game_flink_prod.png ├── k8s_operator.png └── version.png ├── FFA2023-Flink Operator 云原生的下一站 └── ffa2023-云原生flink的下一站.pdf ├── Flink 1.12 资源管理新特性 ├── Flink 1.12 资源管理新特性.md └── img │ ├── image-20210101145852331.png │ ├── image-20210101152324593.png │ ├── image-20210101152432770.png │ ├── image-20210101152756380.png │ ├── image-20210101152844186.png │ ├── image-20210101153149434.png │ ├── image-20210102194947808.png │ ├── image-20210102210054861.png │ ├── image-20210102212126391.png │ ├── image-20210103000207575.png │ └── image-20210103130321825.png ├── Flink 1.13 SQL 深入解读 ├── Flink1.13.md └── img │ ├── image-20210619113225866.png │ ├── image-20210619135838869.png │ ├── image-20210619135903053.png │ ├── image-20210619141938374.png │ ├── image-20210619163651120.png │ ├── image-20210619172919191.png │ ├── image-20210619173221897.png │ ├── image-20210619173253180.png │ ├── image-20210619175642414.png │ ├── image-20210620115925303.png │ ├── image-20210620181805583.png │ └── image-20210620182022617.png ├── Flink 1.14 前言预览 ├── Flink1.14 前言预览.md └── img │ ├── 1.png │ ├── 10.png │ ├── 11.png │ ├── 12.png │ ├── 13.png │ ├── 14.png │ ├── 2.png │ ├── 3.png │ ├── 4.png │ ├── 5.png │ ├── 6.png │ ├── 7.png │ ├── 8.png │ └── 9.png ├── Flink CDC 2.0 ├── Flink CDC 2.0 详解.md └── img │ ├── Compare-cdc.png │ ├── QQ20210725-103535@2x.png │ ├── binlog-chunk .png │ ├── cdc_1.png │ ├── cdc_2.png │ ├── cdc_3.png │ ├── cdc_4.png │ ├── cdc_4_1.png │ ├── cdc_5.png │ ├── cdc_5_1.png │ ├── cdc_5_2.png │ ├── cdc_6.png │ ├── cdc_etl_sql.png │ ├── chunk_all.png │ ├── chunk_cut.png │ ├── chunk_read.png │ ├── chunk_report.png │ ├── debezium_lock.png │ ├── debezium_to_cdc.png │ ├── fcs_1.png │ ├── fcs_2.png │ ├── snapshot-chunk.png │ ├── unlock_1.png │ └── unlock_2.png ├── Flink CDC In HuoLaLa ├── Apache Flink CDC 在货拉拉实践与应用 （共享）.pptx └── Yu Chen Zheng.jpg ├── Flink Forward Asia 2024 └── Flink CDC与Amoro融合入湖新体验.pptx ├── Flink K8S Operator AutoScaling └── ASF2023-流计算-Flink-K8S-Operator-AutoScaling自动调优.pptx ├── Flink中文开源社区一些感悟 ├── Flink开源中文社区感悟.md └── img │ ├── 1-0.png │ ├── 1-1.png │ ├── 1-2.png │ └── 1-3.png ├── README.md ├── imgs ├── asf_garden.jpg └── flink-china.png ├── 尚硅谷 Flink 1.13 在线配套资源文档 └── 尚硅谷大数据技术之Flink1.13（Java）.pdf └── 论文合集 └── The Dataflow Model- A Practical Approach to Balancing Correctness, Latency, and Cost in Massive-Scale, Unbounded, Out-of-Order Data Processing.pdf /CSDN - Flink K8S Operator 实践/CSDN-20220705.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/czy006/FlinkClub/49bc8dc56e7e26b719c5fa4d1a46a623b6e0e3f8/CSDN - Flink K8S Operator 实践/CSDN-20220705.png -------------------------------------------------------------------------------- /CSDN - Flink K8S Operator 实践/Flink K8s Operator 解析与实践.md: -------------------------------------------------------------------------------- 1 | 2 | # 简介 3 | 陈政羽，Flink中文社区志愿者，Flink K8S Operator Contributor & Flink Web Contributor
目前在真有趣大数据平台开发工程师，从0到1为真有趣构建部署、监控、运维一站式云原生的大数据实时计算平台，今天给大家带来的分享是Flink K8s Operator 相关解析和实践。首先先会简单介绍一下当前社区Operator相关情况和发版节奏以及相关功能；于此同时对比社区版本真有趣在内部构建的Operator功能和特色，以及后续公司需要继续迭代的方向和社区未来的RoadMap。 4 | 5 | # Flink K8s Operator 简介 & 社区情况 6 | Flink Kubernetes Operator 旨在承担管理 Flink 部署的用户职责，用户对 Flink 部署应该如何表现、如何启动集群、如何部署作业、如何升级它们以及在出现问题时如何做出调整必须有着深入的了解。Flink Operator主要目标是使得这些流程自动化，在当前单纯靠 Flink 原生集成是无法实现的。整体流程如下图 7 | 8 | ![image.png](k8s_operator.png)
9 | 10 | ``` 11 | apiVersion: flink.apache.org/v1beta1 12 | kind: FlinkDeployment 13 | metadata: 14 | namespace: default 15 | name: basic-example 16 | spec: 17 | image: flink:1.15 18 | flinkVersion: v1_15 19 | flinkConfiguration: 20 | taskmanager.numberOfTaskSlots: "2" 21 | serviceAccount: flink 22 | jobManager: 23 | resource: 24 | memory: "2048m" 25 | cpu: 1 26 | taskManager: 27 | resource: 28 | memory: "2048m" 29 | cpu: 1 30 | job: 31 | jarURI: local:///opt/flink/examples/streaming/StateMachineExample.jar 32 | parallelism: 2 33 | upgradeMode: stateless 34 | state: running 35 | ``` 36 | 用户通过自定义配置，搭配恢复策略（STATELESS）修改作业参数无需人工干预即可完成作业自动重启恢复部署，极大的简化了用户部署成本。
Flink K8S Operator 作为一个新生的婴儿，在此之前社区已经有其他的Flink Operaotr，其中不乏Google、Lyft等开源的，那么为什么社区还要再做一个呢？社区其实主要从中立性、云原生、用户角度等方面去考虑。从中立性的角度出发，这些第三方Operator项目不在ASF等中立基金或者开源社区下。因此往往缺乏更广泛的社区参与和讨论，如果在维护者离职或者关注重心不在这里时候，就会容易项目会停止更新；从云原生的角度出发，Operator 改变传统的服务器部署模式，用户只需通过Helm的方式一键部署在K8S集群上，通过用户自定义资源和K8S Crd 模式提供给使用方快速部署一个Flink程序的能力；从用户角度而言，用户可以通过Operator进行全生命周期的Flink云原生体验，通过kubectl等k8s工具管理Flink应用程序及其生命周期。用户无需关心部署细节，通过Operator即可实现自动化部署作业，暂停作业，水平扩容等功能。
社区目前保持了较快的发版节奏，平均2个月向前发布一个版本，并且从1.0版本开始保证其功能向后兼容
37 | ![image.png](version.png)
38 | 39 | # Flink K8s Operator 功能介绍 40 | Flink K8s Operator 在6月初发布了里程碑1.0版本，意味着用户可以使用其应用生产，其中1.0包含了以下功能 41 | 42 | - 保存点历史记录和清理：清理基于时间或者Savepoint最大数量进行清理 43 | - 多版本支持：同时支持Flink1.13、1.14、1.15版本 44 | - 作业部署恢复和回滚：作业在发生致命错误时候，可以回滚到上一个正常使用的作业逻辑版本 45 | - Session Cluster 作业管理初步支持：初步支持了SessionCluster Job 定义与部署 46 | 47 | 由以上功能组成了1.0的新版本，当然也还包括各种bug fixed，欢迎各位前去体验。目前Flink K8S Operator整体运作流程是十分简洁的（如下图），用户通过自定义资源定义出Flink作业所需要的资源，然乎通过Operator不断部署调整至用户所期望的部署状态，并且通过RestApi追踪其部署情况，并将内部追踪的信息以事件或者状态的形式暴露给用户进行判断。 48 | 49 | ![image.png](https://nightlies.apache.org/flink/flink-kubernetes-operator-docs-release-1.0/img/concepts/control_loop.svg)
50 | 51 | 目前无论是Application Mode 还是 Session 做的部署，他们的状态扭转都如下流程
52 | 53 | ![image.png](https://nightlies.apache.org/flink/flink-kubernetes-operator-docs-release-1.0/img/concepts/JM_deployment_state_machine.svg)
54 | 55 | 作业部署后，状态会为DEPLOYING，当作业部署上去但是并没有完成部署完成时候状态时DEPLOYED_NOT_READY，当部署错误时候会变为ERROR；当部署完成时候状态会扭转至READY，在READY状态时候会不断通过RESTAPI获取当前作业相关信息，如果作业丢失后状态会扭住为MISSING触发重新部署机制，如果发生错误则扭转至ERROR，用户需要手动处理相关问题。
目前1.0版本已经支持了SessionCluster Job方式部署，可以通过以下方式进行定义 56 | ``` 57 | apiVersion: flink.apache.org/v1beta1 58 | kind: FlinkSessionJob 59 | metadata: 60 | name: basic-session-job-example 61 | spec: 62 | deploymentName: basic-session-cluster 63 | job: 64 | jarURI: https://repo1.maven.org/maven2/org/apache/flink/flink-examples-streaming_2.12/1.15.0/flink-examples-streaming_2.12-1.15.0-TopSpeedWindowing.jar 65 | parallelism: 4 66 | upgradeMode: stateless 67 | ``` 68 | 通过这种方式运行SessionCluster目前还有一定的局限性 69 | 70 | - 当前Session Cluster Job 社区版本不支持 LastState Upgrade Mode 71 | - 每次部署/销毁 Session作业需要销毁集群，这一部分暂无高级抽象 72 | - 利用Flink文件系统机制来下载 jar 并提交到会话集群。因此 FlinkSessionJob 必须与由 FlinkDeployment 管理的现有Session集群一起运行 73 | 74 | 社区目前正在基于 _FLIP-225：Implement standalone mode support in the kubernetes operator_ 进行开发这部分功能，后续会继续完善SessionCluster Job这一部分的抽象。 75 | 76 | # Flink云原生在真有趣的实践 77 | 为什么真有趣需要研发自己的Flink Operator，主要有几下以点公司层面的原因： 78 | 79 | - 社区当时 Operator 项目未立项，以及其他开源的同类竞品都是基于 Go 实现，且版本较老和维护频率低，无法满足实际生产需求 80 | - 公司云原生使用和运维积累经验丰富，目前 K8S 已经在游戏服务端大规模部署和应用，希望这部分能力在大数据领域继续深耕和扩展 81 | - 使用云原生技术节省运维和部署成本（核心需求）。当前社区的Operator 无法满足生产上多版本、自定义资源描述、LAST_STATE作业恢复、作业历史、SessionCluster 集群管理等高级功能需求，故需要自己再次封装 82 | - 社区当前 Operator 没有可视化界面，首次使用Flink SQL和Flink的用户体验和学习成本较高，期望借助平台封装减少其对Flink专业名词的了解 83 | 84 | ## 游戏行业Flink业务场景 85 | 在**游戏行业**中，我们也可以汇总为以下几类数据需求痛点，这也是为什么我们需要Flink的原因 86 | 87 | - 实时数据大屏：统计用户数据大屏展示给决策经营层以及相关决策人员，让其知晓游戏当前生命周期以及运营情况 88 | - 反外挂业务：通过订阅相关用户事件以及环境状态和相关游戏参数，判断用户是否使用非法外挂软件或者恶意手段修改游戏数据。本者用户第一的角度，有效维护玩家游戏体验和创造者，提升用户留存率和游戏体验（公司核心主业务，特别针对 FPS 射击类游戏） 89 | - 数据清洗业务：通过实时接入消息中间件清洗数据，输出至不同的数据源（如Clickhouse、Hive）等大数据查询引擎，提供给数据人员查询数据 90 | - 数据同步业务：通过 Flink CDC 可以接入数据库同步，同步相关玩家数据、玩家日志等信息到数据仓库进行离线或者交互式分析 91 | - AI预测：通过 Alink 释放实时计算 AI 计算，预测游戏行业的买量投放、广告投放等业务 92 | 93 | 在真有趣内部，我们主要使用反外挂业务服务于我们的游戏香肠派对，为游戏营造良好的竞技环境；其次还有部分数据同步管道工作，用于同步游戏数据服务的CDC工具。按照业务领域划分，我们可以产出这样一幅全景游戏行业的业务图（适合使用大部分场景） 94 | ![image.png](game_flink_prod.png)
95 | ## 作业状态恢复功能 96 | 作业状态恢复在真有趣主要有以下这几种场景： 97 | 98 | - 业务需求方期望每日定时保存 SavePoint ，避免作业在意外时候，由于使用较老的状态进行恢复导致业务恢复时间过长和重新消费浪费资源 99 | - 业务方需要经常修改不同的反外挂参数，期望作业重启时候无需人为干预，能过基于恢复策略自动重启恢复作业，并且使用最新的保存点（Savepoint）或者检查点（Checkpoint）进行恢复。 100 | - 希望恢复作业时候无需关注是 Savepoint 还是 Checkpoint 这些概念，屏蔽数据分析师、运营等业务方对于底层专业名词的了解。 101 | 102 | 基于上面的场景，我们设计了三种 **_恢复机制_** 103 | 104 | - LATEST_STATE：基于最后状态的恢复，包含了Savepoint和Checkpoint进行恢复，目前在公司内部版本1.14基于K8S Configmap 实现了平台侧管理Snapshot，1.15正在和社区 _Flink-26930 _推进此issuse实现，所以标注为实验性功能 105 | - LATEST_SAVE_POINT：使用平台侧已知的最后的检查点进行恢复，如果有多个检查点，则按照检查点的实际完成时间进行排序，优先选择最新的检查点 106 | - NONE：使用空状态恢复（针对无状态的应用） 107 | 108 | 通过上面三种策略能够满足我们生产大部分的所需的业务场景。社区目前也有类似的策略名词，其实都是一样的，具体大家可以看看官方文档，这里就不做详细阐述。
备注：_社区目前正在推进 [Flink-26930] Rethink last-state upgrade implementation in flink-kubernetes-operator_ 109 | 110 | ## Session Cluster 状态机 111 | 社区目前正在推进的FLIP-212：Support Session Cluster Job，在真有趣内部，为了能够解放运维部署Flink集群和作业的流程，简化工作，我们研发了基于K8S观察机制的一个状态扭转机，其中主要有2大状态 112 | 113 | - 期状状态：用户所期望的值，状态机将尽最大努力扭转至此状态 114 | - 当前状态：抽象出当前内部运行状态，暴露给用户了解当前运行状况 115 | 116 | 其中期望状态是由用户选择的，用户可以自行选择，当用户改变其期望状态时，内部Operator将尽最大努力扭转到用户期望状态，我们设计了2种集群的期望状态 117 | 118 | - RUNNING：期望当前集群是运行的状态 119 | - CANCEL：期望当前集群停止的状态 120 | 121 | 用户基于这2种状态进行选择，当用户期望为RUNNING状态后，系统将暴露当前状态给用户观测，当前状态反馈了当前系统内部部署集群的一个实际状态，主要有以下几种 122 | 123 | - STARTING：集群正在启动中，检查用户资源定义是否正确，验证Flink版本Git Commit Id，集群资源是否足够等流程，如果此流程不通过直接扭转为 FAIELD 124 | - RUNNING：当前集群正在正常运行，使用Rest API 请求 Overview 以及判断集群JM Pod状态去综合判断出当前状态是否为正常运行 125 | - PENDING_UPDATE：等待升级，用户修改TM数量时候触发。如果资源不足则会一直为此状态，并定时重新读取资源相关配置和检查资源状态，直至成功扭转至 126 | - UPDATING状态 为止UPDATING：由PENDING_UPDATE扭转至此状态，表示集群正在扩容/缩小 TM 数量 127 | - FAIELD：集群部署失败时候触发，例如集群在启动过程中的检查中无法通过、集群运行中出现致命错误等都会扭转至此状态 128 | - CANCEL：当前集群为无部署的卸载状态 129 | 130 | ## 存储方面 131 | 在底层存储方面，我们也做了许多调查和研究，最后我们选择Alluxio作为我们底层的一个数据编排和存储引擎的中间加速层
132 | 133 | ![image.png](alluxio.png)
134 | 135 | 我们主要有以下几点考虑： 136 | 137 | - 业务期望屏蔽底层细节，无需关注底层存储系统是HDFS分布式存储 还是S3、OSS、COS等公有云存储，交由开发人员维护，统一上层文件访问接口 138 | - 存储加速功能，冷热数据分离 139 | - 流量费用节省，避免Checkpoint 频繁读写公用云存储产生较高的请求费和流量费 140 | 141 | #
社区未来 & 公司后续规划 142 | 基于现有平台，我们后续还会围绕着社区和公司内部版本做出强化，吸收社区优秀设计。其中包括以下几点 143 | 144 | - 参与社区贡献：Session Cluster 部署模式已经在公司内部成熟运行，希望基于 FLIP-225 进行扩展和参与到社区贡献 145 | - Application Mode 迁移开发：部分稳定性要求较高的作业后续 Session Cluster 逐步迁移至 Flink Application Mode 模式 146 | - 支持Flink SQL：Flink SQL 作业在 FLINK1.16 开始实验性的支持算子级别恢复，后续将调研此工作 147 | - AutoScaling平台研发：作业自动调优功能（仅限 Application Mode 模式），基于流量和业务特点进行动态伸缩，节省 服务器成本 148 | 149 | 社区后续的RoadMap将会推进以下工作： 150 | 151 | - FLIP-225 ：支持Session Cluster Standalone 作业的部署和管理 152 | - 基于Pod的水平自动伸缩相关工作 153 | - 可插拔的状态管理和事件通知机制 154 | - 改进Savepoint的管理和相关触发逻辑 155 | 156 | 目前社区的工作其实有一部分是和我所做的一些工作是有交互的，后续我们也会进行持续关注和做出贡献。视频回放在Apache Flink 官方公众号以及CSDN同步，欢迎各位前去观看。 157 | -------------------------------------------------------------------------------- /CSDN - Flink K8S Operator 实践/alluxio.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/czy006/FlinkClub/49bc8dc56e7e26b719c5fa4d1a46a623b6e0e3f8/CSDN - Flink K8S Operator 实践/alluxio.png -------------------------------------------------------------------------------- /CSDN - Flink K8S Operator 实践/game_flink_prod.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/czy006/FlinkClub/49bc8dc56e7e26b719c5fa4d1a46a623b6e0e3f8/CSDN - Flink K8S Operator 实践/game_flink_prod.png -------------------------------------------------------------------------------- /CSDN - Flink K8S Operator 实践/k8s_operator.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/czy006/FlinkClub/49bc8dc56e7e26b719c5fa4d1a46a623b6e0e3f8/CSDN - Flink K8S Operator 实践/k8s_operator.png -------------------------------------------------------------------------------- /CSDN - Flink K8S Operator 实践/version.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/czy006/FlinkClub/49bc8dc56e7e26b719c5fa4d1a46a623b6e0e3f8/CSDN - Flink K8S Operator 实践/version.png -------------------------------------------------------------------------------- /FFA2023-Flink Operator 云原生的下一站/ffa2023-云原生flink的下一站.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/czy006/FlinkClub/49bc8dc56e7e26b719c5fa4d1a46a623b6e0e3f8/FFA2023-Flink Operator 云原生的下一站/ffa2023-云原生flink的下一站.pdf -------------------------------------------------------------------------------- /Flink 1.12 资源管理新特性/Flink 1.12 资源管理新特性.md: -------------------------------------------------------------------------------- 1 | 文章介绍：相信大家在平时开发中常常会遇到一些关于作业配置的相关问题，例如如何配置Flink内存才能让作业稳定，高吞吐的运行；Flink是如何对内存管理的；在新的1.12版本中有什么关于内存或者资源的新特性新改变吗？在新的资源扩展框架下，如何利用GPU资源做深度学习或者机器学习的相关作业，你都能在这篇文章中找到答案。 2 | 3 | 今天就由来自阿里的两位专家，分别是宋辛童和郭旸泽给我们带来Flink在1.12上资源管理新特性的讲解，大家聊一聊关于内存管理以及资源调度相关的一些进展。 议题主要分为2部分，Flink在1.12版本上的高效内存管理和资源调度相关变化将由宋辛童老师讲解，关于扩展资源框架相关问题由郭旸泽老师给大家介绍，关于如何扩展资源框架和以及如何使用GPU进行Flink计算，最后还跟我们讨论了社区在资源管理方面未来的一些规划。 4 | 5 | 作者：宋辛童（Apache Flink Contributor，阿里巴巴技术专家） 、郭旸泽 （Apache Flink Contributor，阿里巴巴高级开发工程师） 6 | 7 | 整理：陈政羽（Apache Flink China 社区志愿者） 8 | 9 | 校对： 10 | 11 | # 内存管理 12 | 13 | 大家可能都有感觉，在我们运行Flink作业时候，该如何配置Flink的一些内存配置选项，我们到底如何去管理它使得Flink作业能够更加高效稳定的运行。在Flink1.10在Flink1.11分别引入了新的内存模型，如下图 14 | 15 | ![image-20210101153149434](./img/image-20210101153149434.png) 16 | 17 | 18 | 19 | 从图中我们把我们常常需要关注的内存模块我们圈了起来。因为我们80~90%的用户只需要关心的是这一小部分，它才是真正用于任务执行和具体的作业相关的模块，需要每次去不断调整的部分。其他的大部分是Flink框架的内存，我们认为80~90%的情况可能不需要进行调整，如果一旦出现了问题，在社区的文档中也会很好的帮助大家解决这些问题。哪怕只有图中的4项内存需要我们注意，大家还不得不面临的一个问题：我的一个作业到底需要多少内存才能满足实际生产需求？这里面会存在一些问题：这些内存指标到底是什么？我的作业是否因为内存不足影响了我的作业性能导致吞吐量无法提升？作业是否存在资源浪费的现象？ 20 | 21 | 针对这样的一个问题，我们社区在1.12版本当中给大家提供了一个全新的关于叫manager和task manager的UI（如图所示） 22 | 23 | ![image-20210101152844186](./img/image-20210101152844186.png) 24 | 25 | 它能够通过网页直观的把每一项监控指标我们的配置值是多少，实际的使用情况是怎么样的，对应到了我们的内存模型当中，对应到哪一项全部都直观的展示给大家，有了这样的一个展示之后，我们可以很清楚的了解到作业的运行情况到底是怎么样的，我们应该去进行如何的调整，然后再配合社区的文档，我们对于每一项的内存具体用哪些配置参数可以来进行调整，通过这种方式的话，希望能够方便到大家对作业的内存管理能够有一个更好的了解。如果大家想对这一项有兴趣可以参考FFA 2020的相关视频。 26 | 27 | ## 本地内存（Managed Memory） 28 | 29 | 接下来想重点跟大家聊一下的是关于Flink的托管内存，托管内存实际上是Flink特有的一种**本地内存**，它不受JVM的管理和 GC管理，而是由Flink自行进行管理的这样一类的内存。 30 | 31 | 这种内存管理主要体现在两个方面，一个方面是它会进行一个slot级别的，我们叫 **slot级别的预算规划**。它可以保证你在作业运行过程中不会因为内存不足，造成某些算子或者任务无法运行；同时也不会因为说预留了过多的内存没有使用造成这样的一个资源浪费，这是所谓的slot级别的资源规划。 32 | 33 | 同时Flink会去保证当你的任务运行结束的时候，它能够准确的把这些内存释放出来，这样Task Manager在用来给新的任务进行执行的时候，内存一定是可用的，这个是一个Flink管理内存的这种方式。托管内存有一个很重要的特性，我们叫做**适应性**。什么叫做适应性？指的是算子对于内存的需求是一个动态可调整的，算子不会因为说给予任务过多的内存，但是实际不需要这么多从而造成一个资源使用上的浪费，它会在一定的合理范围内，不管多少内存都会进行合理的分配；它也不会说给的内存相对比较少导致整个作业无法运行，只是可能在相对比较少的时候会受到一些限制，例如通过频繁的落盘保证作业的运行，这样会导致性能受到一定的影响。以上这就是我们所说的资源适应性。 34 | 35 | 针对托管内存，目前Flink有以下几个场景是使用的 36 | 37 | * RocksDB的状态后端：主要在流计算的使用场景，每个Slot会去使用State的Operator，从而去共享同一块底层RocksDB的缓存块 38 | * Flink内置算子：包含批处理、Table SQL、DataSet API 等算子，每个算子有自己独立的资源预算，不会相互共享 39 | * Python进程：用户使用PyFlink，使用Python语言定义UDF时候需要启动Python的虚拟机进程 40 | 41 | ## Job Graph 编译阶段 42 | 43 | Flink对于management memory的管理，它的预算的管理主要是分为两个阶段，首先第一个阶段是在作业的 job graph编译的阶段，在这个阶段需要主要去搞清楚的是三个问题 44 | 45 | 第一个问题是：slot当中到底有哪些算子或者任务会同时执行。这个关系到说我在一个查询作业中如何对内存进行规划，是否还有其他的任务需要使用management memory从而把相应的内存留出来。 如果是流式的作业当中，这个问题是比较简单的因为我们需要所有的算子同时的执行，才能保证上游产出的数据能给下游及时的消费掉，这个数据才能够在整个job grep当中流动起来。 但是如果我们是在批处理的一些场景当中，实际上我们会存在两种数据shuffle的模式，一种是pipeline的模式，这种pipeline的模式跟流式是一样的，也就是我们前面听到的blound stream的这种处理方式，我同样是需要上游和下游的算子同时运行，然后上游随时产出，下游随时消费。 46 | 47 | ![image-20210101152756380](./img/image-20210101152756380.png) 48 | 49 | 另外一种的话是我们所谓的 batch的 blocking的这种方式，他要求上游把数据全部产出，并且落盘结束之后，下游才能开始读数据。这两种实际上会影响到哪些任务可以同时执行。我们目前在flink当中，他做的是根据作业拓扑图当中的这样的一个边的类型（如图上）。我们划分出了一个我们定义了一个概念叫做pipelined region，也就是全部都由pipeline的边锁连通起来的这样一个子图，我们把这个子图识别出来，用来判断哪些task会同时执行，这个是我们如何回答第一个问题，哪些算子会同时执行。 50 | 51 | 然后接下来我们搞清楚的第二个问题就是slot当中我们到底有哪些使用场景？我们刚才介绍了三种manage memory的使用场景。在这个阶段，对于流式作业，我们可能会出现的是像 Python UDF以及State Operator。这个阶段当中我们需要注意的是，我们这里并不能肯定 State Operator是否一定会用到management memory，因为这是跟它的状态类型看的类型是相关的，如果它使用了 RocksDB State Operator，它是需要使用的manage memory的，但是如果它是使用Heap State Backend，它并不需要，但是作业在编译的阶段是并不知道状态的类型，所以这里是需要去注意的。 52 | 53 | 然后对于batch的作业的话，我们除了需要搞清楚有哪些使用地方之外，我们还需要去搞清楚一件事情。 我们前面提到过batch的operator，它在使用management memory是一种算子独享的方式，而不是以slot为单位去进行共享。我们需要知道不同的算子到底谁应该分配多少内存，这个事情目前是由目前是由flink的 计划作业来自动的来进行一个设置的，Flink作业编译的阶段主要完成的这几个工作。 54 | 55 | ## 执行阶段 56 | 57 | ![image-20210101152432770](./img/image-20210101152432770.png) 58 | 59 | 第一个步骤是我们根据State Backend的类型去判断是否有 RocksDB。如图上所示，同样的刚才我们比如说这样的一个slot，还有ABC三个算字，B跟C分别用到了Python，C用到了State for的 Operator，这种情况下，如果是在heap里边看的情况下，我们走上面的分支，我们整个slot当中只有一种在使用，就是Python。下面的话我们会存在两种使用方式，其中一个是RocksDB State Backend，有了这样的一个第一步的判断之后，第二步我们会去决定根据一个用户的配置，去决定不同使用方式之间怎么样去共享slot的management memory。 60 | 61 | 在我们这个Steaming的例子当中，我们定义的是说相当于Python的权重是30%，然后State Backend的权重是70%。在这样的一个情况下，如果我只有 Python的情况下，当然 Python的部分是使用100%的内存（Streaming的Heap State Backend分支）；而对于第二种情况（Streaming的RocksDB State Backend分支），B、C的这两个Operator共用30%的内存用于 Python的 UDF，另外C在独享70%的内存用于 RocksDB State Backend。最后Flink会根据 Task manager的资源配置，一个slot当中到底有多少manager memory来决定每个operator实际可以用的内存的数量。 62 | 63 | ![image-20210101152324593](./img/image-20210101152324593.png) 64 | 65 | 批处理的情况下跟流的情况有两个不同的地方，首先它不需要去判断State Backend的类型了，这是一个简化； 其次对于batch的算子，我们刚才说每一个算子它有自己独享的这样一个资源的这样一个预算，这种情况下我们会去根据使用率算出不同的使用场景需要多少的Shared之后，我还要把比例进一步的细分到每个Operator。 66 | 67 | ## 参数配置 68 | 69 | | | 配置参数 | 默认值 | 备注 | 70 | | ---- | :----------------------------------------: | :-------------------: | :-----------------------------: | 71 | | 大小 | taskmanager.memory.managed.size | / | 绝对大小 | 72 | | 权重 | taskmanager.memory.managed.fraction | 0.4 | 相对大小（占用Flink）总内存比例 | 73 | | | taskmanager.memory.managed.consumer-weight | DATAPROC:70,PYTHON:30 | 多种用途并存时候分配权重 | 74 | 75 | 这个图表当中展示了我们需要的上面是 manager，memory大小有两种配置方式，一种是绝对值的这种配置方式，还有一种是作为 Task Manager总内存的一个相对值的这样一个配置方式。taskmanager.memory.managed.consumer-weight是一个新加的配置项，它的数据类型是一个map的类型，也就是说我们在这里面实际上是给了一个key冒号value，然后逗号再加上下一组key冒号value的这样的一个数据这样的结构。这里面我们目前支持两种 consumer的 key，一个是DATAPROC， DATAPROC既包含了流处理当中的状态后端State Backend的内存，也包含了批处理当中的 Batch Operator，然后另外一种是Python。 76 | 77 | # 资源调度 78 | 79 | 部分资源调度相关的Feature是其他版本或者邮件列表里面大家询问较多的，这里我们也做对应的介绍 80 | 81 | ## 最大Slot数 82 | 83 | ![image-20210102194947808](./img/image-20210102194947808.png) 84 | 85 | Flink在1.12支持了最大slot数的一个限制（**slotmanager.number-of-slots.max**），在之前我们也有提到过对于流式作业我们要求所有的operator同时执行起来，才能够保证数据的顺畅的运行。在这种情况下，作业的并发度决定了我们的任务需要多少个slot和资源去执行作业，但是对于批处理其实并不是这样的，批处理作业往往可以有一个很大的并发度，但实际并不需要这么多的资源，批处理用很少的资源，跑完前面的任务腾出Slot给后续的任务使用。通过这种串行的方式去执行任务能避免YARN/K8s 集群的资源过多的占用。目前这个参数支持在yarn/mesos/native k8使用 86 | 87 | ## TaskManager容错 88 | 89 | 在我们实际生产中有可能程序的错误，网络的抖动，硬件的故障等问题造成TaskManager无法连接，甚至TaskManager直接挂掉。我们在日志中常见的就是TaskManagerLost这样的一个报错。对于这种情况就是需要进行作业重启，在重启的过程中需要重新申请资源和重启TaskManager进程，这种性能消耗代价是非常高昂的。对于稳定性要求相对比较高的作业，Flink1.12提供了这样的一个新的 feature，能够支持在Flink集群当中始终持有少量的冗余的TaskManager，这些冗余的TaskManager可以用于在单点故障的时候快速的去恢复，而不需要等待一个重新的资源申请的这样一个过程。 90 | 91 | ![image-20210102210054861](./img/image-20210102210054861.png) 92 | 93 | 通过配置**slotmanager.redundant-taskmanager-num** 可以实现冗余TaskManager。这里所谓的冗余TaskManager并不是完完全全有两个TaskManager是空负载运行的，而是说相比于我所需要的总共的资源数量，会多出两个TaskManager，任务可能是相对比较均匀的分布在上面，在能够在利用空闲TaskManager同时，也能够达到一个相对比较好的负载。 在一旦发生故障的时候，我可以去先把任务快速的调度到现有的还存活的TaskManager当中，然后再去进行一个新一轮的资源申请。目前这个参数支持在yarn/mesos/native k8使用 94 | 95 | ## 任务平铺分布 96 | 97 | 任务平铺问题主要出现在Flink Standalone模式下或者是比较旧版本的k8s模式部署下的。在这种模式下因为事先定义好了有多少个TaskManager，每个TaskManager上有多少slot，这样就会导致经常会出现一个调度不均的问题，可能部分manager放的任务很满，有的放的比较松散。在1.11的版本当中引入了这样一个参数**cluster.evenly-spread-out-slots**，这样的参数能够控制它，去进行一个相对比较均衡的这样一个调度。 98 | 99 | ![image-20210102212126391](./img/image-20210102212126391.png) 100 | 101 | 注意：这个参数我们只针对的是**Standalone模式**，因为在yarn跟k8s的模式下，我们实际上是根据你作业的需求来决定我要起多少task manager的，所以是先有了需求再有TaskManager，而不是先有task manager，再有 slot的调度需求。 在每次调度任务的时候，实际上我只能看到当前注册上来的那一个TaskManager，Flink没办法全局的知道说后面还有多少TaskManager会注册上来，这也是我们为什么很多人在问的一个问题，就是为什么特性打开了之后好像并没有起到一个很好的效果，这是第一件事情。 102 | 103 | 第二个需要注意的点是这里面我们只能决定每一个TaskManager上有多少空闲slot，然而并不能够决定每个operator有不同的并发数，Flink并不能决定说每个operator是否在TaskManager上是一个均匀的分布，因为在flink的资源调度逻辑当中，在整个slot的allocation这一层是完全看不到task的。这2个地方是需要大家注意的 104 | 105 | # 扩展资源框架 106 | 107 | ## 背景 108 | 109 | 近几年随着人工智能领域的不断发展，深度学习模型也已经被应用在了各种各样的生产场景中，比较典型的应用场景像是推荐系统、广告推送以及一些智能的风险控制。支持AI以及支持这些深度学习模型或者机器学习算法，一直以来都是Apache Flink社区的长期目标规划之一。 针对这些目标，目前已经有了一些第三方的工作，那么目前阿里巴巴去开源，一个是**Flink AI Extended**的项目，那么它是一个基于Flink的深度学习扩展框架，目前它里面支持了TensorFlow和PyTouch这些常用的机器学习框架，那么有了它以后，你就在Flink执行这些框架的运行。 110 | 111 | 那么另一个就是**Alink**，它是一个基于Flink的通用算法平台，那么里面也内置了一很多常用的机器学习算法，但是以上两个都是从功能性上对Flink进行一些扩展，那么从算力或者说资源的角度上来说，不管是深度学习模型还是机器学习算法，它通常来讲都是我整个作业中的计算瓶颈所在，而GPU则是这个领域被广泛使用的，用来加速这一过程的这么一种资源的设备，那么对于Flink这种对实质性要求比较高的作业，支持机器去加入对GPU的支持就尤为关键了。 112 | 113 | 那么何为加入对GPU的支持？首先从这个调度上来讲，那么目前Flink只支持用户去配置CPU，内存这两个维度的资源。如果Flink要加入这一部分的支持，那么我们首先需要允许用户配置我每个TaskManager上面有几个GPU资源，而且部署在yarn或者k8s上时，我还要将这些资源需求进行一个转发。 有了资源以后，第二步就是将GPU的信息传递给算子，那么用户自定义的这些算子需要在运行时获取当前环境，也就是说它 task所执行的 TaskManager中可以使用的这些GPU资源的信息。 114 | 115 | 以上两个针对所有扩展资源实际上都是通用的，而针对GPU资源来讲，它有一个特殊的资源隔离需求，GPU的显存资源只支持独占使用，那么如果我们多个TaskManager进程跑在了同一台物理机上的时候，我们需要保证每个GPU只能有一个TM去独占，那么我们的扩展资源框架就是针对调度，还有信息传递这两个通用需求，它抽象出来一个比较高层的框架，任除了不只是GPU任何扩展资源都可以插件的形式来加入我们扩展资源框架。 关于扩展资源框架的具体的实现细节社区的FlIP-108有详细描述，接下来我们从用户的角度上讲一下如何使用扩展资源框架。 116 | 117 | ## 扩展资源框架使用方法 118 | 119 | 使用资源框架我们可以分为以下这3个步骤：首先为该扩展资源设置相关配置，然后为所需的扩展资源准备扩展资源框架中的插件，最后在算子中，从RuntimeContext来获取扩展资源的信息并使用这些资源 120 | 121 | ### 配置参数 122 | 123 | ```yaml 124 | # 定义扩展资源名称，“gpu” 125 | external-resources: gpu 126 | # 定义每个 TaskManager 所需的 GPU 数量 127 | external-resource.gpu.amount: 1 128 | # 定义Yarn或Kubernetes中扩展资源的配置键 129 | external-resource.gpu.yarn.config-key: yarn.io/gpu 130 | external-resource.gpu.kubernetes.config-key: nvidia.com/gpu 131 | # 定义插件 GPUDriver 的工厂类。 132 | external-resource.gpu.driver-factory.class: 133 | org.apache.flink.externalresource.gpu.GPUDriverFactory 134 | ``` 135 | 136 | 首先以GPU为例来说一下配置，那么第一个配置就是 external-resources，那么它的值是一个列表，里面包含了你所有去需要的扩展资源的名称，这个名称是大家可以指自己指定的，不一定叫 GPU。但是这个名称之后，你所有扩展资源相关的配置都会以这个名称作为前缀，我们在这里就定义了一个叫做GPU的扩展资源。那么接下来 amount参数设置就是定义了我每个TaskManager上有多少个GPU这种扩展资源，如果你的Flink部署在YARN或者K8s上，你还需要去配置你这种扩展资源。最后如果你为扩展资源准备了插件的话，你需要把插件的工厂类的类名进行配置。 137 | 138 | ### 准备插件 139 | 140 | 根据不同的部署模式去准备不同的插件，如果你是部署一个StandAlone集群的话，那么 GPU资源是需要有你的集群管理员去保证的。也就是说你TM进程起的那些物理机上需要实际有 GPU的设备，那么如果你是执行在YARN模式的话，你需要保证你的Hadoop版本在2.10以及3.1以上，这样的话它才支持一个GPU的调度，并且需要进行 Resource Type的相关配置。如果你是执行在K8s集群的话，需要保证你集群的版本在1.10以上，这样他才支持体 Device plugin机制。 141 | 142 | 不管是哪个厂商的显卡，我们都需要去安装对应的device plugin，在确保我们TaskManager上有GPU资源以后，我们下一步就是获取 GPU资源的信息，那么你需要准备这么插件，这个插件主要需要实现两个接口，一个是ExternalResourceDriver，一个是ExternalResourceDriverFactory，代码如下 143 | 144 | ```java 145 | public interface ExternalResourceDriverFactory { 146 | /** 147 | * 根据提供的设置创建扩展资源的Driver 148 | */ 149 | ExternalResourceDriver createExternalResourceDriver(Configuration config) throws Exception; 150 | } 151 | 152 | public interface ExternalResourceDriver { 153 | /** 154 | * 获取所需数量的扩展资源信息 155 | */ 156 | Set retrieveResourceInfo(long amount) throws Exception; 157 | } 158 | ``` 159 | 160 | 那么ExternalResourceDriver会在每个TaskManager上进行启动，然后框架会调用它的retrieve resource，从而来获取我当前 TaskManager上可见的或者说可以使用的这些扩展资源的信息。那么factory就是 driver的一个工厂类了，他在TaskManager初始化的时候会被用来初始化所有你定义的扩展资源的这些driver。 目前这个插件的核心的功能就是在运行时去获取扩展资源的信息，现在Flink中内置了针对GPU的插件，那么它里边的实现原理也很简单，首先它通过执行一个叫做Discovery的脚本来获取 GPU的信息，那么目前GPU的信息里只包含 GPU设备的index。 161 | 162 | 那么详细来讲一下 Discovery script，首先我们是给大家提供了一个默认脚本的，但是用户也可以去自定义去实现一个脚本，并通过一个路径的配置来指定它。 那么如果你要自定义实现的话，那么你需要遵守脚本的协议。 163 | 164 | 首先我们的driver会在调脚本的时候将GPU的数量作为第一个参数进行输入，那么之后是接着用户自定义的参数列表，那么如果这个脚本就是执行正常且输出符合你的预期，你需要把 GPU的index列表以逗号分割的形式输出到标准输出；那么如果你脚本执行出错了，或者说你认为结果不符合预期，那么你需要脚本已非零值进行退出。需要注意这也会引发就是TaskManager的初始化失败，那么你的所有标准输出以及错误都会被输出到日志里。 165 | 166 | Flink提供的默认脚本是通过 vdissmi工具来获取当前的机器中可用的GPU数量以及index，它只会返回就是所需数量，例如作业只需要两块GPU，而它发现了三块的话，它会只会截取到前两块，但是如果说你的他发现了这批数量不满足要求的话，他就会以非零值退出。 具体的实现大家感兴趣的话，也可以去flink项目中的plugins/external-resource-gpu/目录下去查看具体实现。 167 | 168 | 如果在StandAlone模式下，我们还需要保证各个TaskManager进程之间的对GPU的独占的访问，因此默认脚本也提供了一个协调模式，那么你可以在用户自定义参数列表里加入Enable Coordination Mode来启动协调模式，启动以后它会通过一个全局的文件锁来实现GPU信息的同步，以此来协调同一台机器上多个TaskManager进程对GPU资源的使用。 169 | 170 | ### 使用资源 171 | 172 | 下面我们根据前面所说的做一个机器学习界的HelloWorld，这个主要是通过手写数字进行识别数据集的一个操作 173 | 174 | ![image-20210103130321825](./img/image-20210103130321825.png) 175 | 176 | 通过一个预先训练好的DNN网络，输入以后经过一层的全连接网络来得到一个10位的向量，然后经过一个MaxIndexOf的这么一个操作，最终得到我们的识别结果。 177 | 178 | 我们的运行环境是在一台有两块GPU的机器上，我们起一个StandAlone集群，然后上面有两个TaskManager进程，那么我们需要保证 TaskManagerr进程分别使用其中一块GPU来不冲突进行计算，这就是通过我们默认脚本的 Coordination Mode来实现的。 179 | 180 | 这里简单的介绍一下它的核心类，MNISTClassifier 181 | 182 | ```java 183 | class MNISTClassifier extends RichMapFunction, Integer> { 184 | 185 | @Override 186 | public void open(Configuration parameters) { 187 | //获取GPU信息并且选择第一块GPU 188 | Set externalResourceInfos = getRuntimeContext().getExternalResourceInfos(resourceName); 189 | final Optional firstIndexOptional = externalResourceInfos.iterator().next().getProperty("index"); 190 | // 使用第一块GPU的index初始化JCUDA组件 191 | JCuda.cudaSetDevice(Integer.parseInt(firstIndexOptional.get())); 192 | JCublas.cublasInit(); 193 | } 194 | } 195 | ``` 196 | 197 | 首先从open方法中的RunTimeContext来获取我们的GPU信息，那么从中选出第一块GPU，用它来初始化机器学习的类库。 198 | 199 | map方法中 ，它的输入就是我们手写图片的矩阵。把这个矩阵以及我们之间训练好的模型矩阵都放入GPU，利用库进行一个矩阵乘法的运算，然后把结果从GPU进行一个取出，在本地做一个MaxIndexOf的操作，最终就能得到我们的识别结果了。 200 | 201 | 在算子中使用GPU 202 | 203 | ```java 204 | class MNISTClassifier extends RichMapFunction, Integer> { 205 | @Override 206 | public Integer map(List value) { 207 | // 使用Jucblas做矩阵算法 208 | JCublas.cublasSgemv('n', DIMENSIONS.f1, DIMENSIONS.f0, 1.0f, 209 | matrixPointer, DIMENSIONS.f1, inputPointer, 1, 0.0f, outputPointer, 1); 210 | 211 | // 获得乘法结果并得出该图所表示的数字 212 | JCublas.cublasGetVector(DIMENSIONS.f1, Sizeof.FLOAT, outputPointer, 1, Pointer.to(output), 1); 213 | 214 | JCublas.cublasFree(inputPointer); 215 | JCublas.cublasFree(outputPointer); 216 | 217 | int result = 0; 218 | for (int i = 0; i < DIMENSIONS.f1; ++i) { 219 | result = output[i] > output[result] ? i : result; 220 | } 221 | return result; 222 | } 223 | } 224 | ``` 225 | 226 | 运行时使用GPU进行计算 227 | 228 | ![image-20210103000207575](./img/image-20210103000207575.png) 229 | 230 | 具体案例演示流程可以前往观看视频或者参考Github上面的链接动手尝试 231 | 232 | # 未来计划 233 | 234 | 目前关于资源方面的计划主要有两个方面，首先是被动资源模式，它是指Flink可以根据运行时的可用资源来决定整个job以及各个算子的并发度，而且当可用资源就是发生变化的时候，会根据变化自动的对并发度进行一个调整，这个Feature主要是为了解决我们平常flink跑在k8s或者yarn上的任务，如果资源不够导致作业无法启动执行，有了被动资源模式可以在有限的资源情况下去处理数据。 235 | 236 | 另一个比较重要的工作就是细粒度的资源管理，那么它允许用户可以为任务指定不同的资源需求，这样在调度的时候就会使用不同规格的TaskManager以及slot做一个TaskManager Slot关于资源的异构。那么它主要是为了对资源的利用效率进行一个优化，尤其是复杂场景的资源利用效率的提升。 237 | 238 | # 总结 239 | 240 | 通过文章的介绍，相信大家对Flink内存管理有了更加清晰的认知。首先从本地内存、Job Graph 编译阶段、执行阶段来解答每个流程的内存管理以及内存分配细节，通过新的参数配置控制TaskManager的内存分配；然后从大家平时遇到资源调度相关问题，包括最大Slot数使用，如何进行TaskManager进行容错，任务如何通过任务平铺均摊任务资源；最后在机器学习和深度学习领域常常用到GPU进行加速计算，通过解释Flink在1.12版本如何使用扩展资源框架和演示Demo给我们展示了资源扩展的使用，最后针对资源利用率方面提出2个社区未来正在做的计划，包括被动资源模式和细粒度的资源管理。 241 | 242 | # 附录 243 | 244 | [[1] Accelerating your workload with GPU and other external resources](https://flink.apache.org/news/2020/08/06/external-resource.html) 245 | 246 | [[2] 扩展资源框架文档](https://ci.apache.org/projects/flink/flink-docs-release-1.11/zh/ops/external_resources.html) 247 | 248 | [[3] FLIP-108: Add GPU support in Flink](https://cwiki.apache.org/confluence/display/FLINK/FLIP-108:+Add+GPU+support+in+Flink) 249 | 250 | [[4] flink-mnist 项目](https://github.com/KarmaGYZ/flink-mnist) -------------------------------------------------------------------------------- /Flink 1.12 资源管理新特性/img/image-20210101145852331.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/czy006/FlinkClub/49bc8dc56e7e26b719c5fa4d1a46a623b6e0e3f8/Flink 1.12 资源管理新特性/img/image-20210101145852331.png -------------------------------------------------------------------------------- /Flink 1.12 资源管理新特性/img/image-20210101152324593.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/czy006/FlinkClub/49bc8dc56e7e26b719c5fa4d1a46a623b6e0e3f8/Flink 1.12 资源管理新特性/img/image-20210101152324593.png -------------------------------------------------------------------------------- /Flink 1.12 资源管理新特性/img/image-20210101152432770.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/czy006/FlinkClub/49bc8dc56e7e26b719c5fa4d1a46a623b6e0e3f8/Flink 1.12 资源管理新特性/img/image-20210101152432770.png -------------------------------------------------------------------------------- /Flink 1.12 资源管理新特性/img/image-20210101152756380.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/czy006/FlinkClub/49bc8dc56e7e26b719c5fa4d1a46a623b6e0e3f8/Flink 1.12 资源管理新特性/img/image-20210101152756380.png -------------------------------------------------------------------------------- /Flink 1.12 资源管理新特性/img/image-20210101152844186.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/czy006/FlinkClub/49bc8dc56e7e26b719c5fa4d1a46a623b6e0e3f8/Flink 1.12 资源管理新特性/img/image-20210101152844186.png -------------------------------------------------------------------------------- /Flink 1.12 资源管理新特性/img/image-20210101153149434.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/czy006/FlinkClub/49bc8dc56e7e26b719c5fa4d1a46a623b6e0e3f8/Flink 1.12 资源管理新特性/img/image-20210101153149434.png -------------------------------------------------------------------------------- /Flink 1.12 资源管理新特性/img/image-20210102194947808.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/czy006/FlinkClub/49bc8dc56e7e26b719c5fa4d1a46a623b6e0e3f8/Flink 1.12 资源管理新特性/img/image-20210102194947808.png -------------------------------------------------------------------------------- /Flink 1.12 资源管理新特性/img/image-20210102210054861.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/czy006/FlinkClub/49bc8dc56e7e26b719c5fa4d1a46a623b6e0e3f8/Flink 1.12 资源管理新特性/img/image-20210102210054861.png -------------------------------------------------------------------------------- /Flink 1.12 资源管理新特性/img/image-20210102212126391.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/czy006/FlinkClub/49bc8dc56e7e26b719c5fa4d1a46a623b6e0e3f8/Flink 1.12 资源管理新特性/img/image-20210102212126391.png -------------------------------------------------------------------------------- /Flink 1.12 资源管理新特性/img/image-20210103000207575.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/czy006/FlinkClub/49bc8dc56e7e26b719c5fa4d1a46a623b6e0e3f8/Flink 1.12 资源管理新特性/img/image-20210103000207575.png -------------------------------------------------------------------------------- /Flink 1.12 资源管理新特性/img/image-20210103130321825.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/czy006/FlinkClub/49bc8dc56e7e26b719c5fa4d1a46a623b6e0e3f8/Flink 1.12 资源管理新特性/img/image-20210103130321825.png -------------------------------------------------------------------------------- /Flink 1.13 SQL 深入解读/Flink1.13.md: -------------------------------------------------------------------------------- 1 | # 深入解读 Flink SQL 1.13 2 | 3 | 文章介绍：Flink1.13版本于最近发布了，里面有比较多新的Feature和特性，今天就由我和徐榜江老师带着大家一起去探寻这些新特性，还有一些改进。徐榜江老师目前就职于阿里巴巴 Flink-SQL引擎团队，主要负责社区的SQL引擎模块开发。这篇文章一共会分为4个部分，首先我们会先给大家介绍Flink-SQL在1.13版本上面整体的一个改动，还有一些核心Feature的解读和重要改进，最后就是总结以及Flink1.14一些功能提前和大家剧透。 4 | 5 | `作者：徐榜江 （Apache Flink PMC）` 6 | `整理：陈政羽（Apache Flink China 社区志愿者）` 7 | 8 | # Flink SQL 1.13概览 9 | 10 | image-20210619113225866 11 | 12 | Flink-SQL 1.13是一个社区大版本，解决的issue在1000+以上，通过图中我们可以看到解决的问题大部分是关于Table-SQL模块，一共400多个issue占了37%左右，主要是围绕了其中的5个Flip进行展开，稍后文章我们也会根据这5个进行描述，它们分别是 13 | 14 | - FLIP-145: 支持 Window TVF 15 | - FLIP-162: SQL层面把时区和时间函数进行修正优化 16 | - FLIP-152: 提升 Hive 语法兼容性 17 | - FLIP-163: 改进 SQL Client，使得生产基本可用 18 | - FLIP-136: 增强 DataStream 和 Table 的转换的增强 19 | 20 | 下面我们来通过逐个Feature进行解读 21 | 22 | ## FLIP-145：支持Windows TVF 23 | 24 | 在腾讯、阿里、字节等内部已经有这个功能，这次社区在Flink1.13我们推出了TVF的相关支持和相关优化。下面将从 Window TVF 语法、近实时累计计算场景、 Window 性能优化、多维数据分析进行解剖这个新功能 25 | 26 | ### Window TVF 语法 27 | 28 | 在1.13 前，是一个特殊的GroupWindowFunction 29 | 30 | ```sql 31 | SELECT 32 | TUMBLE_START(bidtime,INTERVAL '10' MINUTE), 33 | TUMBLE_END(bidtime,INTERVAL '10' MINUTE), 34 | TUMBLE_ROWTIME(bidtime,INTERVAL '10' MINUTE), 35 | SUM(price) 36 | FROM MyTable 37 | GROUP BY TUMBLE(bidtime,INTERVAL '10' MINUTE) 38 | ``` 39 | 40 | 在1.13时候我们对它进行了Table-Valued Function的语法标准化 41 | 42 | ```sql 43 | SELECT window_start,window_end,window_time,SUM(price) 44 | FROM TABLE(TUMBLE(TABLE mytable,DESCRIPTOR(biztime),INTERVAL '10' MINUTE)) 45 | GROUP BY window_start,window_end 46 | ``` 47 | 48 | 通过上面的观察，我们可以发现TVF 无需一定要跟在GROUP BY 语法后面，在Window TVF 基于关系代数 ，使得更加标准化。划分窗口只需要TVF，无需再次进行GROUP BY的相关操作；TVF扩展性和表达能力更强，可以自定义TVF（例如topn） 49 | 50 | ![image-20210619135838869](./img/image-20210619135838869.png) 51 | 52 | ![image-20210619135903053](./img/image-20210619135903053.png) 53 | 54 | 以上例子就是TVF做一个窗口划分，只需要把数据划分到窗口无需聚合，如果后续需要聚合只需要GROPBY即可。对于批的用户操作是很自然的一件事，而不需要像1.13之前做一定需要一个特殊的GROUP Function 55 | 56 | 目前WINDOW TVF 支持TUMBLE，HOP WINDOW；新增了CUMULATE WINDOW，SESSION WINDOW 预计在1.14支持 57 | 58 | ### Cumulate Window 59 | 60 | ![image-20210619141938374](./img/image-20210619141938374.png) 61 | 62 | 以图里面一个宽度为单位，第一个window统计一个宽度的数据，第二个window是想统计第一+第二个宽度的数据，第三个window想统计 1 2 3 宽度的数据。这个就是累积计算场景UV。例如：UV大盘曲线：每隔10分钟统计一次当天累积用户uv。在Flink1.13之前，我们需要做这个场景我们一般做法如下 63 | 64 | ```sql 65 | INSERT INTO cumulative_uv 66 | SELECT date_str,MAX(time_str),COUNT(DISTINCT user_id) as uv 67 | FROM ( 68 | SELECT 69 | DATE_FORMAT(ts,'yyyy-MM-dd') as date_str, 70 | SUBSTR(DATE_FORMAT(ts,'HH:mm'),1,4) || '0' as time_str, 71 | user_id 72 | FROM user_behavior 73 | ) 74 | GROUP BY date_str 75 | ``` 76 | 77 | 把时间戳取出按照GROUP BY 取出来，然后再做聚合操作，在里面按照10分钟进行截取，这样达到近似计算的场景 78 | Flink1.13前做法：弊端 逐条计算，追逆数据时候，如果在生产和消费速度相同时候，就会如上图 曲线会比较平稳，但是生产和消费速度不匹配的时候就会跳变。 79 | 80 | 在Flink1.13可以改变我们的做法，当我们拥有了cumulate windows 时候 我们可以修改为下面的语法，每条数据精确分到每个window里面，例如我们是按照event_time进行划分的时候就会 81 | 82 | ```sql 83 | INSERT INTO cumulative_uv 84 | SELECT window_end,COUNT(DISTINCT user_id) as uv 85 | FROM TABLE( 86 | CUMULATE(TABLE user_behavior,DESCRIPTOR(ts),INTERVAL '10' MINUTES,INTERVAL '1' DAY)) 87 | ) 88 | GROUP BY window_start,window_end 89 | ``` 90 | 91 | 最终实现效果如下图 92 | 93 | image-20210619175642414 94 | 95 | ### Window 性能优化 96 | 97 | 内存优化：通过内存预分配，缓存 window 的数据，通过 window watermark 触发计算，通过申请一些buffer避免高频的访问state 98 | 99 | 切片优化：将 window 切片，尽可能复用已计算结果，如 hopwindow,cumulate window。计算过的window数据无需再次计算，对切片进行重复利用数据 100 | 101 | 算子优化：window 支持，local-global 优化；同时支持count(distinct) 自动解热点优化 102 | 103 | 迟到数据：支持迟到数据计算到后续分片， 保证数据准确性 104 | 105 | 通过开源 Benchmark (Nexmark) 测试，普适性能有 2x 提升，在 count(distinct) 场景会有更好的性能提升 106 | 107 | ![](./img/image-20210620115925303.png) 108 | 109 | ### 多维数据分析 110 | 111 | 语法的标准化带来了更多的灵活性和扩展性，它可以直接在window窗口函数上面进行多维分析，如下图所示，可以直接进行GROUPING SETS、ROLLUP、CUBE的计算，如果是在1.13之前的版本，我们可能需要对这些进行单独的编写SQL后，再做union的一些聚合才能获得结果。类似这种多维分析的场景，可以直接在window-tvf上面实现 112 | 113 | ![image-20210620181805583](./img/image-20210620181805583.png) 114 | 115 | 支持WINDOW TOP-N 116 | 117 | ![image-20210620182022617](./img/image-20210620182022617.png) 118 | 119 | ## FLIP-162: 时区和时间函数 120 | 121 | ### 时区问题分析 122 | 123 | 时区问题可以归纳为3个主要原因： 124 | 125 | - PROCTIME() 应该考虑时区，但未考虑时区 126 | - CURRENT_TIMESTAMP/CURRENT_TIME/CURRENT_DATE/NOW() 未考虑时区 127 | - Flink在时间属性上面只支持定义在TIMESTAMP这种数据类型上面，这个类型没有考虑时区。TIMESTAMP 类型不考虑时区，但用户希望是本地时区的时间 128 | 129 | | 时间函数 | Flink 1.13之前 | Flink1.13 | 130 | | ----------------- | ------------------------------------------------------------ | ------------------------------------------------------------ | 131 | | CURRENT_TIMESTAMP | 返回类型: TIMESTAMP
UTC+0时区: 2021-05-22 01:40:52
UTC+8时区: 2021-05-22 01:40:52 | 返回类型: TIMESTAMP_LTZ
UTC+0时区: 2021-05-22 01:40:52
UTC+8时区: 2021-05-22 09:40:52 | 132 | | PROCTIME() | 返回类型: TIMESTAMP *PROCTIME*
UTC+0时区: 2021-05-22 01:40:52
UTC+8时区: 2021-05-22 01:40:52 | 返回类型: TIMESTAMP_LTZ *PROCTIME*
UTC+0时区: 2021-05-22 01:40:52
UTC+8时区: 2021-05-22 09:40:52 | 133 | 134 | 针对TIMESTAMP类型没有携带时区问题，我们推出了TIMESTAMP_LTZ 类型，LTZ是Local Time Zone的缩写，我们可以通过下面的表格来对比和TIMESTAMP两者的对比 135 | 136 | | 数据类型 | 缩写 | 含义 | 137 | | ------------------------------- | ----------------- | ------------------------------------------------------------ | 138 | | TIMESTAMP (p) WITHOUT TIME ZONE | TIMESTAMP (p) | 用于描述年， 月， 日， 小时， 分钟， 秒 和 小数秒
TIMESTAMP 可以通过一个字符串来指定 | 139 | | TIMESTAMP (p) WITH LOCAL TIME | TIMESTAMP_LTZ (p) | 用于描述时间线上的绝对时间点，类似System.currentTimeMillis()
没有字符串表达形式
在计算和可视化时， 使用 session 中配置
的时区。 | 140 | 141 | TIMESTAMP_LTZ 区别于之前我们使用TIMESTAMP，它是表示绝对时间的含义，通过对比我们可以发现，如果我们配置使用TIMESTAMP类型，他可以是字符串类型的。不管是从英国还是中国来说来对比这个值，其实都是一样的；但是对于TIMSTAMP_TLZ来说，它的来源就是一个Long值，在不同的时区去观察这个数据是不一样的，这样更加符合用户在实际生产上面一些需求。 142 | 143 | ### 时间函数纠正 144 | 145 | **订正 PROCTIME() 函数** 146 | 147 | 当我们有了TIMESTAMP_LTZ 这个类型的时候，我们对PROCTIME()类型做了纠正，在1.13之前它总是返回UTC的TIMESTAMP，我们现在进行了纠正，把返回类型变为了TIMESTAMP_LTZ。PROCTIME除了表示函数之外，PROCTIME也可以表示时间属性的标记，下图我们通过创建这些时间类型的一张demo表可以看到类型发生的变化 148 | 149 | ![image-20210619172919191](./img/image-20210619172919191.png) 150 | 151 | **订正 CURRENT_TIMESTAMP/CURRENT_TIME/CURRENT_DATE/NOW() 函数** 152 | 153 | 这些函数在不同时区下出来的值是会发生变化的，例如在英国UTC时区时候是凌晨2点，但是如果你设置了时区是UTC+8的时候，时间是在早上的10点，不同时区的实际时间会发生变化，效果如下图： 154 | 155 | ![image-20210619173221897](./img/image-20210619173221897.png) 156 | 157 | **解决 processing time window 时区问题** 158 | 159 | PROCTIME可以表示一个时间属性，我们基于PROCTIME的WINDOW操作，在Flink1.13之前如果我们需要做按天的window操作，进行按天WINDOW你需要手动解决时区问题，去做一些8小时的偏移然后再减回去。在FLIP-162解决了这个问题，现在用户使用的时候十分简单，PROCTIME直接声明了，结果是本地的时区。例如下图案例，英国时区的window_end 和 中国时区 的window_end会发生变化 160 | 161 | ```sql 162 | FLINK SQL> CREATE TABLE MyTable( 163 | item STRING, 164 | price DOUBLE, 165 | proctime as PROCTIME() 166 | ) WITH(...); 167 | 168 | FLINK SQL> CREATE VIEW MyView AS 169 | SELECT 170 | TUMBLE_START(bidtime,INTERVAL '10' MINUTE), 171 | TUMBLE_END(bidtime,INTERVAL '10' MINUTE), 172 | TUMBLE_ROWTIME(bidtime,INTERVAL '10' MINUTE), 173 | item, 174 | SUM(price) as max_price 175 | FROM MyTable 176 | GROUP BY TUMBLE(bidtime,INTERVAL '10' MINUTE),item 177 | ``` 178 | 179 | 我们通过设置不同的时区去对比发现实际window聚合的时间区间会有所变化 180 | 181 | ![image-20210619173253180](./img/image-20210619173253180.png) 182 | 183 | **订正 Streaming 和 Batch 模式下函数取值方式** 184 | 185 | 时间函数其实在流和批上面表现的形式会有所区别，主要这次修正是让用户更加符合实际的使用习惯。例如一下函数，在流模式中是per-record计算（在流模式下，是逐条数据的时间），在batch模式是query-start计算，（例如我们在使用一些离线计算引擎，hive 就是每一个批作业实际运行的时间） 186 | 187 | Streaming 模式 per-record 计算，Batch 模式在 query-start 计算： 188 | 189 | - LOCALTIME 190 | - LOCALTIMESTAMP 191 | - CURRENT_DATE 192 | - CURRENT_TIME 193 | - CURRENT_TIMESTAMP 194 | - NOW() 195 | 196 | Stream 和 Batch 模式都是 per-record 计算： 197 | 198 | - CURRENT_ROW_TIMESTAMP() 199 | - PROCTIME() 200 | 201 | ### 时间类型使用 202 | 203 | EVENT_TIME 在Flink1.13也支持了定义在TIMESTAMP列上，相当于EVENT_TIME现在目前支持定义在TIMESTAMP和TIMESTAMP_ 204 | LTZ上面。 205 | 206 | 当你上游源数据包含了字符串的时间（如：2021-4-15 14:00:00）这样的场景，直接声明为TIMESTAMP然后把EVENT_TIME直接定义在上面即可，WINDOW窗口在计算的时候会基于你的字符串进行切分，最终会符合你实际想要的预想结果； 207 | 208 | 209 | 210 | 当你上游数据源的打点时间是属于long值，表示是一个绝对时间的含义。Flink1.13你可以把EVENT_TIME定义在TIMESTAMP上面，然后通过转换为TIMESTAMP_LTZ类型在window上面做一些聚合，在不同时区上面看到的值就是不一样的，自动的解决了8小时的时区便宜问题，无需人工干预在SQL语句查询层面做语法的修改 211 | 212 | 小提示：Flink-SQL标准里面的进行订正，在各位进行版本的时候需要留意作业逻辑中是否包含此类函数，避免升级后业务受到影响 213 | 214 | 215 | ### 夏令时支持 216 | 217 | 对于国外夏令时，以前在做相关窗口计算操作是十分困难的一件事，Flink 支持在 TIMESTAMP_LTZ 列上定义时间属性， Flink SQL 在 window 处理时结合 TIMESTAMP 和 TIMESTAMP_LTZ， 优雅地支持了夏令时。主要是针对海外的业务统计场景会比较友好 218 | 219 | ![image-20210619163651120](./img/image-20210619163651120.png) 220 | 221 | 在洛杉矶时区，[2021-03-14 00:00, 2021-03-14 00:04] 窗口会收集 3 个小时的数据 222 | 在非夏令时区，[2021-03-14 00:00, 2021-03-14 00:04] 窗口会收集 4 个小时的数据 223 | 224 | # Flink SQL重要改进 225 | 226 | ## FLIP-152：提升Hive 语法兼容性 227 | 228 | 这个主要是做了Hive语法的兼容性增强，首先支持了Hive的一些常用DML和DQL语法，这里列举部分 229 | 230 | - SORT/CLUSTER/DISTRIBUTE BY 231 | - Group By 232 | - Join 233 | - Union 234 | - LATERAL VIEW 235 | - Window Functions 236 | - SubQueries 237 | - CTE 238 | - INSERT INTO dest schema 239 | - Implicit type conversions 240 | 241 | Hive dialect 支持 Hive 常用语法，hive有十分多内置函数，Hive dialect 需要配合 HiveCatalog 和 Hive Module 一起使用，Hive Module 提供了 Hive 所有内置函数，加载后可以直接访问 242 | 243 | ```shell 244 | FLINK SQL> CREATE CATALOG myhive WITH ('type'='hive'); --setup HiveCatalog 245 | FLINK SQL> USE CATALOG myhive; 246 | FLINK SQL> LOAD MODULE hive; --setup HiveModule 247 | FLINK SQL> USE MODULES hive,core; 248 | FLINK SQL> SET table.sql-dialect = hive; -- enable Hive dialect 249 | FLINK SQL> SELECT ket,value FROM src CLUSTER BY key; --run some Hive queries 250 | ``` 251 | 252 | 与此同时，我们还可以通过Hive dialect 创建/删除 Catalog 函数以及一些自己自定义的一些函数，对用户使用起来会更加方便 253 | 254 | ```shell 255 | FLINK SQL> SHOW FUNCTIONS; 256 | FLINK SQL> CREATE FUNCTION function_name AS class_name; --create function 257 | FLINK SQL> DROP FUNCTION [IF EXISTS] function_name; 258 | ``` 259 | 260 | ## FLIP-163：改进的SQLClient 261 | 262 | 在Flink1.13之前，大家觉得就是Flink SQL Client就是周边的一个小工具，在FLIP-163进行重要改进： 263 | 264 | 1. 通过-i的参数，提前把DDL一次性加载初始化，方便初始化表的多个DDL语句，无需再多次使用command命令逐条发送，通过替代以前yaml方式去创建表 265 | 266 | ```shell 267 | ./sql-client.sh -i inin.sql 268 | ``` 269 | 270 | 2. -f 参数，其中SQL文件支持DML（insert into）语句 271 | 272 | ```shell 273 | ./sql-client.sh -i inin.sql -f sqlfile 274 | ``` 275 | 276 | 3. 支持更多实用的配置 277 | 278 | - 通过 **SET sql-client.verbose = true** , 开启verbose，通过开启verbose打印整个信息，相对以前只输出一句话更加容易追踪错误信息 279 | - 通过 **SET execution.runtime-mode=streaming / batch** 支持设置批/流作业模式 280 | - 通过 **SET pipline.name=my_flink_job** 设置作业名称 281 | - 通过 **SET execution.savepoint.path=/tmp/flink-savepoints/savepoint-bb0dab** 设置作业savepoint路径 282 | - 对于有依赖的管道作业，通过 **SET table.dml-sync=true** 去选择是否异步执行，例如作业a跑完才能跑作业b的离线作业通过设置为true去执行有依赖关系的pipeline作业 283 | 284 | 4. 支持STATEMENT SET 285 | 286 | ```shell 287 | FLINK SQL> BEGIN STATEMENT SET; 288 | FLINK SQL> INSERT INTO pageview_pv_sink 289 | > SELECT page_id,COUNT(1) FROM clicks GROUP BY page_id; 290 | FLINK SQL> INSERT INTO pageview_uv_sink 291 | > SELECT page_id,COUNT(DISTINCT user_id) FROM clicks GROUP BY page_id; 292 | FLINK SQL> END; 293 | ``` 294 | 295 | 有可能我们一个查询不止写到一个sink里面，我需要输出到多个sink，一个sink写jdbc 一个sink写到hbase；在1.13之前需要启动2个query去完成这个作业，然后1.13我们可以把这些放到一个statement里面以一个作业的方式去执行，能够做到 source的复用，节约资源 296 | 297 | ## FLIP-136：增强DataStream 和 Table 的转换 298 | 299 | 虽然SQL大大降低了我们使用实时计算的一些使用门槛，但是TABLE和SQL以前我们在ds和table之间的转换比较不方便，对于一些底层封装我们上层sql用户无法直接拿到，例如访问state去做操作，flip-136就是解决这个问题的。 300 | 301 | - 支持 DataStream 和 Table转换时传递 EVENT TIME 和WATERMARK 302 | 303 | ```java 304 | Table table = tableEnv.fromDataStream( 305 | dataStream, 306 | Schema.newBuilder() 307 | .columnByMetadata("rowtime","TIMESTMP(3)") 308 | .watermark("rowtime","SOURCE_WATERMARK()") 309 | .build()); 310 | ) 311 | ``` 312 | 313 | - 支持 Changelog 数据流在 Table 和 DataStream 间相互转换 314 | 315 | ```java 316 | //DATASTREAM 转 Table 317 | StreamTableEnvironment.fromChangelogStream(DataStream): Table 318 | StreamTableEnvironment.fromChangelogStream(DataStream,Schema): Table 319 | //Table 转 DATASTREAM 320 | StreamTableEnvironment.toChangelogStream(Table): DataStream 321 | StreamTableEnvironment.toChangelogStream(Table,Schema): DataStream 322 | ``` 323 | 324 | # Flink1.14 SQL 未来规划 325 | 326 | Flink1.14 主要有以下这几点的规划： 327 | 328 | - Flink1.9开始，阿里贡献了新的Blink-Planner后，很多一些新的Feature已经基于此Planner进行开发，所以以前旧的Legacy Planner会彻底删除 329 | - 完善WINDOW TVF，目前还要SESSION WINDOW正在开发，预计1.14会和大家见面 330 | - 提升Schema Handling，Schema校验的提升 331 | - 增强Flink CDC 支持，增强对上游CDC系统的一个集成能力 332 | 333 | # 总结 334 | 335 | 通过上面的文章的介绍，我们可以知道1.13 SQL主要就是围绕着这5部分去展开探讨的： 336 | 337 | - Flink-SQL上统一的支持了window tvf 338 | - 统一的解决了时区和时间函数问题 339 | - 提升hive和flink的兼容性 340 | - 改进sql client 341 | - 对高级用户 使用 DS 和 Table的转换增强 342 | 343 | 最后还分享了关于Flink1.14 SQL 上面的一些未来规划，看完文章的小伙伴相信大家对Flink SQL 在这个版本中变化有了深刻的了解，在实践过程中大家可以多多关注这些新的改动和变化带来业务层面上面的便捷。 344 | -------------------------------------------------------------------------------- /Flink 1.13 SQL 深入解读/img/image-20210619113225866.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/czy006/FlinkClub/49bc8dc56e7e26b719c5fa4d1a46a623b6e0e3f8/Flink 1.13 SQL 深入解读/img/image-20210619113225866.png -------------------------------------------------------------------------------- /Flink 1.13 SQL 深入解读/img/image-20210619135838869.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/czy006/FlinkClub/49bc8dc56e7e26b719c5fa4d1a46a623b6e0e3f8/Flink 1.13 SQL 深入解读/img/image-20210619135838869.png -------------------------------------------------------------------------------- /Flink 1.13 SQL 深入解读/img/image-20210619135903053.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/czy006/FlinkClub/49bc8dc56e7e26b719c5fa4d1a46a623b6e0e3f8/Flink 1.13 SQL 深入解读/img/image-20210619135903053.png -------------------------------------------------------------------------------- /Flink 1.13 SQL 深入解读/img/image-20210619141938374.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/czy006/FlinkClub/49bc8dc56e7e26b719c5fa4d1a46a623b6e0e3f8/Flink 1.13 SQL 深入解读/img/image-20210619141938374.png -------------------------------------------------------------------------------- /Flink 1.13 SQL 深入解读/img/image-20210619163651120.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/czy006/FlinkClub/49bc8dc56e7e26b719c5fa4d1a46a623b6e0e3f8/Flink 1.13 SQL 深入解读/img/image-20210619163651120.png -------------------------------------------------------------------------------- /Flink 1.13 SQL 深入解读/img/image-20210619172919191.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/czy006/FlinkClub/49bc8dc56e7e26b719c5fa4d1a46a623b6e0e3f8/Flink 1.13 SQL 深入解读/img/image-20210619172919191.png -------------------------------------------------------------------------------- /Flink 1.13 SQL 深入解读/img/image-20210619173221897.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/czy006/FlinkClub/49bc8dc56e7e26b719c5fa4d1a46a623b6e0e3f8/Flink 1.13 SQL 深入解读/img/image-20210619173221897.png -------------------------------------------------------------------------------- /Flink 1.13 SQL 深入解读/img/image-20210619173253180.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/czy006/FlinkClub/49bc8dc56e7e26b719c5fa4d1a46a623b6e0e3f8/Flink 1.13 SQL 深入解读/img/image-20210619173253180.png -------------------------------------------------------------------------------- /Flink 1.13 SQL 深入解读/img/image-20210619175642414.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/czy006/FlinkClub/49bc8dc56e7e26b719c5fa4d1a46a623b6e0e3f8/Flink 1.13 SQL 深入解读/img/image-20210619175642414.png -------------------------------------------------------------------------------- /Flink 1.13 SQL 深入解读/img/image-20210620115925303.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/czy006/FlinkClub/49bc8dc56e7e26b719c5fa4d1a46a623b6e0e3f8/Flink 1.13 SQL 深入解读/img/image-20210620115925303.png -------------------------------------------------------------------------------- /Flink 1.13 SQL 深入解读/img/image-20210620181805583.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/czy006/FlinkClub/49bc8dc56e7e26b719c5fa4d1a46a623b6e0e3f8/Flink 1.13 SQL 深入解读/img/image-20210620181805583.png -------------------------------------------------------------------------------- /Flink 1.13 SQL 深入解读/img/image-20210620182022617.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/czy006/FlinkClub/49bc8dc56e7e26b719c5fa4d1a46a623b6e0e3f8/Flink 1.13 SQL 深入解读/img/image-20210620182022617.png -------------------------------------------------------------------------------- /Flink 1.14 前言预览/Flink1.14 前言预览.md: -------------------------------------------------------------------------------- 1 | 文章介绍：Flink1.14版本发布在即，各位小伙伴是不是已经迫不及待了呢。在Flink1.14中带来的变化将在这篇文章逐一进行简单介绍。我们首先先会回顾一下社区在Flink1.14的一些开发状态以及进度。然后来探讨一下社区在批流一体这个方向上的技术改进，批流一体作为社区重要的重要路线，所以对于批流一体的改进是十分重要的。与此同时我们还会探讨checkpoint机制调整、优化以及后续工作；同时进行引擎和资源效率优化的介绍；最后介绍Table-SQL-Api上面发生的改动，让用户在使用高级API时候更加方便。这次给我们带来分享的是阿里巴巴开源大数据平台技术专家宋辛童，花名五藏，Apache Flink PMC Member & Committer Flink 1.14 Release Manager 2 | 3 | 作者：宋辛童（花名：五藏） Apache Flink PMC Member & Committer 4 | 5 | 整理：陈政羽（Apache Flink China 社区志愿者） 6 | 7 | # 简介 8 | 1.14这个新版本一共有35个比较重要的新特性以及一些优化工作，目前已经有26个工作完成，5个任务不确定是否能准时完成，有4个特性放到后续版本完成。 9 | 10 | ![img](./img/1.png) 11 | 12 | 在这个版本在历史当中囊括的优化和新增功能点其实并不算非常的多，其实大家通过观察发版节奏可以发现通常发布1-2个大版本后都会发布一个变化改动稍微少一点的版本，主要目的是把一些特性更加稳定下来。所以我们1.14版本的定位就是这样的一个定位，我们称之为质量改进和维护的一个版本。这个版本预计8.16停止新特性开发，大概9月中能够和大家正式见面，大家有兴趣可以关注以下链接去跟踪功能发布进度 13 | 14 | - Wiki [https://cwiki.apache.org/confluence/display/FLINK/1.14+Release](https://cwiki.apache.org/confluence/display/FLINK/1.14+Release) 15 | - Jira [https://issues.apache.org/jira/projects/FLINK/versions/12349614](https://issues.apache.org/jira/projects/FLINK/versions/12349614) 16 | # 流批一体 17 | Flink流批一体其实从1.9版本开始大家就受到持续的关注，它作为社区RoadMap重要组成部分，随着大数据不断推进的实时化。但是传统的离线的需求并不会给实时任务完全取代，还会是长期存在的一个状态。按照以往流批独立技术方案的痛点，维护两套系统，两套开发人员，两套数据链路处理相似内容带来维护的风险性和冗余，同时有可能是流批使用的不是同一套数据处理系统，引擎本身差异可能存在数据口径不一致的问题，从而导致业务数据存在一定的误差。所以Flink社区定制的目标是实时离线一体化这个技术路线，这个比较重要的技术趋势和方向。 18 | 19 | Flink在过去的几个版本当中流批一体完成了非常多的一个工作，在目前引擎层面来看，API 算子执行层面上做到流批同一套机制运行。在任务具体的执行模式上会有2种不同执行模式。对于无限的数据流我们统一采用了流的执行模式，流的执行模式指的是所有是通过一个Pipeline模式去连接的，流的执行模式是上游和下游数据是同时运行的，随着上游不断产出数据，下游不断消费数据。这种称为全Pipeline的执行方式，它可以通过eventTime表示数据什么时候产生的；通过watermark得知目前哪个时间点数据已经到达了；通过state 来维护计算中间状态；通过checkpoint 做容错的处理。如下图是不同的执行模式 20 | 21 | ![img](./img/2.png) 22 | 23 | 对于有限的数据集有2种模式，我们可以把它看成一个有限的数据流去做处理，也可以把它看成批的执行模式。批的执行模式虽然有eventTime，但是对于watermark来说只有正无穷。如果基于数据的state排序后，它在任务的调度和shuffle上会有更多的选择。流批的执行它们2者是有区别的，例如批的执行模式会有落盘的中间过程，只有当前面任务执行完成，下游的任务才会触发，这个容错机制是通过suffle进入容错。这2者各自有各自的执行优势：对于流的执行模式来说，它没有落盘的压力，容错是基于数据的分段，通过不断对数据进行打点checkpoint去保证断点恢复，然而在批处理上，因为是要经过shuffle落盘的，所以对磁盘会有压力，但是因为我数据是经过排序的，所以对批来说可能后续的计算效率会有一定的提升，同时在执行时候我们是经过分段去执行任务的，无需同时执行。容错计算方面是根据stage进行容错，这两种各自优劣进行不同场景进行选择。 24 | 25 | Flink1.14优化点主要是针对在流的执行模式下，如何去处理有限数据集。之前处理无限数据集和有限数据集最大区别是任务可能结束的问题。我们来看看下图 26 | 27 | ![img](./img/3.png) 28 | 29 | 在流checkpoint机制，对于一个无限流，它的所有checkpoint是由source节点进行触发的，由source节点发送checkpoint Barrier ，当checkpoint Barrier流过整个作业时候，同时这个checkpoint会存储当前作业所有的state状态。在有限流的checkpoint机制中，我们的task是有可能提早完成任务结束的。上游的Task有可能先处理完任务提早退出了，但是下游的task还是在执行中。在同一个stage不同并发下，有可能数据量不一致导致部分任务提早完成了。这种情况下，后续如果进行checkpoint 30 | 31 | 我们引入了JobManager动态根据当前任务的执行情况，去明确checkpoint Barrier 是从哪里开始触发的一个机制。同时我们在部分任务结束后，后续的checkpoint只会保存 仍然在运行task所对应的stage，通过这种方式我们能够让任务执行完成后 还可以继续做checkpoint ，在有限流执行当中更好的保障 32 | 33 | ![img](./img/4.png) 34 | 35 | **Task结束后二阶段提交** 36 | 37 | 我们在部分sink使用上，例如下图的Kafka Sink上，涉及到 Task 需要依靠checkpoint机制，进行二阶段提交，从而保证数据的Exactly-once 一致性 38 | 39 | ![img](./img/5.png) 40 | 41 | 具体而言可以这样说：在checkpoint过程中，每个算子只会进行准备提交的操作。比如数据会提交到外部的临时存储目录下，所有任务都完成这次checkpoint之后会收到一个信号，才会执行真正的commit。它会把所有分布式的临时文件一次性以事务的方式提交到外部系统。这种算法在当前有限流的情况下，作业结束后并不能保证有 Checkpoint，那么最后一部分数据如何提交？在1.14中我们让task数据处理完成后，Task 等待 Checkpoint 完成后才可以正式的退出，这样可以针对有限流可能一些任务结束的改进 42 | 43 | # Checkpoint机制 44 | ## 现有checkpoint机制痛点 45 | 目前Flink触发checkpoint是依靠barrier在算子进行流通，当算子遇barrier随着算子一直往下游进行发送，当下游遇到barrier的时候就会进行快照操作，然后再把barrier往下游继续发送。对于多路的情况我们会把barrier进行对齐，把先到barrier的这一路数据暂时性的block，等到两路 barrier 都到了之后我们才做快照，最后才会去继续往下继续发送barrier。 46 | 47 | ![img](./img/6.png) 48 | 49 | 现有的CheckPoint机制很明显存在以下问题： 50 | 51 | - 反压时无法做出 checkpoint ：在反压时候 barrier 无法随着数据往下游流动，造成反压时候无法做出checkpoint。但是其实我们在发生反压这种情况的时候我们更加需要去做出对数据的checkpoint，因为这个时候是性能遇到了瓶颈，反而是更加容易出问题的阶段 52 | - Barrier 对齐阻塞数据处理 ：对于性能上阻塞对齐存在一定的影响 53 | - 恢复性能受限于 checkpoint 间隔 ：在做恢复时候延迟受到多大的影响很多时候是取决于CheckPoint的间隔，间隔越大，需要replay的数据就会越多，从而造成中断的影响也就会越大。但是目前checkpoint间隔受制于持久化操作的时间，所以没办法做的十分快 54 | ## Unaligned Checkpoint 55 | 针对这些痛点Flink在最近几个版本一直在持续的优化，**Unaligned Checkpoint** 就是其中一个机制。barrier算子在到达input buffer最前面的时候，我们就会开始触发CheckPoint操作。它会立刻把barrier传到算子的Out Put Buffer的最前面，相当于会立刻被下游的算子所读取到。通过这种方式可以使得barrier 不受到数据阻塞，解决反压时候无法进行Checkpoint。当我们把barrier发下去后，我们需要做一个短暂的暂停，暂停时候我们会把算子的State 和 input output buffer 中的数据进行一个标记，以方便后续随时准备上传。对于多路情况会一直等到另外一路barrier到达之前数据，全部进行标注。通过这种方式整个在做Checkpoint的时候，也不需要对barrier进行对齐，唯一需要做的停顿就是在整个过程中对所有buffer和state标注的这样一个过程。这种方式可以很好的解决了反压时无法做出 checkpoint 和 Barrier 对齐阻塞数据影响性能处理 56 | 57 | ![img](/Users/chenzhengyu/Documents/Flink中文社区翻译稿/Flink1.14/img/7.png) 58 | 59 | ## Generalized Incremental Checkpoint 60 | 这个主要是用于减少Checkpoint间隔，如左图1所示，在Incremental Checkpoint 当中，先让算子写入state 的 changelog。写完后才把变化真正数据写入到StateTable上。state 的 changelog不断的向外部进行持久的存储化。在这个过程中我们其实无需等待整个StateTable去做一个持久化操作，我们只需要保证对应的Checkpoint这一部分的changelog能够持久化完成，就可以开始做下一次checkpoint。StateTable是以一个周期性的方式，独立的去对外做持续化的一个过程。 61 | 62 | ![img](./img/8.png) 63 | 64 | 这两个过程进行拆分后，我们就有了从以前需要做**全量持久化（Per Checkpoint）变成** **增量持久化 （Per Checkpoint）+ 后台周期性 全量持久化**，从而达到同样容错的一个效果。在这个过程中我每一次checkpoint需要做持久化的数据量减少了，从而我做checkpoint的间隔能够大幅度减少。其实在RocksDB也是能支持 Incremental Checkpoint 。但是有两个问题，第一个问题是RocksDB的Incremental Checkpoint 是依赖它自己本身的一些实现，当中会存在一些数据压缩，压缩所消耗的时间以及压缩效果具有不确定性，这个是和我们的数据相关的；第二个问题是只能针对特定的StateBackend来使用，目前在做Generalized Incremental Checkpoint 实际上能保证是对于StateBackend无关的，从运行时的机制来保证了一个比较稳定、更小的Checkpoint间隔。 65 | 66 | 目前 Unaligned Checkpoint 是在Flink1.13就已经发布了，在1.14版本主要是针对bug的修复和补充，Generalized Incremental Checkpoint 目前社区还在做最后的冲刺，是比较有希望在1.14中和大家见面。 67 | 68 | # 性能与效率 69 | ## 大规模作业调度的优化 70 | 71 | - 构建Pipeline Region的性能提升：所有由pipline边所连接构成的子图 。在Flink任务调度中需要识别这些Pipeline Region 来保证同一个Pipline连接的边的任务进行同时调度。否则有可能上游的任务开始调度，但是下游的任务并没有运行。从而导致上游运行完的数据无法给下游的节点进行消费，可能会造成死锁的情况 72 | - 任务部署阶段：每个任务都要从哪些上游读取哪些信息，所以我们会生成Result Partition Deployment Descriptor 73 | 74 | 这2个构建过程在之前的版本都有o（n^2）的时间复杂度，主要问题需要对于每个下游节点去遍历每一个上游节点的情况。例如去遍历每一个上游是不是一个Pipeline 边连接的关系，或者我要去遍历它的每一个上游生成对应的Result Partition 信息。我们通过引入group概念，假设我们已知上下游2个任务的连接方式是out to out，那我们相当于把所有Pipeline Region信息 或者 Result Partition 信息以Group的形式进行组合，这样只需知道下游对于的是上游的哪一个group就可以，通过一个简单的wordcount测试对比优化前后的性能如下表格 75 | 76 | | | **执行模式** | **并发度** | **优化前** | **优化后** | 77 | | :----------------------: | :----------: | :--------: | :--------: | :--------: | 78 | | **构建 Pipeline Region** | 流 | 8k x 8k | 3s 441ms | 22ms | 79 | | | | 16k x 16k | 14s 319ms | 107ms | 80 | | | 批 | 8k x 8k | 8s 941ms | 124ms | 81 | | | | 16k x 16k | 34s 484ms | 308ms | 82 | | **任务部署** | 流 | 8k x 8k | 32s 611ms | 6s 480ms | 83 | | | | 16k x 16k | 129s 408ms | 19s 051ms | 84 | 85 | 从表格中可以看到构建速度具有大幅度提升，构建Pipeline Region 的性能从秒级提升至毫秒级别。任务部署我们是从第一个任务开始部署到所有任务开始运行的状态，我们这边只统计了流，因为批需要上游结束后才能结束调度。整体时间来看，整个任务初始化，调度等流程减少到分钟级的消耗 86 | ## 细粒度资源管理 87 | 细粒度资源管理在历史比较多的版本我们一直在做，在Flink1.14我们终于可以把这一部分API暴露出来在DataSteam提供给用户使用了。用户可以在DataStream中自定义SlotSharingGroup的划分情况，如下图所示可以这样去定义Slot的资源划分。通过这样实现了支持 DataStream API，自定义 SSG 划分方式以及资源配置 TaskManager 动态资源扣减 88 | 89 | img 90 | 91 | 对于每一个Slot可以通过比较细粒度的配置，通过这样我们在Runtime上会自动根据用户资源配置进行动态的资源切割，切割后如图下 92 | 93 | ![img](./img/11.png) 94 | 95 | 这样做的好处而不会像之前那样会有固定资源的Slot，而是做资源的动态扣减，通过这样的方式希望能够达到更加精细的资源管理和资源的使用率 96 | 97 | # Table SQL & Python API 98 | Window Table-Valued Function 支持更多算子与窗口类型 ，可以看如下表格对比 99 | 100 | 101 | | | **Tumble** | **Hop** | **Cumulate** | **Session** | 102 | | :-: | :-: | :-: | :-: | :-: | 103 | | **Aggregate** | 1.13 | 1.13 | 1.13 | 1.14 | 104 | | **TopN** | 1.13 | 1.13 | 1.13 || 105 | | **Join** | 1.14 | 1.14 | 1.14 || 106 | | **Deduplicate** | 1.14 | 1.14 | 1.14 || 107 | 108 | 109 | 从表格中可以看出对于原有的三个窗口类型进行加强，同时新增Session窗口支持Aggregate的操作 110 | ## 使用声明式的方式创建Source/Sink 111 | Table API 支持声明式注册 Source / Sink 功能对齐 SQL DDL 如图下所示，同时支持FLIP-27新的Source接口。new Source 替代旧的 connect() 接口 112 | 113 | img 114 | 115 | 全新代码生成器解决了大家在生成代码超过Java最长代码限制，新的代码生成器会对代码进行拆解，彻底解决代码超长问题；同时我们移除Flink Planner，新版本中 Blink Planner 成为Flink Planner的唯一实现 116 | 117 | ## Python UDF 作业性能优化 118 | 在之前版本中有先后执行的UDF可以看到图左边，在Java上面有java的Operator，先去把数据发给python下面的udf去进行执行，执行后又发回给Java传送给下游的Operator，最后向python这种跨进程的传输去处理，这样就会导致存在很多次冗余的数据传输。 119 | 120 | ![img](./img/13.png) 121 | 122 | 在1.14版本中通过改进可以看到右图，可以把他们连接在一起，只需要一个来回的Java和Python进行数据通信，通过减少传输数据次数能够达到性能比较好的一个改进 123 | 124 | ## 支持LoopBack模式 125 | 在以往本地执行实际是在python的进程中去运行我们客户端程序，提交java进程启动一个迷你集群去执行java部分代码。Java部分代码也会和生产环境部分的一样，去启动一个新的python进程去执行对应的python udf，从图下可以看出其实我们在本地调试中是没有必要存在的 126 | 127 | ![img](./img/14.png) 128 | 129 | 所以我们支持lookback模式可以让java的opt直接把udf运行在python client所相同的进程里面，通过这种方式避免了我们额外启动进程所带来一个额外的开销，最重要是在本地调试中我们可以在同一个进程之内能够更好利用一些工具进行debug，这个是对开发者体验上的一个提升 130 | 131 | # 总结 132 | 通过今天讲解Flink1.14的主要新特性介绍，首先我们先介绍了目前社区在批流一体上的工作，通过介绍批流不同的执行模式和JM节点任务触发的优化改进更好的去兼容批作业。然后通过分析现有的CheckPoint机制痛点，在新版本中如何改进；以及在大规模作业调度优化和细粒度的资源管理上面如何做到对性能优化；最后介绍了TableSQL API 和 Pyhton上相关的性能优化。欢迎各位后续继续关注发版的一些最新动态以及我们在后续的Release过程中的一些其他技术分享和专题 133 | -------------------------------------------------------------------------------- /Flink 1.14 前言预览/img/1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/czy006/FlinkClub/49bc8dc56e7e26b719c5fa4d1a46a623b6e0e3f8/Flink 1.14 前言预览/img/1.png -------------------------------------------------------------------------------- /Flink 1.14 前言预览/img/10.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/czy006/FlinkClub/49bc8dc56e7e26b719c5fa4d1a46a623b6e0e3f8/Flink 1.14 前言预览/img/10.png -------------------------------------------------------------------------------- /Flink 1.14 前言预览/img/11.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/czy006/FlinkClub/49bc8dc56e7e26b719c5fa4d1a46a623b6e0e3f8/Flink 1.14 前言预览/img/11.png -------------------------------------------------------------------------------- /Flink 1.14 前言预览/img/12.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/czy006/FlinkClub/49bc8dc56e7e26b719c5fa4d1a46a623b6e0e3f8/Flink 1.14 前言预览/img/12.png -------------------------------------------------------------------------------- /Flink 1.14 前言预览/img/13.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/czy006/FlinkClub/49bc8dc56e7e26b719c5fa4d1a46a623b6e0e3f8/Flink 1.14 前言预览/img/13.png -------------------------------------------------------------------------------- /Flink 1.14 前言预览/img/14.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/czy006/FlinkClub/49bc8dc56e7e26b719c5fa4d1a46a623b6e0e3f8/Flink 1.14 前言预览/img/14.png -------------------------------------------------------------------------------- /Flink 1.14 前言预览/img/2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/czy006/FlinkClub/49bc8dc56e7e26b719c5fa4d1a46a623b6e0e3f8/Flink 1.14 前言预览/img/2.png -------------------------------------------------------------------------------- /Flink 1.14 前言预览/img/3.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/czy006/FlinkClub/49bc8dc56e7e26b719c5fa4d1a46a623b6e0e3f8/Flink 1.14 前言预览/img/3.png -------------------------------------------------------------------------------- /Flink 1.14 前言预览/img/4.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/czy006/FlinkClub/49bc8dc56e7e26b719c5fa4d1a46a623b6e0e3f8/Flink 1.14 前言预览/img/4.png -------------------------------------------------------------------------------- /Flink 1.14 前言预览/img/5.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/czy006/FlinkClub/49bc8dc56e7e26b719c5fa4d1a46a623b6e0e3f8/Flink 1.14 前言预览/img/5.png -------------------------------------------------------------------------------- /Flink 1.14 前言预览/img/6.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/czy006/FlinkClub/49bc8dc56e7e26b719c5fa4d1a46a623b6e0e3f8/Flink 1.14 前言预览/img/6.png -------------------------------------------------------------------------------- /Flink 1.14 前言预览/img/7.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/czy006/FlinkClub/49bc8dc56e7e26b719c5fa4d1a46a623b6e0e3f8/Flink 1.14 前言预览/img/7.png -------------------------------------------------------------------------------- /Flink 1.14 前言预览/img/8.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/czy006/FlinkClub/49bc8dc56e7e26b719c5fa4d1a46a623b6e0e3f8/Flink 1.14 前言预览/img/8.png -------------------------------------------------------------------------------- /Flink 1.14 前言预览/img/9.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/czy006/FlinkClub/49bc8dc56e7e26b719c5fa4d1a46a623b6e0e3f8/Flink 1.14 前言预览/img/9.png -------------------------------------------------------------------------------- /Flink CDC 2.0/Flink CDC 2.0 详解.md: -------------------------------------------------------------------------------- 1 | 文章介绍：如何将数据库中的数据接入数据仓库/数据湖是数仓建设需要考虑的关键一环。今天就由来自阿里的徐榜江（雪尽）老师带来的分享Flink-CDC 2.0 设计方案。徐榜江（雪尽）老师就职于阿里巴巴，目前主要担任FlinkSQL的研发工作。今天带来的Flink-CDC 2.0 设计方案，首先先会对CDC进行简单的概述和解决场景描述，相对比于传统数据同步方案，Flink-CDC 数据同步方案的优缺点进行简单概括，同时分析 Flink-CDC 架构的优势详细解读无锁设计和全量阶段并发设计以及CDC后续的一些规划本次分享 2 | 3 | 4 | 5 | 作者：徐榜江（雪尽）（Apache Flink Contributor，阿里巴巴高级开发工程师） 6 | 7 | 整理：陈政羽（Apache Flink China 社区志愿者） 8 | 9 | 10 | # CDC概述 11 | 12 | CDC 的全称是 Change Data Capture ，在广义的概念上，只要能捕获数据变更的技术，我们都可以称为 CDC 。我们目前通常描述的CDC 技术主要面向数据库的变更，是一种用于捕获数据库中数据变更的技术。CDC 技术应用场景非常广泛： 13 | 14 | - 数据同步，用于备份，容灾 15 | - 数据分发，一个数据源分发给多个下游系统 16 | - 数据采集，面向数据仓库/数据湖的 ETL 数据集成，是非常重要的数据源 17 | 18 | CDC的技术方案非常多，目前业界主流的实现机制的可以分为两种： 19 | 20 | 基于查询的 CDC 21 | 22 | - 离线调度查询作业，批处理。把一张表同步到其他系统，每次通过查询去获取查询的结果 23 | 24 | - 无法保障数据一致性，查的过程中有可能数据已经发生了多次变更 25 | 26 | - 不保障实时性，基于离线调度有查询延迟 27 | 28 | 基于日志的 CDC 29 | 30 | - 实时消费日志，流处理，例如MYSQL的BINLOG完整记录库里面的变更，可以把BINLOG当作流的数据源 31 | - 保障数据一致性，因为BINLOG所有的历史明细都可以获得 32 | - 提供实时数据，因为提供是流式的消费方式，所以实时性有爆炸 33 | 34 | **常用开源CDC比较** 35 | 36 | ## ![Compare-cdc](./img/Compare-cdc.png) 37 | 38 | 通过图上对比我们可以看到，对于日志查询的方式，增量同步都可以做到，但是基于查询的同步是无法做到增量同步的；在断点续传中，我们的任务有可能消费数据到某个时刻点上面因为各种原因而中断导致任务失败，后面恢复作业的时候我们需要基于这个位移点进行恢复的一个功能。在日志同步功能上；在全量同步上，基于查询或者日志都可以做到，例如MYSQL可以把BINLOG进行重放或者直接整库同步，但是Canal没有做全量支持；在全量+增量的模式上，Flink CDC、Debezium、Oracle Goldengate都支持；在架构角度去看，可以分为单机和分布式，分布式我们不单纯表现在水平扩展上面，在大数据场景会影响比较大，例如我们的数据需要入湖或者入仓，我们的文件系统例如HDFS是分布式架构，在对接上面是否能有比较好的支持，从这个角度上面上看Flink CDC 会支持比较好；数据转换方面，当我们数据进入到CDC 工具时候是否能比较方便的对数据做一些过滤或者清洗，在Flink CDC 上面会比较简单操作，可以通过Flink SQL 去操作这些数据，但是例如像DataX、Debezium需要通过脚本或者模板去做，所以用户在使用的门槛会比较高；生态方面指的是下游的一些数据库或者数据源支持，例如像Flink CDC 下游有丰富的Connector，像写入到TiDB、MySQL、HBase、Kafka等常见的一些组件。 39 | 40 | # Flink CDC 项目 41 | 42 | 先来回顾2个基础概念：Dynamic Table 和 Change Log Stream 43 | 44 | ![fcs_1](./img/fcs_1.png) 45 | 46 | ![fcs_2](./img/fcs_2.png) 47 | 48 | Dynamic Table 就是 Flink 内部定义的表，它是和一条流是等价的，他们两者是可以相互转换的，简单的理解就是：mysql一张表背后其实对应的有binlog，如果你一直对表进行操作更新，binlog也是一直在更新的，相当于数据流和表一直是对应关系的，那么表相当于binlog日志流在某个时刻点物化的结果，那么流就是从这个表一直把这些变更数据进行收集。在Flink中，Change Log Stream 的操作是一一对应的。例如我们表操作从一个算子流向另外一个算子的时候，是以Change Log Stream 的格式发送到下游，当我们数据流向下游时候，都是可以和一张表一一对应，我们可以翻译为一个表，也可以翻译为一个流。 49 | 50 | ![debezium_to_cdc](./img/debezium_to_cdc.png) 51 | 52 | Flink CDC 选择一个底层CDC工具，我们选择了debezium，我们可以做全量+增量的cdc 会比较灵活；RowData 代表了一行的数据，在 RowData 上面会有一个元数据的信息 RowKind，RowKind对应了4种类型进行一一映射 RowKind 里面包括了插入 (INSERT)、更新前 (UPDATE_BEFORE)、更新后 (UPDATE_AFTER)、删除 (DELETE)，这样和数据库里面的 binlog 概念十分类似。通过 Debezium 采集的数据，包含了旧数据 (before)和新数据行 (after) 以及原数据信息 (source)，op 的 u 表示是 update 更新操作标识符（op 字段的值 c，u，d，r 分别对应 create，update，delete，reade），同时还包含一些其他元数据，例如ts_ms 表示同步的时间戳。 53 | 54 | ## 传统CDC ETL 分析 55 | 56 | 传统CDC的ETL链路（如下图）可以看到，首先我们必须要有数据采集工具参与，例如国外常用的Debezium，国内常用阿里的Cannal去采集数据库的BINLOG，我们采集到的数据一般输出到消息中间件例如Kafka，然后Flink计算引擎再去消费这一部分数据写入到目的端，例如写入到数据湖或者离线数据仓库 57 | 58 | ![cdc_4_1](./img/cdc_4_1.png) 59 | 60 | 其实我们一直思考是否可以使用Flink CDC去替换前面这2个虚线框内比较大的组件，简化用户的维护成本和使用成本，对于用户而言功能没发生变化，数据传输链路的减少意味着数据时效性的提高。于是就有我们基于Flink CDC 的数据分析流程 61 | 62 | ## 基于Flink CDC ETL 分析 63 | 64 | 我们使用了Flink CDC 之后，大大降低用户的使用门槛，我们可以看看下面的DEMO 65 | 66 | ![cdc_etl_sql](./img/cdc_etl_sql.png) 67 | 68 | 可以看到我们通过Flink SQL去采集数据写入到TiDB，创建了CDC的产品表和订单表，然后对数据流进行JOIN直接写入到下游数据库，一个SQL就完成了CDC的数据同步。完全的纯SQL实现，使用BI的业务方都可以上手，与此同时可以使用Flink SQL 算子进行清洗、分析、聚合。但是如果是传统的CDC需要进行数据计算转换清洗是比较困难的 69 | 70 | ![cdc_5_1](./img/cdc_5_1.png) 71 | 72 | 与此同时我们可以通过双流JOIN、维表JOIN、写一些UDTF去实现一些业务方的功能 73 | 74 | ![cdc_5_2](./img/cdc_5_2.png) 75 | 76 | ## Flink CDC 里程碑 77 | 78 | 2020.07月由云邪第一次提交，是由于个人项目的爱好提交了的第一个commit 79 | 80 | 2020.07中旬开始支持MySQL-CDC 81 | 82 | 2020.07末开始支持postgres-cdc 83 | 84 | 2021.02至今持续发布了多个版本，目前最新版本是1.4.0 85 | 86 | ![cdc_6](/Users/chenzhengyu/Documents/Flink中文社区翻译稿/Flink CDC 2.0/img/cdc_6.png) 87 | 88 | 项目地址 ：https://github.com/ververica/flink-cdc-connectors 89 | 90 | # Flink CDC 2.0 详解 91 | 92 | ## Flink CDC 痛点 93 | 94 | 基于目前版本Flink CDC ，我们通过整理社区的一些反馈，我们可以看到用户普遍有以下痛点： 95 | 96 | - 全量+增量同步的过程需要保证所有数据的一致性，因此需要通过加锁保证，但是加锁在数据库层面上是一个十分高危的操作。底层Debezium 在保证数据一致性时，需要对读取的库或表加锁，全局锁可能导致数据库锁住，表级锁会锁住表的读 ，DBA 一般不给锁权限。 97 | - 不支持水平扩展，因为Flink CDC 早期基于Debezium，架构只有1个节点，所以导致了只支持单并发。在全量阶段读取阶段，如果表非常大(亿级别)， 读取时间都在小时级别，对于用户而言，期望能够通过水平资源扩展增加资源去提升作业速度。 98 | - 全量读取阶段不支持 checkpoint：CDC 读取分为两个阶段，全量读取和 增量读取， 目前全量读取阶段是不支持 checkpoint 的，这个就会存在一个问题，当我们同步数据假设需要5个小时，当我们同步了4小时时候作业失败，这时候就需要重新读取数据。 99 | 100 | ## Debezium 锁分析 101 | 102 | Flink CDC 底层封装了 Debezium， Debezium 同步一张表分为两个阶段： 103 | 104 | - 全量阶段：查询当前表中所有记录 105 | - 增量阶段：从 binlog 消费变更数据 106 | 107 | 大部分用户使用的场景都是全量+增量同步，加锁是发生在全量阶段，目的是为了确定全量阶段的初始位点，保证增量 + 全量实现一条不多，一条不少，保证数据一致性。在我们Flink CDC 上面默认使用无锁模式，能够满足大部分场景。从图中我们可以分析全局锁和表锁的一些加锁流程，左边红色线条是锁的生命周期，右面是MySQL开启可重复读事务的生命周期。 108 | 109 | ![debezium_lock](./img/debezium_lock.png) 110 | 111 | 112 | 113 | 以全局锁为例，首先是获取一个锁，然后再去开启可重复读的事务。这里锁的操作是把当前BINLOG的位置和表的SCEMA读取出来之后，才可以释放一个全局锁。这样做的目的保证你读取的 SCEMA是不变的，获取到你读取一瞬间的表结构。因为后续你有可能对列进行一些操作，例如删除列或者增加列，要保证把这2个正确读取出来之后然后去读取扫描数据，当我们Flink 启动BINLOG Reader 时候是从这个位移点开始读，保证全量数据 + 增量数据的准确性。 114 | 115 | 表锁是全局锁的阉割版，因为全局锁的权限会比较高，因此部分DBA会允许你使用表锁。表锁锁的时间会更长，因为表锁有个特征：锁提前释放了可重复读的事务默认会提交，这样就会到第六步，全量扫描数据库的表数据，只有全量扫描完成后才能释放锁。 116 | 117 | 经过上面分析，我们接下来来看看这些锁到底会造成什么样严重的后果 118 | 119 | 我们通常申请加锁的命令如下 ： 120 | 121 | `FLUSH TABLES WITH READ LOCK` 122 | 123 | 这条命令需要等待所有正在进行的 update 完成，同时阻止所有新来的 update。与此同时该命令执行成功前必须等待所有正在运行的 select 完成，所以导致了等待执行的 update 会等待的更久。更坏的情况是，当我们申请去加锁的时候，刚刚好有一个慢查询的存在，我们就需要等待这个慢查询完成，这个查询的时间是不固定的，有可能几分钟也有可能几十分钟，这个申请加锁就需要一直等待这么长时间了，除非你有设置TimeOut时间，但是在等的期间，有新的SELECT会给挂起，导致无法查询，这样对于业务方来说就是一种灾难。这样导致了数据库实际上处于不可用状态，即使是新加入的 SELECT 也会被阻止。这是 MySQL Query Cache 机制。 124 | 125 | **结论：加锁时间是不确定的，极端情况会锁住数据库导致业务方无法正常访问业务** 126 | 127 | ## Flink CDC 2.0 设计 128 | 129 | 通过上面的分析，我们可以知道我们的设计方案，首先要支持无锁，支持水平扩展，支持checkpoint。我们通过基于 FLINK FLIP-27 Source 实现 使得架构更加优雅，与此同时我们为了无锁操作，借鉴了Netflix的 DBlog paper 设计，DBlog paper是它的一个内部数据同步平台，他通过无锁算法来解决加锁问题，下面就给大家介绍一下这个算法。 130 | 131 | ## 无锁算法 132 | 133 | Chunk筛选的算法如下图 134 | 135 | ![unlock_1](./img/unlock_1.png) 136 | 137 | 138 | 139 | 读chunk，当我们划分了chunk后存在全量部分和增量部分，要保证如何把这2个chunk进行一致性的合并，原理如下图 140 | 141 | ![unlock_2](./img/unlock_2.png) 142 | 143 | 144 | 145 | chunk的切分其实和很多数据库的分库分表原理类似，一张表有pk我们可以按照pk对数据进行分片。如下图所示，假设我们每个分片的chunk大小区间为10，然后我们按照这个规则进行切分，我们只需要把这些chunk的区间做成左开右闭或者左闭右开的区间，只要能保证衔接上，保证chunk读取一致性，从而保障整张表数据结构的一致性。 146 | 147 | ![chunk_cut](./img/chunk_cut.png) 148 | 149 | chunk读取方面，针对Flink做了一些改进。Netflix 的 DBlog paper 实现方式是通过在DB维护一张信号表，在BINLOG上面进行打点，对其做Low Position（低位点） 和 High Position （高位点）的标记，在低位点和高位点之间去查询chunk的数据，读取出这一部分chunk数据之后，再去统计这2个位点之间有哪些BINLOG，只有这些BINLOG有在这个区间上面就会和存量的数据进行一个合并。结合Flink的实际需求，我们需要做全量+增量数据的同步。 150 | 151 | 如下图所示，假设现在数据就是chunk-1，那么chunk是从K1 - K10，直接在这个区间select出来存在window buffer，在select之前保存了一个低位点，select之后保存了一个高位点。消费binlog时候，在图中的-（k2,100）+ （k2,108）表示这条数据从100更新到108，第二条是删除k3，然后继续更新k2为119，第三个是k5数据由原来的77变更为100。我们观察右下角的图片，我们发现出现的key是k3 k5，我们前往window buffer进行标记，对于k1，k4，k6，k7在高位点读取完毕之后，从来没有发生过变化的数据可以直接输出的，对于发送改变过的数据需要保留数据的最终结果，例如k2 最终的结果是119 ，那么我们只需要这个结果，而不需要中间发生过108改变的数据，从而保证全量+增量数据同步的一致性。 152 | 153 | ![chunk_read](./img//chunk_read.png) 154 | 155 | 上图保证的是单个chunk的一致性读，但是我们如果有多个表分了很多不同的chunk，这些chunk都分布在不同的地方，那如何保证一致性读呢？我们接下来看看如何基于FLIP-27去实现（如下图）。我们可以看到有SourceEnumerator的组件，这个组件主要用于chunk的划分，划分好的Chunk会提供给下游的SourceReader前去读取，把这些数据进行分发从而实现分布式读snapshot chunk的一个过程。 156 | 157 | ![snapshot-chunk](./img/snapshot-chunk.png) 158 | 159 | 当我们读取完成之后，我们需要有一个汇报的流程（如下图），汇报snapshot chunk读取的一些信息 160 | 161 | ![chunk_report](./img/chunk_report.png) 162 | 163 | 汇报的主要目的是为了我们后续读取BINLOG（如下图）。因为我们支持全量+增量同步，当我们所有全量数据读取完成之后，我们只需要消费增量的BINLOG，把这些BINLOG分配给Source Reader 。例如SourceReader-1读取过snapshot-chunk-2 和 snapshot-chunk-3，它已经知道高位点（High-Position）和数据所在的范围（Chunk-Range），基于这些信息可以判断是否为这个chunk的数据以及是在全量读的阶段还是在增量读取的阶段 164 | 165 | ![binlog-chunk ](./img/binlog-chunk .png) 166 | 167 | 下面给大家整理一下整体流程：对于用户而言其实无需过于关注如何切分数据和具体的分片算法，主要是要了解整体的流程。我们通过一个key，有可能是pk或者唯一键值对，我们对这个表进行分片，分片之后分给不同reader去读取数据，先读取全量数据，然后再读取增量数据，在读的过程使用算法进行改进为无锁的结构把之前需要用的的锁给去除掉，这个就是Flink CDC 2.0的一个整体设计 168 | 169 | ![chunk_all](./img/chunk_all.png) 170 | 171 | # 未来规划 172 | 173 | Flink CDC 2.0设计只是出来第一版，所以在稳定性方面后续会通过一些其他公司开源力量加入继续做深度优化；在**Binlog Merging**这个点上面也存在一定的优化空间，目前版本是你启动了多少个并发，就会启动多少个BINLOG Reader。但是我们可以通过优化一个作业只用一个BINLOG Reader，这样的好处就是对于日志CDC技术都是依赖BINLOG，当我们模拟数据比较多的时候有可能对Master（主库）读取的性能产生一定影响，虽然我们现在一般使用从库，但是我们在技术实现层面还是尽量把影响降到最低。 174 | 175 | 当我们 Source Reader 对数据读取进行分片的时候，目前方案是一次性全部划分好分片，然后再进行数据读取。这里其实有一个优化点，通过**Lazy Assigning** 进行划分。**Lazy Assigning** 意思是我可以先划分一批，而不是一次性进行全部划分。例如有1W个分片，我们可以先划分1K个分片，而不是一次性全部划分，等用户消耗完后再继续划分分片，避免资源的浪费和节约整体的流程时间。 176 | 177 | 在Feature支持上面，我们可以实现 **Schema Evolution** 。这个场景是：当我们一张表在同步到一半或者一定时期时候，突然在表中添加了一个字段，然后我们希望后续同步下游的系统时候能够自动加入这个字段； **Watermark Pushdown **通过CDC 的 BINLOG 获取到 一些心跳信息，这些心跳的信息可以作为一个Watermark ，通过这个心跳信息我们可以知道到这个流当前消费的一些进度；支持META数据，分库分表的场景下面有可能需要元数据知道这条数据来源哪个库哪个表，在下游系统入湖入仓上面可以有更多的灵活操作；整库同步：用户的整库同步可以让用户使用Flink CDC更加简便快捷 178 | 179 | 在生态集成上面我们可以**集成更多 DB 和 Format** 以便用户使用；在入湖层面Hudi和Iceberg写入上面有一定的优化空间，例如在高QPS入湖时候数据分布有比较大的性能影响，这一点是可以通过和生态打通和集成继续优化。 180 | 181 | # 总结 182 | 183 | 今天雪尽老师首先给大家简单的介绍了一下什么是CDC，然后对比目前市面上开源的数据同步工具，对比出它们的优点和缺点，以及目前Flink CDC 如何简化数据同步流程，给用户带来更加丝滑的体验，与此同时，针对目前架构存在的锁问题，通过无锁算法和Flink CDC FLIP 27 进行水平扩展的实现，从而打造出Flink CDC 2.0架构，总结出方案实现的流程和细节，最后给我们带来了CDC2.0之后未来的一些规划，包括入库性能提升、生态集成等多方面进行提升 184 | 185 | # 附录 186 | 187 | [[1] Flink-CDC-Connector Github](https://github.com/ververica/flink-cdc-connectors) 188 | [[2] Percona - 深入分析了加锁流程](https://www.percona.com/blog/2014/03/11/introducing-backup-locks-percona-server-2/) 189 | [[3] 无锁并发设计pdf](https://arxiv.org/pdf/2010.12597v1.pdf) 190 | [[4] Flink FLIP 27](https://cwiki.apache.org/confluence/display/FLINK/FLIP-27%3A+Refactor+Source+Interface) 191 | -------------------------------------------------------------------------------- /Flink CDC 2.0/img/Compare-cdc.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/czy006/FlinkClub/49bc8dc56e7e26b719c5fa4d1a46a623b6e0e3f8/Flink CDC 2.0/img/Compare-cdc.png -------------------------------------------------------------------------------- /Flink CDC 2.0/img/QQ20210725-103535@2x.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/czy006/FlinkClub/49bc8dc56e7e26b719c5fa4d1a46a623b6e0e3f8/Flink CDC 2.0/img/QQ20210725-103535@2x.png -------------------------------------------------------------------------------- /Flink CDC 2.0/img/binlog-chunk .png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/czy006/FlinkClub/49bc8dc56e7e26b719c5fa4d1a46a623b6e0e3f8/Flink CDC 2.0/img/binlog-chunk .png -------------------------------------------------------------------------------- /Flink CDC 2.0/img/cdc_1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/czy006/FlinkClub/49bc8dc56e7e26b719c5fa4d1a46a623b6e0e3f8/Flink CDC 2.0/img/cdc_1.png -------------------------------------------------------------------------------- /Flink CDC 2.0/img/cdc_2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/czy006/FlinkClub/49bc8dc56e7e26b719c5fa4d1a46a623b6e0e3f8/Flink CDC 2.0/img/cdc_2.png -------------------------------------------------------------------------------- /Flink CDC 2.0/img/cdc_3.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/czy006/FlinkClub/49bc8dc56e7e26b719c5fa4d1a46a623b6e0e3f8/Flink CDC 2.0/img/cdc_3.png -------------------------------------------------------------------------------- /Flink CDC 2.0/img/cdc_4.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/czy006/FlinkClub/49bc8dc56e7e26b719c5fa4d1a46a623b6e0e3f8/Flink CDC 2.0/img/cdc_4.png -------------------------------------------------------------------------------- /Flink CDC 2.0/img/cdc_4_1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/czy006/FlinkClub/49bc8dc56e7e26b719c5fa4d1a46a623b6e0e3f8/Flink CDC 2.0/img/cdc_4_1.png -------------------------------------------------------------------------------- /Flink CDC 2.0/img/cdc_5.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/czy006/FlinkClub/49bc8dc56e7e26b719c5fa4d1a46a623b6e0e3f8/Flink CDC 2.0/img/cdc_5.png -------------------------------------------------------------------------------- /Flink CDC 2.0/img/cdc_5_1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/czy006/FlinkClub/49bc8dc56e7e26b719c5fa4d1a46a623b6e0e3f8/Flink CDC 2.0/img/cdc_5_1.png -------------------------------------------------------------------------------- /Flink CDC 2.0/img/cdc_5_2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/czy006/FlinkClub/49bc8dc56e7e26b719c5fa4d1a46a623b6e0e3f8/Flink CDC 2.0/img/cdc_5_2.png -------------------------------------------------------------------------------- /Flink CDC 2.0/img/cdc_6.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/czy006/FlinkClub/49bc8dc56e7e26b719c5fa4d1a46a623b6e0e3f8/Flink CDC 2.0/img/cdc_6.png -------------------------------------------------------------------------------- /Flink CDC 2.0/img/cdc_etl_sql.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/czy006/FlinkClub/49bc8dc56e7e26b719c5fa4d1a46a623b6e0e3f8/Flink CDC 2.0/img/cdc_etl_sql.png -------------------------------------------------------------------------------- /Flink CDC 2.0/img/chunk_all.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/czy006/FlinkClub/49bc8dc56e7e26b719c5fa4d1a46a623b6e0e3f8/Flink CDC 2.0/img/chunk_all.png -------------------------------------------------------------------------------- /Flink CDC 2.0/img/chunk_cut.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/czy006/FlinkClub/49bc8dc56e7e26b719c5fa4d1a46a623b6e0e3f8/Flink CDC 2.0/img/chunk_cut.png -------------------------------------------------------------------------------- /Flink CDC 2.0/img/chunk_read.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/czy006/FlinkClub/49bc8dc56e7e26b719c5fa4d1a46a623b6e0e3f8/Flink CDC 2.0/img/chunk_read.png -------------------------------------------------------------------------------- /Flink CDC 2.0/img/chunk_report.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/czy006/FlinkClub/49bc8dc56e7e26b719c5fa4d1a46a623b6e0e3f8/Flink CDC 2.0/img/chunk_report.png -------------------------------------------------------------------------------- /Flink CDC 2.0/img/debezium_lock.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/czy006/FlinkClub/49bc8dc56e7e26b719c5fa4d1a46a623b6e0e3f8/Flink CDC 2.0/img/debezium_lock.png -------------------------------------------------------------------------------- /Flink CDC 2.0/img/debezium_to_cdc.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/czy006/FlinkClub/49bc8dc56e7e26b719c5fa4d1a46a623b6e0e3f8/Flink CDC 2.0/img/debezium_to_cdc.png -------------------------------------------------------------------------------- /Flink CDC 2.0/img/fcs_1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/czy006/FlinkClub/49bc8dc56e7e26b719c5fa4d1a46a623b6e0e3f8/Flink CDC 2.0/img/fcs_1.png -------------------------------------------------------------------------------- /Flink CDC 2.0/img/fcs_2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/czy006/FlinkClub/49bc8dc56e7e26b719c5fa4d1a46a623b6e0e3f8/Flink CDC 2.0/img/fcs_2.png -------------------------------------------------------------------------------- /Flink CDC 2.0/img/snapshot-chunk.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/czy006/FlinkClub/49bc8dc56e7e26b719c5fa4d1a46a623b6e0e3f8/Flink CDC 2.0/img/snapshot-chunk.png -------------------------------------------------------------------------------- /Flink CDC 2.0/img/unlock_1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/czy006/FlinkClub/49bc8dc56e7e26b719c5fa4d1a46a623b6e0e3f8/Flink CDC 2.0/img/unlock_1.png -------------------------------------------------------------------------------- /Flink CDC 2.0/img/unlock_2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/czy006/FlinkClub/49bc8dc56e7e26b719c5fa4d1a46a623b6e0e3f8/Flink CDC 2.0/img/unlock_2.png -------------------------------------------------------------------------------- /Flink CDC In HuoLaLa/Apache Flink CDC 在货拉拉实践与应用 （共享）.pptx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/czy006/FlinkClub/49bc8dc56e7e26b719c5fa4d1a46a623b6e0e3f8/Flink CDC In HuoLaLa/Apache Flink CDC 在货拉拉实践与应用 （共享）.pptx -------------------------------------------------------------------------------- /Flink CDC In HuoLaLa/Yu Chen Zheng.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/czy006/FlinkClub/49bc8dc56e7e26b719c5fa4d1a46a623b6e0e3f8/Flink CDC In HuoLaLa/Yu Chen Zheng.jpg -------------------------------------------------------------------------------- /Flink Forward Asia 2024/Flink CDC与Amoro融合入湖新体验.pptx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/czy006/FlinkClub/49bc8dc56e7e26b719c5fa4d1a46a623b6e0e3f8/Flink Forward Asia 2024/Flink CDC与Amoro融合入湖新体验.pptx -------------------------------------------------------------------------------- /Flink K8S Operator AutoScaling/ASF2023-流计算-Flink-K8S-Operator-AutoScaling自动调优.pptx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/czy006/FlinkClub/49bc8dc56e7e26b719c5fa4d1a46a623b6e0e3f8/Flink K8S Operator AutoScaling/ASF2023-流计算-Flink-K8S-Operator-AutoScaling自动调优.pptx -------------------------------------------------------------------------------- /Flink中文开源社区一些感悟/Flink开源中文社区感悟.md: -------------------------------------------------------------------------------- 1 | # 个人介绍 2 | 3 | 主要做一些个人介绍 + 历史以往翻译文章介绍 4 | 5 | 6 | 7 | 各位 Flink 社区的伙伴大家好，我是来自 Apache Flink 中文社区的志愿者陈政羽，负责社区日常技术文章稿的翻译和产出。平时的爱好是钻研技术、健身和旅游，目前正在真有趣科技研究中心 - 基础设施研发部，负责基于 K8S 的 Flink 大数据部署作业平台构建与作业研发，为真有趣构建部署、提交作业的一站式 Flink 智能作业平台和、SQL 平台和反外挂平台，欢迎大家多多交流。 8 | 9 | # 我与中文社区的成长 10 | 11 | 在中文社区带给我在开源的影响和工作的影响，以及社区成长之路的介绍 12 | 13 | 14 | 15 | 大家在社区看到的很多文章都有我参与的身影，例如《Flink 1.14 新特性预览》、《 Flink CDC 2.0》、《深入解读 Flink SQL 1.13》、《Flink 1.12 资源管理新特性》 等都是经过我翻译视频稿和技术原稿，然后带给大家的。我想把这一年在 Flink 中文开源社区的工作和对于一些开源问题的思考分享给各位，希望能给各位在开源上带来新的启发。 16 | 17 | 18 | 19 | 作为 Flink 中文社区早期入坑的志愿者，我还记得我第一篇翻译的文章是《Flink JDBC Connector：Flink与数据库的最佳实践》，徐榜江老师生动的案例和演讲正式带我进入了流式计算的世界。事后我在钉钉中文社区大群看到刚好招聘志愿者翻译这个演讲，于是我就自告奋勇的联系上报名了，其实我是第一次做这样的工作，并没有相关的开源经验，所以也是怀着忐忑和不安的心情去完成的。 20 | 21 | 22 | 23 | 首先我能想到的是，这篇文章的产出是给哪些群体看的？因为我们发布文章是给用户看的，而不是写给自己看的，明确了用户群体才能更好的服务对象。于是我询问了相关工作人员文章会发布到哪里，给我的回答是发布到微信公众号 (主要)，各大论坛和阿里云的开发者专栏。这样从中可以了解到：用户群体大部分是不希望花太多时间去回顾线上视频，而是利用碎片时间去了解并学习有关资讯的。所以我在做文章的时候需要去抓住这个用户核心关注点去描述这个事情。 24 | 25 | 26 | 27 | 明确了服务对象后，我决定再复盘一次视频，仔细抓住每个细节，其实这个动作现在回过头来看也是非常重要的一点。通常第一次看的时候，可能会知道个大概流程，但总会有一些细节从身边划过而没注意。看到老师们演示的很流畅，那是因为老师们已经对这个东西理解比较透彻了。第二次看的时候，配合后面自己实际动手才会发现里面的一些坑。我们在编写文章的时候，也可以顺手把这些坑提醒给用户，以链接的方式放到文章的末，当用户遇到问题了，可以快速参考定位到解决问题的办法。 28 | 29 | 30 | 31 | 但是其实我知道这样是远远不够的，演讲视频或者演讲稿文章的发布，往往都是伴随一些专业名称或者名词，但是对于一些刚刚入门了解 Flink 的用户群体是不友好的，如何把专业名词或者一些抽象概念转化为文章，使用户通俗易懂，也是一件很重要的事情。我会根据文章实际情况去转换这些专业名词，例如在一些版本发布或者重要特性上面，这种需要比较严谨的描述，专业名词会用的比较多；对于实践类的文章，使用一些口语化或者图形化的一些描述，会让用户更加容易了解其运行流程。于此同时，我也会将每次发布的一些文章整理到自己的 github 仓库，方便用户自己进行一些创造或者对认为有歧义的地方提出改进建议。 32 | 33 | 34 | 35 | 通过上面的一些分享，相信大家对 Flink 中文社区志愿者的一些工作流程有了一定的了解。通过志愿者这个工作，也让我对开源有了新的认识和认知。通过开源社区结识了许多志同道合的伙伴去贡献 Flink 周边社区的一些配套基础设施，参与进去开发和讨论，接触各个社区都能体会到 Flink 开发者们的热情。从中我也会逐步思考目前国内的一些开源状况和中文社区开源现状。在 Apache 基金会中，‘社区大于代码’ 是 Apache 之道的核心内容，拥有了社区和用户群体，才能使得这款软件走的更稳、更远。开源社区的项目和公司并不是个人项目和 KPI 项目，是需要各位共同探讨、合作的一个项目，这样才有助于社区的多元性。 36 | 37 | 38 | 39 | 在今年我也尝试迈出了第一步，首先从一个比较小的一个基础功能点参与ISSUSE的讨论，这是关于K8S Operator JM数量的一个实现，我实现的时候，同时也发现了一些问题：我们在设置JobManager时候，如果数量大于1我们没开启高可用导致部署时候失败，我们是否应该在前置流程做一定的校验，拦截这种操作，避免到了实际部署的时候才出现问题，于是我就把问题抛出去希望大家一起讨论 40 | 41 | ![img](./img/1-0.png) 42 | 43 | 从图中可以看到，最后讨论结果是我的建议给采纳了。虽然最后这个ISSUSE不是由我来完成（因为过年期间没有来的及时看邮件，痛失机会~~）。但是从中可以看得出，其他常年活跃在Flink的开发者一直鼓励我提交代码并且给出我一些建议。基于这次体验，我也梳理出社区、开发者、使用者这3者在社区的一个金字塔关系（如下图） 44 | 45 | 46 | 47 | ![img](./img/1-1.png) 48 | 49 | 上图是我自己简单的从开发者，使用者和社区三个角度，自己的理解做了一个图去分析他们彼此的关系。可以看到我是用一个三角形去描述他们之间的关系，三角形是力学里面比较稳定一个结构，这也是为什么埃及金字塔是用三角形建造的原因。三角形的顶端是社区，下面是社区中的不同角色，包括了开发者，使用者，其中同一个人或许会担任不同的角色和不同的身份。开发者和使用者通过社区进行交流、贡献、反馈，中间包含了代码作者，贡献者等等，通过 pr、issuse 提出问题和贡献代码等。各自都在社区扮演不同的多元角色从而组成一个完整的社区生态，缺少其中任意一环可能都会导致这个金字塔发生倾斜。其中，我认为社区之间的讨论正是让所有人连接起来的桥梁，例如像下图的朋友咨询了一些问题，总会有热心的开发者来解答他的疑问，当下次有人遇到同样的问题时候，他也能反馈给其他人。 50 | 51 | 52 | 53 | ![img](./img/1-2.png) 54 | 55 | 56 | 57 | 现在目前大部分问题汇总其实都在 Flink 官方的 issuse 或前往订阅 **user@flink.apache.org** 或者 **user-zh@flink.apache.org** 的邮件列表，但是中文社区没有一个沉淀问题的地方，大部分是在钉钉群、微信群里面讨论 (如图上所示)，可能解决了某些技术性的问题，但一不留神就会被其他的消息刷过去。其实我们可以借助中文社区网站，开设一个问题板块，用户可以比较自由的探讨一些问题。按照标签进行归类，例如咨询类、招聘类等；技术类的可以引导用户前往 apache 的中文 list 或者英文 list 进行讨论沉淀，这样有助于提高用户解决不同类型的问题体验，也可以对这部分内容进行一个沉淀，提供给用户进行检索，快速解决问题。 58 | 59 | 60 | 61 | 社区探讨完后，我们回过头来看看目前国家对待开源是如何定义的。从目前来看，国家对待开源也是持有积极的态度，在国家的十四五纲领就明确指出开源在新时代赋予的新意义。从纲要里提到的 “支持数字技术开源社区等创新联合体发展，完善开源知识产权和法律体系，鼓励企业开放软件源代码、硬件设计和应用服务”，可以看出国家在战略层面对于「开源」的肯定和支持。 62 | 63 | 64 | 65 | ![img](./img/1-3.png) 66 | 67 | 68 | 69 | 放眼国内，2020 和 2021 都是大放异彩的一年，从阿里巴巴收购 Flink 母公司、贡献 Blink 和 Flink 相关特性、国内的开放原子开源基金会挂牌成立、开源流数据公司 StreamNative 等大事件都是值得大家关注的。在这样一个国家大环境下，“十四五” 在法律层面鼓励企业和个人开源，并从底层基础设施方面进行了规划 — 纲要明确指出应完善开源知识产权和法律体系，这足以说明开源是大势所趋。 70 | 71 | # 个人期望 72 | 73 | 针对一些个人目标 74 | 75 | 76 | 77 | 通过上面的一些分享，相信大家对 Flink 中文社区志愿者的工作和一些开源工作流程、开源社区运转、国家对开源态度等各方面都有了大概了解了，后续也欢迎各位加入 Flink 社区一起共建开源社区。其实我从开始参与社区志愿者开始，开源的思想种子就已经在萌芽了，这对于我个人对参与开源社区的影响也是比较深远的，这也促进里我后续进一步去了解开源社区，例如 Apache 基金会的运作，开源的各种协议规则，以及参与到类似 Flink 周边生态的一些项目开发。Apache Flink 中文社区今年也规划今年开始，让志愿者更深入的参与到社区来，而不仅仅是整理文章，未来可能还包括参与开发，线下活动组织等，让大家更加深入了解社区运作和参与进来。我也非常感谢2021年社区对我工作的认可，并且评选为社区优秀贡献者。 78 | 79 | 80 | 81 | 期望在今年，我能在 Flink 中文社区给大家带来更多优质的内容和产出，于此同时在围绕 Flink 周边开源生态软件有更多活跃贡献的表现，与此同时也期望今年能把我在游戏行业实际生产经验通过一些线下活动会议，也欢迎各位大家持续关注Apache Flink 中文社区网站 和 阿里云开发者社区，了解最新的Flink动态。 82 | 83 | 84 | 85 | **参考链接** 86 | 87 | - [0] Apache Flink中文社区：https://flink-learning.org.cn 88 | - [1] 社区志愿稿：https://github.com/czy006/FlinkClub -------------------------------------------------------------------------------- /Flink中文开源社区一些感悟/img/1-0.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/czy006/FlinkClub/49bc8dc56e7e26b719c5fa4d1a46a623b6e0e3f8/Flink中文开源社区一些感悟/img/1-0.png -------------------------------------------------------------------------------- /Flink中文开源社区一些感悟/img/1-1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/czy006/FlinkClub/49bc8dc56e7e26b719c5fa4d1a46a623b6e0e3f8/Flink中文开源社区一些感悟/img/1-1.png -------------------------------------------------------------------------------- /Flink中文开源社区一些感悟/img/1-2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/czy006/FlinkClub/49bc8dc56e7e26b719c5fa4d1a46a623b6e0e3f8/Flink中文开源社区一些感悟/img/1-2.png -------------------------------------------------------------------------------- /Flink中文开源社区一些感悟/img/1-3.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/czy006/FlinkClub/49bc8dc56e7e26b719c5fa4d1a46a623b6e0e3f8/Flink中文开源社区一些感悟/img/1-3.png -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # FlinkClub 2 | 这是我自己的Flink中文社区翻译稿存储仓库以及部分Flink文章资源，用于提供给需要朋友进行二次创作，转载和二次创作请著名Flink中文社区，谢谢Thanks♪(･ω･)ﾉ 3 | 如果觉得对你有帮助点击右上角的Start⭐和关注社区个人公众号️，你的支持是我前进动力~~~ （公众号目前改版中，内容较少，不会推送任何广告，纯技术， 4 | 放心关注） 5 | 6 | - [博客在线阅读入口](https://czy006.github.io) 7 | 8 | # 个人简介 9 | 10 | - Apache Amoro PPMC 11 | - Apache Flink Contributor 12 | - Apache StreamPark Contributor 13 | 14 | 各位好，我是来自 **Apache Flink** 社区志愿者 ConradJam， 主要负责基于 K8S 的 Flink 大数据部署作业平台构建与作业研发等大数据周边相关工作 15 | 智能作业平台和 SQL 平台，目前负责湖仓一体，实时计算等相关工作 16 | 17 | 欢迎关注 **Flink中文社区** 和 **开源之韵（asf_garden）** 了解更多一线Flink资讯 18 | 公众号属于佛系发布技术文章和开源心得 19 | 20 | flink-china 21 | 22 | # 最新消息 23 | 24 | 关注 **FFA 2023**，获取当前最前前沿的Flink云原生技术 25 | - [FFA大会入口](https://flink-forward.org.cn) 26 | 27 | 关注 **Apache 2023 亚洲峰会**，了解Flink自动调优和其他前沿计算机技术 28 | - [Apache Asia 2023](https://apachecon.com/acasia2023/zh/tracks.html) 29 | 30 | 关注 **开源社-第七届开全球源峰会**，获取当前最前Flink K8S Operator 1.2版本中相关动态信息 31 | - [直播&回放入口](https://mp.weixin.qq.com/s/76ekZAfVs320GQ_xbEwwhQ) 32 | 33 | 关注 **CSDN-云原生峰会-Flink专场**，获取当前最前Flink云原生技术，由我演讲的Flink K8S Operator 相关资料已在仓库中 34 | - [直播&回放入口](https://marketing.csdn.net/p/3babe71e2d4612a3092862aacf0f83ab) 35 | 36 | ## Flink Operator 37 | - [FLINK K8S OPERATOR AUTOSCALING](https://apachecon.com/acasia2023/zh/sessions/streaming-1086.html) 38 | 39 | ## Flink特性 40 | 41 | - [Flink1.14 前言预览](https://mp.weixin.qq.com/s/BnpB1JWqRzdQDHlqg9dVmA) 42 | - [深入解读 Flink SQL 1.13](https://mp.weixin.qq.com/s/KaWJ99oGn3WJysfc5OcmTA) 43 | - [Flink 1.12 资源管理新特性](https://mp.weixin.qq.com/s/GPx2UpLIu3ESMmb12OSIHQ) 44 | - [Flink JDBC Connector：Flink与数据库集成最佳实践](https://mp.weixin.qq.com/s/guHl9hnNgD22sBseiGDZ2g) 45 | 46 | ## Flink CDC 47 | 48 | - [Flink CDC 2.0 设计与优化详解](https://mp.weixin.qq.com/s/No7vIFo1c6PlONIKTsPRNA) 49 | - [基于 Flink CDC 实时数据同步方案](https://mp.weixin.qq.com/s/QNJlacBUlkMT7ksKKSNa5Q) 50 | - [Flink CDC 在货拉拉的落地与实践](https://mp.weixin.qq.com/s/ZSc4ZPKwJQnfr_yDQHLzYg) 51 | - [Flink CDC 与 AMORO 融合入湖新体验](https://mp.weixin.qq.com/s/ZSc4ZPKwJQnfr_yDQHLzYg) 52 | 53 | ## 开源社区心得与体会 54 | - [Flink-2021优秀志愿者评选](https://mp.weixin.qq.com/s/xNdyecqpzBZtBukK04pRiQ) 55 | - [Flink-开源社区志愿者招募](https://mp.weixin.qq.com/s/Meh5pLqJsth9iE2YJTXNwA) 56 | - [开源社 - 百花齐放的开源元年](等待发布) 57 | 58 | 59 | 60 | 61 | 62 | 63 | 64 | -------------------------------------------------------------------------------- /imgs/asf_garden.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/czy006/FlinkClub/49bc8dc56e7e26b719c5fa4d1a46a623b6e0e3f8/imgs/asf_garden.jpg -------------------------------------------------------------------------------- /imgs/flink-china.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/czy006/FlinkClub/49bc8dc56e7e26b719c5fa4d1a46a623b6e0e3f8/imgs/flink-china.png -------------------------------------------------------------------------------- /尚硅谷 Flink 1.13 在线配套资源文档/尚硅谷大数据技术之Flink1.13（Java）.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/czy006/FlinkClub/49bc8dc56e7e26b719c5fa4d1a46a623b6e0e3f8/尚硅谷 Flink 1.13 在线配套资源文档/尚硅谷大数据技术之Flink1.13（Java）.pdf -------------------------------------------------------------------------------- /论文合集/The Dataflow Model- A Practical Approach to Balancing Correctness, Latency, and Cost in Massive-Scale, Unbounded, Out-of-Order Data Processing.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/czy006/FlinkClub/49bc8dc56e7e26b719c5fa4d1a46a623b6e0e3f8/论文合集/The Dataflow Model- A Practical Approach to Balancing Correctness, Latency, and Cost in Massive-Scale, Unbounded, Out-of-Order Data Processing.pdf --------------------------------------------------------------------------------