Grupo MasMovil 如何使用 ClickHouse 监控无线接入网络

我们很高兴分享来自西班牙最大的电信运营商之一 Grupo Masmovil 的这篇客座文章。Masmovil 的 OSS & 工具监控部门的高级监控工程师罗德里戈·阿吉雷加比里亚·埃雷罗详细介绍了监控无线接入网络 (RAN) 的挑战，以及 ClickHouse 如何改变了他们的方法。

对于不熟悉无线接入网络 (RAN) 的人来说，它是移动网络的第一个接入点。这些节点允许您的智能手机访问 2G、3G、4G 和 5G 网络。

这些网络规模庞大，需要部署数千个节点（或天线）。这样，当您远离一个节点时，就可以连接到另一个节点并保持互联网连接。

在 MasMovil，我们决定从特定于电信的工具迁移到用于大数据的开源技术，其中之一是 ClickHouse，它使我们能够

• 改进我们的监控解决方案
  • 拥有更可靠的解决方案
  • 加快处理时间
  • 保留更多数据
• 节省以下方面的成本：
  • 软件许可证
  • 三级支持
  • 硬件

让我们看看我们是如何做到的。

那么，我们如何监控为数百万人提供互联网服务的数千个节点呢？

有几种方法可以做到这一点，但在本例中，我们将重点关注直接来自这些节点的信息。

这些节点有许多指标来监控其性能的几乎各个方面，例如与其他节点的连接、呼叫数量、流量，以及每个节点的数千个计数器。

我们不需要所有这些信息，因此我们对其进行了过滤。但是，我们仍然有数百个计数器和数千个节点，所有节点每 15 分钟发布一次数据。

数据以非结构化格式进入我们的服务器，存储在磁盘上写入的文件中。因此，它不会作为事件流发布。这些文件的大小可能在 200kb 到 40 MB 之间（确实是一个很大的范围），但大小为 40 MB 的节点只占一小部分。最常见的情况是节点大小约为 2-5 MB，假设我们只有大约 10,000 个节点，我们将每 15 分钟处理大约 30 GB 的数据，每天近 3TB 的数据。注意：10,000 个节点不足以覆盖整个西班牙的服务。

基本上我们需要每小时处理数千个文件，但主要问题是如何足够快地读取磁盘上写入的文件。使用流式工具处理数据并不复杂。但是，我们需要一个在磁盘使用方面最佳的数据库。

这是 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年的数据。

现在，我们拥有1年的15分钟数据。不需要更多的数据，对于更大的聚合，我们将其保存在单独的表中。最终，我们拥有了一套更加丰富的数据集，并且磁盘空间使用量减少了16倍。

另一个重要的方面是公式。它们彼此之间差异很大，有些很简单，有些使用数百个计数器，有些需要KPI在之前时间的数值，有些计数器是数组，等等。

这给一些公式增加了很大的复杂性。如果你需要一个提供这些功能的系统，你需要一个复杂的系统，如果出现某种新的KPI，它可以持续地进行改进。这类系统不仅需要强大的数据库，还需要强大的后端。在所有这些复杂性中，另一个问题随之而来，即指标发布的延迟，我们的旧系统可能会延迟3个小时发布数据。

但是，借助SQL和ClickHouse带来的附加功能，我们可以复制所有不同的KPI，自己创建它们，或者在ClickHouse支持团队的帮助下创建它们，他们帮助我们处理了许多特殊和奇特的KPI。

使用SQL，我们可以对所有类型的聚合使用相同的公式，在我们的案例中，我们使用Grafana来表示它。通过使用变量和查询，我们使用户能够轻松地在时间和空间聚合之间切换，并且一切都是动态的。

因此，ClickHouse结合了我们的后端和数据库。

我们在ESX中运行的虚拟机上使用docker部署了ClickHouse。

我们从几个核心和8GB的RAM开始，根据需要添加更多资源。

大多数时候它使用几个核心，但它可以占用所有核心，以便尽快向用户提供结果。

在实施这种新的RAN网络监控方式一年半后，以下是结果

• 我们保留了更多的数据，同时使用了16倍的存储空间。
  • 用户可以查看旧数据，而不会丢失任何信息。
• 结果发布的延迟大大减少（15分钟 vs 旧系统的3小时）。主要延迟在于数据文件的提取。
• 我们使用了10倍的资源（CPU和内存）。
• KPI公式对用户来说是透明的，不再隐藏在用户后端中。
• 支持多种可视化工具
  • Superset
  • Grafana
  • 自定义前端开发
• 稳定性。我们的ClickHouse部署从未失败，也从未宕机，而旧系统通常会出现间隙，需要不断重启。

• ClickHouse Grafana插件 | Grafana Labs
• 将Superset连接到ClickHouse | ClickHouse 文档