关于druid:OLAP引擎基于Druid组件进行数据统计分析

3次阅读

共计 3049 个字符,预计需要花费 8 分钟才能阅读完成。

一、Druid 概述

1、Druid 简介

Druid 是一款基于分布式架构的 OLAP 引擎,反对数据写入、低延时、高性能的数据分析,具备优良的数据聚合能力与实时查问能力。在大数据分析、实时计算、监控等畛域都有相干的利用场景,是大数据基础架构建设中重要组件。

与当初绝对热门的 Clickhouse 引擎相比,Druid 对高并发的反对绝对较好和稳固,然而 Clickhouse 在工作队列模式中的数据查问能力非常杰出,然而对高并发反对不够敌对,须要做好很多服务监控和预警。大数据组件中 OLAP 引擎的选型有很多,在数据的查问引擎层通常都具备两种或者以上的 OLAP 引擎,抉择适合的组件解决业务需要是优先准则。

2、根本特点

分布式

分布式的 OLAP 数据引擎,数据分布在多个服务节点中,当数据量强烈增长的时候,能够通过减少节点的形式进行程度扩容,数据在多个节点互相备份,如果单个节点呈现故障,则可基于 Zookeeper 调度机制从新构建数据,这是分布式 OLAP 引擎的根本特点,在之前 Clickhouse 系列中也说过这个策略。

聚合查问

次要针对工夫序列数据提供低延时数据写入和疾速聚合查问,时序数据库特点写入即可查问,Druid 在数据写入时就会对数据预聚合,进而缩小原始数据量,节俭存储空间并晋升查问效率; 数据聚合粒度能够基于特定策略,例如分钟、小时、天等。必须要强调 Druid 适宜数据分析场景,并不适宜单条数据主键查问的业务。

列式存储

Druid 面向列的存储形式,并且能够在集群中进行大规模的并行查问,这象征在只须要加载特定查问所须要的列状况下,查问速度能够大幅度晋升。

3、基础架构

统治者节点

即 Overlord-Node,工作的治理节点,过程监督 MiddleManager 过程,并且是数据摄入 Druid 的控制器,负责将提取任务分配给 MiddleManagers 并协调 Segement 公布。

协调节点

即 Coordinator-Node,次要负责数据的治理和在历史节点上的散布,协调节点通知历史节点加载新数据、卸载过期数据、复制数据、和为了负载平衡挪动数据。

两头治理节点

即 MiddleManager-Node,摄入实时数据,已生成 Segment 数据文件,能够了解为 overlord 节点的工作节点。

历史节点

即 Historical-Node,次要负责历史数据存储和查问,接管协调节点数据加载与删除指令,historical 节点是整个集群查问性能的外围所在,因为 historical 会承当绝大部分的 segment 查问。

查问节点

即 Broker-Node,扮演着历史节点和实时节点的查问路由的角色,接管客户端查问申请,并将这些查问转发给 Historicals 和 MiddleManagers,当 Brokers 从这些子查问中收到后果时,它们会合并这些后果并将它们返回给调用者。

数据文件存储库

即 DeepStorage,寄存生成的 Segment 数据文件。

元数据库

即 MetadataStorage,存储 Druid 集群的元数据信息,比方 Segment 的相干信息。

协调中间件

即 Zookeeper,为 Druid 集群提供协调服务,如外部服务的监控,协调和领导者选举。

二、Druid 部署

1、安装包

imply 对 druid 做了集成,并提供从部署到配置到各种可视化工具的残缺的解决方案。

https://static.imply.io/release/imply-2.7.10.tar.gz

解压并重新命名。

[root@hop01 opt]# tar -zxvf imply-2.7.10.tar.gz
[root@hop01 opt]# mv imply-2.7.10 imply2.7

2、Zookeeper 配置

配置 Zookeeper 集群各个节点,逗号分隔。

[root@hop01 _common]# cd /opt/imply2.7/conf/druid/_common
[root@hop01 _common]# vim common.runtime.properties 
druid.zk.service.host=hop01:2181,hop02:2181,hop03:2181

敞开 Zookeeper 内置校验并且不启动。

[root@hop01 supervise]# cd /opt/imply2.7/conf/supervise
[root@hop01 supervise]# vim quickstart.conf

正文掉如下内容:

3、服务启动

顺次启动相干组件:Zookeeper、Hadoop 相干组件,而后启动 imply 服务。

[root@hop01 imply2.7]# /opt/imply2.7/bin/supervise -c /opt/imply2.7/conf/supervise/quickstart.conf

留神虚拟机内存问题,在如下的目录中 Druid 各个组件的 JVM 配置,条件不容许的话适当拉低,并且要拉高 JVM 相干内存参数。

[root@hop01 druid]# cd /opt/imply2.7/conf/druid

启动默认端口:9095,拜访界面如下:

三、根底用法

1、数据源配置

抉择上述 Http 的形式,基于 imply 提供的 JSON 测试文件。

https://static.imply.io/data/wikipedia.json.gz

2、数据在线加载

执行上述:Sample and continue

样本数据加载配置:

数据列的配置:

配置项总体概览:

最初执行数据加载工作即可。

3、本地样本加载

[root@hop01 imply2.7]# bin/post-index-task --file quickstart/wikipedia-index.json

这样读取两份数据脚本。

4、数据立方体

数据加载实现后,查看可视化数据立方体:

数据立方体中提供一些根底的视图剖析,能够在多个维度上拆分数据集并进行数据分析:

5、SQL 查问

能够基于可视化工具对 Druid 进行 SQL 查问,语法与罕用规定简直一样:

SELECT COUNT(*) AS Edits FROM wikipedia;
SELECT * FROM wikipedia WHERE "__time" BETWEEN TIMESTAMP '开始' AND TIMESTAMP '完结';
SELECT page, COUNT(*) AS Edits FROM wikipedia GROUP BY page LIMIT 2;
SELECT * FROM wikipedia ORDER BY __time DESC LIMIT 5;
SELECT * FROM wikipedia LIMIT 3;

6、Segment 文件

文件地位:

/opt/imply2.7/var/druid/segments/wikipedia/

Druid 基于 Segment 实现对数据的切割,数据按工夫的时序散布,将不同工夫范畴内的数据存储在不同的 Segment 数据块中,按工夫范畴查问数据时,能够防止全数据扫描效率能够极大的进步,同时面向列进行数据压缩存储,进步剖析的效率。

四、源代码地址

GitHub·地址
https://github.com/cicadasmile/big-data-parent
GitEE·地址
https://gitee.com/cicadasmile/big-data-parent

往期举荐

☞ OLAP 查问引擎,ClickHouse 集群化治理
☞ HBase 集群环境搭建和利用案例
☞ 搜索引擎框架,ElasticSearch 集群利用
☞ 分布式 NoSQL 零碎,Cassandra 集群治理

正文完
 0