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 官方技术博客。
这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。
V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。
V2EX is a community of developers, designers and creative people.