druid实时数据（Druid简介和大数据分析）

　　Druid 单词来源于西方古罗马的神话人物，中文常常翻译成德鲁伊。
　　本问介绍的Druid 是一个分布式的支持实时分析的数据存储系统（Data Store）。美国广告技术公司MetaMarkets 于2011 年创建了Druid 项目，并且于2012 年晚期开源了Druid 项目。Druid 设计之初的想法就是为分析而生，它在处理数据的规模、数据处理的实时性方面，比传统的OLAP 系统有了显著的性能改进，而且拥抱主流的开源生态，包括Hadoop 等。多年以来，Druid 一直是非常活跃的开源项目。
　　Druid 的官方网站是http://druid.io。
　　另外，阿里巴巴也曾创建过一个开源项目叫作Druid（简称阿里Druid），它是一个数据库连接池的项目。阿里Druid 和本问讨论的Druid 没有任何关系，它们解决完全不同的问题。

　　大数据一直是近年的热点话题，随着数据量的急速增长，数据处理的规模也从GB 级别增长到TB 级别，很多图像应用领域已经开始处理PB 级别的数据分析。大数据的核心目标是提升业务的竞争力，找到一些可以采取行动的洞察（Actionable Insight），数据分析就是其中的核心技术，包括数据收集、处理、建模和分析，最后找到改进业务的方案。
　　最近一两年，随着大数据分析需求的爆炸性增长，很多公司都经历过将以关系型商用数据库为基础的数据平台，转移到一些开源生态的大数据平台，例如Hadoop 或Spark 平台，以可控的软硬件成本处理更大的数据量。Hadoop 设计之初就是为了批量处理大数据，但数据处理实时性经常是它的弱点。例如，很多时候一个MapReduce 脚本的执行，很难估计需要多长时间才能完成，无法满足很多数据分析师所期望的秒级返回查询结果的分析需求。
　　为了解决数据实时性的问题，大部分公司都有一个经历，将数据分析变成更加实时的可交互方案。其中，涉及新软件的引入、数据流的改进等。数据分析的几种常见方法如下图。

数据分析的基础架构可以分为以下几类：

• 使用Hadoop/Spark进行分析
• 将Hadoop/Spark的结果导入 RDBMS 中提供数据分析
• 将结果注入到容量更大的 NoSQL中，解决数据分析的存储瓶颈，例如：HBase
• 将数据源进行流式处理，对接流式计算框架，例如：Flink、Spark Streaming，结果保存到 RDBMS、NoSQL中
• 将数据源进行流式处理，对接分析数据库，例如：Druid

基于Hadoop大数据平台的问题

基于 Hadoop 的大数据平台，有如下一些问题：

• 无法保障查询性能对于Hadoop使用的MapReduce批处理框架，数据何时能够查询没有性能保证
• 随机IO问题HDFS以集群硬盘作为存储资源池的分布式文件系统在海量数据的处理过程中，会引起大量的读写操作，随机IO是高并发场景下的性能瓶颈
• 数据可视化问题HDFS对于数据分析以及数据的即席查询，HDFS并不是最优的选择

传统的Hadoop大数据处理架构更倾向于一种“后台批处理的数据仓库系统”，其作为海量历史数据保存、冷数据分析，确实是一个优秀的通用解决方案，但

• 无法保证高并发环境下海量数据的查询分析性能
• 无法实现海量实时数据的查询分析与可视化

Druid是面向海量数据的、用于实时查询与分析的OLAP存储系统。Druid的四大关键特性如下：

• 亚秒级的OLAP查询分析采用了列式存储、倒排索引、位图索引等关键技术
• 在亚秒级别内完成海量数据的过滤、聚合以及多维分析等操作
• 实时流数据分析传统分析型数据库采用的批量导入数据，进行分析的方式Druid提供了实时流数据分析，以及高效实时写入
• 实时数据在亚秒级内的可视化
• 丰富的数据分析功能Druid提供了友好的可视化界面
• SQL查询语言REST查询接口
• 高可用性与高可拓展性Druid工作节点功能单一，不相互依赖Druid集群在管理、容错、灾备、扩容都很容易

　　在设计之初，开发人员确定了三个设计原则（Design Principle）。
（1）快速查询（Fast Query）：部分数据的聚合（Partial Aggregate） 内存化（In-emory） 索引（Index）。
（2）水平扩展能力（Horizontal Scalability）：分布式数据（Distributed Data） 并行化查询（Parallelizable Query）。
（3）实时分析（Realtime Analytics）：不可变的过去，只追加的未来（Immutable Past，Append-Only Future）。

1 快速查询（Fast Query）

　　对于数据分析场景，大部分情况下，我们只关心一定粒度聚合的数据，而非每一行原始数据的细节情况。因此，数据聚合粒度可以是1 分钟、5 分钟、1 小时或1 天等。部分数据聚合（Partial Aggregate）给Druid 争取了很大的性能优化空间。
　　数据内存化也是提高查询速度的杀手锏。内存和硬盘的访问速度相差近百倍，但内存的大小是非常有限的，因此在内存使用方面要精细设计，比如Druid 里面使用了Bitmap 和各种压缩技术。
另外，为了支持Drill-Down 某些维度，Druid 维护了一些倒排索引。这种方式可以加快AND 和OR 等计算操作。

