一、背景随着数据时效性对企业的精细化运营越来越重要，“实时即未来”、“实时数仓”、“数据湖” 成为了近几年炙手可热的词。流计算领域的格局也在这几年发生了巨大的变化，Apache Flink 在流批一体的方向上不断深耕，Apache Spark 的近实时处理有着一定的受众，Apache Kafka 也有了 ksqlDB 高调地进军流计算，而 Apache Storm 却开始逐渐地退出历史的舞台。每一种引擎有其优势的地方，如何选择适合自己业务的流计算引擎成了一个由来已久的话题。除了比较各个引擎提供的不同的功能矩阵之外，性能是一个无法绕开的评估因素。基准测试（benchmark）就是用来评估系统性能的一个重要和常见的过程。本文将探讨流计算基准测试设计上的难点，分享我们是如何设计一个流计算基准测试框架 ——Nexmark，以及将来的规划。二、现有流计算基准测试的问题目前在流计算领域中，还没有一个行业标准的基准测试。目前业界较为人知的流计算 benchmark 是五年前雅虎 Storm 团队发布的Yahoo Streaming Benchmarks。雅虎的原意是因为业界缺少反映真实场景的 benchmark，模拟了一个简单的广告场景来比较各个流计算框架，后来被广泛引用。具体场景是从 Kafka 消费的广告的点击流，关联 Redis 中的广告所属的 campaign 信息，然后做时间窗口聚合计 ...继续阅读 (6)

Hive SQL 迁移的动机Flink 已经是流计算的事实标准，当前国内外做实时计算或流计算一般都会选择 Flink 和 Flink SQL。另外，Flink 也是是家喻户晓的流批一体大数据计算引擎。然而，目前 Flink 也面临着挑战。比如虽然现在大规模应用都以流计算为主，但 Flink 批计算的应用并不广泛，想要进一步推动真正意义上的流批一体落地，需要推动业界更多地落地 Flink 批计算，需要更积极地拥抱现有的离线生态。当前业界离线生态主要以 Hive 为主，因此我们在过去版本中做了很多与 Hive 相关的集成，包括 Hive Catalog、Hive 语法兼容、Hive UDF 兼容、流式写入 Hive 等。在 Flink 1.16 版本中，我们进一步提升了 HiveSQL 的兼容度，还支持了 HiveServer2 的协议兼容。所以，为什么 Flink 要去支持 Hive SQL 的迁移？一方面，我们希望吸引更多的 Hive 离线数仓用户，通过用户来不断打磨批计算引擎，对齐主流批计算引擎。另一方面，通过兼容 Hive SQL，来降低现有离线用户使用 Flink 开发离线业务的门槛。除此之外，另外，生态是开源产品的最大门槛。Flink 已经拥有非常丰富的实时生态工具，但离线生态依然较为欠缺。通过兼容 Hive 生态可以快速融入 Hive 离线生态工具和平台，降低用户接入的成 ...继续阅读 (5)

一、Flink CDC 介绍从广义的概念上讲，能够捕获数据变更的技术, 我们都可以称为 CDC 技术。通常我们说的 CDC 技术是一种用于捕获数据库中数据变更的技术。CDC 技术应用场景也非常广泛，包括：数据分发，将一个数据源分发给多个下游，常用于业务解耦、微服务。数据集成，将分散异构的数据源集成到数据仓库中，消除数据孤岛，便于后续的分析。数据迁移，常用于数据库备份、容灾等。Flink CDC 基于数据库日志的 Change Data Caputre 技术，实现了全量和增量的一体化读取能力，并借助 Flink 优秀的管道能力和丰富的上下游生态，支持捕获多种数据库的变更，并将这些变更实时同步到下游存储。目前，Flink CDC 的上游已经支持了 MySQL、MariaDB、PG、Oracle、MongoDB 等丰富的数据源，对 Oceanbase、TiDB、SQLServer 等数据库的支持也已经在社区的规划中。Flink CDC 的下游则更加丰富，支持写入 Kafka、Pulsar 消息队列，也支持写入 Hudi、Iceberg 等数据湖，还支持写入各种数据仓库。同时，通过 Flink SQL 原生支持的 Changelog 机制，可以让 CDC 数据的加工变得非常简单。用户可以通过 SQL 便能实现数据库全量和增量数据的清洗、打宽、聚合等操作，极大地降低了用户门槛。 此外， Fl ...继续阅读 (15)

