Apache Druid介绍

什么是 Druid

Apache Druid 是一个实时分析型数据库,旨在对大型数据集进行快速查询和分析("OLAP" 查询)。

Druid 最常被当做数据库,用以支持实时摄取、高查询性能和高稳定运行的应用场景。 例如,Druid 通常被用来作为图形分析工具的数据源来提供数据,或当有需要高聚和高并发的后端 API。 同时 Druid 也非常适合针对面向事件类型的数据。

通常可以使用 Druid 作为数据源的系统包括有:

  • 点击流量分析(Web 或者移动分析)
  • 网络监测分析(网络性能监控)
  • 服务器存储指标
  • 供应链分析(生产数据指标)
  • 应用性能指标
  • 数字广告分析
  • 商业整合 / OLAP

Druid 的核心架构集合了数据仓库(data warehouses),时序数据库(timeseries databases),日志分析系统(logsearch systems)的概念。

如果你对上面的各种数据类型,数据库不是非常了解的话,那么我们建议你进行一些搜索来了解相关的一些定义和提供的功能。

Druid 的一些关键特性包括有:

  1. 列示存储格式(Columnar storage format) Druid 使用列式存储,这意味着在一个特定的数据查询中它只需要查询特定的列。 这样的设计极大的提高了部分列查询场景性能。另外,每一列数据都针对特定数据类型做了优化存储,从而能够支持快速扫描和聚合。
  2. 可扩展的分布式系统(Scalable distributed system) Druid通常部署在数十到数百台服务器的集群中, 并且可以提供每秒数百万级的数据导入,并且保存有万亿级的数据,同时提供 100ms 到 几秒钟之间的查询延迟。
  3. 高性能并发处理(Massively parallel processing) Druid 可以在整个集群中并行处理查询。
  4. 实时或者批量数据处理(Realtime or batch ingestion) Druid 可以实时(已经被导入和摄取的数据可立即用于查询)导入摄取数据库或批量导入摄取数据。
  5. 自我修复、自我平衡、易于操作(Self-healing, self-balancing, easy to operate) 为集群运维操作人员,要伸缩集群只需添加或删除服务,集群就会在后台自动重新平衡自身,而不会造成任何停机。 如果任何一台 Druid 服务器发生故障,系统将自动绕过损坏的节点而保持无间断运行。 Druid 被设计为 7*24 运行,无需设计任何原因的计划内停机(例如需要更改配置或者进行软件更新)。
  6. 原生结合云的容错架构,不丢失数据(Cloud-native, fault-tolerant architecture that won’t lose data) 一旦 Druid 获得了数据,那么获得的数据将会安全的保存在 深度存储 (通常是云存储,HDFS 或共享文件系统)中。 即使单个个 Druid 服务发生故障,你的数据也可以从深度存储中进行恢复。对于仅影响少数 Druid 服务的有限故障,保存的副本可确保在系统恢复期间仍然可以进行查询。
  7. 针对快速过滤的索引(Indexes for quick filtering) Druid 使用 RoaringCONCISE 来压缩 bitmap indexes 后来创建索引,以支持快速过滤和跨多列搜索。
  8. 基于时间的分区(Time-based partitioning) Druid 首先按时间对数据进行分区,同时也可以根据其他字段进行分区。 这意味着基于时间的查询将仅访问与查询时间范围匹配的分区,这将大大提高基于时间的数据处理性能。
  9. 近似算法(Approximate algorithms) Druid应用了近似 count-distinct,近似排序以及近似直方图和分位数计算的算法。 这些算法占用有限的内存使用量,通常比精确计算要快得多。对于精度要求比速度更重要的场景,Druid 还提供了exact count-distinct 和 exact ranking。
  10. 在数据摄取的时候自动进行汇总(Automatic summarization at ingest time) Druid 支持在数据摄取阶段可选地进行数据汇总,这种汇总会部分预先聚合您的数据,并可以节省大量成本并提高性能。

我应该在什么时候使用 Druid

许多公司都已经将 Druid 应用于多种不同的应用场景。请访问 使用 Apache Druid 的公司 页面来了解都有哪些公司使用了 Druid。

如果您的使用场景符合下面的一些特性,那么Druid 将会是一个非常不错的选择:

  • 数据的插入频率非常高,但是更新频率非常低。
  • 大部分的查询为聚合查询(aggregation)和报表查询(reporting queries),例如我们常使用的 "group by" 查询。同时还有一些检索和扫描查询。
  • 查询的延迟被限制在 100ms 到 几秒钟之间。
  • 你的数据具有时间组件(属性)。针对时间相关的属性,Druid 进行特殊的设计和优化。
  • 你可能具有多个数据表,但是查询通常只针对一个大型的分布数据表,但是,查询又可能需要查询多个较小的 lookup 表。
  • 如果你的数据中具有高基数(high cardinality)数据字段,例如 URLs、用户 IDs,但是你需要对这些字段进行快速计数和排序。
  • 你需要从 Kafka,HDFS,文本文件,或者对象存储(例如,AWS S3)中载入数据。

如果你的使用场景是下面的一些情况的话,Druid 不是一个较好的选择:

  • 针对一个已经存在的记录,使用主键(primary key)进行低延迟的更新操作。Druid 支持流式插入(streaming inserts)数据,但是并不很好的支持流式更新(streaming updates)数据。 Druid 的更新操作是通过后台批处理完成的。
  • 你的系统类似的是一个离线的报表系统,查询的延迟不是系统设计的重要考虑。
  • 使用场景中需要对表(Fact Table)进行连接查询,并且针对这个查询你可以介绍比较高的延迟来等待查询的完成。

高基数

在 SQL 中,基数(cardinality)的定义为一个数据列中独一无二数据的数量。

高基数(High-Cardinality)的定义为在一个数据列中的数据基本上不重复,或者说重复率非常低。

例如我们常见的识别号,邮件地址,用户名等都可以被认为是高基数数据。 例如我们常定义的 USERS 数据表中的 USER_ID 字段,这个字段中的数据通常被定义为 1 到 n。每一次一个新的用户被作为记录插入到 USERS 表中,一个新的记录将会被创建, 字段 USER_ID 将会使用一个新的数据来标识这个被插入的数据。因为 USER_ID 中插入的数据是独一无二的,因此这个字段的数据技术就可以被考虑认为是 高基数(High-Cardinality) 数据。

Fact Table

与 Fact Table 对应的表是 Dimension Table。

这 2 个表是数据仓库的两个概念,为数据仓库的两种类型表。 从保存数据的角度来说,本质上没区别,都是表。 区别主要在数据和用途上,Fact Table 用来存 fact 数据,就是一些可以计量的数据和可加性数据,数据数量,金额等。 Dimension Table 用来存描述性的数据,比如说用来描述 Fact 表中的数据,如区域,销售代表,产品等。

0 0 投票数
文章评分

本文为从大数据到人工智能博主「xiaozhch5」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。

原文链接:https://lrting.top/backend/8716/

(0)
上一篇 2022-07-31 21:29
下一篇 6天前

相关推荐

订阅评论
提醒
guest
0 评论
内联反馈
查看所有评论
0
希望看到您的想法,请您发表评论x