本文导读：

在数据安全管理体系的背后，离不开对安全日志数据的存储与分析。以终端设备为例，中国联通每天会产生百亿级别的日志数据，对于保障网络安全、提高系统稳定性和可靠性具有至关重要的作用。目前，Apache Doris 在联通体系的落地已支持了 30 多条业务线和数百个实时作业，不仅帮助联通实现了万亿级安全日志的高效分析和低成本，也为其他运营商提供了成功的参考案例和学习经验，对推动运营商的数字化转型进程具有重要意义。

作者：刘宇麒，大数据开发工程师

联通西部创新研究院是中国联通在西部地区布局的重要载体，也是中国联通数字化创新能力体系的重要组成部分，承载了集团公司科技创新体系和数字化创新体系的需求。依托联通数科的优质资源及能力底座，在云计算、大数据、物联网、人工智能、网络安全等业务领域具备深厚的技术能力和丰富的项目经验。

近些年来，网络高危漏洞数量的增长、DDoS 攻击比例的提升、恶意 Bot 流量的持续上升使得 Web 安全威胁态势愈发严峻，而数字化转型进程的推进在丰富业务创新的同时、也提升了网络空间复杂度、进一步加剧了网络安全风险。这样的背景之下，联通以攻防实战对抗为目标、进行国家级网络空间的安全治理工作，围绕“云-管-端-数”构建了多级综合防控体系，聚焦于实时监测、攻击溯源、通报预警、应急处置、情报共享等工作，构建数据全生命周期安全管理体系，为客户提供从顶层设计到运营维护一站式服务。

在数据安全管理体系的背后，离不开对安全日志数据的存储与分析。以终端设备为例，每天会产生海量的设备日志，这些日志数据记录着各种网络时间和系统操作的细节信息，对于保障网络安全、提高系统稳定性和可靠性具有至关重要的作用。为了更好的管理和分析安全日志数据，联通西部创新研究院应集团要求构建一个集中化日志数据分析平台，满足对事件和日志数据自动化采集、存储、管理、分析和可视化的诉求。这要求集中化数据分析平台具备以下能力：

建模分析：基于网络日志数据和告警数据进行规则或智能挖掘，发现潜在的安全事件，例如钓鱼邮件、非法访问等，并进行定向威胁感知。
态势大屏：通过多种维度不同监控指标的组合，例如安全事件 TOP5 等，密切监控当前网络安全态势状况，通过态势大屏呈现攻击威胁的主要分布。
追踪溯源：通过对安全事件的快速研判，还原整个攻击链条进行精准的溯源取证，从而保障网络和数据安全。

为搭建具备上述能力的集中化日志数据分析平台，在正式搭建之前，结合日志数据的特性及业务要求，我们需要综合考虑考虑如何满足以下要求，以确保平台能高效的支持联通日志场景的实际应用：

数据接入方面：日志数据具有种类繁多、格式多样化、规模庞大等特点，要求数据平台支持多种日志格式数据的导入，并支持高性能的数据写入。
实时性要求方面：为及时监控和了解系统运营情况和存在的问题，高实时性对于数据平台非常关键。这要求平台要实时进行数据同步，保障数据的一致性，并支持数据实时查询，以便获取最新的系统和业务状态。
可扩展要求方面：数据平台需要具备计算与存储的拓展能力，以便满足集团及分公司不断增长的数据处理分析需求。

在中国联通安全日志数据分析平台的迭代过程中，经历了从基于 Hive 的离线数据仓库到以 Apache Doris 为核心的实时数据仓库。从具体业务收益来讲，Apahce Doris 的引入支持了联通 30+ 条业务线和数百个实时作业，为联通带来了存储资源节约 50%、百亿级别数据查询秒级响应、数据导入效率提升 60% 的显著成果，成功实现了降本增效的业务目标；从集团整体价值来讲，通过该平台，联通可以更好地监控运营状态、保障网络安全，为运营商安全管理体系提供了重要的底层支持。总而言之， Apache Doris 在联通体系的落地，不仅帮助联通实现了万亿级安全日志的高效分析和低成本，也为其他运营商提供了成功的参考案例和学习经验，对运营商数字化转型进程的推进有着重要作用。

基于 Hive 的离线数据仓库

联通1.png

在项目一期建设中，我们以 Apache Hive 为核心建立了离线数仓，并在其此础上进行了数据仓库分层。当原始数据经过数据采集进入离线数仓后，由 Spark 逐层进行处理，并配合 Apache DolphinScheduler 以分钟级调度执行计算作业，最终将数据输出至 OLAP 和应用数据库。

