标签：storage 支持 分享 均衡 细粒度 his over api zookeeper
Druid是一个以Java编写的开源分布式列式数据存储。 Druid的目标是快速提取大量事件数据，并提供低延迟的查询。
德鲁伊的名字来源于许多角色扮演游戏中的变形德鲁伊角色，以表示其系统结构可以为解决不同类型数据问题而灵活改变。 Druid通常用于OLAP（Online analytical processing）应用程序来分析大量的实时和历史数据。
为了方便使用以及cloud-friendly，Druid拥有一个多进程、分布式架构。 Druid按功能分为多种node，每个类型node都可以独立配置和扩展，为Druid群集提供最大的灵活性。 该设计还提供增强的容错能力：一个组件的中断不会立即影响其他组件。
Druid的node类型包括：
如下图所示为Druid的架构图：
Druid的架构将服务划分的比较细，有利于动态扩展和在云上部署。但个人觉得略显复杂的架构，并不是很方便部署和运维，尤其是其依赖了过多的外部组件。
Druid各个node进程可以单独部署或者合设到同一台机器上，一个常用的部署方式：
此外，Druid还依赖3个外部组件：
Druid将数据存储在"datasources"里，相当于传统RDBMS的表格。每个datasource用时间进行分区（可选其他属性进行进一步分区）。每个时间范围（如按天分区，则时间范围为一天）称为一个"chunk" 。在一个chunk里，数据进一步分区为一个或多个"segments"。每个segment是一个单独文件，存储大约几百万行数据。
一个datasource可能包含从几个segments到几百万几个segments。每个segment由MiddleManager创建，然后经过如下步骤的处理以生成紧凑的文件并支持快速查询：
Segments周期性的提交和发布，此时他们写入Deep storage，并不允许再修改，并从MiddleManager转移到Historical。该Segment对应的一条记录写入到metadata store。该记录用一些bits来描述segment的属性，如segment的schema、大小以及其所在deep storage位置。这些信息都是Coordinator需要用到的。
收到查询请求后，Broker根据请求先定位到哪些segments可能包含查询需要的数据，然后根据segments定位并发送请求到对应的Historicals和MiddleManagers。然后Historical/MiddleManager进程查询获取具体的数据并返回结果。Broker最后将查询结果汇聚后返回给调用者。
Broker pruning(裁剪)是Druid限制每个查询请求需要扫描的数据量的重要方式，但它不是唯一方法。过滤器提供了更细粒度的裁剪方法，每个Segment内的索引结构可以帮助Druid过滤出需要查询的行。这样Druid可以只读取匹配了查询过滤器的行，从而跳过不需要读取的行。
所以Druid通过如下3个方法提供查询的性能：
标签：storage 支持 分享 均衡 细粒度 his over api zookeeper
原文地址：https://www.cnblogs.com/jimbo17/p/9703030.html
