本文根據(jù)神策數(shù)據(jù)聯(lián)合創(chuàng)始人 & CTO 曹犟發(fā)表的《數(shù)據(jù)治理中的一些挑戰(zhàn)與應(yīng)用》主題演講整理而成。

本文將為你重點介紹：

• 數(shù)據(jù)治理的概念與重要性
• 數(shù)據(jù)治理面臨的挑戰(zhàn)
• 數(shù)據(jù)治理與組織架構(gòu)
• 數(shù)據(jù)治理中的應(yīng)對

許多大數(shù)據(jù)公司在過去一段時間都得到了較好的發(fā)展，究其原因是因為恰逢專注于業(yè)務(wù)流的信息化建設(shè)正在向數(shù)據(jù)化轉(zhuǎn)型。

但在很多時候，數(shù)據(jù)其實還只是 IT 化的“副產(chǎn)品”，早期的工作思路仍然圍繞如何將業(yè)務(wù) IT 化，而數(shù)據(jù)只是這個過程中自然而然產(chǎn)生的結(jié)果，即所謂的“副產(chǎn)品”。

由于在數(shù)據(jù)生產(chǎn)的過程中并未做到足夠重視，數(shù)據(jù)質(zhì)量與可靠性則很難得到保證，這也是數(shù)據(jù)治理在現(xiàn)在得以被重視的重要原因。

在業(yè)務(wù) IT 化的過程中，企業(yè)通過第三方廠商、自研等方式構(gòu)建多種數(shù)據(jù)系統(tǒng)，采用多種系統(tǒng)中的數(shù)據(jù)化治理，是實現(xiàn)數(shù)據(jù)效能、數(shù)據(jù)驅(qū)動業(yè)務(wù)的關(guān)鍵步驟。

早期，企業(yè)用信息技術(shù)去構(gòu)建業(yè)務(wù)流，而現(xiàn)在，我們試圖用信息技術(shù)，特別是互聯(lián)網(wǎng)行業(yè)中的一些大數(shù)據(jù)處理以及分布式處理技術(shù)構(gòu)建數(shù)據(jù)流，但在構(gòu)建過程中，過多強調(diào)技術(shù)本身而忽視了對數(shù)據(jù)的治理。

數(shù)據(jù)治理是整體性問題，并非僅是技術(shù)問題，市面上數(shù)不勝數(shù)的商業(yè)組件可以解決如何對數(shù)據(jù)進行存儲、查詢等問題，但是在實際的業(yè)務(wù)情況下對于數(shù)據(jù)治理這樣一個系統(tǒng)性工程，目前卻并無現(xiàn)成的產(chǎn)品或技術(shù)可以直接解決。

我們可以嘗試用數(shù)據(jù)治理的角度來解讀上圖。

構(gòu)建數(shù)據(jù)流的過程，很大意義上是為了解決分布在 IT 系統(tǒng)里各個不同子系統(tǒng)之間的數(shù)據(jù)孤島問題，用一條完整的數(shù)據(jù)流將不同子系統(tǒng)之間的數(shù)據(jù)孤島打通，同時應(yīng)用于不同的應(yīng)用場景，這個打通的過程，就是某種意義上的數(shù)據(jù)治理。這也反映了我之前尤為推崇的一個觀點——構(gòu)建數(shù)據(jù)倉庫本身就是一個數(shù)據(jù)治理的過程。

另外，對于數(shù)據(jù)的本質(zhì)，我一直推崇如下兩個定義：第一“信息是用來消除不確定性的”，第二“大數(shù)據(jù)的本質(zhì)，就是用信息來消除不確定性”。

同樣，對于數(shù)據(jù)驅(qū)動在業(yè)務(wù)決策和產(chǎn)品智能兩大方面的應(yīng)用，也都將建立在數(shù)據(jù)治理的基礎(chǔ)上才有意義。

一、什么是數(shù)據(jù)治理？

數(shù)據(jù)治理的本質(zhì)是組織對數(shù)據(jù)的可用性、完整性和安全性的整體管理。

1. 數(shù)據(jù)治理的本質(zhì)

可用性指數(shù)據(jù)可用、可信且有質(zhì)量保證，不會因為分析結(jié)果的準確性造成偏差，從業(yè)者可以放心地根據(jù)數(shù)據(jù)結(jié)果做業(yè)務(wù)決策；完整性分為兩個方面，一方面指數(shù)據(jù)需覆蓋各類數(shù)據(jù)應(yīng)用的需要，另一方面指不會因為數(shù)據(jù)治理沒有到位而造成數(shù)據(jù)資產(chǎn)的流失，也即影響數(shù)據(jù)資產(chǎn)的積累，這也是神策數(shù)據(jù)在創(chuàng)業(yè)伊始便開展私有化部署的原因；安全性指治理和分享過程需安全可控，不侵犯用戶隱私，且不會給組織留下安全隱患。