数据仓库与数据集成数据仓库是一个集成的（Integrated），面向主题的（Subject-Oriented），随时间变化的（Time-Variant），不可修改的（Nonvolatile）数据集合，用于支持管理决策。这是数据仓库之父 Bill Inmon 在 1990 年提出的数据仓库概念。该概念里最重要的一点就是“集成的”，其余特性都是一些方法论的东西。因为数据仓库首先要解决的问题，就是数据集成，就是将多个分散的、异构的数据源整合在一起，消除数据孤岛，便于后续的分析。这个不仅适用于传统的离线数仓，也同样适用于实时数仓，或者是现在火热的数据湖。首先要解决的就是数据集成的问题。如果说业务的数据都在一个数据库中，并且这个数据库还能提供非常高效的查询分析能力，那其实也用不着数据仓库和数据湖上场了。数据集成就是我们常称作 ETL 的过程，分别是数据接入(Extract)、数据清洗转换打宽(Transformation)、以及数据的入仓入湖(Load)，分别对应三个英文单词的首字母，所以叫 ETL。ETL 的过程也是数仓搭建中最具工作量的环节。那么 Flink 是如何改善这个 ETL 的过程的呢？我们先来看看传统的数据仓库的架构。传统的数据仓库，实时和离线数仓是比较割裂的两套链路，比如实时链路通过 Flume和 Canal 实时同步日志和数据库数据到 Kafka 中，然后在 Kafka 中 ...继续阅读 (11)

上周四在 Flink 中文社区钉钉群中直播分享了《Demo：基于 Flink SQL 构建流式应用》，直播内容偏向实战演示。这篇文章是对直播内容的一个总结，并且改善了部分内容，比如除 Flink 外其他组件全部采用 Docker Compose 安装，简化准备流程。读者也可以结合视频和本文一起学习。完整分享可以观看视频回顾：https://www.bilibili.com/video/av90560012Flink 1.10.0 于近期刚发布，释放了许多令人激动的新特性。尤其是 Flink SQL 模块，发展速度非常快，因此本文特意从实践的角度出发，带领大家一起探索使用 Flink SQL 如何快速构建流式应用。本文将基于 Kafka, MySQL, Elasticsearch, Kibana，使用 Flink SQL 构建一个电商用户行为的实时分析应用。本文所有的实战演练都将在 Flink SQL CLI 上执行，全程只涉及 SQL 纯文本，无需一行 Java/Scala 代码，无需安装 IDE。本实战演练的最终效果图：准备一台装有 Docker 和 Java8 的 Linux 或 MacOS 计算机。使用 Docker Compose 启动容器本实战演示所依赖的组件全都编排到了容器中，因此可以通过docker-compose一键启动。你可以通过wget命令自动下载该docker ...继续阅读 (7)

上周六在深圳分享了《Flink SQL 1.9.0 技术内幕和最佳实践》，会后许多小伙伴对最后演示环节的 Demo 代码非常感兴趣，迫不及待地想尝试下，所以写了这篇文章分享下这份代码。希望对于 Flink SQL 的初学者能有所帮助。完整分享可以观看 Meetup 视频回顾 ：https://developer.aliyun.com/live/1416演示代码已经开源到了 GitHub 上：https://github.com/wuchong/flink-sql-submit。这份代码主要由两部分组成：1) 能用来提交 SQL 文件的 SqlSubmit 实现。2） 用于演示的 SQL 示例、Kafka 启动停止脚本、 一份测试数据集、Kafka 数据源生成器。通过本实战，你将学到：如何使用 Blink Planner一个简单的 SqlSubmit 是如何实现的如何用 DDL 创建一个 Kafka 源表和 MySQL 结果表运行一个从 Kafka 读取数据，计算 PVUV，并写入 MySQL 的作业设置调优参数，观察对作业的影响SqlSubmit 的实现笔者一开始是想用SQL Client来贯穿整个演示环节，但可惜 1.9 版本 SQL CLI 还不支持处理 CREATE TABLE 语句。所以笔者就只好自己写了个简单的提交脚本。后来想想，也挺好的，可以让听众同时了解如何通过 SQ ...继续阅读 (5)

注： 本教程实践基于 Ververica 开源的sql-training项目。基于 Flink 1.7.2 。通过本课你能学到什么？本文将通过五个实例来贯穿 Flink SQL 的编程实践，主要会涵盖以下几个方面的内容。如何使用 SQL CLI 客户端如何在流上运行 SQL 查询运行 window aggregate 与 non-window aggregate，理解其区别如何用 SQL 消费 Kafka 数据如何用 SQL 将结果写入 Kafka 和 ElasticSearch本文假定您已具备基础的 SQL 知识。环境准备本文教程是基于 Docker 进行的，因此你只需要安装了Docker即可。不需要依赖 Java、Scala 环境、或是IDE。注意：Docker 默认配置的资源可能不太够，会导致运行 Flink Job 时卡死。因此推荐配置 Docker 资源到 3-4 GB，3-4 CPUs。本次教程的环境使用 Docker Compose 来安装，包含了所需的各种服务的容器，包括：Flink SQL Client：用来提交query，以及可视化结果Flink JobManager 和 TaskManager：用来运行 Flink SQL 任务。Apache Kafka：用来生成输入流和写入结果流。Apache Zookeeper：Kafka 的依赖项ElasticSearc ...继续阅读 (8)

