解密 Grupo MasMovil 使用 ClickHouse 监控无线网络

本文字数：4151；估计阅读时间：11 分钟

作者：Rodrigo Aguirregabiria Herrero, Grupo MasMovil

审校：庄晓东（魏庄）

本文在公众号【ClickHouseInc】首发

我们很高兴与大家分享来自西班牙最大的电信运营商之一Grupo Masmovil的这篇客座文章。Masmovil的OSS & Tools Monitoring部门的高级监控工程师Rodrigo Aguirregabiria Herrero详细介绍了监控无线接入网络（RAN）所面临的挑战以及ClickHouse如何改变了他们的方法。

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

这些网络庞大而复杂，需要部署成千上万个节点（或天线）。这样，当您远离一个节点时，您可以连接到另一个节点并保持互联网连接。

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

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

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

实际数据规模

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

有几种方法可以做到这一点，但在这种情况下，我们将专注于直接来自这些节点的信息。

这些节点有许多指标，几乎可以监控它们的每一个性能方面，例如与其他节点的连接、通话数量、流量，以及每个节点字面上数以千计的计数器。

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

数据以非结构化格式进入我们的服务器，存储在磁盘上的文件中。因此，它不是作为事件流发布的。这些文件的大小可以在200KB到40MB之间（这确实是一个很宽的范围），但是拥有40MB的节点只是一个很小的部分。最常见的情况是节点大小在2-5MB左右，想象一下我们只有大约1万个节点，那么我们每15分钟就要处理大约30GB的数据，每天将近3TB的数据。注意：1万个节点不足以为整个西班牙提供服务。

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

这就是ClickHouse的好处之一。加上查询速度非常快。

使用ClickHouse，您可以使用不同的编解码器和压缩算法，这在这种情况下非常有帮助，因为调整压缩会显着减少存储负担，这不仅更有效，而且更具成本效益。

让我们看看我们在其中一张表中使用ClickHouse实现的数据压缩：

rows	disk_size	compressed_size	uncompressed_size	ratio
562426183	351.84 GiB	349.04 GiB	1.31 TiB	0.260

压缩效果相当不错，与实际数据大小相比，我们使用的磁盘要少得多，与之前的解决方案相比也是如此。

通过我们当前的解决方案，我们使用的磁盘使用量比之前减少了16倍，但最重要的是，我们保留了更多的数据。这是如何可能的呢？首先，我们需要了解一些关于公式、传统电信监控系统以及时间和物理聚合的知识。

公式、时间和空间聚合

在本文的前面部分，我们已经谈到了计数器；然而，在几乎所有情况下，单独的计数器并不提供太多有用的信息。有价值的信息来自我们的工程团队或节点供应商设计的公式。

这些公式生成可以使用一个或多个计数器的关键绩效指标（我指的是很多；我们有使用超过150个计数器的公式）。

因此，如果我们有数百个不太有用的计数器和数百个有用的KPI，为什么不只保留计算出的KPI呢？这可能是一个解决方案，但不是一个有效的解决方案，因为我们不仅监视节点和某个时间段，用户需要在不同的时间聚合和空间聚合中获取信息。

用户以15分钟、每小时、每天等批次中找到有用的数据。这些信息不能预先计算，因为这会导致在更大的时间聚合中出现错误的KPI。

一个快速的例子是节点中的呼叫成功率，公式是：

100 x (成功呼叫数/呼叫尝试数)

一个小时内的一个节点：

Time	Successful Calls	Call Attempts	Success Call Rate
9:00	1	1	100%
9:15	2	2	100%
9:30	100	300	33,33%
9:45	98	100	98%

如果我们只有最终的KPI，我们就无法得到小时的真实值，因为让我们看看如果我们得到平均值 -> (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的值，这些对我们的工程团队至关重要。

在空间聚合方面，我们将会有：

节点包含一组小区，而节点属于城市、地区等。用户需要能够进行所有必要的深入分析。

问题在于，传统系统需要对所有空间和时间聚合都同时使用原始计数器和计算得到的关键绩效指标。

实际数据的图像如下所示：

但我们还没有考虑时间聚合，所以我们将有一个第三维，一个立方体。在数据中，立方体听起来很像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环境

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

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

大多数时候，它只消耗几个内核，但为了尽快为用户提供结果，它可以占用所有内核。

结果和结论

在实施了这种新的RAN网络监控方式的一年半后，这些是我们的成果：

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

更多详情

ClickHouse插件 for Grafana | Grafana Labs 【https://grafana.com/grafana/plugins/grafana-clickhouse-datasource/】
将Superset连接到ClickHouse | ClickHouse文档【https://clickhouse.com/docs/en/integrations/superset】

征稿启示

面向社区长期正文，文章内容包括但不限于关于 ClickHouse 的技术研究、项目实践和创新做法等。建议行文风格干货输出&图文并茂。质量合格的文章将会发布在本公众号，优秀者也有机会推荐到 ClickHouse 官网。请将文章稿件的 WORD 版本发邮件至：Tracy.Wang@clickhouse.com