Flink

摘要：本文整顿自阿里云实时计算高级运维专家王华 (尚付) 在 Flink Forward Asia 2021 生产实践专场的演讲。次要内容包含： 演进历史和运维挑战集群运维 Flink Cluster利用运维 Flink Job点击查看直播回放 & 演讲PDF 一、演进历史和运维挑战 阿里的实时计算经验了近 10 年的疾速倒退，总体来说能够分成三大时代： 1.0 时代：2013 年到 2017 年，三大实时计算引擎并存。大家相熟的 Jstorm 和 Blink 过后都还叫做流式计算。2.0 时代：2017 年团体合并了三大实时计算引擎，Blink 凭借着杰出的性能、高效的吞吐成为惟一的实时计算引擎，实现了大一统。在接下来的 4 年里，团体所有实时计算业务全副迁徙到 Blink，阿里的实时计算业务经验了最飞速的增长，平台规模体量也从千级别增长到万级别，实时计算 all on Blink。3.0 时代：随着前两年阿里收买了德国 Flink 母公司，阿里中国和德国团队联手打造了基于云原生新底座、搭载 Flink 开源新引擎的 VVP 新平台。在 2021 年双 11，VVP 新平台以大幅度的性能晋升安稳撑持了双 11，宣告着阿里实时计算进入了全新的 3.0 时代。目前，阿里的实时计算曾经领有了几百万核算力，几万台物理机，几万个作业，真正造成了一个超大规模的实时计算平台。而且在业务飞速发展过程中，平台整体的架构从云下的 Hadoop Flink 正在全面往云原生 K8s 加 Flink 大规模演进中。 面对这样一个实时计算的硕大无朋，运维也随着时代变迁面临了不同的挑战： 第一阶段是平台运维，外围是帮忙 SRE 解决超大规模体量的平台运维，也就是 Flink Cluster 集群运维的难题；第二阶段是利用运维，外围是帮忙集群上大量的实时计算用户解决利用侧 Flink 作业运维简单的难题；第三阶段是随着 3.0 时代的到来，集群底座全面云原生化，全域数据也随着云原生而标准化，运维能力如何向云原生和智能化疾速演进和晋升，成为咱们新的挑战。二、集群运维 Flink Cluster ...

摘要：本文整顿自小米软件开发工程师金风在 Flink Forward Asia 2021 流批一体专场的演讲。本篇内容次要分为三个局部： 小米的大数据倒退演变流批一体的平台建设流批一体利用场景将来布局点击查看直播回放 & 演讲PDF 一、小米的大数据倒退演变 2019 年之前，小米的实时计算次要以 SparkStreaming 为主，少部分 Storm，离线计算以 Spark 为主。2019 年，开始接入 Flink，并广泛应用于信息流搜寻举荐、广告实时样本、实时 ETL 等场景，逐渐替换了原来的 SparkStreaming 作业，得益于 Flink 框架的各种优良个性，咱们在作业的正确性，实时性，资源应用效率方面都有较大晋升。2020 年，开始接入应用 FlinkSQL，并宽泛用于实时数仓的建设和实时 ETL 作业的开发。FlinkSQL 的实时数仓将数据链路由 T+1 升高到了秒级。2021 年，开始接入数据湖 Iceberg，基于 Flink 和 Iceberg 来构建流批一体的实时数仓解决方案，并在小米外部的局部业务进行了落地，证实流批一体在赋能业务、晋升作业开发效率、简化链路节俭资源的方面是可行的。 上图是小米以后的实时和离线框架，目前是多种框架并存的状态。业务开发人员无论是写 SQL 作业还是写 Jar 包作业，都至多要保护两套代码。公司外部的计算引擎团队也须要花两拨人力别离去保护不同的计算框架，同时平台层也须要对不同的计算引擎去做不同的适配。 基于流批一体的革新，无论是实时还是离线都只须要保护一套计算框架，为业务开发人员、平台提供方和计算引擎的反对方节俭了一半的人力资源。 二、流批一体的平台建设为了摸索流批一体，咱们也做了很多相干的摸索和实际。 对于流批一体的平台化建设，次要分为 4 个方面，别离是元数据管理、权限治理、作业调度以及 Flink 的生态建设。 2.1 元数据管理 咱们基于 Metacat 做了对立的元数据管理，由 Metacat 对立对接上游不同的存储系统和上游的计算引擎。 基于 Metacat，外部的所有零碎都被对立划分成三级构造，与 FlinkSQL 的三级构造绝对应。 第一级 Catalog，次要由服务名和集群名拼接而成。第二级 Database，它与大部分零碎的 Database 保持一致。没有 Database 的零碎默认应用 default 来代替。第三级 Table，也与零碎的 Table 保持一致，比方音讯队列的 topic 名， Elasticsearch 的索引名。在构建好对立的元数据管理之后，只须要写一条 DML 语句即可实现一个实时将音讯队列数据入湖作业的开发。 ...

导读： 近些年随着云计算和云原生利用的衰亡，容器技术能够很好地解决许多问题，所以将大数据平台容器化是一种现实的计划。本文将联合袋鼠云数栈在Flink on Kubernetes的实际让您对大数据平台容器化的操作和价值有初步的理解。 你能够看到 ▫ Kubernetes如何解决Hadoop痛点 ▫ 数栈在Flink on K8S的实际 ▫ 容器化之后的将来构想：资源池化 作者 / 雅泽、狗焕 编辑 / 向山 引言 在过来的很长一段时间，大数据畛域中构建可扩大的分布式应用框架中，Apache Hadoop占据的是相对的统治位置。 目前绝大多数大数据平台都是基于Hadoop生态构建，应用YARN作为外围组件进行资源管理与资源调度，然而这些大数据平台广泛都会存在资源隔离性差、资源利用率低等问题，与此同时近些年随着云计算和云原生利用的衰亡，容器技术能够很好地解决这些问题。 所以将大数据平台容器化是一种现实的计划，本文将联合袋鼠云数栈在Flink on Kubernetes的实际让您对大数据平台容器化的操作和价值有初步的理解。 Hadoop痛点频现，亟待解决 大数据平台顾名思义就是解决急速增长的实时、离线数据的大规模应用程序，所以设计大数据平台的解决方案的须要思考的首要问题就是如何确定生产环境中大数据平台的部署架构，使得平台具备紧密联系数据、应用程序与基础设施之间的能力。 Hadoop次要提供了三个要害性能：资源管理器(YARN)、数据存储层(HDFS)、计算范式(MapReduce)，市面上大多数大数据平台都是基于Hadoop生态构建的，然而这类型的平台会存在下列问题： 资源弹性有余 大数据系统的资源应用顶峰是具备周期性的，不同业务线在一天中的高峰期是不一样的，当业务压力增大时，以后的大数据系统广泛不足资源弹性伸缩的能力，无奈按需进行疾速扩容，为了应答业务顶峰只能预留出足够的资源保障工作失常运行； 资源利用率低 存储密集型的业务存储资源应用较高而CPU使用率长期处于较低的程度，计算密集型的业务尽管CPU使用率绝对较高然而存储的使用率非常低，大量资源闲置； 资源隔离性差 从Hadoop2.2.0开始，YARN开始应用cgroup实现了CPU资源隔离，通过JVM提供的内存隔离机制来实现内存资源隔离，整体上来看YARN的资源隔离做的并不欠缺，会造成多个工作运行到同一个工作节点上时，不同工作会呈现资源抢占的状况。 Kubernetes风头正劲，完满解决Hadoop痛点 Kubernetes是谷歌开源的生产级的容器编排零碎，是建设在谷歌大规模运行生产工作负载方面的十几年的教训根底上的，而且领有一个宏大且快速增长的生态系统，随同着微服务、DevOps、继续交付等概念的衰亡和继续发酵，并依靠与云原生计算基金会(CNCF)，Kubernetes放弃着高速倒退。 如下图所示，Google过来五年对于Kubernetes和Apache Hadoop热度统计后果展现表明市面上对Kubernetes的激情逐步低落而对Hadoop热度逐步减退。 那么，Kubernetes是如何解决Hadoop存在的痛点的呢，咱们一一剖析一下。 解决资源弹性有余 对于资源弹性有余的问题，Kubernetes自身就是设计为一个利用模块化架构来进行扩大的零碎，对用户来说，服务进行扩容只须要批改配置文件中容器的正本数或者是应用Pod程度主动扩缩(HPA)，将利用扩缩容的复杂度交给Kubernetes管制能够极大缩小人为染指的老本。HPA是基于CPU使用率、内存使用率或其余实时采集的性能指标主动扩缩ReplicationController、Deployment和ReplicaSet中的Pod数量。 Kubernetes中的Metrics Server会继续采集所有Pod正本的性能指标信息，HPA控制器通过Metrics Server的API获取这些数据，并依据用户设置的主动扩缩容规定计算指标Pod正本数量，当指标Pod数量与以后Pod数量不统一时，HPA控制器就向Pod的正本控制器发动扩缩容操作，调整Pod数量，实现扩缩容操作。 解决资源使用率低  对于资源使用率低的问题，一方面Kubernetes反对更加细粒度的资源划分，这样能够尽量做到资源能用尽用，最大限度的按需应用。另外一方面反对更加灵便的调度，并依据业务SLA的不同，业务顶峰的不同，通过资源的混合部署来进一步晋升资源使用率。 解决资源隔离性差 对于资源隔离性差的问题，容器技术自身是具备资源隔离的能力的，底层应用Linux namespace进行资源隔离，它将全局零碎的资源包裹在一个形象层中，使得在每个 namespace 外部的过程看起来本人都领有一个独立的全局资源。 同一个 namespace 下的资源变动对于同一 namespace 的过程是可见的，然而对于不同namespace下的过程是不可见的。为了可能让容器不占用其它容器的资源（或者说确定每个容器的“硬件”配置），采纳cgroups来限度单个过程或者多个过程所应用资源的机制，能够对 cpu，内存等资源实现精细化的管制。 Flink on K8S实际，数栈钻研小成 正因为大数据组件容器化劣势显著，数栈应用的大数据计算和存储组件均预期往容器化方向排布。 在数栈目前应用的泛滥组件中，咱们首先抉择在k8s上尝试实际的是数栈流计算引擎——Flink 。通过钻研布设，当初数栈的流计算容器化转换曾经根本实现。接下来是一些Flink on K8S的教训分享: Flink on K8S概述 ...

摘要：本文整顿自网易互娱技术核心计费实时平台与 SDK 技术负责人林佳在 Flink Forward Asia 2021 行业实际专场的演讲。本篇内容次要分为三个局部： 从一次 APP 内购买领取聊起实时 SDK 与平台化的双线倒退走向实时全关联点击查看直播回放 & 演讲PDF 说到网易互娱，大家首先想到的必定是游戏。作为网易的外围业务线之一，让游戏业务能够稳固牢靠地运行天然是重中之重，而游戏业务中最重要就是 APP 内购买服务的可靠性。本文的分享，就从一次 APP 内购买聊起。 一、从一次 APP 内购买领取聊起 玩家在游戏内购买道具的操作，首先会触发客户端行为与渠道商、计费核心进行通信，实现下单与领取。计费核心也会与渠道商进行交互，验证客户端订单的合法性以及领取状态。只有订单非法，游戏服务才会被告诉发货。而这一整套流程下来，每一个参与者产生的日志、数据监控点等等，它们的起源、数据结构、工夫步调可能是千差万别的。此外，这个过程中还有通信网络、数据库、监控零碎等的参加，使得整个过程非常复杂。 数据继续而大量地产生，数据之间会话的关联、数据源之间的异构、数据结构的异构还有工夫步调的不统一等等，都是咱们抉择用实时形式去解决的起因。 2017 年之前咱们的解决形式绝对落后，其中还有一些比拟古老的解决形式，比方网盘、rsync、T+1 解决离线工作等。 组件繁多、技术栈的割裂、时效性低、资源应用状况毛糙等，都会使资源无奈被平均地利用，而这正是带来时效性低的起因之一，也使代码能效、数据能效和资源能效都绝对较低。 上图是咱们之前的离线计算业务运行时的资源状况示意，在凌晨的时候去计算前一天的数据报表。在流式计算遍及之前，这是一种十分大规模应用的模式，在凌晨的时候用一大批机器执行 Spark 离线工作去计算前一天的后果。为了使报表能够按时交付，整个离线集群须要大算力，重叠大量的机器资源，而这些机器资源在许多时间段却是闲暇的，这便造成了资源能效低下。 如果这类计算工作能够被实时化，那么它所须要的算力即可被摊派到每一个工夫片上，防止在凌晨的时候资源应用重大歪斜。这些机器算力能够被托管在资源管理的平台上，所以它们也能够被其余业务所应用，进而晋升能效。 那么如何抉择实时化的框架？通过粗浅的调研和尝试之后，咱们最终抉择了 Flink，它所提供的个性，能够说是齐全适配了咱们的场景，下图列举了咱们对于技术架构选型的一些思考。 二、实时 SDK 与平台化的双线倒退网易互娱从 2018 年开始便制订了双线倒退打算，全面推动数据中心 JFlink 的实时化过程。 通过屡次迭代，目前咱们曾经造成了一个一站式的运维平台 + 一个反对配置化开发的 SDK，且曾经实现了从可用到实用的进阶，下一步就是让用户爱用。 如何进步人力以及代码的效力，是咱们从一开始设计 JFlink 的时候就极其重视的。咱们心愿能够用无限的人力最大化地施展出能效，所以 SDK 的配置化、模块化变得尤为重要，要实现每一个实时作业都能够用一套配置语义来形容。 SDK 中封装了 JFlink SDK 罕用的连接器处理函数以及数据的流转对象，使得能够以配置化的模式来组装和应用它们。SDK 还提供了对立的配置文法，可能将作业以配置的模式形容后，动静地去组织结构 Flink DAG，以实现一个 SDK 程序包笼罩各类数据业务的个性，进步代码的复用和能效。 ...

摘要：本文整顿自众安保险大数据平台开发高级专家郭育波在 Flink Forward Asia 2021 行业实际专场的演讲。次要内容包含： 整体详情智能营销利用实时特色利用反欺诈利用前期布局点击查看直播回放 & 演讲PDF 一、 整体详情 上图是咱们的实时计算整体架构图，最上层是数据源层，包含了来自于利用零碎的业务数据、利用零碎的音讯数据、用户行为埋点数据以及利用日志数据，这些数据都会通过 Flink 进入实时数仓。 实时数仓分为三层： 第一层是 ODS 层，数据通过 Flink 到 ODS 层后会关联一张原始表，这个表是和数据源一一对应的，而后会有一个视图表对原始数据进行简略的荡涤加工；之后，数据通过 Flink 下发到 DWD 层，DWD 层是基于主题域进行划分的，咱们当初划分为用户数据域、营销数据域、信贷数据域和保险数据域等；另外还有一部分是 DIM 层，蕴含用户相干、产品相干和渠道相干等维表数据，DIM 层的数据会保留到 HBase 中。通过 DWD 层的数据荡涤之后，数据下发到 DWS 层，DWS 层会对数据进行整合汇总，个别会有指标宽表和多维明细宽表。之后这些数据会进入 ADS 层，这一层蕴含多样的 OLAP 数据存储引擎。咱们当初次要应用 ClickHouse 作为大盘实时报表的存储引擎，还有 HBase 和阿里云的 TableStore 为用户标签和特色工程提供数据存储服务，还有 ES 次要用于实时监控场景。 上图是咱们的实时计算平台架构图，整个实时计算平台能够分为三个局部。第一局部是工作治理后盾，在工作治理模块外面编辑和提交工作，工作编辑器同时反对 Flink SQL 和 Flink JAR 工作，提供了比拟便当的 Flink SQL 编辑性能和调试性能，也反对多种工作启动策略，比方基于 checkpoint、offset、工夫点和最早地位等，还反对定时和即时生成 checkpoint 性能。工作提交之后，会通过 Flink 客户端将它提交到咱们自建的 CDH 集群里。工作治理服务也会定时从 Yarn 获取工作的实时状态。 ...

摘要：本文整顿自哔哩哔哩基础架构部资深研发工程师张杨在 Flink Forward Asia 2021 平台建设专场的演讲。次要内容包含： 平台建设增量化AI On Flink点击查看直播回放 & 演讲PDF 在过来的一年里，B 站围绕 Flink 次要做了三个方面的工作：平台建设、增量化和 AI on Flink。实时平台是实时业务的技术底座，也是 Flink 面向用户的窗口，须要保持继续迭代优化，一直加强性能，晋升用户效率。增量化是咱们在增量化数仓和流批一体上的尝试，在实时和离线之间找到一个更好的均衡，减速数仓效率，解决计算口径问题。AI 方向，咱们也正在联合业务做进一步的摸索，与 AIFlow 社区进行单干，欠缺优化机器学习工作流。 一、 平台建设1.1 根底功能完善在平台的根底性能方面，咱们做了很多新的性能和优化。其中两个重点的是反对 Kafka 的动静 sink 和工作提交引擎的优化。 咱们遇到了大量这样的 ETL 场景，业务的原始实时数据流是一条较大的混合数据流，蕴含了数个子业务数据。数据通过 Kafka 传输，末端的每个子业务都对应独自的解决逻辑，每个子业务都去生产全量数据，再进行过滤，这样的资源耗费对业务来说是难以承受的，Kafka 的 IO 压力也很大。因而咱们会开发一个 Flink 工作，对混合数据流依照子业务进行拆分，写到子业务对应的 topic 里，让业务应用。 技术实现上，晚期 Flink SQL 的写法就是写一个 source 再写多个 sink，每个 sink 对应一个业务的 topic，这的确能够满足短期的业务诉求，但存在的问题也较多： 第一是数据的歪斜，不同的子业务数据量不同，数据拆分后，不同 sink 之解决的数据量也存在较大差异，而且 sink 都是独立的 Kafka producer，顶峰期间会造成 sink 之间资源的争抢，对性能会有显著的影响；第二是无奈动静增减 sink，须要扭转 Flink SQL 代码，而后重启工作能力实现增减 sink。过程中，不仅所有上游工作都会抖动，还有一个重大的问题就是无奈从 savepoint 复原，也就意味着数据的一致性无奈保障；第三是保护老本高，局部业务存在上百个子分流需要，会导致 SQL 太长，保护老本极高。 ...

摘要：本文整顿自京东资深技术专家付海涛在 Flink Forward Asia 2021 平台建设专场的演讲。次要内容包含： 根本介绍生产实践优化改良将来布局点击查看直播回放 & 演讲PDF 一、根本介绍 K8s 是目前业内十分风行的容器编排和治理平台，它能够非常简单高效地治理云平台中多个主机上的容器化利用。在 2017 年左右，咱们实时计算是多个引擎并存的，包含 Storm、Spark Streaming 以及正在引入的新一代计算引擎 Flink，其中 Storm 集群运行在物理机上，Spark Streaming 运行在 YARN 上，不同的运行环境导致部署和经营老本特地高，且资源利用有肯定节约，所以迫切需要一个对立的集群资源管理和调度零碎来解决这个问题。 而 K8s 能够很好地解决这些问题：它能够很不便地治理成千上万的容器化利用，易于部署和运维；很容易做到混合部署，将不同负载的服务比方在线服务、机器学习、流批计算等混合在一起，取得更好的资源利用；此外，它还具备人造容器隔离、原生弹性自愈的能力，能够提供更好的隔离性与安全性。 通过一系列的尝试、优化和性能比照后，咱们抉择了 K8s。 2018 年初，实时计算平台开始全面容器化革新；到 2018 年 6 月，曾经有 20% 的工作运行在 K8s 上，从运行后果看，无论是资源的共享能力、还是业务解决能力，以及敏捷性和效率方面都取得了较大晋升，初步达到了预期的成果；到 2019 年 2 月实现了实时计算全副容器化；之后直到现在，咱们在 K8s 的环境也始终在进行优化和实际，比方进行弹性伸缩、服务混部、工作疾速恢复能力建设等方面的实际。 全副 on K8s 后收益还是比拟显著的：首先混合部署服务和资源共享能力取得了晋升，节俭机器资源 30%；其次，具备更好的资源隔离和弹性自愈能力，比拟容易实现依据业务的负载进行资源的弹性伸缩，保障了业务的稳定性；最初开发、测试、生产一致性的环境，防止环境给整个开发过程带来问题，同时极大晋升了部署和经营自动化的能力，升高了治理运维的老本。 京东 Flink on K8s 的平台架构如上图，最上面是物理机和云主机，之上是 K8s，它采纳京东自研的 JDOS 平台，基于规范的 K8s 进行了许多定制优化，使之更适应咱们生产环境的理论状况。JDOS 大部分运行在物理机上，少部分是在云主机上。再往上是基于社区版 Flink 进行深度定制化后的 Flink 引擎。 最下面就是京东的实时计算平台 JRC，反对 SQL 作业和 jar 包作业，提供高吞吐、低提早、高可用、弹性自愈易用的一站式海量流批数据计算能力，反对丰盛的数据源和指标源，具备欠缺的作业管理、配置、部署、日志监控和自运维的性能，提供备份回滚和一键迁徙的性能。 ...

摘要：本文整顿自字节跳动基础架构工程师方勇在 Flink Forward Asia 2021 核心技术专场的演讲。次要内容包含： 背景问题和剖析调度执行优化将来打算点击查看直播回放 & 演讲PDF 一、背景 字节跳动的很多的业务方都有混合计算的需要，心愿一套零碎既反对 TP 计算，也反对 AP 计算。 上图是咱们 HTAP 零碎的总体架构。TP 侧应用咱们外部自研的数据库作为 TP 计算引擎，AP 侧是用 Flink 作为 AP 的计算引擎。咱们对外通过 MySQL 协定作为对立的入口，如果一个查问是 AP 计算，就会被转发到 Flink 的 Gateway 生成执行打算，而后提交到 Flink 引擎去执行计算。AP 侧有一个列式存储，Flink 引擎通过 Catalog 和 Connector 的接口，别离与存储端的元信息和存储层进行交互。AP 计算实现后，Client 端会向 Flink Gateway 发动 Proxy 数据的申请，而后由 Gateway 向 Flink 集群 Proxy 后果数据。至此，整个 AP 计算的查问交互和计算执行就实现了。 家喻户晓，Flink 是一个流批一体的计算引擎，既能够反对流式计算，也能够反对批式计算。为什么当初有很多零碎抉择应用 Flink 来做 OLAP 计算？ 咱们比照了 Flink 与 Presto 的差别，首先从架构上看，Flink 反对多种不同的部署模式，Flink 的 session 集群是一个十分典型的 MPP 架构，这是 Flink 能够反对 OLAP 计算的前提和根底。在 Flink 的计算执行上能够分为执行打算、作业 Runtime 治理、计算工作执行治理、集群部署和 Failover 治理 4 大部分。从 Presto 和 Flink OLAP 的架构以及功能模块图来看，两套零碎在反对这些计算性能的具体实现上有很大的差别，但他们提供的零碎能力和模块性能上是基本一致的。 ...

前言Flink CDC (CDC Connectors for Apache Flink®) [1]是 Apache Flink® 的一组 Source 连接器，反对从 MySQL，MariaDB, RDS MySQL，Aurora MySQL，PolarDB MySQL，PostgreSQL，Oracle，MongoDB，SqlServer，OceanBase，PolarDB-X，TiDB 等数据库中实时地读取存量历史数据和增量变更数据，用户既能够抉择用户敌对的 SQL API，也能够应用性能更为弱小的 DataStream API。 作为新一代的数据集成框架， Flink CDC 不仅能够代替传统的 DataX 和 Canal 工具做实时数据同步，将数据库的全量和增量数据一体化地同步到音讯队列和数据仓库中；也能够用于实时数据集成，将数据库数据实时入湖入仓；同时还反对弱小的数据加工能力，能够通过 SQL 对数据库数据做实时关联、打宽、聚合，并将物化后果写入到各种存储中。 绝对于其余数据集成框架，Flink CDC 具备全增量一体化、无锁读取、并发读取、表构造变更主动同步、分布式架构等技术劣势，在开源社区中十分受欢迎，成长迅速，文档欠缺[2]，目前社区已有 44 位贡献者，4 位Maintainer，社区用户群超过 4000 人。 一、Flink CDC 2.2 概览通过3个多月的缓和开发，在社区开发者们的共同努力下，Flink CDC 2.2 版本正式公布了：https://github.com/ververica/... 2.2 版本共有 34 位社区贡献者参加奉献，累计奉献了 110+ commits。一图胜千言，本文通过下图带你一分钟疾速理解 Flink CDC 2.2 版本的重大改良和外围个性。 2.2 版本新增 OceanBase，PolarDB-X，SqlServer，TiDB 四种数据源接入，均反对全量和增量一体化同步。 至此，Flink CDC 已反对 12 种数据源。Flink CDC 兼容 Flink 1.13 和 Flink 1.14 两个大版本，2.2 版本的所有 Connector 都反对跑在 Flink 1.13. 或 Flink 1.14. 的集群上。提供增量快照读取框架，不便其余连接器接入，其余连接器采纳该框架后，便能够提供无锁算法，并发读取，断点续传等性能。MySQL CDC 反对动静加表，该性能能够在无需从新读取已有表的根底上，减少须要监控的表，增加的表会主动先同步该表的全量数据再无缝切换到同步增量数据。MongoDB CDC 反对正则表达式过滤汇合，该性能能够让用户在作业中指定所需监控的库名和汇合名，用户能够用一个作业中监控多个数据库或多个汇合。二、新增 4 种数据源反对Flink CDC 2.2 版本新增了 OceanBase CE，PolarDB-X，SqlServer，TiDB 四种数据源接入。其中新增 OceanBase CDC，SqlServer CDC，TiDB CDC 三个连接器，而 PolarDB-X 的反对则是通过对 MySQL CDC 连接器进行兼容适配实现。 ...

摘要：本文整顿自翼领取高级开发工程师曹劼、尹春光在 Flink Forward Asia 2021 平台建设专场的分享。本篇内容次要分为四个局部： 公司简介实际中的问题案例实际将来布局点击查看直播回放 & 演讲PDF 一、公司简介 翼领取是中国电信的全资子公司，公司次要业务分为民生缴费、生产购物、金融理财，同时咱们依靠云计算、大数据、人工智能等技术手段，赋能线上及线下的商户。 公司次要的业务板块分为数字生存、数字金融及金融科技服务。其中数字生存次要是指惯例的领取业务，例如民生缴费，即居民的水电煤气费缴纳等等，同时咱们会联合电信联合推出 5G 的权利套餐；数字金融次要是蕴含保险、理财、信贷，其中橙分期和企业白条是重点产品；科技服务次要分为企业征信及数智业务，企业征信是指依靠现有的云计算、大数据、人工智能、区块链等外围科技能力，打造业余高效智能的风险管理及征信科技解决方案。数智业务是指以天翼云为根底平台，重点聚焦 SaaS/PaaS 服务及金融平安服务，打造端到端的金融解决方案。 目前，翼领取的月活用户数为 5000万+，存量用户数 5 个亿+，线上的服务器大概 4000 台，每日的记录数为千亿条。 随着公司的业务规模一直扩大，咱们面临的业务挑战也在一直增多，次要体现在两个方面： 一方面，随着需求量的一直增多，采纳定制化开发的形式使得利用的数量急剧减少，导致利用难以对立治理，各个业务线的利用向着烟囱式的方向倒退，指标口径和计算不对立，反复的加工会造成能力的节约；另一方面，某些场景下的单 topic 数据量高达 220 万/秒，同时针对风控等场景，业务响应提早要求 200 毫秒以内。 针对以上问题，咱们从 18 年开始，联合行业的实践经验，积极探索建设实时加工体系。在 19 年开始着手构建实时指标加工零碎，引入 SparkStreaming 作为计算引擎。在 20 年初出于对时效性的思考，咱们引入 StructuredStreaming 作为实时计算引擎。随着服务的利用一直增多，咱们接管到依赖原子指标的组合的实时决策需要逐步增多。因而在 20 年 9 月份，咱们开始构建实时决策零碎，将 FlinkCEP 引入零碎中。直到往年 4 月份，为了解决一些简单指标的加工需要，咱们将 Flink SQL 引入到了指标加工链路中。 通过产品的一直迭代，最终造成了一套企业化的智能决策零碎——先鉴平台。 上图展现了先鉴平台的次要性能。首先是实时指标加工。目前咱们反对多样化的数据源，次要蕴含罕用的中间件比方 Kafka 及 Pulsar。同时为了升高用户的应用难度，咱们提供了 23 种算法模板，也反对 SQL 的定制化加工形式；其次是实时决策。咱们反对丰盛的规定及规定组的嵌套组合，满足简单决策的需要。此外，咱们整合了实时、离线及第三方的标签，为用户提供对立的数据查问服务，同时为了生产的稳定性，咱们提供了全面的监控性能和细粒度资源隔离、熔断、限流的策略。同时针对实时计算作业的运行状态，咱们对 Source 及 Sink 的数据量和提早都进行了相干的 Metrics 监控。 ...

本文整顿自 Apache Flink 中文社区发起人、阿里巴巴开源大数据平台负责人王峰（莫问）在 Flink Forward Asia 2021 的分享。本篇内容次要分为四个局部： 2021: Apache Flink 社区继续凋敝Apache Flink 核心技术演进流批一体演进与落地机器学习场景反对点击查看直播回放 & 演讲PDF 一、2021: Apache Flink 社区继续凋敝1.1 Flink 大版本迭代 2021 年，Flink 社区共公布两个大版本：Flink 1.13 和 Flink 1.14。 在 Flink 1.13 中，Flink 的部署架构朝着云原生架构进一步演进，使得 Flink 可能更加适应云原生环境下的运行；此外，Flink 在易用性方面也有显著晋升，使得用户能够十分便捷地对 Flink 工作进行调试、调优和监控等；在存储方面，Flink Checkpoint 格局失去对立，用户在不同的 State backend 之间无缝切换，不同的版本之间可进行晦涩降级。 Flink 1.14 中最大的变动是残缺地实现了 Flink 流批一体的架构和理念。在去年的 Flink Forward Asia 2020 会议上我重点分享了 Flink Unified SQL。往年，Flink 不仅在 SQL 和 Table API 上进行了流批一体的对立，在 Java API 自身、Data Stream，Data set API 上也进行了流批一体的对立。所有流批一体的语义都被对立到 Data stream API 之上，用户基于 Data stream 能够解决无限流和有限流从而实现流批一体的开发。此外 Flink 在资源层实现了细粒度的资源管理，令 Flink 工作在大规模场景下更高效；在网络流控方面 Flink 也进行了自适应流控的降级，通过自适应流控降级之后，用户能够更快地执行 Flink 的全局一致性快照。通过这些技术创新和技术演进之后，Flink 社区持续放弃疾速倒退和生态沉闷。 ...

