Druid介绍及入门 |
您所在的位置:网站首页 › druid是什么空调 › Druid介绍及入门 |
1.什么是Druid?
Druid是一个高效的数据查询系统,主要解决的是对于大量的基于时序的数据进行聚合查询。数据可以实时摄入,进入到Druid后立即可查,同时数据是几乎是不可变。通常是基于时序的事实事件,事实发生后进入Druid,外部系统就可以对该事实进行查询。 Druid采用的架构: shared-nothing架构与lambda架构 Druid设计三个原则: 1.快速查询(Fast Query) : 部分数据聚合(Partial Aggregate) + 内存华(In-Memory) + 索引(Index) 2.水平拓展能力(Horizontal Scalability):分布式数据(Distributed data)+并行化查询(Parallelizable Query) 3.实时分析(Realtime Analytics):Immutable Past , Append-Only Future 2.Druid的技术特点数据吞吐量大 支持流式数据摄入和实时 查询灵活且快速 3.Druid基本概念:Druid在数据摄入之前,首先要定义一个数据源(DataSource,类似于数据库中表的概念) Druid是一个分布式数据分析平台,也是一个时序数据库 1.数据格式 数据集合(时间列,维度列,指标列) 数据结构: 基于DataSource与Segment的数据结构,DataSource相当于关系型数据库中的表。 DataSource包含: 时间列(TimeStamp):标识每行数据的时间值 维度列(Dimension):标识数据行的各个类别信息 指标列(Metric):用于聚合和计算的列 Segment结构: DataSource是逻辑结构,而Segment是数据实际存储的物理结构,Druid通过Segment实现对数据的横纵切割操作。 横向切割:通过设置在segmentGranularity参数,Druid将不同时间范围内的数据存储在不同Segment数据块中。 纵向切割:在Segment中面向列进行数据压缩处理 设置合理的Granularity segmentGranularity:segment的组成粒度。 queryGranularity :segment的聚合粒度。 queryGranularity 小于等于 segmentGranularity 若segmentGranularity = day,那么Druid会按照天把不同天的数据存储在不同的Segment中。 若queryGranularity =none,可以查询所有粒度,queryGranularity = hour只能查询>=hour粒度的数据 2.数据摄入 实时数据摄入 批处理数据摄入 3.数据查询 原生查询,采用JSON格式,通过http传送 4.时序数据库1.OpenTSDB 开源的时序数据库,支持数千亿的数据点,并提供精确的数据查询功能 采用java编写,通过基于Hbase的存储实现横向拓展 设计思路:利用Hbase的key存储一些tag信息,将同一小时的数据放在一行存储,提高了查询速度 架构示意图: 集群还依赖三类外部依赖 元数据库(Metastore):存储Druid集群的原数据信息,比如Segment的相关信息,一般用MySql或PostgreSQL 分布式协调服务(Coordination):为Druid集群提供一致性协调服务的组件,通常为Zookeeper 数据文件存储系统(DeepStorage):存放生成的Segment文件,并供历史节点下载。对于单节点集群可以是本地磁盘,而对于分布式集群一般是HDFS或NFS 实时节点数据块的生成示意图: 数据块的流向: Historical Node历史节点 Broker Node节点: Druid提供两类介质作为Cache以供选择 外部Cache,比如Memcached 本地Cache,比如查询节点或历史节点的内存作为cache 高可用性: 通过Nginx来负载均衡查询节点(Broker Node) 协调节点: 协调节点(Coordinator Node)负责历史节点的数据负载均衡,以及通过规则管理数据的生命周期 4.索引服务 2.从节点:Middle Manager 索引服务的工作节点,负责接收主节点的分配的任务,然后启动相关的苦工即独立的JVM来完成具体的任务 这样的架构与Hadoop YARN相似 主节点相当于Yarn的ResourceManager,负责集群资源管理,与任务分配 从节点相当于Yarn的NodeManager,负责管理独立节点的资源并接受任务 Peon(苦工)相当于Yarn的Container,启动在具体节点上负责具体任务的执行 问题:由于老版本的Druid使用pull方式消费kafka数据,使用kafka consumer group来共同消费一个kafka topic的数据,各个节点会负责独立消费一个或多个该topic所包含的Partition数据,并保证同一个Partition不会被多于一个的实时节点消费。每当一个实时节点完成部分数据的消费后,会主动将消费进度(kafka topic offset)提交到Zookeeper集群。 当节点不可用时,该kafka consumer group 会立即在组内对所有可用的节点进行partition重新分配,接着所有节点将会根据记录在zk集群中每一个partition的offset来继续消费未曾消费的数据,从而保证所有数据在任何时候都会被Druid集群至少消费一次。 这样虽然能保证不可用节点未消费的partition会被其余工作的节点消费掉,但是不可用节点上已经消费的数据,尚未被传送到DeepStoreage上且未被历史节点下载的Segment数据却会被集群遗漏,这是基于kafka-eight Firehose消费方式的一种缺陷。 解决方案: 1.让不可用节点恢复重新回到集群成为可用节点,重启后会将之前已经生成但未上传的Segment数据文件统统加载回来,并最终合并传送到DeepStoreage,保证数据完整性 2.使用Tranquility与Indexing Service,对kafka的数据进行精确的消费与备份。 由于Tranquility可以通过push的方式将指定数据推向Druid集群,因此它可以同时对同一个partition制造多个副本。所以当某个数据消费失败时候,系统依然可以准确的选择使用另外一个相同的任务所创建的Segment数据库 |
今日新闻 |
推荐新闻 |
CopyRight 2018-2019 办公设备维修网 版权所有 豫ICP备15022753号-3 |