开放原子开发者工作坊

引言

Druid 是一个快速，近实时的查询海量只读数据的系统。Druid 的目标是可用性要达到100%，即使在部署新代码，或者某些节点 down 机的情况下。

Druid 目前支持的单表查询方式和 Dremel，PowerDrill 比较相似。它的主要特性如下：

1．支持嵌套数据的列式存储
2．层级查询
3．二级索引
4．实时数据抽取
5．分布式容错架构

同 PowerDrill 和 Dremel 相比，从功能的角度来说，Druid 几乎实现了 Dremel 提供的所有功能，并且参考了 PowerDrill 的数据存储和压缩方法。

Druid非常适合需要实时从一个数据流中摄取大量数据的产品。特别的，如果您希望零宕机，并且您的数据是时间序列数据，就再适合不过了。如何您更需要查询的灵活性和原始数据，那 Druid 就不是一个很好地选择。

架构

Druid 是由一系列不同角色的组件组成的系统。不同的组件如下：

历史节点（Historical Node）：

该节点负责存储数据和查询。历史节点从深度存储中下载数据分片（segment），并且响应来自查询节点的查询。历史节点会定期刷新本身存贮的 数据分片信息到 zookeeper，并且通过 zookeeper得到需要加载或者卸载哪些数据分片。

实时节点（Realtime Node）:

实时节点负责摄取实时数据。它们负责监听一个数据流，并把数据发到 Druid 系统当中。实时节点也接受来自查询节点的查询，并把结果返回。实时节点会把历史数据写到深度存储中。实时节点会查询 zookeeper，并确认当前存储在实时节点的数据分片是否已经上传至历史节点。如果已经上传，实时节点将删除该数据分片。

协调节点（coordinator node）:

协调节点会监控所有的历史节点，确保所有数据是可用的，多副本的。协调节点会从存储 meta data 数据源中读取 meta data 信息，去决定哪些数据分片应该在 druid 集群当中。协调节点用 zookeeper 发现哪些历史节点存在，并且通过 zookeeper 去通知历史节点装载和卸载相应的数据分片。

查询节点（broker node）:

查询节点接受从客户端来的查询，并转发这些查询到实时节点和历史节点。查询节点得到分别来自实时节点和历史节点的数据后，对这些数据进行合并，然后返回给客户端。查询节点也是利用zookeeper 去发现实时和历史节点的存在。

这种节点划分方式使得不同节点只需要处理好自己擅长的事情。

下面是在这个架构下地数据流图：

下面这张图，显示的是 Druid 集群是如何运作管理的，显示了节点之间是如何通过 meta data 进行协调运作的

（未完待续）

---

OneAPM Mobile Insight以真实用户体验为度量标准进行 Crash 分析，监控网络请求及网络错误，提升用户留存。访问 OneAPM 官方网站感受更多应用性能优化体验，想阅读更多技术文章，请访问 OneAPM 官方技术博客。