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

我有一個簡單直接的方法，就是A和B公司列出對外開放的API的數(shù)量、占比、調(diào)用量和收入，誰多就牛逼一點，不用提采用了什么樣的先進(jìn)理論和方法，比如OneData，OneService啥的。

有人可能就會質(zhì)疑，雖然我的數(shù)據(jù)中臺對外開放的API不多，但卻開放了大量文件（表也算是一種），難道就不算賦能業(yè)務(wù)？API這種開放形式對于數(shù)據(jù)中臺就這么重要？

業(yè)務(wù)化是數(shù)據(jù)中臺的一個核心特征，這個大家應(yīng)有共識，但數(shù)據(jù)中臺如何業(yè)務(wù)化卻缺乏指導(dǎo)，大多企業(yè)的數(shù)據(jù)中臺仍在用傳統(tǒng)的數(shù)據(jù)倉庫數(shù)據(jù)開放模式去服務(wù)業(yè)務(wù)，即大量的文件、表的形式，這可能存在很大問題。

近幾年的實踐告訴我，雖然文件也是數(shù)據(jù)開放的形式，但相較于API的開放形式，其對于數(shù)據(jù)中臺的價值和意義就差遠(yuǎn)了。

1、文件的開放，讓數(shù)據(jù)中臺失去了對業(yè)務(wù)場景的理解

數(shù)據(jù)中臺高效運營的前提，是對于業(yè)務(wù)場景的理解，只有理解了業(yè)務(wù)才能沉淀出公共的數(shù)據(jù)服務(wù)，而要達(dá)到這個目的，數(shù)據(jù)團隊就要在每一次的業(yè)務(wù)需求對接中去充分理解業(yè)務(wù)，不僅要知道做什么，更要知道為什么這么做，能夠舉一反三。但如果采取簡單的開放表的形式去滿足業(yè)務(wù)需求，就失去了充分理解業(yè)務(wù)的機會，比如業(yè)務(wù)流程。

你如果開放過表，一定會有切身的體會，業(yè)務(wù)人員一般只會告訴你要哪張表，表要有哪些字段，甚至直接跟你說那張表同步過來就是了，因為已經(jīng)跟源端溝通過了，至于業(yè)務(wù)要怎么用，就不用管了，業(yè)務(wù)認(rèn)為數(shù)據(jù)中臺開放表給予了業(yè)務(wù)最大的自由。

這個時候，我們所謂的數(shù)據(jù)中臺，實際上就成了數(shù)據(jù)管道，別人飛過，不留下一絲云彩，更不可能沉淀出什么像樣的數(shù)據(jù)服務(wù)。

API對于業(yè)務(wù)的要求則是完全不一樣的，因為API往往是要嵌入到業(yè)務(wù)系統(tǒng)的流程中去的，你需要業(yè)務(wù)方提供輸入和輸出，需要對方提供各種API調(diào)用時的場景信息，在這個充分的互動中，我們對于業(yè)務(wù)場景的理解會更深入。

數(shù)據(jù)團隊由于缺乏業(yè)務(wù)意識，導(dǎo)致大量的可以用API實現(xiàn)的數(shù)據(jù)開放場景，大都用文件替代了。雖然數(shù)據(jù)中臺一直在強調(diào)以服務(wù)（DaaS API）的形式開放數(shù)據(jù)，但在現(xiàn)實中，大家都習(xí)慣挑最簡單的一種形式去開放，即文件，這是數(shù)據(jù)倉庫時代的遺毒，諸不知這也埋下了不懂業(yè)務(wù)的禍根，雖然API開發(fā)、上線和開放遠(yuǎn)比開放表要麻煩，但這對于數(shù)據(jù)中臺來講是必須付出的代價。

數(shù)據(jù)團隊其實也沒有更多的機會去真正理解業(yè)務(wù)，必須是在業(yè)務(wù)人員提交需求的那個時刻去學(xué)習(xí)、理解和消化，那種靠項目驅(qū)動的API服務(wù)的打造，也是無法持續(xù)的。

2、文件的開放，讓數(shù)據(jù)中臺失去了數(shù)據(jù)即席評估的能力

數(shù)據(jù)中臺必需知道開放的數(shù)據(jù)產(chǎn)生了什么價值才能迭代優(yōu)化，但文件開放的形式讓評估變得異常困難。

如果你以文件形式開放數(shù)據(jù)給業(yè)務(wù)，大多數(shù)情況下，這些數(shù)據(jù)在業(yè)務(wù)端產(chǎn)生了什么樣的價值，基本就無從知曉了，主要分為三種情況：

第一，業(yè)務(wù)端雖然能統(tǒng)計到這些開放數(shù)據(jù)的業(yè)務(wù)效果，但數(shù)據(jù)團隊一般沒這個意識主動提，這個問題是非常普遍的。

