文档章节

druid.io剖析

loda0128
 loda0128
发布于 2017/05/15 22:45
字数 2600
阅读 835
收藏 15

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架构用来同时处理离线和实时数据

lambda架构

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

简而言之,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请求并处理的整个流程:

indexing service

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

peon-flow

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

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

handoff流程:

handoff

historical(16c32g480gx10)

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

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三部分。

timestampdomainadvertiserdevicecityclickcost
2015-11-25T10:00:00Zyouku.comBMWAndroidPeking90.9
2015-11-25T10:00:00Zyouku.comBMWIphoneHongKong30.3
2015-11-25T10:00:00Ztudou.comPANDORAIphoneHongKong20.2
2015-11-25T10:00:00Ztudou.comPANDORAIphonePeking10.1
  • 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操作就会导致更多的内存换页操作

参考资料

© 著作权归作者所有

共有 人打赏支持
上一篇: kafka原理解析
下一篇: storm原理剖析
loda0128
粉丝 92
博文 94
码字总数 119257
作品 0
朝阳
程序员
私信 提问
PHP 连接 Druid.IO 驱动服务的扩展 - PHP-Druid

这是一个为 PHP 连接查询 Druid.IO 提供的客户端驱动服务的 PHP 扩展。 安装 Make Install PHP-Druid $ /path/to/phpize$ ./configure --with-php-config=/path/to/php-config$ make && mak......

Neeke
2016/12/28
0
1
druid.io的segmentGranularity参数修改后写入数据被忽略

通过java api写数据到druid.io,配置文件中segmentGranularity参数为DAY时,可以正常写入,但是如果segmentGranularity配为HOUR,就不能写入,日志有以下提示: 相关配置: 数据被过滤的配置...

jakey766
2016/11/15
585
1
druid.io 使用mysql存储metadata overlord启动出错

这是druid.io批量导入数据时出现的问题,当启动overlord节点时,运行的命令如下: java -Xmx2g -Duser.timezone=UTC -Dfile.encoding=UTF-8 -classpath config/common:config/overlord:lib/*...

一只小江
2016/03/14
803
0
druid.io 使用hdfs作为deep storage 出现scheme: hdfs错误

使用hdfs作为druid.io的deep storage,但是在提交任务时却出现了错误。 错误如下: 2016-03-25T01:57:15,917 INFO [task-runner-0] io.druid.storage.hdfs.HdfsDataSegmentPusher - Copying......

一只小江
2016/03/29
171
0
Apache Druid 单机环境搭建

下载 http://druid.io/downloads.html下载druid-0.10.1-bin.tar.gz. ,mysql-metadata-storage-0.10.1.tar.gz 解压 修改日志配置 /druid/druid-0.10.0/conf-quickstart/druid/_common/log4j2......

翱翔fly
2017/10/19
0
0

没有更多内容

加载失败,请刷新页面

加载更多

80后阿里P10,“关老板”如何带着MaxCompute一路升级?

我是个幸运的人。虽然幸运不能被复制,但是眼光和努力可以。 关涛/关老板,80后的阿里P10,阿里巴巴通用计算平台负责人,阿里巴巴计算平台研究员。12年职场人生,微软和阿里的选择。 关涛的花...

阿里云官方博客
15分钟前
0
0
开源软件和开源模式面临的生存危机

开源模式可能正面临一场危机。越来越多的开源软件和平台被大型云计算服务商融入自家的云服务体系,并以此获利颇丰,但并不支付费用,也没有对开源社区做出相应的回馈。而实际上,大部分开源软...

Linux就该这么学
16分钟前
0
0
统一服务消息返回错误:{"errcode":40165,"errmsg":"invalid weapp pagepath hint: [bsAWua0201ge30]"}

{"errcode":40165,"errmsg":"invalid weapp pagepath hint: [bsAWua0201ge30]"} 原因:pagepath参数为所需跳转到小程序的具体页面路径,支持带参数,(示例index?foo=bar), 以前配置的是:m...

tianma3798
18分钟前
0
0
ElasticSearch实战:Linux日志对接Kibana

本文由云+社区发表 ElasticSearch是一个基于Lucene的搜索服务器。它提供了一个分布式多用户能力的全文搜索引擎,基于RESTFul web接口。ElasticSearch是用Java开发的,并作为Apache许可条款下...

腾讯云加社区
20分钟前
0
0
FeignClient超时配置

1前沿 使用Feign调用接口分两层,ribbon的调用和hystrix的调用,所以ribbon的超时时间和Hystrix的超时时间的结合就是Feign的超时时间 1.1ribbon配置 ribbon: OkToRetryOnAllOperations: f...

lovelan1314
23分钟前
0
0

没有更多内容

加载失败,请刷新页面

加载更多

返回顶部
顶部