一文让你彻底了解大数据实时计算引擎 Flink

不知道你是否有过和我类似的经历？

我是 2018 年 6 月加入公司，一直负责监控平台的告警系统。之后，我们的整个监控平台架构中途换过两次，其中一次架构发生了巨大的变化。我们监控告警平台最早的架构如下图所示：

这个架构的挑战难点在于：

• 海量的监控数据（Metric & Log & Trace 数据）实时写入 ElasticSearch；
• 多维度的监控指标页面展示（Dashboard） 查 ElasticSearch 的数据比较频繁；
• 不断递增的告警规则需要通过查询 ElasticSearch 数据来进行判断是否要告警。

从上面的几个问题我们就可以很明显的发现这种架构的瓶颈就在于 ElasticSearch 集群的写入和查询能力，在海量的监控数据（Metric & Log & Trace 数据）下实时的写入对 ElasticSearch 有极大的影响。

我依然清楚记得，当时经常因为写入的问题导致 ElasticSearch 集群挂掉，从而让我的告警和监控页面（Dashboard）歇菜（那会老被喷：为啥配置的告警规则没有触发告警？为啥查看应用的 Dashboard 监控页面没数据）。我也很无奈啊，只想祈祷我们的 ElasticSearch 集群稳一点。

初次接触 Flink

在如此糟糕的架构情况下，我们挺过了几个月，后面由于一些特殊的原因，我们监控平台组的整体做了一个很大的架构调整，如下图：

主要做了四点改变：

• 接入 Flink 集群去消费 Kafka 数据，告警的 Flink Job 消费 Kafka 数据去判断异常点，然后做告警
• Metric & Trace 数据存储到 ElasticSearch，之前还存储在 ElasticSearch 中的有 Log 数据
• Log 数据存储到 Cassandra
• Dashboard 查询数据增加 API 查询 Cassandra 的日志数据

原先因为 Metric & Trace & Log 的数据量一起全部实时写入到 ElasticSearch 中，对 ElasticSearch 的压力很大，所以我们将 Log 的数据拆分存储到 Cassandra 中，分担了一些 ElasticSearch 的写入压力。

但是过