为什么是API而不是文件，对于数据中台的开放如此重要？

数据中台相对于数据仓库，最大的特征就是业务化，但业务化非常抽象，那么如何衡量数据中台的业务化水平呢？如何比较两个公司的数据中台水平高低呢？

有一个简单直接的方法，就是A和B公司列出对外开放的API的数量、占比、调用量和收入，谁多就水平高一点，不用提采用了什么样的先进理论和方法，比如OneData，OneService等等。

有人可能就会质疑，虽然我的数据中台对外开放的API不多，但却开放了大量文件（表也算是一种），难道就不算赋能业务？API这种开放形式对于数据中台就这么重要？

业务化是数据中台的一个核心特征，这个大家应有共识，但数据中台如何业务化却缺乏指导，大多企业的数据中台仍在用传统的数据仓库数据开放模式去服务业务，即大量的文件、表的形式，这可能存在很大问题。

近几年的实践告诉我，虽然文件也是数据开放的形式，但相较于API的开放形式，其对于数据中台的价值和意义就差远了。

1、文件的开放，让数据中台失去了对业务场景的理解

数据中台高效运营的前提，是对于业务场景的理解，只有理解了业务才能沉淀出公共的数据服务，而要达到这个目的，数据团队就要在每一次的业务需求对接中去充分理解业务，不仅要知道做什么，更要知道为什么这么做，能够举一反三。但如果采取简单的开放表的形式去满足业务需求，就失去了充分理解业务的机会，比如业务流程。

如果开放过表，一定会有切身的体会，业务人员一般只会告诉你要哪张表，表要有哪些字段，甚至直接跟你说那张表同步过来就是了，因为已经跟源端沟通过了，至于业务要怎么用，就不用管了，业务认为数据中台开放表给予了业务最大的自由。

这个时候，我们所谓的数据中台，实际上就成了数据管道，别人飞过，不留下一丝云彩，更不可能沉淀出什么像样的数据服务。

API对于业务的要求则是完全不一样的，因为API往往是要嵌入到业务系统的流程中去的，你需要业务方提供输入和输出，需要对方提供各种API调用时的场景信息，在这个充分的互动中，我们对于业务场景的理解会更深入。

数据团队由于缺乏业务意识，导致大量的可以用API实现的数据开放场景，大都用文件替代了。虽然数据中台一直在强调以服务（DaaS API）的形式开放数据，但在现实中，大家都习惯挑最简单的一种形式去开放，即文件，这是数据仓库时代的遗毒，诸不知这也埋下了不懂业务的祸根，虽然API开发、上线和开放远比开放表要麻烦，但这对于数据中台来讲是必须付出的代价。

数据团队其实也没有更多的机会去真正理解业务，必须是在业务人员提交需求的那个时刻去学习、理解和消化，那种靠项目驱动的API服务的打造，也是无法持续的。

2、文件的开放，让数据中台失去了数据即席评估的能力

数据中台必需知道开放的数据产生了什么价值才能迭代优化，但文件开放的形式让评估变得异常困难。

如果你以文件形式开放数据给业务，大多数情况下，这些数据在业务端产生了什么样的价值，基本就无从知晓了，主要分为三种情况：

第一，业务端虽然能统计到这些开放数据的业务效果，但数据团队一般没这个意识主动提，这个问题是非常普遍的。

第二，业务端需要改造才能统计这些数据的业务效果，这个时候即使数据团队主动提了，它也很难或不愿意配合。

第三，业务端的确无法统计这些数据的业务效果，因为这些数据也只是它的中间数据。

即使做到了第一，第二点，数据团队还要结合各种业务场景制定各种数据评估接口标准，这对于数据团队就是个挑战，业务方是生产系统，一般比较强势，他们愿不愿意接受这种规范，也是一种挑战，即使最后说服了业务方落地了这种规范，文件形式的批量评估方式在时效性，准确性等各个方面都存在大量问题。

API则完全不一样，因为API是嵌入到业务场景中的，业务场景的各种上下文数据，即哪个业务场景哪个业务在什么时间产生了什么样的行动，都可以通过API的形式予以实时记录，这种实时的反馈数据形成了数据评估的基础。

数据团队要珍惜开放的每个数据，“无评估不开放”是需要坚持的原则，否则数据中台的运营无从谈起，那种靠线下调研的方式来推进数据中台进化的，显然是太慢太低效了。

3、文件的开放，让数据中台失去了统一运营数据的可能

业务端对于自己建个性化数据集市有天然的冲动，因为谁都讨厌对外沟通求人，为了获得灵活性，业务必须千方百计将所有需要的资源，比如数据抓在自己手里，想怎么用就怎么用，因此，业务方会不停的向数据中台索要各种明细数据，如果有可能的话，最好在自己那里备份一份，当然由于计算和存储限制，这种愿望很难实现。

