文 / 民生证券股份有限公司信息技术中心总裁 吴哲锐
民生证券股份有限公司信息技术中心数据科学负责人 楼轶川
证券公司数据治理的痛点
1.数据孤岛历史遗留问题积重难返
我们都知道，烟囱式的数据孤岛，一直是传统企业特别是证券公司进行数据治理的最大难题和痛点。究其原因，证券公司在早期的信息化建设过程中，通过和供应商合作的模式积累了大量信息系统以及其报表子系统，而不同的供应商之间技术体系、数据模型都不兼容。这就导致了证券公司进行数据治理体系初期，会面临需要投入大量精力进行数据资产历史沉疴的清理，然后才能投入资源进入新的数字化转型过程。这不仅给企业带来了大量初期的沉没成本，数据治理也由于成效慢，投入大而让部分企业怀疑数据治理的意义。
2.传统数据仓库建设周期过长，掣肘数字化转型
一般来说，通过建设统一的数据仓库来进行数据治理是一个通行办法。但是，根据数仓建设的经典方法论——维度建模理论，通常一个数仓的建设，需要在前期进行大量的数据需求分析，这就带来了新的两难问题：数字化转型初期大量涌现的新需求急需快速实施，而数仓又需要时间进行前期建设和分析。这样数仓的建设会始终慢于数字化转型需求，也会拖累数据治理体系的覆盖面从而产生新的数据孤岛，形成一定程度的恶性循环。
3.旧有技术和模型体系不能与时俱进，导致新需求不能被满足
除了上述两点痛点之外，在数字化转型过程中，证券公司还面临旧有体系需要与时俱进的问题。相关机构针对数据治理和架构发布了一系列数据模型和标准，如果证券公司遵循这些标准进行数据中台模型的建设，虽然降低了前期数据需求分析的投入成本，但是在实际使用中也会遇到模型标准已经老化，在数字化转型浪潮中涌现的大量新型数据分析、数据应用场景难以从模型中找到相应指标和解决方案的问题。然而，重新进行模型建设，又会回到上述第2点的难题中。
为此，民生证券通过近两年的新一代数据中台建设和数据治理工作，总结摸索出了适合自己的数据治理体系和实践经验。
民生证券数据治理探索过程中的实践经验与心得
1.坚持数据融合原则的数据中台建设理念
在解决数据孤岛的实践过程中，自底向上搭建统一的数据中台固然重要，但是能真正解决数据孤岛无序生长的办法，仍然需要遵循数据融合的建设原则。其中，要融合的不仅仅是数据架构体系，更需要将数据仓库与数据集市、OLAP与OLTP技术特性、经典证券数据模型与新时代数字化转型分析主题相融合，形成新的数据治理体系思想。
（1）不仅要坚持统一的数据中台，更要坚持“仓市一体”的设计原则。证券公司在进行数据治理建设时，凭着初期的投入和热情，往往会选择一款数据中台产品进行数据技术底座的快速搭建。这种做法本无可厚非，但往往进行到数据的统一采集、数据底层模型的统一设计和落地之后，后续的推进会受到各个业务系统及其数据子系统的数据兼容压力，而不得不最后沦为仅为下游各个系统自身数据集市进行数据分发的集散地。如此一来，数据集市中的计算逻辑重新回到了各个系统中去，数据治理工作前功尽弃。
因此，除了采用数据中台对所有数据采集、处理、作业和口径进行统一管理之外，民生证券在进行数据治理的初期，就定下了“仓市一体”的原则。在实践过程中，则是将数据治理与规划贯彻到所有业务领域的取数、用数中。各应用条线的项目立项、系统架构评审都增加数据评审环节，融合数据开发服务能力，将业务系统的数据集市需求统一归口纳管在数据中台中。这种建设过程的好处是多样的，通过了解业务系统的指标体系可以丰富数据仓库自身的指标体系储备，同时数仓和数据集市为一体的建设又能统一数据指标口径，保障数据治理的成果。例如在客户资产分析、全面风险管理驾驶舱的建设中，通过在模型层面与第三方咨询充分合作，采纳、融合其数据模型的精华，进而产出符合民生证券业务特色和数据应用规划的各类数据指标，最终推进各领域数据集市的建设与应用。
（2）依托SDOM，拓展SDOM，打造自有的证券业务数据模型SDOM+。证券期货行业数据模型（以下简称“SDOM”）是2019年底由证监会发布的一个数据模型，该模型借鉴了当时由IBM和TD主导的金融业的数据模型，并总结了我国证券业通行的业务模型，在业务领域具备了相当的专业性和权威性，对理解证券业数据领域有相当强的参考价值。
由于SDOM及IBM、TD等金融业模型大多基于范式建模，在实际使用星型维度模型进行建设时，会遇到模型转换的困难。同时，如果数据团队过往没有实际落地的数据分析需求和指标体系储备，只根据模型来建设数据集市，又容易陷入纸上谈兵、向壁虚构的困境。
因此，民生证券在建设证券业务数据模型时，坚持了借鉴、拓展、自研的原则。
首先，在数据治理的框架层面，行业标准对模型的稳定性和治理工作的指导有着定海神针的作用，因此我们仍然使用了SDOM模型中的主题域，同时参考SDOM的数据对象关系进行数据仓库底层DWD层和DIM层的建设。其次，为了兼容数仓领域近十年来的行业标准，使用了星型维度模型建模，参考SDOM进行了公司自己的模型转换过程。对于数据集市层面的治理工作，我们坚持“以用促治”的建设理念，在大框架依托SDOM的前提下，分别通过监管数据报送、经纪业务驾驶舱、客户账户分析、全面风险管理驾驶舱等实际项目来驱动上层的数据集市的建设和治理工作。
此外，针对SDOM主要描述证券业核心数据关系的特点，我们分析了常用到的互联网行为数据分析域，营销运营分析域，适当拓展了民生证券的数据模型主题，形成了自有的SDOM+模型。
在成功完成多个数据应用类项目后，公司领导和业务用户对这套基于SDOM、拓展SDOM、融合形成自有模型的治理模式给予了肯定，给公司决策层、数据用户、数据团队都提升了信心从而保证了数据治理的持续投入。
（3）使用融合技术，解决数据分发和技术口径问题。在数据治理的过程中，一个容易忽视是数据集成问题。作为数据仓库的产出，数据集市不仅仅提供数据分析结果，通常也会被推送至业务系统中使用，从而产生更大的数据价值。但是数据集成由于涉及异构数据库同步和推送，难免出现推送数据不及时、推送中发生数据类型转换错误、精度丢失等技术原因造成的数据质量难题。
为了解决上述问题，民生证券采用了融合了OLAP和OLTP两种数据特性的融合架构HTAP数据库来进行数据仓库的技术底座建设。具备了OLAP特性的数据仓库，可以提供高效的分析查询能力，而具备OLTP特性的数据集市，则可以提供可用的并发特性来支持业务系统的需求。而由于采用了同一个数据库来承载不同分层和功能的数据表，数据分发作业大幅度减少，降低了维护成本的同时，也解决同一份数据异构存储的技术口径难题。
2.以敏捷为目标，加速企业数字化转型过程
近年来，通过DataOps进行数据仓库的敏捷迭代与管理，越来越成为解决数据仓库建设周期过长问题的法宝之一。民生证券数据团队也以敏捷为目标，努力通过各种手段加速企业的数字化转型过程。
（1）DataOps，将人从冗余的数据运维工作中解放出来。说到数据治理方法论，始终无法离“统一”二字，即统一的数据开发流程、数据标准及数据口径。传统的解决方式，只能从团队的组织架构入手，设立治理专岗，来进行统一的数据治理工作。但是DataOps概念兴起之后，涌现了大量一站式的数据中台产品。通过打通开发、治理、测试、发布等多个数据建设的环境，将原本看似沉重的数据治理工作，融入到数据开发的生命周期中去，从而消解数据团队对数据治理的畏难情绪，提高数据开发的效率。
通过中台开发治理一体化能力，可以获得全生命周期的元数据。由于这些元数据自动采集获取，无需额外工作量，同时也有助于让企业中的数据资产实现“找得到、看得懂、信得过、管得了”。例如血缘追溯功能就是对数据开发帮助较大的一个功能。传统的人工数据血缘管理，需要耗费大量的人力进行登记和协同，即便如此效果也不一定显著，线上数据出问题或者上游数据出问题，排查影响范围往往需要耗费大量人力，而通过一体化中台自发现的血缘管理，则可以大幅度解放数据运维的工作。
另外，和数据作业深度耦合的数据勾稽、作业监控，可帮助团队具备快速定位问题的能力；自动化测试可在显著提高上线质量的同时加快上线节奏。
（2）全面拥抱微服务化，打造新型数据中台。微服务架构提出已有近十个年头，其能够有效降低业务系统复杂度，提升服务发布效率，降低服务运维难度的特点已深入人心，其思想原则也深刻影响了数仓向数据中台概念的转变。《证券期货业金融科技标准规划（2022—2025）》中明确提出，数据中台区别于传统数仓的主要点在于数据服务化，而建设DataAPI及服务网关是其重要能力。在民生证券的实践中也深刻地体会到，利用数据服务能力，可以大幅度拓展数据中台的能力边界，有效加速数字化转型。
与业务系统的微服务化有所不同的是，数据中台提供的数据服务大多以查询服务为主，其特点是结构化、标准化、脚本化，因此是非常适合改造为配置化平台。数据中台的服务架构大多以配置SQL和定义接口输入输出来提供敏捷的装配过程。民生证券的实践，也通过中台的配置服务，装配了大量查询接口以支持用数需求。
此外，如我们在融合章节所述，数据中台微服务架构，在结合了HTAP数据库之后，发挥出了更大的潜力。从此以OLTP性能指标要求的需求，也可以通过装配接口在HTAP数据库上提供高并发的服务。民生证券在客户账户分析相关数据服务接口开发中最先尝到了甜头，进而通过使用一站式的中台，迅速地交付各类业务数据需求。
（3）模型反哺BI，让业务自助分析成为可能。数据团队的主要工作职责之一，是通过BI平台提供报表服务，为企业决策、业务经营提供帮助。但是在日常工作中，频繁的取数和报表需求会慢慢将数据团队的工作变为单纯的取数制表，这不仅会消耗数据团队的人力资源，同时也因为拉长了取数流程导致业务数据分析效率降低。
通过梳理历史数据需求、进行系统的数据分析后建设的模型，由于有了业务支撑，形成了较为完整的指标体系。同时星型维度模型已经成为数仓领域事实上的行业标准，因此，利用SDOM作为业务依托建立的自有数据仓库模型，可以很方便地导入BI系统中，形成BI的逻辑模型。通过定义维度、事实、指标口径等简单的配置工作之后，即可以让用户在BI系统中通过拖拉拽的方式获取数据分析结果。由于用户可以快速通过BI得到想要的数据，提升了用户使用数据的积极性，反过来加大了BI的数据提供次数与效率。最后，用户自助取数形成习惯之后，还能有效减少数据团队的低效工作消耗，让数据团队可以更多投入在高价值业务数据开发与数据治理工作中。
3.理论和技术的创新，有效拓展数据应用边界
（1）新合作模式，探索双赢目标。在数据治理过程中，民生证券通过和第三方的深入合作来开展数据治理。主要方法为与第三方合作进行指标的分析和定义，将数据集市放入中台计算和纳管，指标通过接口或者数据推送完成在业务系统中的生命周期。在这个过程中，数据团队与第三方通过平行建设互相加深对数据集市的理解，扩展指标体系。第三方供应商也能加强产品能力，提升对外竞争力，形成共赢合作模式。
（2）新数据架构，打造真正的敏捷型数据中台。低代码、数据编织概念是近年来新流行开来的技术应用概念。如上所述，配置化服务是数据中台提供敏捷能力的一大途径。但是在数据服务被普遍推广之后，越来越多的业务技术团队希望数据服务也能提供简单的业务处理能力。由此，“低代码+配置化服务”结合产生的数据编排技术被应用到了民生证券数据服务体系中。例如在投行重要项目发行人企业风险筛查项目中，通过数据编排服务，数据团队成功地将查询、入库、计算、反馈等一系列简单的业务过程串联成一组数据服务接口，从而大幅度降低后端技术人员的代码复杂度，使得数据中台慢慢成为了各个业务系统的一部分，形成了真正的敏捷型数据中台的雏形。
（3）新数仓理论，扩展传统模型理论。传统数据仓库理论，即采用星型维度模型的设计方法，都离不开关系型数据库或者OLAP技术能力的支撑。因此即便星型维度模型脱离了范式设计，仍然不能脱离关系型代数的设计理论。即使如MPP列式存储等OLAP技术的加持下，提升大型数据表之间的关联查询性能仍然是技术难点。而业务模型本身带来的复杂数据对象关系也很难在SQL层面减少关联次数从而进一步降低性能。
为了解决这一难点，民生证券数据团队创新地利用了关系型数据库和NoSQL数据的融合技术，将二进制半结构化数据结构融入了模型设计中。例如在一些事实表中，通过类JSON字段存储退化维和子事实的数据，从而解决了一部分分析查询过程中关联查询性能的问题，同时也解决了OLTP类项目的性能需求。通过一致性的模型设计，再次证明了融合技术的优势。
（4）新分析探索，展望AI时代的分析模式。我们已经论证，让用户能够自助取数，能够提升用户的取数效率和数据应用积极性。但是在自助分析的推广过程中，仍然会遇到业务用户需要进行数据团队模型理解的过程，而一旦模型发生了一些变化，也需要同步和业务用户进行沟通，这无形中也增加了用户取数的难度。恰逢2023年年初，ChatGPT再次掀起了大众对AI的热潮，我们确信，随着对AI的认知和接受度越来越高，对话式应用也会爆发式出现。而通过NLP技术融合公司不断积累成型的数据模型和指标体系，训练出能够通过提问反馈数据统计指标和报表的对话式数据交互，一定能在自主取数用数的大趋势下，形成更加高效实用的新数据分析应用场景，从而进一步提升企业数据的资产价值。
文章来源：“金融电子化”微信公众号