【Druid】初识

格格步入
208 阅读7分钟

这是我参与11月更文挑战的第10天，活动详情查看：2021最后一次更文挑战

一、概述

数据分析的基础架构可以分为以下几类:

  • 使用 Hadoop/Spark 进行分析

  • 将 Hadoop/Spark 的结果导入 RDBMS 中提供数据分析

  • 将结果保存到容量更大的 NoSQL 数据库中, 解决数据分析的存储瓶颈, 例如: HBase

  • 将数据源进行流式处理, 对接流式计算框架(如 Storm、Spark、Flink), 结果保存到 RDBMS 或 NoSQL 中

  • 将数据源进行流式处理, 对接分析数据库, 例如: Druid 2021-05-0322-33-10.png

互联网技术的快速增长催生了各类大体量的数据, Hadoop 很大的贡献在于帮助企业将他们那些低价值的事件流数据转化为高价值的聚合数据。

Hadoop 擅长的是存储和获取大规模数据, 它并不提供任何性能上的保证它能多快获取到数据。虽然 Hadoop 是一个高可用的系统, 但在高并发负载下性能会下降;

Hadoop 是一个很好的后端、批量处理和数据仓库系统。在一个需要高并发并且保证查询性能和数据可用性的并需要提供产品级别的保证的需求, Hadoop 并不能满足。

Druid 是 Metamarkets 公司(一家为在线媒体或广告公司提供数据分析服务的公司)推出的一个分布式内存实时分析系统, 用于解决如何在大规模数据集下进行快速的、交互式的查询和分析。

Druid 是一个开源的数据分析引擎工具, 为实时和历史数据的次秒级(多于一秒)查询设计。

主要应用于对数据的 OLAP 查询, Druid 提供低延迟(实时)的数据摄取、灵活的数据探索、快速的数据聚合。现有的 Druid 部署已支持扩展到数万亿时间和 PB 级数据。

（1）与其他 OLAP 技术对比

DruidKylinESSpark SQLClickHouse
数据规模超大超大中等超大中
查询效率高高中低高
并发度高高高低中
灵活性中低高高高
SQL支持中高中高高

SparkSQL / Impala / ClickHouse, 支持海量数据, 灵活性强, 但对响应时间是没有保证的。

当数据量和计算复杂度增加后, 响应时间会变慢, 从秒级到分钟级, 甚至小时级都有可能。

搜索引擎架构的系统(Elasticsearch 等), 在入库时将数据转换为倒排索引。牺牲了灵活性换取很好的性能, 在搜索类查询上能做到亚秒级响应, 但是对于扫描聚合为主的查询, 随着处理数据量的增加, 响应时间也会退化到分钟级。

Druid / Kylin, 则在入库时对数据进行预聚合, 进一步牺牲灵活性换取性能, 以实现对超大数据集的秒级响应。

  • Kylin 利用 Hadoop/HBase 做计算和存储, 使用 SQL 查询, 提供 JDBC/ODBC 驱动与常见 BI 工具集成

  • Druid 有自己独立的分布式集群, 能够实时摄入数据, 有自己的查询接口(与BI兼容性较弱), 通常多用于实时要求高的场景

目前没有一个 OLAP 分析引擎能在数据量、灵活程度、性能(吞吐&并发)做到完美, 需要基于自己的业务场景进行取舍和选型。

（2）应用场景

Druid 擅长的部分：

  • 对于大部分查询场景可以亚秒级响应

  • 事件流实时写入与批量数据导入兼备

  • 数据写入前预聚合节省存储空间, 提升查询效率

  • 水平扩容能力强

  • 社区活跃

是否需要使用 Druid：

  • 处理时间序列事件

  • 快速的聚合以及探索式分析

  • 近实时分析亚秒级响应

  • 存储大量(TB级、PB级)可以预先定义若干维度的事件

  • 无单点问题的数据存储

二、技术特点

Apache Druid 是一个开源的、分布式、实时 OLAP 分析工具。

Druid 的核心设计结合了数据仓库、时间序列数据库和搜索系统的思想, 适用于多种场景的高性能数据实时分析。 Druid 将这三个系统中的每个系统的关键特征合并到其接收层、存储格式、查询层和核心体系结构中。

如图： 2021-05-0518-50-56.png

时间序列数据库主要用于指处理, 带时间标签(按照时间的顺序变化)的数据, 带时间标签的数据也称为时间序列数据。

时间序列数据主要由电力行业、化工行业等各类型实时监测、检查与分析设备所采集、产生的数据, 这些工业数据的典型特点是: 产生频率快(每一个监测点一秒钟内可产生多条数据)、严重依赖于采集时间(每一条数据均要求对应 唯一的时间)、测点多信息量大(常规的实时监测系统均有成千上万的监测点, 监测点每秒钟都产生数据, 每天产生几十GB的数据量)。

主要特点：

  1. 列式存储：Druid 独立的存储和压缩每一列, 只需要读取特定查询所需的内容, 这可以支持快速扫描、排名和聚合

  2. 流式和批量摄取(Ingestion)：支持 Apache Kafka、HDFS、AWS S3、stream processors 等现成连接器

  3. 本地的搜索索引：Druid 为字符串创建倒排索引, 以支持快速搜索和排序

  4. 灵活的 schema：Druid 可以处理变化的 schema 和 嵌套数据

  5. 基于时间优化 partition：Druid 基于时间智能的对数据进行分区,基于时间的查询比传统数据库要快得多

  6. 支持 SQL：Druid 支持本机的 JSON 语言, 还支持基于 HTTP 或者 JDBC 的 SQL

  7. 水平扩展性：Druid 已经用户生产环境中, 每秒接收数百万个事件, 保存多年的数据并提供次秒级查询

  8. 操作简单：只需要增加或删除服务器即可扩展或缩小规模, Druid 会自动平衡, 容错架构通过服务器的故障进行路由

三、体系架构

（1）Druid 进程和服务

Druid 进程和服务：

  • Coordinator 进程管理群集上的数据可用性。从 metastore 中读取 Segment 的元数据, 并决定哪些 Segments 需要被加载到集群中。使用 ZooKeeper 查看已经存在的历史节点, 了解集群各个节点负载情况。创建一个 ZK 的条目告诉历史节点加载、删除、或者移动 Segments

  • Overlord 进程控制数据提取工作负载的分配

  • Historical 进程存储可查询数据。提供对 Segment 的数据查询服务。与 ZooKeeper 通信, 上报节点信息, 告知 ZK 自己拥有哪些 Segments。从 ZooKeeper 中获取执行任务

  • MiddleManager 进程负责提取数据

  • Broker 进程处理来自外部客户端的查询。负责将查询请求分发到历史节点和实时节点, 并聚合这些节点返回的查询结果数据。Broker 节点通过 zookeeper 知道 Segment 都存放在哪些节点上

  • Router 进程是可选的进程, 可以将请求路由到 Broker、Coordinator、Overlords

根据线程的服务类型分为:

  • Master: Coordinator & Overload 进程, 管理数据可用性和数据摄取
  • Data: Historical & MiddleManager, 执行提取工作负载并存储所有可查询数据
  • Query: Broker & Router, 处理来自外部客户端的查询

如图： 2021-05-0518-59-55.png

（2）外部依赖

  • Deep Storage: 深度存储, 例如 HDFS 或者 S3。不是用来存储查询数据的。而是作为数据的备份或者进程间数据交换

  • Metadata Storage: 元数据存储, 可以用 RDBMS

  • ZooKeeper: 服务发现、leader选举、服务协调

avatar
文章
阅读
粉丝