Druid基础介绍和系统架构

Druid介绍

Druid是什么

Druid("德鲁伊")是由广告公司MetaMarkets开源的实时大数据分析引擎，主要用于大规模事件流数据(Event Stream Data)的存储和分析。
Druid的设计之初就是支持PB级别数据量。Druid之所以能够保持高效，主要有以下个原因：

1. 预汇总，在数据摄入过程中对数据进行了轻度聚合汇总。
2. 数据结构优化，采用了列式存储和位图索引。
3. 高可用架构，系统无单点，支持滚动升级和在线扩展。
4. 高可扩展，可扩展至处理万亿数据、PB数据和1000+QPS。

我们知道Hadoop的设计之初就是为了批量处理大数据，所以在处理实时性上有很大的局限性。而Druid就是为了解决海量数据上的实时分析。数据分析一般有以下几类，也可以看成是实时数据分析的演变：

数据分析

目前使用很广泛的实时数据分析场景就是最后两个分析流程。将数据源进行流式处理，然后对接流式计算框架或分析引擎(OLAP)。

Druid的设计人员在设计之初，就确定了三个目标：

1. 快速查询(Fast Query)：数据预聚合(根据时间进行聚合，生成segment)+内存化(Bitmap和各种压缩算法)+索引(通过倒排索引，支持Dril-Down某些维度)。
2. 水平扩展能力(Horizontal Scalability)：分布式数据+并行化查询。
3. 实时分析(Realtime Analytics)：过去数据不可变(数据进入系统就不可变)，未来数据通过追加形式增加。

Druid的很多设计思想借鉴于Google的分析武器PowerDril(基于Dremel的可视化分析系统)和Apache Dril(Dremel的开源实现)。

Druid的设计人员已经从MetaMarkets离职，创办了高性能分析服务公司Imply。它们继续推动Druid的发展，并且提供了许多Duid相关的套件，比如Web UI等等。

Druid官方地址：http://druid.io
Druid GitHub地址：https://github.com/apache/incubator-druid
Imply官方地址：http://druid.io

Druid系统特性

特性	描述
列式存储	Druid采用了列式存储数据。这意味着针对特定查询只需要加载指定列即可，对于列式查询提供了巨大的速度提升(OLAP分析多是列式查询)。并且Druid针对每列的特定数据类型进行了优化，支持快速扫描和聚合。
可扩展的分布式系统	Druid部署在数十台到数百台的集群上，就可以提供每秒数百万记录的摄取、存储亿万条记录，并且提供亚秒级到几秒钟的查询延迟。
大规模并行处理(MPP,Massively parallel processing)	Druid能够在整个集群中并行处理查询。
实时&批量数据导入	Druid支持实时数据摄入(摄入后的数据能够立即被查询)和批量数据摄入。
高可用、可扩展性	Druid的宗旨是7*24小时运行，无论任何原因都不需要停止服务(包括配置更改、软件升级)。我们可以很容易的增加或减少机器，后台系统会自动进行平衡。对于down掉的服务，druid路由能够避免这些down掉的服务。
容错性	Druid在摄入数据后，会将这些数据拷贝到深层存储中(比如云存储、HDFS或共享文件)。即使所有服务节点都出现故障，用户数据也可以从深层存储中恢复。副本也可以保证少量服务挂掉后，系统仍可以正常运行。
Bitmap索引	Druid使用Roaring压缩位图(Roaring compressed bitmap)创建索引，这些索引可以跨多个列快速过滤和搜索。
近似算法(Approximate algorithms)	Druid中包含了近似count-distinct、近似排序和近似直方图和分位数的计算算法。这样可以确保在有限的内存中，比精确计算快很多。当然，Druid针对精确性比速度更重的场景，提供了精确count-distict和精确排序。
预计算	Druid支持在数据摄入时进行数据汇总，这样可以节省大量成本并且提供查询性能。

技术架构

Druid将OLAP/分析数据库、时间序列数据库和搜索引擎这三个系统的各自关键特性加入到其核心架构中，它们集成到了数据摄取层、数据存储层和查询层(一个生命周期)。

Druid

数据摄入

Druid支持流式数据和批量数据导入。Druid连接到原始数据源(未经处理的数据)，这些数据源通常是一些消息总线(message bus)。比如Kafka用于流式数据导入，或者分布式文件系统HDFS用于批量数据导入。Druid会在索引阶段(indexing)将原始数据转换segment，segment是一种读取优化格式(Read-Optimize )，能够以更高效方式索引到查询数据。

数据摄入

数据存储

