“全链路”指的是全业务、全场景、全方向，那么全链路数据仓库指的是这个数仓中的数据是包罗万象的数据，因为在信息安全业务领域，会有大量的特征、策略、用户行为需要进行数据分析和验证，因此挖掘数据关系的关联性俨然成为了一个趋势，这些数据的链路关系是面向全方位的，两点之间的数据也可以存在多条链路关系，安全业务全链路数据即数据网格化应用， 网格越密集，那么数据就越完善，集成度更高。 只有构建高度集成化的数据链路才能让数据成为安全生产力，让安全业务变得更主动。
![]()
在58信安承担着全集团各个业务线安全治理治理工作，信安业务系统会生产人工审核、机器检测、举报、申诉、维权、处罚、处理、取证等一些列风控系统的数据，但是安全治理工作除了使用到这些风控侧数据之外还需要使用业务侧数据，那么这些业务侧数据的生产维护散落在各个业务线，各个业务线对数据的管理维护标准也会有很大的差异，因此会有 各种结构化、半结构化、非结构化数据，同时账号、帖子id等体系不统一，那么如何能够以一个低成本的方式进行数据分析，如何快速有效的组织和转化数据与黑产对抗，是整个风控环节面临的巨大挑战，因此信息安全需要构建各个业务场景数据与风控系统数据之间的串接，让这些数据有统一的标准、相同的规范、一致的规则存储在安全数仓中。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
按业务概念组织细节数据，并进行名称、代码等标准化处理。
|
|
|
|
|
根据核心业务价值链按照星型模型或雪花模型设计方式建设的最细业务粒度汇总层。在本层需要进行指标与维度的标准化，保证指标数据的唯一性。
|
|
|
|
|
根据不同的业务需求采用星型或雪花型模型设计方法构建的数据集市
|
|
|
|
|
维度是对具体分析对象的分析角度，维度要具备丰富的属性，历史信息的可追溯性，对通用的维表要保持一致性。
|
|
|
|
|
用来降低加工过程计算难度，提高运行效率的临时表层。
|
业 界针对数据建模的标准大致有两个，关于哪种方法更好的争论已经由来已久。 但随着这两种数据仓库应用越来越多，人们也逐渐了解到两种数据仓库的优劣之处，产生这些区别的根本之处在于规范化数据仓库需要对企业全局进行规范化建模，这将导致较大的工作量。 但这一步必须完成好，才能继续往上建设数据。 因此也就导致规范化数据仓库需要一定时间才能投入使用，敏捷性相对后者来说略差。 但是规范化数据仓库一旦建立好了，则以后数据就更易于管理。 然而另一方面维度建模数据仓库除了敏捷性更强，而且适用于业务变化比较频繁的情况，对开发人员的要求也没有规范化数据仓库那么高。 总之各有利弊，下面表格主要从时间、成本、使用、人员、维护等5个纬度做了一个对比。
作为大数据板块，数据来源更加广泛，针对的业务域也更加宽广，所以维度建模相对于我们来说更加灵活并适用，想要做好数据建模，对业务的深刻理解是首要任务，数据仓库模型是数据开发人员、业务人员、产品运营人员相互沟通的一套语言，可以通过这套统一的标准让大家对数据的理解以一个低成本的方式达到一致，在实践中总结出来维度建模的四个关键步骤。
业务过程是通常表示的是业务执行的活动，与之相关的维度描述和每个业务过程事件关联的描述性环境。通常由某个业务型系统支持， 例如：发布系统。一系列的业务过程产生一系列事实表。
粒度传递的是与事实表度量有关的细节级别，精确定义某个事实表的每一行表示什么，同时对事实表的粒度要与业务达成共识。
纬度是看事情的角度，从不同的角度看待事情也会得出不同的结论，正如一首诗词“横看成岭侧成峰，远近高低各不同”。健壮的维度集合可 以更好的来修饰事实表。维度表示承担每个度量环境中所有可能的单值描述符。
如何确认实时事件，可以通过5W1H分析法去分析，不同粒度的事实必须放在不同的事实表中。事实表的设计完全依赖物理活动，不受最终报表的影响。事实表通过外健关联与之相关的维度。查询操作主要是基于事实表开展计算和聚合。
其中粒度是非常重要的，粒度用于确定事实表的行表示什么，建议从关注原子级别的粒度数据开始设计，因为原子粒度能够承受无法预估的用户查询，而且原子数据可以以各种可能的方式进行上卷，而一旦选择了高粒度，则无法满足用户下钻细节的需求。
事实是整个维度建模的核心，其中雪花模型或者星型模型都是基于一张事实表通过外健关联维表进行扩展，生成一份能够支撑可预知查询需求的模型宽表，而且最后的查询也是落在事实表中进行。
维度建模四步走，主要基于业务进行建模，业务建模是基于业务已有信息，结合建模同学对业务的理解，对业务进行梳理，此时不会面向具体的分析细节，确认范围主要是业务域、业务过程和实体之间的关系，输出业务总线矩阵。业务建模的目的是为了对业务需求进行分解，转化为数据理解，包括的具体流程有：划分业务域、确认业务过程、设计事件事实，确认相关实体、关联事件、构建业务总线矩阵。
总线矩阵好比数仓的地图，通过总线矩阵，可以在宏观上对整个仓库包含哪些业务过程，有哪些公共维度，以一个结构化的方式串联起来，这样我们对整个数仓的结构能够有一个清晰的了解，很容易就能看出来某个业务过程包含哪些通用维度。 通过总线矩阵建设数据结构框架，可以处理不同的以过程为中心的维度模型的实现，且他们的实现严格遵守一致性维度。 各部分维度模型可以互相配合，互相联系。
为了更好的让业务人员拥有一个全局观，遇到数据需求知道如何快速的与数仓中的业务进行匹配，我们需求构建一个全链路流程的数据仓库，如果我们在建立数据仓库的时候，只考虑单独的某个业务系统的数据建设，则无法满足一致性的目标，例如：相互有联系的系统数据的维度不同导致关联复杂或者关联不上，数据之间互相成为了孤岛，对于后期的扩展或者整个数仓的建设都是巨大的阻碍。那么总线矩阵就给我们提供了这么一个工具，每一行是一个业务过程，每一列是这个业务过程可能涉及到的一些维度，比如说上面表格中的风控业务过程，这块涉及到的公用维度以及这些维度与哪些业务过程能够进行关联一目了然。
数据仓库中常见的模型有： 范式建模，雪花模型，星型建模，星座模型，其中后三者常被应用在维度建模中，它们之前的关系如下：
星形模式是最常用的维度建模方式，星形模式的维度建模由一个事实表和一组维度表组成。
雪花模式是对星形模式的扩展，每个维度表可继续向外连接多个子维度表，雪花模型相当于将星形模式的大维度表拆分成小维度表，满足了规范化设计
星座模式也是星型模式的扩展，前面介绍的两种维度建模方法都是多维表对应单事实表，但在很多时候维度空间内的事实表不止一个，而一个维表也可能被多个事实表用到。在业务发展后期，绝大部分维度建模都采用的是星座模式。
针对信息安全场景，各个业务以及风控系统之间的大量事实表有共同的维度，因此针对安全业务数仓也采用的星座建模的方式。
提到数据仓库的主题划分，大家最容易想到的就是金融行业的十大主题，因为在某些行业，比如电信、金融等领域都是最早建设数据仓库的行业，因此也都有一些规范。
除了以上按照行业案例分析划分主题域之外下面主要介绍一下其他通常主题划分方法：
1. 按照所属系统划分：业务系统有几种，就划分几种
2. 按照业务（功能模块/业务线）或业务过程划分，比如一个靠销售广告位置的门户网站主题域可能会有广告域，客户域等，而广告域可能就会有广告的库存，销售分析、内部投放分析等主题；
3. 按照部门划分主题，比如公司里面的人力、财务、销售、运营等，运营域中可能会有工资支出分析、活动宣传效果分析等主题。
在互联网行业，尤其是在提到业务安全治理，除了会通过一些内容表现寻找特征之外，大多数还需要通过用户行为寻找特征，那么这些用户行为特征需要将单个系统的所有业务过程串接，用户在各个系统之间的串接，因此针对主题划分我们的思路是重点要考虑业务本身的特点等因素，按照当前业务所属的行业划分主题域，所属系统划分主题。
首先需要明确大方向和目标： 各种结构化、半结构化、非机构化数据，各种不同来源的数据在数据仓库中需要有明确分层和组成，相同的规范和标准，统一的口径和一致性的维度，从而能够让业务人员以一个较低的成本找到数据，理解数据的含义以及指标的口径，避免业务人员之间重复开发自己关注的指标，让数据呈烟囱式发展。
-
通用数仓： 这里主要存储一些通用的能力型数据，比如猎人风控系统、人工审核、云认证、微聊、隐私通话等，这些数据的特点是不分业务，只分接入方式和场景
-
业务数仓： 主要以业务诉求为主，建设满足行业分析的各种数据集合。因为信息安全治理工作同时也需要分析各个业务过程数据。
-
主题数仓： 以公司范围内公共的主题角度，以一致性维度为基础，跨各业务做数据的整合分析和相关建设，包括流量数仓、内容数仓、用户数仓等。
数据仓库之所以划分出通用数仓和主题数仓是因为通用数仓为了做到尽可能的通融，能够融合各个业务数据，比如招聘和房产之前的字段差异还是比较大的，因此这里在数据应用的便捷性上做出了很大的牺牲，那么业务数仓弥补这个缺陷，做到尽可能的给业务人员带来便捷而设计的。不知道大家有没有逛过宜家商场，在逛商场时用户会直接被引导到商场的二楼，在二楼不同的展区可以看到每件商品的实际效果展示，一旦相中了哪件商品可以按照商品编号去一楼的大仓库提货，那么宜家商场的二楼就好比我们的业务仓库，一楼就好比我们的通用数仓。那么通用数仓对了解数据技术，熟悉业务过程的开发人员来讲是比较友好的，业务数仓针对业务分析人员来说会更便捷的了解数据。
目前业界比较主流的实时数据架构有lambda和kappa架构，不同公司在这两个架构模式上设计出符合该公司的数据体系架构。 lambda 架构使开发人员能够构建大规模分布式数据处理系统。 它具有很好的灵活性和可扩展性，也对硬件故障和人为失误有很好的容错性。 而kappa架构解决了lambda架构存在的两套数据加工体系，从而带来的各种成本问题，但在处理全量历史数据、与HIVE兼容等情况仍然面临计算、存储等各种问题。
Lambda 架构将数仓分为离线层和实时层，相应的就有批处理和流处理两个相互独立的数据处理流程，维护成本高，但是数据可以进行交叉验证。
早期安全对抗也主要是以离线特征为主，但是随着业务的发展以及在风控治理过程中与黑产之间存在对抗性，往往当天的数据业务价值更高，所以信安对实时数据的需求特别旺盛，无论是数据指标的分析还是算法模型离线训练到线上的应用都需要事实数据，因为先有了离线数仓，后面需要补充实时数据部分，所以数仓流批一体方案很容易就演化成了lambda架构。但是使用lambda架构过程中随着业务的发展数据业务越来越多导致一下3类问题比较凸显：
-
需要同时维护实时平台和离线平台两套引擎，后期运维成本很高。
-
同时实时离线两个平台需要维护了套框架不同但业务逻辑相同代码，开发成本很高。
-
Kappa 架构它中间其实用的是消息队列，通过用 Flink 将整个链路串联起来。
在Flink 1.11 版本中，社区新增了一大功能是实时数仓，可以通过kafka sink端的数据实时写入到Hive中。正是这一流程打通使kappa架构的一套数据处理引擎能够更好的兼容流批一体的数据结构，在1.12 版本支持了小文件的自动合并，解决了小文件的痛点。只需要在 Hive 表参数中加上 auto-compaction = true，那么在流式写入这张 Hive 表的时候就会自动做小文件的 compaction。当前我们一些新的数据业务正在尝试使用此种方案。
数仓数据除了要给业务人员使用之外还需要为风控过程中各个系统提供数据，在系统对接中，线上系统多数情况下需要实时数据对接，但是我们常用的消息队列组件却没有元数据信息，这样会导致机器无法识别字段，因此数据字典便成为了整个数据仓库的核心部分，试想一下，如果Hive没有MetaSore会怎么样？ 是不是Hive SQL、Spark SQL、MapReduce等这些计算引擎都玩不转了。 正式因为有了数据字典，才让我们在线特征系统特征计算可配置化成为了可能。
我们为数据字典提供了统一的接入服务， 字典的核心为Hive MetaStore， 在中间层我们构建了流批一体的数据模型， 从而让kafka 这类的消息队列有了元数据，最外层， 计算中心中控台的字段配置、实时流字段提取、以及一些模型离线训练到在线应用实现0开发成本等提供了便利。
随着大数据技术的不断更新和迭代，数据管理工具得到了飞速的发展，相关概念如雨后春笋一般应运而生，由于最早的数据仓库到数据中台，在到现在的数据湖技术，当前我们也正在调研如何使用数据湖技术做到真正的流批一体，替代现有的Hive + Kafka模式。 同时随着业务风控引擎的不断完善，黑产的进攻行为也有非常大的变化，目前主要进攻对象是难以结构化的图像和文本的数据。 并且黑产会利用技术手段隐藏行为，大大增加识别难度。 信息安全必须寻找新的平衡点，去解决内容安全和行为安全的数据结构化与链路衔接的问题。 如何构建一个以数据为驱动的风控系统。 其实我们也一直在路上。
本文分享自微信公众号 - 58技术（architects_58）。
如有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。
