Druid ：大数据实时处理的开源分布式系统（1）

###引言

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 官方技术博客。