不知道你有没有和我有过类似的经历？
2018年6月入职，一直负责监控平台的报警系统。之后我们整个监控平台架构改了两次，一次架构大改。我们的监控和报警平台的最早架构如下图所示：
这种架构的挑战和困难是：
海量监控数据(Metric Log Trace数据)写入ElasticSearch实时地；
多维监控索引页面仪表盘，经常查询ElasticSearch的数据；
增加的报警规则需要查询ElasticSearch数据来判断是否报警。
从上面的问题中，我们可以清楚地发现，这种架构的瓶颈在于ElasticSearch集群的写和查询能力，海量监控数据(Metric Log Trace data)下的实时写对ElasticSearch影响很大。我还清楚的记得那时候的ElasticSearch集群经常因为写问题挂掉，让我的报警和监控仪表盘关闭(那会一直被喷：配置的报警规则为什么不触发报警？没有用于查看应用程序的仪表板监视页面的数据)。我也很无奈。我只想祈祷我们的ElasticSearch集群能够保持稳定。
01
第一次接触弗林克
在这样糟糕的建筑中，我们幸存了几个月。后来由于一些特殊原因，我们对整个监控平台组进行了一次大的架构调整，如下图所示：
主要做了四点改动：
访问Flink集群消耗Kafka数据，报警Flink作业消耗Kafka数据判断异常点，然后报警。
度量跟踪数据存储在ElasticSearch中，并且有以前存储在ElasticSearch中的日志数据。
日志数据存储在Cassandra中。
仪表板查询数据添加API来查询Cassandra的日志数据
本来Metric Trace Log的所有数据都是实时写入ElasticSearch的，对ElasticSearch的压力很大，所以我们把Log的数据拆分出来存储在Cassandra中，分担了ElasticSearch的一些写压力。但后来我们发现，偶尔会有数据实时写入ElasticSearch集群，写入ElasticSearch。因此，这将不断调整我们的写数据，以Flink工作的弹性搜索，然后做了很多性能调整的弹性搜索服务器。另外，当时我们的监测数据是以10s为单位发送的。后来我们调整了数据收集的策略(以30s为单位收集数据)，采用了各种优化策略后，终于稳定了我们的ElasticSearch。
02
遭遇与Flink相关的挑战
换成这种新架构后，因为组里没人熟悉Flink，而且当时关于Flink的资料真的很少，所以组里的每个人都是从0开始学习Flink，这对每个人来说都是相当大的挑战。
当时，我们在Flink上运行的作业也遇到了各种问题：
消费卡夫卡数据延迟
检查点失败。
窗口概念模糊，操作错误。
选择事件时间和处理时间时出错。
我不知道如何使用水印机制来处理乱序和延迟数据
Flink附带的连接器优化
Flink中的JobManager和TaskManager经常挂起，导致Flink作业重启。
Flink集群模式的选择
.
因为遇到的各种问题，我们会不断学习Flink的原理和内部机制，然后慢慢解决上面遇到的各种问题，逐步稳定我们监控平台运行的Flink作业。
03
为什么要学Flink？
随着大数据的不断发展，对数据的时效性要求越来越高，对实时场景的需求也越来越多，主要分为以下几类：
然后为了满足这些实时场景的需求，衍生出了很多计算引擎框架。市场上现有的大数据计算引擎对比如下：
可以发现，Flink在架构设计、功能完整性、易用性方面都是领先的，而且Flink是阿里巴巴力推的计算引擎框架，所以从去年开始越来越受欢迎！虽然市面上关于Flink的书籍太少，国内的中文资料也太少，现有的书籍也不是很详细，但是相信在阿里的推动下，Flink在国内会越来越受欢迎，阿里也对Flink做了一些优化和修改，今年年初叫Flink 1.9，源代码也贡献给了Flink，后面的1.9版本会把Flink的功能合并到Flink中。目前，阿里巴巴、腾讯、美团、华为、滴滴出行、携程、饿了么、爱奇艺、有赞、唯品会等大公司都在公司大型项目中实践了Flink，掀起了一股Flink热潮。势必会让Flink人才市场供不应求。
04
我为什么要写FLink专栏？
在这个过程中，我不停地记录着自己对Flink的学习之路。目前我已经发表了20篇Flink的个人学习博客，很多对Flink感兴趣的童鞋也加入到我的讨论议题中。每天群里的童鞋都会问很多Flink的问题，但是我发现回答的比较少。其实这并不是因为群里的大佬不积极，而是大家对Flink了解不多。比如有的是大数据工程师，但以前从事Spark，有的是后端开发工程师转大数据开发，有的是研究生对Flink感兴趣。因为我来自弗林克小白，我知道初学者可能会遇到什么问题。当你回头看的时候，你可能会发现，这么简单的一个问题，你挣扎了那么久，都走不出来。如果这个时候有人给你一些建议，你能省多少力气！于是我脑子里有了一个想法：写一个Flink专栏，帮助大家尽快从小白阶段过渡到入门阶段，再从入门阶段过渡到能够使用Flink，真正在生产环境中运行你的Flink作业，然后调查解决你的生产环境中的错误，根据作业的运行状态进一步优化！
专栏重点
全网率先使用Flink 1.9最新版本讲解内容(该版本有较大更新，架构和功能都有更新)，领先目前市面上Flink 1.7的常用教学课程。
包含大量实战案例和代码解释原理，帮助读者边学习边打代码，达到更快更深的学习境界。目前市面上的书籍没有实战内容，只是讲解纯概念，翻译官网。
在专栏的高级部分，根据Flink常见的项目问题，提供了故障排除和解决的思维方法，并通过这些问题，探究此类问题产生的原因。
在实战和案例研究中，分析了大昌公司的经典需求，包括架构设计、各个环节的操作和代码实现。
列内容
预备文章
介绍了实时计算的常见使用场景，说明了Flink的特点，比较了Spark Streaming、结构化流、Storm等大数据处理引擎，然后通过两个Flink应用准备环境，带你去Flink。
基本物品
深入讲解Flink中时间、窗口、水印、连接器的原理，并有大量文章(包括详细代码)讲解如何使用这些连接器(如Kafka、ElasticSearch、HBase、Redis、MySQL等。)，并讲解使用过程中可能遇到的坑，还教你如何定制连接器。
进步文章
在Flink中解释状态、检查点、保存点、内存管理机制、CEP、Table/SQL API、机器学习和Gelly。在本文中，我们不仅会讨论概念，还会解释如何使用状态、如何配置检查点、检查点流程以及如何使用CEP处理复杂事件。
高级文章
主要介绍了Flink作业上线后的监控运维：如何保证高可用性，如何定位和排查反压问题，如何合理设置作业的并行度，如何保证一次正好，如何处理数据倾斜问题，如何优化整个作业的执行效率，如何监控Flink及其作业。
实战篇
教你如何分析实时计算场景的需求，利用Flink中的技术实现这些需求，比如PV/UV的实时统计，商品销售TopK的实时统计，利用错误日志的实时报警，机器停机报警等。Flink是如何实现这些需求的，会提供完整的代码供大家参考。通过这些需求，可以学习如何使用ProcessFunction、异步I/O、广播变量等知识。
系统案例文章
讲解大流量下的真实案例：如何实时处理海量日志(错误日志的实时报警/日志的实时ETL/of/日志的实时显示/日志的实时搜索)，以及基于Flink的百亿级数据实时重复数据删除的实践(来自重复数据删除的一般解决方案——使用BloomFilter实现重复数据删除——使用Flink的KeyedState实现重复数据删除)。
Flink专栏思维导图
Flink知识点多图讲解
Flink支持多时间语义。
Flink提供灵活的窗口。
纱线上的Flink
弗林克检查站
Flink监控
标签：Flink数据问题