Druid架构讲解

版权声明:本文为博主原创文章,遵循 CC 4.0 by-sa 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://blog.csdn.net/liaynling/article/details/96473842

druid内部节点介绍:

  • Historical: 历史节点的职责主要是对历史的数据进行存储和查询,历史节点从Deep Storage下载Segment,然后响应Broker对于Segment的查询将查询结果返回给Broker节点,它们通过Zookeeper来声明自己存储的节点,同时也通过zookeeper来监听加载或删除Segment的信号。
  • Coordinator:协调节点监测一组历史节点来保证数据的可用和冗余。协调节点读取元数据存储来确定哪些Segment需要load到集群中,通过zk来感知Historical节点的存在,通过在Zookeeper上创建entry来和Historical节点通信来告诉他们加载或者删除Segment。
  • Overload: 统治节点,管理数据写入任务。
  • Broker:节点接收外部客户端的查询,并且将查询路由到历史节点和实时节点。当Broker收到返回的结果的时候,它将结果merge起来然后返回给调用者。Broker通过Zook来感知实时节点和历史节点的存在。
  • Indexing Service: 索引服务是一些worker用来从实时获取数据或者批量插入数据。Realtime:获取实时数据。
  • Tranquility: 是一个以push方式向Druid实时发送数据的应用。它替用户解决了分区、多副本、服务发现、防止数据丢失等多个问题,简化了用户使用Druid的难度。它支持多种数据来源,包括Samza、Spark、Storm、Kafka、Flink等等。
  • Router:它用于把查询路由到不同的Broker,实现Broker层面的查询隔离,例如把热数据查询路由到指定的Broker集合,把不重要的查询路由到剩下的Broker集合。这种隔离在某些场景下非常有用,例如某些不重要的查询耗时过长,会影响其他重要查询的情况。当数据量没达到TB级别,或者对隔离Broker层面的查询没有迫切需求时,不推荐使用Router。

Druid数据结构:

  • Data Source:Druid的基本数据结构,在逻辑上可以理解为关系型数据库中的表。它包含时间、维度和指标三列。
  • Segment:Druid用来存储索引的数据格式,不同的索引按照时间跨度来分区,分区可通过segmentGranularity(划分索引的时间粒度)进行配置。

外部组件:

  • Zookeeper集群
  • 元数据存储实例:Mysql
  • Deep Storage:HDFS

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

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

依赖

tranquility(4c8g120gx9)

/data/tranquility/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

  • 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流程:

handoff

historical

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

 

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

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

broker

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

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

为了提高查询效率,broker会将查询结果缓存(LRU),目前提供了两种方式:

  • heap memory(目前使用)
  • kv存储,如memcached

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

coordinator

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

domain

advertiser

device

city

click

cost

2015-11-25T10:00:00Z youku.com BMW Android Peking 9 0.9
2015-11-25T10:00:00Z youku.com BMW Iphone HongKong 3 0.3
2015-11-25T10:00:00Z tudou.com PANDORA Iphone HongKong 2 0.2
2015-11-25T10:00:00Z tudou.com PANDORA Iphone Peking 1 0.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操作就会导致更多的内存换页操作
展开阅读全文

数据库架构案例分析讲解

03-18