过去三年，我一直在为 Apache Flink 开源项目贡献，也在两年前成为了 Flink Committer。我在 Flink 社区成长的过程中受到过社区大神的很多指导，如今也有很多人在向我咨询如何能参与到开源社区中，如何能成为 Committer。这也是本文写作的初衷，希望能帮助更多人参与到开源社区中。本文将以 Apache Flink 为例，介绍如何参与社区贡献，如何成为 Apache Committer。我们先来了解下一个小白在 Apache 社区中的成长路线是什么样的。Apache 社区的成长路线Apache 软件基金会（Apache Software Foundation，ASF）在开源软件界大名鼎鼎。ASF 能保证旗下 200 多个项目的社区活动运转良好，得益于其独特的组织架构和良好的制度。用户 (User):通过使用社区的项目构建自己的业务架构的开发者都是Apache的用户。贡献者 (Contributor):帮助解答用户的问题，贡献代码或文档，在邮件列表中参与讨论设计和方案的都是 Contributor。提交者 (Committer):贡献多了以后，就有可能经过 PMC 的提议和投票，邀请你成为 Committer。成为 Committer 也就意味着正式加入 Apache了，不但拥有相应项目的写入权限还有 apache.org 的专属邮箱。成为 Committe ...继续阅读 (6)

前几天 Blink 开源的消息刷了朋友圈，因为笔者一直关注着社区的发展。所以今天想从我个人的角度来聊聊 Blink 开源，社区 merge Blink 的计划，以及最近发生的一些很有意义的事情。Blink 开源这次 Blink 开源的主要目的是让社区的开发者们能尽早地尝试一些他们感兴趣的功能与改进。我觉得最核心的贡献包括：Stream SQL 的新功能和性能优化：如维表Join、TopN、支持迟到数据和提早输出的Window、有效解决Agg数据倾斜问题等。完整且高性能的 Batch SQL：跑通全部 TPC-H/TPC-DS （比当前 Flink Batch SQL 快 10x 以上），能够读取 Hive meta 和 data 。易用性提升：焕然一新的Web UI，与 Zeppelin 的集成，交互式编程的支持。Stream SQL 上的功能补齐和性能优化经阿里内部多年千锤百炼打磨而来，毫无疑问是社区用户们最为翘首以盼的功能，笔者认为这部分的开源和回馈能迅速将 Flink SQL 的流式计算能力提升到高度成熟级别。同时，Blink 对Batch SQL 上的完善和优化弥补了 Flink 长久以来在批处理能力上的不足，这也为未来Flink深度统一批流大业打下了更为坚实的基础。另外值得一提的是这次Blink开源的新UI，是由 NG-ZORRO 的作者 vthinkxie 亲自操刀，一 ...继续阅读 (7)

原文：https://data-artisans.com/blog/4-steps-flink-application-production-ready作者：Nico Kruber, Markos Sfikas译者：云邪（Jark）本文阐述了使 Flink 应用达到生产就绪状态所需要的一些配置步骤。在以下部分中，我们概述了重要的配置参数，这些参数是技术领导、DevOps、工程师们在将 Flink 应用程序上线生产之前都需要仔细考虑的。Apache Flink 为大多数配置都提供了开箱即用的默认选项，在许多情况下，它们是POC阶段（概念验证）或探索 Flink 不同 API 和抽象的很好的起点。然而，将 Flink 应用程序投入生产还需要额外的配置，这些配置可以高效地调整应用的规模，使其达到生产就绪状态，并能与不同系统之间保持兼容，以保证未来迭代升级的需求。下面几点是我们收集的需要在 Flink 应用上线前做的检查：1. 明确定义 Flink 算子的最大并发度Flink 的 keyed state 是由key group进行组织的，并分布在 Flink 算子（operator）的各个并发实例上。Key group 是用来分布和影响 Flink 应用程序可扩展性的最小原子单元，每个算子上的 key group 个数即为最大并发数（maxParallelism），可以手动配置也可以直接使 ...继续阅读 (13)

原文：https://data-artisans.com/blog/broadcast-state-pattern-flink-considerations作者：Markos Sfikas译者：云邪（Jark）在 Apache Flink 1.5.0 中引入了广播状态（Broadcast State）。本文将描述什么是广播状态模式（Broadcast State Pattern），广播状态与其他的 Operator State 有什么区别，最后，我们在 Flink 中使用该功能时需要考虑的一些重要的注意事项。什么是广播状态模式广播状态模式指的一种流应用程序，其中低吞吐量的事件流（例如，包含一组规则）被广播到某个 operator 的所有并发实例中，然后针对来自另一条原始数据流中的数据（例如金融或信用卡交易）进行计算。 广播状态模式的一些典型应用案例如下：动态规则：例如，有一个规则：当某个交易超过100万美元时需要发一个警报。我们将这个规则广播到计算交易的算子的所有并发实例中。数据丰富：例如，将用户的详细信息作业广播状态进行广播，对包含用户ID的交易数据流进行数据丰富。为了实现这样的应用，关键组件是广播状态，我们将在下文详细描述。什么是广播状态？广播状态是 Apache Flink 中支持的第三种类型的 operator state。广播状态使得 Flink 用户能够以容错、一致、可 ...继续阅读 (5)

