Druid是一个为大型冷数据集上实时探索查询而设计的开源数据分析和存储系统，提供极具成本效益并且永远在线的实时数据摄取和任意数据处理，并且在面对代码部署、机器故障以及其他产品系统遇到不测时能保持100%正常运行。
Eric Tschetter本科就读于德克萨斯大学奥斯汀分校，在东京国立情报学研究所拿到了计算机科学的硕士学位。之后在硅谷，Eric加入了Marc Andreessen创办的社交网络平台公司Ning(这个名字取自中文“宁”的拼音);后来Eric又加入了LinkedIn，参与了“People You May Know”产品;离开LinkedIn后，Eric成为了Metamarkets的第一位全职雇员，并在那里开发Druid。目前，Eric为一家非盈利组织Tidepool工作，为糖尿病人提供开源的医疗数字化应用。
Druid创始人 Eric Tschetter
Druid是一个开源的分布式实时处理系统，旨在快速处理大规模的数据，并能做到快速查询和分析。为烧钱的大数据处理，提供一种更廉价的选择，目前来说是这个领域唯一的开源产品。Druid还将一些基本功能UI 化，为非技术人员提供服务。说到与Druid最类似的项目，Eric认为是Google的PowerDrill。
MapReduce和BigTable的论文催生了大数据处理的事实标准hadoop。Dremel和PowerDrill问世后，很多人都在好奇有哪些开源大数据技术又要兴起，Druid会是其中之一吗?
应用场景
Druid应用最多的是类似于Metamarkets中的应用场景——广告分析，互联网广告系统监控、度量和网络监控。并且eBay也已经计划将Druid用于生产环境中。
开发团队
目前Druid被托管在GitHub上，有44个 contributor，1000+的关注，Druid 的主要贡献者，包括Metamarkets，Netflix、Yahoo和一些硅谷的创业公司。Druid 的开发人员通过Druid 论坛互动和支持Druid 的开发。笔者刚刚查看了Druid的Google Group，最近一直保持着比较活跃的讨论。
Eric介绍说，每当他们学到新的东西或有新的想法，总会尽快去实践检验。所以自2011年3月第一条代码提交至今，Druid有了很大的改进。比如数据的存储方式，大概变化了9次，查询流程大概变化了3-4次，各个节点间的相互协调大概变化了3次，但是每个节点制作一件事情的原则没有变化过。Eric说未来可能还会有更多的变化，但是基本的架构不会改变。
Druid的中国元素
中国工程师Fangjin Yang(杨仿今)，与Eric一起负责Druid的主要开发工作
Eric开始Druid项目之后的几个月，Fangjin Yang 加入了这个项目。之后的几年，Eric和Fangjin并肩开发了Druid。Eric和Fangjin到目前为止一直是Druid最主要贡献者。今年，Eric和Fangjin开始了和一些中国公司的合作，帮助这些公司评估Druid以及回答关于Druid的问题。据Eric介绍，在中国，云广天下(西安)网络科技有限公司旗下的YeahMobi正在使用Druid。
文档和支持
也许是得益于Eric在本科毕业后做过翻译等相关的文档工作，Druid的相关文档编写得很详细、有条理。Eric说，关于这个项目感到最骄傲的事情，就是将其开源了，其他人仅通过Druid和一些相关文档，就可以解决很多问题。
同时Eric的开发团队，通过一个邮件列表(druid-development@googlegroups.com)为Druid的用户提供支持服务，但是目前还没有专门的赢利公司为其提供支持。
Druid的未来计划
Druid的未来计划，是继续保持这个开源项目的健康成长。围绕Druid已经聚集了多位来自不同公司的工程师。每位工程师、每个公司都希望看到Druid能够带来新的东西，他们的需求有时相同，有时不同，但是大家协力合作，就能把Druid做得更好。所以Eric希望Druid能成为大家共有的项目，形成一个社区，靠这个社区来指引Duid的发展方向。
Eric对未来的展望让笔者想起了Docker目前的发展，Eric说如果围绕Druid，能形成像Docker一样的生态系统，的确会是巨大的成功。
目前，Druid还没有公开的Roadmap，但是Druid已经开始了相关的制定工作，并在尝试和Metamarkets、Yahoo、Netflix和eBay共同合作，同时Eric表示也会参考其他Druid技术实践者的建议。
大数据技术的未来：合久必分，分久必合?
谈到大数据技术的未来，Eric回顾了60、70年代甚至 80年代，关系数据库的发展历史。那时有对象数据库、关系数据库等多种数据库类型，最终关系型数据库成为了主流，其它类型的数据库或者消失或者被边缘化。一直到2006年左右，关系型数据库还是占主导地位，其实70、80年代的数据库类型，都是基于“与存储介质的交互很贵”这样的假定设计的。但随着存储变得越来越廉价，内存越来越便宜，这个假定不成立了，相应的设计架构也需要调整，于是产生了NoSQL。Eric认为大数据技术也是以此为基础的。如今，大家都在基于新的硬件环境，寻找最优的解决方案，数据库技术又走入了新一轮的“百家争鸣”的阶段，特别是近几年出现的多种数据库技术。Eric认为，大概在 5-10年之后，数据库技术也会进入新一轮的融合阶段，届时大数据技术才会有清晰的发展方向，或许根据你的应用场景，也将有人能为你提供最佳的解决方案。
在被问及：“你认为Druid会是未来的方向吗?”Eric坦言说：“我不知道，但我希望是。Druid只是为解决已有的问题提供了一种新的思路，正确与否我还不能肯定，但我知道它解决了Metamarkets等许多公司的问题。但它能解决所有问题吗?答案是否定的，所以我不知道未来数据库技术会向哪个方向融合。”
Druid是为大型数据集上实时探索查询而设计的开源分析数据存储系统，它的设计意图是在面对代码部署、机器故障以及其他产品系统遇到不测时能保持100%正常运行。它也可以用于后台用例，但设计决策明确定位线上服务。
主要特性：
为分析而设计——Druid是为OLAP工作流的探索性分析而构建。它支持各种filter、aggregator和查询类型，并为添加新功能提供了一个框架。用户已经利用Druid的基础设施开发了高级K查询和直方图功能。
交互式查询——Druid的低延迟数据摄取架构允许事件在它们创建后毫秒内查询，因为Druid的查询延时通过只读取和扫描优必要的元素被优化。Aggregate和 filter没有坐等结果。
高可用性——Druid是用来支持需要一直在线的SaaS的实现。你的数据在系统更新时依然可用、可查询。规模的扩大和缩小不会造成数据丢失。
可伸缩——现有的Druid部署每天处理数十亿事件和TB级数据。Druid被设计成PB级别。
Druid当前允许以类似Dremel和PowerDrill的方式单表查询，但也增加了一些新特性。
为局部嵌套数据结构提供列式存储格式;
利用intermediate pruning进行分级查询分配;
为快速过滤做索引;
实时摄取(摄取的数据可立即用于查询);
容错分布式体系架构，不会丢失数据。
就系统而言，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个外部依赖：
一个运行的ZooKeeper集群，为集群服务发现和维持当前的数据拓扑而服务;
一个MySQL实例，用来维持系统服务所需的数据段的元数据;
一个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集群主要用来配置内存映射行为的操作。