rn 高级数据库架构师研修班(重庆)通知rn软件生产过程中,软件架构是核心位置,但软件自身的核心是领域,即数据库的架构和设计,数据库的架构也将影响软件未来的稳定性。研究数据库建模与设计,数据分析模型的建设,揭示数据库中心建设的策略和模式,是企业数据库建设的关键。为此,国信培训在总结IBM、Microsoft等大型软件开发商的开发经验的基础上,在国内率先开发了本课程,以培训数据库架构设计的高级人才。rn课程目标:通过本课程的学习,掌握数据业务模型构建过程、数据库架构设计、数据库详细设计以及数据库分析挖掘技术,揭示数据库中心建设的策略和模式,提高数据库构架设计思维方式与技巧,解决数据库中心建设问题并利于数据库的维护与管理。rn课程特点:本次培训由资深专家全程组织答疑,为大家解答实际工作中遇到的难题!同时现场将与学员分享成功的经验与案例的讲解分析!rn学习对象:项目经理、软件架构师与设计师、数据库开发工程师、软件开发工程师等。rnrn课程安排:(4天)rn★课程安排rnrnrnrn第一天 数据业务模型建立 领域分析:rn领域语言、业务语言与数据元;领域分析方法;rn数据业务分析:业务模型获取;数据分析规则获取;行业性数据业务模型分析; rn需求分析:用例模型与数据需求的关系;数据质量需求; rn rn案例分析rn可操性的领域分析流程实践;rn可操作性的数据业务分析流程实践;rn可操作性需求分析流程实践rnrnrn第二天 数据库架构设计 数据库体系结构设计:rn数据库体系结构模式;业务分离与数据库分离关系;内存规划;软硬件环境规划;数据库进程、线程与连接规划;rn数据库文件系统设计: rn分布式数据库系统设计:数据库群的水平与竖直切分设计;数据库群故障处理策略;分布式环境中数据库文件系统设计 rnrn案例分析rn软件研发过程数据库系统结构规划;rnGoogle、MySpace、Amazon分布式数据库群的策略;rnrnrn第三天 数据库详细设计 ORM模式与设计:rn将领域模型映射到业务实体设计;业务实体类型决策;对象关系模式rnUI层、中间层集成设计:数据传输对象设计;数据UI层设计;中间层业务对象生命周期的管理;分布状态业务对象管理rn数据持久层设计:数据库源的适应性设计;数据库访问模式决策;数据源模式;ORM工具选择rn数据库表规划设计:单数据表设计;数据表关联设计;访问权限设计;元数据表设计;事务脚本设计 rnrn案例分析rn开源ORM分析;rnXXX财务系统、XXX商用化软件数据库表分析rnrnrn第四天 数据中心规划设计 数据聚合:rn结构化、半结构化与无结构化数据的清洗设计;ETL与ESB;对比各个数据库厂商提供的ETL技术rn数据分析与数据挖掘规划设计:数据分析模型建立;数据分析结果展现;数据挖掘模型建立;数据挖掘结果展现;知识管理与商业智能rn数据中心规划设计:门户展现设计;行业数据中心的分析设计;分析XXX行业数据中心设计方案rnrn案例分析rn某大型门户网站日志数据清洗设计rn软件生命周期数据度量模型分析;rn软件研发过程数据中心方案设计;rnrnrn★ 讲师rn国信高级技术培训中心的资深专家、高级顾问,中科院负责领导国家级软件项目首席架构师、受聘于包括微软在内的国际知名IT厂商的金牌讲师,通晓国际项目环境和管理模式,熟悉中国企业的管理实践。曾主持过中国电信、人民银行、长春一汽等多个大型复杂的软件项目架构设计,培训客户包括微软、惠普、神州数码、平安保险、首都机场等几百家企业,有着非常深厚的理论基础和丰富的实际工作经验。rn★ 时间rn从即日起开始报名,截止时间为4 月 18 日,开班时间为 4月 19 -- 22日,名额有限,欲报从速。rn★ 学费rn收费标准为4000元/人(含教材费、讲义费、午餐费、证书费、讲座费等)。外地学员食宿统一代为安排,费用自理。rn★ 证书和认证rn培训结束后,学员获得国信高级技术培训中心颁发数据库架构设计师合格证书。rn★联系方式rn联系人: 高 征rn电话:010-83539023 传 真: 010-83539592 rn手 机: 13811501355 13933639759 rnEmail: gxgaozheng@126.com msn:gaozheng_1984@hotmail.comrnrn rn 论坛

没有更多推荐了,返回首页