druid是什么意思（druid是干嘛的）



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

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

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

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

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

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

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

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

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

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

• 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负载和数据存储

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

Metadata Storage

ZooKeeper

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

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

2013年-2018年

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

版权声明：

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如若内容造成侵权、违法违规、事实不符，请将相关资料发送至xkadmin@xkablog.com进行投诉反馈，一经查实，立即处理！

转载请注明出处，原文链接：https://www.xkablog.com/rfx/32861.html