- 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
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容，请联系我们，一经查实，本站将立刻删除。
如需转载请保留出处：https://51itzy.com/kjqy/162615.html