入门介绍主要是基于官网的技术Druid | Technology官网的技术做了一些翻译和个人加工，大家若英文好，也可以直接看官网介绍。

Druid首先是一个完全开源的分布式时序数据库，这一点要优于InfluxDB（因为它只是单机版开源，分布式版本只存在于InflluxDB enterprise）。

我们从下图中可以看到Druid所关注的领域在时序数据库(Timeseries DBs)、数据仓库(Data warehouses)、搜索系统(Search systems)三者间的结合处，Druid官方也不甘心Druid只是时序数据库，更希望人们把它叫做高性能的实时分析数据库。

​官网图：Druid关注领域的三圆交集图

Druid特点

• 列式存储：Druid基于LSM-Tree数据模型，持久层按列存储和压缩，那么按特定列的排序、分组和扫描就会非常快。
• 原生支持搜索索引：Druid可以为字符串创建倒排索引实现搜索与过滤。
• 流批摄取：适配多种连接器和流处理(Kafka、HDFS、AWS S3等)，支持开箱即用。
• 柔性Schemas：Druid可以优雅地处理模式演进和内嵌数据。
• 针对时间进行优化的分区：Druid会自动基于时间的分区，那么这就对基于时间的查询，相比于传统数据库带来了显著的性能提升。(备注：基于时间的分区对于时序数据库查询很重要，InfluxDB也有类似策略，但OpenTSDB则没有)
• SQL支持：除了原生的基于JSON语言，Druid还可以通过HTTP或JDBC使用SQL。
• 水平扩展：Druid已经被用于生产环境下每秒摄取百万事件，对于保留多年的数据提供亚秒级的查询。
• 操作简单：集群中增加或删除服务器所形成的扩张与收缩，Druid都会自动均衡。围绕服务器故障的容错架构路由。

一体化

Druid作为流批一体的摄取中心，又服务于终端用户的查询或应用，因此它位于存储或处理层与终端用户之间，作为查询层服务于数据分析的工作负载。我们可以看到像Kafka、HDFS以及其他像Flink这样的流处理器都可以作为摄取源。

如下图Druid在Apache大数据开源生态中的位置示意图所示：

Druid在Apache大数据开源生态中的位置示意图

摄取

Druid对于数据源的摄取既支持流式也支持批量，例如：连接到Kafka加载流式数据，或者连接HDFS进行批量数据加载，不过Druid会对加载的原始数据进行所谓“Indexing”的转换，形成一种更加为了读取优化的格式，Druid内部称为：“segment”。

如下图流批摄取转换示意图所示：

流批摄取转换示意图

存储

Druid就像许多数据分析存储一样，数据以列存储，根据列的字段类型(例如：string、number等等)，应用不同的压缩或编码方法。Druid还基于列类型构建不同类型的索引。

类似于搜索系统，Druid为了对字符串列快速查询和过滤，建立了倒排索引。

类似于时序数据库，为了能面向时间的快速查询，Druid更智能地按照时间进行数据分区。

不同于许多传统系统，Druid在数据摄取时可以有选择地预聚合，这个预聚合步骤被称为上卷(rollup)，这能极大地节省存储空间。

如下图Druid数据列表示例图所示：

​Druid数据列表示例图

查询

Druid支持通过JSON-over-HTTP或SQL进行数据查询。除了标准SQL功能之外，Druid还支持一些专有功能，利用近似算法套件提供了快速计数、排名和分位数(quantiles)。

Druid查询交互示意图

架构

Druid基于微服务架构，可认为是个被拆分开了的数据库，在Druid中，每个核心服务(摄取、查询和调度)都能独立或联合的方式，部署在必要的硬件上。

Druid如此明确命名每个主服务，就是为了让操作者根据用例和工作负载好调整每个服务，例如：根据工作负载要求，操作者需要投入更多的资源给Druid摄取服务，同时将更少的资源分配给Druid查询服务。

那么这种架构下，Druid服务就算出现单独故障也是可以不影响到其他服务的操作。

如下图Druid分布式架构示意图所示：

Druid分布式架构示意图​​

部署依赖

Apache Druid依赖深度存储、元数据库和分布式协调器。

• 深度存储主要是解决数据高可靠问题，也就是说，如果Druid数据节点的持久化数据出现丢失，可以从深度存储中恢复。深度存储可以使用本地文件、Hadoop HDFS、Amazon S3等方式，我们这里选择HDFS。
• 元数据库存储集群元数据，包括Datasouce、Segments、Supervisors、Tasks、Rules等前期配置元数据与运行期产生的各项元数据。我们可以使用Derby、MySQL、PostgreSQL等方式，我们这里选择PostgreSQL。
• 分布式协调器是Apache Druid的核心部件，应用于Druid集群不用子服务之间的状态协调。Druid使用的分布式协同器为Zookeeper。

配置Druid集群

部署Druid集群主要考虑$DRUID_HOME/conf/druid/cluster下面的四个目录，分别是：_common、data、master、query，代表了通用性配置、数据节点配置、主节点配置、查询节点配置。

如果我们是按照最少的硬件资源配置，那就至少分配3个节点，每个节点都只具有1个功能服务。

• 通用配置，对应了_common目录。
• 主节点配置：对应master/coordinator-overlord目录，运行coordinator服务、overlord服务。
• 数据节点，对应data/historical，data/middleManager目录，运行historical服务、middleManager服务。
• 查询节点，对应query/broker，query/router目录，运行broker服务、route服务。

在此基础之上增加节点的话，建议先增加数据节点，实现数据节点在Druid上双副本(默认)，这样不仅可以带来数据节点服务的高可用，而且查询请求也可以实现多数据节点的均衡负载。

然后再增加查询节点和主节点，增强集群服务的高可用性和查询方面应对并发请求的均衡负载。

运行示例

我们可以从菜单栏的Load data->Start a new spec进入到Druid支持的各种数据源，我们可以看到Kafka、HDFS是常用的摄取源。

这个示例通过Hadoop HDFS来批量摄取数据，HDFS路径为：/example/simple1/sort/input/Rate_1000.csv，是一个CSV文件，我们可以看到指向该文件后，Druid就会对其进行解析。

 在我的HDFS路径/example/simple1/sort/input/Rate_1000.csv是一个CSV文件，我们可以看到指向该文件后，Druid就会对其进行解析。

我们还可以看到在解析时间的阶段Druid会自动发现importDate列适合作为时序的时间戳_time。

后面还会涉及一些字段过滤、字段转换、指标选择、rollup、分区等，这里就不再赘述，有时间专门写一个操作说明。最终会形成一个Json格式的规格声明，提交json文件到Druid。

Apache Druid不同于其他数据库的编程式写入模式：数据库提供编程接口，用户考虑数据转换的计算逻辑，最终通过程序调用接口实现写入。

Apache Druid类似于声明式摄取模式，也就是说，制作好一个任务的声明规格，那么Druid摄取服务会根据规格说明进行数据源的数据采集、过滤、转换、索引等一系列操作的计算管道逻辑。