brokerdruid查询_Druid高性能实时数据分析数据库

概览

事件流的分析

druid 提供了快速的分析查询一个高并发&＃xff0c;在实时节点和历史节点上&＃xff1b;强大的用户交互界面&＃xff1b;

重构思想

新型数据库&＃xff0c;主要思想来自 OLAP/analytic databases,timerseries database,search systems在这个实时架构中&＃xff1b;

构建下一代数据栈

原生集成了kafka AWS KinesiS 数据湖 HDFS AWS S3&＃xff1b;工作时&＃xff0c;有良好的层次的数据流查询架构。

解锁新的工作流程

构建了一个快速的特别分析在实时数据和历史数据两个方面&＃xff1b;解释趋势&＃xff0c;探索数据&＃xff0c;快速查询回答问题。

任何地方部署

在任何×NIX环境中部署&＃xff0c;商业硬件和云上部署都支持&＃xff1b;原生云支持&＃xff1a;扩容和减少非常简单。

定义

druid是一个为高性能、在大量数据集上分片和分块分析 而设计的数据存储

公共应用场景领域

• 点击流分析
• 网络流量分析
• 服务器指标存储
• 应用性能指标
• 数字营销分析
• 商业智能/OLAP

应用场景

• 大比例的插入操作&＃xff0c;少量的更新操作
• 大部分查询应用聚合和报告查询使用group by、查询或者扫描操作
• 数据有一个时间列
• load data from kafka HDFS Amazon S3

关键特征

列存储格式

druid使用面向列的存储&＃xff0c;对一个特定的查询只需要加载需要的列&＃xff0c;面对少量列的查询有了一个速度的大幅提升&＃xff0c;每一个列的存储针对特定的数据类型做了存储优化&＃xff0c;支持快速扫描和聚合。

可扩展的分布式系统

druid是一个典型的十到数百台的集群服务部署&＃xff0c;每秒百万级的数据摄取&＃xff0c;保留数万条记录&＃xff0c;亚秒级到几秒钟的查询延迟。

大规模并行处理

druid一个查询并行处理在整个集中。

自健康检查 自平衡 简单操作

扩大集群&＃xff0c;增加、减少服务&＃xff0c;这样的操作集群会自动平衡&＃xff0c;无需停机&＃xff0c;如果一个服务失败&＃xff0c;路由会自动绕个这个服务&＃xff0c;直到找到可以替换的服务。druid设计成一个无需任何原因7×24小时不停机的运行的架构&＃xff0c;包括配置修改&＃xff0c;软件升级.

原生云的 默认容错不会丢失数据的架构

一旦druid摄取了数据&＃xff0c;一个copy会被安全的存储到deep storage&＃xff0c;例如HDFS、云存储、一个共享的文件系统中&＃xff1b;及时每一个服务挂了&＃xff0c;数据可以从deep storage恢复&＃xff1b;对于一些失败&＃xff0c;影响了一些服务&＃xff0c;备份确保一些查询是可用的&＃xff0c;直到系统被恢复。

用于快速过滤的索引服务

Druid使用CONCISE或 Roaring压缩位图索引来创建索引&＃xff0c;这些索引可以跨多个列进行快速过滤和搜索。

近似算法

druid包含一些算法&＃xff1b;近似count-distinct、近似排序、位图直方图的近似计算&＃xff0c;算法在有限内存中基本上是快于准确计算&＃xff1b;这些场景是为了快速计算&＃xff1b;druid也提供了准确的count-distinct和排序

摄取时自汇总

druid可选的支持摄取时数据汇总&＃xff0c;汇总可以预先聚合你的数据&＃xff0c;可以大量开销的节和性能提升。

架构

Historical

Historical是一个处理存储和历史数据查询查询到工作站&＃xff0c;Historical处理从deep storage加载过来的segments&＃xff0c;对这些segments从broker发出的历史数据的查询做出回应&＃xff1b;他不接受写&＃xff1b;