原文：https://data-artisans.com/blog/differences-between-savepoints-and-checkpoints-in-flink作者：Stefan Richter, Dawid Wysakowicz, Markos Sfikas译者：云邪（Jark）在本文中，我们将阐述 Savepoint 和 Checkpoint 是什么，它们主要用在什么时候，以及对比它们的主要区别。什么是 Savepoint 和 CheckpointSavepoint 是用来为整个流应用程序在某个“时间点”（point-in-time）的生成快照的功能。该快照包含了输入源的位置信息，数据源读取到的偏移量（offset），以及整个应用的状态。借助 Chandy-Lamport 算法的变体，我们可以无需停止应用程序而得到一致的快照。Savepoint 包含了两个主要元素：首先，Savepoint 包含了一个目录，其中包含（通常很大的）二进制文件，这些文件表示了整个流应用在 Checkpoint/Savepoint 时的状态。以及一个（相对较小的）元数据文件，包含了指向 Savapoint 各个文件的指针，并存储在所选的分布式文件系统或数据存储中。上述有关 Savepoint 的介绍听起来和之前文章中介绍的 Checkpoint 很像。Checkpoint 是 Fli ...继续阅读 (10)

原文：https://data-artisans.com/blog/how-apache-flink-manages-kafka-consumer-offsets作者：Fabian Hueske, Markos Sfikas译者：云邪（Jark）在本周的《Flink Friday Tip》中，我们将结合例子逐步讲解 Apache Flink 是如何与 Apache Kafka 协同工作并确保来自 Kafka topic 的消息以 exactly-once 的语义被处理。检查点（Checkpoint）是使 Apache Flink 能从故障恢复的一种内部机制。检查点是 Flink 应用状态的一个一致性副本，包括了输入的读取位点。在发生故障时，Flink 通过从检查点加载应用程序状态来恢复，并从恢复的读取位点继续处理，就好像什么事情都没发生一样。你可以把检查点想象成电脑游戏的存档一样。如果你在游戏中发生了什么事情，你可以随时读档重来一次。检查点使得 Apache Flink 具有容错能力，并确保了即时发生故障也能保证流应用程序的语义。检查点是以固定的间隔来触发的，该间隔可以在应用中配置。Apache Flink 中实现的 Kafka 消费者是一个有状态的算子（operator），它集成了 Flink 的检查点机制，它的状态是所有 Kafka 分区的读取偏移量。当一个检查点被触发时，每一 ...继续阅读 (8)

原文：https://data-artisans.com/blog/stateful-stream-processing-apache-flink-state-backends作者：Seth Wiesman, Markos Sfikas译者：云邪（Jark）本文我们将深入探讨有状态的流处理，更确切地说是 Apache Flink 中不同的状态后端（state backend）。在以下部分，我们将介绍 Apache Flink 的 3 种状态后端，它们的局限性以及根据具体案例需求选择最合适的状态后端。在有状态的流处理中，当开发人员启用了 Flink 中的 checkpoint 机制，那么状态将会持久化以防止数据的丢失并确保发生故障时能够完全恢复。选择何种状态后端，将决定状态持久化的方式和位置。Flink 提供了三种可用的状态后端：MemoryStateBackend，FsStateBackend，和RocksDBStateBackend。MemoryStateBackendMemoryStateBackend是将状态维护在 Java 堆上的一个内部状态后端。键值状态和窗口算子使用哈希表来存储数据（values）和定时器（timers）。当应用程序 checkpoint 时，此后端会在将状态发给 JobManager 之前快照下状态，JobManager 也将状态存储在 Java 堆上 ...继续阅读 (8)

原文：https://data-artisans.com/blog/watermarks-in-apache-flink-made-easy作者：David Anderson译者：云邪（Jark）当人们第一次使用 Flink 时，经常会对 watermark 感到困惑。但其实 watermark 并不复杂。让我们通过一个简单的例子来说明为什么我们需要 watermark，以及它的工作机制是什么样的。在 Apache Flink 中使用 watermark 的 4 个理解在下文中的例子中，我们有一个带有时间戳的事件流，但是由于某种原因它们并不是按顺序到达的。图中的数字代表事件发生的时间戳。第一个到达的事件发生在时间 4，然后它后面跟着的是发生在更早时间（时间 2）的事件，以此类推：注意这是一个按照事件时间处理的例子，这意味着时间戳反映的是事件发生的时间，而不是处理事件的时间。事件时间（Event-Time）处理的强大之处在于，无论是在处理实时的数据还是重新处理历史的数据，基于事件时间创建的流计算应用都能保证结果是一样的。注：可以访问Apache Flink 文档，了解更多有关时间的概念，如 event-time, processing-time, ingestion-time。现在假设我们正在尝试创建一个流计算排序算子。也就是处理一个乱序到达的事件流，并按照事件时间的顺序输出事件。理 ...继续阅读 (7)