Druid和许多搜索存储引擎一样，采用了列式数据存储。根据列的数据类型(string、number等等)采用不同的压缩算法，并且会根据不同数据类型构建不同类型的索引。比如针对字符串列通过构建位图索引(倒排索引)，来实现快速的搜索和过滤。Druid也可以选择预先数据聚合(上卷)，预先聚合能够节省大量的存储空间(摄入过程会按照时间进行聚合，我们也可以自定义聚合属性)。最后，Druid会按时间划分数据，以便快速面向时间的查询(时间序列数据库使用的方式)。

数据预汇总

查询数据

Duid支持通过JSON(DSL)和SQL形式来查询数据，并且除了标准的SQL操作外，还提供了近似算法组件来提供计数(count)、排序(rank)和分位数(quantile)。

数据查询

应用场景

对于Druid的使用场景可以通过两方面来看：

1. 对于海量数据和实时性要求高的场景，比如广告数据分析、用户行为分析、数据统计分析、运维监控分析等。
2. Druid适合导入数据多，更新数据少的场景。

并不是所有场景都适合使用Druid，比如需要在较低延迟下完成数据的更新、对查询请求延迟没有很高要求、大表之间的join操作等。

更多应用场景，可以查看：http://druid.io/use-cases

Druid系统架构

Druid的目标是提供一个能够在大数据集上高效摄入和快速查询的平台。对于传统数据平台来说，在高效数据摄入和快速查询上需要做一些取舍和权衡。比如RDBMS如果想要快速查询，就需在写入数据时创建索引，从而牺牲了写入性能；反之，如果想要高效写入，就需要放弃一些索引的创建，这样在查询上就会付出相应的代价。而Druid通过其独到架构设计、精巧的数据结构能够同时提供卓越的数据实时摄入和复杂的查询性能。

节点进程	用途
Historical	Historical是用于处理存储和查询历史数据的进程，它会从深层存储中下载段，并且响应这些段的查询
Middlemanager	Middlemanager进程负责将新的数据摄入到集群中，将外部数据源数据转换成Druid所识别的segment
Coordinator	Coordinator进程负责监控Historical进程，它负责将segment分配到指定的Historical服务上，确保所有Historical节点间的段均衡
Overload	Overload进程负责监控Middlemanager进程，它负责将摄取任务分配给Middlemanager并协调segment的发布。它就是数据摄入到Druid的控制器
Broker	Broker进程负责接受Client的查询请求，并将查询转发到Historical和Middlemanager中。Broker会接受所有子查询的结果，并且将数据进行合并返回给Client
Router	Router进程是一个可选的进程，他为Broker、Overload和Coordinator提供了统一API网管服务。如果不启动该进程，也可以直接连接Broker、Overload和Coordinator服务

系统架构

这些线程都可以独立部署，但是一种通用的方式可以为其分为三类服务：

• 数据服务(Data server)：运行Historical和Middlemanager进程。
• 查询服务(Query server)：运行Broker和Router进程。
• Mater服务(Master server)：运行Overlord和Coordinator进程，这里也可以运行Zookeeper服务。

第三方依赖

除了上面这些线程服务外，Druid也需要三类基础设施服务：

• 深度存储服务(Deep storage)：深度存储服务是能够被每个Druid服务都能访问的共享文件系统，一般是分布式对象存储服务，用于存放Druid所有摄入的数据。比如S3、HDFS或网络文件系统。
• 元数据存储(Metadata store)：元数据存储服务主要用于存储Druid中的一些元数据，比如segment的相关信息。一般是传统的RDMS，比如Mysql。
• Zookeeper：用于内部服务发现、协调和leader选举的。

外部依赖

为什么使用Druid

目前OLAP引擎百花齐放(主要原因是没有一款OLAP引擎能够兼容所有业务场景)，Druid又是以什么样的优势能够在众多OLAP引擎下分的一席之地？主要可以归结为以下几点：

• 支持实时数据摄入：可以通过流式计算引擎(比如Storm)或消息系统(比如Kafka)中摄入数据，并且这些数据在被摄入后能够立即提供分析查询(很低的延迟)。
• 交互式OLAP查询：Druid通过列式存储和位图索引，能够提供毫秒级复杂的多维分析与聚合查询。
• 满足面向用户的数据分析产品：OLAP的一个主要应用场景就是作为BI工具后台的查询引擎，这时候就需要考虑OLAP的并发能力，而Druid就能够多租户和高并发(1000+)的需求。
• 高可用：系统无单点，支持滚动升级和在线扩展。
• 高可扩展性：可以扩展到处理亿万事件、PB级别数据。