9.4　数据服务背后的产品技术

数据服务背后的产品技术主要有5种：多样数据服务、全生命周期管理、服务安全控制、多版本管理、审计与计量计费。

9.4.1　多样数据服务

为了快速支撑不同业务对数据服务的需求，数据服务有多种生成方式，通过选取合适的生成方式，快速生成适合业务的数据服务。常见的数据服务生成方式如下。

·标签服务化：对接标签管理，快速选取所需的标签，通过配置输出满足业务场景的数据服务实现标签服务化。这种生成方式主要面向业务人员，不需要具备技术基础就可以快速将数据以服务化的方式提供出去。

·自定义SQL服务化：通过把自定义SQL脚本封装成服务的方式，直接将数据变为一种服务能力对外输出，实现自定义SQL服务化。在一些对服务灵活性有较高要求的场景下，一般会选择对接数据源并通过自定义SQL的方式来实现API，这对于服务的开发者有一定的SQL编程要求，并且需要对数据库存储有一定的认知。

·算法模型服务化：对接算法模型，通过部署算法模型的方式输出模型服务，实现算法模型服务化。将算法人员实施的算法模型快速进行工程化、服务化实现，让算法人员不具备工程化能力的企业也具备算法工程化的能力，快速将算法技术赋能业务。

·注册API服务化：企业还有一些特殊的API，也需要统一管控，支持将企业已有的API注册到数据服务进行统一管理和输出，实现注册API服务化。统一企业的服务出口，统一托管API，形成企业服务能力中心。

9.4.2　生命周期管理

对API服务提供完整的生命周期管理，可以大大降低日常维护成本，包括API服务的新建、维护、上线/下线、授权、监控等。数据服务的生命周期全链路管理主要分为以下几个阶段。

（1）服务的创建部署

服务的创建前提是已经明确该服务的使用场景，是用于报表分析、活动定向人群投放还是用于金融交易风控，抑或其他，只有明确了该服务的应用场景，解决何种问题的目标，才能明确创建服务时选择哪种服务组件。另外，在服务组件的选型完成后还要考虑服务部署的环境，部署环境分为本地机房服务器环境、云服务器环境、远程Docker仓库环境等。准备工作就绪后，即可创建一个服务，服务创建时底层会将该组件包部署在所选择的环境中，一旦部署完成，平台上即可查看到服务的成功运行状态、部署过程日志、服务相关详情信息等。

（2）服务的授权赋能

服务在部署完成后，仅服务的创建者有权直接使用该服务，其他用户必须经过授权才能访问。

（3）服务的运行监控

服务在经过创建、部署、授权后，可以正常运行使用，在运行使用的过程中需要有自动化的运维监控机制来保障服务状态正常。服务正常运行时需要能够监控记录服务的运行时长、历史出错频率等重要参考信息，这样，一旦服务出现故障，自动化运维监控机制可以及时告警通知相关人员，从而尽量减少故障带来的损失。

（4）服务的更新升级

服务部署并投入使用后，并不是一成不变的，中间可能会存在组件升级、数据异常重配、环境缩扩容等情况，此时需要对服务进行更新升级。

（5）服务的到期停服下架

服务到期或者不需要使用时，需要终止服务并将服务下架，此为该服务的生命周期最后阶段。

9.4.3　服务安全控制

服务提供时，需要考虑服务的稳定性和安全性，在保障服务稳定的同时保证数据可控、范围可控等。稳定性方面主要考虑做好自动扩容、容错等相关的工作，一般采用分布式部署机制，提高性能及可靠性。完备的服务安全防护机制包括以下方面：

·鉴权机制：支持对API和授权应用进行鉴权，识别接口请求的身份。常见的鉴权机制有AK鉴权、Access Token、JWT等。

·黑白名单：支持设置IP黑白名单，控制服务调用权限。

·申请审批：经过授权或申请审批通过的API才能被应用使用。

9.4.4　多版本管理

服务在应用到具体场景的过程中，有必要对多版本提供支持。常见的场景有：

·业务不同阶段的需求变化会导致服务经常升级、回滚。

·服务升级后老服务支撑的业务无法短期升级，通过多版本来支撑过渡。

·蓝绿部署、灰度验证等场景的需要。

数据服务通过对服务的多版本管理，可以便捷支持切换服务多版本，同时支持蓝绿部署和灰度验证，以及业务需求的升级和回滚，有效保障服务的连续性。其中主要涉及以下两个关键点。

（1）多版本服务在线

多版本最常见的实现方法是通过服务的版本标识（见图9-16），

让使用者可以快速区分当前使用的版本是什么，也方便不同版本之间的逻辑隔离，从而避免升级时对原业务产生影响。

图9-16　服务的版本标识

（2）服务路由管控

蓝绿部署主要是指在部署时，如何保障业务不停机，用户最小感知。灰度验证是新部署的服务能力，找一小部分流量来进行验证，确认验证成功对实际业务无影响时，再将服务应用到全部流量，是一种对使用方的切分验证方式。这两种方式都需要通过服务调用的路由控制来实现，蓝绿部署是调用路由在两个不同版本之间的切换，而灰度部署则是在不同版本上流量的分拆验证。

9.4.5　审计与计量计费

服务授权后，需要对服务的使用情况进行审计监控。以服务为对象，统计该服务的所有调用方信息、总调用情况、成功调用次数统计、失败调用次数统计等，为后续计量计费、访问控制、流量控制提供审计数据基础。审计控制模块为服务API的调用情况提供了全链路的追踪溯源，为服务的提供方和调用方带来了极大便利，是服务管理、服务监控、服务分析、服务运维等不可或缺的重要模块。

数据服务的审计功能主要包括服务API的审计列表、API调用成功记录、API调用失败记录、API调用方来源审计记录等。通过审计监控记录，服务的管理者能够直观获取服务的使用概况。同时，审计模块记录的历史数据支持在线可视化展现，辅助服务管理者分析服务历史调用情况，服务API的稳定情况，服务API的访问时长、成功率、失败率、高频访问对象等，以及访问的高峰期和低谷期等，来制订各阶段的扩缩容策略。通过审计控制可以获取很多API相关信息，通过这些审计结果数据的分析可以整理出以下相关指标：

·服务接口调用接口总计：平台监控所有服务的接口，并将各服务接口调用信息进行归类、汇总、统计，由此根据相关权重规则即可分析出热门服务使用排名，重点监控此类服务对象。不同服务的接口总数也不尽相同，要根据该服务组件开发设计而定，可以以服务为研究对象，细分统计服务下的各API调用情况、超时统计、异常结果分类等。

·今日调用接口总计：统计当天所有调用过的API情况，可用于统计历史每天的接口总计数、历史每月接口总计数，为后续计量计费选择何种计费模式提供数据参数依据，让用户能够对历史使用情况有个大致数据体量的感知，辅助用户进行相关决策分析。

·今日接口调用时段分布：统计当天各个时段的接口数分布，用来分析API调用的高峰期和低峰期，帮助用户察觉和关注高峰期调用上限值，从而合理安排相关系统运行时段，错开高峰，避免同时高并发请求带来系统性能瓶颈问题等。

·热门调用接口分布：平台通过统计各服务的所有接口总计数来获取热门接口调用排名情况，以此来获知哪些接口是调用相对频繁的，哪些接口是调用相对低频的，可以对重点接口进行单独监控，通过自动化接口测试运维等方式来保障关键系统关键节点接口的稳定性和健壮性。

数据服务的计量计费主要包括各个数据服务API调用量、占用后台资源量等。API的计量计费方式包括两种，分别是按次计费和按时长计费。

·按次计费：根据统计用户调用API次数来实现计费。用户按需来选择相应的API服务，根据预期计算需要调用API的频数来预估自己的调用次数区间，数据服务管理系统提供不同调用次数区间分档供用户选择。

·按时长计费：当用户调用API比较频繁或者有持续调用API的场景时，可以按时长计费。例如1个月、3个月、半年、全年，或者自定义时间段。

数据服务作为数据中台对外能力的核心载体，是连接业务前台和后台的桥梁。数据中台能够以提供数据服务的方式直接支撑数据应用，距离业务更近，让业务更快地产生价值。

本章从数据服务的价值出发，首先阐述数据服务的定义与定位，简单描述数据服务的4个核心价值和3大核心能力，然后重点介绍了4种场景数据服务的定义、特点和构建过程，接着着重说明3种常见数据应用以及和数据服务的关系，最后介绍了数据服务背后的产品和技术。

9.5　中台手记（六）：解决“数据应用最后一公里”问题

9月2日　周三　晴　地点：星巴克

今天，和姚冰、赵伟一起去考察供应商，很顺利，下午结束时，时间尚早。

9月的北京，已经到了一年中最怡人的时节，难得一见的北京蓝，伴着和煦的微风，我邀请他们一同到星巴克坐坐，梳理一下最近的工作。

美式咖啡的醇香扑面而来，我将心中的一些想法和疑惑一一道出：

“资产建设和资产管理的工作已经开展起来了，接下来要考虑怎么实现数据能力的共享与快速输出。

“如果说前期工作是夯实基础，那么数据服务则是解决数据应用最后一公里的关键，也是数据中台共享价值的集中体现。业务线都盯着这块呢，一定要提前规划好。”

姚冰快言快语：“关于数据服务，《数据中台：让数据用起来》这本书里有详细说明，我看了之后很受启发。数据服务是对数据进行计算逻辑的封装（过滤查询、多维分析和算法推理等计算逻辑），生成API服务，上层数据应用通过数据服务API获取数据需求。”

赵伟也表示认同。

“姚工说得没错，数据资产建设中构建了完善的统一数仓层，目的是让数据更好地用起来，而这除了数据层面要做支持，还需要把数据以对使用者友好的方式输出给业务应用。还记得之前咱们给各业务部门做汇报的时候，提过的那个商业地产的例子吗？这个已经实现了，下面就是业务部门想要的客户画像、客群洞察……”赵伟一边说着，一边向我们展示了图9-17和图9-18。

图9-17　客户画像

图9-18　客群洞察

不知不觉中，夕阳的余晖透过大大的落地窗户打在我们身上，我心中对于数据服务能力落地的疑虑和不确定也早已被姚冰、赵伟热烈的讨论打消掉。

第10章　数据中台运营机制

企业数据中台搭建完毕后，如何让数据中台中的数据资产越用越多，越用越活，越用越稳定，这是紧接着要进入的一个新阶段：数据中台运营阶段。

本章将从如何评估运营效果、如何切入运营、如何做资产运营，以及实践案例经验等多方面系统介绍如何建立数据中台运营机制，使数据中台能够真正发挥价值。

10.1　数据中台运营效果评估模型

随着数据中台建设的逐步完善，企业的底层IT架构、数据架构和数据资产基本搭建完毕，移动互联网、物联网传感器+5G趋势的出现，为各行业提供了大量的新数据通道，让企业积累了海量的日志、行为和业务数据，那么，怎样将如此海量的数据持续用起来？企业如何运用数据资产为自身赋能？数据中台的出现，解了许多企业的燃眉之急，为企业的数据管理需求提供了强有力的支撑。

数据中台不是一款简单的产品，而是一个让数据持续用起来的机制。如何通过运营策略，让数据中台建成之后在企业内部持续发挥出更大的价值，是中台运营团队需要时刻思考的问题。

首先，可以通过图10-1所示的模型来思考你所在企业的数据中台运营体系处于什么状态。

图10-1　数据中台运营阶段自评表

如果数据可以被持续高质量地生产出来，数据消费者可以便捷地获取到数据，并能在安全、有监管的环境中使用，最终让数据资产达到一种比较理想的“越来越多，越来越好”的状态，那么恭喜你，你的企业数据中台已经运营成一个非常优秀的范本了。

但如果你发现你的企业无法做到上述的任何一点，那么非常遗憾，可能你的企业数据资产正处在一个非常脆弱的危险境地，此时亟须采取强运营机制来提升数据运营质量。

也许有人会有疑惑，为什么处于第二和第四象限的中台运营状态，同样都只满足了两个维度中的一个维度的要求，却有天差地别的前景？其实这其中的缘由并不难理解：数据质量及安全是数据中台能够运作起来的基础保障，哪怕前期的运行成本稍高一些，产出的数据效益暂时还无法令人满意，但只要采取了适当的运营策略，一段时间后提升到“优秀范本”的可能性还是很大的。反观另一种情况，如果一个企业的数据中台在短期内爆发出惊人的能量，为企业带来了可观的效益，但数据安全和质量没有保障，那就像一座没有地基的高楼，但凡遇到一点风浪，就会轰然倒塌。尤其是数据的安全漏洞，就像一颗埋藏在企业中的定时炸弹，是企业长期稳定发展的重大隐患。从另一个方面来说，收益提升之后，如果中台的成本在后期无法做到持续优化和控制，那么也会“吃掉”中台本身为企业带来的收益，两相抵消，投入产出比降低。

综上所述，可以用两句话来概括中台运营团队的使命及目标：

