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

Druid入门

• 1. 是什么
• 2. 主要特点
• 3. 三个设计原则
• 4. Architecture 架构
• 5. 数据结构
• • 5.1 DataSource 结构
  • 5.2 Segment 结构

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

TAG：druid