Druid 一次海量数据实时处理的实践

原创 2016年08月22日 15:58:41

前言

之在在项目中使用时序DB的时候,使用的是InfluxDB, 后来随着数据量的增大,InfluxDB无法满足需求(在数据量在百万以下使用InfluxDB真的很好用),在一个偶然的机会下看了Druid,当时还是8.x版本,经过两周的试用测试,性能表现完美,可以做到PB级数据的快速聚合查询

简介

Druid是一个用于大数据实时查询和分析的高容错、高性能开源分布式系统,旨在快速处理大规模的数据,并能够实现快速查询和分析

主要特征

Druid的具有以下主要特征:

  • 为分析而设计——Druid是为OLAP工作流的探索性分析而构建,它支持各种过滤、聚合和查询等类。
  • 快速的交互式查询——Druid的低延迟数据摄取架构允许事件在它们创建后毫秒内可被查询到。
  • 高可用性——Druid的数据在系统更新时依然可用,规模的扩大和缩小都不会造成数据丢失。
  • 可扩展——Druid每天能够处理数十亿事件和TB级数据。

现在Druid已经到了9.x版本,新版本在稳定性已经相当好,而且和Hadoop、kafka等结合的更紧密

节点介绍

Druid是由一组不同角色的节点,每种节点都是一个单独的子系统负责不同的功能,这些节点组成一个系统协同工作,我们来看一下Druid的整体架构见下图
druid-manage

Coordinator Node

监控Historical节点组,以确保数据可用、可复制,并且在一般的“最佳”配置。它们通过从MySQL读取数据段的元数据信息,来决定哪些数据段应该在集群中被加载,使用Zookeeper来确定哪个Historical节点存在,并且创建Zookeeper条目告诉Historical节点加载和删除新数据段。

Historical Node

是对“historical”数据(非实时)进行处理存储和查询的地方。Historical节点响应从Broker节点发来的查询,并将结果返回给broker节点。它们在Zookeeper的管理下提供服务,并使用Zookeeper监视信号加载或删除新数据段。

Broker Node

接收来自外部客户端的查询,并将这些查询转发到Realtime和Historical节点。当Broker节点收到结果,它们将合并这些结果并将它们返回给调用者。由于了解拓扑,Broker节点使用Zookeeper来确定哪些Realtime和Historical节点的存在。

Real-time Node

实时摄取数据,它们负责监听输入数据流并让其在内部的Druid系统立即获取,Realtime节点同样只响应broker节点的查询请求,返回查询结果到broker节点。旧数据会被从Realtime节点转存至Historical节点。

ZooKeeper

为集群服务发现和维持当前的数据拓扑而服务;

MySQL

用来维持系统服务所需的数据段的元数据;

Deep Storage

保存“冷数据”,可以使用HDFS。

实践

在其中一个项目中使用Druid,验证了Druid的能力,约使用了10台机器(其中Druid集群 4 台,HDFS 3 台,web一台, 其它2台),项目结构如下图

image

接收数据端使用Golang,快速的构建了一个分布式,性能还不错的接收服务,其中一个数据接收结点,每天千万级报活,每天上传近亿条数据,聚合查询半月内的数据(约10亿条),秒级可返回结果,完美解决问题。

之于为什么没选择Mysql?因为较大数据量下,本人功力有限,实在玩不转Mysql。综合需求最终总结为: 需要一个对于时序支持较好,可以海量数据快速查询,并且高可用的分布式的列存储系统, 因此最终决定尝试 Druid。

目前在国内使用Druid的企业越来越多,其中包括小米、嘀嘀、去那儿、猎豹、优酷等。

了解更多

官方的使用文档写的相当不错,具体细节请移步至Druid Doc(0.9)

官方的使用文档写的相当不错,具体细节请移步至Druid Doc(0.9)

