weixin_42073629的博客

背景介绍本文将介绍如何将 TiDB 中的数据，通过 TiCDC 导入到 Kafka 中，继而被 Flink 消费的案例。为了能够快速的验证整套流程的功能性，所有的组件都以单机的形式部署。如果需要在生产环境中部署，建议将每一个组件替换成高可用的集群部署方案。其中，我们单独创建了一套 Zookeeper 单节点环境，Flink、Kafka、等组件共用这个 Zookeeper 环境。针对于所有需要 JRE 的组件，如 Flink，Kafka，Zookeeper，考虑到升级 JRE 可能会影响到其他

背景介绍本文将介绍如何将 MySQL 中的数据，通过 Binlog + Canal 的形式导入到 Kafka 中，继而被 Flink 消费的案例。为了能够快速的验证整套流程的功能性，所有的组件都以单机的形式部署。如果手上的物理资源不足，可以将本文中的所有组件搭建在一台 4G 1U 的虚拟机环境中。如果需要在生产环境中部署，建议将每一个组件替换成高可用的集群部署方案。其中，我们单独创建了一套 Zookeeper 单节点环境，Flink、Kafka、Canal 等组件共用这个 Zookeeper

当一个应用程序需求比较简单的情况下，数据转换涉及的 operator（算子）可能不多，但是当应用的需求变得越来越复杂时，可能在一个 Job 里面算子的个数会达到几十个、甚至上百个，在如此多算子的情况下，整个应用程序就会变得非常复杂，所以在编写 Flink Job 的时候要是能够随时知道 Job 的执行计划那就很方便了。刚好，Flink 是支持可以获取到整个 Job 的执行计划的，另外 Flink 官网还提供了一个可视化工具 visualizer（可以将执行计划 JSON 绘制出执行图），如下图所示。

介绍在本系列的前两篇文章中，我们描述了如何基于动态更新配置（欺诈检测规则）来实现灵活的数据流分区，以及如何利用 Flink 的 Broadcast 机制在运行时在相关算子之间分配处理配置。直接跟上我们上次讨论端到端解决方案的地方，在本篇文章中，我们将描述如何使用 Flink 的 "瑞士军刀" —— Process Function 来创建一个量身定制的实现，以满足你的流业务逻辑需求。我们的讨论将在欺诈检测引擎的背景下继续进行，我们还将演示如何在 DataStream API 提供的窗口不能满足你的要

1、Checkpoint失败：Checkpoint expired before completing原因是因为checkpointConf.setCheckpointTimeout(8000L)设置的太小了，默认是10min，这里只设置了8sec。当一个Flink App背压的时候（例如由外部组件异常引起），Barrier会流动的非常缓慢，导致Checkpoint时长飙升。2、资源隔离建议在Flink中，资源的隔离是通过Slot进行的，也就是说多个Slot会运行在同一个JVM中

