点一下关注吧！！！非常感谢！！持续更新！！！
目前已经更新到了：
- 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