审校 | 重楼
如今,对于使用批处理工作流程的数据团队而言,要满足业务的实时要求并非易事。从数据的交付、处理到分析,整个批处理工作流往往需要大量的等待,其中包括:等待数据被发送到ETL工具处,等待数据被批量处理,等待数据被加载到数据仓库,甚至需要等待查询的完成。
不过,开源世界已对此有了解决方案:通过Apache Kafka、Flink和Druid的协同使用,我们可创建一个实时数据架构,以消除上述等待状态。如下图所示,该数据架构可以在从事件到分析、再到应用的整个数据工作流程中,无缝地提供数据的新鲜度、扩展性和可靠性。
目前,Lyft、Pinterest、Reddit和Paytm等知名公司,都在同时使用这三种由互补的数据流原生技术构建的应用,来共同处理各种实时用例。
用于实时应用的开源数据架构
上图展现的架构能够使得构建可观察性、物联网与遥测分析、安全检测与诊断、面向客户的洞察力、以及个性化推荐等实时应用,变得简单且易于实现。下面,我们将和您探讨此类工具的各个组成部分,以及它们将如何被结合起来实现广泛的实时应用。
流管道:Apache Kafka
过去,RabbitMQ、ActiveMQ、以及其他被用来提供各种消息传递模式的消息队列系统,虽然可以将数据从生产者分发到消费者处,但是其可扩展性十分有限。而随着Apache Kafka的出现,以及被80%的财富100强企业所使用,它已成为了流式数据的实际标准。其根本原因在于,Kafka架构远不止简单的消息传递,其多功能性使之非常适合在大规模的互联网上进行数据流传输。而其容错性和数据一致性,则可以支持各类关键性任务应用。同时,由Kafka Connect提供的各种连接器,也可与任何数据源相集成。
作为实时数据流平台的Apache Kafka
流处理:Apache Flink
Kafka虽然能够提供实时数据,但是用户在需要兼顾实时效率和扩展性时,往往会选择Apache Flink。作为一个高吞吐量且统一的数据流批处理引擎,Flink的独特优势在于能够大规模处理连续的数据流。而作为Kafka的流处理器,Flink可以无缝地集成并支持精确的一次性语义(exactly-once semantics)。也就是说,即使在系统出现故障时,它也能保证每个事件被精确地处理一次。
具体而言,它会连接到Kafka主题,定义查询逻辑,然后连续输出结果,正所谓“设置好就不用管它(set it and forget it)”。这使得Flink非常适用于对数据流的即时处理和可靠性要求较高的应用案例。以下是Flink的两个常见用例:
填充与转换
如果数据流在使用之前需要进行诸如:修改、增强或重组数据等操作,那么Flink是对此类数据流进行操作的理想引擎。它可以通过持续处理,来保持数据的新鲜度。例如,假设我们有一个安装在智能建筑中的、温度传感器的、物联网遥测用例。其每一个被捕获的Kafka事件,都具有以下JSON结构:
{ "sensor_id":"SensorA," "temperature":22.5, "timestamp":“2023-07-10T10:00:00”}
如果每个传感器的ID都需要映射到一个位置,而且温度需要以华氏度为单位的话,那么Flink可以将JSON结构更新为:
{ “sensor_id”: “SensorA,” “location”: “Room 101”, “temperature_Fahreinheit”: 73.4, “timestamp”: “2023-07-10T10:00:00” }
并且将其直接发送到应用程序,或直接发回Kafka。
Flink数据处理的结构化表格示例
持续监控和警报
通过将Flink的实时持续处理和容错功能相结合,我们可以为各种关键性应用的实时检测和响应需求,设计出理想的解决方案。例如:当需要具备高检测灵敏度(如:亚秒级)和高采样率时,Flink的持续处理功能就非常适合作为数据服务层,被用于监控条件,触发警报,进而采取相应的行动。
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则在技术上能够回答“现在发生的与之前相比有何不同,哪些因素或条件对结果产生了影响”。回答这些问题将有助于消除误报,协助检测新的趋势,进而做出更有洞见的实时决策。
要回答“与以前相比情况如何?”的疑问,我们往往需要以过去的某一天、一周、一年或其他时间跨度,来进行相关性分析。而要回答“哪些因素或条件影响了结果”,我们则需要挖掘完整的数据集。由于Druid是一个能够实时分析的数据库,因此它可以捕获可供实时洞察的数据流,同时它也会持久性地保存数据,以便随时查询多维度的历史信息。
Druid 的查询引擎如何处理实时和历史数据
假设我们正在构建一个用于监控登录可疑行为的应用程序,那么我们可能希望在五分钟的时间窗口内设置一个阈值--更新并发布登录尝试的状态。凭借Druid,当前的登录尝试可以与历史数据相关联,以识别过去未发生、但的确被利用过的登录安全漏洞。据此,历史背景将有助于确定当前的登录反复尝试是否属于正常行为。
此外,如果您的应用程序需要接收大型批处理文件,且对瞬息万变的事件进行大量分析(如:当前状态、各种聚合、分组、时间窗口、以及复杂连接等),同时还要提供历史背景,并通过高度灵活的应用程序接口来检索数据集,那么这些都是Druid的优势所在。
选择Flink和Druid的检查表
可见,Flink和Druid都是为流数据而构建的。虽然它们有着一些高层次的相似之处,例如:都属于内存内部(in-memory)、都能扩展、都能并行,但是正如前文所述,它们的架构实际上是为完全不同的用例而构建的。下面,我为您整理了一份简单的、基于工作量来判断该如何选择的检查表:
- 您是否需要对流式数据进行实时转换或连接?
- Flink就是这样一款专为实时数据处理而设计的服务。
- 您需要同时支持许多不同的查询吗?
- Druid可以支持高QPS分析,而无需管理各种查询和任务。
- 事件相关指标是否需要持续更新或汇总?
- Flink支持有状态的复杂事件处理。
- 分析是否更加复杂,是否需要与历史数据进行比较?
- Druid可以方便快捷地查询实时数据和历史数据。
- 您是否正在为面向用户的应用程序提供数据可视化?
- 可先使用Flink予以填充,然后将数据发送到作为数据服务层的Druid。
总的说来,在大多数情况下,您的选择不会是“非Druid即Flink”,而是“既Druid又Flink”。它们各自的技术特性使得两者能够共同支持各种实时应用。
小结
随着企业对于数据实时性的要求越来越高,数据团队需要重新考虑端到端的数据工作流程。这就是为什么许多公司已将Kafka+Flink+Druid作为构建实时应用的开源数据架构的原因。
译者介绍
陈峻(Julian Chen),51CTO社区编辑,具有十多年的IT项目实施经验,善于对内外部资源与风险实施管控,专注传播网络与信息安全知识与经验。
原文Building a Real-Time Data Architecture With Apache Kafka, Flink, and Druid ,作者:David Wang