Flink 是一个面向分布式数据流处理和批量数据处理的开源计算平台。和 Spark 类似，两者都希望提供一个统一功能的计算平台给用户，都在尝试建立一个统一的平台以运行批量，流式，交互式，图处理，机器学习等应用。
FlinkX是一款基于Flink的分布式离线/实时数据同步插件，可实现多种异构数据源高效的数据同步，其由袋鼠云于2016年初步研发完成，目前有稳定的研发团队持续维护，已在Github上开源（开源地址详见文章末尾），并维护该开源社区。目前已完成批流统一，离线计算与流计算的数据同步任务都可基于FlinkX实现。
我们在Flink重点难点：状态(Checkpoint和Savepoint)容错与两阶段提交一文中对Flink的Checkpoint做过详细的介绍。
摘要：本文介绍了 Dlink 的 Roadmap，站在巨人肩膀上的它，是否真的未来可期？内容包括：
在数仓ETL、实时计算的场景下，我们基于Flink SQL批流一体的框架进行了一定规模的作业迁移。在研发作业管理系统中，我们引入Apache Zeppelin组件作为Flink SQL作业提交客户端，Flink 批流作业可视化预览的核心组件。在一年多时间的产线实践中，我们对作业提交的方式策略进行了几次演进，目前在跑作业规模Flink Batch 任务日均运行超5000次，流作业500+，均稳定运行。
Apache Flink 是一个框架和分布式处理引擎，用于对无边界和有边界的数据流进行有状态的计算。Flink被设计为可以在所有常见集群环境中运行，并能以内存速度和任意规模执行计算。目前市场上主流的流式计算框架有Apache Storm、Spark Streaming、Apache Flink等，但能够同时支持低延迟、高吞吐、Exactly-Once（收到的消息仅处理一次）的框架只有Apache Flink。
随着近来越来越多的业务迁移到 Flink 上，对 Flink 作业的准确性要求也随之进一步提高，其中最为关键的是如何在不同业务场景下保证 exactly-once 的投递语义。虽然不少实时系统（e.g. 实时计算/消息队列）都宣称支持 exactly-once，exactly-once 投递似乎是一个已被解决的问题，但是其实它们更多是针对内部模块之间的信息投递，比如 Kafka 生产（producer 到 Kafka broker）和消费（broker 到 consumer）的 exactly-once。而 Flink 作为实时计算引擎，在实际场景业务会涉及到很多不同组件，由于组件特性和定位的不同，Flink 并不是对所有组件都支持 exactly-once（见[1]），而且不同组件实现 exactly-once 的方法也有所差异，有些实现或许会带来副作用或者用法上的局限性，因此深入了解 Flink exactly-once 的实现机制对于设计稳定可靠的架构有十分重要的意义。
4）在perJob模式下，最终调用的是YarnJobClusterEntrypoint
场景描述：作为分布式系统，尤其是对延迟敏感的实时计算引擎，Apache Flink 需要有强大的容错机制，以确保在出现机器故障或网络分区等不可预知的问题时可以快速自动恢复并依旧能产生准确的计算结果。
整个架构图分为三层，从下往上看，最下面一层是数据安全，包括受限域认证系统、加工层权限系统，应用层权限系统，安全审计系统，来保证最上层数据集成与处理的安全；
在Flink状态管理详解这篇文章中，我们介绍了Flink的状态都是基于本地的，而Flink又是一个部署在多节点的分布式引擎，分布式系统经常出现进程被杀、节点宕机或网络中断等问题，那么本地的状态在遇到故障时如何保证不丢呢？Flink定期保存状态数据到存储上，故障发生后从之前的备份中恢复，整个被称为Checkpoint机制，它为Flink提供了Exactly-Once的投递保障。本文将介绍Flink的Checkpoint机制的原理。本文会使用多个概念：快照（Snapshot）、分布式快照（Distributed Snapshot）、检查点（Checkpoint）等，这些概念均指的是Flink的Checkpoint机制，读者可以将这些概念等同看待。
摘要：本文由美团研究员、实时计算负责人鞠大升分享，主要介绍 Flink 助力美团数仓增量生产的应用实践。内容包括：
Flink是使用Kafka链接计算任务,利用kafka的exactly once实现流计算的不重不丢,而Kafka 的 Exactly Once 语义是通过它的事务和生产幂等两个特性来共同实现的
ChunJun（原FlinkX）是一个基于Flink提供易用、稳定、高效的批流统一的数据集成工具，是袋鼠云一站式大数据开发平台-数栈DTinsight的核心计算引擎，其技术架构基于实时计算框架Flink，打造出“具有袋鼠特色”的实时计算引擎。
一，抽象层次 Flink提供不同级别的抽象来开发流/批处理应用程序。 1，stateful streaming 最底层。它通过Process Function嵌入到DataStream API中。它允
嘉宾 ｜ 付海涛 编辑 ｜ 贾亚宁 Apache Flink 功能强大，支持开发和运行多种不同种类的应用程序。事实证明，Flink 已经可以扩展到数千核心，其状态可以达到 TB 级别，且仍能保持高吞吐、低延迟的特性。出于对云原生和 Flink 之间的关系，以及最新提出的流式数仓这个概念的好奇，我们特意邀请了付海涛老师。 付海涛老师目前在京东担任资深技术专家，日常工作包含 Flink 引擎的优化增强、容器环境任务的优化和智能运维等，一起来看看他的独家理解吧。 一、如何快速恢复作业 我们日常的工作中，
Apache Flink 作为流计算引擎，需要持续从上游接收数据流，并向下游输出最新的计算结果。Connector 起到承上启下的作用：Source 负责与上游的 MQ、数据库等源表对接，Sink 则写入各类数据库、数仓、数据湖等目的表。因此，Connector 是 Flink 连接外部生态的桥梁，也是影响作业吞吐量的重要因素之一。
作为 Flink 最基础也是最关键的容错机制，Checkpoint 快照机制很好地保证了 Flink 应用从异常状态恢复后的数据准确性。
引言：Apache Flink 作为流计算引擎，需要持续从上游接收数据流，并向下游输出最新的计算结果。Connector 起到承上启下的作用：Source 负责与上游的 MQ、数据库等源表对接，Sink 则写入各类数据库、数仓、数据湖等目的表。因此，Connector 是 Flink 连接外部生态的桥梁，也是影响作业吞吐量的重要因素之一。 Flink CDC Connectors 作为 Flink 生态的当红明星，切切实实的抓住了实时数据同步（ETL）的痛点，因此广受欢迎。自从 2.0 新版发布以来，它通过
采访嘉宾｜王峰（莫问） 作者 | Tina 作为最活跃的大数据项目之一，Flink 进入 Apache 软件基金会顶级项目已经有八年了。 Apache Flink 是一款实时大数据分析引擎，同时支持流批执行模式，并与 Hadoop 生态可以无缝对接。2014 年，它被接纳为 Apache 孵化器项目，仅仅几个月后，它就成为了 Apache 的顶级项目。 对于 Flink 来说，阿里有非常适合的流式场景。作为 Flink 的主导力量，阿里从 2015 年开始调研 Flink，并于 2016 年第一次在搜
Flink 通过 org.apache.flink.core.fs.FileSystem 类有自己的文件系统抽象。 这种抽象提供了一组通用的操作和跨各种类型的文件系统实现的最小保证。
本文来自9月1日在成都举行的Apache Flink China Meetup，分享来自于云邪。
作者：黄龙，腾讯 CSIG 高级工程师 数据时代，企业对技术创新和服务水准的要求不断提高，数据已成为企业极其重要的资产。无论是在在企业数据中台的建设，亦或者是打造一站式数据开发和数据治理的PASS平台。首先需要做的就是进行跨应用的数据融合计算，需要将数据从孤立的数据源中采集出来，汇集到可被计算平台高效访问的目的地。此过程称之为ETL。通常所说的同步大致分为离线全量ETL、离线增量+离线全量的ETL、实时增量+离线全量ETL、实时增量ETL4种方式。数据同步成为企业数据开发和使用一个绕不过去的技术需求。业内也
数据时代，企业对技术创新和服务水准的要求不断提高，数据已成为企业极其重要的资产。无论是在在企业数据中台的建设，亦或者是打造一站式数据开发和数据治理的PASS平台。 首先需要做的就是进行跨应用的数据融合计算，需要将数据从孤立的数据源中采集出来，汇集到可被计算平台高效访问的目的地。此过程称之为ETL。通常所说的同步大致分为离线全量ETL、离线增量+离线全量的ETL、实时增量+离线全量ETL、实时增量ETL4种方式。 数据同步成为企业数据开发和使用一个绕不过去的技术需求。业内也存在大量的开源的解决方案。 在数据集成技术选型中，我们需要考虑的因素有哪些？主流开源方案中各自的优缺点有哪些？目前备受瞩目和推崇 Flink CDC ETL 是否能作为线上主力同步工具之一，它的优势有哪些？原理是什么？本文主要围绕以上几个疑问，进行论述。
面对霸气侧漏的业务需求，由于没有大数据知识储备，咱心里没底，咱也不敢问，咱也不敢说，只能静下来默默储备、默默寻觅解决方案。
最近flink真是风生水起，但是浪院长看来这不过是阿里错过了创造spark影响力之后，想要在flink领域创建绝对的影响力。但是，不可否认flink在实时领域确实目前来看独树一帜，当然也有它不适合的地方，比如今天要推荐的第一个基于flink开发的项目，流表和维表的join，还有很多地方还是用spark streaming更合适，但是整体的流处理而言flink确实很优秀，虽然目前测出了一些bug，后面会发文说明一下flink开发时候常见的坑和已有的自身bug。接下来转入正题。
摘要：本文整理自 StarRocks 社区技术布道师谢寅，在 Flink Forward Asia 2022 实时湖仓的分享。本篇内容主要分为五个部分：
CDC全称是Change Data Capture，我们通常将能够捕获数据变更的技术称为CDC。目前通常描述的CDC技术主要面向数据库的变更，是一种用于捕获数据库中数据的变更技术。CDC的技术应用场景有数据同步、数据分发、数据集成等。
基于流计算的基本模型，当前已有各式各样的分布式流处理系统被开发出来。本节将对当前开源分布式流处理系统中三个最典型的代表性的系统：Apache Storm，Spark Streaming，Apache Flink以及它们的编程模型进行详细介绍。
同年FlinkX、FlinkStreamSQL相继上线，经过三年的发展，Star数分别达到2.2k和1.5k，位列Flink生态领域前茅，获得广泛的社区支持。
ApacheFlink是一个面向分布式数据流处理和批量数据处理的开源计算平台，它能够基于同一个Flink运行时，提供支持流处理和批处理两种类型应用的功能。
剩喜漫天飞玉蝶，不嫌幽谷阻黄莺。2020 年是不寻常的一年，Flink 也在这一年迎来了新纪元。
它扮演的是集群管理者的角色，负责调度任务、协调 checkpoints、协调故障恢复、收集 Job 的状态信息，并管理 Flink 集群中的从节点 TaskManager。
主要讲解了技术原理，入门与生产实践，主要功能：全增量一体化数据集成、实时数据入库入仓、最详细的教程。Flink CDC 是Apache Flink的一个重要组件，主要使用了CDC技术从各种数据库中获取变更流并接入到Flink中，Apache Flink作为一款非常优秀的流处理引擎，其SQL API又提供了强大的流式计算能力，因此结合Flink CDC能带来非常广阔的应用场景。例如，Flink CDC可以代替传统的Data X和Canal工具作为实时数据同步，将数据库的全量和增量数据同步到消息队列和数据仓库中。也可以做实时数据集成，将数据库数据实时入湖入仓。还可以做实时物化视图，通过SQL对数据做实时的关联、打宽、聚合，并将物化结果写入到数据湖仓中。
摘要：本文总结了 Dinky 社区在 Doris Summit 2022 上分享的《Dinky 在Doris实时整库同步和模式演变的探索实践》，其分享主要分为四个章节，内容包括：
说明：本文分为四个部分内容：背景、Chandy_Lamport算法、Flink Checkpoint对齐机制和总结。
Apache Flink是用于分布式流和批处理数据处理的开源平台。Flink的核心是流数据流引擎，可为数据流上的分布式计算提供数据分发，通信和容错能力。Flink在流引擎之上构建批处理，覆盖了本机迭代支持，托管内存和程序优化。本文档适用于Apache Flink 1.10版。
Apache Flink 功能强大，支持开发和运行多种不同种类的应用程序，是业界公认的性能优异的大数据实时计算引擎之一。事实证明，Flink 已经可以扩展到数千核心，其状态可以达到 TB 级别，且仍能保持高吞吐、低延迟的特性。在全球范围内，越来越多的公司开始使用 Flink，在国内比较知名的互联网公司如阿里巴巴、字节跳动、京东、美团等，都在大规模使用 Flink 作为企业的分布式大数据处理引擎。
总结一下，本文介绍了10种常见的 CDC 组件和方案，个人觉得还不错，如果还有其他好用的 CDC 组件，欢迎在评论区分享分享。
分布式有状态流处理支持在云中部署和执行大规模连续计算，主要针对低延迟和高吞吐量。这种模式的一个最根本的挑战就是在可能的失败情况下提供处理保证。现有方法依赖于可用于故障恢复的周期性全局状态快照。这些方法有两个主要缺点。首先，他们经常拖延影响数据摄取的整体计算过程。其次，持久化存储所有传输中的记录以及算子状态，这会导致比所需的快照要更大。
摘要：本文整理自 Apache Flink PMC 李劲松（之信）在 9 月 24 日 Apache Flink Meetup 的分享。主要内容包括：
本文整理自 Dinky 实时计算平台 Maintainer 亓文凯老师在 Apache Doris & Apache SeaTunnel 联合 meetup 的实践分享，通过 Doris + Flink + DolphinScheduler + Dinky 构建开源数据平台。
对于一个分布式计算引擎（尤其是7*24小时不断运行的流处理系统）来说，由于机器故障、数据异常等原因导致作业失败的情况是时常发生的，因此一般的分布式计算引擎如Hadoop、Spark都会设计状态容错机制确保作业失败后能够恢复起来继续运行，而新一代的流处理系统Flink在这一点上更有着优秀而简约的设计。
github 地址：https://github.com/DataLinkDC/dlink
目前 Flink 社区正如火如荼的发展，但苦于没有一款适合 Flink SQL 界面化开发的工具，于是增加了 Flink 的门槛与成本。虽然官方提供了 SQL Client，但仍有很多局限与不方便。
Hadoop是目前应用最为广泛的分布式大数据处理框架，其具备可靠、高效、可伸缩等特点。
本文将以WordCount的案例为主线，主要介绍Flink的设计和运行原理。关于Flink WordCount程序可以参考我之前的文章：读取Kafka实时数据流，实现Flink WordCount。阅读完本文后，读者可以对Flink的分布式运行时有一个全面的认识。
Flink Remote Shuffle 的提出与实现，源自我们观察到的用户对流批一体与云原生日益增加的需求。
ChunJun（原 FlinkX）是一个基于 Flink 提供易用、稳定、高效的批流统一的数据集成工具。2018 年 4 月，秉承着开源共享的理念，数栈技术团队在 github 上开源了 FlinkX，承蒙各位开发者的合作共建，FlinkX 得到了快速发展。
领取专属 10元无门槛券
手把手带您无忧上云