作者：云邪（Jark）原文链接：http://wuchong.me/blog/2018/11/09/flink-tech-evolution-introduction/Apache Flink 介绍Apache Flink 是近年来越来越流行的一款开源大数据计算引擎，它同时支持了批处理和流处理，也能用来做一些基于事件的应用。使用官网的一句话来介绍 Flink 就是“Stateful Computations Over Streams”。首先Flink 是一个纯流式的计算引擎，它的基本数据模型是数据流。流可以是无边界的无限流，即一般意义上的流处理。也可以是有边界的有限流，这样就是批处理。因此 Flink 用一套架构同时支持了流处理和批处理。其次，Flink 的一个优势是支持有状态的计算。如果处理一个事件（或一条数据）的结果只跟事件本身的内容有关，称为无状态处理；反之结果还和之前处理过的事件有关，称为有状态处理。稍微复杂一点的数据处理，比如说基本的聚合，数据流之间的关联都是有状态处理。Apache Flink 基石Apache Flink 之所以能越来越受欢迎，我们认为离不开它最重要的四个基石：Checkpoint、State、Time、Window。首先是Checkpoint机制，这是 Flink 最重要的一个特性。Flink 基于 Chandy-Lamport 算法实现了分布式一致 ...继续阅读 (2)

原文：https://data-artisans.com/blog/6-things-to-consider-when-defining-your-apache-flink-cluster-size作者：Fabian Hueske译者：云邪（Jark）译注：原文标题是“6 things to consider when defining your Apache Flink cluster size”，其实在确定作业所需资源时要考虑的事情是一样的，而作业所需资源的问题是用户更经常遇到的问题，所以这里将标题修改了下。本文是我们博客新开系列《Flink Friday Tip》的首篇文章。该系列主要涵盖了易理解的最佳实践、如何提高Flink 性能的建议、以及如何最佳地使用 Flink 的各种功能。译注：这也是我为什么打算开始翻译这个系列的原因，不过我可能做不到每周五同步更新，但是我会尽量做到每周更新，所以翻译过来的系列名叫做《Flink小贴士》。在 Apache Flink 社区中我们被经常问及的一件事是：如何规划和计算一个 Flink 集群的大小（或者说如何确定一个 Flink 作业所需的资源）。确定集群的大小很显然是决定于多种因素的，例如应用场景，应用的规模，以及特定的服务等级协议（SLA）。另外应用程序中的 checkpoint 类型（增量 vs 全量）和 Flink 作业处理是连续 ...继续阅读 (6)

在上一篇入门教程中，我们已经能够快速构建一个基础的 Flink 程序了。本文会一步步地带领你实现一个更复杂的 Flink 应用程序：实时热门商品。在开始本文前我们建议你先实践一遍上篇文章，因为本文会沿用上文的my-flink-project项目框架。通过本文你将学到：如何基于 EventTime 处理，如何指定 Watermark如何使用 Flink 灵活的 Window API何时需要用到 State，以及如何使用如何使用 ProcessFunction 实现 TopN 功能实战案例介绍本案例将实现一个“实时热门商品”的需求，我们可以将“实时热门商品”翻译成程序员更好理解的需求：每隔5分钟输出最近一小时内点击量最多的前 N 个商品。将这个需求进行分解我们大概要做这么几件事情：抽取出业务时间戳，告诉 Flink 框架基于业务时间做窗口过滤出点击行为数据按一小时的窗口大小，每5分钟统计一次，做滑动窗口聚合（Sliding Window）按每个窗口聚合，输出每个窗口中点击量前N名的商品数据准备这里我们准备了一份淘宝用户行为数据集（来自阿里云天池公开数据集，特别感谢）。本数据集包含了淘宝上某一天随机一百万用户的所有行为（包括点击、购买、加购、收藏）。数据集的组织形式和MovieLens-20M类似，即数据集的每一行表示一条用户行为，由用户ID、商品ID、商品类目ID、行为类型和时间戳组成 ...继续阅读 (3)

在本文中，我们将从零开始，教您如何构建第一个 Flink 应用程序。开发环境准备Flink 可以运行在 Linux, Max OS X, 或者是 Windows 上。为了开发 Flink 应用程序，在本地机器上需要有Java 8.x和maven环境。如果有 Java 8 环境，运行下面的命令会输出如下版本信息：$ java -versionjava version"1.8.0_65"Java(TM) SE Runtime Environment (build 1.8.0_65-b17)Java HotSpot(TM) 64-BitServerVM (build 25.65-b01, mixed mode)如果有 maven 环境，运行下面的命令会输出如下版本信息：$ mvn -versionApache Maven3.5.4(1edded0938998edf8bf061f1ceb3cfdeccf443fe;2018-06-18T02:33:14+08:00)Mavenhome:/Users/wuchong/dev/mavenJavaversion:1.8.0_65,vendor:Oracle Corporation,runtime:/Library/Java/JavaVirtualMachines/jdk1.8.0_65.jdk/Contents/Home/jreDefaultlo ...继续阅读 (7)

