点一下关注吧!!!非常感谢!!持续更新!!!
目前已经更新到了:
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会所有节点的数据进行合并,然后返回给ClientRouter Node
(可选)
负责将路由转发到Broker、Coordinator、Overlords
如何分类
Druid的进程可以被任意部署,为了理解与部署组织方便,这些进程分为了三类:
Master:Coordinator、Overlord 负责数据可用性和摄取Query:Broker、Router 负责处理外部请求Data:Historical、MiddleManager,负责实际的Ingestion负载和数据存储其他依赖
Deep Storage
存放生成的 Segment 数据文件,并供历史服务器下载,对于单节点集群可以是本地磁盘,而对于分布式集群一般是HDFS。
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