Flink

作者｜Alan 导读：滴滴实时计算引擎从 Flink-1.4 无缝降级到 Flink-1.10 版本，做到了齐全对用户通明。并且在新版本的指标、调度、SQL 引擎等进行了一些优化，在性能和易用性上相较旧版本都有很大晋升。 这篇文章介绍了咱们降级过程中遇到的艰难和思考，心愿能给大家带来启发。 一、 背景在本次降级之前，咱们应用的次要版本为 Flink-1.4.2，并且在社区版本上进行了一些加强，提供了 StreamSQL 和低阶 API 两种服务模式。现有集群规模达到了 1500 台物理机，运行工作数超过 12000 ，日均解决数据 3 万亿条左右。 不过随着社区的倒退，尤其是 Blink 合入 master 后有很多性能和架构上的降级，咱们心愿能通过版本升级提供更好的流计算服务。往年 2 月份，里程碑版本 Flink-1.10 公布，咱们开始在新版上上进行开发工作，踏上了充斥挑战的降级之路。 二、 Flink-1.10 新个性作为 Flink 社区至今为止的最大的一次版本升级，退出的新个性解决了之前遇到很多的痛点。 1. 原生 DDL 语法与 Catalog 反对Flink SQL 原生反对了 DDL 语法，比方 CREATE TABLE/CREATE FUNCTION，能够应用 SQL 进行元数据的注册，而不须要应用代码的形式。 也提供了 Catalog 的反对，默认应用 InMemoryCatalog 将信息长期保留在内存中，同时也提供了 HiveCatalog 能够与 HiveMetastore 进行集成。也能够通过本人拓展 Catalog 接口实现自定义的元数据管理。 2.Flink SQL 的加强基于 ROW_NUMBER 实现的 TopN 和去重语法，拓展了 StreamSQL 的应用场景。实现了 BinaryRow 类型作为外部数据交互，将数据间接以二进制的形式构建而不是对象数组，比方应用一条数据中的某个字段时，能够只反序列其中局部数据，缩小了不必要的序列化开销。新增了大量内置函数，例如字符串解决、FIRST/LAST_VALUE 等等，因为不须要转换为内部类型，相较于自定义函数效率更高。减少了 MiniBatch 优化，通过微批的解决形式晋升工作的吞吐3.内存配置优化之前对 Flink 内存的治理始终是一个比拟头疼的问题，尤其是在应用 RocksDB 时，因为一个 TaskManager 中可能存在多个 RocksDB 实例，不好估算内存使用量，就导致常常产生内存超过限度被杀。 ...

整顿｜路培杰（Flink 社区志愿者） 摘要：Apache Flink 是目前大数据畛域十分风行的流批对立的计算引擎，数据湖是适应云时代倒退潮流的新型技术架构，以 Iceberg、Hudi、Delta 为代表的解决方案应运而生，Iceberg 目前反对 Flink 通过 DataStream API /Table API 将数据写入 Iceberg 的表，并提供对 Apache Flink 1.11.x 的集成反对。 本文由腾讯数据平台部高级工程师苏舒分享，次要介绍腾讯大数据部门基于 Apache Flink 和 Apache Iceberg 构建实时数仓的利用实际，介绍次要包含如下几个方面： 背景及痛点数据湖 Apache Iceberg 的介绍Flink+Iceberg 构建实时数仓将来布局一．背景及痛点如图 1 所示，这是以后曾经助力的一些外部利用的用户，其中小程序和视频号这两款利用每天或者每个月产生的数据量都在 PB 级或者 EB 级以上。 图1 这些利用的用户在构建他们本人的数据分析平台过程中，他们往往会采纳图 2 这样的一个架构，置信大家对这个架构也十分的相熟了。 1.数据平台架构业务方比方腾讯看点或者视频号的用户，他们通常会采集利用前端的业务打点数据以及应用服务日志之类的数据，这些数据会通过消息中间件（Kafka/RocketMQ）或者数据同步服务 (flume/nifi/dataX) 接入数仓或者实时计算引擎。 在数仓体系中会有各种各样的大数据组件，譬如 Hive/HBase/HDFS/S3，计算引擎如 MapReduce、Spark、Flink，依据不同的需要，用户会构建大数据存储和解决平台，数据在平台通过解决和剖析，后果数据会保留到 MySQL、Elasticsearch 等反对疾速查问的关系型、非关系型数据库中，接下来应用层就能够基于这些数据进行 BI 报表开发、用户画像，或基于 Presto 这种 OLAP 工具进行交互式查问等。 图2 2.Lambda 架构的痛点在整个过程中咱们经常会用一些离线的调度零碎，定期的（T+1 或者每隔几小时）去执行一些 Spark 剖析工作，做一些数据的输出、输入或是 ETL 工作。离线数据处理的整个过程中必然存在数据提早的景象，不论是数据接入还是两头的剖析，数据的提早都是比拟大的，可能是小时级也有可能是天级别的。另外一些场景中咱们也经常会为了一些实时性的需要去构建一个实时处理过程，比方借助 Flink+Kafka 去构建实时的流解决零碎。 ...

本文由美团研究员、实时计算负责人鞠大升分享，次要介绍 Flink 助力美团数仓增量生产的利用实际。内容包含： 数仓增量生产流式数据集成流式数据处理流式 OLAP 利用将来布局一、数仓增量生产1.美团数仓架构先介绍一下美团数仓的架构以及增量生产。如下图所示，这是美团数仓的简略架构，我把它叫做三横四纵。所谓三横，第一是贯通全链路的元数据以及血统，贯通数据集成、数据处理、数据生产、以及数据利用的全过程链路。另外一块贯通全链路的是数据安全，包含受限域的认证零碎、权限零碎、整体的审计零碎。依据数据的流向，咱们把数据处理的过程分为数据集成、数据处理、数据生产、以及数据利用这 4 个阶段。 在数据集成阶段，咱们对于公司外部的，比如说用户行为数据、日志数据、DB 数据、还有文件数据，都有相应的集成的零碎把数据对立到咱们的数据处理的存储中，比如说 Kafka 中。在数据处理阶段，分为流式解决链路、批处理链路以及基于这套链路的数仓工作平台（万象平台）。生产进去的数据，通过 Datalink 导入到生产的存储中，最终通过利用以不同的模式出现进去。 咱们目前在 Flink 下面利用比拟宽泛的中央，包含从 Kafka 把数据导到 Hive，包含实时的解决，数据导出的过程。明天的分享就集中在这些方面。 2.美团 Flink 利用详情美团的 Flink 目前大略有 6000 台左右的物理机，撑持了 3 万左右的作业。咱们生产的 Topic 数在 5 万左右，每天的顶峰流量在 1.8 亿条每秒这样的程度上。 3.美团 Flink 利用场景美团 Flink 次要利用的场景包含四大块。 第一，实时数仓、经营剖析、经营剖析、实时营销。第二，举荐、搜寻。第三，风控、系统监控。第四，平安审计。 4.实时数仓 vs 数仓增量生产接下来我要引入增量生产的概念。离线数仓关注的三块需要，第一个就是时效性。第二个就是品质，产出的数据的品质。第三个就是老本。 对于时效性，有两个更深层次的含意，第一个叫做实时，第二个叫准时。并不是所有的业务需要都是实时的，很多时候咱们的需要是准时。比方做经营剖析，每天拿到相应的昨天的经营数据状况即可。实时数仓更多的是解决实时方面的需要。然而在准时这一块，作为一个企业，更心愿在准时跟老本之间做一个衡量。所以，我把数仓的增量生产定义为对离线数仓的一个对于准时跟老本的衡量。另外，数仓增量生产解决比拟好的一个方面是品质，问题可能及时发现。 5.数仓增量生产的劣势数仓增量生产的劣势有两点。 可能及时发现数据品质问题，防止 T+1 修复数据。充分利用资源，提前数据产出工夫。如下图所示，咱们冀望做的实际上是第二幅图。咱们冀望把离线的生产占用的资源升高，但同时心愿它的产出工夫可能提前一步。 二、流式数据集成1.数据集成 V1.0咱们来看一下流式数据集成的第一代。当数据量十分小以及库非常少的时候，间接做一个批的传输零碎。在每天凌晨的时候把相应的 DB 数据全副 load 一遍，导到数仓外面。这个架构劣势是非常简单，易于保护，然而它的毛病也非常明显，对于一些大的 DB 或者大的数据，load 数据的工夫可能须要 2~3 个小时，十分影响离线数仓的产出工夫。 2.数据集成 V2.0基于这个架构，咱们减少了流式传递的链路，咱们会有通过流式传输的采集零碎把相应的 Binlog 采集到 Kafka，同时会通过一个 Kafka 2 Hive 的程序把它导入到原始数据，再通过一层 Merge，产出上游须要的 ODS 数据。 ...

整顿 | Aven (Flink 社区志愿者) 摘要：本文由 Apache Flink Committer，字节跳动架构研发工程师李本超分享，以四个章节来介绍 Flink 在字节的利用实战。 内容如下： 整体介绍实际优化流批一体将来布局一、整体介绍 2018 年 12 月 Blink 发表开源，经验了约一年的工夫 Flink 1.9 于 2019 年 8 月 22 公布。在 Flink 1.9 公布之前字节跳动外部基于 master 分支进行外部的 SQL 平台构建。经验了 2~3 个月的工夫字节外部在 19 年 10 月份公布了基于 Flink 1.9 的 Blink planner 构建的 Streaming SQL 平台，并进行外部推广。在这个过程中发现了一些比拟有意思的需要场景，以及一些较为奇怪的 BUG。 基于 1.9 的 Flink SQL 扩大尽管最新的 Flink 版本曾经反对 SQL 的 DDL，但 Flink 1.9 并不反对。字节外部基于 Flink 1.9 进行了 DDL 的扩大反对以下语法： ...

作者｜王峰 本文由 Apache Flink 中文社区发起人，阿里云计算平台事业部实时计算与开放平台部门负责人王峰分享，次要介绍 Flink 作为一款对立的流批一体引擎其倒退现状及将来布局。纲要如下： 2020：Apache Flink 社区生态减速凋敝的一年技术创新：Apache Flink 社区倒退的外围驱动力Flink 在阿里巴巴的现状和将来2020：Apache Flink 社区生态减速凋敝的一年1.Flink 蝉联 Apache 社区最沉闷我的项目 咱们先来介绍一下在 2020 年 Flink 社区生态倒退的态势。整体来说，社区处在一个十分衰弱和高速的倒退过程中，尤其是在 2020 年，咱们获得了十分好的成绩。从 Apache 软件基金会 2020 财年的报告中，能够看到一些很要害的数据： Flink 用户和开发者邮件列表活跃度 Top1Github 上 Flink 代码提交次数 Top2Github 上 Flink 的用户访问量 Top2综合这几个数据来看，能够认为 Flink 在 Apache 泛滥的开源我的项目中名落孙山，是 Apache 最沉闷的我的项目之一。咱们在 Github 上 Star 的数量，以及 Flink 贡献者数量的增长趋势也是十分喜人的。最近几年来，咱们始终处在一个减速上涨的过程，每年都是均匀 30% 以上的数据增长，能够看出 Flink 整个生态的凋敝和高速倒退。 2.Apache Flink 年度公布总结 咱们再回顾一下 2020 年整个社区在技术上获得的成绩。Flink 社区在 2020 年公布了三个大的版本， Flink-1.10，Flink-1.11，以及 12 月最新公布的 Flink-1.12 三大版本。这三个版本绝对于去年收官的版本 Flink-1.9 有十分大的提高。 ...

作者｜白学余 本文由中原银行大数据平台研发工程师白学余分享，次要介绍实时金融数据湖在中原银行的利用。次要内容包含： 1、背景详情 2、实时金融数据湖体系架构 3、场景实际 一、背景详情首先简略介绍一下中原银行，它位于河南省郑州市，是河南省惟一的省级法人银行，是河南省最大的城市商业银行。2017 年 7 月 19 日在香港胜利上市。中原银行在成立之初就将科技利行和科技兴行作为我行的策略，我行立志要成为一个科技银行和数据银行。咱们始终在从事技术，也崇尚技术，心愿用技术的伎俩来解决当初的问题。 本文将从实时金融数据湖的建设背景、体系架构、场景实际三个方面分享。 1.数据湖诞生的业务背景■ 决策形式变迁 上面来看一下背景详情，咱们认为当初的银行的决策形式正面临微小的变迁。 首先，传统的银行数据分析次要集中在银行的支出、老本、利润的调配和应答监管部门的监管。这些数据分析非常复杂，但也存在肯定的法则，它属于财务数据分析。随着互联网金融的一直倒退，银行的业务一直受到挤压，如果依然将数据分析集中在支出、老本、调配及监管方面，曾经不能满足业务的需要。现在，更好的理解客户，收集大量的数据，做更多有针对性的营销和决策分析是事不宜迟。因而，当初银行的业务剖析决策由传统的财务剖析逐渐转向面向 KYC 的剖析。其次，传统的银行业务次要依附业务人员进行决策以满足业务的倒退需要。然而随着银行业务的一直倒退，各种各样的利用产生大量的多类型数据。仅仅依附业务人员去做决策，已无奈满足业务的需要。以后面临的问题更加简单，影响因素也日渐增多，须要用更全面、智能的技术形式来进行解决。因而，银行须要将传统的纯业务人员决策形式转变为越来越多依附机器智能的决策形式。■ 问题剖析 大数据的时代最大的特点就是数据量大、数据的类型多。在应用大规模数据的过程中波及各种各样的技术，包含： 传统的面向财务剖析离线数据分析面向非财务的数据分析面向事件或日志等频繁变更实时性较高的数据分析咱们须要多样化的数字营销伎俩来描述更全面、精确、迷信的客户画像。同时，也须要实时危险决策技术来实时监控业务面临的危险、多模数据加工技术来无效撑持不同类型的数据，包含结构化数据、半结构化数据、非结构化数据等。当然也须要机器学习和人工智能技术来反对问题的智能剖析和决策。 如此多的技术，加上数据驱动决策的场景，决定了以后银行的数据分析面临着一个微小的变迁，从传统的面向财务的、面向离线的数据分析，逐渐转向面向客户的、面向实时的数据分析。以上是实时金融数据湖建设的第一个观点。 2.数据湖诞生的技术背景实时金融数据湖建设的第二个观点是，在银行体系下，面向规范化、精准加工的传统数仓体系，可能较好的解决财务剖析等场景，并在很长时间内仍会是支流计划。 ■ 传统数仓架构 下图展现的是传统的数仓架构。从下往上，顺次是根底贴源层、公共数据的整合层、业务集市层和利用加工层。不同的层每天通过批的形式执行大量的运算，来失去业务想要的后果。银行很长时间内十分依赖传统的数仓体系，因为它十分好的解决了财务剖析的问题。其特点也比拟显著： 精准、标准多层数据加工口径对立T+1 数据处理具备较高的性能通过长时间积攒积淀适宜财务剖析以上是传统数据仓库的劣势。当然它的毛病也比拟显著： 变更艰难单位存储老本较高不适宜海量日志、行为等变更频繁，实时性高的数据半结构化数据和非结构化数据兼容差以上是实时金融数据湖建设的第二个观点，即传统的数据仓库有它的劣势和有余，并将长期存在。 ■ 数仓的变迁 实时金融数据湖建设的第三个观点是，面向 KYC、机器智能的剖析，须要反对多类型数据、多时效数据、更加麻利的应用，因而须要新的与数据仓库互补的架构体系。 3.实时金融数据湖的特点通过以上介绍的三个观点引出明天介绍的主题，实时金融数据湖。 次要有三个特点： 第一，开放性。反对多类型场景，如 AI、非结构化、历史数据，海纳百川。第二，时效性。具备无效的反对实时剖析与实时决策的体系架构。第三，交融性。与银行数据仓库技术架构交融，对立数据视图。 整体的实时金融数据湖是一个交融的数据湖，它的交融理念次要体现在以下 6 个方面： 第一，数据汇聚的交融，各种海量、多样数据汇聚的中央，包含结构化、半构造以及非构造数据。第二，技术实现的交融，蕴含云计算、大数据、数据仓库的交融以及流计算和批处理技术的交融。第三，标准设计的交融，数据模型主题设计灵便，同时反对 Schema-on-read 和 Schema-on-write 模式，反对多维、关系数据模型。第四，数据管理的交融，数据湖和数仓元数据管理的对立以及用户开发体验的对立。第五，物理地位的交融，能够是物理集中的繁多大集群，也能够是物理扩散，逻辑集中的逻辑集群。第六，数据存储的交融，剖析数据对立存储的技术平台，合乎入湖仓规范的数据依照要求放入，升高存储和运维老本。1 二、体系架构1.实时金融数据湖架构■ 性能架构 首先来看一下实时金融数据湖的性能架构。在性能上，包含数据源、对立的数据接入、数据存储、数据开发、数据服务和数据利用。 第一，数据源。不仅仅反对结构化数据，也反对半结构化数据和非结构化数据。第二，对立数据接入。数据通过对立数据接入平台，按数据的不同类型进行智能的数据接入。第三，数据存储。包含数据仓库和数据湖，实现冷热温智能数据分布。第四，数据开发。包含工作开发，任务调度，监控运维，可视化编程。第五，数据服务。包含交互式查问，数据 API，SQL 品质评估，元数据管理，血统治理。第六，数据利用。包含数字化营销，数字化风控，数据化经营，客户画像。 ■ 逻辑架构 实时金融数据湖的逻辑架构次要有 4 层，包含存储层、计算层、服务层和产品层。 在存储层，有 MPP 数据仓库和基于 OSS/HDFS 的数据湖，能够实现智能存储管理。在计算层，实现对立的元数据服务。在服务层，有联邦数据计算和数据服务 API 两种形式。其中，联邦数据计算服务是一个联邦查问引擎，能够实现数据跨库查问，它依赖的就是对立元数据服务，查问的是数据仓库和数据湖中的数据。在产品层，提供智能服务：包 RPA、证照辨认、语言剖析、客户画像、智能举荐。商业剖析服务：包含自助剖析、客户洞察、可视化。数据开发服务：包含数据开发平台，自动化治理。 ...

本文由天猫数据负责人黄晓锋分享，次要介绍流批一体技术在天猫双11的利用。纲要如下：1、流批一体架构2、天猫双11实际3、将来布局 一、流批一体架构本文次要跟大家分享流批一体化的相干技术在天猫的利用。此前，在较长的工夫里 Lambda 架构根本能满足业务诉求。但当业务倒退到肯定阶段后，在数据品质、研发效力、稳定性上产生了局部新诉求，须要通过流批一体技术计划来解决。 往年 7 月份，咱们开始进行流批一体化的尝试，而后双 11 全副利用上线了，以后流批一体架构体现十分稳固。 1.传统数仓架构（Lambda）下图为传统的 Lambda 架构，包含业务层、存储层、计算层、服务层和应用层。传统的架构很灵便，流和批之间没有互相耦合，然而也会带来几个问题。 效率层面。流批底层数据模型不统一，导致应用层须要做大量的拼接逻辑（同比、环比、二次加工等），搭建效率低，且容易出错。老本层面。流批存储系统隔离（面向不同写入场景），提供的数据服务不统一，保护老本高。同时，手工创立数据同步工作，减少了开发成本和存储老本。品质与资源层面。首先，一个业务逻辑，两个引擎两套代码，SQL 逻辑不能复用，数据一致性和品质难以保障。其次，不同平台和引擎间切换，开发体验割裂，容易呈现变更脱漏。并且，批处理&流解决集群无奈做到错峰，资源利用率较低。 2.流批一体架构（Kappa+Lambda）基于 Lambda 架构的痛点，咱们设计了流批一体的新架构。如下图所示，流批一体的架构并不是替换原来的 Lambda 架构，它是 Kappa 和 Lambda 联合的架构。批处理和批存储仍然存在，实质上是在流的场景中寻找批场景。 ● 流批逻辑层，这是最重要的局部之一。业务层和存储层依然不变，在此之上构建一个流批逻辑层来进行流存储和批存储的映射。有了这个逻辑层，就能够基于 Flink 引擎面向对立的逻辑层做业务逻辑表白，并且输入是对立的。● 计算层，做流批对立解决。首先，一套代码，两种计算模式，逻辑对立，灵便切换，能够实现研发效率大幅晋升。其次，流批计算资源混部，资源利用率晋升。● 服务层，做流批对立存储，无需手工同步，无反复存储。● 应用层，进行产品组装，流批存储透明化，查问逻辑完全一致，利用端接入老本大幅升高，点查 / OLAP 剖析对立反对。 3.流批逻辑层示例这外面最外围的关键在于流批的逻辑层，如下图所示，是流批逻辑层示例。 在此列举外部的一张逻辑镜像表的例子。右边是 MaxCompute 表，及其表名和 schema。左边是 DataHub 的表，也有其表名和 schema。平台的次要性能在于把两个表名的字段进行镜像化、映射。比方，右边有 100 个字段，左边有 50 个字段，他们的交加可能是 30 个字段，而后将 30 个字段进行镜像化，并将其关联关系映射到一张逻辑镜像表下面去。平台还提供了智能映射，当字段名称、类型一样时，能够主动判断做映射。当然，也能够做一个人工的辅助映射。如此，流批一体的 Flink 工作就能够进行业务表白了。 4.典型流批模式举例以下将分享咱们外部反对的一个典型的流批模式。比方 Kafka 的流表，同时也有盘古的 MaxCompute 表，通过下面的模式映射到流批逻辑表。两头须要编写一个 SQL 业务逻辑的表白。业务逻辑的表白与流批是没有关系的，它只是表白了整个计算的逻辑。在计算逻辑之上，有纯流模式的配置，如流模式的并行度、所在的集群等，这些信息都是流模式相干的。 同时在下面也能够进行一个批模式的撰写，批模式更多依赖调度，是纯批模式，同时也会进行批的参数优化。这样的话，同一套 SQL 就面向两套配置了，而且两套配置能够同时开启。也就是说，这外面有三种模式，包含纯流模式、纯批模式、流批混合的模式。联合业务场景，能够进行灵便的切换。纯流模式能够间接写当天的分区，批的模式能够写历史分区。这种状况下，流和批之间的代码和业务逻辑齐全能够做到统一。同时在对立的模型汇总表中还能够做对立的存储，应用层搭建仅需关怀报表的表白逻辑即可。 5.新老研发模式比对上面是对新老研发模式的一个比对。 ● 第一个场景，批工作周期调度，流批工作因为输出源汇合不统一会导致差别，须要批工作周期调度勘误流输入后果。老模式的批处理工作须要在 MaxCompute、Hive、Spark 等解决零碎编写一套代码，而流是在 Flink 上编写，导致两套代码。在新的模式下面，齐全能够做到一套代码。Flink Batch 工作每天周期调度勘误流产生的历史数据。劣势是解决逻辑统一，一套代码实现流和批的调度，研发效率晋升一倍。● 第二个场景，批工作按需调度（回刷场景），流批工作计算结果完全一致，不须要批工作周期调度勘误。老的模式还是不变，在新的模式下，Flink Batch 工作每天空跑调度，当呈现口径变更时再启动手工工作。长处是解决逻辑统一、研发效率晋升一倍、批空跑调度，计算资源节俭 50%。 ...

本文由京东搜索算法架构团队分享，次要介绍 Apache Flink 在京东商品搜寻排序在线学习中的利用实际。文章的次要纲要如下： 1、背景 2、京东搜寻在线学习架构 3、实时样本生成 4、Flink Online Learning 5、监控零碎 6、布局总结 一、背景在京东的商品搜寻排序中，常常会遇到搜寻后果多样性有余导致系统非最优解的问题。为了解决数据马太效应带来的模型商品排序多样性的有余，咱们利用基于二项式汤普森采样建模，然而该算法仍存在对所有用户采纳统一的策略，未无效思考用户和商品的个性化信息。基于该现状，咱们采取在线学习，使深度学习和汤普森采样交融，实现个性化多样性排序计划，实时更新模型的关参数。 在该计划中，Flink 次要利用于实时样本的生成和 online learning 的实现。在在线学习过程中，样本是模型训练的基石，在超大规模样本数据的解决上，咱们比照了 Flink、Storm 和 Spark Streaming 之后，最终抉择用 Flink 作为实时样本流数据的生产以及迭代 online learning 参数的框架。在线学习的整体链路特地长，波及在线端特色日志、流式特色解决、流式特色与用户行为标签关联、异样样本解决、模型动静参数实时训练与更新等环节，online learning 对样本解决和参数状态解决的准确性和稳定性要求较高，任何一个阶段都有可能呈现问题，为此咱们接入京东的 observer 体系，领有残缺的全链路监控零碎，保障各个阶段数据的稳定性和完整性；上面咱们首先介绍一下京东搜寻在线学习架构。 二、京东搜寻在线学习架构京东搜寻的排序模型零碎架构次要包含以下几个局部： 1、Predictor 是模型预估服务，在 load 模型中分为 static 局部和 dynamic 局部，static 局部由离线数据训练失去，次要学习 user 和 doc 的浓密特色示意，dynamic 局部次要蕴含 doc 粒度的权重向量，这部分由实时的 online learning 工作实时更新。2、Rank 次要包含一些排序策略，在排序最终后果确定之后，会实时落特色日志，将 doc 的特色按程序写入特色数据流，作为后续实时样本的数据源(feature)。3、Feature Collector 的工作是承接在线预估零碎收回的特色数据，对上游屏蔽缓存、去重、筛选等在线零碎特有逻辑，产出 Query+Doc 粒度的特色流。4、Sample join 的工作将下面的 feature 数据、曝光、点击、加购、下单等用户行为标签数据作为数据源，通过 Flink 的 union + timer 数据模型关联成为合乎业务要求的样本数据，算法可依据指标需要抉择不同的标签作为正负样本标记。5、Online learning 工作负责生产上游生成的实时样本做训练，负责更新 model 的 dynamic 局部。 ...

作者：林小铂 在生产环境中，Flink 通常会部署在 YARN 或 k8s 等资源管理零碎之上，过程会以容器化（YARN 容器或 docker 等容器）的形式运行，其资源会受到资源管理零碎的严格限度。另一方面，Flink 运行在 JVM 之上，而 JVM 与容器化环境并不是特地适配，尤其 JVM 简单且可控性较弱的内存模型，容易导致过程因应用资源超标而被 kill 掉，造成 Flink 利用的不稳固甚至不可用。 针对这个问题，Flink 在 1.10 版本对内存治理模块进行了重构，设计了全新的内存参数。在大多数场景下 Flink 的内存模型和默认曾经足够好用，能够帮用户屏蔽过程背地的简单内存构造，然而一旦呈现内存问题，问题的排查和修复都须要比拟多的畛域常识，通常令普通用户望而生畏。 为此，本文将解析 JVM 和 Flink 的内存模型，并总结在工作中遇到和在社区交换中理解到的造成 Flink 内存应用超出容器限度的常见起因。因为 Flink 内存应用与用户代码、部署环境、各种依赖版本等因素都有严密关系，本文次要探讨 on YARN 部署、Oracle JDK/OpenJDK 8、Flink 1.10+ 的状况。此外，特别感谢 @宋辛童（Flink 1.10+ 新内存架构的次要作者）和 @唐云（RocksDB StateBackend 专家）在社区的答疑，令笔者受益匪浅。 JVM 内存分区对于大多数 Java 用户而言，日常开发中与 JVM Heap 打交道的频率远大于其余 JVM 内存分区，因而常把其余内存分区统称为 Off-Heap 内存。而对于 Flink 来说，内存超标问题通常来自 Off-Heap 内存，因而对 JVM 内存模型有更深刻的了解是十分必要的。 ...

作者 | 蔡适择（顺丰大数据平台负责人）整顿 | 赵阳（Flink 社区志愿者） 本文次要介绍顺丰在数据仓库的数据实时化、数据库 CDC、Hudi on Flink 上的实际利用及产品化教训。文章次要分为以下几局部： ● 顺丰业务介绍● Hudi on Flink● 产品化反对● 后续打算 1、顺丰业务1.1 顺丰大数据的利用先来看一下顺丰大数据业务的全景图。 大数据平台，两头的根底局部是大数据平台，这块是顺丰联合开源组件自行搭建的。与之相干的是大数据分析与人工智能，顺丰有一个十分强的地面部队，就是线下的快递小哥以及运输车辆，须要应用 AI 以及大数据分析来辅助治理，晋升整体效率。 区块链，顺丰对接了很多客户与商家，对于商家来说，首先须要确保快件是可信的可能做货物的交易与替换。这块波及的基本上都是品牌商家，溯源与存证的业务顺丰也有波及。 IoT，就像之前提及到的，因为顺丰地面部队较多，相应须要采集的数据也会比拟多。咱们的局部包裹中是有传感器的，车辆也有相干的传感器，如车辆的摄像头，以及快递小哥的手环（蕴含地理位置、员工的衰弱状态，对应做一些关心的行动）。同时，还有一些工作场景既有叉车，也有分拣设施，这些就须要大数据平台来做一些联动，因而 IoT 的利用绝对较多。 智慧供应链和智慧物流，这两块更多的是指如何用大数据的伎俩辅助业务做一些经营上的决策。比方咱们有很多 B 端客户，对于他们来说如何在每个仓库里备货，如何协调以及相互调拨，这部分就由智慧物流来实现。 上面这块就是 IOT 实际中的一部分： 从下面能够看出物流自身的环节是十分多的，下单、小哥收件、分拣、陆运直达等整个过程，红色解释局部是指咱们会做的一些 IoT 与大数据联合的利用，这里其实大部分都是基于 Flink 来实现的。 1.2 顺丰大数据技术矩阵上面这张图是顺丰目前大数据整体的架构概览： 1、数据集成层：最上面为数据集成层，因为顺丰的历史起因，所以蕴含了很多数据存储引擎，如 Oracle、MySQL、MongoDB 等，并且局部引擎仍会持续反对。右下物联网设施绝对较新，次要是进行蕴含一般文本、网络数据库、图像、音频、视频等的数据采集。 2、数据存储计算：实时这块顺丰目前用的最多的还是 Flink，Storm 没有标示进去，目前咱们在做迁徙。消息中间件解决目前次要应用 Kafka。而后左边存储构造的品种就绝对丰盛，因为不同的场景有不同的解决形式，比方数据分析须要性能比拟强的 Clickhouse；数仓和离线计算这块还是比拟传统，以 Hive 为主联合 Spark，目前咱们是联合 Flink 与 Hudi 去实现离线实时化。 3、数据产品，咱们偏向的还是首先降门槛，让外部开发与用户更容易上手。外部同学如果要把握如此多的组件，老本是十分高的，再加上规范化会导致沟通、保护以及运维的高额老本，所以咱们肯定要去做一些产品化、规范化的事件。 1.3 顺丰科技数据采集组成 上图就是咱们大数据整体数据采集的概览，数据采集以后包含微服务的利用，局部数据直发到 Kafka，还有些会落成日志，而后咱们本人做了一个日志采集工具，相似于 Flume，更加的轻量化，达到不丢、不重、以及近程的更新、限速。另外咱们也会将 Kafka 中的数据通过 Flink 放到 HDFS，以 Hudi 的模式去做。上面会具体介绍。 ...

导读：前端开发的实质是什么？响应式编程绝对于 MVVM 或者 Redux 有什么长处？响应式编程的思维是否能够利用到后端开发中？本文以一个新闻网站为例，论述在前端开发中如何应用响应式编程思维；再以计算电商平台双11每小时成交额为例，分享同样的思维在实时计算中的雷同与不同之处。一 、前端开发在开发什么大家在前端开发的过程中，可能会想过这样一个问题：前端开发到底是在开发什么？在我看来，前端开发的实质是让网页视图可能正确地响应相干事件。在这句话中有三个关键字："网页视图"，"正确地响应"和"相干事件"。 "相干事件"可能包含页面点击，鼠标滑动，定时器，服务端申请等等，"正确地响应"意味着咱们要依据相干的事件来批改一些状态，而"网页视图"就是咱们前端开发中最相熟的局部了。 依照这样的观点咱们能够给出这样 视图 = 响应函数(事件) 的公式： View = reactionFn(Event)在前端开发中，须要被处理事件能够归类为以下三种： ● 用户执行页面动作，例如 click, mousemove 等事件。 ● 近程服务端与本地的数据交互，例如 fetch, websocket。 ● 本地的异步事件，例如 setTimeout, setInterval async_event。 这样咱们的公式就能够进一步推导为： View = reactionFn(UserEvent | Timer | Remote API)二、利用中的逻辑解决为了可能更进一步了解这个公式与前端开发的关系，咱们以新闻网站举例，该网站有以下三个要求： ● 单击刷新：单击 Button 刷新数据。 ● 勾选刷新：勾选 Checkbox 时主动刷新，否则进行主动刷新。 ● 下拉刷新：当用户从屏幕顶端下拉时刷新数据。 如果从前端的角度剖析，这三种需要别离对应着： ● 单击刷新：click -> fetch ● 勾选刷新：change -> (setInterval + clearInterval) -> fetch ● 下拉刷新：(touchstart + touchmove + touchend) -> fetch news_app ...

Flink应用HiveCatalog能够通过批或者流的形式来解决Hive中的表。这就意味着Flink既能够作为Hive的一个批处理引擎，也能够通过流解决的形式来读写Hive中的表，从而为实时数仓的利用和流批一体的落地实际奠定了松软的根底。本文将以Flink1.12为例，介绍Flink集成Hive的另外一个十分重要的方面——Hive维表JOIN(Temporal Table Join)与Flink读写Hive表的形式。以下是全文，心愿本文对你有所帮忙。 Flink写入Hive表Flink反对以批处理(Batch)和流解决(Streaming)的形式写入Hive表。当以批处理的形式写入Hive表时，只有当写入作业完结时，才能够看到写入的数据。批处理的形式写入反对append模式和overwrite模式。 批处理模式写入向非分区表写入数据Flink SQL> use catalog myhive; -- 应用catalogFlink SQL> INSERT INTO users SELECT 2,'tom';Flink SQL> set execution.type=batch; -- 应用批处理模式Flink SQL> INSERT OVERWRITE users SELECT 2,'tom';向分区表写入数据-- 向动态分区表写入数据Flink SQL> INSERT OVERWRITE myparttable PARTITION (my_type='type_1', my_date='2019-08-08') SELECT 'Tom', 25;-- 向动静分区表写入数据Flink SQL> INSERT OVERWRITE myparttable SELECT 'Tom', 25, 'type_1', '2019-08-08';流解决模式写入流式写入Hive表，不反对Insert overwrite 形式，否则报如下谬误： [ERROR] Could not execute SQL statement. Reason:java.lang.IllegalStateException: Streaming mode not support overwrite.上面的示例是将kafka的数据流式写入Hive的分区表 -- 应用流解决模式Flink SQL> set execution.type=streaming;-- 应用Hive方言Flink SQL> SET table.sql-dialect=hive; -- 创立一张Hive分区表CREATE TABLE user_behavior_hive_tbl ( `user_id` BIGINT, -- 用户id `item_id` BIGINT, -- 商品id `cat_id` BIGINT, -- 品类id `action` STRING, -- 用户行为 `province` INT, -- 用户所在的省份 `ts` BIGINT -- 用户行为产生的工夫戳) PARTITIONED BY (dt STRING,hr STRING,mi STRING) STORED AS parquet TBLPROPERTIES ( 'partition.time-extractor.timestamp-pattern'='$dt $hr:$mi:00', 'sink.partition-commit.trigger'='partition-time', 'sink.partition-commit.delay'='0S', 'sink.partition-commit.policy.kind'='metastore,success-file');-- 应用默认SQL方言Flink SQL> SET table.sql-dialect=default; -- 创立一张kafka数据源表CREATE TABLE user_behavior ( `user_id` BIGINT, -- 用户id `item_id` BIGINT, -- 商品id `cat_id` BIGINT, -- 品类id `action` STRING, -- 用户行为 `province` INT, -- 用户所在的省份 `ts` BIGINT, -- 用户行为产生的工夫戳 `proctime` AS PROCTIME(), -- 通过计算列产生一个解决工夫列 `eventTime` AS TO_TIMESTAMP(FROM_UNIXTIME(ts, 'yyyy-MM-dd HH:mm:ss')), -- 事件工夫 WATERMARK FOR eventTime AS eventTime - INTERVAL '5' SECOND -- 定义watermark ) WITH ( 'connector' = 'kafka', -- 应用 kafka connector 'topic' = 'user_behaviors', -- kafka主题 'scan.startup.mode' = 'earliest-offset', -- 偏移量 'properties.group.id' = 'group1', -- 消费者组 'properties.bootstrap.servers' = 'kms-2:9092,kms-3:9092,kms-4:9092', 'format' = 'json', -- 数据源格局为json 'json.fail-on-missing-field' = 'true', 'json.ignore-parse-errors' = 'false');对于Hive表的一些属性解释： ...

