Druid创始人Eric Tschetter详解开源实时大数据分析系统Druid

发表于 2014-11-11 16:27|  21477次阅读| 来源 CSDN|  0 条评论| 作者 周小璐、魏伟

云计算 Druid 开源 Hadoop

摘要：Druid是一个为大型冷数据集上实时探索查询而设计的开源数据分析和存储系统，提供极具成本效益并且永远在线的实时数据摄取和任意数据处理。Druid创始人Eric Tschetter在eBay上海大数据峰会上接受了CSDN的专访。

Druid是为大型数据集上实时探索查询而设计的开源分析数据存储系统，它的设计意图是在面对代码部署、机器故障以及其他产品系统遇到不测时能保持100%正常运行。它也可以用于后台用例，但设计决策明确定位线上服务。

主要特性：

• 为分析而设计——Druid是为OLAP工作流的探索性分析而构建。它支持各种filter、aggregator和查询类型，并为添加新功能提供了一个框架。用户已经利用Druid的基础设施开发了高级K查询和直方图功能。
• 交互式查询——Druid的低延迟数据摄取架构允许事件在它们创建后毫秒内查询，因为Druid的查询延时通过只读取和扫描优必要的元素被优化。Aggregate和 filter没有坐等结果。
• 高可用性——Druid是用来支持需要一直在线的SaaS的实现。你的数据在系统更新时依然可用、可查询。规模的扩大和缩小不会造成数据丢失。
• 可伸缩——现有的Druid部署每天处理数十亿事件和TB级数据。Druid被设计成PB级别。

Druid当前允许以类似 Dremel 和PowerDrill的方式单表查询，但也增加了一些新特性。

1. 为局部嵌套数据结构提供列式存储格式；
2. 利用intermediate pruning进行分级查询分配；
3. 为快速过滤做索引；
4. 实时摄取（摄取的数据可立即用于查询）；
5. 容错分布式体系架构，不会丢失数据。

就系统而言，Druid功能位于PowerDrill和Dremel之间。它实现几乎所有Dremel提供的工具（Dremel处理任意嵌套数据结构，而Druid只允许一个基于数组的嵌套级别）并且从PowerDrill吸收一些有趣的数据格式和压缩方法。

Druid对于需要实时单一、海量数据流摄取产品非常适合。特别是如果你面向无停机操作时，如果你对查询查询的灵活性和原始数据访问要求，高于对速度和无停机操作，Druid可能不是正确的解决方案。在谈到查询速度时候，很有必要澄清“快速”的意思是：Druid是完全有可能在6TB的数据集上实现秒级查询。

架构：

Druid是由不同角色的系统构建而成的一个整体系统，它的名字来自在许多角色扮演游戏中的Druid类：它是一个shape-shifter，可以在一个群组中采取许多不同的形式来满足各种不同的角色。

Druid的整体架构中目前包括以下节点类型：

Historical 节点是对“historical”数据（非实时）进行处理存储和查询的地方。historical节点响应从broker节点发来的查询，并将结果返回给broker节点。它们在Zookeeper的管理下提供服务，并使用Zookeeper监视信号加载或删除新数据段.。

Realtime节点实时摄取数据，它们负责监听输入数据流并让其在内部的Druid系统立即获取，Realtime节点同样只响应broker节点的查询请求，返回查询结果到broker节点。旧数据会被从Realtime节点转存至Historical节点。

Coordinator 节点监控historical节点组，以确保数据可用、可复制，并且在一般的“最佳”配置。它们通过从MySQL读取数据段的元数据信息，来决定哪些数据段应该在集群中被加载，使用Zookeeper来确定哪个historical节点存在，并且创建Zookeeper条目告诉historical节点加载和删除新数据段。

Broker 节点接收来自外部客户端的查询，并将这些查询转发到Realtime和Historical节点。当Broker节点收到结果，它们将合并这些结果并将它们返回给调用者。由于了解拓扑，Broker节点使用Zookeeper来确定哪些Realtime和Historical节点的存在。

Indexer 节点会形成一个加载批处理和实时数据到系统中的集群，同时会对存储在系统中的数据变更（也称为索引服务）做出响应。

这种分离让每个节点只关心自身的最优操作。通过将Historical 和Realtime分离，将对进入系统的实时流数据监控和处理的内存分离。通过将Coordinator和Broker分离，把查询操作和维持集群上的“好的”数据分布的操作分离。

下面的关系图显示了架构中的查询和数据流，以及和哪个节点相关：

 

