EMR Druid 探索(一)

  1. 云栖社区>
  2. 博客>
  3. 正文

EMR Druid 探索(一)

xy_xind 2018-06-01 17:46:23 浏览3125
展开阅读全文

EMR Druid 探索(一)

什么是 Druid、Druid 使用场景

Druid 是 Metamarkets 公司(一家为在线媒体或广告公司提供数据分析服务的公司)推出的一个分布式内存实时分析系统,用于解决如何在大规模数据集下进行快速的、交互式的查询和分析。现今有一些非常热的 SQL on Hadoop 解决方案或者基于传统数据库技术的 MPP 方案,前者比如 Hive、Impala、Spark SQL、Presto 等,后者比如 Greenplum。这些方案的查询响应速度往往与数据集的规模成正比,查询时延从秒级到天级不等。这对于想要快速验证想法的业务人员来说是个极大的问题。与这些系统不同,Druid 通过预先聚合一些维度来换取速度,查询时延可以控制在秒亚秒级到秒级。这非常适合那些业务数据维度比较固定,又对查询时延要求非常高的场景,比如

  • 实时指标监控
  • 推荐模型
  • 广告平台
  • 搜索模型

这些场景的特点都是拥有大量的数据,且对数据查询的时延要求非常高。例如在广告程序化交易中,广告平台的出价策略来源于广告流量数据的分析,整个过程要求实时,因为市场变动很快,根据第一天的流量计算第二天的出价是没有意义的,这里的联动需要做到秒级。实时指标监控类似,在一些重要的场合,系统问题需要在出现的一刻被检测到并被反馈随后被解决。在推荐系统或者用户行为分析系统中,模型需要在多个维度分析数据提炼用户行为,并及时更新到线上系统。

Druid 特点

  • 亚秒级 OLAP 查询,包括多维过滤、ad-hoc 的属性分组、快速聚合数据等等
  • 实时的数据消费,真正做到数据摄入实时、查询结果实时
  • 高效的多租户能力,最高可以做到几千用户同时在线查询
  • 扩展性强,支持 PB 级数据、千亿级事件快速处理,支持每秒数千查询并发
  • 极高的高可用保障,支持滚动升级

其中最为亮眼的是第一条与第二条。开源界能够同时做到两者的系统或解决方案并不多见,主要竞争者有 LinkedIn 公司的 Pinot,eBay 公司的 Kylin,以及 Elasticsearch 等。我们下文有专门的对比。

Druid 架构

下图是 Druid 工作层(数据索引以及查询)包含的组件。其中,

  • Realtime 组件负责数据的实时摄入
  • Broker 阶段负责查询任务的分发以及查询结果的汇总,并将结果返回给用户
  • Historical 节点负责索引后的历史数据的存储。数据存储在 deep storage。deep storage 可以是本地,也可以是 HDFS 等分布式文件系统
  • Indexing service 包含两个组件(图中未画出)

    • Overlord 组件负责索引任务的管理、分发
    • MiddleManager 负责索引任务的具体执行

working-laryer

下图是 Druid segments(Druid 索引文件)管理层所涉及的组件。其中

  • Zookeeper 负责存储集群的状态以及作为服务发现组件,例如集群的拓扑信息,overlord leader 的选举,indexing task 的管理等等
  • Coordinator 负责 segments 的管理,如 segments 下载、删除以及如何在 historical 之间做均衡等等。
  • Metadata storage 负责存储 segments 的元信息,以及管理集群各种各样的持久化或临时性数据,比如配置信息、审计信息等等

manage-laryer

Druid 与 Pinot、Kylin 对比

三者均是基于预计算换取查询时延。Druid 与 Pinot 是比较类似的,Kylin 是另外一种。Kylin 实际上是一个预聚合生成 cube 的一个系统。它的数据导入并不是实时的,需要设置定时任务做聚合计算,生成 cube,因此它本质上是一个 cube 生成与管理系统。cube 是一个数据的多维立方体,当维度增多之后 cube 体积会迅速增大。但是在不同的维度间切换视角、或是执行上卷、下钻等操作会非常省时。