2. 數(shù)據(jù)治理的重要性

數(shù)據(jù)治理是所有數(shù)據(jù)應(yīng)用的根基，數(shù)據(jù)治理的好壞直接影響所有數(shù)據(jù)應(yīng)用的價值。

無論是基于數(shù)據(jù)看報表，還是做交互式的多維分析，還是做更復(fù)雜的個性化推薦，所有的數(shù)據(jù)應(yīng)用都需要有一個良好的數(shù)據(jù)治理結(jié)果。

神策本身就擁有一款推薦產(chǎn)品——神策智能推薦，通過這款產(chǎn)品的實踐，我們發(fā)現(xiàn)，它的實施周期相比其它幾個產(chǎn)品普遍偏長，這也是因為個性化推薦對于數(shù)據(jù)的質(zhì)量和準確性要求相對更高。

簡而言之，數(shù)據(jù)應(yīng)用做得越深入，所需數(shù)據(jù)就會更多，對數(shù)據(jù)質(zhì)量也會有更高的要求。

數(shù)據(jù)治理是組織數(shù)據(jù)資產(chǎn)沉淀的基礎(chǔ)，數(shù)據(jù)治理的好壞直接決定了組織的數(shù)據(jù)資產(chǎn)能否得到沉淀，能否充分地發(fā)揮價值。

經(jīng)常會有客戶主動來詢問：

“領(lǐng)導(dǎo)說我們要做一個數(shù)據(jù)中臺沉淀數(shù)據(jù)，但不知具體原因，亦不清楚搭建中臺的具體目的，可能要等搭建之后尋找數(shù)據(jù)價值時，再去探索具體應(yīng)用?！?/p>

個人認為，在經(jīng)費條件允許的情況下，當(dāng)然可以將企業(yè)的所有數(shù)據(jù)整合在一起，通過良好的權(quán)限管控，充分的共享，聚合所有的業(yè)務(wù)部門一起去探索數(shù)據(jù)的應(yīng)用，因為數(shù)據(jù)中臺本身就承載著組織內(nèi)部所有數(shù)據(jù)的整合分享角色。

二、數(shù)據(jù)治理面臨的挑戰(zhàn)

本部分的內(nèi)容將數(shù)據(jù)治理面臨的挑戰(zhàn)分為兩類，一類因“技術(shù)”而起，一類因“人”而起。

由客觀的技術(shù)問題對數(shù)據(jù)治理帶來的挑戰(zhàn)普遍較好解決，比如如何采集數(shù)據(jù)、如何存儲數(shù)據(jù)等，都可通過更先進的工具、更新的技術(shù)等方式解決。

而由人或組織架構(gòu)帶來的問題相對復(fù)雜，它的背后包含的是企業(yè)在文化、流程上的問題，可以通過以下實例說明。

1. 多業(yè)務(wù)系統(tǒng)多數(shù)據(jù)源的整合挑戰(zhàn)

企業(yè)想要做的數(shù)據(jù)應(yīng)用越多，所需的數(shù)據(jù)就會越多，所要去獲取的數(shù)據(jù)源也會增多，而相應(yīng)的數(shù)據(jù)處理也會越多，這是一個極為顯而易見的問題。

對于神策數(shù)據(jù)而言，我們在數(shù)據(jù)應(yīng)用方面相對“單純”，主要針對用戶行為領(lǐng)域，采集用戶行為數(shù)據(jù)，從客戶端、服務(wù)端、數(shù)據(jù)庫等做對接。

但即使是這樣一個限定特殊領(lǐng)域的應(yīng)用，我們在整合多方面數(shù)據(jù)源上也會碰到非常多的挑戰(zhàn)，可想而知在面對多業(yè)務(wù)系統(tǒng)多數(shù)據(jù)源的情況下將更加困難。

2. 數(shù)據(jù)采集技術(shù)上的挑戰(zhàn)

近年來，許多公司都在嘗試將自己的業(yè)務(wù)線上化，都需要通過數(shù)據(jù)對用戶進行分析與運營，如何精準采集可用的用戶數(shù)據(jù)以及其他相關(guān)數(shù)據(jù)，都將是數(shù)據(jù)采集在技術(shù)層面上面臨的挑戰(zhàn)。

