汤奇峰, 虞慧群, 范贵生, 邵志清
(1.华东理工大学计算机科学与工程系, 上海 200237;2.上海数据交易所有限公司, 上海 200131)
数字经济是继农业经济、工业经济之后的主要经济形态,是以数据资源为关键要素,以现代信息网络为主要载体,以信息通信技术融合应用、全要素数字化转型为重要推动力,促进公平与效率更加统一的新经济形态[1]。数字经济正以前所未有的力量推动生产方式、生活方式和治理方式深刻变革。充分发挥海量数据和丰富应用场景优势,促进数字技术与实体经济深度融合,赋能传统产业转型升级,成为我国社会经济和区域发展的重大机遇[2]。
由于数据交易是数据流通和价值实现的关键环节,数据交易设计、实现及验证技术研究成为学术界和工业界的关注热点方向。文献[3]提出了一种隐私保护的群体感知数据交易框架,并给出了参与者的信誉模型,以保障参与者的可信性。文献[4]提出了一种改进的多目标遗传算法——协作式NSGAⅠⅠ,通过数据生产者(DP)、数据消费者(DC)以及数据聚合器(AG)的协作进行计算。针对当前数据交易过程中数据容易被拷贝以及数据保密的问题,文献[5]提出一种基于区块链与可信计算的数据交易方案。文献[6]对基于区块链技术的数据交易模式进行综述分析,并讨论区块链和数据交易结合所面临的挑战和可能的解决方法。文献[7]提出了一种基于偏差约减的大数据交易模型修复方法,通过过程模型的可达标识图发现事件日志与模型之间的偏差关系,对事件日志与模型之间的偏差进行约减。文献[8]研究了各种数据定价模型,将它们分类为不同的组,并对这些模型的利弊进行了全面的比较。数据交易系统涉及多个系统及模块,通过协作才能完成数据交易。模型驱动架构(Model-Driven Architecture,MDA)关注系统高层模型,系统模型通过描述系统成分及成分之间的相互关系,反映设计者对系统结构和行为的设计构想。然而,数据交易在生态平台层的理论模型及设计和分析技术方面的工作还阙如。如何构建数据交易的软件结构模型,对于数据交易平台的功能设计和性能优化至关重要。
面向方面程序设计( Aspect-Oriented Programming,AOP)利用“横切”的技术,将那些影响多个类的行为封装到一个可复用模块(即方面),降低模块间的耦合度[9]。为了解决上述数据交易模型设计面临的问题,本文基于AOP 提出了数据交易自适应软件模型设计方法。该方法融合了形式化理论、数据驱动软件工程以及AOP 方法,建立了自适应数据交易系统的软件结构设计框架。数据交易过程的形式化建模由单元模块通过层次化的组合构造而成,包括数据交易过程中个体的建模、数据交易相关服务的建模、数据各个任务模块的建模和方面模型构建。基于Petri 网形式化方法为数据交易模型提供了数学表达和分析手段。最后,通过仿真实验说明所提方法的有效性和可行性。
自适应数据交易系统软件结构设计框架采用面向方面编程思想对数据交易系统的需求进行解析,分为基本模块和方面模块两部分,如图1 所示。基本模块主要包括任务和服务,其中任务和服务主要包括数据交易过程涉及的相关任务和服务。方面模块主要为调度功能,负责对交易过程进行监测和集成,根据方面所处的层面可分为任务层、交易层和 调度层3 个方面。基于Petri 网和模型库方法研究数据交易系统的形式化模型和控制策略实施。
该框架构建包括需求抽象、模型定义、形式化建模、动态编织、模型验证5 个主要步骤:
(1)需求抽象:以数据交易系统应用为驱动,进行需求抽象,提取系统的多维关注点集、交易场景及其关系,给出数据交易系统需求,包括交易任务、服务、关注点、场景等。
(2)模型定义:基于Petri 网提出数据交易系统的层次形式化描述语言,给出变迁、库所和个体等模型基本元素的实际映射,探索相应模型执行语义以描述系统的动态和静态特性等;
(3)形式化建模:对关注点集、关注点之间关系和控制策略进行建模以形成一个通用的模型库;
(4)动态编织:根据系统基础元素及其关系构建数据交易系统的基础网模型,并根据编制规则在基础网上动态织入控制策略横切关注点以形成不同场景下的形式化模型;
(5)模型验证:基于模型执行语义构造模型的状态空间,利用Petri 相关理论分析模型的一致性、执行正确性等。
由于数据交易系统的功能是由多个独立运行的组件构成,根据AOP 思想可知数据交易系统的执行流程为核心关注点,而横切关注点是指系统的非功能需求,本文主要指组件的属性和一些控制措施[10]。如无特殊说明,后面所涉及的关注点均指横切关注点。
定义1 数据交易系统的软件结构设计需求是Γ={ DP, DC, PW, WS, TK, Rq, YW}:
(1)DP 是数据提供方集合,二元组(pid,cr)分别表示提供方标识符和信誉等级,本文假设标识符唯一。
(2)DC 是有限数据产品集合, PW 表示其属性函数,包括数据产品提供方、价格、数据量、测试数据集、数据规模、产生时间等。
(3)WS 为数据交易服务集, TK 为有限的任务集。
(4)Rq 是数据需求集合,YW 是有限的业务流程集合,每个业务流程对应一个数据交易需求,其中每个业务流程YW=(subT,RL),其中:subT 是有限任务集,标记TKi,j表示业务流程YWi的第j个任务;RL:subT× subT→{>,||,+,∇},>,||,+,∇分别表示顺序、并行、选择和互斥关系。
数据交易中服务类型包括数据合规评估、质量评估、资产评估、挂牌审核、数据测试、概念验证(Proof of Concept,POC)、数据交付[11]。
(1)数据合规评估服务主要由合规安全评估商提供,服务流程包括明确评估范围、制定评估计划、开展合规性评估、选取合规评估手段、数据安全风险分析、编制数据安全评估报告、评估交付。
(2)数据质量评估服务由数据质量评估商提供,使用质量评估模型、产品,提供质量评估服务,对数据产品的质量进行各种纬度的评估,采用某种评估模型进行评估。
(3)数据资产评估服务由数据资产评估商提供,帮助数据产品提供方进行数据资产的梳理、分析、评估。具体流程主要包括质量价值和应用价值计算、案例对比分析、数据读取、选择评估方法、构建评估模型、价值评估等。
(4)挂牌审核服务由数据交易所提供,主要依据《数据交易所挂牌规范》 所描述的审核要求,对挂牌主体、数据产品与限制描述依据不同板块要求进行一一审核。数据交易所会对供方交易资格进行审核,对可交易数据产品的合规性、可交易数据产品质量、数据密级程度进行评估。单项要求均需达到交易要求方可审核通过。
(5)数据测试服务由数据交易所提供,在数据使用上以Notebook 方式提供给用户进行Python编程,对数据集进行交互式分析体验。交易所从数据产品使用形态分类提供APⅠ形式数据在线调用体验、数据集实行数据产品在线编程体验两种体验。被动体验包括数据统计学分布报告和基于应用场景的数据画像。
(6)POC 测试服务由交易所提供,是针对数据具体应用的验证性测试,根据用户的性能要求和扩展需求指标,在服务器上进行真实数据的运行和实际测算。主要包括环境搭建、测试案例设计、脚本编写调试、功能测试、组件测试、性能测试、可靠性测试等。
(7)数据交付服务由数据交付生态服务商提供,利用服务商自身数据交付产品对数据交易的甲乙两方进行数据交付服务。主要流程有交付请求、调用APⅠ接口、容器操作、交付。可采取的交付方式主要有基础数据包、应用程序编程接口和分析产品。
数据交易中任务类型包括数据登记、数据挂牌、数据交易、数据交付、资金清算。
(1)数据登记任务是指数据供方完成数据产品的登记,登记的内容主要包括登记主体、数据产品描述、数据产品来源证明等。
(2)数据挂牌任务是指数据供方完成数据产品的发布。被授权或拥有已登记的数据产品的供方才可成为挂牌主体。
(3)数据交易是指供需双方对可交易数据产品依照既定交易过程进行的活动,涉及到数据供方、数据需方和数据交易所,按照流程完成交易,形成交易合约。
(4)数据交付任务主要完成数据交易过程中的数据交付(数据交割)行为,是交付方从数据交易所接收交易相关信息,帮助数据产品使用方和数据产品提供方进行数据交付。
(5)资金清算任务主要完成费用清结算行为。数据交付完成后,由数据交易所对数据交付服务机构传入的结果(含交易量和交易金额)进行审计、清结算。
Petri 网既有严格数学和直观图形的表述方式,又有丰富系统描述手段和行为分析技术,可以广泛应用于描述和分析系统中控制流和信息流。因此,Petri 非常适合描述数据交易系统及生态这种松耦合的分布式系统。根据数据交易系统建模需求对Petri 网进行扩展,采用文献[12]所提出的模型对数据交易过程进行建模。
将所有数据产品都抽象为个体。数据DCi建模为个体dDCi=(DC,i, RW(DC,i)),个体属性RW(DC,i)表示数据产品DCi的数据产品提供方、价格、数据量、测试数据集、数据规模、产生时间等属性。同理可以将数据提供方、数据需求方、交易过程涉及的服务、资源等都建模为个体。
根据服务内在的执行流程,对服务进行建模。下面以数据合规评估、数据测试、数据交付服务为例给出服务形式化模型及其映射。
2.2.1 数据合规评估服务 数据合规评估服务主要由合规安全评估商提供,其建模如图2 所示,具体数据合规评估服务执行流程如下:
图2 数据合规评估服务的建模Fig.2 Modeling of Data Compliance Assessment Service
2.2.2 数据测试服务 数据测试服务的建模如图3所示。具体执行流程如下:若≠ ∅ ,即存在用户调用数据测试服务,则触发变迁tst执行服务开始操作,同时服务进入等待主动体验位置pwzdt和等待被动体验位置pwbdt;对于主动体验模式,选择触发变迁tbxzd执行放弃主动体验操作,则服务进入放弃主动体验位置;触发变迁txzA执行选择APP 调用体验操作,则服务进入等待APP 调用体验位置pwzA;对于被动体验模式,触发变迁tsbdt执行开始被动体验操作,则服务可同步进入等待统计位置pwtj和等待数据画像开始位置pwhx;若主动和被动都体验结束,则触发变迁tecs执行数据测试结束操作,输出审核结果到服务的输出接口,同时将结果备份到数据测试结果备份位置pcsb。
图3 数据测试服务的建模Fig.3 Modeling of data test service
2.2.3 数据交付服务的建模 数据交付服务的建模如图4 所示。具体执行流程如下:若≠ ∅ ,即存在用户调用数据交付服务,则触发变迁tst执行服务开始操作,同时服务进入等待数据交付方式选择位置pwxjf;变迁txsb、txAPⅠ、txfx分别执行数据包、APⅠ程序编程接口、数据分析报告3 种交付方式的选择操作;引入变迁ttm、tab、tcs、tbs分别描述数据包交付方式的数据脱敏、安全保护、传输、部署操作。其中数据安全保护和传输是同步运行;若交付结束(即库所pejf不为空),则触发tejf执行数据交付结束操作,输出审核结果到,同时将结果和日志备份到库所pjfb。
图4 数据交付服务的建模Fig.4 Modeling of data delivery service
根据任务的内在逻辑,对数据交易相关任务进行建模。下面以数据登记、数据交易任务为例,给出任务形式化模型及其映射。
2.3.1 数据登记任务模块的建模 数据登记任务是指数据供方完成数据产品的登记。数据登记任务模块的建模如图5 所示,具体执行流程如下:若≠∅,存在数据产品输入到数据登记任务模块,即有数据产品需要登记。若任务初始位置ps,则触发变迁tst开始数据登记操作。数据产品分别进入等待数据合规检查、数据质量评估、数据资产评估3 个位置等待数据产品评估机构提供相关服务。变迁tshg,tszp,tszc并行执行,用于启动数据合规检查、数据质量评估和数据资产评估3 个服务,初始化各个服务的输入信息到对应的输入接口库所pshg,pszp,pszc。变迁thgfw,tzlpg,tzcpg分别表示数据合规检查、数据质量评估和数据资产评估服务的替代节点。引入库所phgjg,pzlpg,pzcpg分别用于存放可以提供数据合规检查、数据质量评估和数据资产评估服务的机构个体(每个机构建模为一个个体)。触发变迁tsht完成数据产品登记审核通过操作,输出登记结果到数据产品登记结束输出位置,同时在数据登记结束备案库所pdjb存档。
图5 数据登记任务模块建模Fig.5 Modeling of data registration task module
2.3.2 数据交易任务模块的建模 数据交易是指供需双方对可交易数据产品依照既定交易过程进行的活动。数据交易任务模块的建模如图6 所示:若任务初始位置pssj,则触发变迁tsj开始数据交易操作;触发变迁tssfx启动数据发现操作,通过交易所交易大厅中的数据产品目录查看数据产品说明书,发现所需数据的数据产品,同时任务进入数据发现位置pssfx。后面触发变迁tfxcp启动数据产品存放操作,任务进入等待数据交易位置pdjy;引入变迁txscs,txPcs,txzcg选择执行,分别用于触发任务进入数据测试、POC 测试和数据交付3 个服务等待启动位置pwscs,pwPcs,pwzcg。其中数据测试和POC 测试服务是可选的功能模块。若任务处于服务等待启动位置pwscs,pwPcs,pwzcg,则可以分别触发变迁tsscs,tsPcs,tszcg初始化各个服务的输入信息到对应的输入接口库所pscs,psPcs,pszcg。变迁tscs,tPcs,tzcg分别表示数据测试、POC 测试和数据交付服务的替代节点。引入库所pcssj,pPcsg分别用于存放的数据测试集。最后触发变迁tsjyj完成数据交易结束操作,输出交易结果到数据交易结束位置pjyb存档,同时在数据交易结束输出位置。
图6 数据交易任务模块建模Fig.6 Modeling of data transaction task module
方面模型对交易状态进行监测和交易决策。将交易调度的描述按照切入的对象和目的不同,分为任务-服务调度、请求-任务调度和调度处理3 个方面模块。模型集成由基本模块和方面模块通过AOP 编织机制实现。
2.4.1 调度方面模型
调度元对象根据交易流程提交的任务集计算具体的可用数据产品集,并及时通知服务执行。最后将服务执行的结构反馈给用户。
(1)任务-服务调度方面模块
在数据交易执行过程,任务需要调用一些服务来完成对应功能。所以方面模型需要对任务与服务间调用关系进行建模,并将其抽象为任务-服务调度方面模块。
其次,任务层TKi如果收到服务执行结果(≠ ∅ ),则触发变迁ttew根据服务类型将服务结果转发到对应服务结束库所。
(2)数据需求-任务的调度方面模块
每个数据交易需求完成是根据业务流程调度对应的任务执行完成。将需求和任务间的调度过程建模抽象为需求-任务调度方面模块。
首先,对于每个任务输出的调度集,引入库所pdwj表示任务TKj的调度输出接口。通过触发变迁tdwj将任务TKj的调度方案存到请求层输出接口。
其次,若交易请求Rqi∈ Rq 收到服务执行结果(≠ ∅ ),则触发变迁tqew根据服务所执行的任务将服务结果转发到任务的服务结果输入接口。引入库所pwt1,pwt2,…,pwt|TKi|分别表示各个任务的服务执行结果输入接口。
(3)调度处理方面模块
对于整个数据交易模型,将如何根据调度方案触发相关服务并反馈结果至请求过程抽象为调度处理方面模块。
首先,对于每个交易请求输出的调度方案集合,引入库所pwi表示交易请求Rqi的调度输出接口。通过触发变迁twi将请求Rqi的调度方案存到等待库所paw。
其次,调度层通过触发变迁tsw根据paw库所收到的服务调度方案,将任务基本信息输出到对应不同服务类型的调用库所。如库所pswhg、pswjf分别表示数据合规服务和数据交付服务的调度用库所。通过触发变迁tswhg从库所ppwhg中选择数据合规服务提供商,并进入数据合规服务执行阶段,即输入个体到数据合规服务的输入接口pshg。同理,可以通过触发变迁tswjf从库所ppwjf中选择数据交付服务提供商,并进入数据交付服务执行阶段。
若调度层收到服务结果,则触发对应变迁汇总所有服务结果到库所pew,然后根据服务所执行的任务,将其结果通过触发变迁tew转发到相关用户请求接口。引入库所phgtg、pezp、pezcp、pegsp、pecsg、pePcg、pejfp分别表示数据合规审核服务、数据质量评估服务、数据资产评估服务、数据测试服务、POC 测试服务和数据交付服务的输出接口,每个接口都引入对应的变迁执行结果汇总。引入库所pew1,pew2,...,pew|Rq|分别表示各个交易请求的服务执行结果输入接口。
2.4.2 模型集成 设数据交易调度需求Ξ的模型Ω构造步骤如下:
(1)根据交易请求流程中任务的属性及其关系(参照文献[12])。构造系统中所有任务、数据请求的数据交易模型。由于模型主要考虑交易任务的执行流程,引入ps、ts表示数据请求的初始位置和初始化操作,设置所有请求的M0(ps)=φ,即所有的交易流程处于等待开始。pinj表示任务TKi,j的输入接口。
(2)根据数据服务的属性,构造所有数据服务的模型,并设置相应的初始资源分布。
(3)根据方面模块的定义、服务、任务、请求的关系,构造自适应数据交易模型,将具有相同含义的库所和变迁合并。
通过建模,数据交易的执行流程映射到模型上是一组由变迁集组成的触发序列。因此,通过分析模型的可达状态属性可以对数据交易执行过程进行动态分析和验证。为了区别不同层面或者模块的变迁和库所,在变迁或库所前引入所属对象进行区别,如TKi,j·tkqjf表示任务TKi,j模型中的变迁tkqjf。如无特殊标记,则说明该变迁或库所处于顶层。
数据交易流程的正确建模体现为任务是否可以得到执行、服务是否可调用、用户请求是否会到达结束状态。下面从以下几个方面展开验证。
定理1:设S0是数据交易模型Ω的初始状态,R(Ω)是对应的可达状态集,则有:
证明: (1)数学归纳法, ∀TKi,j∈YWi, 设Fork(TKi,j)={ TKi,f| RL(TKi,f, TKi,j)=>, TKi,f∈ Rqi}为任务TKi,j的前向任务集。根据TKi,j在执行过程中与其余任务的关系可分为两种情形。
情形(a) Fork(TKi,j)= ∅ :即TKi,j不需要其他任务的运行结果,系统可以直接执行。根据用户请求的数据交易模型构造过程可知,因M0(Rqi·ps)≠ ∅ ∧ ·ts=Rqi·ps,所以ts∈FT(S0) 。所以存在S1∈R(Ω)使得|M1(Rqi·pinj) |= 1。因为Rqi·pinj和TKi,j·pin是等价的,表示任务的输入接口。即|M1(TKi,j·pin) |= 1,令S’=S1,可得∀TKi,j∈YWi,∃S∈R(Ω),M(TKi,j·pin)≠ ∅ 。
情形(b) Fork(TKi,j)≠ ∅ ,设∀TKi,f∈ Fork(TKi,j),∃S’∈R(Ω),使得M’(TKi,j·pin)≠ ∅ ,证明TKi,j满足子命题(1):不妨设Fork(TKi,j)={TKi,f,TKi,g,…,TKi,k}, 根据命题前提可知TKi,j的所有前向任务都有可能执行。所以存在S1∈R(Ω),使得|M1(TKi,f·)|= |M1(TKi,g·)|=…=|M1(TKi,k·)|=1。因为RL(TKi,f, TKi,j)= RL(TKi,g,TKi,j)=…=RL(TKi,k, TKi,j)=>,根据任务间关系的建模可知,模型中存在对应的变迁将TKi,f, TKi,g,…, TKi,k的运行结果汇总给TKi,j。即存在S2∈R(S1)使得|M2(TKi,j·pin) |≠0。
综上所述,子命题(1)得证,∀TKi,j∈TK,Ω,S0|=AGϖ1,其中ϖ1为TKi,j·ts∈FT(S)。
同理可证子命题(2)~(3)也成立。
定理1 说明,在数据交易模型中任意一个任务都可以被执行,任意一个用户请求都有可能执行完成,任意一个服务都能触发。据交易模型中可以正确刻画数据交易中任务间关系、用户请求流程、服务执行等过程。因此利用数据交易模型可以有效描述数据交易系统的执行逻辑。
针对数据交易流程、数据特征及其约束,随机生成500 个用户请求,每个用户请求的任务数及其关系可以随机设置。每个用户请求的业务流程可以包含数据登记、数据挂牌、数据交易、数据交付、资金清算任务。随机生成500 个可用服务(设每类服务至少具有20 个以上可用服务),随机生成任务与可用服务之间的映射关系。以下通过两个实验分析数据交易模型对于不同规模业务需求及可用服务的适应性。
实验1:目的是分析数据交易模型状态空间与用户请求数的关系,具体实验步骤如下:
(1) 分别取50、100、150、200、250、300、350、400、450、500 个用户请求作为整个数据交易的需求。取500 个可用服务作为需求的总可用服务集,要求每类服务至少有50 个可用服务。
(2) 将500 个用户请求分为10 组数据交易的需求。取100 个可用服务作为可用服务集,每类服务至少有10 个可用服务。
(3) 构造数据交易的模型,分别计算每个模型的状态空间大小,如图7 所示。
图7 模型状态空间与用户请求数的关系Fig.7 Relationship between model state space and user requests
分析图7(a)可知,当用户请求个数逐渐增加时,数据交易模型的状态空间整体上呈增加趋势。分析其原因是因为新增加的请求使得服务上处理的任务数发生增加。此外,任务的属性也是不一样的,所以请求个数的增加也会使得系统需要更多的任务异步完成,从而导致模型的状态空间增加,但是增加的比例不是固定的。随着用户数的增加,后面状态数逐渐趋于稳定。
分析图7(b)可知,当用户请求个数一样时,每个需求的模型状态空间大小也会有波动。分析其原因是因为虽然用户请求数一样,但是用户所包含的任务数不一样,进而导致完成所有请求所需要总的可达状态数不一样。
实验2:目的是分析数据交易模型状态空间与服务数的关系,具体实验步骤如下:
(1) 随机取100 个请求作为数据交易需求,每个请求的任务数是不确定的。
(2) 随机取30、50、80、100、130、150、180、200 个可用服务作为需求的可用服务集,要求每类服务至少有1 个可用服务。
(3) 分别根据任务、用户请求、服务的属性,构建每个需求的数据交易模型,分别计算每个需求模型的状态空间大小。
实验2 的仿真结果如图8 所示。分析可知:虽然用户请求数一样,但是随着服务数的增加,数据交易模型的状态空间呈下降趋势。分析其原因主要为(1)服务数的增加,导致任务可调用的可用服务增加,进而引起越来越多的变迁可以并发运行,所以可达状态数呈下降趋势。(2)随着总服务数增加,状态空间不是递减的。分析其原因是因为增加的可用服务类型不一样。如增加急需服务,则状态空间出现明显减少;若增加已经满足调用需求的可用服务,则状态空间变化较小。
图8 模型状态空间与可用服务数的关系Fig.8 Relationship between model state space and services
根据实验1 和2 的结果可知,数据交易模型状态空间与用户数、需求业务流程和可用服务数均相关,且整体上可达状态数是有限的。所以可以利用数据交易模型对数据交易流程等进行验证和分析。
数据交易是数据流通的核心环节,数据交易系统的正确性、可维护性和高效性是数据要素市场有效运行的重要支撑。本文提出了一种数据交易自适应软件模型构建及验证方法,该方法中数据交易模型由各个模块通过层次化的组合构造而成。通过面向方面建模方法实现 数据交易过程的自适应演化,并对方面模型与基础模型进行编织得到综合的数据交易模型。基于 Petri 网的形式化方法为数据交易模型提供了数学表达和分析手段。最后通过理论分析和实验表明,该设计方法具有可行性和高效性。进一步的研究方向包括基于模型的数据交易安全设计和应用。