本篇文章主要概括了druid的整体概括

• druid的整体架构
• druid的优点
• druid的缺点
• druid的适用场景

druid系列文章：

• 1、druid整体概览
• 2、druid的存储原理
• 3、druid的index服务原理
• 4、druid的查询原理
• 5、druid的索引解析

druid是做什么的？

Apache Druid（正在孵化）是一个实时分析数据库，旨在对大型数据集进行快速切片和切块分析（“ OLAP ”查询）。Druid最常用作数据库，以支持对实时摄取，快速查询性能和高正常运行时间很重要的用例。因此，Druid通常用于为分析应用程序的datasource，或用作需要快速聚合的高并发API的后端。德鲁伊最适合面向事件的数据。

德鲁伊的核心体系结构结合了数据仓库，时间序列数据库和日志搜索系统的思想。

整体架构：

Druid 的架构是 Lambda 架构，分成实时层和批处理层。主要的节点包括（PS: Druid 的所有功能都在同一个软件包中，通过不同的命令启动）：

• Coordinator节点 负责集群segment的管理和发布，并确保segment在historcal节点中的负载和均衡。
• Overlord 节点：Overlord 负责接受任务、协调任务的分配、创建任务锁以及收集、返回任务运行状态给客户端；在Coordinator 节点配置asOverlord这个选项，让 Coordinator 具备 Overlord 功能，这样减少了一个组件的部署和运维。（我们目前就是这么部署的）。
• MiddleManager 节点：负责接收 Overlord节点分配的索引任务，创建并启动Peon实例来执行索引任务，一个MiddleManager可以运行多个 Peon 实例。
• Broker 节点：负责从客户端接收查询请求，并将查询请求转发给 Historical 节点和 MiddleManager 节点。Broker 节点需要感知 Segment 信息在集群上的分布。
• Historical 节点：负责按照规则加载非实时窗口的Segment。
• Router 节点：可选节点，在 Broker 集群之上的API网关，有了 Router 节点 Broker 不在是单点服务了，提高了并发查询的能力，而且集群可以根据数据情况做分层路由，使整个集群变得灵活很多。

Druid的一些特性：

• 列式存储格式。Druid使用面向列的存储，这意味着它仅需要加载特定查询所需的确切列。这极大地提高了仅命中几列的查询的速度。此外，每列都针对其特定数据类型进行了优化存储，从而支持快速扫描和聚合。
• 可扩展的分布式系统。Druid通常部署在数十到数百台服务器的群集中，并且可以提供每秒数百万条记录的接收速率，数万亿条记录的保留以及亚秒级到几秒的查询延迟。
• 规模并行处理。Druid可以在整个集群中并行处理查询。
• 实时或批量摄取。德鲁伊可以实时（批量获取被查询的数据）或批量提取数据。
• 自我修复，自我平衡，易于操作。作为操作员，要扩展或扩展集群，只需添加或删除服务器，集群就会在后台自动重新平衡自身，而不会造成任何停机。如果任何Druid服务器出现故障，系统将自动绕过损坏，直到可以更换这些服务器为止。Druid设计为24/7全天候运行，而无需出于任何原因而导致计划内停机，包括配置更改和软件更新。
• 云原生的容错架构，不会丢失数据。一旦Druid摄取了数据，副本就安全地存储在深度存储（通常是云存储，HDFS或共享文件系统）中。即使每台Druid服务器发生故障，也可以从深度存储中恢复数据。对于仅影响少数Druid服务器的有限故障，复制可确保在系统恢复时仍可进行查询。
• 用于快速过滤的索引。Druid使用CONCISE或 Roaring压缩的位图索引来创建索引，以支持快速过滤和跨多列搜索。
• 基于时间的分区。德鲁伊首先按时间对数据进行分区，然后可以根据其他字段进行分区。这意味着基于时间的查询将仅访问与查询时间范围匹配的分区。这将大大提高基于时间的数据的性能。
• 似算法。德鲁伊包括用于近似计数区别，近似排名以及近似直方图和分位数计算的算法。这些算法提供有限的内存使用量，通常比精确计算要快得多。对于精度比速度更重要的情况，德鲁伊还提供了精确的计数区别和精确的排名。
• 摄取时自动汇总。Druid可选地在摄取时支持数据汇总。这种汇总会部分地预先聚合您的数据，并可以节省大量成本并提高性能。

什么时候使用Druid

如果您的用例适合以下几个描述符，则Druid可能是一个不错的选择：

• 插入率很高，但更新很少。
• 您的大多数查询都是聚合查询和报告查询（“分组依据”查询）。您可能还具有搜索和扫描查询。
• 您将查询等待时间定为100毫秒到几秒钟。
• 您的数据具有时间成分（Druid包括与时间特别相关的优化和设计选择）。
• 您可能有多个表，但是每个查询仅命中一个大的分布式表。查询可能会击中多个较小的“查找”表。
• 您具有高基数数据列（例如URL，用户ID），并且需要对其进行快速计数和排名。
• 您要从Kafka，HDFS，平面文件或Amazon S3之类的对象存储中加载数据。

情况下，您可能会不希望使用德鲁伊包括：

• 您需要使用主键对现有记录进行低延迟更新。Druid支持流插入，但不支持流更新（使用后台批处理作业完成更新）。
• 您正在构建脱机报告系统，其中查询延迟不是很重要。
• 您想执行“大”联接（将一个大事实表连接到另一个大事实表），并且可以花很长时间来完成这些查询。

总结起来就是 Druid适合高并发的亚秒级响应的聚合查询，但是针对大数据量的全局聚合查询是有待考量的，比较慢，我这边测试4.5亿级别的数据，两个字段或者一个字段的聚合，全局数据查询在40S左右（historacal节点是8g的jvm和12g的off heap space 2个；broker节点是12g的jvm 1个），时间比较长，跟kylin比，就差了一大截。但是Druid就是擅长基于时间序列的查询，时间跨度越大，就会越慢一些。Druid更厉害的一点是稳定，面对高并发请求，时效稳定很多，服务没有明显的瓶颈点。

后续的文章会稍微扒一扒细节，尤其是跟竞品的比较，以及druid的离线导入以及查询的细节，看看有啥可以捯饬的。