3. 用戶隱私與安全挑戰(zhàn)

用戶隱私與安全不僅是對技術(shù)挑戰(zhàn)，更多的是一種意識上的挑戰(zhàn)。企業(yè)需要準確把控數(shù)據(jù)采集的紅線，比如針對歐盟范圍內(nèi)的國際業(yè)務(wù)，就需要參考 GDPR 的相關(guān)規(guī)范。

在國內(nèi)，很多銀行券商等企業(yè)也同樣擁有一套完善的數(shù)據(jù)合規(guī)要求，甚至已經(jīng)細化到“某個特定字段對于某一個特定人可看但不可下載”的程度，這些都是需要在進行數(shù)據(jù)治理時考慮的因素。另外，如果需要在公網(wǎng)傳輸交換數(shù)據(jù)，也同樣需要思考數(shù)據(jù)如何防止竊取和偽造的問題

4. 組織架構(gòu)與部門隔閡帶來的配合

部分組織在數(shù)據(jù)治理的過程中速度過慢，成效不好，其中一個很重要的原因是權(quán)責(zé)、部門配合等方面存在問題。很多情況下，生產(chǎn)數(shù)據(jù)、使用數(shù)據(jù)、分析數(shù)據(jù)的工作人員分布在不同的職能線與部門，角色不同，立場也不同，這些客觀存在的影響因素都會影響整個數(shù)據(jù)治理的最終結(jié)果。

5.業(yè)務(wù)持續(xù)迭代中帶來的挑戰(zhàn)

在互聯(lián)網(wǎng)行業(yè)中，尤其是業(yè)務(wù)迭代較為迅速的團隊里，通常存在“1.0 版本的數(shù)據(jù)質(zhì)量最優(yōu)，1.1 版本不行，2.0 版本完全不可用”的說法，說明第一次做數(shù)據(jù)治理時，極重視數(shù)據(jù)質(zhì)量，會有完善的流程來保證埋點的準確性，本身也沒有太多的包袱；而在后續(xù)的產(chǎn)品迭代中，如果流程和標準的迭代相對滯后，整個數(shù)據(jù)治理的結(jié)果也會隨著受影響，最終導(dǎo)致整個數(shù)據(jù)質(zhì)量低劣，直至所謂的“完全不可用”。

下面舉兩個具體實例說明。

實例 1.

某公司的業(yè)務(wù)部門向第三方數(shù)據(jù)分析平臺提出數(shù)據(jù)需求，該公司內(nèi)部有多個 App 頻道，每個頻道隸屬于一個單獨的部門，而第三方數(shù)據(jù)分析平臺在埋點采集階段需要不同部門的團隊相互配合。由于缺乏統(tǒng)一各部門需求與任務(wù)的統(tǒng)籌角色，實施過程中很難清楚劃分相關(guān)責(zé)任，再加上管理、測試等工具的缺失，最終導(dǎo)致每次發(fā)版都會發(fā)生埋點丟失和報錯。

實例 2.

某企業(yè)的所有用戶相關(guān)數(shù)據(jù)分散在不同的系統(tǒng)里面，試圖通過第三方數(shù)據(jù)分析平臺整合統(tǒng)一的用戶標簽數(shù)據(jù)系統(tǒng)。然而在收集數(shù)據(jù)的過程中，每跨一次部門就需要提一次全套的審批流程，好不容易收集齊各部門各系統(tǒng)中的數(shù)據(jù)之后，卻發(fā)現(xiàn)數(shù)據(jù)統(tǒng)計口徑不一致，無法得到一個公司統(tǒng)一的用戶標簽數(shù)據(jù)。

三、數(shù)據(jù)治理與組織架構(gòu)

上述內(nèi)容已經(jīng)提到關(guān)于組織架構(gòu)的內(nèi)容，因其重要性將在本部分單獨說明。

1. 數(shù)據(jù)治理是一個動態(tài)的過程

數(shù)據(jù)治理實際反映的是組織問題、文化問題，這也是許多公司為了明確權(quán)責(zé)劃分而建立數(shù)據(jù)治理委員會的原因。同時，還需要明確的程序與執(zhí)行程序的計劃，明確的程序指對數(shù)據(jù)進行治理所需經(jīng)歷的階段、問題有明細的了解，執(zhí)行程序的計劃指每一步需要解決哪些問題。當(dāng)公司的主流業(yè)務(wù)發(fā)生變化時，組織架構(gòu)會隨之改變，接而帶來數(shù)據(jù)治理層面的變更，所以，數(shù)據(jù)治理是一個動態(tài)的過程，伴隨整個業(yè)務(wù)變更與組織架構(gòu)變更。