·数据安全及质量是中台可持续运营的基础；

·提效降本是打造中台影响力的关键。

10.2　数据中台运营的4个价值切入点

既然数据中台有那么大的价值，那么运营工作到底应该从何入手？如何才能在整个公司体系内落地呢？这里其实可以从4个层面来开展工作，如图10-2所示。

图10-2　数据中台运营的4个价值切入点

1.统一战略

在战略层级上，管理层需要对为什么建设数据中台有非常清晰的认知，坚定做数据中台的决心；一定要让企业上下都明确数字化转型对于企业生死存亡的决定性作用；一定要让全体员工尤其是战略管理层和执行管理层都理解数据中台在数字化转型中的关键位置和重要性。只有在战略层级给予数据中台足够的重视，并对应拆分到各高级管理层的年终考核以及关键管理策略上，才能够形成真正有效的战略支撑，否则就是董事长和CEO一时的“口舌之快”，终不见落地。此时还特别要注意一点，建设数据中台，信息部门CIO可以牵头落地，但是数据中台一旦开始运营，一定是CEO、CMO、COO、CFO等各业务高管需要共同背负的目标。

2.搭建组织

在组织架构上，需要配套相应的组织以及具体的人为此负责，以保证企业员工有数据运营的意识。具体负责的人员，除了常规的数据分析人员、数据产品经理，还可能是专门的数据运营专家以及盘点开发整体数据资产的数据架构师。当这些角色都已经到位，并指定他们在大的组织体系内向首席数据官汇报之后，这个组织才算成型，成本和收益才能被更好地度量，如图10-3、图10-4所示。

图10-3　集团型企业数据运营团队组织架构示例

其中，数据委员会主要负责制定数据建设战略方向，并授权相关职能部门具体执行落地，因此，建议指定数据相关部门的总监、主管、数据专家等人员来担任主要职位。而虚拟数据团队则需要通过一个企业制定的选拔原则来进行选拔，比如：来自各业务部门数据团队核心成员、熟悉数据建模理论、具备丰富的数据开发经验等。专家评审组则需要提前通知各团队推荐人员准备进组，按照专项评审流程推进工作，记录要点然后线下改进。

图10-4　某科技公司数据委员会架构

作为组织中负责具体执行的团队，需要制定统一开发标准规范，做到有迹可循，有据可依。除此之外，数据测试要做到全面，测试报告要按照要求归档。任务投产需要经过平台管理员审核，按规定发布到生产环境。

以上种种，都是保证组织高效运转、团队效能最大发挥的有效保障。各企业负责人可以参考这种组织架构搭建思路，结合企业自身人员架构情况，进行再设计和调整。

3.打造氛围

在人员到位以后，重点要使整个企业内部有使用数据的氛围。最简单的例子，笔者们参观过很多大公司，对方首先会带我们去看他们的数据大屏，因为这里可以看到整个公司层面的情况，看着就很厉害。这个数据大屏其实就是数据可视化的一种手段，当把数据以公司全局视角呈现并公开分析时，潜移默化地，在员工心里就会慢慢形成数据影响力。

当然，此时要注意，大的数据屏幕不等于大数据，更不等于数据中台，这只是唤醒企业内部数据意识的一种“花招”，数据中台运营负责人一定要牢记于心，万不可引以为豪、止步于此。

4.实践创新

当数据的意识被唤醒之后，就需要选定合适的业务方，一起做数据结合业务的创新实践。其中的重点在于如何形成让各部门争相使用数据的内部竞合态势。

比如一个传媒集团旗下可能有几十家刊物，每条业务线的员工数据意识是不一样的。有人觉得数据没用，有人可能当前业务遇到瓶颈，希望通过数据寻求突破。这个时候，公司就要奖励那些将业务和数据充分结合、创新的行为，树立“优秀数据化部门”的典型，用表扬激励机制来倡导内部员工用数据。

再举个例子，2014年国内最早做数据中台的某互联网巨头提出，所有业务部门都需要数据化，KPI指标也放到了各个业务事业线的副总裁身上。其实在整个集团内，大家都不知道如何清晰定义数据化，但当时他们知道有个部门叫数据平台事业部，这个事业部的人“好像看起来”很会“数据化”，所以各事业部的副总裁就会要求部门员工多去找数据平台事业部共创，多找业务和数据的结合点，最终形成多个总裁级数据化创新项目。业务创新失败率很高，但是不管失败还是成功，都为这个巨头企业提供了一种可抽象的正负样本，什么叫“业务数据化”，什么叫“数据业务化”，“数据化”的路径怎样会成功、怎样会失败，都被有效提炼成了方法论，最终成为企业内部建成数据中台的指导路径。

由上看出，当组织层面有大战略的要求后，下面的各个业务部门都会想尽办法去探索数据创新，慢慢地会出现一些成功的尝试。刚开始，创新的失败率是非常高的，整个数据赋能业务的过程其实也是慢慢找到焦点、逐渐落地、形成方法论的过程。

而每个行业、每家企业的特性都是不一样的，别人的经验未必能复用，所以必须自己尝试才能沉淀，才能有成功的样本。

10.3　数据资产运营

数据中台运营中非常核心的一块在于数据资产的运营，下文将围绕数据资产运营的目标、运营的过程、运营执行工作、资产质量评估、资产安全管理等方面展开论述。

10.3.1　数据资产运营的4个目标

由上文可知，企业数据资产是指由企业业务经营或内部管理形成的，由企业拥有或者控制的，会给企业带来价值利益的数据资源。数据资产的特点是有较好的组织形式，并通过这种组织形式实现数据资产的看、选、用、治、评链路。

因此数据资产运营的目标就是将数据资产变得可阅读、易理解、好使用、有价值，如图10-5所示，最终目标是通过有序的正向循环不断挖掘并提升数据资产的价值，使之变成企业的核心增值资产。

图10-5　资产运营的4个目标

（1）可阅读

数据信息不能仅仅存放在数据库中，通过数据表、数据字段等形式展现的弊端是，只有具备一定数据库基础的人员才能通过库表操作读取数据字段信息，而业务人员往往并不具备这一技术能力，因此就丧失了直接读取数据字段的能力和兴趣，这严重制约了业务人员使用数据。长此以往会产生以下几个弊端：

1）信息在多次传递后容易偏离它原本的意图，技术人员反馈的可能并不是业务人员想要的；

2）信息的传递有漫长的反馈周期，有时业务人员在提出数据需求后，需要等待几天甚至几周才能收到反馈；

3）技术资源匮乏，当业务对数据的需求量越来越大时，灵活变化的数据信息查询需求会层出不穷，根本没有足够的资源来匹配这种数据驱动需求。

因此需要有一个资产信息的读取门户或资产地图，在该门户/地图中，业务人员能够直接自己上手操作，通过简单的检索、分类查找、智能推荐等方式便捷地获知数据资产信息，且资产信息必须是以业务人员的阅读习惯呈现，而非面向技术人员的组织方式，如图10-6所示。

图10-6　数据资产门户的痛点与价值点

（2）易理解

资产信息除了可阅读，也要容易理解，因此需要将数据资产标签化，标签是面向业务人员的数据组织方式。

首先通过业务人员理解事物的方式来确定对象，所有的标签都是围绕特定对象的属性描述的。因此，数据资产首先是根据对象展开的。

例如：一个用户身上的“年龄”字段，以往常规的数据信息只有字段名“age”、存储表“user_info”等简单的词组备注，业务人员难以获取这些字段的生产加工逻辑、数据追溯血缘、有效值覆盖量、历史使用情况等信息，也无法帮助判断是不是本业务可用的数据。可以认为这些没有良好组织信息的数据，尚不足以称为数据资产，只有通过标签化，具备面向业务组织形式的数据才能称为数据资产。

那么一个“年龄”标签，它就应该有标签名“年龄”；标签描述“通过注册身份证信息获得的年龄信息”；标签逻辑“身份证第7～10位信息抽取出的出生年份信息，进行年龄计算”；取值类型“数值型”；值字典“0、1、2、…”等基础的元标签信息（见图10-7）。同时也会有“年龄”标签的来源表字段信息，拥有“年龄”标签的用户覆盖量，“年龄”标签的历史调用量、调用方，“年龄”标签的价值分、质量分等，这些用来帮助业务人员真正理解数据资产的必需信息。

（3）好使用

数据资产被业务理解后，将面临如何方便有效使用的问题。业务人员在充分了解所需信息后，一定会问出的问题是：“我该如何使用这些数据资产？”

传统的使用方式往往是，业务人员告知开发人员需要使用哪些数据字段后，由开发人员编写数据服务接口，对接业务系统或数据应用系统，供业务人员查看、查询、分析、使用数据。

图10-7　数据资产——如何让标签更易理解

前文提到的数据服务体系是一种有效的数据资产使用方式，通过数据服务体系可以实现对数据使用方法的抽象，供业务部门理解后直接配置使用，解决了业务人员难以准确描述需求的问题；同时数据服务配置生成过程简单快速，极大缩短了从0开始的编程过程；如果需要修改使用的数据资产、数据资产的使用计算逻辑方式或性能要求，都可以通过修改参数设置的方式来实现快速变更，大大降低数据使用的试错成本。

（4）有价值

数据资产运营的最终目的是让数据价值越滚越大，因此数据资产运营要始终围绕资产价值开展。在数据资产的使用过程中应该记录调用信息、效果信息、反馈信息、业务信息等所有可以用来评估资产价值的信息，如图10-8所示。

当资产的经济价值较难衡量时，可以考虑通过数据资产的调用信息来衡量，例如根据某标签的历史调用总量、平均每日调用总量、持续调用量走势、环比同比、调用受众量、调用业务量等维度来间接评估标签的重要程度。

此外，通过数据资产服务使用前后的业务指标差异也可以衡量数据资产的价值，例如通过A/B测试或灰度测试比较，使用了数据资产服务支撑的业务和未使用数据资产服务支撑的业务在核心业务指标，如用户黏性、转化率、营业额、访问量、访问深度、好评率、回头率、忠诚度等指标的差异程度，进而衡量数据资产的价值。

图10-8　数据资产价值评估维度

更传统一些的企业业务，虽然无法通过信息化手段自动记录业务调用、变化情况，但也可以采用最原始的客户访谈、意见填写等反馈方式来收集数据资产价值。

但是仍然需要探索数据价值的直接体现。在一些有效的探索中，互联网公司的业务部门可以通过积累的大量信息化数据，计算分析出某一项数据服务能为业务带来多少比例的收益增长，则可以将这一部分增长归属于数据服务带来的价值。例如通过大量持续的A/B测试发现某一项数据服务能给原有业务带来N%的增长，那么可以认为后续业务收入中的N/（100+N）是由该数据服务带来的直接收益。

10.3.2　数据资产运营的完整链路

数据资产运营的完整链路分为看、选、用、治、评5个面向用户使用的运营环节，如图10-9所示。

图10-9　资产运营的5个环节

（1）看

数据资产要通过一个合适的资产门户或资产管理场所，供数据消费方简单、便捷、详细地了解资产信息。消费方以可阅读的方式查看资产信息后才能判断其是不是当前业务所需的数据资产对象。

（2）选

消费方查看资产信息后，可以选择所需的资产对象，为后一阶段的使用做准备。

选的落地有多种形式：对于传统企业来说，可以通过文档的方式进行记录和提报；信息化做得较好的企业，可以通过生成一条数据申请使用的信息流来确认所需数据信息；对于数据管理水平较高的公司，可以通过资产管理系统，将所需数据资产加入购物车或收藏夹，放入一个意向的资产库中，方便业务人员简单便捷地反复查看、研究、复用重点的数据资产。

（3）用

消费方选择好所需数据资产后，就要生成相应的服务接口或通过数据应用产品来使用这些数据资产。用是数据资产运营中最为核心的一环，因为它和价值体现息息相关，所有的数据资产运营的核心追求就是通过不断迭代让资产使用价值最大化。

（4）治

在数据资产使用过程中，会有各种各样针对数据资产本身的问题，因此需要推动数据资产治理的环节。

数据资产治理分为面向业务层的标签治理及面向存储层的数据治理。标签治理包含新标签设计、标签上下架管理、标签类目管理、标签血缘分析、元标签标准、标签质量评估、标签使用安全等；数据治理包含以数据表/字段为对象的生命周期管理、血缘分析、元数据标准、数据质量评估、数据安全方案等。

（5）评

数据资产最终还要通过统一的标准进行完整、系统地评估。评估的角度可以是数据资产的质量层面、使用层面、成本层面、故障层面等多个维度。数据资产的评估要考虑的因素除了通过系统产生的调用次数、调用频率等计算类指标，还包括业务人员对标签使用的反馈评价。

同时，只有形成了对资产的评估信息后，才能让资产消费者在“看”的环节中，更加全面地理解数据资产的质量、应用价值、风险等，形成一个有效的闭环，最终实现数据资产价值的最大化。

