PHP中高级工程师面试重点讲解视频课程
Go快速入门浅显易懂视频教程-基础篇
Go快速入门浅显易懂视频教程-中级篇
DRUID 简介 大数据分析系统概述
原创杂文 / 时间:2015-09-16 12:35:03 / 阅读:1794 / 分享:0

欢迎加druid-io数据库官方474370426


Druid 概述

Druid是为联机分析处理(OLAP)时间序列数据开发的开源分布式系统。2011年开始由Eric Tschetter 和 杨仿今(Fangjin Yang) 研究开发。Druid基于Apache License 2.0协议开源,代码托管在GitHub。根据笔者和创始人的讨论,接下来的很长时间,Druid将一直拓展和改善已有的功能和特性。本文基于Druid官网,希望为读者提供Druid数据存储和集群架构的概述。

数据例子

本文的讨论将用这个来自在线广告公司的简短数据作为例子:


时间戳发行商广告商性别国家点击价格
2011-01-01T01:01:35Zbieberfever.comgoogle.com美国00.65
2011-01-01T01:03:63Zbieberfever.comgoogle.com美国00.62
2011-01-01T01:04:51Zbieberfever.comgoogle.com美国10.45
2011-01-01T01:00:00Zultratrimfast.comgoogle.com英国00.87
2011-01-01T02:00:00Zultratrimfast.comgoogle.com英国00.99
2011-01-01T02:00:00Zultratrimfast.comgoogle.com英国11.53

这组数据是由三个不同的组件组成的。如果你熟悉OLAP术语的话,以下的概念应该比较容易理解:


  1. 时间戳列:Druid把时间戳分开对待,因为所有的查询和分析都以时间戳为中心。本文数据分片段落会对这一点进行更详细的解释。

  2. 维列:这组数据有四个维度:发行商,广告商,性别和国家。每个维度都代表了Druid选择切片整个数据的轴。

  3. 统计列:包括点击和价格。统计列通常是数值,是由聚合运算得出的结果 – 如计数,总和,平均等。

数据上卷

单独事件对分析理解数据不是很有用,但大型事件的数据研究会得出许多有用的见解。运用上卷(roll-up) 的方法,Druid可以很好的根据不同维度的层次实时总结原始数据。下表给出了数据上卷操作的示例:

GROUP BY 时间戳,发行商,广告商,性别,国家
::展示次数= COUNT(),点击= SUM(点击),收入= SUM(价格)

在在线广告数据中,展示次数代表访问量, 收入则来源于所有的投标广告公司。经过第一层次的上卷后,原始数据看起来是这样的:

时间戳出版商广告商性别国家展示次数点击收入
2011-01-01T01:00:00Zultratrimfast.comgoogle.com美国18002515.70
2011-01-01T01:00:00Zbieberfever.comgoogle.com美国29124229.18
2011-01-01T02:00:00Zultratrimfast.comgoogle.com英国19531717.31
2011-01-01T02:00:00Zbieberfever.comgoogle.com英国319417034.01

上卷数据可以显著地降低需要存储的数据量(高达100倍)。当然, 这种减少存储的方式是有代价的。Druid上卷数据的同时,虽然大幅度的减少了存储空间,但是不能再查询单个事件。换句话讲,维度的层次越高,所代表的数据综合度越高,数据量越小,细节也越少。上卷的层次是用户将能够查询数据的最低层次。Druid的数据查询分析的最低粒度是毫秒。


在数据分析处理中,多表操作耗时且烧钱。为此,Druid专注于执行单表操作,目前还不支持多表连接。 在许多生产设置中数据表连接发生在抽取,转换,装载(ETL,Extract Transform Load )层面。因为Druid所期待的数据是行列格式的,所以数据在加载到Druid之前需要规格化。

数据分片

Druid旨在把数据按照时间分片。分片的数据被称为数据段(Segments)。在上述的数据集中,我们可以创建两个数据段,每段包含一个小时的数据。这两个数据段如下表所示:

数据段 sampleData_2011-01-01T01:00:00:00Z_2011-01-01T02:00:00:00Z_v1_0 包含

时间戳出版商广告商性别国家展示次数点击收入
2011-01-01T01:00:00Zultratrimfast.comgoogle.com美国18002515.70
2011-01-01T01:00:00Zbieberfever.comgoogle.com美国29124229.18

