Flink

前一章咱们对 Flink 进行了总体的介绍。对 Flink 是什么、能做什么、入门 demo、架构等进行了解说。本章咱们将学习 Flink 重点概念、外围个性等。本篇对 Flink 四大基石进行概括介绍，是 Flink 中十分要害的四个内容。 一、四大基石Flink四大基石别离是：Time（工夫）、Window（窗口）、State（状态）、Checkpoint（检查点）。 上面咱们对每个局部，别离进行介绍。 （一）State什么是状态？流计算一直有数据流入，会基于历史数据和以后数据做计算，那么各个算子之中计算后的数据就是状态。 Flink 计算引擎，本身就是基于状态计算框架，默认状况下程序本人治理状态提供一致性的语义，使得用户在编程时可能更轻松、更容易地去治理状态提供一套十分简单明了的State API，包含ValueState、ListState、MapState，BroadcastState （二）Checkpoint什么是 Checkpoint（检查点）？一言以蔽之：用于 Flink 的故障复原。 Checkpoint 会定期生成快照（Snapshot），对以后 State 进行备份。若Flink程序解体，从新运行程序时能够有选择地从这些快照进行复原。Checkpoint是Flink可靠性的基石 原理：应用异步屏障快照 Asynchronous Barrier Snapshotting（简称 ABS）算法（依赖于Chandy-Lamport算法的变种）实现分布式快照。 与之相干的，容易混同的是 savepoint。Savepoint 你能够把它当做在某个工夫点程序状态全局镜像，当前程序在进行降级，或者批改并发度等状况，还能从保留的状态位持续启动复原。 checkpointsavepoint概念主动容错机制程序全局状态镜像目标程序主动容错，疾速复原。程序修改后持续从状态复原，程序降级等。用户交互Flink 零碎行为。用户触发。状态文件保留策略默认程序删除，能够设置 CheckpointConfig 中的参数进行保留。会始终保留，除非用户删除。（三）Window流计算一种典型场景是计算一段时间内的统计值，如最近 5min、最近 1h 的点击量。想实现这个操作，就须要划定一个时间段，也就是开窗，基于这个工夫窗口上的数据做计算。 依据窗口数据划分的不同，目前 Flink 反对如下 3 种： 滚动窗口，窗口数据有固定的大小，窗口中的数据不会叠加；滑动窗口，窗口数据有固定的大小，并且有生成距离；会话窗口，窗口数据没有固定的大小，依据用户传入的参数进行划分，窗口数据无叠加。 （四）Time要进行窗口计算，首先要明确基于的是什么工夫。Flink 中一共提供了三类工夫： 事件工夫（Event Time），即事件理论产生的工夫，这个工夫个别由数据生产方本身携带；摄入工夫（Ingestion Time），事件进入流解决框架的工夫；解决工夫（Processing Time），事件被解决的工夫。 Flink还实现了 Watermark 的机制，可能反对基于事件工夫的解决，可能容忍早退/乱序的数据。这个咱们前面篇章再开展讲。 二、小结本篇对 Flink 四大基石进行了概括性的解说，让大家对 State、Checkpoint、Window、Time 的概念有了初步的认知，前面的篇章将会对四个概念进行粗疏的解说和梳理，并会深刻到源码中探索其实现原理和应用形式。 参考文章：Flink 高级个性（一）-Flink四大基石[Flink:四大基石[Time,Window,Checkpoint,State]_flink的四大基石-CSDN博客](https://blog.csdn.net/weixin_43563705/article/details/107614714)FLINK 四大基石_flink四大基石-CSDN博客

后面几篇文章带大家理解了 Flink 是什么、能做什么，本篇将带大家理解 Flink 到底是如何实现这些的，Flink 自身架构是什么样的，让大家先对 Flink 有整体认知，便于前期了解。 一、Flink 组件栈Flink是一个分层架构的零碎，每一层所蕴含的组件都提供了特定的形象，用来服务于下层组件。Flink分层的组件栈如下图所示： Deployment 层该层次要波及了Flink的部署模式，Flink反对多种部署模式： 本地、集群（Standalone/YARN）云（GCE/EC2）Standalone部署模式与Spark相似。咱们看一下Flink on YARN的部署模式，如下图所示： 通过上图能够看到，YARN AM 与 Flink JobManager 在同一个 Container 中，这样 AM 能够晓得 Flink JobManager 的地址，从而 AM 能够申请 Container 去启动 Flink TaskManager。待 Flink 胜利运行在 YARN 集群上，Flink YARN Client 就能够提交 Flink Job 到 Flink JobManager，并进行后续的映射、调度和计算解决。 Runtime层Runtime 层提供了反对 Flink 计算的全副外围实现，比方： 反对分布式 Stream 解决JobGraph 到 ExecutionGraph 的映射、调度等等，为下层API层提供根底服务。API层API 层次要实现了面向无界 Stream 的流解决和面向 Batch 的批处理 API。其中面向流解决对应 DataStream API，面向批处理对应 DataSet API。 Libraries 层该层也能够称为 Flink 利用框架层，依据 API 层的划分，在 API 层之上构建的满足特定利用的实现计算框架，也别离对应于面向流解决和面向批处理两类。 ...

在 StreamGraph 翻译为 JobGraph 的过程中 Flink 会为每一个算子生成对应的 OperatorID，并传递到 Jobvertex 中。JobVertex 是 JobGraph 中的节点，每个 JobVertex 蕴含一个或多个算子 chain 在一起的算子链。如果 JobVertex 只蕴含一个算子，则 JobVertex 的 id 就是这个算子的 OperatorID，如果 JobVertex 蕴含了多个算子 chain 在一起的算子链，则 JobVertex 的 id 是这个算子链的头部算子的 OperatorID。每个 OperatorID 惟一标识一个算子，Flink 状态复原时也是通过 OperatorID 找到以后节点对应的状态。 入口函数之前提到，OperatorID 是在 StreamGraph 翻译为 JobGraph 的过程中生成的，其入口函数为 StreamingJobGraphGenerator#createJobGraph： // Generate deterministic hashes for the nodes in order to identify them across// submission iff they didn't change.Map<Integer, byte[]> hashes = defaultStreamGraphHasher.traverseStreamGraphAndGenerateHashes(streamGraph);// Generate legacy version hashes for backwards compatibilityList<Map<Integer, byte[]>> legacyHashes = new ArrayList<>(legacyStreamGraphHashers.size());for (StreamGraphHasher hasher : legacyStreamGraphHashers) { legacyHashes.add(hasher.traverseStreamGraphAndGenerateHashes(streamGraph));}defaultStreamGraphHasher：默认实现为 StreamGraphHasherV2，用于计算每个节点的 OperatorID，哈希的对象依据 StreamNode 是否设置了 transformationUID 会有变动。legacyHashes：只蕴含一个 StreamGraphUserHashHasher，如果用户给算子设置了 userHash，则这里会抽取用户设置的 userHash 作为 OperatorID。StreamGraphHasherV2找出所有的 source 算子，增加到 remaining 队列；对 remaining 队列采取广度遍历算法，计算每个节点的 OperatorID。public Map<Integer, byte[]> traverseStreamGraphAndGenerateHashes(StreamGraph streamGraph) { // The hash function used to generate the hash final HashFunction hashFunction = Hashing.murmur3_128(0); final Map<Integer, byte[]> hashes = new HashMap<>(); Set<Integer> visited = new HashSet<>(); Queue<StreamNode> remaining = new ArrayDeque<>(); // We need to make the source order deterministic. The source IDs are // not returned in the same order, which means that submitting the same // program twice might result in different traversal, which breaks the // deterministic hash assignment. List<Integer> sources = new ArrayList<>(); for (Integer sourceNodeId : streamGraph.getSourceIDs()) { sources.add(sourceNodeId); } Collections.sort(sources); // // Traverse the graph in a breadth-first manner. Keep in mind that // the graph is not a tree and multiple paths to nodes can exist. // // 将 source 节点放入队列 // Start with source nodes for (Integer sourceNodeId : sources) { remaining.add(streamGraph.getStreamNode(sourceNodeId)); visited.add(sourceNodeId); } // 广度遍历 StreamNode currentNode; while ((currentNode = remaining.poll()) != null) { // Generate the hash code. Because multiple path exist to each // node, we might not have all required inputs available to // generate the hash code. // 如果生成失败，阐明该节点依赖的节点的哈希尚未计算结束，则把该节点从 visited 拿出，期待下一次遍历 // 如果生成胜利，则把该节点的上游节点放入待遍历的队列和 visited 队列，放入 visited 队列的起因是 if (generateNodeHash( currentNode, hashFunction, hashes, streamGraph.isChainingEnabled(), streamGraph)) { // Add the child nodes for (StreamEdge outEdge : currentNode.getOutEdges()) { StreamNode child = streamGraph.getTargetVertex(outEdge); if (!visited.contains(child.getId())) { remaining.add(child); visited.add(child.getId()); } } } else { // We will revisit this later. visited.remove(currentNode.getId()); } } return hashes;}generateNodeHash 办法执行逻辑如下图所示：依据用户是否需给 StreamNode 设置了 transformationUID 会将不同的数据作为哈希对象: ...

摘要：本文整顿自 StarRocks 社区技术布道师谢寅，在 Flink Forward Asia 2022 实时湖仓的分享。本篇内容次要分为五个局部： 极速数据分析实时数据更新StarRocks Connector For Apache Flink客户实际案例将来布局点击查看原文视频 & 演讲PPT 一、极速数据分析 对立 OLAP 剖析的趋势，以及 StarRocks 极速查问剖析的外围能力。计算机科学里所有难题，都能通过加中间层的形式来解决，然而不能加的货色太多。回忆 Hadoop 生态演变的过程，先有了分布式存储，解决了海量数据如何用便宜的设施，来存储的问题。又有 MapReduce 帮忙咱们慢吞吞的解决了，分布式解决的问题。 为了让只会写 SQL 的分析师，可能专一于业务，不必放心 Java 编程的问题，又有了 Hive 帮忙咱们解决，SQL 到 MR 的主动解析。当人们感觉 Shuffle 磁盘太慢，咱们钻研了基于内存的弹性分布式数据集 RDD，让数据在内存里分布式的高效计算。 因为内存里微批的计算仍不能形容所有的实时语义，就有了为实时而生的分布式计算引擎 Flink。 晚期，人们对数据的依赖还没那么深的时候，数据不管怎么进来的，最终能看到就行。随着时代的变迁，除了管理层须要看数，基层小伙伴也须要用数。于是 OLAP 剖析产品，就像雨后春笋似的，有能间接聚合指标的，有能 Adhoc 探查的，有单表无敌的，有能反对数据更新的。 因为组件太多，数据在各个引擎里来回传递，时效性低，口径不统一，硬件资源，人力老本，都十分节约。所以人们期待一种极致性能的剖析型数据库，可能收敛 OLAP 剖析层，开启实时数据分析新范式。 StarRocks 的愿景是心愿帮忙客户，可能实现极速对立 OLAP 剖析的技术架构。首先，通过 2 年的打造，极致的性能曾经深入人心。全面反对了向量化引擎，CBO 技术，智能物化视图等等一揽子技术。使得 StarRocks 能够实现亚秒级极速 OLAP 剖析，保障数据分析利用最初一公里的极速响应。 同时，现代化 MPP 的架构，能够让查问服务充分利用多机多核的资源。保障业务随着硬件，能够 scale-up 和 scale-out。简洁的 fe+be 的架构，能够实现极简运维，优良的实时摄入能力，让实时数据分析变得轻松简略。 在高并发点查的场景，资源正当布局，能够做到上万 QPS。在与云的整合上，咱们曾经在各大云商的半托管服务上，可能疾速部署社区版 StarRocks。周边咱们也在致力整合更丰盛的生态计划。凋谢沉闷的社区也逐步有搭档，帮咱们奉献更多的关键性 Feature。 ...

摘要：本文整顿自 Shopee 研发专家李明昆，在 Flink Forward Asia 2022 流批一体专场的分享。本篇内容次要分为四个局部： 流批一体在 Shopee 的利用场景批处理能力的生产优化与离线生态的齐全集成平台在流批一体上的建设和演进点击查看原文视频 & 演讲PPT 一、流批一体在 Shopee 的利用场景 首先，先来理解一下 Flink 在 Shopee 的应用状况。 除了流工作，仅从反对的批工作来看，Flink 平台上的作业曾经达到了一个比拟大的规模。 目前 Flink 批工作曾经在 Shopee 外部超过 60 个 Project 上应用，作业数量也超过了 1000，这些作业在调度零碎的反对下，每天会生成超过 5000 个实例来反对各个业务线。 从利用场景划分，这些作业在 Shopee 次要分为以下四个局部： 第一个利用场景是数据集成畛域。第二个利用场景是数仓畛域。第三个利用场景是特色工程，次要用于实时和离线特色的生成。第四个利用场景是风控反作弊畛域，用做实时反作弊和离线反作弊。 从 Shopee 外部的业务场景来看，数仓是一个流批一体施展重要作用的畛域。 目前，业内还没有这样一个端到端流式数仓的成熟解决方案，大部分都是通过一些纯流的计划 + 离线数仓计划 + 交互式查问计划叠加起来达到近似成果。 在这类 Lambda 架构中，Flink 流批一体次要带来的劣势是实现计算对立。通过计算对立去升高用户的开发及保护老本，解决两套零碎中计算逻辑和数据口径不统一的问题。 但这样的 Lambda 架构复杂性又太高了。所以针对时延要求不高的业务，Shopee 实时团队主推通过 Flink+ Hudi 的代替计划，构建近实时数仓，这种计划能够解决很多场景的问题。 这种计划的益处很显著，它实现了局部的流批一体：Flink 对立的引擎，Hudi 提供对立的存储。它的限度也很显著，Hudi 数据可见性与 Commit 的距离相干，进而与 Flink 做 Checkpoint 的工夫距离相干，这缩短了整个数据链路的时延。 ...

Flink-learning 学训平台和电商行业实际专栏来啦！ 本期专栏汇总电商行业实际的精髓内容，深刻理解阿里巴巴、聚水潭、京东、唯品会、字节跳动等知名企业建设教训，干货满满，心愿这些实在的实际案例和教训可能帮忙大家更好的了解和应用 Apache Flink，减速更多企业的实时化平台搭建和业务转型。 精彩领先看随着抖音电商业务逐步趋于稳定和成熟，抖音电商实时数仓团队接到的实时数据规定类业务需要也逐渐增多，因而咱们开始尝试应用 Flink CEP 来反对这些业务场景。 「Flink CEP 是基于 Flink 的实时数据规定引擎，反对跨多个事件的规定匹配。然而，过后 Flink CEP 在多规定解决、规定表白方面还存在易用性问题。本文次要介绍 Flink CEP 在抖音电商业务的利用实际以及易用性优化。」 -- 节选自《Flink CEP 在抖音电商的业务实际》张健@字节跳动 参加形式长按下图扫码，登录 Flink-learning 学训平台，退出学习随时记录学习进度，实在走进大量来自不同畛域公司的生产实践案例和教训，帮忙大家更好的了解和应用 Apache Flink。 点击退出学习 更多内容 流动举荐 阿里云基于 Apache Flink 构建的企业级产品-实时计算 Flink 版现开启流动：0 元试用 实时计算 Flink 版（5000CU*小时，3 个月内）理解流动详情：https://click.aliyun.com/m/1000372333/

Flink SQL 的数据脱敏解决方案，反对面向用户级别的数据脱敏访问控制，即特定用户只能拜访到脱敏后的数据。此计划是实时畛域Flink的解决思路，相似于离线数仓 Hive 中 Ranger Column Masking 计划。 一、基础知识1.1 数据脱敏数据脱敏(Data Masking)是一种数据安全技术，用于爱护敏感数据，以避免未经受权的拜访。该技术通过将敏感数据替换为虚伪数据或不可辨认的数据来实现。例如能够应用数据脱敏技术将信用卡号码、社会平安号码等敏感信息替换为随机生成的数字或字母，以爱护这些信息的隐衷和平安。 1.2 业务流程上面用订单表orders的两行数据来举例，示例数据如下: 残缺内容请点击下方链接查看： https://developer.aliyun.com/article/1208514?utm_content=g_10... 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

一、历史背景批作业在算子理论解决数据时，能够提前感知到要解决的这部分数据有多大。从而能够依据数据量的大小，抉择适合的资源解决数据。但流作业是一种 long-running 的作业，它的特点是流量会随着工夫进行变动。咱们没有方法在流作业刚启动时，就预估到将来的流量有多少，须要多少资源。没有一份初始的通用资源配置能够实用于一个流作业的所有场景。 残缺内容请点击下方链接查看： https://developer.aliyun.com/article/1207409?utm_content=g_10... 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

Flink-learning 学训平台第 4 期课程——电商行业实际专栏上线啦！ 本期专栏汇总电商行业实际的精髓内容，深刻理解阿里巴巴、聚水潭、京东、唯品会、字节跳动等知名企业建设教训，干货满满，心愿这些实在的实际案例和教训可能帮忙大家更好的了解和应用 Apache Flink，减速更多企业的实时化平台搭建和业务转型。 Apache Flink 是 Apache 软件基金会的顶级我的项目，也是当下被宽泛应用的开源大数据计算引擎之一。基于它 “流批一体” 的技术，越来越多的企业抉择 Apache Flink 利用于本身的业务场景，如数据集成、数据分析、数据仓库、实时剖析、实时大屏等场景中，解决实时计算的需要。近年来，Apache Flink 开始广泛应用于举荐、广告和搜寻等机器学习业务场景，已笼罩近百家企业的绝大多数实时计算需要，包含互联网娱乐、游戏、电商、金融、证劵、通信等多个行业。 精彩领先看目前 Flink 根本服务于团体的所有 BU ，在双十一峰值的计算能力达到 40 亿条每秒，计算工作达到了 3 万多个，总共应用 100 万+ Core ；简直涵盖了团体内的所有具体业务，比方：数据中台、AI 中台、风控中台、实时运维、搜寻举荐等。 本文次要介绍一些大规模风控的技术难点，以及阿里云在全托管 Flink 商业化产品中如何冲破这些技术难点。 -- 节选自《基于 Flink 构建大规模实时风控系统在阿里巴巴的落地》李佳林（风元）@阿里巴巴 参加形式长按下图扫码，登录 Flink-learning 学训平台，退出学习随时记录学习进度，实在走进大量来自不同畛域公司的生产实践案例和教训，帮忙大家更好的了解和应用 Apache Flink。 点击退出学习 更多内容 流动举荐 阿里云基于 Apache Flink 构建的企业级产品-实时计算 Flink 版现开启流动：0 元试用 实时计算 Flink 版（5000CU*小时，3 个月内）理解流动详情：https://click.aliyun.com/m/1000372333/

在过来几年中，这个话题时不时地在邮件列表、Jira 和线下探讨中被提到。然而，2.0 版本的布局须要投入微小的信心和致力，再加上社区忙于其余优先事项，Flink 2.0 始终没有真正推动起来。近几周，在咱们团队外部以及和来自阿里巴巴 / Ververica 之外的一些人（感激 Becket 和 Robert 的见解）进行了一系列线下探讨后，咱们认为是时候在社区中发展这项工作了。 以下是咱们对 2.0 版本的一些想法。期待您的意见和反馈。 为什么要为 2.0 版本做布局？Flink 1.0.0 于 2016 年 3 月公布。在过来的 7 年中，增加了许多新性能，该我的项目曾经与以前不同。那么当初的 Flink 是什么？将来 3-5 年它将成为什么样子？如何对待 Flink 在行业中的定位？咱们认为当初是从新思考这些问题，并制订出迈向新里程碑的路线图的时候了，这个里程碑值得一个新的主版本。此外，咱们仍在为 7 年前设计并宣称稳固的 API 提供向后兼容性（兴许不是完满的，但很大水平上是）。尽管这样的向后兼容性有助于用户更轻松地应用最新的 Flink 版本，但它有时候也可能会变成保护的累赘和新性能与改良的限度。当初是对所有公共 API 进行全面审查和清理的时候了。 残缺内容请点击下方链接查看： https://developer.aliyun.com/article/1202007?utm_content=g_10... 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

一、Flink SQL InsightFlink 作为流批一体计算引擎，给大家提供了对立的 API，对立的算子形容，以及对立的调度。但 Flink 算子的底层仍有一些轻微的差异。对于一个批算子而言，它的输出是一个无限数据集。批算子会基于残缺数据集进行计算，计算过程中如果内存装不下，数据会 Spill 到磁盘。对于流算子而言，它的输出是一个有限数据集。与批算子不同，流算子不能在收集到所有输出数据之后才开始解决，也不可能将这些数据存到磁盘上。所以流算子的解决是一条一条的（也可能会按一小批进行计算）。当流算子接管到上游的一条数据后，对于 Stateful 算子会从 State 里读取之前的计算结果，而后联合以后数据进行计算，并将计算结果存储到 State 里。因而 State 优化是流计算里十分重要的一部分。 残缺内容请点击下方链接查看： https://developer.aliyun.com/article/1199740?utm_content=g_10... 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

Flink SQL 的数据脱敏解决方案，反对面向用户级别的数据脱敏访问控制，即特定用户只能拜访到脱敏后的数据。此计划是实时畛域Flink的解决思路，相似于离线数仓 Hive 中 Ranger Column Masking 计划。 一、基础知识1.1 数据脱敏数据脱敏(Data Masking)是一种数据安全技术，用于爱护敏感数据，以避免未经受权的拜访。该技术通过将敏感数据替换为虚伪数据或不可辨认的数据来实现。例如能够应用数据脱敏技术将信用卡号码、社会平安号码等敏感信息替换为随机生成的数字或字母，以爱护这些信息的隐衷和平安。 1.2 业务流程上面用订单表orders的两行数据来举例，示例数据如下: 1.2.1 设置脱敏策略管理员配置用户、表、字段、脱敏条件，例如上面的配置。 1.2.2 用户拜访数据当用户在Flink上查问orders表的数据时，会在底层联合该用户的脱敏条件从新生成 SQL，即让数据脱敏失效。当用户 A 和用户 B 在执行上面雷同的 SQL 时，会看到不同的后果数据。 SELECT * FROM orders用户A查看到的后果数据如下，customer_name字段的数据被全副覆盖掉。 用户 B 查看到的后果数据如下，customer_name字段的数据只会显示前 4 位，剩下的用 x 代替。 二、Hive 数据脱敏解决方案在离线数仓工具 Hive 畛域，因为倒退多年已有 Ranger 来反对字段数据的脱敏管制，详见参考文献[[1]](https://docs.cloudera.com/HDPDocuments/HDP3/HDP-3.1.0/authori...)。下图是在 Ranger 里配置 Hive 表数据脱敏条件的页面，供参考。 但因为 Flink 实时数仓畛域倒退绝对较短，Ranger 还不反对 Flink SQL，以及依赖 Ranger 的话会导致系统部署和运维过重，因而开始自研实时数仓的数据脱敏解决工具。当然本文中的核心思想也实用于 Ranger 中，能够基于此较快开发出 ranger-flink 插件。 三、Flink SQL 数据脱敏解决方案3.1 解决方案3.1.1 Flink SQL 执行流程能够参考作者文章 [[FlinkSQL字段血统解决方案及源码]](https://github.com/HamaWhiteGG/flink-sql-lineage/blob/main/README_CN.md)，本文依据 Flink 1.16 修改和简化后的执行流程如下图所示。 ...

背景线上 flink 用户应用 ZooKeeper 做元数据中心以及集群选主，一些版本的 flink 在 ZooKeeper 选主时，会重启 Job，导致一些非预期的业务损失。而 ZooKeeper 在 zxid溢出时，会被动触发一次选主，就会导致 flink Job 的非预期重启，造成业务损失。本篇从原理和最佳实际上剖析和解决因为 ZooKeeper zxid 溢出导致的集群选主问题。查看 ZooKeeper Server 日志呈现。 zxid lower 32 bits have rolled over, forcing re-election, and therefore new epoch start解决办法ZooKeeper 自身提供以后解决的最大的 Zxid，通过 stat 接口可查看到以后解决的最大的 zxid 的值，通过此值能够计算以后 zxid 间隔溢出值还有多少差距。MSE 提供风险管理以及集群选主相干告警，提前预防和及时感知选主危险，防止业务损失。 残缺内容请点击下方链接查看： https://developer.aliyun.com/article/1155595?utm_content=g_10... 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

摘要：本文整顿自 bilibili 大数据实时团队资深开发工程师周晖栋，在 Flink Forward Asia 2022 实时湖仓专场的分享。本篇内容次要分为四个局部： 背景和痛点场景摸索基建优化总结和瞻望点击查看原文视频 & 演讲PPT 一、背景和痛点 在大数据场景利用中，业务不仅要计算数据后果，而且要保障时效性。目前，我司演化出两条链路。时效性高的数据走 Kafka、Flink 实时链路；时效性要求低的数据走 Spark 离线链路。上图简略形容了 B 站数据上报、解决和应用的链路。数据采集次要通过 APP 端上报的行为事件数据。服务端上报的日志数据会通过网关以及散发层，流式散发到大数据数仓体系内。 MySQL 中存储的业务数据，通过 Datax 周期性的批式同步到数仓内。时效性高的数据会通过 Flink+Kafka 进行流式计算。时效性低的数据通过 Spark+HDFS 进行批计算最初出仓到 MySQL Redis Kafka 的介质中，为 AI、BI 的模型训练、报表剖析场景应用。 在应用的过程中，也发现了诸多问题。 离线数据的时效性有余，离线批计算以小时/天为单位。越来越多的业务方心愿时效性达到分钟级，离线的小时计算或天计算不能满足业务方的需要。为了达到更高的时效性，业务会再开发一条实时链路。但实时链路的可观测性较弱。因为在 Kafka 里查看数据并不不便，所以须要将 Kafka 里的数据挪动到其余存储中，能力进行查看。实时数据链路广泛不容易和业务工夫对齐，难以精确定位到须要重跑的终点。如果数据出现异常，业务个别不会抉择在实时流上进行重跑，而是进行离线链路的 T-1 修复。实时离线双链路会有双份的资源开销，开发以及运维老本。除此之外，口径不统一还会带来额定的解释老本。全天计算资源顶峰集中在凌晨，整个大数据集群的应用峰值在凌晨 2 点~8 点。次要在跑天级任务，也存在工作排队的景象。其余时段的资源比拟闲暇，应用时有显著的峰谷景象。整体资源使用率有肯定的优化空间。在数据出仓孤岛方面，对于用户来说还须要克隆一份数据到 HDFS 上，因而会存在数据一致性的问题。当数据出仓后，权限以及数据联邦查问都会存在有余。咱们心愿通过实时数据湖计划，解决以上痛点。 咱们通过 Flink+Hudi 将数据增量，以及增量计算产出的后果存储在 Hudi 中，反对分钟级的数据计算，进一步加强了数据的时效性。除此之外，Hudi 具备流表二象性，岂但能够进行实时的流式增量生产，而且能够作为表，间接进行查问。相比 Kafka 链路，进一步加强了可观测性。实时数据湖同时满足实时和离线的需要，达到降本增效的成果。除此之外，它还反对离线数仓数据重跑的诉求。通过增量计算，将本来在 0 点当前调配的数据资源进行细分，摊派到全天的每分钟，错峰的应用资源。通过排序、索引、物化等形式，咱们能够间接查问 Hudi 表中的数据，从而达到数据不出仓的成果。二、场景摸索 当业务零碎数据存储在 MySQL 中，须要将这些数据导入到大数据的数仓中，进行报表、剖析、计算等场景。目前，业务数据入仓不仅用于离线 ETL，还冀望具备时效性。比方在稿件内容审核场景中，工作人员心愿晓得近十分钟的稿件增长量是否匹配稿件审核人力，存在实时监控诉求，以及告警诉求。稿件的数据来源于业务数据库，它并不满足于以后天级、小时级数据同步的时效性，心愿能达到分钟级的时效性。 在降本增效的大背景下，咱们不仅要满足业务诉求，还要思考效力。实时链路用于实时场景，离线链路用于批量的 ETL 场景比拟节约。所以咱们心愿通过实时数据湖，构建一套流批对立的计划，同时满足实时和离线场景的诉求。通过调研发现，现有的计划中有以下几类： 第一，DataX 定期批量导出数据到 Hive。 ...

要在shell-shell的那个黑框命令行外面，读取一下你的parquet文件，而后打印下他的Schema,再跟你的hive表的建表语句：show create table *外面的字段类型逐个compare一下，而后看看他们的differentia，个别应该是parquet的schema外面有个long类型，被你hive外面该字段定义成了int，或者相同，不兼容导致的； 残缺内容请点击下方链接查看： https://developer.aliyun.com/ask/501077?utm_content=g_1000371897 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

摘要：本文整顿自阿里巴巴开发工程师罗宇侠&方盛凯，在 Flink Forward Asia 2022 流批一体专场的分享。本篇内容次要分为五个局部： 构建流批一体引擎的挑战Hive SQL on Flink流批一体引擎的收益Demo将来瞻望点击查看原文视频 & 演讲PPT 一、构建流批一体引擎的挑战 目前，流和批依然是绝对割裂的。尽管咱们在应用层对立了，但从接入层开始，不同的引擎仍旧有不同的接入层、API 层、执行层。咱们认为，对立的流批一体引擎应该是从接入层开始应用 SQL Gateway 作为接入层。在 API 层应用 Flink SQL 作为编写作业的次要语言，在执行层替换成对立的 Runtime。 为了达成对立的流体引擎，咱们认为有以下两个难点： 应用层的对接。在流批割裂的环境下，应用层依然是有不同的提交平台，如何保障原来的应用层能无损且间接地对接到新的 SQL Gateway 上，是一个微小的难点。用户作业迁徙的老本。用户原来的 Batch 作业是用 Hive SQL 进行撰写的，当初则须要替换成 Flink SQL。为了保障用户的作业能无损迁上来，咱们须要解决语言上的兼容和用户所用的 UDF 的兼容。 为此咱们围绕以下两点在 Flink 1.16 上做了大量改良，保障了 Hive SQL on Flink 构建流批一体引擎是可行的。 Flink 对 Hive SQL 的兼容，咱们在 1.16 中大大晋升了对 Hive SQL 自身的兼容性。咱们在 Flink 社区引入了 SQL Gateway，从而兼容 Hive 的生态。二、Hive SQL on Flink接下来我来讲一下 Flink 社区具体做的一些工作来使得基于 Hive SQL on Flink 构建流批一体引擎成为可能。 ...

语法https://nightlies.apache.org/flink/flink-docs-master/docs/dev... SELECT [column_list]FROM ( SELECT [column_list], ROW_NUMBER() OVER ([PARTITIONBY col1[, col2...]] ORDER BY time_attr [asc|desc])AS rownum FROM table_name)WHERE rownum= 1留神点： ORDER BY 后的字段必须是工夫属性（process time/row time）Minibatch 开关开启 MiniBatch 时应用 KeyedMapBundleOperator，否则应用 KeyedProcessOperator。 状态应用 Event TimeProcess Time开启 minibatchRowTimeMiniBatchDeduplicateFunctionProcTimeMiniBatchDeduplicateKeepLastRowFunction ProcTimeMiniBatchDeduplicateKeepFirstRowFunction没开启 minibatchRowTimeDeduplicateFunctionProcTimeDeduplicateKeepLastRowFunction ProcTimeDeduplicateKeepFirstRowFunction在 Event Time 场景下，每条数据到来后必须比照其附带的事件工夫和该算子已存储的事件工夫进行比照，因而只需一个函数对立做逻辑解决。 而解决工夫是由以后解决数据的算子赋予，因而能够间接简化为两种场景：保留第一条和保留最初一条： First Row：存储第一条过去的数据，并抛弃前面来的所有数据即可，只能解决上游是 Append-only 的数据，如果是 Process Time 场景也只会产生 Insert 数据；Last Row：每次到来数据须要依据工夫属性留下最新的一条，如果以后的数据是最新的，则下发回撤老数据。所有数据的最终解决逻辑最终会落到 DeduplicateFunctionHelper，因而咱们能够通过浏览 DeduplicateFunctionHelper 的源码查看不同场景的解决状况。 DeduplicateFunctionHelper去重函数的解决都最终调用这个工具类的办法 Process Time&Last RowProcess Time 依据是否解决回撤音讯分为两种： processLastRowOnProcTime：仅反对解决 INSERT 音讯；processLastRowOnChangelog：除 INSERT 外可解决回撤等音讯。Last Row on Proctimestatic void processLastRowOnProcTime( RowData currentRow, boolean generateUpdateBefore, boolean generateInsert, ValueState<RowData> state, Collector<RowData> out) throws Exception { checkInsertOnly(currentRow); if (generateUpdateBefore || generateInsert) { // use state to keep the previous row content if we need to generate UPDATE_BEFORE // or use to distinguish the first row, if we need to generate INSERT RowData preRow = state.value(); state.update(currentRow); if (preRow == null) { // the first row, send INSERT message currentRow.setRowKind(RowKind.INSERT); out.collect(currentRow); } else { if (generateUpdateBefore) { preRow.setRowKind(RowKind.UPDATE_BEFORE); out.collect(preRow); } currentRow.setRowKind(RowKind.UPDATE_AFTER); out.collect(currentRow); } } else { // always send UPDATE_AFTER if INSERT is not needed currentRow.setRowKind(RowKind.UPDATE_AFTER); out.collect(currentRow); }}查看该音讯是否是 INSERT 格局（只承受 INSERT 格局音讯）；查看该节点发送的音讯类型（generateUpdateBefore 的值由 changelogmode 和上游须要的音讯类型独特决定是否须要下发回撤，generateInsert 由 table.exec.deduplicate.insert-update-after-sensitive-enabled 配置确定）是否反对 UA 和 I；如果不反对发回撤且不反对发 INSERT 则间接发送 UA 音讯到上游；如果反对，查看以后这条数据是否是第一条数据（依据状态查问，状态里会保留上一条到来的数据），并更新状态为以后数据；如果是第一条数据，则附上 +I 标识发送音讯到上游；如果不是第一条数据，查看该节点是否反对发送 UB 音讯；如果须要，则附上 -UB 标识发送回撤上一条数据；发送 +UA 音讯。Last Row on Changelogstatic void processLastRowOnChangelog( RowData currentRow, boolean generateUpdateBefore, ValueState<RowData> state, Collector<RowData> out, boolean isStateTtlEnabled, RecordEqualiser equaliser) throws Exception { RowData preRow = state.value(); RowKind currentKind = currentRow.getRowKind(); if (currentKind == RowKind.INSERT || currentKind == RowKind.UPDATE_AFTER) { if (preRow == null) { // the first row, send INSERT message currentRow.setRowKind(RowKind.INSERT); out.collect(currentRow); } else { if (!isStateTtlEnabled && equaliser.equals(preRow, currentRow)) { // currentRow is the same as preRow and state cleaning is not enabled. // We do not emit retraction and update message. // If state cleaning is enabled, we have to emit messages to prevent too early // state eviction of downstream operators. return; } else { if (generateUpdateBefore) { preRow.setRowKind(RowKind.UPDATE_BEFORE); out.collect(preRow); } currentRow.setRowKind(RowKind.UPDATE_AFTER); out.collect(currentRow); } } // normalize row kind currentRow.setRowKind(RowKind.INSERT); // save to state state.update(currentRow); } else { // DELETE or UPDATER_BEFORE if (preRow != null) { // always set to DELETE because this row has been removed // even the input is UPDATE_BEFORE, there may no UPDATE_AFTER after it. preRow.setRowKind(RowKind.DELETE); // output the preRow instead of currentRow, // because preRow always contains the full content. // currentRow may only contain key parts (e.g. Kafka tombstone records). out.collect(preRow); // clear state as the row has been removed state.clear(); } // nothing to do if removing a non-existed row }}changelog 场景下，因为须要解决回撤信息，去重逻辑绝对简单一点： ...

1. 类加载机制简介Java 默认的类加载机制是 双亲委派模型。 Flink 则为用户类和框架的类抵触提供了 child-first 的类加载模式，这样可能肯定水平上缩小因为框架降级导致应用的某局部依赖和用户的依赖版本不兼容的问题（当然不能彻底解决，将这部分类替换成用户的依赖版本也可能导致 Flink 框架在运行过程中呈现 NoSuchMethod 等异样）。 但针对一些外围类，Flink 仍旧还是优先从框架提供的环境中加载。 为了实现这些能力，Flink 提供了两个对于类加载的配置： classloader.resolve-order：有两个值，child-first 和 parent-first，前者是下面提到的优先加载用户类的模式，后者是 Java 默认的双亲委派模式。Flink 默认应用 child-first。classloader.parent-first-patterns.default：这里定义了一系列模式，用来匹配一些要害类，被这些模式匹配中的类都会优先加载 Flink 环境的类，而不会从用户类中进行加载，比方 flink-connector-kafka_2.11-1.12.2.jar，必须放到 flink lib 目录下，而不能简略的通过拓展指定 classpath。2. 源码解读创立入口可看 ClientUtils 的 buildUserCodeClassLoader 办法： public static URLClassLoader buildUserCodeClassLoader( List<URL> jars, List<URL> classpaths, ClassLoader parent, Configuration configuration) { URL[] urls = new URL[jars.size() + classpaths.size()]; for (int i = 0; i < jars.size(); i++) { urls[i] = jars.get(i); } for (int i = 0; i < classpaths.size(); i++) { urls[i + jars.size()] = classpaths.get(i); } // 1. 读取配置获取 alwaysParentFirstLoaderPatterns，这部分 pattern 匹配的类都优先从 Flink 环境加载 final String[] alwaysParentFirstLoaderPatterns = CoreOptions.getParentFirstLoaderPatterns(configuration); // 2. 读取配置获取类加载模式 final String classLoaderResolveOrder = configuration.getString(CoreOptions.CLASSLOADER_RESOLVE_ORDER); FlinkUserCodeClassLoaders.ResolveOrder resolveOrder = FlinkUserCodeClassLoaders.ResolveOrder.fromString(classLoaderResolveOrder); final boolean checkClassloaderLeak = configuration.getBoolean(CoreOptions.CHECK_LEAKED_CLASSLOADER); return FlinkUserCodeClassLoaders.create( resolveOrder, urls, parent, alwaysParentFirstLoaderPatterns, NOOP_EXCEPTION_HANDLER, checkClassloaderLeak);}能够看一下 CoreOptions.getParentFirstLoaderPatterns(configuration)，其实和 classLoaderResolveOrder 的读取一样，调用了 Configuration.getString() 办法： ...

摘要：本文整顿自阿里云计算平台算法专家张颖莹，在 Flink Forward Asia 2022 AI 特色工程专场的分享。本篇内容次要分为五个局部：1.阿里云大数据平台的智能运维2.智能运维算法服务利用场景3.传统算法工程链路的局限性4.应用 Flink ML 搭建智能运维算法服务5.总结和开源打算一、阿里云大数据平台的智能运维 阿里云计算平台提供了多个十分外围的大数据计算和人工智能相干的产品，撑持了阿里团体外部以及云上各行各业客户很多外围的业务场景。在这里我筛选了三个十分典型的大数据计算产品来给大家做介绍，它们是大数据计算服务 MaxCompute、实时计算 Flink、实时数仓 Hologres。 这些产品所撑持的业务场景大家其实也都十分相熟，比方咱们日常在手机淘宝、蚂蚁森林中收取的能量数据就依赖于像 MaxCompute 大数据计算服务定时产出，因为它次要负责大规模数据的离线计算；双十一期间，咱们会看到十分多炫酷的数字大屏，这些大屏上实时滚动的数字就依赖于像 Flink 实时大数据处理系统；当咱们日常在手机淘宝上搜寻一些商品的关键词的时候，Hologres 则会在底层帮咱们进行实时的交互式剖析，从而为咱们举荐出实时的搜寻后果。 能够看出，这几个大数据平台所撑持的业务场景是十分丰盛的，它的用户规模十分的宏大，平台自身的架构也十分复杂。因而保障平台的稳定性就变成了一项重要且富裕挑战性的工作。咱们计算平台专门设置了一支运维中台的研发团队，也就是我所在的团队，来负责大数据平台的对立运维管控。 比拟有意思的一点是，咱们既是大数据平台的使用者，同时咱们也负责平台的智能化运维工作。 从运维的视角来看，咱们最关怀的外围问题次要有三个层面，别离是稳定性、老本、效率。 在稳定性层面，波及到的问题包含是否可能及时发现大数据平台中产生的异样、定位异样背地的根本原因、及时的止血和修复问题。在老本层面，咱们关怀是否通过更加正当的资源配置以及优化利用的排布，在保障稳定性的前提下，可能让咱们的老本降到最低。在效率层面，咱们不仅关注大数据平台自身的性能的晋升，同时咱们也心愿应用大数据平台的用户能到可能失去十分高效的技术支持和答疑。后面提到的典型场景当然都离不开数据的撑持，随着零碎的云原生化以及可观测性理念的遍及，咱们当初所能获取到的零碎层面的可观测性数据也越来越丰盛了，包含指标、日志、Trace 等等多种不同状态的数据。 基于传统的人工剖析曾经很难实现对海量数据的全面高效剖析，因而也就催生出了对于智能运维算法能力的需要。那么在智能运维场景里，咱们对算法模型都有哪些需要呢？ 首先，咱们心愿算法模型可能解决来自多个不同数据源、各个不同状态的数据。比方咱们后面所提到的指标就属于工夫序列类型的数据，而日志属于文本类型的数据。 同时，咱们心愿在智能运维场景中的算法还要具备足够高的性能。因为在运维的场景中，咱们须要面对的往往是信息密度比拟低的海量数据。 此外，无论是从大数据平台所撑持的业务场景来看（比方咱们方才提到的双十一的数字大屏），还是从阿里云所承诺给用户的服务质量的角度而言，咱们对于智能运维场景中算法的实时性也都有十分高的要求。 二、智能运维算法服务利用场景那么接下来咱们就通过几个典型的案例来给大家介绍，在智能运维的场景中都有哪一些比拟典型的算法模型，以及他们是如何利用在咱们的理论业务场景中的。咱们仍然会从智能运维的外围场景稳定性、老本和效率三个层面进行开展。 稳定性层面，咱们后面提到的关键问题是，咱们是否及时发现零碎中的异样。在咱们理论的生产中，对应的平台的运维人员会去建设本人的一套外围指标监控大盘，但对于像阿里云这样宏大的平台，即便是外围指标，它的数量也远远超过了人工可能笼罩的领域。因而咱们就须要利用工夫序列的异样检测算法，它能主动捕捉在运维场景中几种比拟典型的异样，包含方差的变动、均值的变动、尖峰深谷、断崖式跌落、趋势增长等等。 那么通过这些智能继续的异样检测算法，咱们就可能更快的发现零碎中的异样问题，最终的目标则是为了保障咱们承诺给用户的稳定性 SLA。常见的稳定性 SLA 的量化规范是 MTTR，也就是问题从产生到最终解决的耗时。而工夫序列异样检测算法所要解决的是其中十分要害的 MTTD 环节。因而如果咱们可能去缩短工夫序列异样检测算法链路侧的延时，就可能缩短 MTTD，进而缩短 MTTR，最终保障咱们整体稳定性 SLA 的达成。 老本层面，咱们心愿通过更加正当的资源配置，使得在保障用户体验和平台稳定性的前提下，可能把老本降到最低。为了达到这个目标，须要具备以下两个基本要素。 咱们须要可能对用户的负载和资源需要进行十分精准的预测。咱们在零碎底层的调度侧须要具备主动扩缩容的能力。目前随着咱们整个零碎的云原生化，底层零碎的主动扩缩容能力曾经根本具备了，因而精准的预测就变得十分要害。在过来，当咱们无奈对用户的负载进行精准预测的时候，通常只能依据教训设置比拟恒定的值，但这种设置办法会导致低峰时段的资源节约，顶峰时段的用户资源需要又无奈充沛失去满足，既节约了机器又影响了用户的体验。 如果咱们有了更加精准的算法，就能更加精准的捕捉用户负载的简单的周期性，同时能够依据精准的预测后果，分不同的时段设置更加正当的资源配置，使得在低峰时候资源的节约缩小，顶峰时候用户的资源需要又能尽可能的失去保障。 当然咱们晓得在理论的业务场景中，用户的资源需要不是完满且安稳的周期性曲线。因而咱们须要联合最新的数据，及时对咱们的预测算法做出调整，调整咱们的预测后果以及相应的置信度。最终优化咱们给用户举荐的资源配置策略，或者修改后期谬误的一些资源配置策略。因而咱们对于工夫序列预测算法链路上延时的革新，能够使得咱们可能更加精准灵便的去应答线上资源的渐变状况。 效率层面，咱们的大数据计算平台上运行着十分多的用户的作业，无论是零碎层面，还是用户本身操作层面的问题，都有可能导致作业呈现报错。当用户接管到零碎报错的时候，大多数用户都不晓得如何解决。因而他们通常的做法就是，通过提工单的形式来寻求业余技术支持的帮忙。 而随着咱们用户体量的不断扩大，技术支持的答疑工作量也变得越来越大，而且其实很多的报错都是同一个起因造成的，所以给技术支持带来了十分多低效反复的答疑。因而咱们心愿利用日志聚类算法来实现对海量原始日志的高效压缩，使咱们可能把海量的原始日志聚合成数量十分无限的日志类别。这样运维人员只需针对研发数量十分无限的日志类别，再联合他们的专家教训标注对应的解决方案即可。 当下一次其余用户遇到相似问题的时候，咱们就能通过日志聚类算法去匹配报错所对应的解决方案，并通过答疑机器人间接传递给用户。从而大大晋升工单的拦挡率，缩小技术支持的答疑工作量。同时对于用户来说，也能在接管到报错很短的工夫内，就失去解决方案的举荐，进而晋升用户侧的满意度。 那么在这里咱们为什么会须要用到流式的日志聚类呢？ 首先，咱们的系统日志是源源不断生成的。其次，以往离线进行训练的算法链路，会导致用户在接管到报错，来寻求技术支持帮忙的时候，底层的日志都还没聚类实现，因而也就无奈举荐出适合的解决方案了。所以利用流式日志聚类算法，咱们可能保障用户在接管到报错很短的工夫内，就可能实现聚类，并且举荐出适合的解决方案。 通过这三个场景的解说，咱们能够理解到在智能运维场景中，这几个算法模型的实时性都有十分高的要求，因而传统的算法链路通常难以满足咱们的须要。 三、传统算法工程链路的局限性 接下来咱们就通过具体的传统算法工程链路来给大家解说它的局限性。上图展现了咱们以往在实践中常常会应用到的传统算法工程链路。 在数据的输出层，咱们有一个流式产生的数据源。比方它可能是各个模块产生的日志数据，或者是各个模块一直上报上来的指标数据。这些数据的格局通常是比拟芜杂的，所以咱们须要利用 Flink 作业对数据进行实时的预处理。把它加工成咱们后续算法所冀望的格局，并把它输入、存储到一个数据库中。 而在传统的链路中，咱们的 AI 算法局部通常是部署在单机上的一段代码，并通过调度机制进行定时的调度。这段算法会离线的从数据库中读取一批数据，进行模型的离线训练，并把训练好的模型也存储下来。 在咱们理论的运维实场景中，通常会须要一些比拟实时性的剖析后果，所以咱们以往都是去减少另外一个 Flink 作业。在这个作业中，一方面咱们会去对接源头的流式数据源，同时咱们也会去调用离线训练好的模型。这样的话就能使得咱们的剖析后果的实时性，不会受到模型自身训练频率的影响。 这样的做法尽管勉强可能运行，但它依然存在着十分大的局限性。首先咱们能够看到，整个流程十分简短。数据的预处理阶段、模型的共建阶段、后续的数据分析阶段都扩散在了各个不同链路中。咱们波及到了两个作业和一段代码脚本，同时上一个阶段的产出是被下一个阶段强依赖的，因而整个链路的运维保障老本十分高。 同时，咱们方才提到了 AI 算法局部是通过部署在机器上的定时调度的程序去执行的，因而它的实时性非常低。此外，我因为部署在单机上，算法的性能也很难失去保障，所以咱们须要去对这一套传统算法工程链路进行革新优化。 ...

摘要：本文整顿自阿里云技术专家，Apache Flink PMC Member & Committer, Flink CDC Maintainer 徐榜江和阿里云高级研发工程师，Apache Flink Contributor & Flink CDC Maintainer 阮航，在 Flink Forward Asia 2022 数据集成专场的分享。本篇内容次要分为四个局部：1.深刻解读 Flink CDC 2.3 版本2.基于 Flink CDC 构建古代数据栈3.阿里云外部实际和改良4.Demo & 将来布局一、深刻解读 Flink CDC 2.3 版本1.1 Flink CDC 首先介绍一下 Flink CDC 技术。Flink CDC 是基于数据库的日志 CDC 技术，实现了全增量一体化读取的数据集成框架。配合 Flink 优良的管道能力和丰盛的上下游生态，Flink CDC 能够高效实现海量数据的实时集成。 如上图所示，在数据库中，咱们有历史的全量数据，也有实时的增量数据。比方上游有业务零碎在源源不断实时写入数据，Flink CDC 技术的能力就是将全量数据和增量数据无缝集成到 Flink 引擎中，为上游利用提供实时的一致性快照。 1.2 Flink CDC 2.3 根本介绍 2022 年 11 月 10 日，Flink CDC 社区公布了 2.3 版本。 此版本的贡献者共有 49 位，解决了 126 个 issue，合并的 PR 达到 133 个；合并的 commits 达到 173 个。 ...

摘要：本文整顿自阿里云技术专家，Apache Flink PMC Member & Committer, Flink CDC Maintainer 徐榜江和阿里云高级研发工程师，Apache Flink Contributor & Flink CDC Maintainer 阮航，在 Flink Forward Asia 2022 数据集成专场的分享。本篇内容次要分为四个局部： 深刻解读 Flink CDC 2.3 版本基于 Flink CDC 构建古代数据栈阿里云外部实际和改良Demo & 将来布局点击查看直播回放和演讲 PPT 一、深刻解读 Flink CDC 2.3 版本1.1 Flink CDC 首先介绍一下 Flink CDC 技术。Flink CDC 是基于数据库的日志 CDC 技术，实现了全增量一体化读取的数据集成框架。配合 Flink 优良的管道能力和丰盛的上下游生态，Flink CDC 能够高效实现海量数据的实时集成。 如上图所示，在数据库中，咱们有历史的全量数据，也有实时的增量数据。比方上游有业务零碎在源源不断实时写入数据，Flink CDC 技术的能力就是将全量数据和增量数据无缝集成到 Flink 引擎中，为上游利用提供实时的一致性快照。 1.2 Flink CDC 2.3 根本介绍 2022 年 11 月 10 日，Flink CDC 社区公布了 2.3 版本。 此版本的贡献者共有 49 位，解决了 126 个 issue，合并的 PR 达到 133 个；合并的 commits 达到 173 个。 ...

一个Flink Cluster是由一个Flink Master和多个TaskManager组成的，Flink Master和TaskManager是集成级组件，其余组件都是过程内的组件 Flink Master中每一个JobManager独自治理一个具体的Job，JobManager中的Scheduler组件负责调度执行该Job的DAG中所有Task，收回资源申请，即整个资源调度的终点;JobManager中Slot Pool组件 持有该 Job 的所有资源。另外，FlinkMaster中惟一的ResourceManager负责整个 Flink Cluster 的资源调度以及与内部调度零碎对接，这里的内部调度零碎指的是 Kubernetes、 Mesos、Yarn 等资源管理零碎 1、MasterJobManager负责一个具体的Job的执行，在一个集群中，可能会有多个JobManager同时执行JobManager的职责次要是接管Flink作业，调度Task，收集作业状态和治理 TaskManager只有在承受到CLient端提交的工作才会启动ResourceManagerFlink的集群资源管理器，Taskslot的治理和资源申请等工作，都由它负责TaskManager启动后会不停的对ResourceManager进行心跳通信DispatcherDispatcher服务提供REST接口来接管client的job提交，它负责启动JobManager和提交 job，同时运行Web UI负责接管用户提交的JobGragh, 而后启动一个JobManager来管理应用程序WebMonitorEndpoint如果客户端通过 flink run 的形式来提交一个 job 到 flink集群，最终是由WebMonitorEndpoint来接管，并且决定应用哪一个 Handler 来执行解决 总结Flink集群的节点运行 : ResourceManager和Dispatcher，当Client提交一个job到集 群运行的时候(客户端会把该Job构建成一个JobGragh 对象)，Dispatcher负责调度 JobManager来治理这个Job的执行，JobManager向ResourceManager申请执行Task 所须要的资源 2、详说JobMaster、REST和ResourceManager组件JobManager(Master节点)包含REST、Dispatcher、ResourceManager和 JobMaster，而TaskManager(Worker节点)次要有TaskExecutor REST的主体局部WebMonitorEndpoint接管客户端的HTTP申请，提供各种REST服务，如作 业、集群的指标、各种作业信息的状况、操作作业等Dispatcher的次要性能是接管REST转发的操作JobMaster申请，启动和治理JobMaster。 JobMaster次要负责作业的运行调度和检查点的协调ResourceManager在不同部署模式下对资源进行治理(次要包含申请、回收资源及资源状态 管控)TaskExecutor对资源(CPU、内存等)以逻辑的Slot进行划分，Slot供作业的Task调度到其上 运行RESTREST是JobManager裸露给内部的服务，次要为客户端和前端提供HTTP服务。REST局部源代码的外围WebMonitorEndpoint类WebMonitorEndpoint继承RestServerEndpoint类，实现JsonArchivist和LeaderContender接口，其中 : RestServerEndpoint是基于Netty实现的抽象类，是整个裸露REST服务的外围局部；LeaderContender接口定义了WebMonitorEndpoint在(Leader)选举方面的解决办法；JsonArchivist接口定义了基于ExecutionGraph生成JSON的接口，供查问作业执行信息的 Handler来实现MiniDispatcherRestEndpoint是作为Per-Job模式(一个作业对应一个集群的模式)的实现DispatcherRestEndpoint是作为Session模式的实现WebMonitorEndpoint的外围是启动过程，启动实现即可为内部提供REST服务，WebMontiorEndpoint的启动过程如下 : 初始化解决内部申请的Handler将解决内部申请Handler注册到路由器(Router)创立并启动NettyServer启动领袖选举服务ResourceManagerResourceManager组件负责资源的调配与开释，以及资源状态的治理ResourceManager组件的根底类为ResourceManagerResourceManager类实现的是ResourceManagerGateway接口，实现的办法供 Dispatcher、REST、JobMaster组件调用ResourceManager的子类有StandaloneResourceManager、MesosResourceManager、 YarnResourceManager，作为不同部署模式的实现，实现在各种部署模式下与资源管控的交互ResourceManager与其余组件的通信次要有以下几种 : REST组件通过Dispatcher透传或者间接与ResourceManager通信来获取TaskExecutor的详细信息、集群的资源状况、TaskExecutor Metric查问服务的信息、TaskExecutor 的日志和标记输入。具体体现在Flink UI上JobMaster与ResourceManager的交互次要体现在申请Slot、开释Slot、将JobMaster注册到ResourceManager，以及组件之间的心跳TaskExecutor与ResourceManager的交互次要是将TaskExecutor注册到 ResourceManager、汇报TaskExecutor上Slot的状况，以及组件之间心跳通信对于资源Slot，在TaskExecutor上以Slot逻辑单元对TaskManager资源(资源CPU、内 存等)进行划分，供作业的Task调度;在JobMaster和ResourceManager上保护与TaskExecutor的Slot的映射关系，JobManager通过SlotPool来治理运行作业的Slot， ResourceManager通过SlotManager来治理TaskManager注册过去的Slot，供多个 JobMaster的SlotPool来申请和调配JobMasterJobMaster组件次要负责单个作业的执行JobMaster组件对应的根底类为JobMaster类JobMaster类继承FencedRpcEndpoint类来实现带Token(Fencing Token)查看的 RpcEndpointJobMaster类实现JobMasterGateway接口，来提供其余组件调用的RPC办法JobMaster类实现JobMasterService接口，来供JobManagerRunner调用JobManagerRunner负责JobMaster的创立与启动，以及与JobMaster领袖选举相干的解决在JobMaster组件中，最外围的组件为Scheduler和CheckpointCoordinator 其中Scheduler负责ExecutionGraph的调度，JobMaster的Scheduler的一个外围逻辑是为作业的任务调度申请Slot而CheckpointCoordinator负责作业检查点的协调 JobMaste是申请Slot的流程的发起方，其中的SlotPool作为作业执行图在调度时提供Slot性能 以及对Slot的生命周期治理，与作业一一对应(一个作业有一个SlotPool实例)，其实现类为 SlotPoolImpl3、TaskManagerTaskExecutor组件是TaskManager的外围局部，次要负责多个Task(工作)的执行TaskExecutor组件的根底类为TaskExecutor类TaskExecutor类继承RpcEndpoint抽象类，由实现的AkkaRpcService来反对RpcEndpoint的实现TaskExecutor类实现TaskExecutorGateway接口，提供其余组件(如JobMaster、 ResourceManager等)RPC的办法TaskManagerRunner是各种部署模式下TaskManager的执行入口，负责构建TaskExecutor的网 络、I/O治理、内存治理、RPC服务、HA服务以及启动TaskExecutorTaskExecutor组件负责与ResourceManager、JobMaster的通信，资源Slot的申请和汇报，Task 的部署和操作及状态的变更，以及检查点相干的协调等TaskExecutor与ResourceManager、JobMaster的通信机会的状况如下 : 与ResourceManager首次建设通信是在ResourceManager向部署模式申请和启动 TaskExecutor，TaskExecutor启动后，通过HA服务监听到ResourceManager的领袖信息，被动发送音讯建立联系TaskExecutor与JobMaster建设通信的机会是ResourceManager向TaskExecutor申请Slot时，TaskExecutor会依据申请Slot中的作业信息，获取JobMaster的通信地址，被动发送信息建设通信，并将Slot提供给JobMasterTaskSlot组织构造与状态Slot是划分TaskExecutor资源的根本逻辑单元。TaskExecutor中所有Slot的状况由TaskSlotTable类来组织治理。TaskSlotTable类由以下属性组成，治理所有Slot的状况 : ...

1、start-cluster.sh# 1、获取文件所在的门路bin=`dirname "$0"`bin=`cd "$bin"; pwd`# 2、先加载配置文件，外面都是一些函数和变量，还有一些逻辑. "$bin"/config.sh# 3、启动JobManager# Start the JobManager instance(s)shopt -s nocasematch# 4、判断JobManager的启动模式，是集群还是单机模式，读取的是flink-conf.yaml中的 high-availability.typeif [[ $HIGH_AVAILABILITY == "zookeeper" ]]; then # HA Mode # 5、如果是基于zookeeper集群模式，调用readMasters readMasters echo "Starting HA cluster with ${#MASTERS[@]} masters." for ((i=0;i<${#MASTERS[@]};++i)); do master=${MASTERS[i]} webuiport=${WEBUIPORTS[i]} # 6、如果是本地模式，本地启动 if [ ${MASTERS_ALL_LOCALHOST} = true ] ; then "${FLINK_BIN_DIR}"/jobmanager.sh start "${master}" "${webuiport}" else # 7、近程通过SSH形式进行后盾启动 ssh -n $FLINK_SSH_OPTS $master -- "nohup /bin/bash -l \"${FLINK_BIN_DIR}/jobmanager.sh\" start ${master} ${webuiport} &" fi doneelse echo "Starting cluster." # Start single JobManager on this machine # 8、以后节点启动JobManager "$FLINK_BIN_DIR"/jobmanager.sh startfishopt -u nocasematch# Start TaskManager instance(s)# 9、启动TaskManagerTMWorkers start2、加载config.sh# 构建Flink ClassPathconstructFlinkClassPath() { local FLINK_DIST local FLINK_CLASSPATH while read -d '' -r jarfile ; do if [[ "$jarfile" =~ .*/flink-dist[^/]*.jar$ ]]; then FLINK_DIST="$FLINK_DIST":"$jarfile" elif [[ "$FLINK_CLASSPATH" == "" ]]; then FLINK_CLASSPATH="$jarfile"; else FLINK_CLASSPATH="$FLINK_CLASSPATH":"$jarfile" fi done < <(find "$FLINK_LIB_DIR" ! -type d -name '*.jar' -print0 | sort -z) local FLINK_DIST_COUNT FLINK_DIST_COUNT="$(echo "$FLINK_DIST" | tr -s ':' '\n' | grep -v '^$' | wc -l)" # If flink-dist*.jar cannot be resolved write error messages to stderr since stdout is stored # as the classpath and exit function with empty classpath to force process failure if [[ "$FLINK_DIST" == "" ]]; then (>&2 echo "[ERROR] Flink distribution jar not found in $FLINK_LIB_DIR.") exit 1 elif [[ "$FLINK_DIST_COUNT" -gt 1 ]]; then (>&2 echo "[ERROR] Multiple flink-dist*.jar found in $FLINK_LIB_DIR. Please resolve.") exit 1 fi echo "$FLINK_CLASSPATH""$FLINK_DIST"}findFlinkDistJar() { local FLINK_DIST FLINK_DIST="$(find "$FLINK_LIB_DIR" -name 'flink-dist*.jar')" local FLINK_DIST_COUNT FLINK_DIST_COUNT="$(echo "$FLINK_DIST" | wc -l)" # If flink-dist*.jar cannot be resolved write error messages to stderr since stdout is stored # as the classpath and exit function with empty classpath to force process failure if [[ "$FLINK_DIST" == "" ]]; then (>&2 echo "[ERROR] Flink distribution jar not found in $FLINK_LIB_DIR.") exit 1 elif [[ "$FLINK_DIST_COUNT" -gt 1 ]]; then (>&2 echo "[ERROR] Multiple flink-dist*.jar found in $FLINK_LIB_DIR. Please resolve.") exit 1 fi echo "$FLINK_DIST"}findSqlGatewayJar() { local SQL_GATEWAY SQL_GATEWAY="$(find "$FLINK_OPT_DIR" -name 'flink-sql-gateway*.jar')" local SQL_GATEWAY_COUNT SQL_GATEWAY_COUNT="$(echo "$SQL_GATEWAY" | wc -l)" # If flink-sql-gateway*.jar cannot be resolved write error messages to stderr since stdout is stored # as the classpath and exit function with empty classpath to force process failure if [[ "$SQL_GATEWAY" == "" ]]; then (>&2 echo "[ERROR] Flink sql gateway jar not found in $FLINK_OPT_DIR.") exit 1 elif [[ "$SQL_GATEWAY_COUNT" -gt 1 ]]; then (>&2 echo "[ERROR] Multiple flink-sql-gateway*.jar found in $FLINK_OPT_DIR. Please resolve.") exit 1 fi echo "$SQL_GATEWAY"}findFlinkPythonJar() { local FLINK_PYTHON FLINK_PYTHON="$(find "$FLINK_OPT_DIR" -name 'flink-python*.jar')" local FLINK_PYTHON_COUNT FLINK_PYTHON_COUNT="$(echo "FLINK_PYTHON" | wc -l)" # If flink-python*.jar cannot be resolved write error messages to stderr since stdout is stored # as the classpath and exit function with empty classpath to force process failure if [[ "$FLINK_PYTHON" == "" ]]; then echo "[WARN] Flink python jar not found in $FLINK_OPT_DIR." elif [[ "$FLINK_PYTHON_COUNT" -gt 1 ]]; then (>&2 echo "[ERROR] Multiple flink-python*.jar found in $FLINK_OPT_DIR. Please resolve.") exit 1 fi echo "$FLINK_PYTHON"}# These are used to mangle paths that are passed to java when using# cygwin. Cygwin paths are like linux paths, i.e. /path/to/somewhere# but the windows java version expects them in Windows Format, i.e. C:\bla\blub.# "cygpath" can do the conversion.manglePath() { UNAME=$(uname -s) if [ "${UNAME:0:6}" == "CYGWIN" ]; then echo `cygpath -w "$1"` else echo $1 fi}manglePathList() { UNAME=$(uname -s) # a path list, for example a java classpath if [ "${UNAME:0:6}" == "CYGWIN" ]; then echo `cygpath -wp "$1"` else echo $1 fi}# Looks up a config value by key from a simple YAML-style key-value map.# $1: key to look up# $2: default value to return if key does not exist# $3: config file to read fromreadFromConfig() { local key=$1 local defaultValue=$2 local configFile=$3 # first extract the value with the given key (1st sed), then trim the result (2nd sed) # if a key exists multiple times, take the "last" one (tail) local value=`sed -n "s/^[ ]*${key}[ ]*: \([^#]*\).*$/\1/p" "${configFile}" | sed "s/^ *//;s/ *$//" | tail -n 1` [ -z "$value" ] && echo "$defaultValue" || echo "$value"}######################################################################################################################### DEFAULT CONFIG VALUES: These values will be used when nothing has been specified in conf/flink-conf.yaml# -or- the respective environment variables are not set.######################################################################################################################### WARNING !!! , these values are only used if there is nothing else is specified in# conf/flink-conf.yamlDEFAULT_ENV_PID_DIR="/tmp" # Directory to store *.pid files toDEFAULT_ENV_LOG_MAX=10 # Maximum number of old log files to keepDEFAULT_ENV_JAVA_OPTS="" # Optional JVM argsDEFAULT_ENV_JAVA_OPTS_JM="" # Optional JVM args (JobManager)DEFAULT_ENV_JAVA_OPTS_TM="" # Optional JVM args (TaskManager)DEFAULT_ENV_JAVA_OPTS_HS="" # Optional JVM args (HistoryServer)DEFAULT_ENV_JAVA_OPTS_CLI="" # Optional JVM args (Client)DEFAULT_ENV_SSH_OPTS="" # Optional SSH parameters running in cluster modeDEFAULT_YARN_CONF_DIR="" # YARN Configuration Directory, if necessaryDEFAULT_HADOOP_CONF_DIR="" # Hadoop Configuration Directory, if necessaryDEFAULT_HBASE_CONF_DIR="" # HBase Configuration Directory, if necessary######################################################################################################################### CONFIG KEYS: The default values can be overwritten by the following keys in conf/flink-conf.yaml########################################################################################################################KEY_TASKM_COMPUTE_NUMA="taskmanager.compute.numa"KEY_ENV_PID_DIR="env.pid.dir"KEY_ENV_LOG_DIR="env.log.dir"KEY_ENV_LOG_MAX="env.log.max"KEY_ENV_YARN_CONF_DIR="env.yarn.conf.dir"KEY_ENV_HADOOP_CONF_DIR="env.hadoop.conf.dir"KEY_ENV_HBASE_CONF_DIR="env.hbase.conf.dir"KEY_ENV_JAVA_HOME="env.java.home"KEY_ENV_JAVA_OPTS="env.java.opts.all"KEY_ENV_JAVA_OPTS_JM="env.java.opts.jobmanager"KEY_ENV_JAVA_OPTS_TM="env.java.opts.taskmanager"KEY_ENV_JAVA_OPTS_HS="env.java.opts.historyserver"KEY_ENV_JAVA_OPTS_CLI="env.java.opts.client"KEY_ENV_SSH_OPTS="env.ssh.opts"KEY_HIGH_AVAILABILITY="high-availability.type"KEY_ZK_HEAP_MB="zookeeper.heap.mb"######################################################################################################################### PATHS AND CONFIG########################################################################################################################target="$0"# For the case, the executable has been directly symlinked, figure out# the correct bin path by following its symlink up to an upper bound.# Note: we can't use the readlink utility here if we want to be POSIX# compatible.iteration=0while [ -L "$target" ]; do if [ "$iteration" -gt 100 ]; then echo "Cannot resolve path: You have a cyclic symlink in $target." break fi ls=`ls -ld -- "$target"` target=`expr "$ls" : '.* -> \(.*\)$'` iteration=$((iteration + 1))done# Convert relative path to absolute path and resolve directory symlinksbin=`dirname "$target"`SYMLINK_RESOLVED_BIN=`cd "$bin"; pwd -P`# Define the main directory of the flink installation# If config.sh is called by pyflink-shell.sh in python bin directory(pip installed), then do not need to set the FLINK_HOME here.if [ -z "$_FLINK_HOME_DETERMINED" ]; then FLINK_HOME=`dirname "$SYMLINK_RESOLVED_BIN"`fiif [ -z "$FLINK_LIB_DIR" ]; then FLINK_LIB_DIR=$FLINK_HOME/lib; fiif [ -z "$FLINK_PLUGINS_DIR" ]; then FLINK_PLUGINS_DIR=$FLINK_HOME/plugins; fiif [ -z "$FLINK_OPT_DIR" ]; then FLINK_OPT_DIR=$FLINK_HOME/opt; fi# These need to be mangled because they are directly passed to java.# The above lib path is used by the shell script to retrieve jars in a# directory, so it needs to be unmangled.FLINK_HOME_DIR_MANGLED=`manglePath "$FLINK_HOME"`if [ -z "$FLINK_CONF_DIR" ]; then FLINK_CONF_DIR=$FLINK_HOME_DIR_MANGLED/conf; fiFLINK_BIN_DIR=$FLINK_HOME_DIR_MANGLED/binDEFAULT_FLINK_LOG_DIR=$FLINK_HOME_DIR_MANGLED/logFLINK_CONF_FILE="flink-conf.yaml"YAML_CONF=${FLINK_CONF_DIR}/${FLINK_CONF_FILE}### Exported environment variables #### 定义一些环境变量export FLINK_CONF_DIRexport FLINK_BIN_DIRexport FLINK_PLUGINS_DIR# export /lib dir to access it during deployment of the Yarn staging filesexport FLINK_LIB_DIR# export /opt dir to access it for the SQL clientexport FLINK_OPT_DIR######################################################################################################################### ENVIRONMENT VARIABLES######################################################################################################################### read JAVA_HOME from config with no default valueMY_JAVA_HOME=$(readFromConfig ${KEY_ENV_JAVA_HOME} "" "${YAML_CONF}")# check if config specified JAVA_HOMEif [ -z "${MY_JAVA_HOME}" ]; then # config did not specify JAVA_HOME. Use system JAVA_HOME MY_JAVA_HOME="${JAVA_HOME}"fi# check if we have a valid JAVA_HOME and if java is not availableif [ -z "${MY_JAVA_HOME}" ] && ! type java > /dev/null 2> /dev/null; then echo "Please specify JAVA_HOME. Either in Flink config ./conf/flink-conf.yaml or as system-wide JAVA_HOME." exit 1else JAVA_HOME="${MY_JAVA_HOME}"fiUNAME=$(uname -s)if [ "${UNAME:0:6}" == "CYGWIN" ]; then JAVA_RUN=javaelse if [[ -d "$JAVA_HOME" ]]; then JAVA_RUN="$JAVA_HOME"/bin/java else JAVA_RUN=java fifi# Define HOSTNAME if it is not already setif [ -z "${HOSTNAME}" ]; then HOSTNAME=`hostname`fiIS_NUMBER="^[0-9]+$"# Verify that NUMA tooling is availablecommand -v numactl >/dev/null 2>&1if [[ $? -ne 0 ]]; then FLINK_TM_COMPUTE_NUMA="false"else # Define FLINK_TM_COMPUTE_NUMA if it is not already set if [ -z "${FLINK_TM_COMPUTE_NUMA}" ]; then FLINK_TM_COMPUTE_NUMA=$(readFromConfig ${KEY_TASKM_COMPUTE_NUMA} "false" "${YAML_CONF}") fifiif [ -z "${MAX_LOG_FILE_NUMBER}" ]; then MAX_LOG_FILE_NUMBER=$(readFromConfig ${KEY_ENV_LOG_MAX} ${DEFAULT_ENV_LOG_MAX} "${YAML_CONF}") export MAX_LOG_FILE_NUMBERfiif [ -z "${FLINK_LOG_DIR}" ]; then FLINK_LOG_DIR=$(readFromConfig ${KEY_ENV_LOG_DIR} "${DEFAULT_FLINK_LOG_DIR}" "${YAML_CONF}")fiif [ -z "${YARN_CONF_DIR}" ]; then YARN_CONF_DIR=$(readFromConfig ${KEY_ENV_YARN_CONF_DIR} "${DEFAULT_YARN_CONF_DIR}" "${YAML_CONF}")fiif [ -z "${HADOOP_CONF_DIR}" ]; then HADOOP_CONF_DIR=$(readFromConfig ${KEY_ENV_HADOOP_CONF_DIR} "${DEFAULT_HADOOP_CONF_DIR}" "${YAML_CONF}")fiif [ -z "${HBASE_CONF_DIR}" ]; then HBASE_CONF_DIR=$(readFromConfig ${KEY_ENV_HBASE_CONF_DIR} "${DEFAULT_HBASE_CONF_DIR}" "${YAML_CONF}")fiif [ -z "${FLINK_PID_DIR}" ]; then FLINK_PID_DIR=$(readFromConfig ${KEY_ENV_PID_DIR} "${DEFAULT_ENV_PID_DIR}" "${YAML_CONF}")fiif [ -z "${FLINK_ENV_JAVA_OPTS}" ]; then FLINK_ENV_JAVA_OPTS=$(readFromConfig ${KEY_ENV_JAVA_OPTS} "" "${YAML_CONF}") if [ -z "${FLINK_ENV_JAVA_OPTS}" ]; then # try deprecated key FLINK_ENV_JAVA_OPTS=$(readFromConfig "env.java.opts" "${DEFAULT_ENV_JAVA_OPTS}" "${YAML_CONF}") fi # Remove leading and ending double quotes (if present) of value FLINK_ENV_JAVA_OPTS="$( echo "${FLINK_ENV_JAVA_OPTS}" | sed -e 's/^"//' -e 's/"$//' )"fiif [ -z "${FLINK_ENV_JAVA_OPTS_JM}" ]; then FLINK_ENV_JAVA_OPTS_JM=$(readFromConfig ${KEY_ENV_JAVA_OPTS_JM} "${DEFAULT_ENV_JAVA_OPTS_JM}" "${YAML_CONF}") # Remove leading and ending double quotes (if present) of value FLINK_ENV_JAVA_OPTS_JM="$( echo "${FLINK_ENV_JAVA_OPTS_JM}" | sed -e 's/^"//' -e 's/"$//' )"fiif [ -z "${FLINK_ENV_JAVA_OPTS_TM}" ]; then FLINK_ENV_JAVA_OPTS_TM=$(readFromConfig ${KEY_ENV_JAVA_OPTS_TM} "${DEFAULT_ENV_JAVA_OPTS_TM}" "${YAML_CONF}") # Remove leading and ending double quotes (if present) of value FLINK_ENV_JAVA_OPTS_TM="$( echo "${FLINK_ENV_JAVA_OPTS_TM}" | sed -e 's/^"//' -e 's/"$//' )"fiif [ -z "${FLINK_ENV_JAVA_OPTS_HS}" ]; then FLINK_ENV_JAVA_OPTS_HS=$(readFromConfig ${KEY_ENV_JAVA_OPTS_HS} "${DEFAULT_ENV_JAVA_OPTS_HS}" "${YAML_CONF}") # Remove leading and ending double quotes (if present) of value FLINK_ENV_JAVA_OPTS_HS="$( echo "${FLINK_ENV_JAVA_OPTS_HS}" | sed -e 's/^"//' -e 's/"$//' )"fiif [ -z "${FLINK_ENV_JAVA_OPTS_CLI}" ]; then FLINK_ENV_JAVA_OPTS_CLI=$(readFromConfig ${KEY_ENV_JAVA_OPTS_CLI} "${DEFAULT_ENV_JAVA_OPTS_CLI}" "${YAML_CONF}") # Remove leading and ending double quotes (if present) of value FLINK_ENV_JAVA_OPTS_CLI="$( echo "${FLINK_ENV_JAVA_OPTS_CLI}" | sed -e 's/^"//' -e 's/"$//' )"fi# -z是如果FLINK_SSH_OPTS的length为0的时候为true，-n是不为0的时候字符串为trueif [ -z "${FLINK_SSH_OPTS}" ]; then FLINK_SSH_OPTS=$(readFromConfig ${KEY_ENV_SSH_OPTS} "${DEFAULT_ENV_SSH_OPTS}" "${YAML_CONF}")fi# Define ZK_HEAP if it is not already setif [ -z "${ZK_HEAP}" ]; then ZK_HEAP=$(readFromConfig ${KEY_ZK_HEAP_MB} 0 "${YAML_CONF}")fi# High availabilityif [ -z "${HIGH_AVAILABILITY}" ]; then HIGH_AVAILABILITY=$(readFromConfig ${KEY_HIGH_AVAILABILITY} "" "${YAML_CONF}") if [ -z "${HIGH_AVAILABILITY}" ]; then # Try deprecated value DEPRECATED_HA=$(readFromConfig "high-availability" "$(readFromConfig "recovery.mode" "" "${YAML_CONF}")" "${YAML_CONF}") if [ -z "${DEPRECATED_HA}" ]; then HIGH_AVAILABILITY="none" elif [ ${DEPRECATED_HA} == "standalone" ]; then # Standalone is now 'none' HIGH_AVAILABILITY="none" else HIGH_AVAILABILITY=${DEPRECATED_HA} fi fifi# Arguments for the JVM. Used for job and task manager JVMs.# DO NOT USE FOR MEMORY SETTINGS! Use conf/flink-conf.yaml with keys# JobManagerOptions#TOTAL_PROCESS_MEMORY and TaskManagerOptions#TOTAL_PROCESS_MEMORY for that!if [ -z "${JVM_ARGS}" ]; then JVM_ARGS=""fi# Check if deprecated HADOOP_HOME is set, and specify config path to HADOOP_CONF_DIR if it's empty.if [ -z "$HADOOP_CONF_DIR" ]; then if [ -n "$HADOOP_HOME" ]; then # HADOOP_HOME is set. Check if its a Hadoop 1.x or 2.x HADOOP_HOME path if [ -d "$HADOOP_HOME/conf" ]; then # It's Hadoop 1.x HADOOP_CONF_DIR="$HADOOP_HOME/conf" fi if [ -d "$HADOOP_HOME/etc/hadoop" ]; then # It's Hadoop 2.2+ HADOOP_CONF_DIR="$HADOOP_HOME/etc/hadoop" fi fifi# if neither HADOOP_CONF_DIR nor HADOOP_CLASSPATH are set, use some common default (if available)if [ -z "$HADOOP_CONF_DIR" ] && [ -z "$HADOOP_CLASSPATH" ]; then if [ -d "/etc/hadoop/conf" ]; then echo "Setting HADOOP_CONF_DIR=/etc/hadoop/conf because no HADOOP_CONF_DIR or HADOOP_CLASSPATH was set." HADOOP_CONF_DIR="/etc/hadoop/conf" fifi# Check if deprecated HBASE_HOME is set, and specify config path to HBASE_CONF_DIR if it's empty.if [ -z "$HBASE_CONF_DIR" ]; then if [ -n "$HBASE_HOME" ]; then # HBASE_HOME is set. if [ -d "$HBASE_HOME/conf" ]; then HBASE_CONF_DIR="$HBASE_HOME/conf" fi fifi# try and set HBASE_CONF_DIR to some common default if it's not setif [ -z "$HBASE_CONF_DIR" ]; then if [ -d "/etc/hbase/conf" ]; then echo "Setting HBASE_CONF_DIR=/etc/hbase/conf because no HBASE_CONF_DIR was set." HBASE_CONF_DIR="/etc/hbase/conf" fifiINTERNAL_HADOOP_CLASSPATHS="${HADOOP_CLASSPATH}:${HADOOP_CONF_DIR}:${YARN_CONF_DIR}"if [ -n "${HBASE_CONF_DIR}" ]; then INTERNAL_HADOOP_CLASSPATHS="${INTERNAL_HADOOP_CLASSPATHS}:${HBASE_CONF_DIR}"fi# Auxiliary function which extracts the name of host from a line which# also potentially includes topology information and the taskManager typeextractHostName() { # handle comments: extract first part of string (before first # character) WORKER=`echo $1 | cut -d'#' -f 1` # Extract the hostname from the network hierarchy if [[ "$WORKER" =~ ^.*/([0-9a-zA-Z.-]+)$ ]]; then WORKER=${BASH_REMATCH[1]} fi echo $WORKER}readMasters() { MASTERS_FILE="${FLINK_CONF_DIR}/masters" if [[ ! -f "${MASTERS_FILE}" ]]; then echo "No masters file. Please specify masters in 'conf/masters'." exit 1 fi MASTERS=() WEBUIPORTS=() MASTERS_ALL_LOCALHOST=true GOON=true while $GOON; do read line || GOON=false HOSTWEBUIPORT=$( extractHostName $line) if [ -n "$HOSTWEBUIPORT" ]; then HOST=$(echo $HOSTWEBUIPORT | cut -f1 -d:) WEBUIPORT=$(echo $HOSTWEBUIPORT | cut -s -f2 -d:) MASTERS+=(${HOST}) if [ -z "$WEBUIPORT" ]; then WEBUIPORTS+=(0) else WEBUIPORTS+=(${WEBUIPORT}) fi if [ "${HOST}" != "localhost" ] && [ "${HOST}" != "127.0.0.1" ] ; then MASTERS_ALL_LOCALHOST=false fi fi done < "$MASTERS_FILE"}# 12、循环遍历slaves文件外面的节点readWorkers() { WORKERS_FILE="${FLINK_CONF_DIR}/workers" if [[ ! -f "$WORKERS_FILE" ]]; then echo "No workers file. Please specify workers in 'conf/workers'." exit 1 fi WORKERS=() WORKERS_ALL_LOCALHOST=true GOON=true while $GOON; do read line || GOON=false HOST=$( extractHostName $line) if [ -n "$HOST" ] ; then WORKERS+=(${HOST}) if [ "${HOST}" != "localhost" ] && [ "${HOST}" != "127.0.0.1" ] ; then WORKERS_ALL_LOCALHOST=false fi fi done < "$WORKERS_FILE"}# starts or stops TMs on all workers# TMWorkers start|stop# 10、启动所有的TaskManagerTMWorkers() { CMD=$1 # 11、读取slaves配置文件内容 readWorkers # 13、本机启动 if [ ${WORKERS_ALL_LOCALHOST} = true ] ; then # all-local setup for worker in ${WORKERS[@]}; do "${FLINK_BIN_DIR}"/taskmanager.sh "${CMD}" done else # 14、近程启动 # non-local setup # start/stop TaskManager instance(s) using pdsh (Parallel Distributed Shell) when available command -v pdsh >/dev/null 2>&1 if [[ $? -ne 0 ]]; then for worker in ${WORKERS[@]}; do ssh -n $FLINK_SSH_OPTS $worker -- "nohup /bin/bash -l \"${FLINK_BIN_DIR}/taskmanager.sh\" \"${CMD}\" &" done else PDSH_SSH_ARGS="" PDSH_SSH_ARGS_APPEND=$FLINK_SSH_OPTS pdsh -w $(IFS=, ; echo "${WORKERS[*]}") \ "nohup /bin/bash -l \"${FLINK_BIN_DIR}/taskmanager.sh\" \"${CMD}\"" fi fi}runBashJavaUtilsCmd() { local cmd=$1 local conf_dir=$2 local class_path=$3 local dynamic_args=${@:4} class_path=`manglePathList "${class_path}"` local output=`"${JAVA_RUN}" -classpath "${class_path}" org.apache.flink.runtime.util.bash.BashJavaUtils ${cmd} --configDir "${conf_dir}" $dynamic_args 2>&1 | tail -n 1000` if [[ $? -ne 0 ]]; then echo "[ERROR] Cannot run BashJavaUtils to execute command ${cmd}." 1>&2 # Print the output in case the user redirect the log to console. echo "$output" 1>&2 exit 1 fi echo "$output"}extractExecutionResults() { local output="$1" local expected_lines="$2" local EXECUTION_PREFIX="BASH_JAVA_UTILS_EXEC_RESULT:" local execution_results local num_lines execution_results=$(echo "${output}" | grep ${EXECUTION_PREFIX}) num_lines=$(echo "${execution_results}" | wc -l) # explicit check for empty result, because if execution_results is empty, then wc returns 1 if [[ -z ${execution_results} ]]; then echo "[ERROR] The execution result is empty." 1>&2 exit 1 fi if [[ ${num_lines} -ne ${expected_lines} ]]; then echo "[ERROR] The execution results has unexpected number of lines, expected: ${expected_lines}, actual: ${num_lines}." 1>&2 echo "[ERROR] An execution result line is expected following the prefix '${EXECUTION_PREFIX}'" 1>&2 echo "$output" 1>&2 exit 1 fi echo "${execution_results//${EXECUTION_PREFIX}/}"}extractLoggingOutputs() { local output="$1" local EXECUTION_PREFIX="BASH_JAVA_UTILS_EXEC_RESULT:" echo "${output}" | grep -v ${EXECUTION_PREFIX}}parseResourceParamsAndExportLogs() { local cmd=$1 java_utils_output=$(runBashJavaUtilsCmd ${cmd} "${FLINK_CONF_DIR}" "${FLINK_BIN_DIR}/bash-java-utils.jar:$(findFlinkDistJar)" "${@:2}") logging_output=$(extractLoggingOutputs "${java_utils_output}") params_output=$(extractExecutionResults "${java_utils_output}" 2) if [[ $? -ne 0 ]]; then echo "[ERROR] Could not get JVM parameters and dynamic configurations properly." echo "[ERROR] Raw output from BashJavaUtils:" echo "$java_utils_output" exit 1 fi jvm_params=$(echo "${params_output}" | head -n1) export JVM_ARGS="${JVM_ARGS} ${jvm_params}" export DYNAMIC_PARAMETERS=$(IFS=" " echo "${params_output}" | tail -n1) export FLINK_INHERITED_LOGS="$FLINK_INHERITED_LOGSRESOURCE_PARAMS extraction logs:jvm_params: $jvm_paramsdynamic_configs: $DYNAMIC_PARAMETERSlogs: $logging_output"}parseJmArgsAndExportLogs() { parseResourceParamsAndExportLogs GET_JM_RESOURCE_PARAMS "$@"}parseTmArgsAndExportLogs() { parseResourceParamsAndExportLogs GET_TM_RESOURCE_PARAMS "$@"}要害的函数 TMWorkers(启动TaskManager)、readMasters(读取masters信息)、readWorkers(读取worker信息)，定义了一些环境变量 ...

高清大图 : https://www.processon.com/v/643971c7cbedfb624bee1cff如感兴趣，点赞加关注，非常感谢！！！

Flink-learning 学训平台和 Flink CDC 专题课程来啦！ 为帮忙开发者更系统化、更便捷地学习利用 Flink，咱们搭建了 Flink-learning 学训平台，为开发者提供丰盛的图文、音频、视频、入手试验等多模式课程和学习素材，助力开发者晋升本身技术能力。首期 Flink CDC 专题正式公布，后续将逐渐上线更多精品课程。 本期 Flink CDC 专题从技术原理、生产利用到入手实际，蕴含 Flink 与 MongoDB、MySQL、Oracle、Hudi、Iceberg、Kafka 的上下游利用，全面介绍如何实现全增量一体化数据集成以及实时数据入湖入仓。 精彩领先看实现 Flink CDC MongoDB 的关键点在于：如何将 MongoDB 的操作日志转换为 Flink 反对的 changelog。 ——节选自《Flink MongoDB CDC 在 XTransfer 的生产实践》 XTransfer 孙家宝 参加形式长按下图扫码，登录 Flink-learning 学训平台，退出学习 随时记录学习进度，每天 10 分钟，入门上手 Flink CDC <u>**<p style="text-align:center"><font color=FF6a00 size=4>点击查看更多技术内容</font></p>**</u> 更多内容<p style="text-align:center"><img src="https://img.alicdn.com/imgextra/i3/O1CN0102Wuzs1dUVfQKlv59_!!6000000003739-2-tps-1920-675.png" alt="img" style="zoom:100%;" /></p> 流动举荐 阿里云基于 Apache Flink 构建的企业级产品-实时计算Flink版现开启流动：99 元试用 实时计算Flink版（包年包月、10CU）即有机会取得 Flink 独家定制卫衣；另包 3 个月及以上还有 85 折优惠！理解流动详情：https://www.aliyun.com/product/bigdata/sc

1、standalone cluster部署 flink的集群也是主从架构。主是jobManager,,从事taskManager。 布局： ip服务形容192.168.216.111jobManager、taskManager192.168.216.112taskManager192.168.216.113taskManager 1、下载 2、解压[root@hadoop01 local]# tar -zxvf /home/flink-1.9.1-bin-scala_2.11.tgz -C /usr/local/[root@hadoop01 local]# cd ./flink-1.9.1/ 3、配置环境变量export FLINK_HOME=/usr/local/flink-1.9.1/export PATH=$PATH:$JAVA_HOME/bin:$ZK_HOME/bin:$HADOOP_HOME/bin:$HADOOP_HOME/sbin:$KAFKA_HOME/bin:$FLINK_HOME/bin: 4、刷新环境变量[root@hadoop01 flink-1.9.1]# source /etc/profile[root@hadoop01 flink-1.9.1]# which flink 5、集群配置 配置三个配置文件-rw-r--r--. 1 yarn games 10327 Jul 18 2019 flink-conf.yaml-rw-r--r--. 1 yarn games 15 Jul 15 2019 masters-rw-r--r--. 1 yarn games 10 Jul 15 2019 slaves 配置flink-conf.yaml： 批改几个中央：jobmanager.rpc.address: hadoop01rest.port: 8081rest.address: hadoop01 配置masters：hadoop01:8081 配置slaves：hadoop01hadoop02hadoop03 6、散发到别的服务器[root@hadoop01 flink-1.9.1]# scp -r ../flink-1.9.1/ hadoop02:/usr/local/[root@hadoop01 flink-1.9.1]# scp -r ../flink-1.9.1/ hadoop03:/usr/local/并配置好其余服务器的环境变量。。。。。。 ...

1 基本概念Hoodie 的所有操作都是基于文件的读写，整个文件组织能够分为两类： 数据文件：parquet（列存）和 arvo（行存）格局，COW（Copy On Write）表的话每次写的时候做合并，只存在 parquet，MOR（Merge On Read）则会有 base file（parquet）和增量 log file（arvo），本文里咱们次要聊的是 MOR：时间轴文件：依据工夫线（instant time）记录对应的操作（compaction、delta commit 等）以及该操作以后处于的状态（REQUESTED、INFLIGHT、COMPLETED），文件里会记录该次操作关联的数据文件。Partition Path + File Id 定位一个 File Group => File Group Id = Partition Path + File IdFile Group + Base Instant Time 定位一个 File Slice.2 Flink+Hudi 执行流程 Hudi 在 HUDI-4397 中将 Rebalance 优化为 Hash 以防止压缩的时候呈现并发抵触。3 HoodieTableFactoryKeyGeneratorOptionsFlinkOptions3.1 配置 Options基于表定义设置配置，比方： 设置 hoodie record key 的获取策略（即怎么从 record 里拿到 hoodie record key）；设置 compaction 相干的配置；设置 hive 相干的配置；设置读相干的配置；设置写相干的配置；设置 source avro schema 的配置;设置 hoodie record key 和 partition key 相干的配置;......最优先的是主键，如果 table 设置了主键，则以主键作为 FlinkOptions.RECORD_KEY_FIELD 的值：if (pkColumns.size() > 0) { // the PRIMARY KEY syntax always has higher priority than option FlinkOptions#RECORD_KEY_FIELD String recordKey = String.join(",", pkColumns); conf.setString(FlinkOptions.RECORD_KEY_FIELD, recordKey);}Partitioned By 语法指定的 partition key 优先于 table properties： ...

1、Flink分布式运行架构执行原理： Client提交作业，相当于Spark的DriverActorSystem相当于Hadoop RPC，是用来进行节点之间通信的Client的程序DataFlow相当于是StreamGraph，而后通过优化成JobGraph由ActorSystem把JobGraph提交到JobManager节点JobManager对JobGraph引入并行度造成ExecutionGraph而后由TaskScheduler进行task之间的任务调度， 将task调配到TaskSlot外面运行，底层也是基于 ActorSystem进行交互TaskManager会返回task运行的状态信息给 JobManager，JobManager会将task运行的状态信息返回给客户端在⻚面上能够看到工作的执行状况，是由 TaskManager返回给JobManager，而后 JobManager返回给客户端的2、数据传输的策略随机分区(shuffle)最简略的重分区形式就是间接“洗牌”。通过调用DataStream的.shuffle()办法，将数据随机地调配到上游算子的并行任务中去 轮询分区(REBALANCE)通过调用DataStream的.rebalance()办法，就能够实现轮询重分区。rebalance应用的是Round-Robin负载平衡算法，能够将输出流数据平均分配到上游的并行任务中去 重缩放分区(rescale)重缩放分区其实和轮询分区十分类似。不同点是轮询分区是针对所有分区进行轮询，重缩放分区只对指定分区外部进行轮询。如下图所示，source并行度为2，上游flatMap并行度为4：其实就是分成了小组，在组内进行REBALANCE。通过调用DataStream的.rebalance() 播送(broadcast)简略说就是一份数据散发到上游所有的Task中。能够通过调用DataStream的broadcast()办法，将输出数据复制并发送到上游算子的所有并行任务中去 全局分区(global)全局分区也是一种非凡的分区形式。这种做法十分极其，通过调用.global()办法，会将所有的输出流数据都发送到上游算子的第一个并行子工作中去。这就相当于强行让上游工作并行度变成了1 自定义分区(Custom)当Flink提供的所有分区策略都不能满足用户的需要时，咱们能够通过应用partitionCustom()办法来自定义分区策略。在调用时，办法须要传入两个参数，第一个是自定义分区器（Partitioner）对象，第二个是利用分区器的字段，它的指定形式与keyBy指定key根本一样：能够通过字段名称指定，也能够通过字段地位索引来指定，还能够实现一个KeySelector * HASH对数据流进行keyBy/window、keyBy/reduce操作3、Task并行度和Slot的关系如果task的工作数量也就是并行度大于slot那么程序会无奈运行 一个TaksManager外面默认只有一个slot在task运行的过程中会进行算子合并，会产生operatorChain的状况，比如说KeyBy->MapOperator Chain的条件 : 数据传输策略是 forward strategy在同一个 TaskManager 中运行TaskManager会尽量保障task在同一个JVM外面运行，有利于晋升效率如下图，设置Source并行度为3，faltMap并行度为2，keyBy->sum->map并行度为2，Sink并行度为1，一共8个Task 如果全局并行度设置为1呢？ source -> flatmap 属于 operator Chain的状况，会将 souce->flatMap进行合并为一个taskkeyby sum -> map -> sink也是属于 oprator chain的状况，会将 keyby sum -> map -> sink进行合并为一个task上游task -> 上游task 因为两头有 keyby所以数据传输的策略是 keybased strategy，也就是HASH所以上述2个Task4、Flink四层图构造Flink程序从提交到运行，须要经验如下4个阶段 : Stream GraphJob GraphExecution GraphPhysical Execution GraphStream Graph和Job Graph是在客户端阶段实现的，而后client通过ActorSystem把JobGraph提交到JobManagerExecution Graph阶段会引入并行度Physical Execution Graph 进一步确定了数据寄存的地位和收发的具体形式

问题景象Flink 部署在K8S启动时，checkpoint目录须要配置成具体某台Hadoop集群的NameNode，如：env.setStateBackend(new FsStateBackend("hdfs://prod02:3333/user/flink-checkpoints")); 如果配置成nameservice模式, 如:env.setStateBackend(new FsStateBackend("hdfs://hztest/user/flink-checkpoints"));则会报错: 解决流程思考flink 启动时，未加载到hadoop 配置文件，以后hadoop配置文件寄存在flink工作的jar中，在classpath下，因而尝试应用外置hadoop配置文件形式加载。拷贝 hadoop的两个配置文件到部署目录的hadoopconf目录中。批改Dockerfile, 减少hadoop conf配置文件到镜像 FROM registry.cn-shanghai.aliyuncs.com/meow-cn/flink:1.13COPY flink-hudi.jar /opt/flink-hudi.jarCOPY hadoopconf/* /opt/hadoopconf/批改deployment.yaml 文件, 减少hadoop配置文件环境变量HADOOP_CONF_DIR - name: flink-main-container imagePullPolicy: Always env: - name: HADOOP_CONF_DIR value: /opt/hadoopconfFlink 启动后失常，然而始终无奈执行checkpoint2023-03-10 18:48:20,786 INFO org.apache.flink.runtime.checkpoint.CheckpointCoordinator [] - Failed to trigger checkpoint for job 3110562c050f0943caca089038709804 since Checkpoint triggering task Source: Custom Source -> DataSteamToTable(stream=default_catalog.default_database.kafka_source, type=STRING, rowtime=false, watermark=false) -> Calc(select=[CAST(UUID()) AS uuid, f0 AS message, CAST(DATE_FORMAT(NOW(), _UTF-16LE'yyyy-MM-dd hh:mm:ss')) AS event_time, CAST(DATE_FORMAT(NOW(), _UTF-16LE'yyyyMMdd')) AS ds]) -> row_data_to_hoodie_record (1/2) of job 3110562c050f0943caca089038709804 is not being executed at the moment. Aborting checkpoint. Failure reason: Not all required tasks are currently running.查看pod 列表,发现flink pod对应的taskmanager的pod 无奈启动, 应用kt get event |grep flink-hudi-event-log-taskmanager命令，进行查看，发现taskmanger 启动报错： ...

参考：https://dbaplus.cn/news-73-3561-1.htmlhttps://flink-learning.org.cn/developers/flink-training-course3/

摘要：本文整顿自阿里巴巴开发工程师，Apache Flink Committer 任庆盛，在 9 月 24 日 Apache Flink Meetup 的分享。次要内容包含：1.Flink CDC 技术比照与剖析2.Flink + Kafka 实时数据集成计划3.Demo：Flink+Kafka 实现 CDC 数据的实时集成和实时剖析一、Flink CDC 技术比照与剖析1.1. 变更数据捕捉（CDC）技术 狭义概念上，可能捕捉数据变更的技术统称为 CDC（Change Data Capture）。通常咱们说的 CDC 次要面向数据库的变更，是一种用于捕捉数据库中数据变动的技术。 CDC 的次要利用有三个方面： 数据同步，通过 CDC 将数据同步到其余存储地位来进行异地灾备或备份。数据散发，通过 CDC 将数据从一个数据源抽取进去后分发给上游各个业务方做数据处理和变换。数据采集，应用 CDC 将源端数据库中的数据读取进去后，通过 ETL 写入数据仓库或数据湖。 依照实现机制，CDC 能够分为两种类型：基于查问和基于日志的 CDC。基于查问的 CDC 通过定时调度离线工作的形式实现，个别为批处理模式，无奈保证数据的实时性，数据一致性也会受到影响。基于日志的 CDC 通过实时生产数据库里的日志变动实现，如通过连接器间接读取 MySQL 的 binlog 捕捉变更。这种流解决模式能够做到低提早，因而更好地保障了数据的实时性和一致性。 1.2. Flink CDC 的技术劣势 在上图中，咱们比拟了几种常见的 CDC 计划。相比于其余计划，Flink CDC 在性能上集成了许多劣势： 在实现机制方面，Flink CDC 通过间接读取数据库日志捕捉数据变更，保障了数据实时性和一致性。在同步能力方面，Flink CDC 反对全量和增量两种读取模式，并且能够做到无缝切换。在数据连续性方面，Flink CDC 充分利用了 Apache Flink 的 checkpoint 机制，提供了断点续传性能，当作业呈现故障重启后能够从中断的地位间接启动复原。在架构方面，Flink CDC 的分布式设计使得用户能够启动多个并发来生产源库中的数据。在数据变换方面，Flink CDC 将从数据库中读取进去后，能够通过 DataStream、SQL 等进行各种简单计算和数据处理。在生态方面，Flink CDC 依靠于弱小的 Flink 生态和泛滥的 connector 品种，能够将实时数据对接至多种内部零碎。1.3. Flink CDC 全增量一体化框架 ...

摘要：本文整顿自抖音电商实时数仓研发工程师张健，在 FFA 实时风控专场的分享。本篇内容次要分为四个局部： Flink CEP 简介业务场景与挑战解决方案实际将来瞻望点击查看直播回放 & 演讲PPT 一、Flink CEP 简介 Flink CEP 是基于 Flink Runtime 构建的简单事件处理库，它善于解决跨多个事件的简单规定匹配场景。例如检测用户下单后，是否超过半个小时没有产生领取行为；检测用户进入直播间后，是否有浏览商品随后退出购物车行为。 Flink CEP 有以下劣势： 反对跨多事件的规定匹配计算；具备精准一次计算语义；低提早、高吞吐等个性。二、业务场景与挑战随着抖音电商业务逐步趋于稳定和成熟，抖音电商实时数仓团队接到的实时数据规定类业务需要也逐渐增多，因而咱们开始尝试应用 Flink CEP 来反对这些业务场景。 上面列举两个典型的业务场景，并介绍一下 Flink CEP 在这些场景中遇到的一些挑战。 2.1 业务背景 第一是实时预警场景，它是十分典型的业务诉求，把用户看数据的形式从大屏“盯盘”转换为“依据规定检测后果，被动推送”，这无疑对一些要害业务问题的发现和洞察起到至关重要的作用。有如下三个具体案例： 直播实时检测场景。当检测到 10 分钟内观看人数继续上涨的直播间时，实时把音讯推送给直播达人，不便其及时做出直播策略的调整。比方调整解说商品的话术，发放粉丝礼物等等，进而晋升转化。实时风控的场景。当检测到有用户 30 分钟内创立了多笔订单，均未领取的状况，这个用户大概率是一个刷单用户。咱们会将这个用户实时推送给平台治理同学，并做出相应的封禁处理，促成平台的整体生态衰弱。售后征询场景。当检测到一个用户发动征询后，超过 30 分钟都未失去回复，会立刻告诉相干的客服人员及时回复，晋升整体的用户体验。第二是施行营销场景，它是基于实时数据驱动，依据定义的规定策略开掘目标群体，并依据业务指标做出精准营销投放的营销流动。有如下三个具体案例： 实时发券场景。针对一些价格比拟高的商品，当检测到用户下单后超过 30 分钟没有领取，那么该用户很有可能是感觉价格太高，所以始终犹豫要不要领取。这个时候能够及时给这个用户发放一些优惠券刺激购买，从而晋升平台的转化率。帮忙商家及时发现爆款商品场景。当检测到某款商品在五分钟内成交超过 1000 单时，会实时将这个商品的名称、品牌、库存等信息推送给商家，以便商家及时补货、直播间挂链接等行为，晋升经营效率。在线发处分场景。当检测到一个达人在实现电商大学学习后，一天内进行了电商开播或者公布了电商短视频等行为，就会对这个达人发放抖 dou+券等典礼处分,晋升整体达人的入驻率，进而给商家晋升更加多元的达人抉择。2.2. 业务挑战 第一，在规定配置方面存在灵活性有余的问题。以后无论是新增还是批改规定，都须要实时数仓的研发同学通过批改代码的形式来反对，这就导致研发同学须要频繁的对接业务。在一些极其的场景，比方双十一大促期间，一个研发同学往往须要同时应对接，二十多个经营同学的规定创立或者批改的诉求。业务需要也因为人力的单点阻塞问题迟迟无奈上线。 第二，规定与计算工作之间存在深度耦合。当每个规定都须要强制绑定一个计算工作时，就会导致计算工作的数量会随着规定的创立逐步增多。大量的工作会造成极高的运维老本和微小的资源节约，使整个零碎最终变得不可保护。以后面提到的商家自定义规定检测爆款商品的这个场景为例，思考到以后抖音电商宏大的商家群体，最终创立规定的数量可能是微小的，进而导致整个计算工作的数量也随之爆炸。 第三，以后 Flink CEP 反对的规定语义不够丰盛。列举两个典型的案例： 第一个案例，假如咱们须要检测用户屡次下单后，没有在一小时内实现领取行为。这种场景的特点是用户最初一次下单后，始终没有领取事件来触发这个规定实现匹配。以后 Flink CEP 不反对这种场景，但在实在的业务中这又是十分广泛的规定诉求。第二个案例，假如咱们须要检测用户在过来一小时内，是否实现浏览商品、退出购物车、下单行为。留神这里要求的三种行为不分先后顺序，只有在规定的工夫内实现以上三种行为即可。这种场景以后 Flink CEP 也不反对。三、解决方案实际 整体咱们分为四个阶段来解决上述的问题。 第一阶段，咱们对 Flink CEP 规定的外围信息进行了提炼和形象，并设计了一套清晰易懂的规定 DSL。这样就能够让业务同学自主配置业务规定，从而解决规定配置灵活性有余的问题。那么如何让业务配置的规定运行起来？ 第二阶段，咱们对 Flink CEP 计算工作进行革新，让其反对动静提交规定或者更新规定的能力，从而实现规定与计算工作之间的彻底解耦。解耦之后，不再强制要求每一个规定必须对应一个计算工作来运行。也就是同一个计算工作能够同时接管提交的多条规定，实现收敛整体计算工作的数量，晋升规定利用率的指标。 后面两个阶段要解决了规定配置的灵活性以及规定与其余工作的强绑定问题，然而依然没有解决规定自身的语义丰富性问题。因而，第三阶段，咱们次要针对特定业务的场景的规定诉求、降级和拓展规定的语义。 ...

摘要：本文整顿自米哈游大数据实时计算团队负责人张剑，在 FFA 行业案例专场的分享。本篇内容次要分为三个局部： 倒退历程平台建设将来瞻望点击查看直播回放 & 演讲PPT 一、倒退历程随着公司业务的倒退，实时计算需要应运而生。咱们依据重点的工作内容将倒退阶段划分为三个局部， 第一阶段是以 DataStream API 开发为主的 Flink 平台第二个阶段是以 Flink SQL 为主一站式开发平台第三阶段是一站式开发平台的性能深入和场景笼罩 第一阶段，以 DataStream API 开发为主的 Flink 平台，很好的解决了咱们对于实时计算的需要。但随着开发同学越来越多，大家发现基于 DataStream API 开发为主的实时计算平台，具备三个弊病，别离是开发成本高、版本易抵触、运维难度大，因而大家对 Flink SQL 的呼声就越来越高。 第二阶段，以 Flink SQL 为主一站式开发平台。次要的工作内容有：Flink SQL 能力晋升、指标和日志体系建设、元数据和血统治理。基于此，业务人员有了新的冀望。 第一，心愿平台可能更加智能化，升高用户的应用调参、调优等老本第二，心愿流量的稳定可能具备主动扩缩容的资源管理能力第三，心愿数据更具时效性。比方数据入仓、入湖后分钟级可查，或者基于近实时数仓开发 第三阶段，一站式开发平台性能深入和场景笼罩。次要的工作和将来要继续做的工作蕴含如下几个方面： 第一，工作资源的动态和动静调优能力第二，资源的弹性扩缩容能力第三，增强近实时数仓的建设 上面咱们进入平台的整体架构，从下图中能够看到平台总体蕴含三个局部，别离是用户权限及鉴权、性能和服务模块、以及环境和资源性能。 性能和服务次要蕴含作业大盘、概览、开发、运维、日志、元数据、血统、监控告警、资源调优、主动扩缩容、弹性资源管理以及平安管控等。 二、平台建设那么基于这样的实时计算平台，咱们是如何建设的呢？围绕 Flink SQL 或者平台化的次要工作有如下四个方面： 第一，语义表白和控制能力的建设第二，资源调优和弹性能力的建设第三，指标体系建设第四，近实时数仓建设截止目前，Flink SQL 占比总任务数曾经在 90%以上，极大的进步了大家的开发效率。上面咱们将对每一个局部进行具体的解说，来看一看具体都是怎么做的。 DataStream API 相较于 Flink SQL 有如下几个长处： 第一，算子并行度和传输方式可控第二，执行图直观易于了解第三，状态保留工夫能够别离设置。但在转变到 SQL 的时候，会产生一些问题。基于此，咱们举个例子，来看一看为什么算子并行度和传输方式不可控了。 比方用户定义了一个 UDF 函数，用来解决 Kafka 数据源的某一个日志，而后将这个解决后的数据写入上游的 MySQL 或者其余存储。咱们假设 Kafka 某一个 Topic 分区有 10 个，整个工作的并行度设置为 20。这个时候就会发现，UDF 理论只会解决 10 个并行度的数据。Flink SQL 须要怎样才能拓展呢？ ...

Apache Flink 作为流批一体的计算引擎，多年来在流批一体方向继续摸索和投入。当初，Flink 曾经是流计算畛域的事实标准，在批处理畛域也越来越成熟，并在越来越多的公司胜利落地。为了进一步帮忙用户落地 Flink Batch 技术，及时响应用户遇到的问题和需要，咱们心愿能够与社区用户和开发者建设一个定期交换的平台，帮忙用户和开发者去理解 Flink Batch 以及流批一体的倒退方向和开发动静，分享生产落地教训，并协调开发奉献工作。 因而，咱们决定开始定期组织公开的线上社区开发者会议，并邀请了 Apache Flink PMC 和 Committer 们，以及一线互联网公司的技术专家们，一起参加分享和探讨，也欢送任何感兴趣的开发者和用户参加互动。咱们将采纳中文，不便与国内用户更深刻的交换。 咱们会提前一周左右，在 Apache Flink 微信公众号上颁布下期会议的会议工夫，并征集会议议题。任何人都能够在会议文档中提交想探讨的议题。议题能够是某个批处理性能需要的探讨或是 Bug 的反馈，也能够是本人团队在应用和上线 Flink Batch 过程中的实际分享和踩坑教训，也能够是对 Apache Flink 社区建设的倡议。 会议阐明会议工夫2 月 8 日 （周三）早晨 19:00 到 20:00。 会议嘉宾本次开发者会议邀请到了 Apache Flink 多位外围 PMC/Committer，以及来自快手、Shopee、字节跳动、蚂蚁金服、eBay 等一线技术专家们来与开发者们分享、探讨和互动。 会议议题Flink Batch 在 v1.17 中的最新开发进展Flink Batch 最新 TPC-DS 性能后果分享Flink Batch 在业界公司的落地状况和实践经验Flink Batch Roadmap 探讨参会形式社区会议采纳 Google Meet，点击链接即可入会，无需装置软件：https://meet.google.com/wvp-d... 欢送所有社区开发者和用户退出，一起分享探讨，一起打造一款世界级的流批一体计算引擎！ 更多 Flink Batch 相干技术问题，可扫码退出社区钉钉交换群～ 点击立刻参会～ 更多内容 流动举荐 ...

摘要：本文整顿自网易互娱资深工程师, Flink Contributor, CDC Contributor 林佳，在 FFA 实时风控专场的分享。本篇内容次要分为五个局部： 实时风控业务会话会话关联的 Flink 实现HTAP 风控平台建设晋升风控后果数据能效倒退历程与展望未来点击查看直播回放 & 演讲PPT 家喻户晓，网易互娱的外围业务之一是线上互动娱乐应用服务，比方大家耳熟能详的梦幻西游、阴阳师等都是网易互娱的产品。不论是游戏产品还是其余利用，都须要做出好的内容来吸引用户进行利用内购买，进而产生盈利。 当用户在商城里点击商品进行购买的时候，会弹出领取界面，进行验证、领取后，就能够收到道具了。这个过程对于用户来说往往都是一些非常简单的操作，但为了保障这个过程能够正确结算、发货，整个领取流程其实逾越了很多服务提供商和终端，走了一条相当简单的调用链路。这些不同的业务节点之间会产生很多互相的调用关系，进而产生一些异构的日志、数据、记录。 因为通过了网络，其中的数据可能会有肯定工夫水位线的不统一、提早，甚至数据失落的状况，且自身这些数据又很可能是异构的，就更增大了咱们对这些数据进行剖析和应用的难度。 如果咱们须要用这些数据进行高时效性的故障排查或者危险管制，就势必须要研制一套计划，来适配这样技术需要。为了解决以上的问题，咱们以 Flink 为计算引擎构建了一套实时风控平台，并为他起名为 Luna，上面我将为大家进行具体的介绍。 一、实时风控业务会话 常见的线上领取逻辑是，当用户在利用上点击商城的道具进行利用内购买的时候，用户的客户端终端就会到计费零碎进行下单，取得本次下单的订单信息。 而后咱们的客户端会弹出领取界面，用户进行渠道付款。 当领取实现后，咱们会把渠道返回给客户端的领取凭证回传给计费零碎，计费零碎会去渠道验证凭证是否无效。 如果是无效的，就会告诉游戏服务器发货，这个时候咱们的客户端才会收到道具。这就是从用户点击到最终收到道具的整个流程。 从这个曾经极度简化了的领取模型能够看到，不同的公司、服务提供商、部门、服务零碎会产生了一系列会话下的数据。如果咱们能把这些数据收集起来，进行肯定的解决后，还原过后用户操作的现场。这将对经营运维人员在定位故障、排查故障，甚至整个业务环境的宏观剖析都有着十分重要的价值。 而剖析的关键点是，咱们如何还原这个行为的现场，咱们把这个行为的现场叫风控业务会话，即由一次用户行为所引发的，须要多个零碎合作实现、同时触发多个申请、产生逾越多个服务提供方调用的全过程。 这里须要留神的是，业务会话逾越了多个互相独立的申请链路，且没有对立全局的 trace-id 能够被提前置入所有的数据中。 因为咱们的业务会话须要逾越多个申请链路，所以在数据关联剖析的时候就存在很多难题。比方： 多服务、多申请产生的异构后果难以间接关联。调用程序简单，存在并发、异步的状况。时间跨度大、业务水位不同步。以前在解决领取丢单、领取一次反复发货等问题的时候，往往只能通过经营人员去解决，这就十分依赖于运维人员的教训了。并且在这些大量的数据里，会有十分多冗余和无用字段，还有可能会有一些非常复杂的嵌套关系。这些都有可能让运维人员在判断时产生错判和误判。此外，还会给运维人员带来十分多的重复性工作，从而使得人力能效低下，把工夫节约在反复的事件上。 前文也提到了开源 Tracing 计划，往往须要依赖全局的 trace-id。对于新的零碎，咱们能够提前设计 trace-id 打点。然而对于有历史包袱的零碎来说，他们往往不违心批改跟踪来跟踪打点，那么这个时候传统的计划就走不通了。 在这种状况下，如果咱们要进行业务会话还原，就须要设计一套新的计划。这套计划咱们心愿能够具备以下性能： 实时宏观业务会话检索与查错。实时宏观业务环境统计与风控。业务会话级数据能效开掘与晋升。 从还原业务会话到应用数据做 HTAP 实时风控平台的全过程，咱们应用 Flink 生产原始数据，依据平台上提前配置好的剖析模板，实时还原出业务会话。而后把业务会话的后果存储存起来，并为它打上咱们提前设置好的一些论断模型，产生的风控论断。 对于存储起来的这些宏观会话进一步被聚合，进而产生整个业务环境上的宏观统计量，以反对咱们在整个平台上的风控剖析需要。 二、会话关联的 Flink 实现Flink 是实时计算的施行规范，基于此咱们毫无疑问地抉择了它。 那么实时业务会话关联在 Flink 零碎上，咱们心愿能够做出怎么的成果呢？ 第一，零侵入。即无需对现有业务进行改变，也无需有全局的跟踪 ID，就能够做到业务会话的还原。第二，跨数据源。因为咱们的业务往往须要逾越 n 种数据源，所以咱们心愿这 n 种数据源都能够被这个零碎所反对，比方日志、维表、事实表、REST 接口等。第三，实时。实时产生后果，无需期待 T+1。第四，低代码。咱们心愿基于剖析需要，能够通过向导式的配置，来产生实时的剖析模板，并对宏观统计报表，能够配置式的进行多维度聚合。 ...

近期举办的 2022 第四届实时计算 Flink 挑战赛中，在各位大佬的领导下，实现了本课题的设计和实际，当初把本计划的设计思路分享给大家，心愿通过本次教训分享能够为其它企业带来一点实时数据应用的新思路。 家喻户晓，实时数仓落地是一个难点，尤其是金融行业，还没有呈现真正所谓的实时报表。金融行业个别案例的实时数仓是在较窄场景、较多限度下的尝试，还不可能称之为实时数仓，如银行广泛的实时报表业务都无奈满足。以后亟需设计实现一套可能落地的金融行业的实时报表计划，来满足业务场景对数据时效性越来越高的需要。 本文内容首先介绍了银行业常见的实时场景和解决方案，而后针对银行业报表依赖维度表计算的特点，提出了基于 Flink Table Store 作为数据存储，进而构建流式数仓的解决方案。 在正式开始之前呢，简略介绍一下中原银行的根本状况。中原银行是河南全省惟一的省属法人银行，总资产冲破 1.2 万亿，在国内城市商业银行排名第 8 位。本团队是负责中原银行的实时计算业务，包含实时的采集、加工和剖析全链路。 一、金融行业实时数仓现状剖析1.1 动账场景介绍 数仓建模有范式建模和维度建模，银行业采纳的是维度建模，其中分为事实表和维度表。 事实表：刻画行为的，个别用来统计交易笔数，交易金额，业务量等。 维度表：形容后果和状态的，常见的用户手机号、身份证号、所属的机构等不常常更新的数据，但其中银行业比拟重要的有“账户余额”，客户余额会随着动账交易而频繁更新。 本文以银行典型的动账场景为例，一次动账操作其实是一个事务，至多操作两张表，第一张比拟好了解，就是交易流水表，记录转账的一次行为；第二张则是用户的属性表，其中有一个字段是用户的余额，须要随着动账的交易流水表同步更新，下面的两个表是两次转账的示例。 在这个转账场景下进行剖析 流水表的特点：次要是 Insert 操作，记录行为信息，适宜增量计算，如统开户、取款、贷款、购买理财等事件行为。利用的场景有实时营销，如大额动账揭示，工资代发，理财产品购买等；实时反欺诈的申请反欺诈、交易反欺诈；在贷后治理也有利用，如监控用户入账行为，提供给零贷贷后临期催收、扣款等。 客户属性表的特点：次要是 Update 操作，记属性信息，客户的贷款、贷款、理财、基金、保险等产品的余额是在维度表中，所以常应用维度表全量计算资产信息，如资产余额类的计算，计算某分支行的总贷款余额等。利用的场景次要是实时报表、实时大屏：如对公 CRM、批发 CRM；经营治理；资产负债治理等。 针对于银行业这两种典型的动账场景，有三种解决方案。上面一一介绍不同计划实用的场景和有哪些局限。 1.2 基于 Kafka 的 ETL 该架构可能解决的问题，大多是基于事实表的增量计算，曾经在行内有大量的落地案例，但无奈解决银行业的基于维度表的全量计算。另外该计划很难造成规模化的数据分层复用，Kafka 存在数据无奈查问和长期长久化等问题。这种烟囱式的 case by case 开发阶段，本行曾经经验过了，生产上也有大量的落地场景，实时工作达到了 300+个。 1.3 基于微批的 ELT 为了解决银行业大量基于维度表的统计分析场景，来看一下进行了哪些形式的摸索。总结来说，是一种先载入后剖析，也就是 ELT 的形式。过程是这样的，先实时采集-> 而后间接实时载入->最初在实时 OLAP 查问阶段进行逻辑的加工。 在ELT摸索的的初期，咱们采纳过微批全量计算的形式，在数据实时地写入到数据库后，定时执行全量加工逻辑，相似于离线数仓有跑批的概念，只不过每天跑批缩短到了小时级别或分钟级别跑一次批，来达到准实时加工的成果。不言而喻，这种形式是不可取的，存在时效性差、跑批不稳固等问题。 1.4 基于视图的 ELT 随着 MPP 数据库的倒退，查问性能失去了极大的晋升，本行应用 StarRocks 引擎，通过 View 视图嵌套加工逻辑的形式也进行了摸索，也就是把业务数据库的数据以 CDC 形式，载入 MPP 数据库的明细层，查问剖析逻辑应用 View 封装，在查问触发时间接计算，这种形式也能够解决基于维度表的全量计算，但每次查问资源耗费太大，撑持大数据高频率的查问操作比拟艰难，无奈大范畴利用推广。 ...

1. Join 算子数据处理流程在流式解决数据的过程中，当本侧到来一条新的数据时，咱们无奈预测对侧是否在之后还会到来可能和该数据关联上的数据，且思考到时效性，咱们也无奈始终期待右侧所有数据到齐后再关联下发，因而 Flink 的解决形式是先将以后数据和对侧曾经到来过的所有数据（如果设置了 TTL，则是对应 TTL 时间段的数据）进行关联计算，并将关联后果下发，如果是 Outer Join，则还要思考关联不上须要下发一条对侧为 null 的数据。除此之外，咱们还要讲该数据记录在状态中，以不便后续对侧数据来做镜像的关联解决。 2. 状态视图而 Regular Join 的状态构造依据是否蕴含惟一键以及是否是 Outer Join 共有六种： Inner/Outer状态RocksDB 语义JoinRecordStateViews.JoinKeyContainsUniqueKeyInnerValueState<RowData>getJoinRecordStateViews.InputSideHasUniqueKeyInnerMapState<RowData, RowData>seekJoinRecordStateViews.InputSideHasNoUniqueKeyInnerMapState<RowData, Integer>seekOuterJoinRecordStateViews.JoinKeyContainsUniqueKeyOuterValueState<Tuple2<RowData, Integer>>getOuterJoinRecordStateViews.InputSideHasUniqueKeyOuterMapState<RowData, Tuple2<RowData, Integer>>seekOuterJoinRecordStateViews.InputSideHasNoUniqueKeyOuterMapState<RowData, Tuple2<Integer, Integer>>seekOuter Join 的状态视图相比 Inner Join 会多记录一个要害属性：numOfAssociations，用来标识该条 record 关联上的对侧 record 的数量，这是因为 Outer Join 相比 Inner Join 有一个非凡的点，即没关联到数据也会下发，因而 Outer Join 须要通过 numOfAssociations 的值来确定以后该下发的关联数据是什么。以 Left Outer Join 为例，当 numOfAssociations 为 0 时，会下发 +I [left-record, null]，前面 numOfAssociations 被更新为 1 时，则须要先下发 -D [left-record, null] 回撤之前的关联后果，再下发最新的关联后果 +I [left-record, right- record]。同理，当 numOfAssociations 被从 1 更新为 0 时（比方收到一条右流的回撤信息），则须要下发 -D [left-record, right-record] 回撤之前的关联后果，再下发最新后果 +I [left-record, null]。 ...

摘要：本文整顿自 Disney 广告智能执行总监郝又超、Disney 广告智能实时计算负责人李丁哲，在 FFA 的分享。本篇内容次要分为四个局部： Disney 流媒体广告与实时利用业务场景实现实时平台构建将来瞻望点击查看直播回放 & 演讲PPT 一、Disney 流媒体广告与实时利用说到 Disney 流媒体业务包含 Hulu，大家可能并不相熟，因为咱们在国内的业务并没有落地。Hulu 是在 15 年前由 Disney、福克斯和 NBC 独特发动成立的，当初曾经在美国外乡是一家头部的流媒体平台了。 2019 年，Disney 收买了福克斯从而失去的 Hulu 的经营控制权，因而也失去了 Hulu 上的广告平台这样一个优质资源。因为作为传统的流媒体公司，Disney 原来并没有本人的技术广告平台，而在 2019 年之后，Disney 也陆续的发力线上流媒体，推出了 Disney+，ESPN+，Star+等多个流媒体品牌。上面来具体看一下 Disney 和 Hulu 的流媒体以及广告业务的数据。 2.35 亿，是截止到往年十月份，Disney 流媒体包含 Disney+，Hulu，ESPN+，Star+在寰球的订阅用户。这是一个什么概念呢？Netflix 曾经在寰球经营了超过十年，咱们在往年 7 月份就曾经超过了它寰球的订阅用户数，且咱们的订阅用户数是以家庭为单位的，所以理论触达的个人用户可能有 7 -10 亿。 Hulu 是以后 Disney 流媒体广告业务的次要起源，每天投放数亿 15 秒、30 秒长的视频广告，而每抉择一个广告都会产生几十甚至上百个事件，对数据平台有着极高的挑战，随着 Disney+上 12 月份行将上线广告，这种挑战预期将数倍增长。 接下来给大家略微介绍一下 Disney 的流媒体广告数据平台。大略分为两层，一层是底层的数据和算法，另一层是利用和服务。 数据和算法次要包含三局部： 用户数据。次要通过以用户和用户身份为次要维度来汇聚用户的行为数据，从而对数据交换以及广告所须要的定向进行人群圈选的外围能力。经营数据。次要包含两局部： 一部分是通过以广告的曝光为外围，汇聚所有的广告曝光、投放、转化以及用户交互的数据，造成 Event Store。另一方面是通过对 Event Store 在广告的订单维度上进行进一步聚合，提供各种的 KPI。这些聚合通常是实时的，这就是 Flink 在咱们广告平台上次要的利用场景。机器学习平台。次要通过咱们丰盛的数据，从用户、广告商以及 Disney 的外围的业务指标进行优化。能够说数据和算法提供的利用和服务，驱动着咱们整个广告生命周期的各个环节。比方: ...

2022 年悄悄闭幕，Apache Flink 社区又迎来了蓬勃发展的一年。社区共公布了 2 个 Flink 主版本，孵化出了新的流批一体表格存储我的项目，举办了 13 场线上线下流动，包含别离面向亚洲（北京）和欧美（旧金山）的 2 次 Flink Forward 大会，并向开发者推送了 100+技术文章，围绕实时湖仓、实时风控、数据集成、流批一体等外围场景进行了深度技术解读和最佳实际的传递，呈现出了一个一直凋敝的开源、凋谢的开发者社区。期待在 2023 年能与寰球开发者共同努力，一起推动 Flink 社区在全球化生态市场中取得更大的胜利。 接下来，咱们将通过 Evolution、Diversity、Connection 三个关键词，从年度最佳实际、核心技术演进、开源技术生态等多维度盘点过来一年的成绩，与各位开发者一起见证社区成长。 业界年度奖项咱们一起见证了 Flink 开源我的项目的技术创新与高速倒退。Flink 间断两年蝉联 Apache 软件基金会财年报告最沉闷我的项目，用户交换水平、开发活跃度、影响力等多项指标，在整个 Apache 软件基金会的社区中名落孙山。在工信部电子规范院开源我的项目成熟度评估中取得“优良一级”评级，并播种了 Segmentfault 思否、CSDN、IT168 等行业媒体赞美。 感激各位开发者、用户、行业媒体、权威机构的反对和认可，置信 2023 年 Flink 社区将会获得更大的问题！ 社区精髓内容2022 年发版回顾官宣｜Apache Flink 1.16 发布公告 Apache Flink Table Store 0.2.0 公布 Flink CDC 2.3 公布，继续优化性能，更多连接器反对增量快照，新增 Db2 反对 Apache Flink ML 2.1.0 发布公告 年度最佳实际美团基于 Flink 的实时数仓平台建设新进展 钱大妈基于 Flink 的实时风控实际 流批一体在京东的摸索与实际 Flink 在米哈游的落地实际 基于 Flink 构建大规模实时风控系统在阿里巴巴的落地 核心技术演进FFA 2022 主会场 Keynote：Flink Towards Streaming Data Warehouse Flink 1.15 新性能架构解析：高效稳固的通用增量 Checkpoint Flink 1.16：Hive SQL 如何平迁到 Flink SQL ...

摘要：本文整顿自阿里巴巴高级技术专家付典，在 FFA 核心技术专场的分享。本篇内容次要分为四个局部： PyFlink 倒退现状介绍PyFlink 最新性能解读PyFlink 典型利用场景介绍PyFlink 下一步的倒退布局点击查看直播回放 & 演讲PPT 一、PyFlink 倒退现状介绍 很多 PyFlink 的新用户都会问这样一些问题，PyFlink 是否成熟？性能是否齐全？性能怎么样？在这里，咱们针对用户的这样一些问题，进行一个具体的解读。 首先，在性能层面，PyFlink 曾经对齐了 Flink Java API 中的绝大多数性能。用户应用 Java API 能够实现的性能，基本上都能够用 Python API 实现得进去。 同时，PyFlink 还面向 Python 用户提供了很多特有的能力，比如说 Python UDF、Pandas UDF 等，容许用户在 PyFlink 作业中应用各种 Python 三方库。 在部署模式上，PyFlink 反对各种常见的部署模式，比如说 YARN、kubernetes、Standalone 等，这意味着用户能够依据须要，灵便地抉择作业的部署模式。 除了性能层面之外，性能也是很多用户十分关怀的。在性能上，PyFlink 也做了很多优化，首先，在执行打算层面，PyFlink 做了一系列的优化，尽可能优化作业的物理执行打算，比方算子交融。 当作业的物理执行打算确定之后，在 Python 运行时，PyFlink 通过 Cython 实现了 Python 运行时中外围链路的代码，尽量升高 Python 运行时中框架局部的开销。对于 Cython 有所理解的同学应该晓得，Cython 在执行时会被编译成 native 代码来执行，性能十分高。 同时，PyFlink 还在现有的过程模式的根底之上，引入了线程执行模式，以进一步晋升 Python 运行时的性能。线程执行模式在 JVM 中执行用户的 Python 代码，通过这种形式，在一些典型利用场景中，性能甚至能够追平 Java，这一块前面咱们还会具体介绍。 ...

摘要：本文整顿自 Apache Flink Contributor 俞航翔 9 月 24 日在 Apache Flink Meetup 的演讲。次要内容包含： Checkpoint 性能优化之路解析 Changelog一览 State/Checkpoint 优化点击查看直播回放 & 演讲PPT 一、Checkpoint 性能优化之路 Flink 作为一个 Stateful 计算引擎，State 是其十分重要的概念，它反对 Stateful 算子通过 State 记录多个 Events 之间的信息，并在 Checkpoint 时做状态长久化，存储全局一致性快照，在复原时通过 Resume Checkpoint 以及 Replay 来实现不同语义的一致性保障。 容错是长期运行的流式零碎十分重要的局部，而 Checkpoint 的次要目标就是解决 Failover 问题。基于此指标，它的生命周期齐全由 Flink 治理。因而对于不同的 StateBackend 能够用特定的原生格局进行存储，利用 StateBackend 的外部机制比方 Incremental Checkpoint 做进一步优化等。 基于以上机制， Checkpoint 目前的设计指标就是更轻量以及更疾速的复原。 那 Flink 在 Chekpoint 性能上做了哪些优化呢？ 最晚期，在反对轻量级异步 Snapshot 算法后， Flink Checkpoint 的性能往前迈了一大步。在该机制下，Flink 将 Barrier 作为非凡 Record 在 Graph 中流动，同时将耗时较大的文件上传等工作放到异步过程中进行，极大升高了对主流程的影响。 ...

摘要：本文整顿自阿里云 Flink 存储引擎团队负责人，Apache Flink 引擎架构师 & PMC 梅源在 FFA 核心技术专场的分享。次要介绍在 2022 年度，Flink 容错 2.0 这个我的项目在社区和阿里云产品的停顿。内容包含： Flink 容错复原 2.0 我的项目简介及思考2022 年度 Flink 容错 2.0 我的项目停顿点击查看直播回放 & 演讲PPT 一、Flink 容错复原 2.0 我的项目简介及思考首先来概括的看一下 Flink 容错的链路，次要包含四个过程：做快照（Checkpointing），发现失败节点（Failure Detection），从新调度（Re-Scheduling）和状态复原（State Recovery）。 在一个 Flink 作业中，数据从数据源通过各个算子的解决最终写入 Sink。其中有些算子须要记录数据处理的两头后果，会临时把两头后果缓存在算子外部，即算子的状态中。如果这个 Flink 作业因为各种起因呈现失败或者谬误，就须要从新复原这些状态，因而咱们须要对状态进行周期性快照，即 Checkpointing 过程。因为快照很频繁，所以须要 Checkpointing 过程稳固、轻量并保障胜利。 如果一个节点挂了，须要疾速发现失败节点，并实现相应的清理工作。 而后生成新的作业，并从新调度，实现部署。 当作业从新调度之后，须要从最新的快照中复原算子的中间状态，也就是 State Recovery 状态复原。 从下面的形容不难看出，容错复原是一个全链路的过程，包含给状态做快照，发现节点失败，从新调度部署以及复原状态。另一方面容错复原也是个须要从多个维度来思考的问题，包含容错老本、对失常解决的影响、数据一致性保障的水平、以及在整个容错复原过程中的行为表现（比方是否须要满速 TPS 的保障和一直流的保障）等等。另外须要指出的是在云原生背景下，容器化部署带来了一些新的限度和便当，这些都是咱们在设计新一代容错时不能漠视的中央。无关这个局部更具体的内容能够参考去年的 talk “Flink 新一代流计算和容错——阶段总结和瞻望” 2022 年咱们的工作次要集中在 Checkpointing，Scheduling 和 State Recovery 这三个局部。在 Checkpointing 这个局部，咱们实现了分布式快照架构的降级： ...

摘要：本文整顿自阿里云高级技术专家宋辛童 (五藏)，在 FFA 2022 核心技术专场的分享。本篇内容次要分为五个局部： Flink Shuffle 的演进流批交融云原生自适应Shuffle 3.0点击查看直播回放 & 演讲PPT 一、Flink Shuffle 的演进 在整个 Shuffle 的演进过程中，其实并没有明确提出过所谓 Shuffle 1.0 和 2.0 的概念。但从它的技术倒退经验中，咱们能把它分成如上图所示的两个阶段。 在 Shuffle 1.0 阶段，Shuffle 只具备根底的数据传输能力，Flink 我的项目也处于绝对年老的阶段。 在 Shuffle 2.0 阶段，咱们对 Shuffle 做了一系列优化。 在性能方面，咱们对数据的序列化，底层网络的内存拷贝进行了优化，并针对 Batch 场景设计了 Sort-Based Blocking Shuffle，这种 Shuffle 形式可能对磁盘 IO 会更加敌对。在稳定性方面，咱们引入了 Credit-Based 流控机制，这种机制会比本来依赖于 TCP 的反压机制更具稳定性。此外，社区还引入了 Buffer-Debloating 机制，使其可能在反压的状态下缩小数据积压对 checkpoint 的影响。在流批一体方面，咱们将 Shuffle 模块进行 Service 插件化重构，让第三方开发的 Shuffle 实现成为可能。除此之外，咱们还为批场景中的 Remote Shuffle Service 技术铺垫了路线。综上咱们能够发现，不论是性能还是稳定性，都是 Flink 上大规模生产必备的能力，而流批一体是 Flink 社区过来倒退的次要方向之一。从整个 Shuffle 2.0 阶段，咱们发现 Flink Shuffle 曾经趋于成熟，在生产中体现优异。 ...

摘要：本文整顿自满帮实时数据团队 TL 欧锐，在 FFA 2022 行业案例专场的分享。本篇内容次要分为四个局部： 满帮业务及平台架构介绍实时数据实时产品将来打算点击查看直播回放 & 演讲PPT 一、满帮业务及平台架构介绍满帮团体全心全意帮忙司机和货主，助力物流降本增效，利用挪动互联网、大数据、人工智能等新技术，打造智慧物流生态平台，晋升“车找货、货找车”的智能化和标准化，改变传统物流行业“小、乱、散、弱”的情况。旗下运满满货运平台一站式解决货运全链路问题，百万司机一秒响应。 满帮实时数据矩阵图满帮的实时数据矩阵图次要采纳了云原生和 OLAP 平台的架构，次要采纳了阿里云 Flink+Hologres 的利用架构。在实时数仓层面，建设了用户、货源、流量、领取、交易、营销以及 CRM 根底层，同时还建设了咱们特有的数仓分层，叫实时供需层，相当于传统公司的 ADM 层。在这一层咱们建设了线路司机散布状况、沿途货源散布状况、二级货类散布状况、实时离线供需交融状况以及每个登程城市或者线路沿途的疫情和天气情况。 在数仓上咱们还往前更近了一层，做了实时特色。基于分钟级或者秒级的实时数仓去做数据，疾速高效的赋能给算法和经营业务。包含司机和货主的行为特色、司机行为概率分布、货源行为状态散布、路线货源价格散布。同时，咱们团队在实时策略上也做了相应开发，比如说司机有拼单的志愿，或者说司机有漫游行为、人群流量实时预测、Push 流量实时预测和调配。 对于为了满足实时业务的实时数据产品，它和离线数仓有一个本质区别，就是实时数据须要更多直接触达业务。那么咱们怎么去定义实时数据产品呢？咱们想把它变成一个实时的决策平台，蕴含如下几个环节： 第一步是数据洞察;第二步是智能归因;第三步是实时预警，指标归因进去后把数据告警给相干的业务方;第四步是人群画像，指在告警时，须要把相干人群的画像被动勾画进去;第五步通过高效的 OLAP 和 Flink 计算开发一条简略的策略;而后导入到规定引擎，让算法和经营来调取;最初通过 A/B 成果实现整个决策平台的产品构建。线上实时决策平台和底层数仓，次要的服务对象蕴含页面排序、搜寻排序、智能召回、Push 收归、司机会员、委托定价等权利或价格的策略，实时决策基本上都用到了实时特色和实时数据。 在做实时数据的时候，咱们思考了三个维度。第一是价值。咱们须要去了解和洞察业务，而后通过实时决策平台赋能业务。第二是闭环，咱们不仅只是把数据做到位，还须要思考整个业务的闭环成果。第三是老本，次要是基于价值去掂量 ROI，如果投入与产出不成正比，咱们就须要在老本上绝对收敛一些。 满帮实时计算平台架构接下来分享一下满帮实时计算平台的架构。满帮的数据分布在不同的机房，当然也散布在不同的云厂商。从下图能够看到 A 机房次要是生产零碎和实时计算，B 机房次要是离线机房，即离线集群。 在这种数据架构下做实时数据的全链路能力，咱们做了如下几件事： 咱们做了全链路稳定性建设。数据源到最上游的数据生产做到分钟级，即一分钟、十几秒甚至几秒钟，业务零碎就要生产到底层传来的数据。咱们在实时计算数据源上进行了稳定性治理。在前端埋点采纳了业内比拟当先的架构，后端埋点在一些要害的业务点上进行了一些打点，让数据能够做到秒级达到实时数据仓库。咱们对立了数据规范。在数据源治理完后，把所有的实时数据放到一个数据总线里，保障实时数据的生产是对立数据规范。咱们已经采纳过传统的 Doris 和自建的一些架构，但发现运维老本都绝对比拟高，所以最终采纳了阿里的 Hologres 集群。咱们要做一个残缺的数据服务生态圈。在把数据赋能到业务方和调用方的时候，咱们须要提供一些 API 和音讯队列。这里咱们排汇了阿里云 OneService 的建设思路，构建了一个对立数据服务。咱们和算法平台一起做了实时样本归因平台，同时配合他们做了一个实时训练的框架，保障算法和经营的实时决策。从自建 Flink 到迁徙云原生的阿里云实时计算 Flink 版平台降本增效以上是实时计算平台架构的分享，接下来分享一下，咱们从自建的 Flink 迁徙到云原生的阿里云实时计算 Flink 版平台的起因。原有自建集群上运行实时作业稳定性差，重大影响业务，自建整体运维老本较高，须要将重心从平台建设向业务优化歪斜，技术倒退路线从开源自建向托管云服务迁徙。具体如下： 第一点，阿里云实时计算 Flink 版平台采纳了云原生全托管架构，部署、资源隔离在下面都具备人造的架构先进性，CU 级别智能弹性扩缩容无效晋升性价比。第二点，咱们在本人搭建 Flink on Yarn 的时候，发现底层的资源隔离和资源之间的影响有很大的波动性，阿里云实时计算 Flink 版平台的云原生资源隔离能力能够实现作业级和代码级的隔离，缩小相互影响，技术当先性发明平台稳定性。第三点，阿里云实时计算 Flink 版开发平台，它的 metrics 采集零碎、SQL 开发、资源调优明显改善开发效率，运维工作量和老本显著升高。上面咱们来看一下，下半年把运满满的整个实时计算 Flink 工作全副迁徙到阿里云，收益是怎么样的？ ...

摘要：本文整顿自 Apache Flink 中文社区发起人、阿里巴巴开源大数据平台负责人王峰（莫问），在 Flink Forward Asia 2022 主会场的分享。本篇内容次要分为四个局部： 实时流计算寰球范畴事实标准2022 数据实时化技术创新不止Streaming Data Warehouse流式数仓 Demo点击查看直播回放 & 演讲PPT 一、实时流计算寰球范畴事实标准Apache Flink 社区从 2014 年诞生到 2022 年曾经通过了间断八年的疾速倒退。从晚期的互联网行业逐渐扩大到更多的传统行业，比方金融、电信、交通、物流、以及能源制作等等。 Apache Flink 诞生于欧洲，暴发于中国。最近几年席卷寰球，在北美、东南亚等寰球各地开始被大量应用。能够说在寰球的各个行业，只有大家想到实时流计算，基本上都会抉择 Apache Flink。因而咱们就能够认定 Apache Flink 社区曾经成为了寰球范畴内实时流计算的事实标准。从 2022 年社区的各项指标中，也进一步失去印证。 Flink 社区通过八年的疾速倒退，在 Github Star 上也始终继续稳固的快速增长。目前为止，Flink 的 Github Star 曾经超过了 20000，这在 Apache 支流的大数据我的项目中仍然是名落孙山的。 在开发者生态方面，咱们也曾经积攒了超过 1600 名的开发者，为 Flink 社区做奉献，2022 年又新减少了 200 多名开发者。从下载量上也能够看到，Flink 在 2022 年再创新高，月度峰值的下载量最高曾经冲破 1400 万次。 在整个 Flink 国际化生态一直凋敝倒退的过程中，咱们能够十分骄傲的看到，中国开发者在外面承当了十分大的外围推动力。 通过 OSS Insight 网站的数据统计能够看到，Flink 社区在 Github 上产生的 Pull Request 有 45% 是来自于中国的开发者。由此可见，整个社区的技术演进和技术开发的推动力次要都是由中国开发者带来的。 ...

摘要：本文整顿自米哈游大数据实时计算团队负责人张剑，在 FFA 的分享，本篇内容次要分为三个局部： 倒退历程和平台建设场景利用实际将来瞻望点击查看直播回放 & 演讲PPT 一、倒退历程和平台建设米哈游成立于 2011 年，致力于为用户提供高品质、超出预期的产品和服务。公司陆续推出多款人气产品，如崩坏学园 2、崩坏 3、未定事件簿、原神以及社区产品米游社等。 随着公司的疾速倒退，实时计算需要应运而生。咱们基于 Flink 计算引擎构建了实时计算平台。根据需要及次要工作的不同划分为三个阶段。 第一阶段，以 Datastream API 开发为主的 Flink 平台。第二阶段，以 Flink SQL 为主的一站式开发平台。第三阶段，一站式开发平台的性能深入和场景笼罩。 为什么抉择 Flink？首先是基于 Flink 框架优异的个性，如毫秒提早、窗口计算、状态治理、容错复原。同时蓬勃发展的社区，对 Flink 的引入充满信心。 1.0 阶段次要是以 Datastream API 开发为主，初步具备了工作治理以及运维能力。但随着开发人员增多，基于 Datastream API 开发弊病稍加浮现，如开发难度大，版本易抵触、运维难度大等。 2.0 阶段为了解决大家的问题，构建了以 Flink SQL 为主的一站式开发平台，次要基于 Flink 1.10 和 1.12。平台的次要工作次要分为如下四个方面： 增强多云跨区域工作治理能力的建设。加强 Flink SQL 能力以及丰盛上下游连接器。构建指标和日志体系。欠缺元数据以及工作血统的治理。基于一站式开发平台较大的进步了大家的开发效率。截止目前，Flink SQL 占比总任务数达 90%以上。 随着业务的倒退，大家提出了新的冀望。总结起来有如下几点： 越来越多的同学退出，对工作的调优和调参方面心愿可能降低成本。局部业务的流量波动性较大，心愿能有工作的主动扩缩容管理机制。局部常见的 ETL 工作，用 Flink SQL 开发也有较大的老本，心愿可能基于配置生成 Flink 工作。对数据的时效性有了新的冀望，心愿数据入仓可能分钟可查，或者基于近实时数仓开发。基于此，3.0 阶段次要是一站式平台开发性能深入和场景笼罩。咱们思考的方向次要有如下四个方面： 动态和动静资源调优。主动扩缩容。资源弹性能力。增强近实时数仓的建设。动态资源调优指用户开发完一个工作，根据其根本的业务逻辑及探测以后时刻的工作流量，联合自身工作的设置来给定初始资源，同时优化一些不合理的选项，防止用户重复调试。动静调优指一个工作曾经上线运行。依据作业收集的指标信息，一直调整工作的资源，来满足工作的失常运行，防止反压及流量稳定所带来的影响。从中能够看出，动静调优须要平台具备主动扩缩容的管理机制。而主动扩缩容的管理机制又对底层资源的弹性具备肯定的要求。 ...

本文整顿自阿里巴巴高级技术专家朱翥、阿里巴巴高级技术专家贺小令在 9 月 24 日 Apache Flink Meetup 的演讲。次要内容包含： Adaptive Batch SchedulerSpeculative ExecutionHybrid ShuffleDynamic Partition Pruning点击查看原文视频 & 演讲PPT Flink 是流批一体计算框架，早些年次要用于流计算场景。近些年随着流批一体概念的推广，越来越多的企业开始应用 Flink 解决批业务。 尽管 Flink 在框架层面人造反对批处理，但在理论生产应用中仍然存在问题。因而在近几个版本中，社区也始终在继续改良 Flink 批处理问题，这些改良体现在 API、执行与运维三个层面。 在 API 层面，咱们始终在改良 SQL，欠缺其语法，并使其可能兼容 HIVE SQL；咱们也在欠缺 DataStream 接口来更好的反对批处理作业开发。在运维层面，咱们心愿 Flink batch 可能更易于在生产中应用，所以咱们欠缺了 history server ，以更好地展现作业在运行中以及完结后的状态，同时也引入了兼容 Hive 生态的 SQLGateway。在执行层面，咱们对于算子、执行打算、调度、网络层都进行了性能与稳定性的改良。 其中一个次要思路是依据运行时信息，比方数据量、数据模式、执行工夫、可用资源等，自适应地优化作业执行，包含依据数据量主动为作业节点设置适合的并发度，通过预测执行来发现与缓解慢节点对作业的影响，引入自适应数据传输方式来进步资源利用率与解决性能，对多分区表进行动静分区裁剪来进步解决效率。 这些改良，有的使得 Flink 批处理更易于应用，有的对批处理作业的稳定性提供了保障，有的晋升了作业执行性能，或是兼而有之。 一、Adaptive Batch Scheduler 此前，作业上线前都须要进行并发度调优。对于批处理作业的用户而言，他们遇到的状况是这样的： 批处理作业往往十分多，对作业进行并发度调优会是十分大的工作量，费时费力。每日数据量可能都在变动，特地是大促期间数据会有数倍乃至数十倍的增长，因而很难预估数据，导致调优艰难。同时，如果要在流动前后更改并发度配置，也会更加消耗人力。Flink 由多个计算节点串联而成的执行拓扑组成。两头节点因为算子复杂性以及数据自身的特质，难以预判数据量，很难进行节点细粒度的并发度配置。而一个全局对立的并发，则可能导致资源节约，乃至额定的调度部署、网络传输的开销。此外，SQL 作业，除了 source 和 sink 外，只能配置全局对立的并行度，没法进行细粒度并行度设置，因而也会面临资源节约与额定开销的问题。 为了解决问题，Flink 引入了自适应批处理调度器，用户能够配置心愿每个并发实例解决的数据量， Flink 会依据运行过程中理论各个节点的数据量主动决定各个逻辑节点的理论并发度，从而保障每个执行并发解决的数据量大抵合乎用户预期。 以上配置形式的特点是配置与数据作业的数据量无关，因而比拟通用，一套配置能够实用于很多作业，不须要独自为每个作业进行调优。其次，主动设置的并行度可能适配每天不同的数据量。同时，因为能够在运行时采集到每个节点理论须要解决的数据量，所以可能进行节点粒度的并行度设置，实现更优的成果。 其流程如上图所示：当上游逻辑节点 A 的所有执行节点执行完并产出数据结束后，能够采集产出数据总量，即节点B要生产的数据量。而后将信息交给并行度计算策略组件计算适合的并行度，动静生成执行节点拓扑进行调度与部署。 ...

作者 | 阿里巴巴高级技术专家、Apache Flink Committer 贺小令（晓令）Apache Flink 继续保持高速倒退，是 Apache 最沉闷的社区之一。Flink 1.16 共有 240 多个 Contributor 激情参加，共实现了 19 个 FLIP [1]和 1100 多个 issue，给社区带来十分多振奋人心的性能。 Flink 曾经是流计算畛域的领跑者，流批一体的概念逐步失去大家的认可，并在越来越多的公司胜利落地。之前的流批一体更强调对立的 API 和对立的计算框架。往年，在此基础上，Flink 推出了 Streaming Warehouse[2]，进一步降级了流批一体的概念：真正实现了流批一体的计算和流批一体的存储的交融，从而实现流批一体的实时化剖析。 在 1.16 版本里，Flink 社区对流、批都实现了泛滥改良： 在批处理方面，实现了易用性、稳定性、性能全方位的改良，1.16 是 Fink 批处理的里程碑式的版本，是走向成熟的重要一步。易用性：引入 SQL Gateway 并齐全兼容 HiveServer2，用户能够十分不便的提交 Flink SQL 作业和 Hive SQL 作业，同时也很容易连贯到原有的 Hive 生态。性能：Flink SQL 用户反对通过 Join Hint 指定 Join 策略，防止不合理的执行打算；Hive SQL 的兼容性曾经达到 94%，用户能够以极低的老本实现 Hive 到 Flink 的迁徙。稳定性：通过预测执行缩小作业长尾以进步作业整体运行稳定性；反对自适应 HashJoin，通过失败回滚机制防止作业失败。性能：对多分区表进行动静分区裁剪以进步解决效率，TPC-DS 在 10TB 规模数据集下性能晋升了 30%；反对混合 Shuffle 模式，进步资源使用率和解决性能。在流解决方面，也实现了很多重大改良：Changelog State Backend 能够为用户提供秒级甚至毫秒级 Checkpoint，从而大幅晋升容错体验，同时为事务性 Sink 作业提供更小的端到端提早体验。维表关联在流解决中宽泛被应用，引入了通用的缓存机制放慢维表查问速度，引入了可配置的异步模式晋升维表查问吞吐，引入可重试查问机制解决维表提早更新问题。这些性能都十分实用，解决了用户常常埋怨的痛点，反对了更丰盛的场景。从 Flink SQL 诞生第一天就存在一些非确定性操作可能导致用户作业呈现谬误后果或作业运行异样，这给用户带来了极大的困扰。1.16 里咱们花了很多大精力解决了大部分问题，将来还会继续改良。随着流批一体的进一步欠缺和 Flink Table Store 的一直迭代（0.2版本已公布[3]），Flink 社区正一步一步推动 Streaming Warehouse 从概念变为事实并走向成熟。 ...

本文整顿自37手游大数据平台资深开发工程师史翱翔在实时数仓Workshop · 广州站的演讲。次要内容包含： 37云平台大数据建设背景37云平台大数据建设计划利用实际将来布局作者：史翱翔 37手游大数据平台资深开发工程师 公司介绍37手游是37互娱的子公司，次要负责经营，也就是发行业务。在中国大陆地区37手游以10%占有率仅次于腾讯和网易排第三。当初在非中国大陆地区也曾经进入月支出过亿的俱乐部，胜利发行了包含《永恒纪元》、《一刀传世》、《斗罗大陆》这几款游戏，以后曾经累计4亿用户。 37手游之前是自建的大数据集群，思考到集群将来的扩展性、稳定性以及老本问题，决定大数据全副上云，本次workshop的分享就是基于IDC集群上云的建设实际。 37手游云平台大数据建设背景痛点：自建集群组件多，架构简单，老本高首先看一下这张图，做大数据的同学对这些组件应该都很相熟，刚开始咱们也一样，像动物园一样，治理了很多 “小动物”。 2019 年，咱们的很多离线作业是基于Hadoop集群做的。基于这个集群之上，咱们有一些OLAP查问场景，过后可选的组件不多，于是咱们用了Kylin、Druid。然而这只能应答一些简略的场景，简单的场景还是没方法间接基于这些组件对外提供服务。2020 年，引入了实时计算，过后用的是社区版Flink，其中ClickHouse跟ADB次要是做OLAP的查问，另外的ElasticSearch是用来存储画像的数据。2021 年，随着业务场景的须要，咱们用到的组件也越来越多，所以不得不选用基于多数据源的查问引擎，于是引入了 Presto，这个时候能够基于Presto做一些联邦查问 ，Hive、MySQL、ADB、ClickHouse等做一个买通关联。基于Presto，咱们会在下层做一个报表的查问。2022 年，咱们大数据全副上云了，只须要用到三个重要组件：MaxCompute、Hologres、Flink。以上是咱们大数据演进的过程，上面先剖析一下IDC集群的状况。 资源老本：机器老本高；机房老本高，因为有一百台机器要有独自的机房；闲暇工夫多。咱们的离线作业大部分在早晨运作，白天的工夫基本上是比拟节约的。人力老本：组件多，运维老本高。一个人要负责三四个组件的保护；组件学习老本高，一些业务开发的同学会应用咱们提供的组件，对于他们来说，会有肯定的学习老本；开发成本高。稳定性、扩展性。IDC 集群做扩容时流程很简单，从申请，到机器的洽购，再到部署、上线等，至多要一个月的工夫，扩展性很差；机房部署周期长；故障率较高。上云需要：低成本、运维简略、可扩大基于IDC集群的综合评估，跟上云在技术和业务做了综合比照。下图是随着节点数的减少自建机房与基于阿里云的比照。在集群节点不断扩大的状况下，能够看到自建机房的单位成本逐步增高，基于阿里云的单位成本根本稳固不变。 从技术上： 上云后用到的组件很少，保护成本低。对立套件，对立开发流程，极大的进步开发效率。实时计算开发更便捷。下面也讲到了，实时计算只需写一条 SQL 就能够了，快捷。监控齐全。以前工作呈现问题很难发现，当初有了配套的监控就能够及时的发现。从业务上： 能够空出更多的工夫做更有业务价值的货色，数据赋能业务。数据的时效性。之前有的 15 分钟、30 分钟跑一次，当初是实时的，这是很显著的比照。从下图的比照能够看出，上云之后咱们的大数据组件变得更加简化了。 流计算将Flink社区版、Spark、Storm间接用阿里云实时计算Flink代替。离线计算之前用Hadoop、hive、Spark，当初对立应用MaxCompute。OLAP数据库查问，之前应用ClickHouse、Presto、Kylin、Druid等简单的组件，当初全副用Hologres 代替。 总体来说37手游上云之后，云平台有以下几个方面的变动： 效率高：上云之后首先是效率的变动，不单单是机器扩大效率，还有包含开发效率。成本低：咱们也和 IDC 集群做了比照，上云之后整体老本会升高。易扩大：当初不论加存储也好、内存或者 cpu 也好，几分钟即可实现扩大。稳定性高。上云之后简直还未呈现过问题。 二、云平台大数据建设计划云平台整体设计方案先看一下总体方案设计 第一条链路是实时流，从 Kafka 过去，通过实时计算，实时计算之后会落到 Hologres。然而有一些场景须要扩大维度，实时计算时会用到配置表，是在 Hologres 基于行存来存储的配置表，通过点查的能力，把配置信息取出来做实时关联，最终落到 Hologres。第二条链路，可能也是大家罕用的（传统的数据库还是要保留），咱们会把传统的 MySQL 数据库通过 DataWorks 数据集成同步到 Hologres。最初一条链路是离线的，Kafka 数据通过 DataWorks 写到 MaxCompute，写完之后会在 MaxCompute 每天定时跑工作来修整第一条线的实时数据，也就是做一个离线的修改。另外咱们会把 MaxCompute 里画像数据推到另外两个组件。这里阐明一下，这两个组件是为了思考到双云部署，所以咱们思考到开源的组件，StarRocks 和 HBase，这两块次要是用在画像上。最初一层是用到Quick BI做展现，包含用户画像也是基于 StarRocks 和 HBase 做一个查问。以上是整体的计划，上面讲一下具体的实时数仓和离线数仓。 下面是实时数仓，能够看到次要来源于两个中央，一个是 MySQL，一个是 Kafka。两块数据是通过 Flink 落到 Hologres，从 DWD 到 DWS 再到 ADS 逐层荡涤，最终落到 Hologres。上面是离线数仓，通过 MySQL、Kafka 落到 MaxCompute，在 MaxCompute 逐渐分层，最终落到 Hologres，离线这一层会修改实时的数据。实时数仓典型利用场景接下来会讲上云后的实时数仓五个典型利用场景的具体实现。 场景1:实时数据入仓 咱们用到数据集成，将MySQL数据、Kafka 数据通过 DataWorks 的数据集成写到 Hologres，这就是数据同步。第二种形式是 MySQL 的数据能够通过 Flink CDC 个性同步到 Hologres，这个过程只是一个简略的同步，没有做任何数据的解决。 ...

本文整顿自 37 手游大数据平台资深开发工程师史翱翔在实时数仓 Workshop · 广州站的演讲。次要内容包含： 云平台大数据建设背景云平台大数据建设计划利用实际将来布局点击查看原文视频 & 演讲PPT 首先介绍一下背景。咱们之前是自建的大数据集群，思考到集群将来的扩展性、稳定性以及老本问题，决定大数据全副上云，明天的分享就是基于 IDC 集群上云的建设实际。 一、云平台大数据建设背景 首先看一下这张图，做大数据的同学对这些组件应该都很相熟，刚开始咱们也一样，像动物园一样，治理了很多 “小动物”。 2019 年，咱们的很多离线作业是基于 Hadoop 集群做的。基于这个集群之上，咱们有一些 OLAP 查问场景，过后可选的组件不多，于是咱们用了 Kylin、Druid。然而这只能应答一些简略的场景，简单的场景还是没方法间接基于这些组件对外提供服务。2020 年，引入了实时计算，过后用的是社区版 Flink，其中 ClickHouse 跟 ADB 次要是做 OLAP 的查问，另外的 ElasticSearch 是用来存储画像的数据。2021 年，随着业务场景的须要，咱们用到的组件也越来越多，所以不得不选用基于多数据源的查问引擎，于是引入了 Presto，这个时候能够基于 Presto 做一些联邦查问 ，Hive、MySQL、ADB、ClickHouse 等做一个买通关联。基于 Presto，咱们会在下层做一个报表的查问。2022 年，咱们大数据全副上云了，只须要用到三个重要组件：MaxCompute、Hologres、Flink。以上是咱们大数据演进的过程，上面先剖析一下 IDC 集群的状况。 第一、资源老本： 机器老本高；机房老本高，因为有一百台机器要有独自的机房；闲暇工夫多。咱们的离线作业大部分在早晨运作，白天的工夫基本上是比拟节约的。第二，人力老本： 组件多，运维老本高。一个人要负责三四个组件的保护；组件学习老本高，一些业务开发的同学会应用咱们提供的组件，对于他们来说，会有肯定的学习老本；开发成本高。第三，稳定性、扩展性。 IDC 集群做扩容时流程很简单，从申请，到机器的洽购，再到部署、上线等，至多要一个月的工夫，扩展性很差；机房部署周期长；故障率较高。基于IDC集群的综合评估，跟云上做了一个比照。次要是两个方面：一是技术，二是业务。 左边图是随着节点数的减少自建机房与基于阿里云的比照。在集群节点不断扩大的状况下，能够看到自建机房的单位成本逐步增高，基于阿里云的单位成本根本稳固不变。 从技术上： 上云后用到的组件很少，保护成本低。对立套件，对立开发流程，极大的进步开发效率。实时计算开发更便捷。下面也讲到了，实时计算只需写一条 SQL 就能够了，快捷。监控齐全。以前工作呈现问题很难发现，当初有了配套的监控就能够及时的发现。从业务上： 能够空出更多的工夫做更有业务价值的货色，数据赋能业务。数据的时效性。之前有的 15 分钟、30 分钟跑一次，当初是实时的，这是很显著的比照。 从上图的比照能够看出，上云之后咱们对组件做了简化。 从流计算开始，Flink 社区版、Spark、Storm 间接用实时计算 Flink 代替。第二是离线计算，之前用 Hadoop、hive、Spark，当初对立存在 MaxCompute。最初一个是 OLAP 数据库，包含之前的 ClickHouse、Presto、Kylin、Druid 等，当初全副用 Hologres 代替。 ...

点击投递议题 在这数据量爆炸性增长的时代，开源软件如雨后春笋般呈现在开发者的视线中，数据的价值被从新定义。同时，越来越多的企业开启实时化路线，数据的实时剖析与计算需要一劳永逸。 作为主打流解决的计算引擎 Apache Flink 于 2014 年正式开源，并在 Apache 基金会的泛滥开源我的项目中，活跃度间断几年名落孙山，堪称煊赫一时。据 Flink 官网数据显示，至多 2/3 的开发者来源于中国，这代表着中国开源力量日益衰亡，并开始在国际化舞台上熠熠生辉。 自 2018 年 Flink 中文社区成立至今，Flink 已在国内多个行业落地，并日益成为推动企业数字化转型的磅礴能源。 成立之初， Flink 中文社区就引入社区顶级盛会 Flink Forward ，并于 2019 年将 Flink Forward China 正式降级为 Flink Forward Asia（简称 FFA）。Flink Forward Asia 每年都会集结最佳行业实际以及 Flink 最新技术动静等，并踊跃拥抱生态搭档，共建凋敝开源大数据生态。 Flink Forward Asia 2022 正式上线！作为最受社区开发者期盼的年度顶会，往年的 Flink Forward Asia 2022 已正式启动！暂定于 11 月在线上举办，探讨交换 Flink 最新动静。 连续 FFA 常规，会议所有议题均为凋谢征集而来，并由业余的议题评比委员会评分筛选，确保内容代表行业领先水平。 超强阵容议题评比委员会FFA 2022 邀请了 10 位行业首领及开拓者组成议题评比委员会，并持续由阿里巴巴开源技术委员会负责人贾扬清负责主席，10 位专家独特为大会内容护航。 议题方向Flink Forward Asia 2022 将采纳议题标签的模式出现所有大会精彩内容，围绕 Flink 横跨多行业，新场景。每个议题能够抉择 1-2 个标签。次要标签划分如下： ...

本文首发于我的集体博客网站 期待下一个秋-Flink什么是CDC？CDC是（Change Data Capture 变更数据获取）的简称。核心思想是，监测并捕捉数据库的变动（包含数据 或 数据表的插入INSERT、更新UPDATE、删除DELETE等），将这些变更按产生的程序残缺记录下来，写入到消息中间件中以供其余服务进行订阅及生产。 1. 环境筹备mysqlkafka 2.3flink 1.13.5 on yarn 阐明：如果没有装置hadoop，那么能够不必yarn，间接用flink standalone环境吧。 2. 下载下列依赖包上面两个地址下载flink的依赖包，放在lib目录上面。 flink-sql-connector-kafka_2.11-1.13.5.jarflink-sql-connector-mysql-cdc-1.3.0.jar如果你的Flink是其它版本，能够来这里下载。 这里flink-sql-connector-mysql-cdc，后面一篇文章我用的mysq-cdc是1.4的，过后是能够的，然而明天我发现须要mysql-cdc-1.3.0了，否则，整合connector-kafka会有来抵触，目前mysql-cdc-1.3适用性更强，都能够兼容的。 如果你是更高版本的flink，能够自行https://github.com/ververica/...下载新版mvn clean install -DskipTests 本人编译。 这是我编译的最新版2.2，传上去发现太新了，如果从新换个版本，我得去gitee下载源码，不然github速度太慢了，而后用IDEA编译打包，又得下载一堆依赖。我投降，我间接去网上下载了个1.3的间接用了。 我下载的jar包，放在flink的lib目录上面： flink-sql-connector-kafka_2.11-1.13.5.jarflink-sql-connector-mysql-cdc-1.3.0.jar3. 启动flink-sql client1) 先在yarn下面启动一个application，进入flink13.5目录，执行： bin/yarn-session.sh -d -s 1 -jm 1024 -tm 2048 -qu root.sparkstreaming -nm flink-cdc-kafka2) 进入flink sql命令行 bin/sql-client.sh embedded -s flink-cdc-kafka 4. 同步数据这里有一张mysql表： CREATE TABLE `product_view` (`id` int(11) NOT NULL AUTO_INCREMENT,`user_id` int(11) NOT NULL,`product_id` int(11) NOT NULL,`server_id` int(11) NOT NULL,`duration` int(11) NOT NULL,`times` varchar(11) NOT NULL,`time` datetime NOT NULL,PRIMARY KEY (`id`),KEY `time` (`time`),KEY `user_product` (`user_id`,`product_id`) USING BTREE,KEY `times` (`times`) USING BTREE) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;-- 样本数据INSERT INTO `product_view` VALUES ('1', '1', '1', '1', '120', '120', '2020-04-24 13:14:00');INSERT INTO `product_view` VALUES ('2', '1', '1', '1', '120', '120', '2020-04-24 13:14:00');INSERT INTO `product_view` VALUES ('3', '1', '1', '3', '120', '120', '2020-04-24 13:14:00');INSERT INTO `product_view` VALUES ('4', '1', '1', '2', '120', '120', '2020-04-24 13:14:00');INSERT INTO `product_view` VALUES ('5', '8', '1', '1', '120', '120', '2020-05-14 13:14:00');INSERT INTO `product_view` VALUES ('6', '8', '1', '2', '120', '120', '2020-05-13 13:14:00');INSERT INTO `product_view` VALUES ('7', '8', '1', '3', '120', '120', '2020-04-24 13:14:00');INSERT INTO `product_view` VALUES ('8', '8', '1', '3', '120', '120', '2020-04-23 13:14:00');INSERT INTO `product_view` VALUES ('9', '8', '1', '2', '120', '120', '2020-05-13 13:14:00');1) 创立数据表关联mysql ...

具体谬误内容: Caused by: java.lang.NoSuchMethodError: com.mysql.cj.CharsetMapping.getJavaEncodingForMysqlCharset(Ljava/lang/String;)Ljava/lang/String; at io.debezium.connector.mysql.MySqlValueConverters.charsetFor(MySqlValueConverters.java:331) at io.debezium.connector.mysql.MySqlValueConverters.converter(MySqlValueConverters.java:298) at io.debezium.relational.TableSchemaBuilder.createValueConverterFor(TableSchemaBuilder.java:400) at io.debezium.relational.TableSchemaBuilder.convertersForColumns(TableSchemaBuilder.java:321) at io.debezium.relational.TableSchemaBuilder.createKeyGenerator(TableSchemaBuilder.java:179) at io.debezium.relational.TableSchemaBuilder.create(TableSchemaBuilder.java:137) at io.debezium.relational.RelationalDatabaseSchema.buildAndRegisterSchema(RelationalDatabaseSchema.java:130) at io.debezium.relational.HistorizedRelationalDatabaseSchema.recover(HistorizedRelationalDatabaseSchema.java:52) at com.ververica.cdc.connectors.mysql.debezium.task.context.StatefulTaskContext.validateAndLoadDatabaseHistory(StatefulTaskContext.java:162) at com.ververica.cdc.connectors.mysql.debezium.task.context.StatefulTaskContext.configure(StatefulTaskContext.java:114) at com.ververica.cdc.connectors.mysql.debezium.reader.SnapshotSplitReader.submitSplit(SnapshotSplitReader.java:92) at com.ververica.cdc.connectors.mysql.debezium.reader.SnapshotSplitReader.submitSplit(SnapshotSplitReader.java:63) at com.ververica.cdc.connectors.mysql.source.reader.MySqlSplitReader.checkSplitOrStartNext(MySqlSplitReader.java:147) at com.ververica.cdc.connectors.mysql.source.reader.MySqlSplitReader.fetch(MySqlSplitReader.java:69) at org.apache.flink.connector.base.source.reader.fetcher.FetchTask.run(FetchTask.java:56) at org.apache.flink.connector.base.source.reader.fetcher.SplitFetcher.runOnce(SplitFetcher.java:138) at org.apache.flink.connector.base.source.reader.fetcher.SplitFetcher.run(SplitFetcher.java:101) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)解决方案:引入mysql对应版本依赖 <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <version>8.0.21</version></dependency>参考：https://github.com/ververica/...

点击参加线下交换 随着数字化业务的增长，企业的数据量出现爆发式增长，数据仓库曾经成为企业数据倒退到肯定规模后必然提供的根底服务之一。数据的时效性，成为数据仓库建设中必不可少的一环，企业最常做的就是通过实时数仓建设，满足对数据的疾速摸索。 在理论业务中，实时数仓须要反对数据实时写入与更新、业务麻利疾速响应、数据自助剖析、运维操作便捷、云原生弹性扩缩容等一列需要，而这就依赖一款弱小的实时数仓引擎。阿里云实时计算 Flink 版作为一款大数据流式计算引擎，提供全增量一体化数据同步技术、弱小的流式 ETL 等能力，反对海量数据实时写入解决；新一代实时数仓引擎阿里云 Hologres 能同时解决 OLAP 多维分析、在线服务、离线数据减速等多个业务查问场景。 通过阿里云实时计算 Flink 版与阿里云 Hologres 的强强联合，实现全链路的数据摸索实时化、数据分析麻利化，疾速助力业务构建企业级一站式实时数仓，实现更具时效更智能的业务决策。 9月15日，实时数仓 Workshop · 广州站将聚焦 Flink & Hologres 实时数仓在数据链路中表演的角色与在智能商业中的重要价值，由业内各界的实时数仓实践者一起探讨实时计算将来趋势、开源生态倒退、实时数仓场景在各行业中的实际与利用及平台智能化的摸索与思考。 嘉宾及议题介绍01《阿里云实时计算Flink版产品介绍与演示》乐洋｜阿里云高级产品专家 围绕Flink的相干场景，包含包含调优、运维、开发等，以及实时数仓相干解决方案 02《Flink和Hologres构建企业级一站式实时数仓》余文兵｜阿里巴巴技术专家 随着实时数仓的遍及，在线化、一站式、麻利化成为实时数仓新的发展趋势，阿里云Hologres反对高吞吐写入与更新、PB级数据秒级查问以及高并发的在线服务查问，兼容PG生态，与Flink深度交融，解决传统数仓加工链路长、数据进口多、数据更新难等问题，提供一站式实时数仓规范解决方案，减速企业实时数仓建设。 03《37手游基于云平台的大数据建设实际》史翱翔｜37手游大数据平台高级开发工程师 传统的大数据架构服务器、运维老本高，扩展性无限，保护组件较多，监控不够欠缺。上云拐点曾经到来，开源大数据上云已成为业界共识。如何在云上低成本存储的同时又实现弹性计算的需要，如何仅通过sql实现流式计算，如何解决业务查问报表慢的问题，本次分享将为你揭晓答案，欢送大数据技术爱好者交换和探讨！ 04《Flink+Hologres实时数仓在Lazada的建设及利用》徐鑫豪｜Lazada数据技术专家 本次会介绍Flink和Hologres架构在Lazada的落地实际。Lazada基于Flink和Hologres技术构建的实时数仓，疾速提供业务小二的多种OLAP多维分析能力，撑持Lazada AB试验、营销剖析等数据平台场景，助力业务快速增长。 05《从ELK到EFK——联合Flink和Elasticsearch新个性重构全观测计划》朱杰｜Elastic 资深解决方案架构师 赵弘扬｜阿里云高级产品专家 近几年，随着IT架构逐渐向云的衍进，传统的IT运维、日志/指标监控与剖析、平安剖析等伎俩，也逐步从独立的日志、指标、分布式追踪零碎迈向云上对立和交融的全观测平台。“开源云服务”和“全观测”这两个近期在国内十分时髦的概念，相结合会碰撞出什么样的火花？ 如何基于云上的海量存储能力、计算能力，解决企业IT架构所面临的数据量大、数据预处理量大、链路时效性要求高和告警工作简单高频等艰巨的问题？本次分享的内容将为大家介绍并剖析：阿里云上的Elasticsearch和Flink服务，是如何高效、低成本地解决上述问题，实现全观测降本增效的指标。 流动详情工夫：2022年9月15日 13:30-18:00 地点：广东省广州市天河区珠江新城W酒店 PC 端直播观看：https://developer.aliyun.com/... 挪动端倡议关注 ApacheFlink 视频号预约观看 点击参加线下交换 延长浏览阿里云实时计算 Flink 版 x Hologres: 构建企业级一站式实时数仓 2022第四届 实时计算FLINK挑战赛 49万奖金等你来拿！ 连续 “激励师打算”，赢取丰富礼品！ 点击进入赛事官网报名参赛 更多 Flink 相干技术问题，可扫码退出社区钉钉交换群第一工夫获取最新技术文章和社区动静，请关注公众号～ 流动举荐 阿里云基于 Apache Flink 构建的企业级产品-实时计算Flink版现开启流动：99 元试用 实时计算Flink版（包年包月、10CU）即有机会取得 Flink 独家定制卫衣；另包 3 个月及以上还有 85 折优惠！理解流动详情：https://www.aliyun.com/produc... ...

作者｜徐榜江 余文兵 赵红梅编辑｜伍翀 随着大数据的迅猛发展，企业越来越器重数据的价值，这就意味着须要数据尽快达到企业剖析决策人员，以最大化施展数据价值。企业最常见的做法就是通过构建实时数仓来满足对数据的疾速摸索。在业务建设过程中，实时数仓须要反对数据实时写入与更新、业务麻利疾速响应、数据自助剖析、运维操作便捷、云原生弹性扩缩容等一系列需要，而这就依赖一个弱小的实时数仓解决方案。阿里云实时计算 Flink 版（以下简称“阿里云 Flink”）提供全增量一体化数据同步技术、弱小的流式 ETL 等能力，反对海量数据实时入仓入湖。阿里云 Hologres 作为新一代实时数仓引擎能同时解决 OLAP 多维分析、在线服务、离线数据减速等多个业务查问场景，通过阿里云 Flink 与 Hologres 的强强联合，实现全链路的数据摸索实时化、数据分析麻利化，疾速助力业务构建企业级一站式实时数仓，实现更具时效更智能的业务决策。 在本文中，咱们将会介绍阿里云 Flink、阿里云 Hologres 在构建实时数仓上所具备的外围能力以及二者联合的最佳解决方案，用户通过阿里云 Flink+Hologres 实时数仓解决方案，能够显著升高数仓建设门槛，让数据施展更大的价值，助力各行各业实现数字化降级。 一、Flink CDC 外围能力Apache Flink 是开源的大数据流式计算引擎，反对解决数据库、Binlog、在线日志等多种实时数据，提供端到端亚秒级实时数据分析能力，并通过规范 SQL 升高实时业务开发门槛。随同着实时化浪潮的倒退和深入，Flink 已逐渐演进为流解决的领军角色和事实标准，并蝉联 Apache 社区最沉闷我的项目。 Flink CDC 是阿里云计算平台事业部 2020 年 7 月开源的一款数据集成框架，与 Flink 生态深度交融，具备全增量一体化、无锁读取、并发读取、分布式架构等技术劣势，既能够代替传统的 DataX 和 Canal 工具做数据同步，也反对数据库数据实时入湖入仓，同时还具备弱小的数据加工能力。 在构建实时数仓的过程中，数据采集是必须的组件。在传统的 ETL 架构里，采集层国外用户通常抉择 Debezium，国内用户则习惯用 DataX 和 Canal，采集工具负责采集数据库的全量数据和增量数据。采集到的数据会输入到消息中间件如 Kafka，而后通过 Flink 计算引擎实时生产消息中间件数据做计算层的数据荡涤和数据加工，加工实现后再写入目标端（装载层），通常是各种数据库、数据湖和数据仓库。在传统 ETL 链路中，数据采集工具与音讯队列是比拟重的组件，可能保护在不同的团队，在上游的数据源有业务变更或者这些组件须要降级保护时，整个链路的保护老本会十分大。 通过应用 Flink CDC 去替换上图中的数据采集组件与音讯队列，将采集层（Extraction）和计算层（Transformation）合并，简化了整个 ETL 剖析链路，用户能够应用更少的组件实现数据链路的搭建，整体架构带来更低的运维开销和更少的硬件老本、更好的数据链路稳定性、以及升高端到端的数据提早。除了稳定性的晋升，Flink CDC 的另一个劣势就是用户只须要写 SQL 脚本就能实现 CDC 数据的荡涤，加工和同步，极大地升高了用户应用门槛。 ...

当下，企业的实时计算需要越来越高频，很多企业和组织抉择建设实时数据仓库，以麻利撑持实时报表剖析、智能算法举荐、零碎危险预警等多元业务场景需要。 相比离线数仓，实时数仓有哪些个性？如何进行实时数仓的技术选型？ 个推TechDay“治数训练营”系列直播课第二期来了！ 8月24日（本周三）早晨19:30-20:30，个推资深数据研发工程师为您解读实时数仓架构演进，分享实时数仓技术选型要点，并联合实战案例具体分析实时数仓的搭建秘诀。 更有超多惊喜福利等你拿！

细粒度资源管理的背景目标Flink 目前采纳粗粒度的资源管理办法，其中task被部署到预约义的、通常雷同的slot中，而不须要每个蕴含多少资源的概念。应用slot共享，能够将同一slot共享组 (SSG)中的task部署到一个slot中，而不论每个task/operator须要多少资源。在FLIP-56中，咱们提出了细粒度资源管理，它依据工作负载的资源需要，利用具备不同资源的slot来执行task。 对于许多job来说，应用粗粒度的资源管理并将所有task简略地放在一个 SSG 中就足够了，无论是在资源利用率还是可用性方面。 对于所有task都具备雷同并行度的许多流式job，每个slot将蕴含一个残缺的pipeline。现实状况下，所有pipeline应该应用大致相同的资源，这能够通过调整雷同slot的资源轻松满足。task的资源耗费随工夫而变动。当一个task的耗费缩小时，额定的资源能够被另一个耗费减少的task应用。这被称为削峰填谷效应，缩小了所需的整体资源。然而，在某些状况下，粗粒度的资源管理不能很好地工作。 task可能有不同的并行度。有时，无奈防止这种不同的并行性。例如，source/sink/lookup task的并行性可能会受到内部上游/上游零碎的分区和 IO 负载的限度。在这种状况下，具备较少task的slot将比具备整个task pipeline的slot须要更少的资源。有时，整个pipeline所需的资源可能太多，无奈放入单个slot/task管理器中。在这种状况下，pipeline须要拆分为多个 SSG，它们可能并不总是具备雷同的资源需要。对于批处理job，并非所有task都能够同时执行。因而，pipeline的刹时资源需要随工夫而变动。尝试应用雷同的slot执行所有task可能会导致非最佳资源利用率。雷同slot位的资源必须可能满足最高资源要求，这对于其余要求将是节约的。当波及到 GPU 等低廉的内部资源时，这种节约会变得更加难以承受。因而，须要细粒度的资源管理，利用不同资源的slot来进步这种场景下的资源利用率。 现状目前，FLIP-56 中提出的大部分slot调配和调度逻辑曾经实现，除了一个仍在进行中的slot管理器插件（FLINK-20835）。次要缺失的局部是用于指定job资源需要的用户接口。 有一些古老的代码用于设置转换算子资源并聚合它们以生成slot申请。然而，这些代码从未真正应用过，也没有向用户公开 API。最重要的是，咱们不确定让用户指定operator级别的资源需要并在运行时聚合它们是正确的办法，这将在后续局部中探讨。 范畴此 FLIP 提出了基于slot共享组 (SSG) 的运行时接口，用于指定细粒度的资源需要。具体来说，咱们探讨了如何在Transformation层指定资源需要并在之后加以利用，这涵盖了 Table/SQL API 和 DataStream API 工作负载的公共门路。 因为以下起因，用于指定资源要求的最终用户接口被排除在本 FLIP 的范畴之外。 细粒度的资源管理不是端到端的。咱们认为这应该是通过公开用户 API 来激活该性能的最初一步。不同的开发 API 可能会以不同的形式公开用于指定资源需要的接口。它须要与组件专家进行更深刻的探讨，以决定开发 API 应如何集成此性能。以下示例只是一些初步想法，用于演示用户接口在不同开发 API 中的外观。 对于DataStream API，曾经有为算子设置SSG的接口。基于此，咱们能够引入新的接口来间接指定 SSG 的资源需要。对于 Table API & SQL，因为没有裸露operator和 SSG 的概念，因而布局器可能应该生成 SSG 资源需要，只向用户裸露几个配置旋钮。细粒度资源需要的粒度在本节中，咱们将探讨应该以什么粒度指定细粒度的资源需要，这是设计运行时接口须要答复的最根本问题。具体来说，咱们探讨了三种设计方案的优缺点：为每个算子、task或slot共享组指定资源要求。 用户故事在深入研究设计选项之前，咱们想明确细粒度资源管理的用户故事，这有助于理解每个设计选项的优缺点如何影响咱们的指标用例。 咱们认为，细粒度的资源管理并不是对现有办法的代替，而是对管制 Flink 资源应用的用户参加范畴的扩大。用户能够依据他们的专业知识和要求抉择他们想要参加的水平。 起码波及的选项是利用开箱即用的粗粒度资源配置。它应该实用于大多数简略的用例，尤其是对于尝试 Flink 的初学者。然而，资源利用通常不是最优的。在生产中，通常须要更多的用户参加，指定算子的并行度，配置粗粒度的 slot/taskmanager 资源，以及拆分 slot 共享组。对于粗粒度资源管理成果不佳的状况（如目标局部所述）细粒度资源管理为专家用户提供了一种进一步优化资源利用率的办法，办法是管制pipeline的每个特定局部应该应用多少资源应用，以更多的用户参加为代价。算子粒度如果为每个算子指定了细粒度的资源需要，那么 Flink 运行时须要聚合这些资源需要来生成slot资源需要，对于算子如何链接以及task如何共享slot。 长处是： 资源需要与算子链/slot共享之间的解耦。operator资源需要独立于operator的链接形式以及task共享slot的形式。现实状况下，算子链和slot共享的更改不应要求用户从新指定资源需要。针对并行性差别的潜在优化。对于具备不同并行度的算子的 SSG，有机会应用slot中算子所需的资源来满足slot申请，这可能会以进一步提高 Flink 运行时的致力为代价，进一步提高资源利用率。然而，也有一些毛病： ...

基于上一篇（3）Flink CEP SQL宽松近邻代码演示的延展，在上一篇中咱们应用贪心词量 +（至多匹配1行或多行），本篇将演示多种贪心词量的成果：（1）应用贪心词量 *（匹配0行或多行） public static void main(String[] args) { EnvironmentSettings settings = null; StreamTableEnvironment tEnv = null; try { StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment(); settings = EnvironmentSettings.newInstance() .useBlinkPlanner() .inStreamingMode() .build(); tEnv = StreamTableEnvironment.create(env, settings); System.out.println("===============CEP_SQL_10================="); final DateTimeFormatter dateTimeFormatter = DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss"); DataStream<Ticker> dataStream = env.fromElements( new Ticker(1, "ACME", 22, 1, LocalDateTime.parse("2021-12-10 10:00:00", dateTimeFormatter)), new Ticker(3, "ACME", 19, 1, LocalDateTime.parse("2021-12-10 10:00:02", dateTimeFormatter)), new Ticker(4, "ACME", 23, 3, LocalDateTime.parse("2021-12-10 10:00:03", dateTimeFormatter)), new Ticker(5, "Apple", 25, 2, LocalDateTime.parse("2021-12-10 10:00:04", dateTimeFormatter)), new Ticker(6, "Apple", 18, 1, LocalDateTime.parse("2021-12-10 10:00:05", dateTimeFormatter)), new Ticker(7, "Apple", 16, 1, LocalDateTime.parse("2021-12-10 10:00:06", dateTimeFormatter)), new Ticker(8, "Apple", 14, 2, LocalDateTime.parse("2021-12-10 10:00:07", dateTimeFormatter)), new Ticker(9, "Apple", 19, 2, LocalDateTime.parse("2021-12-10 10:00:08", dateTimeFormatter)), new Ticker(10, "Apple", 25, 2, LocalDateTime.parse("2021-12-10 10:00:09", dateTimeFormatter)), new Ticker(11, "Apple", 11, 1, LocalDateTime.parse("2021-12-10 10:00:11", dateTimeFormatter)), new Ticker(12, "Apple", 15, 1, LocalDateTime.parse("2021-12-10 10:00:12", dateTimeFormatter)), new Ticker(13, "Apple", 19, 1, LocalDateTime.parse("2021-12-10 10:00:13", dateTimeFormatter)), new Ticker(14, "Apple", 25, 1, LocalDateTime.parse("2021-12-10 10:00:14", dateTimeFormatter)), new Ticker(15, "Apple", 19, 1, LocalDateTime.parse("2021-12-10 10:00:15", dateTimeFormatter)), new Ticker(16, "Apple", 15, 1, LocalDateTime.parse("2021-12-10 10:00:16", dateTimeFormatter)), new Ticker(17, "Apple", 19, 1, LocalDateTime.parse("2021-12-10 10:00:17", dateTimeFormatter)), new Ticker(18, "Apple", 15, 1, LocalDateTime.parse("2021-12-10 10:00:18", dateTimeFormatter))); Table table = tEnv.fromDataStream(dataStream, Schema.newBuilder() .column("id", DataTypes.BIGINT()) .column("symbol", DataTypes.STRING()) .column("price", DataTypes.BIGINT()) .column("tax", DataTypes.BIGINT()) .column("rowtime", DataTypes.TIMESTAMP(3)) .watermark("rowtime", "rowtime - INTERVAL '1' SECOND") .build()); tEnv.createTemporaryView("CEP_SQL_10", table); String sql = "SELECT * " + "FROM CEP_SQL_10 " + " MATCH_RECOGNIZE ( " + " PARTITION BY symbol " + //按symbol分区，将雷同卡号的数据分到同一个计算节点上。 " ORDER BY rowtime " + //在窗口内，对事件工夫进行排序。 " MEASURES " + //定义如何依据匹配胜利的输出事件结构输入事件 " e1.id as id,"+ " AVG(e1.price) as avgPrice,"+ " e1.rowtime AS start_tstamp, " + " e3.rowtime AS end_tstamp " + " ONE ROW PER MATCH " + //匹配胜利输入一条 " AFTER MATCH skip to next row " + //匹配后跳转到下一行 " PATTERN ( e1 e2* e3) WITHIN INTERVAL '2' MINUTE" + " DEFINE " + //定义各事件的匹配条件 " e1 AS " + " e1.price = 25 , " + " e2 AS " + " e2.price > 10 AND e2.price <19," + " e3 AS " + " e3.price = 19 " + " ) MR"; TableResult res = tEnv.executeSql(sql); res.print(); tEnv.dropTemporaryView("CEP_SQL_10");}匹配到了三组数据贪心词量 *（匹配0行或多行）（2）应用贪心词量 {n}（严格匹配n行） ...

上一篇咱们对Flink CEP做了简略介绍，这一篇咱们通过代码来演示一下Flink CEP SQL中的严格近邻成果：（1）pom依赖：<dependency> <groupId>org.apache.flink</groupId><artifactId>flink-cep_${scala.binary.version}</artifactId><version>${flink.version}</version></dependency>（2）定义一个音讯对象public static class Ticker { public long id;public String symbol;public long price;public long tax;public LocalDateTime rowtime;public Ticker() {}public Ticker(long id, String symbol, long price, long item, LocalDateTime rowtime) { this.id = id; this.symbol = symbol; this.price = price; this.tax = tax; this.rowtime = rowtime;}}（3）结构数据，定义事件组合public static void main(String[] args) { EnvironmentSettings settings = null;StreamTableEnvironment tEnv = null;try { StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment(); settings = EnvironmentSettings.newInstance() .useBlinkPlanner() .inStreamingMode() .build(); tEnv = StreamTableEnvironment.create(env, settings); System.out.println("===============CEP_SQL_9================="); final DateTimeFormatter dateTimeFormatter = DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss"); DataStream<Ticker> dataStream = env.fromElements( new Ticker(1, "ACME", 22, 1, LocalDateTime.parse("2021-12-10 10:00:00", dateTimeFormatter)), new Ticker(3, "ACME", 19, 1, LocalDateTime.parse("2021-12-10 10:00:02", dateTimeFormatter)), new Ticker(4, "ACME", 23, 3, LocalDateTime.parse("2021-12-10 10:00:03", dateTimeFormatter)), new Ticker(5, "Apple", 25, 2, LocalDateTime.parse("2021-12-10 10:00:04", dateTimeFormatter)), new Ticker(6, "Apple", 18, 1, LocalDateTime.parse("2021-12-10 10:00:05", dateTimeFormatter)), new Ticker(7, "Apple", 16, 1, LocalDateTime.parse("2021-12-10 10:00:06", dateTimeFormatter)), new Ticker(8, "Apple", 14, 2, LocalDateTime.parse("2021-12-10 10:00:07", dateTimeFormatter)), new Ticker(9, "Apple", 15, 2, LocalDateTime.parse("2021-12-10 10:00:08", dateTimeFormatter)), new Ticker(10, "Apple", 25, 2, LocalDateTime.parse("2021-12-10 10:00:09", dateTimeFormatter)), new Ticker(11, "Apple", 22, 1, LocalDateTime.parse("2021-12-10 10:00:11", dateTimeFormatter)), new Ticker(12, "Apple", 15, 1, LocalDateTime.parse("2021-12-10 10:00:12", dateTimeFormatter)), new Ticker(13, "Apple", 19, 1, LocalDateTime.parse("2021-12-10 10:00:13", dateTimeFormatter)), new Ticker(14, "Apple", 25, 1, LocalDateTime.parse("2021-12-10 10:00:14", dateTimeFormatter)), new Ticker(15, "Apple", 19, 1, LocalDateTime.parse("2021-12-10 10:00:15", dateTimeFormatter)), new Ticker(16, "Apple", 15, 1, LocalDateTime.parse("2021-12-10 10:00:16", dateTimeFormatter)), new Ticker(17, "Apple", 19, 1, LocalDateTime.parse("2021-12-10 10:00:17", dateTimeFormatter)), new Ticker(18, "Apple", 15, 1, LocalDateTime.parse("2021-12-10 10:00:18", dateTimeFormatter))); Table table = tEnv.fromDataStream(dataStream, Schema.newBuilder() .column("id", DataTypes.BIGINT()) .column("symbol", DataTypes.STRING()) .column("price", DataTypes.BIGINT()) .column("tax", DataTypes.BIGINT()) .column("rowtime", DataTypes.TIMESTAMP(3)) .watermark("rowtime", "rowtime - INTERVAL '1' SECOND") .build()); tEnv.createTemporaryView("CEP_SQL_9", table); String sql = "SELECT * " + "FROM CEP_SQL_9 " + " MATCH_RECOGNIZE ( " + " PARTITION BY symbol " + //按symbol分区，将雷同卡号的数据分到同一个计算节点上。 " ORDER BY rowtime " + //在窗口内，对事件工夫进行排序。 " MEASURES " + //定义如何依据匹配胜利的输出事件结构输入事件 " e1.id as id,"+ " AVG(e1.price) as avgPrice,"+ " e1.rowtime AS start_tstamp, " + " e3.rowtime AS end_tstamp " + " ONE ROW PER MATCH " + //匹配胜利输入一条 " AFTER MATCH skip to next row " + //匹配后跳转到下一行 " PATTERN ( e1 e2 e3) WITHIN INTERVAL '2' MINUTE" + " DEFINE " + //定义各事件的匹配条件 " e1 AS " + " e1.price = 25 , " + " e2 AS " + " e2.price > 10 ," + " e3 AS " + " e3.price = 15 " + " ) MR"; TableResult res = tEnv.executeSql(sql); res.print(); tEnv.dropTemporaryView("CEP_SQL_9"); } catch (Exception e) { LOG.error(e.getMessage(), e); }}（4）要害代码解释：输入两分钟内匹配到的数据，输入信息：（5）执行成果： ...

（1）简介及利用场景：简单事件处理(CEP)既是把不同的数据看做不同的事件，并且通过剖析事件之间的关系建设起一套事件关系序列库。利用过滤，聚合，关联性，依赖，档次等技术，最终实现由简略关系产生高级事件关系。简单事件次要利用场景：次要用于信用卡欺诈检测、用户危险检测、设施故障检测、攻击行为剖析等畛域。Flink CEP可能利用的场景较多，在理论业务场景中也有了宽泛的应用案例与教训积攒。比方 在可编程方面，Flink同时推出了Flink SQL CEP，开发者能够通过较为属性的SQL语法疾速构建各类CEP事件组合利用。Flink CEP原理阐明： （2）Flink CEP匹配模式介绍：在Flink CEP中匹配模式分为严格近邻模式和宽松近邻模式。严格近邻模式的事件必须是紧密连接的，宽松近邻事件能够无需紧密连接，如下图：  （3）Flink CEP SQL语法介绍：（3.1）Flink CEP SQL样例： String sql = "SELECT * " + "FROM CEP_SQL_3 " + " MATCH_RECOGNIZE ( " + " PARTITION BY symbol " + //分组 " ORDER BY rowtime " + //排序 " MEASURES " + //定义如何依据匹配胜利的输出事件结构输入事件 " LISTAGG(CAST(e3.id as varchar),',') as ids,"+ " AVG(e1.price) as avgPrice,"+// " START_ROW.rowtime AS start_tstamp, " + " LAST(e1.rowtime) AS bottom_tstamp, " + //第一次的事件工夫为end_timestamp " LAST(e3.rowtime) AS end_tstamp " + //最新的事件工夫为end_timestamp " ONE ROW PER MATCH " + //匹配胜利输入一条 " AFTER MATCH SKIP PAST LAST ROW " + //匹配后跳转到下一行 " PATTERN ( e1 e2 e3{1}) WITHIN INTERVAL '2' MINUTE" + //定义事件组 " DEFINE " + //定义每个事件的匹配条件 " e1 AS " + " e1.price = 25 , " + " e2 AS " + " e2.price = 18 ," + " e3 AS " + " e3.price = 15 " + " ) MR";（3.2）Flink CEP匹配规定：贪心词量和勉强词量Concatenation-像(AB)这样的模式意味着A和B之间的连贯是严格的。因而，在它们之间不能存在没有映射到A或B的行。Quantifiers-批改能够映射到模式变量的行数。* 0或者多行+ 1或者多行？ 0或者1行{n} 严格n行(n>0){n,} n或者更多行(n≥O){n,m} 在n到m（蕴含）行之间(0≤n≤m,0<m)< div="">{,m}一在0到m（蕴含）行之间(m>0) ...

public static void main(String[] args) throws Exception { StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment(); env.setParallelism(1); StreamTableEnvironment tableEnv = StreamTableEnvironment.create(env); DataStreamSource<String> streamSource = env.socketTextStream("127.0.0.1", 9999,"\n"); SingleOutputStreamOperator<WaterSensor> waterDS = streamSource.map(new MapFunction<String, WaterSensor>() { @Override public WaterSensor map(String s) throws Exception { String[] split = s.split(","); return new WaterSensor(split[0], Long.parseLong(split[1]), Integer.parseInt(split[2])); } }); // 将流转化为表 Table table = tableEnv.fromDataStream(waterDS, $("id"), $("ts"), $("vc"), $("pt").proctime()); tableEnv.createTemporaryView("EventTable", table); tableEnv.executeSql("CREATE TABLE flinksink (" + "componentname STRING," + "componentcount BIGINT NOT NULL," + "componentsum BIGINT" + ") WITH (" + "'connector.type' = 'jdbc'," + "'connector.url' = 'jdbc:mysql://localhost:3306/testdb?characterEncoding=UTF-8&useUnicode=true&useSSL=false&tinyInt1isBit=false&allowPublicKeyRetrieval=true&serverTimezone=Asia/Shanghai'," + "'connector.table' = 'flinksink'," + "'connector.driver' = 'com.mysql.cj.jdbc.Driver'," + "'connector.username' = 'root'," + "'connector.password' = 'root'," + "'connector.write.flush.max-rows'='3'\r\n" + ")" ); Table mysql_user = tableEnv.from("flinksink"); mysql_user.printSchema(); Table result = tableEnv.sqlQuery( "SELECT " + "id as componentname, " + //window_start, window_end, "COUNT(ts) as componentcount ,SUM(ts) as componentsum " + "FROM TABLE( " + "TUMBLE( TABLE EventTable , " + "DESCRIPTOR(pt), " + "INTERVAL '10' SECOND)) " + "GROUP BY id , window_start, window_end" ); //形式一：写入数据库// result.executeInsert("flinksink").print(); //;.insertInto("flinksink"); ...

本章节次要演示从socket接收数据，通过滚动窗口每30秒运算一次窗口数据，而后将后果写入Mysql数据库（1）筹备一个实体对象，音讯对象 package com.pojo; import java.io.Serializable; /** Created by lj on 2022-07-05. */public class WaterSensor implements Serializable { private String id;private long ts;private int vc;public WaterSensor(){}public WaterSensor(String id,long ts,int vc){ this.id = id; this.ts = ts; this.vc = vc;}public int getVc() { return vc;}public void setVc(int vc) { this.vc = vc;}public String getId() { return id;}public void setId(String id) { this.id = id;}public long getTs() { return ts;}public void setTs(long ts) { this.ts = ts;}} ...

滑动窗口（Sliding Windows）与滚动窗口相似，滑动窗口的大小也是固定的。区别在于，窗口之间并不是首尾相接的，而是能够“错开”肯定的地位。如果看作一个窗口的静止，那么就像是向前小步“滑动”一样。定义滑动窗口的参数有两个：除去窗口大小（window size）之外，还有一个滑动步长（window slide），代表窗口计算的频率。 demo演示：场景：接管通过socket发送过去的数据，定义一个1小时的工夫窗口大小，每30秒滑动触发运算一次（1）筹备一个实体对象，音讯对象 package com.pojo; import java.io.Serializable; /** Created by lj on 2022-07-05. */public class WaterSensor implements Serializable { private String id;private long ts;private int vc;public WaterSensor(){}public WaterSensor(String id,long ts,int vc){ this.id = id; this.ts = ts; this.vc = vc;}public int getVc() { return vc;}public void setVc(int vc) { this.vc = vc;}public String getId() { return id;}public void setId(String id) { this.id = id;}public long getTs() { return ts;}public void setTs(long ts) { this.ts = ts;}} ...

滚动窗口（Tumbling Windows） 滚动窗口有固定的大小，是一种对数据进行平均切片的划分形式。窗口之间没有重叠，也不会有距离，是“首尾相接”的状态。滚动窗口能够基于工夫定义，也能够基于数据个数定义；须要的参数只有一个，就是窗口的大小（window size）。demo演示：场景：接管通过socket发送过去的数据，每30秒触发一次窗口计算逻辑（1）筹备一个实体对象，音讯对象 package com.pojo; import java.io.Serializable; /** Created by lj on 2022-07-05. */public class WaterSensor implements Serializable { private String id;private long ts;private int vc;public WaterSensor(){}public WaterSensor(String id,long ts,int vc){ this.id = id; this.ts = ts; this.vc = vc;}public int getVc() { return vc;}public void setVc(int vc) { this.vc = vc;}public String getId() { return id;}public void setId(String id) { this.id = id;}public long getTs() { return ts;}public void setTs(long ts) { this.ts = ts;}} ...

FlinkSQL的呈现，极大水平上升高了Flink的编程门槛，更加容易了解和把握应用。明天将本人的笔记分享进去，心愿能帮忙在这方面有须要的敌人。（1）首先引入POM依赖：<properties> <flink.version>1.13.1</flink.version><scala.binary.version>2.12</scala.binary.version><slf4j.version>1.7.30</slf4j.version></properties> <dependencies> <dependency> <groupId>org.apache.flink</groupId> <artifactId>flink-java</artifactId> <version>${flink.version}</version></dependency><dependency> <groupId>org.apache.flink</groupId> <artifactId>flink-streaming-java_${scala.binary.version}</artifactId> <version>${flink.version}</version</dependency><dependency> <groupId>org.apache.flink</groupId> <artifactId>flink-clients_${scala.binary.version}</artifactId> <version>${flink.version}</version></dependency><dependency> <groupId>org.apache.flink</groupId> <artifactId>flink-table-api-java-bridge_${scala.binary.version}</artifactId> <version>${flink.version}</version></dependency><!-- https://mvnrepository.com/artifact/org.apache.flink/flink-connector-jdbc --><dependency> <groupId>org.apache.flink</groupId> <artifactId>flink-connector-jdbc_${scala.binary.version}</artifactId> <version>${flink.version}</version> <!--<scope>provided</scope>--></dependency><dependency> <groupId>org.apache.flink</groupId> <artifactId>flink-table-planner-blink_${scala.binary.version}</artifactId> <version>${flink.version}</version></dependency><dependency> <groupId>org.apache.flink</groupId> <artifactId>flink-streaming-scala_${scala.binary.version}</artifactId> <version>${flink.version}</version></dependency><dependency> <groupId>org.apache.flink</groupId> <artifactId>flink-table-common</artifactId> <version>${flink.version}</version></dependency><dependency> <groupId>org.apache.flink</groupId> <artifactId>flink-json</artifactId> <version>${flink.version}</version></dependency><!-- https://mvnrepository.com/artifact/com.fasterxml.jackson.core/jackson-databind --><dependency> <groupId>com.fasterxml.jackson.core</groupId> <artifactId>jackson-databind</artifactId> <version>2.12.0</version></dependency><!-- https://mvnrepository.com/artifact/mysql/mysql-connector-java --><dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <version>8.0.16</version></dependency><dependency> <groupId>com.alibaba</groupId> <artifactId>fastjson</artifactId> <version>1.2.66</version></dependency></dependencies> （2）编写代码public static void main(String[] args) throws Exception { final StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment();EnvironmentSettings settings = EnvironmentSettings.newInstance() .inStreamingMode() //.useOldPlanner() // flink .useBlinkPlanner() // blink .build();StreamTableEnvironment ste = StreamTableEnvironment.create(env, settings);String ddl = "CREATE TABLE flinksinksds(\r\n" + "componentname STRING,\r\n" + "componentcount INT,\r\n" + "componentsum INT\r\n" + ") WITH(\r\n" + "'connector.type'='jdbc',\r\n" + "'connector.driver' = 'com.mysql.cj.jdbc.Driver'," + "'connector.url'='jdbc:mysql://localhost:3306/testdb?characterEncoding=UTF-8&useUnicode=true&useSSL=false&tinyInt1isBit=false&allowPublicKeyRetrieval=true&serverTimezone=Asia/Shanghai',\r\n" + "'connector.table'='flinksink',\r\n" + "'connector.username'='root',\r\n" + "'connector.password'='root',\r\n" + "'connector.write.flush.max-rows'='1'\r\n" + ")";System.err.println(ddl);ste.executeSql(ddl);String insert = "insert into flinksinksds(componentname,componentcount,componentsum)" + "values('1024', 1 , 2 )";ste.executeSql(insert);env.execute();System.exit(0);} ...

摘要：本文整顿自字节跳动基础架构工程师，Apache Flink Contributor 马越在 Flink Forward Asia 2021 平台建设专场的演讲。次要内容包含： 背景State Processor API 介绍StateMeta Snapshot 机制State as Database应用 Flink Batch SQL 查问工作状态将来瞻望点击查看直播回放 & 演讲PDF 一、背景家喻户晓，Flink 中的 State 保留了算子计算过程的两头后果。当工作出现异常时，能够通过查问工作快照中的 State 获取无效线索。 但目前对于 Flink SQL 工作来说，当咱们想要查问作业 State 时，通常会因为无奈获知 State 的定义形式和具体类型等信息，而导致查问 State 的老本过高。 为了解决这个问题，字节跳动流式计算团队在外部提出了 State Query on Flink SQL 的解决方案——用户通过写 SQL 的形式就能够简略地查问 State。本文将次要介绍字节跳动在 Flink 状态查问这方面所进行的相干工作。 二、State Processor API 介绍 提到状态查问，咱们天然会联想到 Flink 在 1.9 版本提出的个性 -- State Processor API。应用 State Processor API，咱们能够将作业产生的 Savepoint 转换成 DataSet，而后应用 DataSet API 实现对 State 的查问、批改和初始化等操作。 ...

摘要：本文整顿自中原银行数据平台核心开发工程师陈玉强在 Flink Forward Asia 2021 行业实际专场的演讲。次要内容包含： 建设体系选型 & 架构利用场景建设功效点击查看直播回放 & 演讲PDF 一、建设体系银行是经营风险的企业，对危险进行辨认、掂量、定价和防备的能力是银行外围竞争力。中原银行构建了面向反欺诈、信用风险、经营危险的业务全流程风控体系。 银行业务的申请、交易、营销等环节都可能存在欺诈行为，随着技术倒退，在欺诈行为团伙化、荫蔽化、专业化、实时化状况下进行反欺诈难度越来越大。同时，随着业务品种增多，传统的专家规定评分卡模型难以应酬简单的风控场景，须要借助大数据、实时计算、机器学习、常识图谱等高新技术打造高质量的授信能力。此外，是否可能及时发现和化解业务经营危险，包含流程危险、员工异样行为、资产及负债流动性危险也面临较大挑战。 传统技术应答这些挑战时难以实时获取用户多渠道的操作行为，难以达到全方位、实时化的防控成果。传统风控体系广泛基于专家规定进行测算，存在规定触发阈值难以管制、排汇低饱和乐音数据难度大等特点，很难通过累计规定数量来晋升精准度。此外，传统零碎间绝对孤立、数据流通难度大、数据孤岛的状况导致了专家规定制订和模型训练难度大，不利于整体风控成果。 新的风控体系首先实现了实时化，通过流计算、内存计算等技术进步数据处理的时效性，做到了及时辨认跨零碎的危险行为，并通过云原生、资源弹性等技术进步零碎的高并发能力。在晋升硬实力的同时更重视智能化，将基于概率的机器学习模型与专家规定联合，充沛开释大数据价值，防止专家规定教训盲区。此外，通过打造平台化的产品，造成不同场景的疾速撑持能力和欠缺的风控体系。 近三年咱们经验了对实时计算的摸索、尝试和平台化建设，并将实时计算技术利用至反欺诈、事件驱动、实时 OLAP 等多种场景，2021 年底工作数量和日均解决数据量都晋升数倍。在风控方面，经验了从引入国外决策零碎到自研决策平台的转变，2021 年自研决策平台曾经开始承接新需要和局部国外决策零碎迁徙而来的规定模型。 智能风控体系能力模型能够总结为： 危险特色辨认及计算实时化；交融专家规定与机器学习模型通过简单编排提供智能化的决策能力；通过平台化屏蔽技术细节，给用户提供敌对的应用体验。在风控体系中通过标准化来制订标准、构建数据规范和凋谢数据能力。并通过构建 ModelOps 管理体系实现危险模型从需要到投产的全生命周期治理。此外，通过低代码、可视化的形式有助于升高应用门槛。二、选型 & 架构 在本体系架构中，Flink 次要用于数据荡涤、实时维表加工与关联以及窗口计算等场景，通过预计算、内存计算、聚合计算实现根底指标、衍生指标、复合指标的加工，为决策模型提供特色反对。模型编排专一于编排决策集、评分卡、决策树、决策表等丰盛和易用规定模型，同时在规定中能够调用指标服务、算法模型服务独特参加逻辑运算。 风控体系基于云原生架构和开源技术实现，反对报文、接口、多种类型数据库。通过数据源、维表、参数配置界面化，并反对用户用 Flink SQL 编写业务逻辑，极大水平升高了实时计算的应用门槛。通过可视化编排 (DAG) 将规定/模型/指标引擎的计算能力进行组合以撑持风控决策。此外还有一些特色性能，如 SQL 评分、网关分流等。 实时指标能够用于专家规定，实时特色能够供在线 (online) 模型训练。机器学习平台应用离线 (offline) 数据进行模型训练和模型推理，同时联合规定筛选进去的危险数据，基于离线数据进行有监督和无监督的算法训练。 三、利用场景 反欺诈是交易的重要环节，通常会基于黑白名单、常识图谱、司法、税务、工商等内外部数据对交易数据打宽，打宽后的数据用于专家规定和机器学习模型。交易发动零碎会依据智策平台的决策后果对交易放行或增强验证。危险后果数据可作为样本，用于图数据进行关联开掘或特征分析，或者用于有监督学习。 技术实现方面，针对交易申请，智策平台会依据 DAG 编排逻辑来调用不同的计算引擎，并返回计算结果。同时，实时计算平台会应用交易系统数据库的变动数据计算交易/行为等实时指标。此外，历史数据会被抽取到离线数仓和数据湖中，供上游的机器学习平台应用。 对授信广义且简略的了解就是金融机构向客户提供资金的行为。智策平台通过评分卡、决策集等形式承载了贷前阶段 50 余个场景，日均接管授信申请约 3 万笔；对于以批量数据处理为主的贷中、贷后环节，日均解决数据 1300 万条。 授信场景较交易反欺诈场景在技术架构显著的差别在于它须要内部数据反对。智策平台将关联了内外部数据的交易变量进行专家规定运算、机器学习模型推理。授信场景临时没有应用实时指标。 员工行为、信贷管理、舆情剖析都在经营危险的领域内，将冲正行为、机具治理等场景数据加工成离线经营危险指标，将高敏感行为数据加工为实时指标，通过智策平台对两类指标进行规定、模型运算而得出预警后果，进而造成危险核查事件、名单等。后果数据也会作为危险特色样本来训练算法和开掘危险。 经营危险的技术架构比拟直观，每天将历史业务数据同步到数据仓库，在数仓中实现危险指标的加工，同时离线数据也会被用于模型训练。智策平台每天定时对离线指标进行规定运算，并将危险预警后果推送给上游经营零碎。 四、建设功效 ...

导读：本文基于Flink + Apache Doris 构建实时数仓的业务场景的调研后果，根据用户的面临的挑战和问题对 Flink 实时写入 Apache Doris 的优化实现与将来布局进行了具体的介绍。背景随着数据实时化需要的日益增多，数据的时效性对企业的精细化经营越来越重要，在海量数据中，如何能实时无效的挖掘出有价值的信息，疾速的获取数据反馈，帮助公司更快的做出决策，更好的进行产品迭代，实时数仓在这一过程中起到了不可代替的作用。 在这种局势下，Apache Doris 作为一款实时 MPP 剖析型数据库怀才不遇，同时具备高性能、简略易用等个性，具备丰盛的数据接入形式，联合 Flink 流式计算，能够让用户疾速将 Kafka 中的非结构化数据以及 MySQL 等上游业务库中的变更数据，疾速同步到 Doris 实时数仓中，同时 Doris 提供亚秒级剖析查问的能力，能够无效地满足实时 OLAP、实时数据看板以及实时数据服务等场景的需要。 挑战通常实时数仓要保障端到端高并发以及低提早，往往面临诸多挑战，比方： 如何保障端到端的秒级别数据同步？如何疾速保障数据可见性？在高并发大压力下，如何解决大量小文件写入的问题？如何确保端到端的 Exactly Once 语义？联合这些挑战，同时对用户应用 Flink+Doris 构建实时数仓的业务场景进行深刻调研，在把握了用户应用的痛点之后，咱们在 Doris 1.1 版本中进行了针对性的优化，大幅晋升实时数仓构建的用户体验，同时晋升零碎的稳定性，系统资源耗费也失去了大幅的优化。 优化流式写入Flink Doris Connector 最后的做法是在接管到数据后，缓存到内存 Batch 中，通过攒批的形式进行写入，同时应用 batch.size、batch.interval 等参数来管制 Stream Load 写入的机会。这种形式通常在参数正当的状况下能够稳固运行，一旦参数不合理导致频繁的 Stream Load，便会引发 Compaction 不及时，从而导致 version 过多的谬误(-235)；其次，当数据过多时，为了缩小 Stream Load 的写入机会，batch.size 过大的设置还可能会引发 Flink 工作的 OOM。为了解决这个问题，咱们引入了流式写入 ： Flink 工作启动后，会异步发动一个 Stream Load 的 Http 申请。接管到实时数据后，通过 Http 的分块传输编码(Chunked transfer encoding)机制继续向 Doris 传输数据。3. 在 Checkpoint 时完结 Http 申请，实现本次 Stream Load 写入，同时异步发动下一次 Stream Load 的申请。4. 持续接管实时数据，后续流程同上。因为采纳 Chunked 机制传输数据，就防止了攒批对内存的压力，同时将写入的机会和 Checkpoint 绑定起来，使得 Stream Load 的机会可控，并且为上面的 Exactly-Once 语义提供了根底。 ...

摘要：本文整顿自科大讯飞中级大数据工程师汪李之在 Flink Forward Asia 2021 的分享。本篇内容次要分为四个局部： 业务简介数仓演进场景实际将来瞻望点击查看直播回放 & 演讲PDF 一、业务简介 构建实时数据分析平台是为了更好的解决业务对更高数据时效性的需要，先简略介绍一下业务流程。 从日常的场景说起，当咱们关上手机 APP 时，常会看到广告。在这样一个场景中，波及到了两个比拟重要的角色。一是手机 APP，即流量方；另一个是投广告的广告主，如支付宝、京东会投放电商广告。广告主购买流量方的流量投广告就产生了交易。 讯飞构建了一个流量交易平台，流量交易平台次要的职能是聚合上游流量，上游再对接广告主，从而帮忙广告主和流量方在平台上进行交易。讯飞还构建了投放平台，这个平台更侧重于服务广告主，帮忙广告主投放广告，优化广告成果。 在上述的业务流程图中，APP 与平台交互时会向平台发动申请，而后平台会下发广告，用户随后能力看到广告。用户看到广告的这个动作称之为一次曝光，APP 会把这次曝光行为上报给平台。如果用户点击了广告，那么 APP 也会上报点击行为。 广告在产生之后产生了很多行为，能够将广告的整个过程称为广告的一次生命周期，不仅限于图中的申请、曝光、点击这三次行为，前面可能还有下单、购买等。 在这样一个业务流程中，业务的外围诉求是什么呢？在广告的生命周期中有申请、曝光和点击等各种行为，这些行为会产生对应的业务日志。那么就须要从日志生成数据供业务侧剖析，从日志到剖析的过程中就引入了数仓构建、数仓分层，数据出现的时效性就带来了实时数据仓库的倒退。 二、数仓演进 上图是一个典型的数仓分层框架，最底层是 ODS 数据，包含业务日志流、OLTP 数据库、第三方文档数据。通过 ETL 将 ODS 层的数据荡涤成业务模型，也就是 DWD 层。 最后是建设了 Spark 数仓，将业务日志收集到 Kafka 中再投递到 HDFS 上，通过 Spark 对日志进行荡涤建模，而后将业务模型再回写到 HDFS 上，再应用 Spark 对模型进行统计、剖析、输入报表数据。后续，讯飞沿用了 Spark 技术栈引入了 spark-streaming。 随后逐步将 spark-streaming 迁徙到了 Flink 上，次要是因为 Flink 更高的时效性和对事件工夫的反对。 当初 spark-streaming 的实际是微批的，个别设置 10 秒或是 30 秒一批，数据的时效性顶多是秒级的。而 Flink 能够反对事件驱动的开发模式，实践上时效性能够达到毫秒级。 ...

摘要：本文整顿自 Apache Flink Committer，Flink CDC Maintainer，阿里巴巴高级开发工程师徐榜江（雪尽）在 5 月 21 日 Flink CDC Meetup 的演讲。次要内容包含： Flink CDC 技术传统数据集成计划的痛点基于 Flink CDC 的海量数据的实时同步和转换Flink CDC 社区倒退点击查看直播回放 & 演讲PDF 一、Flink CDC 技术 CDC 是 Change Data Capture 的缩写，是一种捕捉变更数据的技术，CDC 技术很早就存在，倒退至今，业界的 CDC 技术计划泛滥，从原理上能够分为两大类： 一类是基于查问的 CDC 技术 ，比方 DataX。随着当下场景对实时性要求越来越高，此类技术的缺点也逐步凸显。离线调度和批处理的模式导致提早较高；基于离线调度做切片，因此无奈保障数据的一致性；另外，也无奈保障实时性。一类是基于日志的 CDC 技术，比方 Debezium、Canal、 Flink CDC。这种 CDC 技术可能实时生产数据库的日志，流式解决的模式能够保障数据的一致性，提供实时的数据，能够满足当下越来越实时的业务需要。 上图为常见开源 CDC 的计划比照。能够看到 Flink CDC 的机制以及在增量同步、断点续传、全量同步的体现都很好，也反对全增量一体化同步，而很多其余开源计划无奈反对全增量一体化同步。Flink CDC 是分布式架构，能够满足海量数据同步的业务场景。依附 Flink 的生态劣势，它提供了 DataStream API 以及 SQL API，这些 API 提供了十分弱小的 transformation 能力。此外，Flink CDC 社区和 Flink 社区的开源生态十分欠缺，吸引了很多社区用户和公司在社区开发共建。 ...

摘要：本文整顿自网易游戏资深开发工程师林小铂在 Flink Forward Asia 2021 平台建设专场的演讲。次要内容包含： 网易游戏 Flink SQL 倒退历程基于模板 jar 的 StreamflySQL v1基于 SQL Gateway 的 StreamflySQL v2将来工作点击查看直播回放 & 演讲PDF 一、网易游戏 Flink SQL 倒退历程 网易游戏实时计算平台叫做 Streamfly，这个名字取名自电影《驯龙高手》中的 Stormfly。因为咱们曾经在从 Storm 迁徙到 Flink，所以将 Stormfly 中的 Storm 替换成了更为通用的 Stream。 Streamfly 前身是离线作业平台 Omega 下的名为 Lambda 的子系统，它负责了所有实时作业的调度，最开始开始反对 Storm 和 Spark Streaming，起初改为只反对 Flink。在 2019 年的时候咱们将 Lambda 独立进去以此为根底建设了 Streamfly 计算平台。随后，咱们在 2019 年底开发并上线了第一个版本 Flink SQL 平台 StreamflySQL。这个版本基于模板 jar 提供了根本 Flink SQL 的性能，然而用户体验还有待晋升，因而咱们在 2021 年年初从零开始从新建设了第二个版本的 StreamflySQL，而第二个版本是基于 SQL Gateway。 ...

起源｜Apache Flink 官网博客Apache Flink 社区很荣幸地发表 Apache Flink ML 2.1.0 版本正式公布！本次公布的版本重点改良了 Flink ML 的基础设施，例如 Python SDK，内存治理，以及性能测试框架，来帮忙开发者基于 Flink ML 开发具备高性能，高稳定性，以及高易用性的机器学习算法库。 基于本次发版中提出的改良，以及咱们失去的性能测试后果，咱们置信 Flink ML 的基础设施曾经筹备好提供给社区开发者应用，来开发高性能的、反对 Python 环境的机器学习算法库。 咱们激励您下载该版本 [1] 并通过 Flink 邮件列表 [2] 或 JIRA [3] 与社区分享您的反馈！咱们心愿您喜爱新版本，并且咱们期待理解您的应用体验。 重要个性1. 算子接口和基础设施1.1 反对算子级别粒度的内存管控在之前的版本中，机器学习算子的外部状态数据，例如须要被缓存并在每轮迭代中反复读取的训练数据，是被贮存在 state backend 中。这些数据之前只能是全量放在内存中，或者全量放在磁盘上。前一种状况，状态数据量大的状况下，可能导致 OOM 和升高作业稳定性。后一种状况，因为每轮迭代会须要从磁盘读取全量数据并且进行反序列化，在状态数据量不大的状况下，性能低于把数据放在内存中的做法。这个问题减少了开发者开发高性能和高稳定性算子的难度。 在本次发版中，咱们改良了 Flink ML 的基础设施，容许指定一个算子能够应用的托管内存配额。在算子状态数据量低于配额的状况下，这些状态数据会被寄存在 Flink 的管控内存中。当算子状态数据量高于配额时，超出配额的数据会被寄存在磁盘上，以防止产生 OOM。算法开发者能够应用这个机制容许算子对于不同的输出数据量，都能提供最佳性能。开发者能够参考 KMeans 算子的代码来学习应用这个机制。 1.2 开发在线训练算法的基础设施的改良Flink ML 的一个重要指标是推动在线训练算法的倒退。在上一个版本中，咱们通过提供 setModelData() 和 getModelData() 办法，让在线训练算法的模型数据能以有限数据流的模式被传输和保留，加强了 Flink ML API 对于在线训练算法的反对能力。本次发版进一步改良和验证了 Flink ML 基础设施对于在线训练算法的反对能力。 本次发版增加了 2 个在线训练算法 (i.e. OnlineKMeans and OnlineLogisticRegression)，并提供了单元测试，验证和测试了这些算法的正确性。这两个算法引入了 global batch size，模型版本等概念，并提供了指标和接口来设置和读取相应的信息。尽管这两个算法的预测准确率还没通过调优，然而这些工作将帮忙咱们进一步建设开发在线训练算法的最佳实际。咱们心愿越来越多的社区贡献者能退出咱们，共同完成这个指标。 ...

作者｜高赟（云骞）点击进入 Flink 中文学习网 第一局部 简介Flink 能够同时反对无限数据集和有限数据集的分布式解决。在最近几个版本中，Flink 逐渐实现了流批一体的 DataStream API 与 Table / SQL API。大部分用户都同时有流解决与批处理的需要，流批一体的开发接口能够帮忙这些用户减小开发、运维与保障两类作业处理后果一致性等方面的复杂度， 例如阿里巴巴双十一的场景 [1]。 图1. 流执行模式与批执行模式的比照。以Count算子为例，在流模式下，达到的数据是无序的，算子将会读写与该元素对应的状态并进行增量计算。而在批模式下，算子将首先对数据排序，雷同Key的数据将被对立解决。 在流批一体的接口之下，Flink 提供了两种不同的执行模式，即流执行模式与批执行模式。流执行模式下 Flink 基于中间状态增量的解决达到的数据，它能够同时反对无限数据与有限数据的解决。批执行模式则是基于按拓扑序顺次执行作业中的所有工作，并通过事后对数据进行排序来防止对状态的随机拜访，因而它只能用于无限数据的解决，然而个别状况下能够获得更好的性能。尽管许多场景下用户间接采纳批处理模式来解决无限数据集，然而也存在许多场景用户依然依赖流解决模式来解决无限数据集。例如，用户可能想要应用 SQL 的 Retraction 性能或者用户可能依赖于流模式下数据近似按工夫有序的性质（例如 Kappa+ 架构 [2])。此外，许多用户须要执行同时包含有限数据流与无限维表的作业，这类作业也必须采纳流执行模式。 在流执行模式下，Checkpointing [3] 是保障 Exactly-once 语义的外围机制。通过定期的保留作业的状态，当产生谬误时 Flink 能够从最新的保留点复原并继续执行。然而，在之前的版本中，Flink 不反对当局部工作执行完结之后进行 Checkpoint 操作。对于同时包含有限和无限数据输出的作业，这个问题将导致当无限数据输出解决实现后作业无奈持续进行 Checkpoint 操作，从而导致当产生谬误时须要从很久之前从新计算。 此外，无奈对于局部工作完结后的作业进行 Checkpoint 操作也会影响应用两阶段提交 Sink 来保障端到端一致性 [4] 的作业。为了保障端到端一致性，两阶段提交的 Sink 通常首先将数据写入临时文件或者启用内部零碎的事务，而后在 Checkpoint 胜利实现后提交 Checkpoint 之前写入的数据，从而防止在产生谬误后重放这部分数据导致数据反复。然而，如果作业中蕴含无限数据源，在这部分源节点工作完结后作业将无奈持续提交数据。特地是对于所有数据源均为无限数据源的状况，作业总是无奈提交最初一次 Checkpoint 到作业执行完结两头的这部分数据。在之前的实现中，Flink 在作业完结时间接疏忽这部分数据，这对于用户带来了极大的困扰，在邮件列表中也有不少用户在询问这个问题。 因而，为了欠缺流执行模式对无限数据流的反对，Flink 须要： 反对工作完结后持续进行 Checkpoint 操作。修改作业完结的流程，保障所有数据都能够被失常提交。下文咱们将首先简要形容针对这两个指标所进行的改变。在第二局部，咱们也将分享更具体的实现。 反对蕴含结束任务的 Checkpoint总体来说，反对蕴含结束任务的 Checkpoint 操作的外围思路是给曾经执行实现的算子打标，从而在重启后能够跳过这部分算子的执行。如图 2 所示，在 Flink 中，Checkpoint 是由所有算子的状态来组成的。如果一个算子的所有并发都曾经执行实现，那们咱们就能够将该算子标记为『执行实现』，并在重启后跳过。对于其它算子，算子的状态是由所有以后还在运行的并发的状态组成，当重启后，算子状态将在所有并发中从新划分。 ...

摘要：本文整顿自快手实时计算团队技术专家刘建刚在 Flink Forward Asia 2021 生产实践专场的演讲。次要内容包含： 快手 Flink 的历史及现状Flink 容错能力晋升Flink 引擎管制与实际快手批处理实际将来布局点击查看直播回放 & 演讲PDF 一、快手 Flink 的历史与现状 快手从 2018 年开始对 Flink 进行深度整合，通过 4 年倒退，实时计算平台逐步欠缺并赋能周边各种组件。 2018 年咱们针对 Flink 1.4 进行了平台化建设并大幅晋升运维治理能力，达到了生产可用。2019 年咱们开始基于 1.6 版本进行迭代开发，很多业务都开始实时化，比方优化 interval join 为商业化等平台带来显著收益、开发实时多维分析减速超大多维报表的实时化，这一年咱们的 Flink SQL 平台也投入使用。到了 2020 年，咱们降级到 1.10，对 sql 的性能进行了十分多的欠缺，同时进一步优化 Flink 的外围引擎，保障了 Flink 的易用性、稳定性、可维护性。2021 年咱们开始发力离线计算，反对湖仓一体的建设，进一步欠缺 Flink 生态。 上图是快手基于 Flink 的技术栈。 最外围、最底层是 Flink 的计算引擎，包含流计算和批处理，咱们针对稳定性和性能做了大量工作。里面一层是跟 Flink 打交道的周边组件，既有 Kafka、rocketMQ 等中间件，也有 ClickHouse、Hive 等数据分析工具，还有 Hudi 等数据湖的应用。用户能够基于 Flink 和这些组件构建各种利用，涵盖了实时、近实时、批处理的各种场景。最外层是具体的应用场景，常见的有电商、商业化等视频相干的业务方，利用场景蕴含机器学习、多维分析等。另外还有很多技术部门基于 Flink 来实现数据的导入、转换，比方 CDC、湖仓一体等。 利用规模上，咱们有 50 万 CPU 核，次要通过 Yarn 和 K8s 的形式进行资源托管，下面运行着 2000+ 作业，峰值解决达到了 6亿/秒，日解决条数达到了 31.7 万亿，节假日或流动的时候流量甚至会翻倍。 ...

摘要：本文整顿自京东高级技术专家韩飞在 Flink Forward Asia 2021 流批一体专场的分享。次要内容包含： 整体思考技术计划及优化落地案例将来瞻望点击查看直播回放 & 演讲PDF 一、整体思考 提到流批一体，不得不提传统的大数据平台 —— Lambda 架构。它可能无效地撑持离线和实时的数据开发需要，但它流和批两条数据链路割裂所导致的高开发保护老本以及数据口径不统一是无奈漠视的缺点。 通过一套数据链路来同时满足流和批的数据处理需要是最现实的状况，即流批一体。此外咱们认为流批一体还存在一些两头阶段，比方只实现计算的对立或者只实现存储的对立也是有重大意义的。 以只实现计算对立为例，有一些数据利用的实时性要求比拟高，比方心愿端到端的数据处理延时不超过一秒钟，这对目前开源的、适宜作为流批对立的存储来说是一个很大的挑战。以数据湖为例，它的数据可见性与 commit 的距离相干，进而与 Flink 做 checkpoint 的工夫距离相干，此个性联合数据处理链路的长度，可见做到端到端一秒钟的解决并不容易。因而对于这类需要，只实现计算对立也是可行的。通过计算对立去升高用户的开发及保护老本，解决数据口径不统一的问题。 在流批一体技术落地的过程中，面临的挑战能够总结为以下 4 个方面： 首先是数据实时性。如何把端到端的数据时延升高到秒级别是一个很大的挑战，因为它同时波及到计算引擎及存储技术。它实质上属于性能问题，也是一个长期指标。第二个挑战是如何兼容好在数据处理畛域曾经广泛应用的离线批处理能力。此处波及开发和调度两个层面的问题，开发层面次要是复用的问题，比方如何复用曾经存在的离线表的数据模型，如何复用用户曾经在应用的自定义开发的 Hive UDF 等。调度层面的问题次要是如何正当地与调度零碎进行集成。第三个挑战是资源及部署问题。比方通过不同类型的流、批利用的混合部署来进步资源利用率，以及如何基于 metrics 来构建弹性伸缩能力，进一步提高资源利用率。最初一个挑战也是最艰难的一个：用户观点。大多数用户对于比拟新的技术理念通常仅限于技术交换或者验证，即便验证之后感觉能够解决理论问题，也须要期待适合的业务来试水。这个问题也催生了一些思考，平台侧肯定要多站在用户的视角对待问题，正当地评估对用户的现有技术架构的改变老本以及用户收益、业务迁徙的潜在危险等。 上图是京东实时计算平台的全景图，也是咱们实现流批一体能力的载体。两头的 Flink 基于开源社区版本深度定制。基于该版本构建的集群，内部依赖蕴含三个局部，JDOS、HDFS/CFS 和 Zookeeper。 JDOS 是京东的 Kubernetes 平台，目前咱们所有 Flink 计算工作容器化的，都运行在这套平台之上；Flink 的状态后端有 HDFS 和 CFS 两种抉择，其中 CFS 是京东自研的对象存储；Flink 集群的高可用是基于 Zookeeper 构建的。在利用开发方式方面，平台提供 SQL 和 Jar 包两种形式，其中 Jar 的形式反对用户间接上传 Flink 利用 Jar 包或者提供 Git 地址由平台来负责打包。除此之外咱们平台化的性能也绝对比较完善，比方根底的元数据服务、SQL 调试性能，产品端反对所有的参数配置，以及基于 metrics 的监控、工作日志查问等。 连贯数据源方面，平台通过 connector 反对了丰盛的数据源类型，其中 JDQ 基于开源 Kafka 定制，次要利用于大数据场景的音讯队列；JMQ 是京东自研，次要利用于在线零碎的音讯队列；JimDB 是京东自研的分布式 KV 存储。 ...

编者荐语：随着领创团体的疾速倒退，为了满足十亿级数据量的实时报表统计与决策分析，领创集团选择了 Flink + Doris 的实时数仓计划。本篇文章详尽了介绍了此计划的实际过程。以下文章来源于领创团体Advance Group， 作者苏浩 原文链接：https://mp.weixin.qq.com/s/qg... 业务背景Advance Intelligence Group（领创团体）成立于 2016 年，是一家以 AI 技术驱动的科技团体，致力于通过科技翻新的本地化利用，革新和重塑金融和批发行业，以多元化的业务布局打造一个服务于消费者、企业和商户的生态圈。团体旗下蕴含企业业务和消费者业务两大板块，企业业务蕴含 ADVANCE.AI 和 Ginee，别离为银行、金融、金融科技、批发和电商行业客户提供基于 AI 技术的数字身份验证、风险管理产品和全渠道电商服务解决方案；消费者业务 Atome Financial 包含亚洲当先的先享后付平台 Atome 和数字金融服务。 2021 年 9 月，领创团体发表实现超 4 亿美元 D 轮融资，融资实现后领创团体估值已超 20 亿美元，成为新加坡最大的独立科技守业公司之一。业务笼罩新加坡、印度尼西亚、中国大陆、印度、越南等 17 个国家与地区，服务了 15 万以上的商户和 2000 万消费者。 随着团体业务的疾速倒退，为满足十亿级数据量的实时报表统计与决策分析，咱们抉择基于 Apache Flink + Apache Doris 构建了实时数仓的零碎计划。 Doris 基本原理Apache Doris 根本架构非常简单，只有 FE(Frontend)、BE(Backend) 两种角色，不依赖任何内部组件，对部署和运维十分敌对。架构图如下： FE（Frontend）以 Java 语言为主。 次要性能职责： 接管用户连贯申请（MySQL 协定层）元数据存储与治理查问语句的解析与执行打算下发集群管控FE 次要有有两种角色，一个是 Follower，还有一个 Observer，Leader 是通过选举推选出的非凡 Follower。Follower 次要是用来达到元数据的高可用，保障单节点宕机的状况下，元数据可能实时地在线复原，而不影响整个服务。 BE（Backend） 以 C++ 语言为主。 ...

摘要：本文整顿自快手实时计算数据团队技术专家李天朔在 Flink Forward Asia 2021 实时数仓专场的演讲。次要内容包含： 业务特点及实时数仓保障痛点快手实时数仓保障体系架构春节流动实时保障实际将来布局点击查看直播回放 & 演讲PDF 一、业务特点及实时数仓保障痛点 快手最大的业务特点就是数据量大。每天入口流量为万亿级别。对于这么大的流量入口，须要做正当的模型设计，避免反复读取的适度耗费。另外还要在数据源读取和标准化过程中，极致压迫性能保障入口流量的稳固执行。第二个特点是诉求多样化。快手业务的需要包含流动大屏的场景、2B 和 2C 的业务利用、外部外围看板以及搜寻实时的撑持，不同的场景对于保障的要求都不一样。如果不做链路分级，会存在高低优先级凌乱利用的景象，对于链路的稳定性会产生很大的影响。此外，因为快手业务场景的外围是做内容和创作者的 IP，这就要求咱们构建通用维度和通用模型，避免反复烟囱建设，并且通过通用模型疾速撑持利用场景。第三个特点是流动场景频繁，且流动自身有很高的诉求。外围诉求次要为三个方面：可能体现对公司大盘指标的牵引能力、可能对实时参与度进行剖析以及流动开始之后进行玩法策略的调整，比方通过对红包老本的实时监控疾速感知流动成果。流动个别都会有上百个指标，但只有 2-3 周的开发工夫，这对于稳定性的要求就很高。最初一个特点是快手的外围场景。一个是提供给高管的外围实时指标，另外一个是提供给 C 端的实时数据利用，比方快手小店、创作者核心等。这对数据精度的要求极其高，呈现问题须要第一工夫感知并染指解决。以上因素形成了快手实时数仓建设和保障场景的必要性。 在实时数仓保障的起始阶段，咱们借鉴了离线侧的保障流程和标准，依照生命周期划分了三个阶段：研发阶段、生产阶段和服务阶段。 研发阶段构建了模型设计规范、模型开发标准以及公布的 checklist。生产阶段次要构建底层监控能力，对于时效性、稳定性、准确性几个方面进行监控，并且按照监控能力进行 SLA 优化和治理晋升。服务阶段明确了上游对接的服务规范和保障级别，以及对于整个服务的价值评估。然而相比于离线，实时的学习老本颇高，实现以上建设后，各个结算仍然存在几个问题： 研发阶段：Flink SQL 的学习曲线相比于 Hive SQL 更高，容易在开发阶段引入隐患。另外，实时计算场景下，流动呈现洪峰时是否疾速生产，也是一个未知数。最初，DWD 层的反复生产对于实时侧的资源挑战也很大，在抉择数据源和依赖关系时须要思考资源问题。生产阶段： state 没有清理机制会导致状态变大、作业频繁失败。另外高优先级和低优先级部署须要机房隔离，因而须要在上线前就安顿好，上线后再进行调整，老本会比离线高很多。服务阶段：对于一个实时工作，最无奈承受的就是作业流程失败、重启，导致数据反复或者曲线掉坑的问题。为了防止这类问题，须要有标准化的计划，而离线大概率能够保障重启后数据一致性。 形象来看，实时数仓相比于离线，还存在几个保障难点，具体体现在以下几个方面： 高时效性。相比于离线的执行工夫，实时状况下，提早分钟级就要染指运维，对时效性要求很高。复杂性。次要体现在两个方面：一方面数据不是导入即可查，数据逻辑验证的难度更高；另外一方面，实时大多是有状态，服务产生问题的时候状态不肯定可能被残缺保留，会存在很多无奈复现的 bug。数据流量大。整体的 QPS 比拟高，入口流量级别在亿级。问题随机性。实时数仓产生问题的工夫点更加随机，没有法则可循。开发能力参差不齐。如何保障通用场景的开发计划对立，避免因开发计划不同而产生不可控的问题。二、快手实时数仓保障体系架构 基于以上保障的难度，咱们设计了两条思路来解决，次要分为两个方面： 一方面是以开发生命周期为根底的正向保障思路，确保每一个生命周期都有标准和计划领导，标准化 80% 的惯例需要。另一方面是以故障注入和场景模仿为根底的反向保障思路，通过场景模仿和故障注入，确保保障措施真正落地并合乎预期。2.1 正向保障 正向保障的整体思路如下： 开发阶段次要做需要调研，针对开发过程中根底层如何开发、应用层如何开发进行标准化解决，能够解决 80% 的通用需要，残余 20% 的个性化需要通过计划评审的形式来满足，同时一直从个性化需要中积淀标准化计划。测试阶段次要做品质验证和离线侧比照以及压测资源预估。自测阶段次要通过离线实时的一致性比照、server 看板和实时后果比照来保障整体准确性。上线阶段次要针对重要工作上线须要筹备的预案，确认上线前动作、上线中部署形式和上线后的巡检机制。服务阶段次要是针对于指标做监控和报警机制，确保服务是在 SLA 规范之内的。最初是下线阶段，次要做资源的回收和部署还原工作。 快手的实时数仓分为三个档次： 第一，DWD 层。DWD 层逻辑侧比较稳定且很少有个性化，逻辑批改分为三种不同的格局数据：客户端、服务端和 Binlog 数据。 第一项操作是拆分场景，因为实时数仓没有分区表的逻辑，所以场景拆分的目标是生成子 topic，避免反复生产大 topic 的数据。第二个操作就是字段标准化，其中包含纬度字段的标准化解决、脏数据的过滤、IP 和经纬度一一映射关系的操作。第三是解决逻辑的维度关联，通用维度的关联尽量在 DWD 层实现，避免上游过多流量依赖导致维表压力过大，通常维表是通过 KV 存储 + 二级缓存的形式来提供服务。第二，DWS 层。这里有两种不同的解决模式：一是以维度和分钟级窗口聚合为根底的 DWS 层，为上游可复用场景提供聚合层的撑持；二是单实体粒度的 DWS 层数据，比方原始日志里外围用户和设施粒度的聚合数据，能够极大地缩小 DWD 层大数据量的关联压力，并可能更无效地进行复用。DWS 层数据也须要进行维度裁减，因为 DWD 层数据量过大，无奈齐全 cover 维度关联的场景，因而维度关联 QPS 过高并有肯定延时的需要，须要在 DWS 层实现。第三，ADS 层。它的外围是依赖 DWD 层和 DWS 层的数据进行多维聚合并最终输入后果。 ...

flink stop-cluster.sh敞开集群不起作用。提醒: No taskexecutor daemon to stop on host xxxx......起因: flink的过程默认存储在/tmp目录下，该目录为长期目录，会被零碎清理，当存储在/tmp下的过程被清理后，执行stop-cluster.sh就无奈找到对应的过程并进行进行了。解决方案: 更改寄存flink过程的目录，批改flink bin目录下的config.sh文件。DEFAULT_ENV_PID_DIR="/tmp"，将tmp批改为指定的不会被清理的目录即可。jps 查问过程kill xxxx再次启动集群，执行stop-cluster.sh，此时就能够通过脚本来敞开集群了

摘要：本文整顿自美团实时数仓平台负责人姚冬阳在 Flink Forward Asia 2021 实时数仓专场的演讲。次要内容包含： 平台建设现状遇到的问题及解决将来布局点击查看直播回放 & 演讲PDF 一、平台建设现状 美团于 2018 年首次引入 Flink 实时计算引擎，过后的实时数仓概念还不太遍及，平台只提供了 Flink Jar 工作的生命周期治理和监控报警。 2019 年，咱们留神到实时计算的次要利用场景是解决离线数仓时效性低的问题。离线数仓曾经比拟成熟，通过 SQL 形式开发很简略，而数仓的实时局部次要通过 Flink DataStream API 来开发，门槛比拟高，而且与离线数仓的开发方式相比较为割裂。因而，咱们开始调研实时数仓的解决方案，指标是升高开发门槛，并尝试推广 FlinkSQL，最终将美团的实时数仓平台取名为 NAU。 2020 年，美团实时数仓平台正式上线。它向业务提供 FlinkSQL 作业开发入口，次要负责两个方面的工作： 首先，将实时数仓常见的数据源与离线表概念对齐，用数据模型进行治理；其次，提供 FlinkSQL 开发配套的效率工具，比方校验和调试性能。然而在理论推广过程中，咱们发现业务在 FlinkSQL 的运维方面门槛仍然比拟高，因而，咱们将接下来的工作重点转向了运维核心。 FlinkSQL 作业运维的痛点次要集中在两个方面：有状态 SQL 作业部署的断流问题和 SQL 作业的异样定位问题。为此，咱们通过 Checkpoint 长久化和状态生成的异步化来解决第一个问题，并通过提供作业的主动诊断来解决第二个问题。目前，整个实时数仓的平台化建设曾经初步齐备，将来咱们会在开发和运维能力上一直精细化，并且持续推动公司业务数仓架构的进化，比方流批生产的一体化、生产服务的一体化。 实时数仓目前已根本笼罩了公司的全副业务，为 100 多个业务团队提供了反对，比方美团优选、美团买菜、金融、骑行等业务。托管了 7000 多个实时数据模型，次要为 Kafka 表和 KV 表模型。线上运行 FlinkSQL 作业 4000+，新增的实时 SQL 作业占比曾经达到 70% 以上。从数据上看，FlinkSQL 曾经能够解决美团实时数仓大部分流解决的问题。 接下来以美团业务中的两个实时数仓生产链路为例，具体分享 FlinkSQL 的理论利用。 利用场景 1 是基于 FlinkSQL + OLAP 的实时生产链路。这个业务链路的实时数据源有两个，别离是业务 DB 的变更事件和业务服务的日志事件，这些事件首先会被收集到 Kafka 中，而后 DB 事件会按表名散发到新的 Kafka 中，DB 和日志的数据也会在这一层进行格局上的对立并实现实时数仓的 ODS 层。而后业务会应用 FlinkSQL 来荡涤和关联 ODS 层的数据，生成实时数仓的主题宽表，最初写入 OLAP 查问引擎做实时剖析。对于时效性要求不高的场景，局部业务还会在 OLAP 引擎上配置分钟级别的调度来缩小雷同查问的压力。 ...

本文整顿自 XTransfer 资深 Java 开发工程师、Flink CDC Maintainer 孙家宝在 Flink CDC Meetup 的演讲。次要内容包含： MongoDB Change Stream 技术简介MongoDB CDC Connector 业务实际MongoDB CDC Connector 生产调优MongoDB CDC Connector 并行化 Snapshot 改良后续布局点击查看直播回放 & 演讲PDF 一、MongoDB Change Stream 技术简介 MongoDB 是一种面向文档的非关系型数据库，反对半结构化数据存储；也是一种分布式的数据库，提供正本集和分片集两种集群部署模式，具备高可用和程度扩大的能力，比拟适宜大规模的数据存储。另外， MongoDB 4.0 版本还提供了多文档事务的反对，对于一些比较复杂的业务场景更加敌对。 MongoDB 应用了弱结构化的存储模式，反对灵便的数据结构和丰盛的数据类型，适宜 Json 文档、标签、快照、地理位置、内容存储等业务场景。它人造的分布式架构提供了开箱即用的分片机制和主动 rebalance 能力，适宜大规模数据存储。另外， MongoDB 还提供了分布式网格文件存储的性能，即 GridFS，适宜图片、音频、视频等大文件存储。 MongoDB 提供了正本集和分片集两种集群模部署模式。 正本集：高可用的部署模式，主要节点通过拷贝次要节点的操作日志来进行数据的复制。当次要节点产生故障时，主要节点和仲裁节点会从新发动投票来选出新的次要节点，实现故障转移。另外，主要节点还能分担查问申请，加重次要节点的查问压力。 分片集：程度扩大的部署模式，将数据平均扩散在不同 Shard 上，每个 Shard 能够部署为一个正本集，Shard 中次要节点承载读写申请，主要节点会复制次要节点的操作日志，可能依据指定的分片索引和分片策略将数据切分成多个 16MB 的数据块，并将这些数据块交给不同 Shard 进行存储。Config Servers 中会记录 Shard 和数据块的对应关系。 MongoDB 的 Oplog 与 MySQL 的 Binlog 相似，记录了数据在 MongoDB 中所有的操作日志。Oplog 是一个有容量的汇合，如果超出预设的容量范畴，则会抛弃先前的信息。 ...

作者｜王立杰 & 朱翥点击进入 Flink 中文学习网 一、引言对大部分用户来说，为 Flink 算子配置适合的并行度并不是一件容易的事。对于批作业，小的并行度会导致作业运行工夫长，故障复原慢，而不必要的大并行度会导致资源节约，工作部署和数据 shuffle 开销也会变大。 为了管制批作业的执行时长，算子的并行度应该和其须要解决的数据量成正比。用户须要通过预估算子须要解决的数据量来配置并行度。但精确预估算子须要解决的数据量是一件很艰难的事件：须要解决的数据量可能每天都在变动，作业中可能会存在大量的 UDF 和简单算子导致难以判断其产出的数据量。 为了解决这个问题，咱们在 Flink 1.15 中引入了一种新的调度器：自适应批作业调度器（Adaptive Batch Scheduler）。自适应批作业调度器会在作业运行时依据每个算子须要解决的理论数据量来主动推导并行度。它会带来以下益处： 大大降低批处理作业并发度调优的繁琐水平；能够依据解决的数据量为不同的算子配置不同的并行度，这对于之前只能配置全局并行度的 SQL 作业尤其无益；能够更好的适应每日变动的数据量。二、用法使 Flink 主动推导算子的并行度，须要进行以下配置： 启用自适应批作业调度器；配置算子的并行度为 -1。2.1 启用自适应批作业调度器启用自适应批作业调度器，须要进行以下配置： 配置 jobmanager.scheduler: AdaptiveBatch；将 execution.batch-shuffle-mode 配置为 ALL-EXCHANGES-BLOCKING (默认值)。因为目前自适应批作业调度器只反对 shuffle mode 为 ALL-EXCHANGES-BLOCKING 的作业。此外，还有一些相干配置来指定主动推导的算子并行度的上上限、预期每个算子解决的数据量以及 source 算子的默认并行度，详情请参阅 Flink 文档 [1]。 2.2 配置算子的并行度为 -1自适应批作业调度器只会为用户未指定并行度的算子（即并行度为默认值 -1）推导并行度。 所以须要进行以下配置： 配置 parallelism.default: -1；对于 SQL 作业，须要配置 table.exec.resource.default-parallelism: -1；对于 DataStream/DataSet 作业，防止在作业中通过算子的 setParallelism() 办法来指定并行度；对于 DataStream/DataSet 作业，防止在作业中通过 StreamExecutionEnvironment/ExecutionEnvironment 的 setParallelism() 办法来指定并行度。三、实现细节接下来咱们将介绍自适应批作业调度器的实现细节。在此之前，咱们简要介绍一下波及到的一些术语概念： 逻辑节点（JobVertex）[2] 和逻辑拓扑（JobGraph）[3]：逻辑节点是为了更优的性能而将几个算子链接到一起造成的算子链，逻辑拓扑则是多个逻辑节点连贯组成的数据流图。执行节点（ExecutionVertex）[4] 和执行拓扑（ExecutionGraph）[5]：执行节点对应一个可部署物理工作，是逻辑节点依据并行度进行开展生成的。例如，如果一个逻辑节点的并行度为 100，就会生成 100 个对应的执行节点。执行拓扑则是所有执行节点连贯组成的物理执行图。以上概念的介绍能够参见 Flink 文档 [6]。须要留神的是，自适应批作业调度器是通过推导逻辑节点的并行度来决定该节点蕴含的算子的并行度的。 ...

摘要：本文作者彭明德，介绍了钱大妈与阿里云 Flink 实时计算团队共建实时风控规定引擎，准确辨认羊毛党以防营销估算散失。次要内容包含： 我的项目背景业务架构未规定模型难点攻坚回顾瞻望一、我的项目背景目前钱大妈基于云原生大数据组件（DataWorks、MaxCompute、Flink、Hologres）构建了离线和实时数据一体化的全渠道数据中台，为各业务线提供 BI 报表及数据接口反对。除了数仓的剖析场景以外，钱大妈面临着业务零碎中的风控需要，例如每季度的营销费用中被不少的羊毛党薅走失常用户的利益，其中羊毛党一方面可能导致用户的口碑降落，另一方面也会影响原有的流动经营估算迅速攀升从而导致资损。钱大妈与阿里云 Flink 实时计算团队共建实时风控规定引擎，准确辨认羊毛党以防营销估算散失。 图一：钱大妈实时风控流程示意图 二、业务架构钱大妈风控业务架构如图二所示总共分为四个局部：事件接入、危险感知、危险应答、危险回溯。通过 Flink 在线 ETL 加工解决的实时用户画像标签和销售事实指标，除了作为线上 BI 指标和实时大屏数据展现，也为实时规定引擎的事件接入提供重要的数据反对。 事件接入。其中包含黑白灰名单库、画像特色数据、行为埋点数据和中台交易数据。危险感知。策略调研后公布到规定引擎，并对告警后果进行离线回归和多渠道触达。危险应答。对波及到财务结算的规定提供再审核、豁免机制或人工弥补。危险回溯。策略命中后进行统计和危险分类分级，预警离线回溯并对风控事件闭件。 图二：钱大妈实时风控业务架构图 三、规定模型风控业务专员通过产品界面简略配置即可实时动静公布风控规定，同时对在线 Flink 作业的规定进行新增、更新以及删除，其中风控规定模型次要分为统计型规定和序列型规定，雷同模型反对子规定的嵌套，不同模型之间能够通过与、或关系进行组合。 图三：钱大妈Flink作业DAG形象图 以下为规定组合中须要动静配置能力的配置项： 分组字段。不同字段分组、多字段分组的状况在风控规定的利用中十分常见。有如下规定样例： 以用户 ID 分组："用户的下单次数"；以用户 ID、区域 ID 作为分组："用户同一段时间内不同区域的订单数"。聚合函数。聚合函数包含业务罕用的聚合逻辑，规定引擎依赖 Flink 内置丰盛的累加器，并在 Accumulator 接口的根底上进行了依据需要场景的自定义实现。样例规定如下： A 门店近 30 分钟独立生产用户数小于 100；B 门店新客生产金额大于 300。窗口周期。窗口周期也即每个窗口的大小，如业务方可能心愿在继续 30 分钟的秒杀流动周期内运行规定，或者心愿重点关注异样时段。 每 30 分钟工夫窗口内，单个用户发动超过 20 笔未领取订单；凌晨 1 点至 3 点，单个用户领取订单数超 50 笔。窗口类型。为了面对不同的业务需要，咱们将业务规定中常见的窗口类型集成到规定引擎外部。其中包含滑动窗口、累计窗口、甚至是无窗口（即时触发）。聚合前的过滤条件： 只对"下单事件"进行统计；过滤门店"虚构用户"。聚合后的过滤条件： 用户 A 在 5 分钟内下单次数 "超过 150 次"；用户 B 在 5 分钟内购买金额 "超过 300 元"。计算表达式。风控规定的字段口径通常是须要组合计算的，咱们在表达式计算和编译中集成了更轻便和更高性能的 Aviator 表达式引擎。规定样例如下： ...

本文整顿自 OceanBase 技术专家王赫（川粉）在 5 月 21 日 Flink CDC Meetup 的演讲。次要内容包含： OceanBase 介绍Flink CDC OceanBase Connector 实现原理Flink CDC + OceanBase 利用场景Flink CDC OceanBase Connector 将来瞻望点击查看直播回放 & 演讲PDF 一、OceanBase 介绍 OceanBase 是蚂蚁团体自研的分布式数据库。从 10 年开始立项并研发迭代，最早的用户是淘宝的收藏夹。14 年，OceanBase 研发团队从淘宝迁徙至蚂蚁团体，次要负责反对支付宝外部的去 IOE 工作，即替换支付宝所用的 Oracle 数据库。目前，蚂蚁团体数据库曾经全副迁徙到 OceanBase。2021 年 6 月 1 号，OceanBase 正式地对外开源，凋谢了 MySQL 兼容的版本。 OceanBase 数据库经验了三代架构降级，从最后利用于电商的分布式存储系统，到前面通用的分布式数据库，再到现在企业级的分布式数据库。 上图展现了 OceanBase 的架构。 最上层的 App 通过 OBProxy（负载平衡代理）拜访 OceanBase 数据库的 server 端， server 端的数据存在多个正本，正本之间的关系相似于数据库架构中的主从关系，但它是表级别的，即分区表的分区是以表级别为单位存在多个正本，而后打散存在于多个 server 中。 OceanBase 的架构具备以下几个特点： 无共享架构：每个节点均有本人残缺的 SQL 引擎、存储引擎和事务处理逻辑，节点之间齐全对等，不存在分层构造。分区级可用性：提供分区级的可用性。在 OceanBase 数据库中，分区是可靠性和扩展性的根本单元，实现了拜访路由、负载平衡以及主动故障复原。高可用 + 强一致性：因为数据存在多个正本，多个正本之间通过 Paxos 的一致性协定来提供高可靠性，并且确保日志的长久化在多数派节点胜利。 ...

本文整顿自卑健云仓基础架构负责人、Flink CDC Maintainer 龚中强在 5 月 21 日 Flink CDC Meetup 的演讲。次要内容包含： 引入 Flink CDC 的背景现今外部落地的业务场景将来外部推广及平台化建设社区单干点击查看直播回放 & 演讲PDF 一、引入 Flink CDC 的背景 公司引入 CDC 技术，次要基于以下四个角色的需要： 物流科学家：须要库存、销售订单、物流账单等数据用于做剖析。开发：须要同步其余业务零碎的根本信息。财务：心愿财务数据可能实时传送到财务零碎，而不是月结前能力看到。老板：须要数据大屏，通过大屏查看公司的业务和经营状况。 CDC 是数据捕捉变更的技术。狭义上来说，凡是可能捕捉数据变更的技术，都能被称为 CDC。但通常咱们说的 CDC 技术次要面向数据库的变更。 CDC 的实现形式次要有两种，别离是基于查问和基于日志： 基于查问：查问后插入、更新到数据库即可，毋庸数据库的非凡配置以及账号权限。它的实时性基于查问频率决定，只能通过进步查问频率来保障实时性，而这必然会对 DB 造成微小压力。此外，因为是基于查问，所以它无奈捕捉两次查问之间数据的变更记录，也就无奈保证数据的一致性。基于日志：通过实时生产数据的变更日志实现，因而实时性很高。而且不会对 DB 造成很大的影响，也可能保证数据的一致性，因为数据库会将所有数据的变动记录在变更日志中。通过对日志的生产，即可明确晓得数据的变动过程。它的毛病是实现绝对简单，因为不同数据库的变动日志实现不一样，格局、开启形式以及非凡权限都不一样，须要针对每一种数据库做相应的适配开发。 正如 Flink 的宣言 “实时即将来”，在现在的大背景下，实时性是亟待解决的重要问题。因而，咱们将支流 CDC 基于日志的技术做了比照，如上图所示： 数据源：Flink CDC 除了对传统的关系型数据库做到了很好的反对外，对文档型、NewSQL（TiDB、OceanBase） 等当下风行的数据库都可能反对；Debezium 对数据库的反对绝对没有那么宽泛，然而对支流的关系型数据库都做到了很好的撑持；Canal 和 OGG 只反对繁多的数据源。断点续传：四种技术都可能反对。同步模式：除了 Canal 只反对增量，其余技术均反对全量 + 增量的形式。而全量 + 增量的形式意味着第一次上线时全量到增量的切换过程全副能够通过 CDC 技术实现，毋庸人为地通过全量的工作加上增量的 job 去实现全量 + 增量数据的读取。活跃度：Flink CDC 领有十分沉闷的社区，材料丰盛，官网也提供了详尽的教程以及疾速上手教程；Debezium 社区也相当沉闷，但材料大多是英文的；Canal 的用户基数特地大，材料也绝对较多，但社区活跃度个别；OGG 是 Oracle 的大数据套件，须要付费，只有官网材料。开发难度：Flink CDC 依附 Flink SQL 和 Flink DataStream 两种开发模式，尤其是 Flink SQL，通过非常简单的 SQL 即可实现数据同步工作的开发，开发上手尤为简略；Debezium 须要本人解析采集到的数据变更日志进行独自解决，Canal 亦是如此。运行环境依赖：Flink CDC 是以 Flink 作为引擎，Debezium通常是将 Kafka connector 作为运行容器；而 Canal 和 OGG 都是独自运行。上游丰盛水平：Flink CDC 依附 Flink 十分沉闷的周边以及丰盛的生态，可能买通丰盛的上游，对一般的关系型数据库以及大数据存储引擎 Iceberg、ClickHouse、Hudi 等都做了很好的反对；Debezium 有 Kafka JDBC connector， 反对 MySQL 、Oracle 、SqlServer；Canal 只能间接生产数据或将其输入到 MQ 中进行上游的生产； OGG 因为是官网套件，上游丰盛水平不佳。二、现今外部落地的业务场景 ...

Flink 源码：播送流状态源码解析 Broadcast State 是 Operator State 的一种非凡类型。它的引入是为了反对这样的场景: 一个流的记录须要播送到所有上游工作，在这些用例中，它们用于在所有子工作中保护雷同的状态。而后能够在解决第二个流的数据时拜访这个播送状态，播送状态有本人的一些个性。 必须定义为一个 Map 构造。播送状态只能在播送流侧批改，非播送侧不能批改状态。Broadcast State 运行时的状态只能保留在内存中。看到这置信你必定会有上面的疑难： 播送状态为什么必须定义为 Map 构造，我用其余的状态类型不行吗？播送状态为什么只能在播送侧批改，非播送侧为什么不能批改呢？播送状态为什么只能保留在内存中，难道不能用 Rockdb 状态后端吗？上面就带着这三个疑难通过浏览相干源码，答复下面的问题。 broadcast 源码/** * Sets the partitioning of the {@link DataStream} so that the output elements are broadcasted * to every parallel instance of the next operation. In addition, it implicitly as many {@link * org.apache.flink.api.common.state.BroadcastState broadcast states} as the specified * descriptors which can be used to store the element of the stream. * * @param broadcastStateDescriptors the descriptors of the broadcast states to create. * @return A {@link BroadcastStream} which can be used in the {@link #connect(BroadcastStream)} * to create a {@link BroadcastConnectedStream} for further processing of the elements. */@PublicEvolvingpublic BroadcastStream<T> broadcast( final MapStateDescriptor<?, ?>... broadcastStateDescriptors) { Preconditions.checkNotNull(broadcastStateDescriptors); final DataStream<T> broadcastStream = setConnectionType(new BroadcastPartitioner<>()); return new BroadcastStream<>(environment, broadcastStream, broadcastStateDescriptors);}能够发现 broadcast 办法须要的参数是 MapStateDescriptor<?, ?> 也就是一个 Map 构造的状态描述符，咱们在应用的时候就必须定义为 MapStateDescriptor，否则会间接报错，其实次要是因为播送状态的作用是和非播送流进行关联，你能够设想成双流 join 的场景，那么 join 的时候就必须要有一个主键，也就是雷同的 key 能力 join 上，所以 Map（key-value） 构造是最适宜这种场景的，key 能够存储要关联字段，value 能够是任意类型的播送数据，在关联的时候只须要获取到播送状态，而后 state.get(key) 就能够很容易拿到播送数据。 ...

IDEA 中应用 Big Data Tools 连贯大数据组件简介Big Data Tools 插件可用于 Intellij Idea 2019.2 及当前的版本。它提供了应用 Zeppelin，AWS S3，Spark，Google Cloud Storage，Minio，Linode，数字凋谢空间，Microsoft Azure 和 Hadoop 分布式文件系统（HDFS）来监督和解决数据的特定性能。 上面来看一下 Big Data Tools 的装置和应用，次要会配置 Flink,Kafka 和 HDFS。 装置 Big Data Tools 插件 点击装置实现之后，须要重启一下 IDEA，插件能力失效，下面我曾经装置过了。 Flink 配置（不举荐）flink 须要下载行将公布的 IDEA 2022.2-EAP 版本才有，因为之前是不反对 flink 的。 先点击 IDEA 右侧的 Big Data Tools，而后点击加号就能够增加 Flink 组件了。 输出 Flink WEB UI 地址，点击 OK 就能够了。 这样就能够间接在 IDEA 外面查看 Flink Dashboard，跟在 Web UI 上的性能齐全一样，点击箭头所指的中央能够间接跳转到 Flink UI,尽管能够间接在 IDEA 外面查看 Dashboard，然而个人感觉还是在 Flink Web UI 上查看更加不便，可能是看习惯了。不是太举荐这个性能。 ...

Flink 通过 State Processor API 实现状态的读取和写入大家好，我是 JasonLee。 在 1.9 版本之前，Flink 运行时的状态对于用户来说是一个黑盒，咱们是无法访问状态数据的，从 Flink-1.9 版本开始，官网提供了 State Processor API 这让用户读取和更新状态成为了可能，咱们能够通过 State Processor API 很不便的查看工作的状态，还能够在工作第一次启动的时候基于历史数据做状态冷启动。从此状态对于用户来说是通明的。上面就来看一下 State Processor API 的应用。 增加依赖<dependency> <groupId>org.apache.flink</groupId> <artifactId>flink-state-processor-api_2.11</artifactId> <version>1.14.4</version></dependency>Mapping Application State to DataSetsState Processor API 将流应用程序的状态映射到一个或多个能够独自解决的数据集。为了可能应用 API，咱们先来了解一下工作的状态和 DataSets 之间是如何映射的。 让咱们先看看有状态的 Flink 作业是什么样子的。Flink 作业由多个算子组成，通常有一个或多个 source 数据源，一些用于理论解决数据的算子，以及一个或多个 sink 算子。每个算子并行的在一个或多个 task 上运行，并且能够解决不同类型的状态。一个算子能够有 0、1 个或多个 operator states，这些状态被组织成 list，作用于所有的 tasks 上。如果 operator 利用于 keyed states，它还能够有 0 个、1 个或多个 keyed state，这些状态的作用域为从每个 record 中提取的 key。 下图显示了应用程序 MyApp，它由 Src、Proc 和 Snk 三个算子组成。Src 有一个 operator state 状态(os1)， Proc 有一个 operator 状态(os2) 和两个 keyed state 状态(ks1, ks2)，而 Snk 是无状态的。 ...

Flink on yarn 近程调试源码大家好，我是 JasonLee。 前几天有小伙伴问我，我写的 Flink 代码是提交到 yarn 下来运行的，那我怎么能近程调试代码呢？在本地调试代码大家都十分相熟了，间接在 IDEA 外面打个断点，而后以 debug 模式启动就能够一步步调试代码了。其实 Flink on yarn 近程调试也不简单，只须要简略的配置即可。 集群配置(flink-conf.yaml)在 flink-conf.yaml 配置文件中增加上面三行配置 # 近程调试env.java.opts.client: -agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=5666env.java.opts.jobmanager: -agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=5005env.java.opts.taskmanager: -agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=5006dt_socket：应用的通信形式 server：是被动连贯调试器还是作为服务器期待调试器连贯 suspend：是否在启动 JVM 时就暂停，并期待调试器连贯（倡议设置成 y） address：地址和端口，地址能够省略，两者用冒号分隔 这里你能够抉择只设置 client，jobmanager，taskmanager 其中一个，也能够同时设置 client，jobmanager，taskmanager，因为 JM 和 TM 可能会在同一台机器下面可能会发生冲突，所以就把 JM 和 TM 离开独自设置，当然调试的时候也能够先从 client -> jobmanager -> taskmanager 整个启动流程。 Client 端的入口类是：org.apache.flink.client.cli.CliFrontend JM 的入口是：org.apache.flink.runtime.entrypoint.ClusterEntrypoint TM 的入口是：org.apache.flink.runtime.taskexecutor.TaskManagerRunner IDEA 配置 依照下面的配置增加一个 remote JVM debug，留神端口须要和 flink-conf.yaml 配置文件外面的保持一致。 提交 Flink 工作flink run -d -m yarn-cluster -Dyarn.application.name=FlinkStreamingNewDemoHome -Dyarn.application.queue=flink -Dmetrics.reporter.promgateway.groupingKey="jobname=FlinkStreamingNewDemoHome" -Dmetrics.reporter.promgateway.jobName=FlinkStreamingNewDemoHome -c flink.stream.FlinkStreamingNewDemo -Denv.java.opts="-Dflink_job_name=FlinkStreamingNewDemoHome" /home/jason/bigdata/jar/flink-1.14.x-1.0-SNAPSHOT.jar留神要先把工作提交到 yarn 上。而后在 idea 外面近程调试。比方我想要调试客户端的解析流程，只须要在 CliFrontend 构造方法外面设置了一个断点就行了。 ...

给 Print SQL Connector 增加随机取样Flink 提供了 Print SQL Connector 能够让咱们十分不便的把数据打印到规范输入.有助于咱们测试 SQL 工作,测验数据的正确性. 然而在生产环境中,上游的数据量是十分大的,如果间接把数据输入的话,可能会把规范输入文件打满,造成页面卡死的状况,反而不利于咱们观测数据,所以咱们能够对 Print SQL Connector 进行简略的革新,加一个随机取样的参数控制数据输入. 间接把 Print SQL Connector 相干的代码复制进去. PrintRateTableSinkFactory/* * Licensed to the Apache Software Foundation (ASF) under one * or more contributor license agreements. See the NOTICE file * distributed with this work for additional information * regarding copyright ownership. The ASF licenses this file * to you under the Apache License, Version 2.0 (the * "License"); you may not use this file except in compliance * with the License. You may obtain a copy of the License at * * http://www.apache.org/licenses/LICENSE-2.0 * * Unless required by applicable law or agreed to in writing, software * distributed under the License is distributed on an "AS IS" BASIS, * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. * See the License for the specific language governing permissions and * limitations under the License. */package flink.stream.connector.print;import org.apache.flink.annotation.Internal;import org.apache.flink.api.common.functions.util.PrintSinkOutputWriter;import org.apache.flink.configuration.ConfigOption;import org.apache.flink.configuration.Configuration;import org.apache.flink.configuration.ReadableConfig;import org.apache.flink.streaming.api.functions.sink.PrintSinkFunction;import org.apache.flink.streaming.api.functions.sink.RichSinkFunction;import org.apache.flink.streaming.api.operators.StreamingRuntimeContext;import org.apache.flink.table.connector.ChangelogMode;import org.apache.flink.table.connector.sink.DynamicTableSink;import org.apache.flink.table.connector.sink.DynamicTableSink.DataStructureConverter;import org.apache.flink.table.connector.sink.SinkFunctionProvider;import org.apache.flink.table.connector.sink.abilities.SupportsPartitioning;import org.apache.flink.table.data.RowData;import org.apache.flink.table.factories.DynamicTableSinkFactory;import org.apache.flink.table.factories.FactoryUtil;import org.apache.flink.table.types.DataType;import javax.annotation.Nullable;import java.util.*;import java.util.concurrent.ThreadLocalRandom;import static flink.stream.connector.print.PrintConnectorOptions.PRINT_RATE;import static org.apache.flink.connector.print.table.PrintConnectorOptions.PRINT_IDENTIFIER;import static org.apache.flink.connector.print.table.PrintConnectorOptions.STANDARD_ERROR;/** * Print table sink factory writing every row to the standard output or standard error stream. It is * designed for: - easy test for streaming job. - very useful in production debugging. * * <p>Four possible format options: {@code PRINT_IDENTIFIER}:taskId> output <- {@code * PRINT_IDENTIFIER} provided, parallelism > 1 {@code PRINT_IDENTIFIER}> output <- {@code * PRINT_IDENTIFIER} provided, parallelism == 1 taskId> output <- no {@code PRINT_IDENTIFIER} * provided, parallelism > 1 output <- no {@code PRINT_IDENTIFIER} provided, parallelism == 1 * * <p>output string format is "$RowKind[f0, f1, f2, ...]", example is: "+I[1, 1]". */@Internalpublic class PrintRateTableSinkFactory implements DynamicTableSinkFactory { // 简略批改 public static final String IDENTIFIER = "print-rate"; @Override public String factoryIdentifier() { return IDENTIFIER; } @Override public Set<ConfigOption<?>> requiredOptions() { return new HashSet<>(); } @Override public Set<ConfigOption<?>> optionalOptions() { Set<ConfigOption<?>> options = new HashSet<>(); options.add(PRINT_IDENTIFIER); options.add(STANDARD_ERROR); options.add(FactoryUtil.SINK_PARALLELISM); // 增加到 options options.add(PRINT_RATE); return options; } @Override public DynamicTableSink createDynamicTableSink(Context context) { FactoryUtil.TableFactoryHelper helper = FactoryUtil.createTableFactoryHelper(this, context); helper.validate(); ReadableConfig options = helper.getOptions(); return new PrintSink( context.getCatalogTable().getResolvedSchema().toPhysicalRowDataType(), context.getCatalogTable().getPartitionKeys(), options.get(PRINT_IDENTIFIER), options.get(STANDARD_ERROR), options.getOptional(FactoryUtil.SINK_PARALLELISM).orElse(null), options.get(PRINT_RATE)); } private static class PrintSink implements DynamicTableSink, SupportsPartitioning { private final DataType type; private String printIdentifier; private final boolean stdErr; private final @Nullable Integer parallelism; private final List<String> partitionKeys; private Map<String, String> staticPartitions = new LinkedHashMap<>(); private @Nullable Float printRate; private PrintSink( DataType type, List<String> partitionKeys, String printIdentifier, boolean stdErr, Integer parallelism, Float printRate) { this.type = type; this.partitionKeys = partitionKeys; this.printIdentifier = printIdentifier; this.stdErr = stdErr; this.parallelism = parallelism; this.printRate = printRate; } @Override public ChangelogMode getChangelogMode(ChangelogMode requestedMode) { return requestedMode; } @Override public SinkRuntimeProvider getSinkRuntimeProvider(Context context) { DataStructureConverter converter = context.createDataStructureConverter(type); staticPartitions.forEach( (key, value) -> { printIdentifier = null != printIdentifier ? printIdentifier + ":" : ""; printIdentifier += key + "=" + value; }); return SinkFunctionProvider.of( new RowDataPrintFunction(converter, printIdentifier, stdErr, printRate), parallelism); } @Override public DynamicTableSink copy() { return new PrintSink(type, partitionKeys, printIdentifier, stdErr, parallelism, printRate); } @Override public String asSummaryString() { return "Print to " + (stdErr ? "System.err" : "System.out"); } @Override public void applyStaticPartition(Map<String, String> partition) { // make it a LinkedHashMap to maintain partition column order staticPartitions = new LinkedHashMap<>(); for (String partitionCol : partitionKeys) { if (partition.containsKey(partitionCol)) { staticPartitions.put(partitionCol, partition.get(partitionCol)); } } } } /** * Implementation of the SinkFunction converting {@link RowData} to string and passing to {@link * PrintSinkFunction}. */ private static class RowDataPrintFunction extends RichSinkFunction<RowData> { private static final long serialVersionUID = 1L; private final DataStructureConverter converter; private final PrintSinkOutputWriter<String> writer; private final Float printRate; private RowDataPrintFunction( DataStructureConverter converter, String printIdentifier, boolean stdErr, Float printRate) { this.converter = converter; this.writer = new PrintSinkOutputWriter<>(printIdentifier, stdErr); this.printRate = printRate; } @Override public void open(Configuration parameters) throws Exception { super.open(parameters); StreamingRuntimeContext context = (StreamingRuntimeContext) getRuntimeContext(); writer.open(context.getIndexOfThisSubtask(), context.getNumberOfParallelSubtasks()); } @Override public void invoke(RowData value, Context context) { if (ThreadLocalRandom.current().nextFloat() < this.printRate) { Object data = converter.toExternal(value); assert data != null; writer.write(data.toString()); } } }}PrintConnectorOptions/* * Licensed to the Apache Software Foundation (ASF) under one * or more contributor license agreements. See the NOTICE file * distributed with this work for additional information * regarding copyright ownership. The ASF licenses this file * to you under the Apache License, Version 2.0 (the * "License"); you may not use this file except in compliance * with the License. You may obtain a copy of the License at * * http://www.apache.org/licenses/LICENSE-2.0 * * Unless required by applicable law or agreed to in writing, software * distributed under the License is distributed on an "AS IS" BASIS, * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. * See the License for the specific language governing permissions and * limitations under the License. */package flink.stream.connector.print;import org.apache.flink.annotation.PublicEvolving;import org.apache.flink.configuration.ConfigOption;import static org.apache.flink.configuration.ConfigOptions.key;/** Options for the Print sink connector. */@PublicEvolvingpublic class PrintConnectorOptions { public static final ConfigOption<String> PRINT_IDENTIFIER = key("print-identifier") .stringType() .noDefaultValue() .withDescription( "Message that identify print and is prefixed to the output of the value."); public static final ConfigOption<Boolean> STANDARD_ERROR = key("standard-error") .booleanType() .defaultValue(false) .withDescription( "True, if the format should print to standard error instead of standard out."); public static final ConfigOption<Float> PRINT_RATE = key("print-rate") .floatType() .defaultValue(0.0001F) .withDescription( "Controls the printing rate of data"); private PrintConnectorOptions() {}}首先在 PrintConnectorOptions 配置外面增加 PRINT_RATE 属性,用来管制随机取样,默认值是 0.0001. ...

作者：Jingsong Lee jingsonglee0@gmail.com点击进入 Flink 中文学习网 一、数仓中的计算在计算机领域，数据仓库（DW 或 DWH），是一个用于报告和数据分析的零碎，被认为是商业智能的一个外围组成部分。它将以后和历史数据存储在一个中央，为整个企业的工作人员创立剖析报告。[1] 典型的基于提取、转换、加载（ETL）的数据仓库应用 ODS 层、DWD 层和 DWS 层来包容其要害性能。数据分析师能够灵便的查问 (Query) 数仓中的每一层，获取有价值的商业信息。 数仓中有三个要害指标 [2]： 数据的新鲜度：数据从产生开始，到在仓库中通过一系列解决后可供用户查问所通过的工夫长度。通常 ETL 就是用来筹备数据的一系列过程，ETL 更多是通过调度运行一系列流计算或者批计算的作业来实现。数据的查问延时：数据筹备好后，用户通过 Query 查问表中的数据，从用户收回查问到收到查问后果的工夫长度为查问延时。查问延时间接决定了终端用户的体感。老本：实现一定量的数据分析（包含 ETL 和查问等各类计算）须要的资源量。老本也是数仓中的一个要害指标。这三个指标的关系是什么呢？ 企业须要在管制老本的状况下，能达到更好的查问延时和新鲜度。不同的数据可能有不同的老本要求。新鲜度和查问延时在某些状况也是此消彼长的关系，比方应用更长时间来筹备数据、荡涤和预处理数据，查问会更快。所以这三者形成了数仓中的一个三角 Tradeoff [2]： <p style="text-align:center">(注：三角中，离顶点更近代表更好，离顶点更远代表更差)</p> 对于这个三角 Tradeoff，业界目前的支流架构有着怎么样的取舍呢？ 二、业界支流架构典型的离线数仓： 离线数仓应用 Batch ETL 基于分区粒度来覆写 (INSERT OVERWRITE)，在解决超大数据的场景的同时，有着很好的老本管制。 然而它有两个比较严重的问题： 新鲜度差：数据延时个别是 T + 1，即业务上当天产生的数据须要第二天能力查问到。不善于解决更新流 (Changelog)，离线数仓外面存储的都是 Append 数据，如果须要接管相似数据库变更日志的更新流，须要重复的合并全量数据和增量数据，老本激增。 为了解决上述问题，实时数仓逐步衰亡，一个典型的实时数仓实现是应用 Flink + Kafka 的计划构建中间层，最终写到在线数据库或剖析零碎中，达到秒级的全链路延时，有着十分好的数据新鲜度。 然而，它也逐步暴露出一些问题。 问题一，中间层不可查 存在 Kafka 中的数据查问受限，无奈灵便的进行 OLAP 查问，通常也没有保留长期历史数据。这与宽泛应用的数仓有很大不同，在一个成熟的 Warehouse 体系中，数仓中的每一个数据集都应该是可供查问的 Table 形象，而 Kafka 无奈满足用户对于 Table 形象的所有需要，比如说： ...

摘要：本文整顿自阿里巴巴高级技术专家林东、阿里巴巴技术专家高赟（云骞）在 Flink Forward Asia 2021 核心技术专场的演讲。次要内容包含： 面向实时机器学习的 API流批一体的迭代引擎Flink ML 生态建设点击查看直播回放 & 演讲PDF 一、面向实时机器学习的 API Flink ML API 指的是提供给用户应用算法的接口。通过把所有算法打包为对立的 API 提供给用户，让所有使用者的体验保持一致，也能升高学习和了解算法的老本，此外算法之间也能够更好地交互和兼容。 举个例子，在 Flink ML API 中提供一些根底的性能类，通过应用这些性能类能够把不同算子连贯组合成一个高级的算子，能够大大提高了算法的开发效率。同时，通过应用对立的 Table API，让所有的数据都以 Table 格局进行传输，能够使得不同公司开发的算法可能相互兼容，升高不同公司反复开发的算子的老本，晋升算法单干的效率。 之前版本的 Flink ML API 还是存在不少痛点。 首先是表达能力方面。之前的 API 的输出只反对单个 Table 的模式，无奈表白一些常见的算法逻辑。比方有些训练算法的输出表白是一张图，把数据通过不同的 Table 传进来，这种状况下单个 Table 输出的接口就不实用了。再比方有些数据预处理的逻辑须要将多个输出失去的数据进行交融，用单个 Table 输出的 API 也不适宜。因而咱们打算把算法接口扩大为反对多输出多输入。 其次是实时训练方面。之前的 API 无奈原生反对实时机器学习场景。在实时机器学习中，咱们心愿训练算法能够实时产生模型数据，并将模型数据以流的形式实时传输到多个前端服务器中。然而现有的接口只有一次性的训练和一次性的推理 API，无奈表白这种逻辑。 最初是易用性方面。之前采纳 toJson() 和 fromJson() 来导出和加载模型数据，并且容许用户贮存这些数据。然而有些模型的数据量高达几个 G，在这种状况下将模型数据以 string 的形式进行贮存，效率会非常低，甚至可能无奈实现。当然，存在一些 hacky 办法，能够把模型数据贮存到一个近程终端，再把相干的 url 通过 toJson() 办法传导进去。然而这种状况下会存在易用性的问题，算法使用者须要本人去解析 URL，并从近程获取这些数据。 受限于以上几个方面的因素，咱们决定对 Flink ML API 进行扩大。 ...

作者 | 梅源（Yuan Mei）& Roman Khachatryan 流解决零碎最重要的个性是端到端的提早，端到端提早是指开始解决输出数据到输入该数据产生的后果所需的工夫。Flink，作为流式计算的标杆，其端到端提早包含容错的快慢次要取决于检查点机制（Checkpointing），所以如何将 Checkpoint 做得高效稳固是 Flink 流计算的首要任务。咱们在 “Flink 新一代流计算和容错——阶段总结和瞻望”[1] 一文中介绍了 Flink 从社区 1.12 版本开始所做的晋升 Checkpointing 机制的致力，本文将着重介绍其中刚刚在 Flink 1.15 版本公布的 Generic Log-Based Incremental Checkpointing 这个性能。 一、概述Generic Log-Based Incremental Checkpointing 的设计初衷是咱们将全量的状态快照和增量的检查点机制分隔开，通过继续上传增量 Changelog 的办法，来确保每次 Checkpointing 能够稳固疾速的实现，从而减小 Checkpointing 之间的距离，晋升 Flink零碎端到端的提早。拓展开来说，次要有如下三点晋升： 更短的端到端提早：尤其是对于 Transactional Sink。Transactional Sink 在 Checkpoint 实现的时候能力实现两阶段提交，因而减小 Checkpointing 的距离意味着能够更频繁的提交，达到更短的端到端的提早。更稳固的 Checkpoint 实现工夫：目前 Checkpoint 实现工夫很大水平上取决于在 Checkpointing 时须要长久化的（增量）状态的大小。在新的设计中，咱们通过继续上传增量，以达到缩小 Checkpoint Flush 时所须要长久化的数据，来保障 Checkpoint 实现的稳定性。容错复原须要回滚的数据量更少：Checkpointing 之间的距离越短，每次容错复原后须要重新处理的数据就越少。那是怎么做到的呢？咱们晓得影响 Flink Checkpointing 工夫的次要因素有以下几点： Checkpoint Barrier 流动和对齐的速度；将状态快照长久化到非易失性高可用存储（例如 S3）上所须要的工夫。对Flink Checkpoint 机制不太理解的读者能够参考 1。 ...

点击查看 Flink CDC Meetup 直播回放 & 演讲PDF 5 月 21 日，Flink CDC Meetup 圆满结束！ 来自阿里巴巴、XTransfer、顺丰、OceanBase、大健云仓的 5 位老师分享 Flink CDC 在各场景中的最佳实际、生产教训、技术原理等。 观看了本场 Meetup 的同学能够说是播种满满，不仅 get 了超多实用干货，如 Flink CDC 实现海量数据的实时同步和转换的技术原理，以及各业务场景下的实际优化。而且积攒已久的疑难也在当场取得了解答！（讲师们真的极有急躁） 议题回顾 Flink CDC Meetup · Online，5.21 开讲！ 流动亮点 基于 Flink CDC 实现海量数据的实时同步和转换Flink CDC MongoDB Connector 的实现原理和应用实际Flink CDC + Hudi 海量数据入湖在顺丰的实际Flink CDC + OceanBase 全增量一体化数据集成计划Flink CDC 在大健云仓的实际点击查看 Flink CDC Meetup 直播回放 & 演讲PDF 更多 Flink 相干技术问题，可扫码退出社区钉钉交换群第一工夫获取最新技术文章和社区动静，请关注公众号～ 流动举荐 阿里云基于 Apache Flink 构建的企业级产品-实时计算Flink版现开启流动：99 元试用 实时计算Flink版（包年包月、10CU）即有机会取得 Flink 独家定制卫衣；另包 3 个月及以上还有 85 折优惠！理解流动详情：https://www.aliyun.com/produc... ...

摘要：本文整顿自阿里巴巴高级开发工程师黄兴勃 (断尘) 在 Flink Forward Aisa 2021 核心技术专场的演讲。次要内容包含： PyFlink 最新性能PyFlink Runtime基于 FFI 的 PEMJAPyFlink Runtime 2.0Future Work点击查看直播回放 & 演讲PDF 原 Flink Forward Asia 2021 演讲中的 JCP 我的项目已改名为 PEMJA，并且于 2022 年 1 月 14 日正式开源，开源地址为： https://github.com/alibaba/pemja Ps： JCP 已在本文替换为 PEMJA。 一、PyFlink 新性能 PyFlink 1.14 新增了很多性能，次要分为性能、易用性和性能三个方面。 性能方面，新增了 State TTL config。在 1.14 以前曾经实现了 Python Datastream API 以及一些操作 State 上的性能，然而并没有提供 State TTL config 的配置，这也意味着用户写 Python Datastream API 的自定义函数时无奈主动把State的值清掉，而是须要手动的操作，对用户不够敌对。 易用性方面，次要新增了以下几项性能： 在依赖治理局部反对了 tar.gz 格局。Profile 性能。用户写 PyFlink 会用到一些 Python 的自定义函数，但并不分明这部分函数的性能瓶颈在哪里。而有了 profile 性能之后，Python 函数呈现性能瓶颈时，便能够通过 profile 剖析它的瓶颈具体是由起因什么引起，从而能够针对这部分进行一些优化。Print 性能。在 1.14 以前，打印自定义的 log 信息必须应用 Python 自定义的 logging 模块。但对于 Python 用户来说，print 是他们比拟习惯应用的一种输入日志信息的形式。所以在 1.14 增加上了这部分性能。Local Debug 模式。在 1.14 以前，用户如果应用 Python 自定义的函数在本地开发 PyFlink 作业，必须应用 remote debug 形式调试自定义逻辑，但它应用起来绝对比拟繁琐，而且应用门槛较高。在 1.14 扭转了这种模式，如果在本地编写一个 PyFlink 作业应用了 Python 自定义函数，能够主动切到 local debug 模式，能够在 ide 外面间接 debug 自定义 Python 函数。性能方面次要新增了以下性能： ...

摘要：本文整顿自小红书数据流团队资深研发工程师何军在 Flink Forward Asia 2021 平台建设专场的演讲，介绍了小红书基于 K8s 治理 Flink 工作的建设过程，以及往 Native Flink on K8s 计划迁徙过程的一些实践经验。次要内容包含： 多云部署架构业务场景Helm 集群管理模式Native Flink on Kubernetes流批一体作业管控平台将来瞻望点击查看直播回放 & 演讲PDF 一、多云部署架构 上图是以后 Flink 集群多云部署模式图。业务数据扩散在各个云厂商之上，为了适配业务数据处理，Flink 集群天然也进行了多云部署。这些云存储产品一方面用于外部的离线数据存储，另外一方面会用于 Flink 做 checkpoint 存储应用。 在这些云基础设施之上，咱们搭建了 Flink 引擎反对 SQL 及 JAR 工作的运行，得益于之前做的一项推动工作 SQL 化的工作，以后外部 SQL 工作和 JAR 工作比例曾经达到了 9:1。 在此之上是流批一体作业管控平台，它次要有以下几个性能：作业开发运维、工作监控报警、工作版本治理、数据血统剖析、元数据管理、资源管理等。 平台数据输出次要有以下三个局部，第一局部是业务数据，存在于业务外部的 DB 零碎里比方 MySQL 或者 MongoDB，还有一部分是前后端打点数据，前端打点次要是用户在小红书 APP 端的行为日志，后端打点次要是 APP 外部应用程序性能指标相干的数据。这些数据通过 Flink 集群解决之后，会输入到三个次要业务场景中，首先是音讯总线，比方 Kafka 集群以及 RocketMQ 集群，其次会输入到 olap 引擎中，比方 StarRocks 或 Clickhouse，最初会输入到在线零碎，比方 Redkv 或者 ES 供一些在线查问应用。 ...

当下数据规模正在以惊人的速度增长，越来越多的利用场景也对数据处理的时效性有了更高的要求。随着近几年实时计算技术的迅猛发展，涌现了实时 OLAP、实时数据湖、实时数仓等架构，较好地解决了湖仓实时化问题。然而实时化须要的是端到端的解决方案，除了湖仓实时化之外，咱们还急需数据集成的实时化。 实时数据集成是指将各个数据孤岛中的数据实时地同步、集中到数据仓库中，便于后续进行对立的实时剖析。实时数据集成是数据技术栈实时化的重要组成部分，也是目前业界的支流发展趋势。与离线数据集成不同，实时数据集成须要面对随时都可能发生变化的数据与构造，除了须要保障低提早地同步到指标存储中，还须要保障在各种场景下的数据一致性、正确性等问题。 Flink CDC 是实时数据集成框架的开源代表，具备全增量一体化、无锁读取、并发读取、分布式架构等技术劣势，在开源社区中十分受欢迎。除了具备实时入湖入仓能力，Flink CDC 还反对弱小的数据加工能力，能够通过 SQL 对数据库数据做实时关联、聚合、打宽等。 Flink CDC Meetup · Online 5月21日 | 线上 为了促成 Flink CDC 技术的交换和倒退，咱们将于 5 月 21 日在线举办 Flink CDC Meetup。本次 Meetup 由阿里巴巴技术专家，Apache Flink PMC Member & Committer 伍翀 (云邪) 作为出品人，邀请了来自阿里巴巴、XTransfer、顺丰、OceanBase、大健云仓的大咖分享 Flink CDC 在各场景中的最佳实际、生产教训、技术原理等。 【流动亮点】 • 超多实用干货，如 Flink CDC 实现海量数据的实时同步和转换的技术原理，以及各业务场景下的实际优化。• 每位讲师均留有 Q&A 环节，通过社区钉群、微信群、视频号直播提出问题，均有机会失去讲师线上回答～• 通过 ApacheFlink 视频号观看直播，将有机会取得 Flink CDC 定制 T恤！ 【流动议程】 嘉宾及议题介绍伍翀 阿里巴巴技术专家，Apache Flink PMC Member & Committer 出品人简介： ...

作者 | Joe Moser & 高赟翻译 | 高赟Apache Flink，作为 Apache 社区最沉闷的我的项目之一[1]，始终秉承踊跃凋谢的态度一直进行技术深耕。在此咱们很荣幸的公布 Flink 1.15 版本，并和大家分享这个版本令人振奋的一些性能和改良！ Apache Flink 外围概念之一是流 (无界数据) 批 (有界数据) 一体。流批一体极大的升高了流批交融作业的开发复杂度。在过来的几个版本中，Flink 流批一体逐步成熟，Flink 1.15 版本中流批一体更加欠缺，前面咱们也将持续推动这一方向的停顿。目前大数据处理的一个趋势是越来越多的业务和场景采纳低代码的形式进行数据分析，而 Flink SQL则是这种低代码形式数据分析的典型代表。越来越多的用户开始采纳 Flink SQL 来实现他们的业务，这也是 Flink 用户和生态快速增长的重要起因之一。Apache Flink 作为数据处理生态中的重要一环，能够与许多其余技术联合在一起反对各类用户场景。在当下云原生的背景下。咱们也尽可能将 Flink 与这些零碎以及各类云基础设施进行无缝集成。 在 1.15 版本中，Apache Flink 社区在上述这些方面都获得了重大进展： 1.15 版本的一大看点是改良了运维 Apache Flink 的体验：包含明确 Checkpoint 和 Savepoint 在不同作业之间的所属权，简化 Checkpoint 和 Savepoint 生命周期治理；更加无缝反对残缺的主动伸缩；通过 Watermark 对齐来打消多个数据源速率不同带来的问题等1.15 版本中，Flink 进一步欠缺流批一体的体验：持续欠缺局部作业实现后的 Checkpoint 操作；反对批模式下的 Window table-valued 函数，并且使其在流批混合的场景下更加易用。Flink SQL 的进阶：包含可能在不失落状态的状况下降级 SQL 作业；增加了对 JSON 相干函数的反对来简化数据的输出与输入操作。Flink 作为整个数据处理生态中的一环，1.15 版本进一步晋升了与云服务的交互操作性，并且增加了更多的 Sink 连接器与数据格式。最初，咱们在运行时中去除了对 Scala 的依赖[2]。轻松运维 Apache Flink长期来看，即便是由最好的工程团队来进行构建和调优，Flink 作业依然依赖运维操作。 Flink 反对多种不同的部署模式、API、调优配置与用例，这意味着运维工作至关重要并且可能非常沉重。 ...

作者：Jimmy 随着营销 3.0 时代的到来，企业愈发须要依靠弱小 CDP 能力解决其重大的数据孤岛问题，帮忙企业加温线索、促活客户。但什么是 CDP、好的 CDP 应该具备哪些要害特色？本文在答复此问题的同时，具体讲述了爱番番租户级实时 CDP 建设实际，既有先进架构指标下的组件抉择，也有平台架构、外围模块要害实现的介绍。一、CDP 是什么1.1 CDP 由来CDP (Customer Data Platform) 是近些年时髦的一个概念。随着时代倒退、大环境变动，企业在自有媒体增多的同时，客户治理、营销变难，数据孤岛问题也愈发重大，为了更好的营销客户，CDP 诞生了。纵向来看，CDP 呈现之前次要经验了两个阶段： CRM 时代，企业通过电话、短信、email 与现有客户和潜在客户的互动，以及执行数据分析，从而帮忙推动保留和销售；DMP 阶段，企业通过治理各大互联网平台进行广告投放和执行媒体宣传流动。 CRM、DMP、CDP 三个平台核心作用不同，但纵向来比照，更容易了解 CDP。三者之间在数据属性、数据存储、数据用处等方面都较大差别。 有几个要害区别如下： CRM vs CDP 客户治理：CRM 侧重于销售跟单；CDP 更加侧重于营销。触点：CRM 的客户次要是电话、QQ、邮箱等；CDP 还蕴含租户的自有媒体关联的用户账号 (例如，企业本人的网站、app、公众号、小程序)。DMP vs CDP 数据类型：DMP 是匿名数据为主；CDP 以实名数据为主。数据存储：DMP 数据只是短期存储；CDP 数据长期存储。1.2 CDP 定义2013 年 MarTech 分析师 David Raab 首次提出 CDP 这个概念，起初其发动的 CDP Institute 给出权威定义：packaged software that creates a persistent, unified customer database that is accessible to other systems。 ...

2022 年 ApacheCon Asia 演讲征集流动正式启动！ ApacheCon 组委会以及 Apache 软件基金会很快乐地发表，ApacheCon Asia 大会将于 2022 年 7 月 29 日至 31 日在线举办。大会将再次展现来自基金会的几十个我的项目相干的内容，以及对于社区、Apache 如何运作、围绕 Apache 软件的商业模式、开源的法律问题以及其余许多主题的内容。 本次为第二次针对亚太地区时区举办的 ApacheCon 在线会议，以服务于这个新兴地区快速增长的 Apache 用户和贡献者。演讲稿的征集曾经开始，截止到 5 月 31 日，世界各地的演讲者都能够加入。 无关会议的具体内容请拜访 https://www.apachecon.com/aca... Streaming Track (数据流专题)流式数据处理是当今大数据畛域的趋势，很多企业渴望更及时地洞察本人的数据，而已经的 “批处理” 思维正迅速被流式解决所取代。越来越多的公司，无论大小，都在从新思考技术架构时把实时性作为第一考量，并开始用弱小的开源引擎如 Apache Flink、Apache Spark、Apache Kafka、 Apache Pulsar、Apache Storm 等构建本人的实时计算平台。 在该主题中，您将理解到一线大厂把这些 Apache 我的项目利用到其生产环境中的理论教训，以及这些 Apache 我的项目生态的最新倒退和流计算技术将来的倒退方向。 本次 Streaming Track 由 Apache Member、Apache Flink PMC 李钰负责 Track Chair，目前演讲征集曾经开始，欢送大家投递议题！ 议题投递截止5月31日，投递链接： https://apachecon.com/acasia2... 咱们期待着看到您对世界上最受欢迎开源软件流动的奉献!

摘要：本文整顿自蔚来汽车大数据部门数据开发、OLAP 平台 tech lead 吴江在 Flink Forward Asia 2021 行业实际专场的演讲。次要内容包含： 实时计算在蔚来的倒退历程实时计算平台实时看板CDP实时数仓其余利用场景点击查看直播回放 & 演讲PDF 一、 实时计算在蔚来的倒退历程 18 年 5 月份左右，咱们开始接触实时计算的概念，最后是用 Spark Streaming 做一些简略的流式计算数据的解决；19 年 9 月份咱们引入了 Flink，通过命令行的形式进行提交，包含治理整个作业的生命周期；到了 21 年 1 月份，咱们上线了实时计算平台 1.0，目前正在进行 2.0 版本的开发。二、实时计算平台在实时计算平台 1.0，咱们是通过将代码进行编译，而后上传 jar 包到一个服务器上，以命令行的形式进行提交。这个过程中存在很多问题： 首先，所有流程都是手动的，十分繁琐而且容易出错；其次，不足监控，Flink 自身内置了很多监控，然而没有一个主动的形式将它们加上去，还是须要手动地去做配置；此外，工作的保护也十分麻烦，一些不太熟悉的开发人员进行操作很容易呈现问题，而且呈现问题之后也难以排查。 实时计算平台 1.0 的生命周期如上图。工作写完之后打成 jar 包进行上传提交，后续的开启工作、进行、复原和监控都可能主动进行。 作业管理次要负责作业的创立、运行、进行、复原和更新。日志次要记录 Flink 工作提交时的一些日志，如果是运行时的日志还是要通过 Yarn 集群里的 log 来查看，略微有点麻烦。对于监控和告警模块，首先 metrics 监控次要是利用 Flink 内置的指标上传到 Prometheus，而后配置各种监控的界面，告警也是利用 Prometheus 的一些指标进行规定的设置，而后进行告警的设置。Yarn 负责整体集群资源的治理。 上图是实时计算平台 1.0 的界面，整体性能比较简单。 上图是实时计算平台 2.0。绝对于 1.0，最大的区别是蓝色的局部。对于实时计算平台的状态，可能并没有一个对立的规范，它与每个公司自身的状况非亲非故，比方公司自身的体量和规模、公司对实时计算平台的资源投入等，最终还是应该以实用于公司自身的现状为最佳规范。 2.0 版本咱们减少从开发到测试两个阶段性能的反对。简略介绍一下它们的具体性能： FlinkSQL：它是很多公司的实时计算平台都反对的性能，它的长处在于能够升高应用老本，也比较简单易用。空间治理：不同的部门和不同的组能够在本人的空间里进行作业的创立、治理。有了空间的概念之后，咱们能够利用它做一些权限的管制，比方只能在本人有权限的空间里进行一些操作。UDF 治理：应用了 FlinkSQL 的前提下，就能够基于 SQL 的语义用 UDF 的形式裁减性能。此外，UDF 还能用于 Java 和 Schema 工作，能够把一些专用的性能包装成 UDF，升高开发成本。它还有一个很重要的性能就是调试，能够简化原有的调试流程，做到用户无感知。实时计算平台 2.0 的实现，带给咱们最大的影响就是加重了数据团队的累赘。在咱们原先的开发流程里，常常须要数据团队的染指，但实际上其中的很大一部分工作都是比较简单的，比方数据同步或数据的简略解决，这类工作并不一定须要数据团队去染指。 ...