10.3.3　数据资产运营执行的5个动作

数据资产运营要有效开展，需要配备专职运营人员对资产对象进行统筹的运营执行管理，因此和看、选、用、治、评相对应的有以下几部分运营执行工作，如图10-10所示。

1.组织登记

组织登记是数据资产运营执行的第一步。想要让消费者看到数据资产进而利用数据推动业务发展，实现企业业绩的增长，需要运营人员先将数据资产在系统登记入库，在通过管理审核后，才能开放出来让消费者看到。

运营人员在这一阶段需要确认企业现有的数据有哪些，对业务有帮助的数据又有哪些，将对业务有帮助的数据资产进行完整信息登记后上架数据资产信息，以供业务人员在前台的资产门户页面中查看。

（1）掌握现有数据

“巧妇难为无米之炊”，当资产运营人员需要利用数据资产来推动业务运营时，先要掌握企业现有的数据资产情况。

图10-10　中台运营执行的5个动作

不同行业、不同规模的企业，所掌握的数据各不相同，但是只要是实现了信息化的企业，都可以在其使用的业务系统、管理系统中找到可用的有价值的数据资产。

·对于规模较小的企业，数据库以及数据表的数量较少，方便整理，通过简单分类、标注即可让运营人员掌握当前大部分数据。

·对于大规模的企业，会出现跨部门、跨业务、跨系统、跨项目的现实情况，不同的数据库与表的干系人、权限要求各有不同，对数据收集工作带来很大挑战。

当企业的数据资产标准化之后，资产运营人员即可看到企业数据资产的全貌，掌握哪些数据资产可用。

（2）收集业务需求

资产运营人员收集完企业现有全量的数据资产信息后，需要根据当前主流、核心的业务需求筛选有价值的数据资产对象进行信息登记上架。

业务需求通常来自一线业务人员，不同行业的业务人员在日常工作中面对的对象不同，提出的需求也各不相同。比如电商行业的类目运营人员，可能会针对复购率高的女性用户精细化运营，那么在向资产运营人员提需求时，就会将“复购率”和“性别”作为主要的标签需求；对于制造业的业务人员来说，要增强设备制造产品的成品率，那么某零件的“制造失败率”就是主要的标签需求。

资产运营人员在调研、收集、了解、提炼数据需求时，不仅要能够理解一线业务人员所描述的内容，还需要掌握他们参与的生产经营活动流程，这样才能在标签信息的登记工作中以业务人员的视角记录、录入资产信息时，准确地使用专业术语定义及标签信息规则。同时，由于对生产经营活动流程非常熟悉，因而能够不局限于现有的流程现状所需要用到的数据资产对象，通过基于对流程发展的有效预估，将未来可能使用的数据资产对象也一并入库登记，提早考虑可能会使用到的数据资产。

（3）信息登记上架

对于资产运营人员，数据资产是一种承载价值的“商品”，只有被“交易”或者“使用”，才会体现出数据的价值以及对数据梳理、开发的价值，也可以通过交易和使用的数据反馈来优化、改善，持续提升数据对业务的赋能。因此还需要一个数据资产管理工具来实现资产的上架、展示和使用。

数据资产管理工具需要支持从资产申请上架、使用审批、使用、评价等功能，和前台的资产门户配合起来提供给业务人员“看”“选”“用”，并持续完成“治”“评”。

当资产运营人员认为某资产可能发挥价值时，选择该资产可用业务范围，并提交上架申请。通过批准后，相关业务人员即可看到该数据资产并申请使用。当使用量长时间为零或者因为业务调整撤销，不再需要这种数据资产时，可以将其下架，此时系统需要发送通知给正在使用、曾经使用或关注该数据资产的业务人员，并在一定时间内停止对该资产计算、存储、读取的支持。

2.宣传推广

宣传推广是数据资产运营执行的第二步。运营人员通过各种营销手段和方案，激发业务人员对数据资产的兴趣后，才有可能进入选用合适数据的阶段。

数据资产在上架审核通过后，就可以对外展示。初始阶段，数据资产对于业务人员是一个新概念，如何将数据资产进行包装并推广到实际应用中，考验着资产运营人员对运营和营销知识的掌握程度和对业务使用数据场景的理解。同时在数据资产的不断生产上新过程中，也需要对新标签、优化标签、高质量和高价值标签进行营销活动式的包装营销出去，方便业务人员在第一时间了解标签上新信息，或者对标签产生需求，因此在资产的推广宣传上，需要融入一些营销的思路，才能更快地让企业的数据被用起来。

对于数据资产，要以点带面地进行推广宣传，无法一蹴而就。初期的推广仅针对已有的标签进行即可。在上文提到的标签需求收集阶段，资产运营人员与小范围的业务人员进行了接触，所以对于数据资产这个“产品”，这部分业务人员是种子用户。面向种子用户，撰写精准有吸引力的广告文案或者推送消息，在资产门户端对数据资产这个“产品”进行产品营销。在这一阶段，需要资产运营人员持续跟进已有标签在实际业务中发挥的作用和产生的效果。可以定期安排业务人员产出报告，将使用标签后与使用前的业务状态进行比对，比如在使用标签后，业务进行效率是否有提升、盈利能力是否有上升等。除此之外，也可以通过监控标签调用频率来了解标签使用频率。如果标签调用的频率稳步增长，说明前台业务对其逐渐依赖，这些标签的价值逐步体现，也证明了标签的有效性。

当验证过数据资产价值后，可以通过持续的宣传推广手段来传递有效标签信息：对于原有组织用户，推荐更多适配业务场景需求的有价值、高质量的标签；对于新组织的用户，可以研究分析其业务共性、数据需求，将现有成功案例包装宣传，通过内部邮件、事务海报、内网发帖、行政建议等方式介绍现有数据资产并将其效果广而告之，以此激发更广泛的业务人员对数据的兴趣。

在有效的推广宣传后，除了会引导产生出对现有数据资产的使用动作，还会产生对新数据资产的使用需求，因此资产运营人员也需要对收集到的新资产需求进行评估、设计、下发开发任务、登记上架等操作，并逐步完善数据资产体系。

3.服务保障

服务保障是数据资产运营执行的第三步。运营人员只有搭建出一个可看、可控、可追溯、可预警的服务保障平台，才能让业务人员放心地使用数据服务。

数据资产通过与各种服务组件结合，例如分析服务组件、圈人服务组件、推荐服务组件等，形成各种类型的数据服务输出，进而被上层应用产品或业务系统调用。在这个过程中，作为数据资产的运营人员，就要保障数据服务的稳定性，避免因为数据服务的不稳定导致企业业务受损。

那么如何保障数据服务的稳定性呢？

首先，需要对所有要调用数据服务的上层应用进行审核，确保所有的上层应用都是经过授权的，避免外部应用不经过授权直接调用服务，从而导致数据资产泄露。

其次，还需要对服务调用的性能进行保障，服务调用的响应时间、QPS、处理数据体量等都会对应不同的计算引擎的选型，同时会配合一些负载优化、分流控流的机制来避免调用激增、恶意攻击等因短时间内有过多服务调用，导致服务请求阻塞引起故障。也可以通过流量控制实现流量倾斜，控制尾部应用的服务调用次数，向头部应用倾斜更多的流量，从而保障头部应用服务的稳定。

最后，还需要一套完整的服务监控体系，对所有的服务进行监控。当服务出现请求异常、内容匹配异常以及访问超时等情况时，系统会自动向相关的运营人员和技术人员发送告警邮件，告知相关人员去修复该服务，从而保障服务正常。每周期定时提供服务监控报告，告知运营人员服务的调用情况，例如哪些服务经常被调用，哪些服务不经常被调用，哪些服务调用的请求时间比较长，哪些时间段服务被调用得比较频繁等。根据服务监控报告，运营人员可以制订相应的运营策略，保障服务正常运行。

4.治理优化

治理优化是数据资产运营执行的第四步。运营人员作为数据资产管理者中的一员，需要对数据资产使用过程中的问题做好登记、人工修正或下发治理任务，同时不断迭代优化资产，形成正向循环。

在项目管理领域有一个模型叫戴明循环，也就是PDCA循环。它是一个持续改进模型，包括持续改进与不断学习的四个循环反复的步骤（见图10-11）。其中A代表Action，表示效果优化。对于做得好的部分，可以通过模式化或者标准化进行推广；而对于做得不好的地方，要总结经验，在下次任务中优化。对于数据资产，戴明循环同样适用。

数据资产并不是用完就可以不管了，运营人员需要对其进行持续优化：

1）对于业务人员反馈的使用过程中的资产问题，及时做好信息登记，并触发工作流任务。部分资产治理工作可以由运营人员自己完成，例如元标签信息不够完备、有错误、不标准；或某些数据资产具体取值存在错误，需要人工审核；或随着企业业务发展，原有的资产类目结构不再适用或者需要新增修改类目结构等。部分治理工作由于需要以技术方式解决，则需要下发任务交由技术人员完成。

图10-11　PDCA的4个阶段

2）对于能正常使用的数据资产，也要定期关注其使用价值情况及占用资源成本，需要及时清理长期不用、过时、性价比低或不合时宜的资产，沉淀出有价值的数据资产并进行资产体系优化，进而影响新数据资产的设计、迭代与落地。

例如在保险业务中，因为渠道考核的标准变化比较频繁，所以经常需要对数据资产进行优化和迭代。拿保费来举例，根据管监的要求，有些渠道需要关注规模保费指标，有些渠道需要关注价值规模保费指标，还有些需要关注价值VNB指标。根据管监不同的要求（业务显性驱动），要对这些指标数据不断迭代和优化。

如果说上面这个例子是因为业务方强制优化和迭代数据资产，那么下面这个就是一个业务驱动的例子。在电商平台上，手机配件市场还没有像现在这么庞大的时候，它是作为数码3C下的一个子类目存在的。智能手机的爆发式增长，也带动了手机配件市场的火爆，许多用户开始在电商平台上查找手机配件。以往通过先查找数码3C再查找手机配件的方式，因为整个链路太长导致许多用户放弃下单。这个时候，就需要对现有的数据资产做优化。原本作为二级类目的手机配件变成和数码3C平级的一级类目，从而大大提高了成交转化率，避免了用户流失（见图10-12）。

图10-12　业务驱动数据类目优化

所以，无论出于什么目的，运营人员都需要持续对数据资产进行治理优化，这样数据资产才能真正发挥价值。

5.价值评估

价值评估是数据资产运营执行的第五步。运营人员作为管理角色，还要对数据资产进行价值评估，同时需要将这些价值信息定期上报管理层并合理披露给业务人员，以方便业务人员持续使用数据资产并对其进行评估。

毫无疑问，对数据资产的价值评估是根据数据资产的使用情况进行整体判定的。作为数据资产的载体，标签的使用情况也就代表了数据资产的使用情况。如果一个标签被开发人员辛辛苦苦加工出来却无人问津，那么这个标签的价值可想而知。反之，如果一个标签被业务频繁使用，甚至连业务的运转都离不开它，那么它的价值显然会更高。

当然，对于标签的价值评估，并不能仅仅根据标签调用次数这个单一指标。要知道有些标签虽然调用次数比较多，但并不能给业务带来多大的实际价值。比如“用户姓名”“用户手机号”等标签，虽然大多数业务线都会调用，但这仅仅是因为这些标签是基础标签。而像一些算法标签，比如“用户信用评分”这个标签，可能只被风控业务线调用，但是这个标签给该业务线带来的价值却是巨大的，甚至整个业务线都会围绕这个标签运转。

所以，在对数据资产进行价值评估时，资产运营人员需要综合多个指标进行多维评估，包括数据资产使用准确率、关注热度、调用量、可用率、故障率、持续优化度、持续使用度、成本性价比等。同时系统也可以把每一个价值评估指标放入价值评估模型进行模型运算，最终得到标签的综合价值分，从而得到数据资产价值的综合排名。

因此对数据资产的价值评估既可以从各个细分维度展开，也可以根据综合指标进行排名。运营人员可以根据需求制作数据资产的价值看板或BI报表并上报给管理层进行阅览，同时需要将这些资产价值信息通过登记、同步、联动等方式展示在资产门户相应位置上，方便业务人员根据价值评估指标判断所需数据资产能否满足业务对性能与质量的要求。

10.3.4　数据资产质量评估

资产质量评估维度包括完整性、规范性、准确性、一致性、唯一性和时效性等，在本章开篇提到的数据运营效果评估模型中，如果你发现你的企业数据是低质量或低安全系数的，那么你需要特别关注以下内容。下文将从源头数据质量、加工过程质量和使用价值质量三方面来系统阐述数据资产质量评估体系。

（1）源头数据质量

资产质量首先和源头数据质量有关，源头数据不完整、不准确或不及时都会影响下游数据资产质量，描述数据源质量的典型指标有：

·数据源安全性：数据源数据是否合法取得、是否得到用户授权许可等，会间接影响标签的数据安全性。