从业务的角度来看，该架构数据流的痛点问题在于数据实时性不足，主要受限于 Hive 的离线批处理模式，端到端的延迟最短竟然需要 10 分钟。

其次，我们在该架构中选择了 ClickHouse 作为 OLAP 引擎，但在实际使用场景中发现 ClickHouse 存在以下不足：

ClickHouse 并发支持能力不足，无法满足业务需求，例如实时大屏指标的计算与加载缓慢，经常会在业务高峰期出现查询超时。
业务中有大量安全事件表需要进行多表 Join，这些表数据量较大，而 Clickhouse 在分布式 Join 实现性能较低，时常会出现 OOM 问题，为避免该情况发生，常常需要依赖宽表才能缓解，而这既影响了业务的稳定性，也增加了许多额外的维护成本。
由于 ClickHouse 对于数据更新操作支持较弱、更新性能较差，这也限制了它在某些场景下的应用。
ClickHouse 使用和运维成本较高，也给我们带来了更高的人工投入成本。

系统选型及落地

随着一期架构问题的逐步暴露，我们迫切需要对数据分析平台进行更新迭代。对于二期建设来说，提升数据的实时性被确立为首要目标，为了实现这一目标，我们计划增加实时数据处理链路，以更好地实现数据的实时收集、处理和查询要求，为系统稳定和网络安全提供更有力的支持和保障。其次，为解决一期平台存在的并发能力不足、多表 Join 性能低等核心问题，提升 OLAP 引擎性能成为二期建设的的另一关键目标，因此亟需对一期平台中 OLAP 引擎 ClickHouse 进行替换，以满足业务侧日益严格的数据分析和处理需求。

在此背景下，我们考虑是否可以只选择一个新的实时数据仓库同时满足以上两个目标，一方面即能帮助我们构建实时数据分析处理链路，另一方面又可以作为性能更强悍、更易用的 OLAP 分析引擎，这样不仅可以简化数据处理流程、提高实时效率，而且可以降低平台运维管理的成本。

为了找到符合条件的数据库，我们进行了多方调研和对比研究，最终选择以 Apache Doris 为核心来构建统一的实时数据仓库体系。为了直观展示 Apache Doris 的性能和功能特点，我们使用 Apache Doris 与 ClickHouse 进行了对比，其中最直观的感受是 Apache Doris 在系统并发、Join 性能以及多个功能的易用性都更为领先。

联通2.png

Doris 替换 Hive + ClickHouse 建设实时数据仓库

联通3.png

在项目二期的建设中，我们使用 Apache Doris 替换了 Hive 成功搭建实时数据仓库，实现数据的实时采集、处理和分析，同时使用 Apache Doris 替换 ClickHouse 作为 OLAP 引擎。架构工作机制如下所示：

ODS 贴源层：主要用于存放未经处理的原始数据，通过 Flume 等实时采集工具，将各个厂商未经处理的原始日志以及告警数据统一汇集到 Kafka 中，同时完全相同的数据也会被存入 HDFS 中一份，作为原始数据核查依据或进行数据回放。
DWD 明细层：该层为事实表，数据通过 Flink 计算引擎实时对生产数据及字段进行清洗、标准化、回填、脱敏之后写入 Kafka 。Kafka 中的数据还会对接到 Doris 中，以支持明细日志数据详情回溯查询、准实时模型分析、实时大屏及报表业务。由于大部分日志数据对于数据重复不是很敏感，因此 DWD 层采用 Doris 的 Duplicate Key 模型。
DWS 汇总层：以明细层 Kafka 数据为基础，通过动态规则引擎进行细粒度的聚合分析，为后续的业务查询和 OLAP 分析做准备，同时大部分建模分析的结果也集中在 DWS 层。
ADS 应用层：该层主要使用 Doris 的 Aggregate Key 模型和 Unique Key 模型对以上三层的数据进行自动聚合或者自动更新，以满足前端人员的具体分析需求。

新架构的应用实践

日增百亿数据，稳定快速导入

数据分析平台平均每天有 150 亿的业务日志数据新增，面对如此大规模的数据量，我们需要考虑如何将数据快速实时稳定入库。经调研，Doris Flink Connector 组件（主要依赖 Doris Stream Load ）可以实现海量数据快速导入。并且其使用非常简单，只需要导入相关依赖包进行简单的配置即可进行。在应用 Doris Flink Connector 后，数据写入性能可达到每秒 20-30 万条，极大地提升了数据导入的速度和效率，同时也不会对正常的数据分析造成干扰。

