0 引　　言

传统的数据中台主要服务于数据的分层与属性分离, 具有沉淀公共数据的能力. 数据中台是通过数据技术对海量数据进行采集、计算、存储、加工, 同时统一标准和口径的一种共享平台. 其最早由阿里巴巴于2016年的研究报告中提出, 目的是帮助实现全局数据规范, 力图将技术平台开发的功能充分反哺到前端应用^[1]. 阿里巴巴数据中台出现的缘由则是来源于其内部众多业务部门千变万化的数据需求和高速时效性的要求, 既要满足多个业务前台的数据需求, 同时还要应对大规模数据的线性可扩展问题以及复杂活动场景业务系统的解耦问题等^[2]. 不过, 数据中台的概念目前仍过于宽泛, 业界亦无行业性标准. 在国内科技公司竞相展开大中台规划的时候, 阿里巴巴首席信息官张建锋近些年则在不同场合提出了业务中台的架构思想. 所谓的业务中台是指所有应用系统都必须与之建立联系, 以便更好地实现企业核心业务运行机制的一种整合型体系系统. 张考虑使用业务中台与数据中台融合创新的新思路来进一步细化中台职能. 但是, 数据中台和业务中台融合过程中存在的突出问题是数据交互的效能问题. 在中台间多股业务流和数据流交互传输时, 很难明晰出一条完整的业务与数据处理过程. 内生性的业务信息与数据信息的杂糅, 导致业务流的溯源、数据流的调度变得烦琐, 数据交互的安全性也面临着一定的挑战. 因此, 如何确保在安全情况下提升中台间内生性数据交互效能以推动中台建设是亟待研究的问题.

针对上述问题, 本研究使用区块链技术来对交互的数据进行拆分. 区块链技术作为一种点对点的新兴计算机技术, 可以在解决业务溯源困难、数据调度粗略问题方面提供可能途径. 借助区块链技术特性, 一方面赋能“数据+业务”的双中台系统在数据安全流转和数据安全存储方面的隐私保护; 另一方面借助共识机制和经济模型, 融合区块链生态的资源来对实际落地场景进行技术融合创新. 区块链技术融于双中台, 但并不会侵入相关中台业务, 而是类似作为中台系统的底层技术进行赋能, 避免了区块链技术直接对海量数据进行处理的低效率问题. 利用区块链公开透明、难被篡改等优势, 能够对已经处理过的有价值数据进行流转、存储及追溯, 从而最终服务于数据交互效能的提升.

本研究根据中台中交互数据源的不同, 将业务流信息和数据流信息放置于基于区块链的业务链和数据链上分别进行存储, 进而提出了一种面向双中台双链架构的内生性数据交互协议. 通过该协议, 核心数据信息通过集合中台中一定数量的信息主体对上链数据信息进行授权, 将合法信息批量传入指定区块链. 同时, 抽离协议中核心的门限签名算法构造内生性数据交互流转的模型. 通过实验, 分析算法在进行数据交互时的时间开销, 并与传统的链上单一签名、验签进行比较, 证实了该协议在改善数据交互效能上具有一定的优势.

1 研究基础 1.1 数据中台现状

不少学者为推动中台的发展做了相关的研究, 概括而言, 目前的数据中台的阶段模式可以分为以下三种.

第一种是阿里巴巴最初提出的数据中台, 主要是为了在“大中台, 小前台”的业务战略下进行数据化的实践^[2], 通过划分不同业务边界然后进行业务建模, 进而指导系统的服务化建设. 在延续阿里巴巴提出的数据中台战略思想的基础上, 邓立君提出紧跟大数据时代的发展潮流, 通过融合数据中台到大数据中心的建设中, 实现对所有业务进行数据化处理, 以充分发挥数据资产价值^[3].