作者：余敖 本文次要介绍在流式场景中 join 的实战。大家都晓得在应用 SQL 进行数据分析的过程中，join 是常常要应用的操作。在离线场景中，join 的数据集是有边界的，能够缓存数据有边界的数据集进行查问，有Nested Loop/Hash Join/Sort Merge Join 等多表 join；而在实时场景中，join 两侧的数据都是无边界的数据流，所以缓存数据集对长时间 job 来说，存储和查问压力很大，另外双流的达到工夫可能不统一，造成 join 计算结果准确度不够；因而，Flink SQL 提供了多种 join 办法，来帮忙用户应答各种 join 场景。 本文次要介绍 regular join/interval join/temproal table join 这种 3 种 join 的实战利用，次要蕴含如下几个局部： 数据筹备Flink SQL join 之 regular joinFlink SQL join 之 interval joinFlink SQL join 之 temproal table join总结01 数据筹备一般来说大部分公司的实时的数据是保留在 kafka，物料数据保留在 MySQL 等相似的关系型数据库中，依据 Flink SQL 提供的 Kafka/JDBC connector，咱们先注册两张 Flink Kafka Table 以及注册一张 Flink MySQL Table，明细建表语句如下所示： ...

本文次要介绍 HBase 和 Flink SQL 的联合应用。HBase 作为 Google 发表 Big Table 论文的开源实现版本，是一种分布式列式存储的数据库，构建在 HDFS 之上的 NoSQL 数据库，非常适合大规模实时查问，因而 HBase 在实时计算畛域应用十分宽泛。能够实时写 HBase，也能够利用 buckload 一把把离线 Job 生成 HFile Load 到HBase 表中。而当下 Flink SQL 的炽热水平不必多说，Flink SQL 也为 HBase 提供了 connector，因而 HBase 与 Flink SQL 的联合十分有必要实际实际。 当然，本文假如用户有肯定的 HBase 常识根底，不会具体去介绍 HBase 的架构和原理，本文着重介绍 HBase 和 Flink 在理论场景中的联合应用。次要分为两种场景，第一种场景：HBase 作为维表与 Flink Kafka table 做 temporal table join 的场景；第二种场景：Flink SQL 做计算之后的后果写到 HBase 表，供其余用户查问的场景。因而，本文介绍的内容如下所示： · HBase 环境筹备· 数据筹备· HBase 作为维度表进行 temporal table join的场景· Flink SQL 做计算写 HBase 的场景· 总结 ...

Apache Flink 是大数据畛域十分风行的流批对立的计算引擎，数据湖是适应云时代倒退潮流的新型技术架构。那么当 Apache Flink 遇见数据湖时，会碰撞出什么样的火花呢？本次分享次要包含以下核心内容： 数据湖的相干背景介绍；经典业务场景介绍；为什么抉择 Apache Iceberg；如何通过 Flink+Iceberg 实现流式入湖社区将来布局工作。视频回顾：https://www.bilibili.com/vide... 数据湖的相干背景介绍数据湖是个什么概念呢？一般来说咱们把一家企业产生的数据都保护在一个平台内，这个平台咱们就称之为“数据湖”。 看上面这幅图，这个湖的数据起源多种多样，有的可能是结构化数据，有的可能是非构造数据，有的甚至是二进制数据。有一波人站在湖的入口，用设施在检测水质，这对应着数据湖上的流解决作业；有一批抽水机从湖外面抽水，这对应着数据湖的批处理作业；还有一批人在船头钓鱼或者在岸上捕鱼，这对应着数据科学家从数据湖中通过机器学习的伎俩来提取数据价值。 咱们总结起来，其实数据湖次要有 4 个方面的特点。第一个特点是存储原始数据，这些原始数据起源十分丰盛；第二个特点是反对多种计算模型；第三个特点是有欠缺的数据管理能力，要能做到多种数据源接入，实现不同数据之间的连贯，反对 schema 治理和权限治理等；第四个特点是灵便的底层存储，个别用 ds3、oss、hdfs 这种便宜的分布式文件系统，采纳特定的文件格式和缓存，满足对应场景的数据分析需要。 那么开源数据湖架构个别是啥样的呢？这里我画了一个架构图，次要分为四层： 最底下是分布式文件系统，云上用户 S3 和 oss 这种对象存储会用的更多一些，毕竟价格便宜很多；非云上用户个别采纳本人保护的 HDFS。第二层是数据减速层。数据湖架构是一个存储计算彻底拆散的架构，如果所有的数据拜访都近程读取文件系统上的数据，那么性能和老本开销都很大。如果能把常常拜访到的一些热点数据缓存在计算节点本地，这就十分天然的实现了冷热拆散，一方面能播种到不错的本地读取性能，另一方面还节俭了近程拜访的带宽。这一层外面，咱们个别会抉择开源的 alluxio，或者抉择阿里云上的 Jindofs。第三层就是 Table format 层，次要是把一批数据文件封装成一个有业务意义的 table，提供 ACID、snapshot、schema、partition 等表级别的语义。个别对应这开源的 Delta、Iceberg、Hudi 等我的项目。对一些用户来说，他们认为Delta、Iceberg、Hudi 这些就是数据湖，其实这几个我的项目只是数据湖这个架构外面的一环，只是因为它们离用户最近，屏蔽了底层的很多细节，所以才会造成这样的了解。最上层就是不同计算场景的计算引擎了。开源的个别有 Spark、Flink、Hive、Presto、Hive MR 等，这一批计算引擎是能够同时拜访同一张数据湖的表的。 经典业务场景介绍那么，Flink 和数据湖联合能够有哪些经典的利用场景呢？这里咱们探讨业务场景时默认选型了 Apache Iceberg 来作为咱们的数据湖选型，前面一节会具体论述选型背地的理由。 首先，Flink+Iceberg 最经典的一个场景就是构建实时的 Data Pipeline。业务端产生的大量日志数据，被导入到 Kafka 这样的音讯队列。使用 Flink 流计算引擎执行 ETL后，导入到 Apache Iceberg 原始表中。有一些业务场景须要间接跑剖析作业来剖析原始表的数据，而另外一些业务须要对数据做进一步的提纯。那么咱们能够再新起一个 Flink 作业从 Apache Iceberg 表中生产增量数据，通过解决之后写入到提纯之后的 Iceberg 表中。此时，可能还有业务须要对数据做进一步的聚合，那么咱们持续在iceberg 表上启动增量 Flink 作业，将聚合之后的数据后果写入到聚合表中。 ...

在数据库中的动态表上做 OLAP 剖析时，两表 join 是十分常见的操作。同理，在流式解决作业中，有时也须要在两条流上做 join 以取得更丰盛的信息。Flink DataStream API 为用户提供了3个算子来实现双流 join，别离是： ● join() ● coGroup() ● intervalJoin() 本文举例说明它们的应用办法，顺便聊聊比拟非凡的 interval join 的原理。 筹备数据从 Kafka 别离接入点击流和订单流，并转化为 POJO。 DataStream<String> clickSourceStream = env .addSource(new FlinkKafkaConsumer011<>( "ods_analytics_access_log", new SimpleStringSchema(), kafkaProps ).setStartFromLatest());DataStream<String> orderSourceStream = env .addSource(new FlinkKafkaConsumer011<>( "ods_ms_order_done", new SimpleStringSchema(), kafkaProps ).setStartFromLatest());DataStream<AnalyticsAccessLogRecord> clickRecordStream = clickSourceStream .map(message -> JSON.parseObject(message, AnalyticsAccessLogRecord.class));DataStream<OrderDoneLogRecord> orderRecordStream = orderSourceStream .map(message -> JSON.parseObject(message, OrderDoneLogRecord.class));join()join() 算子提供的语义为"Window join"，即依照指定字段和（滚动/滑动/会话）窗口进行 inner join，反对解决工夫和事件工夫两种工夫特色。以下示例以10秒滚动窗口，将两个流通过商品 ID 关联，获得订单流中的售价相干字段。 ...

作者：王峰（莫问） 导读：往年的双11，实时计算解决的流量洪峰创纪录地达到了每秒40亿条的记录，数据体量也达到了惊人的每秒7TB，基于Flink的流批一体数据利用开始在阿里巴巴最外围的数据业务场景锋芒毕露，并在稳定性、性能和效率方面都禁受住了严苛的生产考验。本文深度解析“流批一体”在阿里外围数据场景首次落地的实践经验，回顾“流批一体”大数据处理技术的倒退历程。随着 11 月 11 日 12 点钟声的敲响，2020 年双 11 的 GMV 数字定格在了 4982 亿，在 Flink 实时计算技术的驱动下全程放弃了丝般顺滑滚动，基于 Flink 的阿里巴巴实时计算平台也圆满完成了往年双 11 整体经济体的实时数据工作保障，再次安稳度过全年大考。 除了 GMV 媒体大屏之外，Flink 还反对了诸如搜寻举荐实时机器学习，广告实时反作弊，菜鸟订单状态实时跟踪反馈，云服务器的实时攻打探测以及大量基础设施的监控报警等等重要业务。实时业务量和数据量每年都在大幅增长，往年的实时计算峰值达到了创纪录的每秒 40 亿条记录，数据体量也达到了惊人的7 TB 每秒，相当于一秒钟须要读完 500 万本《新华字典》。 截止目前，咱们的实时计算作业数达到了 35000 多个，集群总计算规模也达到了超过 150 万核，在中国乃至世界范畴内都处于领先水平。至此，Flink 曾经反对了阿里经济体所有的实时计算需要，实现了全链路数据实时化，第一工夫为消费者、商家以及经营人员带来了数据的价值。 但往年 Flink 技术演进带来的价值不仅于此，基于 Flink 的流批一体数据利用也开始在阿里巴巴最外围的数据业务场景锋芒毕露，并在稳定性、性能和效率方面都禁受住了严苛的生产考验。 “流批一体”在阿里外围数据场景首次落地事实上，Flink 流批一体技术很早就在阿里巴巴外部开始利用了。Flink 在阿里的倒退始于搜寻举荐场景，因而搜索引擎的索引构建以及机器学习的特色工程都曾经是基于 Flink的 批流一体架构。往年双11，Flink 更进一步，利用流批一体计算能力，助力数据中台实现更加精准的实时离线穿插数据分析和业务决策。 阿里的数据报表分为实时和离线两种，前者在诸如双 11 大促场景下的作用尤为显著，能够为商家、经营以及管理层提供各种维度的实时数据信息，并帮忙其及时作出决策，晋升平台和业务效率。例如：在典型的营销数据实时剖析场景，经营和决策层须要比照大促当天某个时间段和历史某个时间段的数据后果（比方大促当天 10 点的成交额和昨天 10 点成交额的比照），从而判断以后营销的成果，以及是否须要进行调控、如何调控等策略。 在下面这种营销数据分析场景下，实际上须要两套数据分析后果，一套是基于批处理技术在每天晚上计算出的离线数据报表，一套是基于流解决技术算出当天的实时数据报表，而后针对实时和历史数据进行比照剖析，依据比照后果进行相干决策。离线和实时报表别离是基于批和流两种不同计算引擎产出，即批和流拆散的架构不仅会有两套开发成本，更难以解决的是数据逻辑和口径对齐问题，很难保障两套技术开发出的数据统计后果是统一的。因而，现实的解决方案就是利用一套流批一体的计算引擎进行数据分析，这样离线和实时报表将人造统一。鉴于 Flink 流批一体计算技术的一直成熟，以及后期在搜寻举荐场景的胜利落地，往年双 11 数据平台开发团队也展现出动摇的信念和信赖，与 Flink 实时计算团队并肩作战，独特推动实时计算平台技术升级，第一次让基于 Flink 的流批一体数据处理技术在双 11 最外围的数据场景顺利落地。 ...

作者：王峰（莫问）、梅源 剩喜漫天飞玉蝶，不嫌幽谷阻黄莺。2020 年是不寻常的一年，Flink 也在这一年迎来了新纪元。 12 月13 – 15 号，2020 Flink Forward Asia（FFA）在春雪的号召下顺利拉开帷幕。Flink Forward Asia 是由 Apache 官网受权，Apache Flink Community China 反对举办的会议。通过两年的一直降级和欠缺，Flink Forward Asia 已成为国内最大的 Apache 顶级我的项目会议，是 Flink 开发者和使用者的年度盛会！往年因为疫情的起因，Flink Forward Asia 首次采纳线上线下双线同步会议的模式，吸引了更多的参会者观看探讨，三天理论总参加人数（UV）超过 9.2 万，单日最高观看人数（UV）超过 4 万。 FFA 大会从社区倒退，业内影响力和 Flink 引擎生态这三方面总结了 Flink 过来一年内的问题。 社区方面，如上图所示，依据 Apache 基金会财年报告颁布的各项外围指标显示，Flink 在 2020 年蝉联 Apache 社区最沉闷的我的项目。不仅如此，Flink Github 的星数（代表我的项目受欢迎水平）和 Flink 的社区代码贡献者（contributor）数量在过来数年中始终放弃年均 30%+ 的增长。尤其值得一提的是 Flink 中文社区的凋敝倒退：Flink 是以后 Apache 顶级我的项目中惟一一个开明了中文邮件列表（user-zh@flink.apache.org）的我的项目，且中文邮件列表的活跃度已超过英文邮件列表；Flink 的官网公众号订阅数超过 3 万人，全年推送超过 200 篇和 Flink 技术，生态以及实际相干的最新资讯。此外，Flink 官网中文学习网站也曾经正式开明：https://flink-learning.org.cn/ ，收纳了和 Flink 相干的学习材料，场景案例以及流动信息，心愿能对 Flink 感兴趣的同学有所助益。 ...

在上一篇分享Flink集成Hive之疾速入门--以Flink1.12为例中，介绍了Flink集成Hive的进本步骤。本文分享，将持续介绍Flink集成Hive的另外两个概念：Hive Catalog与Hive Dialect。本文包含以下内容，心愿对你有所帮忙。 什么是Hive Catalog如何应用Hive Catalog什么是Hive Dialect如何应用Hive Dialect公众号『大数据技术与数仓』，回复『材料』支付大数据资料包什么是Hive Catalog咱们晓得，Hive应用Hive Metastore(HMS)存储元数据信息，应用关系型数据库来长久化存储这些信息。所以，Flink集成Hive须要买通Hive的metastore，去治理Flink的元数据，这就是Hive Catalog的性能。 Hive Catalog的次要作用是应用Hive MetaStore去治理Flink的元数据。Hive Catalog能够将元数据进行长久化，这样后续的操作就能够重复应用这些表的元数据，而不必每次应用时都要从新注册。如果不去长久化catalog，那么在每个session中取解决数据，都要去反复地创立元数据对象，这样是十分耗时的。 如何应用Hive CatalogHiveCatalog是开箱即用的，所以，一旦配置好Flink与Hive集成，就能够应用HiveCatalog。比方，咱们通过FlinkSQL 的DDL语句创立一张kafka的数据源表，立即就能查看该表的元数据信息。 HiveCatalog能够解决两种类型的表：一种是Hive兼容的表，另一种是一般表(generic table)。其中Hive兼容表是以兼容Hive的形式来存储的，所以，对于Hive兼容表而言，咱们既能够应用Flink去操作该表，又能够应用Hive去操作该表。 一般表是对Flink而言的，当应用HiveCatalog创立一张一般表，仅仅是应用Hive MetaStore将其元数据进行了长久化，所以能够通过Hive查看这些表的元数据信息(通过DESCRIBE FORMATTED命令)，然而不能通过Hive去解决这些表，因为语法不兼容。 对于是否是一般表，Flink应用is_generic属性进行标识。默认状况下，创立的表是一般表，即is_generic=true，如果要创立Hive兼容表，须要在建表属性中指定is_generic=false。 尖叫提醒：因为依赖Hive Metastore，所以必须开启Hive MetaStore服务 代码中应用Hive Catalog EnvironmentSettings settings = EnvironmentSettings.newInstance().useBlinkPlanner().build(); TableEnvironment tableEnv = TableEnvironment.create(settings); String name = "myhive"; String defaultDatabase = "default"; String hiveConfDir = "/opt/modules/apache-hive-2.3.4-bin/conf"; HiveCatalog hive = new HiveCatalog(name, defaultDatabase, hiveConfDir); tableEnv.registerCatalog("myhive", hive); // 应用注册的catalog tableEnv.useCatalog("myhive");Flink SQLCli中应用Hive Catalog在FlinkSQL Cli中应用Hive Catalog很简略，只须要配置一下sql-cli-defaults.yaml文件即可。配置内容如下： catalogs: - name: myhive type: hive default-database: default hive-conf-dir: /opt/modules/apache-hive-2.3.4-bin/conf ...

本次由快手刘建刚老师分享，内容次要分为三局部。首先介绍流式计算的基本概念， 而后介绍 Flink 的关键技术，最初讲讲 Flink 在快手生产实践中的一些利用，包含实时指标计算和疾速 failover。 一、流式计算的介绍流式计算次要针对 unbounded data（无界数据流）进行实时的计算，将计算结果疾速的输入或者修改。 这部分将分为三个大节来介绍。第一，介绍大数据系统发展史，包含初始的批处理到当初比拟成熟的流计算；第二，为大家简略比照下批处理和流解决的区别；第三，介绍流式计算外面的关键问题，这是每个优良的流式计算引擎所必须面临的问题。 1、大数据系统发展史 上图是 2003 年到 2018 年大数据系统的发展史，看看是怎么一步步走到流式计算的。 2003 年，Google 的 MapReduce 横空出世，通过经典的 Map&Reduce 定义和零碎容错等保障来不便解决各种大数据。很快就到了 Hadoop，被认为是开源版的  MapReduce， 带动了整个apache开源社区的凋敝。再往后是谷歌的 Flume，通过算子连贯等 pipeline 的形式解决了多个 MapReduce 作业连贯解决低效的问题。 流式零碎的开始以 Storm 来介绍。Storm 在2011年呈现， 具备延时短、性能低等个性， 在过后颇受青睐。然而 Storm 没有提供零碎级别的 failover 机制，无奈保障数据一致性。那时的流式计算引擎是不准确的，lamda 架构组装了流解决的实时性和批处理的准确性，已经风行一时，起初因为难以保护也逐步败落。 接下来呈现的是 Spark Streaming，能够说是第一个生产级别的流式计算引擎。Spark Streaming 晚期的实现基于成熟的批处理，通过 mini batch 来实现流计算，在 failover 时可能保障数据的一致性。 Google 在流式计算方面有很多摸索，包含 MillWheel、Cloud Dataflow、Beam，提出了很多流式计算的理念，对其余的流式计算引擎影响很大。 再来看 Kafka。Kafka 并非流式计算引擎，然而对流式计算影响特地大。Kafka 基于log 机制、通过 partition 来保留实时数据，同时也能存储很长时间的历史数据。流式计算引擎能够无缝地与kafka进行对接，一旦呈现 Failover，能够利用 Kafka 进行数据回溯，保证数据不失落。另外，Kafka 对 table 和 stream 的摸索特地多，对流式计算影响微小。 ...

1.环境筹备指标实现构建一个以Flink SQL Client为根底，简略的读取mysql binlog增量同步数据到kafka topic中的Flink工作 利用筹备清单Docker Desktop windows桌面版/DockerFlink docker镜像(Flink 1.11.2 scala 2.12)MySQL docker镜像(latest)kafka docker镜像(latest)连接器清单flink-format-changelog-json-1.1.0.jar flink-sql-connector-kafka_2.12-1.11.2.jar flink-sql-connector-mysql-cdc-1.1.0.jar 备注：连接器须要独自下载并放到FLINK_HOME/lib下，可从阿里云镜像点下载相干jar包 仓库服务 https://maven.aliyun.com/应用命令docker cp ${jar} ${containerName}:/${dir}，从本地复制jar包到docker容器中 Docker compose.yml文件配置flink：compose-flink.yml version: "2.1" services: jobmanager: image: flink expose: - "6123" ports: - "8081:8081" command: jobmanager environment: - JOB_MANAGER_RPC_ADDRESS=jobmanager taskmanager: image: flink expose: - "6121" - "6122" depends_on: - jobmanager command: taskmanager links: - "jobmanager:jobmanager" environment: - JOB_MANAGER_RPC_ADDRESS=jobmanagermysql：compose-mysql.yml version: '2.1' services: mysql: image: debezium/example-mysql:1.1 ports: - "3306:3306" environment: - MYSQL_ROOT_PASSWORD=123456kafka：compose-kafka.yml ...

继搜索引擎之后，举荐零碎曾经成为挪动互联网时代人们获取信息的次要渠道，比方，风行的新闻 App 都会利用举荐零碎进行用户的个性化举荐。新闻举荐场景具备高度的实时性，每时每刻都会有大量的新闻、热点产生。王喆前辈的两篇博客曾经对举荐零碎的实时性问题进行了深刻的探讨： 天下文治，唯快不破，论举荐零碎的「 实时性」如何加强举荐零碎模型更新的「实时性」？增量更新、在线学习、部分更新甚至强化学习等训练策略能够令举荐零碎迅速的对用户的新行为做出反馈，而这些更新策略的前提是样本自身具备足够的实时性。新闻场景下，典型的训练样本是用户的点击等行为数据。用户行为数据在客户端收集之后，须要尽可能迅速的发回后盾生成训练样本，再尽快对模型进行更新。笔者于 2020 年夏在某千万用户级别新闻 App 举荐组实习，负责了样本实时化我的项目的次要开发工作。在这里对该我的项目进行技术层面的总结。 样本的产生与实时性首先讨论一下典型的新闻利用举荐零碎的 Data Pipline 与模型训练样本的产生。客户端将一组新闻曝光给用户之后，曝光数据流 PV (Page View) 会被立刻发送回后端 Online Service. 用户会点击感兴趣的新闻，产生用户行为数据流也即 Action 数据流，这部分数据也被发回后端。之后后端会将这些用户行为音讯写入音讯队列 Message Queue, 最终会将其落盘到分布式文件系统，如 HDFS 上。最简化的举荐零碎样本生成逻辑就是 PV Join Action. 用户只会对局部曝光新闻样本产生行为，这部分样本即为正样本，残余的没有产生行为的曝光样本即为负样本。生成正负样本之后即可进行模型的训练。 实时性要求不高的举荐零碎能够应用批处理技术（典型的工具是 Apache Spark）生成样本，如图 1 左图所示. 设置一个定时工作，每隔一段时间，比方一小时，从 HDFS 读取工夫窗内的用户行为日志、曝光日志进行 JOIN 操作，生成训练样本，再将训练样本写回 HDFS, 之后启动模型的训练更新。 图 1: 典型的新闻举荐零碎 Data pipeline 批处理一个显著的问题是延时。定时运行批处理工作典型的周期是一个小时，这就意味着从样本产生到模型训练至多有一个小时的延时，有时批处理平台负载过大，工作须要排队，则延时会更大。另一个问题是边界问题，上一段提到的，PV 数据如果产生在批处理工作选取的日志工夫窗结尾，则对应的 Action 数据可能会落到批处理工作的下一个工夫窗中，导致 Join 失败，产生假负样本。 为了加强实时性，咱们应用 Apache Flink 框架，将样本的生成逻辑以流解决技术重写。如图 1 右图所示。线上服务生成的用户曝光与行为日志写入音讯队列后，不再期待其落盘到 HDFS, 而是间接用 Flink 生产这些音讯流。Flink 同时从 Redis 缓存等地位读取必要的特色信息，间接生成样本音讯流。样本音讯流写回 Kafka 队列，上游 Tensorflow 能够间接生产该音讯流进行模型的训练。 ...

摘要：本文所介绍 Nebula Graph 连接器 Nebula Flink Connector，采纳相似 Flink 提供的 Flink Connector 模式，反对 Flink 读写分布式图数据库 Nebula Graph。 文章首发 Nebula Graph 官网博客：https://nebula-graph.com.cn/posts/nebula-flink-connector/ 在关系网络分析、关系建模、实时举荐等场景中利用图数据库作为后盾数据撑持已绝对遍及，且局部利用场景对图数据的实时性要求较高，如举荐零碎、搜索引擎。为了晋升数据的实时性，业界广泛应用流式计算对更新的数据进行增量实时处理。为了反对对图数据的流式计算，Nebula Graph 团队开发了 Nebula Flink Connector，反对利用 Flink 进行 Nebula Graph 图数据的流式解决和计算。 Flink 是新一代流批对立的计算引擎，它从不同的第三方存储引擎中读取数据，并进行解决，再写入另外的存储引擎中。Flink Connector 的作用就相当于一个连接器，连贯 Flink 计算引擎跟外界存储系统。 与外界进行数据交换时，Flink 反对以下 4 种形式： Flink 源码外部预约义 Source 和 Sink 的 API；Flink 外部提供了 Bundled Connectors，如 JDBC Connector。Apache Bahir 我的项目中提供连接器Apache Bahir 最后是从 Apache Spark 中独立进去的我的项目，以提供不限于 Spark 相干的扩大/插件、连接器和其余可插入组件的实现。通过异步 I/O 形式。流计算中常常须要与内部存储系统交互，比方须要关联 MySQL 中的某个表。一般来说，如果用同步 I/O 的形式，会造成零碎中呈现大的等待时间，影响吞吐和提早。异步 I/O 则能够并发解决多个申请，进步吞吐，缩小提早。 ...

当这个时代到来的时候，锐不可当。万物肆意成长，尘埃与曙光升腾，江河汇聚成川，无名山丘崛起为峰，天地一时无比宽阔。 ——吴晓波《激荡三十年》 从结绳记事到量子计算，从飞鸽传书到万物互联，两岸风光突飞猛进，人类文明的过程奔流不息。 咱们见证了，数据增长带来计算能力质的飞跃。咱们参加了，技术倒退从新定义产业的价值。咱们减速了，数字时代转型降级的步调。 数据连贯世界，算力编织幻想。二者作为“新商业时代的原油”，推动人类社会跨入愈发智慧的世界。生生不息。 作为大数据畛域的顶级盛会之一，Flink Forward 继续关注数据与算力的外围价值。12月13-15日，Flink Forward Asia 2020 在线峰会如约而至，寰球 38+ 一线厂商，70+ 优质议题，行将重磅开启！大会议程已正式上线，扫描下方二维码即可收费预约～ ▼ 扫码预约 ▼ 点击预约在线峰会：https://flink-forward.org.cn 弱小嘉宾阵容，让您满载而归Flink Forward Asia 2020 邀请了15 位来自不同行业的顶级技术专家负责议题评审委员会委员，并由阿里巴巴团体副总裁贾扬清作为主席，独特参加大会议题的内容评比，保障大会内容生命线，他们别离是： 内容重磅降级，见证硬核算力Flink Forward Asia 2020 大会内容重磅降级，除经典的行业最佳实际、Flink 核心技术解析、实时数仓、机器学习等主题外，开源生态内容更加丰盛，并新增金融专题集中分享 Flink 在金融行业的利用实际。 行业实际字节跳动、快手、微博、Bigo、网易游戏、知乎、爱奇艺、小米、京东、汽车之家、贝壳找房、58同城、好将来、360、网易云音乐、有赞、蚂蚁团体等 17+ 不同行业一线技术专家分享 Apache Flink 与大数据根底平台建设停顿和实际，具体解读大数据相干技术在各行业的利用与落地，包含利用场景、业务痛点、面临挑战、如何破局等贵重实践经验。 核心技术由 Apache Flink 外围贡献者与来自字节跳动、美团、领英、腾讯、第四范式先知等一线技术专家解析 Flink 技术动向与利用实际，回归技术实质，打造 Flink 全方位技术盛宴。 实时数仓实时数仓专场邀请腾讯、阿里巴巴、亚马逊、PingCAP、360、滴滴、蔚来汽车、比特大陆、顺丰、美团、腾讯看点、网易等多位数仓技术专家剖析实时数仓的利用实际及平台智能化的摸索与思考。 开源生态开源大数据生态专场，来自 Pravega、Kubernetes、Kylin、Hudi、Pulsar、Zeppelin、Arm 等不同技术方向的技术专家围绕 Flink 的生态交融，探讨当下大数据的发展趋势与将来动向，并展示相干技术在一线生产场景的优良实际。 机器学习人工智能专场由来自阿里巴巴、英特尔、微博、小米、bilibili 等技术专家出现 Flink 机器学习的最新进展、具体利用实际与最新技术落地案例。 金融从传统的“商业智能”走向要害工夫的“决策和预测”，实时计算正在驱动金融科技迈向新的倒退高度。本专题由 Wealthsimple、数禾科技、中原银行、安全银行、陆金所的多位技术专家解读 Flink 在金融行业的利用实际。 ...

作者：LittleMagic “为什么我的 Flink 作业 Web UI 中只显示出了一个框，并且 Records Sent 和Records Received 指标都是 0 ？是我的程序写得有问题吗？” Flink 算子链简介笔者在 Flink 社区群里常常能看到相似这样的疑难。这种状况简直都不是程序有问题，而是因为 Flink 的 operator chain ——即算子链机制导致的，即提交的作业的执行打算中，所有算子的并发实例（即 sub-task ）都因为满足特定条件而串成了整体来执行，天然就察看不到算子之间的数据流量了。 当然上述是一种非凡状况。咱们更常见到的是只有局部算子失去了算子链机制的优化，如官网文档中呈现过屡次的下图所示，留神 Source 和 map() 算子。 算子链机制的益处是不言而喻的：所有 chain 在一起的 sub-task 都会在同一个线程（即 TaskManager 的 slot）中执行，可能缩小不必要的数据交换、序列化和上下文切换，从而进步作业的执行效率。 铺垫了这么多，接下来就通过源码简略看看算子链产生的条件，以及它是如何在 Flink Runtime 中实现的。 逻辑打算中的算子链对 Flink Runtime 稍有理解的看官应该晓得，Flink 作业的执行打算会用三层图构造来示意，即： StreamGraph —— 原始逻辑执行打算JobGraph —— 优化的逻辑执行打算（Web UI 中看到的就是这个）ExecutionGraph —— 物理执行打算算子链是在优化逻辑打算时退出的，也就是由 StreamGraph 生成 JobGraph 的过程中。那么咱们来到负责生成 JobGraph 的 o.a.f.streaming.api.graph.StreamingJobGraphGenerator 类，查看其外围办法 createJobGraph() 的源码。 ...

现在的举荐零碎，对于实时性的要求越来越高，实时举荐的流程大抵能够概括为：举荐零碎对于用户的申请产生举荐，用户对举荐后果作出反馈 (购买/点击/来到等等)，举荐零碎再依据用户反馈作出新的举荐。这个过程中有两个值得关注的中央： 这可被视为是一个举荐零碎和用户一直交互、相互影响的过程。举荐零碎须要对用户反馈作出疾速及时的响应。这两点本篇别离通过强化学习和 Flink 来实现，而在此之前先理解一些背景概念。 强化学习强化学习畛域的出名教材 《Reinforcement Learning: An Introduction》开篇就写道： 当咱们思考学习的实质的时候，脑中首先联想到的可能就是在与环境一直交互中学习。当一个婴儿在游玩、挥动手臂或是旁顾周围时，并没有任何老师教它，但它的确能间接感知到周围环境的变动。强化学习的次要过程是构建一个智能体，使之在与环境交互的过程中一直学习，以期取得最大的冀望处分。它是一种十分通用的学习范式，能够用于对各种各样问题的建模，比方游戏、机器人、主动驾驶、人机交互、举荐、衰弱护理等等。其与监督学习的次要不同点在于：强化学习依据提早的反馈通过一直试错 (trial-and-error) 进行学习，而监督学习则是每一步都有明确的反馈信息进行学习。 下图反映了一个举荐智能体 (recommender agent) 与环境进行互动的过程。这里将用户 (user) 视为环境，用户的行为数据作为状态 (state) 输出到智能体中，智能体据此作出相应的动作 (action) ，即举荐相应的物品给用户，用户对此举荐的反馈如点击/不点击、购买/不购买等可视为新一轮的处分。从这里能够看出，举荐可被认为是一个动静序列决策过程，举荐物品对用户产生影响，进而用户的反馈反过来影响举荐零碎的决策自身，这样的过程会一直延续下去造成一个序列。 “决策” 这个词实际上很能代表强化学习自身的特点。构想当一个人在做决策的时候，很多时候须要对瞬息万变的局势进行评估并疾速作出相应的抉择，而另一方面，作出的决定须要思考长期的指标而非仅仅是短期收益。而这两点恰好是简直所有用强化学习做举荐零碎的论文中都会提到的对于传统举荐办法的问题，行将举荐视为动态预测的过程以及只重视短期收益等等。当然论文里这么说次要是为了凸显本人的成绩，但理论的状况应该远不是这么简略。 强化学习的最终目标是学习出一个策略 ????(????|????) 来最大化冀望处分。策略 (policy) 指的是智能体如何依据环境状态 ???? 来决定下一步的动作 ????，对应到举荐的场景中就是依据用户过往行为记录来决定下一步举荐的物品。 对于如何通过训练失去最优策略，目前支流有两类办法: on-policy 和 off-policy 。不同于监督学习的须要事后人工收集数据并标注，强化学习的数据来源于一直地与环境进行互动，继而用收集来的数据更新模型。所以在这个过程中有两个局部与策略相干，一是与环境互动时须要应用策略，二是训练时更新策略。On-policy 指的是环境互动的策略和训练时更新的策略是同一个策略，相应地 off-policy 则是互动和更新时应用的是不同的策略。如下左图为 on-policy，下中图为 off-policy (下右图为 offline 办法，后文再述 )。 On-policy 的思维比拟直观，相当于一个智能体在环境中边试错边学习，然而其次要问题是样本利用率低，进而训练效率低。应用了一个策略与环境进行交互获得数据进而更新模型后，就产生了一个新的策略，那么旧策略交互得来的数据可能就不遵从新策略的条件散布了，所以这些数据不能再应用会被抛弃。 Off-policy 则缓解了这个问题，次要通过将之前策略收集来的数据通过一个教训回放池 (experience replay buffer) 储存起来，而后从中采样数据进行训练。那么 off-policy 类办法为什么能应用旧策略产生的数据进行训练？既然数据分布不同导致新旧数据不能放一起训练，那就调整数据分布使之靠近就能够了，所以 Off-policy 类的算法广泛采纳了重要性采样的思维对不同数据施加不同的权重，后文介绍 YouTube 的举荐零碎时会提到，到那时再说。 那么本篇的强化学习办法实用于哪一种呢？这其实不大好说。我没有能互动的环境，只有静态数据集，所以 off-Policy 看上去更适宜一些，但即便是 off-policy 的办法通常也须要与环境进行交互一直产生新数据用于训练。因而本篇的办法属于 batch reinforcement learning，或称 offline reinforcement learning，不过我偏向于应用 batch 这个词，因为 offline 和 off-policy 很容易混同。上右图显示的就是 batch (offline) reinforcement learning，其特点是一次性收集完一批数据后就只用这批数据进行训练，在正式部署之前不再与环境作任何交互。 ...