2. 數(shù)據(jù)治理中的兩個核心角色

• 第一，數(shù)據(jù)使用者，通常集中在產(chǎn)品經(jīng)理、數(shù)據(jù)分析師、營銷經(jīng)理、運營經(jīng)理等崗位，有查看報表、數(shù)據(jù)分析、用戶畫像、用戶運營等需求，他們屬于數(shù)據(jù)治理的受益者。
• 第二，數(shù)據(jù)生產(chǎn)者，通常集中在前端開發(fā)、后端開發(fā)、數(shù)據(jù)工程師、ETL 工程師，有埋點、打日志、做數(shù)據(jù) ETL 的需求，他們屬于數(shù)據(jù)治理的付出者，可能看不到直接收益，反而增加工作負擔(dān)。

由于數(shù)據(jù)使用者屬于數(shù)據(jù)治理中受益的一方，多數(shù)情況下需由其來推動數(shù)據(jù)治理任務(wù)進行。

在神策數(shù)據(jù)的具體實踐中，我們非常強調(diào)對客戶接口人，通常情況下也就是數(shù)據(jù)使用者的培訓(xùn)，由他去推動整個流程，去了解數(shù)據(jù)生產(chǎn)者的實際情況，從而讓數(shù)據(jù)治理工作更好地進行。

四、數(shù)據(jù)治理中的應(yīng)對

首先，數(shù)據(jù)治理的核心認識是，數(shù)據(jù)治理是一個持續(xù)并且長久的一個過程，不同的產(chǎn)品可以解決比如采集、傳輸?shù)葦?shù)據(jù)治理層面上的不同問題，但并不存在一款所謂的“數(shù)據(jù)治理產(chǎn)品”，可以用來解決所有問題。

其次，數(shù)據(jù)治理的整體方法論是“從應(yīng)用倒推”。先確定數(shù)據(jù)應(yīng)用、數(shù)據(jù)資產(chǎn)的需求，接著確定需要哪些數(shù)據(jù)，之后確定需要從哪種數(shù)據(jù)源獲取數(shù)據(jù)，最終確定具體的數(shù)據(jù)治理方案。

神策憑借近年在實際業(yè)務(wù)中的經(jīng)驗，圍繞用戶行為分析領(lǐng)域，總結(jié)出一套數(shù)據(jù)治理方法論。

• 第一步，確定分析需求。通過了解數(shù)據(jù)使用者需要看哪些指標、用在哪些場景、使用哪些分析模型等方面來了解具體的數(shù)據(jù)使用需求，完成需求梳理。
• 第二步，映射數(shù)據(jù)模型。在該步驟需確定采集的事件和屬性，并完成事件設(shè)計。
• 第三步，確定數(shù)據(jù)采集技術(shù)方案。根據(jù)要采的事件和屬性，結(jié)合現(xiàn)有實際業(yè)務(wù)系統(tǒng)，去確定到底要從何種系統(tǒng)里以何種技術(shù)方案采集數(shù)據(jù)。
• 第四步，數(shù)據(jù)采集與集成。這一步就是指具體的開發(fā)、集成工作，包括完成相應(yīng)的 SDK 集成、數(shù)據(jù)采集工具的開發(fā)、數(shù)據(jù) ETL 開發(fā)等。
• 第五步，數(shù)據(jù)校驗和上線。這一步中需要使用必要的測試工具、利用埋點管理平臺做數(shù)據(jù)對比等。

下面，舉例說明數(shù)據(jù)治理的三大原則：

數(shù)據(jù)治理原則 1：不要先污染后治理，要從源頭控制

在創(chuàng)立神策數(shù)據(jù)之前，我們曾長期參與百度的日志數(shù)據(jù)相關(guān)的工作。在最開始的階段，所謂的日志處理就是通過中控機器，從不同的業(yè)務(wù)系統(tǒng)里下載文本日志，跑完腳本后生成報表，再通過郵件的形式分發(fā)。

2008 年，團隊解決了之前方案中的技術(shù)架構(gòu)的問題，把以前的單機系統(tǒng)變成了分布式系統(tǒng)，提高了整體性能與計算效率，用分布式的方式下載日志，用分布式的方式來計算報表。但是，我們本質(zhì)上只提供了一個計算的調(diào)度平臺。就數(shù)據(jù)本身而言，沒有人知道這些海量數(shù)據(jù)其中的細節(jié)，數(shù)據(jù)沒有得到充分的復(fù)用，造成了許多計算資源的浪費。所以，這部分的工作其實只是解決了一個技術(shù)問題，但并沒有解決任何數(shù)據(jù)治理方面的問題。