第二种是业务中台. 根据业务需求的不同, 划分不同业务边界然后进行业务建模, 进而指导系统的服务化建设. 对于业务中台的作用, 宫志奇认为业务中台能够解决效率问题, 同时也能降低业务创新成本^[4]. 而赵冠东等学者则是考虑基于业务中台技术对全渠道运营支撑平台架构进行改良设计, 主要包括运营活动、运营渠道管理以及监督预警, 并研究了部署方式和面向电力营销的运营支撑平台的业务内容^[5].

第三种是碎片化中台. 在前两种数据中台的基础之上, 根据业务或职能进行更细粒度的拆分, 使得中台碎片化, 以降低成本, 进一步提高组织效率. 在此类中台实践中, 付威认为数据中台遵循高度集中化与可复用原则, 可在中台基础上将服务组件快速封装起来, 提供给前台便利使用^[6].

传统数据中台功能过于集中化, 而在真实的业务场景下, 系统往往需要通过不同的业务服务来获取业务所需要的数据. 这种方式即便考虑用分布式系统架构来实现传统的数据中台相关功能, 技术上仍然存在缓存穿透、造成雪崩效应的问题. 为解决这一痛点, 通常的做法是进行数据治理, 可以实现更高效地提升高并发业务场景下的计算和存储能力^[7-8]. 但考虑到业务的需求分析会随着不同时间点动态变化, 如果不能对新业务进行及时处理^[9], 也无法做到在技术上根据需求的特性进行持续功能迭代和技术更替, 那么数据治理的效益将会大打折扣. 因此“数据+业务”形式的双中台架构逐渐进入产业界中.

1.2 “数据+业务”双中台

典型的“数据+业务”双中台架构将数据处理与业务服务按照逻辑顺序及处理对象属性进行并列设计, 使得业务上的需求分析能够及时得到反馈, 有助于缓解现有数据平台中单一数据中台业务冗余的技术痛点, 达到有效进行数据治理的目的. 同时业务中台的剥离, 还有助于一部分业务信息能提前进行预处理, 从而提升业务处理效能. 具有普适性的“数据+业务”双中台架构如图1所示.

从图1的左半部分业务中台可以看出, 业务中台的基础件是由业务中的微服务平台、分布式数据库、消息队列和应用监控组成的, 上层则根据业务主体的不同, 分配不同的服务、权能和管理措施. 右半部分数据中台的基础件是由数据采集、数据分析、数据服务和数据安全四个部分组成, 数据中台中会依照不同的算法模型对不同的数据进行不同的处理. 在风险控制模型中, 需要对主数据的安全性、质量进行评估分析; 在采集模型中, 需要对上传的数据进行归类, 收集整合同类业务数据进行后续处理; 对于计算模型, 主要是根据业务需要提取数据中的关键信息进行分析计算, 然后给出对应的处理结果. 此外, 数据中台还会向外提供数据查询的接口并给出相应的数据接口配置, 方便根据服务需求进行调整, 然后调用.

在这种双中台架构下, 进行业务分析时, 使用业务中台进行处理; 进行数据分析时, 则使用数据中台进行处理, 从而减少业务和数据的耦合度. 与此同时两者还能相辅相成、互相改进, 形成增强闭环, 并进一步降低各中台中信息的冗余, 提升一定的计算效能.

1.3 基于区块链技术的双中台架构

在数据中台逐渐丰富和完善的同时, 区块链技术也在走向成熟. 例如, 毕娅等人就提出了一种用户信息链和交易链的双链结构, 在保证用户隐私的同时, 将业务信息与交易数据进行拆分, 减少了节点记录信息的冗余量^[10]. 再如, Gai等提出了用于融合区块链和数据中台以创造附加价值的概念模型^[11]. Li等人也给出了一种使用区块链技术来实现整个数据生命周期中的数据跟踪的方法^[12].

鉴于上述先行研究, 在双中台的基础上, 为了在数据安全可信的情况下更好地对数据信息和业务记录进行管理, 本研究也引入了基于区块链技术的双链架构^[10]. 根据具体业务和数据读取的需要, 将具有不同共识机制、不同经济模型、不同交易处理能力的区块链进行组合, 以便借助不同的区块链生态力量搭建最符合实际场景的业务体系. 具体的双链架构设计如图2所示.