MiddleManager

MiddleManager摄取新数据到集群中&＃xff1b;它负责度额外的数据源&＃xff08;新的实时的数据&＃xff09;和发布新的druid segments

MiddleManager是一个执行提交任务的工作节点&＃xff1b;提交任务到peon上在一个独立的JVMs&＃xff0c;因为任务的资源和日志的隔离&＃xff0c;每一个Peon使用了隔离的JVMS&＃xff0c;每一个Peon同时每次只能运行一个task&＃xff0c;一个MiddleManager有多个peon&＃xff1b;

Broker

处理来自客户端的查询&＃xff0c;解析将查询重定向到Historical和MiddleManager&＃xff0c;Broker接收到数据从这个子查询中&＃xff0c;合并这些结果然后返回给查询者&＃xff1b;

Coordinator

Corrdinator监控Historical处理&＃xff0c;负责分配segments到指定的服务&＃xff0c;确保存在HIstorical中是自平衡的&＃xff1b;

Overlord

监控MiddleManager处理和控制数据加载进druid集群&＃xff1b;对分配给MiddleManager的摄取任务和协调segments的发布负责&＃xff1b;

local or remote模式 默认local
创建任务锁

Router

可选服务&＃xff1b;提供了Brokers&＃xff0c;Overlords&＃xff0c;Coordinator的统一路由网关&＃xff1b;

Peon&＃xff08;苦力&＃xff09;

Peons运行一个单独的任务在一个单独的JVM,MiddleManager负责创建执行任务的peon&＃xff1b;peons自己运行是非常稀少的。

总结

1. Historical是历史数据摄取和查询到节点&＃xff0c;Coordinator监控协调Historical节点上的任务&＃xff0c;确保segments自平衡&＃xff1b;
2. MiddleManager是一个新数据摄取和查询的节点&＃xff1b;overlord监控和协调task任务的分配和segments的发布。
3. 三种托管计划&＃xff1a; "Data" servers run Historical and MiddleManager processes.
   "Query" servers run Broker and (optionally) Router processes.
   "Master" servers run Coordinator and Overlord processes. They may run ZooKeeper as well.

额外依赖

• Deep storage&＃xff1a;一个被druid可访问的共享的文件存储&＃xff1b;比如分布式文件系统HDFS、S3、一个网络挂在的文件系统&＃xff1b;用它来存储已经陪摄入的任何数据&＃xff1b;
• Metadata store&＃xff1a;一个共享的元数据存储&＃xff0c;典型的关系型数据库PostgreSql和Mysql&＃xff1b;
• Zookeeper&＃xff1a;一个被用来了额外服务发现、协调、领导选举的&＃xff1b; 这个额外依赖设计的idea是为了druid集群在生产环境容易扩张&＃xff1b;比如&＃xff1a;独立的deep storage 和 metadata store 使集群处理是根本上的容错的&＃xff1b;即使一个druid server失败&＃xff1b;你可以重启集群从存储在deep storage 和 Metadata store&＃xff1b;

Datasources 和 segments

druid data 被存储在打他source中&＃xff0c;datasource按照时间进行分区&＃xff1b;也可以用其他属性进行分区&＃xff0c;每一个时间范围&＃xff0c;叫做chunk&＃xff1b;一个chunk被分区到一个或多个segments&＃xff0c;一个segments是一个单一的文件&＃xff1b;里面存储典型的被压缩的原生数据&＃xff1b;segments被组织成chunks&＃xff1b;就像生活在这个时间线上&＃xff1b;datasource > chunk > segment;
一个datasource可能有几个或几千个甚至百万个segments&＃xff1b;每一个segment在MiddleManager被创建&＃xff0c;在这个时候segment是易变的没有提交的&＃xff1b;生成紧凑的支持快速查询segment的步骤&＃xff1a; 1. 转换为列模式 2. 建立位图索引 3. 各种算法压缩数据&＃xff1a;

