大数据-154 Apache Druid 架构与原理详解基础架构、架构演进

点一下关注吧！！！非常感谢！！持续更新！！！

目前已经更新到了：

Hadoop（已更完）
HDFS（已更完）
MapReduce（已更完）
Hive（已更完）
Flume（已更完）
Sqoop（已更完）
Zookeeper（已更完）
HBase（已更完）
Redis （已更完）
Kafka（已更完）
Spark（已更完）
Flink（已更完）
ClickHouse（已更完）
Kudu（已更完）
Druid（正在更新…）

章节内容

上节我们完成了如下的内容：

Apache Druid 从 Kafka 中加载数据
实际测试可视化操作

在这里插入图片描述

基础架构

在这里插入图片描述

Coordinator Node

主要负责历史节点的数据负载均衡，以及通过规则管理数据的生命周期，协调节点告诉历史节点加载新数据、卸载过期数据、复制数据、负责均衡移动数据
Coordinator是周期运行的（由 druid.coordinator.period 配置指定，默认间隔60秒），Coordinator需要维护和ZooKeeper的连接，以获取集群的信息。Segment和Rule的信息保存在元数据中，所以也需要维护与元数据库的连接。

Overlord Node

进程监视MiddleManager进程，并且是Druid数据摄入的主节点，负责将提取任务分配给MiddleManagers并协调Segment发布，包括接受、拆解、分配Task，以及创建Task相关的锁，并返回Task的状态。

Historical Node

加载生成好的数据文件，以供数据查询。Historical Node是整个集群查询性能的核心所在，Historical会承担绝大部分的Segment查询。

Historical 进程从 Deep Storage 中下载 Segment，并响应有关这些Segment的查询请求（这些请求来自Broker进程）
Historical 进程不处理写入请求
Historical 进程采用了无共享架构设计，它知道如何去加载和删除 Segment，以及如何基于 Segment 来响应查询。即便底层的深度存储无法正常工作，Historical 进程还是能针对其已同步的 Segments，正常提供查询服务。
底层的深度存储无法正常工作，Historical进程还是能针对其已同步的 Segments，正常提供查询服务。

MiddleManager Node

及时摄入实时数据，生成Segment数据文件

MiddleManager 进程是执行提交任务的工作节点，MiddleManagers将任务转发给在不同JVM中运行的Peon进程
MiddleManager、Peon、Task的对应关系是：每个Peon进程一次只能运行一个Task任务，但一个MiddleManager却可以管理多个Peon进程

Broker Node

接收客户端查询请求，并将这些查询转发给 Histo 和 MiddleManagers。当Brokers从这些子查询中收到结果时，它们会合并这些结果并将它们返回给调用者。

Broker 节点负责转发Client查询请求的
Broker 通过 ZooKeeper 能够知道哪个 Segment 在哪些节点上，将查询转发给相应节点
所有节点返回数据后，Broker会所有节点的数据进行合并，然后返回给Client

Router Node

（可选）
负责将路由转发到Broker、Coordinator、Overlords

Router进程可以在 Broker、Overlords、Coordinator进程之上，提供一层统一的API网关
Router进程是可选的，如果集群数据规模已经到达了TB级别，需要考虑启动（druid.router.managerProxy.enable=true）
一旦集群规模达到一定数量级，那么发生故障的概率就会变得不容忽视，而Router支持将请求只发送给健康的节点，避免请求失败。
同时，查询的响应时间和资源消耗，也会随着数据量的增长而变高，而Router支持设置查询的优先级和负载均衡策略，避免了大查询造成的队列堆积或查询热点等问题

如何分类

Druid的进程可以被任意部署，为了理解与部署组织方便，这些进程分为了三类：

Master：Coordinator、Overlord 负责数据可用性和摄取
Query：Broker、Router 负责处理外部请求
Data：Historical、MiddleManager，负责实际的Ingestion负载和数据存储

其他依赖

Deep Storage
存放生成的 Segment 数据文件，并供历史服务器下载，对于单节点集群可以是本地磁盘，而对于分布式集群一般是HDFS。

Druid使用 Deep Storage来做数据的备份，也作为Druid进程之间在后台传输数据的一种方式
当相应查询时，Historical首先从本地磁盘读取预取的段，这也意味着需要在Deep Storage和加载的数据Historical中拥有足够的磁盘空间。

Metadata Storage

存储Durid集群的元数据信息，如Segment的相关信息，一般使用MySQL。

ZooKeeper

为Durid集群提供以执行协调任务，如内部服务的监控，协调和领导者选举

Coordinator 节点的 Leader 选举
Historical 节点发布 Segment 的协议
Coordinator 和 Historical 之间 load、drop Segment的协议
Orverlord节点的Leader选举
Overlord和MiddleManger之间Task管理

架构演进

初始版本~0.6.0

2012-2013年
在这里插入图片描述

0.7.0~0.12.0

2013年-2018年

在这里插入图片描述

集群管理

在这里插入图片描述

0.13.0~当前版本

在这里插入图片描述

Lambda架构

从大的架构上看，Druid是一个Lambda架构。
Lambda架构是由Storm坐着Nathan Marz提出的一个实时大数据处理框架，Lambda架构设计是为了处理大规模数据时，同时发挥流处理和批处理的优势：

通过批处理提供全面、准确的数据
通过流处理提供低延迟的数据
从而达到平衡延迟、吞吐量和容错性的目的，为了满足下游的及时查询，批处理和流处理的结果会合并。

Lambda架构包含三层：BatchLayer、SpeedLayer、Serving Layer

BatchLayer：批处理层，对离线的历史数据进行预计算，为了下游能够快速查询想要的结果，由于批处理基于完成的历史数据集，准确性可以得到保证，批处理层可以用Hadoop、Spark、Flink等框架计算。
SpeedLayer：加速处理层，处理实时的增量数据，这一层重点在于低延迟，加速层的数据不如批处理层那样完整和准确，但是可以填补批处理高延迟导致的数据空白。加速层可以使用Storm、Spark Streaming和Flink等框架计算。
ServingLayer：合并层，将历史数据、实时数据合并在一起，输出到数据库或者其他介质，供下游分析

在这里插入图片描述