双链架构依据数据链和业务链进行拆分, 并最终服务于一个应用中处理. 数据链的区块中存储的是数据信息, 业务链的区块中存储的是业务记录. 根据业务和数据特性, 架构中数据链是作为私有链, 而业务链可以是公有链, 也可以是联盟链. 然后根据数据、业务记录的具体信息决定是采用默克尔树(Merkle Tree)结构存储的区块链还是用默克尔帕特里夏树(Merkle Patricia Tree)结构存储的区块链. 同时对于双链架构并不仅限定数量为两条链, 而有可能是以数据类型和业务类型所区分的两种链. 每一种链均可以由具体的去中心化应用(Dapp)或调用服务来进行协同通信.

这样的实现方式会在内生性数据交互上有以下三个方面的好处: 1)链上的任意用户节点可以在不知道隐私数据信息的情况下查看大致的业务处理情况, 这样就在保证数据安全的同时, 也保证了业务记录的真实可信; 2)将业务记录和数据信息拆分开来, 相比单链处理, 同一时刻能够减少大部分节点记账信息的冗余, 一定程度上提高了系统的吞吐量性能; 3)方便系统运维和管理, 能够在逻辑上进行业务的平滑扩展.

结合上述的基础知识, 本文给出双中台双链架构下的数据交互过程, 如图3所示. 首先, 将某个数据源输入数据中台, 由数据中台采集数据后, 对数据源中的信息进行安全分析. 然后经过数据中台周转, 将信息存入数据链. 与此同时, 抽离出数据源的业务数据交由业务中台进行处理判断. 对不同主体进行不同的业务处理, 然后将其传入业务链中进行保存, 并根据业务需求输出结果反馈, 即实施业务服务.

如果业务主体需要进行相关服务, 那么需要经过业务中台的业务服务进行访问, 由业务服务反馈给业务中台后, 向数据中台请求相关数据的调用, 并记录此次业务数据到业务链. 数据中台收到请求后进行合法确认, 然后调用数据链上的内容进行返回, 最终将内容反馈给业务主体. 因此, 双中台的架构设计既有效地提高了数据在业务链路分片的准确度和效率, 同时减少了数据耦合, 有利于在未来业务中对数据集进行预分类. 而且, 在以双中台架构为核心的基础上融入双链架构, 对比单一区块链结构更有效地利用了解耦思想来对上链信息进行合理区分. 在不使用效率和性能相对低下的跨链交互技术的同时, 还能够最大限度地减少区块链数据的并发数据量, 提高吞吐量, 极大地提高了双中台双链系统的整体效能.

但是, 在充分利用双中台双链架构的技术优势之时一个无法回避的问题也随之产生, 即为了充分利用区块链公开透明、全程加密、安全追溯的优势, 在双中台与双链之间做签名和验签时会面临低效的问题, 因此设计一个相对高效的交互协议来提升交互效率就显得尤为重要.

2 一种面向双中台双链架构的内生性数据交互协议

针对以双中台为核心的分布式系统和去中心化区块链系统间的数据协同中的效能问题提出以下的协议. 如图4所示.

结合图4, 以业务中台和业务链间数据交互为例, 研究中的协议核心部分按照舒普(Shoup)门限签名算法^[13]来对业务主体传输的业务记录进行授权后上链. 一方面舒普门限签名中签名的生成和验证是完全非交互的, 减少了不必要的传输开销; 另一方面舒普门限签名者身份防伪造, 实现了各个业务主体间的权利均分, 避免了滥用职权上传恶意业务记录. 下面给出这个协议中主要算法的详细步骤.

第一步: 需要由中台中设定的可信中心随机选取一个多项式 $f(x)$ .

$ f\left( x \right) = \sum\limits_{i = 0}^{t - 1} {{a_i}} {x^i}\;{\rm{mod}}\;p, $

