平台的告警系统

整个监控平台架构

• 海量的监控数据（Metric & Log & Trace 数据）实时写入 ElasticSearch；

• 多维度的监控指标页面展示（Dashboard） 查 ElasticSearch 的数据比较频繁；

• 不断递增的告警规则需要通过查询 ElasticSearch 数据来进行判断是否要告警。

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

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

 

 

 

• 接入 Flink 集群去消费 Kafka 数据，告警的 Flink Job 消费 Kafka 数据去判断异常点，然后做告警

• Metric & Trace 数据存储到 ElasticSearch，之前还存储在 ElasticSearch 中的有 Log 数据

• Log 数据存储到 Cassandra

• Dashboard 查询数据增加 API 查询 Cassandra 的日志数据

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

但是过后我们发现偶尔还会出现数据实时写入到 ElasticSearch 集群把 ElasticSearch 写挂的情况。所以那会不断调优我们的写入数据到 ElasticSearch 的 Flink Job，然后也对 ElasticSearch 服务端做了不少的性能调优。

另外那会我们的监控数据是以 10s 一次为单位将采集的数据发上来的，后面我们调整了下数据采集的策略（变成 30s 一次为单位采集数据），采取多种调优策略后，终于将我们的 ElasticSearch 弄稳定了

 

 

 

在流式计算领域，同一套系统需要同时兼具容错和高性能其实非常难，同时它也是衡量和选择一个系统的标准。在这个领域，Flink和Spark无疑是彼此非常强劲的对手。

Spark与Flink支持的Connectors的数量差不多，目前来说可能Spark支持更多一些，Flink后续的支持也会逐步的完善。

3. Flink VS Spark 之 运行环境

Spark 与Flink所支持的运行环境基本差不多，都比较广泛。

4. Flink VS Spark 之 社区

Spark 社区在规模和活跃程度上都是领先的，毕竟多了几年发展时间，同时背后的商业公司Databricks由于本土优势使得Spark在美国的影响力明显优于Flink

而且作为一个德国公司，Data Artisans 想在美国扩大影响力要更难一些。不过 Flink 社区也有一批稳定的支持者，达到了可持续发展的规模。

在中国情况可能会不一样一些。比起美国公司，中国公司做事情速度更快，更愿意尝试新技术。中国的一些创新场景也对实时性有更高的需求。这些都对 Flink 更友好一些。

总结：

Spark 和 Flink 都是通用的开源大规模处理引擎，目标是在一个系统中支持所有的数据处理以带来效能的提升。两者都有相对比较成熟的生态系统。是下一代大数据引擎最有力的竞争者。

Spark 的生态总体更完善一些，在机器学习的集成和易用性上暂时领先。

Flink 在流计算上有明显优势，核心架构和模型也更透彻和灵活一些。

在易用性方面两者也都还有一些地方有较大的改进空间。接下来谁能尽快补上短板发挥强项就有更多的机会。

总而言之，Flink与Spark没有谁强谁弱，只有哪个更适合当前的场景。