在采用 Flink 进行高频实时写入 Doris 时，如果未合理调整参数配置，可能导致数据版本堆积。为避免该问题，我们进行了以下调整优化：

Flink 优化：为减轻 Doris 的写入压力，可通过提高 Flink 的 Checkpoint 时间来减少版本数量。具体来说，我们可以将 Checkpoint 时间从之前的 15 秒提高为 60 秒，以减少批次写入频率，降低 Doris 单位时间处理事务数量。这样可以在不影响业务的情况下，缓解写入压力，避免产生大量的数据版本。
数据预处理：为了减轻 Doris 的写入压力，部分数据我们会先在 Flink 中通过主键 ID 进行预聚合，将来自多个表中相同的 ID 进行处理并构建大宽表，降低多流数据的写入资源消耗。
Doris 优化：调整 Doris BE 参数，增加 CPU 资源参与 Compaction 操作；根据业务设置合理的表分区、分桶和副本数量，避免过多分分片，以降低 Compaction 的开销。同时增大 max_tablet_version_num，避免版本堆积。

通过以上优化措施，每日新增的百亿数据可以平稳导入 Doris 中，整个导入过程中 BE 表现稳定，Compaction Score 始终保持低位，大批量数据的写入对于前端查询的性能也没有造成任何影响。同时在 Doris 的 Unique Key 模型的加持下，我们可以利用 Flink 对输入数据进行关联、聚合等处理，再以微批、精准一次性写入 Doris 中，实现了数据秒级更新。

存储资源合理配置，成本节约 50%

日志数据具有非常大的数据量和数据增长速度，如果不对存储资源进行合理分配和控制，存储成本将会成为一个巨大的负担。日志数据中也会存在重要性的区分，有一定比例的数据价值密度比较低，如果毫无差别的将这些数据都存储下来，不仅会造成存储浪费，也会增加数据分析的难度。为了有效解决这些问题，我们采用了一系列策略来降低数据存储成本：

ZSTD 高效压缩算法：利用 Doris 的新特性——ZSTD 高效压缩算法进行压缩存储。在建表时指定压缩方法为 ZSTD，特别是对数据量超过 T 级别的数据表，这种压缩方法可以有效地减少数据占用的存储空间，数据压缩比最高可达 1:10。即使采用 3 副本来保证数据的高可靠，数据存储占用的空间仍有非常大幅度的降低。
冷热数据精细化管理：在 Doris 中只存储近一年的数据，将更早的数据备份到成本更低的存储介质中。同时使用热数据转冷的功能，在 SSD 中仅存储最近 7 天的数据，将 7 天之前的数据转存到 HDD 中，以进一步降低存储成本。这样可以根据数据的使用频率，合理分配存储资源，达到性能和成本的平衡。目前 Apache Doris 2.0 版本已经实现了对冷热数据分层功能的支持，这一功能可以将冷数据下沉到存储成本更加低廉的对象存储中，冷数据在对象存储上的保存方式也从多副本变为单副本，存储成本进一步降至原先的三分之一，同时也减少了因存储附加的计算资源成本和网络开销成本，目前我们正在积极测试中，未来有机会也会与大家分享实践经验。
分区级副本设置：将 3 个月以内的数据设置为高频使用数据，将其分区设置为 3 副本；将 3-6 个月的数据分区设置为 2 副本；将 6 个月之前的数据分区设置为 1 副本。这样可以根据数据的使用情况，合理分配副本数量，实现存储成本降低的同时也充分利用多副本来提升热数据的查询性能。

借助于 Doris 极高效率的压缩算法、冷热数据分层管理、分区级副本设置等功能，可对存储资源合理分配，最终实现存储成本节约 50%，成功达到性能和成本的平衡。

数据规模分级查询，查询速度提升 10+ 倍

日志中包含了许多对分析及时性要求非常高的数据，例如异常事件、故障信息等，因此为了保障日志数据的查询效率，我们以数据量的级别为基准采用了不同的查询策略：

对于 100G 以下的数据，可以采用分区表的形式进行查询。在业务初期业务表按照天进行分区，每天执行任务需要手动管理分区为我们带来了非常大的维护成本。后来我们利用 Doris 的动态分区功能，针对数据量较大的表可以使用小时作为分区字段，为了避免分区内数据倾斜，以雪花 ID 作为分桶字段，保证数据的均衡。此外为了避免数据积压，我们还开启了动态分区的起始偏移，保留近 20 天的数据来支撑业务分析。这样可以有效地降低数据积压的风险，同时也能够满足业务的分析需求。
对于 100G 到 1T 的数据，我们采用物化视图进行查询，物化视图是一种预先计算并存储结果集的方式，可以减少查询所需的计算时间和资源消耗，从而提高查询效率。Doris 系统提供了完整的物化视图 DDL 语法，可用于创建、查看和删除等操作，这些语法与 PostgreSQL 和 Oracle 语法一致，使用简单、不需重新学习。
对于上百 T 的数据，我们通过 Aggregate 聚合模型表进行查询，使用 Aggregate 模型在数据写入前进行预聚合，通过以上方式，我们成功将 20 亿条数据的查询时间进一步缩短至 1-2s，有效提高了数据查询的效率。