和其它项目的关系
Druid vs Spark
Druid vs SQL-on-Hadoop
Druid vs. Key/Value Stores
Druid vs Redshift
Druid vs Elasticsearch


本文作者:ganggang



Druid实时大数据分析原理与实践__欧阳辰.pdf 完整版 带书签

  • 2017年11月10日 13:47
  • 48.45MB
  • 下载

Druid (大数据实时统计分析数据存储)

原文见此 : Druid White PaperDruid 是一个为在大数据集之上做实时统计分析而设计的开源数据存储。这个系统集合了一个面向列存储的层,一个分布式、shared-nothing的架构,...
  • bluejoe2000
  • bluejoe2000
  • 2016年12月18日 09:48
  • 5207

Druid大数据实时处理的开源分布式系统——介绍

Abstract Druid 是一个为在大数据集之上做实时统计分析而设计的开源数据存储。这个系统集合了一个面向列存储的层,一个分布式、shared-nothing的架构,和一个高级的索引结构,来达成在...
  • u013573133
  • u013573133
  • 2017年10月22日 13:13
  • 319

时序列数据库武斗大会之 TSDB 名录 Part 1

通过上一章《时序列数据库武斗大会之什么是TSDB》的介绍,相信大家已经知道了什么是时序列数据库,以及对它能干什么,具有什么特点。 那么在这一篇文章中,我们将介绍一下目前都有哪些 TSDB,以及它们各自...
  • wangpeng198688
  • wangpeng198688
  • 2016年03月18日 12:38
  • 925

InfluxDB使用总结与性能优化

如果项目的功能模块中用到对时间特性比较敏感的数据,例如性能监控,趋势走向等需求时,InfluxDB将会是一个不错的选择,虽然其很强很彪悍,但只有在使用的过程中遵循一定规范与原则,才能发挥其良好的特性。...
  • sun7545526
  • sun7545526
  • 2017年07月28日 18:16
  • 3386

数据库连接池优化配置(druid,dbcp,c3p0)

主要描述了数据库连接池参数配置的准则,针对常用的数据库连接池(c3p0,dbcp,druid)给出推荐的配置。...
  • hetaohappy
  • hetaohappy
  • 2016年07月08日 14:58
  • 11462

mysql性能优化(七) 数据库阿里连接池 druid配置详解

Java程序很大一部分要操作数据库,为了提高性能操作数据库的时候,有不得不使用数据库连接池。数据库连接池有很多选择,c3p、dhcp、proxool等,druid作为一名后起之秀,凭借其出色的性能,也...
  • zengdeqing2012
  • zengdeqing2012
  • 2017年03月06日 11:11
  • 3870

分布式时序数据库InfluxDB

InfluxDB 是一个开源分布式时序、事件和指标数据库。使用 Go 语言编写,无需外部依赖。其设计目标是实现分布式和水平伸缩扩展。 它有三大特性: 1. Time Series (时间序...
  • cxzhq2002
  • cxzhq2002
  • 2016年08月05日 11:22
  • 1911

spring对接InfluxDB(一)--创建数据库和数据写入

最近做的项目涉及到InfluxDB,相对来说,这算是个稍微偏门些的了吧,毕竟时序数据库很多朋友都不会接触。这里记录下与spring的对接,以便刚入手的朋友参考。参照官网上数据写入这块,首先是创建数据库...
  • qq_35981283
  • qq_35981283
  • 2017年07月19日 16:28
  • 1214

数据库连接池性能比对(hikari druid c3p0 dbcp jdbc)

背景 对现有的数据库连接池做调研对比,综合性能,可靠性,稳定性,扩展性等因素选出推荐出最优的数据库连接池 。      NOTE: 本文所有测试均是MySQL库 测试结论   ...
  • qq_31125793
  • qq_31125793
  • 2016年04月25日 14:15
  • 27560
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:Druid 一次海量数据实时处理的实践
举报原因:
原因补充:

(最多只允许输入30个字)