国产雪球数据库在运营商O域数据中心的应用

通信运营商的O域是指负责网络运行维护,保障网络运行质量,提升用户使用感知的生产部门。在网络运行维护过程中,通过采集网络运行、用户使用的各个环节的信息,包括网元的告警、性能数据,网络设备间的信令数据,设备上的日志数据等,并对其进行加工处理,从而为网络规划、设备运行、终端分析、用户关怀、业务发展等多方面提供决策支持。

在分析和处理网管及其信令数据的过程中,O域数据中心主要面临这样几个方面的挑战:

  1. 数据增长迅速:随着运营商用户数的增长,信令类数据日增量增长非常快。例如:某省2012年日增8T左右的信令数据,到2022年已经增长到日增1.4P的数据;随着网络设备和支撑业务的演进,数据源的种类和格式也变化多样。从传统结构化的的数据库表数据,到半结构化的文件和消息,再到无结构的日志信息均需数据中心进行统一处理。

  2.  要分析的内容多样且多变:从网络设备到终端、到用户、到业务提供商、到业务内容都可以被O域数据中心展开分析;同时也要求数据中心可以快速迭代演进以适应运营商网络的演进和业务发展;另外运营商网络灵活性和业务多样性决定了网络运维过程较为复杂,经常需要深入分析各种异常场景下的运行状态,这也就要求数据中心可以灵活应对不同类型的数据分析过程。

  3. 为应对通信用户日益增长的通信需求,精细化运营已经成为了网络运营的基本要求。O域数据中心的数据源具备分析面向单用户业务运行情况的基础,这就要求其能够支撑对特定用户问题的定位、网络故障影响的用户识别、用户业务服务质量评估、用户业务支撑参数调优建议、潜在用户的挖掘等数据分析场景。

  4. 在现在快节奏的社会生活环境下,对问题的发现、业务的支撑情况的监控也都提出了更高的及时性要求。早些阶段只是针对特定的VIP用户进行实时监控的场景,也已经无法满足目前业务支撑的需求了,面向全网、细分客户、细分业务、细分使用场景的监控场景在日常网络运营过程中都是不可缺少的。

为应对以上的各种挑战,O域数据中心也在逐步演进,不断引入新的技术,从而更好的进行业务支撑。从下图可以看到,系统演进主要分成了4个阶段:

1672901238393885.png

以数据库为核心的数据中心:由于数据库的关系型计算的特点使其非常适合完成数据的各种汇总分析场景,因此,将各类数据统一汇聚到数据库中以形成各类分析结果表并最终以报表的形式展现数据是资源利用最高效的解决方案;这种架构随着数据量的增加(无论日增数据量的增加还是存量数据的累积),核心数据库的计算压力会越来越大,只能靠数据库软硬件的扩容来满足需求,带来了较高的成本压力;

  1. 为缓解单体关系型数据库的计算压力,系统演进的思路是将计算分解:数据预处理的能力逐步向ETL环节下沉,在数据入库前完成更多的计算;CUBE通过预先构造出多维的计算结果的模式,来缓解应用查询数据库时的开销并缩短等待时延;而数据库自身则通过使用并行处理架构来进行扩展,从而可以支持存放更多的明细数据。但随着数据量的持续增加,通用MPP架构数据库依然无法继续满足明细数据的存储和查询,而CUBE在应对面向用户级的分析时,也存在性能瓶颈;同时由于预建模型需要预留出时间通过批处理完成预计算的过程,端到端的数据时延较大;

  2. 大数据技术的引入,将关系型数据库从明细数据及其细粒度分析结果中解脱出来,使其更专注于面向应用的数据访问,从而合理的分流了需要在数据库中处理的数据量,更多的分析计算过程和数据存储转移到大数据生态中完成。但大数据生态主要是面向计算的使用场景,其提供了丰富的批处理和流处理的计算架构,在与应用交互时,支持能力受限;同时丰富的大数据生态也就意味着需要学习掌握的技术较多,要使用不同的技术组件应对不同的使用场景,导致数据要使用不同的方式保存多份,才能满足最终应用的需求;

  3. 引入雪球可以降低应用侧对接大数据生态的门槛,雪球可以直接存储详单级别的明细数据,还可以支持汇总类数据的实时加载和汇聚,也可以直接在详单上做各种数据计算从而实现数据探索类分析,同时又具备非常好的交互速度,可以补足大数据计算平台对应用和数据分析人员即席分析支撑的不足;

