Druid学习笔记（2）Druid架构剖析

1. 前言

Druid 的目标是提供一个能够在大数据集上做实时数据摄入与查询的平台，然而对于大多数系统而言，提供数据的快速摄入与提供快速查询是难以同时实现的两个指标。例如对于普通的RDBMS,如果想要获取更快的查询速度，就会因为创建索引而牺牲掉写入的速度，如果想要更快的写入速度，则索引的创建就会受到限制。而Druid却可以完美的对两者进行结合，本文将对Druid如何实现这种结合做一个简单的介绍。

2. Druid数据流

下图为Druid的数据流，包括数据摄入，元数据，查询，三方面的流程

2.1数据摄入

数据可以通过实时节点以及批处理的方式进入Druid,对于实时节点而言，数据流的数据被实时节点消费后，当满足条件后，实时节点会将收到的数据生成为Segment文件并上传到DeepStorage.批量数据经过Druid消费后，会被直接上传到DeepStorage中。

2.2元数据

当数据文件上传到DeepStorage后，Coordinator节点会通知历史节点将Segment的文件从DeepStorage上下载到本地磁盘。

2.3查询

在数据摄入的同事，Broker节点可以接受查询请求，并将分别从实时节点与历史节点的查询的结果合并后返回

3. 架构设计

前文提到Druid在数据摄入与查询的性能方面，做到了很好结合，本章节将详细分析Druid是如何做到的。

3.1 常见的文件组织方式

除了内存数据库之外的大多数数据库，数据基本都是存在磁盘上，而磁盘的访问操作相对于内存操作而言是非常耗时的操作，提高数据库性能的关键点之一就是减少对磁盘的访问次数。

为了减少访问次数，每个数据库基本都有自己特殊的数据结构来帮助提高查询效率（也可以叫索引），考虑到数据查询一般都是一个范围的数据，所以相关结构一般都不会考虑使用HASH结构，而会使用Tree结构，下面对几种常见的Tree结构进行简单的说明

• 二叉查找树(Binary Search Tree)

  就是一颗二叉有序树，保证左子树上的所有节点都小于根节点，保证右子树上的所有节点都大于根节点。优点是简单，缺点是出现数据倾斜时，效率会很低

• 平衡二叉树

  针对二叉查找树的问题，平衡二叉树出现了，该种树结构的缺点是树高为Log2N,树的高度越高，查找效率越低

• B+树

  在传统的关系数据库中，B+树以及其衍生树是被用来作为索引数据结构最多的书，特点是能够保持数据稳定有序，其插入与修改拥有较稳定的对数时间复杂度。详细介绍请参考：<高性能MySql进化论(六):常见索引类型的原理及其特点的介绍> http://blog.csdn.net/eric_sunah/article/details/14045991：

  B+树的缺点来自于其优点，当存储数据为亿级别时，随着插入操作的不断产生，叶子节点会慢慢的分裂，可能导致原本连续存放的数据，存放在不同的物理磁盘块位置上，做范围查询时，导致较高的磁盘IO,导致性能下降

• 日志合并树（LSM）
  对于写操作而言，顺序写的效率会远远大于随机写的速度，而上述的B+树就违反了该原则。

  1992年日志结构(Log Structured)的新型索引结构产生了，该种类型的思想主要是将磁盘看成是一个大的日志，每次数据都最佳到末端，从而提高了写的性能。此时的日志结构索引对于随机读取的效率很低。

  1996年，日志结构合并树(Log structured Merge-Tree-LSM)的索引结构被提出。该种结构包含了LS的优点，同时又通过将数据文件预排序来克服随机查性能不足的问题。

  LSM的名声大噪归功于HBASE以及Cassandra,随着这两个Apache顶级项目的发展,LSM技术也在不断的发展

LSM-tree是由两个或两个以上存储数据的结构组成的。最简单的LSM-tree由两个部件构成。一个部件常驻内存