·数据源准确性：数据源数据是第一现场取得、间接获取还是边缘推算出的，将与标签最终的准确性密切相关。

·数据源稳定性：数据源数据产生的稳定性，包括产生周期、产生时段、产生数据量、产生数据格式、产生数据取值等的稳定性。

·数据源时效性：数据源数据从第一现场产生到传输录入的时间间隔，行为类数据的时效性会间接影响标签准确度。

·数据源全面性：数据源数据是否全面，各个层面的数据是否都能整合打通，进行全域计算。

（2）加工过程质量

资产质量也和资产加工过程有关，加工过程中的规范性和时效性、加工产出的资产覆盖率和完整度都是加工过程类的质量指标。笔者总结了资产标签加工过程相关指标：

·标签测试准确率：标签在建模、测试过程中得到的准确率，是一种类似试验性质的初始准确率，供参考使用。

·标签产出稳定性：标签每天计算加工产出时间的稳定性，能否准时产出，这也是业务使用时要重点考虑的指标。

·标签生产时效性：标签生产过程所耗费的时间间隔，时间间隔越短，时效性越强。时效性对实时类标签尤为重要。

·标签覆盖量：具有某标签的标签值的对象个体数量。每个对象个体数据完善程度不同，同一个标签能覆盖到的对象群体也不同，例如用户信息中，可能有些用户登记有性别信息，有些用户没有登记性别信息，因此性别这个标签的覆盖量是那些有性别取值的群体量。

·标签完善度：标签有很多元数据信息，即标签的“标签”，这些元数据信息的完善程度是业务使用的可用性指标。

·标签规范性：标签的元数据信息，需要按照标准的格式规范进行登记，现有标签的元数据信息是否合规，合规程度如何。

·标签值离散度：标签取值是集中在某个数值区间或某几个取值，还是呈相对平均分布。离散度没有绝对的好坏，一般场景下离散度越大越好，说明人群在该标签属性下均匀分布于不同特征值。

（3）使用价值质量

在大数据时代，企业对数据价值的实现常常体现在数据分析、数据挖掘、数据应用等层面。数据资产作为一种无形资产，其价值质量的衡量标准应当是数据资产产生的数据服务或数据应用给企业业务带来的经济利益提升或经营成本降低。只有对数据资产使用价值进行合理评估，才能以更有效率的方式管理数据资产。

资产质量会体现在资产的使用过程中，目前笔者所归纳的与资产使用价值相关的质量指标如下：

·标签使用准确率：标签在使用过程中，经过业务场景验证、反馈得出的标签准确率，是一种较为真实的准确率判断。

·标签调用量：标签平均每日的调用量、今日当前累计调用量、历史累计调用量、历史调用量峰值都是可参考的调用量信息，反映该标签被业务采用的真实调用次数。

·标签受众热度：标签被多少业务部门、业务场景、业务人员申请使用，可以反映标签的适用性和泛化能力。

·标签可用率：标签在真实使用场景中，历史总调用成功次数占历史总调用次数的比例。

·标签故障率：标签在真实使用场景中，历史故障时长占历史总服务时长的比例。

·标签关注热度：对标签在标签集市中被搜索、浏览、收藏、咨询、讨论等方面的热度，进行综合计算后得出关注热度。

·标签持续优化度：标签是被开发人员持续迭代优化，还是尚处于开发阶段，反映了该标签经过反复迭代、持续优化的程度。

·标签持续使用度：标签被业务申请使用调用后，平均持续调用的时长、频率、推广，反映了该标签能够真正给业务带来价值。

·标签成本性价比：标签加工过程中所投入的数据源成本、计算成本、存储成本，与为业务带来的价值、调用量、应用重要程度等产生的性价比指标，是一个纵观成本和价值的平衡参数。

10.3.5　数据资产安全管理

在数据资产运营中，还有一个重要组成部分是通过安全策略实施保障资产的安全。一旦数据资产出现安全漏洞，是十分有可能对企业造成毁灭性打击的。这也是为什么在数据中台运营效果评估模型中，将此类公司归为“昙花一现”。下文将从资产的分级分类管理、脱敏和加密、监控和审计三个层面来阐述数据资产的安全管理。

（1）分级分类管理

按照信息分类保护的思想，从安全考虑，将系统中所存储、传输和处理的数据信息进行分类，并将每一类数据信息对应于一个确定的安全保护等级；对数据的安全级别进行等级划分，保障数据的使用安全。可以从业务应用倒推资产重要程度，对资产实行分级管理。资产分级分类方式一般包含以下几点：

·按资产与核心业务的关联程度：如果某数据资产是核心业务流程中对转化最为关键的，它的等级就会很高。例如在营销系统中，订单表、客户信息表、财务流水表是和核心业务紧密相关的数据。除了核心数据外，还有部分是核心数据所衍生出来的统计或关联数据，它们的等级相比于核心数据就要低一些。

·按资产敏感程度：已分类的数据资产由业务部门进行敏感分级，划分为C1、C2、C3或C4。其中C1为完全公开，表示该数据对内、外都公开；C2为内部公开，表示该数据对内部人员公开，对外不可见；C3为保密，表示数据对特定人员公开；C4为机密，表示数据对平台管理员公开。

·按资产更新周期划分：根据数据资源更新的频度，分为实时、每日、每周、每月、每季度、每年等。

（2）脱敏和加密

数据脱敏是为了防止人员非法获取有价值数据而加设的数据防护手段，从而保证用户根据其业务所需和安全等级，有层次地访问敏感数据。当业务访问系统数据时，该模块对数据进行实时筛选，并依据访问者的角色权限或数据安全规范对敏感数据进行模糊化处理。

资产脱敏管理主要包含两部分：数据屏蔽和存储数据加密（服务器敏感数据隔离）。屏蔽可分为全部屏蔽、部分屏蔽、替换、乱序，加密可支持DES、RC4算法进行加密。

脱敏设置提供屏蔽、替换等多种脱敏方式对查询和透出的数据进行转换。脱敏为不可逆操作，数据经过脱敏后不能反推出原始数据，可防止数据泄露，实现数据可用不可见的效果。数据加密是对数据存储的操作，配置加密后数据存储的是密文，实际使用数据时需要先解密再使用，数据加密可防止通过“拖库”类操作直接从存储层泄露数据。

（3）监控和审计

资产监控包括对资产的存储、质量、安全使用等进行监控。监控规则一般按照通用和自定义的稽核规则进行校验和检查，并配合可视化工具对问题数据和任务进行记录和展示，对有问题的数据资产需要提供多种处理方式。

常见的质量、存储、安全监控主要包含如下几个方面：

·表记录数的波动监控。对指定表分区的行数和历史数据进行比较得出波动值，判断是否超出了设定阈值。

·字段的统计值波动监控。对指定表的一列进行统计计算，然后和历史数据比较得出波动值，也可以和用户指定的期望值进行比较。

·数据量监控。对整张表或者表的分区和历史数据进行比较得出波动值，判断是否超出了设定阈值。

·数据资产各种质量类指标监控。通过对各标签的质量指标设定最低阈值，判断质量绝对值是否下降到设定阈值；或通过对质量指标设定阈值并与历史数据比较波动值，判断是否超出了设定阈值。

·数据资产分级分类监控。定期扫描数据资产是否按照标准规范进行分级分类，并监控数据资产使用人员是否按照其权限范围访问、查询、使用、同步、下载数据资产，是否有违规操作。

·数据资产脱敏监控。定期扫描数据资产是否按照标准规范进行脱敏加密，是否有人访问、查询、使用、同步、下载了未脱敏数据，是否有违规操作。

在数据安全监控过程中，需要伴随有完整的审计机制。审计方式从审计体系规范建设入手，同时需要建立数据资产审计方法和专职人员审计方法。审计对象包括数据权限使用制度及审批流程、日志留存管理办法、数据备份恢复管理机制、监控审计体系规范以及安全操作方案等体系制度规范。数据资产管理在实施过程中需要保障集中审计的可行性。

数据资产与业务场景存在较强的相关性，所以需要注意权限和安全问题。一般地，资产的可见性、可用性会与业务人员所在的业务部门或者项目关联，在实际资产的使用过程中，并不是具体的“人”在使用，而是其代表的组织整体在使用。所以在业务人员想使用某标签时，需要提交审批，经过业务部门和数据资产部门审批后方可使用。如果该业务人员转岗到其他无法使用该标签的部门时，该人员的使用权限也要随之取消。

数据安全审计是一个安全的平台必须支持的功能特性，审计是记录用户使用数据中台进行所有活动的过程，是提高安全性的重要工具。通过对安全事件的不断收集与积累并且加以分析，有选择性地对其中的某些用户进行审计跟踪，以便对发现或可能产生的破坏性行为提供有力的证据。

10.3.6　数据资产运营与数据资产管理的关系

在10.3.2节“数据资产运营的完整链路”中，谈到在数据资产使用过程中，会遇到数据资产本身的问题，如数据质量问题、安全问题、血缘链路不全的问题等，因此需要推动数据资产治理的环节，持续改善数据资产的质量水平。

数据资产运营和数据资产管理是相互促进的关系。在运营的过程中发现数据资产存在问题，倒逼数据资产管理水平的提升；同时数据资产管理水平与数据资产质量的提升，本身又能促进数据资产运营更加顺利地开展下去。这两者之间的关系如图10-13所示。

图10-13　数据资产运营与数据资产管理的关系

这种相互促进的关系并不是天然形成的，必须打通数据资产运营和数据资产管理之间的联系通道。具体来说，首先需要实现数据资产的认责和问责，真正把每一项数据资产、每一个问题都落实到具体的责任人，并且形成一套最终的考核机制，督促相关责任人持续不断地关注与提升数据资产的质量。

10.4　数据成本运营

随着企业数据的增多，对于存储消耗所带来的成本也会随之增加，而数据价值是个缓慢释放的过程，不会马上被挖掘出来，因此需要对数据的存储成本进行相应的分析，通过分析形成的数据来支撑成本运营优化。

在企业发展初期，存储成本可能并不是企业关注的重点，但当数据体量到达一定规模时，数据存储成本会升级为企业的财务包袱。举个非常典型的例子，2014年，阿里巴巴集团预测按照它的自有数据增长情况，如果再不进行数据的管理和成本治理，那么企业的利润可能都会被这种数据的增长所带来的硬件和计算开支吞噬殆尽。

在数据中台运营的下一阶段，企业需要精细化管理数据存储成本。下文将从存储成本和计算成本两个维度展开讨论。

10.4.1　通过细分数据类型，优化数据资产存储成本

伴随着业务的发展，有些数据资产将失去使用价值，也会出现蕴含更高价值的新资产。为了将有限的计算、存储资源最大化地用在更高价值的数据资产上，需要对资产的可用性进行管理。通过对数据资产的上下架管理，控制可用性。

数据的阶段可划分成原始数据、过程数据、结果数据，不同阶段的存储处理也会有所不同。

（1）原始数据成本优化

对于原始数据，一般建议永久保存，有些数据可能当前阶段并没有被应用，但随着场景的不断深入以及挖掘技术的提升，其价值可能会被逐步释放，而如果没有保留原始数据，当价值挖掘条件具备时却发现数据不够，相应的时间成本可能会很高。当然具体情况需要结合企业的实际阶段、业务特点来判断。

（2）过程数据成本优化

过程数据又可以分为临时性的过程数据和支撑结果计算的过程数据。临时性的过程数据，一般都是以临时表的形式存在，支持单次作业计算或者某个任务流的计算过程，处理完之后就可以清除，但有时候开发不够规范时，可能只做了创建、存储的动作，而没有做删除、清理的动作，导致存储成本的浪费。因此在设定开发规范时，可以先对这类数据做一些区分，比如对于临时表的命名可以统一前缀，如统一以“tmp_”开头，方便成本分析处理时快速定位。

支撑结果计算的过程数据，也可以认为是ETL过程的中间结果数据，如对一些原始数据的清洗加工，规整之后形成的汇总表或明细表数据。这部分数据在某些特定场景也可以作为结果数据，但一般由于体量较大，实际应用时会再做一层提取。在考虑这部分数据的存储成本时，一般有三种策略：

·全量存储：不需要跟踪数据的历史变化时一般会采用这种方式，只存储最新的一份快照数据，比如用户上传的一份字典数据。全量存储的管理相对简单，只要有别的表依赖于这份数据，就需要一直将其保留在系统中。

·增量存储：当数据需要跟踪历史变化，且体量比较大时，一般会采用这类方式。早期阿里云梯1上实现的极限存储就是类似方案，只是一种是系统层实现增量存储，还有一种就是自己手工来管理。对于存储成本的考虑主要需要关注数据的引用时效性，全量快照需要根据引用时长有一定的滚动机制，避免存储太多不使用的数据。

