前言
本文隶属于专栏《大数据技术体系》，该专栏为笔者原创，引用请注明来源，不足和错误之处请在评论区帮忙指出，谢谢！
本专栏目录结构和参考文献请见大数据技术体系
概述
Apache Druid 是一个实时分析型数据库，旨在对大型数据集进行快速的查询分析（OLAP 查询）。
Druid 最常被当作数据库用以支持摄取、高性能查询和高稳定运行的应用场景，通过 Druid 也常用作为 GUI 分析应用程序提供动力的数据存储，或者用作需要快速聚合的高并发 API 的后端。
Druid 最适合应用于面向事件类型的数据。
应用领域
Druid 常见的应用领城包括：
- 点击流分析（网络和移动分析）。
- 网络遥测分析（网络性能监控）。
- 服务器指标存储。
- 供应链分析（制造指标）。
- 应用程序性能指标。
- 数字营销/广告分析。
- 商业智能 /OLAP。
主要特征
Druid 的核心架构吸收和结合了数据仓库、时序数据库以及检索系统的优势，其主要特征如下：
- 列式存储：Druid 使用列式存销，这意味着在一个特定的数据套询中它只需要查询特定的列，这样极大地提高了部分列查询场景的性能。另外，每一列数据都针对特定数据类型做了优化存储，从而支持快速的扫描和聚合。
- 可扩展的分布式系统：Druid 通常以集群形式对外提供服务，集群规模可达数十甚至数百台，并且可以提供每秒数百万条记录的接收速率、数万亿条记录的保留存储以及亚秒级到几秒的查询延迟。
- 大规模并行处理：Druid 可以在集群中并行处理查询。
- 实时或批量摄取：Druid 可以实时（已经被摄取的数据立即可查）或批量摄取数据。
- 自修复、自平衡、易于操作：伸缩集群只需添加或删除服务，集群就会在后台自动重新平衡数据，而不会造成任何停机。如果任何一台 Druid 服务器发生故障，系统將自动绕过损坏。Druid 设计为 7 x 24h 全天候运行，不会出于任何原因而导致计划内停机，包括配置更改和软件更新。
- 不会丢失数据的云原生容错架构：一旦 Druid 摄取了数据，副本就安全地存储在深度存储介质 （通常是云存储、HDFS 或共享文件系统）中。即使某个 Druid 服务发生故障，也可以以从深度存储中恢复效据，对于仅影响的少数 Druid 服务的有限故障，副本可确保在系统恢复时仍然可以进行查询。
- 快速过滤的紫引：Druid 使用由 CONCISE 或 Roaring 压缩的位图索引来创建索引，以支持快速过滤和跨多列搜素。
- 基于时间的分区：Druid 首先按时间对数据进行分区，另外同时可以根据其他字段进行分区，这意味着基于时间的查询将仅访问与查询时间范围匹配的分区，这将大大提高基于时间的数据的性能。
- 近似算法：Druid 应用了近似 count-distinct、近似排序以及近似直方图和分位数计算的算法，这些算法占用有限的内存使用量，通常比精确计算要快得多；对于精度要求比速度更重要的场景，Druid还提供了精确 count-distint 和精确排序。
- 自动汇总聚合：Druid 支持在数据摄取阶段进行数据汇总，这种汇总会部分预先聚合数据，并可以节省大量成本并提高性能。
适合场景
- 数据插人频率比较高，但较少更新数据。
- 大多数查询场景为聚合查询和分组查询（GroupBy)，同时还有一定的检索与扫描查询。
- 将数据查询延迟目标定位 100ms 到几秒钟之间。
- 数据具有时间属性（Druid 针对时间做了优化和设计）。
- 在多表场景下，每次查询仅命中一个大的分布式表，查询又可能命中多个较小的 lookup 表。
- 场景中包含高基维度数据列（例如 URL，用户 ID 等），并且需要对其进行快速计数和排序。
- 需要从 Kafka、HDFS、对象存储（如 Amazon S3） 中加载数据。
不适合场景
- 根据主键对现有数据进行低延迟更新操作，Druid 支持流式插人，但不支持流式更新（更新操作通过后台批处理作业完成）。
- 延迟不重要的离线数据系统。
- 场景最中包括大连接（将一个大事实表连接到另一个大事实表)，并且可以接受花费很长时间来完成这些查询。