Druid 非中文官网，内容不少且介绍的挺详细的，需要英文阅读能力或者翻译工具进行辅助。

1. 是什么

先看看官网怎么说：

Apache Druid is an open source distributed data store. Druid’s core design combines ideas from data warehouses, timeseries databases, and search systems to create a high performance real-time analytics database for a broad range of use cases. Druid merges key characteristics of each of the 3 systems into its ingestion layer, storage format, querying layer, and core architecture.

Druid 是一个分布式的支持实时分析的数据存储系统（Data Store）。Druid 设计之初的想法就是为分析而生，它在处理数据的规模、数据处理的实时性方面，比传统的OLAP 系统有了显著的性能改进，而且拥抱主流的开源生态，包括Hadoop 等。

Druid应用最多的是类似于广告分析创业公司MetaMarkets中的应用场景，如广告分析、互联网广告系统监控以及网络监控等。当业务中出现以下情况时，Druid是一个很好的技术方案选择：

• 需要交互式聚合和快速探究大量数据时；
• 具有大量数据时，如每天数亿事件的新增、每天数10T数据的增加；
• 对数据尤其是大数据进行实时分析时；
• 需要一个高可用、高容错、高性能数据库时。

2. 主要特点

官网的8大特点：

1. Column-oriented storage 列式存储格式。Druid使用面向列的存储，这意味着，它只需要加载特定查询所需要的列。这为只差看几列的查询提供了巨大的速度提升。此外，每列都针对其特定的数据类型进行优化，支持快速扫描和聚合。
2. Native search indexes 本地化的搜索索引。Druid为字符串值创建反向索引，使用CONCISE或Roaring压缩位图索引来创建索引，这些索引可以快速过滤和跨多个列搜索。
3. Streaming and batch ingest 实时或批量摄取。提供 Apache Kafka, HDFS, AWS S3，流处理器等的开箱即用连接器。可以实时摄取数据（实时获取的数据可立即用于查询）或批量处理数据。

4. Flexible schemas 模式灵活。Druid优雅地处理演进的模式和嵌套的数据。

5. Time-optimized partitioning 实时优化分区。Druid基于时间和基于时间的查询智能地划分数据，比传统数据库快得多。
6. SQL support SQL支持。除了原生的基于JSON的语言，Druid还通过HTTP或JDBC使用SQL。Druid支持通过 json over http 和SQL查询数据。除了标准SQL操作符外，Druid还支持独特的操作符，这些操作符利用其近似算法套件来提供快速计数、排序和分位数。

1. Horizontal scalability 水平伸缩（可扩展的分布式系统）。Druid通常部署在数十到数百台服务器的集群中，并且提供数百万条/秒的摄取率，保留数百万条记录，以及亚秒级到几秒钟的查询延迟。
2. Easy operation 操作简单。集群扩展和缩小，只需添加或删除服务器，集群将在后台自动重新平衡，无需任何停机时间。容错架构围绕服务器故障进行路由。

可以提炼出的特点：

Druid可以在整个集群中进行大规模的并行查询。支持原生云、容错的架构，不会丢失数据。一旦Druid吸收了您的数据，副本就安全地存储在深度存储中（通常是云存储、HDFS或共享文件系统）。即使每个Druid服务器都失败，也可以从深层存储恢复数据。对于仅影响少数Druid服务器的更有限的故障，复制确保在系统恢复时仍然可以执行查询。

Druid包括用于近似计数、近似排序以及计算近似直方图和分位数的算法。这些算法提供了有限的内存使用，并且通常比精确计算快得多。对于准确度比速度更重要的情况，Druid还提供精确的计数-明确和准确的排名。

插入数据时自动聚合。Druid可选地支持摄取时的数据自动汇总。预先汇总了您的数据，并且可以导致巨大的成本节约和性能提升。

3. 三个设计原则

1️⃣ Fast Query 快速查询：部分数据的聚合（Partial Aggregate）+ 内存化（In-emory）+ 索引（Index）。

  对于数据分析场景，大部分情况下，我们只关心一定粒度聚合的数据，而非每一行原始数据的细节情况。因此，数据聚合粒度可以是1 分钟、5 分钟、1 小时或1 天等。部分数据聚合（Partial Aggregate）给Druid 争取了很大的性能优化空间。
  数据内存化也是提高查询速度的杀手锏。内存和硬盘的访问速度相差近百倍，但内存的大小是非常有限的，因此在内存使用方面要精细设计，比如Druid 里面使用了Bitmap 和各种压缩技术。
另外，为了支持Drill-Down 某些维度，Druid 维护了一些倒排索引。这种方式可以加快AND 和OR 等计算操作。

2️⃣ Horizontal Scalability 水平扩展能力：分布式数据（Distributed Data）+ 并行化查询（Parallelizable Query）。

  Druid 查询性能在很大程度上依赖于内存的优化使用。数据可以分布在多个节点的内存中，因此当数据增长的时候，可以通过简单增加机器的方式进行扩容。为了保持平衡，Druid按照时间范围把聚合数据进行分区处理。对于高基数的维度，只按照时间切分有时候是不够的（Druid 的每个Segment 不超过2000 万行），故Druid 还支持对Segment 进一步分区。
  历史Segment 数据可以保存在深度存储系统中，存储系统可以是本地磁盘、HDFS 或远程的云服务。如果某些节点出现故障，则可借助Zookeeper 协调其他节点重新构造数据。
  Druid 的查询模块能够感知和处理集群的状态变化，查询总是在有效的集群架构中进行。集群上的查询可以进行灵活的水平扩展。

