当前位置:首页 » 《关于电脑》 » 正文

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

20 人参与  2024年10月09日 16:00  分类 : 《关于电脑》  评论

点击全文阅读


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

目前已经更新到了:

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


点击全文阅读


本文链接:http://zhangshiyu.com/post/169583.html

<< 上一篇 下一篇 >>

  • 评论(0)
  • 赞助本站

◎欢迎参与讨论,请在这里发表您的看法、交流您的观点。

关于我们 | 我要投稿 | 免责申明

Copyright © 2020-2022 ZhangShiYu.com Rights Reserved.豫ICP备2022013469号-1