流数据处理正处于蓬勃发展中，可以提供更实时的数据以实现更好的数据洞察，同时从数据中进行分析的流程更加简化。在现实世界中数据生产是一个连续不断的过程(例如，Web服务器日志，移动应用程序中的用户活跃，数据库事务或者传感器读取的数据)。正如其他人所指出的，到目前为止，大部分数据架构都是建立在数据是有限的、静态的这样的基本假设之上。为了缩减连续数据生产和旧”批处理”系统局限性之间的这一根本差距，引入了复杂而脆弱(fragile)的端到端管道。现代流处理技术通过以现实世界事件产生的形式对数据进行建模和处理，从而减轻了对复杂解决方案的依赖。
我们正在继续有关在Flink的帮助下实现实时日志聚合的博客系列。在本系列的《使用Flink进行实时日志聚合：第一部分》中，我们回顾了为什么从长期运行的分布式作业中实时收集和分析日志很重要。我们还研究了一种非常简单的解决方案，仅使用可配置的附加程序将日志存储在Kafka中。提醒一下，让我们再次检查管道
根据最新的统计显示，仅在过去的两年中，当今世界上90％的数据都是在新产生的，每天创建2.5万亿字节的数据，并且随着新设备，传感器和技术的出现，数据增长速度可能会进一步加快。 从技术上讲，这意味着我们的大数据处理将变得更加复杂且更具挑战性。而且，许多用例（例如，移动应用广告，欺诈检测，出租车预订，病人监护等）都需要在数据到达时进行实时数据处理，以便做出快速可行的决策。这就是为什么分布式流处理在大数据世界中变得非常流行的原因。
整体上来说的话，Flink 内部是基于 producer-consumer 模型来进行消息传递的，也正是 producer-consumer 模型的存在，Flink 能够实现完美的反压。要想更好的理解为什么 Flink 可以完美的实现反压，我们首先需要明白 Flink内部的 producer-consumer 模型，理解了模型，自然也就懂了反压。 我会用几张图来展示 Flink的 producer-consumer 模型。 我们以 WC 为例，这里盗用一下别人的图片，感谢，笔芯!
从 PrestoDB 0.275 版本开始，用户现在可以利用原生 Hudi 连接器来查询 Hudi 表。它与 Hive 连接器中的 Hudi 支持相当。要了解有关连接器使用的更多信息，请查看 prestodb 文档[1]。
Flink对分布式任务的执行操作，它是把操作子任务链起来放到任务中。每个任务由一个线程来执行。把操作链起来放入任务中是非常好的一个优化：它可以减少线程间交互和缓存的开销，减少延迟的同时提升整体的吞吐量。链操作的方式是可以配置的，在链操作文档中有详细的介绍chaining docs 。
AI前线导读：本文是 **Apache Beam实战指南系列文章** 的第二篇内容，将重点介绍 Apache Beam与Flink的关系，对Beam框架中的KafkaIO和Flink源码进行剖析，并结合应用示例和代码解读带你进一步了解如何结合Beam玩转Kafka和Flink。系列文章第一篇回顾Apache Beam实战指南之基础入门
Apache Hudi 0.13.0引入了一系列新特性，包括Metaserver, Change Data Capture, new Record Merge API, new sources for Deltastreamer等。虽然此版本不需要表版本升级，但希望用户在使用 0.13.0 版本之前按照下面的迁移指南采取相关重大更改和行为更改的操作。
在本文中，我们将深入探讨Flink新颖的检查点机制是如何工作的，以及它是如何取代旧架构以实现流容错和恢复。我们在各种类型的流处理应用程序上对Flink性能进行测试，并通过在Apache Storm（一种广泛使用的低延迟流处理器）上运行相同的实验来进行对比。
之前有想过系统地来一番flink源码分析系列，谁曾想工作中需要完成的需求有些多，完整的flink源码分析系列只能一再往后拖了。之前公众号后台有想学习flink的朋友留言想看更多学习flink的资料，现在先发一些之前收藏的关于flink相关的文章，其中大多翻译自flink社区，希望能给大家带来一些帮助。本文[1]主要围绕flink任务的生命周期展开。
随着大数据时代的到来，数据量动辄PB级，因此亟需一种低成本、高稳定性的实时数仓解决方案来支持海量数据的OLAP查询需求，Apache Hudi[1]应运而生。Hudi借助与存放在廉价的分布式文件系统之中列式存储文件，并将其元数据信息存放在Hive元数据库中与传统查询引擎Hive、Presto、Spark等整合，完美地实现了计算与存储的分离。Hudi数据湖方案比传统的Hive数仓的优势是加入了数据实时同步功能， 可以通过最新的Flink流计算引擎来以最小的成实现数据实时同步。本质来说Hudi是整合现有的技术方案实现的，属于新瓶装旧酒，Hudi内部需要整合各种组件（存储、Indexer、Compaction，文件分区），为了达到通用及灵活性，每个组件会有大量的配置参数需要设置，且各种组件 的配置是有关联性的，所以对与新手来说要构建一个生产环境中可用的数据库方案，面对一大堆配置往往会望而却步。本文就向大家介绍如何通过TIS来改善Hudi数据湖实例构建流程，从而大幅提高工作效率。
Flink Forward，给了我一个绝佳的机会，向全球 Apache Flink 社区介绍微博如何使用 Apache Flink 在我们的平台上运行实时数据处理和机器学习。在以下各节中，我将向您介绍微博，并将描述我们的机器学习平台的体系结构以及我们如何使用Apache Flink开发实时机器学习管道。最后，我将解释我们如何计划在微博上扩展 Flink 的用途，并简要了解我们在组织中使用开源技术的经验。
Using Flink to inspect live data as it flows through a data pipeline -- Matthew Dailey(Splunk)
例：flink run -m yarn-cluster -yd -yjm 1024m -ytm 1024m -ynm -ys 1
人们经常会问Flink是如何处理背压(backpressure)效应的。 答案很简单：Flink不使用任何复杂的机制，因为它不需要任何处理机制。它只凭借数据流引擎，就可以从容地应对背压。在这篇博文中，我们介绍一下背压。然后，我们深入了解 Flink 运行时如何在任务之间传送缓冲区中的数据，并展示流数传输自然双倍下降的背压机制(how streaming data shipping naturally doubles down as a backpressure mechanism)。 我们最终通过一个小实验展示了这一点。
ApacheFlink努力为所有现成的应用程序自动导出合理的默认资源需求。对于希望根据特定场景的知识微调资源消耗的用户，Flink提供细粒度资源管理。
https://flink.apache.org/zh/usecases.html
Creating millions of user sessions using Complex Event Processing -- Prem Santosh & Udaya Shankar(Yelp)
Apache Flink是一个框架和分布式处理引擎，用于对无界和有界数据流进行状态计算。 Flink设计为在所有常见的集群环境中运行，以内存速度和任何规模执行计算。
Building production Flink jobs with Airstream at Airbnb
在 Shopify 中，我们将Apache Flink作为标准的有状态流媒体引擎，为我们的BFCM Live Map等各种用例提供支持。我们的 Flink 应用程序部署在利用Google Kubernetes Engine的 Kubernetes 环境中。我们的集群采用配置使用高可用性模式，配置任务管理为故障点。我们还为我们使用状态保存器作为我们使用的检查点和点写入谷歌云存储（GCS）。
在伴鱼，我们在多个在线场景使用机器学习提高用户的使用体验，例如：在伴鱼绘本中，我们根据用户的帖子浏览记录，为用户推荐他们感兴趣的帖子；在转化后台里，我们根据用户的绘本购买记录，为用户推荐他们可能感兴趣的课程等。
👆关注“博文视点Broadview”，获取更多书讯 以下内容节选自《Flink实战派》一书！ ---- --正文-- 大数据技术和人工智能（机器学习）的结合，使利用数据价值的技术有了新的突破。 在通常情况下，大数据技术与机器学习是互相促进、相依相存的关系。 01 大数据和机器学习之间的关系 机器学习不仅需要合理、适用和先进的算法，还需要依赖足够好和足够多的数据。 大数据可以提高机器学习模型的精确性。 数据的数据量越多，质量越高，机器学习的效率和准确性就越高。机器学习是大数据分析的一个重要方向（方式）。
在定义数据处理管道时，Table API 和 DataStream API 同样重要。
Beam可以解决什么问题？当MapReduce作业从Hadoop迁移到Spark或Flink，就需要大量的重构。Dataflow试图成为代码和执行运行时环境之间的一个抽象层。代码用Dataflow SDK实施后，会在多个后端上运行，比如Flink和Spark。Beam支持Java和Python，与其他语言绑定的机制在开发中。它旨在将多种语言、框架和SDK整合到一个统一的编程模型。
Flink文档：https://ci.apache.org/projects/flink/flink-docs-release-1.12/
Flink四大基石分别是：Time （时间）、Window（窗口）、State （状态）、Checkpoint（检查点）。
我们在Cloudflare的一个大规模数据基础架构挑战是为我们的客户提供HTTP流量分析。我们所有客户都可以通过两种方式使用HTTP分析：
前一阵痴迷于calcite，打算写一些streaming sql相关的东西，正好时逢置办年货，就买了本书《Flink基础教程》，打开看了一下，就放不下了，一口气都看完了，书不厚，很薄的一本小册子，有种醍醐灌顶的感觉，回想起9月份写的《阿卡姆科普报告——Flink》未免有些稚嫩......
Flink CDC [1] 是基于数据库的日志 CDC 技术，实现了全增量一体化读取的数据集成框架。配合 Flink 优秀的管道能力和丰富的上下游生态，Flink CDC 可以高效实现海量数据的实时集成。
我们非常高兴的宣布 Apache Celeborn（Inclubating）[1]正式支持 Flink，Celeborn 于去年 12 月份正式进入 Apache 软件基金会 (ASF) 的孵化器，一直致力打造统一的中间数据服务，助力引擎全方位提升性能、稳定性和弹性，最新发布的 0.3.0 版本新增对 Flink 批作业 Shuffle 的支持，从此 Flink、Spark 可以同时使用统一的数据 Shuffle 服务，更大程度节省资源、降低运维成本。
Pinterest是世界上最大的图片社交分享网站。网站允许用户创建和管理主题图片集合,例如事件、兴趣和爱好。以下为来自Pinterest工程师关于代码审查的一些思考。
作为目前最为高效的流处理框架之一，Flink在我们的大数据平台产品中得到了广泛运用。为了简化开发，我们对Flink做了一些封装，以满足我们自己的产品需求。
作者 | 陈易生 前言 在伴鱼，我们在多个在线场景使用机器学习提高用户的使用体验，例如：在伴鱼绘本中，我们根据用户的帖子浏览记录，为用户推荐他们感兴趣的帖子；在转化后台里，我们根据用户的绘本购买记录，为用户推荐他们可能感兴趣的课程等。 特征是机器学习模型的输入。如何高效地将特征从数据源加工出来，让它能够被在线服务高效地访问，决定了我们能否在生产环境可靠地使用机器学习。为此，我们搭建了特征系统，系统性地解决这一问题。目前，伴鱼的机器学习特征系统运行了接近 100 个特征，支持了多个业务线的模型对在线获取特征的
本文将深入探讨Flink实时流处理框架的原理、应用，以及面试必备知识点与常见问题解析，助你在面试中展现出深厚的Flink技术功底。
每个大型企业组织都在尝试加速其数字化转型战略，以更加个性化、相关和动态的方式与客户互动。在创建和收集数据时对数据执行分析（也称为实时数据流）并生成即时洞察以加快决策制定的能力为组织提供了竞争优势。
Apache Flink是用于可扩展流和批数据处理的开源平台，它提供了富有表现力的API来定义批和流数据程序，以及一个强大的可扩展的引擎来执行这些作业。
Sherlock.IO是eBay现有的监控平台，每天要处理上百亿条日志、事件和指标。Flink Streaming job实时处理系统用于处理其中的日志和事件。本文将结合监控系统Flink的现状，具体讲述Flink在监控系统上的实践和应用，希望给同业人员一些借鉴和启发。
数据湖是大数据领域近年来非常火热的技术，传统数仓无法实现增量数据的实时更新，也无法支持灵活的元数据格式，数据湖技术便在这一背景下诞生了。数据库的增量变更是数据湖中增量数据的主要来源，但目前 TiDB 的入湖路径还比较割裂，全量变更用 Dumpling 组件，增量变更用 TiCDC 组件。两者处于割裂的链路， TiDB 也无法通过实时物化视图完成数据入湖的实时清洗和加工。
大数据技术中常见的大数据实时计算引擎有Spark、Storm、Flink等，目前有很多公司已经将计算任务从旧系统 Storm 迁移到 Flink。
PyFlink就是Apache Flink与Python的组合，或者说是Python上的Flink。两者的结合意味着您可以在Python中使用Flink的所有功能。
状态可以存储在Java的堆内或堆外。根据你的状态终端，Flink 也可以管理应用程序的状态，这意味着 Flink 可以处理内存管理（可能会溢出到磁盘，如果有必要），以允许应用程序存储非常大的状态。默认情况下，配置文件 flink-conf.yaml 为所有Flink作业决定其状态终端。
反压机制（BackPressure）被广泛应用到实时流处理系统中，流处理系统需要能优雅地处理反压（backpressure）问题。反压通常产生于这样的场景：短时负载高峰导致系统接收数据的速率远高于它处理数据的速率。许多日常问题都会导致反压，例如，垃圾回收停顿可能会导致流入的数据快速堆积，或者遇到大促或秒杀活动导致流量陡增。反压如果不能得到正确的处理，可能会导致资源耗尽甚至系统崩溃。反压机制就是指系统能够自己检测到被阻塞的Operator，然后系统自适应地降低源头或者上游的发送速率。目前主流的流处理系统 Apache Storm、JStorm、Spark Streaming、S4、Apache Flink、Twitter Heron都采用反压机制解决这个问题，不过他们的实现各自不同。
Yelp 公司 采用 Apache Beam 和 Apache Flink 重新设计了原来的数据流架构。该公司使用 Apache 数据流项目创建了统一而灵活的解决方案，取代了将交易数据流式传输到其分析系统（如 Amazon Redshift 和内部数据湖）的一组分散的数据管道。
后台很多小伙伴都在问Flink的学习路径，那么我们在学习Flink的时候，到底重点学习哪些东西呢？
Apache Hudi填补了在DFS上处理数据的巨大空白，并可以和一些大数据技术很好地共存。然而，将Hudi与一些相关系统进行对比，来了解Hudi如何适应当前的大数据生态系统，并知晓这些系统在设计中做的不同权衡仍将非常有用。
除了看过两周 Flink 外，其他的框架都没有接触过，只是简单的拿来用一下，也并不是很了解，所以本篇教程如果有什么错误，欢迎指出。
Flink 1.5.0 是 1.x.y 系列的第六个主要版本。与往常一样，它兼容之前 1.x.y 版本中使用 @Public 注解标注过的 API。
The Trade Desk's Year in Flink--Jonathan Miles
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
对象存储
即时通信 IM