(1)

其中 $ {a}_{0}=d $ 为初始密钥参数; $ p $ 为公共模数; $ t $ 为安全参数, 也称门限值.

第二步: 可信中心需要计算 $ {d}_{j} $ , $ j\in \{1,\cdots,N\} $ , 作为对应业务主体的编号, 并将其发送给中台中相应的业务主体 $ {B}_{j} $ , 即:

${d_j} = f\left( j \right)\;{\rm{mod}}\;p \to {B_j}.$

(2)

同时, 可信中心还需要给出公钥对 $ (n,e) $ , 并计算 $ L =l! $ , $ l $ 为参与业务记录上链操作的业务主体总数.

第三步: 由各个业务主体 $ {B}_{j} $ 计算业务记录 $ m $ 的摘要哈希并进行签名分片:

${\rm{SigSlide}}_j = H(m)^{2L {d_j}}od \;n.$

(3)

第四步: 产生聚合签名, 首先根据公式计算:

${\rm SigSlide}^2_j =H(m)^{4L {d_j}}od n, $

(4)

然后根据拉格朗日插值公式计算得:

$y = H{\left( m \right)^{4{L ^2}d}}od n.$

(5)

令 ${e'}=4{L }^{2}$ , 根据扩展欧几里得算法可以得知存在 $ a $ 和 $ b $ 使得 $ ae+b{e'}=1 $ , 所以可以得出最后的聚合签名:

${\rm sigM} = {x^a}{y^b}od n.$

(6)

第五步: 由链上合约验证聚合的门限签名是否正确, 按照如下公式进行判断:

${\rm sigM}^e = H( m )od n.$

(7)

如果等式不成立, 则上链失败; 如果等式成立, 则表明签名有效, 允许将交易记录加密上链保存, 等到需要调用时, 再从链上拉取相关信息进行解密, 从而在一定程度上保障了内生性数据的交互安全.

3 实验验证及结果

本章将围绕数据上链前的数据交互, 先给出一个泛化场景的形式化证明和通用算法, 然后对此进行仿真模拟实验, 测试协议在数据交互上的效能.

3.1 形式化验证

为验证本研究中的链上链下数据协同技术是否合理有效, 率先给出形式化证明的算法流程图加以分析, 如图5所示.

结合图5所示的算法流程图, 首先, 算法第一步是根据公式(1)生成密钥协商的多项式; 其次, 根据公式(2)构造出分片密钥 $ d $ , 通过匿名信道分发给业务主体或者数据主体.

在此基础上, 给出业务记录或者数据信息的门限签名, 并判断签名人数是否达到门限规定数量, 如果没有, 则授权失败, 无法进行下面的操作; 如果达到门限规定数量, 就根据公式(4)—(6)计算一个聚合的签名 ${\rm sigM}$ ; 接着就按照公式(7)交由合约验证, 判断签名的合法性. 如果不合法, 业务记录或数据信息就会上链失败; 如果合法, 即调用加密函数 ${\rm encrypted}(\cdots )$ 进行业务记录或数据信息的加密上链操作, 加密方式如下.

$ c_{\text{encypted}}=c_{\text{message}}^{k_{\text{pbkey}}}, $

(8)

其中 $c_{\text{message}}$ 是需要加密的消息, $k_{\text{pbkey}}$ 是加密使用的公钥. 最后如果需要查询链上存储的内容, 那么就调用解密函数 ${\rm decrypted}(\cdots )$ , 解密方式如下.

$ c_{\text{decypted}}=c_{\text{encypted}}^{k_{\text{prkey}}}, $

(9)

其中 $k_{\text{prkey}}$ 是解密使用的私钥. 获得解密后的业务记录或数据信息的明文后, 一个完整的形式化证明流程才算结束.

