druid简介
Druid的由来
随着大数据分析需求的爆炸性增长，很多公司都经历过将以关系型商用数据库为基础的数据平台，转移到一些开源生态的大数据平台，例如Hadoop 或Spark 平台，以可控的软硬件成本处理更大的数据量。Hadoop 设计之初就是为了批量处理大数据，但数据处理实时性经常是它的弱点。例如，很多时候一个MapReduce 脚本的执行，很难估计需要多长时间才能完成，无法满足很多数据分析师所期望的秒级返回查询结果的分析需求。为了解决数据实时性的问题，大部分公司都有一个经历，将数据分析变成更加实时的可交互方案。其中，涉及新软件的引入、数据流的改进等。数据分析的几种常见方法如下图。
大数据分析的发展路程：
- 使用Hadoop/Spark 的MR 分析。
- 将Hadoop/Spark 的结果注入RDBMS 中提供实时分析。
- 将结果注入到容量更大的NoSQL 中，例如HBase 等。
- 将数据源进行流式处理，对接流式计算框架，如Storm，结果落在RDBMS/NoSQL 中。
- 将数据源进行流式处理，对接分析数据库，例如Druid、kyllin 等。
Druid的特点
Druid 具有如下技术特点。
• 数据吞吐量大。
• 支持流式数据摄入和实时。
• 查询灵活且快。
• 社区支持力度大。
Druid的架构
架构预览
Druid本身包含以下四个节点和一个服务
- 实时节点(RealTime Node) 即时摄入实时数据，并且生成Segment文件
- 历史节点(Historical Node)加载已经生成好的数据文件，以供数据查询使用
- 查询节点(Broker Node) 对外提供数据查询服务，并且从实时节点和历史节点汇总数据，合并后返回
- 协调节点(Coordinator Node)负责历史节点的数据的负载均衡，以及通过规则管理数据的生命周期
- 索引服务(Indexing Service)有不同的获取数据的方式，更加灵活的生成segment文件管理资源。
数据结构
与Druid架构相辅相成的是基于DataSource和Segment的数据结构。
DataSource的结构：与传统的关系型数据库相比较DataSource可以理解为表，包含下面几点
- 时间列 表明每行数据的时间值
- 维度列 表明数据的各个维度信息
- 指标列 需要聚合的列的数据
Segment 结构：Datasource是指的逻辑概念，Segment指的是实际的物理存储格式，Druid通过Segment实现了横纵向切割操作。Druid将不同的时间范围内的数据存放在不同的Segment文件块中，通过时间实现了横向切割，同时，Segment也面向列进行数据压缩存储，这边是纵向切割。
架构详情
实时节点
实时节点主要负责即时摄入实时数据，以及生成Segment文件。
实时节点通过firehose进行数据的摄入，firehose是Druid实时消费模型。比如通过kafka消费，就是kafkaFireHose。 同时，实时节点的另外一个模块Plumer，用于Segment的生成，并且按照指定的周期，将本周期内生成的所有数据块合并成一个
Segment文件从制造到传播要经历一个完整的过程。
- 实时节点生产出Segment文件，并且存到文件系统中。
- Segment文件的MetaStore存放到Mysql等其他外部数据库中
- Master通过Mysql中的MetaStore，通过一定的规则，将Segment分配给属于它的节点。
- 历史节点得到Master发送的指令后会从文件系统中拉取属于自己的Segment文件，并且通过zookeeper，告知集群，自己提供了此块Segment的查询服务
- 实时节点丢弃Segment文件，并且声明不在提供此块文件的查询服务
历史节点
历史节点再启动的时候，会优先检查自己的本地缓存中是否已经有了缓存的Segment文件，然后从文件系统中下载属于自己，但还不存在的Segment文件，无论是何种查询，历史节点首先将相关的Segment从磁盘加载到内存。然后在提供服务。
可以看出，历史节点的查询效率受内存空间富余成都的影响很大，内存空间富余，查询时需要从磁盘加载数据的次数减少，查询速度就快，反之，查询时需要从磁盘加载数据的次数就多，查询速度就相对较慢，因此，原则上历史节点的查询速度与其内存大小和所负责的Segment数据文件大小成正比关系
查询节点
在常规情况下，Druid集群直接对外提供查询的节点只有查询节点，而查询节点会将从实时节点与历史节点查询到的数据合并后返回给客户端，因此查询节点便是整个集群的查询中枢。
Druid使用了Cache机制来提高自己的查询效率。Druid立功了两类介质作为Cache以供选择，
- 外部cache，比如Memcached
- 内部Cache，比如查询节点或历史节点的内存
如果用查询节点的内存作为Cache，查询的时候会首先访问其Cache，只有当不命中的时候才会去访问历史节点和实时节点查询数据
协调节点
对于整个Druid集群来说。其实并没有真正意义上的Master节点，因为实时节点与查询节点能自行管理并不听命于任何其他节点，但是对于历史节点来说，协调节点便是他们的Master，因为协调节点将会给历史节点分配数据，完成数据分布在历史节点之间的负载均衡。历史节点之间是相互不进行通讯的，全部通过协调节点进行通讯。
利用规则管理数据的生命周期：Druid利用针对每个DataSoure设置的规则来加载或者丢弃具体的文件数据，来管理数据的生命周期，可以对一个DataSource按顺序添加多条规则，对于一个Segment文件来说，协调节点会逐条检查规则，当碰到当前Segment文件负责某条规则的情况下，协调节点会立即命令历史节点对该文件执行此规则，加载或者丢弃，并停止余下的规则，否则继续检查。
索引服务
除了通过实时节点生产Segment文件之外，druid还提供了一组索引服务来摄入数据，相比较于实时节点，索引服务的优点是能够有不同的获取数据的方式，支持pull和push；可以通过API编程的方式来配置任务；可以更加灵活地使用资源；灵活地操作Segment文件等。
索引服务的主从架构
索引服务包含一组组件，并以主从结构作为架构方式，其统治节点 Overload node 为主节点。而中间管理者Middle Manager 为从节点
Overload node：作为索引服务的主节点，对外负责接收任务请求，对内负责将任务分解并下发到从节点即Middle Manager 上，Overload node 有两种运行模式
- 本地模式（默认）：，此模式主节点不仅需要负责集群的调度，协调分配工作，还需要负责启动苦工（Peon）来完成一部分具体的任务
- 远程模式 ：此模式下，主从节点分别运行在不同的节点上，主节点只负责协调分配工作，不负责完成任务，并且提供rest服务，因此客户端可以通过 HTTP POST 来提交任务
Middle Manager 与苦工：Middle Manager 即是 Overload node 的工作节点，负责接收Overload node 分配的任务，然后启动相关的Peon来完成任务 这种模式和yarn的架构比较类似
- Overload node 相当于Yarn的ResourceManager，负责资源管理和任务分配
- Middle Manager 相当于Yarn的NodeManager ，负责管理独立节点的资源，并且接收任务
- Peon 相当于Yarn的Container ，启动在具体节点上具体任务的执行