第二，業(yè)務(wù)端需要改造才能統(tǒng)計這些數(shù)據(jù)的業(yè)務(wù)效果，這個時候即使數(shù)據(jù)團隊主動提了，它也很難或不愿意配合。

第三，業(yè)務(wù)端的確無法統(tǒng)計這些數(shù)據(jù)的業(yè)務(wù)效果，因為這些數(shù)據(jù)也只是它的中間數(shù)據(jù)。

即使做到了第一，第二點，數(shù)據(jù)團隊還要結(jié)合各種業(yè)務(wù)場景制定各種數(shù)據(jù)評估接口標(biāo)準(zhǔn)，這對于數(shù)據(jù)團隊就是個挑戰(zhàn)，業(yè)務(wù)方是生產(chǎn)系統(tǒng)，一般比較強勢，他們愿不愿意接受這種規(guī)范，也是一種挑戰(zhàn)，即使最后說服了業(yè)務(wù)方落地了這種規(guī)范，文件形式的批量評估方式在時效性，準(zhǔn)確性等各個方面都存在大量問題。

API則完全不一樣，因為API是嵌入到業(yè)務(wù)場景中的，業(yè)務(wù)場景的各種上下文數(shù)據(jù)，即哪個業(yè)務(wù)場景哪個業(yè)務(wù)在什么時間產(chǎn)生了什么樣的行動，都可以通過API的形式予以實時記錄，這種實時的反饋數(shù)據(jù)形成了數(shù)據(jù)評估的基礎(chǔ)。

數(shù)據(jù)團隊要珍惜開放的每個數(shù)據(jù)，“無評估不開放”是需要堅持的原則，否則數(shù)據(jù)中臺的運營無從談起，那種靠線下調(diào)研的方式來推進(jìn)數(shù)據(jù)中臺進(jìn)化的，顯然是太慢太低效了。

3、文件的開放，讓數(shù)據(jù)中臺失去了統(tǒng)一運營數(shù)據(jù)的可能

業(yè)務(wù)端對于自己建個性化數(shù)據(jù)集市有天然的沖動，因為誰都討厭對外溝通求人，為了獲得靈活性，業(yè)務(wù)必須千方百計將所有需要的資源，比如數(shù)據(jù)抓在自己手里，想怎么用就怎么用，因此，業(yè)務(wù)方會不停的向數(shù)據(jù)中臺索要各種明細(xì)數(shù)據(jù)，如果有可能的話，最好在自己那里備份一份，當(dāng)然由于計算和存儲限制，這種愿望很難實現(xiàn)。

因此，業(yè)務(wù)會對數(shù)據(jù)中臺提大量的批量數(shù)據(jù)接口需求，即使它的業(yè)務(wù)場景可以用API來支持，業(yè)務(wù)也希望這個API是基于自己的平臺數(shù)據(jù)生成的，畢竟OLTP生產(chǎn)系統(tǒng)相對于一般的OLAP系統(tǒng)，具有高可用的優(yōu)勢，生產(chǎn)保障級別也非OLAP所能比擬。

這種開放形式的確給業(yè)務(wù)帶來了靈活性，但站在企業(yè)的角度，從長遠(yuǎn)的角度看，數(shù)據(jù)的集約化使用就不太可能了，數(shù)據(jù)中臺更失去了意義。隨著業(yè)務(wù)的需求越來越多，業(yè)務(wù)端的數(shù)據(jù)越積越多，各種數(shù)據(jù)豎井重新立起，數(shù)據(jù)中臺就這樣被業(yè)務(wù)過頂傳球了，數(shù)據(jù)中臺褪去了業(yè)務(wù)屬性，淪為了供數(shù)平臺，要對數(shù)據(jù)做統(tǒng)一運營，基本也就不可能了。

雖然我們希望數(shù)據(jù)中臺能做好數(shù)據(jù)能力的復(fù)用和共享，但在每一次文件的開放過程中，我們實際失去了數(shù)據(jù)中臺這個初心，雖然API也許能改變這種狀態(tài)，但提供生產(chǎn)API對于數(shù)據(jù)中臺的挑戰(zhàn)也是前所未有，因為以往OLAP的運維保障能力相對OLTP實在是太低了。

不管如何，數(shù)據(jù)中臺只有提供更多的API才能推進(jìn)數(shù)據(jù)的統(tǒng)一運營，同時，它必須確保對外提供的API具備連續(xù)性，這才能夠讓業(yè)務(wù)放心。

4、文件的開放，讓數(shù)據(jù)中臺越來越保守去對外開放數(shù)據(jù)