Druid 与 Pinot 都是 lambda 架构,既可以通过批处理历史数据,又可以通过流实时处理数据。下表列出了两者在主要维度上的对比

Pinot Druid
发起者 LinkedIn MetaMarkets
发布年份 2015 2011
架构 lambda 架构 lambda 架构
存储方式 列存 列存
索引类型 inverted/start tree/bitmap inverted
消费数据格式 avro/csv/json(historical), Kafka(realtime) json/csv/tsv/regex(any custom data format), stream(rest), Kafka
组件管理 Zookeeper+Helix Zookeeper
文档支持 一般
SQL 支持 PQL Druid SQL
JDBC 不支持,但其java api 类似于jdbc 通过 avatica jdbc driver 支持

Druid 与 Elasticsearch 对比

Elasticsearch (ES) 是一个基于 Lucenen 的搜索引擎系统,原先主要应用于搜索领域,后来加入了聚合等特性,支持了更多的查询类型,从而变成了一个 NoSQL 的数据库。它是从搜索引擎而来,因此具有一些搜索引擎所具有的特点,同时由于其基于搜索的设计,也导致了一些场景下的短板。

ES 的优点主要在于

  • 可以处理海量的数据同时查询时延得到保证 这一点与搜索引擎是类似的
  • 支持全文检索 这一点对于文档型数据非常重要,对于这一类型数据,ES 可以说非常适合
  • 支持聚合查询 通过 ES 提供的聚合接口,用户可以实现多维度的聚合查询
  • 支持明细查询 ES 存储了原始文档的正排信息,查询后可以将原始文档原文输出
  • 支持join join 是很多场景不可避免的,也是很多实时分析系统(如 Druid、Kylin)不具备的,因此支持 join 就是一个很大的优势
  • 良好的扩展性和高可用 不同于 Hadoop 生态系统的很多 master-slave 架构,ES 各节点是全同的,只是在运行时会有一个节点被选举出来做 leader 做一些轻量化的工作。当一个 leader 挂掉后,另外一个就会选举出来
  • 提供了ELK一体化工具 这是一个日志分析场景的一套工具,Logstash 负责数据接入,ES 负责数据分析,Kibana 负责数据展现
  • Schema free 数据可以事先不定义 schema 导入 ES,ES 会自动生成 schema,本质上仍然属于 “schema on write”。

ES 的缺点有

  • 数据导入非实时 ES 不支持实时索引,但是 ES 支持近实时索引作为弥补。
  • 数据膨胀 相对于原始文档,默认配置下 ES 索引后数据是膨胀的,ES 存储了文档的倒排信息和正排信息,有时还要存储文档本身。
  • 不支持SQL ES 官方目前没有支持,其查询语言是一套自定义的 DSL。
  • Range 查询性能较差 这是由其技术基础决定的

Druid 与 ES 是两种技术上完全不同的方案。前者基于数据的预计算换取查询时延,后者则是完全基于倒排索引。Druid 相对于 ES 的优势在于

  1. 实时数据索引与查询
  2. 更适合传统数仓领域的结构化数据,相比 ES 更适合半结构化数据
  3. 更加方便的数据源接入,包括 Kafka、Flink 等接入数据,与 Hadoop 生态融合更好
  4. Range 查询性能更佳

由于两者都具有鲜明的特点,因此针对具体场景选择哪种方案就不存在什么选择困难。对于半结构化的日志分析,ELK 可能更好一些。对于结构化的数据又有实时性的要求的话,Druid 是更好的选择。

Druid 性能

Druid 具有高超的性能。主要体现在:一,很高的水平扩展能力,能够处理极大的数据集;二,预聚合带来的自然加速优势;三,基于内存的计算保证了计算的速度;四,从 deep storage 到磁盘再到内存形成了一个多级缓存架构,热数据能够快速被处理。

下表列出了 Metamarkets 公司 Druid 集群的一些性能指标

  • 每天处理 1000 亿的事件,100TB 的流式数据
  • 超过 100 PB 的原始数据
  • 超过 50000 亿的总数据
  • 上千用户的每秒查询峰值
  • 数万个处理器核

网友评论

登录后评论
0/500
评论
xy_xind
+ 关注