document/TranslateProject
2
0
Fork 0
mirror of https://github.com/LCTT/TranslateProject.git synced 2025-01-13 22:30:37 +08:00
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #25698 from wxy/20220428-Why-use-Apache-Druid-for-your-open-source-analytics-database

Browse Source 
RP:published/20220428 Why use Apache Druid for your open source analytics database.md
This commit is contained in:
Xingyu.Wang 2022-05-18 15:56:00 +08:00 committed by GitHub
commit 57db3901a3
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 13 additions and 15 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

28
translated/tech/20220428 Why use Apache Druid for your open source analytics database.md → published/20220428 Why use Apache Druid for your open source analytics database.md
View File

@ -3,21 +3,20 @@
[#]: author: "David Wang https://opensource.com/users/davidwang"
[#]: collector: "lkxed"
[#]: translator: "unigeorge"
[#]: reviewer: " "
[#]: publisher: " "
[#]: url: " "
[#]: reviewer: "wxy"
[#]: publisher: "wxy"
[#]: url: "https://linux.cn/article-14608-1.html"
开源分析数据库 Apache Druid 的推荐理由
为什么推荐开源分析数据库 Apache Druid
======
对用户而言，优秀的对外数据分析工具不可多得，因此选择合适的数据架构就显得尤为重要。
![metrics and data shown on a computer screen][1]
> 对用户而言，优秀的对外数据分析工具非常关键，因此选择合适的数据架构就显得尤为重要。
(Image by: Opensource.com)
![](https://img.linux.net.cn/data/attachment/album/202205/18/154417bvakcquzn2ahv4ua.jpg)
现如今，数据分析不再是仅面向内部开发人员。当为业务方构建数据分析系统时，你需要确认哪种数据库后端是最合适的。
程序员的本能可能是“选用自己了解的数据库（例如 PostgreSQL 或 [MySQL][2]）”。诚然，数据仓库可能会扩展到其核心 BI 仪表板和报告之外的功能，不过对业务方的数据分析支持仍是其重要功能之一，因此要选择合适的工具来保证此功能的性能。
程序员的本能可能是“选用自己了解的数据库（例如 PostgreSQL 或 [MySQL][2]）”。数据仓库也可能会扩展核心的 BI 仪表板和报告之外的功能，不过对业务方的数据分析支持仍是其重要功能之一，因此要选择合适的工具来保证此功能的性能。
问题的关键点在于用户体验，以下是对外支持数据分析工作的一些关键技术讨论点（以 Apache Druid 为例）。
@ -25,12 +24,11 @@
一直在队列中等待查询会让人很恼火。与延迟有关的因素包括数据量、数据库的处理能力、用户和 API 调用的数量，以及数据库支持查询应用的能力。
当数据量比较大时，有一些方法可以基于任意在线分析处理 (OLAP) 数据库构建交互式数据体验，但或多或少都有一些其他方面的牺牲。预计算查询会对性能要求较高，还会使架构变得僵化。预聚合处理会使数据粒度变大。将数据时间限制在近期的处理方式，会使得数据完整性得不到保证。
当数据量比较大时，有一些方法可以基于任意在线分析处理（OLAP）数据库构建交互式数据体验，但或多或少都有一些其他方面的牺牲。预计算查询会对性能要求较高，还会使架构变得僵化。预聚合处理会使数据粒度变大。将数据时间限制在近期的处理方式，会使得数据完整性得不到保证。
“不妥协”的解决方案是选择专为大规模交互而构建的优化架构和数据格式，[Apache Druid][3] 正是这样一个旨在支持现代分析程序的实时数据库。
一个“不妥协”的解决方案是选择专为大规模交互而构建的优化架构和数据格式，[Apache Druid][3] 正是这样一个旨在支持现代分析程序的实时数据库。
* 首先，Druid 具备特有的分布式弹性架构，可将数据从共享数据层预取到近乎无限容量的数据服务器集群中。这种架构与诸如云数据仓库这样的解耦查询引擎相比，具有更快的性能，因为它不需要移动数据，并且比像 PostgreSQL 和 MySQL 这样的纵向扩展数据库具有更高的可扩展性。
* 其次，Druid 采用内置于数据格式中的自动多级索引来驱动每个内核去支持更多查询操作。在常规 OLAP 列格式基础之上，还增加了全局索引、数据字典和位图索引，这可以最大化利用 CPU 周期，加快处理速度。
### 高可用性
@ -41,11 +39,11 @@
考虑弹性就需要考虑设计标准。节点或集群范围的故障能完全避免吗？丢失数据的后果有多严重？保障应用程序和数据需要涉及哪些工作？
关于服务器故障，保证弹性的常规方法是多节点服务以及[备份机制][4]。但如果你是为客户构建应用程序，则对数据丢失的敏感性要高得多。*间断性*备份并不能完全解决这一问题。
关于服务器故障，保证弹性的常规方法是多节点服务以及 [备份机制][4]。但如果你是为客户构建应用程序，则对数据丢失的敏感性要高得多。*偶尔的*备份并不能完全解决这一问题。
Apache Druid 的核心架构内置了该问题的解决方案，本质是一种强大而简单的弹性方法，旨在保证承受任何变故都不会丢失数据（即使是刚刚发生的事件）。
Druid 基于对象存储中共享数据的自动、多级复制实现高可用性 (HA) 和持久性。它实现了用户期望的 HA 特性以及持续备份机制，即使整个集群出现问题，也可以自动保护和恢复数据库的最新状态。
Druid 基于对象存储中共享数据的自动、多级复制实现高可用性（HA）和持久性。它实现了用户期望的 HA 特性以及持续备份机制，即使整个集群出现问题，也可以自动保护和恢复数据库的最新状态。
### 多用户
@ -63,7 +61,7 @@ Druid 基于对象存储中共享数据的自动、多级复制实现高可用
分析应用程序对于用户而言至关重要，所以要构建正确的数据架构。
你肯定不想一开始就选择了一个错误的数据库，然后在后续扩展时面对诸多令人头疼的问题。幸运的是，Apache Druid 可以从小规模开始，并在之后轻松扩展以支持任何可以想象的应用程序。Apache Druid 有[优秀的官方文档][5]，当然它是开源的，所以不妨尝试一下并，快速上手吧。
你肯定不想一开始就选择了一个错误的数据库，然后在后续扩展时面对诸多令人头疼的问题。幸运的是，Apache Druid 可以从小规模开始，并在之后轻松扩展以支持任何可以想象的应用程序。Apache Druid 有 [优秀的官方文档][5]，当然它是开源的，所以不妨尝试一下并，快速上手吧。
--------------------------------------------------------------------------------
@ -72,7 +70,7 @@ via: https://opensource.com/article/22/4/apache-druid-open-source-analytics
作者：[David Wang][a]
选题：[lkxed][b]
译者：[unigeorge](https://github.com/unigeorge)
校对：[校对者ID](https://github.com/校对者ID)
校对：[wxy](https://github.com/wxy)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出