因此，业务会对数据中台提大量的批量数据接口需求，即使它的业务场景可以用API来支持，业务也希望这个API是基于自己的平台数据生成的，毕竟OLTP生产系统相对于一般的OLAP系统，具有高可用的优势，生产保障级别也非OLAP所能比拟。

这种开放形式的确给业务带来了灵活性，但站在企业的角度，从长远的角度看，数据的集约化使用就不太可能了，数据中台更失去了意义。随着业务的需求越来越多，业务端的数据越积越多，各种数据竖井重新立起，数据中台就这样被业务过顶传球了，数据中台褪去了业务属性，沦为了供数平台，要对数据做统一运营，基本也就不可能了。

虽然我们希望数据中台能做好数据能力的复用和共享，但在每一次文件的开放过程中，我们实际失去了数据中台这个初心，虽然API也许能改变这种状态，但提供生产API对于数据中台的挑战也是前所未有，因为以往OLAP的运维保障能力相对OLTP实在是太低了。

不管如何，数据中台只有提供更多的API才能推进数据的统一运营，同时，它必须确保对外提供的API具备连续性，这才能够让业务放心。

4、文件的开放，让数据中台越来越保守去对外开放数据

随着企业数据安全意识的崛起，现在所有的数据开放都变得谨慎，不仅仅是对外数据开放，也包括对内数据开放，即使你的数据对业务价值巨大，但只要有踩红线的可能，就会接受一道又一道的安全审计，一个又一个的流程控制。

数据中台希望自己的数据被业务更多的使用，这样自己做的工作才更有价值，但数据安全又要求它尽量减少数据开放的范围，在这种背景下，很多数据中台团队采取了保守策略，既然安全这么要求，那就少开放或不开放呗，但假如企业的数据中台团队都是这个保守思想，那数据创新就只能呵呵了，更别提什么大数据价值变现了。

这让我想起开发和运维一直存在的矛盾，前者想着价值，后者想着稳定，然后出了个DevOps，很好的去解决这个问题，数据中台团队也在面临着类似的挑战，是否也需要一种积极解决问题的态度？

文件开放这种形式，相对于API，安全程度肯定是低的，因为一旦开放了，就实际失去了对数据的实际控制，基本上也不可能进行跟踪，然后这些脱缰的数据经过改头换面出现在其他的地方，这的确造成了安全的隐患。安全部门往往由于这些原因，对文件形式的开放管控是非常严的，比如所有的数据都需要脱敏，而脱敏后的很多数据就失去了价值。

API的安全程度显然要高很多，因为首先它是围绕特定业务开展的，因此使用的范围是受限的，你可以通过各种技术手段去限制访问者；其次，API是可以进行实时调用跟踪的，基于使用的评估可以判断安全风险，最后，它是可以进行实时拦截的，只要发现异常，数据提供方可以及时关停API。

API实际为数据中台方提供了一种更加安全的数据开放手段，很多通过文件形式不能开放的数据，通过API却是可以开放的。数据中台方应该站在业务的角度，主动给出可控的数据开放的手段，至少API是一种解决方式。

5、文件的开放，让数据中台的开放变得冗余且效率低下

文件的开放意味着需要将全部的数据从一个地方搬迁到另一个地方，相对于API，其效率的确是比较低的：

首先，数据开放的时间成本较高，源端抽取数据需要时间，源端交换到目的端需要时间，目的端ETL数据更需要时间，数据中台的运维中，数据交换的及时性保障是最大的问题之一。

再次，数据开放的资源消耗较大，只要文件大了，就会消耗大量的计算、I/O或是内存资源。

再次，业务方拿到数据后，还需要进行数据的二次加工，让OLTP系统干OLAP系统的事情，效率也是很低的，比如我们以前曾把一张超级大表同步给业务方，业务方的ORACLE在有限的时间窗口根本入库不了。

最后，数据的一致性会受到挑战，因为如果多个业务方加工同一份数据，往往会导致不同的结果，最后背锅的可能就是数据提供方，如果业务方再把这个文件又做了二次开放，那就更糟了。

数据中台应该尽量以API的形式对外开放数据，把数据处理和建模的复杂性留给自己，把加工完的简单的、高价值的数据轻量化的供给业务。现在云原生、微服务领域都在提声明式调用，摈弃命令式调用，目的就是为了交付简单，这也是一种技术架构发展的一种趋势吧，数据中台对外提供服务如果总是铁板一块，那的确不合时宜。

中翰软件：专注数据治理17年（http://www.jobhand.cn）

免责声明：本网站所发布的文章为本网站原创，或者是在网络搜索到的优秀文章进行的编辑整理，文章版权归原作者所有，仅供读者朋友们学习、参考。对于分享的非原创文章，有些因为无法找到真正来源，如果标错来源或者对于文章中所使用的图片、连接等所包含但不限于软件、资料等，如有侵权，请直接致电联系，说明具体的文章，后台会尽快删除。给您带来的不便，深表歉意。