diff --git a/GettingStarted/Docker.md b/GettingStarted/Docker.md new file mode 100644 index 0000000..9285881 --- /dev/null +++ b/GettingStarted/Docker.md @@ -0,0 +1,63 @@ + + + + + + +## Docker + +在这个部分中，我们将从 [Docker Hub](https://hub.docker.com/r/apache/druid) 下载Apache Druid镜像，并使用 [Docker](https://www.docker.com/get-started) 和 [Docker Compose](https://docs.docker.com/compose/) 在一台机器上安装它。完成此初始设置后，集群将准备好加载数据。 + +在开始快速启动之前，阅读 [Druid概述](chapter-1.md) 和 [摄取概述](../DataIngestion/ingestion.md) 是很有帮助的，因为教程将参考这些页面上讨论的概念。此外，建议熟悉Docker。 + +### 前提条件 + +* Docker + +### 快速开始 + +Druid源代码包含一个 [示例docker-compose.yml](https://github.com/apache/druid/blob/master/distribution/docker/docker-compose.yml) 它可以从Docker Hub中提取一个镜像，适合用作示例环境，并用于试验基于Docker的Druid配置和部署。 + +#### Compose文件 + +示例 `docker-compose.yml` 将为每个Druid服务创建一个容器，包括Zookeeper和作为元数据存储PostgreSQL容器。深度存储将是本地目录，默认配置为相对于 `docker-compose.yml`文件的 `./storage`，并将作为 `/opt/data` 挂载，并在需要访问深层存储的Druid容器之间共享。Druid容器是通过 [环境文件](https://github.com/apache/druid/blob/master/distribution/docker/environment) 配置的。 + +#### 配置 + +Druid Docker容器的配置是通过环境变量完成的，环境变量还可以指定到 [标准Druid配置文件](../Configuration/configuration.md) 的路径 + +特殊环境变量： + +* `JAVA_OPTS` -- 设置 java options +* `DRUID_LOG4J` -- 设置完成的 `log4j.xml` +* `DRUID_LOG_LEVEL` -- 覆盖在log4j中的默认日志级别 +* `DRUID_XMX` -- 设置 Java `Xmx` +* `DRUID_XMS` -- 设置 Java `Xms` +* `DRUID_MAXNEWSIZE` -- 设置 Java最大新生代大小 +* `DRUID_NEWSIZE` -- 设置 Java 新生代大小 +* `DRUID_MAXDIRECTMEMORYSIZE` -- 设置Java最大直接内存大小 +* `DRUID_CONFIG_COMMON` -- druid "common"属性文件的完整路径 +* `DRUID_CONFIG_${service}` -- druid "service"属性文件的完整路径 + +除了特殊的环境变量外，在容器中启动Druid的脚本还将尝试使用以 `druid_`前缀开头的任何环境变量作为命令行配置。例如，Druid容器进程中的环境变量`druid_metadata_storage_type=postgresql` 将被转换为 `-Ddruid.metadata.storage.type=postgresql` + +Druid `docker-compose.yml` 示例使用单个环境文件来指定完整的Druid配置；但是，在生产用例中，我们建议使用 `DRUID_COMMON_CONFIG` 和`DRUID_CONFIG_${service}` 或专门定制的特定于服务的环境文件。 + +### 启动集群 + +运行 `docker-compose up` 启动附加shell的集群，或运行 `docker-compose up -d` 在后台运行集群。如果直接使用示例文件，这个命令应该从Druid安装目录中的 `distribution/docker/` 运行。 + +启动集群后，可以导航到 [http://localhost:8888](http://localhost/) 。服务于 [Druid控制台](../Operations/druid-console.md) 的 [Druid路由进程](../Design/Router.md) 位于这个地址。 + +![](img/tutorial-quickstart-01.png) + +所有Druid进程需要几秒钟才能完全启动。如果在启动服务后立即打开控制台，可能会看到一些可以安全忽略的错误。 + +从这里你可以跟着 [标准教程](chapter-2.md)，或者详细说明你的 `docker-compose.yml` 根据需要添加任何其他外部服务依赖项。 \ No newline at end of file diff --git a/GettingStarted/chapter-1.md b/GettingStarted/chapter-1.md new file mode 100644 index 0000000..26d0ceb --- /dev/null +++ b/GettingStarted/chapter-1.md @@ -0,0 +1,60 @@ + + + + + + +### Druid是什么 + +Apache Druid是一个实时分析型数据库，旨在对大型数据集进行快速的查询分析（"[OLAP](https://en.wikipedia.org/wiki/Online_analytical_processing)"查询)。Druid最常被当做数据库来用以支持实时摄取、高性能查询和高稳定运行的应用场景，同时，Druid也通常被用来助力分析型应用的图形化界面，或者当做需要快速聚合的高并发后端API，Druid最适合应用于面向事件类型的数据。 + +Druid通常应用于以下场景： + +* 点击流分析（Web端和移动端） +* 网络监测分析（网络性能监控） +* 服务指标存储 +* 供应链分析（制造类指标） +* 应用性能指标分析 +* 数字广告分析 +* 商务智能 / OLAP + +Druid的核心架构吸收和结合了[数据仓库](https://en.wikipedia.org/wiki/Data_warehouse)、[时序数据库](https://en.wikipedia.org/wiki/Time_series_database)以及[检索系统](https://en.wikipedia.org/wiki/Search_engine_(computing))的优势，其主要特征如下： + +1. **列式存储**，Druid使用列式存储，这意味着在一个特定的数据查询中它只需要查询特定的列，这样极地提高了部分列查询场景的性能。另外，每一列数据都针对特定数据类型做了优化存储，从而支持快速的扫描和聚合。 +2. **可扩展的分布式系统**，Druid通常部署在数十到数百台服务器的集群中，并且可以提供每秒数百万条记录的接收速率，数万亿条记录的保留存储以及亚秒级到几秒的查询延迟。 +3. **大规模并行处理**，Druid可以在整个集群中并行处理查询。 +4. **实时或批量摄取**，Druid可以实时（已经被摄取的数据可立即用于查询）或批量摄取数据。 +5. **自修复、自平衡、易于操作**，作为集群运维操作人员，要伸缩集群只需添加或删除服务，集群就会在后台自动重新平衡自身，而不会造成任何停机。如果任何一台Druid服务器发生故障，系统将自动绕过损坏。 Druid设计为7*24全天候运行，无需出于任何原因而导致计划内停机，包括配置更改和软件更新。 +6. **不会丢失数据的云原生容错架构**，一旦Druid摄取了数据，副本就安全地存储在[深度存储介质](Design/../chapter-1.md)（通常是云存储，HDFS或共享文件系统）中。即使某个Druid服务发生故障，也可以从深度存储中恢复您的数据。对于仅影响少数Druid服务的有限故障，副本可确保在系统恢复时仍然可以进行查询。 +7. **用于快速过滤的索引**，Druid使用[CONCISE](https://arxiv.org/pdf/1004.0403.pdf)或[Roaring](https://roaringbitmap.org/)压缩的位图索引来创建索引，以支持快速过滤和跨多列搜索。 +8. **基于时间的分区**，Druid首先按时间对数据进行分区，另外同时可以根据其他字段进行分区。这意味着基于时间的查询将仅访问与查询时间范围匹配的分区，这将大大提高基于时间的数据的性能。 +9. **近似算法**，Druid应用了近似count-distinct，近似排序以及近似直方图和分位数计算的算法。这些算法占用有限的内存使用量，通常比精确计算要快得多。对于精度要求比速度更重要的场景，Druid还提供了精确count-distinct和精确排序。 +10. **摄取时自动汇总聚合**，Druid支持在数据摄取阶段可选地进行数据汇总，这种汇总会部分预先聚合您的数据，并可以节省大量成本并提高性能。 + +### 什么场景下应该使用Druid + +许多公司都已经将Druid应用于多种不同的应用场景，详情可查看[Powered by Apache Druid](https://druid.apache.org/druid-powered)页面。 + +如果您的使用场景符合以下的几个特征，那么Druid是一个非常不错的选择： + +* 数据插入频率比较高，但较少更新数据 +* 大多数查询场景为聚合查询和分组查询（GroupBy），同时还有一定得检索与扫描查询 +* 将数据查询延迟目标定位100毫秒到几秒钟之间 +* 数据具有时间属性（Druid针对时间做了优化和设计） +* 在多表场景下，每次查询仅命中一个大的分布式表，查询又可能命中多个较小的lookup表 +* 场景中包含高基维度数据列（例如URL，用户ID等），并且需要对其进行快速计数和排序 +* 需要从Kafka、HDFS、对象存储（如Amazon S3）中加载数据 + +如果您的使用场景符合以下特征，那么使用Druid可能是一个不好的选择： + +* 根据主键对现有数据进行低延迟更新操作。Druid支持流式插入，但不支持流式更新（更新操作是通过后台批处理作业完成） +* 延迟不重要的离线数据系统 +* 场景中包括大连接（将一个大事实表连接到另一个大事实表），并且可以接受花费很长时间来完成这些查询 + diff --git a/GettingStarted/chapter-2.md b/GettingStarted/chapter-2.md new file mode 100644 index 0000000..053e536 --- /dev/null +++ b/GettingStarted/chapter-2.md @@ -0,0 +1,163 @@ + + + + + +### 快速开始 + +在本快速入门教程中，我们将下载Druid并将其安装在一台服务器上，完成初始安装后，向集群中加载数据。 + +在开始快速入门之前，阅读[Druid概述](./chapter-1.md)和[数据摄取概述](../DataIngestion/index.md)会很有帮助，因为当前教程会引用这些页面上讨论的概念。 + +#### 预备条件 +##### 软件 +* **Java 8(8u92+)** +* Linux, Mac OS X, 或者其他类UNIX系统（Windows不支持） + +> [!WARNING] +> Druid服务运行依赖Java 8，可以使用环境变量`DRUID_JAVA_HOME`或`JAVA_HOME`指定在何处查找Java,有关更多详细信息，请运行`verify-java`脚本。 + +##### 硬件 + +Druid安装包提供了几个[单服务器配置](./chapter-3.md)的示例，以及使用这些配置启动Druid进程的脚本。 + +如果您正在使用便携式等小型计算机上运行服务，则配置为4CPU/16GB RAM环境的`micro-quickstart`配置是一个不错的选择。 + +如果您打算在本教程之外使用单机部署进行进一步试验评估，则建议使用比`micro-quickstart`更大的配置。 + +#### 入门开始 + +[下载](https://www.apache.org/dyn/closer.cgi?path=/druid/0.17.0/apache-druid-0.17.0-bin.tar.gz)Druid最新0.17.0release安装包 + +在终端中运行以下命令来提取Druid + +```json +tar -xzf apache-druid-0.17.0-bin.tar.gz +cd apache-druid-0.17.0 +``` + +在安装包中有以下文件： + +* `LICENSE`和`NOTICE`文件 +* `bin/*` - 启停等脚本 +* `conf/*` - 用于单节点部署和集群部署的示例配置 +* `extensions/*` - Druid核心扩展 +* `hadoop-dependencies/*` - Druid Hadoop依赖 +* `lib/*` - Druid核心库和依赖 +* `quickstart/*` - 配置文件，样例数据，以及快速入门教材的其他文件 + +#### 启动服务 + +以下命令假定您使用的是`micro-quickstart`单机配置，如果使用的是其他配置，在`bin`目录下有每一种配置对应的脚本，如`bin/start-single-server-small` + +在`apache-druid-0.17.0`安装包的根目录下执行命令： + +```json +./bin/start-micro-quickstart +``` +然后将在本地计算机上启动Zookeeper和Druid服务实例，例如： + +```json +$ ./bin/start-micro-quickstart +[Fri May 3 11:40:50 2019] Running command[zk], logging to[/apache-druid-0.17.0/var/sv/zk.log]: bin/run-zk conf +[Fri May 3 11:40:50 2019] Running command[coordinator-overlord], logging to[/apache-druid-0.17.0/var/sv/coordinator-overlord.log]: bin/run-druid coordinator-overlord conf/druid/single-server/micro-quickstart +[Fri May 3 11:40:50 2019] Running command[broker], logging to[/apache-druid-0.17.0/var/sv/broker.log]: bin/run-druid broker conf/druid/single-server/micro-quickstart +[Fri May 3 11:40:50 2019] Running command[router], logging to[/apache-druid-0.17.0/var/sv/router.log]: bin/run-druid router conf/druid/single-server/micro-quickstart +[Fri May 3 11:40:50 2019] Running command[historical], logging to[/apache-druid-0.17.0/var/sv/historical.log]: bin/run-druid historical conf/druid/single-server/micro-quickstart +[Fri May 3 11:40:50 2019] Running command[middleManager], logging to[/apache-druid-0.17.0/var/sv/middleManager.log]: bin/run-druid middleManager conf/druid/single-server/micro-quickstart +``` + +所有的状态（例如集群元数据存储和服务的segment文件）将保留在`apache-druid-0.17.0`软件包根目录下的`var`目录中, 服务的日志位于 `var/sv`。 + +稍后，如果您想停止服务，请按`CTRL-C`退出`bin/start-micro-quickstart`脚本，该脚本将终止Druid进程。 + +集群启动后，可以访问[http://localhost:8888](http://localhost:8888)来Druid控制台，控制台由Druid Router进程启动。 + +![tutorial-quickstart](img/tutorial-quickstart-01.png) + +所有Druid进程完全启动需要花费几秒钟。 如果在启动服务后立即打开控制台，则可能会看到一些可以安全忽略的错误。 + +#### 加载数据 +##### 教程使用的数据集 + +对于以下数据加载教程，我们提供了一个示例数据文件，其中包含2015年9月12日发生的Wikipedia页面编辑事件。 + +该样本数据位于Druid包根目录的`quickstart/tutorial/wikiticker-2015-09-12-sampled.json.gz`中,页面编辑事件作为JSON对象存储在文本文件中。 + +示例数据包含以下几列，示例事件如下所示： + +* added +* channel +* cityName +* comment +* countryIsoCode +* countryName +* deleted +* delta +* isAnonymous +* isMinor +* isNew +* isRobot +* isUnpatrolled +* metroCode +* namespace +* page +* regionIsoCode +* regionName +* user + +```json +{ + "timestamp":"2015-09-12T20:03:45.018Z", + "channel":"#en.wikipedia", + "namespace":"Main", + "page":"Spider-Man's powers and equipment", + "user":"foobar", + "comment":"/* Artificial web-shooters */", + "cityName":"New York", + "regionName":"New York", + "regionIsoCode":"NY", + "countryName":"United States", + "countryIsoCode":"US", + "isAnonymous":false, + "isNew":false, + "isMinor":false, + "isRobot":false, + "isUnpatrolled":false, + "added":99, + "delta":99, + "deleted":0, +} +``` + +##### 数据加载 + +以下教程演示了将数据加载到Druid的各种方法，包括批处理和流处理用例。 所有教程均假定您使用的是上面提到的`micro-quickstart`单机配置。 + +* [加载本地文件](../Tutorials/chapter-1.md) - 本教程演示了如何使用Druid的本地批处理摄取来执行批文件加载 +* [从Kafka加载流数据](../Tutorials/chapter-2.md) - 本教程演示了如何从Kafka主题加载流数据 +* [从Hadoop加载数据](../Tutorials/chapter-3.md) - 本教程演示了如何使用远程Hadoop集群执行批处理文件加载 +* [编写一个自己的数据摄取规范](../Tutorials/chapter-10.md) - 本教程演示了如何编写新的数据摄取规范并使用它来加载数据 + +##### 重置集群状态 + +如果要在清理服务后重新启动，请删除`var`目录，然后再次运行`bin/start-micro-quickstart`脚本。 + +一旦每个服务都启动，您就可以加载数据了。 + +##### 重置Kafka + +如果您完成了[教程：从Kafka加载流数据](../Tutorials/chapter-2.md)并希望重置集群状态，则还应该清除所有Kafka状态。 + +在停止ZooKeeper和Druid服务之前，使用`CTRL-C`关闭`Kafka Broker`，然后删除`/tmp/kafka-logs`中的Kafka日志目录： + +``` +rm -rf /tmp/kafka-logs +``` diff --git a/GettingStarted/chapter-3.md b/GettingStarted/chapter-3.md new file mode 100644 index 0000000..a232c9e --- /dev/null +++ b/GettingStarted/chapter-3.md @@ -0,0 +1,69 @@ + + + + + + +### 单服务器部署 + +Druid包括一组参考配置和用于单机部署的启动脚本： + +* `nano-quickstart` +* `micro-quickstart` +* `small` +* `medium` +* `large` +* `large` +* `xlarge` + +`micro-quickstart`适合于笔记本电脑等小型机器，旨在用于快速评估测试使用场景。 + +`nano-quickstart`是一种甚至更小的配置，目标是具有1个CPU和4GB内存的计算机。它旨在在资源受限的环境（例如小型Docker容器）中进行有限的评估测试。 + +其他配置旨在用于一般用途的单机部署,它们的大小适合大致基于亚马逊i3系列EC2实例的硬件。 + +这些示例配置的启动脚本与Druid服务一起运行单个ZK实例,您也可以选择单独部署ZK。 + +通过[Coordinator配置文档](../Configuration/configuration.md#Coordinator)中描述的可选配置`druid.coordinator.asOverlord.enabled = true`可以在单个进程中同时运行Druid Coordinator和Overlord。 + +虽然为大型单台计算机提供了示例配置，但在更高规模下，我们建议在集群部署中运行Druid，以实现容错和减少资源争用。 + +#### 单服务器参考配置 +##### Nano-Quickstart: 1 CPU, 4GB 内存 + +* 启动命令: `bin/start-nano-quickstart` +* 配置目录: `conf/druid/single-server/nano-quickstart` + +##### Micro-Quickstart: 4 CPU, 16GB 内存 + +* 启动命令: `bin/start-micro-quickstart` +* 配置目录: `conf/druid/single-server/micro-quickstart` + +##### Small: 8 CPU, 64GB 内存 (~i3.2xlarge) + +* 启动命令: `bin/start-small` +* 配置目录: `conf/druid/single-server/small` + +##### Medium: 16 CPU, 128GB 内存 (~i3.4xlarge) + +* 启动命令: `bin/start-medium` +* 配置目录: `conf/druid/single-server/medium` + +##### Large: 32 CPU, 256GB 内存 (~i3.8xlarge) + +* 启动命令: `bin/start-large` +* 配置目录: `conf/druid/single-server/large` + +##### X-Large: 64 CPU, 512GB 内存 (~i3.16xlarge) + +* 启动命令: `bin/start-xlarge` +* 配置目录: `conf/druid/single-server/xlarge` + +--- \ No newline at end of file diff --git a/GettingStarted/chapter-4.md b/GettingStarted/chapter-4.md new file mode 100644 index 0000000..597c3b5 --- /dev/null +++ b/GettingStarted/chapter-4.md @@ -0,0 +1,421 @@ + + + + + + +## 集群部署 + +Apache Druid旨在作为可伸缩的容错集群进行部署。 + +在本文档中，我们将安装一个简单的集群，并讨论如何对其进行进一步配置以满足您的需求。 + +这个简单的集群将具有以下特点： +* 一个Master服务同时起Coordinator和Overlord进程 +* 两个可伸缩、容错的Data服务来运行Historical和MiddleManager进程 +* 一个Query服务，运行Druid Broker和Router进程 + +在生产中，我们建议根据您的特定容错需求部署多个Master服务器和多个Query服务器，但是您可以使用一台Master服务器和一台Query服务器将服务快速运行起来，然后再添加更多服务器。 +### 选择硬件 +#### 首次部署 + +如果您现在没有Druid集群，并打算首次以集群模式部署运行Druid，则本指南提供了一个包含预先配置的集群部署示例。 + +##### Master服务 + +Coordinator进程和Overlord进程负责处理集群的元数据和协调需求，它们可以运行在同一台服务器上。 + +在本示例中，我们将在等效于AWS[m5.2xlarge](https://aws.amazon.com/ec2/instance-types/m5/)实例的硬件环境上部署。 + +硬件规格为： + +* 8核CPU +* 31GB内存 + +可以在`conf/druid/cluster/master`下找到适用于此硬件规格的Master示例服务配置。 + +##### Data服务 + +Historical和MiddleManager可以分配在同一台服务器上运行，以处理集群中的实际数据，这两个服务受益于CPU、内存和固态硬盘。 + +在本示例中，我们将在等效于AWS[i3.4xlarge](https://aws.amazon.com/cn/ec2/instance-types/i3/)实例的硬件环境上部署。 + +硬件规格为： +* 16核CPU +* 122GB内存 +* 2 * 1.9TB 固态硬盘 + +可以在`conf/druid/cluster/data`下找到适用于此硬件规格的Data示例服务配置。 + +##### Query服务 + +Druid Broker服务接收查询请求，并将其转发到集群中的其他部分，同时其可以可选的配置内存缓存。 Broker服务受益于CPU和内存。 + +在本示例中，我们将在等效于AWS[m5.2xlarge](https://aws.amazon.com/ec2/instance-types/m5/)实例的硬件环境上部署。 + +硬件规格为： + +* 8核CPU +* 31GB内存 + +您可以考虑将所有的其他开源UI工具或者查询依赖等与Broker服务部署在同一台服务器上。 + +可以在`conf/druid/cluster/query`下找到适用于此硬件规格的Query示例服务配置。 + +##### 其他硬件配置 + +上面的示例集群是从多种确定Druid集群大小的可能方式中选择的一个示例。 + +您可以根据自己的特定需求和限制选择较小/较大的硬件或较少/更多的服务器。 + +如果您的使用场景具有复杂的扩展要求，则还可以选择不将Druid服务混合部署（例如，独立的Historical Server）。 + +[基本集群调整指南](../Operations/basicClusterTuning.md)中的信息可以帮助您进行决策，并可以调整配置大小。 + +#### 从单服务器环境迁移部署 + +如果您现在已有单服务器部署的环境，例如[单服务器部署示例](./chapter-3.md)中的部署，并且希望迁移到类似规模的集群部署，则以下部分包含一些选择Master/Data/Query服务等效硬件的准则。 + +##### Master服务 + +Master服务的主要考虑点是可用CPU以及用于Coordinator和Overlord进程的堆内存。 + +首先计算出来在单服务器环境下Coordinator和Overlord已分配堆内存之和，然后选择具有足够内存的Master服务硬件，同时还需要考虑到为服务器上其他进程预留一些额外的内存。 + +对于CPU，可以选择接近于单服务器环境核数1/4的硬件。 + +##### Data服务 + +在为集群Data服务选择硬件时，主要考虑可用的CPU和内存，可行时使用SSD存储。 + +在集群化部署时，出于容错的考虑，最好是部署多个Data服务。 + +在选择Data服务的硬件时，可以假定一个分裂因子`N`，将原来的单服务器环境的CPU和内存除以`N`,然后在新集群中部署`N`个硬件规格缩小的Data服务。 + +##### Query服务 + +Query服务的硬件选择主要考虑可用的CPU、Broker服务的堆内和堆外内存、Router服务的堆内存。 + +首先计算出来在单服务器环境下Broker和Router已分配堆内存之和，然后选择可以覆盖Broker和Router内存的Query服务硬件，同时还需要考虑到为服务器上其他进程预留一些额外的内存。 + +对于CPU，可以选择接近于单服务器环境核数1/4的硬件。 + +[基本集群调优指南](../Operations/basicClusterTuning.md)包含有关如何计算Broker和Router服务内存使用量的信息。 + +### 选择操作系统 + +我们建议运行您喜欢的Linux发行版，同时还需要： + +* **Java 8** + +> [!WARNING] +> Druid服务运行依赖Java 8，可以使用环境变量`DRUID_JAVA_HOME`或`JAVA_HOME`指定在何处查找Java,有关更多详细信息，请运行`verify-java`脚本。 + +### 下载发行版 + +首先，下载并解压缩发布安装包。最好首先在单台计算机上执行此操作，因为您将编辑配置，然后将修改后的配置分发到所有服务器上。 + +[下载](https://www.apache.org/dyn/closer.cgi?path=/druid/0.17.0/apache-druid-0.17.0-bin.tar.gz)Druid最新0.17.0release安装包 + +在终端中运行以下命令来提取Druid + +``` +tar -xzf apache-druid-0.17.0-bin.tar.gz +cd apache-druid-0.17.0 +``` + +在安装包中有以下文件： + +* `LICENSE`和`NOTICE`文件 +* `bin/*` - 启停等脚本 +* `conf/druid/cluster/*` - 用于集群部署的模板配置 +* `extensions/*` - Druid核心扩展 +* `hadoop-dependencies/*` - Druid Hadoop依赖 +* `lib/*` - Druid核心库和依赖 +* `quickstart/*` - 与[快速入门](./chapter-2.md)相关的文件 + +我们主要是编辑`conf/druid/cluster/`中的文件。 + +#### 从单服务器环境迁移部署 + +在以下各节中，我们将在`conf/druid/cluster`下编辑配置。 + +如果您已经有一个单服务器部署，请将您的现有配置复制到`conf/druid /cluster`以保留您所做的所有配置更改。 + +### 配置元数据存储和深度存储 +#### 从单服务器环境迁移部署 + +如果您已经有一个单服务器部署，并且希望在整个迁移过程中保留数据，请在更新元数据/深层存储配置之前，按照[元数据迁移](../Operations/metadataMigration.md)和[深层存储迁移](../Operations/DeepstorageMigration.md)中的说明进行操作。 + +这些指南针对使用Derby元数据存储和本地深度存储的单服务器部署。 如果您已经在单服务器集群中使用了非Derby元数据存储，则可以在新集群中可以继续使用当前的元数据存储。 + +这些指南还提供了有关从本地深度存储迁移段的信息。集群部署需要分布式深度存储，例如S3或HDFS。 如果单服务器部署已在使用分布式深度存储，则可以在新集群中继续使用当前的深度存储。 + +#### 元数据存储 + +在`conf/druid/cluster/_common/common.runtime.properties`中，使用您将用作元数据存储的服务器地址来替换"metadata.storage.*": + +* `druid.metadata.storage.connector.connectURI` +* `druid.metadata.storage.connector.host` + +在生产部署中，我们建议运行专用的元数据存储，例如具有复制功能的MySQL或PostgreSQL，与Druid服务器分开部署。 + +[MySQL扩展](../Configuration/core-ext/mysql.md)和[PostgreSQL](../Configuration/core-ext/postgresql.md)扩展文档包含有关扩展配置和初始数据库安装的说明。 + +#### 深度存储 + +Druid依赖于分布式文件系统或大对象（blob）存储来存储数据，最常用的深度存储实现是S3（适合于在AWS上）和HDFS（适合于已有Hadoop集群）。 + +##### S3 + +在`conf/druid/cluster/_common/common.runtime.properties`中， + +* 在`druid.extension.loadList`配置项中增加"druid-s3-extensions"扩展 +* 注释掉配置文件中用于本地存储的"Deep Storage"和"Indexing service logs" +* 打开配置文件中关于"For S3"部分中"Deep Storage"和"Indexing service logs"的配置 + +上述操作之后，您将看到以下的变化： + +```json +druid.extensions.loadList=["druid-s3-extensions"] + +#druid.storage.type=local +#druid.storage.storageDirectory=var/druid/segments + +druid.storage.type=s3 +druid.storage.bucket=your-bucket +druid.storage.baseKey=druid/segments +druid.s3.accessKey=... +druid.s3.secretKey=... + +#druid.indexer.logs.type=file +#druid.indexer.logs.directory=var/druid/indexing-logs + +druid.indexer.logs.type=s3 +druid.indexer.logs.s3Bucket=your-bucket +druid.indexer.logs.s3Prefix=druid/indexing-logs +``` +更多信息可以看[S3扩展](../Configuration/core-ext/s3.md)部分的文档。 + +##### HDFS + +在`conf/druid/cluster/_common/common.runtime.properties`中， + +* 在`druid.extension.loadList`配置项中增加"druid-hdfs-storage"扩展 +* 注释掉配置文件中用于本地存储的"Deep Storage"和"Indexing service logs" +* 打开配置文件中关于"For HDFS"部分中"Deep Storage"和"Indexing service logs"的配置 + +上述操作之后，您将看到以下的变化： + +```json +druid.extensions.loadList=["druid-hdfs-storage"] + +#druid.storage.type=local +#druid.storage.storageDirectory=var/druid/segments + +druid.storage.type=hdfs +druid.storage.storageDirectory=/druid/segments + +#druid.indexer.logs.type=file +#druid.indexer.logs.directory=var/druid/indexing-logs + +druid.indexer.logs.type=hdfs +druid.indexer.logs.directory=/druid/indexing-logs +``` + +同时： + +* 需要将Hadoop的配置文件（core-site.xml, hdfs-site.xml, yarn-site.xml, mapred-site.xml）放置在Druid进程的classpath中，可以将他们拷贝到`conf/druid/cluster/_common`目录中 + +更多信息可以看[HDFS扩展](../Configuration/core-ext/hdfs.md)部分的文档。 + +### Hadoop连接配置 + +如果要从Hadoop集群加载数据，那么此时应对Druid做如下配置： + +* 在`conf/druid/cluster/_common/common.runtime.properties`文件中更新`druid.indexer.task.hadoopWorkingPath`配置项，将其更新为您期望的一个用于临时文件存储的HDFS路径。 通常会配置为`druid.indexer.task.hadoopWorkingPath=/tmp/druid-indexing` +* 需要将Hadoop的配置文件（core-site.xml, hdfs-site.xml, yarn-site.xml, mapred-site.xml）放置在Druid进程的classpath中，可以将他们拷贝到`conf/druid/cluster/_common`目录中 + +请注意，您无需为了可以从Hadoop加载数据而使用HDFS深度存储。例如，如果您的集群在Amazon Web Services上运行，即使您使用Hadoop或Elastic MapReduce加载数据，我们也建议使用S3进行深度存储。 + +更多信息可以看[基于Hadoop的数据摄取](../DataIngestion/hadoopbased.md)部分的文档。 + +### Zookeeper连接配置 + +在生产集群中，我们建议使用专用的ZK集群，该集群与Druid服务器分开部署。 + +在 `conf/druid/cluster/_common/common.runtime.properties` 中，将 `druid.zk.service.host` 设置为包含用逗号分隔的host：port对列表的连接字符串，每个对与ZK中的ZooKeeper服务器相对应。（例如" 127.0.0.1:4545"或"127.0.0.1:3000,127.0.0.1:3001、127.0.0.1:3002"） + +您也可以选择在Master服务上运行ZK，而不使用专用的ZK集群。如果这样做，我们建议部署3个Master服务，以便您具有ZK仲裁。 + +### 配置调整 +#### 从单服务器环境迁移部署 +##### Master服务 + +如果您使用的是[单服务器部署示例](./chapter-3.md)中的示例配置，则这些示例中将Coordinator和Overlord进程合并为一个合并的进程。 + +`conf/druid/cluster/master/coordinator-overlord` 下的示例配置同样合并了Coordinator和Overlord进程。 + +您可以将现有的 `coordinator-overlord` 配置从单服务器部署复制到`conf/druid/cluster/master/coordinator-overlord` + +##### Data服务 + +假设我们正在从一个32CPU和256GB内存的单服务器部署环境进行迁移，在老的环境中，Historical和MiddleManager使用了如下的配置： + +Historical（单服务器） + +```json +druid.processing.buffer.sizeBytes=500000000 +druid.processing.numMergeBuffers=8 +druid.processing.numThreads=31 +``` + +MiddleManager（单服务器） + +```json +druid.worker.capacity=8 +druid.indexer.fork.property.druid.processing.numMergeBuffers=2 +druid.indexer.fork.property.druid.processing.buffer.sizeBytes=100000000 +druid.indexer.fork.property.druid.processing.numThreads=1 +``` + +在集群部署中，我们选择一个分裂因子（假设为2），则部署2个16CPU和128GB内存的Data服务，各项的调整如下： + +Historical + +* `druid.processing.numThreads`设置为新硬件的（`CPU核数 - 1`） +* `druid.processing.numMergeBuffers` 使用分裂因子去除单服务部署环境的值 +* `druid.processing.buffer.sizeBytes` 该值保持不变 + +MiddleManager: + +* `druid.worker.capacity`: 使用分裂因子去除单服务部署环境的值 +* `druid.indexer.fork.property.druid.processing.numMergeBuffers`: 该值保持不变 +* `druid.indexer.fork.property.druid.processing.buffer.sizeBytes`: 该值保持不变 +* `druid.indexer.fork.property.druid.processing.numThreads`: 该值保持不变 + +调整后的结果配置如下： + +新的Historical(2 Data服务器) + +```json + druid.processing.buffer.sizeBytes=500000000 + druid.processing.numMergeBuffers=8 + druid.processing.numThreads=31 + ``` + +新的MiddleManager（2 Data服务器） + +```json +druid.worker.capacity=4 +druid.indexer.fork.property.druid.processing.numMergeBuffers=2 +druid.indexer.fork.property.druid.processing.buffer.sizeBytes=100000000 +druid.indexer.fork.property.druid.processing.numThreads=1 +``` + +##### Query服务 + +您可以将现有的Broker和Router配置复制到`conf/druid/cluster/query`下的目录中，无需进行任何修改. + +#### 首次部署 + +如果您正在使用如下描述的示例集群规格： + +* 1 Master 服务器(m5.2xlarge) +* 2 Data 服务器(i3.4xlarge) +* 1 Query 服务器(m5.2xlarge) + +`conf/druid/cluster`下的配置已经为此硬件确定了，一般情况下您无需做进一步的修改。 + +如果您选择了其他硬件，则[基本的集群调整指南](../Operations/basicClusterTuning.md)可以帮助您调整配置大小。 + +### 开启端口(如果使用了防火墙) + +如果您正在使用防火墙或其他仅允许特定端口上流量准入的系统，请在以下端口上允许入站连接： + +#### Master服务 + +* 1527（Derby元数据存储，如果您正在使用一个像MySQL或者PostgreSQL的分离的元数据存储则不需要） +* 2181（Zookeeper，如果使用了独立的ZK集群则不需要） +* 8081（Coordinator） +* 8090（Overlord） + +#### Data服务 + +* 8083（Historical） +* 8091，8100-8199（Druid MiddleManager，如果`druid.worker.capacity`参数设置较大的话，则需要更多高于8199的端口） + +#### Query服务 + +* 8082（Broker） +* 8088（Router，如果使用了） + +> [!WARNING] +> 在生产中，我们建议将ZooKeeper和元数据存储部署在其专用硬件上，而不是在Master服务器上。 + +### 启动Master服务 + +将Druid发行版和您编辑的配置文件复制到Master服务器上。 + +如果您一直在本地计算机上编辑配置，则可以使用rsync复制它们： + +```json +rsync -az apache-druid-0.17.0/ MASTER_SERVER:apache-druid-0.17.0/ +``` + +#### 不带Zookeeper启动 + +在发行版根目录中，运行以下命令以启动Master服务： +```json +bin/start-cluster-master-no-zk-server +``` + +#### 带Zookeeper启动 + +如果计划在Master服务器上运行ZK，请首先更新`conf/zoo.cfg`以标识您计划如何运行ZK，然后，您可以使用以下命令与ZK一起启动Master服务进程： +```json +bin/start-cluster-master-with-zk-server +``` + +> [!WARNING] +> 在生产中，我们建议将ZooKeeper运行在其专用硬件上。 + +### 启动Data服务 + +将Druid发行版和您编辑的配置文件复制到您的Data服务器。 + +在发行版根目录中，运行以下命令以启动Data服务： +```json +bin/start-cluster-data-server +``` + +您可以在需要的时候增加更多的Data服务器。 + +> [!WARNING] +> 对于具有复杂资源分配需求的集群，您可以将Historical和MiddleManager分开部署，并分别扩容组件。这也使您能够利用Druid的内置MiddleManager自动伸缩功能。 + +### 启动Query服务 +将Druid发行版和您编辑的配置文件复制到您的Query服务器。 + +在发行版根目录中，运行以下命令以启动Query服务： + +```json +bin/start-cluster-query-server +``` + +您可以根据查询负载添加更多查询服务器。 如果增加了查询服务器的数量，请确保按照[基本集群调优指南](../Operations/basicClusterTuning.md)中的说明调整Historical和Task上的连接池。 + +### 加载数据 + +恭喜，您现在有了Druid集群！下一步是根据使用场景来了解将数据加载到Druid的推荐方法。 + +了解有关[加载数据](../DataIngestion/index.md)的更多信息。 + + diff --git a/GettingStarted/img/tutorial-quickstart-01.png b/GettingStarted/img/tutorial-quickstart-01.png new file mode 100644 index 0000000..d6ee11b Binary files /dev/null and b/GettingStarted/img/tutorial-quickstart-01.png differ diff --git a/design/index.md b/design/index.md index d803a70..64fdba5 100644 --- a/design/index.md +++ b/design/index.md @@ -1,28 +1,7 @@ ---- -id: index -title: "Introduction to Apache Druid" ---- +# Druid 介绍 +本页面对 Druid 的基本情况进行了一些介绍和简要说明。 - - -## What is Druid? +## 什么是 Druid Apache Druid is a real-time analytics database designed for fast slice-and-dice analytics ("[OLAP](http://en.wikipedia.org/wiki/Online_analytical_processing)" queries) on large data sets. Druid is most often @@ -74,27 +53,69 @@ offers exact count-distinct and exact ranking. 10. **Automatic summarization at ingest time.** Druid optionally supports data summarization at ingestion time. This summarization partially pre-aggregates your data, and can lead to big costs savings and performance boosts. -## When should I use Druid? -Druid is used by many companies of various sizes for many different use cases. Check out the -[Powered by Apache Druid](/druid-powered) page +Apache Druid是一个实时分析型数据库，旨在对大型数据集进行快速的查询分析（"[OLAP](https://en.wikipedia.org/wiki/Online_analytical_processing)"查询)。Druid最常被当做数据库来用以支持实时摄取、高性能查询和高稳定运行的应用场景，同时，Druid也通常被用来助力分析型应用的图形化界面，或者当做需要快速聚合的高并发后端API，Druid最适合应用于面向事件类型的数据。 -Druid is likely a good choice if your use case fits a few of the following descriptors: +Druid通常应用于以下场景： -- Insert rates are very high, but updates are less common. -- Most of your queries are aggregation and reporting queries ("group by" queries). You may also have searching and -scanning queries. -- You are targeting query latencies of 100ms to a few seconds. -- Your data has a time component (Druid includes optimizations and design choices specifically related to time). -- You may have more than one table, but each query hits just one big distributed table. Queries may potentially hit more -than one smaller "lookup" table. -- You have high cardinality data columns (e.g. URLs, user IDs) and need fast counting and ranking over them. -- You want to load data from Kafka, HDFS, flat files, or object storage like Amazon S3. +* 点击流分析（Web端和移动端） +* 网络监测分析（网络性能监控） +* 服务指标存储 +* 供应链分析（制造类指标） +* 应用性能指标分析 +* 数字广告分析 +* 商务智能 / OLAP -Situations where you would likely _not_ want to use Druid include: +Druid的核心架构吸收和结合了[数据仓库](https://en.wikipedia.org/wiki/Data_warehouse)、[时序数据库](https://en.wikipedia.org/wiki/Time_series_database)以及[检索系统](https://en.wikipedia.org/wiki/Search_engine_(computing))的优势，其主要特征如下： -- You need low-latency updates of _existing_ records using a primary key. Druid supports streaming inserts, but not streaming updates (updates are done using -background batch jobs). -- You are building an offline reporting system where query latency is not very important. -- You want to do "big" joins (joining one big fact table to another big fact table) and you are okay with these queries -taking a long time to complete. +1. **列式存储**，Druid使用列式存储，这意味着在一个特定的数据查询中它只需要查询特定的列，这样极地提高了部分列查询场景的性能。另外，每一列数据都针对特定数据类型做了优化存储，从而支持快速的扫描和聚合。 +2. **可扩展的分布式系统**，Druid通常部署在数十到数百台服务器的集群中，并且可以提供每秒数百万条记录的接收速率，数万亿条记录的保留存储以及亚秒级到几秒的查询延迟。 +3. **大规模并行处理**，Druid可以在整个集群中并行处理查询。 +4. **实时或批量摄取**，Druid可以实时（已经被摄取的数据可立即用于查询）或批量摄取数据。 +5. **自修复、自平衡、易于操作**，作为集群运维操作人员，要伸缩集群只需添加或删除服务，集群就会在后台自动重新平衡自身，而不会造成任何停机。如果任何一台Druid服务器发生故障，系统将自动绕过损坏。 Druid设计为7*24全天候运行，无需出于任何原因而导致计划内停机，包括配置更改和软件更新。 +6. **不会丢失数据的云原生容错架构**，一旦Druid摄取了数据，副本就安全地存储在[深度存储介质](Design/../chapter-1.md)（通常是云存储，HDFS或共享文件系统）中。即使某个Druid服务发生故障，也可以从深度存储中恢复您的数据。对于仅影响少数Druid服务的有限故障，副本可确保在系统恢复时仍然可以进行查询。 +7. **用于快速过滤的索引**，Druid使用[CONCISE](https://arxiv.org/pdf/1004.0403.pdf)或[Roaring](https://roaringbitmap.org/)压缩的位图索引来创建索引，以支持快速过滤和跨多列搜索。 +8. **基于时间的分区**，Druid首先按时间对数据进行分区，另外同时可以根据其他字段进行分区。这意味着基于时间的查询将仅访问与查询时间范围匹配的分区，这将大大提高基于时间的数据的性能。 +9. **近似算法**，Druid应用了近似count-distinct，近似排序以及近似直方图和分位数计算的算法。这些算法占用有限的内存使用量，通常比精确计算要快得多。对于精度要求比速度更重要的场景，Druid还提供了精确count-distinct和精确排序。 +10. **摄取时自动汇总聚合**，Druid支持在数据摄取阶段可选地进行数据汇总，这种汇总会部分预先聚合您的数据，并可以节省大量成本并提高性能。 + + +## 我应该在什么时候使用 Druid + +许多公司都已经将 Druid 应用于多种不同的应用场景。请访问 [使用 Apache Druid 的公司](https://druid.apache.org/druid-powered) 页面来了解都有哪些公司使用了 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 表中的数据，如区域，销售代表，产品等。 \ No newline at end of file