作者：刘迪珊整理：上海-星辰（Flink China社区志愿者）本文整理自8月11日在北京举行的FlinkMeetup，分享嘉宾刘迪珊(2015年加入美团数据平台。致力于打造高效、易用的实时计算平台，探索不同场景下实时应用的企业级解决方案及统⼀化服务)。美团实时计算平台现状和背景实时平台架构上图呈现的是当前美团实时计算平台的简要架构。最底层是数据缓存层，可以看到美团测的所有日志类的数据，都是通过统一的日志收集系统收集到Kafka。Kafka作为最大的数据中转层，支撑了美团线上的大量业务，包括离线拉取，以及部分实时处理业务等。在数据缓存层之上，是一个引擎层，这一层的左侧是我们目前提供的实时计算引擎，包括Storm和Flink。Storm在此之前是 standalone 模式的部署方式，Flink由于其现在运行的环境，美团选择的是On YARN模式，除了计算引擎之外，我们还提供一些实时存储功能，用于存储计算的中间状态、计算的结果、以及维度数据等，目前这一类存储包含Hbase、Redis以及ES。在计算引擎之上，是趋于五花八门的一层，这一层主要面向数据开发的同学。实时数据开发面临诸多问题，例如在程序的调试调优方面就要比普通的程序开发困难很多。在数据平台这一层，美团面向用户提供的实时计算平台，不仅可以托管作业，还可以实现调优诊断以及监控报警，此外还有实时数据的检索以及权限管理等功能。除了提 ...继续阅读 (3)

这两天，团队来了不少新人，有实习生也有刚毕业的大学生。看着他们稚气的面庞，文静而腼腆的样子，跟我两年前刚进公司的时候好像。今天内网提示我这是我在阿里的第732天，两周年快乐。突然觉得，我应该写点什么东西，一方面给自己一个总结，分享一下自己成长的故事。另一方面，希望能帮助刚毕业的大学生们消除一些成长路上的疑惑。JStorm我是2015年7月毕业后加入的公司，当时进入的是中间件-实时计算 JStorm 团队。JStorm 是用 Java 语言代替 Clojure 语言重写了 Apache Storm，并在原有的基础上做了诸多性能和功能优化。JStorm 是阿里巴巴开源的几个明星产品之一，在国内的用户非常多。很多国内做流计算，实时计算的应该都知道 JStorm。但是我当时并不知道 JStorm 或是 Storm，我当时只知道 Spark，也不懂什么是实时计算，流计算。所以都是入职之后现学，看文档，看源码，学习 Clojure。差不多11月份的时候，阿里正式向 Apache 基金会捐赠了 JStorm。这是阿里捐赠给 Apache 的第一个项目，后面还有Apache RocketMQ,Apache Weex。JStorm 火了一把，当时有很多报道转载这件事情，还放了一张我们团队油头垢面、屌丝气十足的合照。在第一个半年里，我重写了 JStorm 的开源 UI，参与了管控平台的开发，做了 JS ...继续阅读 (8)

背景Async I/O 是阿里巴巴贡献给社区的一个呼声非常高的特性，于1.2版本引入。主要目的是为了解决与外部系统交互时网络延迟成为了系统瓶颈的问题。流计算系统中经常需要与外部系统进行交互，比如需要查询外部数据库以关联上用户的额外信息。通常，我们的实现方式是向数据库发送用户a的查询请求，然后等待结果返回，在这之前，我们无法发送用户b的查询请求。这是一种同步访问的模式，如下图左边所示。图片来自官方文档图中棕色的长条表示等待时间，可以发现网络等待时间极大地阻碍了吞吐和延迟。为了解决同步访问的问题，异步模式可以并发地处理多个请求和回复。也就是说，你可以连续地向数据库发送用户a、b、c等的请求，与此同时，哪个请求的回复先返回了就处理哪个回复，从而连续的请求之间不需要阻塞等待，如上图右边所示。这也正是 Async I/O 的实现原理。Async I/O使用 Async I/O 的前提是需要一个支持异步请求的客户端。当然，没有异步请求客户端的话也可以将同步客户端丢到线程池中执行作为异步客户端。Flink 提供了非常简洁的API，让用户只需要关注业务逻辑，一些脏活累活比如消息顺序性和一致性保证都由框架处理了，多么棒的事情！使用方式如下方代码片段所示（来自官网文档）：/** 'AsyncFunction' 的一个实现，向数据库发送异步请求并设置回调 */classAsyncDatabaseRequ ...继续阅读 (8)

