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

前言

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

简介

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

主要特征

Druid的具有以下主要特征：

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

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

节点介绍

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

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台)，项目结构如下图

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

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

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

了解更多

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

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

和其它项目的关系Druid vs SparkDruid vs SQL-on-HadoopDruid vs. Key/Value StoresDruid vs RedshiftDruid vs Elasticsearch

本文作者：ganggang