数据中台——数据开放篇

数据中台之数据开放篇

自高校进入数字化校园建设阶段，数据共享的需求便一直是不可忽略的一部分。在当时的背景限制下，各部门管理信息系统长期处于烟囱式建设的状况，由此导致的数据割裂和信息孤岛问题给高校带来了很大的困扰。为了解决数据跨系统互通的难题，高校逐步开展了数字化校园平台的建设，其中最为有代表性的就是高校行业的三大平台之一：公共数据交换平台。公共数据交换平台/主数据管理平台等产品实现了将分散的业务数据集中、整合、分发，一定程度上解决了管理信息系统之间主数据的共享和交换难题，为业务管理效率和使用体验均带来了提升的作用。但在当前高校的智慧校园建设过程中，越来越多的学校感受到，面对激增的业务应用和大数据分析需求，原有的数据平台已疲于应对，这不得不让我们对传统的数据平台架构和数据开放方式进行剖析：

图：传统公共数据平台架构图

上图是一个典型的传统数据平台架构图，从中可以发现，其核心是数据库层面的直接抽取和推送。一般而言，数据平台接收由管理信息系统厂商提供的对应数据视图，在共享库中完成一定程度的整合后再推送到其它管理信息系统的中间库中，需要数据的管理信息系统再进行数据的订阅和使用。

值得肯定的是，在学校系统数量不多、信息化建设变化幅度较小的过去十年，这类架构具有操作直接、交付快速的优点，但随着智慧校园阶段应用需求多、关注点变化快、建设周期短等建设模式的转变，传统架构已越来越力不从心，以下是希嘉在走访了众多高校后总结的代表性感受与原因分析：

1、——“数据协调复杂，每次都需要来回折腾”

原因分析：原有的数据共享均在数据库层面用视图完成，属于单点线下的集成模式，对于新建系统或应用来说，原本的工作无法复用。举个例子，即使10个系统/应用需要同样的数据，也要重复做10个推送的接口。并且涉及到平台厂商、信息中心、系统/应用厂商多方间的协调，沟通成本过高，给各方都带来了不好的感受。

2、——“厂商响应速度太慢，自己做又摸不清数据”

原因分析：由于各厂商在项目交付时没能够将所有的知识成果进行转移，导致各学校无法具有充分的主动权，对平台厂商过度依赖，响应效率完全取决于厂商的重视程度。同时在原有的架构中完全使用数据库视图的方式进行数据的共享也导致了可维护性差、难以继承、含义不明等痛点。

3、——“运维和管控困难”

原因分析：随着学校信息化建设的不断深入，信息中心维护的中心库数量由几个逐渐增加到几十个，给日常的运维工作带来了极大的负担。同时由于数据的共享完全在数据库底层进行运转，很难去对其运行的过程进行监控和管理，例如无法得知每类数据的调用情况、成功/出错情况等。对于管理人员的日常管理工作带来了“不可见”的困扰。

4、——“数据的实时性难以保证”

原因分析：随着高校应用场景的深入，对于数据实时性的需求较多。但在传统的单点集成架构中，数据的上行抽取、下行分发、使用订阅都需要划出时间段，一般间隔为数个小时，且为了减轻负担，普遍每天定期执行一次。这也造成了数据的实时性难以得到保障。

5、——“……”

正是由于传统数据平台在架构上的落后，部分高校也开始探寻更为高效的数据共享方式，例如企业服务总线ESB在高校行业的落地历程。

企业服务总线（ESB）在高校的落地历程

实际上ESB并不是新型的技术或产品，在96年Gartner最早提出SOA架构（面向服务的架构），随之一段时间内企业信息化行业曾一度掀起了SOA化转型的浪潮。作为SOA架构中最主流的的核心集成层中间件和实现方式，ESB曾被寄予厚望，像一根“聪明”的管道，用来连接各个“愚笨”的节点。为了集成不同系统，不同协议的服务，ESB做了消息的转换解释与路由等工作，让不同的服务可以互联互通。

图：ESB架构图

如上图所示，ESB在架构上主要分为服务提供方和服务消费方，通过在ESB上设计一套标准的数据接口（通用的XML格式），规定采用统一的协议（例如Web Service/HTTP），希望各系统能够标准化的实现服务的注册和服务的调用，从而达到系统间无缝、灵活对接的目的。新建的服务消费者应用系统不需要关心服务的提供者在哪里，使用何种通讯协议，与其交互的数据源头是怎样的……，它只需向ESB发出请求，使用开放的、标准的通讯协议进行数据/服务的便捷和实时调用。最终提升整个信息化架构的敏捷性和灵活性。但以实际落地的效果来看，在高校领域这是一个很浪漫很理想但不可能完全实现的目标。原因如下：

1、服务的定义由谁去完成？

