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

目前已经更新到了：

• 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：合并层，将历史数据、实时数据合并在一起，输出到数据库或者其他介质，供下游分析

流式数据链路

Raw Data - Kafka - Streaming Processor（Optional 实时ETL）- Kafka（Optional）- Druid - Application/User

批处理数据链路

Raw data - Kafka（Optional） - HDFS - ETL Process（Optional）- Druid - Application/User