点击下方“JavaEdge”，选择“设为星标”
第一时间关注技术干货！
免责声明~
任何文章不要过度深思！
万事万物都经不起审视，因为世上没有同样的成长环境，也没有同样的认知水平，更「没有适用于所有人的解决方案」；
不要急着评判文章列出的观点，只需代入其中，适度审视一番自己即可，能「跳脱出来从外人的角度看看现在的自己处在什么样的阶段」才不为俗人。
怎么想、怎么做，全在乎自己「不断实践中寻找适合自己的大道」
0 前言
对于使用批处理工作流的数据团队来说，要满足当今的实时需求并不容易。为什么呢？因为批处理工作流，从数据传递和处理到分析，涉及很多等待。
需要等待将数据发送到ETL工具，等待批量处理数据，等待将数据加载到数据仓库，甚至等待查询完成运行。
但是，来自开源世界的这个问题有一个解决方案。当一起使用时，Apache Kafka，Flink和Druid创建了一个实时数据架构，消除了所有这些等待状态。在本博客文章中，我们将探讨这些工具的组合如何实现各种实时数据应用。
Kafka-Flink-Druid的源到应用程序的示意数据流。
1 构建实时数据应用程序的架构
首先，什么是实时数据应用程序？只需考虑任何使用新鲜数据提供实时洞察或决策的UI或API驱动的应用程序。这包括警报、监控、仪表板、分析和个性化推荐等。
为了提供这些工作流程，需要能够处理从事件到应用程序的整个管道的专门工具。这就是Kafka-Flink-Druid（KFD）架构的用武之地。
开源实时数据架构
像Lyft、Pinterest、Reddit和Paytm等具有实时需求的大型公司之所以同时使用这三者，是因为它们都是由相互补充的流原生技术构建的，可以无缝地提供实时用例所需的数据新鲜度、规模和可靠性。
这种架构使构建诸如可观察性、物联网/遥测分析、安全检测/诊断和面向客户的见解等高吞吐量和QPS的实时数据应用程序变得简单。
让我们更详细地看看每个工具以及它们如何一起使用。
2 流水线：Apache Kafka
在过去的几年里，Apache Kafka已经成为流数据的事实标准。在它之前，使用RabbitMQ、ActiveMQ和其他消息队列系统来提供各种消息传递模式，以从生产者分发数据到消费者，但存在规模限制。
快进到今天，Kafka已经变得无处不在，超过80%的财富100强公司使用它¹。这是因为Kafka的架构远远超出了简单消息传递的范畴。其架构的多功能性使Kafka非常适合在规模庞大的“互联网”规模上进行流处理，具有容错性和数据一致性，以支持关键任务应用，而其通过Kafka Connect的各种连接器与任何数据源集成。
3 流处理：Apache Flink
随着Kafka提供实时数据，需要适当的消费者来利用其速度和规模。其中一个流行的选择是Apache Flink。
为什么选择Flink？首先，Flink在处理规模化的连续数据流方面非常强大，具有统一的批处理和流处理引擎。作为Kafka的流处理器，Flink是一个自然的选择，因为它能够无缝集成并支持仅一次语义，确保每个事件仅被处理一次，即使在系统故障的情况下也是如此。
使用它非常简单：连接到Kafka主题，定义查询逻辑，然后连续发射结果，即“设置并忘记”。这使得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进行基于事件的数据丰富的示例（图像由imply.io提供）
在这里，Flink的一个优势是在规模上处理庞大的Kafka流 — 达到每秒数百万事件 — 实时。此外，丰富/转换通常是一个无状态的过程，每个数据记录都可以在不需要维护持久状态的情况下进行修改，使其成本最低且性能高效。
连续监控和警报
Flink的实时连续处理和容错性的组合也使其成为各种关键应用程序的实时检测和响应的理想解决方案。
当对检测的敏感度非常高（考虑亚秒级）且采样率也很高时，Flink的连续处理非常适合用作监控条件的数据服务层，并触发相应的警报和操作。
Flink在警报方面的一个优势是，它既支持无状态的警报，也支持有状态的警报。阈值或事件触发器，如“当温度达到X时通知消防部门”，是直截了当的，但不总是足够智能。因此，在需要通过连续数据流监视和更新状态来识别偏差和异常的复杂模式的用例中，Flink可以监视和更新状态以识别偏差和异常。
需要考虑的一点是，使用Flink进行监控和警报涉及连续的CPU — 因此涉及连续的成本和资源 — 用于根据阈值和模式评估条件，这与仅在查询执行期间使用CPU的数据库不同。因此，了解是否需要连续是一个好主意。
4 实时分析：Apache Druid
Apache Druid是数据架构的最后一块拼图，与Kafka和Flink一起成为流的消费者，用于支持实时分析。虽然它是用于分析的数据库，但其设计中心和用途与其他数据库和数据仓库不同。
首先，Druid就像Kafka和Flink的兄弟一样。它也是流原生的。事实上，它无需与Kafka连接器连接，直接连接到Kafka主题，支持仅一次语义。Druid还专为在规模上快速摄取流数据和在到达时在内存中立即查询事件而设计。
Druid的摄取过程专为每个事件摄取而本地设计。
在查询方面，Druid是一个高性能、实时分析数据库，可以在规模和负载下提供亚秒查询。如果用例对性能敏感，并且需要处理TB到PB级别的数据（例如聚合、过滤、GroupBy、复杂连接等）以及高查询量，那么Druid是一个理想的数据库，因为它始终提供闪电般快速的查询，并且可以轻松从单台笔记本扩展到数千个节点的集群。
这就是为什么Druid被称为实时分析数据库的原因：它是当实时数据满足实时查询时的理想选择。
以下是Druid如何补充Flink：
高度交互式查询
实时与历史数据
高度交互式查询
工程团队使用Druid为分析应用程序提供动力。这些是包括内部（即运营）和外部（即面向客户）用例的数据密集型应用程序，涵盖了观察、安全、产品分析、物联网/遥测、制造操作等多个领域。使用Druid提供动力的应用程序通常具有以下特征：
**规模上的性能：**需要对大数据集进行分析性查询时，无需预计算。即使应用程序的用户随意对TB-PB规模的大量数据进行任意分组、过滤和切片/切块，Druid也具有极高的性能。
**高查询量：**需要对分析查询进行高QPS。这里的一个例子是任何外部面向应用程序 — 即数据产品 — 需要为产生100到1000个（不同的）并发查询的工作负载提供亚秒SLA的情况。
**时间序列数据：**需要在具有时间维度的数据上提供见解的应用程序（Druid的强项，但不是限制）。由于Druid的时间分区和数据格式，Druid可以非常快速地处理时间序列数据。这使得基于时间的
WHERE过滤器非常快速。
这些应用程序要么具有非常交互式的数据可视化/合成结果集UI，具有在运行时灵活更改查询的灵活性（因为Druid是如此快速），要么在许多情况下，它们正在利用Druid的API，以实现在大规模的决策工作流中以亚秒速度提供查询。
以下是由Apache Druid提供动力的分析应用程序的示例：
Confluent Health+由Apache Druid提供支持。
Confluent，Apache Kafka的原始创建者，通过Confluent Health+为其客户提供分析服务。上面的应用程序非常互动，并且具有关于客户Confluent环境的丰富见解。在幕后，事件以每秒500万个事件的速度流入Kafka和Druid，而应用程序每秒提供350个查询。
实时与历史数据
虽然上面的例子展示了Druid支持一个非常互动的分析应用程序，可能会想知道“流式数据与之有何关系？”这是一个很好的问题，因为Druid不仅限于流式数据。它非常适合摄取大批量文件。
但是，Druid之所以在实时数据架构中具有相关性，是因为它可以在实时数据与历史数据的基础上提供交互式数据体验，以获得更丰富的上下文。
虽然Flink擅长回答“现在发生了什么”（即发出Flink作业的当前状态），但Druid技术上可以回答“现在发生了什么，这与以前相比如何，以及哪些因素/条件影响了结果”。这些问题的结合非常强大，例如可以消除误报，帮助检测新趋势，并导致更有深度的实时决策。
回答“与以前相比如何”需要历史背景——一天、一周、一年或其他时间范围——以进行相关性。而“哪些因素/条件影响了结果”则需要通过整个数据集进行挖掘。由于Druid是一个实时分析数据库，它摄取流以提供实时见解，但它还持久保存数据，因此可以查询历史数据和所有其他维度进行即席探索。
Apache Druid扩展实时摄取，将主题映射到摄取任务。
例如，假设我们正在构建一个监视安全登录以寻找可疑行为的应用程序。我们可能希望在5分钟的窗口内设置一个阈值：即更新并发出登录尝试的状态。这对于Flink来说很容易。但是，使用Druid，当前的登录尝试也可以与历史数据相关联，以识别过去没有安全问题的相似登录高峰。因此，这里的历史背景有助于确定当前高峰是否表明存在问题或只是正常行为。
因此，当应用程序需要在不断变化的事件上提供大量分析——例如当前状态、各种聚合、分组、时间窗口、复杂连接等——但也提供历史背景并通过高度灵活的API探索该数据集时，Druid就是其最擅长的领域。
5 Flink和Druid检查清单
Flink和Druid都是为流数据构建的。虽然它们在一些高层次上有一些相似之处——都是内存中的，都可以扩展，都可以并行化——但它们的架构实际上是为完全不同的用例而构建的，就像我们上面看到的那样。
这里是一个基于工作负载的简单决策清单：
是否需要在流式数据上实时转换或连接数据？查看Flink，因为这是它的“拿手好戏”，它专为实时数据处理而设计。
是否需要同时支持许多不同的查询？查看Druid，因为它支持高QPS的分析，而无需管理查询/作业。
指标是否需要连续更新或聚合？查看Flink，因为它支持有状态的复杂事件处理。
分析是否更复杂，并且是否需要历史数据进行比较？查看Druid，因为它可以轻松快速地查询具有历史数据的实时数据。
是否正在为用户界面应用程序或数据可视化提供支持？查看Flink进行丰富，然后将数据发送到Druid作为数据服务层。
在大多数情况下，答案不是Druid或Flink，而是Druid和Flink。它们各自提供的技术特性使它们共同非常适合支持各种实时数据应用程序。
6 结论
企业越来越需要从数据团队中获得实时数据。这意味着数据工作流需要从头到尾重新考虑。这就是为什么许多公司将Kafka-Flink-Druid视为构建实时数据应用程序的事实上的开源数据架构。它们是完美的三剑客。
要尝试Kafka-Flink-Druid架构，可以在这里下载这些开源项目 — Kafka，Flink，Druid — 或者只需获取Confluent Cloud和Imply Polaris 的免费试用，它们分别是Kafka-Flink（Confluent）和Druid（Imply）的云服务。
参考：
编程严选网
写在最后
编程严选网（www.javaedge.cn），程序员的终身学习网站已上线！
点击阅读原文，即可访问网站！
欢迎长按图片加好友，我会第一时间和你分享软件行业趋势，面试资源，学习途径等等。
添加好友备注【技术群交流】拉你进群，更多教程资源应有尽有
关注公众号后，在后台私信：
回复【架构师】，获取架构师学习资源教程
回复【面试】，获取最新最全的互联网大厂面试资料
回复【简历】，获取各种样式精美、内容丰富的简历模板
回复 【路线图】，获取直升Java P7技术管理的全网最全学习路线图
回复 【大数据】，获取Java转型大数据研发的全网最全思维导图
微信【ssshflz】私信 【副业】，进副业交流群
点击【阅读原文】，即可访问程序员一站式学习网站