Druid架构面面观

2019 年 10 月 8 日
筆記

来源:知乎

作者:王boy

By 暴走大数据

场景描述：大数据时代，对于数据的各种操作要求往往是分离开的，比如有专门的系统负责插入，有专门的系统负责查询。druid的就很好的体现了这一点。

关键词：Druid 原理

Druid存在的意义

为理解druid的意义，需了解druid所面向的对象：大数据。了解大数据的一些特点属性，我们才能理解druid在利用大数据的哪个特点进行决策。

IBM曾提出大数据的5V特点：Volume（大量）、Velocity（高速）、Variety（多样）、Value（低价值密度）、Veracity（真实性）。

这些特点意味着什么？

意味着，传统的架构（比如单机、单节点结构）很难处理这些特点。

比如，“大量”这个特点决定了数据不可能在单块磁盘上存储下来，必须多块磁盘协作起来（单块磁盘如果能够达到PB级别，在现有的技术下，将会把硬盘做的很大，这样子造成的后果是，磁盘如果毁坏代价很大，另一个方面寻址的时间也会大大增加，因为盘面大了，机械臂寻址的路径就长了）。

比如，“高速”这个特点来源于，互联网的普及，群众创造数据的速度惊人，针对这个特点机器需要有专门的系统负责处理快速产生的数据，否则会有大量的信息会被丢弃。（实时处理系）

这些数据是“真实”的，但是却是“低价值密度”的。所以有必要对其进行提取，抽象（求和，求平均等），进而将这些小的价值收集起来，汇总成大的价值（规律）。

druid的作用

druid解决的问题在于，数据的快速摄入，数据的快速查询。它的摄入及查询是两个不同的系统，需要区别对待。

个人认为其特色在于，快速响应用户的查询请求，在其查询的结果中包含过去的历史数据，还有最近很短时间产生的查询结果（创新之处）。

基于MapReduce的工具框架，处理的大多是已经存放于硬盘的历史数据。这意味着处理的数据距离当前时间点有一定的差距，因为当前还有一段时间的数据中缓存在内存中，这些并没有参与到计算中来。druid的将内存中的数据和已经存储在内存中的数据都考虑进来，并进行了相应的汇总。

druid架构

理解druid，需要将其理解为两个系统，即输入系统和查询系统。

druid总体架构

【druid本身节点】Broker(查询)，RealTime(处理实时大数据)，Historical（处理批量数据），Coordinator(监控history节点数据的状态)
【依赖的外部节点】Metadata Storage （存储元数据信息），Deep Storage(永久存储数据信息)，Distributed Coordination(分布式协调节点，协调其他各节点的状态等信息)

接下来，分别就外部节点以及内部节点进行相应的说明。

依赖的外部节点有何作用？

Metadata Storage :

druid若要查询数据（比如查询2017年发生的事情），它需要将这些条件的信息找到（在哪个机器的哪个文件之中），然后再去筛选。去那里找这些数据，也就是位置信息，就是一种元数据信息（描述数据的存储位置），这些信息存储在Metadata Storage中，可以说Metadata Storage在某种程度上，起到了书本中目录的作用。

没有Metadata Storage之后，你将失去了进入各个数据文件的入口。

Deep Storage:

相对于前面而言，该节点负责的是存储的具体的数据（比如2017年具体的事件），要与前面的元数据区分开来。

该类存储的特点是：插入，读取慢，但能够永久存储。（本地硬盘，HDFS都是属于这类存储）

与Metadata Storage 相互配合，才能定位出数据所在位置，并且取出相应的数据。

Distributed Coordination:(比如Zookeeper)

该节点的作用在于协调各个节点。听起来很模糊，举一个简单的例子，zookeeper中保存着各个节点的状态（比如某个节点是否可用），然后创建了一个任务，要分配到相应的节点中去执行，先去zookeeper上查看相关的节点的状态，如果节点可用，并且资源较多，那么就把任务分配到该节点上。（节点可用，资源较多这些信息就是存储在zookeeper上的）

druid内部各节点的职责

查询节点

对外提供查询服务
调用实时节点、历史节点进行查询，合并两者的查询结果
【注意】查询的过程是漫长的，因为数据量大，但 broker本身只是把查询计算任务分配给了实时节点以及历史节点。它只是对于最后的结果进行了简单的汇总。
broker 根据zookeeper中的节点状态信息(历史节点，实时节点 )，去决定何时合并，如何合并在各个节点上查询出的结果。

实时节点

摄入实时数据
将实时数据生成Segment，存储到DeepStorage中
为查询数据进行服务
【注意】具有查询、摄入两种功能

历史节点

【可查询】为查询数据提供服务
不提供摄入服务
和DeepStorage关系紧密。
【进一步解释】因为DeepStorage只是提供了硬盘，而没有提供计算及内存。所以历史节点就担当了这些责任，从DeepStorage那里获得数据，加载到历史节点的内存中，然后进行计算。简而言之，history节点主要负责对于历史信息的查询计算。

协调者节点（与外部协调者相区分）

协调历史节点
相当于hadoop中的Jobtracker,只不过是针对查询的Jobtracker.
类似于Master-Slave结构，其中协调者是Master,而历史节点是Slave. Master根据Slave的资源使用等情况，对历史节点分配相应适当的任务。

索引服务节点

【责任】数据摄入
将数据摄入，并整理成Segment（druid中的高层抽象概念）的形式。
【结构】数据摄入是一个较为复杂的过程，所以单就索引服务方面而言就设计成了Master-Slave结构的形式。为何复杂呢？因为它需要把接收到的数据，存储到各台机器上，这意味着在每台相应的机器上还应该有负责在单个节点上进行存储的员工。Master负责选择机器，而Slave负责相关节点的数据存储转化。所以在索引服务中，又进一步划分成了三类节点：统治节点（即Master节点），中间管理者节点，苦工节点。
【统治节点】在分布式中的管理者，负责任务分配到相应的机器。
【中间管理者】在本地上，负责将任务分配到具体的进程。
【苦工】接受任务，然后真正办实事（具体任务的执行）。
【注意】与数据查询时，协调者节点与历史节点构成的Master-Slave节点相区分。此处针对的是数据摄入，为了快速摄入以及快速查询，所以将这两部分功能分开做了。

索引服务架构图：

各节点间的关系

查询及摄入的数据流图：

PS：

区分查询与摄入，这是理解该架构的关键点。
实时节点，历史节点属于数据节点。
多处使用Master-Slave结构（索引方式数据摄入，历史节点查询）
Coordinator & Index（lord,midmanager）有何区别？
摄入数据是通过index的方式摄入的，实时数据必须经过实时节点，而批量数据不经过历史节点，直接借助index节点被存入到DeepStorage中。

参考：

《Druid实时大数据分析原理与实践》

欢迎点赞+收藏