·周期快照：对数据历史变化建立周期快照并进行跟踪。重复存储历史数据的成本一般不会太大，而易用性方面却可以大大提升。正常情况下，引用者主要还是引用最新的数据，但出现意外情况时，则可以取最近的数据来保障业务正常运转，如新周期数据没有产出时，业务方可以用上一个周期的数据来补充。另外一种情况是在分析历史变迁过程的状态时，也可以通过这种方式来应用。

周期性的生产依赖于实际被引用的情况，如果所有任务对数据的引用不超过7天，那么留30%左右的冗余，比如10天左右的存储周期，就可以保障下游的正常生产。当然如果出现某一天需要引用更多数据时，则需要联系相关表的所有人来进行补数据操作，将数据补齐到下游所需的最长时间，以保障业务方的正常使用。

（3）结果数据成本优化

在构建数据体系时，根据分层模型最终产出直接为业务提供支撑的数据层，如TDM、ADM的数据集。以前构建数据会根据业务需求，需要什么生产什么，而数据中台中数据体系建设除了业务需求的输入外，从数据层出发构建基于某个对象特定的数据标签集也是一种常见的方式。这种方式可能会带来一些存储上的浪费，就像产品研发一样，产品会根据市场调研或者对问题的定义来研发，而实际研发出来的产品不一定会被市场所接受，哪些产品有价值、哪些没有价值需要通过市场来检验。数据资产也是同样，哪些数据集有价值，哪些没有价值，也需要通过业务来验证。因此在设置结果数据的成本策略时，往往会借助于数据在实际场景中的应用情况来分析，并根据应用数据提供成本策略建议。是加工挖掘更多数据体系来供业务选择，还是专注打磨某个数据体系、做深做透其数据价值，需要视企业的不同阶段、不同业务特点而定，因此数据的成本策略选择上也需要同步跟进。

10.4.2　四种关键优化策略，破解计算成本控制难题

和存储成本息息相关的，就是计算成本。企业数据量增加之后，需要不断对数据进行价值挖掘，才能真正发挥数据的力量，帮企业降本增效。而数据量越大，所需要消耗的计算量也就越大，这也是Hadoop、Spark等产品生态能够欣欣向荣的一个重要原因。

计算的成本相比存储要高很多，CPU、内存都属于稀缺资源，而同时大量的计算会产生大量的热量，需要为数据中心提供较好的物理环境，配备专用的机房通风、降温，甚至有些大企业把数据中心放到千岛湖利用水循环降温，在贵州把山挖空来装机器，在内蒙古利用风的条件来降低机器、设备用电所需要的能源消耗。因此计算成本的控制，对一定数据规模的企业来说也非常关键。

计算成本的控制有很多方面，专属硬件、指令优化等各种手段，各显神通。笔者主要关注数据加工处理的逻辑，通过运营的手段来看计算是否合理、高效。常见的影响计算成本的因素，根据相关的运营经验总结为以下五部分。

（1）重复计算

目前在企业中，数据的利用和软件系统的研发相比，显得更为松散，由于其主要的使用者往往不是研发人员而是业务方，而且使用场景更多更散，因此相应的计算也会存在一定的浪费。其中最常见的现象就是集群资源排满了任务，相互等待资源的释放，数据处理逻辑存在较多重复计算，如：

某用户加工存储了一张结果表A，他的加工逻辑是从5张源表关联加工而来，而另外一个用户想用某个数据，该数据也需要从5张源表关联加工，但发现想要的数据之前并没有人使用，因此也自己动手加工了一张结果表B，当然表B可能除了所需要的数据外，也可能会加工一些当前不需要的字段。

类似场景在企业中使用数据的人员较多的情况下很容易发生。这其中存在以下这些比较明显的问题：

·命名相似：系统识别到多个任务的名称、相应产出的表名和字段名相似度较高，结合某些周期产出数据的抽样对比计算出相似度指数，如果相似度达到了阈值，系统会给相关责任人发出提醒邮件，相关责任人需要进行任务合并或者给出解释。

·相同源头：多个数据抽取任务的输入源头是同一个库的一张或多张表，这样会把同样的数据多次复制到ODS层，这种情况往往是因为负责不同业务的数据工程师之间沟通不足以及数据使用不规范造成的。

·计算类似：多个数据处理任务读取的表相同，输出的表的结果也相同，并且对表的处理特征相似，比如代码逻辑中使用了同样的函数，对结果抽样对比一致。

·产出类似：某个任务在每个周期内产出的数据在很长的时间内（比如半年）都没有任何变化，或检测到使用该数据的服务或者产品已经下线了，比如使用该数据的API调用次数为0，导出该数据的同步任务的目的端数据库已经不再服务。

如何避免上述问题的发生？首先需要能够通过量化的方式计算出作业的重复度，包括输入的重复度和输出的重复度。相应的重复度计算时，需要对每个任务的逻辑或输入输出进行分析，识别出其中的加工方法以及输入输出的匹配情况。在具体运营过程中，可以根据实际情况设置重复率达到多少比例时，需要推进优化，同时配合相应的运营考核机制，推动重复的合并和优化。

（2）冗余计算

在计算过程中，有时由于个人能力有限和对实现过程的思考不够全面，无法做到最优化的数据处理及计算控制，而不合理的数据处理量将大大提高计算的成本，导致企业算力的浪费。在数据指标的加工过程中，合理的数据量输入检测也是需要考虑的问题。这类场景容易出现在处理逻辑时因忽略限定条件而导致数据处理量过大、不合理的数据量处理耗时等情况下。具体可以通过提取数据量与处理耗时的算力基线，以及数据加工输入量的合理性基线分析，发现一些不合理的处理逻辑，从而减少可能存在的冗余计算过程。

（3）低价值计算

和存储类似，也存在一些经过加工得到的数据并没有直接被业务使用，因此与其相关的计算成本同样是浪费。而当大部分的计算成本消耗在当前不需要用到的数据集上时，需要考虑降低这部分的资源或者暂停执行不必要的处理逻辑，避免计算资源的无效利用。

除此之外，也可能出现某些任务在一定的时间长度，比如最近半年内每个周期运算的结果数据持续为空，没有产出任何数据的空跑表情况，在业务上没有意义，却造成了算力成本的浪费。

（4）调度不合理

在数据应用过程中，特别常见的一种现象是每个人都觉得自己的任务优先级很高，都希望在某个时间产出相应的结果，至于是否合理，缺少统一的衡量标准。如何合理分配不同的作业在不同的时间周期进行调度，如何让一些作业见缝插针地挖掘计算资源，也是计算成本运营时必须面对的问题。

其中对于调度时效性的判断，业务的实际需求可能无法精准判断，但通过下游业务的使用情况以及上游的作业加工逻辑，可以做一些相应的分析来为运营提供支撑。尤其是下游的作业与当前作业的时间要求相差较大时，如下游作业在23点处理完即可，而前一个作业却被要求必须在早上6点加工完，这时作业6点调度可能不是很合理；如果上游作业的加工产出时间是23点，而下游作业却要设置在早上6点完成，逻辑上完全矛盾时，也可以通过调整调度设置将调度资源进行重新分配，以达到合理使用算力的目的。

（5）频率不符

某些任务的产出频率和使用该数据的业务对数据更新的频率要求不一致，比如某些任务产出的表保持每小时或者每分钟的高频率更新，但是使用该数据的业务仅仅需要T+1的数据，造成了计算资源的浪费。

10.4.3　数据中台成本账单监管

成本运营是一个不断优化的过程，除了对储存成本及计算成本精细化管理以外，还需要建立一个责任追踪规范：任何一个成本支出账单都可以在第一时间找到责任人，迅速定位成本支出异常的原因，并配合运营团队共同进行降本增效。

这需要从数据的源头开始分析。一个企业所有产生的数据都是有源头的，任何数据的生产加工和最终使用，都可以落实到对应的责任人。作为企业数据运营的负责人，需要明确数据由谁生产，被谁管理，在为谁服务，从而将这个表、这个数据库每天所产生的账单分解到对应的责任人或者部门身上。比如集团公司、子公司、事业部、业务单元，他们今天所产生的数据储存成本、计算成本、使用成本等，都应该被归结成一种账单，发送到各个相应的责任单元，并且进入他们的内部成本考核体系，让各个使用人和数据部门负责人来进行持续优化。

图10-14所示为企业内部数据成本账单的范例，运营负责人可以设置账单报表生成周期，系统会自动按照相关部门使用的存储资源、计算资源、数据底层资源等生成账单，并发送给相关责任人。

当这些账单体系建立之后，作为运营负责人，该如何进行监控？运营团队可以通过稽查工具等扫描检查规范执行、重复建设、资源占用等情况，以邮件或者公开信息形式通告个人或者团队稽查结果，给出团队和个人的排名、警告，并给出优化建议。所有数据开发人员都关注排名以及警告信息，并有专门的团队监督稽查结果改进进度，长期不改进有升级机制，跟考核等结合，并降低占用资源的优先级，从而确保规范落地。

图10-14　企业内部数据成本账单

10.5　数据中台运营的实践经验

数据中台想要运营好，与运营人员、业务人员、开发团队等都密不可分。核心还是要围绕数据中台价值的体现来推动运营的各个环节，这里分享一些笔者在实际落地过程中积累的经验教训供借鉴参考。

10.5.1　全员具备数据意识是中台战略开展的基础保障

数据中台的运营流程由于涉及多个部门的联动配合，因此单靠某一个部门发起，往往难以支撑，做到最后很可能就不了了之了。因此在每个部门人员动作起来之前，最应当疏通的是对数据中台的统一的正确认知。

针对数据中台中最核心的资产部分，首先应该和所有部门明确的是，任何事物都可以用数据去记录、表述、展示，业务开展、评价、优化都需要考虑是否有数据记录，且通过数据进行分析、展示、汇报。数据是唯一客观评价企业管理问题或业务状态的指示牌，所有人都要尊重数据结果，形成以数据指标为导向来说明问题、实践数据化运营的思路。只有把数据意识根植到每个人的心中，在之后的配合行动中才能最快达成共识，免去不必要的争执和试错成本。

其次要明确的是，大家对数据、数据技术、数据资产、数据平台解决问题的能力要有正确的认知，这些都仅仅是资源、工具、能力，最终要想产生价值还需通过组织的力量灵活、坚持、充分地运用。因此数据平台并不能解决所有的业务问题，也不要过于神话云计算、大数据、人工智能的替代作用，企业要想的是如何将这些先进技术运用到自己的业务、管理中去，而不是寄希望买一套数据平台或搭建一套数据平台就能自动化解决难题。

最后，每一个和数据资产运营相关的岗位人员，都要对自身岗位职责、其他岗位职责有清楚的认知。技术人员的岗位职责是搭建运维平台，开发生产数据资产，提供保障数据服务、数据应用的稳定性。但是也要学会站在业务端思考问题，技术人员开发出的结果只有让业务人员使用起来才是有用的，否则都是堆积在仓库的存储，时间久了都要被清理淘汰。业务人员的岗位职责是提出数据需求，将数据资产充分运用起来，并及时给出优化反馈。业务人员一方面要理解数据技术能力的有限性，不能想当然地认为数据可以解决所有问题或者可以立刻解决问题；同时也要学习一些数据理论，来使自己能和技术人员进行一定程度的对话。

在整个数据观树立的过程中，一定是需要企业组织结构从上到下的重视、认知和执行的。通过大量的实践发现，在数据资产运营过程中，一定会涉及大量的新工作，且工作量不小，因此一线工作人员的自发配合是很难形成的，甚至会存在一定的阻力和排斥。因此需要建立从公司CEO、CTO、CIO等高层到公司核心管理层到公司中层再到一线员工的认知建立和意识统一，对数据工作的重视程度，需要和工作目标、工作业绩打通，才能较好地配合执行。

10.5.2　数据中台运营一定要以场景需求为导向

上文提到不同工种需要相互理解、互相融合理解对方的业务知识，但是如果在某一阶段，必须有优先级判断或者必须做一个倾向性的选择时，笔者的建议是以场景优先，而非纯以业务需求为先，场景分析来自于业务需求，但是需要对需求进行抽象。科学技术是生产力，但前提是要为生产服务，不能服务于生产的科学技术只是课本中的理论知识。因此所有围绕数据的采集、清洗、加工、服务化，都需要有一个明确的目的：面向业务需求进行场景抽象，进而最终解决业务问题。

因此数据技术人员需要在原有的一般的数据工作基础上，增加对业务知识、业务人员、业务操作的理解，同时进行必要的场景需求抽象。数据资产有没有价值，只有业务用起来才算；业务能不能用起来，不能纯靠业务人员自己去学习，而是要把数据概念、数据能力、数据产品转化到他们能理解、操作的方式和水平。

当业务人员能够理解、查看数据资产时，需要有运营、技术团队来协助其先践行一个成功的数据应用案例，让他了解数据使用的全流程闭环、感受数据价值的力量，产生对数据资产的兴趣和信心。

