近年來(lái)，“數(shù)據(jù)治理”已成為企業(yè)數(shù)字化轉(zhuǎn)型的核心議題。企業(yè)投入重金構(gòu)建數(shù)據(jù)平臺(tái)、梳理元數(shù)據(jù)、建立數(shù)據(jù)目錄，成功地使數(shù)據(jù)資產(chǎn)在一定程度上“可見(jiàn)”了。
業(yè)務(wù)部門(mén)至少“看”到了企業(yè)有什么數(shù)據(jù)。
然而，一個(gè)普遍的悖論擺在眼前：盡管數(shù)據(jù)“可見(jiàn)”，但業(yè)務(wù)方獲取和使用數(shù)據(jù)的流程依然“堵塞”。數(shù)據(jù)治理的“最后一公里”，即從“數(shù)據(jù)資產(chǎn)”到“數(shù)據(jù)消費(fèi)”的鏈路，為何如此難以打通？
1. 數(shù)據(jù)治理的“上半場(chǎng)”：從“不可見(jiàn)”到“可見(jiàn)”
在探討“最后一公里”之前，我們必須肯定數(shù)據(jù)治理“上半場(chǎng)”的成果。過(guò)去十年，企業(yè)主要解決了數(shù)據(jù)“存”和“看”的問(wèn)題：
“存”的問(wèn)題：通過(guò)數(shù)據(jù)倉(cāng)庫(kù)、數(shù)據(jù)湖等技術(shù)，企業(yè)將分散在各個(gè)業(yè)務(wù)系統(tǒng)（ERP, CRM, SCM...）中的數(shù)據(jù)孤島進(jìn)行了匯集和標(biāo)準(zhǔn)化存儲(chǔ)。
“看”的問(wèn)題：通過(guò)數(shù)據(jù)目錄、元數(shù)據(jù)管理、數(shù)據(jù)血緣等工具，企業(yè)對(duì)匯集的數(shù)據(jù)進(jìn)行了梳理。DBA、數(shù)據(jù)架構(gòu)師和部分業(yè)務(wù)分析師，至少可以通過(guò)數(shù)據(jù)地圖（Data Catalog）查到“客戶主數(shù)據(jù)表在哪里”、“訂單額這個(gè)指標(biāo)是怎么來(lái)的”。
至此，數(shù)據(jù)在技術(shù)和管理層面上實(shí)現(xiàn)了“可見(jiàn)”。然而，治理的最終目的不是為了“看”，而是為了“用”?！翱梢?jiàn)”只是起點(diǎn)，而“安全、便捷地使用”才是終點(diǎn)。
問(wèn)題恰恰出在從“可見(jiàn)”到“使用”的這個(gè)跳躍上。
2. 核心矛盾：IT的“安全風(fēng)控” vs 業(yè)務(wù)的“敏捷用數(shù)”
“最后一公里”的堵塞，本質(zhì)上源于一個(gè)不可調(diào)和的結(jié)構(gòu)性矛盾：IT和數(shù)據(jù)安全部門(mén)的核心職責(zé)是“風(fēng)控、保穩(wěn)定”，而業(yè)務(wù)部門(mén)的核心訴求是“敏捷、要效率”。
IT的視角（風(fēng)控）：“我放開(kāi)一個(gè)原始表的權(quán)限，誰(shuí)知道你會(huì)寫(xiě)什么SQL？會(huì)不會(huì)SELECT *拖垮生產(chǎn)庫(kù)？會(huì)不會(huì)JOIN錯(cuò)表導(dǎo)致性能雪崩？萬(wàn)一你把敏感數(shù)據(jù)（如手機(jī)號(hào)）導(dǎo)出到本地Excel，泄露了誰(shuí)負(fù)責(zé)？” ——因此，IT的默認(rèn)策略是“不開(kāi)放”。
業(yè)務(wù)的視角（敏捷）：“我只是想看一下本季度TOP10客戶的復(fù)購(gòu)率，為什么提個(gè)工單要等三天？為什么IT給我的數(shù)據(jù)還是錯(cuò)的？我急著要數(shù)據(jù)做決策，等不了！” ——因此，業(yè)務(wù)的默認(rèn)策略是“催促”與“繞過(guò)”。
這種矛盾導(dǎo)致數(shù)據(jù)消費(fèi)鏈路被割裂，形成了橫亙?cè)凇皵?shù)據(jù)”與“用戶”之間的四大屏障。
3. 屏障一：權(quán)限的“審批黑盒”
當(dāng)業(yè)務(wù)分析師（用戶）在數(shù)據(jù)目錄中“看”到一張表（例如dws_customer_order_detail）并嘗試訪問(wèn)時(shí)，他面對(duì)的第一道墻，就是權(quán)限。
在傳統(tǒng)治理模式下，獲取權(quán)限是一個(gè)漫長(zhǎng)、不透明的流程：
提工單：用戶提交一個(gè)OA或ITSM工單，描述“我想要某某表的讀權(quán)限，用于某某分析”。
漫長(zhǎng)審批：工單流經(jīng)業(yè)務(wù)主管（確認(rèn)需求）、數(shù)據(jù)Owner（確認(rèn)數(shù)據(jù)歸屬）、DBA（確認(rèn)安全風(fēng)險(xiǎn)）、安全合規(guī)部門(mén)（確認(rèn)合規(guī)性）。
粗粒度授權(quán)：DBA為了省事，要么直接拒絕，要么就直接授予該用戶一個(gè)數(shù)據(jù)庫(kù)賬戶，允許其通過(guò)客戶端工具進(jìn)行SELECT。
這個(gè)過(guò)程動(dòng)輒數(shù)天，且結(jié)果往往是“一刀切”的。業(yè)務(wù)人員要么拿不到權(quán)限，要么拿到了一個(gè)“風(fēng)險(xiǎn)極大”的原始表權(quán)限。IT部門(mén)不得不在“噎死業(yè)務(wù)”和“撐死業(yè)務(wù)”之間做選擇。
4. 屏障二：技術(shù)的“能力鴻溝”
假設(shè)業(yè)務(wù)分析師歷經(jīng)千辛萬(wàn)苦，終于拿到了表的SELECT權(quán)限。他馬上會(huì)遇到第二道墻：技術(shù)鴻溝。
SQL門(mén)檻：業(yè)務(wù)人員懂“業(yè)務(wù)指標(biāo)”，但未必懂“SQL”。他們很難將“本季度復(fù)購(gòu)率”翻譯成一個(gè)涉及多表JOIN、GROUP BY、CASE WHEN和窗口函數(shù)的復(fù)雜查詢。
“表”不等于“指標(biāo)”：IT治理的數(shù)據(jù)是“表”，而業(yè)務(wù)需要的是“指標(biāo)”或“服務(wù)”。dws_customer_order_detail這張表可能有200個(gè)字段，業(yè)務(wù)人員如何知道該用哪個(gè)字段？
工具缺失：業(yè)務(wù)人員的電腦上通常只有Excel和BI工具，他們?nèi)狈ο馜BA那樣的專業(yè)SQL客戶端。
結(jié)果是，即使權(quán)限開(kāi)放了，業(yè)務(wù)人員依然“用不起來(lái)”。他們只能再次回頭找IT的數(shù)據(jù)開(kāi)發(fā)團(tuán)隊(duì)：“能幫我跑個(gè)數(shù)嗎？”—— 最終又回到了“提需求、排期、T+1交付”的瀑布流模式。
5. 屏障三：安全的“合規(guī)枷鎖”
IT部門(mén)之所以設(shè)置重重關(guān)卡，核心擔(dān)憂在于“安全”與“合規(guī)”。這構(gòu)成了第三道，也是最堅(jiān)固的一道墻。
數(shù)據(jù)泄露風(fēng)險(xiǎn)：傳統(tǒng)授權(quán)（如給一個(gè)數(shù)據(jù)庫(kù)賬戶）是高風(fēng)險(xiǎn)的。員工可以通過(guò)客戶端工具輕易地SELECT * FROM sensitive_table LIMIT 10000，將海量敏感數(shù)據(jù)（如身份證、手機(jī)號(hào)、家庭住址）導(dǎo)出到本地，形成“數(shù)據(jù)泄露”。
合規(guī)性挑戰(zhàn)：《數(shù)據(jù)安全法》、《個(gè)人信息保護(hù)法》等法規(guī)要求數(shù)據(jù)的使用必須遵循“最小化原則”和“可追溯原則”。
最小化原則：業(yè)務(wù)人員只想看“復(fù)購(gòu)率”這個(gè)聚合后的統(tǒng)計(jì)值，但I(xiàn)T卻給了他“所有訂單明細(xì)”的原始權(quán)限，這嚴(yán)重違反了最小化原則。
可追溯原則：IT只知道user_bi這個(gè)公共賬戶執(zhí)行了查詢，但無(wú)法追溯到是哪一個(gè)業(yè)務(wù)人員、在什么時(shí)間、為了什么目的查詢了數(shù)據(jù)。
在合規(guī)高壓下，IT部門(mén)寧可“不作為”（不給權(quán)限），也不敢“亂作為”（給錯(cuò)權(quán)限）。
6. 屏障四：“影子IT”與“數(shù)據(jù)孤島2.0”
當(dāng)正式的數(shù)據(jù)使用鏈路被前三道屏障堵死時(shí)，業(yè)務(wù)的敏捷需求并不會(huì)消失。它只會(huì)轉(zhuǎn)向“地下”，催生出“影子IT”。
這是“最后一公里”堵塞后最諷刺的惡果：
業(yè)務(wù)部門(mén)實(shí)在等不及，要求IT數(shù)據(jù)團(tuán)隊(duì)“你把數(shù)據(jù)導(dǎo)成Excel發(fā)我吧”。
IT團(tuán)隊(duì)為了應(yīng)付業(yè)務(wù)，執(zhí)行了一次SQL查詢，將結(jié)果（可能包含敏感數(shù)據(jù)）導(dǎo)出為CSV或Excel，通過(guò)郵件或共享網(wǎng)盤(pán)發(fā)給業(yè)務(wù)方。
業(yè)務(wù)方拿到這個(gè)Excel，如獲至寶。他們?cè)诖嘶A(chǔ)上進(jìn)行二次加工、VLookup、制作PPT。
這份“離線、脫敏失效、版本未知、血緣中斷”的Excel，開(kāi)始在部門(mén)內(nèi)部流傳，成為新的“數(shù)據(jù)源”。
企業(yè)投入巨資治理數(shù)據(jù)湖，結(jié)果業(yè)務(wù)的核心決策卻依賴于一份無(wú)人管理的、存在于個(gè)人電腦上的Excel。這形成了“數(shù)據(jù)孤島2.0”，使得數(shù)據(jù)治理的“上半場(chǎng)”成果付諸東流。
7. 結(jié)論：
數(shù)據(jù)治理的“最后一公里”堵塞，核心在于我們混淆了“治理數(shù)據(jù)”和“治理數(shù)據(jù)的使用”。
我們成功地治理了“靜止”在數(shù)據(jù)湖/倉(cāng)中的數(shù)據(jù)（數(shù)據(jù)資產(chǎn)），卻未能有效治理“流動(dòng)”向用戶的數(shù)據(jù)（數(shù)據(jù)服務(wù)）。我們用管理“金庫(kù)”（數(shù)據(jù)倉(cāng)庫(kù)）的思路，去管理“自來(lái)水管”（數(shù)據(jù)消費(fèi)），導(dǎo)致業(yè)務(wù)方“臨渴掘井”。
從“看”到“用”，缺少的不是更嚴(yán)的審批，也不是更松的權(quán)限，而是一個(gè)全新的“數(shù)據(jù)服務(wù)層”。這個(gè)中間層必須能夠?qū)ⅰ霸?、高風(fēng)險(xiǎn)的表權(quán)限”轉(zhuǎn)換為“安全、低門(mén)檻的API服務(wù)或指標(biāo)”。