ESB仅是一个技术中间件，其中不包含任何业务逻辑和含义，对应而言ESB方案提供商无法深入到高校的所有业务进行探索和总结，并提炼出一套可实行、权威的数据服务标准和服务颗粒度定义，而高校信息中心也没有精力和驱动力去成为校内所有部门的业务专家，因为服务定义的缺失是ESB在高校落地效果不佳的首要因素。

2、服务的注册由谁去配合？

服务的提供由对应管理信息系统的厂商配合最为合适，但由于高校实际上各部门间的壁垒、厂商间的竞争特性事实存在，在高校仅做数据对接还需要付“接口费”的情况下，协调原厂商做更为复杂的服务梳理和注册工作注定了ESB无法在高校顺利落地。

3、大批量数据的传输如何实现？

在大数据时代，海量数据的可靠传输也成为了核心需求之一，作为服务集成的中间件，使用者往往会过分放大了ESB对数据的传输能力，如果在ESB传输巨大的数据体量，会导致ESB整体性能的下降，损害其他重要服务的质量。

除上述主要原因以外，定制困难、使用复杂、无高校业务特性的设计也导致了ESB在高校行业的落地效果远远低于人们对它的期望。在当前的智慧校园阶段，各大高校也在积极探寻更为实用和先进的数据开放模式。

基于互联网模式的数据开放实践

互联网行业集中了最为顶尖的软件技术和思想，其发展方向对于高校信息化行业具有深刻的影响。“赋能”这个词汇正在被互联网巨头们高频度提起。本质上是希望通过开放自身积累的海量用户数据资源，为第三方应用开发商提供低门槛、便捷和高可用的数据能力服务，从而不断完善自身的应用生态。例如阿里支付宝能力开放平台、腾讯微信开放平台、百度地图开放平台等生态圈：

如上图所示，互联网厂商通过构建能力开放平台和API数据调用体系，很好的解决了如何将自身积累的丰富数据能力有效的面向第三方应用和服务提供商开放的难题。并达成了应用生态繁荣和增强用户粘性的效果，对于支付宝本身、第三方厂商、用户形成了“多方共赢”的局面。这与高校智慧校园建设阶段如何充分利用数据资产，以更好的满足不断增长的信息化服务需求的背景高度类似。

希嘉数据中台体系在数据开放层面上充分借鉴了互联网的成功经验，并结合高校的业务特性，提供足够开放、便捷、高性能的数据服务，以在南京理工大学、西安电子科技大学、南京工业大学、温州大学、长沙民政职业技术学院、宁波卫生职业技术学院等高校的成功落地经验为例，希嘉总结了在智慧校园应用生态构建的目标下，数据开放API体系在产品功能上应该具备的能力如下：

1、能够继承数据集成/治理成果，“一次治理，多次复用“

通过对于各类数据源类型、各个厂商的平台建设成果兼容，希嘉数据中台具备“只要能够获取到数据表/视图的权限，便支持封装为API接口发布”的能力。而标准的API接口能够充分实现各厂商按需申请使用，现有成果的可复用性大大减少了重复建设的成本，也极大降低了信息中心的工作压力。

2、低门槛的使用体验，让学校实现数据共享的自主权

无需编写复杂的数据库视图或配置代码，完全可视化的API发布功能，实现“1分钟1个API”的使用体验，给予高校充分的自主权，去除厂商响应效率问题给信息化建设带来的隐性风险。

3、统一的在线开发者入口，降低数据调用门槛，提升应用上线效率

数据中台能够将高校现有的数据封装为标准化的API集，并具有统一的开发者中心提供多个厂商在线查看数据结构说明、开发文档、调用示例和API数据申请等服务。标准化的API接口统一以JSON的数据格式提供，屏蔽了源头复杂异构的数据类型，将数据调用的门槛降至最低。同时整体完全在线的申请、审核体系也避免了数据消费方陷入冗长的协调中。以南京工业大学科探流程服务的建设为例，数据调用的周期由原本的两周时间缩短到了分钟级。

4、全流程数据开放管控体系，“便捷”与“安全”同时兼顾

希嘉数据中台提供了完整的管控体系，实现了数据的发布、申请、审核、调用全流程可控与数据安全保障。同时基于API体系进行的数据开放业务能够充分实现可留存、可追溯，并能够清晰直观地展现数据服务的支撑状况，方便对于数据的运维和管理。

图：数据中台全流程数据开放管控体系

图：数据服务可视化大屏

数据的第一次生命起源于在系统中的录入和维护，而数据良好的开放和利用是赋予和挖掘数据更多价值的核心手段。在智慧校园建设阶段，高校信息化生态圈不再是原有封闭的局面，面对校内爆发式的信息化服务需求和数据共享需求，高校应着力构建开放的智慧校园生态，引入更多开发资源，集众智共建可持续、可快速迭代的服务应用。而只有重视数据的支撑性作用，并建立起符合当前和未来需要的数据开放共享体系，才能为智慧校园的建设提供强劲的驱动力。