druid.io剖析

简介

druid作为现在最有潜力的海量数据实时分析系统，在优酷广告团队中扮演者非常重要的角色

整体架构

现在已经用tranquility+indexing service替换realtime

实时数据经由tranquility被推送到Indexing Service，然后生成索引(Segment)，同时提供来自用户的 查询请求。当索引所在的时间段过去以后，Indexing Service会将索引推送到deep storage。 索引信息会被注册到metadata中。协调节点定时同步metadata，感知新生成的Segment， 并通过Zookeeper去通知历史节点加载索引。

除了实时加载数据，Druid也支持批量导入数据。导入的数据生成索引segment，写入deep storage， 经与上述同样的步骤,通过修改metadata信息将segment加载到历史节点。

Lambda架构思想

Lamda架构用来同时处理离线和实时数据

druid借助lambda思想，很好的解决了实时处理逻辑会丢弃时间窗口以外的数据的问题。

• 实时：通过tranquility拉取数据并导入druid
• 离线：通过druid提供的Hadoop Indexer(实际上是mr任务)获取hdfs数据，生成segment并导入hdfs，并将索引元信息导入mysql。druid定时轮询mysql并获取最新索引数据，最后通过指定负载均衡算法分配给工作节点

依赖

kafka(16c32g480gx8)

TT日志-->storm etl-->kafka

kafka作为storm和druid之间的缓冲

tranquility(4c8g120gx9)

/home/admin/druid-tranquility/default

config目录存储了很多json文件，定义了数据源的schema，也就是druid表结构，所有schema中配置的segmentGranularity都是hour级别, queryGranularity有hour也有minute级别

重要参数

segmentGranularity不等于queryGranularity

• segmentGranularity:索引粒度，也就是一个segment文件包含的数据时间范围
• queryGranularity:查询粒度，也就是最小聚合粒度，代表数据存储的时候，在维度相同的情况下，同一查询粒度范围内的数据会自动被聚合，导致查询的时候只能查到该粒度级别的数据
• intermediatePersistPeriod：定时持久化增量索引的周期，目前大多是5min
• windowPeriod：时间窗口，表示如果数据时间比当前时间老或者比当前时间新，超过该窗口范围之外的全部被丢弃，目前大多是10min，也有5min

推荐配置：intermediatePersistPeriod ≤ windowPeriod < segmentGranularity,queryGranularity<= segmentGranularity

tranquility工作流程：

简而言之，tranquility会做两件事：

• 建立索引任务并发给overlord：tranquility发送的task会被overlord接受，最后会占用middle-manager的一个空闲slot。为防止太多task，tranquility会为同一个segmentGranularity范围之内的task分配同一个id，这个所有发送过去的task都会被合并。还有两个配置项影响task数量，tranquility可以在schema中为每个数据源配置partitions和replicants，一个小时以内请求的task数量= partitions * replicants。目前middle-manager的所有slot数量都可以在overlord UI查看，可以根据剩余slot数量来修改配置中的partitions和replicants参数。建立的task主要目的是明确每个tranquility该往哪个peon发送实时数据，即实时数据在众多peon中负载均衡的策略（稍后讨论handoff阶段）
• 将实时数据发送给peon进程：peon会通过EventReceiverFirehose服务暴露一个http接口，tranquility通过zookeeper获取task的分配信息，明确实时数据该往哪个peon发，并将peon暴露的接口发起post请求，提交实时数据

内部组件

indexing service

indexing service分为三个组件（工作进程），用类似storm的nimbus->supervisor->worker的方式工作

• overlord(4c8g120gx2)：接收tranquility请求的实时索引task，选择slot空闲最多的middle-manager，通过zk将task分配给middle-manager，填满为止。目前overlord两台机器，master-slave结构
• middle-manager(4c8g120gx51)：通过zk获取task，启动本地进程peon执行task
• peon：获取实时数据，执行task，完成索引建立。peon本身还负责索引查询服务

index service接收tranquility请求并处理的整个流程：

peon完成了索引build,merge,handoff的整个生命周期

每个middle-manger有N个slot，对应N个peon，每次分配一个索引task就会创建一个peon进程，这个小时以内peon会占据这个slot，等完成handoff之后才释放

这个小时以内，peon会不断生成增量索引，定时持久化索引，合并索引生成segment，最后handoff segment

handoff流程：

historical(16c32g480gx10)

historical提供索引加载和查询服务

历史节点在从下载segment前，会从本地缓存检查是否存在，如果不存在才从hdfs下载。下载完成之后，会根据zk获取到的压缩信息进行解压处理并加载到内存，这时就能提供查询服务。

可以通过配置给历史节点划分不同的层，然后在coordinator配置规则来加载指定数据源到某个层。这样可以实现冷热数据划分处理，热数据查询多存量小，采用更好的cpu和内存机型配置，冷数据查询少存量大，采用更大的硬盘机型配置