最小存储的字符串列的字典编码
位图索引的位图压缩
所有列的类型感知压缩

定期提交和发布segments&＃xff1b;在这一时刻&＃xff0c;他们被写入深度存储&＃xff0c;变成不可变的&＃xff0c;从MiddleManager移除到HIstorical流程&＃xff1b;一个关于这个segment的条目被写入到Metadata store&＃xff1b;这个条目关于segment是自描述的&＃xff0c;包含segment的列信息&＃xff0c;大小&＃xff0c;deep storage的位置&＃xff1b;这些条目是告诉Coordinator集群中有哪些数据是可以访问的。

查询处理

查询首先到达Broker&＃xff0c;broker确定被修建的查询需要的数据在哪些segments上&＃xff1b;这个segments经常按照时间被修剪&＃xff0c;也可以按照你datasource分区时的属性进行修剪&＃xff1b;broker确定Historical还是MiddleManager服务于这些segments&＃xff0c;然后发出子查询向Historical和MiddleManager&＃xff0c;Historical和MiddleManager处理这些查询&＃xff0c;并返回结果&＃xff0c;broker汇总结果&＃xff0c;最终返回给调用者&＃xff1b;
broker裁剪是druid限制每一个查询扫描数据的关键方法&＃xff0c;但不是唯一途径&＃xff1b;broker可以采用更细粒度的过滤器进行裁剪&＃xff0c;segments内部索引结构允许druid指出过滤器匹配的数据&＃xff0c;在查看任何原生数据之前&＃xff1b;一旦druid知道匹配了一个特定查询哪些行&＃xff0c;他就会访问查询的指定列&＃xff1b;druid可以在行之间进行跳跃&＃xff0c;避免读取查询过滤器不匹配的数据。

druid最大化查询性能的三种技术

• 为每一个查询修剪访问的segments
• 在每一个segment中&＃xff0c;使用索引确定要访问的列
• 在每一个segment中&＃xff0c;只读取特定查询的特定行和列

额外依赖

Deep storage

Druid使用deep stroage只作为一个数据的备份和一种druid内部处理转化数据的方式。为了相应查询&＃xff0c;Historical预先拉取segment从你的本地硬盘&＃xff0c;而不是deep stroage&＃xff1b;这意味这druid在一个查询期间从不需要访问deep stroage&＃xff0c;最少的降低延迟&＃xff1b;这也意味着为了在deep storage和Historical处理你将要加载的数据&＃xff0c;你必须有足够硬盘空间。

Metadata storage

存储各种各样的系统元数据

MySQL

metadata storage被访问的节点(only)

• Indexing Service Nodes
• Realtime Nodes
• Coordinator Nodes 只有overlord 和Coordinator能够直接访问Metadata storage

Zookeeper

druid使用zookeeper管理集群状态&＃xff0c;使用场景 - Coordinator选举 - segment publishing协议从Historical和Realtime - segment 加载/删除协议在Coordinator和Historical - Overload选举 - Indexing Service管理任务

Task

Task Overview

tasks 跑在MiddleManager和总是操作单一的数据源 tasks 通过post请求发送到Overlord节点
几种不同的tasks类型

Segment Creation Tasks

• Hadoop Index Task
• Native Index Tasks
• Kafka Indexing Tasks
• Stream Push Tasks (Tranquility)

Compaction Tasks

Segment Merging Tasks

Indexing Service

Indexing service是一个跑关于task索引的、高可用、分布式服务。
Indexing tasks 创建了Druid的segments&＃xff1b;Indexing service有一个主从架构。
Indexing service 主要由3个组件构成&＃xff1a;a Peon、 a MiddleManager、a Overlord。
a Peon 跑一个单一的task&＃xff1b;一个MiddleManager包含多个peons&＃xff0c;an Overlord管理多个分布式任务到MiddleManager。
当MiddleManagers和peons总是跑在相同的节点时&＃xff0c;Overlords和MiddleManager或许跑在同一个节点或跨越多个节点