导读：Flink 从 1.9.0 开始提供与 Hive 集成的性能，随着几个版本的迭代，在最新的 Flink 1.11 中，与 Hive 集成的性能进一步深入，并且开始尝试将流计算场景与Hive 进行整合。 本文次要分享在 Flink 1.11 中对接 Hive 的新个性，以及如何利用 Flink 对 Hive 数仓进行实时化革新，从而实现批流一体的指标。次要内容包含： · Flink 与 Hive 集成的背景介绍 · Flink 1.11中的新个性 · 打造 Hive 批流一体数仓 一、 Flink 与 Hive 集成背景为什么要做 Flink 和 Hive 集成的性能呢？最早的初衷是咱们心愿开掘 Flink 在批处理方面的能力。家喻户晓，Flink 在流计算方面曾经是胜利的引擎了，应用的用户也十分多。在 Flink 的设计理念当中，批计算是流解决中的一个特例。也就意味着，如果 Flink 在流计算方面做好，其实它的架构也能很好的反对批计算的场景。在批计算的场景中，SQL 是一个很重要的切入点。因为做数据分析的同学，他们更习惯应用SQL 进行开发，而不是去写 DataStream 或者 DataSet 这样的程序。 Hadoop 生态圈的 SQL 引擎，Hive 是一个事实上的规范。大部分的用户环境中都会应用到了 Hive 的一些性能，来搭建数仓。一些比拟新的 SQL 的引擎，例如 Spark SQL、Impala ，它们其实都提供了与 Hive 集成的能力。为了不便的可能对接上目前用户已有的应用场景，所以咱们认为对 Flink 而言，对接 Hive 也是不可短少的性能。 ...

当这个时代到来的时候，锐不可当。万物肆意成长，尘埃与曙光升腾，江河汇聚成川，无名山丘崛起为峰，天地一时无比宽阔。 ——吴晓波《激荡三十年》 从结绳记事到量子计算，从飞鸽传书到万物互联，两岸风光突飞猛进，人类文明的过程奔流不息。 咱们见证了，数据增长带来计算能力质的飞跃。咱们参加了，技术倒退从新定义产业的价值。咱们减速了，数字时代转型降级的步调。 数据连贯世界，算力编织幻想。二者作为“新商业时代的原油”，推动人类社会跨入愈发智慧的世界。生生不息。 作为大数据畛域的顶级盛会之一，Flink Forward 继续关注数据与算力的外围价值。12月26日，Flink Forward Asia 2020 在线峰会如约而至，寰球 38+ 一线厂商，近 70 优质议题，行将重磅开启！大会议程已正式上线，扫描下方二维码即可收费预约～ ▼ 扫码预约 ▼（大会官网） 点击预约在线峰会：https://flink-forward.org.cn 弱小嘉宾阵容，让您满载而归Flink Forward Asia 2020 邀请了15 位来自不同行业的顶级技术专家负责议题评审委员会委员，并由阿里巴巴团体副总裁贾扬清作为主席，独特参加大会议题的内容评比，保障大会内容生命线，他们别离是： 内容重磅降级，见证硬核算力Flink Forward Asia 2020 大会内容重磅降级，除经典的行业最佳实际、Flink 核心技术解析、实时数仓、机器学习等主题外，开源生态内容更加丰盛，并新增金融专题集中分享 Flink 在金融行业的利用实际。 行业实际字节跳动、快手、微博、Bigo、网易游戏、知乎、爱奇艺、小米、京东、汽车之家、贝壳找房、58同城、好将来、360、网易云音乐、有赞、蚂蚁团体等 17+ 不同行业一线技术专家分享 Apache Flink 与大数据根底平台建设停顿和实际，具体解读大数据相干技术在各行业的利用与落地，包含利用场景、业务痛点、面临挑战、如何破局等贵重实践经验。 核心技术由 Apache Flink 外围贡献者与来自字节跳动、美团、领英、腾讯、第四范式先知等一线技术专家解析 Flink 技术动向与利用实际，回归技术实质，打造 Flink 全方位技术盛宴。 实时数仓实时数仓专场邀请腾讯、阿里巴巴、亚马逊、PingCAP、360、滴滴、蔚来汽车、比特大陆、顺丰、美团、腾讯看点、网易等多位数仓技术专家剖析实时数仓的利用实际及平台智能化的摸索与思考。 开源生态开源大数据生态专场，来自 Pravega、Kubernetes、Kylin、Hudi、Pulsar、Zeppelin、Arm 等不同技术方向的技术专家围绕 Flink 的生态交融，探讨当下大数据的发展趋势与将来动向，并展示相干技术在一线生产场景的优良实际。 机器学习人工智能专场由来自阿里巴巴、英特尔、微博、小米、bilibili 等技术专家出现 Flink 机器学习的最新进展、具体利用实际与最新技术落地案例。 金融从传统的“商业智能”走向要害工夫的“决策和预测”，实时计算正在驱动金融科技迈向新的倒退高度。本专题由 Wealthsimple、数禾科技、中原银行、安全银行、陆金所的多位技术专家解读 Flink 在金融行业的利用实际。 ...