在一期数据分析平台中，大部分业务场景都是通过 T+1 的方式进行计算。而在基于 Doris 的二期数据分析平台中，我们实现了对大部分业务准实时（分钟以及小时级）和实时计算场景的支持。同时结合以上优化措施，极大降低了各种维度指标的统计时间，以往需要分钟级别的明细查询，现在可以在毫秒级别迅速响应，极大地改善了用户体验；另外，在 Doris 中，我们能够快速对百亿级别的大表进行不同维度的数据分析，只需要几秒即可获得查询结果，大大提高了联通各业务部门数据分析的能力。

收益总结

自引入 Apache Doris 以来，我们已经部署了多个集群、数十台机器，支持了中国联通 30 多条业务线和数百个实时作业，日增日志数据百亿级别，单个集群的数据规模达到数 PB 。Apache Doris 的成功应用为联通带来了多方面收益，主要包括如下方面：

在数据导入方面， 对于联通而言，每天都面临着庞大的日志增量，并且这些数据的实时性和准确性对于业务发展和决策至关重要，而 Doris Flink Connector 帮助我们实现了数据快速且稳定导入，可轻松应对日增百亿数据的导入要求，为后续的数据处理和分析提供了更高效的解决方案。

在存储资源分配方面， 由于数据量庞大、存储周期长等原因，日志数据的存储成本一直是运营商面临的难题，通过采用 Doris 高效的压缩算法、冷热数据精细管理、分区级副本设置等功能，帮助我们降低了数据存储成本，数据存储利用效率和价值得到显著提升。

在查询性能方面， 快速获取日志数据查询结果可以帮助运营商及时掌控网络及系统情况，及时发现并解决问题，也有利于及时了解用户需求和行为，优化营销策略和服务方案。Doris 在查询性能方面提供了强大的支持，能够处理百亿级别大表按小时/天级别的明细查询，并支持不同维度聚合查询分析。业务线整体响应时间可在秒级或毫秒级别完成，甚至可以在 1-2s 内完成对 20 亿条数据的查询，查询速度较之前提升了 10+ 倍。

未来规划

在最新发布的 Apache Doris 2.0 版本中，Apache Doris 提供了大量新的功能，比如倒排索引功能和冷热数据分层等，对于日志分析场景来说都是具有重要意义的更新。目前我们是以数据存储周期为基准进行副本分配，并按照数据热度分别存储在 SSD 和 HDD 中，后续我们将使用冷热数据分层新功能，将数据从从 SSD 或者 HDD 下沉到对象存储中，从而降低数据存储成本，进一步达到服务器磁盘资源节省的目的。此外，我们正在对倒排索引功能进行测试，并计划先在小范围业务场景推广使用，倒排索引对于字符串类型的全文检索和普通数值、日期等类型的等值、范围检索具有更高效的支持，希望通过倒排索可以帮助我们进一步提高日志数据查询的效率和准确度。

除此之外，基于联通的使用场景，我们对自动分桶功能提出一些建议。目前自动分桶计算逻辑是根据最近的分区数据量来动态决定当前分区的分桶数目，这种方式适用于分区数据量呈线性关系的业务表。然而，由于我们的业务表在白天的数据量较多，夜晚数据量较少，因此使用自动分桶会导致白天部分分区具有较少的分桶，而夜晚分区则具有较多的分桶。因此，未来我们期望社区可以增加一种新的分桶规则，以前一天的数据分区存储情况为参照，来对当天的分区进行自动分桶，这样可以更加准确的根据业务表特点进行自动分桶。当然我们也将对该功能的优化进行探索，及时与社区交流，将最新的优化代码贡献到社区，共同推动社区的发展进步。

最后，非常感谢 Apache Doris 社区和 SelectDB 的同学，我们在使用中遇到任何问题时，他们给予了我们快速的响应与技术支持，未来我们会持续的将在实践过程中取得的相关成果贡献到社区。希望 Apache Doris 与 SelectDB 越来越好！