Skip to content

Commit

Permalink
fix typo
Browse files Browse the repository at this point in the history
  • Loading branch information
isno committed Jan 26, 2025
1 parent 05abc9d commit 07e0446
Showing 1 changed file with 16 additions and 32 deletions.
48 changes: 16 additions & 32 deletions Observability/logging.md
Original file line number Diff line number Diff line change
Expand Up @@ -2,10 +2,9 @@

处理日志本来是件稀松平常的事情,但随着数据规模的增长,量变引发质变,高吞吐写入(GB/s)、低成本海量存储(PB 级别)以及亿级数据的实时检索(1 秒内),已成为软件工程领域最具挑战性的难题之一。

本节将从日志存储与分析的角度出发,介绍三种业内应对海量数据处理的方案。

本节将从日志存储与分析的角度出发,介绍业内三种主流的日志处理解决方案。

## 1. 全文索引方案 Elastic Stack
## 1. 全文索引 Elastic Stack

在讨论如何实现完整的日志系统时,ELK、ELKB 或 Elastic Stack 是工程师们耳熟能详的名词。它们实际上指代同一套由 Elastic 公司[^1]开发的开源工具,用于海量数据的收集、搜索、分析和可视化处理。

Expand Down Expand Up @@ -53,7 +52,7 @@ Elasticsearch 的另一项关键技术是“分片”(sharding)。每个分
- **存储空间占用高**:Elasticsearch 不仅存储原始数据和反向索引,为了加速分析能力,可能还额外存储一份列式数据(Column-oriented Data);其次,为了避免单点故障,Elasticsearch 会为每个分片创建一个或多个副本副本(Replica),这导致 Elasticsearch 会占用极大的存储空间。


## 2. 轻量化方案 Loki
## 2. 轻量化 Loki

Grafana Loki 是由 Grafana Labs 开发的一款日志聚合系统,其设计灵感来源于 Prometheus,目标是成为“日志领域的 Prometheus”。与 Elastic Stack 相比,Loki 具有轻量、低成本和与 Kubernetes 高度集成等特点。

Expand All @@ -77,17 +76,11 @@ Loki 的主要特点是,只对日志的元数据(如标签、时间戳)建

不难看出,Loki 通过仅索引元数据、以及索引和块的分离存储设计,让其在处理大规模日志数据时具有明显的成本优势。

## 3. 列式存储数据库 ClickHouse

近几年,在日志处理场景,ClickHouse 一词频繁出现。

ClickHouse 是一个用于 OLAP(On-Line Analytical Processing,在线分析处理)的列式数据库管理系统,由俄罗斯 Yandex [^2]公司在 2008 年开发,并于 2016 年 6 月 开源。
## 3. 列式存储 ClickHouse

ClickHouse 的关键特点是:列式存储、向量化查询执行、高效压缩、实时数据处理、水平扩展、复杂查询(支持 SQL 语法)...。这些特点使 ClickHouse 能够在海量数据(数十亿级别)的规模下,实现基于 SQL 语法查询的秒级响应,因此成为大规模数据分析、实时流式数据查询以及业务数据分析的理想选择
ClickHouse 是由俄罗斯 Yandex 公司[^2]于 2008 年开发的开源列式数据库管理系统。它支持高并发查询,能够高效处理数百亿到数万亿条记录的数据,且具备极快的查询速度,广泛应用于实时数据分析、日志处理、指标监控等领域

一个流行的观点认为:“提升查询速度的最简单有效方法是减少数据扫描范围和数据传输量”。减少数据扫描范围和数据传输量的核心,在于数据是如何被组织和存储的。

先来看传统的行式数据库系统中,数据是如何存储的。如下所示,MySQL、Postgres 这类的数据库按如下方式组织数据。
在大规模数据处理过程中,提升查询速度的最有效方法是减少数据扫描范围,这其中的关键在于数据的组织和存储方式。我们先来看传统的行式数据库是如何存储数据的,以 MySQL 或 PostgreSQL 数据库为例,它们的数据组织如表 9-2 所示,是按行存储的。

<center >表 9-2 行式数据库存储结构</center>

Expand All @@ -98,19 +91,14 @@ ClickHouse 的关键特点是:列式存储、向量化查询执行、高效压
| #2 | 89953706054 | 78 | Mission| 1 | 2016-05-18 07:38:00| |
| #N | ...| ...| ...| ... | ...

在行式数据库中,表的一行数据会在物理存储介质中紧密相邻。如果要执行下面的 SQL 来统计某个产品的销售额,行式数据库需要加载整个表的所有行到内存,进行扫描和过滤(检查是否符合 WHERE 条件)。过滤出目标行后,若有聚合函数(如 SUM、MAX、MIN),还需要进行相应的计算和排序,最后才会过滤掉不必要的列,整个过程可能非常耗时。

行式数据库一张表中的一行内的所有数据在物理介质内是彼此相邻存储的。如果要执行下面的 SQL(统计某个产品的销售额):

