數據中臺相對于數據倉庫，最大的特征就是業務化，但業務化非常抽象，那么如何衡量數據中臺的業務化水平呢？如何比較兩個公司的數據中臺水平高低呢？

我有一個簡單直接的方法，就是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的形式對外開放數據，把數據處理和建模的復雜性留給自己，把加工完的簡單的、高價值的數據輕量化的供給業務。現在云原生、微服務領域都在提聲明式調用，擯棄命令式調用，目的就是為了交付簡單，這也是一種技術架構發展的一種趨勢吧，數據中臺對外提供服務如果總是鐵板一塊，那的確不合時宜。

孔子說得好啊，“己所不欲，勿施于人”，塔勒布在《非對稱風險》中也提到了，"skin in the game"，我的團隊正在踐行這個API理念，因此也同樣推薦給你，下面給一張截圖，證明我是來真的，希望大家的數據中臺，都能再進化一次。