从上述形式化证明中可以看出, 数据上链前经过了两轮质询, 一是数据传输时签名人数的核验; 二是聚合签名的核验, 保证了数据的安全传输. 而数据上链后是经过特定算法函数加密处理的, 调用时只需要用对应的解密函数进行解密, 就可以获得完整可信的数据明文信息.

3.2 通用算法设计

本节将从算法层面介绍链上链下数据协同的过程, 数据交互调用的伪代码如下.

Begin

Input:

　callerId; //调用者ID

　operation; //操作

　operationId; //操作标识符, 是业务操作还是数据操作

　sigM: [SigSlide_1, SigSlide_2 $,\cdots, $ SigSlide_N]; //sigM为聚合签名, SigSlide为单个调用者签名分片

Output:

　message; // 布尔类型, 表示上链操作是否成功

Load Input; //载入链下传入合约的信息流

If(!verifySig(callerId, sigM)) // 验证聚合签名消息是否合法

Return false;

If(operationId = 1) // 判断执行哪种操作

　executeBusiness(); //执行业务操作

Else if(operationId = 2)

　executeData(); //执行数据操作

Else

　 Return false;

If(saveToContract(callerId, operation, sigM)) //保存相关信息到链上

　 Return true;

Else

　 Return false;

End

算法的第一步需要载入调用者的相关操作信息流; 第二步需要验证聚合签名的有效性, 判断聚合签名者的身份是否合法, 以及聚合签名中签名人数是否达到指定标准, 即判断有多少签名分片; 第三步检查具体的操作内容, 根据operationId分析具体的操作是业务操作还是数据操作, 然后再分发到不同的链上合约进行处理; 第四步是业务记录或数据信息的上链存储操作, 通过智能合约添加新的内容到区块链上进行安全保存.

3.3 内生性数据交互过程的仿真模拟

为了进一步说明内生性数据交互协议的可行性, 抽离出协议中对提升内生性数据交互效能起关键作用的门限签名算法进行模拟仿真实验, 以业务中台和业务链之间的交互为例, 设定门限为6, 进行签名的业务主体签名人数为13的方案, 进行相应的编码测试. 在此次测试中, 主要硬件环境如下: 英特尔双核i7处理器2.5 GHz、内存8 GB、Win10系统 64位.

对于单次内生性数据交互, 基于改进的协议签名编码测试结果如图6所示.

从图6中可以看出, 消息 $ m $ 、聚合签名、模 $ n $ 后的聚合签名、消息摘要都是以大数形式展现的数字流. 且根据前面的验签公式(7)不难看出, 聚合签名 $ e $ 次幂模 $ n $ 后的签名数字流和消息摘要模 $ n $ 后的数字流内容一致, 从而证实了图6中的验签过程合法有效.

虽然在图6中给出了加密消息 $ m $ 、聚合签名等签名、验签过程中的关键数据内容, 但并未阐明这些数据与业务链之间的交互关系. 图7给出在同样硬件环境中用开源智能合约开发环境Remix测试基于业务链的数据上传及下载的两个主要函数接口.

图7中, 数据上传的主要函数接口为 ${\rm addMessage}\left(\right)$ , 需要由指定业务主体将对应授权之后的聚合签名的字节码值以及经过加密函数 ${\rm encrypted}(\dots )$ 处理后的加密消息 $ m $ 的字节码值传入该函数接口, 然后在函数接口内部判断签名无误后, 再把加密消息 $ m $ 的字节码值上传到业务链上指定区块中进行存储. 等到需要下载时再通过另外的函数接口 ${\rm getMessage}\left(\right)$ , 输入需要查询的相应区块信息的映射编号, 接着就可以获取之前上链存储的指定聚合签名以及链上待解密的消息 $ m $ . 最后再调用 ${\rm decrypted} (\dots )$ 函数对加密消息进行解密, 即可获得相关的业务记录. 此外, 返回值中还可以获取先前指定业务主体的地址信息, 方便业务中台内部跟踪数据源主体, 以便进行有效监管.

