利用Apache Kafka、Flink和Druid构建实时数据架构( 二 ) _Apache

Flink在警报方面的优势主要体现在：它既能够支持无状态警报，也可以支持有状态警报。例如：像“温度达到X时，通知消防队”这样的阈值或事件触发条件虽然简单，但不够智能。在一些真实的使用案例中，警报需要由能够保持状态的复杂模式驱动，甚至需要在持续的数据流中汇总各项指标（如：总量、平均值、最小值、最大值、以及计数等），而Flink则可以监控和更新状态，以及时发现偏差和异常。
值得注意的是，使用Flink进行监控和警报时，往往需要持续使用系统CPU来根据阈值和模式评估条件。这与只在执行查询时，才用到CPU的数据库有所不同。因此，您需要最好事先了解待开发的应用是否需要持续使用CPU 。
实时分析：Apache Druid总的说来，Apache Druid完善了数据架构，能够与Kafka和Flink一起成为支持实时分析的数据流消费者。虽然它是一个被用于分析的数据库，但是其设计中心和用途与其他数据库、以及数据仓库有较大的不同。
首先，由于Druid是数据流原生的，因此，Druid和Kafka之间不需要连接器，它可以直接连接到Kafka主题，并且支持精确的一次性语义。同时，Druid也被设计为用于大规模地快速捕获流数据，并在事件到达时，立即在内存中进行查询。

文章插图
Druid如何与Kafka原生集成，以实现数据流捕获
在查询方面，Druid是一种高性能的实时分析数据库，可以在大规模和负载条件下，提供亚秒级的查询。它非常适用于那些对性能极其敏感，并且需要处理从TB到PB的数据（例如：聚合、过滤、GroupBy、以及复杂连接等）和高查询体量的用例。Druid不但能够持续提供快如闪电的查询，而且可以轻松从一台笔记本电脑扩展为由1000个节点组成的集群。这就是Druid被称为实时分析数据库的原因。以下是Druid与Flink的互补用例：
高度交互式查询工程团队可以使用Druid支持包括：各种内部（即运营）和外部（即面向客户）涉及到可观察性、安全性、产品分析、物联网与遥测、制造运营等数据密集型分析应用。其核心特点包括：

大规模性能：应用程序需要在不进行预计算的情况下，对大型数据集进行亚秒级读取、查询和分析。即使用户以TB甚至PB的规模，对大量随机查询进行任意分组、过滤、切片、以及切割，Druid都能提供不俗的性能。
高查询量：能够针对具有较高QPS（每秒查询率）要求的分析查询应用，例如：任何面向外部的数据产品应用，都需要为产生100到1000次不同的并发查询的工作负载，提供亚秒级SLA 。
时间序列数据：由于采用了时间分区和数据格式的应用需求，Druid可以非常快速地、大规模处理时序数据，进而提出洞见。这使得基于时间的WHERE过滤器的速度极快。

这些应用要么具有交互性很强的数据可视化、以及合成结果集的用户界面，并得益于Druid的快速，能够非常灵活地即时更改查询；要么在很多情况下，它们利用Druid的应用程序接口（API）来提高查询速度，从而为决策工作流提供依据。
下图展示的是一个由Apache Druid支持的分析应用示例。

文章插图
图片来源：Confluent的Confluent Health+仪表板
众所周知，由Apache Kafka原创的Confluent，可以通过Confluent Health+为客户提供分析服务。上图中的应用具有高度交互性。通常，事件会以每秒500万次的速度流向Kafka和Druid，该应用通过提供350 QPS的服务，来深入洞察客户的Confluent环境。
实时历史数据Druid与实时数据架构的关联之处在于，它可以提供实时数据与历史数据相结合的交互式数据体验，从而提供更丰富的语境。
如果说Flink擅长回答“现在发生着什么（即发出Flink任务的当前状态）”的话，那么Druid则在技术上能够回答“现在发生的与之前相比有何不同，哪些因素或条件对结果产生了影响” 。回答这些问题将有助于消除误报，协助检测新的趋势，进而做出更有洞见的实时决策。
【利用Apache Kafka、Flink和Druid构建实时数据架构】要回答“与以前相比情况如何？”的疑问，我们往往需要以过去的某一天、一周、一年或其他时间跨度，来进行相关性分析。而要回答“哪些因素或条件影响了结果”，我们则需要挖掘完整的数据集。由于Druid是一个能够实时分析的数据库，因此它可以捕获可供实时洞察的数据流，同时它也会持久性地保存数据，以便随时查询多维度的历史信息。