broker(16c32g480gx2)

broker负责查询索引，目前是master-master结构

broker是查询节点，负责接受查询请求，解析查询对象中的时间范围，根据时间范围将实时索引请求（当前小时）路由到peon节点，将历史索引请求（1小时之前）路由到historical节点。接收peon和historical查询返回的数据，在做一次合并，最后返回结果

为了提高查询效率，broker会将查询结果缓存（LRU），目前提供了两种方式：

• heap memory（目前使用）
• kv存储，如memcached

只会缓存历史节点返回的数据，因为peon返回的实时数据经常改变，没有缓存的价值

coordinator(4c8g120gx2)

coordinator会协调历史节点中segment的分配

• rules:每分钟从mysql拉取druid_rules和druid_segments，rules用来告知historical将如何load和drop索引文件，coordinator会读取这些rules，然后修改zk，通知historical加载删除指定的segment，这些都可以在coordinator的UI配置
• load balance:根据zk中每个historical node负责的segment量，做负载均衡
• replication:在coordinator的UI中配置rules时，可以同时配置加载segment的备份数量，这些备份数量会以load balance的形式，分配到多个historical上面。这个备份数量与hdfs的segment备份数量不一样，hdfs那个保证深度存储的数据不会丢失，historical上面备份是为了保证当某个historical挂掉的时候，其他存储了备份segment的节点能接着提供查询服务

外部依赖

zookeeper

druid依赖zk实现集群之间的交互

druid采用shard-nothing架构，每个节点之间不直接和其他打交道，而是采用zk来沟通。这样保证了druid本身的HA特性

peon和historical发布索引

• /druid/announcements：声明所有peon和historical的host
• /druid/segments：记录所有peon和historical的host，以及他们负责的索引

提供indexing service相关数据（overlord页面数据来源）

• /druid/indexer
• leaderLatchPath：overlord选主
• tasks：运行的peon任务
• status：peon任务状态
• announcements：声明middle-manager的capacity

coordinator用来通知historical加载卸载索引

• /druid/loadQueue/_historical_host/_segement_id：记录历史节点所负责的segment

coordinator选主

• coordinator：记录coordinator信息

集群通信

• discovery：集群中所有服务

附属功能

• /druid/listeners：存储lookup数据

deep storage —— hdfs

存储索引文件

metadata storage —— mysql

存储元数据

• druid_segments：索引元数据，数据源、是否可用、大小、维度、指标
• druid_rules：通知historical该如何加载、卸载索引的规则，可以在coordinator配置
• druid_config：存放运行时配置信息
• druid_audit：记录配置、规则的变化
• druid_task(相关的几张表）：overlord用来存放索引task数据，防止overlord挂掉导致task丢失

索引文件

segment就是压缩后的索引文件，命名方式为datasource_intervalStart_intervalEnd_version_partitionNum。如dsp_report_2011-01-01T01:00:00Z_2011-01-01T02:00:00Z_v1_0，代表dsp_report数据源，从2011-01-01那天1点到2点的数据，版本号为v1，分区数为0

深入剖析segment存储结构

• version.bin:4字节，记录segment version
• XXXXX.smoosh:该文件存放多个逻辑意义上的子文件，通过记录offset来管理这些子文件。有的子文件存放了column信息，有的存放了索引元信息。column信息也就是真实存储的数据
• meta.smoosh:上面这些子文件名称以及他们出现的offset都记录在meta.smoosh中

XXXXX.smoosh中存放的column是最重要的，可以分为Timestamp, Dimensions, Metrics三部分。

• Timestamp:用时间戳来表示时间，可以用一系列时间戳表示该segment所有Timestamp列信息，采用LZ4算法压缩
• Metrics:也是数字，存放方法同上，压缩算法同上
• Dimensions:由于Dimensions大多是字符串，采用上面的存放方式无法很好压缩。目前Dimensions拆分成多个结构进行存储。

Dimensions结构：

1. 将字符串映射为整数id的字典
2. 记录该dimension每一行的值，值用上述字典编码
3. 为每个不同dimension的值，定义一个bitmap，存储该值出现的行号，采用roaring压缩算法

上述结构中，1可以有效减少索引文件的大小，2的基础上做排序可以很方便的做groupby合并处理，3是快速完成where条件查询的利器。

内存管理

druid使用了三种不同类型的内存：

• 堆内存：broker用来缓存查询结果、简单计算
• 直接内存：一般用来存储聚合操作中所产生的临时数据
• MMap：历史节点用来加载segment，快速，减少一次系统复制操作。memory_for_segments = total_memory - heap - direct_memory - jvm_overhead，segment可用的内存越小，mmap操作就会导致更多的内存换页操作

参考资料

• http://druid.io/
• http://static.druid.io/docs/druid.pdf
• https://book.douban.com/subject/26954670/
• https://github.com/druid-io/druid
• https://www.slideshare.net/seoeun25/druid-realtime-indexing