2 水平扩展能力（Horizontal Scalability）

　　Druid 查询性能在很大程度上依赖于内存的优化使用。数据可以分布在多个节点的内存中，因此当数据增长的时候，可以通过简单增加机器的方式进行扩容。为了保持平衡，Druid按照时间范围把聚合数据进行分区处理。对于高基数的维度，只按照时间切分有时候是不够的（Druid 的每个Segment 不超过2000 万行），故Druid 还支持对Segment 进一步分区。
　　历史Segment 数据可以保存在深度存储系统中，存储系统可以是本地磁盘、HDFS 或远程的云服务。如果某些节点出现故障，则可借助Zookeeper 协调其他节点重新构造数据。
　　Druid 的查询模块能够感知和处理集群的状态变化，查询总是在有效的集群架构中进行。集群上的查询可以进行灵活的水平扩展。Druid 内置提供了一些容易并行化的聚合操作，例如Count、Mean、Variance 和其他查询统计。对于一些无法并行化的操作，例如Median，Druid暂时不提供支持。在支持直方图（Histogram）方面，Druid 也是通过一些近似计算的方法进行支持，以保证Druid 整体的查询性能，这些近似计算方法还包括HyperLoglog、DataSketches的一些基数计算。

3 实时分析（Realtime Analytics）

　　Druid 提供了包含基于时间维度数据的存储服务，并且任何一行数据都是历史真实发生的事件，因此在设计之初就约定事件一但进入系统，就不能再改变。
　　对于历史数据Druid 以Segment 数据文件的方式组织，并且将它们存储到深度存储系统中，例如文件系统或亚马逊的S3 等。当需要查询这些数据的时候，Druid 再从深度存储系统中将它们装载到内存供查询使用。

　　Druid 具有如下技术特点。
• 数据吞吐量大。
• 支持流式数据摄入和实时。
• 查询灵活且快。
• 社区支持力度大。

1 数据吞吐量大

　　很多公司选择Druid 作为分析平台，都是看中Druid 的数据吞吐能力。每天处理几十亿到几百亿的事件，对于Druid 来说是非常适合的场景，目前已被大量互联网公司实践。因此，很多公司选型Druid 是为了解决数据爆炸的问题。

2 支持流式数据摄入

　　很多数据分析软件在吞吐量和流式能力上做了很多平衡，比如Hadoop 更加青睐批量处理，而Storm 则是一个流式计算平台，真正在分析平台层面上直接对接各种流式数据源的系统并不多。

3 查询灵活且快

　　数据分析师的想法经常是天马行空，希望从不同的角度去分析数据，为了解决这个问题，OLAP 的Star Schema 实际上就定义了一个很好的空间，让数据分析师自由探索数据。数据量小的时候，一切安好，但是数据量变大后，不能秒级返回结果的分析系统都是被诟病的对象。因此，Druid 支持在任何维度组合上进行查询，访问速度极快，成为分析平台最重要的两个杀手锏。

4 社区支持力度大

　　Druid 开源后，受到不少互联网公司的青睐，包括雅虎、eBay、阿里巴巴等，其中雅虎的Committer 有5 个，谷歌有1 个，阿里巴巴有1 个。最近，MetaMarkets 之前几个Druid 发明人也成立了一家叫作Imply.io 的新公司，推动Druid 生态的发展，致力于Druid 的繁荣和应用。

• 腾讯腾讯企点采用Druid用于分析大量的用户行为，帮助提升客户价值
• 阿里巴巴阿里搜索组使用Druid的实时分析功能用于获取用户交互行为
• 新浪微博新浪广告团队使用Druid构建数据洞察系统的实时分析部分，每天处理数十亿的消息
• 小米Druid用于小米统计的后台数据收集和分析也用于广告平台的数据分析
• 滴滴打车Druid是滴滴实时大数据处理的核心模块，用于滴滴实时监控系统，支持数百个关键业务指标通过Druid，滴滴能够快速得到各种实时的数据洞察
• 优酷土豆Druid用于其广告的数据处理和分析

Druid 对比其他OLAP

Druid vs. Elasticsearch

• Druid在导入过程会对原始数据进行Rollup，而ES会保存原始数据
• Druid专注于OLAP，针对数据导入以及快速聚合操作做了优化
• Druid不支持全文检索

Druid vs. Key/Value Stores (HBase/Cassandra/OpenTSDB)

• Druid采用列式存储，使用倒排和bitmap索引，可以做到快速扫描相应的列

Druid vs. Spark

• Spark SQL的响应还不做到亚秒
• Druid可以做到超低的响应时间，例如亚秒，而且高并发面向用户的应用。

Druid vs SQL-on-Hadoop (Impala/Drill/Spark SQL/Presto)

• Driud查询速度更快
• 数据导入，Druid支持实时导入，SQL-on-Hadoop一般将数据存储在Hdfs上，Hdfs的写入速度有可能成为瓶颈
• SQL支持，Druid也支持SQL，但Druid不支持Join操作

Druid vs. Kylin

• Kylin不支持实时查询，Druid支持
• Kylin支持表连接（Join），Druid不支持