1-Druid 概览

一、概览

Druid官网

设计原理white paper

API：点击打开链接

MataMarkets在2012年开源Druid，定位为分布式，支持实时分析的数据存储系统，类似于传统的OLPA，但做了一些取舍和强化，像时序数据库，按照时间粒度聚合，加快分析

Druid定位为为实时+历史数据亚秒级查询而设计的开源数据库存储系统（data store），主要用于事件数据的OLPA查询分析，支持实时数据摄取，复杂数据分析，快速数据聚合。现有的部署实践可知其支持万亿级事件和PB级数据量，主要用于用户分析类应用中。Druid功能介于PowerDrill和Dremel之间，它几乎实现了Dremel的所有功能，并且从PowerDrill吸收一些有趣的数据格式。Druid允许以类似Dremel和PowerDrill的方式进行单表查询，同时还增加了一些新特性，如为局部嵌套数据结构提供列式存储格式、为快速过滤做索引、实时摄取和查询、高容错的分布式体系架构等

【主要特性】

• 亚秒级OLAP查询（Sub-second OLAP Queries ）：支持快速的多维过滤和ad-hoc属性分组（groupings），极快的聚合
• 实时流摄取（Real-time Streaming Ingestion ）：支持lock-free方式的同时高维、高数据集的注入与查询，数据摄取后的即时分析
• 高可用性和低资源消耗（Cost Effective、Highly Available）
• 高扩展（Scalable）：现有部署实践统计可支持万亿级事件，PB级数据量，每秒千万次查询

【应用场景】

• 快速交互聚合与OLPA查询
• 实时分析
• 高数据量（(trillions of events, petabytes of data)）
• 无单点故障的数据存储

【现有应用部署的性能】

• 3+ trillion events/month
• 3M+ events/sec through Druid's real-time ingestion
• 100+ PB of raw data
• 50+ trillion events
• Thousands of queries per second for applications used by thousands of users
• Tens of thousands of cores

【对比】

• Druid vs Elasticsearch
• Druid vs Key/Value Stores (HBase/Cassandra)
• Druid vs Redshift
• Druid vs Spark
• Druid vs SQL-on-Hadoop (Hive/Impala/Drill/Spark SQL/Presto)

[1]Druid和spark可以互补，spark基于RDDs 天生适合机器学习（rdd复用，迭代计算）查询达不到亚秒级，将spark用于计算，Druid用于查询

应用实践：https://www.linkedin.com/pulse/combining-druid-spark-interactive-flexible-analytics-scale-butani

[2]Druid与Hadoop生态的SQL查询

Druid主要设计于：

• • • 全时在线服务
    • 实时数据摄取
    • 处理分片类型的ad-hoc查询

Hadoop生态的SQL查询，回避 Map/Reduce，直接查询HDFS，或像Impala and Presto托管HDFS，本地化查询

可从以下几个方面对比

• • • 查询
    • 数据摄取
    • 查询复杂性

（1）查询

Druid 自定义列式存储数据segments，查询segments的过程中，计算结果集，最后在broker 层对结果merge，即计算在各servers内部完成，servers间只传输queries 和results。

Hadoop生态的SQL查询引擎负责对底层存储层和存储格式的查询规划和执行，即使在无查询时也有进程在运行（(eliminating the JVM startup costs from Hadoop MapReduce)）

即便Impala/Presto的守护进程可直接在数据存储层运行，减少网络传输消耗，但也会存在数据层到计算层的延迟消耗

（2）数据摄取

Druid支持实时数据摄取，Hadoop生态数据存储在HDFS或其他，为保证数据存储的正确性必须限制数据摄取的速度

（3）查询复杂性

Druid查询复杂性低于Hadoop生态的SQL

【数据格式】

[1]时间列（必须，按照时间序列聚合）

[2]维度列（数据切片，字符串）

[3]指标列（聚合+计算）

【数据源】

实时数据Kafka etc.

批数据HDFS etc.

【查询】

目前不支持SQL,采用JSON格式的HTTP请求

二、Druid Concepts

官网原文

【The Data 数据源】