隨著企業(yè)數(shù)據(jù)安全意識的崛起，現(xiàn)在所有的數(shù)據(jù)開放都變得謹(jǐn)慎，不僅僅是對外數(shù)據(jù)開放，也包括對內(nèi)數(shù)據(jù)開放，即使你的數(shù)據(jù)對業(yè)務(wù)價值巨大，但只要有踩紅線的可能，就會接受一道又一道的安全審計，一個又一個的流程控制。

數(shù)據(jù)中臺希望自己的數(shù)據(jù)被業(yè)務(wù)更多的使用，這樣自己做的工作才更有價值，但數(shù)據(jù)安全又要求它盡量減少數(shù)據(jù)開放的范圍，在這種背景下，很多數(shù)據(jù)中臺團隊采取了保守策略，既然安全這么要求，那就少開放或不開放唄，但假如企業(yè)的數(shù)據(jù)中臺團隊都是這個保守思想，那數(shù)據(jù)創(chuàng)新就只能呵呵了，更別提什么大數(shù)據(jù)價值變現(xiàn)了。

這讓我想起開發(fā)和運維一直存在的矛盾，前者想著價值，后者想著穩(wěn)定，然后出了個DevOps，很好的去解決這個問題，數(shù)據(jù)中臺團隊也在面臨著類似的挑戰(zhàn)，是否也需要一種積極解決問題的態(tài)度？

文件開放這種形式，相對于API，安全程度肯定是低的，因為一旦開放了，就實際失去了對數(shù)據(jù)的實際控制，基本上也不可能進(jìn)行跟蹤，然后這些脫韁的數(shù)據(jù)經(jīng)過改頭換面出現(xiàn)在其他的地方，這的確造成了安全的隱患。安全部門往往由于這些原因，對文件形式的開放管控是非常嚴(yán)的，比如所有的數(shù)據(jù)都需要脫敏，而脫敏后的很多數(shù)據(jù)就失去了價值。

API的安全程度顯然要高很多，因為首先它是圍繞特定業(yè)務(wù)開展的，因此使用的范圍是受限的，你可以通過各種技術(shù)手段去限制訪問者；其次，API是可以進(jìn)行實時調(diào)用跟蹤的，基于使用的評估可以判斷安全風(fēng)險，最后，它是可以進(jìn)行實時攔截的，只要發(fā)現(xiàn)異常，數(shù)據(jù)提供方可以及時關(guān)停API。

API實際為數(shù)據(jù)中臺方提供了一種更加安全的數(shù)據(jù)開放手段，很多通過文件形式不能開放的數(shù)據(jù)，通過API卻是可以開放的。數(shù)據(jù)中臺方應(yīng)該站在業(yè)務(wù)的角度，主動給出可控的數(shù)據(jù)開放的手段，至少API是一種解決方式。

5、文件的開放，讓數(shù)據(jù)中臺的開放變得冗余且效率低下

文件的開放意味著需要將全部的數(shù)據(jù)從一個地方搬遷到另一個地方，相對于API，其效率的確是比較低的：

首先，數(shù)據(jù)開放的時間成本較高，源端抽取數(shù)據(jù)需要時間，源端交換到目的端需要時間，目的端ETL數(shù)據(jù)更需要時間，數(shù)據(jù)中臺的運維中，數(shù)據(jù)交換的及時性保障是最大的問題之一。

再次，數(shù)據(jù)開放的資源消耗較大，只要文件大了，就會消耗大量的計算、I/O或是內(nèi)存資源。

再次，業(yè)務(wù)方拿到數(shù)據(jù)后，還需要進(jìn)行數(shù)據(jù)的二次加工，讓OLTP系統(tǒng)干OLAP系統(tǒng)的事情，效率也是很低的，比如我們以前曾把一張超級大表同步給業(yè)務(wù)方，業(yè)務(wù)方的ORACLE在有限的時間窗口根本入庫不了。

最后，數(shù)據(jù)的一致性會受到挑戰(zhàn)，因為如果多個業(yè)務(wù)方加工同一份數(shù)據(jù)，往往會導(dǎo)致不同的結(jié)果，最后背鍋的可能就是數(shù)據(jù)提供方，如果業(yè)務(wù)方再把這個文件又做了二次開放，那就更糟了。

數(shù)據(jù)中臺應(yīng)該盡量以API的形式對外開放數(shù)據(jù)，把數(shù)據(jù)處理和建模的復(fù)雜性留給自己，把加工完的簡單的、高價值的數(shù)據(jù)輕量化的供給業(yè)務(wù)。現(xiàn)在云原生、微服務(wù)領(lǐng)域都在提聲明式調(diào)用，擯棄命令式調(diào)用，目的就是為了交付簡單，這也是一種技術(shù)架構(gòu)發(fā)展的一種趨勢吧，數(shù)據(jù)中臺對外提供服務(wù)如果總是鐵板一塊，那的確不合時宜。

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