不管是教会业务人员自己看、选、用数据资产，还是通过技术团队直接将数据资产封装成数据应用系统供业务使用，最终目标都是要让业务人员走通并成功实践数据应用。运营人员需要通过培训、咨询、典型案例操盘等方式，协助业务人员通过数据应用获得业务效率或收益的提升，让业务人员对数据资产的作用有切身的体会并产生持续使用的兴趣，才会逐渐把所有的业务流程都与数据绑定在一起，养成使用数据的工作习惯。不需要一开始就全面切换数据驱动决策或者数据化运营，这种方式往往过重，所需时间过长，对业务人员的培训改造工作量也较大，不利于积极性、主动性的培养。数据资产要真正运营起来，不能仅靠行政命令，也不能仅靠技术积累，关键还是让业务人员学会并积极主动地运用数据资产。

10.5.3　运营中台本质上是对各部门需求及资源的盘活

在中台运营过程中，数据管理部门（下称“数据部门”）和业务部门是两大核心协作的部门，紧密配合的协作关系可以将中台价值最大化，反之可能会陷入僵局。以数据资产优化过程为例，以往企业中负责数据资产优化的责任部门是数据部门，由数据部门发起数据资产的优化迭代。如果这种优化迭代仅局限于数据加工生产研发范围内，那么数据部门还能推动起来并有效完成；但是当优化迭代涉及数据原始采集部分、数据资产的使用反馈等部分时，因为涉及业务部门的配合，就会难以开展工作。而且因为缺乏数据资产的使用过程信息，就算数据部门想要治理、优化数据资产质量，可能都会无从下手。因此最合适的资产优化的推动者，应该是业务部门。只有当业务人员迫切需要源源不断的数据资产或更高质量的数据资产时，他们才会自发推动数据技术保障团队来一起完成数据资产的优化工作。并且会配合完成数据使用的埋点工作、数据使用的信息反馈、新数据的需求整理等工作。

另一个重要考虑是，在一家企业中，由于业务部门往往是企业的营收中心，而数据部门往往是企业的成本中心，因此业务部门的话语权更大。当资产优化过程中涉及人员投入、设备采购、资源分配等问题时，业务部门有更大范围的调配权。

因此如何调动各部门的积极性，在优化中台机制的过程中紧密配合，需要中台运营团队设计出一套运营机制，在其中进行资源的调配及价值的宣导，让企业各部门共同对数据中台优化的结果负责。

图10-15给出了一个经过实践证明较为有效的协作方式，供大家参考。

图10-15　业务、产品、研发、数据团队配合示意图

业务团队向对口的产品团队提出具体的需求，产品团队分析需求之后，梳理出业务流程，并把需求细化拆分为业务侧需求和数据侧需求，前者指的是与数据本身关系不大的流程类、信息架构类、前端展现形式类的需求，后者指的是纯粹依赖数据本身的需求，如期望展现哪种数据结果、希望怎样去统计、构建怎样的数据模型等。以规划阿里巴巴的商家数据产品平台生意参谋初版为例，目标是为商家提供店铺的流量、商品、交易等经营全链路的数据。为此生意参谋的产品经理把用户操作流程设计、功能模块划分、前端如何呈现和交互作为业务侧需求；同时把每个数据表所需要的数据结果、数据定义和对数据的操作作为数据侧需求，例如店铺的UV、PV信息，该统计哪些粒度，以什么频率更新，对UV和PV能进行哪些维度的筛选等。

10.6　数据中台运营的要素与口诀

数据中台建设是项持续性的工作，有起点，没有终点。高层的数据战略是人、财、物持续投入的保障，有高层的数据战略才有全集团的数据意识，数据意识推动数据应用场景落地，发挥出数据的价值。

同时，数据中台建设还需要有一套契合集团数据现状以及未来发展的方法规范。数据建模方法大同小异，关键需要一套规范保障方法的执行，比如命名规范、开发规范、数据分层规范、数据隔离规范、易用性原则，这套规范是数据体系可用、易用、好用的关键，是数据有可能更多参与业务的基础。

另外，数据中台建设涉及多个团队长期协作，由于人员的变化以及业务的发展变化，很难靠人保证规范的持续执行。建模、质量、稽查、数据地图等工具是保障规范执行的有效手段。很多在中台建设走在前列的企业，就是把规范融入工具中，这是数据中台运营成功的关键。

最后，战略的执行、方法规范的制定、数据工具的落地都需要有组织人员保障。要有数据委员会做顶层设计，制定建设目标、规范、制度并推动执行。专业、稳定的数据业务、数据技术团队，落实目标规范的执行。数据团队的考核与业务发展绑定，推动数据在业务中发挥实际价值。

数据中台从立项到正式运作起来，是条漫漫长路，在地基稳固的基础上，运营工作是数据中台这条路越走越宽敞、越走越平坦的保障。因此，贯穿始终的精细化运营是企业数据中台建设过程中必不可少的一环。

结合以上内容，附赠一首简单好记的中台运营口诀，方便大家理解中台建设及运营过程中的要点和方法，如图10-16所示。

图10-16　中台运营口诀

10.7　中台手记（七）：让数据用起来

10月8日　周二　晴　地点：CIO办公室

随着集团数据中台建设的逐步完善，采用什么运营策略能让数据中台的效果在整个集团体系内落地，是近期在思考的核心问题。

国庆节后第一天上班，我特意约了数据部门运营负责人杨东，针对运营策略进行探讨。

杨东是一个很干练的经理人，在集团很多部门都轮岗过，非常熟悉公司各业务部门的流程和现状，同时又具备丰富的运营实操经验，对于数据运营，他抛出了三个策略。

“刘总，数据中台项目已经上线了，中台运营策略将主要覆盖以下三个层面：

一是场景价值层面，关键在于如何在企业内部自上而下地传递数据意识。

二是数据资产层面，关键在于如何将数据资产真正用起来。

三是数据成本层面，关键在于如何降低数据中台技术硬支出。

“首先，数据中台立项及推进的过程，对于集团全员数据意识的提升，影响是立竿见影的，后面也将通过持续的项目推进会、业务数据通报以及优秀典型示范等举措，不断提升大家的数据意识。比如，前段时间给行政部门做了一个大数据事业部员工基本信息的可视化大屏，如图10-17所示，大家看到之后觉得非常震撼，其实这样的一些小‘花招’，也可以潜移默化地培养大家的数据意识。

“其次，落实到数据资产层面，需要配备专职运营人员对资产对象进行从组织登记、宣传推广、服务保障、治理优化到价值评估的统筹的运营执行管理。总之，目标就是将数据资产变得可阅读、易理解、好使用、有价值，不断挖掘提升数据资产的价值，使之变成企业的核心增值资产。

“此外，数据成本也是需要考虑的重要方面，咱们作为大的集团公司，数据体量已经达到一定规模，目前集团部署的服务器每年的成本已经突破1亿元，如果再不对数据存储成本进行相应的分析来支撑成本运营的优化，数据储存成本总有一天会升级为集团的财务包袱。”

数据成本运营也是我非常关心的问题，这是个需要不断优化的过程。

杨东继续侃侃而谈：“除了对数据产生的储存成本及计算成本进行精细化管理以外，关键还要建立一个责任追踪规范：对于任何一个成本支出账单都可以在第一时间找到责任人，迅速定位成本支出异常的原因。因此，打算建立一套数据中台成本账单监管机制，会定期按照各业务线或各部门使用的存储资源、计算资源等生成账单，并发送给相关责任人……”

数据运营不可能一蹴而就，是最需要打持久战的。而杨东对数据运营的认知，既能高屋建瓴，又能脚踏实地，我很是欣赏，年轻人实在是不可估量，而他们也正是集团数字化转型的中坚力量！

图10-17　大数据事业部员工可视化大屏

第11章　数据安全管理

数据安全管理既是数据资产管理中不可或缺的一部分，又是信息安全管理的重要组成部分。但因为其重要性和特殊性，笔者将其从第8章“数据资产管理”中剥离出来，专门用一章来阐述。进入大数据时代，数据安全面临愈发严峻的挑战，各国政府、各个组织和个人也都更加重视数据的保护，通过建立安全管理体系，尤其是一系列法律政策、制度流程、技术手段等，来保障数据的安全与隐私。

11.1　数据安全面临的挑战

随着大数据技术和应用的快速发展，数据所承载的多维度业务价值已被越来越多地挖掘和应用变现，数据中台成为数字经济时代信息基础设施不可或缺的核心。随之而来的是数据安全和隐私已经成为世界性的关注点，上升到国家战略层面，如何在满足用户隐私保护、数据安全和政府法规的前提下，进行跨组织的高效数据应用是数据中台必须解决的一大难题。

11.1.1　数据安全问题带来的4大损害

数据安全出现问题，可能会在个人安全、组织安全、公共安全、国家安全四个层面造成损害。

·个人安全：数据滥用行为危害到个人安全，包括人身、财产、名誉等公民合法权益。此方面为个人信息保护法律管控的主要内容。但个人信息保护的合法化、客户授权、去标识化、可审计等要求与个人信息频繁、高效使用存在天然的矛盾，如何化解这些矛盾，给数据安全管理工作提出了非常高的要求。

·组织安全：数据处理行为危害到其他组织的合法利益，包括知识产权、商业秘密，以及其他竞争和名誉等方面的利益。例如企业非法爬取其他企业的数据，企业非法窃取其他企业的商业秘密，企业非法使用其他企业的知识产权（比如商标、专利等）。

·公共安全、公共利益、公共秩序：数据处理行为危害到公共安全、公共利益、公共秩序。例如企业公开发布统计信息影响到行政管理、经济秩序等。

·国家主权、安全、发展利益：数据处理行为危害到“国家在政治、经济、国防、外交等领域的安全和利益”。例如企业通过数据聚合分析，推论出国家秘密，进而影响国防、国际关系等。

11.1.2　法律与政策背景

自从数据产生以来，数据的安全与隐私管理就是一个非常重要也非常庞大的话题。人类进入大数据时代，由于数据大量汇聚，不占体积，极易被复制、携带和传输，而其本身又是在网络节点之间不断流动，使得黑客成功攻击一次就有可能获得大量有价值的数据，极大降低了黑客的攻击成本。针对数据的犯罪日趋猖獗，后果也越来越严重，因此数据安全与隐私管理在世界各国愈加受到重视。

为了维护国家安全、社会公共利益，保护公民、法人和其他组织在网络空间的合法权益，保障个人信息和重要数据安全，根据《中华人民共和国网络安全法》等法律法规，国家互联网信息办公室会同相关部门研究起草了《数据安全管理办法（征求意见稿）》，并于2019年5月28日发布，向社会公开征求意见，意见反馈截止时间为2019年6月28日。《数据安全管理办法（征求意见稿）》全文共计五章四十条，系统地规定了网络运营者数据收集、数据处理使用、数据安全监督管理等覆盖数据全生命周期的综合合规要求，直面强制捆绑授权、网络爬虫、定向推送、自动化洗稿、算法歧视等新型数据安全问题，对违反数据安全的行为进行了有效约束，标志着我国数据安全管理迈出了具有里程碑意义的一步。国家互联网信息办公室与中央网络安全和信息化委员会办公室为一个机构两块牌子，属于中央直属机构序列，拥有规章制定权。因此，一旦《数据安全管理办法（征求意见稿）》正式生效，其将成为我国数据安全管理领域首个综合性规章。由此可见，数据安全管理已经成为国家层面重视的重大课题。

“九一一”事件后，美国政府意识到信息安全的重要性，先后制定了一系列法案，来打击计算机网络犯罪，保障关键信息基础设施的安全，如《联邦信息安全管理法案》《加强网络安全法》《公共网络安全法》《加强计算机安全法》等。近年来，云计算、大数据、物联网、移动互联网等新技术的迅速普及，给个人信息安全保护带来了极大冲击，也推动了新时期各国对相关法律的立法及修订进程。美国在原有体系之上，积极制定了应对上述挑战的法案，于2012年2月23日发布了《网络环境下消费者数据的隐私保护–在全球数字经济背景下保护隐私和促进创新的政策框架》，正式提出《消费者隐私权利法案》，规范大数据时代隐私保护措施，以确定隐私保护的法治框架。

欧盟GDPR（General Data Protection Regulation，通用数据保护条例）于2018年5月25日正式生效，被称作史上最严苛隐私数据保护法。GDPR与其前身《数据保护指令》相比，适用于更大范围的组织，所有处理欧盟国家公民数据的组织，都必须遵守该法案，这意味着凡是要跟欧盟打交道的机构，无论是政府还是社会组织、公司，都必须遵守该法案。众多可能违反GDPR法案的公司受到调查，这些调查案件的主体，涉及众多美国互联网巨头，其中包括谷歌、苹果、Facebook、WhatsApp、Instagram、Twitter、LinkedIn以及Quantcast等多家公司，这些公司可能会受到巨额罚款。

总体而言，全世界的政府和组织都越来越重视数据安全保护，从法律与政策等各方面进行引导与约束。

11.1.3　数据安全的4大技术挑战