```SQL
```SQL
// 统计销售额
SELECT sum(sales) AS count FROMWHERE ProductId=90329509958
```

上述分析类的查询,实际上只需要读取表的一小部分列(sales 列)。

但行式数据库需要将所有行从磁盘加载到内存中,进行扫描和过滤(检查是否符合 where 条件),过滤出目标行之后,再判断是否有聚合函数(如 SUM、MAX、MIN),如有则执行相应的计算和排序,再过滤不需要的列,最终输出结果。整个流程可能需要非常长的时间。


接着看列式数据库系统是如何规避上面的问题。首先,列式数据库按如下方式组织数据。
接下来,我们来看列式数据库,ClickHouse 的数据组织如表 9-3 所示,数据按列而非按行存储。我们继续以上面的统计销售额的 SQL 为例,列式数据库只读取与查询相关的列(如 sales 列),不会读取不相关列,从而减少不必要的磁盘 I/O 操作。

<center >表 9-3 列式数据库存储结构</center>

Expand All @@ -122,15 +110,11 @@ SELECT sum(sales) AS count FROM 表 WHERE ProductId=90329509958
|GoodEvent: | 1| 1| 1| ...|
|CreateTime: | 2016-05-18 05:19:20 |2016-05-18 08:10:20 |2016-05-18 07:38:00 |...|

可以看到,列式存储不是将一行中的所有值存储在一起,而是将每列中的所有值存储在一起。

列式数据库中我们只需读取的数据。如上面统计销售额示例的 SQL,只需读取 sales 列,其他与查询无关的列并不会被读取,从而避免了不必要的磁盘 IO 操作。

此外,列式存储和数据压缩通常是伴生的。

数据压缩的本质是通过一定的步长对数据进行匹配扫描,发现重复部分后进行编码转换。因此,数据中重复项越多,压缩率越高。面向列式的存储,同一列字段的数据具有相同的数据类型和语义,重复项的可能性自然更高。ClickHouse 支持不同的列配置不同的压缩算法。这样,用户可以根据每列的数据特性选择最合适的压缩方式。
此外,列式存储通常与数据压缩伴生。数据压缩的本质是通过一定步长对数据进行匹配扫描,发现重复部分后进行编码转换。面向列式的存储,同一列的数据类型和语义相同,重复项的可能性更高,因此自然有着更高的压缩率。ClickHouse 更进一步的允许用户根据每列数据的特性选择最适合的压缩算法。如下 SQL 示例,创建 MergeTree 类型 example 表,其中:

如下所示,创建一个 MergeTree 类型的 example 表。对 UInt64 列使用了 LZ4 算法(适合快速读取的大量数值数据),对 name 列使用 ZSTD 算法(适合较大的字符串),对 createTime 列使用了 Double-Delta(适合递增或相邻值差异较小的数据)等。
- id 列使用的 LZ4 算法,主要用于需要快速压缩和解压缩的场景。
- name 列使用的 ZSTD 算法,主要用于日志、文本、二进制数据数据,该算法在压缩效率、速度和压缩比之间有良好的平衡。
- createTime 列使用的 Double-Delta 算法,主要用于压缩具有递增或相邻值差异较小的数据,特别适用于时间戳或计数类数据。

```SQL
CREATE TABLE example (
Expand All @@ -143,7 +127,7 @@ CREATE TABLE example (
ORDER BY id;
```

作为一款分布式数据系统,ClickHouse 自然支持分片”(Sharding)技术只要有足够多的硬件资源,ClickHouse 能处理数万亿条记录、PB 级别的数据量。根据 Yandex 内部的基准测试结果来看(图 9-9),ClickHouse 的性能遥遥领先对手,比 Vertica(一款商业 OLAP 软件)快约 5 倍比 Hive 快 279 倍比 InfiniDB 快 31 倍。
作为一款分布式数据系统,ClickHouse 自然支持“分片”(Sharding)技术。ClickHouse 可将海量数据水平切分成多个较小的部分,并分布到多个物理节点。也就是说,只要有足够多的硬件资源,ClickHouse 就能处理数万亿条记录、PB 级别规模的数据量。根据 Yandex 内部的基准测试结果来看(图 9-9),ClickHouse 性能表现遥遥领先对手,比 Vertica(一款商业 OLAP 软件)快约 5 倍比 Hive 快 279 倍比 InfiniDB 快 31 倍。

:::center
![](../assets/ClickHouse-benchmark.jpeg)<br/>
Expand All @@ -152,5 +136,5 @@ ORDER BY id;

正如 ClickHouse 的宣传所言,其他的开源系统太慢,商用的又太贵。只有 ClickHouse 在存储成本与查询性能之间做到了良好平衡,不仅快且还开源。

[^1]: Elastic 公司的发展始于创始人 Shay Banon 的个人兴趣,从开源、聚人、成立公司,到走向纽交所,再到股价一路狂飙(截止 2024 年 7 月 11 日,最新市值 $107 亿),几乎是最理想的工程师创业故事。
[^1]: Elastic 公司的发展始于创始人 Shay Banon 的个人兴趣,从开源、聚人、成立公司,到走向纽交所,再到股价一路狂飙(2024 年 7 月 11 日,最新市值 $107 亿),几乎是最理想的工程师创业故事。
[^2]: Yandex 是一家总部位于俄罗斯的跨国科技公司,被称为“俄罗斯的谷歌”,以其搜索引擎、互联网服务和技术创新而闻名。

0 comments on commit 07e0446

Please sign in to comment.