开源分布式系统Druid简谈

介绍

Druid是一个拥有大数据实时查询和分析的高容错、高性能开源分布式系统，旨在快速处理大规模的数据，并能够实现快速查询和分析。尤其是当发生代码部署、机器故障以及其他产品系统遇到宕机等情况时，Druid仍然能够保持100%正常运行。创建Druid的最初意图主要是为了解决查询延时问题，当时试图使用hadoop来实现交互式查询分析，但是很难满足实时分析的需要。而Druid提供了以交互方式访问数据的能力，并权衡了查询的灵活性和性能二采取了特殊的存储格式。

Druid允许以类似Dremel和PowerDrill的方式进行单表查询，同时还增加了一些新特性，如为局部嵌套数据结构提供列式存储格式、为快速过滤做索引、实时摄取和查询、高容错的分布式体系架构等。

特性

为分析而设计：为OLAP工作流的探索性分析而构建，支持各种过滤、聚合和查询等类；

快速的交互式查询：Druid的低延迟数据摄取架构允许事件在他们创建后毫秒内可被查询到；

高可用性：Druid的数据在系统更新时依然可用，规模的扩大和缩小都不会造成数据丢失；

可扩展：Druid已实现每天能够处理数十亿事件和TB级数据。

使用场景

1、需要交互式聚合和快速探究大量数据时；

2、需要实时查询分析时；

3、具有大量数据时，如每天数亿事件的新增、每天数10T数据的增加；

4、对数据尤其是大数据进行实时分析时；

5、需要一个高可用、高容错、高性能数据库时。

架构

Historical：对非实时数据进行处理存储和查询；

Realtime：实时摄取数据、监听输入数据流

Coordinator：监控historical节点

Broker：接收来自外部客户端的查询，和将查询转发到Realtime和historical

Indexer：负责索引服务

对比

Spark+Redis+Hbase 实时数据探索

代存在下述问题：

• 流量高峰期处理延迟

• 纬度交叉分析，不灵活

• 消耗资源大

• 系统故障，重算慢

这是第一代、消耗大、系统故障，在大内存情况下很容易导致崩溃。马蜂窝之前就遇到突发，一组三台，每一台 512 个 G，这个时候内存太大了，哪天一个内存条坏的话，这一天的数据可能就要重新算，而且对于现在当前整个实时数据量来看，完全就不符合当前的现状，算一天需要十几个小时。

当时考虑到，在数据量大的情况下，是不是我们可以去牺牲 UV 的计算。所以就引入在 Druid 里面。把 Druid 引入到 MES，误差基本上保持在 2% 左右。后面我们又通过雅虎提供的data sketch,可以精确调控 UV 的计算，它的默认值是 16384，16384 以下可以是精确的。当然这个值是可以控制的，就是 2 的 N 次幂，当前我们是调到特别大，800 多万。但 Druid 里面不支持MES第一代的虚拟 key。

在 Druid 里面对于datasource 有一个按时间密度去分的，我们历史数据在查询力度这个层面，只能让他查到按每小时去查，其他按天去分配。最新的数据就在最近 15 天，我们可以让他精确到一分钟的查询，对于历史数据，力度越精确，数据量到 Druid 里面越大。

在离线批量导入，现在 Druid 支持，T+1 的数据校正。如果在 PSPARK+TRANQUILITY 这一阶段，因为 SPARK 的 task 失败的话，可能会导致这个数据到 Druid 里面 PV 会上升。所以说需要每天凌晨通过批量导入的方法把上一天的数据做一个数据校准。同样的是需要打平在 attr 里打平所有工程师上报的数据制定的值。

｜Druid 集群注意事项

在 Druid 里面配置，

1、维度不要太多，像蚂蜂窝最开始 700 多个维度。每天导进去将近 100 个 G，导进去十分耗时。

2、维度大小，不要太大。比如你来一个维度值几兆的，这个不行。

3、要去合理配置比例。在最开始，我们就拿了跟我们之前节点挂上了 10 个 T 的磁盘，作为整个 Druid 节点的数据存储，但是发现在你去查，无论你是去查任务，或者查历史数据。10 个 T 的磁盘跟不上来，查询各种超时，各种响应。

4、磁盘选用。其实采用的固态盘，基本上像我们现在的配置，就是 256 个 G 内存，1.2T 的固态盘。这个配置起来，你去查询整个历史数据，或者无论你查询其他的数据都是很快的。

5、在segment大小，我们最开始是按天的，100个G，后面拆分成每小时去分。这个时候到几个G，几个G也不行，我们就是要在去拆分几个G，到最终查询相当于是在在300-700兆左右。

6、在Druid里面，不支持逗号，因为 Druid 里在底层逗号是用来分隔。

7、优先去升级 Druid 的版本。我们在最早从 0.6 慢慢升级到 0.8，我们现在用的是 0.9。每一次 Druid 的发版，优化了很多东西。你觉得每一个查询有问题，或者说你想要去更快查询这些数据，可以优先考虑一下去 github 上面去看看 Druid 的最新近况。

这个就是今天给大家分享的一些东西。当然我们在使用 Druid 的过程当中，其实还遇到其他很多问题。也希望 Druid 能越来越好。

其他

Druid已基于Apache License 2.0协议开源，代码托管在github，当前最稳定版本是0.7.11，已经有63个代码Contributer和近2000个关注。Druid的主要贡献者包括广告分析创业公司Metamarkets、电影流媒体网站Metflix、Yahoo等公司。Druid官方对Druid通Shark、Vertica、Cassandra、Hadoop、Spark、Elasticsearch等在容错能力、灵活性、查询性能等方面进行了对比说明。