一，Druid介绍

Apache Druid是一个实时分析数据库，旨在对大型数据集进行快速切片和分析（“OLAP”查询）。Druid最常用作支持实时接收、快速查询性能和高正常运行时间的用例的数据库。因此，Druid通常用于支持分析应用程序的gui，或者作为需要快速聚合的高度并发api的后端。 OLAP(Online analytical processing)，即联机分析处理。

二，Druid特点：

1，列存储格式。 2，可扩展分布式系统，Druid通常部署在大数集群中，水平扩展能力强。 3，大规模并行处理。Druid可以跨整个集群并行处理一个查询。 4，实时或批量数据导入。Druid可以实时（摄取的数据可以立即用于查询）或成批地摄取数据。 5，自我修复，自我平衡，易于操作。添加或删除服务器，集群将在后台自动重新平衡，而不需要停机。 6，不会丢失数据。一旦Druid接收了您的数据，一个副本就安全地存储在深存储中（通常是HDFS）。 7，支持索引。 8，时序数据库，基于时间分区。 9，预聚合。Druid在数据摄入时可以做一些聚合操作，节省存储空间，提高性能。

三，Druid适合使用场景：

1，插入率非常高，但更新不太常见（最好不更新）。 2，大多数查询是聚合和报告查询（“分组依据”查询）。 3，查询延迟低，为100毫秒到几秒钟。 4，数据需要针对时间进行优化。 5，您可能有多个表，但每个查询只命中一个大的分布式表。查询可能会命中多个较小的“查找”表。 6，快速统计数据。

四，Druid不适合使用场景：

1，对现有记录进行低延迟更新。Druid支持流式插入，但不支持流式更新（更新是使用后台批处理作业完成的）。 2，需要执行join操作。

五，datasource and segment

Datasource：

相当于关系型数据库中的表名。 每一个datasource都被时间划分为chunk（块），比如说按天划分（也有可能会被其它属性进一步划分）。每一个chunk中会包含一个或者多个segment（段）。

"segmentGranularity": "day”

segment：

用于存储数据。 特点: 1,列式存储。每个列单独存储，读取数据时只需要读取需要的列不需要读取整条数据。 2,列分为三种类型 timestamp column （时间戳列） 单位：

iso: ISO8601 with 'T' separator, like "2000-01-01T01:02:03.456" posix: seconds since epoch millis: milliseconds since epoch micro: microseconds since epoch nano: nanoseconds since epoch auto: automatically detects ISO (either 'T' or space separator) or millis format any Joda DateTimeFormat string

dimension columns（纬度列）

单位：

string, long, float, or double.

默认单位是string，其它单位需要明确说明，格式：{“name”: “page”, “type”: “double”}。string类型的默认会创建bitmap，其它类型不能创建。

metric columns（度量列） 针对特定列进行预聚合运算

"metricsSpec": [ { "type": "count", "name": "count" }, { "type": "doubleSum", "name": "bytes_added_sum", "fieldName": "bytes_added" }, { "type": "doubleSum", "name": "bytes_deleted_sum", "fieldName": "bytes_deleted" } ]

type：聚合类型 name：聚合结果列名 fieldName：针对的列

segment命名规则：

datasource_intervalStart_intervalEnd_version_partitionNum dataSourceName_开始时间_截止时间_版本好_分区号

备注： segmentname反应到文件系统中是一个文件夹名字，没有分区的话就没有分区号，时间都是0时区，北京时间是东八区，比0时区早八小时。

sampleData_2011-01-01T02:00:00:00Z_2011-01-01T03:00:00:00Z_v1_0 sampleData_2011-01-01T02:00:00:00Z_2011-01-01T03:00:00:00Z_v1_1 sampleData_2011-01-01T02:00:00:00Z_2011-01-01T03:00:00:00Z_v1_2

对一个时间区间内所有的segments更新是原子操作，全部写成功后查询才会读取高版本数据。多个时间区间之间的更新操作不是原子操作，更新数据时最好不要跨区间。更新成功后低版本数据会很快被清理。

segment文件大小规划

建议1:每个segment文件大小在300MB-700MB范围内。 建议2:每个segment文件建议包含的数据条数为500万条。

建议2 优先于建议1 ，指定数据条数能直接控制查询时一个线程处理的数据量。

查询数据的时候，历史数据节点中每个线程负责查询一个segment，如果segment太大不利于查询的并行度；如果segment太小，线程池中线程之间的调度会花费大量额外时间。

下一篇: Druid服务介绍