总结来看，大数据平台安全面临的安全风险和技术挑战可以总结为以下几条。

1.平台安全

从大数据技术的发展来看，基于Hadoop生态系统的大数据平台随着企业的不断采用及开源组织的持续优化、增强，已逐渐成为大数据平台建设的标准产品。然而Hadoop最初的设计专注于发展数据处理能力，忽视了其他能力的发展，但Hadoop生态系统作为一个分布式系统，承载了丰富的应用，集中了海量的数据，如何管理和保护这些数据充满了挑战，当前市场上，大数据平台在数据本身的安全管控方面普遍存在严重缺陷和较大漏洞。

大数据平台是使用数据资源的基础平台，平台安全是保障安全可靠地利用数据资源的基础。大数据平台除了面临传统的恶意代码、攻击软件套件、物理损坏与丢失等安全威胁外，由于自身架构要根据企业业务需求和安全要求变化不断改进，因而产生传统的身份认证、数据加密手段适用性问题。由于大数据平台是复杂且异构的，所以安全保障必须是整体性的，以确保大数据服务的可用性和连续性。

2.服务安全

为了更好地利用大数据的价值，越来越多的大数据平台开始面向企业内外部用户提供基于大数据的服务。便捷的互联网应用环境下，在提供优质数据服务的同时，也为大数据服务安全带来严峻的安全挑战，大数据平台需要应对基于？Web的攻击、应用程序攻击？、注入攻击、拒绝服务攻击、网络钓鱼、用户身份盗窃等威胁，抵御信息泄露、网络瘫痪、服务中断等安全风险。

3.数据本身的安全

企业在开展业务和对大数据进行开发利用的同时，数据自身安全非常重要，数据安全涉及数据生命周期各个阶段，包括数据采集、数据传输、数据存储、数据处理、数据交换、数据销毁等活动。行业间以及行业内部数据交换共享时的数据安全，是迫切需要解决的问题，是大数据资源实现开放共享的关键。

数据已经被社会公认为有价值的资产，数据可变现、易变现的特点使得接触到数据的人员窃取数据的动机或可能性大大增加。不同于传统的资产，数据不占体积，极易被复制、携带和传输，而其本身又是在网络节点之间不断流动着的，这些特点让数据安全管理的难度极高，而数据泄露所带来的损失又是实实在在的，一旦发生高风险事件，会造成巨大的经济损失并有可能触犯法律，社会上已经发生过很多次惨痛的教训。这些给数据安全管理带来更大的挑战。

4.APT攻击防御

APT（Advanced Persistent Threat，高级可持续威胁攻击），也称为定向威胁攻击，指某组织对特定对象展开的持续有效的攻击活动，是一种蓄谋已久的“恶意网络间谍威胁”。这种攻击活动具有以下特点：

·针对性强。APT攻击是以商业和政治为目的的网络犯罪。这种攻击方式往往不会追求短期的经济收益和单纯的系统破坏，而是专注于窃取核心资料，如国家安全数据、商业机密、知识产权等。

·组织严密。由于APT攻击针对性强，获益巨大，因此攻击者往往以组织的形式存在，并进行分工协作。

·持续时间长。APT攻击具有较强的持续性，往往要经过长期的准备与策划，攻击者通常在目标网络中潜伏几个月甚至几年，通过反复渗透，不断改进攻击路径和方法，发动持续攻击，如零日漏洞攻击等。

·极强的隐蔽性。APT攻击通常会运用受感染的各种介质、供应链和社会工程学等多种手段实施先进、隐蔽、持久且有效的威胁和攻击。APT攻击根据目标的特点，能绕过目标所在网络的防御系统，极其隐藏地盗取数据或进行破坏。

·间接攻击。APT攻击通常利用第三方网站或服务器作跳板，布设恶意程序向目标网络进行渗透攻击。恶意程序或木马潜伏于目标网络中，攻击者往往在远端进行遥控攻击。

由于APT攻击以窃取核心资料为目的，对政府部门和企业的大数据安全产生重大威胁，因此必须高度防范此类攻击。针对APT攻击行为的防范需要构建一个多维度的安全模型，既有技术层面的检测手段，也包含用户安全意识的提高。如可以通过部署入侵检测系统和入侵防御系统，启用反病毒保护软件，启用垃圾邮件过滤程序，良好的补丁管理机制，对用户进行安全意识培训等手段，做到事前防御。

11.1.4　数据安全的3大市场挑战

随着数据安全重要性的提升，用户在这个方向的投资也在增大。在我国，随着《中华人民共和国网络安全法》的出台，数据资产价值得到确认，政府机构和企业在这个方向的投资也在加码，以数据审计、脱敏和加密等为目标的数据安全投资正在成为采购的热点。但市场的机遇与挑战并存，综合来看，笔者把挑战分成三类：企业内部面临的挑战、对大数据服务商的挑战，以及数据确权问题。

1.企业内部挑战

从企业内部来说，一方面，大数据平台的安全管控能力缺失，使得平台在数据存储、处理以及使用等各环节造成数据泄露的风险较大，安全风险面广，且缺乏有效的处理机制；另一方面，企业敏感数据的所有权和使用权缺乏明确界定和管理，可能造成用户隐私信息和企业内部数据的泄露，直接造成企业声誉和经济的双重损失。

一个全球化的企业，或者业务涉及跨境电商等业务的企业，必然会涉及数据的跨境问题。不同国家和地区的数据保护法规对数据跨境流动的要求存在差异性，比如俄罗斯明确提出俄罗斯公民的数据应在俄罗斯境内更新后方可传到海外进行处理，欧盟则扩大了数据保护法律适用的管辖范围。这些法规将给跨境电商企业带来高昂的合规成本，制约了跨境业务的发展。如何处理数据跨境安全合规与跨境电商战略发展的矛盾，是亟待解决的难题。

要实现组织内部的数据安全管控，一方面需要根据现有法律法规、国际标准、行业标准以及企业的信息安全策略，制定安全、可靠、可执行的数据安全相关的标准、规范和操作流程；另一方面要建立企业数据安全风险分析范围，通过安全风险分析，制订切实可行的风险防护措施，对现有安全控制措施的有效性进行评估，提升数据安全等级，确保企业数据安全得到有效提升。

如建立数据安全等级，指定专门的数据安全管理员和责任人，经常开展数据安全宣讲工作，对数据进行分级分类管理，制定并落实系统安全、网络安全、密码安全、密钥安全、数据备份和恢复制度、数据共享安全制度、数据销毁环节的安全管控措施。

2.对大数据服务商的挑战

随着企业云化进程的加速，越来越多的数据会产生、处理、存储在云端，不论是公有云还是私有云都需要支撑各类技术服务商，站在大数据服务提供商的角度，在服务客户的过程中，也越来越能感受到客户的这种变化和要求。在数据中台的项目中，客户要求在存储、传输、使用、共享个人信息的阶段，均需要去标识化。如进行身份证号隐藏、家庭住址隐藏等。在这个过程中，还需要在保证合法合规的前提下充分考虑数据可用性。这就需要与企业内部的数据安全人员不断地进行沟通与讨论，才能最终确定数据安全方案。关于如何去标识化，读者可以参阅2017年国家标准委员会发布的《信息安全技术个人信息去标识化指南》征求意见稿。

3.数据确权问题

数据的所有权、使用权、管理权涉及个人、企业、政府和其他组织，一旦处理不当，会损害个人隐私、组织利益、国家安全等。在进行大数据收集、处理和应用的过程中，必须做到权责分明，厘清数据权属关系，防止数据流通过程中的非法使用，保障数据安全流通。但是目前数据权属仍缺乏法律支撑，数据使用尤其是跨境流动所产生的安全风险日益凸显。需要政府牵头、市场参与，形成数据权益的确认和共享机制，有效保护数据权益，推进整个社会数据的有序开放和融合。

11.2　贯穿数据全生命周期的数据安全管理体系

广义上的数据安全管理涵盖范围很广，包括监管主体、监管方式、监管对象、国家立法、互联网信息安全、个人隐私保护等多方面的内容。本书要介绍的数据安全管理，侧重于包括企业或者政府组织内部的数据安全管理，是狭义上的数据安全管理，重点放在大数据平台的安全管理技术手段上。数据安全管理既是数据资产管理中不可或缺的一部分，又是信息安全管理的重要组成部分。

11.2.1　数据生命周期

传统时代，数据基本都在某个组织的内部，使用人员相对可控，可变现程度较低，只要把网络安全和系统安全做好，就可以在很大程度上防范数据安全风险。但我们已经迈入大数据时代，数据具有高流动性、高价值、可衍生性等特点，数据安全管理需要针对数据流动的每一个环节，因此，数据安全管理必须贯穿图11-1所示的数据的整个生命周期。

图11-1　数据生命周期

1）数据产生：指新的数据产生或现有数据内容发生显著改变或更新的阶段。

2）数据存储：指非动态数据以任何数字格式进行物理存储的阶段。

3）数据传输：指数据在组织内部从一个实体通过网络流动到另一个实体的过程。

4）数据使用：指组织在内部针对动态数据进行的一系列活动的组合。

5）数据共享：指数据经由组织与外部组织及个人产生交互的阶段。

6）数据销毁：指利用物理或者技术手段使数据永久或临时不可用的过程。

数据全生命周期的每一环节上基于不同类型的数据、不同的应用系统、不同的人员等有不同的风险，无论哪一个环节出现了问题，都有可能发生数据安全事件。这很容易理解，只要出现一个薄弱环节，敌人一定会首先从那里发起攻击。数据的价值与日俱增，靠窃取数据获取非法收入的黑灰色产业链给数据安全防护带来巨大风险。

11.2.2　数据安全管理体系

整体的数据安全管理体系通过分层建设、分级防护，利用平台能力及应用的可成长、可扩充性，创造面向数据的安全管理体系系统框架，形成完整的数据安全管理体系。

数据中台的建设，应该始终把数据安全管理放在最重要的位置上，通过设计完备的数据安全管理体系，多方面、多层次保障大数据安全。一个完备的数据安全管理体系包括安全战略、安全组织管理、安全过程管理、安全技术保障、数据运行能力保障、数据生命周期安全保障，如图11-2所示。

（1）安全战略层面

企业的主要负责人要带头深入理解业务范围内世界各国对于数据安全与隐私相关的法律法规，制定适合企业可落地的相关制度，并进行组织规划。

（2）安全组织管理层面

要建设相关的数据安全保障组织，开展人才储备、宣传培训等工作，并保证相关的资源到位。

（3）安全过程管理层面

需要设计一套涵盖规划、设计、实施、运维、测评、改进的安全管控流程，通过流程的不断循环，持续改善安全管理各个环节的水平。

图11-2　数据安全管理体系

（4）安全技术保障层面

要从系统层安全、应用层安全、数据层安全、平台设施层安全等多个层次保障安全。以系统层安全为例，需要选用高安全性、成熟的操作系统，从官方渠道下载和打补丁，保障安全扫描软件的正常运行等。

（5）数据生命周期安全保障层面

要根据数据在生命周期的不同阶段，设计不同的安全防护措施，以数据传输安全为例，要保证数据传输的安全，保证敏感数据传输的时候不会被截取，需要传输加密等手段，即使黑客截获了数据包，也无法解析其中的内容。

（6）数据运行能力保障层面

需要态势感知、监控预警、阻断和恢复等多种手段，举例来说，大数据平台可以识别和监控可疑账户，一旦可疑账户发生异常访问，如访问敏感数据，或者频繁查询和获取某些数据，系统可以立刻发出告警，并阻断和跟踪该账户的其他网络行为。

只有兼顾数据安全管理体系中的这六个层次，从多个维度去保障大数据，才能打造一个安全可靠的数据中台体系。

11.3　大数据平台安全管理技术手段 11.3.1　统一安全认证和权限管理

有了数据安全管理的理论支持、管控措施，还需要落实到具体的技术实现上。一提到Hadoop集群安全，首先就会想到业界通用的解决方案：Kerberos。Kerberos是一种网络认证协议，其设计目标是通过密钥系统为客户机/服务器应用程序提供强大的认证服务。该认证过程的实现不依赖于主机操作系统的认证，不需要基于主机地址的信任，不要求网络上所有主机的物理安全，并假定网络上传送的数据包可以被任意读取、修改和插入数据。在以上情况下，Kerberos作为一种可信任的第三方认证服务，是通过传统的密码技术（如共享密钥）执行认证服务的。

Kerberos通常会与LDAP配合使用。在大数据平台通常服务器多、租户也较多，需要进行Linux层面及应用层面的统一，这也就是构建Kerberos+LDAP这一组合的缘由。LDAP是一个轻量级的产品，作为一个统一认证的解决方案，其主要优点在于能够快速响应用户的查找需求。当需要进行账号认证时，会请求KDC Server即Kerberos的服务端（请求者需要安装客户端，客户端中存有KDC所在机器的域名），KDC拿到账号密码后，会向LDAP中查询密码的请求，这个步骤很快，大量并发时通常比MySQL要快。如果密码匹配则通过认证。通过认证后，就可以在机器上进行其他操作。

