从个人实践经验来看，大多数情况下RD和PM对SOP没有一致的认知，PM对RD说:有风

险的部件需要实现筛选，修复这些推进单。RD直接实现了该功能的开发，但PM不清楚我的

功能是为了解决什么问题。RD往往认为自动化效率，自动化可以提高效率。这种观点在大多

数情况下没有问题，但实际上对MTTR有要求，有很多数据分析因此，PM在提出需求时，必

须同步RD这一需求解决什么样的安全问题，同时通知RD相关指标，在RD开发符合要求的产

品的同时，RD也必须积极询问PM的需求是固定的还是一次性的(很多PM不提出需求，RD将

很多一次性的需求视为永久性的需求)。

 

 

 

感觉很远，回到安全数据交互的问题，很好理解数据交互这个词，是用户对数据操作期待的

结果。影响数据互动效率的两个方面，一个是算法的时间和空间的复杂性，另一个是数据分

析平台的设计问题。本文主要集中讨论后者。对数据分析有一定了解的朋友可以跳过以下部

分。在这里，我们来讨论一下在安全场景中使用的数据分析模型和构想。

 

 

在设计数据交互系统时，首先需要考虑查询和存储两个层面。需要考虑的因素包括数据大小

、数据使用方法、数据更新频率。首先，从数据的大小开始，画一幅图来说明。图的内容可

能因公司而异。一般来说，这些数据的数据量与资产和业务复杂性成正比，如果是比较大的

公司，PB水平可能真的不是问题。

 

 

关于数据的应用场景，这与安全需求有很强的关系，但总体来说，这种应用场景本质上分为

在线分析处理(OLAS)和在线事务处理(OLTP)，OLTP是传统关系型数据库的主要应用，主要

是基本的日常事务处理，例如从accesslog中找到具有特定IP的访问记录。OLAS是数据仓储

系统的主要应用，支持复杂的分析操作，侧重决策支持，提供直观易懂的查询结果。OLTP

一般将大数据用于在线业务，如某个漏洞影响资产的展示等。该需求具有实时性，查询后需

要在秒级返回，服务稳定性和容错性有一定要求。此外，阅读操作的数量远大于写作操作，

增量数据的大小远小于历史数据。OLAS主要是离线分析，对时效性的要求不高，跑几个小

时到几天没什么问题，机器挂了也没关系，不能重新开始。但是，这个系统的数据量非常大

，数据的维度特别多，几乎需要多次扫描历史数据。在设计OLTP查询模型时，复杂的地方

是数据分层、分层、分布式事务，在设计OLAS查询模型时影响性能的主要是列存储、分割

、降低维度。OLTP比较比较简单，企业产品和开源产品非常多，OLAS比较复杂，由于数

据维度非常多，SQL语言在这种条件下进行数据分析也力。因此，在OLAS的设计中，建模

和抽象变得非常重要，如何解决数据的含义和查询的描述变得非常困难。相比之下，这方面

的突破并不容易。