雪球的特性:

1. 提供了极速OLAP数据分析的能力:

      a) 提供PB级分析数据的列式存储,千亿级结构化数据高速查询;

b) 支撑大规模快速搜索、高并发查询、多维度关联分析;

c) 适合构建高性能实时数据仓库;

2. 分布式并行执行:

a) 多master集群:采用多master节点方式,消除中心节点性能瓶颈,大幅提升集群性能

b) 线性扩展:灵活添加节点,支持平滑扩展

c) 边读边写:支持同时写入和查询操作

3. 高性能数据导入:

a) 实时加载:通过Kafka实时加载数据,单节点日加载数据量超3T

b) 消除写入瓶颈:多节点同时导入,屏蔽中心节点架构的瓶颈问题

c) 副本异步拷贝:多副本异步拷贝,保证数据安全的情况下,提升性能

4. 高性能查询运算机制:

a) 列式存储:节省IO资源;压缩数据;支持快速复杂查询;

b) LLVM:运行时代码生成,简化了条件分支;虚函数的调用;

c) 数据压缩:轻量化数据压缩,在保证高性能的情况下,提供较高的压缩比

d) 向量化执行:通过SIMD/AVX,以数据块为调度单位,构建高效分析查询引擎,进而加速数据处理。

根据上述雪球的特性可以看出在运营商O域数据中心中使用雪球在这样几个场景下具有明显优势:

  1. 详单存储:解决详单存储在HBase中的单一场景。使用雪球可以在满足多条件查询的响应速度不低于HBase+索引的情况下,还提供了即席分析的能力,原始数据也无需在HIVE中再次存储。而且雪球的SQL分析能力使得原来很多面向用户的分析需要从HBase中提取用户详单后,再通过代码实现各种分析算法的开发模式,也转化为使用SQL直接在雪球中完成。,这样不仅充分利用资源,还提升响应速度,降低了开发复杂度。

  2. 实时数仓:传统的离线数仓通过预建的多维模型,将指标按照不同的维度进行统计汇总,从而在做数据分析和运行决策时,可以综合考虑多种不同的因素,看到这些因素对最终指标变化的影响。而随着分析场景实时性要求不断提升,特别是在故障问题分析时,无法利用传统的离线数仓来及时统计出多维指标。大数据中的流计算引擎受内存限制,对于数据源迟到的异常数据的容忍度相对较弱;而且,在流计算引擎中实现所有多维维度组合后的各项实时指标计算,则需要付出很大的代价。通过雪球的Kafka数据实时接入和多种增量算法,可以在雪球中实现实时数据的多维计算,应用可直接查询雪球中的统计结果。

  3. 准实时关联算法:在信令数据源的分析场景中,经常需要做的一个算法是将不同数据源的数据,按照一定的规则把相关的数据合并到一起后统一输出后,再完成相应的指标计算。当各数据源间的数据不能完全保证是按照时间顺序到达时,再加上数据的关联算法本身也较为复杂,通常有两种策略来实现这个场景。一个是采用批处理的模式,延时一段时间后,再利用批处理的算法完成关联。数据到达的波动被这个缓冲时间所屏蔽,准确性较高,但及时性较差;另一个是完全在流计算引擎中实现,这种实现机制可以保证及时性,但数据完整性会因资源限制而受到影响。在雪球中利用其物化视图的小批次处理机制,可以在保证及时性的同时,访问到已经入库的存量数据。即使出现迟到的数据,也可以在其到达后直接参与运算,保证数据准确性和完整性。

在O域数据中心中引入雪球后,对于详单类数据的处理,无需存储两份,对于HBase查询来说,也无需另建索引,空间节省超57%。基于详单的临时分析类任务,计算时延也从原来的小时级缩短到分钟级。 

1672900586748634.jpg

对于原有的批处理类关联计算类需求,从原来的4小时计算时延,缩短到5分钟之内;对于原来的流处理类计算指标需求,资源消耗只需要原有的20%。

1672900637440720.jpg

 国产雪球数据库是国内少有的掌握PB级数据处理技术公司睿帆科技的匠心之作。作为下一代大数据技术运用于电信运营商市场,已经实现稳定运行累计在网时长超过1200天,给各个运营商客户带来了巨大的技术变革,支撑很多业务场景从无到有的实现,也使得很多原有场景得到更大的效率提升,随着国产雪球数据库在运营商的更加广泛使用,相信会有更多的价值被发现。