Apache Druid海量日志收集

Apache Druid大数据实时分析系统，我们可以采用Apache Druid存储海量日志，并对海量日志进行实时分析。

关于Apache Druid学习可以参考中文地址www.apache-druid.cn/。

Apache Druid介绍

当前市面上主流的大数据实时分析数据库很多，我们为什么选择Apache Druid？我们先做个对比：

Apache Druid是一个实时分析型数据库，旨在对大型数据集进行快速的查询分析（"OLAP"查询)。Druid最常被当做数据库来用以支持实时摄取、高性能查询和高稳定运行的应用场景，同时，Druid也通常被用来助力分析型应用的图形化界面，或者当做需要快速聚合的高并发后端API，Druid最适合应用于面向事件类型的数据。

Druid通常应用于以下场景：

1:点击流分析（Web端和移动端）
2:网络监测分析（网络性能监控）
3:服务指标存储
4:供应链分析（制造类指标）
5:应用性能指标分析
6:数字广告分析
7:商务智能 / OLAP

Druid主要特征：

1:列式存储，Druid使用列式存储，这意味着在一个特定的数据查询中它只需要查询特定的列，这样极地提高了部分列查询场景的性能。另外，每一列数据都针对特定数据类型做了优化存储，从而支持快速的扫描和聚合。

2:可扩展的分布式系统，Druid通常部署在数十到数百台服务器的集群中，并且可以提供每秒数百万条记录的接收速率，数万亿条记录的保留存储以及亚秒级到几秒的查询延迟。

3:大规模并行处理，Druid可以在整个集群中并行处理查询。

4:实时或批量摄取，Druid可以实时（已经被摄取的数据可立即用于查询）或批量摄取数据。

5:自修复、自平衡、易于操作，作为集群运维操作人员，要伸缩集群只需添加或删除服务，集群就会在后台自动重新平衡自身，而不会造成任何停机。如果任何一台Druid服务器发生故障，系统将自动绕过损坏。 Druid设计为7*24全天候运行，无需出于任何原因而导致计划内停机，包括配置更改和软件更新。

6:不会丢失数据的云原生容错架构，一旦Druid摄取了数据，副本就安全地存储在深度存储介质（通常是云存储，HDFS或共享文件系统）中。即使某个Druid服务发生故障，也可以从深度存储中恢复您的数据。对于仅影响少数Druid服务的有限故障，副本可确保在系统恢复时仍然可以进行查询。

7:用于快速过滤的索引，Druid使用CONCISE或Roaring压缩的位图索引来创建索引，以支持快速过滤和跨多列搜索。

8:基于时间的分区，Druid首先按时间对数据进行分区，另外同时可以根据其他字段进行分区。这意味着基于时间的查询将仅访问与查询时间范围匹配的分区，这将大大提高基于时间的数据的性能(__time)。

9:近似算法，Druid应用了近似count-distinct，近似排序以及近似直方图和分位数计算的算法。这些算法占用有限的内存使用量，通常比精确计算要快得多。对于精度要求比速度更重要的场景，Druid还提供了精确count-distinct和精确排序。

10:摄取时自动汇总聚合，Druid支持在数据摄取阶段可选地进行数据汇总，这种汇总会部分预先聚合您的数据，并可以节省大量成本并提高性能。

什么场景下应该使用Druid

1:数据插入频率比较高，但较少更新数据
2:大多数查询场景为聚合查询和分组查询（GroupBy），同时还有一定得检索与扫描查询
3:将数据查询延迟目标定位100毫秒到几秒钟之间
4:数据具有时间属性（Druid针对时间做了优化和设计）
5:在多表场景下，每次查询仅命中一个大的分布式表，查询又可能命中多个较小的lookup表
6:场景中包含高基维度数据列（例如URL，用户ID等），并且需要对其进行快速计数和排序
7:需要从Kafka、HDFS、对象存储（如Amazon S3）中加载数据

Apache Druid架构

如上图，这是官网Apache Druid的架构图：

1.Historicale：加载已生成好的数据文件，以供数据查询。
2.Broker：对外提供数据查询服务。
3.Coordinator：负责Historical Node的数据负载均衡，以及通过Rule管理数据生命周期。
4.元数据库（Metastore）：存储druid集群的元数据信息，如Segment的相关信息，一般使用MySQL或PostgreSQL
5.分布式协调服务（Coordination）：为Druid集群提供一致性服务，通常为zookeeper
6.数据文件存储（DeepStorage）：存储生成的Segment文件，供Historical Node下载，一般为使用HDFS

总结

本篇主要介绍了一下Apache Druid的特征、适用的场景、架构。