Apache 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:负责索引服务

image.png
image.png

对比

Spark+Redis+Hbase 实时数据探索

代存在下述问题:

  • 流量高峰期处理延迟

  • 维度交叉分析,不灵活

  • 消耗资源大

  • 系统故障,重算慢

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

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

image.png

在 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等在容错能力、灵活性、查询性能等方面进行了对比说明。

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 218,640评论 6 507
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 93,254评论 3 395
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 165,011评论 0 355
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 58,755评论 1 294
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 67,774评论 6 392
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 51,610评论 1 305
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 40,352评论 3 418
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 39,257评论 0 276
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 45,717评论 1 315
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 37,894评论 3 336
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 40,021评论 1 350
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 35,735评论 5 346
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 41,354评论 3 330
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,936评论 0 22
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 33,054评论 1 270
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 48,224评论 3 371
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 44,974评论 2 355