这篇文章主要介绍“Druid有什么特点”，在日常操作中，相信很多人在Druid有什么特点问题上存在疑惑，小编查阅了各式资料，整理出简单好用的操作方法，希望对大家解答”Druid有什么特点”的疑惑有所帮助！接下来，请跟着小编一起来学习吧！

创新互联坚持“要么做到，要么别承诺”的工作理念，服务领域包括：成都做网站、成都网站制作、成都外贸网站建设、企业官网、英文网站、手机端网站、网站推广等服务，满足客户于互联网时代的南关网站设计、移动媒体设计的需求，帮助企业找到有效的互联网解决方案。努力成为您成熟可靠的网络建设合作伙伴！

Druid 命名来自游戏中的德鲁伊角色，比如在Dota里德鲁伊有人和熊两种形态，还可以召唤小熊，不多说废话了。主要比喻面向各种场景都能适用。

Druid 针对的数据是日志数据。什么是日志呢？日志就是系统中发生的事情的记录。比如你在百度百科里编辑了一个词条，会产生一个日志，这个日志包含你操作的时间、你的名字、你编辑的条目、增加了多少字、去掉了多少个字等属性。这些属性中，时间是必不可少的，每个日志都有一个时间戳 time，long类型，时间戳也主要作为查询语句中的过滤条件；其他属性比如你的名字，条目等作为属性维度 dimension，通常为字符串类型；增加了多少个字，去掉了多少个字这种属性叫做度量列，metric，通常为数值类型。

日志数据通常按照时间顺序产生的。系统不可能产生一条2点的日志，又产生一条1点日志。但是，日志在从产生后，传输到另一个地方是可能出现乱序的。

通常日志数据存储在 Hadoop 中，但是 hadoop 没有对查询过滤提供很好的支持，无法满足用户的交互查询需求。同时，用户需要高可用，0 宕机重启时间。

Druid 中一共有 4 种类型的节点。注意是 4 种类型，每种类型的节点都可以有多个。我们一个一个介绍：

Real-time 节点：

这些节点的本质是 Kafka 的消费者。用来处理实时到达的数据。因此，这些节点的性质和 Kafka 的 consumer 一样。比如他们属于一个 消费者组，去消费 Kafka 的一个 Topic。这样他们的数据就不重复。当然他们也可以作为不同的 消费者组 去消费，这样他们的数据就是重复的，重复不一定是坏事，重复可以做副本。 

Real-time 节点在内存中维护一个索引，随着日志数据的到达，会先加到内存索引中，并周期性的将索引和当前内存数据持久化到磁盘上，比如每 10 分钟持久化一次，或者每处理10000条数据持久化一次。每次持久化的数据和索引不可更改，这也简化了其系统设计。

一个 read-time 节点负责的数据段是有时间限制的，比如当前节点只接收 1点-2点的数据，当过了2点之后，不再接收1点-2点的数据，而开始接收2点-3点的数据。由于1点-2点的数据已经被写到磁盘了。需要一个合并任务来将这些数据和索引合并成一份。叫做 Segment。Segment 是 Druid 数据存储的基本单位。

Historical 节点：

Real-time 节点整理好的 Segment，交给了底层存储。Historical 节点负责从底层存储中读取 Segment，读到内存中以供查询。

Historical 节点独立工作，互不感知。Historical 节点维护了一个 cache，缓存一部分 Segment，每次需要读取一个 Segment 时，先检查 Cache，如果 Cache 没命中，再去底层存储下载 Segment。

Historical 节点可以划分为不同层次。 各个层次可以单独配置。比如，可以将系统中那些性能比较好的 Historical 节点组成一个 热数据层，性能一般的节点组成 冷数据层。这样，热数据层的 Historical 节点就可以频繁加载数据。主要为了异构集群的负载均衡。

Broker 节点；

这些节点负责查询路由和结果合并。Broker 节点也有个 cache，主要维护了查询请求和对应的结果。这个结果只维护了 Historical 节点的查询结果，因为 real-time 节点的数据是实时的、不断变化的。如果 Historical 节点的 Segment 满足 cache了，就直接读 cache，剩下的再发送请求去读数据。

这个节点还负责结果合并。由于一次查询请求可能涉及多个节点，因此需要结果合并。

Coordinator 节点：

MySQL 中存储了每个 Segment 的元信息，Real-time 节点每处理完一个 Segment，会将其信息注册到 MySQL 中。除此之外，MySQL 还存了一个 规则表，用来定义冷热 Segment。在这种分布式系统中，关系关系数据库如 MySQL 的功能基本就是管理系统元数据。

Coordinator 节点与 MySQL 相连，读到了所有 Segment 信息，就开始把各个 Segment 分配到各个 Historical 节点上，负责 Historical 节点的负载均衡。还可以控制 Segment 的复制因子。由于副本的存在，各个节点都可以随时替换，完成不宕机情况下的软件升级。

按数据范围和时间段划分 Segment 。比如数据跨度为1年，1天一个 Segment 就比较合适。按照时间划分 Segment 后，就可以按照时间进行过滤，相当于时间是主索引。

其次，Segment 是列式存储的，每列可以选择编码和压缩方式。一般 String 类型选择字典编码。RLE 、BitMap等。

存储模型没什么特殊的地方，基本都是列式存储的特点。

Druid 的基本数据组织为 Segment ，由 data source identifier、时间段、一个递增的版本号、 partition id（分区号）唯一确定。当 real-time 节点属于同一个consumer group，他们各自消费的数据是不重叠的，这时这些 real-time 节点产生的同一个时间段的 segment 都是一个版本的，只是 partition id 不一样。这时一个时间段的所有 Segment 组成了一个 block，当这个 block 的数据都准备好后才会执行查询。

到此，关于“Druid有什么特点”的学习就结束了，希望能够解决大家的疑惑。理论与实践的搭配能更好的帮助大家学习，快去试试吧！若想继续学习更多相关知识，请继续关注创新互联网站，小编会继续努力为大家带来更多实用的文章！