druid 关键技术点回顾

一、druid 的设计原则方式

1、快速查询：
（1）、实现技术点，内存使用上精细设计，（例如在druid中使用bitMap 压缩技术）
（2）、维护一些倒排索引（可以加快And和 Or 的计算操作）
2、水平扩展能力：
（1）、druid 查询性能很大程度依赖于内存的优化使用，数据可以分布在多个节点的内存中。数据增长的时候，可以通过简单增加机器的方式进行扩容。只是按照时间切分有时候是不够的（druid 的每个segment 不超过2000万行），故druid 还支持对segment进一步分区。
（2）、历史的segment数据可以保存在深度存储系统中，存储系统可以是本地磁盘、hdfs或远程的云服务等。
（3）、druid 的查询模块能够告知和处理集群的状态变化，查询总是在有效的集群架构上进行。并且集群上的查询可以进行灵活的水平扩展。druid 内置提供一些容易并行化聚合操作。对于一些无法并行化的操作，druid 提供了一些近似计算的方法进行支持。如hyperLoglog等
3、实时分析：
druid数据不支持更新操作。对于历史数据的druid 以segment 数据文件方式组织，并且将他们存储到升读存储系统中。当需要查询这些数据的时候，druid 再从升读存储系统中将它们装载到内存中供查询使用。

二、druid 的技术特点

1、数据吞吐量大
druid每天可以处理几十亿到几百亿的事件，因此很多公司看重了其吞吐能力，用于解决数据爆炸的问题。
2、流式数据摄入的支持
能直接再分析平台面直接对接各种流式数据源，如kafka 等。
3、查询灵活且快
druid 支持再任何维度组合上进行查询，访问速度极快，成为分析平台最重要的杀手锏。
4、社区支持度大。

三、druid 架构概览

集群包含三方面的外部依赖，
（1）、元数据库：存储druid集群的元信息，比如segment相关元信息。
（2）、分布式协调服务（coordination）：为druid 集群提供一致性协调服务组件
（3）文件存储：存放生成segment 数据文件。
druid 采用类lsm-tree架构中实时节点负责消费实时数据。与经典Lsm-tree 架构不同的是，druid 不提供日志及实行wal 原则，
（1）、实时数据首先被直接加载进实时节点内存中的堆结构缓冲区，（相当于memtable）.当条件满足时，缓存区里的数据会被冲写到硬盘上形成一个数据块，同时实时节点又会立即将新生成的数据块加载到内存的非堆区中。因此无论堆结构缓冲区还是非堆区里的数据，都能够被查询节点查询。
（2）、实时节点会周期性的将磁盘上同一个事件段内生成的所有数据块合并成一个大的数据块segment。这个过程再实时节点中叫做segment merge 操作。也相当越Lsm-tree 架构中数据合并操作。
（3）、合并好的segment 会立即被实时节点上传到数据文件存储库中。随后协调节点（Coordinator node）会指导一个历史节点（historical node） 去文件存储库，将新生成的segment 下载到本地磁盘中。当历史节点成功加载到segment后。会通过分布式协调服务（coordination）再集群中声明其从此刻开始服务该segment的查询。
（4）、实时节点收到该声明之后会立即向集群中声明此刻自己不再提供该segment的查询，接下来查询节点会转从该历史节点查询此segment数据。
（5）对于全局来说，查询节点会同时从实时节点（少量数据）。与历史节点（大量数据）分别查询。然后做个结果整合，最后返回给用户。
这种查询方式借鉴命令查询职责分离模式，这也是druid不同于hbase等lsm-tree 系列架构的一个显著特点。

三、druid 的架构包含 6 个不同的组件。

Coordinator：顾名思义，Coordinator 就是协调器，主要负责 segment 的分发等。比如我们只保存 30 天的数据，这个规则就是由 Coordinator 来定时执行的。
Overlord：处理数据摄入的 task，将 task 提交到 MiddleManager。比如使用 Tranquility 做数据摄入的时候，每个 segment 都会生成一个对应的 task。
Broker : 处理外部请求，并对结果进行汇总。
Router : Router 相当于多个 Broker 前面的路由，不是必须的。
Historical ：Historical 可以理解为将 segment 存储到本地，相当于 cache。相比于 Deep Storage 的，Historical 将 segment 直接存储到本地磁盘，只有 segment 存储到本地才能被查询。其实这个地方是有点异于直观感受的。正常我们可能会认为查询先查本地，如果本地没有数据才去查 Deep Storage，但是实际上如果本地没有相应的 segment，则查询是无法查询的。
Historical 处理那些 segment 是由 Coordinator 指定的，但是 Historical 并不会和 Coordinator 直接交互，而是通过 Zookeeper 来解耦。
MiddleManager : MiddleManager 可以认为是一个任务调度进程，主要用来处理 Overload 提交过来的 task。每个 task 会以一个 JVM 进程启动。