Druid【基础 01】是什么+主要特点+设计原则+架构+数据结构（简单入门Druid）

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

1. 是什么

先看看官网怎么说：

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还支持独特的操作符，这些操作符利用其近似算法套件来提供快速计数、排序和分位数。

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

可以提炼出的特点：

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

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

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

3. 三个设计原则

1️⃣ fast query 快速查询：部分数据的聚合（partial aggregate）+ 内存化（in-emory）+ 索引（index）。

2️⃣ horizontal scalability 水平扩展能力：分布式数据（distributed data）+ 并行化查询（parallelizable query）。

3️⃣ realtime analytics 实时分析：不可变的过去，只追加的未来（immutable past，append-only future）这个特点跟hbase很像。

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等技术对数据的访问进行了优化。