Flink 已经拥有了强大的 DataStream/DataSet API，可以基本满足流计算和批计算中的所有需求。为什么还需要 Table & SQL API 呢？首先 Table API 是一种关系型API，类 SQL 的API，用户可以像操作表一样地操作数据，非常的直观和方便。用户只需要说需要什么东西，系统就会自动地帮你决定如何最高效地计算它，而不需要像 DataStream 一样写一大堆 Function，优化还得纯靠手工调优。另外，SQL 作为一个“人所皆知”的语言，如果一个引擎提供 SQL，它将很容易被人们接受。这已经是业界很常见的现象了。值得学习的是，Flink 的 Table API 与 SQL API 的实现，有 80% 的代码是共用的。所以当我们讨论 Table API 时，常常是指 Table & SQL API。Table & SQL API 还有另一个职责，就是流处理和批处理统一的API层。Flink 在runtime层是统一的，因为Flink将批任务看做流的一种特例来执行，这也是 Flink 向外鼓吹的一点。然而在编程模型上，Flink 却为批和流提供了两套API （DataSet 和 DataStream）。为什么 runtime 统一，而编程模型不统一呢？ 在我看来，这是本末倒置的事情。用户才不管你 runtime 层是否统一，用户更关心的是写一套代 ...继续阅读 (10)

在上一篇文章：Window机制中，我们介绍了窗口的概念和底层实现，以及 Flink 一些内建的窗口，包括滑动窗口、翻滚窗口。本文将深入讲解一种较为特殊的窗口：会话窗口（session window）。建议您在阅读完上一篇文章的基础上再阅读本文。当我们需要分析用户的一段交互的行为事件时，通常的想法是将用户的事件流按照“session”来分组。session 是指一段持续活跃的期间，由活跃间隙分隔开。通俗一点说，消息之间的间隔小于超时阈值（sessionGap）的，则被分配到同一个窗口，间隔大于阈值的，则被分配到不同的窗口。目前开源领域大部分的流计算引擎都有窗口的概念，但是没有对 session window 的支持，要实现 session window，需要用户自己去做完大部分事情。而当 Flink 1.1.0 版本正式发布时，Flink 将会是开源流计算领域第一个内建支持 session window 的引擎。在 Flink 1.1.0 之前，Flink 也可以通过自定义的window assigner和trigger来实现一个基本能用的session window。release-1.0版本中提供了一个实现 session window 的 example：SessionWindowing。这个session window范例的实现原理是，基于GlobleWindow这个wind ...继续阅读 (57)

Flink 认为 Batch 是 Streaming 的一个特例，所以 Flink 底层引擎是一个流式引擎，在上面实现了流处理和批处理。而窗口（window）就是从 Streaming 到 Batch 的一个桥梁。Flink 提供了非常完善的窗口机制，这是我认为的 Flink 最大的亮点之一（其他的亮点包括消息乱序处理，和 checkpoint 机制）。本文我们将介绍流式处理中的窗口概念，介绍 Flink 内建的一些窗口和 Window API，最后讨论下窗口在底层是如何实现的。什么是 Window在流处理应用中，数据是连续不断的，因此我们不可能等到所有数据都到了才开始处理。当然我们可以每来一个消息就处理一次，但是有时我们需要做一些聚合类的处理，例如：在过去的1分钟内有多少用户点击了我们的网页。在这种情况下，我们必须定义一个窗口，用来收集最近一分钟内的数据，并对这个窗口内的数据进行计算。窗口可以是时间驱动的（Time Window，例如：每30秒钟），也可以是数据驱动的（Count Window，例如：每一百个元素）。一种经典的窗口分类可以分成：翻滚窗口（Tumbling Window，无重叠），滚动窗口（Sliding Window，有重叠），和会话窗口（Session Window，活动间隙）。我们举个具体的场景来形象地理解不同窗口的概念。假设，淘宝网会记录每个用户每次购买的商 ...继续阅读 (20)

Flink 为流处理和批处理分别提供了 DataStream API 和 DataSet API。正是这种高层的抽象和 flunent API 极大地便利了用户编写大数据应用。不过很多初学者在看到官方 Streaming 文档中那一大坨的转换时，常常会蒙了圈，文档中那些只言片语也很难讲清它们之间的关系。所以本文将介绍几种关键的数据流类型，它们之间是如何通过转换关联起来的。下图展示了 Flink 中目前支持的主要几种流的类型，以及它们之间的转换关系。DataStreamDataStream是 Flink 流处理 API 中最核心的数据结构。它代表了一个运行在多个分区上的并行流。一个DataStream可以从StreamExecutionEnvironment通过env.addSource(SourceFunction)获得。DataStream 上的转换操作都是逐条的，比如map()，flatMap()，filter()。DataStream 也可以执行rebalance（再平衡，用来减轻数据倾斜）和broadcaseted（广播）等分区转换。valstream:DataStream[MyType] = env.addSource(newFlinkKafkaConsumer08[String](...))valstr1:DataStream[(String,MyType)] = st ...继续阅读 (35)