文：王东阳 前言 在Flink中依据数据集是否依据Key进行分区，将状态分为Keyed State和Operator State（Non-keyed State）两种类型 ，在之前的文章《Flink中基于KeyedState的计算开发方法》曾经具体介绍了Keyed State的概念和用法，本文将持续介绍Operator State。 Operator State与Keyed State不同的是，Operator State只和并行的算子实例绑定，和数据元素中的key无关，每个算子实例中持有所有数据元素中的一部分状态数据。Operator State反对当算子实例并行度发生变化时主动重新分配状态数据， OperatorState目前只反对应用ListState。 Operator State与并行的操作算子实例相关联，例如在Kafka Connector中，每个Kafka生产端算子实例都对应到Kafka的一个分区中，保护Topic分区和Offsets偏移量作为算子的Operator State 在Flink中能够通过 Checkpointed-Function 或者 ListCheckpointed<T extends Serializable>两个接口来定义操作Operator State的函数。 Operator State开发实战 本章节将通过理论的我的项目代码演示Operator State在两种不同计算场景下的开发方法。 在样例中将演示Operator State如何交融进入Flink 的DataStream API，让用户在开发Flink利用的时候，能够将长期数据保留在State中，从State中读取数据，在运行的时候，在运行层面上与算子、Function体系交融，主动对State进行备份Checkpoint，一旦出现异常可能从保留的State中复原状态，实现Exactly-Once 。 通过CheckpointedFunction接口操作Operator StateCheckpointedFunction接口定义如代码所示，须要实现两个办法，当checkpoint触发时就会调用snapshotState()办法，当初始化自定义函数的时候会调用initializeState()办法，其中包含第一次初始化函数和从之前的checkpoints中复原状态数据，同时initializeState()办法中须要蕴含两套逻辑， 一个是不同类型状态数据初始化的逻辑，一个是从之前的状态中复原数据的逻辑 @Publicpublic interface CheckpointedFunction { // 每当 checkpoint 触发的时候 调用这个办法 void snapshotState(FunctionSnapshotContext var1) throws Exception; // 每次 自定义函数初始化的时候 调用此办法初始化 void initializeState(FunctionInitializationContext var1) throws Exception;}在每个算子中Managed Operator State都是以List模式存储，算子和算子之间的状态数据互相独立，List存储比拟适宜于状态数据的从新散布，Flink目前反对对Managed Operator State两种重散布的策略，别离是Even-split Redistribution和Union Redistribution。 Even-split Redistribution：每个算子实例中含有局部状态元素的List列表，整个状态数据是所有List列表的合集。当触发 restore/redistribution 动作时，通过将状态数据平均分配成与算子并行度 雷同数量的List列表，每个task实例中有一个List，其能够为空或者含有多个元素Union Redistribution：每个算子实例中含有所有状态元素的List列表，当触发 restore/redistribution 动作时，每个算子都可能获取到残缺的状态元素列表实现FlatMapFunction和CheckpointedFunction在理论我的项目中能够通过实现FlatMapFunction和CheckpointedFunction实现对输出数据中每个key的数据元素数量和算子中的元素数量的统计。如代码所示，通过在initializeState()办法中别离创立keyedState和operatorState两种State，存储基于Key相干的状态值以及基于算子的状态值。 ...

背景字节跳动开发套件数据集成团队（DTS ，Data Transmission Service）在字节跳动内基于 Flink 实现了流批一体的数据集成服务。其中一个典型场景是 Kafka/ByteMQ/RocketMQ -> HDFS/Hive 。Kafka/ByteMQ/RocketMQ -> HDFS/Hive（上面均称之为 MQ dump，具体介绍可见 字节跳动基于Flink的MQ-Hive实时数据集成 ） 在数仓建设第一层，对数据的准确性和实时性要求比拟高。 目前字节跳动中国区 MQ dump 例行工作数微小，日均解决流量在 PB 量级。微小的任务量和数据量对 MQ dump 的稳定性以及准确性带来了极大的挑战。 本文次要介绍 DTS MQ dump 在极其场景中遇到的数据失落问题的排查与优化，最初介绍了上线成果。 线上问题HDFS 集群某个元数据节点因为硬件故障宕机。在该元数据节点终止半小时后，HDFS 手动运维操作将 HDFS 切主到 backup 节点后，HDFS 复原服务。故障复原后用户反馈 MQ dump 在故障期间有数据失落，产出的数据与 MQ 中的数据不统一。 收到反馈后咱们立刻进行故障的排查。上面先简要介绍一下 Flink Checkpoint 以及 MQ dump 写入流程，而后再介绍一下故障的排查过程以及解决方案，最初是上线成果以及总结。 Flink Checkpoint 简介Flink 基于 Chandy-Lamport 分布式快照算法实现了 Checkpoint 机制，可能提供 Exactly Once 或者 At Least Once 语义。 Flink 通过在数据流中注入 barriers 将数据拆分为一段一段的数据，在不终止数据流解决的前提下，让每个节点能够独立创立 Checkpoint 保留本人的快照。每个 barrier 都有一个快照 ID ，在该快照 ID 之前的数据都会进入这个快照，而之后的数据会进入下一个快照。 ...

摘要：本文整顿自斗鱼实时计算负责人夏畅在 Flink Forward Asia 2021 行业实际专场的分享。本篇内容次要分为四个局部： 背景介绍实时平台建设实时数仓摸索将来倒退与瞻望点击查看直播回放 & 演讲PDF 一、背景介绍 斗鱼成立于 2014 年，是一家致力于为所有人带来欢畅的，弹幕式直播分享平台。在斗鱼，实时计算倒退得并不算早。 2018 年前后，为了满足一些近实时数据需要，如 5 分钟、1 小时等场景，先后引入了 Spark streaming 和 Storm 技术。随着业务的继续倒退，实时指标的需要更加多样性，Spark streaming 和 Strom 也越加难以反对。 大略在 2019 年，斗鱼引入了 Flink 技术，起初以 Flink jar 的开发方式，来反对这类实时数据需要。但 Flink jar 的形式应用起来门槛和老本还是太高了。 在 19 年底 20 年初，设计开发落地了基于 K8s 的 Flink 实时计算平台，同时反对以 SQL 和 JAR 两种形式的作业开发，在外部这个平台称为 “玄武计算平台”。 玄武计算平台上线后，撑持了不少业务场景，如广告、大屏，举荐、系统监控、风控，数据分析和实时标签等。 截止到 2021 年 3 季度，斗鱼实时计算平台的用户数达到 100+，Vcore 达到 2000+，作业数达到 500+，日解决数据量超过千亿条。 二、实时平台建设在建设玄武实时计算平台之前，咱们次要以 Flink jar 的形式开发，有以下几个痛点： ...

摘要：本文整顿自奇安信团体高级技术专家覃永靖在 Flink Forward Asia 2021 行业实际专场的分享。本篇内容次要分为四个局部： 什么是平安剖析计算框架的抉择引擎设计实际与瞻望点击查看直播回放 & 演讲PDF 一、什么是平安剖析 近 10 年来，大数据技术倒退突飞猛进。平安剖析场景和办法也更新换代。目前，罕用的平安剖析流程大略分为三个流程： 日志采集解析。通过各种办法，从服务器、网关设施、终端、数据库或其它数据源采集各种流量日志、威逼日志、运行日志，和终端日志等数据；实时平安剖析。剖析过程次要有平安基线、关联剖析、平安规定、威逼情报，和平安知识库；平安经营和态势感知。这个流程基于平安剖析的后果来实现态势可视化、平安经营、多设施平安联动、平安编排等能力。 如上图所示，平安畛域次要有三个特点： 疾速响应。因为安全事件常常是突发的，比方破绽的披露、病毒的暴发等经常是在很短的工夫忽然产生，所以须要以十分无效和简略易用的形式来疾速的对突发的安全事件进行解决，能第一工夫响应客户的需要、应答各类安全事件；场景定制。因为平安剖析和惯例的大数据分析场景会有一些不同，平安剖析检测的是异样而不是失常，还有畛域独有的一些需要，所以这里会波及到很多畛域定制开发的需要。资源受限。相比惯例互联网大数据平台应用形式，平安剖析可应用的资源会有很多的限度，通常用户受限于估算和资源的限度，会尽可能的压缩和优化可用计算和存储资源规模，这会导致大量的组件采纳混合部署的形式，且未来硬件和集群扩大老本也很高，流程很长。 在实时数据安全方面，一共有五点需要： 第一是须要实时剖析。平安检测对时延要求严格，攻防单方抢时间差，须要能第一工夫检测到异样。同时因为是安全事件驱动，要求解决方案上线快，响应及时，能在最短时间造成防护能力；第二是须要提供十分丰盛的剖析语义。平安检测的场景通常比较复杂的，须要提供丰盛的平安剖析语义，笼罩大部分平安剖析场景；第三个是能灵便部署。因为客户的环境非常复杂，须要能反对各种大数据平台，比方客户自建的，或者是他购买的一些云平台，并且还要有最大的版本兼容性；第四是须要实现最小的资源应用。反对部署从一到几十甚至上百台节点的集群，在资源占用尽可能小的同时反对大规模，比方上千条剖析规定或平安基线同时运行；最初是运行稳固。平安产品部署在客户侧，须要 7×24 小时不间断运行，须要提供极高的运行稳定性，尽可能减少人工保护和染指，让客户无感知。 传统的平安分析方法个别是基于先验常识，采纳基于特色检测技术来进行异样检测，个别是通过剖析检测对象的数据或日志特点，而后人工演绎和统计出可检测特色，建设平安模型，比方平安规定、威逼情报等。这种形式比较简单和牢靠，能够很好的应答已有的攻打办法，然而它对未知的没有对应检测特色的攻打办法则不能无效的进行检测。 平安基线采纳基于行为的检测办法，应用检测对象数据和日志，采纳各种办法学习出行为特色，建设平安基线，并用于异样检测。 为了让大家能更好的了解平安基线的应用场景，这里列了三个实在场景： 场景一，DBA 用户账号登录异样。比方登录地位异样，登录工夫异样，应用数据库的行为异样等。比方一个 DBA 用户，通常是在某些工夫、某些 IP 或是某些地点登录，然而某天忽然在另外一个中央登录了，且工夫也不是通常登录工夫，那这可能就是一个异样，须要生成异样事件；场景二，邮件发送附件数量超过惯例值。比方平安基线学习部门或者整个公司发送邮件的行为数据，发现某一个用户发送附件的数量和历史学习数据有较大出入，那这可能是一个异样；场景三，最近账号登录 VPN 服务的次数异样。通过学习用户账号 VPN 历史登录行为，构建平安基线，如果未来发现账号登录异样，则产生异样事件。二、计算框架的抉择目前支流实时计算框架次要有两个，Spark 和 Flink。咱们当初设计这个引擎是在 2018 年左右，过后咱们钻研了 Storm、Spark、Flink 这三个计算框架，综合各方面因素最终抉择了 Flink 作为底层计算框架。过后应用的 Flink 是 1.4 版本左右，是一个比拟成熟的版本，相比其它框架，它的 API 以及它的底层分布式和流计算实现形式比拟合乎咱们的应用场景。 Flink 的劣势点比较突出，它是分布式计算框架，部署灵便，适配目前常见大数据平台。它领有很好的解决性能，能达到高吞吐低提早，这非常适合进行实时平安剖析。它还提供灵便的 DataStreaming API，不便实现定制化需要。另外，还反对简略易用的检查点和保留点机制。并且，作为目前十分热门的计算框架，社区沉闷，有丰盛的文档和场景样例。 尽管Flink有很多劣势，但当企业资源受限，规定集数量上千规模的状况下。Flink 在满足业务及性能需求上遇到了很多问题。比方无大规模规定语义/流优化，不足平安场景定制窗口和逻辑，无平安基线相干算子以及无资源爱护机制等。 三、引擎设计 引擎利用框架分为三层： 底层是部署层，通常是一个大数据集群；第二层是平安剖析层，基于 Flink DataStreaming API 来构建平安基线引擎，Flink 负责底层的分布式计算和事件流发送，具体的业务计算由平安基线引擎来实现。平安基线引擎向用户提供的应用接口为规定和 DSL，用户通过界面来下发规定 DSL 给引擎，引擎依据规定和 DSL 来对事件流进行剖析和计算，同时依据规定语义应用内部的数据，比方常识数据、威逼情报、资产和破绽等；用户通过第三层的应用层来治理和应用引擎。并基于引擎数据后果态势剖析，平安经营，资源监控等具体平安业务。 ...

本文首发于泊浮目标语雀:https://www.yuque.com/17sing 版本日期备注1.02022.3.16文章首发0.背景：Dataflow之前在Dataflow相干的论文发表前，大家都往往认为须要两套API来实现流计算和批计算，典型的实现便是Lambda架构。 因为晚期的流解决框架并不反对Exactly Once，导致流解决的数据并不精准。在这个根底上，一旦数据呈现问题，则要导致大量的数据重放——这是因为事件往往是有时序要求的。因而，Lambda往往会通过流解决框架获取不是特地精准的后果，同时也会定时运行批处理程序，来获取更精准的后果——当更精准的后果进去时，咱们就不须要前者了。 但这也带来的新的问题，所有的视图都须要流、批处理层各做一次，代码也要写两套，这带来了数据口径不同。能够说是在计算机资源以及人力资源上至多加了两倍的开销。 Kappa提出了将所有数据落到Kafka上，将存储模型与计算模型对立，但就义了工夫——当数据量大时，回溯计算的压力微小。 直到The dataflow model: a practical approach to balancing correctness, latency, and cost in massive-scale, unbounded, out-of-order data processing发表后，流与批无望在编程模型上对立， 上述相干的问题得以缓解。 1. Flink的实现Flink比起其余的流解决框架，更优在两点： 遵循Dataflow模型，在编程模型上对立流批一体改良Chandy-Lamport算法，以更低的代价保障精准一次的实现1.1 编程模型对立的背地编程模型的对立具体体现在Flink SQL以及DataStream上。咱们能够用雷同的SQL or 简直雷同的代码跑流与批的工作。尤其是SQL，比起DataStream在申明式上更甚。因而用户在应用它们时，仅仅须要形容本人想要什么，而不是本人要做什么。具体做什么的事，Flink框架会帮你搞定。 在Flink框架上，目前次要解决了以下问题： IO模型：批处理会更加关注吞吐，因而是pull模型；而流解决更加关注实时性，因而是push模型。基于这个条件，Source算子须要同时反对两种模型来适应不同的计算模式。具体见 FLIP-27: Refactor Source Interface。调度策略：批处理的算子并不需要同时在线，前一批的算子实现后再调度后一批算子即可——因为计算资源往往比存储资源低廉，这是一个很不错的优化计划。当然在资源短缺的状况下，谋求性能也能够不思考这种策略；但流解决的作业须要作业启动时就全副被调度。因而，StreamGraph须要同时反对这两种模式——即LazyScheduling和EagerScheduling。批流的连接：如果咱们要剖析近30天的数据，大多数状况下都是29天的离线数据加上最近一天的实时数据，如何保障连接时数据不多也不少，其实是个麻烦的事件，在不少工程实际中会用一些比拟hacks的办法。好在Flink1.4中引入了 Hybrid Source来简化这件事—— FLIP-150: Introduce Hybrid Source。1.2 Checkpoint不是银弹Checkpoint是Flink框架中重要的容错机制，它的一个前提要求是数据源可反复读。在数仓场景下，尽管绝大多数状况下数据都不会发生变化——但也会有冷数据处理机制以及一些merge产生。这将对数据可重读造成肯定的挑战。另外，在笔者负责的产品QMatrix中，对数据库做全量迁徙时也会遇到相似的挑战：T1时刻读到的全量数据为汇合1，而T2时刻读到的全量数据则为汇合2。而MVVC也只能维持在一个session中。 下面形容的是在数据源要思考的容错条件。在数据曾经全副流入工作时，容错机制也须要重新考虑——尽量避免反复读取数据源以及上游工作的重算。因而社区引入了可插拔的Shuffle Service来提供Shuffle数据的长久用以反对细粒度的容错复原——FLIP-31: Pluggable Shuffle Service。 2. 剩下的问题：数据起源不对立上述流批连接的前提是数据源被分为了流数据源和批数据源。那么口径便是不对立的，这会带来一些对接老本。 目前风行的计划会采纳数据湖（如IceBerg、Hudi、DeltaLake）来做流批数据的对立，并且因为大多数据湖都反对Time Travel，离线数据的可反复读问题也顺带解决。 另外，Pravega这种以流批一体存储为设计指标的软件可能也是解决方案之一。 3. 小结在本文中，笔者和大家一起理解了流批一体的起源，以及Flink社区在流批一体中做出的致力。此外，咱们也看到了有些问题并不是Flink这个框架能够解决的，须要整个大数据生态来一起演进，走向流批一体。 在文章的最初，感激余空同学的交换与领导，咱们一起写出了这篇文章。

作者：王东阳 前言状态在Flink中叫作State，用来保留两头计算结果或者缓存数据。依据是否须要保留两头后果，分为无状态计算和有状态计算。对于流计算而言，事件继续一直地产生，如果每次计算都是互相独立的，不依赖于上下游的事件，则是无状态计算。如果计算须要依赖于之前或者后续的事件，则是有状态计算。 在Flink中依据数据集是否依据Key进行分区，将状态分为Keyed State和Operator State（Non-keyed State）两种类型 ，本文次要介绍Keyed State，后续文章会介绍Operator State。 Keyed State 示意和key相干的一种State，只能用于KeydStream类型数据集对应的Functions和Operators之上。Keyed State是Operator State的特例，区别在于Keyed State当时依照key对数据集进行了分区，每个Key State仅对应一个Operator和Key的组合。Keyed State能够通过Key Groups进行治理，次要用于当算子并行度发生变化时，主动从新散布 Keyed State数据。在零碎运行过程中，一个Keyed算子实例可能运行一个或者多个Key Groups的keys。 依照数据结构的不同，Flink中定义了多种Keyed State，具体如下: ValueState<T> 即类型为T的单值状态。这个状态与对应的Key绑定，是最简略的状态。ListState<T>即Key上的状态值为一个列表。MapState<UK,UV> 定义与Key对应键值对的状态，用于保护具备key-value构造类型的状态数据。ReducingState<T>这种State通过用户传入的ReduceFucntion，每次调用add(T)办法增加元素时，会调用ReduceFucntion，最初合并到一个繁多的状态值。AggregatingState<IN,OUT> 聚合State和ReducingState<T>十分相似，不同的是，这里聚合的类型能够是不同的元素类型，应用add（IN）来退出元素，并应用AggregateFunction函数计算聚合后果。State开发实战本章节将通过理论的我的项目代码演示不同数据结构在不同计算场景下的开发方法。 本文中我的项目 pom文件ValueStateValueState<T> 即类型为T的单值状态。这个状态与对应的Key绑定，是最简略的状态。能够通过update(T)办法更新状态值，通过T value()办法获取状态值。 因为ValueState<T> 是与Key对应单个值的状态，利用场景能够是例如统计user_id对应的交易次数，每次用户交易都会在count状态值上进行更新。 接下来咱们将通过一个具体的实例代码展现如何利用ValueState去统计各个用户的交易次数。 ValueStateCountUser实现通过定义ValueState<Integer>类型的countState存储用户曾经拜访的次数，并在每次收到新的元素时，对countState中的数据加1更新，同时把以后用户名和曾经拜访的总次数返回。在本样例代码中将会通过 RichMapFunction 来对流元素进行解决。 在其中的 open(Configuration parameters) 办法中对 countState进行初始化。Flink提供了RuntimeContext用于获取状态数据，同时RuntimeContext提供了罕用的Managed Keyd State的获取形式，能够通过创立相应的StateDescriptor并调用RuntimeContext办法来获取状态数据。例如获取ValueState能够调用ValueState[T] getState(ValueStateDescriptor[T])办法。在 Tuple2<String, Integer> map(Tuple2<String, String> s)中，通过 countState.value() 获取用户之前的拜访次数，而后对countState中的数据加1更新，同时把以后用户名和曾经拜访的总次数返回。import org.apache.flink.api.common.functions.RichMapFunction;import org.apache.flink.api.common.state.ValueState;import org.apache.flink.api.common.state.ValueStateDescriptor;import org.apache.flink.api.java.tuple.Tuple2;import org.apache.flink.configuration.Configuration; public class ValueStateCountUser extends RichMapFunction<Tuple2<String, String>, Tuple2<String, Integer>> { private ValueState<Integer> countState; ...

前言：什么是 Flink CDC ？Flink CDC 是一个应用 Apache License 2.0 协定的开源我的项目，反对从 MySQL、MariaDB、RDS MySQL、Aurora MySQL、PolarDB MySQL、PostgreSQL、Oracle、MongoDB、SqlServer、TiDB、OceanBase 等数据库中实时地读取存量历史数据和增量变更数据，整个过程提供 exactly-once 语义保障。Flink CDC 同时提供了 SQL API 和 DataStream API 两套 API，很好地满足了不同开发者的需要。 作为新一代数据集成框架，Flink CDC 既能够代替传统的 DataX 和 Canal 工具做实时数据同步，将数据库的全量和增量数据一体化地同步到音讯队列和数据仓库中；也能够做实时数据集成，将数据库数据实时入湖入仓；同时还反对弱小的数据加工能力，能够通过 SQL 对数据库数据做实时关联、打宽、聚合，并将物化后果写入到各种存储中。绝对于其余数据集成框架，Flink CDC 具备全增量一体化、无锁读取、并发读取、分布式架构等技术劣势，在开源社区中十分受欢迎。 Flink CDC 我的项目地址： https://github.com/ververica/... 一、GitHub star 超过 2000自 2020 年 7 月份开源以来，Flink CDC 社区倒退迅速，在 GitHub 的关注度继续走高。回顾 Flink CDC 我的项目的倒退，在 2021 年 9 月初，Flink CDC 我的项目的 GitHub star 首次超过 1000，也是这个时候 Flink CDC 公布了 2.0 版本，正式进入大规模生产可用阶段，社区的倒退速度也犹如装上了减速引擎。 ...

摘要：本文整顿自汽车之家实时计算平台负责人邸星星在 Flink Forward Asia 2021 平台建设专场的演讲。次要内容包含： 利用场景估算资源管控Flink 伸缩容湖仓一体PyFlink 实际后续布局点击查看直播回放 & 演讲PDF 一、利用场景 咱们的利用场景与其余公司很相似，涵盖了实时指标统计、监控预警、实时数据处理、实时用户行为、实时入湖、实时数据传输这几个方面： 施行指标统计包含实时的流量剖析、车展大屏、818 实时大屏等，能够间接反对实时地查看重大流动的成果，不便及时调整经营策略；监控预警包含各个利用的后端日志剖析报警、利用的性能监控预警、C 端用户的视频播放品质监控预警，这也是实时计算很典型的利用场景。通过定义正当的告警策略，能够在第一工夫感知到外围零碎的问题，并联合实时的数据分析疾速定位问题；实时数据处理次要反对实时数仓建设、内容中台、电商中台等业务；实时用户行为次要依据用户在 APP 上的各种行为来记录用户的画像及特色，这部分利用的成果最终会间接晋升用户体验。典型的场景就是智能举荐，咱们会联合用户最近感兴趣的内容，来为用户实时举荐文章、小视频等优质资源，晋升用户的应用体验；实时入湖是咱们往年在平台建设方面重点发力的方向。咱们落地的湖仓一体架构相比齐全基于 Hive 的架构，在很多方面都有晋升。目前曾经在多个主题落地，晋升成果也比较显著；最初是根底的实时数据传输场景，用户能够将业务库或 Kafka 中的数据便捷地散发到多种存储引擎中应答不同的业务需要，比方散发到 ES 中反对疾速检索。 咱们最早是应用 Storm平台，基于 Spout、Bolt 开发模型，实现了根底的实时计算开发，这个阶段是齐全基于 Java 编码方式实现开发，开发门槛及学习老本都比拟高。 第二阶段，咱们在 18、19 年引入 Flink，并建设了 AutoStream 1.0 平台。这个阶段咱们次要的指标是提效、升高开发门槛和学习老本。将之前纯 Java 开发方式转变为基于 SQL + UDF 的开发方式。因为 Flink 晚期还不反对 DDL，所以咱们很大一部分工作就是建设本人的 meta server，并通过 DDL 定义 source sink 组件，同时欠缺业务库数据的实时接入，并将公司外部罕用的存储引擎集成到平台上，实现整个实时开发链路的买通。 第三阶段，咱们将 Flink 降级到 1.9 版本，并将平台降级为 AutoStream 2.0 版本，反对原生 DDL，同时反对自助上传 UDF，简化了 UDF 应用流程。同时随着工作数及平台用户的减少，咱们的日常 on call 工夫也随之减少，所以咱们上线了工作的衰弱评分机制，从多个方面剖析工作的衰弱度，帮忙用户理解工作能够优化的点并附带解决方案。咱们还上线了在线诊断性能，反对动静批改日志级别，查看线程栈和火焰图，晋升用户定位问题的效率，同时也升高了咱们平台方的日常 on call 老本。 ...

摘要：本文整顿自阿里巴巴技术专家高赟 (云骞) 在 Flink Forward Asia 2021 核心技术专场的演讲。次要内容包含： 流批一体语义欠缺与加强性能优化Remote Shuffle总结与瞻望点击查看直播回放 & 演讲PDF 一、流批一体 流批一体的指标是心愿可能为无限数据和有限数据提供一套对立的解决 API，包含 Datastream API 与 Table/SQL API，其中无限数据的解决对应离线解决，而有限数据的解决则对应在线解决。 之所以须要这么一套流批一体的解决 API，次要有以下两个起因： 首先，随着实时计算的一直倒退，大多数企业数据处理的 pipeline 都是由离线解决和在线解决组成的，应用同一套开发 API 就能够缩小流解决和批处理作业开发过程中的学习与保护的老本；另外，在许多场景下，用户的流解决作业可能受限于提早数据或者线上逻辑变更的状况，例如用户可能会过很长时间才会发动评论或线上解决的逻辑可能须要进行降级，这种状况下就须要应用离线作业对之前解决的后果进行修改，即 backfill 的状况。这种状况下如果应用两套不同的 API 会很难保护处理结果的一致性，因而用户须要一套对立的 API 来解决上述问题。 Flink 流批一体的 API 由 Datastream API 与 Table/SQL API 两局部组成，其中 Table/SQL API 是绝对比拟 high level 的 API，次要提供规范的 SQL 以及与它等价的 table 操作，datastream 则绝对 low level，用户能够显式地操作算子 time 和 state，这两套 API 能够相互转换联合应用。 针对两套 API，Flink 提供了两种不同的执行模式： 其中流执行模式是通过保留算子的 state 等新数据达到的时候进行增量计算来实现的。它能够同时用于无限数据集和有限数据集的解决，能够反对任意解决逻辑，比方 salt 操作，它容许保留所有历史数据并反对 retraction，当一条新数据达到时，就能够更新保留的历史数据并对历史上收到的所有数据进行从新排序，最初对之前发送的后果进行 retraction 来实现。比方 reduce 算子，能够进一步优化来防止理论存储无限大的历史状态。另外增量计算中，因为数据达到时是无序的，因而它对 sql 的拜访也是无序的，从而可能导致随机 io。最初，流解决模式依赖于定时 checkpoint 来反对 failover，这种状况也会导致肯定的解决开销。因而对于无限数据集的解决，咱们也提供了专用的批处理模式，算子通过逐级运算的形式来解决，因而只能用于无限数据的解决。这种状况下算子实现能够进行特定的优化，比方对数据先进行排序，而后按 key 进行一一解决，从而防止无限大的状态随机 io 的问题。Flink 可能保障，在两种执行模式下，雷同的无限输出数据的处理结果能够保持一致。此外，它对两种不同的模式也提供了对立的 pipelined region 调度器、对立的 shuffle service 插件接口以及对立的 connector 接口，为两种接口提供了对立的反对。 ...

摘要：本篇内容整顿自中信建投证券金融实时数仓我的项目负责人刘成龙、金融资讯数据研发工程师蔡跃在 Flink Forward Asia 2021 行业实际专场的演讲。次要内容包含： 中信建投证券 Flink 框架Flink 流解决场景金融资讯实时化革新将来瞻望点击查看直播回放 & 演讲PDF 中信建投证券公司成立于 2005 年，2016 年港交所上市，2018 年上交所主板上市。投行业务间断 8 年放弃行业前 3，托管证券规模行业第 2，次要经营指标目前均列于行业前 10。随同着公司的业务一路高歌猛进，技术方面也不容落后，数字化转型正在成为咱们近些年来的倒退重点。 因为金融行业波及的业务畛域泛滥，公司多年来积攒了大量简单的与业务高度相干的根底数据，在发现问题、剖析问题，解决问题的过程中，如何协调业务前、中、后盾以及科技部门等多方面配合来开展业务口径的梳理与加工逻辑的开发，成为目前亟待解决的关键问题。 一、中信建投证券 Flink 框架 数据中台架构如图所示。次要分为以下几大板块：由 Greenplum 数据仓库和 Hadoop 大数据平台形成的数据中心板块；以离线开发、实时开发、数据交换为主的数据开发板块；以及数据门户、数据网关、数据治理、经营治理等板块形成。 其中数据开发板块目前的工作次要以离线开发与数据交换的离线数据处理为主。但随着业务对数据时效性的进步，基于离线批处理的 t+1 业务模式曾经无奈齐全满足以后市场环境下对信息及时性的需要，这也是大力发展实时开发，力求为客户提供更高时效性数据服务的目标。 咱们以实时开发整个链路为例，对数据中台各个板块间的互相联动进行阐明。 从数据门户对立入口进入实时开发模块，首先将集中交易、融资融券等业务信息的实时增量数据拉取到 Kafka 音讯队列，Flink 生产 Kafka 实时流数据并与维表数据进行数据加工。加工逻辑中波及的维表数据量比拟大时，须要离线开发与数据交换，通过离线跑批的形式实现对维表的数据筹备。最初将后果数据写入关系型数据库或 NoSQL 数据库。数据网关再通过读取后果数据生成 API 接口，对上游的零碎提供数据服务。 数据治理板块中的数据管控模块次要治理数据中台的数据库表以及业务相干的数据库表的元数据，用户能够在数据门户订阅他们所关注数据库表的变更信息。当订阅的数据表产生了变动的时候，经营核心能够通过对立告警模块，多渠道告诉订阅用户数据库表的变更状况，以便于开发人员及时调整数据加工的工作。 Flink 实时流解决架构首先通过 Attunity 工具采集业务数据库的 CDC 日志，将同一零碎下的数据库表变动写入 Kafka 的一个 topic 队列中，这也就意味着 Kafka 的每一个 topic 中都会有多个表的数据，所以在 Flink 的 Kafka source 要先对 schema 和 tablename 这两个字段进行一次过滤，获取想要拿到的数据表的 CDC 数据流，再进行后续与维表的加工逻辑。将解决后的数据写入后果表，依据需要不同写入不同的数据库进行存储。 ...

调度器是 Flink 作业执行的外围组件，治理作业执行的所有相干过程，包含 JobGraph 到 ExecutionGraph 的转换、作业生命周期治理（作业的公布、勾销、进行）、作业的 Task 生命周期治理（Task 的公布、勾销、进行）、资源申请与开释、作业和 Task 的 Failover 等。调度有几个重要的组件： 调度器：SchedulerNG 及其子类、实现类 调度策略：SchedulingStrategy 及其实现类 调度模式：ScheduleMode 蕴含流和批的调度，有各自不同的调度模式 1、调度器 调度器作用： 1）作业的生命周期治理，如作业的公布、挂起、勾销 2）作业执行资源的申请、调配、开释 3）作业的状态治理，作业公布过程中的状态变动和作业异样时的 FailOver 等 4）作业的信息提供，对外提供作业的详细信息 看一下源码构造： SchedulerNG.java public interface SchedulerNG { void setMainThreadExecutor(ComponentMainThreadExecutor mainThreadExecutor); void registerJobStatusListener(JobStatusListener jobStatusListener); void startScheduling(); void suspend(Throwable cause); void cancel(); CompletableFuture<Void> getTerminationFuture(); void handleGlobalFailure(Throwablecause); default boolean updateTaskExecutionState(TaskExecutionState taskExecutionState) { return updateTaskExecutionState(new TaskExecutionStateTransition(taskExecutionState)); } boolean updateTaskExecutionState(TaskExecutionStateTransition taskExecutionState); SerializedInputSplitrequestNextInputSplit(JobVertexID vertexID, ExecutionAttemptIDexecutionAttempt) throws IOException; ExecutionState requestPartitionState(IntermediateDataSetIDintermediateResultId, ResultPartitionID resultPartitionId) throws PartitionProducerDisposedException; void scheduleOrUpdateConsumers(ResultPartitionID partitionID); ArchivedExecutionGraph requestJob(); JobStatus requestJobStatus(); JobDetails requestJobDetails(); }实现类：DefaultScheduler（1.11 移除了 LegacyScheduler） ...

作者:王东阳前言ANSI-SQL 2011 中提出了Temporal 的概念，Oracle，SQLServer，DB2等大的数据库厂商也先后实现了这个规范。Temporal Table记录了历史上任何工夫点所有的数据改变，Temporal Table具备一般table的个性，有具体独特的DDL/DML/QUERY语法，工夫是其外围属性。历史意味着工夫，意味着快照Snapshot。 Apache Flink遵循ANSI-SQL规范，Apache Flink中Temporal Table的概念也源于ANSI-2011的规范语义，但目前的实现在语法层面和ANSI-SQL略有差异，下面看到ANSI-2011中应用FOR SYSTEM_TIME AS OF的语法，Apache Flink在晚期版本中仅仅反对 LATERAL TABLE(TemporalTableFunction)的语法，以后flinkv14版本中曾经反对FOR SYSTEM_TIME AS OF语法。 因为Flink中基于eventtime 的 temporal table join 基于flink 的watermark机制实现，为了更好的让读者了解，本文首先介绍flink中的 动静表和时序表，工夫概念，Watermark等相干常识，最初通过具体的代码用例介绍Flink中基于eventtime 的 temporal table join用法。 动静表和时序表动静表什么是动静表动静表 是 Flink 的反对流数据的 Table API 和 SQL 的外围概念。与示意批处理数据的动态表不同，动静表是随工夫变动的。能够像查问动态批处理表一样查问它们。查问动静表将生成一个 间断查问 。一个间断查问永远不会终止，后果会生成一个动静表。查问不断更新其(动静)后果表，以反映其(动静)输出表上的更改。实质上，动静表上的间断查问十分相似于定义物化视图的查问。 动静表能够像一般数据库表一样通过 INSERT、UPDATE 和 DELETE 来一直批改。它可能是一个只有一行、不断更新的表，也可能是一个 insert-only 的表，没有 UPDATE 和 DELETE 批改，或者介于两者之间的其余表。 动静表转换在将动静表转换为流或将其写入内部零碎时，须要对这些更改进行编码。Flink的 Table API 和 SQL 反对三种形式来编码一个动静表的变动: Append-only 流： 仅通过 INSERT 操作批改的动静表能够通过输入插入的行转换为流。Retract 流： retract 流蕴含两种类型的 message： add messages 和 retract messages 。通过将INSERT 操作编码为 add message、将 DELETE 操作编码为 retract message、将 UPDATE 操作编码为更新(先前)行的 retract message 和更新(新)行的 add message，将动静表转换为 retract 流。下图显示了将动静表转换为 retract 流的过程。 ...

摘要：本文整顿自挪动软件开发工程师谢磊在 Flink Forward Asia 2021 平台建设专场的演讲。本篇内容次要分为四个局部： 实时计算平台建设中移信令业务优化稳定性实际将来方向的摸索点击查看直播回放 & 演讲PDF 中移（苏州）软件技术有限公司是中国移动通信有限公司的全资子公司，公司定位为中国移动云设施的构建者、云服务的提供者、云生态的绘制者。公司以挪动云为经营核心，产品和服务在电信、政务、金融、交通等畛域都有广泛应用。 一、实时计算平台介绍 实时计算引擎在挪动云的演进分为几个阶段： 2015 年到 16 年，咱们应用的是第一代实时计算引擎 Apache Storm；17 年咱们开始调研 Apache Spark Streaming，它能够与自研框架进行整合，升高了运维压力和保护老本；18 年，用户对云计算的需要越来越多，Storm 和 Spark曾经无奈很好地满足业务。同时咱们钻研了流计算比拟闻名的几篇文章，发现 Apache Flink 曾经比拟残缺地具备了文中提到的一些语义；19 年 - 20 年，咱们开始实现云服务，并把实时计算平台上线至私有云和公有云；20 年 - 21 年，咱们开始调研实时数仓，并将 LakeHouse 上线挪动云。 目前 Flink 次要用于中移信令数字的解决、实时用户画像和埋点、实时数仓、实时运维监控、实时举荐以及挪动云的数据管道服务。 中移的实时计算平台性能分为三大部分。 第一局部是服务治理，反对了工作生命周期的托管、Flink 和 SQL 作业、Spark Streaming 作业以及引擎多版本的反对；第二局部是 SQL 的反对，提供了在线 Notebook 编写、SQL 语法检测、UDF 治理和元数据管理；第三局部是工作运维，反对实时工作的日志检索、实时性能指标采集以及音讯提早报警和工作反压报警等。本文次要分享两个外围设计：引擎多版本的设计和实时工作日志检索。 在日常有工作场景中，咱们发现用户程序调试老本比拟高，用户尝试新版本引擎的周期也比拟长，此外无奈躲避用户 hack 引擎的性能以及有些工作运行失败然而没有异样信息，因而咱们引入了引擎多版本设计。 多版本提交的流程如下：用户的工作首先会提交到 rtp 服务，rtp 服务将用户程序上传到 HDFS 保留，须要提交的时候再从 HDFS 拉回来提交到 Yarn 集群。此类工作存在一个共性——作业中蕴含 Apache Flink 的外围包，这会导致很多问题。 ...

文末有官网的残缺的HBasesink代码; Flink自定义sink端自定义sink次要有二种实现形式,一种是实现RichSinkFunction和SInkFuncion 如果要实现Checkpointed还须要实现CheckpointedFunction接口 举荐应用RichSinkFunction全生命周期函数 HBaseSink的实现简略版 实现RichSinkFunction 但不具备通用性,没对一个源就须要批改代码,且没有提供构建办法,开始本人写的一个版本 import org.apache.flink.configuration.Configuration;import org.apache.flink.streaming.api.functions.sink.RichSinkFunction;import org.apache.hadoop.hbase.HBaseConfiguration;import org.apache.hadoop.hbase.TableName;import org.apache.hadoop.hbase.client.*;import org.apache.hadoop.hbase.util.Bytes;import org.slf4j.Logger;import org.slf4j.LoggerFactory; import java.io.IOException; /** * @author WangKaiYu * @date 2022-02-18 15:19 */ public class HbaseSink extends RichSinkFunction<String>{ private final static Logger logger = LoggerFactory.getLogger(HbaseSink.class); private static org.apache.hadoop.conf.Configuration configuration; private static Connection connection= null; private static BufferedMutator mutator; private static String Tablename="student"; @Override public void open(Configuration parameters) throws Exception { configuration=HBaseConfiguration.create(); configuration.set("hbase.master", "192.168.10.154:16000"); configuration.set("hbase.zookeeper.quorum", "192.168.10.154,192.168.10.155,192.168.10.196"); configuration.set("hbase.zookeeper.property.clientPort", "2181"); try {// asyncConnection = ConnectionFactory.createAsyncConnection(configuration); connection = ConnectionFactory.createConnection(configuration);// connection.getBufferedMutator(TableName.valueOf(Tablename).) }catch (Exception e){ e.printStackTrace(); } BufferedMutatorParams params = new BufferedMutatorParams(TableName.valueOf(Tablename)); //缓存大小 params.writeBufferSize(2*1024*1024); //最大工夫 params.setWriteBufferPeriodicFlushTimeoutMs(5 * 1000L);// AsyncConnection asyncConnection = HbaseSink.asyncConnection.get(); try { mutator = connection.getBufferedMutator(params); }catch (IOException e){ logger.error("以后获取bufferedMutator 失败：" + e.getMessage()); } } @Override public void close() throws Exception { if (mutator != null) { mutator.close(); } if (connection != null) { connection.close(); } } @Override public void invoke(String value, Context context) throws Exception { String familyName = "info"; String[] values = value.split(","); Put put = new Put(Bytes.toBytes(values[0])); put.addColumn(Bytes.toBytes(familyName),Bytes.toBytes("name"),Bytes.toBytes(values[1])); put.addColumn(Bytes.toBytes(familyName),Bytes.toBytes("age"),Bytes.toBytes(values[2])); mutator.mutate(put); // 指定工夫内的数据强制刷写到hbase mutator.flush(); }}源码介绍1，次要类介绍 ...

摘要：本篇内容整顿自联通大数据技术专家穆纯进在 Flink Forward Asia 2021 平台建设专场的演讲。次要内容包含： 实时计算平台背景实时计算平台演进与实际基于 Flink 的集群治理将来布局FFA 2021 直播回放 & 演讲 PDF 下载 一、实时计算平台背景 首先理解一下实时计算平台的背景。电信行业的业务零碎非常复杂，所以它的数据源也是十分多的，目前实时计算平台接入了 30 多种数据源，这 30 多种数据源绝对于总的数据品种来说是比拟小的。即便这样，咱们的数据量也达到了万亿级别，每天有 600TB 的数据增量，而且咱们接入的数据源品种和大小还在持续增长。平台的用户来自于全国 31 个省份公司以及联通团体的各个子公司，尤其是在节假日会有大量用户去做规定的订阅。用户想要获取数据，须要在平台上进行订阅，咱们会将数据源封装成标准化的场景，目前咱们有 26 种标准化场景，撑持了 5000 多个规定的订阅。 订阅场景有三大类。 用户行为类的场景有 14 个，比方地位类的场景，是对于用户进入某个区域后停留了多长时间，还有终端登网，是对于用户连贯了哪个网络，4G 还是 5G 网，以及漫游、语音、产品订购等各种场景；用户应用类的场景有 6 个，比方用户应用了多少流量、账户余额是多少、是否有欠费停机等；用户触网类的场景大略有 10 个，比方业务的办理、充值缴费，还有新入户入网等。 对于实时计算平台来说，实时性的要求是很高的。数据从产生到进入咱们的零碎，大略有 5~20 秒的提早，通过零碎失常解决之后大略有 3~10 秒的提早，咱们容许的最大提早是 5 分钟，所以必须做好实时计算平台端到端的提早的监控。 用户定义的场景符合要求的数据起码要下发一次，这个是有严格要求的，不能漏发，而 Flink 很好地满足了这个需要；数据的准确性要求须要达到 95%，平台实时下发的数据会保留一份到 HDFS 上，每天咱们会抽取局部订阅和离线数据，依照雷同的规定进行数据生成以及数据品质比对，如果差别过大就须要找到起因并保障后续下发数据的品质。 本次分享更多的是 Flink 在电信行业的一次企业的深度实际：如何应用 Flink 更好地撑持咱们的需要。 通用的平台无奈撑持咱们的非凡场景，比方以地位类的场景为例，咱们会在地图上画多个电子围栏，当用户进入围栏并在围栏外面停留一段时间，并且满足用户设定性别、年龄、职业、支出等用户特色，这样的数据才进行下发。 咱们的平台能够认为是一个实时场景中台，将数据进行实时的荡涤解决，封装成反对多个条件组合的简单场景，集约化地提供规范实时能力的同时，更进一步凑近业务，提供给业务方简略易用、门槛很低的接入形式。业务方通过调用标准化的接口，通过网关认证鉴权，才能够订阅咱们的场景。订阅胜利之后会将 Kafka 的一些连贯信息和数据的 Schema 返回给订阅用户，用户订阅的筛选条件跟数据流进行匹配，匹配胜利之后会以 Kafka 的模式再进行数据下发。以上就是咱们的实时计算平台与上游零碎交互的流程。 二、实时计算平台演进与实际 ...

所谓Catalog即数据目录，简略讲，Catalog是企业用于治理数据资产的形式，Catalog借助元数据来治理数据，包含数据收集、组织、拜访、发现和治理。可见，Catalog在数据资产治理中处于外围地位。元数据自身内容十分丰盛，包含技术元数据、业务元数据和操作元数据，本文仅仅钻研大数据计算存储框架自身的技术元数据，比方数据库、数据表、分区、视图、函数等。限于篇幅，参加比拟的计算存储框架为Flink、Iceberg和Hive，比拟维度为Catalog的定义、Catalog的实现和生态拓展几个方面。 Catalog接口定义 1 Flink Catalog 从Flink Catalog的接口定义来看，Flink Catalog提供了根本的数据库、数据表、函数、视图、分区的增删改查基本操作。 2 Iceberg Catalog 从Iceberg Catalog的接口定义来看，Iceberg Catalog提供了根本的表创立、表替换、表删除、表改名和表加载、查问等操作。在对外接口参数中，Iceberg应用TableIdentifier来标识一个表，TableIdentifier外部又蕴含一个Namespace。在Iceberg中，一个表的残缺标识组成为： TableIdentifier=Namespace+table，其中Namespace是一个字符串数组，反对多层级的表润饰，第0层为table，第1层为database。 3 Hive Catalog Hive Catalog在3.x版本以前没有Catalog 的概念，尔后的版本中才勉强在Metastore中加上了一张表，专门存储Catalog，从Hive Catalog的类定义中可见，申明是相当简略的： private String name; // required privateString description; // optional privateString locationUri; // required其中locationUri指定了Catalog所属的数据存储门路，该属性必填。 小结 通过Catalog定义来看，Flink Catalog性能绝对欠缺，Iceberg Catalog跟Flink Catalog相比，没有明确的对数据库相干的操作，而且也没有像Flink Catalog那样明确的表的全名称（如用database.table来标识一个表）润饰概念，而是将表的标识概念泛化。相比Flink、Iceberg的 Catalog，Hive Catalog显得”后知后觉“，因为Hive晚期设计是基于database和table两级命名来实现，也没有思考到以后蓬勃发展的联邦查问场景。 Catalog实现 1 Flink Catalog Flink Catalog的实现有两种：Hive Catalog和Memory Catalog。两者都继承形象的AbstractCatalog，区别是前者借助HMS来治理元数据，后者基于内存治理，Flink Job进行之后，这些数据会失落，须要重建。 2 Iceberg Catalog Iceberg Catalog的实现类有4种，Hive Catalog、Hadoop Catalog、CacheCatalog和JDBC Catalog。它们都继承抽象类BaseMetastoreCatalog。Hive Catalog将表的元数据信息存储在Hive Metastore，为了兼容HMS，Namespace必须蕴含table和database。 Hadoop Catalog将表的元数据信息存储在Hadoop之上，因为Hadoop反对存算拆散，因而底层的数据文件能够是HDFS或者是S3这样的对象零碎，对Hadoop Catalog来讲，定位一个表的地位，只须要提供表的门路即可，因为表的元信息都存储在文件中，比方TableIdentifier为["test_table","test_db","test_nm1","test_nm2"]的表全门路为: ...

摘要：本文整顿自 Apache Flink 引擎架构师、阿里巴巴存储引擎团队负责人梅源在 Flink Forward Asia 2021 核心技术专场的演讲。本次演讲内容围绕 Flink 的高可用性探讨 Flink 新一代流计算的外围问题和技术选型，包含： Flink 高可用流计算的要害门路容错 (Fault Tolerance) 2.0 及关键问题数据恢复过程稳固疾速高效的 Checkpointing云原生下容错和弹性扩缩容FFA 2021 直播回放 & 演讲 PDF 下载 一、高可用流计算的要害门路 上图的双向轴线是大数据利用随时间延迟的图谱，越往右边时间延迟要求越短，越往左提早要求没那么高。Flink 诞生之初大略是在上图两头，能够了解为往右对应的是流式计算，而往左边对应的是批式计算。过来一两年，Flink 的利用图谱向右边有了很大的扩大，也就是咱们常说的流批一体；与此同时咱们也素来没有进行过把图谱向更实时的方向推动。 Flink 是以流式计算起家，那么向更实时的方向推动到底是指什么？什么是更实时更极致的流式计算？ 在失常解决的状况下，Flink 引擎框架自身除了定期去做 Checkpoint 的快照，简直没有其余额定的开销，而且 Checkpoint 快照很大一部分是异步的，所以失常解决下 Flink 是十分高效的，端到端的提早在 100 毫秒左右。正因为要反对高效的解决，Flink 在做容错复原和 Rescale 的时候代价都会比拟大：须要把整个作业停掉，而后从过来的快照检查点整体复原，这个过程大略须要几秒钟，在作业状态比拟大的状况下会达到分钟级。如果须要预热或启动其余服务过程，工夫就更长了。 所以，Flink 极致流计算的关键点在容错复原局部。这里说的极致的流计算是指对提早性、稳定性和一致性都有肯定要求的场景，比方风控平安。这也是 Fault Tolerance 2.0 要解决的问题。 二、容错 (Fault Tolerance) 2.0 及关键问题 容错复原是一个全链路的问题，包含 failure detect、job cancel、新的资源申请调度、状态复原和重建等。同时，如果想从已有的状态复原，就必须在失常处理过程中做 Checkpoint，并且将它做得足够轻量化才不会影响失常解决。 容错也是多维度的问题，不同的用户、不同的场景对容错都有不同需要，次要包含以下几个方面： 数据一致性 (Data Consistency)，有些利用比方在线机器学习是能够容忍局部数据失落；提早 (Latency)，某些场景对端到端的提早要求没那么高，所以能够将失常解决和容错复原的时候要做的工作综合均匀一下；复原时的行为表现 (Recovery Behavior)，比方大屏或者报表实时更新的场景下，可能并不需要迅速全量复原，更重要的在于迅速复原第一条数据；代价 (Cost)，用户依据本人的需要，违心为容错付出的代价也不一样。综上，咱们须要从不同的角度去思考这个问题。另外，容错也不仅仅是 Flink 引擎侧的问题。Flink 和云原生的联合是 Flink 将来的重要方向，咱们对于云原生的依赖形式也决定了容错的设计和走向。咱们冀望通过非常简单的弱依赖来利用云原生带来的便当，比方 across region durability，最终可能将有状态的 Flink 的利用像原生的无状态利用一样弹性部署。 ...

摘要：本篇内容整顿自美团数据平台工程师冯斐、王不凡在 Flink Forward Asia 2021 的演讲。次要内容包含： 相干背景大作业部署优化Checkpoint 跨机房正本状态稳定性相干优化将来布局FFA 2021 直播回放 & 演讲 PDF 下载 一、相干背景 美团 Flink 的利用场景笼罩了社区定义的三种场景： 利用比拟多的是数据管道场景，比方数仓 ODS 层数据的实时接入，或跨数据源的实时数据同步；比拟典型的利用场景是数据分析，比方实时数仓的建设和利用，业务会出一些实时报表和大盘辅助业务做决策，或者计算一些实时特色服务于业务生产；事件驱动场景，目前次要利用于平安风控、系统监控告警。 随着业务的倒退和实时计算的迭代，业务对实时计算的利用越来越宽泛，也越来越深刻。以后咱们有将近 5 万个作业部署在超过 15,000 台机器上，高峰期解决的流量达到了 5.4 亿条/秒，这几个指标相比今年都有了很大的增长。除了整体的规模增长，往年咱们也遇到了单作业规模大幅增长的状况，目前咱们的大作业并发度达到 5000，状态达到了 10 TB。单作业规模的增长也给咱们带来了新的问题和挑战。 首先是作业启动的问题。以往在小规模作业上不那么显著的问题，在大作业部署启动流程中裸露了进去，比方 Task 启动慢部署慢、散布不均，大作业对 HDFS 的影响等。另外在状态方面，状态很大的时候同样给作业带来了不可疏忽的影响，次要是 Savepoint 的制作开销和复原效率，以及状态的容灾等问题。 二、大作业部署优化 咱们以后的大作业算子并发达到了 5000，拓扑复杂度上算子数量达到了 8000，有两层的数据 shuffle 替换，资源上作业须要超过 1000 个 TaskManager，在这样的规模下，咱们遇到了一些之前没有遇到过的问题。 首先，部署大量 Task 的时候会遇到部署工夫长或因为 RPC 超时而部署失败的问题；此外，Task 散布不够正当，局部 TaskManager 中 Network Buffer 的数量有余，会导致作业启动失败；另外，大作业做 Checkpoint 期间，会给 HDFS 带来刹时压力，也会影响其余作业应用 HDFS。 针对上述问题咱们进行了以下优化： 咱们首先剖析了 JobManager 视角的作业部署流程，心愿能搞清楚各个环节有哪些因素影响部署，以及他们是如何影响部署的，而后隔靴搔痒去解决问题。 能够看到，从收到 JobGraph 到启动所有 Task，次要环节有构建执行图、申请资源、部署 Task、启动 Task 这几个步骤。 ...

摘要：本文整顿自新加坡国立大学计算机系博士在读生毛言粲在 Flink Forward Asia 2021 核心技术专场的分享。次要内容包含： 背景：流作业动静调控挑战：兼顾普适、高效和易用设计：以 Task 为核心的零碎设计实现：基于 Flink 的 Barrier 机制评估：Trisk 与已有零碎的性能比照FFA 2021 直播回放 & 演讲 PDF 下载 一、背景：流作业动静调控 流数据处理是十分重要的一种数据处理形式，它在各个领域都有宽泛的利用，比方机器学习、数据分析和实时事件处理以及实时交易等畛域。流解决领有低提早和高吞吐量的个性，它被大规模部署成以流工作实例 stream task 形成的流作业 stream job 并行处理输出的数据流，流作业会部署成并行的流工作，这些流工作实例被两头流连贯，并造成一个有向无环图。 流数据的并行处理是通过将输出数据在并行任务之间进行分区，而后每个工作独立解决调配的分区工作实时实现的，因为流作业是长期执行且会随着工夫抖动，而不同的流作业有不同的性能需求，比方实时交易工作对提早很敏感，而一些数据分析的工作对吞吐量要求很高。为了达到不同流解决作业的性能要求，动静重配置流工作的技术很要害。 常见的数据抖动有如下几类： 第一，输出速率的变动。流作业是长期执行，而数据流的输出速率会不可预测地产生动态变化，导致动态调配的资源无奈低提早高吞吐地解决数据流；第二，数据歪斜。流数据的数据分布会动态变化，比方某个数据的呈现频率增大会导致对应 stream task 的工作负载变大，提早变大；第三，新兴事件的产生。流数据中可能会呈现新兴事件或者数据，这种数据无奈被以后执行逻辑正确地执行。比方新型欺骗交易须要通过新的规定能力检测到。 针对不同的数据抖动，有不同类型的重配置技术来优化流作业，从而在保障资源利用率的同时，以高吞吐低延时的性能来解决流数据。 针对输出数列的变动，能够通过 scaling 的形式动静伸缩资源，进步吞吐量、升高提早；针对数据歪斜，能够通过 load balancing 的形式来从新散布并行执行流工作之间的工作负载，以从新达到负载平衡；对于新兴事件的解决，能够通过 change of logic 的形式来更新流工作的执行逻辑，从而能够正确地解决新兴事件和数据。 有了不同类型的数据抖动和重配置技术后，须要思考下一个问题就是如何动静地检测数据抖动，并抉择适合的办法来调控流工作。为了解决这个的问题，通常是通过设计一个控制器来对工作进行动静重配置，控制器次要通过实时监听流作业剖析症状，而后针对不同的症状批改不同的流作业配置，来做性能优化。 这个过程分为三步：监听、诊断、重配置。 首先控制器能够实时监听流工作，目前流作业的控制器次要通过监听系统层面的metrics比方CPU utilization，或利用层面的metrics比方端到端的数据处理提早、吞吐量积压等，来进行建模剖析和策略判断；而后控制器通过控制策略来诊断症状，控制策略能够通过预约义的规定，比方CPU利用率高于肯定阈值就执行scaling out，或进行模型剖析，比方预测须要达到的资源分配来诊断存在的问题；最初控制器抉择不同类型的重配置办法去动静优化流作业。 为了缩小为不同流作业实现控制器的工程开销，须要有一个管制平台来对流作业进行托管。管制平台封装了 metrics 和重配置办法，并且对外提供相应的 API，从而开发者能够在流作业部署好之后通过在管制平台提交控制器，对流作业进行托管。这样的控制器也蕴含了自定义的控制策略，并且能够间接应用管制平台的 API 实现 metrics 的采集和重配置，暗藏了零碎底层的解决逻辑，简化了控制器的设计和开发。 大部分流解决零碎都封装了比拟成熟的 metrics 零碎，因而管制平台能够基于原有零碎 API 实现 metrics 的采集，然而动静重配置的反对仍是一个较大的挑战。 二、挑战：兼顾普适、高效和易用 动静重配置的管制平台该当具备三种性质： 普适性，不同类型的控制策略须要应用不同类型的重配置办法；高效性，重配置的执行应在短时间内实现，并且尽量不阻塞原数据处理；易用性，API 应简略易用，用户调用时无需晓得零碎底层逻辑。 ...

摘要：本文整顿自 ASF Member、Apache Flink & HBase PMC、阿里巴巴资深技术专家李钰 (绝顶)，Apache Flink Committer、阿里巴巴技术专家唐云 (茶干) 在 Flink Forward Asia 2021 核心技术专场的演讲。次要内容包含： State Backend ImprovementSnapshot ImprovementFuture WorkFFA 2021 直播回放 & 演讲 PDF 下载 一、State Backend improvement在过来一年中，Flink 社区 state-backend 模块有了很大的倒退。在 1.13 版本之前，用户对于状态相干算子的性能不足监控伎俩，也没有很好的方法能够获悉状态读写操作的提早。 咱们引入了状态拜访的延时监控，原理就是在每次状态拜访前后，应用 system.nowTime 去统计拜访延时，而后将其存储在一个 histgram 类型的指标中，监控性能关上对其性能的影响，尤其是 state 拜访的性能影响是比拟小的。 对于状态拜访提早监控相干的配置，须要特别强调的是采样距离和保留历史数据这两个配置，采样距离越小，数据后果就越精确，然而对日常拜访的性能影响也稍大一些；历史数据保留的个数越多，数据后果越准确，然而内存占用也会稍大一些。 在 Flink 1.14 版本中，咱们终于将 RocksDB 从 5.17 降级到 6.20 版本，除了 RocksDB 本身若干 bug 的修复，新版 RocksDB 也减少了一些个性，能够用于 Flink 1.14 和 1.15 中。首先它反对了 ARM 平台，能够保障 Flink 作业可能在 arm 根底上运行，其次提供了更细粒度的 WriteBuffer 内存管控，晋升内存管控的稳定性。此外，还提供了 deleteRange 接口，为之后在扩容场景下的性能晋升带来十分大的帮忙。 ...

一、CDC 简介 CDC 是 Change Data Capture(变更数据获取)的简称。核心思想是，监测并捕捉数据库的变动（包含数据或数据表的插入、更新以及删除等），将这些变更按产生的程序残缺记录下来，写入到消息中间件中以供其余服务进行订阅及生产。 CDC 次要分为基于查问和基于 Binlog 两种形式，咱们次要理解一下这两种之间的区别： Flink 社区开发了 flink-cdc-connectors 组件，这是一个能够间接从 MySQL、PostgreSQL 等数据库间接读取全量数据和增量变更数据的 source 组件。目前也已开源，开源地址：https://github.com/ververica/... 二、Flink DataStream 形式利用的案例实操 在 pom.xml 中减少如下依赖<dependencies> <dependency> <groupId>org.apache.flink</groupId> <artifactId>flink-java</artifactId> <version>1.12.0</version> </dependency> <dependency> <groupId>org.apache.flink</groupId> <artifactId>flink-streaming-java_2.12</artifactId> <version>1.12.0</version> </dependency><dependency> <groupId>org.apache.flink</groupId> <artifactId>flink-clients_2.12</artifactId> <version>1.12.0</version> </dependency><dependency> <groupId>org.apache.hadoop</groupId> <artifactId>hadoop-client</artifactId> <version>3.1.3</version> </dependency><dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <version>5.1.49</version> </dependency><dependency> <groupId>com.alibaba.ververica</groupId> <artifactId>flink-connector-mysql-cdc</artifactId> <version>1.2.0</version> </dependency> <dependency> <groupId>com.alibaba</groupId> <artifactId>fastjson</artifactId> <version>1.2.75</version> </dependency></dependencies> <build> <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-assembly-plugin</artifactId> <version>3.0.0</version><configuration><descriptorRefs> <descriptorRef>jar-with-dependencies</descriptorRef> </descriptorRefs> </configuration> <executions><execution> <id>make-assembly</id> <phase>package</phase><goals> <goal>single</goal> </goals> </execution> </executions> </plugin> </plugins> </build>编写代码import com.alibaba.ververica.cdc.connectors.mysql.MySQLSource;import com.alibaba.ververica.cdc.debezium.DebeziumSourceFunction;import com.alibaba.ververica.cdc.debezium.StringDebeziumDeserializationSchema;import org.apache.flink.api.common.restartstrategy.RestartStrategies;import org.apache.flink.runtime.state.filesystem.FsStateBackend;import org.apache.flink.streaming.api.CheckpointingMode;import org.apache.flink.streaming.api.datastream.DataStreamSource;import org.apache.flink.streaming.api.environment.CheckpointConfig;import org.apache.flink.streaming.api.environment.StreamExecutionEnvironment; ...

摘要：本文整顿自阿里巴巴高级开发工程师郭旸泽 (天凌) 在 Flink Forward Asia 2021 的演讲。次要内容包含： 细粒度资源管理与实用场景Flink 资源调度框架基于 SlotSharinGroup 的资源配置接口动静资源切割机制资源申请策略总结与将来瞻望FFA 2021 直播回放 & 演讲 PDF 下载 一、细粒度资源管理与实用场景 在 Flink1.14 之前，应用的是一种粗粒度的资源管理形式，每个算子 slot request 所须要的资源都是未知的，在 Flink 外部用一个 UNKNOWN 的非凡值来示意，这个值能够和任意资源规格的物理 slot 来匹配。从 TaskManager (以下简称 TM) 的角度来说，它领有的 slot 个数和每个 slot 的资源维度都是依据 Flink 配置动态决定的。 对于少数简略作业，现有的粗粒度资源管理曾经能够根本满足对资源效率的要求。比方上图作业，由 Kafka 读入数据后通过一些简略的解决，最终将数据写入到 Redis 中。对于这种作业，咱们很容易将上下游并发保持一致，并将作业的整个 pipeline 放到一个 SlotSharingGroup (以下简称 SSG) 中。这种状况下，slot 的资源需要是基本相同的，用户间接调整默认的slot配置即可达到很高的资源利用效率，同时因为不同的 task 热点峰值不肯定雷同，通过削峰填谷效应，将不同的 task 放到一个大的 slot 里，还能够进一步升高整体的资源开销。 然而对于一些生产中可能遇到的简单作业，粗粒度资源管理并不能很好地满足他们的需要。 比方图上作业，有两个 128 并发的 Kafka source 和一个 32 并发的 Redis 维表，高低两路数据处理门路。一条是两个 Kafka source，通过 join 当前再通过一些聚合操作，最终将数据 sink 到第三个 16 并发的 Kafka 中；另一条门路则是 Kafka 和 Redis 维表进行 join，后果流入一个基于 TensorFlow 的在线推断模块，最终贮存到 Reids 中。 ...

摘要：本文整顿自阿里巴巴技术专家陈玉兆 (玉兆)、阿里巴巴开发工程师刘大龙 (风离) 在 Flink Forward Asia 2021 的分享。次要内容包含： Apache Hudi 101Flink Hudi IntegrationFlink Hudi Use CaseApache Hudi RoadmapFFA 2021 直播回放 & 演讲 PDF 下载 一、Apache Hudi 101提到数据湖，大家都会有这样的疑难，什么是数据湖？为什么数据湖近两年热度很高？数据湖其实不是一个新的概念，最早的数据湖概念在 80 年代就曾经提出，过后对数据湖的定义是原始数据层，能够寄存各种结构化、半结构化甚至非结构化的数据。像机器学习、实时剖析等很多场景都是在查问的时候确定数据的 Schema。 湖存储成本低、灵活性高的个性，十分实用于做查问场景的中心化存储。随同着近年来云服务的衰亡，尤其是对象存储的成熟，越来越多的企业抉择在云上构建存储服务。数据湖的存算拆散架构非常适合以后的云服务架构，通过快照隔离的形式，提供根底的 acid 事务，同时反对对接多种剖析引擎适配不同的查问场景，能够说湖存储在老本和开放性上占了极大劣势。 以后的湖存储曾经开始承当数仓的性能，通过和计算引擎对接实现湖仓一体的架构。湖存储是一种 table format，在原有的 data format 根底上封装了 table 的高级语义。Hudi 从 2016 年开始将数据湖投入实际，过后是为了解决大数据场景下文件系统上的数据更新问题，Hudi 类 LSM 的 table format 以后在湖格局中是自成一家的，对近实时更新比拟敌对，语义也绝对欠缺。 Table format 是以后风行的三种数据湖格局的根底属性，而 Hudi 从我的项目之初就始终朝着平台方向去演变，领有比较完善的数据治理和 table service，比方用户在写入的时候能够并发地优化文件的布局，metadata table 能够大幅优化写入时查问端的文件查找效率。 上面介绍一些 Hudi 的根底概念。 Timeline service 是 Hudi 事务层的外围形象，Hudi 所有数据操作都是围绕着 timeline service 来开展的，每次操作通过 instant 形象绑定一个特定的工夫戳，一连串的 instant 形成了 timeline service，每一个 instance 记录了对应的 action 和状态。通过 timeline service，Hudi 能够晓得以后表操作的状态，通过一套文件系统视图的形象联合 timeline service，能够对 table 以后的 reader 和 writer 裸露特定工夫戳下的文件布局视图。 ...

本篇内容整顿自 Pravega 中国社区创始人、戴尔科技团体软件工程技术总监滕昱在 Flink Forward Asia 2021 主会场的演讲。次要内容包含： 存储形象的现状Pravega 性能架构详解Pravega 流存储数据演示展望未来FFA 2021 直播回放 & 演讲 PDF 下载 一、存储形象的现状 在计算机软件设计中，有一个十分驰名的观点：任何新的计算机问题都能够通过新退出的形象层解决，对于存储也是一样。上图列出了三种大家次要应用的存储形象，即块存储、文件存储和对象存储。块存储基本上和古代计算机工业同期间诞生；文件存储作为当今支流的存储形象稍晚呈现；对象存储更晚，其诞生于 1990 年代。而在实时计算的倒退和云时代背景下，流式的数据有着越来越宽泛的利用，咱们认为须要一种新兴的存储形象来应答这一种强调低延时、高并发流量的数据。而在文件存储中增加字节流可能是一个最直观的想法，但在理论需要上面临着一系列的挑战，实现反而更加简单，如下图所示： 数据的写入大小对吞吐量的影响至关重要，为了均衡延时和吞吐量，在实现上须要引入 batching，并且须要预调配空间防止块调配造成的性能损耗，最初作为存储，长久化也必须保障。 本地文件系统实质上是不平安的。在事实世界中，每时每刻硬件节点，磁盘介质都可能会损坏。为了解决这些问题，就须要引入分布式存储系统，例如常见的多正本零碎，但正本的拷贝费时费空间，分布式一致性协定的数据安全问题又会成为新的难题。 如果基于 shared-nothing 架构设计，齐全并行不存在共享资源，例如上图中有三个正本别离存于三个独立的物理节点之上，那么单条流数据的存储大小就受限于单个物理界点的存储下限，所以这仍然不是一个齐备的解决办法。 由此可见，因为上述一系列的问题，基于文件系统构建流存储是相当简单的。 于是，咱们受到了开篇的观点的启发，尝试换个角度，应用分布式文件和对象存储的分层架构模式来解决这个问题。底层的可扩大存储能够作为一个数据湖，流的历史数据能够存入其中与其余非流的数据集共存，在节俭了数据迁徙、存储运维开销的同时能够解决数据孤岛的问题，批流联合的计算将会更加不便。 分层架构能够解决扩散的多客户端。为了解决容错复原的问题，咱们在流存储的根底上减少了分布式 log 存储。 在实在利用实例中，实时应用程序的流量可能随着工夫稳定，为了应答数据的峰谷，咱们引入了动静伸缩性能。 在左上角的图标中，横轴示意工夫，纵轴示意应用程序的数据。它的波形图刚开始很安稳，到了特定点时数据量忽然变大，这往往是一些跟工夫无关的应用程序的个性，比方早晚顶峰、双十一等场景，这个时候流量就会簇拥而入。 一个齐备的流存储系统应该可能感知到实时流量的变动进行资源的正当调配。当数据质变大时，底层会动静地调配更多的存储单元解决数据。在云原生时代的底层架构中，动静伸缩也是通用的存储系统中十分重要的一点。 二、Pravega 性能架构详解Pravega 的设计主旨是成为流的实时存储解决方案。 第一，应用程序将数据长久化存储到 Pravega 中，借助分层存储架构，Pravega Stream 实现了无下限的流存储；第二，Pravega 反对端到端的仅一次语义，包含读端的 checkpoint 与事务性写性能，使得计算能够拆分为多个牢靠的独立应用程序，实现了流式零碎的微服务架构；第三，Pravega 的动静伸缩机制，能够实现流量监控并主动在底层进行资源的调配，让开发和运维人员无需手动调度集群。Pravega 独立的伸缩机制，让生产者和消费者互不影响，数据处理管道变得富裕弹性，能对数据的实时变动做出适时的反馈。 如图所示，Pravega 是从存储的视角对待流数据。Kafka 自身的定位是音讯零碎，所以它会从音讯视角对待流数据。音讯零碎与存储系统的定位是不同的，音讯零碎是指音讯传输零碎，次要关注数据传输与生产生产的过程。Pravega 的定位是企业级的分布式流存储产品，岂但满足流的属性还反对数据存储的长久化、安全可靠、隔离等属性。 视角的不同带来了设计架构上的差异性，因为音讯零碎无需解决长时间的数据存储，因而都会须要额定的工作和组件进行数据的搬运来实现长久化。而定位流存储的 Pravega 则在主存储中间接解决了数据 retention 问题。Pravega 的数据存储的外围引擎称之为 segment store，间接对接 HDFS 或 S3 的分布式存储组件用以进行长期、长久化的存储。依靠底层存储组件的成熟架构与可扩大能力，Pravega 在存储端也就天然具备了大规模存储和可扩大的个性。 ...

摘要：本文整顿自快手实时计算团队技术专家张静、张芒在 Flink Forward Asia 2021 的分享。次要内容包含： Flink SQL 在快手性能扩大性能优化稳定性晋升将来瞻望FFA 2021 直播回放 & 演讲 PDF 下载 一、Flink SQL 在快手 通过一年多的推广，快手外部用户对 Flink SQL 的认可度逐步进步，往年新增的 Flink 作业中，SQL 作业达到了 60%，与去年相比有了一倍的晋升，峰值吞吐达到了 6 亿条/秒。 二、性能扩大为了反对外部的业务需要，快手做了很多性能扩大，本文重点分享其中的两个围绕窗口的扩大，一个是 Group Window Aggregate 扩大，一个是在 Flip-145 里提出的 Window Table-valued Function 扩大。 解释一下以上两者的区别和分割： Group Window Aggregate 是在 Flink 1.12 和更早的版本里用来做窗口聚合的，它有两个局限性，第一个是它的语法不合乎 SQL 规范，要借助非凡的窗口函数，还要配合窗口辅助函数来实现作业聚合。另外它还限度了窗口函数只能呈现在 group by 的子句外面，所以只能用于聚合；因而 Flink 在 Flip-145 里提出了 Window TVF，它是基于 2017 年的 SQL 规范里提出的多态表函数的语法，另外它除了能够在窗口上做聚合，还能够做窗口关联，TopN 和去重等操作。2.1 Group Window Aggregate 扩大大家可能会问，既然曾经有 Window TVF 了，为什么还要在 Group Window Aggregate 上做性能扩大呢？因为快手是在往年下半年才开始进行版本 1.10 到 1.13 的降级，大部分业务还是在应用 1.10 版本。 ...

本文整顿自 BIGO Staff Engineer 邹云鹤在 Flink Forward Asia 2021 的分享。次要内容包含： 业务背景落地实际 & 特色改良利用场景将来布局FFA 2021 直播回放 & 演讲 PDF 下载 一、业务背景BIGO 是一家面向海内的以短视频直播业务为主的公司, 目前公司的次要业务包含 BigoLive (寰球直播服务)，Likee (短视频创作分享平台)，IMO (收费通信工具) 三局部，在寰球范畴内领有 4 亿用户。随同着业务的倒退，对数据平台解决能力的要求也是越来越高，平台所面临的问题也是日益凸显，接下来将介绍 BIGO 大数据平台及其所面临的问题。BIGO 大数据平台的数据流转图如下所示： 用户在 APP，Web 页面上的行为日志数据，以及关系数据库的 Binlog 数据会被同步到 BIGO 大数据平台音讯队列，以及离线存储系统中，而后通过实时的，离线的数据分析伎俩进行计算，以利用于实时举荐、监控、即席查问等应用场景。然而存在以下几个问题： OLAP 剖析平台入口不对立：Presto/Spark 剖析工作入口并存，用户不分明本人的 SQL 查问适宜哪个引擎执行，自觉抉择，体验不好；另外，用户会在两个入口同时提交雷同查问，以更快的获取查问后果，导致资源节约；离线工作计算时延高，后果产出太慢：典型的如 ABTest 业务，常常计算到下午才计算出后果；各个业务方基于本人的业务场景独立开发利用，实时工作烟囱式的开发，短少数据分层，数据血统。面对以上的问题，BIGO 大数据平台建设了 OneSQL OLAP 剖析平台，以及实时数仓。 通过 OneSQL OLAP 剖析平台，对立 OLAP 查问入口，缩小用户自觉抉择，晋升平台的资源利用率；通过 Flink 构建实时数仓工作，通过 Kafka/Pulsar 进行数据分层；将局部离线计算慢的工作迁徙到 Flink 流式计算工作上，减速计算结果的产出；另外建设实时计算平台 Bigoflow 治理这些实时计算工作，建设实时工作的血缘关系。 二、落地实际 & 特色改良2.1 OneSQL OLAP 剖析平台实际和优化OneSQL OLAP 剖析平台是一个集 Flink、Spark、Presto 于一体的 OLAP 查问剖析引擎。用户提交的 OLAP 查问申请通过 OneSQL 后端转发到不同执行引擎的客户端，而后提交对应的查问申请到不同的集群上执行。其整体架构图如下： ...

StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment();env.setStreamTimeCharacteristic(TimeCharacteristic.EventTime);dataStream.filter(data -> "test".equals(data.getTag())).keyBy("userId");......执行报错： Exception in thread "main" org.apache.flink.api.common.InvalidProgramException: This type (GenericType<com.zixi.User>) cannot be used as key. at org.apache.flink.api.common.operators.Keys$ExpressionKeys.<init>(Keys.java:330) at org.apache.flink.streaming.api.datastream.DataStream.keyBy(DataStream.java:340) at com.zixi.main(UserTest.java:58)解决办法：1.提供默认无参构造函数2.字段名必须申明为public

Iceberg作为凌驾于HDFS和S3等存储系统之上的数据组织框架，提供了数据写入、读取、文件治理和元数据管理等基本功能，尽管Iceberg提供了丰盛的API接口，然而面向API开发须要应用方比拟理解其原理和实现细节，还是显得门槛过高。此外，在面向实时数据读写场景，须要有一个桥接框架来主动实现数据的读写，于是Iceberg和Flink成为天作之合，本文就来钻研下Iceberg是如何跟Flink对接的。 Flink写入Iceberg总体流程介绍 Flink典型的数据处理链路是Source->Transform->Sink，对Iceberg来讲，也听从这一模式，比方下图： Custom Souce是自定义的数据源类型的Source，用于向上游发送数据，比方上面的数据来源于动态List汇合： DataStream<RowData> dataStream = env.fromCollection(list）IcebergStreamWriter起着数据变换作用，跟Source 组成链式Operator，IcebergFilesCommiter作为Sink，将数据提交到本地文件test表。 Source端发送数据到IcebergStreamWriter，IcebergFilesCommiter将从IcebergStreamWriter获取的数据提交到元数据管理系统，比方Hive Metastore或者文件系统。当胜利提交元数据之后，写入的数据才对外部可见。在这一个过程中，IcebergStreamWriter除了相当于上述链路模式中的Transform角色之外，还有一个重要起因：实现事务提交隔离。IcebergStreamWriter将数据临时写入到一个缓冲文件，该文件临时对外部是不可见的，而后IcebergFilesCommiter再将IcebergStreamWriter写入的文件的元信息，比方门路、文件大小，记录行数等写入到ManifestFile中，最初将ManifestFile文件元信息再写入到ManifestList（ManifestList即快照信息），ManifestList又被写入以版本号辨别的metadata文件中（v%版本号%.metadata.json)，下图展现了一个残缺的数据包含元数据组织示例： 上面开展来讲下实现上述指标的细节内容： 首先Source端DataStream数据流通过IcebergStreamWriter变换，生成新的DataStream： SingleOutputStreamOperator ，输入类型是WriteResult： //DataStream<RowData> input//IcebergStreamWriter streamWriterSingleOutputStreamOperator<WriteResult> writerStream = input .transform(operatorName(ICEBERG_STREAM_WRITER_NAME), TypeInformation.of(WriteResult.class), streamWriter) .setParallelism(parallelism);其中WriteResult的定义如下： public class WriteResult implements Serializable { private DataFile[] dataFiles; private DeleteFile[] deleteFiles; private CharSequence[] referencedDataFiles; ...}从类定义可知，IcebergStreamWriter的输入后果其实只是该过程产生的数据文件，次要包含DataFile和DeleteFile，referencedDataFiles临时先不关注。 而后，IcebergFilesCommiter对上游的Operator 做变换，生成新的DataStream：SingleOutputStreamOperator，这个过程只是提交元数据，自身不会再往上游发送数据，所以返回数据类型为Void： //SingleOutputStreamOperator<WriteResult> writerStreamSingleOutputStreamOperator<Void> committerStream = writerStream .transform(operatorName(ICEBERG_FILES_COMMITTER_NAME), Types.VOID, filesCommitter) .setParallelism(1) .setMaxParallelism(1);IcebergStreamWriter和IcebergFilesCommiter实现详细分析 从下面介绍可知，IcebergStreamWriter和IcebergFilesCommiter是最次要的两个数据处理过程，上面对其具体介绍。IcebergStreamWriter和IcebergFilesCommiter都是AbstractStreamOperator的子类，自身除了要实现对单个元素的解决逻辑，还有对快照解决的相干逻辑，先说说对单个元素的解决逻辑： class IcebergStreamWriter<T> extends AbstractStreamOperator<WriteResult> implements OneInputStreamOperator<T, WriteResult>, BoundedOneInput { private transient TaskWriter<T> writer; @Override public void processElement(StreamRecord<T> element) throws Exception { writer.write(element.getValue()); } @Override public void endInput() throws IOException { // For bounded stream, it may don't enable the checkpoint mechanism so we'd better to emit the remaining // completed files to downstream before closing the writer so that we won't miss any of them. emit(writer.complete()); }}IcebergStreamWriter的processElement逻辑看起来比较简单，理论都封装到TaskWriter中去了。endInput办法起着兜底作用，在敞开writer之前，将残余未发送的数据发到上游，由前文可知，发给上游的数据类型为WriteResult。这里一个显著问题是writer是无止境地往文件中写吗？理论不是的，Writer会依据写入的文件大小主动切换新的Writer。 ...

摘要：本文整顿自作业帮实时计算负责人张迎在 Flink Forward Asia 2021 的分享。在作业帮实时计算演进过程中，Flink 起到了重要的作用，特地是借助于 FlinkSQL 极大的进步了实时工作的开发效率。这篇文章次要分享 FlinkSQL 在作业帮的应用状况、实践经验，以及随着工作规模增长，在从 0 到 1 搭建实时计算平台的过程中遇到的问题及解决方案。内容包含： 倒退历程Flink SQL 利用实际平台建设总结瞻望FFA 2021 直播回放 & 演讲 PDF 下载 一、倒退历程作业帮次要使用人工智能、大数据等技术，为学生提供更高效的学习解决方案。因而业务上的数据，次要是学生的到课状况、知识点把握的状况这些。整体架构上，无论是 binlog 还是一般日志，通过采集后写入 Kafka，别离由实时和离线计算写入存储层，基于 OLAP 再对外提供对应的产品化服务，比方工作台、BI 剖析工具。 作业帮的实时计算目前根本以 Flink 为主，倒退历程大略有三个阶段： 19 年，实时计算蕴含大量的 SparkStreaming 作业，提供到辅导老师、主讲侧。在解决实时需要的过程中，就会发现开发效率很低，数据简直无奈复用；之后惯例的做法，是在生产实践中逐渐利用 Flink JAR，积攒教训后开始搭建平台以及利用 Flink SQL。不过在 20 年，业务提出了十分多的实时计算需要，而咱们开发人力储备有余。过后 Flink SQL 1.9 公布不久，SQL 性能变动较大，所以咱们的做法是间接在实时数仓方向利用 Flink SQL，目前整个实时数仓超过 90% 的工作都是应用 Flink SQL 实现的；到了 20 年 11 月份，Flink 作业很快减少到几百条，咱们开始从 0 到 1 搭建实时计算平台，曾经反对了公司全副重要的业务线，计算部署在多个云的多个集群上。 接下来介绍两个方面： FlinkSQL 实际遇到的典型问题以及解决方案；实时计算平台建设过程中的一些思考。二、Flink SQL 利用实际这是基于 Flink SQL 的残缺数据流架构： ...

摘要：1 月 8 日，Flink Forward Asia 2021 邀请到了几位国内外顶尖科技公司实时计算方向的负责人，举办了两场圆桌分享。本文为大家带来北京场题为《行业先锋畅聊 Flink 将来》的圆桌分享的精彩内容。本场圆桌次要探讨了三个话题： 如何对待 Flink 与实时计算的将来？如何对待 Flink 与其余开源我的项目的关系？如何对待企业与开源社区之间的关系？FFA 2021 直播回放 & 演讲 PDF 下载 一、如何对待 Flink 与实时计算的将来是否能够认为 Flink 在实时计算方面曾经趋于成熟？各位嘉宾眼中实时计算的将来是什么样的？间隔实现这样的将来，Flink 还须要摸索哪些畛域、解决哪些问题？ 王加胜：性能趋于成熟，应用领域有待扩大 我集体认为，成熟有两个比拟重要的标记：性能趋于欠缺、在外围场景下失去大规模的利用。我认为 Flink 当初在性能层面曾经趋于成熟，包含对实时计算和流批一体的反对。但在利用方面，Flink 还须要推广更多的业务。期待 Flink 在更多的畛域施展更大的作用。 董亭亭：流式计算趋于成熟，流批一体仍有较大摸索空间 流式计算畛域，Flink 曾经是业界事实标准，是各公司流式计算选型的首选，在稳定性和易用性方面也越来越成熟。作为流批一体引擎，Flink 在批处理方面仍有较大摸索空间，例如动静资源调度、揣测执行等能力，以及湖仓一体、OLAP 等利用场景。在这方面，社区和各公司也在踊跃推动、摸索，还不能说是成熟的。 鞠大升：Flink 是一种趋势，将来前景会更光明 从数据处理畛域来看，Flink 现阶段曾经达成了一种趋势，但还不是成熟。掂量是否成熟要看两个方面：从在业务利用场景的理论应用状况来看，目前 Flink 在流式解决的趋势曾经达成，批式解决仍以 Spark 为主，数据湖、增量生产才刚刚起步，所以从利用角度来说，Flink 的使命任重而道远；从技术能力来说，Flink 在批处理、大状态作业执行、容灾复原等方面还有提高空间。冀望 Flink 在数据处理畛域施展更大的作用、增长出更多的能力和场景。 张光芒：流式计算场景绝对成熟，技术层面进一步晋升 Flink 在流式计算的场景曾经绝对成熟，在实时数仓、实时 ETL、实时机器学习都曾经有大规模落地，随着 Hybrid Source、CDC connector、实时入湖入仓等技术的开源，对业务场景的覆盖面曾经比拟广了。但在技术层面上，还有一些须要将来进一步摸索的中央，比方状态和计算的存算拆散、弹性计算应答突发流量的能力、更优良的容错能力等。 王峰：流计算要走向极致，实时计算不只是流计算 大数据的整体趋势是向实时化演进，Flink 在其中充当了先锋的作用。Flink 在流解决技术方面曾经走向成熟，但还没有达到极致。比方，Flink 在云原生的挑战下如何动静的适配弹性扩缩容，如何实现彻底的存算拆散架构，如何晋升容错能力做到 zero downtime。我感觉在流计算方面，Flink 接下来应该朝着极致方向去演进。 实时计算这个大的概念并不等于流计算。当数据发生变化时，第一工夫感知变动、按预约逻辑进行解决，这是流计算所做的事件；同时，实时计算还有其余的状态，比方要对一批数据进行毫秒级、秒级的剖析，这仍然是实时计算的领域。Flink 在对存量数据进行高时效剖析方面还有很大倒退空间，依赖其流批一体的能力、高效的计算引擎能够实现更大场景数据的实时化。 ...

本文首发于泊浮目标语雀:https://www.yuque.com/17sing版本日期备注1.02022.1.26文章首发0.前言前阵子组里的小伙伴问我“为什么Flink从咱们的代码到真正可执行的状态，要通过这么多个graph转换？这样做有什么益处嘛？”我晚期看到这里的设计时确实有过雷同的纳闷，过后因为手里还在看别的货色，查阅过一些材料后就翻页了。现在又碰到了这样的问题，无妨就在这篇文章中好好搞清楚。 本文的源码基于Flink1.14.0。1. 分层设计 该图来自Jark大佬的博客：http://wuchong.me/blog/2016/0...以上是Flink的Graph档次图，在接下来的内容咱们会逐个揭开它们的面纱，得悉它们存在的意义。 1.1 BatchAPI的OptimizedPlan在这个大节中，咱们会看到DataSet从Plan转换到OptimizedPlan的过程中。为了不便读者有个概念，咱们在这里解释一下几个名词： DataSet：面向用户的批处理API。Plan：形容DataSource以及DataSink以及Operation如何互动的打算。OptimizedPlan：优化过的执行打算。代码入口： |--ClientFrontend#main \-- parseAndRun \-- runApplication \-- getPackagedProgram \-- buildProgram \-- executeProgram|-- ClientUtils#executeProgram|-- PackagedProgram#invokeInteractiveModeForExecution \-- callMainMethod //调用用户编写的程序入口|-- ExecutionEnvironment#execute \-- executeAsync // 创立Plan|-- PipelineExecutorFactory#execute|-- EmbeddedExecutor#execute \-- submitAndGetJobClientFuture|-- PipelineExecutorUtils#getJobGraph|-- FlinkPipelineTranslationUtil#getJobGraph|-- FlinkPipelineTranslator#translateToJobGraph //如果传入的是Plan，则会在外部实现中先转换出OptimizedPlan，再转换到JobGraph；如果是StreamGraph，则会间接转换出JobGraph|-- PlanTranslator#translateToJobGraph \-- compilePlan咱们看一下这段代码： private JobGraph compilePlan(Plan plan, Configuration optimizerConfiguration) { Optimizer optimizer = new Optimizer(new DataStatistics(), optimizerConfiguration); OptimizedPlan optimizedPlan = optimizer.compile(plan); JobGraphGenerator jobGraphGenerator = new JobGraphGenerator(optimizerConfiguration); return jobGraphGenerator.compileJobGraph(optimizedPlan, plan.getJobId()); }十分的清晰。就是从OptimizedPlan到JobGraph。OptimizedPlan的转换过程咱们看Optimizer#compile办法。先看办法签名上的正文： /** * Translates the given program to an OptimizedPlan. The optimized plan describes for each * operator which strategy to use (such as hash join versus sort-merge join), what data exchange * method to use (local pipe forward, shuffle, broadcast), what exchange mode to use (pipelined, * batch), where to cache intermediate results, etc, * * <p>The optimization happens in multiple phases: * * <ol> * <li>Create optimizer dag implementation of the program. * <p><tt>OptimizerNode</tt> representations of the PACTs, assign parallelism and compute * size estimates. * <li>Compute interesting properties and auxiliary structures. * <li>Enumerate plan alternatives. This cannot be done in the same step as the interesting * property computation (as opposed to the Database approaches), because we support plans * that are not trees. * </ol> * * @param program The program to be translated. * @param postPasser The function to be used for post passing the optimizer's plan and setting * the data type specific serialization routines. * @return The optimized plan. * @throws CompilerException Thrown, if the plan is invalid or the optimizer encountered an * inconsistent situation during the compilation process. */ private OptimizedPlan compile(Plan program, OptimizerPostPass postPasser)这里提到了会有好几步来做优化： ...

简介：本文将对FFA Keynote议题作一些简略的演绎总结，感兴趣的小伙伴们能够在FFA官网[2]找到相干主题视频观看直播回放。 作者 | 梅源（Yuan Mei）起源 | 阿里技术公众号 律回春晖渐，万象始更新，这句诗用来形容2021年的大数据畛域再适合不过，而Flink在2021年也开启了新的篇章。 2022年1月8-9号，Flink Forward Asia（FFA）线上峰会胜利举办。Flink Forward Asia 是由 Apache 官网受权，Apache Flink中文社区主持举办的会议。目前，Flink Forward Asia 已成为国内最大的 Apache 顶级我的项目会议之一，是 Flink 开发者和使用者的年度盛会。在线上峰会的同时，FFA还举办了首届以实时计算为主题的Flink Hackathon，共有267支参赛队伍，最终27支队伍入围参加线下决赛。将来Flink Hackathon也会常态化举办，集思广益。 FFA大会从社区倒退，业界影响力以及生态技术演进这三方面总结了Flink在过来一年的倒退。社区方面，依据Apache软件基金会2021财年报告颁布的各项外围指标，Flink已间断三年位列Apache社区最沉闷的我的项目之一。而作为社区的最小原子，Flink的社区代码开发者（Contributor）已超过1400名，年增长率超过20%。其中尤其值得一提的是Flink中文社区的蓬勃发展：Flink的官网公众号订阅数超过5万人，全年推送超过140篇和Flink技术，生态以及行业实际相干的最新资讯。最近，Flink社区开明了Flink官网视频号，心愿通过更加丰盛新鲜的模式从更多纬度让大家对Flink有更全面的理解。此外，Flink社区重构和改版了去年开明的Flink官网学习网站Flink Learning[1]，心愿通过这个学习网站，汇总积淀和Flink相干的学习材料，场景案例以及流动信息，使Flink Learning真正成为大家学习钻研摸索Flink的好帮手。 业界影响力方面，Flink已成为业界实时计算的事实标准。越来越多的公司不仅应用Flink，也积极参与Flink的倒退与建设，独特欠缺Flink。目前，Flink的代码开发者来自寰球超过100+公司。去年举办的4场的线下meet up，阿里巴巴、字节跳动，携程和360都提供了大力支持。而往年FFA大会有来自互联网，金融，能源，制造业，电信等各个行业的40+出名公司共83个主题演讲。从生态技术演进来看，Flink在云原生，高可用性，流批一体和AI四个主打方向上都获得了不错的问题。特地值得一提的是Flink新推出了流批一体的进阶版，流式数仓（Streaming Warehouse）这个概念，实现流批实时剖析一体化，真正意义上实现流批一体计算和流批一体存储的交融，让整个数仓的数据流动起来。流式数仓将是Flink将来最重要的方向之一，在Flink社区也会同步推广。 本文将对FFA Keynote议题作一些简略的演绎总结，感兴趣的小伙伴们能够在FFA官网[2]找到相干主题视频观看直播回放。 一 主会场议题 在主议题之前，阿里巴巴团体副总裁，阿里巴巴开源技术委员会负责人，阿里云智能计算平台负责人贾扬清老师作为收场嘉宾，分享了他对开源在云计算的大背景下的思考：开源，无论是从技术奉献还是生态倒退来看，已从最后的代替和补充逐渐倒退成为翻新和引领的角色。阿里巴巴到目前为止曾经开源了2700多个我的项目，是国内互联网技术企业中的先锋。而Flink作为阿里巴巴最具影响力的开源我的项目之一，无论是在技术先进性还是生态丰富性上都无可争议。不仅如此，阿里巴巴在过来几年中踊跃拓展Flink的实用场景，通过本身大规模业务打磨迭代开源技术，进而将这些技术回馈Flink社区，并携手其余开源我的项目造成更全面的联结解决方案，真正做到了开源凋谢，继续回馈，减速遍及。 上面来重点聊一聊几个主议题。 1 Flink Next –– Beyond Stream Processing主议题照例由Apache Flink中文社区发起人，阿里巴巴开源大数据平台负责人王峰（花名莫问）老师开启，次要介绍 Flink 社区在 2021 年获得的成绩以及将来的倒退方向，包含云原生，Flink容错，流批一体和机器学习四个局部。 云原生 –– 部署架构演进 Flink部署的三种模式 说起开源大数据的倒退，绕不开云原生，两者相依相生相辅相成。作为开源大数据的引擎课代表Flink的部署模式是如何在云原生大背景下演进的是个很乏味的话题。Flink最早的部署模式是经典的动态（Static）Standalone模式，这里的动态是指用户必须依据业务估算预留资源，资源少了作业就跑不起来，所以大部分状况下须要按最大资源量来预留。不言而喻这种模式对于用户来说既简单资源利用率也不高。第二种模式咱们称为被动（Active）模式，这里的被动是指Flink会依据业务资源的应用状况被动的去向底层Kubernetes或者Yarn申请和开释资源。这种模式须要Flink和底层Kubernetes或者Yarn深度集成，实用于须要对资源深度把控的用户，对中小用户来讲太过简单。这就引出了第三种模式咱们称为适应性（Adaptive/Reactive）模式。在这种模式下，Flink能够像云上其余利用一样依据所给的资源（减少或缩小资源pod），通过扭转本身拓扑构造来动静调整运行。从用户的角度来看，他并不需要理解资源是如何调配的，所以第三种模式对于用户的门槛绝对较低。 还有一个值得思考的问题是云原生到底给Flink带来了什么，除了弹性资源管理，数据多备份，自适应运维治理，标准化的工具和操作，笔者感觉更重要的是升高用户的应用门槛，用更小的老本给用户提供更简略，稳固和丰盛的应用体验。 Flink容错 –– 稳固疾速的Checkpoint 和Checkpointing相干的探讨简直贯通了Flink的整个倒退历程，它是整个Flink容错架构的外围。Flink会定期给所有的算子状态做快照检查点（Checkpoint），如果Flink作业失败，作业会从上一个残缺的Checkpoint复原。在理论工作中，咱们发现引擎这一层很大部分的Oncall的问题都跟做Checkpoint相干，所以如何可能高频稳固的实现Checkpoint是晋升Flink高可用性（容错）的重点。造成做Checkpoint失败（超时）的次要起因来自两方面：一是两头数据流动迟缓造成Checkpoint Barrier流动迟缓，二是算子状态过大造成状态数据上传超时。Flink针对这两个方面都有重点项目在跟进：Buffer Debloating和Generalized Log-Based Checkpoint。 ...

概要2021年12月13日，中国信息通信研究院新一轮“大数据产品能力评测”后果颁布，阿里云实时计算 Flink 版通过分布式流解决平台稳定性专项测评，阿里云成为「首批+惟一」通过该稳定性专项评测的厂商。此前，实时计算 Flink 版别离在2019年5月和2021年6月通过中国信通院“分布式流解决平台-根底能力测评”和“分布式流解决平台-性能专项测评”，因而阿里云实时计算 Flink 版成为国内惟一全面通过中国信通院根底能力、性能、稳定性三款评测的分布式流解决平台产品。 评测详情近年来，“中国信通院大数据产品能力评测”作为国内首个大数据产品权威评测体系，已成为厂商产品研发和用户洽购选型的风向标。本次阿里云实时计算 Flink 版在稳定性专项性能测评中，通过了CPU高负载、硬盘高负载、内存高负载、读写高负载、网络丢包、单节点故障、随机高强度综合测试等7个子我的项目评测。其中 CPU高负载、硬盘高负载、内存高负载、读写高负载、网络丢包 这五种状况下作业主动适应环境，从而安稳运行；单节点故障、随机混合测试中 作业均从故障中实现主动复原，并继续运行直到计算工作实现。面对小规模硬件故障和简单网络环境，实时计算Flink版体现出极高的架构健壮性，继续向用户提供稳固的企业级服务。 技术劣势实时计算 Flink 版产品在阿里巴巴团体各类大促环境中早已有广泛应用，在天猫双十一购物节和618等重大电商流动中都体现出卓越的能力。往年的双十一购物节期间，Flink实时计算的算力总TPS达到惊人的69亿条每秒，GMV 大屏提早在 3 秒以内。2021年实时计算 Flink 版成为中国惟一进入Forrester强劲表现者象限的产品，刷新了国内公司在数据流计算畛域的最好问题。 阿里云流计算产品进入 Forrester 数据流剖析报告 产品劣势作为国内最早布局实时计算技术方向的企业之一，早在 2016 年阿里巴巴就曾经开始大规模上线应用实时计算产品。本次通过测试的阿里云实时计算 Flink 版，是阿里云Flink企业级开发运维平台和增强型内核引擎所形成的云上产品。实时计算 Flink 版产品绝对于开源 Apache Flink 领有更具劣势的性能和稳定性，开箱即用，同时企业级加强性能集成阿里云加强的 Iceberg、Hudi 等数据湖格局能力，不便用户构建大规模数据湖。 实时计算 Flink 版还领有丰盛的作业运行监控与诊断调优能力，能够为用户提供状态兼容性检查和状态数据迁徙，以最大可能的复用原来的状态数据，帮忙用户疾速降级 SQL作业。同时反对算子级别的精细化资源配置（CPU/Mem），大规模作业资源利用率进步 100%+。 在产品状态层面，实时计算 Flink 版向用户提供灵便的产品状态以供选择。不仅反对适宜用户开箱即用的全托管状态，帮忙用户疾速落地流计算的开发运维，同时也反对用户自主可控、易于集成的半托管状态（基于 Yarn 资源分配调度），包年包月模式与用户自建成本统一，帮忙用户实现一站式实时数据流解决的基础架构（蕴含 Kafka 和 企业版Flink引擎VVR）。对于资源绝对变动较小的状况，能够抉择包年包月。对于资源不好明确评估或有业务高下峰变动的，能够抉择按量付费 + Autopilot 模式实现 serverless 的“用多少买多少”。 实时计算 Flink 版产品在阿里巴巴的倒退历程 客户案例目前阿里云实时计算 Flink 版曾经积淀了互联网娱乐，在线交易，金融，在线教育等近百个行业案例场景，多行业全方位实际场景，为业务稳固倒退保驾护航。 实时计算Flink版局部客户案例

作者：梅源（Yuan Mei） FFA 2021 直播回放 & 演讲 PDF 下载 律回春晖渐，万象始更新，这句诗用来形容 2021 年的大数据畛域再适合不过，而 Flink 在 2021 年也开启了新的篇章。 2022 年 1 月 8-9 号，Flink Forward Asia (FFA) 线上峰会胜利举办。Flink Forward Asia 是由 Apache 官网受权，Apache Flink 中文社区主持举办的会议。目前，Flink Forward Asia 已成为国内最大的 Apache 顶级我的项目会议之一，是 Flink 开发者和使用者的年度盛会。因为疫情起因，本届峰会仍采纳线上直播的模式，峰会首日流量峰值 PV 20W+、UV 10W+；实时观看量峰值 4.5W+。直播页累计 PV 100W+、UV 30W+。在线上峰会的同时，FFA 还举办了首届以实时计算为主题的 Flink Hackathon，共有 267 支参赛队伍，最终 27 支队伍入围参加线下决赛。将来 Flink Hackathon 也会常态化举办，集思广益。 FFA 大会从社区倒退，业界影响力以及生态技术演进这三方面总结了 Flink 在过来一年的倒退。社区方面，依据 Apache 软件基金会 2021 财年报告颁布的各项外围指标，Flink 已间断三年位列 Apache 社区最沉闷的我的项目之一。而作为社区的最小原子，Flink 的社区代码开发者 (Contributor) 已超过 1400 名，年增长率超过 20%。其中尤其值得一提的是 Flink 中文社区的蓬勃发展：Flink 的官网公众号订阅数超过 5 万人，全年推送超过 140 篇和 Flink 技术，生态以及行业实际相干的最新资讯。最近，Flink 社区开明了 Flink 官网视频号，心愿通过更加丰盛新鲜的模式从更多纬度让大家对 Flink 有更全面的理解。此外，Flink 社区重构和改版了去年开明的 Flink 官网学习网站 Flink Learning[1]，心愿通过这个学习网站，汇总积淀和 Flink 相干的学习材料，场景案例以及流动信息，使 Flink Learning 真正成为大家学习钻研摸索 Flink 的好帮手。 ...

本文整顿自中国工商银行大数据平台负责人袁一在 Flink Forward Asia 2021 的分享。次要内容包含： 工行实时大数据平台建设历程工行实时大数据平台建设思路瞻望FFA 2021 直播回放 & 演讲 PDF 下载 一、工行实时大数据平台建设历程 工商银行从 2002 年开始建设数据集市，过后次要应用 Oracle 类单机版的关系型数据库。随着数据量一直减少，开始引入 TD、ED 等国外高端一体机。2014 年工行正式基于 Hadoop 技术建设了大数据平台，在其之上构建了企业级数据湖及数据仓库。2017 年，随着 AI 技术的衰亡，又开始建设机器学习平台，2020 年开始建设数据中台和高时效类场景。 为了满足数据时效，以及企业级大规模普惠用数的诉求，企业外部的大数据平台须要不仅反对批量计算，还须要满足各类用数场景全栈笼罩的技术体系。以工行为例，大数据平台外部除批量计算之外，蕴含实时计算，联机剖析、数据 API 等平台，次要以 Flink 作为外部引擎，用于缩短数据端到端闭环工夫，造成联机高并发的拜访能力，晋升数据赋能业务的时效。除此之外，还蕴含数据交换、数据安全等面向特定技术畛域的二级平台。在最下面一层，咱们向开发人员、数据分析师、运维人员提供了可视化的撑持工具。 二、工行实时大数据平台建设思路工行实时大数据平台建设思路，次要会围绕时效、易用、安全可靠和降本增效来开展。 在数据时效方面，上图是形容数据流向的示意图，原始数据从左上角的利用产生，通过蓝色和粉色两条链路。其中，蓝色链路是业务视角上端到端闭坏的链路，利用产生的数据会写入 MySQL 或者 Oracle 等关系型数据库，之后通过 CDC 相干技术，将数据库产生的日志复制到 Kafka 音讯队列中，将同一份数据的共享，防止屡次读取数据库日志。 在 Kafka 之后，是实时计算平台。实时计算平台除了实现对时效要求较高的计算解决场景之外，它还能够通过 Flink 联合 Hudi/IceBerg 等产品实现实时数据入湖。而且能将 Flink 的后果输入到 HBase/ES 等联机数据库中。将这部分数据以服务的模式裸露，即数据中台服务，从而提供给利用调用。 粉色链路的数据，最终回到数据分析师那里，是蓝色链路的衍生。各个利用产生的数据，通过 Flink 和 Hudi 的实时数据入湖，通过 Presto 或 CK 等剖析型引擎，供数据分析师进行 BI 剖析。通过这条链路，数据时效得以晋升，让分析师拜访到分钟级延时的热数据，更加实时、精确地做出经营决策。个别高时效的业务场景，都蕴含在这条技术链路的体系之内。 ...

本文整顿自京东搜寻举荐算法工程师张颖、刘露在 Flink Forward Asia 2021 的分享。次要内容包含： 背景京东搜寻举荐机器学习现状基于 Alink 实现在线学习Tensorflow on Flink 利用布局FFA 2021 直播回放 & 演讲 PDF 下载 一、背景 搜寻和举荐是互联网利用的两个外围入口，大多数流量都来自于搜寻和举荐这两个场景。京东批发按站点，分为主站、京喜、海内站以及一些垂直畛域站点。 对于搜寻业务来讲，每个站点下会有关键词搜寻、下拉发现、以及店铺、优惠券、订单等细分页面的搜寻；对举荐业务来讲，按照利用场域不同，划分了大大小小几百种举荐位。 以上每一种业务场景下，都蕴含了十多种策略环节，须要机器学习模型反对。基于海量的商品数据、海量的用户行为，作为机器学习的特色样本。 除了搜推广畛域中典型的用意辨认、召回、排序、相关性模型以外，京东搜寻举荐为了更好的保护用户、商家、平台这三方的生态，在智能经营、智能风控、成果剖析这些环节，也越来越多的引入模型进行决策。 二、京东搜寻举荐机器学习现状 咱们根据服务场景和服务时效的差别，将这些机器学习场景进行分成了三类： 一种模型是在用户拜访搜寻或举荐页面时，即时申请到的商品召回、排序、用意辨认等模型， 这类模型在服务层面对响应工夫要求极高，预估服务位于在线零碎中。另一种模型是对服务响应工夫要求不高，但对模型的训练和预估有肯定的时效性要求，比方实时用户画像、实时反作弊模型，这里咱们把它称作是近线场景。第三种是纯离线的模型场景，比方商品或用户的长期画像、针对于各种素材标签的常识图谱， 这些场景的训练和预测对时效要求绝对较低，全在离线环境下进行。 咱们来看下以后次要的模型服务架构是怎么样的： 京东搜寻和举荐零碎因为业务零碎自身的差别，别离由不同的 kernel 链式模块，组成为搜寻零碎和举荐零碎。 一次用户搜寻，会逐级申请链路上的各级服务，先对关键词过 QP 服务，走用意辨认模型；再由召回服务并行申请各路的召回，会顺次调用召回模型、相关性模型、粗排模型；而后排序服务汇总后果集后，会调用精排模型、重排模型等。 一次用户拜访举荐的业务过程，有一些差别，但整体上流程比拟靠近。 这两个大业务上层，会共享一些离线、近线根底用处的模型，比方用户的画像、素材标签、各种指标剖析。 他们拜访的模型服务架构，都由训练 + 预估两局部组成，两头由模型仓库和参数服务桥接起来；特色方面，在线场景须要特色服务器，离线场景则由数据链路组成。 从模型状态上，咱们能够把现有模型划分成两种状态： 左侧一类模型，单体规模绝对简单，采纳数据并行的模式对同一组参数进行训练，应用自研参数服务器对超大规模稠密参数进行训练，训练和预估的架构互相拆散。右侧一类模型，单体模型绝对简略，数据量和业务粒度繁多，按不同业务粒度进行数据划分，别离建模，由流式计算框架来驱动数据流转，做到训练和预估的架构一体。 基于在线服务和离线训练的架构差别，少数模型零碎会是这种在线和离线拆散的零碎状态。 训练过程是基于 Tensorflow、Pytorch 进行一层封装。 样本生产和预处理，是基于 Flink 构建出的样本链路框架，其中很多在线业务的特色，源于线上服务的 Featurelog 特色日志；模型训练和样本生产形成了离线局部， 依赖一些公共的根底组件比方 Hive、Kafka、HDFS；预估过程基于自研的预估引擎，在 CPU 或 GPU 上进行 Inference 计算，大规模稠密向量由独立的参数服务器提供；特色服务为预估过程提供输出数据，也是由自研的特色服务形成，因为预估时特色起源和训练时不同，有一层对立的特色数据获取接口，以及对应的特色抽取库。 特色抽取和模型预估形成了在线局部和离线局部拆散。 在模型迭代的状态上，对时效有较高要求的模型，个别是先离线应用历史累积的批式数据训练失去 Base 模型，部署上线之后，持续用实时数据流样本在其根底上继续的训练和迭代上线。 因为预估和训练在两套架构下，继续迭代的过程就波及两套架构的交互、数据传递，以及一致性方面的要求。 训练以及预估须要联合数据状态，自主实现容错转移、故障复原的能力。 如何将数据的分布式解决和模型的分布模式联合为一个整体，便于部署和保护，也是一个不易实现的性能。对不同模型，加载和切换预训练参数的模式也难做到对立。 三、基于 Alink 实现在线学习 ...

作者：闻乃松 需要背景 假如有一种数据源（比方CDC binlog Events、Kafka 实时数据流等），须要实时展现时序数据的摄入数量趋势，并能查看任意工夫范畴内的数据分布品质（比方每个字段的数据密度、总取值数量、去重后的数据取值总量等），最小工夫范畴距离为1分钟，最大范畴不限度。展现样例见下图，如何在计算资源无限的状况下（不应用分布式MPP查问引擎等），在可承受的工夫内给出响应。 解决方案 思考到查问工夫范畴不限，数据摄入速率和规模不限，在可承受的工夫内响应查问，必然须要提前物化查问后果。梳理指标，能够将这些指标分为两类：可物化的指标和不可物化的指标。 可物化的指标 指能够提前预计算的指标，包含密度散布（字段不为空的数量占总记录Events的比例）、总Events数量、最早解决工夫、最晚解决工夫等不可物化的指标 指不能提前预计算的指标，这里次要是distinct去重值数量先说可物化的指标，因为数据指标查问最小1分钟，因而能够应用Flink Window机制：先在内存窗口暂存1分钟数据，当工夫窗口过期，触发数据指标的统计和输入。大范畴工夫的指标基于分钟级的指标汇总得出。总体方案如下图： 整个过程包含以下几个外围局部： 内部数据源的接入和数据解析 内部数据源反对多种，比方mysql、Kafka、S3等，数据格式也多种多样，比方JSON、CSV、AVRO等，数据解析将源格局解析成规范化的关系记录格局（含Schema）。实时指标计算 基于Flink 的Window实时统计是整个流程的外围，实现分布式并行统计和后果汇总。指标存储和查问 实践上每分钟1条统计后果，数据总量不算大，然而思考到这样的实时统计作业会很多，因而一种反对可扩大的分布式存储系统显得至关重要，因为Iceberg数据湖存储框架轻量，不引入新的存储系统，是本方案设计的选项之一。另外，Iceberg反对SDK查问形式，在计算资源和查问资源无限，满足响应工夫的状况下，能够在单JVM线程中运行查问。具体设计与实现 内部数据源的接入和数据解析 这里以Kafka JSON格局数据接入为例阐明： KafkaSource<MetaAndValue> kafkaSource = KafkaSource.<ObjectNode>builder() .setBootstrapServers(servers) .setGroupId(DataSinkIcebergJob.class.getName()) .setTopics(topic) .setDeserializer(recordDeserializer) .setStartingOffsets(OffsetsInitializer.earliest()) .setBounded(OffsetsInitializer.latest()) .setProperties(properties) .build();示例中依照String反序列形式将Kafka字节数据反序列化为String Json格局，设置从分区起始地位拉取，并在达到最新地位进行。 数据解析将JSON的每个Field依照所在path展平成一维关系型记录数据，比方上面的一条JSON数据，通过展平后存储在Map中的成果： 将原始JSON字段path用下划线连接起来，同时增加一些Kafka的元数据字段（topic,offset,partition）和额定的解决工夫字段（processing），如下图所示： 实时指标计算 实时指标计算拓扑构造如下所示，分为并行计算局部和汇总计算两局部： 其中并行计算局部将ParseResult类型的数据流依照字段维度进行统计，每个字段别离统计最大值、最小值、不为空的记录数量、字段类型。另外分钟级的统计指标还包含整体性的指标，如本统计周期的开始工夫、完结工夫、胜利解析的事件数量和解析失败的事件数量等。 //将原始JSON数据流转换为解析后果流DataStream<ParseResult> parseResultStream = sourceStream.transform("ParseResultStreamOperator", TypeInformation.of(ParseResult.class), new ParseResultStreamOperator()).rebalance(); //将解析后果流依照分钟级窗口划分ProcessWindowFunction processWindowFunction = new StatProcessWindowsFunction();SingleOutputStreamOperator<Map<String, Object>> wndStream = parseResultStream.keyBy(pr -> pr.getProcessingTime() % 1000) .window(TumblingProcessingTimeWindows.of(Time.minutes(1))) //设置工夫窗口 .process(processWindowFunction);计算结果款式： 图中的failEventCount示意本统计周期内的解析失败数量，statPeriodEnd示意本统计周期的开始工夫（窗口开始工夫），其余Map类型的字段存储本字段的统计信息，如本统计周期内的最大、最小值。 ...

作者：闻乃松 应用Flink实时生产kafka数据时候，波及到offset的状态保护，为了保障Flink作业重启或者运行时的Operator级别的失败重试，如果要做到“断点续跑”，须要Flink的Checkpoint的反对。问题是，如果简略的开启Flink的Checkpoint机制，而不须要额定的编码工作，是否能达到目标？为答复该问题，本文首先要钻研Flink的Checkpoint的解决机制，而后再看Flink是否反对Kafka的状态存储，于是本文分以下四个局部： Flink Checkpoint 状态快照（snapshotState）次要流程Flink Checkpoint 状态初始化（initializeState）次要流程Kafka Source Operator 对Flink Checkpoint实现Kafka Source Operator状态复原为了精确形容起见，本文以Flink 1.12.x版本，Kafka客户端版本2.4.x为例阐明。 Flink Checkpoint 状态快照（snapshotState）次要流程 咱们已知 Flink Checkpoint由CheckpointCoordinator周期性发动，它通过向相干的tasks发送触发音讯和从各tasks收集确认音讯（Ack）来实现checkpoint。这里省略CheckpointCoordinator发动调用逻辑解析，直奔音讯受体TaskExecutor，来看Checkpoint的执行流程，在TaskExecutor中获取Task实例，触发triggerCheckpointBarrier： TaskExecutor.class @Override public CompletableFuture<Acknowledge> triggerCheckpoint( ExecutionAttemptID executionAttemptID, long checkpointId, long checkpointTimestamp, CheckpointOptions checkpointOptions) { ... final Task task = taskSlotTable.getTask(executionAttemptID); if (task != null) { task.triggerCheckpointBarrier(checkpointId, checkpointTimestamp, checkpointOptions); return CompletableFuture.completedFuture(Acknowledge.get()); ... } }Task是在TaskExecutor中的调度执行单元，也响应Checkpoint申请： Task.class public void triggerCheckpointBarrier( final long checkpointID, final long checkpointTimestamp, final CheckpointOptions checkpointOptions) { ... final CheckpointMetaData checkpointMetaData = new CheckpointMetaData(checkpointID, checkpointTimestamp); invokable.triggerCheckpointAsync(checkpointMetaData, checkpointOptions); ... }其中的看点是invokable，为AbstractInvokable类型的对象，依据调用类动静实例化： ...

实现批处理的技术许许多多，从各种关系型数据库的sql解决，到大数据畛域的MapReduce，Hive，Spark等等。这些都是解决无限数据流的经典形式。而Flink专一的是有限流解决，那么他是怎么做到批处理的呢？ 有限流解决：输出数据没有止境；数据处理从以后或者过来的某一个工夫 点开始，继续不停地进行 另一种解决模式叫作无限流解决，即从某一个工夫点开始解决数据，而后在另一个工夫点完结。输出数据可能自身是无限的（即输出数据集并不会随着工夫增长），也可能出于剖析的目标被人为地设定为无限集（即只剖析某一个时间段内的事件）。 显然，无限流解决是有限流解决的一种非凡状况，大数据培训它只不过在某个工夫点进行而已。此外，如果计算结果不在执行过程中间断生成，而仅在开端处生成一次，那就是批处理（分批解决数据）。 批处理是流解决的一种十分非凡的状况。在流解决中，咱们为数据定义滑 动窗口或滚动窗口，并且在每次窗口滑动或滚动时生成后果。批处理则不同，咱们定义一个全局窗口，所有的记录都属于同一个窗口。举例来说， 以下代码示意一个简略的Flink 程序，它负责每小时对某网站的访问者计数，并依照地区分组。 val counts = visits.keyBy(“region”).timeWindow(Time.hours(1)).sum(“visits”)如果晓得输出数据是无限的，则能够通过以下代码实现批处理。 val counts = visits.keyBy(“region”).window(GlobalWindows.create).trigger(EndOfTimeTrigger.create).sum(“visits”) Flink 的不寻常之处在于，它既能够将数据当作有限流来解决，也能够将它当作无限流来解决。Flink 的 DataSet API 就是专为批处理而生的，如下所示。 val counts = visits.groupBy(“region”).sum(“visits”) 如果输出数据是无限的，那么以上代码的运行后果将与前一段代码的雷同， 然而它对于习惯应用批处理器的程序员来说更敌对。 Fink批处理模型 Flink 通过一个底层引擎同时反对流解决和批处理 在流解决引擎之上，Flink 有以下机制： 检查点机制和状态机制：用于实现容错、有状态的解决；水印机制：用于实现事件时钟；窗口和触发器：用于限度计算范畴，并定义出现后果的工夫。在同一个流解决引擎之上，Flink 还存在另一套机制，用于实现高效的批处理。 用于调度和复原的回溯法：由 Microsoft Dryad 引入，当初简直用于所有批处理器；用于散列和排序的非凡内存数据结构：能够在须要时，将一部分数据从内存溢出到硬盘上；优化器：尽可能地缩短生成后果的工夫。两套机制别离对应各自的API（DataStream API 和 DataSet API）；在创立 Flink 作业时，并不能通过将两者混合在一起来同时 利用 Flink 的所有性能。 在最新的版本中，Flink 反对两种关系型的 API，Table API 和 SQL。这两个 API 都是批处理和流解决对立的 API，这意味着在无边界的实时数据流和有边界的历史记录数据流上，关系型 API 会以雷同的语义执行查问，并产生雷同的后果。Table API 和 SQL 借助了 Apache Calcite 来进行查问的解析，校验以及优化。它们能够与 DataStream 和 DataSet API 无缝集成，深圳大数据培训并反对用户自定义的标量函数，聚合函数以及表值函数。 ...

本文是字节跳动数据平台开发套件团队在1月9日Flink Forward Asia 2021: Flink Forward 峰会上的演讲分享，将着重分享Flink在字节跳动数据流的实际。 字节跳动数据流的业务背景数据流解决的次要是埋点日志。埋点，也叫Event Tracking，是数据和业务之间的桥梁，是数据分析、举荐、经营的基石。 用户在应用App、小程序、Web等各种线上利用时产生的行为，次要通过埋点的模式进行采集上报，按不同的起源分为客户端埋点、Web端埋点、服务端埋点。 不同起源的埋点都通过数据流的日志采集服务接管到MQ，而后通过一系列的Flink实时ETL对埋点进行数据标准化、数据荡涤、实时风控反作弊等解决，最终散发到上游，次要的上游包含ABTest、举荐、行为剖析零碎、实时数仓、离线数仓。 所以，如果用一句话来概括数据流次要业务，其实就是埋点的收集、荡涤、散发。 目前在字节跳动，荡涤和散发环节是基于Flink搭建的。 01 - 数据流业务规模业务数量：在 字节跳动，包含抖音、今日头条、西瓜视频、番茄小说在内的3000多个大大小小的APP和服务都接入了数据流。援用数据流峰值流量：以后，字节跳动埋点数据流峰值流量超过1亿每秒，每天解决超过万亿量级埋点，PB级数据存储增量。援用ETL工作规模：目前，字节跳动数据流在多个机房部署超过1000个Flink工作和超过1000个MQ Topic，应用超过50W Core CPU，单任务最大12W Core CPU ，Topic最大10000 Partitio。02 - 数据流业务挑战字节跳动数据流ETL遇到的挑战次要有四点： 第一点，流量大，工作规模大。援用第二点，处在所有产品数据链路最上游，上游业务多，ETL需要变动频繁。援用第三点，高SLA要求，上游举荐、实时数仓等业务对稳定性和时效性有比拟高的要求。援用最初一点，在流量大、业务多、SLA要求高的状况下，针对流量、老本、SLA保障等多维度的综合治理也面临挑战。援用上面从两个数据流业务场景中介绍一下咱们遇到的业务挑战。1、UserAction ETL场景 在UserAction ETL场景中，咱们遇到的外围需要是：品种繁多且流量微小的客户端埋点需要和ETL规定动静更新的需要。 在字节外部，客户端的埋点品种繁多且流量微小，而举荐关注的只是局部埋点，因而为了晋升上游举荐零碎解决效率，会在数据流配置一些ETL规定，对埋点进行过滤，并对字段进行删减、映射、标准化之类的荡涤解决，将埋点打上不同的动作类型标识。 解决之后的埋点个别称之为UserAction，UserAction数据会和服务端展示等数据在举荐Joiner工作的分钟级窗口中进行拼接Join，产出Instance训练样本。 举个例子：一个客户端的文章点赞埋点形容了用户在一个工夫点对某一篇文章进行了点赞操作，埋点通过数据流日志采集服务进入数据流ETL链路，通过UserAction ETL解决后实时地进入到举荐Joiner工作中拼接生成样本更新举荐模型，从而晋升用户体验。 如果产出UserAction数据的ETL链路呈现比拟大的提早，那么就不能在窗口内及时实现拼接，可能导致用户体验降落。 因而对于举荐来说，数据流的时效性是一个强需要。 而举荐模型的迭代、产品埋点的变动都可能导致UserAction的ETL规定的变动。如果ETL规定硬编码在代码中，每次批改都须要降级代码并重启Flink Job，会影响数据流稳定性和数据的时效性。因而，这个场景的另一个需要就是ETL规定的动静更新。 2、数据分流场景 目前，抖音业务的埋点Topic晚顶峰流量超过1亿/秒，而上游电商、直播、短视频等不同业务的实时数仓关注的埋点范畴实际上都只是其中的一小部分。 如果各业务别离应用一个Flink工作，生产抖音埋点Topic，过滤生产各自关注的埋点，须要耗费大量Yarn资源，同时会造成MQ集群带宽扇出重大，影响MQ集群的稳定性。 因而，数据流提供了数据分流服务，应用一个Flink工作生产上游埋点Topic，而后通过配置规定的形式，将各业务关注的埋点分流到上游小Topic中，再提供给各个业务生产。这样就缩小了不必要的反序列化开销，同时升高了MQ集群带宽扇出比例。 在数据分流场景中，外围须要解决的是高稳固的SLA。因为断流、数据提早可能会影响举荐成果、广告支出、实时数据报表。 同时随着业务倒退，实时数据需要日益减少，分流规定新增和批改也会日益频繁。如果每次规定变动都须要批改代码并重启Flink Job，会影响很多上游，因而分流规定的动静更新也是这一场景中的强需要。 字节跳动数据流实际01-数据流ETL链路建设字节跳动数据流ETL链路建设次要经验了三个阶段： 第一阶段是2018年以前业务需要疾速迭代的晚期阶段 次要应用PyJStorm和基于Python的规定引擎构建次要的流式数据处理链路。其特点是比拟灵便，能够疾速反对业务需要。 但随着埋点流量疾速上涨，PyJStorm暴露出很多稳定性和运维上的问题，性能也不足以撑持业务的增长。 2018年，公司外部开始大力推广Flink，并且针对大量旧工作应用PyJStorm的状况，提供了PyJStorm到PyFlink的兼容适配。流式工作托管平台的建设肯定水平上解决了流式工作运维治理的问题。数据流ETL链路也在2018年全面迁徙到了PyFlink，进入了流式计算的新时代。 第二个阶段是2018至2020年 随着流量的进一步上涨，PyFlink和Kafka的性能瓶颈、以及JSON数据格式带来的性能和数据品质问题都一一显现出来，与此同时上游业务对提早、数据品质的敏感水平却是一劳永逸。 于是，咱们一方面对一些痛点进行了针对性的优化。另一方面，破费1年多的工夫将整个ETL链路从PyFlink切换到了Java Flink，应用基于Groovy的规定引擎替换了基于Python的规定引擎，应用ProtoBuf替换了JSON。 数据流ETL新链路，相比旧链路性能晋升了1倍。 与此同时，一站式大数据开发平台和流量平台的建设晋升了数据流在工作开发运维、ETL规定治理、埋点元数据管理、多机房容灾降级等多方面的能力。 第三个阶段是从2021年开始 在寰球资源供给缓和的背景下，进一步晋升数据流ETL性能和稳定性，满足流量增长和需要增长的同时，升高资源老本和运维老本，是这一阶段的次要指标。咱们次要从三个方面进行了优化： 优化引擎性能。随着流量和ETL规定的一直减少，基于Groovy的规定引擎应用的资源也一直减少，于是咱们基于Janino进行了重构，引擎性能失去数倍晋升。优化埋点治理体系。咱们基于流量平台建设了一套比较完善的埋点治理体系，通过无用埋点下线、埋点采样等伎俩升高埋点老本。优化链路。咱们进行了链路分级，不同等级的链路保障不同的SLA，在资源有余的状况下优先保障高优埋点链路。从2018年到2020年，咱们继续在数据流Flink ETL Job应答需要挑战上获得了一些实际成果。下图展现了数据流Flink ETL Job是如何反对动静更新的，在不重启工作的状况下，实时更新上下游Schema、规定解决逻辑、批改路由拓扑。 流量平台Config Center为数据流Flink ETL Job提供上下游数据集拓扑关系、Schema、ETL规定和UDF等元数据。 数据流Flink ETL Job中的每个TaskManager中会有一个Meta Updater更新线程，更新线程每分钟通过RPC申请从流量平台拉取并更新相干元数据。 Source将从MQ中生产到的数据传入ProcessFunction，依据MQ对应的Schema反序列化为InputMessage，而后进入规定引擎中，通过规定索引匹配出须要运行的规定，每条规定形象为一个Filter模块和一个action模块，Filter和action都反对UDF ，Filter筛选命中后，通过action模块对输出数据进行字段映射和荡涤，而后写出到OutputMessage中。 ...

作者 | 蔡芳芳 采访嘉宾 | 王峰（莫问） 维基百科的 “Apache Flink” 词条下，有这么一句形容：“Flink 并不提供本人的数据存储系统，但为 Amazon Kinesis、Apache Kafka、Alluxio、HDFS、Apache Cassandra 和 Elasticsearch 等零碎提供了数据源和接收器”，很快，这句话的前半句或者将不再实用。残缺视频：https://developer.aliyun.com/... 2021 年初，在 InfoQ 编辑部策动的全年技术趋势瞻望中，咱们提到大数据畛域将减速拥抱“交融”（或“一体化”）演进的新方向。实质是为了升高大数据分析的技术复杂度和老本，同时满足对性能和易用性的更高要求。现在，咱们看到风行的流解决引擎 Apache Flink（下称 Flink）沿着这个趋势又迈出了新的一步。 1 月 8 日上午，Flink Forward Asia 2021 以线上会议的模式拉开帷幕。往年是 Flink Forward Asia（下文简称 FFA）落地中国的第四个年头，也是 Flink 成为 Apache 软件基金会顶级我的项目的第七年。随同着实时化浪潮的倒退和深入，Flink 已逐渐演进为流解决的领军角色和事实标准。回顾其演进历程，Flink 一方面继续优化其流计算外围能力，一直进步整个行业的流计算解决规范，另一方面沿着流批一体的思路逐步推进架构革新和利用场景落地。但在这些之外，Flink 长期倒退还须要一个新的突破口。 在 Flink Forward Asia 2021 的主题演讲中，Apache Flink 中文社区发起人、阿里巴巴开源大数据平台负责人王峰（花名莫问）重点介绍了 Flink 在流批一体架构演进和落地方面的最新进展，并提出了 Flink 下一步的倒退方向——流式数仓（Streaming Warehouse，简称 Streamhouse）。正如主题演讲题目“Flink Next, Beyond Stream Processing”所言，Flink 要从 Stream Processing 走向 Streaming Warehouse 去笼罩更大的场景，帮忙开发者解决更多问题。而要实现流式数仓的指标，就意味着 Flink 社区要拓展适宜流批一体的数据存储，这是 Flink 往年在技术方面的一个翻新，社区相干工作曾经在 10 月份启动，接下来这会作为 Flink 社区将来一年的一个重点方向来推动。 ...

Flink Forward Asia 2021 行将于 1 月 8 日开启，除了 80+ 干货议题，还有哪些内容值得关注？本文带你一探到底！次要内容包含： 大会直播圆桌论坛有奖问答HackathonFlink 中文学习网站https://flink-learning.org.cn 大会直播 1 月 8-9 日，Flink Forward Asia 2021 行将重磅启动。作为开源大数据畛域的顶级盛会之一，Flink Forward 继续集结最佳行业实际以及 Flink 最新技术动静，并踊跃拥抱生态搭档，共建凋敝开源大数据生态。 其中，阿里巴巴、腾讯、戴尔、字节跳动、快手、网易、工商银行、蔚来、挪动、联通、BIGO 等寰球 40+ 多行业一线厂商，将在以下专场分享 80+ 干货议题： 主会场、Flink 核心技术、行业实际、平台建设、实时数据湖、实时数仓、流批一体、开源解决方案、生产实践、机器学习。 大会议程详见官网： https://flink-forward.org.cn 大会线上观看地址 (记得点击预约直播哦) ： https://developer.aliyun.com/... 圆桌论坛 FFA 组委会特邀多位行业大咖，以圆桌论坛的模式畅聊 Flink 和实时计算的将来倒退，探讨波及诸多开发者和社区搭档高度关注的问题，比方： Flink 在实时计算方面是否已趋于成熟？如何对待 Flink 与生态我的项目之间的关系？实时计算的将来应该是什么样的？如何对待外部技术实际、技术创新与开源社区之间的关系？精彩内容领先看～ https://www.bilibili.com/vide... (FFA 组委会特邀多位行业大咖，以圆桌论坛的模式畅聊 Flink 和实时计算的将来倒退。) 有奖问答为了更好地拉近 FFA 观众与讲师的间隔，进步互动性，咱们开设了 FFA 有奖问答流动，为观众和讲师之间搭建了线上沟通的桥梁。参加发问还有机会取得 FFA 定制礼品哦～ FFA 2021 有奖问答入口： https://developer.aliyun.com/... 在直播窗口下方也能够找到跳转入口，具体步骤如下： Hackathon本次 Flink Forward Asia Hackathon 为开放式命题，以实时计算为主题，以 Flink 为工具，解决大家日常学习和工作中遇到的理论问题。能够是气象预测、城市交通管理、金融交易监察这样关乎国计民生的选题；也能够是晋升购物体验、加强游戏互动性、集体静止治理、社交等改善生活中琐碎点滴的选题；还能够是对 Flink 自身的翻新和改良。 ...

背景 日志零碎接入的日志品种多、格局简单多样，支流的有以下几种日志： filebeat采集到的文本日志，格局多样winbeat采集到的操作系统日志设施上报到logstash的syslog日志接入到kafka的业务日志以上通过各种渠道接入的日志，存在2个次要的问题： 格局不对立、不标准、标准化不够如何从各类日志中提取出用户关怀的指标，开掘更多的业务价值为了解决下面2个问题，咱们基于flink和drools规定引擎做了实时的日志解决服务。 零碎架构 架构比较简单，架构图如下：各类日志都是通过kafka汇总，做日志直达。 flink生产kafka的数据，同时通过API调用拉取drools规定引擎，对日志做解析解决后，将解析后的数据存储到Elasticsearch中，用于日志的搜寻和剖析等业务。 为了监控日志解析的实时状态，flink会将日志解决的统计数据，如每分钟解决的日志量，每种日志从各个机器IP来的日志量写到Redis中，用于监控统计。 模块介绍 零碎我的项目命名为eagle。 eagle-api：基于springboot，作为drools规定引擎的写入和读取API服务。 eagle-common：通用类模块。 eagle-log：基于flink的日志解决服务。 重点讲一下eagle-log： 对接kafka、ES和Redis 对接kafka和ES都比较简单，用的官网的connector（flink-connector-kafka-0.10和flink-connector-elasticsearch6），详见代码。 对接Redis，最开始用的是org.apache.bahir提供的redis connector，起初发现灵便度不够，就应用了Jedis。 在将统计数据写入redis的时候，大数据培训最开始用的keyby分组后缓存了分组数据，在sink中做统计解决后写入，参考代码如下： String name = "redis-agg-log"; DataStream<Tuple2<String, List<LogEntry>>> keyedStream = dataSource.keyBy((KeySelector<LogEntry, String>) log -> log.getIndex()) .timeWindow(Time.seconds(windowTime)).trigger(new CountTriggerWithTimeout<>(windowCount, TimeCharacteristic.ProcessingTime)) .process(new ProcessWindowFunction<LogEntry, Tuple2<String, List<LogEntry>>, String, TimeWindow>() { @Override public void process(String s, Context context, Iterable<LogEntry> iterable, Collector<Tuple2<String, List<LogEntry>>> collector) { ArrayList<LogEntry> logs = Lists.newArrayList(iterable); if (logs.size() > 0) { collector.collect(new Tuple2(s, logs)); } } }).setParallelism(redisSinkParallelism).name(name).uid(name);起初发现这样做对内存耗费比拟大，其实不须要缓存整个分组的原始数据，只须要一个统计数据就OK了，优化后： ...

作者：罗宇侠 本篇教程将展现如何应用 Flink CDC 构建实时数据湖，并解决分库分表合并同步的场景。Flink-CDC 我的项目地址： https://github.com/ververica/... Flink 中文学习网站https://flink-learning.org.cn 在 OLTP 零碎中，为了解决单表数据量大的问题，通常采纳分库分表的形式将单个大表进行拆分以进步零碎的吞吐量。 然而为了不便数据分析，通常须要将分库分表拆分出的表在同步到数据仓库、数据湖时，再合并成一个大表。 这篇教程将展现如何应用 Flink CDC 构建实时数据湖来应答这种场景，本教程的演示基于 Docker，只波及 SQL，无需一行 Java/Scala 代码，也无需装置 IDE，你能够很不便地在本人的电脑上实现本教程的全部内容。 接下来将以数据从 MySQL 同步到 Iceberg [1] 为例展现整个流程，架构图如下所示： 一、筹备阶段筹备一台曾经装置了 Docker 的 Linux 或者 MacOS 电脑。 1.1 筹备教程所须要的组件接下来的教程将以 docker-compose 的形式筹备所须要的组件。 应用上面的内容创立一个 docker-compose.yml 文件： version: '2.1'services: sql-client: user: flink:flink image: yuxialuo/flink-sql-client:1.13.2.v1 depends_on: - jobmanager - mysql environment: FLINK_JOBMANAGER_HOST: jobmanager MYSQL_HOST: mysql volumes: - shared-tmpfs:/tmp/iceberg jobmanager: user: flink:flink image: flink:1.13.2-scala_2.11 ports: - "8081:8081" command: jobmanager environment: - | FLINK_PROPERTIES= jobmanager.rpc.address: jobmanager volumes: - shared-tmpfs:/tmp/iceberg taskmanager: user: flink:flink image: flink:1.13.2-scala_2.11 depends_on: - jobmanager command: taskmanager environment: - | FLINK_PROPERTIES= jobmanager.rpc.address: jobmanager taskmanager.numberOfTaskSlots: 2 volumes: - shared-tmpfs:/tmp/iceberg mysql: image: debezium/example-mysql:1.1 ports: - "3306:3306" environment: - MYSQL_ROOT_PASSWORD=123456 - MYSQL_USER=mysqluser - MYSQL_PASSWORD=mysqlpwvolumes: shared-tmpfs: driver: local driver_opts: type: "tmpfs" device: "tmpfs"该 Docker Compose 中蕴含的容器有： ...

本文作者俞航翔&李钰，具体阐明了 Log4j2 Zero Day 破绽的影响，以及 Flink 社区的应答计划。次要内容包含： 破绽阐明Flink 用户可能受到的影响受影响的 Flink 版本和长期解决方案Flink 社区修复打算概述Apache Log4j 是基于 Java 的日志记录工具，Apache Log4j2 重写了 Log4j 并减少了很多丰盛的个性。最近，由阿里云平安报告了 Apache log4j2 的 Zero Day 破绽[1]，基于该破绽，攻击者能够结构歹意申请，触发近程代码执行破绽，目前该破绽被 CVE-2021-44228[2] 追踪。Log4j 团队在发现该问题后马上公布了 2.15.0 版本，并给出了长期解决方案。 12 月 14 日，来自 Twitter 公司的团队发现并且报告了一个新的破绽问题：CVE-2021-45046[17]。该破绽示意 2.15.0 中对 CVE-2021-44228 的修复以及给出的长期解决方案并不齐备，在某些配置条件下仍然会被利用导致 DOS 攻打。随后 Log4j 团队又公布了 2.16.0 版本，并举荐受影响的软件降级至该版本，同时给出了新的长期解决方案。 上述破绽的影响版本范畴为 2.0-beta9 <= log4j2 <= 2.12.1 和 2.13.0 <= log4j2 <= 2.15.0。Apache Flink 在 1.10 及以前的版本中应用的是 Log4j 1.x 版本，能够认为不受影响。而 1.11 及以上版本中应用了 Log4j 2.x 版本，且均在受影响范畴内。 ...

本文作者为中国农业银行研发核心丁杨，在 Flink CDC 2.1 版本公布后第一工夫下载应用，并胜利实现了对 Oracle 的实时数据捕捉以及性能调优，现将试用过程中的一些要害细节进行分享。次要内容包含： 无奈连贯数据库无奈找到 Oracle 表数据提早较大调节参数持续升高数据提早Debezium Oracle Connector 的暗藏参数Flink CDC 于 2021 年 11 月 15 日公布了最新版本 2.1，该版本通过引入内置 Debezium 组件，减少了对 Oracle 的反对。笔者第一工夫下载了该版本进行试用并胜利实现了对 Oracle 的实时数据捕捉以及性能调优，现将试用过程中的一些要害细节进行分享。 阐明：本文力求依据理论的问题排查教训，以及外部执行原理分享一些 “干货”，所以对 Flink CDC，以及其内置的 Debezium 模块的根底应用办法并未波及，对于根底的应用办法、参数等，读者可参考以下地址： Flink CDC： https://ververica.github.io/f... Debezium： https://debezium.io/documenta... 试用环境： Oracle：11.2.0.4.0（RAC 部署） Flink：1.13.1 Hadoop：3.2.1 通过 Flink on Yarn 形式部署应用 一、无奈连贯数据库依据官网文档阐明，在 Flink SQL CLI 中输出以下语句： create table TEST (A string)WITH ('connector'='oracle-cdc', 'hostname'='10.230.179.125', 'port'='1521', 'username'='myname', 'password'='***', 'database-name'='MY_SERVICE_NAME', 'schema-name'='MY_SCHEMA', 'table-name'='TEST' );之后尝试通过 select * from TEST 察看，发现无奈失常连贯 Oracle，报错如下： ...

Flink 中文学习网站https://flink-learning.org.cn 前言随着云数仓技术的一直成熟，数据湖俨然已成为当下最热门的技术之一，而 Apache Hudi 是当下最具竞争力的数据湖格局之一： 领有最沉闷的开源社区之一，周沉闷 PR 始终维持在 50+ 程度；领有最沉闷的国内用户群之一，目前的 Apache Hudi 钉钉群用户已超过 2200+，国内各大厂商都曾经布局 Apache Hudi 生态。Apache Hudi 的活跃度得益于其杰出的 file format 设计和丰盛的事物语义反对： 类 LSM 的 file format 布局很好的适配了近实时更新场景，解决了超大数据集更新的痛点；Hudi 的事物层语义在目前的湖存储中是极其成熟和丰盛的，根本所有的数据治理都能够自动化实现：compaction、rollback、cleaning、clustering。Flink On HudiApache Hudi 的 table format 对流计算敌对的个性使得 Flink On Hudi 成为 Apache Hudi 我的项目最值得摸索和开掘的方向之一，Flink 不仅为 Hudi 解锁了超大数据流的实时更新能力、更增加了流式生产和计算的能力，让端到端近实时 ETL 得以在低成本的文件存储上轻松实现。 Flink On Hudi 我的项目在 2020 年 11 月立项，至今已迭代了三个版本，从第一个版本开始人气和活跃度就始终低落。5 月份组建的 Apache Hudi 钉钉群截止目前半年的工夫，曾经有超过 2200+ 用户，并且活跃度始终排在 Flink 用户群的前列。 Flink On Hudi 已成为部署 Apache Hudi 我的项目的首选计划，国内次要云厂商：阿里云、华为云、腾讯云，国外的 AWS 都已集成 Flink On Hudi；国内的大型互联网公司：头条、快手、B站 以及传统企业：顺丰、海康等均有 Flink On Hudi 的生产实践，具钉钉群的跟踪回访等不齐全统计，至多超过 50+ 国内公司在生产上应用 Flink On Hudi，Uber 公司更将 Flink On Hudi 作为 2022 年的重点方向在推动 ！ ...

1. 简介SqlClient 是 Flink 提供的一个 SQL 命令行交互工具，在下载 flink 二进制包时，在其 bin 目录下有一个 sql-client.sh，通过启动该脚本就能够进入交互页面。SqlClient 的具体源码实现在 flink-table 模块的 flink-sql-client 子模块下能够找到，其启动函数在 org/apache/flink/table/client/SqlClient.java 中，该启动函数在创立好交互环境后，会调用 CliClient 的 open 函数，进入一个死循环： public void open() { isRunning = true; // print welcome terminal.writer().append(CliStrings.MESSAGE_WELCOME); // begin reading loop while (isRunning) { // make some space to previous command terminal.writer().append("\n"); terminal.flush(); final String line; try { // 1. 读取用户输出（以“;”为终结符） line = lineReader.readLine(prompt, null, (MaskingCallback) null, null); } catch (UserInterruptException e) { // user cancelled line with Ctrl+C continue; } catch (EndOfFileException | IOError e) { // user cancelled application with Ctrl+D or kill break; } catch (Throwable t) { throw new SqlClientException("Could not read from command line.", t); } if (line == null) { continue; } // 2. 调用 parseCommand 解析用户输出，获取相应的命令 final Optional<SqlCommandCall> cmdCall = parseCommand(line); // 3. 调用 callCommand 执行命令 cmdCall.ifPresent(this::callCommand); }}2. 解析命令—parseCommand2.1 SqlCommandCallSqlCommandCall 是 SqlCommandParser 的外部类，定义如下： ...

数据仓库有四个根本的特色：面向主题的、集成的、绝对稳固的、反映历史变动的。其中数据集成是数据仓库构建的首要前提，指将多个扩散的、异构的数据源整合在一起以便于后续的数据分析。将数据集成过程平台化，将极大晋升数据开发人员的效率。本文次要内容为： 数据集成 VS 数据同步集成需要数据集成 V1数据集成 V2线上成果总结Flink 中文学习网站https://flink-learning.org.cn A data warehouse is a subject-oriented, integrated, nonvolatile, and time-variant collection of data in support of management’s decisions. —— Bill Inmon 一、数据集成 VS 数据同步「数据集成」往往和「数据同步」在概念上存在肯定的混同，为此咱们对这二者进行了辨别。 「数据集成」特指面向数据仓库 ODS 层的数据同步过程，「数据同步」面向的是一般化的 Source 到 Sink 的数据传输过程。二者的关系如下图所示： 「数据同步平台」提供根底能力，不掺杂具体的业务逻辑。「数据集成平台」是构建在「数据同步平台」之上的，除了将原始数据同步之外还蕴含了一些聚合的逻辑（如通过数据库的日志数据对快照数据进行复原，下文将会具体开展）以及数仓标准相干的内容（如数仓 ODS 层库表命名标准）等。目前「数据同步平台」的建设正在咱们的布局之中，但这并不影响「数据集成平台」的搭建，一些同步的需要可提前在「实时计算平台」创立，以「约定」的形式解耦。 值得一提的是「数据集成」也该当涵盖「数据采集」（由特定的工具反对）和「数据荡涤」（由采集粒度、日志标准等因素决定）两局部内容，这两局部内容各个公司都有本人的实现，本文将不做具体介绍。 二、集成需要目前伴鱼外部数据的集成需要次要体现在三块：Stat Log (业务标准化日志或称统计日志)、TiDB 及 MongoDB。除此之外还有一些 Service Log、Nginx Log 等，此类不具备代表性不在本文介绍。另外，因为实时数仓正处于建设过程中，目前「数据集成平台」只涵盖离线数仓（Hive）。 Stat Log：业务落盘的日志将由 FileBeat 组件收集至 Kafka。因为日志为 Append Only 类型， 因而 Stat Log 集成绝对简略，只需将 Kafka 数据同步至 Hive 即可。DB（TiDB、MongoDB）：DB 数据绝对麻烦，外围诉求是数仓中可能存在业务数据库的镜像，即存在业务数据库中某一时刻（天级 or 小时级）的数据快照，当然有时也有对数据变更过程的剖析需要。因而 DB 数据集成须要将这两个方面都思考进去。因为以上两种类型的数据集成形式差别较大，下文将别离予以探讨。 ...

实现批处理的技术许许多多，从各种关系型数据库的sql解决，到大数据畛域的MapReduce，Hive，Spark等等。这些都是解决无限数据流的经典形式。而Flink专一的是有限流解决，那么他是怎么做到批处理的呢？有限流解决：输出数据没有止境；数据处理从以后或者过来的某一个工夫 点开始，继续不停地进行另一种解决模式叫作无限流解决，即从某一个工夫点开始解决数据，而后在另一个工夫点完结。输出数据可能自身是无限的（即输出数据集并不会随着工夫增长），也可能出于剖析的目标被人为地设定为无限集（即只剖析某一个时间段内的事件）。显然，无限流解决是有限流解决的一种非凡状况，它只不过在某个工夫点进行而已。此外，如果计算结果不在执行过程中间断生成，而仅在开端处生成一次，那就是批处理（分批解决数据）。批处理是流解决的一种十分非凡的状况。在流解决中，咱们为数据定义滑 动窗口或滚动窗口，并且在每次窗口滑动或滚动时生成后果。批处理则不同，咱们定义一个全局窗口，所有的记录都属于同一个窗口。举例来说， 以下代码示意一个简略的Flink 程序，它负责每小时对某网站的访问者计数，并依照地区分组。val counts = visits.keyBy(“region”).timeWindow(Time.hours(1)).sum(“visits”)如果晓得输出数据是无限的，则能够通过以下代码实现批处理。val counts = visits.keyBy(“region”).window(GlobalWindows.create).trigger(EndOfTimeTrigger.create).sum(“visits”)Flink 的不寻常之处在于，它既能够将数据当作有限流来解决，也能够将它当作无限流来解决。Flink 的 DataSet API 就是专为批处理而生的，如下所示。val counts = visits.groupBy(“region”).sum(“visits”)如果输出数据是无限的，那么以上代码的运行后果将与前一段代码的雷同， 然而它对于习惯应用批处理器的程序员来说更敌对。Fink批处理模型Flink 通过一个底层引擎同时反对流解决和批处理在流解决引擎之上，Flink 有以下机制：检查点机制和状态机制：用于实现容错、有状态的解决；水印机制：用于实现事件时钟；窗口和触发器：用于限度计算范畴，并定义出现后果的工夫。在同一个流解决引擎之上，Flink 还存在另一套机制，用于实现高效的批处理。用于调度和复原的回溯法：由 Microsoft Dryad 引入，当初简直用于所有批处理器；用于散列和排序的非凡内存数据结构：能够在须要时，将一部分数据从内存溢出到硬盘上；优化器：尽可能地缩短生成后果的工夫。两套机制别离对应各自的API（DataStream API 和 DataSet API）；在创立 Flink 作业时，并不能通过将两者混合在一起来同时 利用 Flink 的所有性能。在最新的版本中，大数据培训Flink 反对两种关系型的 API，Table API 和 SQL。这两个 API 都是批处理和流解决对立的 API，这意味着在无边界的实时数据流和有边界的历史记录数据流上，关系型 API 会以雷同的语义执行查问，并产生雷同的后果。Table API 和 SQL 借助了 Apache Calcite 来进行查问的解析，校验以及优化。它们能够与 DataStream 和 DataSet API 无缝集成，并反对用户自定义的标量函数，聚合函数以及表值函数。Table API / SQL 正在以流批对立的形式成为剖析型用例的次要 API。DataStream API 是数据驱动应用程序和数据管道的次要API。从久远来看，DataStream API应该通过有界数据流齐全蕴含DataSet API。Flink批处理性能MapReduce、Tez、Spark 和 Flink 在执行纯批处理工作时的性能比拟。测试的批处理工作是 TeraSort 和分布式散列连贯。第一个工作是 TeraSort，即测量为 1TB 数据排序所用的工夫。TeraSort 实质上是分布式排序问题，它由以下几个阶 段组成：(1) 读取阶段：从 HDFS 文件中读取数据分区；(2) 本地排序阶段：对上述分区进行局部排序；(3) 混洗阶段：将数据依照 key 从新散布到解决节点上；(4) 终排序阶段：生成排序输入；(5) 写入阶段：将排序后的分区写入 HDFS 文件。Hadoop 发行版蕴含对 TeraSort 的实现，同样的实现也能够用于 Tez，因为 Tez 能够执行通过MapReduce API 编写的程序。Spark 和 Flink 的 TeraSort 实现由 Dongwon Kim 提供.用来测量的集群由 42 台机器组成，每台机器 蕴含 12 个 CPU 内核、24GB 内存，以及 6 块硬盘。结果显示，Flink 的排序工夫比其余所有零碎都少。MapReduce 用了2157 秒，Tez 用了1887 秒，Spark 用了2171 秒，Flink 则 只用了 1480 秒。第二个工作是一个大数据集（240GB）和一个小数据集（256MB）之间的分布式散列连贯。结果显示，Flink 依然是速度最快的零碎，它所用的工夫别离是 Tez 和 Spark 的 1/2 和 1/4.产生以上后果的总体起因是，Flink 的执行过程是基于流的，这意味着各个解决阶段有更多的重叠，并且混洗操作是流水线式的，因而磁盘拜访操作更少。相同，MapReduce、Tez 和 Spark 是基于批的，这意味着数据在通过网络传输之前必须先被写入磁盘。该测试阐明，在应用Flink 时，零碎闲暇工夫和磁盘拜访操作更少。值得一提的是，性能测试后果中的原始数值可能会因集群设置、配置和软件版本而异。因而，Flink 能够用同一个数据处理框架来解决有限数据流和无限数据流，并且不会就义性能。 ...

本文通过实例来演示怎么通过 Flink CDC 联合 Doris 的 Flink Connector 实现从 Mysql 数据库中监听数据并实时入库到 Doris 数仓对应的表中。次要内容包含： 什么是 CDCFlink CDC什么是 Flink Doris Connector用法示例Flink 中文学习网站https://flink-learning.org.cn 一、什么是 CDCCDC 是变更数据捕捉 (Change Data Capture) 技术的缩写，它能够将源数据库 (Source) 的增量变动记录，同步到一个或多个数据目标 (Sink)。在同步过程中，还能够对数据进行肯定的解决，例如分组 (GROUP BY)、多表的关联 (JOIN) 等。 例如对于电商平台，用户的订单会实时写入到某个源数据库；A 部门须要将每分钟的实时数据简略聚合解决后保留到 Redis 中以供查问，B 部门须要将当天的数据暂存到 Elasticsearch 一份来做报表展现，C 部门也须要一份数据到 ClickHouse 做实时数仓。随着工夫的推移，后续 D 部门、E 部门也会有数据分析的需要，这种场景下，传统的拷贝散发多个正本办法很不灵便，而 CDC 能够实现一份变动记录，实时处理并投递到多个目的地。 CDC 的利用场景数据同步：用于备份，容灾；数据散发：一个数据源分发给多个上游零碎；数据采集：面向数据仓库 / 数据湖的 ETL 数据集成，是十分重要的数据源。CDC 的技术计划十分多，目前业界支流的实现机制能够分为两种： 基于查问的 CDC： 离线调度查问作业，批处理。把一张表同步到其余零碎，每次通过查问去获取表中最新的数据；无奈保障数据一致性，查的过程中有可能数据曾经产生了屡次变更；不保障实时性，基于离线调度存在人造的提早。基于日志的 CDC： 实时生产日志，流解决，例如 MySQL 的 binlog 日志残缺记录了数据库中的变更，能够把 binlog 文件当作流的数据源；保障数据一致性，因为 binlog 文件蕴含了所有历史变更明细；保障实时性，因为相似 binlog 的日志文件是能够流式生产的，提供的是实时数据。二、Flink CDCFlink 在 1.11 版本中新增了 CDC 的个性，简称扭转数据捕捉。名称来看有点乱，咱们先从之前的数据架构来看 CDC 的内容。 ...

作为反对 Flink 流批一体与云原生的重要组成部分，Flink Remote Shuffle 明天正式开源了： https://github.com/flink-exte... Flink Remote Shuffle 是一种批场景下利用内部服务实现工作间数据交换的 Shuffle 实现，本文后续将具体介绍 Flink Remote Shuffle 研发的背景，以及 Flink Remote Shuffle 的设计与应用。 一、为什么须要 Flink Remote Shuffle ?1.1 背景Flink Remote Shuffle 的提出与实现，源自咱们察看到的用户对流批一体与云原生日益减少的需要。 因为实时处理能够大幅晋升用户体验以及减少产品在市场的竞争力，越来越多的用户业务场景中同时蕴含了实时和离线解决需要。如果流解决和批处理采纳不同的框架来实现，将带来用户在框架学习、代码开发与线上运维的诸多不便。同时，对于许多利用场景，因为实时处理受限于提早数据（例如用户可能隔很久才会填写评论）或业务逻辑降级等起因，必须采纳离线工作进行数据勘误，采纳两种不同的框架编写两份代码逻辑很容易产生计算结果不统一的问题。 针对这些问题，Flink 提出了流批一体的数据模型，即用一套 API 来实现实时数据与离线数据的解决。为了反对这一指标，Flink 设计与实现了流批对立的 DataStream API [1] + Table / SQL API [2] + Connector [3][4] ，并在执行层反对流批一体的调度 [5] 与面向批处理进行优化的 Batch 执行模式 [6]。而为了反对 Batch 模式，还须要 Flink 可能实现高效与稳固的 Blocking Shuffle。Flink 内置的 Blocking Shuffle 在上游完结后持续依赖上游所在的 TaskManager 来为上游提供数据读取服务，这将导致 TaskManager 不能立刻开释从而升高资源利用率，并导致 Shuffle 服务的稳定性受 Task 执行稳定性的影响。 ...

本篇教程将展现如何基于 Flink CDC 疾速构建 MySQL 和 Postgres 的流式 ETL。 Flink-CDC 我的项目地址： https://github.com/ververica/... 本教程的演示基于 Docker 环境，都将在 Flink SQL CLI 中进行，只波及 SQL，无需一行 Java/Scala 代码，也无需装置 IDE。 假如咱们正在经营电子商务业务，商品和订单的数据存储在 MySQL 中，订单对应的物流信息存储在 Postgres 中。 对于订单表，为了不便进行剖析，咱们心愿让它关联上其对应的商品和物流信息，形成一张宽表，并且实时把它写到 ElasticSearch 中。 接下来的内容将介绍如何应用 Flink Mysql/Postgres CDC 来实现这个需要，零碎的整体架构如下图所示： 一、筹备阶段筹备一台曾经装置了 Docker 的 Linux 或者 MacOS 电脑。 1.1 筹备教程所须要的组件接下来的教程将以 docker-compose 的形式筹备所须要的组件。 应用上面的内容创立一个 docker-compose.yml 文件： version: '2.1'services: postgres: image: debezium/example-postgres:1.1 ports: - "5432:5432" environment: - POSTGRES_PASSWORD=1234 - POSTGRES_DB=postgres - POSTGRES_USER=postgres - POSTGRES_PASSWORD=postgres mysql: image: debezium/example-mysql:1.1 ports: - "3306:3306" environment: - MYSQL_ROOT_PASSWORD=123456 - MYSQL_USER=mysqluser - MYSQL_PASSWORD=mysqlpw elasticsearch: image: elastic/elasticsearch:7.6.0 environment: - cluster.name=docker-cluster - bootstrap.memory_lock=true - "ES_JAVA_OPTS=-Xms512m -Xmx512m" - discovery.type=single-node ports: - "9200:9200" - "9300:9300" ulimits: memlock: soft: -1 hard: -1 nofile: soft: 65536 hard: 65536 kibana: image: elastic/kibana:7.6.0 ports: - "5601:5601"该 Docker Compose 中蕴含的容器有： ...

本文介绍了汽车之家在基于 Flink 的实时物化视图的一些实践经验与摸索，并尝试让用户间接以批处理 SQL 的思路开发 Flink Streaming SQL 工作。次要内容为： 系统分析与问题拆解问题解决与零碎实现实时物化视图实际限度与有余总结与瞻望 前言物化视图这一性能想必大家都不生疏，咱们能够通过应用物化视图，将事后设定好的简单 SQL 逻辑，以增量迭代的模式实时 (依照事务地) 更新后果集，从而通过查问后果集来防止每次查问简单的开销，从而节省时间与计算资源。事实上，很多数据库系统和 OLAP 引擎都不同水平地反对了物化视图。另一方面，Streaming SQL 自身就和物化视图有着很深的分割，那么基于 Apche Flink (下称 Flink) SQL 去做一套实时物化视图零碎是一件非常自然而然的事件了。 本文介绍了汽车之家 (下称之家) 在基于 Flink 的实时物化视图的一些实践经验与摸索，并尝试让用户间接以批处理 SQL 的思路开发 Flink Streaming SQL 工作。心愿能给大家带来一些启发，独特摸索这一畛域。 一、系统分析与问题拆解Flink 在 Table & SQL 模块做了大量的工作，Flink SQL 曾经实现了一套成熟与绝对齐备的 SQL 零碎，同时，咱们也在 Flink SQL 上有着比拟多的技术和产品积攒，间接基于 Flink SQL 自身就曾经解决了构建实时物化零碎的大部分问题，而惟一一个须要咱们解决的问题是如何不重不漏地生成数据源表对应的语义齐备的 Changelog DataStream，包含增量和全量历史两局部。 尽管规约到只剩一个问题，然而这个问题解决起来还是比拟艰难的，那咱们将这个问题持续拆解为以下几个子问题： 1. 加载全量数据；2. 加载增量数据；3. 增量数据与全量数据整合。二、问题解决与零碎实现问题一：基于数据传输平台的增量数据读取增量数据加载还是绝对比拟好解决的，咱们间接复用实时数据传输平台的根底建设。数据传输平台[1] 曾经将 Mysql / SqlServer / TiDB 等增量数据以对立的数据格式写入到特定的 Kafka Topic 中，咱们只有获取到对应的 Kafka Topic 就能够进行读取即可。 ...

尊敬的各位嘉宾： Flink Forward Asia 2021 大会，原定于 12 月 4-5 日 在北京国家会议核心举办。现为配合疫情防控相干要求，积极响应国家政策，本着对参会嘉宾及合作伙伴的衰弱平安负责，经 FFA 组委会切磋、慎重考虑，大会改为以线上的模式与大家相见，并且日期延后至 2022 年 1 月 8-9 日 (具体以官网为准)。因大会延期给各位嘉宾带来的不便，咱们深表歉意。 作为开源大数据畛域的顶级盛会之一，Flink Forward 继续集结最佳行业实际以及 Flink 最新技术动静，并踊跃拥抱生态搭档，共建凋敝开源大数据生态。 其中，阿里巴巴、腾讯、戴尔、字节跳动、快手、网易、工商银行、蔚来、挪动、联通、BIGO 等寰球 40+ 多行业一线厂商，将在 Flink 核心技术、行业实际、平台建设、实时数据湖、实时数仓等多个时下热门方向，分享 80+ 干货议题，带来专属于开发者的技术盛宴。 本届 FFA 虽转为线上举办，咱们依旧会尽全力出现高质量的内容。并且，以线上的形式进行分享，咱们能够对内容进行更为精准的把控，为开发者们输入更加优质的干货。 Flink Forward Asia，定不负你的期待。 大会官网：https://flink-forward.org.cn/ 大会线上观看地址：https://www.aliyun.com/page-s... 大会工夫：2022 年 1 月 8-9 日 Tips： 进入直播网站，点击右上角 “预约直播”，精彩内容不错过。Flink Forward Asia 大会最终议程以官网颁布信息为准。官网链接 https://flink-forward.org.cn/，点击议题，即可查看议题详情以及讲师介绍。时代的过程浩浩荡荡，咱们一起，把握大数据的潮向，向将来致敬。 Flink Forward Asia 2021 资助与单干首届 Flink Forward Asia Hackathon 正式启动，20W 奖金等你来！详情点击《奖金翻倍！Flink Forward Asia Hackathon 最新参赛指南请查收》 ...

flink集群有jobmanager、taskmanager、client三个角色。jobmanager作用：1.负责接管flink job，将JobGraph转换成ExecutionGraph，最终将Execution Graph拿来运行2.负责管理taskmanager3.负责协调checkpoint4.负责failover故障复原组件：1.Actor system，负责跟taskmanager之间同行 scheduler，负责task任务调度3.Checkpoint Coordinator，负责协调整个checkpoint的过程taskmanager作用：1.负责执行计算工作的节点，每个taskmanager负责管理其所在节点的资源信息，如︰内存、磁盘、网络，在启动时向jobmanager汇报组件：1.Memory & 1/O Manager，即内存I/O的治理2.Network Manager，用来对网络方面进行治理3.Actor system，用来负责网络的通信client1.负责将flink job提交给jobmanager理解更多大数据面试题欢送关注小编大数据培训专栏内容！

首届 Flink Forward Asia Hackathon 曾经正式启动。本次新鲜的开放式命题失去了宽广开发者的关注，目前在 GitHub 上有不少团队曾经提交了参赛我的项目 issue，其中不乏有充斥创意的想法和构思。 为了回馈各位开发者的激情，本次 Flink Forward Asia Hackathon 将会进行奖金追加，全面降级！愿各位开发者都可能获得好问题。 一、奖金降级奖金总额翻倍，让创意发光！ 奖金降级前 奖金降级后 二、彩蛋降级Pravega 鼎力相助，额定奖金等你来！ 本次较量取得了 Pravega 社区（pravega.io）的鼎力支持，如果选手在参赛我的项目中应用 Pravega，将会有 Pravega 的专家提供技术帮忙。同时，最终取得冠军/亚军/季军的队伍如果应用了 Pravega，将会额定取得处分 10000 元。 三、赛程降级赛程缩短，让更多选手能够施展本人的创意！ 四、参赛指南3 步参加，轻松快捷！ Step 1 点击较量主页，注册报名。 报名地址：https://www.aliyun.com/page-s... Step 2 进入 GitHub 专题页，公布计划 issue。 公布地址：https://github.com/flink-chin... Step 3 实现以上操作，即可进入投票环节啦～ 舒适提醒：Apache Flink 社区 Contributor 认可很重要哦！ 本次初赛采纳 Hackathon 评委投票 + Flink 社区投票形式评比。 Hackathon 评委会打分占 50% 权重。取得的 Apache Flink 社区 Contributor 票数占 50% 权重。欢送进入赛事官网理解更多信息： ...

本文作者胡梦宇，知乎大数据架构开发工程师，次要负责知乎外部大数据组件的二次开发和数据平台建设。背景Flink 因为其可靠性和易用性，曾经成为以后最风行的流解决框架之一，在流计算畛域占据了主导地位。早在 18 年知乎就引入了 Flink，倒退到当初，Flink 曾经成为知乎外部最重要的组件之一，积攒了 4000 多个 Flink 实时工作，每天解决 PB 级的数据。 Flink 的部署形式有多种，依据资源调度器来分类，大抵可分为 standalone、Flink on YARN、Flink on Kubernetes 等。目前知乎外部应用的部署形式是 Flink 官网提供的 native Kubernetes。谈到 Kubernetes，就不得不说容器镜像的问题，因为 Flink 工作的依赖多种多样，如何给 Flink 打镜像也是一个比拟头疼的问题。 Flink 镜像及依赖解决Flink 的工作大抵可分为两类，第一类是 Flink SQL 工作，Flink SQL 工作的依赖大抵有以下几种： 官网的 connector JAR 包，如 flink-hive-connector、flink-jdbc-connector、flink-kafka-connector 等;非官方或者是外部实现的 connector JAR 包；用户的 UDF JAR 包，一些简单的计算逻辑，用户可能会本人实现 UDF。第二类 Flink 工作是 Flink 的 jar 包工作，除了以上三种依赖，还须要依赖用户本人写的 Flink jar 程序包。 显然，对于每一个 Flink 工作，它的依赖不尽相同，咱们也不可能为每一个 Flink 工作独自打一个镜像，咱们目前的解决如下： 将依赖进行分类，分为稳固依赖和非稳固依赖；稳固依赖包含组件（如 Flink、JDK 等）以及官网的 connector 包，这类依赖非常稳固，只会在 Flink 版本升级和 bug 修复这两种状况下进行改变，因而咱们会在构建镜像时，将这类依赖打入镜像；非稳固依赖包含第三方的 connector 和用户本人的 JAR 包。第三方的 connector 因为不是 Flink 官网保护，所以出问题须要修复的概率绝对更大；用户本人的 JAR 包对于每个工作来说都不雷同，而且用户会常常改变从新提交。对于这类不稳固的依赖，咱们会动静注入，注入的形式是将依赖存入分布式文件系统，在容器启动的时候，利用 pre command 下载进容器里。通过以上解决，Flink 镜像具备了肯定的动静加载依赖的能力，Flink Job 的启动流程大抵如下： ...

本文作者徐榜江 (雪尽) 以下视频为伍翀 (云邪) 分享的 Flink CDC 前世今生：https://www.bilibili.com/vide... 前言CDC (Change Data Capture) 是一种用于捕获数据库变更数据的技术，Flink 从 1.11 版本开始原生反对 CDC 数据（changelog）的解决，目前曾经是十分成熟的变更数据处理计划。 Flink CDC Connectors 是 Flink 的一组 Source 连接器，是 Flink CDC 的外围组件，这些连接器负责从 MySQL、PostgreSQL、Oracle、MongoDB 等数据库读取存量历史数据和增量变更数据。Flink CDC Connectors 是一个独立的开源我的项目，从去年 7 月份开源以来，社区放弃了相当高速的倒退，均匀两个月一个版本，在开源社区的关注度继续走高，也逐步有越来越多的用户应用 Flink CDC 来疾速构建实时数仓和数据湖。 在往年 7 月份，Flink CDC Maintainer 徐榜江 (雪尽) 在北京的 Flink Meetup 首次分享了 Flink CDC 2.0 的设计。随后的 8 月份，Flink CDC 社区公布 2.0 版本，解决了诸多生产实践上的痛点，Flink CDC 社区的用户群也随之迅速壮大。 除了社区用户群体的迅速扩充，社区的开发者也在疾速减少，目前曾经有国内外多家公司的开发者退出到 Flink CDC 社区的开源共建，有来自北美 Cloudera 的开发者，也有来自欧洲 Vinted，Ververica 的开发者，国内的开发者更加沉闷，有来自腾讯，阿里，字节等互联网公司的开发者，也有来自 XTransfer，新华文轩等守业公司和传统企业的开发者。此外，国内外的多家云厂商，其流计算产品都曾经集成了 Flink CDC，让更多的用户体验到 Flink CDC 的弱小与便捷。 ...

本文介绍 Sort-Shuffle 如何帮忙 Flink 在应答大规模批数据处理工作时更加熟能生巧。次要内容包含： 数据 Shuffle 简介引入 Sort-Shuffle 的意义Flink Sort-Shuffle 实现测试后果调优参数将来瞻望Flink 作为批流一体的大数据计算引擎，大规模批数据处理也是 Flink 数据处理能力的重要组成部分。随着 Flink 的版本迭代，其批数据处理能力也在一直加强，sort-shuffle 的引入，使得 Flink 在应答大规模批数据处理工作时更加熟能生巧。 一、数据 Shuffle 简介数据 shuffle 是批数据处理作业的一个重要阶段，在这一阶段中，上游解决节点的输入数据会被长久化到内部存储中，之后上游的计算节点会读取这些数据并进行解决。这些长久化的数据不仅仅是一种计算节点间的数据交换模式，还在谬误复原中施展着重要作用。 目前，有两种批数据 shuffle 模型被现有的大规模分布式计算零碎采纳，别离是基于 hash 的形式以及基于 sort 的形式： 基于 hash 形式的外围思路是将发送给上游不同并发生产工作的数据写到独自的文件中，这样文件自身就成了一个天然的辨别不同数据分区的边界；基于 sort 形式的外围思路是先将所有分区的数据写在一起，而后通过 sort 来辨别不同数据分区的边界。咱们在 Flink 1.12 版本将基于 sort 的批处理 shuffle 实现引入了 Flink 并在后续进行了继续的性能与稳定性优化；到 Flink 1.13 版本，sort-shuffle 曾经实现生产可用。 二、引入 Sort-Shuffle 的意义咱们之所以要在 Flink 中引入 sort-shuffle 的实现，一个重要的起因是 Flink 本来的基于 hash 的实现对大规模批作业不可用。这个也是被现有的其余大规模分布式计算零碎所证实的： 稳定性方面：对于高并发批作业，基于 hash 的实现会产生大量的文件，并且会对这些文件进行并发读写，这会耗费很多资源并对文件系统会产生较大的压力。文件系统须要保护大量的文件元数据，会产生文件句柄以及 inode 耗尽等不稳固危险。性能方面：对于高并发批作业，并发读写大量的文件意味着大量的随机 IO，并且每次 IO 理论读写的数据量可能是非常少的，这对于 IO 性能是一个微小的挑战，在机械硬盘上，这使得数据 shuffle 很容易成为批处理作业的性能瓶颈。通过引入基于 sort 的批数据 shuffle 实现，并发读写的文件数量能够大大降低，有利于实现更好的数据程序读写，从而可能进步 Flink 大规模批处理作业的稳定性与性能。除此之外，新的 sort-shuffle 实现还能够减小内存缓冲区的耗费。对于基于 hash 的实现，每个数据分区都须要一块读写缓冲区，内存缓冲区耗费和并发成正比。而基于 sort 的实现则能够做到内存缓冲区耗费和作业并发解耦（只管更大的内存可能会带来更高的性能）。 ...

本文转载自「好将来技术」公众号，以 Flink SQL 案例来介绍 Flink CDC 2.0 的应用，并解读 CDC 中的外围设计。次要内容为： 案例外围设计代码详解 8 月份 Flink CDC 公布 2.0.0 版本，相较于 1.0 版本，在全量读取阶段反对分布式读取、反对 checkpoint，且在全量 + 增量读取的过程在不锁表的状况下保障数据一致性。 具体介绍参考 Flink CDC 2.0 正式公布，详解外围改良。 Flink CDC 2.0 数据读取逻辑并不简单，简单的是 FLIP-27: Refactor Source Interface 的设计及对 Debezium Api 的不理解。本文重点对 Flink CDC 的解决逻辑进行介绍， FLIP-27 的设计及 Debezium 的 API 调用不做过多解说。 本文应用 CDC 2.0.0 版本，先以 Flink SQL 案例来介绍 Flink CDC 2.0 的应用，接着介绍 CDC 中的外围设计蕴含切片划分、切分读取、增量读取，最初对数据处理过程中波及 flink-mysql-cdc 接口的调用及实现进行代码解说。 一、案例全量读取 + 增量读取 Mysql 表数据，以changelog-json 格局写入 kafka，察看 RowKind 类型及影响的数据条数。 ...

1. 外围构造与概念Calcite 提供的 Validator 流程极为简单，但概括下来次要做了这么一件事，对每个 SqlNode 联合元数据校验其语义是否正确，这些语义包含： 验证表名是否存在；select 的列在对应表中是否存在，且该匹配到的列名是否惟一，比方 join 多表，两个表有雷同名字的字段，如果此时 select 的列不指定表名就会报错；如果是 insert，须要插入列和数据源进行校验，如列数、类型、权限等；…… Calcite 提供的 validator 和后面提到的 Catalog 关系严密，Calcite 定义了一个 CatalogReader 用于在校验过程中拜访元数据 (Table schema)，并对元数据做了运行时的一些封装，最外围的两局部是 SqlValidatorNamespace 和 SqlValidatorScope。 SqlValidatorNamespace：形容了 SQL 查问返回的关系，一个 SQL 查问能够拆分为多个局部，查问的列组合，表名等等，当中每个局部都有一个对应的 SqlValidatorNamespace。SqlValidatorScope：能够认为是校验流程中每个 SqlNode 的工作上下文，当校验表达式时，通过 SqlValidatorScope 的 resolve 办法进行解析，如果胜利的话会返回对应的 SqlValidatorNamespace 形容后果类型。在此基础上，Calcite 提供了 SqlValidator 接口，该接口提供了所有与校验相干的外围逻辑，并提供了内置的默认实现类 SqlValidatorImpl 定义如下： public class SqlValidatorImpl implements SqlValidatorWithHints { // ... final SqlValidatorCatalogReader catalogReader; /** * Maps {@link SqlNode query node} objects to the {@link SqlValidatorScope} * scope created from them. */ protected final Map<SqlNode, SqlValidatorScope> scopes = new IdentityHashMap<>(); /** * Maps a {@link SqlSelect} node to the scope used by its WHERE and HAVING * clauses. */ private final Map<SqlSelect, SqlValidatorScope> whereScopes = new IdentityHashMap<>(); /** * Maps a {@link SqlSelect} node to the scope used by its GROUP BY clause. */ private final Map<SqlSelect, SqlValidatorScope> groupByScopes = new IdentityHashMap<>(); /** * Maps a {@link SqlSelect} node to the scope used by its SELECT and HAVING * clauses. */ private final Map<SqlSelect, SqlValidatorScope> selectScopes = new IdentityHashMap<>(); /** * Maps a {@link SqlSelect} node to the scope used by its ORDER BY clause. */ private final Map<SqlSelect, SqlValidatorScope> orderScopes = new IdentityHashMap<>(); /** * Maps a {@link SqlSelect} node that is the argument to a CURSOR * constructor to the scope of the result of that select node */ private final Map<SqlSelect, SqlValidatorScope> cursorScopes = new IdentityHashMap<>(); /** * The name-resolution scope of a LATERAL TABLE clause. */ private TableScope tableScope = null; /** * Maps a {@link SqlNode node} to the * {@link SqlValidatorNamespace namespace} which describes what columns they * contain. */ protected final Map<SqlNode, SqlValidatorNamespace> namespaces = new IdentityHashMap<>(); // ...}能够看到 SqlValidatorImpl 当中有许多 scopes 映射 (SqlNode -> SqlValidatorScope) 和 namespaces (SqlNode -> SqlValidatorNamespace)，校验其实就是在一个个 SqlValidatorScope 中校验 SqlValidatorNamespace 的过程，另外 SqlValidatorImpl 有一个成员 catalogReader，也就是下面说到的 SqlValidatorCatalogReader，为 SqlValidatorImpl 提供了拜访元数据的入口。（注：为了简便，后续本文均以 scope 指代 SqlValidatorScope，应用 namespace 指代 SqlValidatorNamespace）。 ...

本文基于字节跳动举荐零碎根底服务方向负责人郭文飞在 5 月 22 日 Apache Flink Meetup 分享的《Flink 在字节跳动举荐特色体系中的落地实际》整顿，次要内容包含： 业务背景新一代零碎架构后续布局 2021 年，字节跳动旗下产品总 MAU 已超过 19 亿。在以抖音、今日头条、西瓜视频等为代表的产品业务背景下，弱小的举荐零碎显得尤为重要。Flink 提供了十分弱小的 SQL 模块和有状态计算模块。目前在字节举荐场景，实时简略计数特色、窗口计数特色、序列特色曾经齐全迁徙到 Flink SQL 计划上。联合 Flink SQL 和 Flink 有状态计算能力，咱们正在构建下一代通用的根底特色计算对立架构，冀望能够高效反对罕用有状态、无状态根底特色的生产。 一、业务背景 对于今日头条、抖音、西瓜视频等字节跳动旗下产品，基于 Feed 流和短时效的举荐是外围业务场景。而举荐零碎最根底的燃料是特色，高效生产根底特色对业务举荐零碎的迭代至关重要。 1. 次要业务场景 抖音、火山短视频等为代表的短视频利用举荐场景，例如 Feed 流举荐、关注、社交、同城等各个场景，整体在国内大略有 6 亿 + 规模 DAU；头条、西瓜等为代表的 Feed 信息流举荐场景，例如 Feed 流、关注、子频道等各个场景，整体在国内有数亿规模 DAU；2. 业务痛点和挑战 目前字节跳动举荐场景根底特色的生产现状是“百花齐放”。离线特色计算的基本模式都是通过生产 Kafka、BMQ、Hive、HDFS、Abase、RPC 等数据源，基于 Spark、Flink 计算引擎实现特色的计算，而后把特色的后果写入在线、离线存储。各种不同类型的根底特色计算散落在不同的服务中，不足业务形象，带来了较大的运维老本和稳定性问题。 而更重要的是，不足对立的根底特色生产平台，使业务特色开发迭代速度和保护存在诸多不便。如业务方需自行保护大量离线工作、特色生产链路不足监控、无奈满足一直倒退的业务需要等。 在字节的业务规模下，构建对立的实时特色生产零碎面临着较大挑战，次要来自四个方面： 微小的业务规模：抖音、头条、西瓜、火山等产品的数据规模可达到日均 PB 级别。例如在抖音场景下，晚顶峰 Feed 播放量达数百万 QPS，客户端上报用户行为数据高达数千万 IOPS。 业务方冀望在任何时候，特色工作都能够做到一直流、生产没有 lag 等，这就要求特色生产具备十分高的稳定性。 较高的特色实时化要求：在以直播、电商、短视频为代表的举荐场景下，为保障举荐成果，实时特色离线生产的时效性需实现常态稳固于分钟级别。 更好的扩展性和灵活性：随着业务场景一直简单，特色需要更为灵便多变。从统计、序列、属性类型的特色生产，到须要灵便反对窗口特色、多维特色等，业务方须要特色中台可能反对逐步衍生而来的新特色类型和需要。 业务迭代速度快：特色中台提供的面向业务的 DSL 须要足够场景，特色生产链路尽量让业务少写代码，底层的计算引擎、存储引擎对业务齐全通明，彻底开释业务计算、存储选型、调优的累赘，彻底实现实时根底特色的规模化生产，一直晋升特色生产力； ...

本文整顿自 BIGO Staff Engineer 陈航在 Flink Forward Asia 2020 分享的议题《借助 Flink 与 Pulsar，BIGO 打造实时音讯解决零碎》。次要内容包含： 对于 BIGOBIGO 为什么会抉择 Apache PulsarApache Pulsar 在 BIGO 中的角色BIGO 借助 Apache Pulsar 和 Flink 结构本人的实时音讯流解决零碎。将来打算 一、对于 BIGO借助于大数据和人工智能技术，BIGO 基于视频的服务和产品取得了宽泛的欢送，在 150 多个国家和地区取得了大量的用户。BIGO 次要有两款十分风行的产品，第一款是 BIGO Live，另外一款是 Likee。BIGO Live 是一个直播平台，而 Likee 是一个短视频平台。 二、为什么抉择 Apache Pulsar在过来的几年里，BIGO 的音讯平台次要还是以开源的 Kafka 集群为主，然而随着业务的一直增长、用户一直裁减，整个音讯流平台所承载的音讯量和数据量也呈现了成倍的增长，同时也对整个音讯流零碎提出了更高的要求。 次要体现在以下几个方面： 第一，它对整个零碎的稳定性、可扩展性以及鲁棒性提出了更高的要求。第二，因为咱们是短视频举荐相干的服务，所以对整个音讯流的低提早也提出了十分高的要求。随着数量增长，整个 BIGO 的音讯流平台的团队在保护多个 Kafka 集群上付出了大量的工作，摆在咱们背后的有很多 Kafka 集群运维相干的问题。这个时候，咱们就在思考，咱们是抉择开源 Kafka 的一个基线版本进行本人的迭代开发呢？还是看一下开源社区外面有哪些能够借鉴的计划，来打造一个合乎咱们利用场景需要的音讯流平台。 于是咱们进行了一系列调研。在调研的过程中，咱们的眼光留神到了 Apache Pulsar，它有以下几点 feature 比拟 match 咱们的利用场景： 首先，它可能程度地扩大。咱们晓得对于 Kafka 而言，它是一个服务和存储绑定的零碎。当咱们须要去扩容一个集群的时候，单单把机器上线是不可能满足需要的，咱们须要对整个 topic 的 partition 进行相应操作，这个时候就是耗人力去运维的。所以，咱们须要有一个可能程度扩大的零碎。而 Apache Pulsar 提供的是存储和服务拆散的一个架构，应用的是 bookkeeper 作为底层的数据存储，下层有一个 broker 来提供相干的服务。另外，就是它的 low latency 还有高吞吐、低提早以及在雅虎的生产环境下面禁受了大数据量的考验。跨集群的复制等一系列的 feature 对于咱们而言也是十分须要的。并且，这样一个存储和服务拆散的架构也极大地缩小了人工运维的老本。所以咱们抉择了 Apache Pulsar。 ...

本文转载自公众号【麒思妙想】，具体介绍了 Flink + Hudi 湖仓一体化计划的原型构建。次要内容为： Hudi新架构与湖仓一体最佳实际Flink on HudiFlink CDC 2.0 on Hudi 一、Hudi1. 简介Apache Hudi (发音为 “Hoodie”)在 DFS 的数据集上提供以下流原语 插入更新 (如何扭转数据集?)增量拉取 (如何获取变更的数据?)Hudi 保护在数据集上执行的所有操作的时间轴 (timeline），以提供数据集的即时视图。Hudi 将数据集组织到与 Hive 表十分类似的根本门路下的目录构造中。数据集分为多个分区，文件夹蕴含该分区的文件。每个分区均由绝对于根本门路的分区门路惟一标识。 分区记录会被调配到多个文件。每个文件都有一个惟一的文件 ID 和生成该文件的提交 (commit)。如果有更新，则多个文件共享雷同的文件 ID，但写入时的提交 (commit) 不同。 存储类型 – 解决数据的存储形式 写时复制纯列式创立新版本的文件读时合并近实时视图 – 解决数据的读取形式 读取优化视图 - 输出格局仅抉择压缩的列式文件 parquet 文件查问性能500GB 的延迟时间约为 30 分钟导入现有的 Hive 表近实时视图 混合、格式化数据约 1-5 分钟的提早提供近实时表增量视图 数据集的变更启用增量拉取Hudi 存储层由三个不同的局部组成 元数据 – 它以时间轴的模式保护了在数据集上执行的所有操作的元数据，该时间轴容许将数据集的即时视图存储在根本门路的元数据目录下。时间轴上的操作类型包含 提交 (commit)，一次提交示意将一批记录原子写入数据集中的过程。枯燥递增的工夫戳，提交示意写操作的开始。清理 (clean)，清理数据集中不再被查问中应用的文件的较旧版本。压缩 (compaction)，将行式文件转化为列式文件的动作。索引，将传入的记录键疾速映射到文件 (如果已存在记录键)。索引实现是可插拔的，Bloom 过滤器 - 因为不依赖任何内部零碎，因而它是默认配置，索引和数据始终保持统一。Apache HBase - 对大量 key 更高效。在索引标记过程中可能会节俭几秒钟。数据，Hudi 以两种不同的存储格局存储数据。理论应用的格局是可插入的，但要求具备以下特色 – 读优化的列存储格局 (ROFormat)，默认值为 Apache Parquet；写优化的基于行的存储格局 (WOFormat)，默认值为 Apache Avro。 ...

本⽂由社区志愿者苗文婷整顿，内容起源⾃ LinkedIn 大数据高级开发工程师张晨娅在 Flink Forward Asia 2020 分享的《从 Spark 做批处理到 Flink 做流批一体》，分享的主题是如何从 Spark 做批处理到 Flink 做流批一体，在 LinkedIn 的一些摸索实践经验。次要内容为： 为什么要做流批一体？以后行业已有的解决方案和现状，劣势和劣势摸索生产实践场景的教训Shuflle Service 在 Spark 和 Flink 上的比照，以及 Flink 社区前面能够思考做的工作总结 1. 为什么要做流批一体 做流批一体到底有哪些好处，尤其是在 BI/AI/ETL 的场景下。整体来看，如果能帮忙用户做到流批一体，会有以上 4 个比拟显著的好处： 能够防止代码反复，复用代码外围解决逻辑代码逻辑能完全一致是最好的，但这会有肯定的难度。但整体来讲，当初的商业逻辑越来越长，越来越简单，要求也很多，如果咱们应用不同的框架，不同的引擎，用户每次都要从新写一遍逻辑，压力很大并且难以保护。所以整体来讲，尽量避免代码反复，帮忙用户复用代码逻辑，就显得尤为重要。 流批一体有两个方向这两个方向要思考的问题很不一样，目前 Flink 做 Streaming、Spark 做 Batch 等等一些框架在批处理或流解决上都比拟成熟，都曾经产生了很多的单方面用户。当咱们想帮忙用户移到另外一个方向上时，比方一些商业需要，通常会分成两类，是先从流解决开始到批处理，还是从批处理开始到流解决。之后介绍的两个生产实践场景案例，正好对应这两个方向。 缩小保护工作量防止保护多套零碎，零碎之间的差别可能十分大，框架和引擎都不一样，会带来比拟多的问题。如果公司外部有多条 pipeline ，一个实时一个离线，会造成数据不一致性，因而会在数据验证、数据准确性查问、数据存储等方面做很多工作，尽量去保护数据的一致性。 学习更多框架和引擎很多，商业逻辑既要跑实时，也要跑离线，所以，反对用户时须要学习很多货色。 2. 以后行业现状 Flink 和 Spark 都是同时反对流解决和批处理的引擎。咱们统一认为 Flink 的流解决做的比拟好，那么它的批处理能做到多好？同时，Spark 的批处理做的比拟好，那么它的流解决能不能足够帮忙用户解决现有的需要？ 当初有各种各样的引擎框架，能不能在它们之上有一个对立的框架，相似于联邦解决或者是一些简略的 physical API，比方 Beam API 或者是自定义接口。 Beam 方面须要思考的问题，是它在批处理和流解决上的优化能做到多好？Beam 目前还是偏物理执行，之后的打算是咱们须要讲究的。 LinkedIn，包含其余公司，会思考做一些自定义接口的解决方案，思考有一个共通的 SQL 层，通用的 SQL 或 API 层，底下跑不同的框架引擎。这里须要思考的问题是，像 Spark 、Flink 都是比拟成熟的框架了，曾经领有大量的用户群体。当咱们提出一个新的 API ，一个新的解决方案，用户的接受度如何? 在公司外部应该如何保护一套新的解决方案？ ...

网易云音乐从2018年开始搭建实时计算平台，通过几年的倒退曾经渗透到云音乐的各个业务当中。本文是大愚老师的一篇实际分享，将从一个日常运维问题登程，率领大家理解云音乐实时计算平台的一些工作进展和将来布局。次要内容为： 平台性能批流一体将来布局 网易云音乐实时数仓平台上线当前，通过一年半的倒退，整体实时数仓曾经初具规模，咱们已有实时数仓表300+，运行中的工作数有1200+。其中1000左右的工作是SQL工作， Kafka总进口流量达到到18GB/S，总用户数达到了200+。 数据量和用户的增长也给数据平台的易用性以及稳定性带来了了越来越多的挑战，蕴含Kafka的稳定性、集群的稳定性、运维工作的挑战以及很多晚期的技术债；业务的增长，暴露出了基建的单薄，也给咱们积攒了很多平台建设和运维的教训。 一、平台性能咱们平台整体的的性能大家能够参考《云音乐实时数仓技术改造以及将来的一些布局》，这里将次要介绍咱们最新的一些工作： “我的工作提早了，怎么扩容都不行，这是为什么？” 在日常运维工作中这是咱们常常遇到的问题，往往也是比拟消耗工夫的问题。导致这种这种问题的起因有很多，为了解决这个问题，咱们做了一些工作来加强咱们的运维能力。 1. IO指标欠缺IO问题是导致以上问题经常出现的起因之一，蕴含音讯读取效率、维表JOIN效率、SINK效率等等，第三方存储的性能以及稳定性，间接影响实时工作的稳定性，为了疾速定位相干问题，咱们增加了很多IO相干Metric指标。 1.1 Kafka生产侧的一些性能指标 1.2 读取反序列化指标蕴含： 反序列化的RT反序列化的谬误比例在Format侧咱们开发了一套Format代理，反对在不批改原有format代码的状况下，上报相干metirc指标，疏忽谬误数据等性能。只有增加属性format.proxy指定代理类就能够反对不同形式的Format封装。 比方咱们指定format.proxy=magina，就能够反对上报上述的性能指标；指定format.proxy=ds 就能够反对解析ds封装的日志格局，应用被代理的Format解析DS中的Body局部，不须要独自为DS封装的日志格局开发Format，且同样会上报性能相干指标，反对疏忽谬误音讯等性能。 1.3 维表JOIN相干指标在维表JOIN侧, 咱们增加了： 数据查问的响应工夫本地缓存的命中率查问产生重试的比例胜利JOIN上的数据的比例等1.4 数据写入的一些性能指标数据序列化的RT数据写入内部数据源的均匀响应工夫等整套IO相干指标的实现，咱们全副是在Flink Connector的顶层接口做了一些公共的封装，重构了相干Connector的代码，只有依照咱们本人的接口实现Connector，无需关怀细节指标的上报，这些指标都会自动化的上报进去。 2. Kafka分区问题Kafka分区的限度也是常常导致咱们程序性能无奈扩大的起因，出于Exactly Once的实现、读取性能、以及读取稳定性的思考，Flink采纳被动拉取的形式读取Kafka音讯，这种形式限度了咱们读取Kafka音讯的工作数，大大限度咱们工作性能的扩张能力，以上面这个case为例： SET 'table.exec.state.ttl' = '1h';SET 'table.exec.mini-batch.enabled' = 'true';SET 'table.exec.mini-batch.allow-latency' = '10s';SET 'table.exec.mini-batch.size' = '100000';INSERT INTO music_kudu_online.music_kudu_internal.ads_ab_rtrs_user_metric_hourSELECT from_unixtime(`timestamp`, 'yyyy-MM-dd') as dt,from_unixtime(`timestamp`, 'HH') as `hour`,os, sceneid, parent_exp, `exp`, exp_type, userid,count(1) pvFROM iplay_ods.ods_rtrs_ab_log INNER JOIN abtest_online.abtest.abtest_sence_metric_relationFOR SYSTEM_TIME AS OF user_metric.proctimeON ods_rtrs_ab_log.sceneid = abtest_sence_metric_relation.sceneid GROUP BY from_unixtime(`timestamp`, 'yyyy-MM-dd'), from_unixtime(`timestamp`, ‘HH’), os, sceneid, parent_exp, `exp`, exp_type, userid这是一个实时全聚合工作，在原始的FLINK中这段SQL执行的DAG大略是这样的： ...

在 Apache 软件基金会近期公布的年度报告中，Apache Flink 再次跻身最沉闷我的项目前 5 名！该我的项目最新公布的 1.14.0 版本同样体现了其不凡的沉闷力，囊括了来自超过 200 名贡献者的 1000 余项奉献。整个社区为我的项目的推动付出了坚持不懈的致力，咱们引以为傲。 新版本在 SQL API、更多连接器反对、Checkpoint 机制、PyFlink 等多个方面带来了大量的新个性与改良。其中一个次要的改良是针对流批一体的应用体验。咱们置信，在实践中，对无界的数据流的解决与对有界的批数据的解决是密不可分的，因为很多场景都须要在解决实时数据流的同时解决来自各种数据源的历史数据。例如开发新利用时的数据摸索、新利用的状态初始化、用于流式利用的训练模型、降级或修复后的数据重解决等。 在 Flink 1.14 中，咱们终于能够在同一个利用当中混合应用有界流和无界流：Flink 当初反对对局部运行、局部完结的利用（局部算子已解决到有界输出数据流的末端）做 Checkpoint。此外，Flink 在解决到有界数据流末端时会触发最终 Checkpoint，以确保所有计算结果顺利提交到 Sink。 批执行模式当初反对在同一利用中混合应用 DataStream API 和 SQL/Table API（此前仅反对独自应用 DataStream API 或 SQL/Table API）。 咱们更新了对立的 Source 和 Sink API，并已开始围绕对立的 API 整合连接器生态。咱们新增了混合 Source 可在多个存储系统间过渡。你当初能够实现诸如先从 Amazon S3 中读取旧的数据再无缝切换到 Apache Kafka 这样的解决。 此外，这一版本朝着咱们将 Flink 打造得更加自调易用、无需大量流解决特定常识的指标又迈进了一步。作为向此指标迈出的第一步，咱们在上个版本中引入了被动弹性伸缩模式。当初，咱们又新增了对网络内存的主动调整（即缓冲区去收缩）。这一个性能在放弃高吞吐、不减少 Checkpoint 大小的前提下，减速高负载时的Checkpoint。该机制通过一直调整网络缓冲区的大小，可能以起码的缓冲数据达到最佳的吞吐效率。更多详情请参考缓冲区去收缩章节。 新版本中有许多来自各个组件的新个性与改良，咱们将在下文介绍。与此同时，咱们也辞别了一些在最近的版本中逐步被取代、废除的组件和性能。最具代表性的是，新版本中移除了旧版 SQL 查问引擎和对 Apache Mesos 的集成。 咱们心愿你喜爱这个新版本，同时迫切地想理解你的应用体验：这一版本解决了哪些此前尚未解决的问题，满足了哪些新场景？ 一、流批一体的解决体验Flink 的一个独特之处是其对流和批处理的对立：应用同一套 API、同一个可反对多种执行范式的运行时。 ...

本文由社区志愿者路培杰整顿，腾讯看点数据团队高级工程师王展雄在 Flink Forward Asia 2020 分享的议题《腾讯看点基于 Flink 构建万亿数据量下的实时数仓及实时查问零碎》。内容包含： 背景介绍架构设计实时数仓实时数据查问零碎实时零碎利用成绩总结 一、背景介绍1. 须要解决的业务痛点举荐零碎 对于举荐同学来说，想晓得一个举荐策略在不同人群中的举荐成果是怎么样的。 经营 对于经营的同学来说，想晓得在广东省的用户中，最火的广东地区内容是哪些？不便做地区 push。 审核 对于审核的同学，想晓得过来 5 分钟游戏类被举报最多的内容和账号是哪些，不便可能及时处理。 内容创作 对于内容的作者，想晓得明天到目前为止，内容被多少个用户观看，收到了多少个点赞和转发，不便可能及时调整他的策略。 老板决策 对于老板来说，想晓得过来 10 分钟有多少用户生产了内容，对生产人群有一个宏观的理解。 以上这几点都是咱们日常工作中常常遇到的业务场景，前面的篇幅中会给出对应的解决方案。 2. 开发前调研在进行开发之前咱们做了如下这些调研。 2.1 离线数据分析平台是否满足这些需要调研的论断是不能满足离线数据分析平台，不行的起因如下： 首先用户的消费行为数据上报须要通过 Spark 的多层离线计算，最终后果出库到 MySQL 或者 ES 提供给离线剖析平台查问。这个过程的延时至多是 3-6 个小时，目前比拟常见的都是提供隔天的查问，所以很多实时性要求高的业务场景都不能满足。另一个问题是腾讯看点的数据量太大，带来的不稳定性也比拟大，常常会有预料不到的提早，所以离线剖析平台是无奈满足这些需要的。2.2 准实时数据分析平台在腾讯外部提供了准实时数据查问的性能，底层技术用的是 Kudu + Impala，Impala 尽管是 MPP 架构的大数据计算引擎，并且拜访以列式存储数据的 Kudu。然而对于实时数据的剖析场景来说，它的查问响应速度和数据的提早都还是比拟高的。比如说查问一次实时的 DAU 返回后果的耗时至多是几分钟，无奈提供良好的交互式的用户体验。 所以 Kudu+Impala 这种通用的大数据处理框架的速度劣势，更多的是相比 Spark 加 HDFS 这种离线剖析框架来说的，对于咱们实时性要求更高的场景是无奈满足的。因而须要进行开发，这就波及到了计划选型和架构设计。 3. 腾讯看点信息流的业务流程在大家介绍一下腾讯看点信息流的业务流程，理解了业务的流程，就可能更好的了解技术架构的计划。 第 1 步，内容创作者公布内容；第 2 步，内容会通过内容审核零碎启用或者下架；第 3 步，启用的内容给到举荐零碎和经营零碎，分发给 C 侧用户；第 4 步，内容分发给 C 侧用户之后，用户会产生各种行为，比如说曝光、点击举报等，这些行为数据通过埋点上报，实时接入到音讯队列中；第 5 步，构建实时数据仓库；第 6 步，构建实时数据查问零碎。 ...

本文作者为刘杰，介绍了顺丰科技数仓的架构，趟过的一些问题、应用 Hudi 来优化整个 job 状态的实际细节，以及将来的一些布局。次要内容为： 数仓架构Hudi 代码躺过的坑状态优化将来布局顺丰科技早在 2019 年引入 Hudi ,过后是基于 Spark 批处理，2020 年对数据的实时性要求更高公司对架构进行了降级，在社区 Hudi on Flink 的半成品上继续优化实现 Binlog 数据 CDC 入湖。在 Hudi 社区飞速发展的同时公司往年对数仓也提出了新的要求，最终采纳 Flink + Hudi 的形式来宽表的实时化。过程中遇到了很多问题次要有两点： Hudi Master 代码过后存在一些破绽；宽表波及到多个 Join，Top One 等操作使得状态很大。庆幸的是社区的修复速度很给力加上 Hudi 弱小 upsert 能力使这两个问题失去以无效的解决。 一、数仓架构感兴趣的同学能够参考之前顺丰分享的 Hudi on Flink 在顺丰的实际利用。 二、Hudi 代码趟过的坑在去年咱们是基于 Hudi 0.6 左右进行的 Hudi on Flink 的实际，代码较老。为了拥抱社区咱们应用最新 master 代码进行实际，在大数据量写入场景中，发现了一个比拟隐秘的丢数问题，这个问题花了将近两周的工夫才定位到。 1. Hudi StreamWriteFunction 算子外围流程梳理 StreamWriteFunction 算子收数据的时候会先把数据依照 fileld 分组缓存好，数据的继续流会使得缓存数据越来越大，当达到肯定阈值时便会执行 flush。阈值由 2 个外围参数管制： write.batch.size 默认 64M ，write.task.max.size 默认 1G 。当单个分组数据达到 64M 或者总缓存数据达到 800M ~ 1G 就会触发 flush 。 ...

本文整顿自汽车之家实时计算平台负责人邸星星在 Flink Forward Asia 2020 分享的议题《Apache Flink 在汽车之家的利用及实际》。次要内容包含： 背景及现状AutoStream 平台基于 Flink 的实时生态建设后续布局 一、背景及现状1. 第一阶段在 2019 年之前，汽车之家的大部分实时业务都是运行在 Storm 之上的。Storm 作为晚期支流的实时计算引擎，凭借简略的 Spout 和 Bolt 编程模型以及集群自身的稳定性，俘获了少量用户，咱们在 2016 年搭建了 Storm 平台。 随着实时计算的需要日渐增多，数据规模逐渐增大，Storm 在开发及保护老本上都凸显了有余，这里列举几个痛点: 开发成本高 咱们始终是用的 Lambda 架构，会用 T+1 的离线数据修改实时数据，即最终以离线数据为准，所以计算口径实时要和离线齐全保持一致，实时数据开发的需要文档就是离线的 SQL，实时开发人员的外围工作就是把离线的 SQL 翻译成 Storm 代码，期间尽管封装了一些通用的 Bolt 来简化开发，但把离线动辄几百行的 SQL 精准地翻译成代码还是很有挑战的，并且每次运行都要通过打包、上传、重启的一系列的繁琐操作，调试老本很高。 计算低效 Storm 对状态反对的不好，通常须要借助 Redis、HBase 这类 kv 存储保护中间状态，咱们之前是强依赖 Redis。比方常见的计算 UV 的场景，最简略的方法是应用 Redis 的 sadd 命令判断 uid 是否为曾经存在，但这种办法会带来很高的网络 IO，同时如果没有提前报备的大促或搞流动导致流量翻倍的状况，很容易把 Redis 内存搞满，运维同学也会被杀个措手不及。同时 Redis 的吞吐能力也限度了整个作业的吞吐量。 难以保护、治理 因为采纳编写 Storm 代码形式开发，难以剖析元数据及血缘关系，同时可读性差，计算口径不通明，业务交接老本很高。 ...

简介JobGraph 能够认为是 StreamGraph 的优化图，它将一些合乎特定条件的 operators 合并成一个 operator chain，以缩小数据在节点之间序列化/反序列化以及网络通信带来的资源耗费。 入口函数与 StreamGraph 的生成相似，调用 StreamGraph.getJobGraph() 就能够失去对应的 JobGraph，底层会创立一个 StreamingJobGraphGenerator 以创立 JobGraph：new StreamingJobGraphGenerator(streamGraph, jobID).createJobGraph()。 private JobGraph 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 compatibility List<Map<Integer, byte[]>> legacyHashes = new ArrayList<>(legacyStreamGraphHashers.size()); for (StreamGraphHasher hasher : legacyStreamGraphHashers) { legacyHashes.add(hasher.traverseStreamGraphAndGenerateHashes(streamGraph)); } setChaining(hashes, legacyHashes); // ... return jobGraph;}外围是这两步： ...

我趁老婆洗澡，看了一眼她手机， 发现她和丈母娘的语音聊天。 老婆说：明天胸口闷得慌， 老婆说：待会儿把他揍一顿出出气。 丈母娘：不要做无理取闹的事！ 丈母娘：先翻旧账铺垫铺垫哈。 我整个人都不好了…… 第二天早上起床，不爱搭理老婆。 她问我：你干啥呢？ 我：死了。 她又问：那怎么睁着眼睛？ 我：抱恨终天。 她再问：那为啥还喘气呢? 我：咽不下这口气。 我果决和她离别了， 她说：你会找到更好的。 我：连你这么差的我都留不住…… 我：还能留住更好的？ 起初我去了小公园相亲角， 相亲对象第一句话就问我： 你也没人要吗? 生存，对我下手了…… 世界奇奇怪怪，汪公子怯懦可恶。 情感专家妇女之友汪公子又来啦！ 不相熟男女关系懂王的敌人猛击： Hive源码解析及优化视频 Flume新版视频 大数据圈的浪里小白龙理解一下。 汪公子对我开启了疯狂课工场模式： 男儿当自强，对镜贴花黄。 所有不依不饶，都是画地为牢， 有的人一旦错过，你应该谢天谢地。 来来来，安利你一波撩老妹小话术。 汪公子上学的时候就很会撩。 他难过地对她说： 你给我的和他人一样多，我不要。 食堂阿姨说：不吃滚！ 如果不是食堂阿姨，操作是不是满分？ 汪公子和前女友也相当会撩。 我跑遍了整个中国的医院， 都治不好我的深情和专一。 若我会见到你，事隔经年， 我如何向你招呼，以眼泪，以缄默。 汪公子对老婆那是更加会撩。 她问：咱们结婚了，你会不会家暴我？ 汪公子：只有你喜爱，我能够学。 有一次汪公子喝大了，回家躺公开了。 他老婆说，你上床睡吧。 汪公子：不必了谢谢你，我有女人了。 说完躺地板上就睡着了。 喝酒喝到七分醉，演的老婆直流泪！ 汪公子能量包已就位： 邻家有女初长成，力拔山兮气盖世。 年轻人，削尖脑袋向前冲啊！ 我：……汪公子，其实我想学点别的。 汪公子：早说啊，来都来了，给： Flink实时数仓视频教程公布！ B站中转：传送门 https://www.bilibili.com/vide... 在大数据处理畛域，实时和离线各占十分大的比重，本套视频教程综合展现实时数据处理畛域的一个重要利用：实时数仓我的项目。 我的项目从数据采集开始，别离解说了针对不同数据采取的不同采集策略，应用的不同数据采集工具。在数据处理局部，将实时采集的数据依照数据建模要求进行正当分层，应用以后最炽热的实时计算引擎Flink，对实时计算结果进行可视化展现。 内容包含：搭建用户行为数据的实时数据采集框架Flume-Kafka-Flink；采纳Canal、Maxwell、Flink CDC三种计划实现业务数据的实时采集；分层搭建实时数据仓库，包含ODS层、DWD层、DIM层、DWM层、DWS层、ADS层；数据可视化接口的实现；ClickHouse技术的深刻解说…… 每一部分解说均参照理论开发环境，提供了多种问题的解决方案，疏导学员对问题进行更深层的思考。通过本套教程的学习，你将把握企业理论开发中实时数仓搭建的全流程，深刻了解Flink的高阶利用实例，把握开发环节多种框架技术。 汪公子火力全开，教程总计200集，时长40小时+，附赠全副视频、代码、笔记及材料。你要是学不会，都对不起汪公子这波操作！ 教程涵盖的关键技术点 数仓架构深刻解说、离线架构与实时架构比照剖析、SpringBoot我的项目搭建解说、Nginx装置配置应用、Flink CDC深刻案例剖析、Maxwell与Canal比照剖析、应用侧输入流分流操作、Flink与HBase交互、Flink状态编程利用、Flink CEP循环模式匹配、双流join、旁路缓存、异步IO编码、ClickHouse多引擎解说、Flink SQL、数据可视化接口编写、Flink实战优化计划等。 ...

本文通过实例来演示怎么通过Flink CDC 联合Doris的Flink Connector实现从Mysql数据库中监听数据并实时入库到Doris数仓对应的表中。 1.什么是CDCCDC 是变更数据捕捉（Change Data Capture）技术的缩写，它能够将源数据库（Source）的增量变动记录，同步到一个或多个数据目标（Sink）。在同步过程中，还能够对数据进行肯定的解决，例如分组（GROUP BY）、多表的关联（JOIN）等。 例如对于电商平台，用户的订单会实时写入到某个源数据库；A 部门须要将每分钟的实时数据简略聚合解决后保留到 Redis 中以供查问，B 部门须要将当天的数据暂存到 Elasticsearch 一份来做报表展现，C 部门也须要一份数据到 ClickHouse 做实时数仓。随着工夫的推移，后续 D 部门、E 部门也会有数据分析的需要，这种场景下，传统的拷贝散发多个正本办法很不灵便，而 CDC 能够实现一份变动记录，实时处理并投递到多个目的地。 1.1 CDC的利用场景数据同步：用于备份，容灾；数据散发：一个数据源分发给多个上游零碎；数据采集：面向数据仓库 / 数据湖的 ETL 数据集成，是十分重要的数据源。CDC 的技术计划十分多，目前业界支流的实现机制能够分为两种： 基于查问的 CDC：离线调度查问作业，批处理。把一张表同步到其余零碎，每次通过查问去获取表中最新的数据；无奈保障数据一致性，查的过程中有可能数据曾经产生了屡次变更；不保障实时性，基于离线调度存在人造的提早。基于日志的 CDC：实时生产日志，流解决，例如 MySQL 的 binlog 日志残缺记录了数据库中的变更，能够把 binlog 文件当作流的数据源；保障数据一致性，因为 binlog 文件蕴含了所有历史变更明细；保障实时性，因为相似 binlog 的日志文件是能够流式生产的，提供的是实时数据。2.Flink CDCFlink在1.11版本中新增了CDC的个性，简称 扭转数据捕捉。名称来看有点乱，咱们先从之前的数据架构来看CDC的内容。 以上是之前的mysq binlog日志解决流程，例如 canal 监听 binlog 把日志写入到 kafka 中。而 Apache Flink 实时生产 Kakfa 的数据实现 mysql 数据的同步或其余内容等。拆分来说整体上能够分为以下几个阶段。 mysql开启binlogcanal同步binlog数据写入到kafkaflink读取kakfa中的binlog数据进行相干的业务解决。整体的解决链路较长，须要用到的组件也比拟多。Apache Flink CDC能够间接从数据库获取到binlog供上游进行业务计算剖析 2.1 Flink Connector Mysql CDC 2.0 个性提供 MySQL CDC 2.0，外围 feature 包含 ...

作为开源大数据畛域的顶级盛会之一，Flink Forward 继续集结最佳行业实际以及 Flink 最新技术动静，并踊跃拥抱生态搭档，共建凋敝开源大数据生态。12 月 4-5 日，北京国家会议核心，Flink Forward Asia 2021 重磅开启，寰球 40+ 多行业一线厂商，80+ 干货议题，带来专属于开发者的技术盛宴。大会议程已正式上线，点击下方链接即可收费报名~ https://flink-forward.org.cn/ 弱小的嘉宾阵容FFA 2021 邀请了 11 位行业首领及开拓者组成议题评比委员会，并持续由阿里巴巴开源技术委员会负责人贾扬清负责主席，独特为大会内容护航，他们别离是： 内容重磅降级Flink Forward Asia 2021 大会内容重磅降级，除了经典的 Flink 核心技术解析、行业最佳实际、实时数仓、开源解决方案、机器学习主题，还新增了平台建设、实时数据湖、流批一体等时下热门方向。 主会场本届 Flink Forward Asia 将由阿里巴巴开源技术委员会负责人贾扬清进行收场演讲。Apache Flink 中文社区创始人王峰、字节跳动计算基础架构负责人师锐、中国工商银行大数据平台负责人袁一、Pravega 中国社区创始人滕昱将分享基于 Flink 的深度实际以及 Flink 下一步的的布局与瞻望。 核心技术由 Apache Flink 外围贡献者与来自阿里巴巴、字节跳动、快手、美团等一线技术专家解析 Flink 技术动向与利用实际。 行业实际字节跳动、网易、蔚来、中原银行、建信金融、中信建投等多行业实时计算领域专家具体解读 Flink 在业内的利用与落地，围绕业务场景、业务痛点、面临挑战、如何破局等贵重实践经验倾囊相授。 平台建设平台建设专场由来自字节跳动、腾讯新闻、网易、京东、滴滴、bilibili、汽车之家、挪动、联通、BIGO、蚂蚁金服、翼领取的技术专家分享基于 Apache Flink 的实时计算平台演进与实际。 实时数据湖来自阿里巴巴、字节跳动、网易的技术专家们将解读如何构建数据湖平台、简化实时数据入湖入仓等相干问题，更有 Flink + Iceberg、Flink + Hudi 构建流式数据湖最佳实际。 实时数仓实时数仓专场邀请腾讯、快手、美团、科大讯飞、现实汽车、蚂蚁金服、SmartNews、智慧芽、十荟团等多位数仓技术专家剖析实时数仓的利用实际及平台智能化的摸索与思考。 ...

StreanGraph是一个 DAG（以邻接表的模式存储），存储了整个流的拓扑构造信息，由一系列 StreamEdge 和 StreamNode 组成。 调用 StreamExecutionEnvironment.getStreamGraph() 即能够生成 StreamGraph。StreamExecutionEnvironment.getStreamGraph() 默认会革除 StreamExecutionEnvironment 中保留的 transformations，后续就无奈调用 StreamExecutionEnvironment.execute() 了，因而须要重复使用 transformations 的话能够应用重载办法 StreamExecutionEnvironment.getStreamGraph(String jobName, boolean clearTransformations)，其源码如下： public StreamGraph getStreamGraph(String jobName, boolean clearTransformations) { StreamGraph streamGraph = getStreamGraphGenerator().setJobName(jobName).generate(); if (clearTransformations) { this.transformations.clear(); } return streamGraph;}这部分代码会生成一个 StreamGraphGenerator（生成过程中曾经存储了所有 transformations 的信息），调用其 generate 办法生成 StreamGraph。 StreamGraphGeneratorgeneratepublic StreamGraph generate() { streamGraph = new StreamGraph(executionConfig, checkpointConfig, savepointRestoreSettings); shouldExecuteInBatchMode = shouldExecuteInBatchMode(runtimeExecutionMode); configureStreamGraph(streamGraph); alreadyTransformed = new HashMap<>(); for (Transformation<?> transformation : transformations) { transform(transformation); } final StreamGraph builtStreamGraph = streamGraph; alreadyTransformed.clear(); alreadyTransformed = null; streamGraph = null; return builtStreamGraph;}这个办法外围做了四件事： ...

简介： 介绍了顺丰科技数仓的架构，趟过的一些问题、应用 Hudi 来优化整个 job 状态的实际细节，以及将来的一些布局。 本文作者为刘杰，介绍了顺丰科技数仓的架构，趟过的一些问题、应用 Hudi 来优化整个 job 状态的实际细节，以及将来的一些布局。次要内容为： 数仓架构Hudi 代码躺过的坑状态优化将来布局顺丰科技早在 2019 年引入 Hudi ,过后是基于 Spark 批处理，2020 年对数据的实时性要求更高公司对架构进行了降级，在社区 Hudi on Flink 的半成品上继续优化实现 Binlog 数据 CDC 入湖。在 Hudi 社区飞速发展的同时公司往年对数仓也提出了新的要求，最终采纳 Flink + Hudi 的形式来宽表的实时化。过程中遇到了很多问题次要有两点： Hudi Master 代码过后存在一些破绽；宽表波及到多个 Join，Top One 等操作使得状态很大。庆幸的是社区的修复速度很给力加上 Hudi 弱小 upsert 能力使这两个问题失去以无效的解决。 一、数仓架构感兴趣的同学能够参考之前顺丰分享的 Hudi on Flink 在顺丰的实际利用。 二、Hudi 代码趟过的坑在去年咱们是基于 Hudi 0.6 左右进行的 Hudi on Flink 的实际，代码较老。为了拥抱社区咱们应用最新 master 代码进行实际，在大数据量写入场景中，发现了一个比拟隐秘的丢数问题，这个问题花了将近两周的工夫才定位到。 1. Hudi StreamWriteFunction 算子外围流程梳理 StreamWriteFunction 算子收数据的时候会先把数据依照 fileld 分组缓存好，数据的继续流会使得缓存数据越来越大，当达到肯定阈值时便会执行 flush。阈值由 2 个外围参数管制： write.batch.size 默认 64M ，write.task.max.size 默认 1G 。当单个分组数据达到 64M 或者总缓存数据达到 800M ~ 1G 就会触发 flush 。 ...

简介： 汽车之家如何基于 Flink 上线了 AutoStream 平台并继续打磨。本文整顿自汽车之家实时计算平台负责人邸星星在 Flink Forward Asia 2020 分享的议题《Apache Flink 在汽车之家的利用及实际》。次要内容包含：背景及现状、AutoStream 平台、基于 Flink 的实时生态建设、后续布局。 一、背景及现状1. 第一阶段在 2019 年之前，汽车之家的大部分实时业务都是运行在 Storm 之上的。Storm 作为晚期支流的实时计算引擎，凭借简略的 Spout 和 Bolt 编程模型以及集群自身的稳定性，俘获了少量用户，咱们在 2016 年搭建了 Storm 平台。 随着实时计算的需要日渐增多，数据规模逐渐增大，Storm 在开发及保护老本上都凸显了有余，这里列举几个痛点: 开发成本高 咱们始终是用的 Lambda 架构，会用 T+1 的离线数据修改实时数据，即最终以离线数据为准，所以计算口径实时要和离线齐全保持一致，实时数据开发的需要文档就是离线的 SQL，实时开发人员的外围工作就是把离线的 SQL 翻译成 Storm 代码，期间尽管封装了一些通用的 Bolt 来简化开发，但把离线动辄几百行的 SQL 精准地翻译成代码还是很有挑战的，并且每次运行都要通过打包、上传、重启的一系列的繁琐操作，调试老本很高。 计算低效 Storm 对状态反对的不好，通常须要借助 Redis、HBase 这类 kv 存储保护中间状态，咱们之前是强依赖 Redis。比方常见的计算 UV 的场景，最简略的方法是应用 Redis 的 sadd 命令判断 uid 是否为曾经存在，但这种办法会带来很高的网络 IO，同时如果没有提前报备的大促或搞流动导致流量翻倍的状况，很容易把 Redis 内存搞满，运维同学也会被杀个措手不及。同时 Redis 的吞吐能力也限度了整个作业的吞吐量。 ...

本文首发于泊浮目标简书:https://www.jianshu.com/u/204...版本日期备注1.02021.10.8文章首发0. 前言前阵子笔者波及了些许监控相干的开发工作，在开发过程中也碰到过些许问题，便翻读了FLink相干局部的代码，在读代码的过程中发现了一些好的设计，因而也是写成文章整顿上来。 本文的源码基于FLink1.13.2。1. 扩大插件化在官网中，FLink社区本人提供了一些已接入的Repoter，如果咱们有本人定制的Reporter，也能够依据它的标准去实现本人的Repoter。 在FLink的代码中，提供了反射机制实例化MetricReporter：要求MetricReporter的实现类必须是public的拜访修饰符，不能是抽象类，必须有一个无参构造函数。 外围代码为RepoterSetup#getAllReporterFactories： private static Iterator<MetricReporterFactory> getAllReporterFactories( @Nullable PluginManager pluginManager) { final Iterator<MetricReporterFactory> factoryIteratorSPI = ServiceLoader.load(MetricReporterFactory.class).iterator(); final Iterator<MetricReporterFactory> factoryIteratorPlugins = pluginManager != null ? pluginManager.load(MetricReporterFactory.class) : Collections.emptyIterator(); return Iterators.concat(factoryIteratorPlugins, factoryIteratorSPI); }该代码会通过Java的SPI机制来获取MetricReporter的相干实现类，实质上是通过ClassLoder来获取。 |-- ReporterSetup \-- fromConfiguration //当集群启动时，会从配置读取监控并初始化相干类 \-- loadAvailableReporterFactories // 加载无效的Reporter们 \-- getAllReporterFactories // 外围代码，通过SPI以及ClassLoader机制获取Repoter们2. 内置松耦合上文提到了社区会提供常见的一些监控Repoter。在代码中，实质是工厂模式的实现。 /** * {@link MetricReporter} factory. * * <p>Reporters that can be instantiated with a factory automatically qualify for being loaded as a * plugin, so long as the reporter jar is self-contained (excluding Flink dependencies) and contains * a {@code META-INF/services/org.apache.flink.metrics.reporter.MetricReporterFactory} file * containing the qualified class name of the factory. * * <p>Reporters that previously relied on reflection for instantiation can use the {@link * InstantiateViaFactory} annotation to redirect reflection-base instantiation attempts to the * factory instead. */public interface MetricReporterFactory { /** * Creates a new metric reporter. * * @param properties configured properties for the reporter * @return created metric reporter */ MetricReporter createMetricReporter(final Properties properties);}每接入一个监控，只有实现相应的工厂办法即可。目前实现的有： ...

何其有幸咱们身处开源软件群星璀璨的年代数据的价值被从新定义工夫，愈发争分夺秒时代，在召唤它的弄潮儿。 作为主打流解决的计算引擎 Apache Flink 应运而生。2014 年正式开源，2018 年至今已间断三年蝉联 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 2021 正式上线！作为最受社区开发者期盼的年度顶会，往年的 Flink Forward Asia 2021 已正式启动！FFA 2021 将于 12 月 4-5 日在北京·国家会议核心举办，预计将有 3000+ 开发者参加，探讨交换 Flink 最新动静。 连续 FFA 常规，会议所有议题均为凋谢征集而来，并由业余的议题评比委员会评分筛选，内容齐全去商业化，代表行业领先水平。 往年的议题投递形式有两种： 挪动端可间接点击 https://survey.aliyun.com/app... 投递；PC 端可关上 Flink 中文社区网站，点击最新公告栏 FFA 流动投递议题：https://flink-learning.org.cn/参考下图所示： ...

1.Flink状态治理详解：Keyed State和Operator List State深度解析Flink状态治理详解：Keyed State和Operator List State深度解析

1.解决Flink中org.apache.flink.client.program.ProgramInvocationException:在jar文件中找不到flink以jar包模式打到镜像外面:而后k8s拉取镜像进行运行,而后报错: 排查解决过程:1.去docker镜像特定目录去查看:发现有特定目录的包。然而就是起不来。 最初咱们查看上传包权限:发现只有读取包权限:

简介： 介绍了 37 手游为何抉择 Flink 作为计算引擎，并如何基于 Flink CDC + Hudi 构建新的湖仓一体计划。 本文作者是 37 手游大数据开发徐润柏，介绍了 37 手游为何抉择 Flink 作为计算引擎，并如何基于 Flink CDC + Hudi 构建新的湖仓一体计划，次要内容包含： Flink CDC 基本知识介绍 Hudi 基本知识介绍 37 手游的业务痛点和技术计划选型 37 手游湖仓一体介绍 Flink CDC + Hudi 实际 总结 一、Flink-CDC 2.0Flink CDC Connectors 是 Apache Flink 的一个 source 端的连接器，目前 2.0 版本反对从 MySQL 以及 Postgres 两种数据源中获取数据，2.1 版本社区确定会反对 Oracle，MongoDB 数据源。 Fink CDC 2.0 的外围 feature，次要体现为实现了以下三个十分重要的性能： 全程无锁，不会对数据库产生须要加锁所带来的危险； 多并行度，全量数据的读取阶段反对程度扩大，使亿级别的大表能够通过加大并行度来放慢读取速度； 断点续传，全量阶段反对 checkpoint，即便工作因某种原因退出了，也可通过保留的 checkpoint 对工作进行复原实现数据的断点续传。 Flink CDC 2.0 详解外围改良 ...

本文作者是 37 手游大数据开发徐润柏，介绍了 37 手游为何抉择 Flink 作为计算引擎，并如何基于 Flink CDC + Hudi 构建新的湖仓一体计划，次要内容包含： Flink CDC 基本知识介绍Hudi 基本知识介绍37 手游的业务痛点和技术计划选型37 手游湖仓一体介绍Flink CDC + Hudi 实际总结一、Flink-CDC 2.0Flink CDC Connectors 是 Apache Flink 的一个 source 端的连接器，目前 2.0 版本反对从 MySQL 以及 Postgres 两种数据源中获取数据，2.1 版本社区确定会反对 Oracle，MongoDB 数据源。 Fink CDC 2.0 的外围 feature，次要体现为实现了以下三个十分重要的性能： 全程无锁，不会对数据库产生须要加锁所带来的危险；多并行度，全量数据的读取阶段反对程度扩大，使亿级别的大表能够通过加大并行度来放慢读取速度；断点续传，全量阶段反对 checkpoint，即便工作因某种原因退出了，也可通过保留的 checkpoint 对工作进行复原实现数据的断点续传。Flink CDC 2.0 详解外围改良二、HudiApache Hudi 目前被业内形容为围绕数据库内核构建的流式数据湖平台 (Streaming Data Lake Platform)。 因为 Hudi 领有良好的 Upsert 能力，并且 0.10 Master 对 Flink 版本反对至 1.13.x，因而咱们抉择通过 Flink + Hudi 的形式为 37 手游的业务场景提供分钟级 Upsert 数据的剖析查问能力。 ...

简介： 58 同城的实时 SQL 建设以及如何从 Storm 迁徙至 Flink。本文整顿自 58 同城实时计算平台负责人冯海涛在 Flink Forward Asia 2020 分享的议题《Flink 在 58 同城利用与实际》，内容包含： 实时计算平台架构实时 SQL 建设Storm 迁徙 Flink 实际一站式实时计算平台后续布局 一、实时计算平台架构实时计算平台的定位是为 58 团体海量数据提供高效、稳固的实时计算一站式服务。一站式服务次要分为三个方向： 第一个方向是实时数据存储，次要负责为线上业务接入提供高速度的实时存储能力。 第二是实时数据计算，次要为海量数据的解决提供分布式计算框架。 第三是实时数据散发，次要负责将计算后的数据散发到后续的实时存储，供下层利用。 平台建设次要分为两个局部： 第一局部是根底能力建设，目前次要包含 Kafka 集群、storm 集群、 Flink 集群、SparkStreaming 集群。 另一部分是平台化建设，次要是包含两点： 第一个是数据散发，咱们的数据散发是基于 Kafka Connect 打造的一个平台，指标是实现异构数据源的集成与散发。在理论应用数据场景过程中，常常须要将不同的数据源汇聚到一起进行计算剖析。 传统形式可能须要针对不同的存储采纳不同的数据同步计划。咱们的数据散发是通过提供一套残缺的架构，实现不同数据源的集成和散发。 第二个是咱们基于 Flink 打造的一站式实时计算平台，后文会有具体的介绍。 上图是咱们的实时计算平台的架构。 在实时数据接入这部分，咱们采纳的是 Kafka，binlog 提供 canal 和 debezium 两种形式进行接入。在业务日志这部分，咱们次要采纳 flume 进行线上业务的 log 的采集。在实时计算引擎这部分，依据开源社区倒退以及用户的需要，从最早的 Storm 到起初引入 SparkStreaming，以及当初支流的 Flink。在实时存储这部分，为了满足多元化的实时需要，咱们反对 Kafka、Druid、Hbase、ES、ClickHouse。同时在计算架构之上，咱们建设了一些治理平台，比方集群治理，它次要负责集群的扩容，稳定性的治理。另一个是 Nightfury，次要负责集群治理，包含数据接入、权限治理、资源管理等等。咱们在业务倒退过程中，引入了 Flink 计算框架。首先从业务来说，58 是一个一站式生存服务平台，蕴含很多业务线。随着业务的倒退，数据量越来越大，场景越来越丰盛，须要一个更加弱小的计算框架来满足用户的需要。 ...

本文由社区志愿者陈政羽整顿，内容源自阿里巴巴技术专家宋辛童 (五藏) 在 8 月 7 日线上 Flink Meetup 分享的《Flink 1.14 新个性预览》。次要内容为： 简介流批一体Checkpoint 机制性能与效率Table / SQL / Python API总结此文章为 8 月 7 日的分享整顿，1.14 版本最新进展采纳正文的形式在文末进行阐明。 一、简介1.14 新版本本来布局有 35 个比拟重要的新个性以及优化工作，目前曾经有 26 个工作实现；5 个工作不确定是否能准时实现；另外 4 个个性因为工夫或者自身设计上的起因，会放到后续版本实现。[1] 1.14 绝对于历届版本来说，囊括的优化和新增性能点其实并不算多。其实通过观察发版的节奏能够发现，通常在 1-2 个大版本后都会公布一个变动略微少一点的版本，次要目标是把一些个性稳定下来。 1.14 版本就是这样一个定位，咱们称之为品质改良和保护的版本。这个版本预计 8 月 16 日进行新个性开发，可能在 9 月份可能和大家正式见面，有趣味能够关注以下链接去跟踪性能公布进度。 Wiki：https://cwiki.apache.org/conf...Jira：https://issues.apache.org/jir...二、流批一体流批一体其实从 Flink 1.9 版本开始就受到继续的关注，它作为社区 RoadMap 的重要组成部分，是大数据实时化必然的趋势。然而另一方面，传统离线的计算需要其实并不会被实时工作齐全取代，而是会长期存在。 在实时和离线的需要同时存在的状态下，以往的流批独立技术计划存在着一些痛点，比方： 须要保护两套零碎，相应的就须要两组开发人员，人力的投入老本很高；另外，两套数据链路解决类似内容带来保护的风险性和冗余；最重要的一点是，如果流批应用的不是同一套数据处理系统，引擎自身差别可能会存在数据口径不统一的问题，从而导致业务数据存在肯定的误差。这种误差对于大数据分析会有比拟大的影响。在这样的背景下，Flink 社区认定了实时离线一体化的技术路线是比拟重要的技术趋势和方向。 Flink 在过来的几个版本中，在流批一体方面做了很多的工作。能够认为 Flink 在引擎层面，API 层面和算子的执行层面上做到了真正的流与批用同一套机制运行。然而在工作具体的执行模式上会有 2 种不同的模式： 对于有限的数据流，对立采纳了流的执行模式。流的执行模式指的是所有计算节点是通过 Pipeline 模式去连贯的，Pipeline 是指上游和上游计算工作是同时运行的，随着上游一直产出数据，上游同时在一直生产数据。这种全 Pipeline 的执行形式能够： 通过 eventTime 示意数据是什么时候产生的；通过 watermark 得悉在哪个工夫点，数据曾经达到了；通过 state 来保护计算中间状态；通过 Checkpoint 做容错的解决。下图是不同的执行模式： ...

本文作者陈易生，介绍了伴鱼平台机器学习特色零碎的降级，在架构上，从 Spark 转为 Flink，解决了特色上线难的问题，以及 SQL + Python UDF 如何用于生产实践。 次要内容为： 前言老版特色零碎 V1新版特色零碎 V2总结一、前言在伴鱼，咱们在多个在线场景应用机器学习进步用户的应用体验，例如：在伴鱼绘本中，咱们依据用户的帖子浏览记录，为用户举荐他们感兴趣的帖子；在转化后盾里，咱们依据用户的绘本购买记录，为用户举荐他们可能感兴趣的课程等。 特色是机器学习模型的输出。如何高效地将特色从数据源加工进去，让它可能被在线服务高效地拜访，决定了咱们是否在生产环境牢靠地应用机器学习。为此，咱们搭建了特色零碎，系统性地解决这一问题。目前，伴鱼的机器学习特色零碎运行了靠近 100 个特色，反对了多个业务线的模型对在线获取特色的需要。 上面，咱们将介绍特色零碎在伴鱼的演进过程，以及其中的衡量考量。 二、旧版特色零碎 V1特色零碎 V1 由三个外围组件形成：特色管道，特色仓库，和特色服务。整体架构如下图所示： 特色管道包含流特色管道和批特色管道，它们别离生产流数据源和批数据源，对数据通过预处理加工成特色 (这一步称为特色工程)，并将特色写入特色仓库。 批特色管道应用 Spark 实现，由 DolphinScheduler 进行调度，跑在 YARN 集群上；出于技术栈的统一思考，流特色管道应用 Spark Structured Streaming 实现，和批特色管道一样跑在 YARN 集群上。特色仓库选用适合的存储组件 (Redis) 和数据结构 (Hashes)，为模型服务提供低提早的特色拜访能力。之所以选用 Redis 作为存储，是因为： 伴鱼有丰盛的 Redis 应用教训；包含 DoorDash Feature Store [1] 和 Feast [2] 在内的业界特色仓库解决方案都应用了 Redis。特色服务屏蔽特色仓库的存储和数据结构，对外裸露 RPC 接口 GetFeatures(EntityName, FeatureNames)，提供对特色的低提早点查问。在实现上，这一接口根本对应于 Redis 的 HMGET EntityName FeatureName_1 ... FeatureName_N 操作。 这一版本的特色零碎存在几个问题： 算法工程师短少管制，导致迭代效率低。这个问题与零碎波及的技术栈和公司的组织架构无关。在整个零碎中，特色管道的迭代需要最高，一旦模型对特色有新的需要，就须要批改或者编写一个新的 Spark 工作。而 Spark 工作的编写须要有肯定的 Java 或 Scala 常识，不属于算法工程师的常见技能，因而交由大数据团队全权负责。大数据团队同时负责多项数据需要，往往有很多排期工作。后果便是新特色的上线波及频繁的跨部门沟通，迭代效率低；特色管道只实现了轻量的特色工程，升高在线推理的效率。因为特色管道由大数据工程师而非算法工程师编写，简单的数据预处理波及更高的沟通老本，因而这些特色的预处理水平都比拟轻量，更多的预处理被留到模型服务甚至模型外部进行，增大了模型推理的时延。为了解决这几个问题，特色零碎 V2 提出几个设计目标： ...

本⽂由社区志愿者苗文婷整顿，内容源⾃顺丰科技大数据平台研发工程师龙逸尘在 Flink Forward Asia 2020 分享的《Flink 在顺丰的利用实际》，次要分享内容为：顺丰基于 Flink 建设实时数仓的思路，引入 Hudi On Flink 减速数仓宽表，以及实时数仓平台化建设的实际。分为以下 5 个局部： 建设背景建设思路落地实际利用案例将来布局一、建设背景 顺丰是国内当先的快递物流综合服务商，通过多年的倒退，顺丰应用大数据技术支持高质量的物流服务。以下是一票快件的流转过程，能够看到从客户下单到最终客户收件的整个过程是十分长的，其中波及的一些解决逻辑也比较复杂。为了应答简单业务的挑战，顺丰进行了数据仓库的摸索。 传统数仓次要分为离线和实时两个局部。 离线局部以固定的计算逻辑，通过定时调度，实现数据抽取，荡涤，计算，最初产出报表；而实时局部则是需要驱动的，用户须要什么，就马上着手开发。这种数仓架构在数据量小、对实时性要求不高的状况下运行得很好。然而随着业务的倒退，数据规模的扩充和实时需要的一直增长，传统数仓的毛病也被放大了。 从业务指标的开发效率来看实时指标采纳的是需要驱动的、纵向烟囱式的开发模式，须要用户手写 Flink 工作进行开发，这种开发方式效率低门槛高，输入的指标很难对立治理与复用。 从技术架构方面来看离线和实时两套架构是不对立的，开发方式、运维形式、元数据方面都存在差别。传统架构整体还是以离线为主，实时为辅，依赖离线 T+1 调度导出报表，这些调度工作通常都运行在凌晨，导致凌晨时集群压力激增，可能会导致报表的产出不稳固；如果重要的报表产出有提早，相应的上游的报表产出也会呈现提早。这种以离线为主的架构无奈满足精细化、实时化经营的须要。 从平台治理的角度来看传统数仓的实时指标开发是比拟粗放的，没有 Schema 的标准，没有元数据的治理，也没有买通实时和离线数据之间的分割。 为了解决传统数仓的问题，顺丰开始了实时数仓的摸索。实时数仓和离线数仓实际上解决的都是雷同的业务问题，最大的区别就在于时效性。 离线数仓有小时级或天级的提早；而实时数仓则是秒级或分钟级的提早。其余个性，比方数据源、数据存储以及开发方式都是比拟相近的。因而，咱们心愿： 用户能从传统数仓平滑迁徙到实时数仓，保持良好的体验；同时对立实时和离线架构，放慢数据产出，缩小开发的撕裂感；增强平台治理，升高用户应用门槛，进步开发效率也是咱们的指标。二、建设思路通过总结，咱们提炼出以下 3 个实时数仓的建设思路。首先是通过对立数仓规范、元数据以及开发流程，使得用户达到开发体验上的批流对立。随后，引入 Hudi 减速数仓宽表，基于 Flink SQL 建设咱们的实时数仓。最初是增强平台治理，进行数仓平台化建设，实现数据对立接入、对立开发、以及对立的元数据管理。 1. 批流对立的实时数仓建设批流对立的实时数仓能够分为以下 3 个阶段： 1.1 对立数仓标准 首先，无规矩不成方圆，建设数仓必须有对立的数仓标准。对立的数仓标准包含以下几个局部： 设计规范命名标准模型标准开发标准存储标准流程标准对立好数仓标准之后，开始数仓层级的划分，将实时和离线统一规划数仓层级，分为 ODS、DWD、DWS、ADS 层。 1.2 对立元数据基于以上对立的数仓标准和层级划分模型，能够将实时和离线的元数据进行对立治理。上游的数据治理过程，比方数据字典、数据血统、数据品质、权限治理等都能够达到对立。这种对立能够积淀实时数仓的建设成绩，使数仓能更好的落地施行。 1.3 基于 SQL 对立开发流程 开发人员都晓得，应用 DataStream API 开发 Flink 工作是比较复杂的。在数据量比拟大的状况下，如果用户应用 API 不标准或者开发能力有余，可能会导致性能和稳定性的问题。如果咱们能将实时开发的过程对立到 SQL 上，就能够达到缩小用户开发成本、学习老本以及运维老本的目标。 ...

本文整顿自京东高级技术专家付海涛在 Flink Forward Asia 2020 分享的议题《Apache Flink 在京东的实际与优化》，内容包含： 业务演进和规模容器化实际Flink 优化改良将来布局一、业务演进和规模1. 业务演进京东在 2014 年基于 storm 打造了第一代流式解决平台，能够较好的满足业务对于数据处理实时性的要求。不过它有一些局限性，对于那些数据量特地大，然而对提早却不那么敏感的业务场景，显得有些力不从心。于是咱们在 2017 年引入了 Spark streaming，利用它的微批处理来应答这种业务场景。 随着业务的倒退和业务规模的扩充，咱们迫切需要一种兼具低提早和高吞吐能力，同时反对窗口计算、状态和恰好一次语义的计算引擎。 于是在 2018 年，咱们引入了 Flink，同时开始基于 K8s 进行实时计算容器化的降级革新；到了 2019 年，咱们所有的实时计算工作都跑在 K8s 上了。同年咱们基于 Flink 1.8 打造了全新的 SQL 平台，不便业务开发实时计算利用；到了 2020 年，基于 Flink 和 K8s 打造的全新实时计算平台曾经比较完善了，咱们进行了计算引擎的对立，同时反对智能诊断，来升高用户开发和运维利用的老本和难度。在过来，流解决是咱们关注的一个重点。同年，咱们也开始反对批处理，于是整个实时计算平台开始朝着批流一体的方向演进。 2. 业务场景京东 Flink 服务于京东外部十分多的业务线，次要利用场景包含实时数仓、实时大屏、实时举荐、实时报表、实时风控和实时监控，当然还有其余一些利用场景。总之，实时计算的业务需要，个别都会用 Flink 进行开发。 3. 业务规模目前咱们的 K8s 集群由 5000 多台机器组成，服务了京东外部 20 多个一级部门。目前在线的流计算工作数有 3000 多，流计算的解决峰值达到 5亿条每秒。 二、容器化实际上面分享一下容器化的实际。 在 2017 年，京东外部的大多数工作还是 storm 工作，它们都是跑在物理机上的，同时还有一小部分的 Spark streaming 跑在 Yarn 上。不同的运行环境导致部署和运维的老本特地高，并且在资源利用上有肯定的节约，所以咱们迫切需要一个对立集群资源管理和调度零碎，来解决这个问题。 ...