druid 理解规划
druid
Druid.io（以下简称Druid）是面向海量数据的、用于实时查询与分析的OLAP存储系统。Druid的四大关键特性总结如下：
亚秒级的OLAP查询分析。Druid采用了列式存储、倒排索引、位图索引等关键技术，能够在亚秒级别内完成海量数据的过滤、聚合以及多维分析等操作。
实时流数据分析。区别于传统分析型数据库采用的批量导入数据进行分析的方式，Druid提供了实时流数据分析，采用LSM(Long structure merge)-Tree结构使Druid拥有极高的实时写入性能；同时实现了实时数据在亚秒级内的可视化。
丰富的数据分析功能。针对不同用户群体，Druid提供了友好的可视化界面、类SQL查询语言以及REST 查询接口。
高可用性与高可拓展性。Druid采用分布式、SN(share-nothing)架构，管理类节点可配置HA，工作节点功能单一，不相互依赖，这些特性都使得Druid集群在管理、容错、灾备、扩容等方面变得十分简单。
1 为什么会有Druid
大数据技术从最早的Hadoop项目开始已经有十多年的历史了，而Druid是在2013年年底才开源的，虽然目前还不是Apache顶级项目，但是作为后起之秀，依然吸引了大量用户的目光，社区也非常活跃。那么，为什么会有Druid，而Druid又解决了传统大数据处理框架下的哪些“痛点”问题，下面我们来一一解答。
大数据时代，如何从海量数据中提取有价值的信息，是一个亟待解决的难题。针对这个问题，IT巨头们已经开发了大量的数据存储与分析类产品，比如IBM Netezza、HP Vertica、EMC GreenPlum等，但是他们大多是昂贵的商业付费类产品，业内使用者寥寥。
而受益于近年来高涨的开源精神，业内出现了众多优秀的开源项目，其中最有名的当属Apache Hadoop生态圈。时至今日，Hadoop已经成为了大数据的“标准”解决方案，但是，人们在享受Hadoop便捷数据分析的同时，也必须要忍受Hadoop在设计上的许多“痛点”，下面就罗列三方面的问题：
何时能进行数据查询？对于Hadoop使用的Map/Reduce批处理框架，数据何时能够查询没有性能保证。
随机IO问题。Map/Reduce批处理框架所处理的数据需要存储在HDFS上，而HDFS是一个以集群硬盘作为存储资源池的分布式文件系统，那么在海量数据的处理过程中，必然会引起大量的读写操作，此时随机IO就成为了高并发场景下的性能瓶颈。
数据可视化问题。HDFS是一个优秀的分布式文件系统，但是对于数据分析以及数据的即席查询，HDFS并不是最优的选择。
传统的大数据处理架构Hadoop更倾向于一种“后台批处理的数据仓库系统”，其作为海量历史数据保存、冷数据分析，确实是一个优秀的通用解决方案，但是如何保证高并发环境下海量数据的查询分析性能，以及如何实现海量实时数据的查询分析与可视化，Hadoop确实显得有些无能为力。
2 Druid直面痛点
Druid的母公司MetaMarket在2011年以前也是Hadoop的拥趸者，但是在高并发环境下，Hadoop并不能对数据可用性以及查询性能给出产品级别的保证，使得MetaMarket必须去寻找新的解决方案，当尝试使用了各种关系型数据库以及NoSQL产品后，他们觉得这些已有的工具都不能解决他们的“痛点”，所以决定在2011年开始研发自己的“轮子”Druid，他们将Druid定义为“开源、分布式、面向列式存储的实时分析数据存储系统”，所要解决的“痛点”也是上文中反复提及的“在高并发环境下，保证海量数据查询分析性能，同时又提供海量实时数据的查询、分析与可视化功能”。
在介绍Druid架构之前，我们先结合有关OLAP的基本原理来理解Druid中的一些基本概念。
1 数据
以图3.1为例，结合我们在第一章中介绍的OLAP基本概念，按列的类型上述数据可以分成以下三类：
时间序列(Timestamp)，Druid既是内存数据库，又是时间序列数据库，Druid中所有查询以及索引过程都和时间维度息息相关。Druid底层使用绝对毫秒数保存时间戳，默认使用ISO-8601格式展示时间(形如：yyyy-MM-ddThh:mm:sss.SSSZ，其中“Z”代表零时区，中国所在的东八区可表示为+08:00)。
维度列(Dimensions)，Druid的维度概念和OLAP中一致，一条记录中的字符类型(String)数据可看作是维度列，维度列被用于过滤筛选(filter)、分组(group)数据。如图3.1中page、Username、Gender、City这四列。
度量列(Metrics)，Druid的度量概念也与OLAP中一致，一条记录中的数值(Numeric)类型数据可看作是度量列，度量列被用于聚合(aggregation)和计算(computation)操作。如图3.1中的Characters Added、Characters Removed这两列。
2 上卷
生产环境中，每天会有成百上千亿的原始数据(raw data)进入到Druid中，Druid最小粒度支持毫秒级别的事件，但是在一般使用场景中，我们很少会关注如此细粒度的数据集，同时，对数据按一定规律进行聚合不仅可以节约存储空间，亦可获得更有价值的视图。所以与其他OLAP类产品一样，Druid也支持上卷(roll-up)操作。最常用的上卷操作是对时间维度进行聚合，比如对图3.2中的数据按照小时粒度进行聚合可以得到图3.3，图3.3相对于图3.2来说，显得更加直观，也更有助于分析人员掌握全局态势。不过，上卷操作也会带来信息量的丢失，因为上卷的粒度会变成最小数据可视化粒度，即毫秒级别的原始数据，如果按照分钟粒度进行roll-up，那么入库之后我们能够查看数据的最小粒度即为分钟级别。
3 分片
Druid是时间序列数据库，也存在分片(Sharding)的概念。Druid对原始数据按照时间维度进行分片，每一个分片称为段(Segment)。
Segment是Druid中最基本的数据存储单元，采用列式(columnar)存储某一个时间间隔(interval)内某一个数据源(dataSource)的部分数据所对应的所有维度值、度量值、时间维度以及索引。
Segment数据结构
时间维度（绝对毫秒数）和度量值在底层使用整数(Integer)或者浮点数(floating point)数组进行压缩存储，默认采用LZ4压缩算法（可选LZF、uncompressed）。
维度列使用字典编码、位图索引以及相应压缩算法，包含如下三种数据结构，以图3.1中数据举例：
为什么使用这三种数据结构，它们有哪些优势：
使用字典编码可以减少字符串数据的存储空间，同时表达更加简便、紧凑；
位图索引，结构类似于倒排索引，可以快速地进行按位逻辑操作；
位图索引尺寸=列基数 *数据行数，对于高基数列，我们在第二章中也详细介绍了很多位图索引压缩算法，Druid中实现了Concisebitmap compression以及Roaring bitmap compression，默认使用Concise。
Segment存储结构
Segment逻辑名称形如“datasource_intervalStart_intervalEnd_version_partitionNum”，：
dataSource：数据源；
intervalStart、intervalEnd：时间间隔的起止，使用ISO-8601格式；
version：版本号，默认v1，用于区分多次加载同一数据对应的Segment；
partitionNumber：分区编号，在每个时间间隔内，根据数据量的大小一个Segment内部可能会有多个分区，官方推荐通过控制时间间隔粒度或者partition的个数来保证每个partition的大小在300Mb-700Mb之间，从而获得最优的加载与查询性能。
4 集群节点
Druid集群包含多种节点类型，分别是Historical Node、Coordinator Node、Broker Node、Indexing Service Node（包括Overlord、MiddleManager和Peon）以及Realtime Node（包括Firehose和Plumber）。
Druid将整个集群切分成上述角色，有两个目的：第一，划分Historical Node和Realtime Node，是将历史数据的加载与实时流数据处理切割开来，因为二者都需要占用大量内存与CPU；第二，划分Coordinator Node和Broker Node，将查询需求与数据如何在集群内分布的需求切割开来，确保用户的查询请求不会影响数据在集群内的分布情况，从而不会造成数据“冷热不均”，局部过热，影响查询性能的问题。
图3.5给出了Druid集群内部的实时/批量数据流以及查询请求过程。我们可以看到，实时数据到达Realtime Node，经过Indexing Service，在时间窗口内的数据会停留在Realtime Node内存中，而时间窗口外的数据会组织成Segment存储到Deep Storage中；批量数据经过Indexing Service也会被组织成Segment存储到Deep Storage中，同时Segment的元信息都会被注册到元信息库中，Coordinator Nodes会定期（默认为1分钟）去同步元信息库，感知新生成的Segment，并通知在线的Historical Node去加载Segment，Zookeeper也会更新整个集群内部数据分布拓扑图。
当用户需要查询信息时，会将请求提交给Broker Node，Broker Node会请求Zookeeper获取集群内数据分布拓扑图，从而知晓请求应该发给哪些Historical Node以及Realtime Node，汇总各节点的返回数据并将最终结果返回给用户。
在（三）中，我们将逐一介绍各类节点。
1 Historical Node
Historical Node的职责单一，就是负责加载Druid中非实时窗口内且满足加载规则的所有历史数据的Segment。每一个Historical Node只与Zookeeper保持同步，不与其他类型节点或者其他Historical Node进行通信。
根据上节知晓，Coordinator Nodes会定期（默认为1分钟）去同步元信息库，感知新生成的Segment，将待加载的Segment信息保存在Zookeeper中在线的Historical Nodes的load queue目录下，当Historical Node感知到需要加载新的Segment时，首先会去本地磁盘目录下查找该Segment是否已下载，如果没有，则会从Zookeeper中下载待加载Segment的元信息，此元信息包括Segment存储在何处、如何解压以及如何如理该Segment。Historical Node使用内存文件映射方式将index.zip中的XXXXX.smoosh文件加载到内存中，并在Zookeeper中本节点的served segments目录下声明该Segment已被加载，从而该Segment可以被查询。对于重新上线的Historical Node，在完成启动后，也会扫描本地存储路径，将所有扫描到的Segment加载如内存，使其能够被查询。
2 Broker Node
Broker Node是整个集群查询的入口，作为查询路由角色，Broker Node感知Zookeeper上保存的集群内所有已发布的Segment的元信息，即每个Segment保存在哪些存储节点上，Broker Node为Zookeeper中每个dataSource创建一个timeline，timeline按照时间顺序描述了每个Segment的存放位置。我们知道，每个查询请求都会包含dataSource以及interval信息，Broker Node根据这两项信息去查找timeline中所有满足条件的Segment所对应的存储节点，并将查询请求发往对应的节点。
对于每个节点返回的数据，Broker Node默认使用LRU缓存策略；对于集群中存在多个Broker Node的情况，Druid使用memcached共享缓存。对于Historical Node返回的结果，Broker Node认为是“可信的”，会缓存下来，而Real-Time Node返回的实时窗口内的数据，Broker Node认为是可变的，“不可信的”，故不会缓存。所以对每个查询请求，Broker Node都会先查询本地缓存，如果不存在才会去查找timeline，再向相应节点发送查询请求。
3 Coordinator Node
Coordinator Node主要负责Druid集群中Segment的管理与发布，包括加载新Segment、丢弃不符合规则的Segment、管理Segment副本以及Segment负载均衡等。如果集群中存在多个Coordinator Node，则通过选举算法产生Leader，其他Follower作为备份。
Coordinator会定期（默认一分钟）同步Zookeeper中整个集群的数据拓扑图、元信息库中所有有效的Segment信息以及规则库，从而决定下一步应该做什么。对于有效且未分配的Segment，Coordinator Node首先按照Historical Node的容量进行倒序排序，即最少容量拥有最高优先级，新的Segment会优先分配到高优先级的Historical Node上。由3.3.4.1节可知，Coordinator Node不会直接与Historical Node打交道，而是在Zookeeper中Historical Node对应的load queue目录下创建待加载Segment的临时信息，等待Historical Node去加载该Segment。
Coordinator在每次启动后都会对比Zookeeper中保存的当前数据拓扑图以及元信息库中保存的数据信息，所有在集群中已被加载的、却在元信息库中标记为失效或者不存在的Segment会被Coordinator Node记录在remove list中，其中也包括我们在3.3.3节中所述的同一Segment对应的新旧version，旧version的Segments同样也会被放入到remove list中，最终被逻辑丢弃。
对于离线的Historical Node，Coordinator Node会默认该Historical Node上所有的Segment已失效，从而通知集群内的其他Historical Node去加载该Segment。但是，在生产环境中，我们会遇到机器临时下线，Historical Node在很短时间内恢复服务的情况，那么如此“简单粗暴”的策略势必会加重整个集群内的网络负载。对于这种场景，Coordinator会为集群内所有已丢弃的Segment保存一个生存时间(lifetime)，这个生存时间表示Coordinator Node在该Segment被标记为丢弃后，允许不被重新分配最长等待时间，如果该Historical Node在该时间内重新上线，则Segment会被重新置为有效，如果超过该时间则会按照加载规则重新分配到其他Historical Node上。
考虑一种最极端的情况，如果集群内所有的Coordinator Node都停止服务，整个集群对外依然有效，不过新Segment不会被加载，过期的Segment也不会被丢弃，即整个集群内的数据拓扑会一直保持不变，直到新的Coordinator Node服务上线。
4 Indexing Service
Indexing Service是负责“生产”Segment的高可用、分布式、Master/Slave架构服务。主要由三类组件构成：负责运行索引任务(indexing task)的Peon，负责控制Peon的MiddleManager，负责任务分发给MiddleManager的Overlord；三者的关系可以解释为：Overlord是MiddleManager的Master，而MiddleManager又是Peon的Master。其中，Overlord和MiddleManager可以分布式部署，但是Peon和MiddleManager默认在同一台机器上。图3.5给出了Indexing Service的整体架构。
Overlord
Overlord负责接受任务、协调任务的分配、创建任务锁以及收集、返回任务运行状态给调用者。当集群中有多个Overlord时，则通过选举算法产生Leader，其他Follower作为备份。
Overlord可以运行在local（默认）和remote两种模式下，如果运行在local模式下，则Overlord也负责Peon的创建与运行工作，当运行在remote模式下时，Overlord和MiddleManager各司其职，根据图3.6所示，Overlord接受实时/批量数据流产生的索引任务，将任务信息注册到Zookeeper的/task目录下所有在线的MiddleManager对应的目录中，由MiddleManager去感知产生的新任务，同时每个索引任务的状态又会由Peon定期同步到Zookeeper中/Status目录，供Overlord感知当前所有索引任务的运行状况。
Overlord对外提供可视化界面，通过访问http://:/console.html，我们可以观察到集群内目前正在运行的所有索引任务、可用的Peon以及近期Peon完成的所有成功或者失败的索引任务。
MiddleManager
MiddleManager负责接收Overlord分配的索引任务，同时创建新的进程用于启动Peon来执行索引任务，每一个MiddleManager可以运行多个Peon实例。
在运行MiddleManager实例的机器上，我们可以在${ java.io.tmpdir}目录下观察到以XXX_index_XXX开头的目录，每一个目录都对应一个Peon实例；同时restore.json文件中保存着当前所有运行着的索引任务信息，一方面用于记录任务状态，另一方面如果MiddleManager崩溃，可以利用该文件重启索引任务。
Peon
Peon是Indexing Service的最小工作单元，也是索引任务的具体执行者，所有当前正在运行的Peon任务都可以通过Overlord提供的web可视化界面进行访问。
5 Real-Time Node
在流式处理领域，有两种数据处理模式，一种为Stream Push，另一种为Stream Pull。
Stream Pull
如果Druid以Stream Pull方式自主地从外部数据源拉取数据从而生成Indexing Service Tasks，我们则需要建立Real-Time Node。Real-Time Node主要包含两大“工厂”：一个是连接流式数据源、负责数据接入的Firehose（中文翻译为水管，很形象地描述了该组件的职责）；另一个是负责Segment发布与转移的Plumber（中文翻译为搬运工，同样也十分形象地描述了该组件的职责）。在Druid源代码中，这两个组件都是抽象工厂方法，使用者可以根据自己的需求创建不同类型的Firehose或者Plumber。Firehose和Plumber给我的感觉，更类似于Kafka_0.9.0版本后发布的Kafka Connect框架，Firehose类似于Kafka Connect Source，定义了数据的入口，但并不关心接入数据源的类型；而Plumber类似于Kafka Connect Sink，定义了数据的出口，也不关心最终输出到哪里。
Stream Push
如果采用Stream Push策略，我们需要建立一个“copy service”，负责从数据源中拉取数据并生成Indexing Service Tasks，从而将数据“推入”到Druid中，我们在druid_0.9.1版本之前一直使用的是这种模式，不过这种模式需要外部服务Tranquility，Tranquility组件可以连接多种流式数据源，比如Spark-Streaming、Storm以及Kafka等，所以也产生了Tranquility-Storm、Tranquility-Kafka等外部组件。Tranquility-Kafka的原理与使用将在3.4节中进行详细介绍。
6 外部拓展
Druid集群依赖一些外部组件，与其说依赖，不如说正是由于Druid开放的架构，所以用户可以根据自己的需求，使用不同的外部组件。
Deep Storage
Druid目前支持使用本地磁盘(单机模式)、NFS挂载磁盘、HDFS、Amazon S3等存储方式保存Segments以及索引任务日志。
Zookeeper
Druid使用Zookeeper作为分布式集群内部的通信组件，各类节点通过Curator Framework将实例与服务注册到Zookeeper上，同时将集群内需要共享的信息也存储在Zookeeper目录下，从而简化集群内部自动连接管理、leader选举、分布式锁、path缓存以及分布式队列等复杂逻辑。
Metadata Storage
Druid集群元信息使用MySQL 或者PostgreSQL存储，单机版使用derby。在Druid_0.9.1.1版本中，元信息库druid主要包含十张表，均以“druid_”开头，如图3.7所示。
7 加载数据
对于加载外部数据，Druid支持两种模式：实时流(real-time ingestion)和批量导入(batch ingestion)。
Real-Time Ingestion
实时流过程可以采用Apache Storm、Apache Spark Streaming等流式处理框架产生数据，再经过pipeline工具，比如Apache Kafka、ActiveMQ、RabbitMQ等消息总线类组件，使用Stream Pull 或者Stream Push模式生成Indexing Service Tasks，最终存储在Druid中。
Batch Ingestion
批量导入模式可以采用结构化信息作为数据源，比如JSON、Avro、Parquet格式的文本，Druid内部使用Map/Reduce批处理框架导入数据。
8 高可用性
Druid高可用性可以总结以下几点：
Historical Node
如3.3.4.1节中所述，如果某个Historical Node离线时长超过一定阈值，Coordinator Node会将该节点上已加载的Segments重新分配到其他在线的Historical Nodes上，保证满足加载规则的所有Segments不丢失且可查询。
Coordinator Node
集群可配置多个Coordinator Node实例，工作模式为主从同步，采用选举算法产生Leader，其他Follower作为备份。当Leader宕机时，其他Follower能够迅速failover。
即使当所有Coordinator Node均失效，整个集群对外依然有效，不过新Segments不会被加载，过期的Segments也不会被丢弃，即整个集群内的数据拓扑会一直保持不变，直到新的Coordinator Node服务上线。
Broker Node
Broker Node与Coordinator Node在HA部署方面一致。
Indexing Service
Druid可以为同一个Segment配置多个Indexing Service Tasks副本保证数据完整性。
Real-Time
Real-Time过程的数据完整性主要由接入的实时流语义(semantics)决定。我们在0.9.1.1版本前使用Tranquility-Kafka组件接入实时数据，由于存在时间窗口，即在时间窗口内的数据会被提交给Firehose，时间窗口外的数据则会被丢弃；如果Tranquility-Kafka临时下线，会导致Kafka中数据“过期”从而被丢弃，无法保证数据完整性，同时这种“copy service”的使用模式不仅占用大量CPU与内存，又不满足原子操作，所以在0.9.1.1版本后，我们使用Druid的新特性Kafka Indexing Service，Druid内部使用Kafka高级Consumer API保证exactly-once semantics，尽最大可能保证数据完整性。不过我们在使用中，依然发现有数据丢失问题。
Metadata Storage
如果Metadata Storage失效，Coordinator则无法感知新Segment的生成，整个集群中数据拓扑亦不会改变，不过不会影响老数据的访问。
Zookeeper
如果Zookeeper失效，整个集群的数据拓扑不会改变，由于Broker Node缓存的存在，所以在缓存中的数据依然可以被查询。
9 数据分层
Druid访问控制策略采用数据分层(tier)，有以下两种用途：
将不同的Historical Node划分为不同的group，从而控制集群内不同权限(priority)用户在查询时访问不同group。
通过划分tier，让Historical Node加载不同时间范围的数据。例如tier_1加载2016年Q1数据，tier_2加载2016年Q2数据，tier_3加载2016年Q3数据等；那么根据用户不同的查询需求，将请求发往对应tier的Historical Node，不仅可以控制用户访问请求，同时也可以减少响应请求的Historical Node数量，从而加速查询。