除了这些节点，系统还有3个外部依赖：

1. 一个运行的ZooKeeper集群，为集群服务发现和维持当前的数据拓扑而服务；
2. 一个MySQL实例，用来维持系统服务所需的数据段的元数据；
3. 一个LOB存储系统，保存“冷数据”。

下面的图说明了集群的管理层，展示特定的节点和依赖如何通过跟踪和交换元数据来帮助管理集群：

 

数据存储

获取数据到Druid系统需要一个索引进程，如上面图所示。这给系统一个机会，为了优化查询速度，分析数据，添加索引结构，压缩和调整布局。

• 转换为列式存储
• 建立位图索引
• 使用各种压缩算法

LZF （切换到Snappy尚未实现）
Dictionary encoding w/ id存储最小化 
Bitmap压缩
RLE （尚未实现）

索引过程的输出存储在一个LOB存储系统中，数据被Historical节点加载，首先是通过将数据下载到它们的本地磁盘，然后在服务查询之前内存映射它。

如果Historical节点死亡，它将不再服务它的数据，但考虑到数据仍可以在“deep storage”中获取，任何其他节点只需下载数据，就可以开始服务。这实际上意味着可以从集群中删除所有的Historical节点，然后重新指配给它们，而没有任何数据丢失。

为了使数据存在于集群内部，一个条目必须被添加在一个MySQL实例表中。这个条目是关于数据的自描述元数据，包括诸如数据段的模式、大小以及在“deep storage”中的位置等。

容错

Historical正如上面所讨论的，如果一个historical节点死亡，另一个历史的节点可以取而代之，不用担心数据丢失。

Coordinator可以运行在一个热故障转移配置上。如果没coordinators在运行，然后数据拓扑将停止变化，但该系统将继续运行。

Broker可以并行或在hot fail-over上运行。

Realtime取决于delivery流的语义，它们可以并行运行处理完全相同的流。它们定期检查磁盘并最终推送到Historical节点，并且可以采取措施恢复死亡进程，如果访问本地磁盘是将数据添加到系统的唯一方式，那么如果失去本地磁盘的访问可能导致数据丢失。

“deep storage”文件系统如果不可用，新数据将无法进入集群，但集群将继续按原来方式操作。

MySQL如果不可用，Coordinator将无法找出系统中的新segment，但原有的数据仍然可以被查询到。

ZooKeeper如果不可用，数据拓扑结构改变将不能进行，但Broker将相应的保持它们最新的数据拓扑视图和持续服务请求。

查询处理

一个查询首先进入Broker，Broker将查询与已知存在的数据段匹配。然后选择一组服务那些segment的机器，并且为每个服务器重写查询来指定目标segment。Historical/Realtime节点将查询、处理、并返回结果。Broker然后将结果合并在一起，得到最终的它返回的结果。通过这种方式，broker可以在看到行数据之前删除所有与查询不匹配的数据。

对于在更高细粒度水平的filter，每个segment内部的索引结构在看到任意行数据之前，允许historical节点找出哪些（如果有的话）行匹配filter组。它可以在位图索引做所有的filter boolean algebra，并且从来没有直接看到一行数据。

一旦知道行与当前查询相匹配，它可以直接访问它关心的列，而无需加载其它数据。

In-memory？

Druid并不总是以及只在内存。当我们第一次构建它时，它始终是全内存的，但随着时间的推移，将所有客户数据保持在内存中是行不通的。然后，我们增加了内存映射数据能力以及允许操作系统处理页面数据在内存里外的需求。我们的production集群主要用来配置内存映射行为的操作。（编译/魏伟 审校/周小璐）

更多介绍请点击Druid官网： Druid  

更多eBay上海大数据峰会内容： eBay上海大数据峰会2014

2014年12月12-14日，2014中国大数据技术大会（Big Data Technology Conference 2014，BDTC 2014）将在北京新云南皇冠假日酒店举办。大会将邀请近100位国内外大数据技术领域顶尖专家与一线实践者，深入讨论Hadoop、YARN、Spark、HBase、Impala、Tez等开源软件的最新进展，NoSQL/NewSQL、内存计算、流计算和图计算技术的发展趋势，以及大数据下的可视化、图计算、机器学习/深度学习、商业智能、数据分析等的最新业界应用，分享实际生产系统中的技术特色和实践经验。欢迎报名参加！

---

欢迎订阅“CSDN云计算和CSDN大数据”微信公众号！