除了统一认证，在数据的传输过程中，可以通过选择适合的SSL（Secure Socket Layer）证书，对传输中的一些敏感数据进行加密。SSL证书可加密隐私数据，使黑客无法截取到用户敏感信息的明文数据，因此部署SSL证书是网络安全的基础防护措施之一。一份SSL证书包括一个公共密钥和一个私用密钥。公共密钥用于加密信息，私用密钥用于解译加密的信息。当用户端的浏览器指向一个安全域时，SSL同步确认服务器和客户端，并创建一种加密方式和一个唯一的会话密钥。它们可以启动一个保证消息的隐私性和完整性的安全会话。

在数据的操作和应用过程中，可以通过权限管理，控制不同的角色能操作的数据权限。设计良好的大数据平台权限管理，能从两个维度控制角色权限：第一个维度是控制粒度，如控制到字段级权限，两个不同角色的用户，可能第一个用户只能访问一张表的前5个字段，第二个用户只能访问同一张表的后5个字段；第二个维度控制动作，如控制该角色是否能进行select、alter、delete等操作。

11.3.2　资源隔离

在资源隔离层面，可以通过建立不同的租户，对不同权限的数据资源进行隔离。多租户技术是一种软件架构技术，可实现在多用户环境下共用相同的系统或程序组件，并且可确保各用户间数据的隔离性。多租户在数据存储上存在三种主要的方案，按照隔离程度从高到低，分别是：

·独立数据库

·共享数据库，隔离数据架构

·共享数据库，共享数据架构

上面介绍了三种数据安全管理的技术手段：统一安全认证、SSL证书实现数据加密、多租户技术。在数据安全管理的实践中，往往还会使用到更多的技术手段，如数据访问日志审计、数据服务管控等，在此不一一介绍。

11.3.3　数据加密

数据加密是用某种特殊的算法改变原有的信息数据使其不可读或无意义，使未授权用户获得加密后的信息，因不知解密的方法仍无法了解信息的内容。在大数据环境下，数据具有多源、异构的特点，数据量大且类型众多，若对所有数据制订同样的加密策略，则会大大降低数据的机密性和可用性。因此，需要先进行数据资产安全分类分级，然后对不同类型和安全等级的数据指定不同的加密要求和加密强度。尤其是大数据资产中非结构化数据涉及文档、图像和声音等多种类型，其加密等级和加密实现技术不尽相同，因此，需要针对不同的数据类型提供快速加解密技术。

根据数据是否流动的特点，数据加密分为存储加密和传输加密。

数据存储加密会根据数据的安全分级采用不同的加密方式，一般数据可以直接采用明文存储或者明文加上验证码存储，对于重要数据和关键数据则除了附加验证码之外，还需要先加密后存储以防止数据被非法窃取或篡改。

数据传输加密在数据流转过程中，通过端对端的专用加密通道，使数据以密文形式在网络上进行传输，防止数据被截取。

根据密钥类型的不同，将现代密码技术分为两类：对称加密算法（秘密钥匙加密）和非对称加密算法（公开密钥加密）。

对称钥匙加密系统是加密和解密均采用同一把秘密钥匙，而且通信双方都必须获得这把钥匙，并保持钥匙的秘密。非对称密钥加密系统采用的加密钥匙（公钥）和解密钥匙（私钥）是不同的。

用户应该根据操作的数据的特点来确定具体使用哪种算法。举例来说，由于非对称加密算法的运行速度比对称加密算法的速度慢很多，当用户需要加密大量的数据时，建议采用对称加密算法，提高加解密速度。对称加密算法不能实现签名，因此签名只能采用非对称算法。由于对称加密算法的密钥管理是一个复杂的过程，密钥的管理直接决定着它的安全性，因此当数据量很小时，可以考虑采用非对称加密算法。

11.3.4　数据脱敏

为了防止用户隐私信息、商业机密信息和企业内部数据泄露，在数据的传输、共享、展现等环节，往往需要对数据中台中的某些敏感数据进行脱敏操作。

大数据脱敏主要包括以下两大功能：

·敏感数据识别：通过设置敏感数据的发现机制，计算机自动识别敏感数据，并在发现敏感数据后自动为该敏感数据打上相应的标签。

·敏感数据脱敏：提供敏感数据的动态脱敏功能，保障敏感数据访问安全。同时基于大数据安全分析技术，发现访问敏感数据的异常行为，并在可能的情况下进行追踪。

1.敏感数据识别

（1）建立敏感数据规则

防止敏感信息泄露的第一步是定义企业敏感信息，通过建立敏感信息样本库，定义企业的敏感信息的具体特征。

敏感信息库内置企业各类敏感信息的识别规则，包括但不限于：

·身份证号码

·手机号码

·生日

·信用卡号码

同时敏感信息规则应支持用户自定义各类敏感信息规则，以便在不同应用场景中允许用户进行规则扩展。

（2）敏感数据检测

脱敏系统支持对大数据平台存储的结构化和半结构化数据库、表进行敏感数据扫描探测，并对每个数据表进行抽样数据匹配，基于敏感信息库来检测存储在大数据平台的敏感数据，如客户信息、交易数据等。

脱敏系统将数据库中包含敏感信息的表和字段标记出来以实现各类高级数据安全功能。例如，已知用户数据库表中含有多种类型的客户信息（如用户姓名、身份证号、账号、手机号等），利用敏感数据标记实现以下自定义规则：

·只向外传输姓名，不是信息泄露事件；

·姓名、账号和电话等信息同时向外泄露，则认定为信息泄露事件。

数据检测支持在给定数据行的任意列组合的基础上进行检测。例如，接受单一姓名、账号、电话的检测，也能够接受“姓名”和“身份证号码”字段的组合，因此可以灵活、方便地进行敏感数据的检测。

用户管理人员采用内容描述匹配来辅助建立敏感数据样本库。内容描述匹配具有高度准确性，对结构化和半结构化数据同样适用，它通过用户输入关键字、模式匹配、文件类型、文件大小、发送人、接收人、用户名和网络协议等各类条件，来实现敏感信息的检测。

2.敏感数据脱敏

数据脱敏方法可根据用户需求的不同而进行定制，最常见的脱敏方式包括如下几种形式：

·数据替换：以虚构数据代替数据的真实值。

·截断、加密、隐藏或使之无效：以“无效”或“*”等代替数据的真实值。

·随机化：以随机数据代替数据的真实值。

·偏移：通过随机移位改变数字型的数据。

11.3.5　数据共享安全

数据对外共享一般包括两种方式：接口和文件。

接口方式包括接口数据（JSON/XML）、流式数据（Kafka）等多种数据访问方式。通过API操作权限管理、API流量管控、API认证管理等手段实现接口管控。

文件方式主要指通过FTP、SFTP、邮件等对外共享数据，数据类型包括TXT、CSV、Word、PPT、Excel、HTML等，通过数字暗水印进行安全防护。数字暗水印通过对共享的文件嵌入暗水印作为标记一起传输，保障数据在发生泄露时，能够提取水印信息并追踪至责任人，达到事后安全保护的目的，解决了数据泄露后无法追踪、难以定责、难以避免再发生的问题。

11.3.6　数据的容灾备份

服务器的硬件故障、软件故障、网络发生问题等，都可能导致数据丢失、错误或损坏。另外，人为的操作失误、自然灾害、战争等不可预料的因素，也可能导致发生不可挽回的数据丢失，给用户带来巨大损失。

为了应对这些情况，用户必须考虑数据的容灾备份，确保在任何情况下都不会影响到重要业务活动的持续开展。

用户可以根据恢复目标将业务的关键等级划分为核心业务系统、一般性重要业务系统和一般业务系统三个级别，并根据不同级别分别有针对性地制订容灾备份方案。比如针对核心业务系统，采用存储数据双活的方式来实现业务系统的持续可用；针对一般性重要业务平台，可以采用主流成熟的备份系统进行定时备份保护；针对一般业务系统可根据业务数据的重要程度，采用定时备份或者不备份策略。

11.3.7　数据安全的其他技术

数据安全管理的技术手段中，除了前面所讲的统一安全认证和权限管理、资源隔离、数据加密、数据脱敏、数据共享安全、数据容灾备份之外，还有一些数据安全技术同样应用广泛，如数据的匿名处理、人工加干扰，应对数据共享、发布时的隐私保护，以及隐私数据可信销毁、数据水印、数据溯源、角色挖掘等技术。

（1）数据发布匿名保护技术

数据发布匿名保护技术使用K-匿名化（K-anonymization）等一系列技术手段，使攻击者不能判别出隐私信息所属的具体个体，从而保护了个人隐私。

（2）数字水印技术

数字水印是指将标识信息以难以察觉的方式嵌入数据载体内部且不影响其使用方法，多见于多媒体数据版权保护，也有针对数据库和文本文件的水印方案。数字水印技术能保障数据在发生泄露时，能够提取水印信息并追踪至责任人。

（3）数据溯源技术

数据溯源技术的目标是帮助人们确定各项数据的来源，也可用于文件的溯源与恢复。其基本方法是标记法，比如通过对数据进行标记来记录数据在大数据平台中的查询、流动与传播历史。

（4）角色挖掘技术

角色挖掘技术指的是根据现有“用户–对象”授权情况，设计算法自动实现角色的提取与优化。有效的角色挖掘可以为用户权限提供角色最优分配，鉴别在正常模式外进行操作的用户，检测并删除冗余或过量的角色或用户权限，使角色定义及用户权限保持最新。在设计角色挖掘算法的过程中，要特别注意信息中隐藏的噪声数据对角色挖掘结果造成不良影响，需要对这些噪声进行识别和处理。

进入大数据时代，数据安全面临越来越严峻的挑战，一旦发生数据泄露事件，往往影响着一个部门甚至一个企业的生死。但同时数据安全管理也是容易被忽视的工作。这是因为在人们的意识中，“未发生的总是不重要的，不紧迫的”。本章分析了数据安全面临的挑战，如何建立数据安全管理体系，保障大数据安全的技术手段，探讨了如何进行完善的数据安全管理，保障数据的安全与隐私。

11.4　中台手记（八）：数据安全！数据安全！数据安全！

11月22日　周一　雾霾　地点：CIO私家车/CIO办公室

又是一个周一的清晨。

今天估计是天气的原因，路上一路拥堵，心情也莫名地烦躁。

刚打开交通电台，想听音乐舒缓一下心情，这时候蓝牙耳机响了，传来了马总急促的声音。

“刘锋，你看到新闻了吗？美国某全球连锁品牌旗下酒店预订系统遭网络“黑客”入侵，泄露大约5亿个客户的用户信息。据说将面临消费者125亿美元的索赔，这下他们可是有大麻烦了！SL集团旗下有庞大的数据信息，你们一定要引以为戒，千万不要出现这样的数据安全事件啊！”

“好的，马总，谢谢您的提醒，数据安全是数据中台项目首要考虑的环节，这块一定会处理好的！”我赶紧回复道。

到了公司，立刻召集部门骨干人员开会，数据安全早就在考虑范畴内，不过马总提到的事让我觉得有必要将数据安全尽快提上项目议程来。

赵伟不紧不慢地说：“数据安全主要包含两个方面：一个是技术层面，需要保证存储中不丢失，传输中不泄露，并能抵抗一定的攻击；另一个是业务层面，需要保证分层分级授权，以及隐私信息的脱敏加密。技术层面需要作专项研究，业务层面除了在工具上提供基本的功能，还需要调研特定的业务，看是否对系统有特定的需求。”

“对的，技术层面我已经做过调研，大数据平台对数据的存储已经有了备份策略，特殊数据的传输也会采取加密措施。业务上的分层级授权，业界有一些开源和商业的方案，我正在做技术选型的评估。”姚冰显然对于这块也是做足了功课。

“好的，技术上的评估后面发一些报告给我，另外你们找一些关键业务线，比如商业地产和零售，开展一次安全方面的需求调研，把之前没有考虑到的需求整理一下发给我。”

……

“姚总，商业地产和零售已经调研过，他们主要关心的就是数据不泄密，使用中有监控预警，使用后有审计，便于事后追查，为此需要提供一些相关的功能，都在前期考虑的范围内。”

开完会后，我长舒了一口气，不禁感叹，有多少公司倒在数据安全的门槛上。在大数据应用场景下，数据利用和数据安全是天然矛盾的两端，如何把握这个度，需要不断探索。需要投入更大的资源去研究同态加密、多方安全计算等前沿算法，同时推动数据脱敏、数据审计等技术手段在大数据环境下的增强应用，提升大数据环境下的数据安全管理水平。

经过数据中台战略项目一役，SL集团已经在数据应用、数据治理、数据安全等各方面取得里程碑式的突破，但我和我的伙伴们依然在路上……

附录　6大行业解决方案架构图