druid-docs-cn/design/index.md

Druid 介绍

本页面对 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 使用 Roaring 或 CONCISE 来压缩 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 表中的数据，如区域，销售代表，产品等。