继前文Flink 原理与实现：架构和拓扑概览中介绍了Flink的四层执行图模型，本文将主要介绍 Flink 是如何将 StreamGraph 转换成 JobGraph 的。根据用户用Stream API编写的程序，构造出一个代表拓扑结构的StreamGraph的。以 WordCount 为例，转换图如下图所示：StreamGraph 和 JobGraph 都是在 Client 端生成的，也就是说我们可以在 IDE 中通过断点调试观察 StreamGraph 和 JobGraph 的生成过程。JobGraph 的相关数据结构主要在org.apache.flink.runtime.jobgraph包中。构造 JobGraph 的代码主要集中在StreamingJobGraphGenerator类中，入口函数是StreamingJobGraphGenerator.createJobGraph()。我们首先来看下StreamingJobGraphGenerator的核心源码：publicclassStreamingJobGraphGenerator{privateStreamGraph streamGraph;privateJobGraph jobGraph;// id -> JobVertexprivateMap<Integer, JobVertex> job ...继续阅读 (46)

本文所讨论的计算资源是指用来执行 Task 的资源，是一个逻辑概念。本文会介绍 Flink 计算资源相关的一些核心概念，如：Slot、SlotSharingGroup、CoLocationGroup、Chain等。并会着重讨论 Flink 如何对计算资源进行管理和隔离，如何将计算资源利用率最大化等等。理解 Flink 中的计算资源对于理解 Job 如何在集群中运行的有很大的帮助，也有利于我们更透彻地理解 Flink 原理，更快速地定位问题。Operator Chains为了更高效地分布式执行，Flink会尽可能地将operator的subtask链接（chain）在一起形成task。每个task在一个线程中执行。将operators链接成task是非常有效的优化：它能减少线程之间的切换，减少消息的序列化/反序列化，减少数据在缓冲区的交换，减少了延迟的同时提高整体的吞吐量。我们仍以经典的 WordCount 为例（参考前文Job例子），下面这幅图，展示了Source并行度为1，FlatMap、KeyAggregation、Sink并行度均为2，最终以5个并行的线程来执行的优化过程。上图中将KeyAggregation和Sink两个operator进行了合并，因为这两个合并后并不会改变整体的拓扑结构。但是，并不是任意两个 operator 就能 chain 一起的。其条件还是很苛刻的： ...继续阅读 (15)

继上文Flink 原理与实现：架构和拓扑概览中介绍了Flink的四层执行图模型，本文将主要介绍 Flink 是如何根据用户用Stream API编写的程序，构造出一个代表拓扑结构的StreamGraph的。注：本文比较偏源码分析，所有代码都是基于 flink-1.0.x 版本，建议在阅读本文前先对Stream API有个了解，详见官方文档。StreamGraph 相关的代码主要在org.apache.flink.streaming.api.graph包中。构造StreamGraph的入口函数是StreamGraphGenerator.generate(env, transformations)。该函数会由触发程序执行的方法StreamExecutionEnvironment.execute()调用到。也就是说 StreamGraph 是在 Client 端构造的，这也意味着我们可以在本地通过调试观察 StreamGraph 的构造过程。TransformationStreamGraphGenerator.generate的一个关键的参数是List<StreamTransformation<?>>。StreamTransformation代表了从一个或多个DataStream生成新DataStream的操作。DataStream的底层其实就是一个StreamT ...继续阅读 (9)

架构要了解一个系统，一般都是从架构开始。我们关心的问题是：系统部署成功后各个节点都启动了哪些服务，各个服务之间又是怎么交互和协调的。下方是 Flink 集群启动后架构图。当 Flink 集群启动后，首先会启动一个 JobManger 和一个或多个的 TaskManager。由 Client 提交任务给 JobManager，JobManager 再调度任务到各个 TaskManager 去执行，然后 TaskManager 将心跳和统计信息汇报给 JobManager。TaskManager 之间以流的形式进行数据的传输。上述三者均为独立的 JVM 进程。Client为提交 Job 的客户端，可以是运行在任何机器上（与 JobManager 环境连通即可）。提交 Job 后，Client 可以结束进程（Streaming的任务），也可以不结束并等待结果返回。JobManager主要负责调度 Job 并协调 Task 做 checkpoint，职责上很像 Storm 的 Nimbus。从 Client 处接收到 Job 和 JAR 包等资源后，会生成优化后的执行计划，并以 Task 的单元调度到各个 TaskManager 去执行。TaskManager在启动的时候就设置好了槽位数（Slot），每个 slot 能启动一个 Task，Task 为线程。从 JobManager 处接收需 ...继续阅读 (23)