意識到數(shù)據(jù)治理的問題之后，團隊中開始了百度用戶數(shù)據(jù)倉庫的構(gòu)建工作。有工程師每天將文本日志用程序轉(zhuǎn)成結(jié)構(gòu)化日志，并在進行必要的數(shù)據(jù)清洗、Union、Join 等 ETL 的工作之后，將這些結(jié)構(gòu)化日志統(tǒng)一映射到一張大表（今天 event 模型前身），并對外提供集中訪問。

但隨著產(chǎn)品線不斷增多，入庫周期變得更長，到后期，每增加一條產(chǎn)品線，都需要付出至少一周時間去解決。同時，由于數(shù)據(jù)在產(chǎn)生后需要做 ETL，從產(chǎn)生到傳輸?shù)浇y(tǒng)一的 Hadoop 集群需要時間， ETL 的計算也同樣需要時間，即使在最佳情況下也只能保證半小時的時效性。

這是一個典型的數(shù)據(jù)“先污染后治理”的例子，不僅在治理上需要付出更多的代價和成本，數(shù)據(jù)本身的可用性和時效性也會受到影響。

之后，我們嘗試通過推行全百度統(tǒng)一的 Logging 平臺，從打日志開始就保證數(shù)據(jù)的正確性，并且直接將數(shù)據(jù)傳輸?shù)椒植际郊荷弦员ＷC數(shù)據(jù)的可用，這就是從源頭來治理數(shù)據(jù)的思路。

在創(chuàng)立神策之后，我們就充分吸取了這些教訓(xùn)，通過 SDK 或者其他工具去嚴格控制數(shù)據(jù)埋點格式及數(shù)據(jù)模型，盡最大努力減少 ETL 的代價，從而保證查詢時效性與導(dǎo)入時效性。所以，數(shù)據(jù)治理要從源頭開始，不要先污染后治理。

數(shù)據(jù)治理原則 2：數(shù)據(jù)治理的過程要貫穿到整個業(yè)務(wù)迭代的過程中

以軟件開發(fā)流程為例。

首先，在產(chǎn)品需求階段，同樣需要去明確數(shù)據(jù)需求。在具體設(shè)計階段，完成產(chǎn)品交互系統(tǒng)架構(gòu)變更的同時，去確定要加哪些日志、字段等。

在實際開發(fā)階段，完成相應(yīng)的代碼開發(fā)、日志變更，單元測試應(yīng)包括相應(yīng)的日志變更部分，并進行日志審計，不要將埋點當(dāng)成一個單獨的開發(fā)任務(wù)，而是伴隨的過程。在

測試階段，當(dāng)測試整體性能的正確性的同時，測試數(shù)據(jù)、日志的正確性，確保功能符合預(yù)期、日志打印正確，可以滿足分需求。

在上線階段，要實際查看上線的埋點、日志是否正確，并對功能進行確認。

最后，在項目總結(jié)階段，用數(shù)據(jù)說明轉(zhuǎn)化率變化、流程優(yōu)化情況，對功能完成程度的總結(jié)，嘗試真正地用數(shù)據(jù)說話。

數(shù)據(jù)治理原則 3：以產(chǎn)品化、組件化的思路來解決，不能依賴于人工

以產(chǎn)品的方式解決客戶端數(shù)據(jù)采集問題。

神策的開源 SDK 被許多業(yè)界同仁參考學(xué)習(xí)，究其原因是因為它用產(chǎn)品的方式解決客戶端數(shù)據(jù)采集問題的思維，無論是電商、社交、金融、游戲，還是哪一種產(chǎn)品，都會在客戶端采集用戶數(shù)據(jù)時面臨匿名 ID 生成、基礎(chǔ)屬性采集、數(shù)據(jù)打包壓縮加密、本地緩存、網(wǎng)絡(luò)傳輸、時間校準、根據(jù)數(shù)據(jù)模型限定了采集數(shù)據(jù)的 Schema、通過全埋點等方式提供了對常見數(shù)據(jù)的自動采集功能、結(jié)合后端提供了對于采集端調(diào)試功能等場景，所以，可以用產(chǎn)品思維來解決的問題，不依賴人工。

作者：曹犟，神策數(shù)據(jù)聯(lián)合創(chuàng)始人 & CTO

本文由 @神策數(shù)據(jù) 發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載

題圖來自Unsplash，基于CC0協(xié)議