Top-NTop-N是我们应用Flink进行业务开发时的常见场景，传统的DataStream API已经有了非常成熟的实现方案，如果换成Flink SQL，又该怎样操作？好在Flink SQL官方文档已经给出了标准答案，我们只需要照抄就行，其语法如下：SELECT [column_list]FROM ( SELECT [column_list], ROW_NUMBER() OVER ([PARTITION BY col1[, col2...]] ORDER BY c

前言在上一篇博客中，我们对欺诈检测引擎的目标和所需要的功能进行了描述，我们还描述了如何基于可修改的规则而不是使用硬编码的 KeysExtractor 实现 Flink 应用程序的数据自定义分区。我们在上篇博客中特意省略了有关如何初始化应用的规则以及如何在作业运行时更新的细节，在本文我们将详细的介绍这些细节，你将学习如何将上篇博客中描述的数据分区防御与动态配置结合使用，当这两种模式结合使用的时候，可以省去重新编译代码和重新部署 Flink 作业的需要，从而可以应对多种业务场景逻辑修改的情况。广播规

前言在本系列博客中，你将学习到三种构建 Flink 应用程序的强大案例： 动态更新应用程序的逻辑 动态的数据分区（shuffle），在作业运行时进行控制 基于自定义窗口逻辑的低延迟告警（不使用 Window API） 这几个案例扩展了使用静态定义的数据流可以实现的功能，并提供了满足复杂业务需求的基础。动态更新应用程序的逻辑允许作业在运行时进行更改，不需要将作业停止后修改代码再发布。动态的数据分区为运行中的 Flink 作业作业提供了动态地将数据分组（group ..

基于Flink构建流批一体的实时数仓是目前数据仓库领域比较火的实践方案。随着Flink的不断迭代，其提供的一系列技术特性使得用户构建流批一体的应用变得越来越方便。本文将以Flink1.12为例，一一介绍这些特性的基本使用方式，主要包括以下内容： Flink集成Hive Hive Catalog与Hive Dialect Flink读写Hive Flink upsert-kafka连接器 Flink CDC的connector Flink集成Hive使用H

在使用 Flink 中不知道你有没有觉得配置的管理很不方便，比如像算子的并行度配置、Kafka 数据源的配置（broker 地址、topic 名、group.id）、Checkpoint 是否开启、状态后端存储路径、数据库地址、用户名和密码等，反正各种各样的配置都杂乱在一起，当然你可能说我就在代码里面写死不就好了，但是你有没有想过你的作业是否可以不修改任何配置就直接在各种环境（开发、测试、预发、生产）运行呢？可能每个环境的这些配置对应的值都是不一样的，如果你是直接在代码里面写死的配置，那这下子就比较痛苦了，

一、简介flink-streaming-platform-web系统是基于flink封装的一个可视化的web系统，用户只需在web界面进行sql配置就能完成流计算任务，主要功能包含任务配置、启/停任务、告警、日志等功能。目的是减少开发，完全实现 flink-sql 流计算任务，flink 任务支持单流、双流、单流与维表等，支持本地模式、yarn-per模式、STANDALONE模式。支持udf、自定义连接器等,完全兼容官方连接器目前flink版本已经升级到1.12效果图.

一．背景及痛点如图 1 所示，这是当前已经助力的一些内部应用的用户，其中小程序和视频号这两款应用每天或者每个月产生的数据量都在 PB 级或者 EB 级以上。图1这些应用的用户在构建他们自己的数据分析平台过程中，他们往往会采用图 2 这样的一个架构，相信大家对这个架构也非常的熟悉了。1.数据平台架构业务方比如腾讯看点或者视频号的用户，他们通常会采集应用前端的业务打点数据以及应用服务日志之类的数据，这些数据会通过消息中间件（Kafka/RocketMQ）或者数据同步服务(flume/..

前言阿里的双11销量大屏可以说是一道特殊的风景线。实时大屏（real-time dashboard）正在被越来越多的企业采用，用来及时呈现关键的数据指标。并且在实际操作中，肯定也不会仅仅计算一两个维度。由于Flink的“真·流式计算”这一特点，它比Spark Streaming要更适合大屏应用。本文从笔者的实际工作经验抽象出简单的模型，并简要叙述计算流程（当然大部分都是源码）。数据格式与接入简化的子订单消息体如下。{ "userId": 234567, "ord..

Sherlock.IO 是 eBay 现有的监控平台，每天要处理上百亿条日志、事件和指标。Flink Streaming job 实时处理系统用于处理其中的日志和事件。本文将结合监控系统 Flink 的现状，具体讲述 Flink 在监控系统上的实践和应用，希望给同业人员一些借鉴和启发。监控系统 Flink 的现状eBay 的监控平台 Sherlock.IO 每天处理着上百亿条日志（log），事件（event）和指标（metric）。通过构建 Flink Streaming job 实时处理系

滴滴的核心业务是一个实时在线服务，因此具有丰富的实时数据和实时计算场景。本文将介绍滴滴实时计算发展之路以及平台架构实践。实时计算演进随着滴滴业务的发展，滴滴的实时计算架构也在快速演变。到目前为止大概经历了三个阶段： 业务方自建小集群阶段； 集中式大集群、平台化阶段； SQL化阶段。 下图标识了其中重要的里程碑，稍后会给出详细阐述：在2017年以前，滴滴并没有统一的实时计算平台，而是各个业务方自建小集群。其中用到的引擎有Storm、JStorm、Spark Str

随着云计算、大数据等新一代IT技术在各行业的深入应用，政企机构IT规模和复杂程度不断提高，网络流量、日志等各类数据规模大幅提升。与此同时，网络攻防日益激烈，网络安全威胁逐渐凸显出来，这对于SOC/SIEM产品的性能提出了一个很大的挑战。因此，奇安信独立研发了国内首款流式分布式关联分析引擎Sabre，搭载于公司旗下态势感知与安全运营平台（下文简称NGSOC），从而大幅提升NGSOC的数据分析能力和网络安全检测能力。本文将从技术研发的角度，全面阐述Sabre的由来。1.Sabre是什么？Sabre是

58 同城作为覆盖生活全领域的服务平台，业务覆盖招聘、房产、汽车、金融、二手及本地服务等各个方面。丰富的业务线和庞大的用户数每天产生海量用户数据需要实时化的计算分析，实时计算平台定位于为集团海量数据提供高效、稳定、分布式实时计算的基础服务。本文主要介绍 58 同城基于 Flink 打造的一站式实时计算平台 Wstream。实时计算场景和很多互联网公司一样，实时计算在 58 拥有丰富的场景需求，主要包括以下几类：实时数据 ETL：实时消费 Kafka 数据进行清洗、转换、结构化处理用于下游计算处理

众所周知，Flink 是当前最为广泛使用的计算引擎之一，它使用 Checkpoint 机制进行容错处理 [1]，Checkpoint 会将状态快照备份到分布式存储系统，供后续恢复使用。在 Alibaba 内部，我们使用的存储主要是 HDFS，当同一个集群的 Job 到达一定数量后，会对 HDFS 造成非常大的压力，本文将介绍一种大幅度降低 HDFS 压力的方法——小文件合并。背景不管使用 FsStateBackend、RocksDBStateBackend 还是 NiagaraStateBacken

一、Lyft 的流数据与场景关于 LyftLyft 是位于北美的一个共享交通平台，和大家所熟知的 Uber 和国内的滴滴类似，Lyft 也为民众提供共享出行的服务。Lyft 的宗旨是提供世界最好的交通方案来改善人们的生活。Lyft 的流数据场景Lyft 的流数据可以大致分为三类，秒级别、分钟级别和不高于 5 分钟级别。分钟级别流数据中，自适应定价系统、欺诈和异常检测系统是最常用的，此外还有 Lyft 最新研发的机器学习特征工程。不高于 5 分钟级别的场景则包括准实时数据交互查...

数据仓库的建设是“数据智能”必不可少的一环，也是大规模数据应用中必然面临的挑战，而 Flink 实时数仓在数据链路中扮演着极为重要的角色。本文中，美团点评高级技术专家鲁昊为大家分享了美团点评基于 Apache Flink 的实时数仓平台实践。本文授权转自社区公众号，原文地址目录：一、美团点评实时计算演进美团点评实时计算演进历程在 2016 年，美团点评就已经基于 Storm 实时计算引擎实现了初步的平台化。2017 年初，我们引入了 Spark Streaming 用于特定场景的

提到 Flink SQL 如何 Join 两个数据流，有读者反馈说如果不打算用 SQL 或者想自己实现底层操作，那么如何基于 DataStream API 来关联维表呢？实际上由于 Flink DataStream API 的灵活性，实现这个需求的方式是非常多样的，但是大部分用户很难在设计架构时就考虑得很全面，可能会走不少弯路。针对于此，笔者根据工作经验以及社区资源整理了用 DataStream 实现 Join 维表的常见方式，并给每种的方式优劣和适用场景给出一点可作为参考的个人观点。衡量指标总

一、业务场景与现状分析趣头条查询的页面分为离线查询页面和实时查询页面。趣头条今年所实现的改造是在实时查询中接入了 ClickHouse 计算引擎。根据不同的业务场景，实时数据报表中会展现数据指标曲线图和详细的数据指标表。目前数据指标的采集和计算为每五分钟一个时间窗口，当然也存在三分钟或一分钟的特殊情况。数据指标数据全部从 Kafka 实时数据中导出，并导入 ClickHouse 进行计算。二、Flink-to-Hive 小时级场景1.小时级实现架构图如下图所示，Database 中.

自 Google Dataflow 模型被提出以来，流批一体就成为分布式计算引擎最为主流的发展趋势。流批一体意味着计算引擎同时具备流计算的低延迟和批计算的高吞吐高稳定性，提供统一编程接口开发两种场景的应用并保证它们的底层执行逻辑是一致的。对用户来说流批一体很大程度上减少了开发维护的成本，但同时这对计算引擎来说是一个很大的挑战。作为 Dataflow 模型的最早采用者之一，Apache Flink 在流批一体特性的完成度上在开源项目中是十分领先的。本文将基于社区资料和笔者的经验，介绍 Flink 目前（1

1.爱奇艺 Flink 服务现状爱奇艺从 2012 年开始开展大数据业务，一开始只有二十几个节点，主要是 MapReduce、Hive 等离线计算任务。到 2014 年左右上线了 Storm、Spark 实时计算服务，并随后发布了基于 Spark 的实时计算平台 Europa。2017 年开始引入 Flink，用来替代部分 Spark Streaming 场景，满足更低延迟的实时计算需求。在这之后，相继推出流式 SQL 引擎、实时分析平台、实时数据生产平台等一系列工具，用来提升实时计算开发效率。

背景日志系统接入的日志种类多、格式复杂多样，主流的有以下几种日志： filebeat采集到的文本日志，格式多样 winbeat采集到的操作系统日志 设备上报到logstash的syslog日志 接入到kafka的业务日志 以上通过各种渠道接入的日志，存在2个主要的问题： 格式不统一、不规范、标准化不够 如何从各类日志中提取出用户关心的指标，挖掘更多的业务价值 为了解决上面2个问题，我们基于flink和drools规则引擎做了实时的日志处理服务。

前言小田，你看能不能做个监控大屏实时查看促销活动销售额（GMV）？小朱，搞促销活动的时候能不能实时统计下网站的 PV/UV 啊？小鹏，我们现在搞促销活动能不能实时统计销量 Top5 啊？小李，怎么回事啊？现在搞促销活动结果服务器宕机了都没告警，能不能加一个？小刘，服务器这会好卡，是不是出了什么问题啊，你看能不能做个监控大屏实时查看机器的运行情况？小赵，我们线上的应用频繁出现 Error 日志，但是只有靠人肉上机器查看才知道情况，能不能在出现错误的时候及时告警通知？小夏，我们 1

随着互联网的发展进入下半场，数据的时效性对企业的精细化运营越来越重要， 商场如战场，在每天产生的海量数据中，如何能实时有效的挖掘出有价值的信息， 对企业的决策运营策略调整有很大帮助。此外，随着 5G 技术的成熟、广泛应用， 对于工业互联网、物联网等数据时效性要求非常高的行业，企业就更需要一套完整成熟的实时数据体系来提高自身的行业竞争力。本文从上述现状及实时数据需求出发，结合工业界案例、笔者的实时数据开发经验， 梳理总结了实时数据体系建设的总体方案，本文主要分为三个部分： 第一部分主要介绍了当下在工

1．前言随着互联网的迅速发展，各个公司都建立了自己的监控体系，用于提前发现问题降低损失，携程亦是如此。然而携程的监控体系存在以下三个问题： 监控系统繁多 监控告警配置复杂 没有统一规范 首先携程目前光公司级别的监控系统就有三套，各个 BU 为了满足自己的业务监控需求也陆续开发了许多自己的监控系统。其次这些监控系统都是基于规则来判断是否存在异常，比如当满足同环比连续几个点上升或下降到用户配置的阈值时触发告警。最后是没有统一的规范，这里指的是两个规范，第一，没有统一的规则告警配

本文从数据传输和数据可靠性的角度出发，对比测试了Storm与Flink在流处理上的性能，并对测试结果进行分析，给出在使用Flink时提高性能的建议。Apache Storm、Apache Spark和Apache Flink都是开源社区中非常活跃的分布式计算平台，在很多公司可能同时使用着其中两种甚至三种。对于实时计算来说，Storm与Flink的底层计算引擎是基于流的，本质上是一条一条的数据进行处理，且处理的模式是流水线模式，即所有的处理进程同时存在，数据在这些进程之间流动处理。而Spark是基于批

一.OPPO 实时数仓的演进思路本文转载自 AI 前线公众号，作者张俊，编辑 | Vincent本文整理自 2019 年 4 月 13 日在深圳举行的 Flink Meetup 会议，分享嘉宾张俊，目前担任 OPPO 大数据平台研发负责人，也是 Apache Flink contributor。本文主要内容如下：OPPO 实时数仓的演进思路； 基于 Flink SQL 的扩展工作； 构建实时数仓的应用案例； 未来工作的思考和展望。1.1.OPPO 业务与数据规模大家都知道 OP

前言Flink On YARN 默认作业挂了之后打开的话，是一个如下这样的页面：作业失败后对于这种我们页面我们只能查看 JobManager 的日志，不再可以查看作业挂掉之前的运行的 Web UI，很难清楚知道作业在挂的那一刻到底发生了啥？如果我们还没有 Metrics 监控的话，那么完全就只能通过日志去分析和定位问题了，所以如果能还原之前的 Web UI，我们可以通过 UI 发现和定位一些问题。History Server 介绍那么这里就需要利用 Flink 中的 History

问题导读1.Barrier 对齐会造成什么问题？2.Barrier 对齐是否会造成反压？3.如何理解Unaligned Checkpoint ？作为 Flink 最基础也是最关键的容错机制，Checkpoint 快照机制很好地保证了 Flink 应用从异常状态恢复后的数据准确性。同时 Checkpoint 相关的 metrics 也是诊断 Flink 应用健康状态最为重要的指标，成功且耗时较短的 Checkpoint 表明作业运行状况良好，没有异常或反压。然而，由于 Checkpoint 与反压的耦

Flink 1.11 版本即将正式宣告发布！为满足大家的好奇与期待，我们邀请 Flink 核心开发者对 1.11 版本的功能特性进行解读与分享。Flink 1.11 在 1.10 的基础上对许多方面进行了完善和改进，并致力于进一步提高 Flink 的可用性及性能。本文将详细介绍 1.11 版本的新功能、改进、重要变化及未来的发展计划。更多信息可以参考相应的 FLIP 或 Jira 页面，并关注我们后续的专题直播。集群部署与资源管理在集群部署方面1.[FLIP-85] Flink 支持 App

Apache Flink 社区很荣幸的宣布 Flink 1.11.0 版本正式发布！超过 200 名贡献者参与了 Flink 1.11.0 的开发，提交了超过 1300 个修复或优化。这些修改极大的提高了 Flink 的可用性，并且增强了各个 API 栈的功能。其中一些比较重要的修改包括： 核心引擎部分引入了非对齐的 Checkpoint 机制。这一机制是对 Flink 容错机制的一个重要改进，它可以提高严重反压作业的 Checkpoint 速度。 实现了一套新的 Source 接口。.

集群和部署 支持 Hadoop 3.0 及更高的版本：Flink 不再提供任何flink-shaded-hadoop-依赖。用户可以通过配置 HADOOP_CLASSPATH 环境变量(推荐)或在 lib 文件夹下放入 Hadoop 依赖项。另外include-hadoopMaven profile 也已经被移除了。 移除了 LegacyScheduler：Flink 不再支持 legacy scheduler，如果你设置了jobmanager.scheduler: legacy...

Apache Flink 1.10 对 TaskManager 的内存模型和 Flink 应用程序的配置选项进行了重大变更。这些最近引入的更改做到了对内存消耗提供了严格的控制，使得 Flink 在各种部署环境（例如 Kubernetes，Yarn，Mesos）更具有适应能力，在本文中，我们将介绍 Flink 1.10 中的内存模型、如何设置和管理 Flink 应用程序的内存消耗以及社区在最新的 Apache Flink Release 版本中的变化。Flink 内存模型的介绍对 Apache F

大数据时代，随着公司业务不断的增长，数据量自然也会跟着不断的增长，那么业务应用和集群服务器的的规模也会逐渐扩大，几百台服务器在一般的公司已经是很常见的了。那么将应用服务部署在如此多的服务器上，对开发和运维人员来说都是一个挑战。一个优秀的系统运维平台是需要将部署在这么多服务器上的应用监控信息汇总成一个统一的数据展示平台，方便运维人员做日常的监测、提升运维效率，还可以及时反馈应用的运行状态给应用开发人员。举个例子，应用的运行日志需要按照时间排序做一个展示，并且提供日志下载和日志搜索等服务，这样如果应用出现问题开

Flink 相关的组件和作业的稳定性通常是比较关键的，所以得需要对它们进行监控，如果有异常，则需要及时告警通知。本章先会教会教会大家如何利用现有 Flink UI 上面的信息去发现和排查问题，会指明一些比较重要和我们非常关心的指标，通过这些指标我们能够立马定位到问题的根本原因。接着笔者会教大家如何去利用现有的 Metrics Reporter 去构建一个 Flink 的监控系统，它可以收集到所有作业的监控指标，并会存储这些监控指标数据，最后还会有一个监控大盘做数据可视化，通过这个大盘可以方便排查问题。实

简介之前文章中提到JoinedStream与CoGroupedStream，例如下列代码：dataStream.join(otherStream) .where(0).equalTo(1) .window(TumblingEventTimeWindows.of(Time.seconds(3))) .apply { ... }由于joinedStream与coGroupedStream来自于一个特定的window，且在一个关联上的key中实现，因此，Flink中的双流jo