为了证实协议应用的门限签名算法能够有效提升内生性数据交互的效能, 本文分别设置了三组签名验签对照组, 依次为链下签名及验签对照组、链上签名及验签对照组以及基于改进的协议签名、验签对照组. 通过设定20次单体测试, 对每组的签名、验证的开销进行了详细分析, 每次测试的时间开销如表1所示. 在此测试中, 主要硬件环境如下: 英特尔双核i7处理器2.5 GHz、内存8 GB、Win10系统 64位.

从表1中可以看到, 在20次单体测试中, 链下签名及验签实验对照组的签名和验签时间总体来说时间开销最短. 但是因为如果内生性数据交互在链下签名、验签, 则并未涉及区块链结构, 那么在业务溯源、数据安全方面就没有很好的保障, 也不具备实际应用价值. 所以主要分析后面两个对照组的签名、验签方面时间开销的结果. 链上签名及验签对照组将中台间内生性数据的签名、验签的过程全部交由区块链进行处理, 虽然在业务溯源、数据安全方面有所保障, 但是由于签名和验签时间普遍较长, 因此相应地, 数据交互处理的效能便会有所偏低. 所以, 综合来看, 采用协议设计的签名方案, 在链下签名后交由链上进行验签处理, 就可在提升中台间数据交互效能的同时, 借助区块链双链结构实现中台业务溯源、数据调度精准的目标, 并且保障数据可信安全.

为了更直观地对比在使用区块链技术的前提下, 协议中的门限签名方案与传统单一链上签名、验签方案的时间开销, 分别计算20次单体测试中两种方案各自签名与验签总花费时间开销的平均值, 给出如图8所示的柱形图. 从图8中可看出链上签名及验签算法的签名和验签总时间开销平均为32067.9 ms, 而基于改进的协议签名算法链上签名及链下验签算法的签名和验签总时间开销平均为18563.3 ms. 相比之下, 协议签名算法节省了近42.1%的时间成本.

综上, 实验结果表明该协议算法在内生性数据交互过程中签名效率较高, 验签效率相对较低, 相对于传统单一链上签名、验签方式, 协议在对内生性数据的交互处理上具有较高的效能.

4 讨　　论

本研究从“数据+业务”的双中台架构设计出发, 结合区块链双链技术, 切入双中台数据上链到区块链中传输信道中内生性数据的交互效率问题, 给出了一个高效交互的协议设计, 主要的创新点如下.

(1) 通过将区块链技术导入中台, 提升了内生性数据的交互安全, 保证了中台数据上链前的可信性. 构建了一种改进的舒普门限内生性数据交互协议来保障数据在上链前的安全性.

(2) 在上述工作的基础上设计了一个融合链下签名、链上验签的交互机制, 提升了双中台双链的数据交互效率. 实验结果表明, 该机制降低了42.1%的时间开销, 提升了中台与区块链两个体系间数据交互的效率.

当然, 新协议仍然面临着以下挑战: 首先, 在技术层面上, 还必须要融合其他技术, 如大数据、人工智能等新技术, 来持续优化中台技术结构. 其次, 在政策层面, 要有国家对区块链技术的支持, 鼓励实施优良技术标准和发布相关可信规范, 在宏观调控上尽量避免技术作恶. 最后, 在业务层面上, 需要继续细分业务结构, 使得业务中台在提取数据中台相关信息时能更高效, 从而增强业务处理能力.

5 结　　论

本文提出了面向双中台双链架构的内生性数据交互协议, 从算法公式推导上证实了协议的可实现性. 针对中台与区块链两个体系间的数据协同给出了形式化验证, 对协同的关键机制进行了实验模拟, 结果表明该机制能够提升系统内生性数据间的交互效率. 这种双中台双链体系架构下的新协议将会对“区块链+中台”的落地应用有一定的启示作用. 当然, 中台也仍然还是一个发展中的概念, 中台在落地应用实践中还会不断产生新的问题与需求, 这将是未来持续研究的方向.