00-

概览

事件流的分析

druid在实时节点和历史节点上提供高并发的快速分析和查询；强大的用户界面；

00-1010新数据库，主要思想来源于OLAP/分析数据库、时间序列数据库和搜索系统这一实时架构；

00-1010最初集成kafka AWS驱动数据湖HDFS AWS S3；工作时，有良好的分层数据流查询架构。

重构思想

在实时数据和历史数据中构建了快速专项分析；解释趋势，探索数据，快速查询和回答问题。

00-1010可以部署在任何NIX环境，有商用硬件和云部署支持；原生云支持：扩展和缩减非常简单。

构建下一代数据栈

druid是一个数据存储，旨在对大量数据集进行高性能、切片和块分析。

解锁新的工作流程

click stream analysis network traffic analysis server index storage应用性能指数digital marketing analysis business intelligence/OLAP

任何地方部署

大规模插入操作，少量更新操作，大部分查询应用聚合和报表查询，还有一个时间列加载数据来自Kafka HDFS亚马逊S3

定义

公共应用场景领域

druid使用面向列的存储，对于特定的查询只需要加载所需的列，大大提高了少量列的查询速度。每列的存储针对特定的数据类型进行了优化，并支持快速扫描和聚合。

应用场景

druid是一个典型的10到数百的集群服务部署，每秒钟有数百万个数据入口，保留了数万条记录，查询延迟只有几秒到几秒。

关键特征

德鲁伊在整个集合中并行处理一个查询。

00-1010:扩展集群，增减服务。这种操作集群会自动平衡，不会停机。如果服务失败，路由将自动绕过该服务，直到可以替换它。Druid被设计成724小时不间断架构，没有任何理由，包括配置修改和软件升级。

00-1010一旦德鲁伊吸收数据，副本将安全地存储在深度存储中，例如HDFS、云存储和共享文件系统。及时，每个服务都挂起，数据可以从深度存储中恢复；对于影响某些服务的某些故障，备份可确保某些查询在系统恢复之前可用。

列存储格式

Druid使用conclusive或Roaring来压缩位图索引，以创建可以跨多列快速过滤和搜索的索引。

可扩展的分布式系统

德鲁伊包含一些算法；近似计数——对位图直方图进行区分、近似排序和近似计算，算法在有限的内存中基本上比精确计算快；这些场景是为了快速计算；德鲁伊还提供了精确的计数和分类。

大规模并行处理

德鲁伊在摄取时可选支持数据聚合，可以提前聚合你的数据，节省大量开支，提升性能。

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

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

ass="pgc-h-arrow-right">Historical

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

MiddleManager

MiddleManager摄取新数据到集群中；它负责度额外的数据源（新的实时的数据）和发布新的druid segments

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

Broker

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

Coordinator

Corrdinator监控Historical处理，负责分配segments到指定的服务，确保存在HIstorical中是自平衡的；

Overlord

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

local or remote模式 默认local

创建任务锁

Router

可选服务；提供了Brokers，Overlords，Coordinator的统一路由网关；

Peon（苦力）

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

总结

Historical是历史数据摄取和查询到节点，Coordinator监控协调Historical节点上的任务，确保segments自平衡；MiddleManager是一个新数据摄取和查询的节点；overlord监控和协调task任务的分配和segments的发布。三种托管计划："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.

druid架构.png

额外依赖

Deep storage：一个被druid可访问的共享的文件存储；比如分布式文件系统HDFS、S3、一个网络挂载的文件系统；用它来存储已经陪摄入的任何数据；Metadata store：一个共享的元数据存储，典型的关系型数据库PostgreSql和Mysql；Zookeeper：一个被用来了额外服务发现、协调、领导选举的；

这个额外依赖设计的idea是为了druid集群在生产环境容易扩张；比如：独立的deep storage 和 metadata store 使集群处理是根本上的容错的；即使一个druid server失败；你可以重启集群从存储在deep storage 和 Metadata store；

Datasources 和 segments

druid data 被存储在其他source中，datasource按照时间进行分区；也可以用其他属性进行分区，每一个时间范围，叫做chunk；一个chunk被分区到一个或多个segments，一个segments是一个单一的文件；里面存储典型的被压缩的原生数据；segments被组织成chunks；就像生活在这个时间线上；datasource > chunk > segment;

一个datasource可能有几个或几千个甚至百万个segments；每一个segment在MiddleManager被创建，在这个时候segment是易变的没有提交的；生成紧凑的支持快速查询segment的步骤：

转换为列模式建立位图索引各种算法压缩数据：

最小存储的字符串列的字典编码

位图索引的位图压缩

所有列的类型感知压缩

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

查询处理

查询首先到达Broker，broker确定被修建的查询需要的数据在哪些segments上；这个segments经常按照时间被修剪，也可以按照你datasource分区时的属性进行修剪；broker确定Historical还是MiddleManager服务于这些segments，然后发出子查询向Historical和MiddleManager，Historical和MiddleManager处理这些查询，并返回结果，broker汇总结果，最终返回给调用者；

broker裁剪是druid限制每一个查询扫描数据的关键方法，但不是唯一途径；broker可以采用更细粒度的过滤器进行裁剪，segments内部索引结构允许druid指出过滤器匹配的数据，在查看任何原生数据之前；一旦druid知道匹配了一个特定查询哪些行，他就会访问查询的指定列；druid可以在行之间进行跳跃，避免读取查询过滤器不匹配的数据。

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

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

额外依赖

Deep storage

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

Metadata storage

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

MySQL

metadata storage被访问的节点(only)

Indexing Service NodesRealtime NodesCoordinator Nodes

只有overlord 和Coordinator能够直接访问Metadata storage

Zookeeper

druid使用zookeeper管理集群状态，使用场景

Coordinator选举segment publishing协议从Historical和Realtimesegment 加载/删除协议在Coordinator和HistoricalOverload选举Indexing Service管理任务

Task

Task Overview

tasks 跑在MiddleManager和总是操作单一的数据源

tasks 通过post请求发送到Overlord节点

几种不同的tasks类型

Segment Creation Tasks

Hadoop Index TaskNative Index TasksKafka Indexing TasksStream Push Tasks (Tranquility)

Compaction Tasks

Segment Merging Tasks

Indexing Service

Indexing service是一个跑关于task索引的、高可用、分布式服务。

Indexing tasks 创建了Druid的segments；Indexing service有一个主从架构。

Indexing service 主要由3个组件构成：a Peon、 a MiddleManager、a Overlord。

a Peon 跑一个单一的task；一个MiddleManager包含多个peons，an Overlord管理多个分布式任务到MiddleManager。

当MiddleManagers和peons总是跑在相同的节点时，Overlords和MiddleManager或许跑在同一个节点或跨越多个节点