作者：伍翀 (云邪) 整顿：陈政羽（Flink 社区志愿者） Flink 1.11 引入了 Flink SQL CDC，CDC 能给咱们数据和业务间能带来什么变动？本文由 Apache Flink PMC，阿里巴巴技术专家伍翀 (云邪）分享，内容将从传统的数据同步计划，基于 Flink CDC 同步的解决方案以及更多的利用场景和 CDC 将来开发布局等方面进行介绍和演示。 1、传统数据同步计划 2、基于 Flink SQL CDC 的数据同步计划（Demo） 3、Flink SQL CDC 的更多利用场景 4、Flink SQL CDC 的将来布局 直播回顾：https://www.bilibili.com/video/BV1zt4y1D7kt/ 传统的数据同步计划与 Flink SQL CDC 解决方案业务零碎常常会遇到须要更新数据到多个存储的需要。例如：一个订单零碎刚刚开始只须要写入数据库即可实现业务应用。某天 BI 团队冀望对数据库做全文索引，于是咱们同时要写多一份数据到 ES 中，革新后一段时间，又有需要须要写入到 Redis 缓存中。 很显著这种模式是不可继续倒退的，这种双写到各个数据存储系统中可能导致不可保护和扩大，数据一致性问题等，须要引入分布式事务，老本和复杂度也随之减少。咱们能够通过 CDC（Change Data Capture）工具进行解除耦合，同步到上游须要同步的存储系统。通过这种形式进步零碎的稳健性，也不便后续的保护。 Flink SQL CDC 数据同步与原理解析CDC 全称是 Change Data Capture ，它是一个比拟狭义的概念，只有能捕捉变更的数据，咱们都能够称为 CDC 。业界次要有基于查问的 CDC 和基于日志的 CDC ，能够从上面表格比照他们性能和差别点。 ...

本文次要探讨一个问题：ValueState 中存 Map 与 MapState 有什么区别？ 如果不懂这两者的区别，而且应用 ValueState 中存大对象，生产环境很可能会呈现以下问题： · CPU 被打满 · 吞吐上不去 1、 论断从性能和 TTL 两个维度来形容区别。 性能· RocksDB 场景，MapState 比 ValueState 中存 Map 性能高很多。 · 生产环境强烈推荐应用 MapState，不举荐 ValueState 中存大对象 · ValueState 中存大对象很容易使 CPU 打满 · Heap State 场景，两者性能相似。 TTLFlink 中 State 反对设置 TTL： · MapState 的 TTL 是基于 UK 级别的 · ValueState 的 TTL 是基于整个 key 的 触类旁通能应用 ListState 的场景，不要应用 ValueState 中存 List。大佬们曾经把 MapState 和 ListState 性能都做了很多优化，高性能不香吗？下文会详细分析 ValueState 和 MapState 底层的实现原理，通过剖析原理得出上述论断。 ...

随着互联网飞速发展，企业业务品种会越来越多，业务数据量会越来越大，当倒退到肯定规模时，传统的数据存储构造逐步无奈满足企业需要，实时数据仓库就变成了一个必要的根底服务。以维表 Join 为例，数据在业务数据源中以范式表的模式存储，在剖析时须要做大量的 Join 操作，升高性能。如果在数据荡涤导入过程中就能流式的实现 Join，那么剖析时就无需再次 Join，从而晋升查问性能。 利用实时数仓，企业能够实现实时 OLAP 剖析、实时数据看板、实时业务监控、实时数据接口服务等用处。但想到实时数仓，很多人的第一印象就是架构简单，难以操作与保护。而得益于新版 Flink 对 SQL 的反对，以及 TiDB HTAP 的个性，咱们摸索了一个高效、易用的 Flink+TiDB 实时数仓解决方案。 本文将首先介绍实时数仓的概念，而后介绍 Flink+TiDB 实时数仓的架构与劣势，接着给出一些曾经在应用中的用户场景，最初给出在 docker-compose 环境下的 Demo，用于读者进行尝试。 实时数仓的概念数据仓库的概念在 90 年代由 Bill Inmon 提出，是指一个面向主题的、集成的、绝对稳固的、反映历史变动的汇合，用于反对管理决策。过后的数据仓库通过音讯队列收集来自数据源的数据，通过每天或每周进行一次计算以供报表应用，也称为离线数仓。 进入 21 世纪，随着计算技术的倒退、以及整体算力的晋升，决策的主体逐步从人工控制转变为计算机算法，呈现了实时举荐、实时监控剖析等需要，对应的决策周期时间由天级逐渐变为秒级，在这些场景下，实时数仓应运而生。 以后的实时数仓次要有三种架构：Lambda架构、Kappa 架构以及实时 OLAP 变体架构： Lambda 架构是指在离线数仓的根底上叠加了实时数仓局部，应用流式引擎解决实时性较高的数据，最初将离线和在线的后果对立供给用应用。 Kappa 架构则移除了离线数仓局部，全副应用实时数据生产。这种架构对立了计算引擎，升高了开发成本。 随着实时 OLAP 技术的晋升，一个新的实时架构被提出，临时被称为“实时 OLAP 变体”。简略来说，就是将一部分计算压力从流式计算引擎转嫁到实时 OLAP 剖析引擎上，以此进行更加灵便的实时数仓计算。 总结一下，对于实时数仓，Lambda 架构须要保护流批两套引擎，开发成本相较其它两者更高。相比于 Kappa 架构，实时 OLAP 变体架构能够执行更加灵便的计算，但须要依赖额定的实时 OLAP 算力资源。接下来咱们将介绍的 Flink + TiDB 实时数仓计划，就属于实时 OLAP 变体架构。 对于实时数仓及这些架构更加具体的比照阐明，有趣味的读者能够参考 Flink 中文社区的这篇文章：基于 Flink 的典型 ETL 场景实现计划。 ...

01 数据仓库平台建设的痛点痛点一： 咱们凌晨一些大的离线工作常常会因为一些起因呈现提早，这种提早会导致外围报表的产出工夫不稳固，有些时候会产出比拟早，然而有时候就可能会产出比拟晚，业务很难承受。 为什么会呈现这种景象的产生呢？目前来看大抵有这么几点因素： 工作自身要申请的数据量会特地大。通常来说一天原始的数据量可能在几十TB。几百个分区，甚至上千个分区，五万+的文件数这样子。如果说全量读取这些文件的话，几百个分区就会向 NameNode 发送几百次申请，咱们晓得离线工作在凌晨运行的时候，NameNode 的压力是十分大的。所以就很有可能呈现 Namenode 响应很慢的状况，如果申请响应很慢就会导致工作初始化工夫很长。工作自身的 ETL 效率是绝对低效的，这个低效并不是说 Spark 引擎低效，而是说咱们的存储在这块反对的不是特地的好。比方目前咱们查一个分区的话是须要将所有文件都扫描一遍而后进行剖析，而实际上我可能只对某些文件感兴趣。所以相对而言这个计划自身来说就是绝对低效的。这种大的离线工作一旦遇到磁盘坏盘或者机器宕机，就须要重试，重试一次须要消耗很长的工夫比方几十分钟。如果说重试一两次的话这个提早就会比拟大了。痛点二： 针对一些细琐的一些问题而言的。这里简略列举了三个场景来剖析： 不牢靠的更新操作。咱们常常在 ETL 过程中执行一些 insert overwrite 之类的操作，这类操作会先把相应分区的数据删除，再把生成的文件加载到分区中去。在咱们移除文件的时候，很多正在读取这些文件的工作就会产生异样，这就是不牢靠的更新操作。表 Schema 变更低效。目前咱们在对表做一些加字段、更改分区的操作其实是十分低效的操作，咱们须要把所有的原始数据读出来，而后在从新写回去。这样就会十分耗时，并且低效。数据可靠性不足保障。次要是咱们对于分区的操作，咱们会把分区的信息分为两个中央，HDFS 和 Metastore，别离存储一份。在这种状况下，如果进行更新操作，就可能会呈现一个更新胜利而另一个更新失败，会导致数据不牢靠。痛点三： 基于 Lambda 架构建设的实时数仓存在较多的问题。如上图的这个架构图，第一条链路是基于 kafka 直达的一条实时链路（提早要求小于5分钟），另一条是离线链路（提早大于1小时），甚至有些公司会有第三条准实时链路（提早要求5分钟～一小时），甚至更简单的场景。 两条链路对应两份数据，很多时候实时链路的处理结果和离线链路的处理结果对不上。Kafka 无奈存储海量数据， 无奈基于以后的 OLAP 剖析引擎高效查问 Kafka 中的数据。Lambda 保护老本高。代码、数据血统、Schema 等都须要两套。运维、监控等老本都十分高。痛点四： 不能敌对地反对高效更新场景。大数据的更新场景个别有两种，一种是 CDC ( Change Data Capture) 的更新，尤其在电商的场景下，将 binlog 中的更新删除同步到 HDFS 上。另一种是提早数据带来的聚合后后果的更新。目前 HDFS 只反对追加写，不反对更新。因而业界很多公司引入了 Kudu。然而 Kudu 自身是有一些局限的，比方计算存储没有做到拆散。这样整个数仓零碎中引入了 HDFS、Kafka 以及 Kudu，运维老本不堪称不大。 下面就是针对目前数仓所波及到的四个痛点的大抵介绍，因而咱们也是通过对数据湖的调研和实际，心愿能在这四个方面对数仓建设有所帮忙。接下来重点解说下对数据湖的一些思考。 02 数据湖 Iceberg 外围原理1. 数据湖开源产品调研 数据湖大抵是从19年开始缓缓火起来的，目前市面上外围的数据湖开源产品大抵有这么几个： ...

PrometheusPrometheus 作为一个微服务架构监控零碎的解决方案，它和容器也脱不开关系。早在 2006 年 8 月 9 日，Eric Schmidt 在搜索引擎大会上首次提出了云计算（Cloud Computing）的概念，在之后的十几年里，云计算的倒退长驱直入。在 2013 年，Pivotal 的 Matt Stine 又提出了云原生（Cloud Native）的概念，云原生由微服务架构、DevOps 和以容器为代表的麻利基础架构组成，帮忙企业疾速、继续、牢靠、规模化地交付软件。 Prometheus 数据采集形式也非常灵活。要采集指标的监控数据，首先须要在指标处装置数据采集组件，这被称之为 Exporter，它会在指标处收集监控数据，并暴露出一个 HTTP 接口供 Prometheus 查问，Prometheus 通过 Pull 的形式来采集数据，这和传统的 Push 模式不同。不过 Prometheus 也提供了一种形式来反对 Push 模式，你能够将你的数据推送到 Push Gateway，Prometheus 通过 Pull 的形式从 Push Gateway 获取数据。目前的 Exporter 曾经能够采集绝大多数的第三方数据，比方 Docker、HAProxy、StatsD、JMX 等等，官网有一份 Exporter 的列表。 Prometheus 的整体架构图 从上图能够看出，Prometheus 生态系统蕴含了几个要害的组件：Prometheus server、Pushgateway、Alertmanager、Web UI 等，然而大多数组件都不是必须的，其中最外围的组件当然是 Prometheus server，它负责收集和存储指标数据，反对表达式查问，和告警的生成。 装置命令wget https://github.com/prometheus/prometheus/releases/download/v2.7.2/prometheus-2.7.2.linux-amd64.tar.gzcd prometheus-2.7.2.linux-amd64./prometheus --version./prometheuscat prometheus.yml - job_name: 'prometheus' static_configs: - targets: ['localhost:9090'] - job_name: 'server' static_configs: - targets: ['localhost:9100']killall -HUP prometheus实际上 Graph 页面是 Prometheus 最弱小的性能，在这里咱们能够应用 Prometheus 提供的一种非凡表达式来查问监控数据，这个表达式被称为 PromQL（Prometheus Query Language）。通过 PromQL 不仅能够在 Graph 页面查问数据，而且还能够通过 Prometheus 提供的 HTTP API 来查问。查问的监控数据有列表和曲线图两种展示模式（对应上图中 Console 和 Graph 这两个标签）。 ...

Operator StateOperator State能够用在所有算子上，每个算子子工作或者说每个算子实例共享一个状态，流入这个算子子工作的数据能够拜访和更新这个状态。下图展现了Operator State，算子子工作1上的所有数据能够共享第一个Operator State，以此类推，每个算子子工作上的数据共享本人的状态。 如何应用Operator State呢？咱们能够通过实现CheckpointedFunction接口来实现，或者实现ListCheckpointed<T extends Serializable>接口来实现，它们之间次要的区别是：实现CheckpointedFunction接口，有两种模式的ListState API能够应用，别离是getListState以及getListUnionState，它们都会返回一个ListState，然而他们在从新分区的时候会有区别，前面会具体介绍。。。 Operator State的理论利用场景不如Keyed State多，它常常被用在Source或Sink等算子上，用来保留流入数据的偏移量或对输入数据做缓存，以保障Flink利用的Exactly-Once语义。这里咱们来看一个Flink官网提供的Sink案例以理解CheckpointedFunction的工作原理。 import org.apache.flink.api.common.state.ListState;import org.apache.flink.api.common.state.ListStateDescriptor;import org.apache.flink.api.common.typeinfo.TypeHint;import org.apache.flink.api.common.typeinfo.TypeInformation;import org.apache.flink.runtime.state.FunctionInitializationContext;import org.apache.flink.runtime.state.FunctionSnapshotContext;import org.apache.flink.streaming.api.checkpoint.CheckpointedFunction;import org.apache.flink.streaming.api.functions.sink.SinkFunction;import scala.Tuple2;import java.util.ArrayList;import java.util.List;/** * @Author Natasha * @Description 输入到Sink之前，先将数据放在本地缓存中，并定期进行snapshot。即便程序解体，状态中存储着还未输入的数据，下次启动后还会将这些未输入数据读取到内存，持续输入到内部零碎。 * @Date 2020/10/19 16:30 **/public class BufferingSink implements SinkFunction<Tuple2<String, Integer>>, CheckpointedFunction { private final int threshold; //托管状态 private transient ListState<Tuple2<String, Integer>> checkpointedState; //原始状态（本地缓存） private List<Tuple2<String, Integer>> bufferedElements; public BufferingSink(int threshold) { this.threshold = threshold; this.bufferedElements = new ArrayList(); } @Override //Sink的外围解决逻辑，将上游数据value输入到内部零碎：在invoke办法外头先将value缓存到bufferedElements，缓存个数触发阈值时，执行sink操作，而后清空bufferedElements public void invoke(Tuple2<String, Integer> value) throws Exception { // 先将上游数据缓存到本地的缓存 bufferedElements.add(value); // 当本地缓存大小达到阈值时，将本地缓存输入到内部零碎 if (bufferedElements.size() == threshold) { for (Tuple2<String, Integer> element: bufferedElements) { // send it to the sink } // 清空本地缓存 bufferedElements.clear(); } } @Override // Checkpoint触发时会调用这个办法，对bufferedElements进行snapshot本地状态长久化 public void snapshotState(FunctionSnapshotContext context) throws Exception { checkpointedState.clear(); //将最新的数据写到状态中 for (Tuple2<String, Integer> element : bufferedElements) { checkpointedState.add(element); } } @Override // 第一次初始化时会调用这个办法，或者从之前的检查点复原时也会调用这个办法 public void initializeState(FunctionInitializationContext context) throws Exception { ListStateDescriptor<Tuple2<String, Integer>> descriptor = new ListStateDescriptor( "buffered-elements", TypeInformation.of(new TypeHint<Tuple2<Long, Long>>() {})); checkpointedState = context.getOperatorStateStore().getListState(descriptor); // 如果是作业重启，读取存储中的状态数据并填充到本地缓存中 if (context.isRestored()) { for (Tuple2<String, Integer> element : checkpointedState.get()) { //从托管状态将数据到挪动到原始状态 bufferedElements.add(element); } } }}Keyed StateKeyed State是KeyedStream上的状态。如果输出流依照id为Key进行了keyBy分组，造成一个KeyedStream，数据流中所有id为1的数据共享一个状态，能够拜访和更新这个状态，以此类推，每个Key对应一个本人的状态。下图展现了Keyed State，因为一个算子子工作能够解决一到多个Key，算子子工作1解决了两种Key，两种Key别离对应本人的状态。 ...

Flink提供了以下三种开箱即用的状态后端(用于存储状态数据) MemoryStateBackendFsStateBackendRocksDBStateBackendMemoryStateBackendMemoryStateBackend外部将state作为对象保留在taskManager的堆内存中，通过checkpoint机制，MemoryStateBackend将state进行快照并保留Jobmanager的堆内存中。 MemoryStateBackend能够通过配置来应用异步快照（asynchronous snapshots），通过异步快照能够防止阻塞管道，目前是默认开启。 MemoryStateBackend的限度： 每个独立的状态（state）默认限度大小为5MB， 能够通过构造函数减少容量；状态的大小不能超过akka的framesize大小。聚合状态（aggregate state ）必须放入JobManager的内存。MemoryStateBackend的实用场景： 本地调试flink工作状态数据量较小的场景FsStateBackendFsStateBackend通过配置文件系统门路来进行设置，将动态数据保留在taskmanger的内存中，通过checkpoint机制，将状态快照写入配置好的文件系统或目录中。 val env: StreamExecutionEnvironment = StreamExecutionEnvironment.getExecutionEnvironment//fs状态后端配置,如为file:///,则在taskmanager的本地val checkPointPath = new Path("hdfs:///flink/checkpoints") val fsStateBackend: StateBackend = new FsStateBackend(checkPointPath)env.setStateBackend(fsStateBackend)FsStateBackend实用场景： 大状态、长窗口、大key/value状态的的工作全高可用配置RocksDBStateBackendRocksDBStateBackend将工作状态保留在RocksDB数据库（地位在taskManagerd的数据目录）。通过checkpoint, 整个RocksDB数据库被复制到配置的文件系统或目录中 private val checkpointDataUri = "hdfs:///flink/checkpoints" private val tmpDir = "file:///tmp/rocksdb/data/" val env = StreamExecutionEnvironment.getExecutionEnvironment val fsStateBackend: StateBackend = new FsStateBackend(checkpointDataUri) val rocksDBBackend: RocksDBStateBackend = new RocksDBStateBackend(fsStateBackend, TernaryBoolean.TRUE) val config = new Configuration() //TIMER分为HEAP(默认，性能更好)和RocksDB(扩大好) config.setString(RocksDBOptions.TIMER_SERVICE_FACTORY,RocksDBStateBackend.PriorityQueueStateType.ROCKSDB.toString) rocksDBBackend.configure(config) rocksDBBackend.setDbStoragePath(tmpDir) env.setStateBackend(rocksDBBackend.asInstanceOf[StateBackend])RocksDBStateBackend实用场景： 大状态、长窗口、大key/value状态的的工作全高可用配置因为RocksDBStateBackend将工作状态存储在taskManger的本地文件系统，状态数量仅仅受限于本地磁盘容量限度，比照于FsStateBackend保留工作状态在内存中，RocksDBStateBackend能防止flink工作继续运行可能导致的状态数量暴增而内存不足的状况，因而适宜在生产环境应用。 ...

Restart Strategies（重启策略)重启策略有三种: Fixed delay 固定工夫重启 ，配置文件中的值fixed-delayFailure rate 依据失败率，配置文件中的值failure-rateNo restart 无重启，配置文件中的值None固定提早重启策略（Fixed Delay Restart Strategy）固定提早重新启动策略尝试给定次数重新启动作业, 如果超过最大尝试次数，则该作业最终将失败,在两次间断的重新启动尝试之间，重新启动策略将期待固定的工夫。 通过在flink-conf.yaml中设置以下配置参数，默认状况下启用此策略。 restart-strategy: fixed-delay#申明Flink在作业失败之前重试执行的次数，默认值是1。restart-strategy.fixed-delay.attempts: 3#提早重试意味着在执行失败之后，从新执行不会立刻启动，而是在肯定的提早之后，默认是10s。restart-strategy.fixed-delay.delay: 10 s固定提早重启策略也能够通过编程形式设置： ExecutionEnvironment env = ExecutionEnvironment.getExecutionEnvironment();env.setRestartStrategy(RestartStrategies.fixedDelayRestart( 3, // number of restart attempts Time.of(10, TimeUnit.SECONDS) // delay));故障率重启策略（Failure Rate Restart Strategy）故障率重新启动策略在故障后重新启动作业，然而当超过故障率（每个工夫距离的故障）时，作业最终将失败。 在两次间断的重新启动尝试之间，重新启动策略将期待固定的工夫。 通过在flink-conf.yaml中设置以下配置参数，默认状况下启用此策略。 在5min内如果失败了三次以上，作业就失败了。 restart-strategy: failure-raterestart-strategy.failure-rate.max-failures-per-interval: 3restart-strategy.failure-rate.failure-rate-interval: 5 minrestart-strategy.failure-rate.delay: 10 s故障率重启策略也能够通过编程形式设置： ExecutionEnvironment env = ExecutionEnvironment.getExecutionEnvironment();env.setRestartStrategy(RestartStrategies.failureRateRestart( 3, // max failures per interval Time.of(5, TimeUnit.MINUTES), //time interval for measuring failure rate Time.of(10, TimeUnit.SECONDS) // delay));无重启策略（No Restart Strategy）作业间接失败，不尝试重启。 ...

Flink 并行度：优先级：算子层面>环境层面>客户端层面>零碎层面 Operator Level（操作算子层面）final StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment();DataStream<String> text = [...]DataStream<Tuple2<String, Integer>> wordCounts = text .flatMap(new LineSplitter()) .keyBy(0) .timeWindow(Time.seconds(5)) .sum(1).setParallelism(5);wordCounts.print();env.execute("Word Count Example");复制代码operators、data sources、data sinks都能够调用setParallelism()办法来设置parallelismExecution Environment Level（执行环境层面）final StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment();env.setParallelism(3);DataStream<String> text = [...]DataStream<Tuple2<String, Integer>> wordCounts = [...]wordCounts.print();env.execute("Word Count Example");复制代码在ExecutionEnvironment外头能够通过setParallelism来给operators、data sources、data sinks设置默认的parallelism；如果operators、data sources、data sinks本人有设置parallelism则会笼罩ExecutionEnvironment设置的parallelismClient Level（客户端层面）./bin/flink run -p 10 ../examples/*WordCount-java*.jar复制代码或者 try { PackagedProgram program = new PackagedProgram(file, args); InetSocketAddress jobManagerAddress = RemoteExecutor.getInetFromHostport("localhost:6123"); Configuration config = new Configuration(); Client client = new Client(jobManagerAddress, config, program.getUserCodeClassLoader()); // set the parallelism to 10 here client.run(program, 10, true);} catch (ProgramInvocationException e) { e.printStackTrace();}复制代码应用CLI client，能够在命令行调用是用-p来指定，或者Java/Scala调用时在Client.run的参数中指定parallelismSystem Level（零碎层面）# The parallelism used for programs that did not specify and other parallelism.parallelism.default: 1复制代码能够在flink-conf.yaml中通过parallelism.default配置项给所有execution environments指定零碎级的默认parallelismFlink数据流图简介1.1 Flink作业的逻辑视图在大数据畛域，词频统计（WordCount）程序就像是一个编程语言的HelloWorld程序，它展现了一个大数据引擎的根本标准。麻雀虽小，五脏俱全，从这个样例中，咱们能够一窥Flink设计和运行原理。 ...

Flink的窗口操作对于Flink的窗口操作，尤其是基于事件工夫的窗口操作，大家还要掌三个重要的知识点： 窗口分配器：就是决定着流入flink的数据，该属于哪个窗口。工夫戳抽取器/watermark生成器：抽取工夫戳并驱动着程序失常执行。trigger：决定着数据啥时候落地。数据流入flink的source之后，如果须要窗口函数，咱们就要应用肯定的规定来判断或者叫决定该数据应该属于哪个窗口，而后是窗口要是基于事件工夫的话咱们还要提供工夫戳抽取器和watermark分配器，最初还要指定满足何种条件触发窗口计算并输入后果。 那这里可能会说了，触发窗口计算不就是工夫到窗口完结工夫了间接输入 不就行了吗？ 实际上是不行的，基于事件工夫解决机制，数据会在有些意想不到的状况下滞后，比方forward故障等。这种状况，对于flink来说咱们能够设置一些参数来容许解决滞后的元素，比方容许其滞后一小时，那么这个时候实际上窗口输入距离就是要加上这个滞后工夫了。这时候如果咱们想要尽可能的实时输入的话，就要用到flink的trigger机制。 Trigger机制Trigger定义了何时开始应用窗口计算函数计算窗口。每个窗口分配器都会有一个默认的Trigger。如果，默认的Trigger不能满足你的需要，你能够指定一个自定义的trigger()。 onElement():进入窗口的每个元素都会调用该办法。onEventTime():事件工夫timer触发的时候被调用。onProcessingTime():解决工夫timer触发的时候会被调用。onMerge():有状态的触发器相干，并在它们相应的窗口合并时合并两个触发器的状态，例如应用会话窗口。clear():该办法次要是执行窗口的删除操作。TriggerResultCONTINUE:什么都不做。FIRE:触发计算。PURE:革除窗口的元素。FIRE_AND_PURE:触发计算和革除窗口元素。内置和自定义触发器EventTimeTrigger：基于事件工夫和watermark机制来对窗口进行触发计算。ProcessingTimeTrigger:基于解决工夫触发。CountTrigger:窗口元素数超过事后给定的限度值的话会触发计算。PurgingTrigger作为其它trigger的参数，将其转化为一个purging触发器。

本系列每篇文章都是从一些理论的 case 登程，剖析一些生产环境中常常会遇到的问题，抛砖引玉，以帮忙小伙伴们解决一些理论问题。本文介绍 Flink 工夫以及时区问题，剖析了在天级别的窗口时会遇到的时区问题，如果对小伙伴有帮忙的话，欢送点赞 + 再看~本文次要分为两局部：第一局部（第 1 - 3 节）的剖析次要针对 flink，剖析了 flink 天级别窗口的中存在的时区问题以及解决方案。第二局部（第 4 节）的剖析能够作为所有时区问题的剖析思路，次要以解决方案中的时区偏移量为什么是加 8 小时为案例做了通用的深度解析。为了让读者能对本文探讨的问题有一个大抵理解，本文先给出问题 sql，以及解决方案。后文给出具体的剖析~1.问题以及解决方案问题 sqlsql 很简略，用来统计当天累计 uv。 --------------- 伪代码 ---------------INSERT INTO kafka_sink_tableSELECT -- 窗口开始工夫 CAST( TUMBLE_START(proctime, INTERVAL '1' DAY) AS bigint ) AS window_start, -- 以后记录解决的工夫 cast(max(proctime) AS BIGINT) AS current_ts, -- 每个桶内的 uv count(DISTINCT id) AS part_daily_full_uvFROM kafka_source_tableGROUP BY mod(id, bucket_number), -- bucket_number 为常数，依据具体场景指定具体数值 TUMBLE(proctime, INTERVAL '1' DAY)--------------- 伪代码 ---------------你是否能一眼看出这个 sql 所存在的问题？（PS：数据源以及数据汇时区都为东八区）没错，天级别窗口所存在的时区问题，即这段代码统计的不是楼主所在东八区一整天数据的 uv，这段代码统计的一整天的范畴在东八区是第一天早 8 点至第二天早 8 点。 ...

Process Function API 后面学习的Transformations 是无法访问事件的工夫戳和水位线信息的，如MapFunction的map转换算子是无法访问工夫戳和以后事件的事件工夫。基于此，DataStream API提供了一系列的Low Level转换算子--Process Function API，与高层算子不同，通过这些底层转换算子咱们能够拜访数据的工夫戳，watermark以及注册定时事件。Process Function 用来构建事件驱动的利用和实现自定义的业务逻辑。例如Flink SQL就是用Process Function 实现的。 Flink为咱们提供了8中process function： ProcessFunctionKeyedProcessFunctionCoProcessFunctionProcessJoinFunctionBroadcastProcessFunctionKeyedBroadcastProcessFunctionProcessWindowFunctionProcessAllWindowFunction于是我抉择了基于Flink的电商用户行为数据分析的我的项目，进行对Flink的KeyedProcessFunction进行全面学习与意识。 首先咱们重点意识下KeyedProcessFunction，KeyedProcessFunction 用来操作 KeyedStream，KeyedProcessFunction 会解决流的每一个元素，KeyedProcessFunction[KEY, IN, OUT]还额定提供了两个办法： processElement(v: IN, ctx: Context, out: Collector[OUT]), 流中的每一个元素都会调用这个办法，调用后果将会放在 Collector 数据类型中输入。Context能够拜访元素的工夫戳，元素的 key，以及 TimerService 工夫服务。Context还能够将后果输入到别的流(side outputs)。onTimer(timestamp: Long, ctx: OnTimerContext, out: Collector[OUT])是一个回调函数。当之前注册的定时器触发时调用。参数 timestamp 为定时器所设定的触发的工夫戳。Collector 为输入后果的汇合。OnTimerContext 和 processElement 的 Context 参数一样，提供了上下文的一些信息，例如定时器触发的工夫信息(事件工夫或者解决工夫)。当定时器 timer 触发时，会执行回调函数 onTimer()，留神定时器 timer 只能在keyed streams 下面应用。实时热门页面流量统计根本需要 从 web 服务器的日志中，统计实时的热门拜访页面统计每分钟的 ip 访问量，取出访问量最大的 5 个地址，每 5 秒更新一次解决思路 将 apache 服务器日志中的工夫，转换为工夫戳，作为 Event Time构建滑动窗口，窗口长度为 1 分钟，滑动间隔为 5 秒import java.text.SimpleDateFormatimport model.ApacheLogEventimport org.apache.flink.streaming.api.TimeCharacteristicimport org.apache.flink.streaming.api.functions.timestamps.BoundedOutOfOrdernessTimestampExtractorimport org.apache.flink.streaming.api.scala.StreamExecutionEnvironmentimport org.apache.flink.streaming.api.windowing.time.Timeimport org.apache.flink.streaming.api.scala._/** * 统计近 1 个小时内的热门商品，每5分钟更新一次 */object NetWorkFlowAnalysis { def main(args: Array[String]): Unit = { val env = StreamExecutionEnvironment.getExecutionEnvironment env.setParallelism(5) env.setStreamTimeCharacteristic(TimeCharacteristic.EventTime) val resource = getClass.getResource("/apache.log").getPath val inputStream = env.readTextFile(resource) val dataStream = inputStream .map(data => { val arr = data.split(" ") ApacheLogEvent(arr(0), arr(1), new SimpleDateFormat("dd/MM/yyyy:HH:mm:ss").parse(arr(3)).getTime, arr(5), arr(6)) }) .assignTimestampsAndWatermarks(new BoundedOutOfOrdernessTimestampExtractor[ApacheLogEvent](Time.seconds(1)) { override def extractTimestamp(t: ApacheLogEvent): Long = t.timestamp }) .keyBy(_.url) .timeWindow(Time.minutes(10), Time.seconds(5)) .aggregate(new NetWorkFlowAggregateFunction, new NetWorkFlowWindowFunction) .keyBy(_.windowEnd) .process(new NetWorkFlowKeyedProcessFunction(3)) .print() env.execute("NetWorkFlowAnalysis") }}实时流量统计—PV 和 UV根本需要 ...

Flink 和 ClickHouse 别离是实时计算和（近实时）OLAP 畛域的翘楚，也是近些年十分火爆的开源框架，很多大厂都在将两者联合应用来构建各种用处的实时平台，成果很好。对于两者的长处就不再赘述，本文来简略介绍笔者团队在点击流实时数仓方面的一点实践经验。 点击流及其维度建模所谓点击流（click stream），就是指用户拜访网站、App 等 Web 前端时在后端留下的轨迹数据，也是流量剖析（traffic analysis）和用户行为剖析（user behavior analysis）的根底。点击流数据个别以拜访日志和埋点日志的模式存储，其特点是量大、维度丰盛。以咱们一个中等体量的一般电商平台为例，每天产生约 200GB 左右、数十亿条的原始日志，埋点事件 100+ 个，波及 50+ 个维度。 依照 Kimball 的维度建模实践，点击流数仓遵循典型的星形模型，简图如下。 点击流数仓分层设计点击流实时数仓的分层设计依然能够借鉴传统数仓的计划，以扁平为上策，尽量减少数据传输中途的提早。简图如下。 DIM 层：维度层，MySQL 镜像库，存储所有维度数据。ODS 层：贴源层，原始数据由 Flume 间接进入 Kafka 的对应 topic。DWD 层：明细层，通过 Flink 将 Kafka 中数据进行必要的 ETL 与实时维度 join 操作，造成标准的明细数据，并写回 Kafka 以便上游与其余业务应用。再通过 Flink 将明细数据别离写入 ClickHouse 和 Hive 打成大宽表，前者作为查问与剖析的外围，后者作为备份和数据质量保证（对数、补数等）。DWS 层：服务层，局部指标通过 Flink 实时汇总至 Redis，供大屏类业务应用。更多的指标则通过 ClickHouse 物化视图等机制周期性汇总，造成报表与页面热力求。特地地，局部明细数据也在此层凋谢，不便高级 BI 人员进行漏斗、留存、用户门路等灵便的 ad-hoc 查问，这些也是 ClickHouse 远超过其余 OLAP 引擎的弱小之处。要点与注意事项Flink 实时维度关联Flink 框架的异步 I/O 机制为用户在流式作业中拜访内部存储提供了很大的便当。针对咱们的状况，有以下三点须要留神： ...

Apache Hudi 是由 Uber 开发并开源的数据湖框架，它于 2019 年 1 月进入 Apache 孵化器孵化，次年 5 月份顺利毕业晋升为 Apache 顶级我的项目。是以后最为热门的数据湖框架之一。 1. 为何要解耦Hudi 自诞生至今始终应用 Spark 作为其数据处理引擎。如果用户想应用 Hudi 作为其数据湖框架，就必须在其平台技术栈中引入 Spark。放在几年前，应用 Spark 作为大数据处理引擎能够说是很平时甚至是天经地义的事。因为 Spark 既能够进行批处理也能够应用微批模仿流，流批一体，一套引擎解决流、批问题。然而，近年来，随着大数据技术的倒退，同为大数据处理引擎的 Flink 逐步进入人们的视线，并在计算引擎畛域获占据了肯定的市场，大数据处理引擎不再是一家独大。在大数据技术社区、论坛等领地，Hudi 是否反对应用 Flink 计算引擎的的声音开始逐步呈现，并日渐频繁。所以使 Hudi 反对 Flink 引擎是个有价值的事件，而集成 Flink 引擎的前提是 Hudi 与 Spark 解耦。 同时，纵观大数据畛域成熟、沉闷、有生命力的框架，无一不是设计优雅，能与其余框架互相交融，彼此借力，各专所长。因而将 Hudi 与 Spark 解耦，将其变成一个引擎无关的数据湖框架，无疑是给 Hudi 与其余组件的交融发明了更多的可能，使得 Hudi 能更好的融入大数据生态圈。 2. 解耦难点Hudi 外部应用 Spark API 像咱们平时开发应用 List 一样稀松平时。自从数据源读取数据，到最终写出数据到表，无处不是应用 Spark RDD 作为次要数据结构，甚至连一般的工具类，都应用 Spark API 实现，能够说 Hudi 就是用 Spark 实现的一个通用数据湖框架，它与 Spark 的绑定堪称是深入骨髓。 ...

最近在做大数据量的实时数据迁徙, 频繁应用到了keyby hash去平衡数据, 然而却发现subtask执行的数据量不是很平衡, 导致checkpoint频繁超时, 于是开始寻找解决办法.问题背景应用keyby进行分区, 自定义KeySelector, 进行hash%并行度来进行分区, 比方应用的并行度是8, 最初会失去分区key 0, 1, 2, 3, 4, 5, 6, 7run起我的项目后, 关上监督后盾, 发现8个subtask中有一个task没有数据, 另一个task会有双倍的数据. 起因具体参考官网文档 起因很简略, flink无奈预估你会有多少key, 所以会基于最大并行度(默认128)进行一个key分组, 在这个范畴内的才会调配到task中. 以下是相干代码 public static int computeKeyGroupForKeyHash(int keyHash, int maxParallelism) { return MathUtils.murmurHash(keyHash) % maxParallelism;}那么咱们对下面本人的key, 去运行这段代码, 会失去以下后果 0 861 542 273 334 45 796 197 115咱们是8个并行, 相当于每个subtask占有16个key, 会失去以下分组: 0~15 416~31 19 2732~47 3348~63 5464~79 7980~95 8696~111 112~127 115会发现有个分区的确取得了两个key, 而一个分区轮空. 解将6换成murmurhash后在 96~111 中的key, 比方 6666(hash为106) ...

概要：大家好，咱们是 BTC.com 团队。 2020 年，咱们有幸接触到了 Flink 和 PyFlink 生态，从团队本身需要登程，欠缺了团队内实时计算的工作和需要，搭建了流批一体的计算环境。 在实现实时计算的过程中，咱们在实践中播种了一些教训，在此分享一些这方面的心路历程。 0x01 TOC困惑 • 形容 • 思考 • 口头流批一体的架构 架构成果zeppelin，PyFlink on k8s 等实际 zeppelinPyFlink on k8s区块链畛域实际瞻望 • 总结0x02 困惑 • 形容 • 思考 • 口头作为工程师，咱们每天都在一直地理解需要，研发业务。 有一天，咱们被拉到了一次团队总结会议上，收到了以下的需要： 销售总监 A： 咱们想要晓得销售的历史和实时转化率、销售额，能不能统计一下实时的 TOP5 的商品，还有就是大促时候，用户实时拜访、商品实时浏览量 TOP5 的状况呢，能够依据他历史拜访的记录实时举荐相干的吗。 市场总监 B： 咱们想要晓得市场推广的成果，每次流动的实时数据，不然咱们的市场投放无奈精确评估成果，及时反馈啊。 研发总监 C： 有些用户的 bug 无奈复现，日志能够再实时一点吗？传统日志剖析，须要肯定的梳理，可不可以间接荡涤 / 解决相干的数据？ 洽购总监 D： 这些年是不是风行数字化，洽购这边想预测洽购需要，做一下实时分类和治理收入，预测将来供给起源，欠缺一下老本。这个有方法做吗？还有有些供应商不太稳固啊，能监控到他们的状况吗？ 运维总监 E： 网站有时候拜访比较慢，没有中央能够看到实时的机器状况，搞个什么监控大屏，这个有方法解决吗？ 部门领导 F： 能够实现下面的人的需要吗。 做以上的理解之后，才发现，大家对于数据需要的渴望水平，应用方不仅须要历史的数据，而且还须要实时性的数据。 在电商、金融、制作等行业，数据有着迅猛的增长，诸多的企业面临着的新的挑战，数据分析的实时处理框架，比如说做一些实时数据分析报表、实时数据处理计算等。 和大多数企业相似，在此之前，咱们是没有实时计算这方面的教训和积攒的。这时，就开始困惑了，怎么能够更好地做下面的需要，在老本和成果之间获得均衡，如何设计相干的架构。 穷则思变，在有了困惑当前，咱们就开始筹备梳理已有的条件和咱们到底须要什么。 ...

背景在字节跳动的实时计算场景中，咱们有很多工作（数量 2k+）会间接服务于线上，其输入时延和稳定性会间接影响线上产品的用户体验，这类工作通常具备如下特点： 流量大，并发高（最大的工作并行度超过 1w）拓扑相似于多流 Join，将各个数据源做整合输入给上游，不依赖 Checkpoint没有应用 Checkpoint 并且对短时间内的小局部数据失落不敏感（如 0.5%），但对数据输入的持续性要求极高在 Flink 现有的架构设计中，多流 Join 拓扑下单个 Task 失败会导致所有 Task 重新部署，耗时可能会继续几分钟，导致作业的输入断流，这对于线上业务来说是不可承受的。针对这一痛点，咱们提出单点复原的计划，通过对 network 层的加强，使得在机器下线或者 Task 失败的状况下，以短时间内故障 Task 的局部数据失落为代价，达成以下指标： 作业不产生全局重启，只有故障 Task 产生 Failover非故障 Task 不受影响，失常为线上提供服务解决思路当初遇到这些问题的时候，咱们提出的想法是说能不能在机器故障下线的时候，只让在这台机器上的 Tasks 进行 Failover，而这些 Tasks 的上下游 Tasks 能恰好感知到这些失败的 Tasks，并作出对应的措施： 上游：将本来输入到 Failed Tasks 的数据间接抛弃，期待 Failover 实现后再开始发送数据。上游：清空 Failed Tasks 产生的不残缺数据，期待 Failover 实现后再从新建设连贯并承受数据依据这些想法咱们思考得出几个比拟关键点在于： 如何让上下游感知 Task Failed ?如何清空上游不残缺的数据 ?Failover 实现后如何与上下游从新建设连贯 ?基于以上思考咱们决定基于已有的 Network 层线程模型，批改上下游对于 Task Failed 后的解决逻辑，让非故障的 Tasks 短时间内实现对失败 Task 的感知操作，从而使得作业继续稳固地输入。 以后架构注：咱们的实现基于 Flink-1.9，1.11 后的网络模型退出了 Unaligned Checkpoint 的个性，可能会有所变动。咱们先将 Flink 的上下游 Task 通信模型简略形象一下： ...

本系列每篇文章都比拟短小，不定期更新，从一些理论的 case 登程抛砖引玉，进步小伙伴的姿♂势程度。本文介绍在满足原有需要、实现原有逻辑的场景下，在 Flink 中应用 union 代替 cogroup(或者join) ，简化工作逻辑，晋升工作性能的办法，浏览时长大略一分钟，话不多说，间接进入注释！ ## 需要场景剖析需要场景需要诱诱诱来了。。。数据产品妹妹想要统计单个短视频粒度的点赞，播放，评论，分享，举报五类实时指标，并且汇总成 photo_id、1 分钟工夫粒度的实时视频生产宽表（即宽表字段至多为：photo_id + play_cnt + like_cnt + comment_cnt + share_cnt + negative_cnt + minute_timestamp）产出至实时大屏。问题在于对同一个视频，五类视频消费行为的触发机制以及上报工夫是不同，也就决定了对实时处理来说五类行为日志对应着五个不同的数据源。sql boy 们天然就想到了 join 操作将五类消费行为日志合并，可是实时 join(cogroup) 真的那么完满咩~，下文细谈。 source 输出以及特点首先咱们剖析下需要中的 source 特点： photo_id 粒度 play（播放）、like（点赞）、comment（评论）、share（分享）、negative（举报）明细数据，用户播放（点赞、评论...）n 次，客户端服务端就会上传 n 条播放（点赞、评论...）日志至数据源五类视频消费行为日志的 source schema 都为：photo_id + timestamp + 其余维度 ### sink 输入以及特点sink 特点如下： photo_id 粒度 play（播放）、like（点赞）、comment（评论）、share（分享）、negative（举报）1 分钟级别窗口聚合数据实时视频生产宽表 sink schema 为：photo_id + play_cnt + like_cnt + comment_cnt + share_cnt + negative_cnt + minute_timestampsource、sink 样例数据source 数据： ...

如何抉择适宜本人业务的流计算引擎？除了比拟各自的性能矩阵外，基准测试（benchmark）便是用来评估零碎性能的一个重要和常见的办法。 然而在流计算畛域，目前还没有一个行业标准的基准测试。本文将探讨流计算基准测试设计上的难点，分享如何设计流计算基准测试框架——Nexmark，以及未来的布局。 背景随着数据时效性对企业的精细化经营越来越重要，“实时即将来”、“实时数仓”、“数据湖” 成为了近几年煊赫一时的词。流计算畛域的格局也在这几年产生了微小的变动，Apache Flink 在流批一体的方向上一直深耕，Apache Spark 的近实时处理有着肯定的受众，Apache Kafka 也有了 ksqlDB 高调地进军流计算，而 Apache Storm 却开始逐步地退出历史的舞台。 每一种引擎有其劣势的中央，如何抉择适宜本人业务的流计算引擎成了一个由来已久的话题。除了比拟各个引擎提供的不同的性能矩阵之外，性能是一个无奈绕开的评估因素。基准测试（benchmark）就是用来评估零碎性能的一个重要和常见的过程。 二  现有流计算基准测试的问题目前在流计算畛域中，还没有一个行业标准的基准测试。目前业界较为人知的流计算 benchmark 是五年前雅虎 Storm 团队公布的 Yahoo Streaming Benchmarks[4]。雅虎的原意是因为业界短少反映实在场景的 benchmark，模仿了一个简略的广告场景来比拟各个流计算框架，起初被宽泛援用。具体场景是从 Kafka 生产的广告的点击流，关联 Redis 中的广告所属的 campaign 信息，而后做工夫窗口聚合计数。 然而，正是因为雅虎团队太过于谋求还原实在的生产环境，导致这些内部零碎服务（Kafka, Redis）成为了作业的瓶颈。Ververica 曾在这篇文章[5]中做过一个扩大试验，将数据源从 Kafka 替换成了一个内置的 datagen source，性能晋升了 37 倍！由此可见，引入的 Kafka 组件导致了无奈精确反映引擎实在的性能。更重要的一个问题是，Yahoo Benchmark 只蕴含一个非常简单的，相似 “Word Count” 的作业，它无奈全面地反映当今简单的流计算零碎和业务。试想，谁会用一个简略的 “Word Count” 去掂量比拟各个数据库之间的性能差别呢？正是这些起因使得 Yahoo Benchmark 无奈成为一个行业标准的基准测试。这也正是咱们想要解决的问题。 因而，咱们认为一个行业标准的基准测试应该具备以下几个特点： 1.可复现性可复现性是使得 benchmark 被信赖的一个重要条件。许多 benchmark 的后果是难以重现的。有的是因为只摆了个 benchmark 后果图，用于生成这些后果的代码并没有公开。有的是因为用于 benchmark 的硬件不容易被他人获取到。有的是因为 benchmark 依赖的服务太多，以致测试后果不稳固。 ...

基于 Hive 的离线数仓往往是企业大数据生产零碎中不可短少的一环。Hive 数仓有很高的成熟度和稳定性，但因为它是离线的，延时很大。在一些对延时要求比拟高的场景，须要另外搭建基于 Flink 的实时数仓，将链路延时升高到秒级。然而一套离线数仓加一套实时数仓的架构会带来超过两倍的资源耗费，甚至导致反复开发。 想要搭建流式链路就必须得摈弃现有的 Hive 数仓吗？并不是，借助 Flink 能够实现已有的 Hive 离线数仓准实时化。本文整顿自 Apache Flink Committer、阿里巴巴技术专家李劲松的分享，文章将剖析以后离线数仓实时化的难点，详解 Flink 如何解决 Hive 流批一体准实时数仓的难题，实现更高效、正当的资源配置。文章纲要如下： 离线数仓实时化的难点Flink 在流批一体的摸索构建流批一体准实时数仓利用实际离线数仓实时化的难点离线数仓 上图是一个典型的离线数仓，假如当初公司有一个需要，目前公司的数据量很大，须要每天出一个报表且输入到业务数据库中。首先是刚入库的业务数据，大抵分为两种，一种是 MySQL 的 binlog，另外一种是业务零碎中的业务打点，这个日志打点信息能够通过 Flume 等工具去采集，再离线入库到数仓中。而后随着业务越来越多，业务中的各个表能够做一些形象，形象的益处是更好的治理和更高效的数据复用和计算复用。所以数仓就分成了多层 (明细层、中间层、服务层等等)，每一层存的是数据表，数据表之间通过 HiveSQL 的计算来实现 ETL 转换。 不止是 HiveSQL ，Hive 只是动态的批计算，而业务每天都要出报表，这意味着每天都要进行计算，这种状况下会依赖于调度工具和血统治理： 调度工具：依照某个策略把批计算调度起来。血统治理：一个工作是由许多个作业组合而成，可能有非常复杂的表构造档次，整个计算是一个非常复杂的拓扑，作业间的依赖关系非常复杂 (缩小冗余存储和计算，也能够有较好的容错)，只有当一级完结后能力进行下一级的计算。当工作非常宏大的时候，咱们得出后果往往须要很长的一段时间，也就是咱们常说的 T+1，H+1 ，这就是离线数仓的问题。 第三方工具 下面说过，离线数仓不仅仅是简略的 Hive 计算，它还依赖了其它的第三方工具，比方： 应用 Flume 来入库，但存在肯定的问题，首先，它的容错可能无奈保障 Exactly-Once 成果，须要上游再次进行去重操作。其次，自定义逻辑须要通过一些伎俩，比方脚本来管制。第三，离线数仓并不具备良好的扩大能力，当数据剧增时，减少本来的并发数就比拟艰难了。基于调度工具的作业调度会带来级联的计算提早，比方凌晨 1 点开始计算昨天的数据，可能须要到早上 6、7 点能力做完，并且无奈保障在设置的调度工夫内数据能够齐全 ready 。此外，级联的计算还会带来简单的血统治理问题，大工作的 Batch 计算可能会忽然打满集群的资源，所以也要求咱们对于负载治理进行考量，这些都会给业务减少累赘。无论是离线数仓还是第三方工具，其实次要的问题还是“慢”，如何解决慢的问题，此时就该实时数仓出场了。 实时数仓 实时数仓其实是从 Hive+HDFS 的组合换成了 Kafka，ETL 的性能通过 Flink 的流式解决解决。此时就不存在调度和血统治理的问题了，通过实时一直的增量更新，最终输入到业务的 DB 中。 ...

本文整顿自 Apache Flink PMC 伍翀（云邪）直播分享，旨在为具备肯定大数据根底、对 Flink 社区倒退感兴趣的同学提供参加奉献的一些教训和流程。 为什么要参加开源社区作为 Apache Flink PMC 的云邪依据本身经验总结了参加开源社区倒退的三个次要起因。 1. 开源精力「自在」堪称是开源精力的外围，自在意味着世界范畴内自由自在的交换分享与思维的碰撞。云邪自述“拿我集体来说，我在大学阶段正好经验了 Hadoop、Spark 大火的阶段，那时候就特地神往做开源，特地崇拜能熟读源码的大神，特地心愿本人有一天也可能写很多开源代码，让本人写的代码被上万的用户应用。所以对于我来说，参加开源就像是一个喜好一样，违心为之付出工夫和致力。我也很幸运地在毕业后就接触上了开源社区。” 2. 技术成长参加开源是晋升集体代码品质的好办法。开源社区对于代码和设计要求十分高，不像一些外部我的项目绝对随便。对于设计，Flink 社区有一套专门的 FLIP 机制，任何重大的奉献都会通过公开和粗疏的探讨。对于代码，Flink CTO 亲自写了 26 页的 Code style 指南[1]，此外每次提交 PR 后也会收到 Committers 的 Review 倡议，所以继续地在开源社区里奉献代码，对于集体的零碎思维能力和代码能力都有很大晋升。 3. 职业规划如果你在筹备跳槽或是公司外部降职，除了现有的 Title 外，参加开源社区的经验相对是一个加分项，因为开源产品自身就带有网红的标签，而参加其中则有助于进步本身的影响力 & 结识同行业的大牛们。开源奉献除了能间接地反映你的代码能力外，成为 Committer 甚至 PMC member 更能证实你的激情 & 毅力 & 沟通合作方面的 Soft skills（因为这须要你继续实现高质量的奉献，与社区其它成员独特合作，在有意见分歧的时候放弃凋谢敌对的态度 etc.）。 如何成为 Contributor1. 奉献路径不论初衷是什么，Flink 都十分欢送大家一起建设和欠缺社区。在开始具体的奉献步骤之前，咱们先简要介绍一下参加奉献的几种路径，以及 Clarify 对于开源奉献的一些固有印象。 说起开源奉献可能大家的直观反馈就是奉献代码。不过在 Flink 社区中有十分多的参加奉献的形式，包含文档、翻译、答疑、测试、以及代码等，并且社区将文档奉献放在第一位，代码奉献放在最初。因为 Apache 社区对于代码奉献的态度是  Community Over Code，Flink CTO 更是亲自发推阐明代码奉献的“不重要性”。 ...

简介： 在 Flink 现有的架构设计中，多流 Join 拓扑下单个 Task 失败会导致所有 Task 重新部署，耗时可能会继续几分钟，导致作业的输入断流，这对于线上业务来说是不可承受的。针对这一痛点，字节提出单点复原的计划。 背景在字节跳动的实时计算场景中，咱们有很多工作（数量 2k+）会间接服务于线上，其输入时延和稳定性会间接影响线上产品的用户体验，这类工作通常具备如下特点： 流量大，并发高（最大的工作并行度超过 1w）拓扑相似于多流 Join，将各个数据源做整合输入给上游，不依赖 Checkpoint没有应用 Checkpoint 并且对短时间内的小局部数据失落不敏感（如 0.5%），但对数据输入的持续性要求极高在 Flink 现有的架构设计中，多流 Join 拓扑下单个 Task 失败会导致所有 Task 重新部署，耗时可能会继续几分钟，导致作业的输入断流，这对于线上业务来说是不可承受的。 针对这一痛点，咱们提出单点复原的计划，通过对 network 层的加强，使得在机器下线或者 Task 失败的状况下，以短时间内故障 Task 的局部数据失落为代价，达成以下指标： 作业不产生全局重启，只有故障 Task 产生 Failover非故障 Task 不受影响，失常为线上提供服务解决思路当初遇到这些问题的时候，咱们提出的想法是说能不能在机器故障下线的时候，只让在这台机器上的 Tasks 进行 Failover，而这些 Tasks 的上下游 Tasks 能恰好感知到这些失败的 Tasks，并作出对应的措施： 上游：将本来输入到 Failed Tasks 的数据间接抛弃，期待 Failover 实现后再开始发送数据。上游：清空 Failed Tasks 产生的不残缺数据，期待 Failover 实现后再从新建设连贯并承受数据依据这些想法咱们思考得出几个比拟关键点在于： 如何让上下游感知 Task Failed ?如何清空上游不残缺的数据 ?Failover 实现后如何与上下游从新建设连贯 ?基于以上思考咱们决定基于已有的 Network 层线程模型，批改上下游对于 Task Failed 后的解决逻辑，让非故障的 Tasks 短时间内实现对失败 Task 的感知操作，从而使得作业继续稳固地输入。 ...

「有状态的流式解决」概念解析流式解决流式解决简略地说就是一个无穷尽的数据源在继续的收数据，以代码作为数据处理的根底逻辑，而后输入，这就是流式解决的基本原理。 分布式流式解决Stream须要做分区，设置雷同的Key，并让同样的Key流到一个computition instance做雷同的运算。 有状态分布式流式解决代码中定义了变量X，X在数据处理过程会进行读写操作，变量X会影响最初的后果输入。比方计算每个使用者呈现的次数，次数即所谓的状态。 Apache Flink 的劣势状态容错作为有状态分布式流式解决引擎，咱们会思考到容灾问题，而且心愿是准确一次的状态容错保障，因为如果批改超过了一次就意味着数据引擎产生的后果是不牢靠的。于是咱们开始思考以下几点问题： 怎么确保状态领有准确一次（Exactly-once guarantee）的容错保障？在分布式场景下怎么为领有多个本地状态的operator产生grobal consistent snapshot？最重要的是，怎么在不中断的前提下继续一直地产生快照呢？简略场景的准确一次容错办法 咱们能够思考最简略的应用场景，比方是在繁多的Flink Process中进行运算，咱们想到能够用“笨办法”，每解决完一笔计算就累计一次状态，进行一次快照，就能确保准确一次。 分布式状态容错 假如在分布式场景下，进行多个本地状态的运算。当初咱们引入一个Checkpoint的概念，将每个Opeartor的状态保留在Checkpoint中，并且将Checkpoint传入共享的DFS中。如果任何一个Process挂掉，就能够从三个残缺的Checkpoint将所有运算值得状态复原。Checkpoint的存在使整个Process可能实现在分布式环境中的Exactly-once。 分散式快照（Distributed Snapshots）办法 对于 Flink 如何在不中断运算的情况下继续产生 Global consistent snapshot？引入Checkpoint barrier N 的概念， Flink首先会在job manager触发Checkpoint，Checkpoint触发后会在 Datastream 中会安插 Checkpoint barrier N。 当数据源收到 Checkpoint barrier N 后会将自已的状态保留好，Checkpoint barrier N 跟着数据流动到 Opeartor1 之后，Opeartor1 将数据记录在状态中，同样当 Checkpoint barrier N 流到 Opeartor2，Opeartor2 也会将数据反映到状态上。以上能够看到 Checkpoint barrier N 实现了一个残缺的表格，这个表格叫做Distributed Snapshots，即分布式快照。 Flink job manager 能够触发其余的Checkpoint，比方 Checkpoint N + 1，Checkpoint N + 2,等也能够同步进行。正是利用这种机制，能够在不阻挡运算的情况下继续的产生Checkpoint。 ...

这些天学习了Flink的的架构，流计算和罕用算子后，陷入了迷茫，不晓得从哪里持续下手了，起初发现了阿里巴巴出品的Flink官网视频教程，看了巴真大佬的第一章 “ 1. 为什么要学习 Apache Flink？”，我过后就感叹，妈耶，讲得太好了吧。于是我决定从Flink-China的系列教程开始，对每一章节讲完之后在SegmenetFault上进行成绩的总结输入，以此来鞭策自已的不断进步，也与大家共勉! Apache Flink Definition：Apache Flink is a framework and distributed processing engine for stateful computations over unbounded and bounded data streams.Apache Flink是一个框架和分布式解决引擎，用于无边界和有边界数据流上的有状态计算。Flink Application Flink（应⽤开发相干常识）根底解决语义 Streams、State、TimeFlink Application - Streams Flink Application - State Flink Application - Time 多层次API，灵活性和⽅便性的兼顾Flink Application - API Flink Architecture Flink根本架构原理以及核⼼逻辑Flink Operation Flink运维治理相干内容有状态Flink应用程序针对本地状态拜访进行了优化。Flink通过定期和异步地将本地状态查看为长久状态来保障在产生故障时的一次状态一致性 Flink Scenario 利用场景Data Pipeline（实时build搜索引擎，实时数仓）提取-转换-加载(ETL)是在存储系统之间转换和挪动数据的常见办法。Flink数据管道以连续流模式运行，而不是周期性地触发。 Data Analytics（大屏）剖析工作从原始数据中提取信息和洞察力 Data Driven （简单规定的风控）事件驱动的应用程序是一个有状态的应用程序，它从一个或多个事件流中摄取事件，并通过触发计算、状态更新或内部操作来响应传入的事件。 ...

Flink 1.11 最重要的 Feature —— Hive Streaming 之前曾经和大家分享过了，明天就和大家来聊一聊另一个特地重要的性能 —— CDC。 CDC概述何为CDC？Change Data Capture，将数据库中的’增’、’改’、’删’操作记录下来。在很早之前是通过触发器来实现记录，当初通过 binlog+同步中间件来实现。罕用的 binlog 同步中间件有很多，比方 Alibaba 开源的 canal[1]，Red Hat 开源的debezium[2]，Zendesk 开源的 Maxwell[3] 等等。 这些中间件会负责 binlog 的解析，并同步到消息中间件中，咱们只须要生产对应的 Topic 即可。 回到 Flink 上，CDC 仿佛和咱们没有太大的关联？其实不然，让咱们更加抽象地来看这个世界。 当咱们用 Flink 去生产数据比方 Kafka 时，咱们就好像在读一张表，什么表？一张一直有记录被插入的表，咱们将每一条被插入的数据取出来，实现咱们的逻辑。 当插入的每条数据都没有问题时，所有都很美妙。关联、聚合、输入。 但当咱们发现，某条曾经被计算过的数据有问题时，麻烦大了。咱们间接改最初的输入值其实是没有用的，这次改了，当再来数据触发计算时，后果还是会被谬误的数据笼罩，因为两头计算结果没有被批改，它依然是一个谬误的值。怎么办？撤回流仿佛能解决这个问题，这也的确是解决这个问题的伎俩，然而问题来了，撤回流怎么确定读取的数据是要被撤回的？另外，怎么去触发一次撤回？ CDC 解决了这些：将消息中间件的数据反序列化后，依据 Type 来辨认数据是 Insert 还是 Delete；另外，如果大家看过 Flink 源码，会发现反序列化后的数据类型变了，从 Row 降级为 RowData，RowData 可能将数据标记为撤回还是插入，这就意味着每个算子可能判断出数据到底是须要下发还是撤回。 CDC 的重要性就先说这么多，之后有机会的话，出一篇实时 DQC 的视频，通知大家 CDC 的呈现，对于实时 DQC 的帮忙有多大。上面让咱们回到正题。 既然有那么多 CDC 同步中间件，那么肯定会有各种各样的格局寄存在消息中间件中，咱们必然须要去解析它们。于是 Flink 1.11 提供了 canal-json 和 debezium-json，但咱们用的是 Maxwell 怎么办？只能等官网出或者说是等有人向社区奉献吗？那如果咱们用的是自研的同步中间件怎么办？ ...

当业务倒退到肯定规模，实时数据仓库是一个必要的根底服务。从数据驱动方面思考，多维实时数据分析系统的重要性也显而易见。然而当数据量微小的状况下，拿腾讯看点来说，一天上报的数据量达到万亿级的规模，要实现极低提早的实时计算和亚秒级的多维实时查问是有技术挑战的。 本文将介绍信息流场景下，腾讯看点的实时数据仓库和多维实时数据分析系统的技术架构。 1、可解决的痛点能够先看一下，多维实时数据分析系统能够解决哪些痛点。比方： 举荐同学 10 分钟前上了一个举荐策略，想晓得在不同人群的举荐成果怎么样？经营同学想晓得，在广东省的用户中，最火的广东地区内容是哪些，不便做地区 Push。审核同学想晓得，过来 5 分钟，游戏类被举报最多的内容和账号是哪些？老板可能想理解，过来 10 分钟有多少用户在看点生产了内容，对生产人群有一个宏观理解。2、调研 在进行开发之前，咱们做了这些调研。 1. 离线数据分析平台是否满足这些需要，论断是不能满足。离线数据分析平台不行的起因如下。 C 侧数据上报过去，须要通过 Spark 的多层离线计算，最终后果出库到 MySQL 或者 ES 提供给离线剖析平台查问。这个过程的延时起码 3-6 个小时，目前比拟常见的都是提供隔天的查问，所以很多实时性要求高的业务场景都是不能满足的。另一个问题是，腾讯看点的数据量太大，带来的不稳定性也比拟大，常常会有预料不到的提早。所以，离线剖析平台是无奈满足很多需要的。2. 实时数据分析平台的话，事业群外部提供了准实时数据查问的性能，底层技术用的是 Kudu+Impala，Impala 尽管是 MPP 架构的大数据计算引擎，并且拜访以列式存储数据的 Kudu。然而对于实时数据分析场景来说，查问响应的速度和数据的提早都还是比拟高，查问一次实时 DAU，返回后果耗时至多几分钟，无奈提供良好的交互式用户体验。所以（Kudu+Impala）这种通用大数据处理框架的速度劣势更多的是相比（Spark+Hdfs）这种离线剖析框架来说的，对于咱们这个实时性要求更高的场景，是无奈满足的。 3、我的项目背景 通过方才的介绍，再来看下咱们这个我的项目的背景。作者发文的内容被内容核心引入，通过内容审核链路，启用或者下架。启用的内容给到举荐零碎和经营零碎，而后举荐零碎和经营零碎将内容进行 C 侧散发。内容分发给 C 侧用户之后，用户会产生各种行为，曝光、点击、举报等，通过埋点上报实时接入到音讯队列中。接下来咱们做了两局部工作，就是图中有色彩的这两局部。 第一局部构建了一个腾讯看点的实时数据仓库。第二局部就是基于 OLAP 存储引擎，开发了多维实时数据分析系统。咱们为什么要构建实时数仓，因为原始的上报数据量十分大，一天上报峰值就有上万亿条。而且上报格局凌乱。不足内容维度信息、用户画像信息，上游没方法间接应用。而咱们提供的实时数仓，是依据腾讯看点信息流的业务场景，进行了内容维度的关联，用户画像的关联，各种粒度的聚合，上游能够十分不便的应用实时数据。 4、计划选型 那就看下咱们多维实时数据分析系统的计划选型，选型咱们比照了行业内的当先计划，抉择了最合乎咱们业务场景的计划。 第一块是实时数仓的选型，咱们抉择的是业界比拟成熟的 Lambda 架构，他的长处是灵活性高、容错性高、成熟度高和迁徙成本低；毛病是实时、离线数据用两套代码，可能会存在一个口径批改了，另一个没改的问题，咱们每天都有做数据对账的工作，如果有异样会进行告警。第二块是实时计算引擎选型，因为 Flink 设计之初就是为了流解决，SparkStreaming 严格来说还是微批处理，Strom 用的曾经不多了。再看 Flink 具备 Exactly-once 的准确性、轻量级 Checkpoint 容错机制、低延时高吞吐和易用性高的特点，咱们抉择了 Flink 作为实时计算引擎。第三块是实时存储引擎，咱们的要求就是须要有维度索引、反对高并发、预聚合、高性能实时多维 OLAP 查问。能够看到，Hbase、Tdsql 和 ES 都不能满足要求，Druid 有一个缺点，它是依照时序划分 Segment，无奈将同一个内容，寄存在同一个 Segment上，计算全局 TopN 只能是近似值，所以咱们抉择了最近两年大火的 MPP 数据库引擎 ClickHouse。5、设计指标与设计难点 ...

工作提交流程 Flink提交工作，Client向HDFS上传Flink的Jar包和配置之后向Yarn ResourceManager提交工作ResourceManager调配Container资源并告诉对应的NodeManager启动ApplicationMaster，ApplicationMaster启动后加载Flink的Jar包和配置来构建环境，而后启动JoManager。之后ApplicationMaster向ResourceManager申请资源启动TaskManagerResourceManager调配Container资源后，由ApplicationMaster告诉资源所在节点的NodeManager启动TaskManager，NodeManager加载Jar和配置构建环境并启动TaskManagerTaskManager启动后向JobManager发送心跳包，并期待JobManager向其分配任务。任务调度原理 Client：提交Job的客户端。JobManager: 从Client处接到Job和Jar包后，以Task的单元调度到各个TaskManager去执行。即次要负责调度Job并协调Task做checkpoint。TaskManager：从JobManager接管须要部署的Task，与自已的上游建设Netty连贯。在启动是设置好槽位数Slot，每个Slot能启动一个Task线程。当Flink集群启动后，首先会启动一个JobManager和一或多个TaskManager。JobManager再调度各个Task到TaskManager执行，TaskManager将心跳和统计信息汇报给JobManager。 GraphFlink 中的执行图能够分成四层：StreamGraph -> JobGraph -> ExecutionGraph -> 物理执行图 StreamGraph：依据用户通过Stream API编写的代码生成最后的图，示意程序的拓扑构造。JobGraph：StreamGraph通过优化后生成了JobGraph，是提交给JobManager的数据结构。次要优化位，将多个符合条件的节点chain在一起作为一个节点，这样能够缩小数据在节点之间流动所须要的序列化/反序列化/传输耗费。ExecutionGraph：JobManager依据JobGraph生成ExecutionGraph，ExecutionGraph是JobGraph的并行化版本，是调度层最外围的数据结构。物理执行图：JobManager 依据 ExecutionGraph 对 Job 进行调度后，在各个TaskManager 上部署 Task 后造成的“图”Stream 和 TransformationFlink是由Stream和Transformation这两个根本构建块组成，其中Stream是一个两头后果数据，Transformation是一个操作，，它对一个或多个输出Stream进行计算解决，输入一个或多个后果Stream。 Flink程序被执行的时候，会被映射为Streaming Dataflow。一个Streaming Dataflow是由一组Stream和Transformation Opearator组成。 并行数据流一个Stream能够被分成多个Stream Partition，一个Operator能够被分成多个Operator Subtask，每一个Operator Subtask是在不同的线程中独立执行的。一个Operator的并行度，等于Operator Subtask的个数，一个Stream的并行度总是等于生成它的Operator的并行度。 One-to-one模式:比如说从Source[1]到map[1]，他放弃了Source的分区个性和分区内元素解决的有序性，也就是说map()[1]的Subtask看到的数据流中记录的数据，与Source[1]看到的记录程序是一样的。Redistribution模式：这种模式扭转了输出数据流的分区，比方从map()[1]、map()[2]到keyBy()/window()/apply()[1]、keyBy()/window()/apply()[2]，上游的Subtask向上游的多个不同的Subtask发送数据，扭转了数据流的分区，这与理论利用所抉择的Operator有关系。 工作链Fink分布式执行环境中，会将多个Operator Subtask串起来组成一个Operator Chain，实际上就是一个执行链，每个执行链会在TaskManager上一个独立的线程中执行。 Checkpoint机制 CheckpointCoordinator周期性的向该数据流，所有的source算子发送barrier。Source算子接管到一个barrier后，便暂停解决数据，将以后的状态制作成快照，并保留到指定的长久化存储中，最初它再向CheckpointCoordinator报告本人的快照制作状况。同时向本身上游所有算子播送该barrier。而后复原该算子的数据处理工作。上游的算子接管到barrier后，也会暂停自的数据处理过程，同2过程。最初CheckpointCoordinator会确认它接管到的报告，如果收到本周期的所有算子的快照就认为快照制作胜利，否则失败。

多流join实时计算的JOIN和传统批处理JOIN的语义统一，都用于将两张表分割起来。区别的是实时计算分割的是两张动静表，分割的后果也会动静更新以保障最终后果和批处理后果保持一致。 场景形容订单表动静关联商品表，关联字段为商品id，输入关联后的宽表，源表数据样例如下所示。 订单表： 商品表： -- 多流join-- 2019-10-22 11:42:04-- moxian-- 实时计算的JOIN和传统批处理JOIN的语义统一，都用于将两张表分割起来。区别的是实时计算分割的是两张动静表，分割的后果也会动静更新以保障最终后果和批处理后果保持一致。INSERT INTO mx_stream2streamSELECT o.rt as rowtime, o.productId as productId, o.orderId as orderId, o.units as units, p.name as category, cast(p.unitPrice as int) as unitPriceFROM orders o --源表1 订单表JOIN products p --源表2 产品表ON o.productId = p.productId;留神： 订单表是动静的，产品示意动态的，动静表join动态表

引言实时工作的解决流程通常分3步，前2步建设好数据源与数据指标，之后再写数据计算的逻辑，实现对流式数据的剖析解决，如下图所示： 窗口函数窗口函数Flink SQL反对基于无限大窗口的聚合（无需显式定义在SQL Query中增加任何的窗口）以及对一个特定的窗口的聚合。 Flink SQL反对的窗口聚合次要是两种：Window聚合和Over聚合。Window聚合反对两种工夫属性定义窗口：Event Time和Processing Time。每种工夫属性类型反对三种窗口类型：滚动窗口（TUMBLE）、滑动窗口（HOP）和会话窗口（SESSION），本文将以滚动窗口（TUMBLE）为例，具体介绍窗口函数的应用。 -- 滚动窗口【proctime】-- 2019-09-17 10:52:34-- moxian-- 滚动窗口（TUMBLE）将每个元素调配到一个指定大小的窗口中。通常滚动窗口有一个固定的大小，并且不会呈现重叠。-- 例如：如果指定了一个5分钟大小的滚动窗口，有限流的数据会依据工夫划分成 [0:00 - 0:05)、 [0:05, 0:10)、 [0:10, 0:15)等窗口insert into user_clicks_resultselect cast(TIMESTAMPADD(HOUR,8,tumble_start(PROCTIME,interval '1' minute)) as varchar) as window_start, --返回窗口的起始工夫,如窗口区间[00:00,01:00],返回[00:00] cast(TIMESTAMPADD(HOUR,8,tumble_end(PROCTIME,interval '1' minute)) as varchar) as window_end, --返回窗口的起始工夫,如窗口区间[00:00,01:00],返回[01:00] username, cast(count(click_url) as varchar) as clicksfrom user_clicksgroup by tumble(PROCTIME,interval '1' minute),username --tumble(time-attr,窗口大小)

流式计算的世界观： 工夫不停万物不停在批量的时代，咱们只记录要害的信息，只在乎以后，不在乎状态是如何一步步变动至当状态的，所以说批时代咱们计算所面向的数据是动态的。在分布式环境中批量计算是将计算挪动到相应的数据上进行运行。在流世界里，咱们在乎的是变动，咱们计算所面临的将是时时刻刻更新流动的数据。流式计算是将定义好的计算部署到分布式节点上，让数据在下面流动。不再把数据定性为“解决某天的数据，解决某个季度的数据”，而是随着工夫的推移，零碎要捕捉到用户每分每秒产生的数据，进行计算解决后让业务报告保障最新。 流式解决中的工夫事件工夫（Eventtime）：事件实在产生的工夫，因为...起因，事件产生的工夫和达到服务端的工夫可能是相差极大的达到工夫：服务端接管到事件的工夫解决工夫：零碎开始前途达到事件的工夫//创立环境上下文val env = StreamExecutionEnvironment.getExecutionEnvironment// 设置在以后程序中应用 ProcessingTimeenv.setStreamTimeCharacteristic(TimeCharacteristic.ProcessingTime);窗口滚动窗口：依照固定的工夫片断划分数据流，将数据流宰割成固定大小的片段。滑动窗口：由固定窗口长度windows-size=1和窗口滑动步长windows-slide=0.5，示意窗口长度为1，每0.5个单位就向前滑动一个新窗口。滑动窗口常常被用来统计诸如“每5分钟统计过来10分钟的访问量”，windows-size=10和windows-slide=5会话窗口：会话的窗口的大小由用户流动的事件频率决定，没有固定的窗口大小。流式解决的设计模式流和表的连贯:有时候，咱们须要在内部数据中保留一些规定后，须要时将信息完完整整的拉进流中。然而，流式解决零碎每秒能够解决10-50W个事件，而数据库每秒的只能解决1W个事件。所以，内部查找不仅会带来重大的提早性，如果数据刷新的太频繁会对数据库造成很大的压力，如果刷新不及时，那么流式解决中所用的数据就会过期。所以，咱们采纳通过Canal来捕捉Mysql数据库的变动，造成事件流，Flink就能够监听事件流，并及时更新。State在Flink中，状态用于缓存用户数据，窗口数据，程序运行状态，数据源偏移量 Checkpoint定期对State中的数据进行备份并复原的机制，正是有了State和Checkpoint，Flink能力做到： 备份与复原，7*24的运行是容错数据不失落不反复，Exactly one低提早数据间有关联，通过状态满足业务逻辑Watermark 和 TriggerFlink中放弃正确性的工具是State和Checkpoint，提供工夫推理能力的是Watermark和Trigger。

Flink集群的部署Flink的部署有三种模式，别离是Local，Standalone Cluster和Yarn Cluster，这里咱们次要讲如何配置Yarn Cluster。 在配置Flink On Yarn之前，必须保障hdfs和yarn都曾经开启：Hadoop集群部署与启动，Yarn模式要思考Container内存资源分配 装置版本： flink-1.7.1-bin-hadoop28-scala_2.11.tgz mkdir /usr/local/flinktar zxvf flink-1.7.1-bin-hadoop28-scala_2.11.tgz -C /usr/local/flink批改域名与IP的对应关系(hadoop2和hadoop3同样也须要批改hosts文件） vi /etc/hosts10.2.15.176 hadoop110.2.15.177 hadoop210.2.15.170 hadoop3配置环境变量(hadoop2和hadoop3同样也须要批改hosts文件） vi /etc/profileexport FLINK_HOME=/usr/local/flink/flink-1.7.1export PATH=$PATH:$FLINK_HOME/binexport HADOOP_HOME=/usr/local/hadoop/hadoop-2.8.3export PATH=$HADOOP_HOME/bin:$PATHsource /etc/profile批改flink-conf.yaml文件 vi /usr/local/flink/flink-1.7.1/conf/flink-conf.yaml#==============================================================================# Common#==============================================================================jobmanager.rpc.port: 6123jobmanager.heap.size: 1024mtaskmanager.heap.size: 1024mtaskmanager.numberOfTaskSlots: 1parallelism.default: 1env.java.home: /usr/local/jdk/jdk1.8.0_251jobmanager.heap.mb: 6192mtaskmanager.heap.mb: 8192m#==============================================================================# High Availability#==============================================================================high-availability: zookeeperhigh-availability.storageDir: hdfs:///flink/ha/high-availability.zookeeper.quorum: 10.2.15.181:2181,10.2.15.174:2181,10.2.15.172:2181high-availability.zookeeper.path.root: /flink_on_yarnhigh-availability.zookeeper.path.namespace: /cluster_yarn#==============================================================================# Fault tolerance and checkpointing#==============================================================================state.backend: filesystemstate.backend.fs.checkpointdir: hdfs:///flink/checkpoints#==============================================================================# Web Frontend#==============================================================================rest.port: 8081#==============================================================================# Advanced#==============================================================================taskmanager.memory.preallocate: falsetaskmanager.network.numberOfBuffers: 64000fs.hdfs.hadoopconf: /usr/local/hadoop/hadoop-2.8.5/etc/hadoop批改masters和slaves文件 vi conf/mastershadoop1:8081hadoop2:8081vi conf/slaveshadoop2hadoop3提交Job首先先启动ZooKeeperjps仲裁 ./start-zookeeper-quorum.sh而后启动Per-Job-Cluster工作，可通过 ./bin/flink run -m yarn-cluster -d -c mainClass /path/to/user/jar 命令应用拆散模式启动一个集群，即单任务单集群 ...

Apache Flink Meetup 2020 · 深圳站正！式！上！线！ 如何基于 Flink + Iceberg 构建企业级数据湖？ Hudi on Flink 有哪些生产环境利用实际？基于 Flink 搭建的监控体系如何更平面？ AI + Flink 可实现隐衷爱护？ 9月26日，来自阿里巴巴、英特尔、顺丰、腾讯的四位技术专家与你分享 Flink 最新企业应用实际，以及与时下热门的数据湖、数仓、社区生态的联合有哪些新进展。 流动亮点：独家干货分享，4位一线大厂技术专家分享时下热门的数据湖、数仓、AI、监控等企业级生产环境利用实际；流动模式多样化，线下线上同步开启，同城可参加线下 Meetup 面对面交换，异地也可在线观看直播，精彩内容不错过；丰盛周边等你拿，报名加入就有机会取得超多 Flink 社区定制的精美周边！▼ 扫码报名，理解更多流动详情 ▼ 演讲主题及嘉宾介绍《Hudi on Flink 在顺丰的实际利用》蔡适择 | 顺丰 大数据平台负责人 演讲简介： 本次分享次要介绍顺丰在数据仓库的数据实时化、数据库 CDC、Hudi on Flink 上的实际利用及产品化教训。 嘉宾简介： 负责顺丰大数据平台建设及产品化工作，在大数据平台、物联网、边缘计算畛域有丰盛的实践经验，致力于大幅升高数据开发及利用门槛，让大数据技术成为一项人人可用、可疾速利用的技术。 《用 Analytics-Zoo 和 Flink 实现隐衷爱护的 Cluster Serving》龚奇源 | 英特尔 机器学习工程师 演讲简介： 如何在数据利用过程中爱护用户隐衷，始终是近年来工业界和学术界的热点。本次讲座将为大家介绍，如何通过 Analytics-Zoo 和 Flink，在 Intel SGX 上实现隐衷爱护的 Cluster Serving，从而在 Model Serving 过程中爱护用户数据、模型和预测后果。 Key points: ...

大家好我是许振文，明天分享的主题是《基于 Flink+ServiceMesh 的腾讯游戏大数据服务利用实际》，内容次要分为以下四个局部： 背景和解决框架介绍实时大数据计算 OneData数据接口服务 OneFun微服务化& ServiceMesh一、背景和解决框架介绍1、离线数据经营和实时数据经营 首先介绍下背景，咱们做游戏数据经营的工夫是比拟久的了，在 13 年的时候就曾经在做游戏离线数据分析，并且能把数据使用到游戏的经营流动中去。 但那时候的数据有一个缺点，就是大部分都是离线数据，比方明天产生的数据咱们算完后，第二天才会把这个数据推到线上。所以数据的实时性，和对游戏用户的实时干涉、实时经营成果就会十分不好。尤其是比方我明天中的奖，今天能力拿到礼包，这点是玩家很不爽的。 当初提倡的是：“我看到的就是我想要的”或者“我想要的我立马就要”，所以咱们从 16 年开始，整个游戏数据逐步从离线经营转到实时经营，但同时咱们在做的过程中，离线数据必定少不了，因为离线的一些计算、累计值、数据校准都是十分有价值的。 实时方面次要是补足咱们对游戏经营的体验，比如说在游戏里玩完一局或者做完一个工作后，立马就能失去相应的处分，或者下一步的玩法指引。对用户来说，这种及时的刺激和干涉，对于他们玩游戏的体验会更好。 其实不单单是游戏，其余方面也是一样的，所以咱们在做这套零碎的时候，就是离线+实时联合着用，但次要还是往实时方面去聚拢，将来大数据的方向也是，尽量会往实时方向去走。 2、利用场景■ 1）游戏内工作零碎 这个场景给大家介绍一下，是游戏内的工作零碎，大家都应该看过。比方第一个是吃鸡里的，每日实现几局？分享没有？还有其余一些流动都会做简历，但这种简历咱们当初都是实时的，尤其是须要全盘计算或者分享到其余社区里的。以前咱们在做数据经营的时候，都是工作做完回去计算，第二天才会发到处分，而当初所有工作都能够做到实时干涉。 游戏的工作零碎是游戏中特地重要的环节，大家不要认为工作零碎就是让大家实现工作，收大家钱，其实工作零碎给了玩家很好的指引，让玩家在游戏中能够失去更好的游戏体验。 ■ 2）实时排行版 还有一个很重要的利用场景就是游戏内的排行榜，比如说王者光荣里要上星耀、王者，其实都是用排行榜的形式。但咱们这个排行榜可能会更具体一些，比如说是明天的战力排行榜，或者明天的对局排行榜，这些都是全局计算的实时排行榜。而且咱们有快照的性能，比方 0 点 00 分 的时候有一个快照，就能立马给快照里的玩家发处分。 这些是实时计算的典型利用案例，一个工作零碎一个排行榜，其余的咱们前面还会缓缓介绍。 3、游戏对数据的需要 再说一下为什么会有这样一个平台，其实咱们最后在做数据经营的时候，是筒仓式或者手工作坊式的开发。当接到一个需要后，咱们会做一个资源的评审、数据接入、大数据的编码，编码和数据开发完后，还要做线上资源的申请、公布、验证，再去开发大数据计算实现后的服务接口，而后再开发页面和线上的零碎，这些都完了后再发到线下来，做线上监控，最初会有一个资源回收。 其实这种形式在很晚期的时候是没有问题的，那为什么说当初不适应了？次要还是流程太长了。咱们当初对游戏经营的要求十分高，比如说咱们会接入数据挖掘的能力，大数据实时计算实现之后，咱们还要把实时的用户画像，离线画像进行综合，接着举荐给他这个人适宜哪些工作，而后指引去实现。 这种状况下，原来的做法门槛就比拟高了，每一个都要独自去做，而且老本高效率低，在数据的复用性上也比拟差，容易出错，而且没有方法积淀。每一个做完之后代码回收就扔到一块，最多下次做的时候，想起来我有这个代码了能够略微借鉴一下，但这种借鉴基本上也都是一种手工的形式。 所以咱们心愿能有一个平台化的形式，从我的项目的创立、资源分配、服务开发、在线测试、独立部署、服务上线、线上监控、成果剖析、资源回收、我的项目结项整个综合成一站式的服务。 其实这块咱们是借鉴 DevOps 的思路，就是你的开发和经营应该是一个人就能够独立实现的，有这样一个零碎可能去撑持这件事。当一个服务在平台上出现进去的时候，有可能会复用到计算的数据，比说实时的登录次数或击杀数，那这个指标在前面的服务中就能够共用。 而且有了这样一个平台之后，开发者只需次要关注他的开发逻辑就行了，其余两条运维公布和线上经营都由平台来保障。所以咱们心愿有一个平台化的形式，把数据计算和接口服务对立起来，通过数据的标准化和数据字典的对立，可能造成下面不同的数据利用，这个是咱们的第一个指标。 其实咱们当初都是这种形式了，第一是要在 DevOps 的指导思想上来做，尤其是腾讯去做的时候数据服务的量是十分大的，比方咱们去年一共做了 5、6 万的营销服务，在这种状况下如果没有平台撑持，没有平台去治理和治理这些服务，单靠人的话老本十分大。 4、思路3 个现代化，大数据利用的 DevOps。 咱们的思路也是这样，三个现代化，而且把大数据利用的 DevOps 思路实现起来。 规范化：流程标准、数据开发标准和开发框架；自动化：资源分配、公布上线、监控部署（这是 DevOps 里不可短少的）；一体化：数据开发、数据接口开发、测试公布、运维监控。所以咱们针对大数据的利用零碎，会把它拆成这样三块，一个是大数据的开发，另外一个是数据服务接口的开发，当然接口前面就是一些页面和客户端，这些完了后这些开发还要有一个残缺的开发流程反对。 这样咱们就可能为各种数据利用场景提供一站式的数据开发及利用解决服务、对立的流动治理、数据指标计算开发治理和各种数据利用接口自动化生产治理的一站式的服务。 这样的零碎能保障这些的事件，而且咱们这里也正当拆分，不要把大数据和接口混到一块去，肯定要做解耦，这是一个十分要害的中央。 5、数据服务平台整体架构 ■ 1）计算存储 这个框架大家能够看一下，我认为能够借鉴，如果你外部要去做一个数据服务平台的话，基本上思路也是这样的，底层的 Iass 能够不必管，间接用腾讯云或者阿里云或者其余云上的服务就能够了。 咱们次要是做下层这一块的货色，最上面的计算存储这个局部咱们外部在做零碎的时候也不是 care 的，这块最好是能承包进来。当初 Iass 倒退到这个水平，这些货色在云上能够间接像 MySQL 数据库或者 Redis 数据库一样购买就行了，比方 Kafka、Pulsar、Flink、Storm。 ...

截至以后，Flink 作业的状态后端依然只有 Memory、FileSystem 和 RocksDB 三种可选，且 RocksDB 是状态数据量较大（GB 到 TB 级别）时的惟一抉择。RocksDB 的性能施展十分仰赖调优，如果全副采纳默认配置，读写性能有可能会很差。 然而，RocksDB 的配置也是极为简单的，可调整的参数多达百个，没有放之四海而皆准的优化计划。如果仅思考 Flink 状态存储这一方面，咱们依然能够总结出一些绝对普适的优化思路。本文先介绍一些基础知识，再列举办法。 Note：本文的内容是基于咱们在线上运行的 Flink 1.9 版本实际得出的。在1.10版本及当前，因为 TaskManager 内存模型重构，RocksDB 内存默认成为了堆外托管内存的一部分，能够免去一些手动调整的麻烦。如果性能依然不佳，须要干涉，则必须将 state.backend.rocksdb.memory.managed 参数设为 false 来禁用 RocksDB 内存托管。State R/W on RocksDBRocksDB 作为 Flink 状态后端时的读写逻辑与个别状况略有不同，如下图所示。 Flink 作业中的每一个注册的状态都对应一个列族（column family），即蕴含本人独立的 memtable 和 sstable 汇合。写操作会先将数据写入流动 memtable，写满之后则会转换为不可变 memtable，并 flush 到磁盘中造成 sstable。读操作则会顺次在流动 memtable、不可变 memtable、block cache 和 sstable 中寻找指标数据。另外，sstable 也须要通过 compaction 策略进行合并，最终造成分层的 LSM Tree 存储构造，陈词滥调了。 特地地，因为 Flink 在每个检查点周期都会将 RocksDB 的数据快照长久化到文件系统，所以天然也就不须要再写预写日志（WAL）了，能够平安地敞开WAL与fsync。 之前笔者曾经具体解说过 RocksDB 的 compaction 策略，并且提到了读放大、写放大和空间放大的概念，对 RocksDB 的调优实质上就是在这三个因子之间获得均衡。而在 Flink 作业这种重视实时性的场合，则要重点思考读放大和写放大。 ...

❝本文具体介绍了在上游应用解决工夫语义的 flink 工作呈现故障后，重启生产大量积压在上游的数据并产出至上游数据乱序特地重大时，上游 flink 工作应用事件工夫语义时遇到的大量丢数问题以及相干的解决方案。 ❞ 本文分为以下几个局部： 「1.本次踩坑的利用场景」「2.利用场景中产生的丢数故障剖析」「3.待修复的故障点」「4.丢数故障解决方案及原理」「5.总结」利用场景利用场景如下： 「flink 工作 A」 以「解决工夫」语义做过滤产出新增 xx 明细数据至 「Kafka Y」「flink 工作 B」 以「事件工夫」语义生产 「Kafka Y」 做窗口聚合操作产出分钟级别聚合指标至 「Kafka Z」「Kafka Z」 实时导入至 「Druid」 以做即时 OLAP 剖析，并且展现在 BI 利用看板 丢数故障剖析简要介绍下这次生产中故障场景。整条故障追踪链路如下： 故障一： 收到报警反馈 「flink 工作 A」 入口流量为 0定位 「flink 工作 A」 中某个算子的故障导致整个 job 卡住导致此 「flink 工作 A」 上游 「kafka X」 积压了大量数据重启 「flink 工作 A」后，生产大量积压在上游 「kafka X」 数据实现，工作恢复正常故障一从而引发上游的故障二： 因为 「flink 工作 A」 应用了「解决工夫」语义解决数据，并且有过滤和 keyBy 分桶窗口逻辑，在重启后生产大量积压在上游的数据时，导致 sink rebalance 后产出到上游 「kafka Y」 各个分区数据中的 server_timestamp 是乱序的上游 「flink 工作 B」 在生产 「Kafka Y」 时应用了「事件工夫」语义解决数据，并且应用了数据中的 server_timestamp 作为「事件工夫」工夫戳「flink 工作 B」 生产了乱序很重大的数据之后，导致在窗口聚合计算时失落了大量数据最终展现在 BI 利用中的报表有失落数据的状况 ...

随着滴滴业务的高速倒退，业务对于数据时效性的需要越来越高，而随同着实时技术的一直倒退和成熟，滴滴也对实时建设做了大量的尝试和实际。本文次要以逆风车这个业务为引子，从引擎侧、平台侧和业务侧各个不同方面，来论述滴滴所做的工作，分享在建设过程中的教训。 1.实时数仓建设目标随着互联网的倒退进入下半场，数据的时效性对企业的精细化经营越来越重要，商场如战场，在每天产生的海量数据中，如何能实时无效的挖掘出有价值的信息， 对企业的决策经营策略调整有很大帮忙。 其次从智能商业的角度来讲，数据的后果代表了用户的反馈，获取后果的及时性就显得尤为重要，疾速的获取数据反馈可能帮忙公司更快的做出决策，更好的进行产品迭代，实时数仓在这一过程中起到了不可代替的作用。 1.1 解决传统数仓的问题从目前数仓建设的现状来看，实时数仓是一个容易让人产生混同的概念，依据传统教训剖析，数仓有一个重要的性能，即可能记录历史。通常，数仓都是心愿从业务上线的第一天开始有数据，而后始终记录到当初。但实时流解决技术，又是强调以后解决状态的一个技术，联合以后一线大厂的建设教训和滴滴在该畛域的建设现状，咱们尝试把公司内实时数仓建设的目标定位为，以数仓建设实践和实时技术，解决因为以后离线数仓数据时效性低解决不了的问题。 现阶段咱们要建设实时数仓的次要起因是： 公司业务对于数据的实时性越来越迫切，须要有实时数据来辅助实现决策实时数据建设没有标准，数据可用性较差，无奈造成数仓体系，资源大量节约数据平台工具对整体实时开发的反对也日渐趋于成熟，开发成本升高1.2 实时数仓的利用场景实时 OLAP 剖析：OLAP 剖析自身就是数仓畛域重点解决的问题，基于公司大数据架构团队提供的基于 Flink 计算引擎的 stream sql 工具，Kafka 和 ddmq (滴滴自研)等消息中间件，druid 和 ClickHouse 等 OLAP 数据库，晋升数仓的时效性能力，使其具备较优的实时数据分析能力。实时数据看板：这类场景是目前公司实时侧次要需要场景，例如“全民拼车日”订单和券花销实时大屏曲线展现，逆风车新开城当日分钟级订单侧外围指标数据展现，增长类我的项目资源投入和收益实时成果展现等。实时业务监控：滴滴出行大量外围业务指标须要具备实时监控能力，比方平安指标监控，财务指标监控，投诉进线指标监控等。实时数据接口服务：因为各业务线之间存在很多业务壁垒，导致数仓开发很难相熟公司内全副业务线，须要与各业务线相干部门在数据加工和数据获取方面进行合作，数仓通过提供实时数据接口服务的形式，向业务方提供数据反对。 2. 滴滴逆风车实时数仓建设举例在公司外部，咱们数据团队有幸与逆风车业务线深刻单干，在满足业务方实时数据需要的同时，不断完善实时数仓内容，通过屡次迭代，根本满足了逆风车业务方在实时侧的各类业务需要，初步建设起逆风车实时数仓，实现了整体数据分层，蕴含明细数据和汇总数据，对立了 DWD 层，升高了大数据资源耗费，进步了数据复用性，可对外输入丰盛的数据服务。 数仓具体架构如下图所示： 从数据架构图来看，逆风车实时数仓和对应的离线数仓有很多相似的中央。例如分层构造；比方 ODS 层，明细层，汇总层，乃至应用层，他们命名的模式可能都是一样的。但认真比拟不难发现，两者有很多区别： 与离线数仓相比，实时数仓的档次更少一些从目前建设离线数仓的教训来看，数仓的数据明细层内容会十分丰盛，解决明细数据外个别还会蕴含轻度汇总层的概念，另外离线数仓中应用层数据在数仓外部，但实时数仓中，app 应用层数据曾经落入利用零碎的存储介质中，能够把该层与数仓的表拆散。应用层少建设的益处：实时处理数据的时候，每建一个档次，数据必然会产生肯定的提早。汇总层少建的益处：在汇总统计的时候，往往为了容忍一部分数据的提早，可能会人为的制作一些提早来保证数据的精确。举例，在统计跨天相干的订单事件中的数据时，可能会等到 00:00:05 或者 00:00:10 再统计，确保 00:00 前的数据曾经全副承受到位了，再进行统计。所以，汇总层的档次太多的话，就会更大的减轻人为造成的数据提早。与离线数仓相比，实时数仓的数据源存储不同在建设离线数仓的时候，目前滴滴外部整个离线数仓都是建设在 Hive 表之上。然而，在建设实时数仓的时候，同一份表，会应用不同的形式进行存储。比方常见的状况下，明细数据或者汇总数据都会存在 Kafka 外面，然而像城市、渠道等维度信息须要借助 Hbase，MySQL 或者其余 KV 存储等数据库来进行存储。接下来，依据逆风车实时数仓架构图，对每一层建设做具体开展： 2.1 ODS 贴源层建设依据逆风车具体场景，目前逆风车数据源次要包含订单相干的 binlog 日志，冒泡和平安相干的 public 日志，流量相干的埋点日志等。这些数据局部已采集写入 Kafka 或 ddmq 等数据通道中，局部数据须要借助外部自研同步工具实现采集，最终基于逆风车数仓ods层建设标准分主题对立写入 Kafka 存储介质中。 命名标准：ODS 层实时数据源次要包含两种。 一种是在离线采集时曾经自动生产的 DDMQ 或者是 Kafka topic，这类型的数据命名形式为采集零碎主动生成标准为：cn-binlog-数据库名-数据库名 eg：cn-binlog-ihap_fangyuan-ihap_fangyuan一种是须要本人进行采集同步到 kafka topic 中，生产的topic命名标准同离线相似：ODS 层采纳：realtime_ods_binlog_{源零碎库/表名}/ods_log_{日志名} eg: realtime_ods_binlog_ihap_fangyuan2.2 DWD 明细层建设依据逆风车业务过程作为建模驱动，基于每个具体的业务过程特点，构建最细粒度的明细层事实表；联合逆风车分析师在离线侧的数据应用特点，将明细事实表的某些重要维度属性字段做适当冗余，实现宽表化解决，之后基于以后逆风车业务方对实时数据的需要重点，重点建设交易、财务、体验、平安、流量等几大模块；该层的数据来源于 ODS 层，通过大数据架构提供的 Stream SQL 实现 ETL 工作，对于 binlog 日志的解决次要进行简略的数据荡涤、解决数据漂移和数据乱序，以及可能对多个 ODS 表进行 Stream Join，对于流量日志次要是做通用的 ETL 解决和针对逆风车场景的数据过滤，实现非结构化数据的结构化解决和数据的分流；该层的数据除了存储在音讯队列 Kafka 中，通常也会把数据实时写入 Druid 数据库中，供查问明细数据和作为简略汇总数据的加工数据源。 ...

2020年，放慢利用数字技术，推动企业的数字化转型、迷信高效倒退简直已成为业界共识。人工智能、大数据、云计算、挪动互联网...每一场技术革新都曾被寄予厚望。在此背景下，企业与集体如何不被时代浪潮裹挟，寻找核心技术的将来价值？ 洞察先机，智见将来， Flink Forward Asia 2020 隆重开启！诚邀开源社区的各方力量与咱们一起，探讨新型数字化技术下的将来趋势，独特打造 2020 年大数据畛域的这场顶级盛会！ Flink Forward Asia 2020 简介联合 2020 年的非凡状况，Flink Forward Asia 将从线下转变为线上，以在线峰会的模式与大家见面。与以往相比，往年大会的次要特色在于： 1.在线直播互动，用户反馈更及时：大会将在线收集用户反馈，可实时理解用户需要、用户痛点及纳闷之处，造成良性反馈的闭环，讲师体验更敌对。 2.整合流传，影响范畴更宽泛：除主题分享的直播外，大会还将整合内容输入，以视频、文字、电子书、专题等多种形式组合流传，让优质内容造成长链路输入，扩充内容影响力，实现内容价值最大化。 3.不同维度打分，议题评比更多元：大会在去年重量级议题评比委员会阵容的根底上，邀请了13位来自国内外各个技术畛域的大神坐镇，从不同维度为投递的议题进行打分，保障内容的品质。 4.内容主题划分更精密，施展空间更短缺：除以往的企业实际、核心技术、实时数仓、开源生态外，还波及机器学习、云原生等热门畛域，可投递的议题类型更丰盛。 欢送投递议题：https://survey.alibabacloud.c... 超强阵容议题评比委员会往年大会议题评比委员会再度降级，邀请了13 位来自各畛域的行业首领及行业开拓者组成议题评比委员会，由阿里巴巴开源技术委员会负责人贾扬清负责主席，为大会内容提供业余保障。 议题征集邀请Flink Forward Asia 2020 将采纳议题标签的模式出现所有大会精彩内容，每个议题能够抉择1-2个标签。次要标签划分如下： 实时数仓机器学习行业实际核心技术开源生态云原生在 Flink Forward Asia 2020，您可与寰球开发者分享您的远见卓识，同各技术畛域顶级专家面对面交换，摸索数字化技术下的将来趋势。如果您对以上任意技术方向有积攒与洞察，欢送投递议题！每位嘉宾最多能够投递三个Topic，投递日期截止至 10 月 12 日。 ▼ 议题投递二维码 ▼ Flink Forward Aisa 2020，咱们不仅心愿为大家出现一场 Apache Flink 的技术盛宴，让大家理解 2020 年 Flink 在技术、利用、生态上的成绩、翻新与冲破；更心愿在大会中与社区合作伙伴、开源大数据各大新兴技术建设连贯、实现交融，独特定义和发明下一个对于数字化转型的新计划、新趋势。 期待您的分享！点击下方链接可间接投递议题～https://survey.alibabacloud.c...

作者：买蓉 · 美团点评高级技术专家整顿：赵阳（Flink 社区志愿者）校对：苗浩冲（Flink 社区志愿者） 本文将从数仓诞生的背景、数仓架构、离线与实时数仓的比照着手，综述数仓倒退演进，而后分享基于 Flink 实现典型 ETL 场景的几个计划。 1.实时数仓的相干概述1.1 实时数仓产生背景咱们先来回顾一下数据仓库的概念。 数据仓库的概念是于90年代由 Bill Inmon 提出, 过后的背景是传统的 OLTP 数据库无奈很好的反对长周期剖析决策场景，所以数据仓库概念的4个外围点，咱们要联合着 OLTP 数据库过后的状态来比照了解。 面向主题的：数据仓库的数据组织形式与 OLTP 面向事务处理不同。因为数据仓库是面向剖析决策的，所以数据常常按剖析场景或者是剖析对象等主题模式来组织。集成的：对于数据仓库来说，常常须要去汇合多个扩散的、异构的数据源，做一些数据荡涤等 ETL 解决，整合成一块数据仓库，OLTP 则不须要做相似的集成操作。绝对稳固的：OLTP 数据库个别都是面向业务的，它次要的作用是把以后的业务状态精准的反映进去，所以 OLTP 数据库须要反对大量的增、删、改的操作。然而对于数据仓库来说，只有是入仓存下来的数据，个别应用场景都是查问，因而数据是绝对稳固的。反映历史变动：数据仓库是反映历史变动的数据汇合，能够了解成它会将历史的一些数据的快照存下来。而对于 OLTP 数据库来说，只有反映过后的最新的状态就能够了。以上这4个点是数据仓库的一个外围的定义。咱们也能够看出对于实时数据仓库来说，传统数据仓库也就是离线数据仓库中的一些定义会被弱化，比如说在反映历史变动这一点。介绍完数据仓库的基本概念，简略说下数据仓库建模这块会用到一些经典的建模办法，次要有范式建模、维度建模和 Data Vault。在互联网大数据场景下，用的最多的是维度建模办法。 而后先看一下离线数仓的经典架构。如下图： 这个数仓架构次要是偏差互联网大数据的场景计划，由上图能够看出有三个外围环节。 第一个环节是数据源局部，个别互联网公司的数据源次要有两类：第1类是通过在客户端埋点上报，收集用户的行为日志，以及一些后端日志的日志类型数据源。对于埋点行为日志来说，个别会通过一个这样的流程，首先数据会上报到 Nginx 而后通过 Flume 收集，而后存储到 Kafka 这样的音讯队列，而后再由实时或者离线的一些拉取的工作，拉取到咱们的离线数据仓库 HDFS。第2类数据源是业务数据库，而对于业务数据库的话，个别会通过 Canal 收集它的 binlog，而后也是收集到音讯队列中，最终再由 Camus 拉取到 HDFS。这两局部数据源最终都会落地到 HDFS 中的 ODS 层，也叫贴源数据层，这层数据和原始数据源是保持一致的。 第二个环节是离线数据仓库，是图中蓝色的框展现的局部。能够看到它是一个分层的构造，其中的模型设计是根据维度建模思路。最底层是 ODS 层，这一层将数据放弃无信息损失的寄存在 HDFS，根本放弃原始的日志数据不变。在 ODS 层之上，个别会进行对立的数据荡涤、归一，就失去了 DWD 明细数据层。这一层也蕴含对立的维度数据。而后基于 DWD 明细数据层，咱们会依照一些剖析场景、剖析实体等去组织咱们的数据，组织成一些分主题的汇总数据层 DWS。在 DWS 之上，咱们会面向利用场景去做一些更贴近利用的 APP 利用数据层，这些数据应该是高度汇总的，并且可能间接导入到咱们的应用服务去应用。在两头的离线数据仓库的生产环节，个别都是采纳一些离线生产的架构引擎，比如说 MapReduce、Hive、Spark 等等，数据个别是存在 HDFS 上。 ...

作者：曾庆东，金地物业中级开发工程师，负责聚合营业平台实时计算开发及运维工作，从事过大数据开发，目前专一于apache flink实时计算，喜爱开源技术，喜爱分享。 01 我的项目背景自己目前参加的我的项目属于公司外面数据密集、计算密集的一个重要我的项目，须要提供高效且精确的OLAP服务，提供灵便且实时的报表。业务数据存储在MySQL中，通过主从复制同步到报表库。作为团体级公司，数据增长多而且快，呈现了多个千万级、亿级的大表。为了实现各个维度的各种简单的报表业务，有些千万级大表依然须要进行Join，计算规模十分惊人，常常不能及时响应申请。随着数据量的日益增长和实时剖析的需要越来越大，急需对系统进行流式计算、实时化革新。正是在这个背景下，开始了咱们与 Flink SQL CDC 的故事。 02 解决方案针对平台当初存在的问题，咱们提出了把报表的数据实时化的计划。该计划次要通过 Flink SQL CDC + Elasticsearch 实现。Flink SQL 反对 CDC 模式的数据同步，将 MySQL 中的全增量数据实时地采集、预计算、并同步到 Elasticsearch 中，Elasticsearch 作为咱们的实时报表和即席剖析引擎。我的项目整体架构图如下所示： 实时报表实现具体思路是，应用 Flink CDC 读取全量数据，全量数据同步实现后，Flink CDC 会无缝切换至 MySQL 的 binlog 位点持续生产增量的变更数据，且保障不会多生产一条也不会少生产一条。读取到的账单和订单的全增量数据会与产品表做关联补全信息，并做一些预聚合，而后将聚合后果输入到 Elasticsearch，前端页面只须要到 Elasticsearch 通过精准匹配（terms）查找数据，或者再应用 agg 做高维聚合统计失去多个服务中心的报表数据。 从整体架构中，能够看到，Flink SQL 及其 CDC 性能在咱们的架构中扮演着外围角色。咱们采纳 Flink SQL CDC，而不是 Canal + Kafka 的传统架构，次要起因还是因为其依赖组件少，保护成本低，开箱即用，上手容易。具体来说Flink SQL CDC 是一个集采集、计算、传输于一体的工具，其吸引咱们的长处有： ① 缩小保护的组件、简化实现链路；② 缩小端到端提早；③ 加重保护老本和开发成本；④ 反对Exactly Once的读取和计算（因为咱们是账务零碎，所以数据一致性十分重要）；⑤ 数据不落地，缩小存储老本；⑥ 反对全量和增量流式读取； 无关 Flink SQL CDC 的介绍和教程，能够观看 Apache Flink 社区公布的相干视频：https://www.bilibili.com/vide... ...

<section id="nice" data-tool="mdnice编辑器" data-website="https://www.mdnice.com" style="color: black; line-height: 1.6; word-spacing: 0px; letter-spacing: 0px; word-break: break-word; word-wrap: break-word; text-align: left; font-family: Optima-Regular, Optima, PingFangSC-light, PingFangTC-light, 'PingFang SC', Cambria, Cochin, Georgia, Times, 'Times New Roman', serif; font-size: 14px; padding: 10px;"><blockquote data-tool="mdnice编辑器" style="display: block; font-size: 0.9em; overflow: auto; overflow-scrolling: touch; color: #6a737d; padding-top: 10px; padding-bottom: 10px; padding-left: 20px; padding-right: 10px; margin-bottom: 20px; margin-top: 20px; border-left: 3px solid rgba(0, 0, 0, 0.65); border-right: 1px solid rgba(0, 0, 0, 0.65); background: rgb(249, 249, 249);"><p style="padding-top: 8px; padding-bottom: 8px; font-size: 14px; margin: 0px; color: black; line-height: 26px;">本文具体介绍了实时监控类指标的数据流转链路以及技术计划，大多数的实时监控类指标都可依照本文中的几种计划实现。</p></blockquote><h2 data-tool="mdnice编辑器" style="margin-top: 30px; margin-bottom: 15px; padding: 0px; font-size: 22px; text-align: center; position: relative; font-weight: bold; color: black; line-height: 1.1em; padding-top: 12px; padding-bottom: 12px; margin: 70px 30px 30px; border: 1px solid #000;"><span style="float: left; display: block; width: 90%; border-top: 1px solid #000; height: 1px; line-height: 1px; margin-left: -5px; margin-top: -17px;"> </span><span class="prefix" style="display: block; width: 3px; margin: 0 0 0 5%; height: 3px; line-height: 3px; overflow: hidden; background-color: #000; box-shadow: 3px 0 #000, ...

本文整顿自 Flink PMC member 云邪在 Apache Flink Meetup 2020 · 上海站的 talk，旨在帮忙用户疾速理解新版本 Table & SQL 在 Connectivity 和 Simplicity 等方面的优化及理论开发应用的最佳实际，次要分为以下四个局部： 简要回顾 Flink 1.8 ~ Flink 1.11 版本在 Apache 社区的发展趋势，其中国内开发者的积极参与和中文社区的蓬勃发展对 Flink 在社区和 GitHub 的活跃度做出了重要奉献。具体解读 Flink SQL 1.11 新性能，E.g. connectors 参数简化 + 动静 Table 参数缩小代码冗余，内置 connectors + LIKE 语法帮忙疾速测试，重构的 TableEnvironment 、TableSource / TableSink 接口晋升易用性，Hive Dialect + CDC 进一步反对流批一体。重点展现新版本对 Hive 数仓实时化的反对和 Flink SQL 引入 CDC 的数据同步最佳实际。简要解读 Flink SQL 1.12 将来布局。作者：伍翀（云邪），Apache Flink PMC member，阿里巴巴技术专家 ...

在线机器学习与离线相比，在模型更新的时效性，模型的迭代周期，业务试验成果等方面有更好的体现。所以将机器学习从离线迁徙到在线曾经成为晋升业务指标的一个无效的伎俩。 在线机器学习中，样本是要害的一环。本文将给大家具体的介绍微博是如何用 Flink 来实现在线样本生成的。 为何抉择 Flink 来做在线的样本生成？在线样本生成对样本的时效性和准确性都有极高的要求。同样对作业的稳定性及是否容灾也都有严格的指标要求。基于这个前提，咱们对目前较为风行的几种实时计算框架（Storm 0.10, Spark 2.11, Flink 1.10）进行了剖析比拟，论断如下： 因而，咱们决定应用 Flink 来作为在线样本生成的实时流计算框架。 如何实现？在线样本生成，简略形容一个业务场景：对用户的曝光数据和点击数据实时的做关联，关联后将数据输入到 Kafka 中，给上游的在线训练作业用。 首先咱们要确定两个数据流关联的工夫窗口。这一步个别倡议先离线对两个数据流的日志做关联，通过离线的形式对两份数据在不同的工夫范畴内做 join，来判断在线须要的工夫窗口。比方业务承受的最低关联比例是 85%，并且通过离线测试确认 20 分钟内两个数据流能够关联 85%的数据，那么就能够采纳 20 分钟作为工夫窗口。这里的关联比例和窗口工夫实际上是在准确性和实时性之间的一个 trade-off。 确定工夫窗口后，咱们并没有应用 Flink 的 time window 来实现多个数据流的 join，而是抉择采纳 union + timer 形式来实现。这里次要思考两点：第一、Flink 自带的 join 操作不反对多个数据流。第二、应用 timer+state 来实现，自定义水平更高，限度更少，也更不便。 接下来，咱们把样本生成过程细分为： ① 输出数据流个别咱们的数据源包含 Kafka，Trigger，MQ 等。Flink 须要从数据源中实时的读取日志。 ② 输出数据流的格式化和过滤读取日志后，对数据做格式化，并且过滤掉不须要的字段和数据。指定样本 join 的 key。例如：用户 id 和 内容 id 作 key。输入的数据格式个别为 tuple2（K,V）,K:参加 join 的 key。V：样本用到的字段。③ 输出数据流的 union应用 Flink 的 union 操作，将多个输出流叠加到一起，造成一个 DataStream。为每个输出流指定一个能够辨别的别名或者减少一个能够辨别的字段。④ 输出数据流的聚合：keyby 操作对 join 的 key 做 keyby 操作。接上例，示意依照用户 id 和内容 id 对多个数据流做 join。如果 key 存在数据歪斜的状况，倡议对 key 加随机数后先聚合，去掉随机数后再次聚合。⑤ 数据存储 state + timer定义一个Value State。keyby后的process办法中，咱们会重写processElement办法，在processElement办法中判断，如果value state为空，则new 一个新的state，并将数据写到value state中，并且为这条数据注册一个timer（timer会由Flink按key+timestamp主动去重），另外此处咱们应用的是ProcessingTime（示意onTimer()在零碎工夫戳达到Timer设定的工夫戳时触发）。如果不为空则依照拼接的策略，更新曾经存在的后果。比方：工夫窗口内 用户id1，内容id1的第一条日志数据没有点击行为，则这个字段为0，第二条点击数据进入后，将这个字段更新为1。当然除了更新操作，还有计数、累加、均值等各种操作。如何在process里辨别数据是来自曝光还是点击呢，应用下面步骤③定义的别名。重写onTimer办法，在onTimer办法中次要是定义定时器触发时执行的逻辑：从value state里获取到存入的数据，并将数据输入。而后执行state.clear。样本从窗口输入的条件有2个：第一，timer到期。第二，业务须要的样本都拼接上了。此处参考伪代码： ...

简介： 2020年，放慢利用数字技术，推动企业的数字化转型、迷信高效倒退简直已成为业界共识。人工智能、大数据、云计算、挪动互联网...每一场技术革新都曾被寄予厚望。在此背景下，企业与集体如何不被时代浪潮裹挟，寻找核心技术的将来价值？ 2020年，放慢利用数字技术，推动企业的数字化转型、迷信高效倒退简直已成为业界共识。人工智能、大数据、云计算、挪动互联网...每一场技术革新都曾被寄予厚望。在此背景下，企业与集体如何不被时代浪潮裹挟，寻找核心技术的将来价值？ 洞察先机，智见将来， Flink Forward Asia 2020 隆重开启！诚邀开源社区的各方力量与咱们一起，探讨新型数字化技术下的将来趋势，独特打造 2020 年大数据畛域的这场顶级盛会！ 01 Flink Forward Asia 2020 简介联合 2020 年的非凡状况，Flink Forward Asia 将从线下转变为线上，以在线峰会的模式与大家见面。与以往相比，往年大会的次要特色在于： 在线直播互动，用户反馈更及时：大会将在线收集用户反馈，可实时理解用户需要、用户痛点及纳闷之处，造成良性反馈的闭环，讲师体验更敌对。整合流传，影响范畴更宽泛：除主题分享的直播外，大会还将整合内容输入，以视频、文字、电子书、专题等多种形式组合流传，让优质内容造成长链路输入，扩充内容影响力，实现内容价值最大化。不同维度打分，议题评比更多元：大会在去年重量级议题评比委员会阵容的根底上，邀请了13位来自国内外各个技术畛域的大神坐镇，从不同维度为投递的议题进行打分，保障内容的品质。内容主题划分更精密，施展空间更短缺：除以往的企业实际、核心技术、实时数仓、开源生态外，还波及机器学习、云原生等热门畛域，可投递的议题类型更丰盛。欢送投递议题： https://survey.alibabacloud.com/apps/zhiliao/POBlm3tWx02 超强阵容议题评比委员会往年大会议题评比委员会再度降级，邀请了 14 位来自各畛域的行业首领及行业开拓者组成议题评比委员会，由阿里巴巴开源技术委员会负责人贾扬清负责主席，为大会内容提供业余保障。 03 议题征集邀请Flink Forward Asia 2020 将采纳议题标签的模式出现所有大会精彩内容，每个议题能够抉择1-2个标签。次要标签划分如下： 实时数仓机器学习行业实际核心技术开源生态云原生在 Flink Forward Asia 2020，您可与寰球开发者分享您的远见卓识，同各技术畛域顶级专家面对面交换，摸索数字化技术下的将来趋势。如果您对以上任意技术方向有积攒与洞察，欢送投递议题！每位嘉宾最多能够投递三个Topic，投递日期截止至 10 月 12 日。 ▼ 议题投递二维码 ▼ Flink Forward Aisa 2020，咱们不仅心愿为大家出现一场 Apache Flink 的技术盛宴，让大家理解 2020 年 Flink 在技术、利用、生态上的成绩、翻新与冲破；更心愿在大会中与社区合作伙伴、开源大数据各大新兴技术建设连贯、实现交融，独特定义和发明下一个对于数字化转型的新计划、新趋势。

用过 Zeppelin 的人应该比拟相熟 Zeppelin 的 UI，因为 Zeppelin 的次要应用场景都是交互式，用户须要手动来操作。那除了这种手动的形式，还有其余的形式吗？如果你不想用 Zeppelin UI，但又想用 Zeppelin 提交和治理大数据作业 （比方 Flink Job）的能力该怎么办？或者是你在 Zeppelin 里写好了代码，想定时调度起来，或者集成到其余零碎里，该怎么办？ 如果你有这样的诉求，那么 Zeppelin Client API （SDK）就是你所须要的货色。 Zeppelin 简介对于不相熟 Zeppelin 的人，能够用一句话来解释 Zeppelin：大数据引擎的入口，交互式大数据分析平台底座。Zeppelin 最大的特点是连贯多种引擎，具备可插拔式，上面这张图例举了一些罕用的引擎，当然 Zeppelin 还反对其余很多引擎，这里就不一一例举。 尽管 Zeppelin 有 Rest API，然而 Zeppelin 的 Rest API 太多，对于很多不相熟 Zeppelin 的人来说应用 Rest API 门槛太高，所以 Zeppelin 专门开发了一个 Client API （SDK），不便大家做集成。Zeppelin Client API （SDK）分为 2 个层面的的货色（接下来会一一具体介绍）： Zeppelin Client API （Low Level API)Session API （High Level API)Zeppelin Client API （Low Level API）Zeppelin Client API 能够在 Note 和 Paragraph 的粒度进行操作。你能够先在 notebook 里写好代码 (比方开发阶段在 notebook 里写代码，做测试），而后用 Low Level API 用编程的形式把 Job 跑起来（比方生产阶段把作业定时调度起来）。Zeppelin Client API 最重要的 class 是 ZeppelinClient，也是 Zeppelin Client API 的入口。上面例举几个重要的接口（这些 API 都比拟直观，我就不多做解释了）。 ...

Flink SQL 的 FileSystem Connector 为了与 Flink-Hive 集成的大环境适配，做了很多改良，而其中最为显著的就是分区提交（partition commit）机制。 本文先通过源码简略过一下分区提交机制的两个因素——即触发（trigger）和策略（policy）的实现，而后用合并小文件的实例说一下自定义分区提交策略的办法。 PartitionCommitTrigger在最新的 Flink SQL 中，FileSystem Connector 原生反对数据分区，并且写入时采纳规范 Hive 分区格局，如下所示。 path└── datetime=2019-08-25 └── hour=11 ├── part-0.parquet ├── part-1.parquet └── hour=12 ├── part-0.parquet└── datetime=2019-08-26 └── hour=6 ├── part-0.parquet那么，曾经写入的分区数据何时能力对上游可见呢？这就波及到如何触发分区提交的问题。依据官网文档，触发参数有以下两个： sink.partition-commit.trigger：可选 process-time（依据解决工夫触发）和 partition-time（依据从事件工夫中提取的分区工夫触发）。sink.partition-commit.delay：分区提交的时延。如果 trigger 是 process-time，则以分区创立时的零碎工夫戳为准，通过此时延后提交；如果 trigger 是 partition-time，则以分区创立时自身携带的事件工夫戳为准，当水印工夫戳通过此时延后提交。可见，process-time trigger 无奈应答处理过程中呈现的抖动，一旦数据早退或者程序失败重启，数据就不能依照事件工夫被纳入正确的分区了。所以在理论利用中，咱们简直总是选用 partition-time trigger，并本人生成水印。当然咱们也须要通过 partition.time-extractor.*一系列参数来指定抽取分区工夫的规定（PartitionTimeExtractor），官网文档说得很分明，不再赘述。在源码中，PartitionCommitTrigger 的类图如下。 上面以分区工夫触发的 PartitionTimeCommitTrigger 为例，简略看看它的思路。间接上该类的残缺代码。 public class PartitionTimeCommitTigger implements PartitionCommitTrigger { private static final ListStateDescriptor<List<String>> PENDING_PARTITIONS_STATE_DESC = new ListStateDescriptor<>( "pending-partitions", new ListSerializer<>(StringSerializer.INSTANCE)); private static final ListStateDescriptor<Map<Long, Long>> WATERMARKS_STATE_DESC = new ListStateDescriptor<>( "checkpoint-id-to-watermark", new MapSerializer<>(LongSerializer.INSTANCE, LongSerializer.INSTANCE)); private final ListState<List<String>> pendingPartitionsState; private final Set<String> pendingPartitions; private final ListState<Map<Long, Long>> watermarksState; private final TreeMap<Long, Long> watermarks; private final PartitionTimeExtractor extractor; private final long commitDelay; private final List<String> partitionKeys; public PartitionTimeCommitTigger( boolean isRestored, OperatorStateStore stateStore, Configuration conf, ClassLoader cl, List<String> partitionKeys) throws Exception { this.pendingPartitionsState = stateStore.getListState(PENDING_PARTITIONS_STATE_DESC); this.pendingPartitions = new HashSet<>(); if (isRestored) { pendingPartitions.addAll(pendingPartitionsState.get().iterator().next()); } this.partitionKeys = partitionKeys; this.commitDelay = conf.get(SINK_PARTITION_COMMIT_DELAY).toMillis(); this.extractor = PartitionTimeExtractor.create( cl, conf.get(PARTITION_TIME_EXTRACTOR_KIND), conf.get(PARTITION_TIME_EXTRACTOR_CLASS), conf.get(PARTITION_TIME_EXTRACTOR_TIMESTAMP_PATTERN)); this.watermarksState = stateStore.getListState(WATERMARKS_STATE_DESC); this.watermarks = new TreeMap<>(); if (isRestored) { watermarks.putAll(watermarksState.get().iterator().next()); } } @Override public void addPartition(String partition) { if (!StringUtils.isNullOrWhitespaceOnly(partition)) { this.pendingPartitions.add(partition); } } @Override public List<String> committablePartitions(long checkpointId) { if (!watermarks.containsKey(checkpointId)) { throw new IllegalArgumentException(String.format( "Checkpoint(%d) has not been snapshot. The watermark information is: %s.", checkpointId, watermarks)); } long watermark = watermarks.get(checkpointId); watermarks.headMap(checkpointId, true).clear(); List<String> needCommit = new ArrayList<>(); Iterator<String> iter = pendingPartitions.iterator(); while (iter.hasNext()) { String partition = iter.next(); LocalDateTime partTime = extractor.extract( partitionKeys, extractPartitionValues(new Path(partition))); if (watermark > toMills(partTime) + commitDelay) { needCommit.add(partition); iter.remove(); } } return needCommit; } @Override public void snapshotState(long checkpointId, long watermark) throws Exception { pendingPartitionsState.clear(); pendingPartitionsState.add(new ArrayList<>(pendingPartitions)); watermarks.put(checkpointId, watermark); watermarksState.clear(); watermarksState.add(new HashMap<>(watermarks)); } @Override public List<String> endInput() { ArrayList<String> partitions = new ArrayList<>(pendingPartitions); pendingPartitions.clear(); return partitions; }}留神到该类中保护了两对必要的信息： ...

用户行为日志剖析是实时数据处理很常见的一个利用场景，比方常见的PV、UV统计。本文将基于Flink从0到1构建一个用户行为日志剖析零碎，包含架构设计与代码实现。本文分享将残缺出现日志剖析零碎的数据处理链路，通过本文，你能够理解到： 基于discuz搭建一个论坛平台Flume日志收集零碎应用形式Apache日志格局剖析Flume与Kafka集成日志剖析解决流程架构设计与残缺的代码实现我的项目简介本文分享会从0到1基于Flink实现一个实时的用户行为日志剖析零碎，根本架构图如下： 首先会先搭建一个论坛平台，对论坛平台产生的用户点击日志进行剖析。而后应用Flume日志收集系统对产生的Apache日志进行收集，并将其推送到Kafka。接着咱们应用Flink对日志进行实时剖析解决，将解决之后的后果写入MySQL供前端利用可视化展现。本文次要实现以下三个指标计算： 统计热门板块，即访问量最高的板块统计热门文章，即访问量最高的帖子文章统计不同客户端对版块和文章的总访问量基于discuz搭建一个论坛平台装置XAMPP下载wget https://www.apachefriends.org/xampp-files/5.6.33/xampp-linux-x64-5.6.33-0-installer.run装置# 赋予文件执行权限chmod u+x xampp-linux-x64-5.6.33-0-installer.run# 运行安装文件./xampp-linux-x64-5.6.33-0-installer.run配置环境变量将以下内容退出到 ~/.bash_profile export XAMPP=/opt/lampp/export PATH=$PATH:$XAMPP:$XAMPP/bin刷新环境变量source ~/.bash_profile启动XAMPPxampp restartMySQL的root用户明码和权限批改#批改root用户明码为123qwe update mysql.user set password=PASSWORD('123qwe') where user='root'; flush privileges; #赋予root用户近程登录权限 grant all privileges on *.* to 'root'@'%' identified by '123qwe' with grant option;flush privileges; 装置Discuz下载discuzwget http://download.comsenz.com/DiscuzX/3.2/Discuz_X3.2_SC_UTF8.zip装置#删除原有的web利用 rm -rf /opt/lampp/htdocs/*unzip Discuz_X3.2_SC_UTF8.zip –d /opt/lampp/htdocs/cd /opt/lampp/htdocs/ mv upload/* #批改目录权限 chmod 777 -R /opt/lampp/htdocs/config/chmod 777 -R /opt/lampp/htdocs/data/chmod 777 -R /opt/lampp/htdocs/uc_client/ chmod 777 -R /opt/lampp/htdocs/uc_server/ Discuz基本操作自定义版块进入discuz后盾：http://kms-4/admin.php点击顶部的论坛菜单依照页面提醒创立所需版本，能够创立父子版块 Discuz帖子/版块存储数据库表介-- 登录ultrax数据库mysql -uroot -p123 ultrax -- 查看蕴含帖子id及题目对应关系的表-- tid, subject（文章id、题目）select tid, subject from pre_forum_post limit 10;-- fid, name（版块id、题目）select fid, name from pre_forum_forum limit 40;当咱们在各个板块增加帖子之后，如下所示： ...

FlinkCommodityRecommendationSystemRecs FlinkCommodityRecommendationSystem(基于 Flink 的商品举荐零碎) 1. 前言零碎取名为 Recs，灵感源于 Recommendation System。logo 应用在线 logo 网站制作。 作者开发该我的项目，是为了学习 Flink 以及相干大数据中间件。出于展现目标，应用 Springboot + Vue 开发了配套的 web。 作者有过 python + django + JavaScript 的 web 开发的经验，思考到我的项目应用 java 开发，为了技术栈的对立，现学了 Springboot 框架以及 Vue。 本我的项目借鉴了 ECommerceRecommendSystem 开源学习我的项目，前端局部借鉴较多，在作者搭建好的框架根底上进行优化。批改了 ui 以及局部 bug，并且新增局部性能。 通过本我的项目的开发锤炼，作者对大数据相干的技术有了较为零碎的了解，播种较大。在开发过程中，遇到过很多问题，但都逐个攻克了。作者的教训是，解决问题最好的方法就是浏览官网文档和踊跃应用 Google。 最初，相干的技术都是现学现用，常识比拟全面，因而本我的项目存在很多待优化的中央，欢送大家 issue，一起学习，一起提高。 2. 我的项目简介2.1 Recs 零碎架构 零碎次要工作流程： 用户登录/注册零碎。用户对商品进行评分。评分数据通过 Kafka 发送到举荐模块的实时举荐工作中。零碎执行实时举荐工作，并且将数据存储到 hbase 的 rating 和 userProduct 表中。实时工作包含：实时 topN 以及 基于用户行为举荐。实时 topN 将计算结果存储到 hbase 的 onlineHot 表中，基于用户行为举荐将计算结果存储到 hbase 的表 onlineRecommend 中。web 端通过查问 hbase 获取相干模块所需数据并展现后果。2.2 首页 ...

最近在加入第二届 Apache Flink 极客挑战赛，较量要求各队利用大数据 + AI 技术来帮忙解决疫情防控的挑战，官网提供的计算框架是 Apache Flink + Analytics Zoo。 因为本次大赛既要用到大数据技术，又要用到 AI 技术，这使得只有繁多技术背景的同学在搭建本地调试环境时遇到了不少问题。所以我把本人配置本地环境的流程和须要留神的中央记录下来，以供各位参赛同学参考，心愿大家能将本人的精力更多集中在算法开发和迭代上。 注：心愿大家在参考环境搭建流程时，不要间接照搬照抄；多了解其中的原理，针对本人的机器，要能做出一些细节上的调整。环境搭建Linux 18.04官网要求的操作系统是 Linux 18.04，我本地配置环境用的是 Linux 16.04，亲测也能胜利。 注：千万不要在 macOS 或者 windows 上间接配置环境，因为本次较量依赖的 pyproxima 只提供了 linux 的安装包。如果只有 macOS 或者 windows，能够搭一个 linux 18.04 的虚拟机，或者应用 docker。Java 1.8+倡议装置 java1.8 (java 8)。 java 1.8+ 包含 java 8，java 9，······，java 14，我开始装的是 java 14，呈现了 kafka 2.3 不能启动等异样，最初换成了 java 8。 从 java 官网下载 jdk-8u261-linux-x64.tar.gz解压下面下载的压缩包：tar xzf jdk-8u261-linux-x64.tar.gz配置环境变量：export JAVA_HOME=/data/gaohongjie1/usr/local/jdk1.8.0_261 # jdk-8u261-linux-x64.tar.gz 解压后的门路export PATH=$JAVA_HOME/bin:$PATH运行 java -version 测试是否装置胜利 ...

现如今想浏览 HashMap 源码实际上比较简单，因为网上一大堆博客去剖析 HashMap 和 ConcurrentHashMap。而本文是全网首篇详细分析 CopyOnWriteStateTable 源码的博客，浏览简单汇合类源码的过程是相当有挑战的，笔者在刚开始浏览也遇到很多疑难，最初一一解决了。本文有一万两千多字加不少的配图，实属不易。具体浏览完本文，无论是针对面试还是开阔视野肯定会对大家有帮忙的。 具体浏览完本文，无论是针对面试还是开阔视野肯定会对大家有帮忙的。 申明：笔者的源码剖析都是基于 flink-1.9.0 release 分支，其实浏览源码不必十分在意版本的问题，各版本的次要流程根本都是相似的。如果相熟了某个版本的源码，之后新版本有变动，咱们重点看一下变动之处即可。本文次要讲述 Flink 中 CopyOnWriteStateTable 相干的常识，当应用 MemoryStateBackend 和 FsStateBackend 时，默认状况下会将状态数据保留到 CopyOnWriteStateTable 中。CopyOnWriteStateTable 中保留多个 KeyGroup 的状态，每个 KeyGroup 对应一个 CopyOnWriteStateMap。 CopyOnWriteStateMap 是一个相似于 HashMap 的构造，但反对了两个十分有意思的性能： 1、hash 构造为了保障读写数据的高性能，都须要有扩容策略，CopyOnWriteStateMap 的扩容策略是一个渐进式 rehash 的策略，即：不是一下子将数据全迁徙的新的 hash 表，而是缓缓去迁徙数据到新的 hash 表中。2、Checkpoint 时 CopyOnWriteStateMap 反对异步快照，即：Checkpoint 时能够在做快照的同时，依然对 CopyOnWriteStateMap 中数据进行批改。问题来了：数据批改了，怎么保障快照数据的准确性呢？理解 Redis 的同学应该晓得 Redis 也是一个大的 hash 构造，扩容策略也是渐进式 rehash。Redis 的 RDB 在长久化数据的过程中同时也是对外服务的，对外服务意味着数据可能被批改，那么 RDB 如何保障长久化好的数据肯定是正确的呢？ 举个例子：17 点00分00秒 RDB 开始长久化数据，过了 1 秒 Redis 中某条数据被批改了，过了一分钟 RDB 才长久化完结。RDB 预期的长久化后果应该是 17 点00分00秒那一刻 Redis 的残缺快照，请问长久化过程中那些批改操作是否会影响 Redis 的快照。答：当然能够做到不影响。 ...

实时数仓次要是为了解决传统数仓数据时效性低的问题，实时数仓通常会用在实时的OLAP剖析、实时的数据看板、业务指标实时监控等场景。尽管对于实时数仓的架构及技术选型与传统的离线数仓会存在差别，然而对于数仓建设的根本方法论是统一的。本文会分享基于Flink SQL从0到1搭建一个实时数仓的demo，波及数据采集、存储、计算、可视化整个解决流程。通过本文你能够理解到： 实时数仓的根本架构实时数仓的数据处理流程Flink1.11的SQL新个性Flink1.11存在的bug残缺的操作案例今人学识无遗力，少壮时间老始成。纸上得来终觉浅，绝知此事要躬行。 案例简介本文会以电商业务为例，展现实时数仓的数据处理流程。另外，本文旨在阐明实时数仓的构建流程，所以不会波及太简单的数据计算。为了保障案例的可操作性和完整性，本文会给出具体的操作步骤。为了不便演示，本文的所有操作都是在Flink SQL Cli中实现的。 架构设计具体的架构设计如图所示：首先通过canal解析MySQL的binlog日志，将数据存储在Kafka中。而后应用Flink SQL对原始数据进行荡涤关联，并将解决之后的明细宽表写入kafka中。维表数据存储在MySQL中，通过Flink SQL对明细宽表与维表进行JOIN，将聚合后的数据写入MySQL，最初通过FineBI进行可视化展现。 业务数据筹备订单表（order_info）CREATE TABLE `order_info` ( `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT '编号', `consignee` varchar(100) DEFAULT NULL COMMENT '收货人', `consignee_tel` varchar(20) DEFAULT NULL COMMENT '收件人电话', `total_amount` decimal(10,2) DEFAULT NULL COMMENT '总金额', `order_status` varchar(20) DEFAULT NULL COMMENT '订单状态', `user_id` bigint(20) DEFAULT NULL COMMENT '用户id', `payment_way` varchar(20) DEFAULT NULL COMMENT '付款形式', `delivery_address` varchar(1000) DEFAULT NULL COMMENT '送货地址', `order_comment` varchar(200) DEFAULT NULL COMMENT '订单备注', `out_trade_no` varchar(50) DEFAULT NULL COMMENT '订单交易编号（第三方领取用)', `trade_body` varchar(200) DEFAULT NULL COMMENT '订单形容(第三方领取用)', `create_time` datetime DEFAULT NULL COMMENT '创立工夫', `operate_time` datetime DEFAULT NULL COMMENT '操作工夫', `expire_time` datetime DEFAULT NULL COMMENT '生效工夫', `tracking_no` varchar(100) DEFAULT NULL COMMENT '物流单编号', `parent_order_id` bigint(20) DEFAULT NULL COMMENT '父订单编号', `img_url` varchar(200) DEFAULT NULL COMMENT '图片门路', `province_id` int(20) DEFAULT NULL COMMENT '地区', PRIMARY KEY (`id`)) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8 COMMENT='订单表';订单详情表（order_detail）CREATE TABLE `order_detail` ( `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT '编号', `order_id` bigint(20) DEFAULT NULL COMMENT '订单编号', `sku_id` bigint(20) DEFAULT NULL COMMENT 'sku_id', `sku_name` varchar(200) DEFAULT NULL COMMENT 'sku名称（冗余)', `img_url` varchar(200) DEFAULT NULL COMMENT '图片名称（冗余)', `order_price` decimal(10,2) DEFAULT NULL COMMENT '购买价格(下单时sku价格）', `sku_num` varchar(200) DEFAULT NULL COMMENT '购买个数', `create_time` datetime DEFAULT NULL COMMENT '创立工夫', PRIMARY KEY (`id`)) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8 COMMENT='订单详情表';商品表（sku_info）CREATE TABLE `sku_info` ( `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT 'skuid(itemID)', `spu_id` bigint(20) DEFAULT NULL COMMENT 'spuid', `price` decimal(10,0) DEFAULT NULL COMMENT '价格', `sku_name` varchar(200) DEFAULT NULL COMMENT 'sku名称', `sku_desc` varchar(2000) DEFAULT NULL COMMENT '商品规格形容', `weight` decimal(10,2) DEFAULT NULL COMMENT '分量', `tm_id` bigint(20) DEFAULT NULL COMMENT '品牌(冗余)', `category3_id` bigint(20) DEFAULT NULL COMMENT '三级分类id（冗余)', `sku_default_img` varchar(200) DEFAULT NULL COMMENT '默认显示图片(冗余)', `create_time` datetime DEFAULT NULL COMMENT '创立工夫', PRIMARY KEY (`id`)) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8 COMMENT='商品表';商品一级类目表（base_category1）CREATE TABLE `base_category1` ( `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT '编号', `name` varchar(10) NOT NULL COMMENT '分类名称', PRIMARY KEY (`id`)) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8 COMMENT='一级分类表';商品二级类目表（base_category2）CREATE TABLE `base_category2` ( `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT '编号', `name` varchar(200) NOT NULL COMMENT '二级分类名称', `category1_id` bigint(20) DEFAULT NULL COMMENT '一级分类编号', PRIMARY KEY (`id`)) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8 COMMENT='二级分类表';商品三级类目表（base_category3）CREATE TABLE `base_category3` ( `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT '编号', `name` varchar(200) NOT NULL COMMENT '三级分类名称', `category2_id` bigint(20) DEFAULT NULL COMMENT '二级分类编号', PRIMARY KEY (`id`)) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8 COMMENT='三级分类表';省份表（base_province）CREATE TABLE `base_province` ( `id` int(20) DEFAULT NULL COMMENT 'id', `name` varchar(20) DEFAULT NULL COMMENT '省名称', `region_id` int(20) DEFAULT NULL COMMENT '大区id', `area_code` varchar(20) DEFAULT NULL COMMENT '行政区位码') ENGINE=InnoDB DEFAULT CHARSET=utf8;区域表（base_region）CREATE TABLE `base_region` ( `id` int(20) NOT NULL COMMENT '大区id', `region_name` varchar(20) DEFAULT NULL COMMENT '大区名称', PRIMARY KEY (`id`)) ENGINE=InnoDB DEFAULT CHARSET=utf8;留神：以上的建表语句是在MySQL中实现的，残缺的建表及模仿数据生成脚本见：链接：https://pan.baidu.com/s/1fcMg... 提取码：zuqw ...

实时数仓次要是为了解决传统数仓数据时效性低的问题，实时数仓通常会用在实时的OLAP剖析、实时的数据看板、业务指标实时监控等场景。尽管对于实时数仓的架构及技术选型与传统的离线数仓会存在差别，然而对于数仓建设的根本方法论是统一的。本文会分享基于Flink SQL从0到1搭建一个实时数仓的demo，波及数据采集、存储、计算、可视化整个解决流程。通过本文你能够理解到： 实时数仓的根本架构实时数仓的数据处理流程Flink1.11的SQL新个性Flink1.11存在的bug残缺的操作案例今人学识无遗力，少壮时间老始成。纸上得来终觉浅，绝知此事要躬行。 案例简介本文会以电商业务为例，展现实时数仓的数据处理流程。另外，本文旨在阐明实时数仓的构建流程，所以不会波及太简单的数据计算。为了保障案例的可操作性和完整性，本文会给出具体的操作步骤。为了不便演示，本文的所有操作都是在Flink SQL Cli中实现的。 架构设计具体的架构设计如图所示：首先通过canal解析MySQL的binlog日志，将数据存储在Kafka中。而后应用Flink SQL对原始数据进行荡涤关联，并将解决之后的明细宽表写入kafka中。维表数据存储在MySQL中，通过Flink SQL对明细宽表与维表进行JOIN，将聚合后的数据写入MySQL，最初通过FineBI进行可视化展现。 业务数据筹备订单表（order_info）CREATE TABLE `order_info` ( `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT '编号', `consignee` varchar(100) DEFAULT NULL COMMENT '收货人', `consignee_tel` varchar(20) DEFAULT NULL COMMENT '收件人电话', `total_amount` decimal(10,2) DEFAULT NULL COMMENT '总金额', `order_status` varchar(20) DEFAULT NULL COMMENT '订单状态', `user_id` bigint(20) DEFAULT NULL COMMENT '用户id', `payment_way` varchar(20) DEFAULT NULL COMMENT '付款形式', `delivery_address` varchar(1000) DEFAULT NULL COMMENT '送货地址', `order_comment` varchar(200) DEFAULT NULL COMMENT '订单备注', `out_trade_no` varchar(50) DEFAULT NULL COMMENT '订单交易编号（第三方领取用)', `trade_body` varchar(200) DEFAULT NULL COMMENT '订单形容(第三方领取用)', `create_time` datetime DEFAULT NULL COMMENT '创立工夫', `operate_time` datetime DEFAULT NULL COMMENT '操作工夫', `expire_time` datetime DEFAULT NULL COMMENT '生效工夫', `tracking_no` varchar(100) DEFAULT NULL COMMENT '物流单编号', `parent_order_id` bigint(20) DEFAULT NULL COMMENT '父订单编号', `img_url` varchar(200) DEFAULT NULL COMMENT '图片门路', `province_id` int(20) DEFAULT NULL COMMENT '地区', PRIMARY KEY (`id`)) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8 COMMENT='订单表';订单详情表（order_detail）CREATE TABLE `order_detail` ( `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT '编号', `order_id` bigint(20) DEFAULT NULL COMMENT '订单编号', `sku_id` bigint(20) DEFAULT NULL COMMENT 'sku_id', `sku_name` varchar(200) DEFAULT NULL COMMENT 'sku名称（冗余)', `img_url` varchar(200) DEFAULT NULL COMMENT '图片名称（冗余)', `order_price` decimal(10,2) DEFAULT NULL COMMENT '购买价格(下单时sku价格）', `sku_num` varchar(200) DEFAULT NULL COMMENT '购买个数', `create_time` datetime DEFAULT NULL COMMENT '创立工夫', PRIMARY KEY (`id`)) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8 COMMENT='订单详情表';商品表（sku_info）CREATE TABLE `sku_info` ( `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT 'skuid(itemID)', `spu_id` bigint(20) DEFAULT NULL COMMENT 'spuid', `price` decimal(10,0) DEFAULT NULL COMMENT '价格', `sku_name` varchar(200) DEFAULT NULL COMMENT 'sku名称', `sku_desc` varchar(2000) DEFAULT NULL COMMENT '商品规格形容', `weight` decimal(10,2) DEFAULT NULL COMMENT '分量', `tm_id` bigint(20) DEFAULT NULL COMMENT '品牌(冗余)', `category3_id` bigint(20) DEFAULT NULL COMMENT '三级分类id（冗余)', `sku_default_img` varchar(200) DEFAULT NULL COMMENT '默认显示图片(冗余)', `create_time` datetime DEFAULT NULL COMMENT '创立工夫', PRIMARY KEY (`id`)) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8 COMMENT='商品表';商品一级类目表（base_category1）CREATE TABLE `base_category1` ( `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT '编号', `name` varchar(10) NOT NULL COMMENT '分类名称', PRIMARY KEY (`id`)) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8 COMMENT='一级分类表';商品二级类目表（base_category2）CREATE TABLE `base_category2` ( `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT '编号', `name` varchar(200) NOT NULL COMMENT '二级分类名称', `category1_id` bigint(20) DEFAULT NULL COMMENT '一级分类编号', PRIMARY KEY (`id`)) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8 COMMENT='二级分类表';商品三级类目表（base_category3）CREATE TABLE `base_category3` ( `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT '编号', `name` varchar(200) NOT NULL COMMENT '三级分类名称', `category2_id` bigint(20) DEFAULT NULL COMMENT '二级分类编号', PRIMARY KEY (`id`)) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8 COMMENT='三级分类表';省份表（base_province）CREATE TABLE `base_province` ( `id` int(20) DEFAULT NULL COMMENT 'id', `name` varchar(20) DEFAULT NULL COMMENT '省名称', `region_id` int(20) DEFAULT NULL COMMENT '大区id', `area_code` varchar(20) DEFAULT NULL COMMENT '行政区位码') ENGINE=InnoDB DEFAULT CHARSET=utf8;区域表（base_region）CREATE TABLE `base_region` ( `id` int(20) NOT NULL COMMENT '大区id', `region_name` varchar(20) DEFAULT NULL COMMENT '大区名称', PRIMARY KEY (`id`)) ENGINE=InnoDB DEFAULT CHARSET=utf8;留神：以上的建表语句是在MySQL中实现的，残缺的建表及模仿数据生成脚本见：链接：https://pan.baidu.com/s/1fcMg... 提取码：zuqw ...

Flink 中的利用部署：以后状态与新利用模式 公布文章Flink 中的利用部署：以后状态与新利用模式同步滚动：开 作为古代企业的重要工具，流解决和实时剖析这类工具逐步衰亡，越来越多的企业以 Apache Flink 为外围构建平台，并将其作为服务在外部提供。在最新举办的 Flink Forward 会议中， Uber、 Netflix 和阿里巴巴等公司的许多相干主题演讲进一步阐明了这一趋势。 泛滥平台旨在通过加重最终用户的所有经营累赘来简化外部的 Application （利用）提交。为了提交 Flink 应用程序，这些平台通常只公开一个集中式或低并行度端点（例如 Web 前端）用于利用提交，咱们将调用 Deployer（部署器）。 平台开发人员和保护人员常常提到的阻碍之一是，Deployer 可能是一个很难配置的大量资源耗费者。如果依照均匀负载进行配置，可能会导致 Deployer 服务被部署申请吞没（在最坏的状况下，短时间内对所有生产应用程序都是如此），而依照最高负载进行布局的话，又会带来不必要的老本。依据这一察看后果，Flink 1.11 引入了 Application 模式（利用模式）作为部署选项，它容许一个轻量级、更可伸缩性的利用提交过程，从而使应用程序部署负载更平均地散布在集群的各个节点上。 为了了解这个问题以及理解 Application 模式如何解决该问题，咱们首先简要概述 Flink 中应用程序执行的以后状态，而后再论述部署模式引入的架构变动以及如何利用它们。 Flink 中的应用程序执行在 Flink 中执行应用程序次要波及三个实体：Client（客户端）、JobManager（作业管理器）和 TaskManager（工作管理器）。Client 负责将利用提交给集群，JobManager 负责执行期间必要的 bookkeeping，而 TaskManager 则负责理论的计算。更多细节请参考 Flink 的架构 文档。 以后部署模式在 1.11 版本中引入 Application 模式之前，Flink 容许用户在 Session（会话）或 Per-Job 集群上执行应用程序。两者之间的差别与集群生命周期和它们提供的资源隔离保障无关。 Session 模式Session 模式（会话模式）假设集群曾经运行，并应用该集群的资源来执行任何提交的应用程序。在同一（Session）集群中执行的应用程序应用雷同的资源，并因而相互竞争。这样做的益处是，你无需为每个提交的作业调配整个集群的资源开销。然而，如果其中一个作业行为不失常或者敞开了 TaskManager，那么在该 TaskManager 上运行的所有作业都将受到故障的影响。除了对导致故障的作业产生负面影响之外，这还意味着潜在的大规模复原过程，即所有重新启动的作业同时拜访文件系统，并使其不可用于其余服务。此外，单个集群运行多个作业意味着 JobManager 的负载更大，它负责集群中所有作业的 bookkeeping。这种模式非常适合启动短作业，例如交互式查问。 ...

Flink 中的利用部署：以后状态与新利用模式 公布文章Flink 中的利用部署：以后状态与新利用模式同步滚动：开 作为古代企业的重要工具，流解决和实时剖析这类工具逐步衰亡，越来越多的企业以 Apache Flink 为外围构建平台，并将其作为服务在外部提供。在最新举办的 Flink Forward 会议中， Uber、 Netflix 和阿里巴巴等公司的许多相干主题演讲进一步阐明了这一趋势。 泛滥平台旨在通过加重最终用户的所有经营累赘来简化外部的 Application （利用）提交。为了提交 Flink 应用程序，这些平台通常只公开一个集中式或低并行度端点（例如 Web 前端）用于利用提交，咱们将调用 Deployer（部署器）。 平台开发人员和保护人员常常提到的阻碍之一是，Deployer 可能是一个很难配置的大量资源耗费者。如果依照均匀负载进行配置，可能会导致 Deployer 服务被部署申请吞没（在最坏的状况下，短时间内对所有生产应用程序都是如此），而依照最高负载进行布局的话，又会带来不必要的老本。依据这一察看后果，Flink 1.11 引入了 Application 模式（利用模式）作为部署选项，它容许一个轻量级、更可伸缩性的利用提交过程，从而使应用程序部署负载更平均地散布在集群的各个节点上。 为了了解这个问题以及理解 Application 模式如何解决该问题，咱们首先简要概述 Flink 中应用程序执行的以后状态，而后再论述部署模式引入的架构变动以及如何利用它们。 Flink 中的应用程序执行在 Flink 中执行应用程序次要波及三个实体：Client（客户端）、JobManager（作业管理器）和 TaskManager（工作管理器）。Client 负责将利用提交给集群，JobManager 负责执行期间必要的 bookkeeping，而 TaskManager 则负责理论的计算。更多细节请参考 Flink 的架构 文档。 以后部署模式在 1.11 版本中引入 Application 模式之前，Flink 容许用户在 Session（会话）或 Per-Job 集群上执行应用程序。两者之间的差别与集群生命周期和它们提供的资源隔离保障无关。 Session 模式Session 模式（会话模式）假设集群曾经运行，并应用该集群的资源来执行任何提交的应用程序。在同一（Session）集群中执行的应用程序应用雷同的资源，并因而相互竞争。这样做的益处是，你无需为每个提交的作业调配整个集群的资源开销。然而，如果其中一个作业行为不失常或者敞开了 TaskManager，那么在该 TaskManager 上运行的所有作业都将受到故障的影响。除了对导致故障的作业产生负面影响之外，这还意味着潜在的大规模复原过程，即所有重新启动的作业同时拜访文件系统，并使其不可用于其余服务。此外，单个集群运行多个作业意味着 JobManager 的负载更大，它负责集群中所有作业的 bookkeeping。这种模式非常适合启动短作业，例如交互式查问。 ...

Flink1.11引入了CDC的connector，通过这种形式能够很不便地捕捉变动的数据，大大简化了数据处理的流程。Flink1.11的CDC connector次要包含：MySQL CDC和Postgres CDC,同时对Kafka的Connector反对canal-json和debezium-json以及changelog-json的format。本文次要分享以下内容： CDC简介Flink提供的 table format应用过程中的留神点mysql-cdc的操作实际canal-json的操作实际changelog-json的操作实际简介Flink CDC Connector 是ApacheFlink的一组数据源连接器，应用变动数据捕捉change data capture (CDC)）从不同的数据库中提取变更数据。Flink CDC连接器将Debezium集成为引擎来捕捉数据变更。因而，它能够充分利用Debezium的性能。 特点反对读取数据库快照，并且可能继续读取数据库的变更日志，即便产生故障，也反对exactly-once 的解决语义对于DataStream API的CDC connector，用户无需部署Debezium和Kafka，即可在单个作业中应用多个数据库和表上的变更数据。对于Table/SQL API 的CDC connector，用户能够应用SQL DDL创立CDC数据源，来监督单个表上的数据变更。应用场景数据库之间的增量数据同步审计日志数据库之上的实时物化视图基于CDC的维表join…Flink提供的 table formatFlink提供了一系列能够用于table connector的table format，具体如下： FormatsSupported ConnectorsCSVApache Kafka, FilesystemJSONApache Kafka, Filesystem, ElasticsearchApache AvroApache Kafka, FilesystemDebezium CDCApache KafkaCanal CDCApache KafkaApache ParquetFilesystemApache ORCFilesystem应用过程中的留神点应用MySQL CDC的留神点如果要应用MySQL CDC connector，对于程序而言，须要增加如下依赖: <dependency> <groupId>com.alibaba.ververica</groupId> <artifactId>flink-connector-mysql-cdc</artifactId> <version>1.0.0</version></dependency>如果要应用Flink SQL Client，须要增加如下jar包：flink-sql-connector-mysql-cdc-1.0.0.jar，将该jar包放在Flink装置目录的lib文件夹下即可。 应用canal-json的留神点如果要应用Kafka的canal-json，对于程序而言，须要增加如下依赖: <!-- universal --><dependency> <groupId>org.apache.flink</groupId> <artifactId>flink-connector-kafka_2.11</artifactId> <version>1.11.0</version></dependency>如果要应用Flink SQL Client，须要增加如下jar包：flink-sql-connector-kafka_2.11-1.11.0.jar，将该jar包放在Flink装置目录的lib文件夹下即可。因为Flink1.11的安装包 的lib目录下并没有提供该jar包，所以必须要手动增加依赖包，否则会报如下谬误： [ERROR] Could not execute SQL statement. Reason:org.apache.flink.table.api.ValidationException: Could not find any factory for identifier 'kafka' that implements 'org.apache.flink.table.factories.DynamicTableSourceFactory' in the classpath.Available factory identifiers are:datagenmysql-cdc应用changelog-json的留神点如果要应用Kafka的changelog-json Format，对于程序而言，须要增加如下依赖: ...

Flink1.11引入了CDC的connector，通过这种形式能够很不便地捕捉变动的数据，大大简化了数据处理的流程。Flink1.11的CDC connector次要包含：MySQL CDC和Postgres CDC,同时对Kafka的Connector反对canal-json和debezium-json以及changelog-json的format。本文次要分享以下内容： CDC简介Flink提供的 table format应用过程中的留神点mysql-cdc的操作实际canal-json的操作实际changelog-json的操作实际简介Flink CDC Connector 是ApacheFlink的一组数据源连接器，应用变动数据捕捉change data capture (CDC)）从不同的数据库中提取变更数据。Flink CDC连接器将Debezium集成为引擎来捕捉数据变更。因而，它能够充分利用Debezium的性能。 特点反对读取数据库快照，并且可能继续读取数据库的变更日志，即便产生故障，也反对exactly-once 的解决语义对于DataStream API的CDC connector，用户无需部署Debezium和Kafka，即可在单个作业中应用多个数据库和表上的变更数据。对于Table/SQL API 的CDC connector，用户能够应用SQL DDL创立CDC数据源，来监督单个表上的数据变更。应用场景数据库之间的增量数据同步审计日志数据库之上的实时物化视图基于CDC的维表join…Flink提供的 table formatFlink提供了一系列能够用于table connector的table format，具体如下： FormatsSupported ConnectorsCSVApache Kafka, FilesystemJSONApache Kafka, Filesystem, ElasticsearchApache AvroApache Kafka, FilesystemDebezium CDCApache KafkaCanal CDCApache KafkaApache ParquetFilesystemApache ORCFilesystem应用过程中的留神点应用MySQL CDC的留神点如果要应用MySQL CDC connector，对于程序而言，须要增加如下依赖: <dependency> <groupId>com.alibaba.ververica</groupId> <artifactId>flink-connector-mysql-cdc</artifactId> <version>1.0.0</version></dependency>如果要应用Flink SQL Client，须要增加如下jar包：flink-sql-connector-mysql-cdc-1.0.0.jar，将该jar包放在Flink装置目录的lib文件夹下即可。 应用canal-json的留神点如果要应用Kafka的canal-json，对于程序而言，须要增加如下依赖: <!-- universal --><dependency> <groupId>org.apache.flink</groupId> <artifactId>flink-connector-kafka_2.11</artifactId> <version>1.11.0</version></dependency>如果要应用Flink SQL Client，须要增加如下jar包：flink-sql-connector-kafka_2.11-1.11.0.jar，将该jar包放在Flink装置目录的lib文件夹下即可。因为Flink1.11的安装包 的lib目录下并没有提供该jar包，所以必须要手动增加依赖包，否则会报如下谬误： [ERROR] Could not execute SQL statement. Reason:org.apache.flink.table.api.ValidationException: Could not find any factory for identifier 'kafka' that implements 'org.apache.flink.table.factories.DynamicTableSourceFactory' in the classpath.Available factory identifiers are:datagenmysql-cdc应用changelog-json的留神点如果要应用Kafka的changelog-json Format，对于程序而言，须要增加如下依赖: ...

1.Error:can not resolve asScala谬误导入 import scala.collection.JavaConverters._2.Error:(39, 26) could not find implicit value for evidence parameter of type org.apache.flink.api.common.typeinfo.TypeInformation[String]导入 import org.apache.flink.api.scala._

继6月首次 Flink 中文邮件列表的邮件数超过英文邮件列表，7月再创新纪录，中文邮件列表的邮件数超英文邮件列表50%。通过数据，咱们不难发现 Flink 中文社区正在蓬勃发展。作为备受瞩目的新一代开源大数据计算引擎，Flink 已成为 Apache 基金会和 GitHub 最为沉闷的顶级我的项目之一。 因为社区大群仍然有很多同学在问邮件列表如何订阅、有何性能效用，本文借此机会具体跟大家介绍一下邮件列表的由来、外围性能以及正确的订阅形式。 开源社区邮件列表的作用成熟的开源社区都有用户邮件列表，如 Flink、 Kafka、HBase、Spark 等，用户会在邮件列表里征询和交换问题, 用户邮件列表的沉闷水平在很大水平上也反映了社区的发展趋势。 开源社区包容性家喻户晓，用户来自不同的公司、学校、钻研机构，大家独特保护社区、奉献社区、促成社区倒退，邮件列表是社区用户最次要的交换工具，绝大部分社区活动都是通过邮件列表来实现。通常一个开源社区至多会有两个邮件列表，别离是： 开发者(dev)邮件列表：dev 邮件列表的使用者次要是开源软件的开发者，用于探讨社区开发相干的工作，比方 feature 设计、版本公布等。用户(user)邮件列表：user 邮件列表的使用者次要是应用开源软件的用户，次要用于反馈问题、寻求帮忙、探讨交换。下表列出了几个常见开源社区的邮件列表。 用户邮件列表是社区中最为沉闷的邮件列表，绝大多数社区开发者的成长都是从用户邮件列表开始，从最开始时在用户邮件列表寻求帮忙，到帮忙他人，再到奉献社区，再到成长为社区外围力量。 Flink 中文邮件列表的诞生Apache 基金会一贯推崇应用英文交换，作为 Apache 旗下的顶级我的项目，Flink 社区的邮件列表之前也始终应用英文邮件列表(user@flink.apache.org)，没有中文邮件列表。 但随着 Flink 社区中文用户的高速增长，参加社区探讨、给社区奉献的中文用户也日益减少，不少华人甚至成长为 Flink 的外围贡献者。据 Flink 官网数据统计，在2018年全年拜访 Flink 的流量有24%来自中国，22%来自美国，并且来自中国的流量继续减少，在18年的最初一个月，拜访 Flink 的流量有30%来自中国，而来自美国的流量只有20%，这些事件都使得 Flink 社区越加器重中文用户群体。 为了解决中文用户的语言沟通阻碍，为中文用户提供更大的反对，在2019年1月，Flink 社区的 PMC 成员 Robert Metzger 提议并开设了中文邮件列表(user-zh@flink.apache.org)。 据笔者所知，这也是第一个开设中文用户邮件列表的 Apache 顶级我的项目，这也从侧面反映中国的开源力量在世界开源舞台开始取得了越来越多的关注和尊重。 Flink 中文邮件列表的倒退一年半过来了，让咱们一起通过数据看看 Flink 中文邮件列表的倒退。 在 Flink 中文邮件列表刚建设的第一个月只有12封邮件，而刚刚过来的7月份则是有1271封邮件，足足晋升了两个数量级。在往年6月份的时候首次超过了英文邮件列表(user@flink.apache.org), 在7月份中文邮件列表更是超过了英文邮件列表的50%，6，7月份刚好是 Flink 大版本 1.11 的公布窗口，所以6、7月份的邮件列表也最为沉闷。 可能大家对这个邮件数没有直观的感触，咱们能够比照下另外一些 Apache 顶级我的项目如 Spark 和 Kafka，如下图所示，这两个社区的用户邮件列表数每个月均匀在200+，能够发现 Flink 社区的活跃度遥遥领先。 ...

Flink蕴含8中分区策略，这8中分区策略(分区器)别离如上面所示，本文将从源码的角度一一解读每个分区器的实现形式。 GlobalPartitionerShufflePartitionerRebalancePartitionerRescalePartitionerBroadcastPartitionerForwardPartitionerKeyGroupStreamPartitionerCustomPartitionerWrapper继承关系图接口名称ChannelSelector 实现public interface ChannelSelector<T extends IOReadableWritable> { /** * 初始化channels数量，channel能够了解为上游Operator的某个实例(并行算子的某个subtask). */ void setup(int numberOfChannels); /** *依据以后的record以及Channel总数， *决定应将record发送到上游哪个Channel。 *不同的分区策略会实现不同的该办法。 */ int selectChannel(T record); /** *是否以播送的模式发送到上游所有的算子实例 */ boolean isBroadcast();}抽象类名称StreamPartitioner 实现public abstract class StreamPartitioner<T> implements ChannelSelector<SerializationDelegate<StreamRecord<T>>>, Serializable { private static final long serialVersionUID = 1L; protected int numberOfChannels; @Override public void setup(int numberOfChannels) { this.numberOfChannels = numberOfChannels; } @Override public boolean isBroadcast() { return false; } public abstract StreamPartitioner<T> copy();}继承关系图 ...

Hive 是大数据畛域最早呈现的 SQL 引擎，倒退至今有着丰盛的性能和宽泛的用户根底。之后呈现的 SQL 引擎，如 Spark SQL、Impala 等，都在肯定水平上提供了与 Hive 集成的性能，从而不便用户应用现有的数据仓库、进行作业迁徙等。 Flink从1.9开始反对集成Hive，不过1.9版本为beta版，不举荐在生产环境中应用。在最新版Flink1.10版本，标记着对 Blink的整合宣告实现，随着对 Hive 的生产级别集成，Hive作为数据仓库零碎的相对外围，承当着绝大多数的离线数据ETL计算和数据管理，期待Flink将来对Hive的完满反对。 而 HiveCatalog 会与一个 Hive Metastore 的实例连贯，提供元数据长久化的能力。要应用 Flink 与 Hive 进行交互，用户须要配置一个 HiveCatalog，并通过 HiveCatalog 拜访 Hive 中的元数据。 增加依赖要与Hive集成，须要在Flink的lib目录下增加额定的依赖jar包，以使集成在Table API程序或SQL Client中的SQL中起作用。或者，能够将这些依赖项放在文件夹中，并别离应用Table API程序或SQL Client 的-C 或-l选项将它们增加到classpath中。本文应用第一种形式，行将jar包间接复制到$FLINK_HOME/lib目录下。本文应用的Hive版本为2.3.4(对于不同版本的Hive，能够参照官网抉择不同的jar包依赖)，总共须要3个jar包，如下： flink-connector-hive_2.11-1.10.0.jarflink-shaded-hadoop-2-uber-2.7.5-8.0.jarhive-exec-2.3.4.jar其中hive-exec-2.3.4.jar在hive的lib文件夹下，另外两个须要自行下载，下载地址：flink-connector-hive_2.11-1.10.0.jar，flink-shaded-hadoop-2-uber-2.7.5-8.0.jar 切莫拔剑四顾心茫然，话不多说，间接上代码。 构建程序增加Maven依赖<!-- Flink Dependency --><dependency> <groupId>org.apache.flink</groupId> <artifactId>flink-connector-hive_2.11</artifactId> <version>1.10.0</version> <scope>provided</scope></dependency><dependency> <groupId>org.apache.flink</groupId> <artifactId>flink-table-api-java-bridge_2.11</artifactId> <version>1.10.0</version> <scope>provided</scope></dependency><!-- Hive Dependency --><dependency> <groupId>org.apache.hive</groupId> <artifactId>hive-exec</artifactId> <version>${hive.version}</version> <scope>provided</scope></dependency> 实例代码package com.flink.sql.hiveintegration;import org.apache.flink.table.api.EnvironmentSettings;import org.apache.flink.table.api.TableEnvironment;import org.apache.flink.table.catalog.hive.HiveCatalog;/** * @Created with IntelliJ IDEA. * @author : jmx * @Date: 2020/3/31 * @Time: 13:22 * */public class FlinkHiveIntegration { public static void main(String[] args) throws Exception { EnvironmentSettings settings = EnvironmentSettings .newInstance() .useBlinkPlanner() // 应用BlinkPlanner .inBatchMode() // Batch模式，默认为StreamingMode .build(); //应用StreamingMode /* EnvironmentSettings settings = EnvironmentSettings .newInstance() .useBlinkPlanner() // 应用BlinkPlanner .inStreamingMode() // StreamingMode .build();*/ TableEnvironment tableEnv = TableEnvironment.create(settings); String name = "myhive"; // Catalog名称，定义一个惟一的名称示意 String defaultDatabase = "qfbap_ods"; // 默认数据库名称 String hiveConfDir = "/opt/modules/apache-hive-2.3.4-bin/conf"; // hive-site.xml门路 String version = "2.3.4"; // Hive版本号 HiveCatalog hive = new HiveCatalog(name, defaultDatabase, hiveConfDir, version); tableEnv.registerCatalog("myhive", hive); tableEnv.useCatalog("myhive"); // 创立数据库，目前不反对创立hive表 String createDbSql = "CREATE DATABASE IF NOT EXISTS myhive.test123"; tableEnv.sqlUpdate(createDbSql); }}Flink SQL Client集成HiveFlink的表和SQL API能够解决用SQL语言编写的查问，然而这些查问须要嵌入到用Java或Scala编写的程序中。此外，这些程序在提交到集群之前须要与构建工具打包。这或多或少地限度了Java/Scala程序员对Flink的应用。 ...

Flink总共有三种工夫语义：Processing time(解决工夫)、Event time(事件工夫)以及Ingestion time(摄入工夫)。对于这些工夫语义的具体解释，能够参考另一篇文章Flink的工夫与watermarks详解。本文次要解说Flink Table API & SQL中基于工夫的算子如何定义工夫语义。通过本文你能够理解到： 工夫属性的简介解决工夫事件工夫工夫属性简介Flink TableAPI&SQL中的基于工夫的操作(如window)，须要指定工夫语义，表能够依据指定的工夫戳提供一个逻辑工夫属性。 工夫属性是表schama的一部分，当应用DDL创立表时、DataStream转为表时或者应用TableSource时，会定义工夫属性。一旦工夫属性被定义实现，该工夫属性能够看做是一个字段的援用，从而在基于工夫的操作中应用该字段。 工夫属性像一个工夫戳，能够被拜访并参加计算，如果一个工夫属性参加计算，那么该工夫属性会被雾化成一个惯例的工夫戳，惯例的工夫戳不能与Flink的工夫与水位线兼容，不能被基于工夫的操作所应用。 Flink TableAPI & SQL所须要的工夫属性能够通过Datastream程序中指定，如下： final StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment();env.setStreamTimeCharacteristic(TimeCharacteristic.ProcessingTime); // 默认// 能够抉择:// env.setStreamTimeCharacteristic(TimeCharacteristic.IngestionTime);// env.setStreamTimeCharacteristic(TimeCharacteristic.EventTime);解决工夫基于本地的机器工夫，是一种最简略的工夫语义，然而不能保障后果一致性，应用该工夫语义不须要提取工夫戳和生成水位线。总共有三种形式定义解决工夫属性，具体如下 DDL语句创立表时定义解决工夫解决工夫的属性能够在DDL语句中被定义为一个计算列，须要应用PROCTIME()函数，如下所示： CREATE TABLE user_actions ( user_name STRING, data STRING, user_action_time AS PROCTIME() -- 申明一个额定字段，作为解决工夫属性) WITH ( ...);SELECT TUMBLE_START(user_action_time, INTERVAL '10' MINUTE), COUNT(DISTINCT user_name)FROM user_actionsGROUP BY TUMBLE(user_action_time, INTERVAL '10' MINUTE); -- 10分钟的滚动窗口DataStream转为Table的过程中定义解决工夫在将DataStream转为表时，在schema定义中能够通过.proctime属性指定工夫属性，并将其放在其余schema字段的最初面，具体如下： DataStream<Tuple2<String, String>> stream = ...;// 申明一个额定逻辑字段作为解决工夫属性Table table = tEnv.fromDataStream(stream, "user_name, data, user_action_time.proctime");WindowedTable windowedTable = table.window(Tumble.over("10.minutes").on("user_action_time").as("userActionWindow"));应用TableSource自定义TableSource并实现DefinedProctimeAttribute 接口，如下： ...

Apache Flink提供了两种顶层的关系型API，别离为Table API和SQL，Flink通过Table API&SQL实现了批流对立。其中Table API是用于Scala和Java的语言集成查问API，它容许以十分直观的形式组合关系运算符（例如select，where和join）的查问。Flink SQL基于Apache Calcite 实现了规范的SQL，用户能够应用规范的SQL解决数据集。Table API和SQL与Flink的DataStream和DataSet API严密集成在一起，用户能够实现互相转化，比方能够将DataStream或者DataSet注册为table进行操作数据。值得注意的是，Table API and SQL目前尚未齐全欠缺，还在踊跃的开发中，所以并不是所有的算子操作都能够通过其实现。 <!-- more --> 依赖从Flink1.9开始，Flink为Table & SQL API提供了两种planner,别离为Blink planner和old planner，其中old planner是在Flink1.9之前的版本应用。次要区别如下： 尖叫提醒：对于生产环境，目前举荐应用old planner. flink-table-common: 通用模块，蕴含 Flink Planner 和 Blink Planner 一些共用的代码flink-table-api-java: java语言的Table & SQL API，仅针对table(处于晚期的开发阶段，不举荐应用)flink-table-api-scala: scala语言的Table & SQL API，仅针对table(处于晚期的开发阶段，不举荐应用)flink-table-api-java-bridge: java语言的Table & SQL API，反对DataStream/DataSet API(举荐应用)flink-table-api-scala-bridge: scala语言的Table & SQL API，反对DataStream/DataSet API(举荐应用)flink-table-planner:planner 和runtime. planner为Flink1,9之前的old planner(举荐应用)flink-table-planner-blink: 新的Blink planner.flink-table-runtime-blink: 新的Blink runtime.flink-table-uber: 将上述的API模块及old planner打成一个jar包，形如flink-table-*.jar，位与/lib目录下flink-table-uber-blink:将上述的API模块及Blink 模块打成一个jar包，形如fflink-table-blink-*.jar，位与/lib目录下Blink planner & old plannerBlink planner和old planner有许多不同的特点，具体列举如下： ...

Flink最大的亮点是实时处理局部，Flink认为批处理是流解决的非凡状况，能够通过一套引擎解决批量和流式数据，而Flink在将来也会重点投入更多的资源到批流交融中。我在Flink DataStream API编程指南中介绍了DataStream API的应用，在本文中将介绍Flink批处理计算的DataSet API的应用。通过本文你能够理解： DataSet转换操作(Transformation)Source与Sink的应用播送变量的基本概念与应用Demo分布式缓存的概念及应用DemoDataSet API的Transformation应用Demo案例WordCount示例在开始解说DataSet API之前，先看一个Word Count的简略示例，来直观感受一下DataSet API的编程模型，具体代码如下： public class WordCount { public static void main(String[] args) throws Exception { // 用于批处理的执行环境 ExecutionEnvironment env = ExecutionEnvironment.getExecutionEnvironment(); // 数据源 DataSource<String> stringDataSource = env.fromElements("hello Flink What is Apache Flink"); // 转换 AggregateOperator<Tuple2<String, Integer>> wordCnt = stringDataSource .flatMap(new FlatMapFunction<String, Tuple2<String, Integer>>() { @Override public void flatMap(String value, Collector<Tuple2<String, Integer>> out) throws Exception { String[] split = value.split(" "); for (String word : split) { out.collect(Tuple2.of(word, 1)); } } }) .groupBy(0) .sum(1); // 输入 wordCnt.print(); }}从下面的示例中能够看出，根本的编程模型是： ...

欢送关注我的公众号:大数据技术与数仓收费支付百G大数据资料窗口是流式计算中十分罕用的算子之一，通过窗口能够将有限流切分成无限流，而后在每个窗口之上应用计算函数，能够实现非常灵活的操作。Flink提供了丰盛的窗口操作，除此之外，用户还能够依据本人的解决场景自定义窗口。通过本文，你能够理解到： 窗口的基本概念和简略应用内置Window Assigners的分类、源码及应用Window Function的分类及应用窗口的组成部分及生命周期源码解读残缺的窗口应用Demo案例Quick Start是什么Window(窗口)是解决无界流的外围算子，Window能够将数据流分为固定大小的"桶(buckets)"(即通过依照固定工夫或长度将数据流切分成不同的窗口)，在每一个窗口上，用户能够应用一些计算函数对窗口内的数据进行解决，从而失去肯定工夫范畴内的统计后果。比方统计每隔5分钟输入最近一小时内点击量最多的前 N 个商品，这样就能够应用一个小时的工夫窗口将数据限定在固定工夫范畴内，而后能够对该范畴内的有界数据执行聚合解决。 依据作用的数据流(DataStream、KeyedStream)，Window能够分为两种：Keyed Windows与Non-Keyed Windows。其中Keyed Windows是在KeyedStream上应用window(…)操作，产生一个WindowedStream。Non-Keyed Windows是在DataStream上应用windowAll(…)操作，产生一个AllWindowedStream。具体的转换关系如下图所示。留神：个别不举荐应用AllWindowedStream，因为在一般流上进行窗口操作，会将所有分区的流都会集到单个的Task中，即并行度为1，从而会影响性能。 如何用下面咱们介绍了什么是窗口，那么该如何应用窗口呢?具体如上面的代码片段： Keyed Windowsstream .keyBy(...) // keyedStream上应用window .window(...) // 必选: 指定窗口分配器( window assigner) [.trigger(...)] // 可选: 指定触发器(trigger),如果不指定，则应用默认值 [.evictor(...)] // 可选: 指定清除器(evictor),如果不指定，则没有 [.allowedLateness(...)] // 可选: 指定是否提早解决数据，如果不指定，默认应用0 [.sideOutputLateData(...)] // 可选: 配置side output，如果不指定，则没有 .reduce/aggregate/fold/apply() // 必选: 指定窗口计算函数 [.getSideOutput(...)] // 可选: 从side output中获取数据Non-Keyed Windowsstream .windowAll(...) // 必选: 指定窗口分配器( window assigner) [.trigger(...)] // 可选: 指定触发器(trigger),如果不指定，则应用默认值 [.evictor(...)] // 可选: 指定清除器(evictor),如果不指定，则没有 [.allowedLateness(...)] // 可选: 指定是否提早解决数据，如果不指定，默认应用0 [.sideOutputLateData(...)] // 可选: 配置side output，如果不指定，则没有 .reduce/aggregate/fold/apply() // 必选: 指定窗口计算函数 [.getSideOutput(...)] // 可选: 从side output中获取数据简写window操作下面的代码片段中，要在keyedStream上应用window(…)或者在DataStream上应用windowAll(…)，须要传入一个window assigner的参数，对于window assigner下文会进行具体解释。如上面代码片段： ...

当咱们在应用Flink的时候，防止不了要和工夫(time)、水位线(watermarks)打交道，了解这些概念是开发分布式流解决利用的根底。那么Flink反对哪些工夫语义？Flink是如何解决乱序事件的？什么是水位线？水位线是如何生成的？水位线的传播方式是什么？让咱们带着这些问题来开始本文的内容。 <!-- more --> 工夫语义基本概念工夫是Flink等流解决中最重要的概念之一，在 Flink 中 Time 能够分为三种：Event-Time，Processing-Time 以及 Ingestion-Time，如下图所示： Event Time事件工夫，事件(Event)自身的工夫，即数据流中事件理论产生的工夫，通常应用事件产生时的工夫戳来形容，这些事件的工夫戳通常在进入流解决利用之前就曾经存在了，事件工夫反映了事件实在的产生工夫。所以，基于事件工夫的计算操作，其后果是具备确定性的，无论数据流的处理速度如何、事件达到算子的程序是否会乱，最终生成的后果都是一样的。 Ingestion Time摄入工夫，事件进入Flink的工夫，行将每一个事件在数据源算子的解决工夫作为事件工夫的工夫戳，并主动生成水位线(watermarks,对于watermarks下文会详细分析)。 Ingestion Time从概念上讲介于Event Time和Processing Time之间。与Processing Time相比 ，它的性能耗费更多一些，但后果却更可预测。因为 Ingestion Time应用稳固的工夫戳（在数据源处调配了一次），因而对记录的不同窗口操作将援用雷同的工夫戳，而在Processing Time中每个窗口算子都能够将记录调配给不同的窗口。 与Event Time相比，Ingestion Time无奈解决任何乱序事件或早退的数据，即无奈提供确定的后果，然而程序不用指定如何生成水位线。在外部，Ingestion Time与Event Time十分类似，然而能够实现主动调配工夫戳和主动生成水位线的性能。 Processing Time解决工夫，依据解决机器的零碎时钟决定数据流以后的工夫，即事件被解决时以后零碎的工夫。还以窗口算子为例(对于window，下文会详细分析)，基于解决工夫的窗口操作是以机器工夫来进行触发的，因为数据达到窗口的速率不同，所以窗口算子中应用解决工夫会导致不确定的后果。在应用解决工夫时，无需期待水位线的到来后进行触发窗口，所以能够提供较低的提早。 比照通过下面的剖析，应该对Flink的工夫语义有了大抵的理解。不晓得你会不会有这样一个疑难：既然事件工夫曾经可能解决所有的问题了，那为何还要用解决工夫呢？其实解决工夫有其特定的应用场景，解决工夫因为不必思考事件的提早与乱序，所以其解决数据的提早较低。因而如果一些利用比拟器重处理速度而非准确性，那么就能够应用解决工夫，比方要实时监控仪表盘。总之，尽管解决工夫的提早较低，然而其后果具备不确定性，事件工夫尽管有提早，然而可能保障解决的后果具备准确性，并且能够解决提早甚至无序的数据。 应用上一小结讲述了三种工夫语义的基本概念，接下来将从代码层面解说在程序中该如何配置这三种工夫语义。首先来看一段代码： /** The time characteristic that is used if none other is set. */ private static final TimeCharacteristic DEFAULT_TIME_CHARACTERISTIC = TimeCharacteristic.ProcessingTime;//省略的代码/** The time characteristic used by the data streams. */ private TimeCharacteristic timeCharacteristic = DEFAULT_TIME_CHARACTERISTIC;上述两行代码摘自StreamExecutionEnvironment类，能够看出，Flink在流处理程序中默认的工夫语义是Processing Time，那么该如何批改默认的工夫语义呢？很简略，再来看一段代码，上面的代码片段同样来自于StreamExecutionEnvironment类： ...

在Flink的工夫与watermarks详解这篇文章中，论述了Flink的工夫与水位线的相干内容。你可能不禁要提问，该如何拜访工夫戳和水位线呢？首先通过一般的DataStream API是无法访问的，须要借助Flink提供的一个底层的API——Process Function。Process Function不仅可能拜访工夫戳与水位线，而且还能够注册在未来的某个特定工夫触发的计时器(timers)。除此之外，还能够将数据通过Side Outputs发送到多个输入流中。这样以来，能够实现数据分流的性能，同时也是解决早退数据的一种形式。上面咱们将从源码动手，联合具体的应用案例来阐明该如何应用Process Function。 <!-- more --> 简介Flink提供了很多Process Function，每种Process Function都有各自的性能，这些Process Function次要包含： ProcessFunctionKeyedProcessFunctionCoProcessFunctionProcessJoinFunctionProcessWindowFunctionProcessAllWindowFunctionBaseBroadcastProcessFunction KeyedBroadcastProcessFunctionBroadcastProcessFunction继承关系图如下： 从下面的继承关系中能够看出，都实现了RichFunction接口，所以反对应用open()、close()、getRuntimeContext()等办法的调用。从名字上能够看出，这些函数都有不同的实用场景，然而根本的性能是相似的，上面会以KeyedProcessFunction为例来探讨这些函数的通用性能。 源码KeyedProcessFunction/** * 解决KeyedStream流的低级API函数 * 对于输出流中的每个元素都会触发调用processElement办法.该办法会产生0个或多个输入. * 其实现类能够通过Context拜访数据的工夫戳和计时器(timers).当计时器(timers)触发时，会回调onTimer办法. * onTimer办法会产生0个或者多个输入，并且会注册一个将来的计时器. * * 留神：如果要拜访keyed state和计时器(timers)，必须在KeyedStream上应用KeyedProcessFunction. * 另外，KeyedProcessFunction的父类AbstractRichFunction实现了RichFunction接口，所以，能够应用 * open()，close()及getRuntimeContext()办法. * * @param <K> key的类型 * @param <I> 输出元素的数据类型 * @param <O> 输入元素的数据类型 */@PublicEvolvingpublic abstract class KeyedProcessFunction<K, I, O> extends AbstractRichFunction { private static final long serialVersionUID = 1L; /** * 解决输出流中的每个元素 * 该办法会输入0个或者多个输入，相似于FlatMap的性能 * 除此之外，该办法还能够更新外部状态或者设置计时器(timer) * @param value 输出元素 * @param ctx Context，能够拜访输出元素的工夫戳，并其能够获取一个工夫服务器(TimerService)，用于注册计时器(timers)并查问工夫 * Context只有在processElement被调用期间无效. * @param out 返回的后果值 * @throws Exception */ public abstract void processElement(I value, Context ctx, Collector<O> out) throws Exception; /** * 是一个回调函数，当在TimerService中注册的计时器(timers)被触发时，会回调该函数 * @param timestamp 触发计时器(timers)的工夫戳 * @param ctx OnTimerContext，容许拜访工夫戳，TimeDomain枚举类提供了两种工夫类型： * EVENT_TIME与PROCESSING_TIME * 并其能够获取一个工夫服务器(TimerService)，用于注册计时器(timers)并查问工夫 * OnTimerContext只有在onTimer办法被调用期间无效 * @param out 后果输入 * @throws Exception */ public void onTimer(long timestamp, OnTimerContext ctx, Collector<O> out) throws Exception {} /** * 仅仅在processElement()办法或者onTimer办法被调用期间无效 */ public abstract class Context { /** * 以后被解决元素的工夫戳，或者是触发计时器(timers)时的工夫戳 * 该值可能为null，比方当程序中设置的工夫语义为：TimeCharacteristic#ProcessingTime * @return */ public abstract Long timestamp(); /** * 拜访工夫和注册的计时器(timers) * @return */ public abstract TimerService timerService(); /** * 将元素输入到side output (侧输入) * @param outputTag 侧输入的标记 * @param value 输入的记录 * @param <X> */ public abstract <X> void output(OutputTag<X> outputTag, X value); /** * 获取被解决元素的key * @return */ public abstract K getCurrentKey(); } /** * 当onTimer办法被调用时，才能够应用OnTimerContext */ public abstract class OnTimerContext extends Context { /** * 触发计时器(timers)的工夫类型，包含两种：EVENT_TIME与PROCESSING_TIME * @return */ public abstract TimeDomain timeDomain(); /** * 获取触发计时器(timer)元素的key * @return */ @Override public abstract K getCurrentKey(); }}下面的源码中，次要有两个办法，剖析如下： ...

Flink是一个分布式的流解决引擎，而流解决的其中一个特点就是7X24。那么，如何保障Flink作业的继续运行呢？Flink的外部会将利用状态(state)存储到本地内存或者嵌入式的kv数据库(RocksDB)中，因为采纳的是分布式架构，Flink须要对本地生成的状态进行长久化存储，以防止因利用或者节点机器故障等起因导致数据的失落，Flink是通过checkpoint(检查点)的形式将状态写入到近程的长久化存储，从而就能够实现不同语义的后果保障。通过本文，你能够理解到什么是Flink的状态，Flink的状态是怎么存储的，Flink可抉择的状态后端(statebackend)有哪些，什么是全局一致性检查点，Flink外部如何通过检查点实现Exactly Once的后果保障。另外，本文内容较长，倡议关注加珍藏。 <!-- more --> 什么是状态引子对于什么是状态，咱们先不做过多的剖析。首先看一个代码案例，其中案例1是Spark的WordCount代码，案例2是Flink的WorkCount代码。 案例1：Spark WCobject WordCount { def main(args:Array[String]){ val conf = new SparkConf().setMaster("local[2]").setAppName("NetworkWordCount") val ssc = new StreamingContext(conf, Seconds(5)) val lines = ssc.socketTextStream("localhost", 9999) val words = lines.flatMap(_.split(" ")) val pairs = words.map(word => (word, 1)) val wordCounts = pairs.reduceByKey(_ + _) wordCounts.print() ssc.start() ssc.awaitTermination()}}输出： C:\WINDOWS\system32>nc -lp 9999hello sparkhello spark输入： 案例2：Flink WCpublic class WordCount { public static void main(String[] args) throws Exception { StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment().setParallelism(1); DataStreamSource<String> streamSource = env.socketTextStream("localhost", 9999); SingleOutputStreamOperator<Tuple2<String,Integer>> words = streamSource.flatMap(new FlatMapFunction<String, Tuple2<String,Integer>>() { @Override public void flatMap(String value, Collector<Tuple2<String,Integer>> out) throws Exception { String[] splits = value.split("\\s"); for (String word : splits) { out.collect(Tuple2.of(word, 1)); } } }); words.keyBy(0).sum(1).print(); env.execute("WC"); }}输出： ...

Flink是一个分布式的流解决引擎，而流解决的其中一个特点就是7X24。那么，如何保障Flink作业的继续运行呢？Flink的外部会将利用状态(state)存储到本地内存或者嵌入式的kv数据库(RocksDB)中，因为采纳的是分布式架构，Flink须要对本地生成的状态进行长久化存储，以防止因利用或者节点机器故障等起因导致数据的失落，Flink是通过checkpoint(检查点)的形式将状态写入到近程的长久化存储，从而就能够实现不同语义的后果保障。通过本文，你能够理解到什么是Flink的状态，Flink的状态是怎么存储的，Flink可抉择的状态后端(statebackend)有哪些，什么是全局一致性检查点，Flink外部如何通过检查点实现Exactly Once的后果保障。另外，本文内容较长，倡议关注加珍藏。 <!-- more --> 什么是状态引子对于什么是状态，咱们先不做过多的剖析。首先看一个代码案例，其中案例1是Spark的WordCount代码，案例2是Flink的WorkCount代码。 案例1：Spark WCobject WordCount { def main(args:Array[String]){ val conf = new SparkConf().setMaster("local[2]").setAppName("NetworkWordCount") val ssc = new StreamingContext(conf, Seconds(5)) val lines = ssc.socketTextStream("localhost", 9999) val words = lines.flatMap(_.split(" ")) val pairs = words.map(word => (word, 1)) val wordCounts = pairs.reduceByKey(_ + _) wordCounts.print() ssc.start() ssc.awaitTermination()}}输出： C:\WINDOWS\system32>nc -lp 9999hello sparkhello spark输入： 案例2：Flink WCpublic class WordCount { public static void main(String[] args) throws Exception { StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment().setParallelism(1); DataStreamSource<String> streamSource = env.socketTextStream("localhost", 9999); SingleOutputStreamOperator<Tuple2<String,Integer>> words = streamSource.flatMap(new FlatMapFunction<String, Tuple2<String,Integer>>() { @Override public void flatMap(String value, Collector<Tuple2<String,Integer>> out) throws Exception { String[] splits = value.split("\\s"); for (String word : splits) { out.collect(Tuple2.of(word, 1)); } } }); words.keyBy(0).sum(1).print(); env.execute("WC"); }}输出： ...

本文次要从Binlog实时采集和离线解决Binlog还原业务数据两个方面，来介绍如何实现DB数据精确、高效地进入Hive数仓。 背景在数据仓库建模中，未经任何加工解决的原始业务层数据，咱们称之为ODS(Operational Data Store)数据。在互联网企业中，常见的ODS数据有业务日志数据（Log）和业务DB数据（DB）两类。对于业务DB数据来说，从MySQL等关系型数据库的业务数据进行采集，而后导入到Hive中，是进行数据仓库生产的重要环节。如何精确、高效地把MySQL数据同步到Hive中？个别罕用的解决方案是批量取数并Load：直连MySQL去Select表中的数据，而后存到本地文件作为两头存储，最初把文件Load到Hive表中。这种计划的长处是实现简略，然而随着业务的倒退，毛病也逐步裸露进去： 性能瓶颈：随着业务规模的增长，Select From MySQL -> Save to Localfile -> Load to Hive这种数据流破费的工夫越来越长，无奈满足上游数仓生产的工夫要求。间接从MySQL中Select大量数据，对MySQL的影响十分大，容易造成慢查问，影响业务线上的失常服务。因为Hive自身的语法不反对更新、删除等SQL原语(高版本Hive反对，然而须要分桶+ORC存储格局)，对于MySQL中产生Update/Delete的数据无奈很好地进行反对。为了彻底解决这些问题，咱们逐渐转向CDC (Change Data Capture) + Merge的技术计划，即实时Binlog采集 + 离线解决Binlog还原业务数据这样一套解决方案。Binlog是MySQL的二进制日志，记录了MySQL中产生的所有数据变更，MySQL集群本身的主从同步就是基于Binlog做的。 实现思路首先，采纳Flink负责把Kafka上的Binlog数据拉取到HDFS上。 而后，对每张ODS表，首先须要一次性制作快照（Snapshot），把MySQL里的存量数据读取到Hive上，这一过程底层采纳直连MySQL去Select数据的形式，能够应用Sqoop进行一次性全量导入。 最初，对每张ODS表，每天基于存量数据和当天增量产生的Binlog做Merge，从而还原出业务数据。 Binlog是流式产生的，通过对Binlog的实时采集，把局部数据处理需要由每天一次的批处理摊派到实时流上。无论从性能上还是对MySQL的拜访压力上，都会有显著地改善。Binlog自身记录了数据变更的类型（Insert/Update/Delete），通过一些语义方面的解决，齐全可能做到精准的数据还原。 实现计划Flink解决Kafka的binlog日志应用kafka source，对读取的数据进行JSON解析，将解析的字段拼接成字符串，合乎Hive的schema格局，具体代码如下： package com.etl.kafka2hdfs;import com.alibaba.fastjson.JSON;import com.alibaba.fastjson.JSONArray;import com.alibaba.fastjson.JSONObject;import com.alibaba.fastjson.parser.Feature;import org.apache.flink.api.common.functions.FilterFunction;import org.apache.flink.api.common.functions.MapFunction;import org.apache.flink.api.common.serialization.SimpleStringEncoder;import org.apache.flink.api.common.serialization.SimpleStringSchema;import org.apache.flink.core.fs.Path;import org.apache.flink.runtime.state.StateBackend;import org.apache.flink.runtime.state.filesystem.FsStateBackend;import org.apache.flink.streaming.api.datastream.DataStream;import org.apache.flink.streaming.api.datastream.SingleOutputStreamOperator;import org.apache.flink.streaming.api.environment.CheckpointConfig;import org.apache.flink.streaming.api.environment.StreamExecutionEnvironment;import org.apache.flink.streaming.api.functions.sink.filesystem.RollingPolicy;import org.apache.flink.streaming.api.functions.sink.filesystem.StreamingFileSink;import org.apache.flink.streaming.api.functions.sink.filesystem.rollingpolicies.DefaultRollingPolicy;import org.apache.flink.streaming.connectors.kafka.FlinkKafkaConsumer;import java.util.Map;import java.util.Properties;/** * @Created with IntelliJ IDEA. * @author : jmx * @Date: 2020/3/27 * @Time: 12:52 * */public class HdfsSink { public static void main(String[] args) throws Exception { String fieldDelimiter = ","; StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment(); env.setParallelism(1); // checkpoint env.enableCheckpointing(10_000); //env.setStateBackend((StateBackend) new FsStateBackend("file:///E://checkpoint")); env.setStateBackend((StateBackend) new FsStateBackend("hdfs://kms-1:8020/checkpoint")); CheckpointConfig config = env.getCheckpointConfig(); config.enableExternalizedCheckpoints(CheckpointConfig.ExternalizedCheckpointCleanup.DELETE_ON_CANCELLATION); // source Properties props = new Properties(); props.setProperty("bootstrap.servers", "kms-2:9092,kms-3:9092,kms-4:9092"); // only required for Kafka 0.8 props.setProperty("zookeeper.connect", "kms-2:2181,kms-3:2181,kms-4:2181"); props.setProperty("group.id", "test123"); FlinkKafkaConsumer<String> consumer = new FlinkKafkaConsumer<>( "qfbap_ods.code_city", new SimpleStringSchema(), props); consumer.setStartFromEarliest(); DataStream<String> stream = env.addSource(consumer); // transform SingleOutputStreamOperator<String> cityDS = stream .filter(new FilterFunction<String>() { // 过滤掉DDL操作 @Override public boolean filter(String jsonVal) throws Exception { JSONObject record = JSON.parseObject(jsonVal, Feature.OrderedField); return record.getString("isDdl").equals("false"); } }) .map(new MapFunction<String, String>() { @Override public String map(String value) throws Exception { StringBuilder fieldsBuilder = new StringBuilder(); // 解析JSON数据 JSONObject record = JSON.parseObject(value, Feature.OrderedField); // 获取最新的字段值 JSONArray data = record.getJSONArray("data"); // 遍历，字段值的JSON数组，只有一个元素 for (int i = 0; i < data.size(); i++) { // 获取到JSON数组的第i个元素 JSONObject obj = data.getJSONObject(i); if (obj != null) { fieldsBuilder.append(record.getLong("id")); // 序号id fieldsBuilder.append(fieldDelimiter); // 字段分隔符 fieldsBuilder.append(record.getLong("es")); //业务工夫戳 fieldsBuilder.append(fieldDelimiter); fieldsBuilder.append(record.getLong("ts")); // 日志工夫戳 fieldsBuilder.append(fieldDelimiter); fieldsBuilder.append(record.getString("type")); // 操作类型 for (Map.Entry<String, Object> entry : obj.entrySet()) { fieldsBuilder.append(fieldDelimiter); fieldsBuilder.append(entry.getValue()); // 表字段数据 } } } return fieldsBuilder.toString(); } }); //cityDS.print(); //stream.print(); // sink // 以下条件满足其中之一就会滚动生成新的文件 RollingPolicy<String, String> rollingPolicy = DefaultRollingPolicy.create() .withRolloverInterval(60L * 1000L) //滚动写入新文件的工夫，默认60s。依据具体情况调节 .withMaxPartSize(1024 * 1024 * 128L) //设置每个文件的最大大小 ,默认是128M，这里设置为128M .withInactivityInterval(60L * 1000L) //默认60秒,未写入数据处于不沉闷状态超时会滚动新文件 .build(); StreamingFileSink<String> sink = StreamingFileSink //.forRowFormat(new Path("file:///E://binlog_db/city"), new SimpleStringEncoder<String>()) .forRowFormat(new Path("hdfs://kms-1:8020/binlog_db/code_city_delta"), new SimpleStringEncoder<String>()) .withBucketAssigner(new EventTimeBucketAssigner()) .withRollingPolicy(rollingPolicy) .withBucketCheckInterval(1000) // 桶查看距离，这里设置1S .build(); cityDS.addSink(sink); env.execute(); }}对于Flink Sink到HDFS，StreamingFileSink 代替了先前的 BucketingSink，用来将上游数据存储到 HDFS 的不同目录中。它的外围逻辑是分桶，默认的分桶形式是 DateTimeBucketAssigner，即依照解决工夫分桶。解决工夫指的是音讯达到 Flink 程序的工夫，这点并不合乎咱们的需要。因而，咱们须要本人编写代码将事件工夫从音讯体中解析进去，按规定生成分桶的名称，具体代码如下： ...

本文次要从Binlog实时采集和离线解决Binlog还原业务数据两个方面，来介绍如何实现DB数据精确、高效地进入Hive数仓。 背景在数据仓库建模中，未经任何加工解决的原始业务层数据，咱们称之为ODS(Operational Data Store)数据。在互联网企业中，常见的ODS数据有业务日志数据（Log）和业务DB数据（DB）两类。对于业务DB数据来说，从MySQL等关系型数据库的业务数据进行采集，而后导入到Hive中，是进行数据仓库生产的重要环节。如何精确、高效地把MySQL数据同步到Hive中？个别罕用的解决方案是批量取数并Load：直连MySQL去Select表中的数据，而后存到本地文件作为两头存储，最初把文件Load到Hive表中。这种计划的长处是实现简略，然而随着业务的倒退，毛病也逐步裸露进去： 性能瓶颈：随着业务规模的增长，Select From MySQL -> Save to Localfile -> Load to Hive这种数据流破费的工夫越来越长，无奈满足上游数仓生产的工夫要求。间接从MySQL中Select大量数据，对MySQL的影响十分大，容易造成慢查问，影响业务线上的失常服务。因为Hive自身的语法不反对更新、删除等SQL原语(高版本Hive反对，然而须要分桶+ORC存储格局)，对于MySQL中产生Update/Delete的数据无奈很好地进行反对。为了彻底解决这些问题，咱们逐渐转向CDC (Change Data Capture) + Merge的技术计划，即实时Binlog采集 + 离线解决Binlog还原业务数据这样一套解决方案。Binlog是MySQL的二进制日志，记录了MySQL中产生的所有数据变更，MySQL集群本身的主从同步就是基于Binlog做的。 实现思路首先，采纳Flink负责把Kafka上的Binlog数据拉取到HDFS上。 而后，对每张ODS表，首先须要一次性制作快照（Snapshot），把MySQL里的存量数据读取到Hive上，这一过程底层采纳直连MySQL去Select数据的形式，能够应用Sqoop进行一次性全量导入。 最初，对每张ODS表，每天基于存量数据和当天增量产生的Binlog做Merge，从而还原出业务数据。 Binlog是流式产生的，通过对Binlog的实时采集，把局部数据处理需要由每天一次的批处理摊派到实时流上。无论从性能上还是对MySQL的拜访压力上，都会有显著地改善。Binlog自身记录了数据变更的类型（Insert/Update/Delete），通过一些语义方面的解决，齐全可能做到精准的数据还原。 实现计划Flink解决Kafka的binlog日志应用kafka source，对读取的数据进行JSON解析，将解析的字段拼接成字符串，合乎Hive的schema格局，具体代码如下： package com.etl.kafka2hdfs;import com.alibaba.fastjson.JSON;import com.alibaba.fastjson.JSONArray;import com.alibaba.fastjson.JSONObject;import com.alibaba.fastjson.parser.Feature;import org.apache.flink.api.common.functions.FilterFunction;import org.apache.flink.api.common.functions.MapFunction;import org.apache.flink.api.common.serialization.SimpleStringEncoder;import org.apache.flink.api.common.serialization.SimpleStringSchema;import org.apache.flink.core.fs.Path;import org.apache.flink.runtime.state.StateBackend;import org.apache.flink.runtime.state.filesystem.FsStateBackend;import org.apache.flink.streaming.api.datastream.DataStream;import org.apache.flink.streaming.api.datastream.SingleOutputStreamOperator;import org.apache.flink.streaming.api.environment.CheckpointConfig;import org.apache.flink.streaming.api.environment.StreamExecutionEnvironment;import org.apache.flink.streaming.api.functions.sink.filesystem.RollingPolicy;import org.apache.flink.streaming.api.functions.sink.filesystem.StreamingFileSink;import org.apache.flink.streaming.api.functions.sink.filesystem.rollingpolicies.DefaultRollingPolicy;import org.apache.flink.streaming.connectors.kafka.FlinkKafkaConsumer;import java.util.Map;import java.util.Properties;/** * @Created with IntelliJ IDEA. * @author : jmx * @Date: 2020/3/27 * @Time: 12:52 * */public class HdfsSink { public static void main(String[] args) throws Exception { String fieldDelimiter = ","; StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment(); env.setParallelism(1); // checkpoint env.enableCheckpointing(10_000); //env.setStateBackend((StateBackend) new FsStateBackend("file:///E://checkpoint")); env.setStateBackend((StateBackend) new FsStateBackend("hdfs://kms-1:8020/checkpoint")); CheckpointConfig config = env.getCheckpointConfig(); config.enableExternalizedCheckpoints(CheckpointConfig.ExternalizedCheckpointCleanup.DELETE_ON_CANCELLATION); // source Properties props = new Properties(); props.setProperty("bootstrap.servers", "kms-2:9092,kms-3:9092,kms-4:9092"); // only required for Kafka 0.8 props.setProperty("zookeeper.connect", "kms-2:2181,kms-3:2181,kms-4:2181"); props.setProperty("group.id", "test123"); FlinkKafkaConsumer<String> consumer = new FlinkKafkaConsumer<>( "qfbap_ods.code_city", new SimpleStringSchema(), props); consumer.setStartFromEarliest(); DataStream<String> stream = env.addSource(consumer); // transform SingleOutputStreamOperator<String> cityDS = stream .filter(new FilterFunction<String>() { // 过滤掉DDL操作 @Override public boolean filter(String jsonVal) throws Exception { JSONObject record = JSON.parseObject(jsonVal, Feature.OrderedField); return record.getString("isDdl").equals("false"); } }) .map(new MapFunction<String, String>() { @Override public String map(String value) throws Exception { StringBuilder fieldsBuilder = new StringBuilder(); // 解析JSON数据 JSONObject record = JSON.parseObject(value, Feature.OrderedField); // 获取最新的字段值 JSONArray data = record.getJSONArray("data"); // 遍历，字段值的JSON数组，只有一个元素 for (int i = 0; i < data.size(); i++) { // 获取到JSON数组的第i个元素 JSONObject obj = data.getJSONObject(i); if (obj != null) { fieldsBuilder.append(record.getLong("id")); // 序号id fieldsBuilder.append(fieldDelimiter); // 字段分隔符 fieldsBuilder.append(record.getLong("es")); //业务工夫戳 fieldsBuilder.append(fieldDelimiter); fieldsBuilder.append(record.getLong("ts")); // 日志工夫戳 fieldsBuilder.append(fieldDelimiter); fieldsBuilder.append(record.getString("type")); // 操作类型 for (Map.Entry<String, Object> entry : obj.entrySet()) { fieldsBuilder.append(fieldDelimiter); fieldsBuilder.append(entry.getValue()); // 表字段数据 } } } return fieldsBuilder.toString(); } }); //cityDS.print(); //stream.print(); // sink // 以下条件满足其中之一就会滚动生成新的文件 RollingPolicy<String, String> rollingPolicy = DefaultRollingPolicy.create() .withRolloverInterval(60L * 1000L) //滚动写入新文件的工夫，默认60s。依据具体情况调节 .withMaxPartSize(1024 * 1024 * 128L) //设置每个文件的最大大小 ,默认是128M，这里设置为128M .withInactivityInterval(60L * 1000L) //默认60秒,未写入数据处于不沉闷状态超时会滚动新文件 .build(); StreamingFileSink<String> sink = StreamingFileSink //.forRowFormat(new Path("file:///E://binlog_db/city"), new SimpleStringEncoder<String>()) .forRowFormat(new Path("hdfs://kms-1:8020/binlog_db/code_city_delta"), new SimpleStringEncoder<String>()) .withBucketAssigner(new EventTimeBucketAssigner()) .withRollingPolicy(rollingPolicy) .withBucketCheckInterval(1000) // 桶查看距离，这里设置1S .build(); cityDS.addSink(sink); env.execute(); }}对于Flink Sink到HDFS，StreamingFileSink 代替了先前的 BucketingSink，用来将上游数据存储到 HDFS 的不同目录中。它的外围逻辑是分桶，默认的分桶形式是 DateTimeBucketAssigner，即依照解决工夫分桶。解决工夫指的是音讯达到 Flink 程序的工夫，这点并不合乎咱们的需要。因而，咱们须要本人编写代码将事件工夫从音讯体中解析进去，按规定生成分桶的名称，具体代码如下： ...

canal是阿里巴巴旗下的一款开源我的项目，纯Java开发。基于数据库增量日志解析，提供增量数据订阅&生产，目前次要反对了MySQL（也反对mariaDB）。 筹备常见的binlog命令# 是否启用binlog日志show variables like 'log_bin';# 查看binlog类型show global variables like 'binlog_format';# 查看具体的日志配置信息show global variables like '%log%';# mysql数据存储目录show variables like '%dir%';# 查看binlog的目录show global variables like "%log_bin%";# 查看以后服务器应用的biglog文件及大小show binary logs;# 查看最新一个binlog日志文件名称和Positionshow master status;配置MySQL的binlog对于自建 MySQL , 须要先开启 Binlog 写入性能，配置 binlog-format 为 ROW 模式，my.cnf 中配置如下 [mysqld]log-bin=mysql-bin # 开启 binlogbinlog-format=ROW # 抉择 ROW 模式server_id=1 # 配置 MySQL replaction 须要定义，不要和 canal 的 slaveId 反复受权受权 canal 链接 MySQL 账号具备作为 MySQL slave 的权限, 如果已有账户可间接 grant ...

微博机器学习平台应用 Flink 实现多流 join 来生成在线机器学习须要的样本。工夫窗口内的数据会被缓存到 state 里，且 state 拜访的提早通常决定了作业的性能。开源 Flink 的状态存储次要包含 RocksDB 和 Heap 两种，而在去年的 Flink Forward 大会上咱们理解到阿里云 VVP 产品自研了一款更高性能的状态存储插件 Gemini，并对其进行了测试和试用。 在本篇文章中咱们将对 RocksDB、Heap 和 Gemini 在雷同场景下进行压测，并对其资源耗费进行比照。测试的 Flink 内核版本为 1.10.0。 测试场景咱们应用实在的样本拼接业务作为测试场景，通过将多个流的数据union后对指定key做聚合（keyby），在聚合函数里从各个流中获取相应的字段，并将须要的字段重新组合成一个新的对象存储到 value state 里。这里对每个新的对象都定义一个 timer，用 timer 性能来代替 TimeWindow，窗口完结时将数据发射到上游算子。应用 timer 性能的次要起因是 timer 更灵便，更不便用户自定义，在平台的实用性，可扩展性上体现更好。 MemoryStateBackend vs. RocksDBStateBackend首先须要阐明的是，MemoryStateBackend 不倡议在线上应用，这里次要是通过测试量化一下应用 Heap 存储 state 的资源耗费。 咱们在测试中对 checkpoint 的配置如下： CheckpointInterval:10分钟CheckpointingMode: EXACTLY_ONCECheckpointTimeout:3分钟同时对 RocksDB 减少了如下配置： setCompressionType：LZ4_COMPRESSIONsetTargetFileSizeBase：128 * 1024 * 1024setMinWriteBufferNumberToMerge：3setMaxWriteBufferNumber：4setWriteBufferSize：1GsetBlockCacheSize：10GsetBlockSize：4 * 1024setFilter：BloomFilter(10, false)测试发现，雷同作业处理雷同的数据量时，应用 MemoryStateBackend 的作业吞吐和 RocksDB 相似（输出 qps 为 30 万，聚合后输入 qps 为 2 万），但所须要的内存(taskmanager.heap.mb)是 RocksDB 的 8 倍，对应的机器资源是 RocksDB 的 2 倍。 ...

微博机器学习平台应用 Flink 实现多流 join 来生成在线机器学习须要的样本。工夫窗口内的数据会被缓存到 state 里，且 state 拜访的提早通常决定了作业的性能。开源 Flink 的状态存储次要包含 RocksDB 和 Heap 两种，而在去年的 Flink Forward 大会上咱们理解到阿里云 VVP 产品自研了一款更高性能的状态存储插件 Gemini，并对其进行了测试和试用。 在本篇文章中咱们将对 RocksDB、Heap 和 Gemini 在雷同场景下进行压测，并对其资源耗费进行比照。测试的 Flink 内核版本为 1.10.0。 测试场景咱们应用实在的样本拼接业务作为测试场景，通过将多个流的数据union后对指定key做聚合（keyby），在聚合函数里从各个流中获取相应的字段，并将须要的字段重新组合成一个新的对象存储到 value state 里。这里对每个新的对象都定义一个 timer，用 timer 性能来代替 TimeWindow，窗口完结时将数据发射到上游算子。应用 timer 性能的次要起因是 timer 更灵便，更不便用户自定义，在平台的实用性，可扩展性上体现更好。 MemoryStateBackend vs. RocksDBStateBackend首先须要阐明的是，MemoryStateBackend 不倡议在线上应用，这里次要是通过测试量化一下应用 Heap 存储 state 的资源耗费。 咱们在测试中对 checkpoint 的配置如下： CheckpointInterval:10分钟CheckpointingMode: EXACTLY_ONCECheckpointTimeout:3分钟同时对 RocksDB 减少了如下配置： setCompressionType：LZ4_COMPRESSIONsetTargetFileSizeBase：128 * 1024 * 1024setMinWriteBufferNumberToMerge：3setMaxWriteBufferNumber：4setWriteBufferSize：1GsetBlockCacheSize：10GsetBlockSize：4 * 1024setFilter：BloomFilter(10, false)测试发现，雷同作业处理雷同的数据量时，应用 MemoryStateBackend 的作业吞吐和 RocksDB 相似（输出 qps 为 30 万，聚合后输入 qps 为 2 万），但所须要的内存(taskmanager.heap.mb)是 RocksDB 的 8 倍，对应的机器资源是 RocksDB 的 2 倍。 ...