数据段 sampleData_2011-01-01T02:00:00:00Z_2011-01-01T03:00:00:00Z_v1_0 包含



时间戳出版商广告商性别国家展示次数点击收入
2011-01-01T02:00:00Zultratrimfast.comgoogle.com英国19531717.31
2011-01-01T02:00:00Zbieberfever.comgoogle.com英国319417034.01

上表中的数据段名称例如 “sampleData_2011-01-01T01:00:00:00Z_2011-01-01T02:00:00:00Z_v1_0 ”包括数据源(sampleData),时间间隔(2011-01-01T01:00:00:00Z_2011-01-01T02:00:00:00Z),版本(v1),和分区号(0)。


数据段是持有某段时间间隔的自包含数据容器。每个段包含列方向的数据,以及这些列的索引。因为Druid查询只可以过滤段,所以只有数据段中的数据源,间隔,版本,以及可选的分区号是能够被识别的。

数据索引

Druid之所以可以高速过滤和查询,部分归结与它的数据存储方式。借用了搜索的基础架构的想法,Druid针对数据创建了数据快照。这些数据快照存储在为了分析查询而高度优化的数据结构中。

Druid是一个列存储,这意味着每个列是单独存储的。只有涉及到的列才会被使用在查询中。Druid优化了只查询涉及到的列这个特性。不同的列也可以采用不同的压缩方式, 或不同的索引。索引数据发生在在数据段的层面上。

数据摄取

Druid的数据摄取有两种形式:实时和批处理。实时摄取不能保证单独事件只输入一次,我们已经把它加在Druid的发展路线图中,希望早日支持这一点。批摄取可以保证单独事件只输入一次, 同时批处理创建的数据段会确保摄取数据的准确性。操作Druid的一种常见方法是用一个实时管道来分析最近事件,并用批处理管道来分析所有精确数据。

Druid集群

Druid集群由多种不同类型的节点构成。每个节点可以非常好的完成一些任务。这些节点归纳如下:

  1. 历史节点(Historical Node): 历史节点是Druid集群的中坚力量。历史节点会下载本地的不变数据段, 然后查询这些数据段。该节点无共享架构,可以加载段,删除段,并提供段的查询操作。

  2. 代理节点(Broker Node):用户和应用程序用代理节点查询以从Druid获取数据。代理节点负责转发查询(到其他节点),并收集和合并结果。代理节点知道所有段的所处区。

  3. 协调节点(Coordinator Node):协调节点管理历史节点中的数据段。协调节点会命令历史节点加载新段,删除旧段以及移动段来保持负载均衡。

  4. 实时节点(Realtime Node):目前可以使用独立的实时节点或使用索引操作来完成Druid的实时处理。这两种操作的实时处理逻辑是通用的。实时处理涉及数据摄取, 数据索引(创建数据段),并移交数据段给历史节点。 数据一旦由实时处理的逻辑摄取便立即可以查询。移交的过程中数据不会有损失,而且在整个过程中数据都是可以被查询的。

Druid集群操依赖于下面几个外部系统:

  1. Zookeeper: Druid依靠Zookeeper为集群内传达信息。

  2. 元数据存储(Metadata Storage): Druid依靠元数据存储来存储数据段和配置的元数据。创建数据段的操作会在元数据存储中写入新条目。协调节点会监听元数据存储并且知道什么时候新的数据需要被摄取或旧数据需要被删除。Druid查询不会涉及元数据存储。 MySQL和PostgreSQL是常用的元数据管理器。

  3. 深存储(Deep Storage): 深存储作为数据段的永久备份。创建段的操作把数据上传到深存储中, 历史节点再从深存储中下载数据。Druid查询不会涉及深存储。 S3和HDFS是常用的深存储器。

各个节点,以及外部系统的关系如下图所示:

Druid_Open-Source_Data_Store,_architecture,_DruidArchitecture3.svg

Druid是高容错的集群,一个节点操作失败不会影响其他节点的运行。要运行高可用性的集群,用户应该在每种节点类型中都至少运行2个节点。


摘自:http://druid.io

感谢:http://nancyl.me/druid-intro/


关于作者
按时间分类