3️⃣ Realtime Analytics 实时分析：不可变的过去，只追加的未来（Immutable Past，Append-Only Future）这个特点跟HBase很像。

  Druid 提供了包含基于时间维度数据的存储服务，并且任何一行数据都是历史真实发生的事件，因此在设计之初就约定事件一但进入系统，就不能再改变。
  对于历史数据Druid 以Segment 数据文件的方式组织，并且将它们存储到深度存储系统中，例如文件系统或亚马逊的S3 等。当需要查询这些数据的时候，Druid 再从深度存储系统中将它们装载到内存供查询使用。

4. Architecture 架构

【官网介绍】基于微服务的体系结构，可以看作是一个可分解的数据库。Druid中的每个核心服务(摄取、查询和协调)可以单独或联合部署在商用硬件上。Druid明确地命名了每个主要服务，允许操作员根据用例和工作负载对每个服务进行微调。例如，如果工作负载需要，操作员可以将更多的资源分配给Druid的摄取服务，而将更少的资源分配给Druid的查询服务。Druid服务可以独立故障而不影响其他服务的操作。

Druid总体包含 5️⃣ 类节点：

1. MiddleManager Node 中间管理节点：及时摄入实时数据，已生成Segment数据文件。
2. Historical Node 历史节点：加载已生成好的数据文件，以供数据查询。historical 节点是整个集群查询性能的核心所在，因为historical会承担绝大部分的segment查询。
3. Broker Node 查询节点：接收客户端查询请求，并将这些查询转发给Historicals和MiddleManagers。当Brokers从这些子查询中收到结果时，它们会合并这些结果并将它们返回给调用者。
4. Coordinator Node 协调节点：主要负责历史节点的数据负载均衡，以及通过规则（Rule）管理数据的生命周期。协调节点告诉历史节点加载新数据、卸载过期数据、复制数据、和为了负载均衡移动数据。
5. Overlord Node 统治者：进程监视MiddleManager进程，并且是数据摄入Druid的控制器。他们负责将提取任务分配给MiddleManagers并协调Segement发布。

Druid还包含 3️⃣ 类外部依赖：

1. Deep Storage 数据文件存储库：存放生成的Segment数据文件，并供历史服务器下载，对于单节点集群可以是本地磁盘，而对于分布式集群一般是HDFS。
2. Metadata Store 元数据库：存储Druid集群的元数据信息，比如Segment的相关信息，一般用MySQL或PostgreSQL。
3. Zookeeper ：为Druid集群提供以执行协调服务。如内部服务的监控，协调和领导者选举。

5. 数据结构

与Druid架构相辅相成的是其基于DataSource与Segment的数据结构，它们共同成就了Druid的高性能优势。

5.1 DataSource 结构

与传统的关系型数据库管理系统比较，Druid的DataSource可以理解为 RDBMS 中的表Table。DataSource的结构包含以下几个方面：

1. Timestamp 时间列：表明每行数据的时间值，默认使用 UTC时间格式且精确到毫秒级别。这个列是数据聚合与范围查询的重要维度。跟HBase的时间戳类似。
2. Dimensions 维度列：维度来自于 OLAP 的概念，用来标识数据行的各个类别信息。
3. Metrics 指标列：指标对应于 OLAP 概念中的 Fact，是用于聚合和计算的列。这些指标列通常是一些数字，计算操作通常包括 Count、Sum 和 Mean等。

无论是实时数据消费还是批量数据处理， Druid在基于DataSource结构存储数据时即可选择对任意的指标列进行聚合（ RollUp）操作。该聚合操作主要基于维度列与时间范围两方面的情况。下图显示的是执行聚合操作后 DataSource的数据情况。

相对于其他时序数据库， Druid在数据存储时便可对数据进行聚合操作是其一大特点，该特点使得 Druid不仅能够节省存储空间，而且能够提高聚合查询的效率。

5.2 Segment 结构

DataSource是一个逻辑概念， Segment却是数据的实际物理存储格式， Druid正是通过 Segment 实现了对数据的横纵向切割（ Slice and Dice）操作。从数据按时间分布的角度来看，通过参数 segmentGranularity 的设置，Druid将不同时间范围内的数据存储在不同的 Segment数据块中，这便是所谓的数据横向切割。

这种设计为 Druid 带来一个显而易见的优点：按时间范围查询数据时，仅需要访问对应时间段内的这些 Segment数据块，而不需要进行全表数据范围查询，这使效率得到了极大的提高。

通过 Segment将数据按时间范围存储，同时，在 Segment中也面向列进行数据压缩存储，这便是所谓的数据纵向切割。而且在 Segment中使用了 Bitmap等技术对数据的访问进行了优化。