ToB企服应用市场:ToB评测及商务社交产业平台

标题: Druid【基础 01】是什么+主要特点+设计原则+架构+数据结构（简单入门Druid [打印本页]

作者: 惊雷无声 时间: 2024-7-27 06:15
标题: Druid【基础 01】是什么+主要特点+设计原则+架构+数据结构（简单入门Druid
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大特点：

Column-oriented storage 列式存储格式。Druid利用面向列的存储，这意味着，它只需要加载特定查询所需要的列。这为只差看几列的查询提供了巨大的速率提升。别的，每列都针对其特定的数据范例进行优化，支持快速扫描和聚合。
Native search indexes 当地化的搜索索引。Druid为字符串值创建反向索引，利用CONCISE或Roaring压缩位图索引来创建索引，这些索引可以快速过滤和跨多个列搜索。
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还支持独特的利用符，这些利用符利用其近似算法套件来提供快速计数、排序和分位数。

Horizontal scalability 程度伸缩（可扩展的分布式系统）。Druid通常部署在数十到数百台服务器的集群中，并且提供数百万条/秒的摄取率，保留数百万条记录，以及亚秒级到几秒钟的查询延迟。
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️⃣ 类节点：

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

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

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

5. 数据结构

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

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

Timestamp 时间列：表明每行数据的时间值，默认利用 UTC时间格式且准确到毫秒级别。这个列是数据聚合与范围查询的重要维度。跟HBase的时间戳类似。
Dimensions 维度列：维度来自于 OLAP 的概念，用来标识数据行的各个种别信息。
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等技能对数据的访问进行了优化。

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。

欢迎光临 ToB企服应用市场:ToB评测及商务社交产业平台 (https://dis.qidao123.com/)