数据源基本数据包括时间列、维度列、计算指标列
Timestamp column
Dimension columns
Metric columns

 timestamp             publisher          advertiser  gender  country  click  price
2011-01-01T01:01:35Z  bieberfever.com    google.com  Male    USA      0      0.65
2011-01-01T01:03:63Z  bieberfever.com    google.com  Male    USA      0      0.62
2011-01-01T01:04:51Z  bieberfever.com    google.com  Male    USA      1      0.45
2011-01-01T01:00:00Z  ultratrimfast.com  google.com  Female  UK       0      0.87
2011-01-01T02:00:00Z  ultratrimfast.com  google.com  Female  UK       0      0.99
2011-01-01T02:00:00Z  ultratrimfast.com  google.com  Female  UK       1      1.53


【Roll-up 上卷数据】
Roll-up：按照rollup granularity时间周期做上卷聚合，也即不能查询明细数据
这个时间也是允许的queryGranularity（最小ms）

GROUP BY timestamp, publisher, advertiser, gender, country
  :: impressions = COUNT(1),  clicks = SUM(click),  revenue = SUM(price)

   timestamp             publisher          advertiser  gender country impressions clicks revenue
 2011-01-01T01:00:00Z  ultratrimfast.com  google.com  Male   USA     1800        25     15.70
 2011-01-01T01:00:00Z  bieberfever.com    google.com  Male   USA     2912        42     29.18
 2011-01-01T02:00:00Z  ultratrimfast.com  google.com  Male   UK      1953        17     17.31
 2011-01-01T02:00:00Z  bieberfever.com    google.com  Male   UK      3194        170    34.01

【Sharding the Data 数据分片】
对于上卷后的数据结果可以分片，分成不同的segment
segment定义格式：
dataSource_interval_version_partitionNumber
比如：
Segment sampleData_2011-01-01T01:00:00:00Z_2011-01-01T02:00:00:00Z_v1_0 contains


 2011-01-01T01:00:00Z  ultratrimfast.com  google.com  Male   USA     1800        25     15.70
 2011-01-01T01:00:00Z  bieberfever.com    google.com  Male   USA     2912        42     29.18
Segment sampleData_2011-01-01T02:00:00:00Z_2011-01-01T03:00:00:00Z_v1_0 contains


 2011-01-01T02:00:00Z  ultratrimfast.com  google.com  Male   UK      1953        17     17.31
 2011-01-01T02:00:00Z  bieberfever.com    google.com  Male   UK      3194        170    34.01


Indexing the Data
Druid indexes data on a per-shard (segment) level.
Druid is a column store


【Loading the Data 数据加载】
real-time :尽最大努力的实时，Exactly once semantics目前达不到
batch：exactly once
通用的应用是：一个实时的pipeline注入分析现场，一个batch pipeline用于精确备份数据
  

 【Querying the Data】
 自备http json格式，单表不支持join

【The Druid Cluster】

• Historical Nodes：druid主干，将segment固化到本地 供集群查询时使用。采用了一个无共享架构设计，知道如何去加载segment, 删除segment以及segment查询。
• Broker Nodes：客户端和相关应用从druid集群上查询数据的节点，对查询做负载，聚集和合并查询结果。 broker节点知道每个segment都在哪儿
• Coordinator Nodes：管理druid集群放在historical nodes上的segment。
• Real-time Processing：单点实时节点或者索引服务(indexing service)， 实时处理包括加载数据，创建索引(创建segment)， 将segment迁移到historical nodes。基于此逻辑数据在整个过程中均可查询。

【External Dependencies】

• Zookeeper：集群内部通讯
• Metadata Storage  ：用户存储segment，configuration等的metadata信息，服务创建segments会向metadatastore中写新标记，coordinatenode监控metadatastore来获取有哪些新的数据需要被重新load，或者有哪些旧数据需要去除。查询时不需要metadatastor数据。 mysql、postgresql是常用metadatastor， derby可用于单机测试环境
• Deep Storage deepstorage作为segments一种持久的备份。 服务创建segments后，上传到deepstore。 coordinatenode从deepstorage下载segments。查询时不会用到deepstorage。 常用deepstorage有S3和hdfs。