我们很高兴分享这篇来自西班牙最大的电信运营商之一 Grupo Masmovil 的客座文章。来自 Masmovil OSS & Tools 监控部门的高级监控工程师 Rodrigo Aguirregabiria Herrero 详细介绍了监控无线接入网络 (RAN) 的挑战，以及 ClickHouse 如何改变了他们的方法。
对于那些不熟悉无线接入网络 (RAN) 的人来说，它们是移动网络的第一个接入点。这些节点允许您的智能手机访问 2G、3G、4G 和 5G 网络。
这些网络规模庞大，需要部署数千个节点（或天线）。这样，当您从一个节点移开时，您可以连接到另一个节点并保持您的互联网连接。
在 MasMovil，我们决定从电信专用工具迁移到用于大数据的开源技术，其中之一是 ClickHouse，它使我们能够
- 改进我们的监控解决方案
- 拥有更可靠的解决方案
- 加快我们的处理时间
- 保留更多数据
- 节省成本
- 软件许可
- 三级支持
- 硬件
让我们看看我们是如何做到的。
数据的实际大小
那么，我们如何监控为数百万人提供互联网服务的数千个节点呢？
有几种方法可以做到这一点，但在本例中，我们将重点关注直接来自这些节点的信息。
这些节点有许多指标来监控其性能的几乎每个方面，例如与其他节点的连接、呼叫次数、流量以及每个节点数千个计数器。
我们不需要所有这些信息，所以我们对其进行过滤。但是，我们仍然有数百个计数器和数千个节点，所有节点每 15 分钟发布一次数据。
数据以非结构化格式进入我们的服务器，存储在磁盘上写入的文件中。因此，它不是作为事件流发布的。这些文件的大小可以在 200kb 到 40 MB 之间（这确实是一个很大的范围），但 40 MB 的节点只占很小一部分。最常见的情况是 2-5 MB 左右的节点，想象一下我们只有大约 10,000 个节点，我们每 15 分钟将处理大约 30 GB 的数据，每天几乎 3TB 的数据。注意：1 万个节点不足以向整个西班牙提供服务。
基本上，我们需要每小时处理数千个文件，但主要问题是以足够快的速度读取磁盘上写入的文件。使用流处理工具处理数据并不太复杂。然而，我们需要一个在磁盘使用方面最佳的数据库。
这是 ClickHouse 的优势之一，以及非常快速的查询速度。
使用 ClickHouse，您可以使用不同的编解码器和压缩算法，这在本例中很有帮助，因为调整压缩会显着减少存储负担，这不仅更高效，而且更具成本效益。
让我们看一下我们在 ClickHouse 的一个表中实现的数据压缩
| 行数 | 磁盘大小 | 压缩后大小 | 未压缩大小 | 压缩比 |
| 562426183 | 351.84 GiB | 349.04 GiB | 1.31 TiB | 0.260 |
压缩效果非常好，与数据的实际大小以及我们之前的解决方案相比，我们使用的磁盘空间要少得多。
使用我们当前的解决方案，我们使用的磁盘空间比以前减少了 16 倍，但最重要的是，我们保留了更多数据。这怎么可能呢？首先，我们需要了解一些关于公式、传统电信监控系统以及时间和空间聚合的知识。
公式、时间和空间聚合
在本文的前面，我们已经讨论过计数器；但是，在几乎所有情况下，仅靠计数器并不能提供太多有用的信息。有价值的信息来自我们的工程团队或节点供应商设计的公式。
这些公式生成可以使用一个或多个计数器的 KPI（我说的多个是指很多；我们的公式中有超过 150 个计数器）。
因此，如果我们有数百个无用的计数器和数百个有用的 KPI，为什么不只保留计算出的 KPI 呢？这可能是一种解决方案，但不是有效的解决方案，因为我们不仅监控节点和某个时期，用户还需要不同时间和空间聚合的信息。
用户在 15 分钟、每小时、每天等批次中找到有用的数据，并且此信息不能预先计算，因为这会导致在更大的时间聚合中产生错误的 KPI。
一个快速示例，节点中呼叫的成功率，公式将是
100 x (成功呼叫/呼叫尝试)
以及一个节点在一个小时内
| 时间 | 成功呼叫 | 呼叫尝试 | 呼叫成功率 |
| 9:00 | 1 | 1 | 100% |
| 9:15 | 2 | 2 | 100% |
| 9:30 | 100 | 300 | 33,33% |
| 9:45 | 98 | 100 | 98% |
如果我们只得到最终的 KPI，我们就无法获得小时的真实值，因为让我们看看如果我们得到 AVG -> (100 + 100 + 33, 33 + 98)/4 = 82.83
但是，该值完全被歪曲了。它没有考虑到在某些时间戳中呼叫次数要多得多。
真实的 KPI 将通过以下方式计算
100 * ((1+2+100+98)/(1+2+300+100)) = 49,88
这几乎是使用平均值估计值的一半。这意味着我们需要所有计数器的信息，而不是最终的 KPI。
这种计算使用 SQL 非常容易，只需将时间转换为前几个小时，然后对计数器求和，例如
toStartOfHour(Time), 100 * SUM(Successful Calls)/SUM(Call Attempts)
非常简单！最棒的是我们不需要计算出的 KPI。
我们遗留系统的问题在于它需要计算出的 KPI 和原始计数器，因此结果是我们消耗了更多的磁盘空间。
我们已经讨论了时间聚合，但还有空间聚合。我们只提到了节点的监控，但在这些节点内部有小区，在它们之上，有关于城市、区域的拓扑信息，以及整个国家/地区某些 KPI 的值，这些对我们的工程团队至关重要。
在特殊聚合方面，我们将有
一个节点包含一组小区，一个节点属于一个城市、一个区域等。用户需要能够进行所有必要的向下钻取。
问题在于，遗留系统需要所有空间和时间聚合的原始计数器和计算出的 KPI。
遗留系统所需的实际数据的图像如下所示
但是我们没有考虑时间聚合，所以我们将有第三个维度，一个立方体。数据中的立方体听起来很像 OLAP 立方体，对吗？
我们正在以指数方式增加数据的大小。在遗留系统中，我们有复杂的方法来创建这些公式和聚合，为 KPI 和网络拓扑都有内部清单。
但是考虑一下，如果我们有一个高速 OLAP 数据库，我们只需要用拓扑结构的其余部分标记（添加列）的小区的原始计数器，就像这样
这就是我们使用 ClickHouse 的主要原因。ClickHouse 中的实时查询速度非常快，以至于我们不再需要复杂的系统来计算不同类型聚合的公式。目前，我们拥有小区数据，并使用拓扑结构进行了丰富，我们拥有其上的所有信息，没有第二个进程在后台等待更多数据。
此外，遗留系统需要在磁盘上存储大量数据，它无法存储最小时间聚合的太多数据。例如，对于 15 分钟数据，我们只有 15 天，对于每小时数据，我们有 30 天，对于 15 分钟数据，我们有一年。
现在，我们有 1 年的 15 分钟数据。不需要更多，对于更大的聚合，我们将其保存在单独的表中。最后，我们拥有更丰富的数据集，并且我们使用的磁盘空间减少了 16 倍。
SQL，查询的力量
另一个重要的方面是公式。它们彼此之间差异很大，有些很简单，有些使用数百个计数器，有些需要上一次的相同 KPI 的值，有些计数器是数组等等。
这给一些公式增加了很多复杂性。如果您需要一个为您提供这些功能的系统，您将需要一个复杂的系统，如果出现某种新的 KPI，它可以持续提供改进。这些类型的系统不仅需要强大的数据库，还需要强大的后端。由于所有这些复杂性，另一个问题随之而来，即指标发布的延迟，我们的遗留系统可能会以 3 小时的延迟发布数据。
但是，借助 SQL 和 ClickHouse 带来的附加功能，我们可以复制所有不同的 KPI，自己创建它们或者在 ClickHouse 支持团队的帮助下创建它们，他们帮助我们处理了很多特殊和奇怪的 KPI。
借助 SQL，我们可以将相同的公式用于各种聚合，在我们的案例中，我们使用 Grafana 来表示它。使用变量和查询，我们使用户能够轻松地在时间和空间聚合之间切换，并且一切都是动态的。
因此，ClickHouse 结合了我们的后端和数据库。
关于我们的 ClickHouse 环境
我们使用 docker 在 ESX 中运行的虚拟机中部署了 ClickHouse。
我们从几个核心和 8GB 内存开始，根据需要添加更多资源。
大多数时候它消耗几个核心，但它可以占用所有核心，以便尽快给用户结果。
结果与结论
在实施这种新的 RAN 网络监控方式一年半后，以下是结果
- 我们保留了更多数据，使用的空间减少了 16 倍。
- 用户可以查看更旧的数据，而不会丢失信息。
- 结果发布延迟大大减少（15 分钟 vs 遗留系统的 3 小时）。主要延迟在于数据文件的提取。
- 我们使用的资源（CPU 和内存）减少了 10 倍
- KPI 的公式对用户是透明的，不再对用户后端隐藏。
- 支持多种可视化工具
- Superset
- Grafana
- 自定义前端开发
- 稳定性。我们的 ClickHouse 部署从未失败且未宕机，而遗留系统通常会出现故障，需要不断重启。
