數(shù)據(jù)文化 | Uber的數(shù)據(jù)治理
Uber 通過賦能數(shù)十億打車和快遞服務(wù)，連接數(shù)以百萬計的乘客、企業(yè)、餐館、司機和快遞員，徹底改變了世界的出行方式。這個龐大的交通平臺的核心是大數(shù)據(jù)和數(shù)據(jù)科學(xué)，它們支撐著 Uber 的所有工作，比如更好的定價和匹配、欺詐檢測、降低預(yù)計達(dá)到時間（ETA）和實驗。每天 PB 級的數(shù)據(jù)被收集和處理，成千上萬用戶根據(jù)這些數(shù)據(jù)進行分析決策，從而構(gòu)建 / 改進這些產(chǎn)品。
雖然我們能夠擴展我們的數(shù)據(jù)系統(tǒng)，但以前，對于一些重要的數(shù)據(jù)問題，我們沒有給予足夠的關(guān)注，在規(guī)模擴大之后，它們變得更加重要，涉及的具體問題包括：
數(shù)據(jù)重復(fù)： 一些關(guān)鍵數(shù)據(jù)和指標(biāo)缺少一個真實的數(shù)據(jù)來源，這導(dǎo)致了重復(fù)、不一致，并且在使用時會有很多困惑。消費者必須從解決業(yè)務(wù)問題中抽出時間來做大量的盡職調(diào)查，從而彌補這一點。使用自助服務(wù)工具創(chuàng)建的數(shù)十萬個數(shù)據(jù)集加劇了這個問題，因為我們無法明顯看出哪個數(shù)據(jù)集更重要。
發(fā)現(xiàn)問題： 如果沒有豐富的元數(shù)據(jù)和分面搜索，在數(shù)十萬數(shù)據(jù)集中發(fā)現(xiàn)數(shù)據(jù)是很困難的。糟糕的發(fā)現(xiàn)導(dǎo)致了重復(fù)的數(shù)據(jù)集、重復(fù)的工作和不一致的答案（這取決于回答問題時所使用的數(shù)據(jù)）。
工具互不連通： 數(shù)據(jù)流經(jīng)許多工具、系統(tǒng)和組織。但是我們的工具沒有相互集成，導(dǎo)致工作重復(fù)和糟糕的開發(fā)體驗——例如，必須在多個工具之間復(fù)制粘貼文檔和所有者信息；開發(fā)者無法自信地修改數(shù)據(jù)模式，因為不清楚它在下游是如何使用的。
日志不一致： 在移動設(shè)備上的日志是手動完成的；日志沒有統(tǒng)一的結(jié)構(gòu)，我們無法通過簡單、一致的方法度量用戶的實際行為，只能通過推斷來判定（這低效且容易出錯）。
流程缺失： 缺乏跨團隊的數(shù)據(jù)工程流程，導(dǎo)致各個團隊的成熟度不同，團隊間沒有一致的數(shù)據(jù)質(zhì)量定義或指標(biāo)。
所有權(quán)和 SLA 缺失： 數(shù)據(jù)集沒有明確的屬主——它們通常沒有質(zhì)量保證、錯誤修復(fù)的 SLA 不一致，電話支持、事件管理與我們對服務(wù)的管理方式相去甚遠(yuǎn)。
這些問題并不是 Uber 獨有的——根據(jù)我們與其它公司的工程師和數(shù)據(jù)科學(xué)家的交流，這些問題很常見，特別是對于那些增長非常快的公司。由于服務(wù)故障 / 中斷即時可見，所以我們對服務(wù)和服務(wù)質(zhì)量的關(guān)注比較多，而對數(shù)據(jù)和相關(guān)工具的關(guān)注往往比較少。但在規(guī)模比較大時，解決這些問題，并使其與服務(wù)工具 / 管理的嚴(yán)格程度保持一致，變得極其重要，尤其是如果數(shù)據(jù)在產(chǎn)品功能和創(chuàng)新中扮演著關(guān)鍵角色，正如數(shù)據(jù)在 Uber 的角色一樣。
下圖顯示了從移動應(yīng)用程序和服務(wù)到數(shù)據(jù)倉庫和最終消費面的高級數(shù)據(jù)流。我們最初只在數(shù)據(jù)流中出現(xiàn)數(shù)據(jù)問題的地方應(yīng)急性地解決了這些問題的癥狀，而沒有解決根本問題。我們認(rèn)識到，需要一種整體的方案來解決這些問題，并徹底解決其根源。我們的目標(biāo)是重新組織數(shù)據(jù)日志系統(tǒng)、工具和流程，從而逐步改變整個 Uber 的數(shù)據(jù)質(zhì)量。我們召集了橫跨端到端數(shù)據(jù)流堆棧的團隊，其中包括來自堆棧各個部分的工程師和數(shù)據(jù)科學(xué)家，最終修改了 20 多個現(xiàn)有系統(tǒng)。
為了將精力集中在整體思考上，我們從 Rider 應(yīng)用程序上獲取了與行程和會話信息相關(guān)的關(guān)鍵數(shù)據(jù)“切片”，并嘗試為它們構(gòu)建一個真實數(shù)據(jù)源（source of truth，SoT），并且修復(fù)應(yīng)用程序上的日志記錄、數(shù)據(jù)處理工具、數(shù)據(jù)本身以及將其維護成 SoT 所需的過程。
與試圖隱藏數(shù)據(jù)并向服務(wù)外部公開狹窄接口的服務(wù)不同，倉庫中的離線數(shù)據(jù)更多的是公開來自相關(guān)服務(wù)和領(lǐng)域的數(shù)據(jù)，以便一起進行分析。我們的一個關(guān)鍵認(rèn)識是，為了做好這一點，我們不僅要解決數(shù)據(jù)工具的問題，還要解決數(shù)據(jù)的人員和流程方面的問題。因此我們提出了一些指導(dǎo)原則：
數(shù)據(jù)即代碼： 數(shù)據(jù)應(yīng)該作為代碼對待。對數(shù)據(jù)工件的創(chuàng)建、棄用和關(guān)鍵更改應(yīng)該通過設(shè)計評審流程，并使用適當(dāng)?shù)臅嫖臋n，而且是以客戶視角編寫的文檔。必須為模型更改指定審閱者，他們在更改落地之前進行評審。模型復(fù)用 / 擴展優(yōu)先于創(chuàng)建新模型。數(shù)據(jù)工件具有與之相關(guān)聯(lián)的測試，我們要對其進行持續(xù)測試。通常，這是用于 API 服務(wù)的實踐，在考慮數(shù)據(jù)時，我們需要同樣嚴(yán)格。
數(shù)據(jù)要有屬主： 數(shù)據(jù)就是代碼，所有的代碼必須有屬主。每個數(shù)據(jù)工件必須有一個明確的所有者，一個明確的目的，并且在用完后廢棄。
數(shù)據(jù)質(zhì)量可知： 數(shù)據(jù)工件必須有數(shù)據(jù)質(zhì)量 SLA，以及事件報告和管理，就像我們對服務(wù)所做的那樣。所有者負(fù)責(zé)維護這些服務(wù)協(xié)議。
加速數(shù)據(jù)生產(chǎn)效率： 數(shù)據(jù)工具的設(shè)計必須可以改進生產(chǎn)者和消費者之間的協(xié)作，必要時必須有所有者、文檔和審閱者。數(shù)據(jù)工具必須與其它相關(guān)工具無縫集成，讓我們不必再考慮必要的元數(shù)據(jù)。數(shù)據(jù)工具應(yīng)配備與服務(wù)相同級別的開發(fā)人員，提供在更改落地之前編寫和運行測試的能力，在轉(zhuǎn)入生產(chǎn)環(huán)境之前在準(zhǔn)生產(chǎn)環(huán)境中測試這些更改的能力，并與現(xiàn)有的監(jiān)控 / 告警生態(tài)系統(tǒng)很好地集成。
針對數(shù)據(jù)的組織： 團隊的目標(biāo)應(yīng)該是“全棧”配置，因此，必要的數(shù)據(jù)工程人才就可以對數(shù)據(jù)的整個生命周期進行長期的觀察。雖然更為核心的團隊有復(fù)雜的數(shù)據(jù)集，但是大多數(shù)生成數(shù)據(jù)的團隊?wèi)?yīng)該以本地所有權(quán)為目標(biāo)。我們應(yīng)該有必要的培訓(xùn)材料，并優(yōu)先培訓(xùn)工程師，使其相當(dāng)精通數(shù)據(jù)的生產(chǎn)和消費實踐。最后，團隊領(lǐng)導(dǎo)應(yīng)該對他們生產(chǎn)和使用的數(shù)據(jù)的所有權(quán)和質(zhì)量負(fù)責(zé)。
在本文的余下部分，我們將重點介紹我們編程體驗中一些最有用也最有趣的收獲。
由于數(shù)據(jù)質(zhì)量差，我們經(jīng)受了許多艱苦的工作。我們看到過這樣的例子：實驗測量值不準(zhǔn)確，導(dǎo)致了大量的體力勞動，降低了驗證和修正數(shù)據(jù)的效率。事實證明，隨著大數(shù)據(jù)的應(yīng)用，這個問題變得越來越普遍——據(jù) IBM的一份研究 和哈佛商業(yè)評論（HBR）估計，由數(shù)據(jù)驅(qū)動的企業(yè)將因數(shù)據(jù)不足而遭受巨大的負(fù)面影響。
為了減少繁重的工作和不良的業(yè)務(wù)影響，我們希望開發(fā)一種用于討論數(shù)據(jù)質(zhì)量的通用語言和框架，以便任何人都可以以一致的預(yù)期來生產(chǎn)和消費數(shù)據(jù)。為了實現(xiàn)這一點，我們發(fā)展了兩個主要概念：標(biāo)準(zhǔn)數(shù)據(jù)質(zhì)量檢查和數(shù)據(jù)集等級定義。
數(shù)據(jù)質(zhì)量是一個復(fù)雜的話題，有許多不同的方面值得深入研究，因此我們將把數(shù)據(jù)質(zhì)量的討論局限于我們已經(jīng)取得重大進展的領(lǐng)域，而將其它方面留待以后討論。Uber 生成和使用數(shù)據(jù)的環(huán)境對我們選擇關(guān)注哪些數(shù)據(jù)質(zhì)量領(lǐng)域起著重要的作用。雖然其中有些也能適用于其他人，但有些不是。在 Uber，數(shù)據(jù)生產(chǎn)者和消費者面臨的一系列常見問題是：如何在分析最新數(shù)據(jù)和完整數(shù)據(jù)之間進行權(quán)衡？如果在不同的數(shù)據(jù)中心并行運行管道，我們?nèi)绾谓忉尣煌瑪?shù)據(jù)中心的數(shù)據(jù)一致性？在給定的數(shù)據(jù)集上應(yīng)該運行什么語義質(zhì)量檢查？我們想要選擇一組檢查，為解釋這些問題提供一個框架。
經(jīng)過幾次迭代，我們得到了下面描述的 5 種主要類型的數(shù)據(jù)質(zhì)量檢查。每個數(shù)據(jù)集都必須附帶這些檢查并配置默認(rèn)的 SLA：
新鮮度： 從數(shù)據(jù)生成到數(shù)據(jù)在目標(biāo)系統(tǒng)中達(dá)到 99.9% 完成度之間的時間延遲，包括完整性水印（默認(rèn)設(shè)置為 39 秒），因為只優(yōu)化新鮮度而不考慮完整性會導(dǎo)致低質(zhì)量的決策。
完整性： 目標(biāo)系統(tǒng)中的行數(shù)與源系統(tǒng)中的行數(shù)之比。
重復(fù)： 具有重復(fù)主鍵或唯一鍵的行數(shù)百分比，在原始數(shù)據(jù)表中默認(rèn)為 0% 重復(fù)，而在建模表中允許少量重復(fù)。
跨數(shù)據(jù)中心的一致性： 將當(dāng)前數(shù)據(jù)中心中的數(shù)據(jù)集副本與另一個數(shù)據(jù)中心中的副本進行對比時，數(shù)據(jù)丟失的百分比。
語義檢查： 捕獲數(shù)據(jù)字段的關(guān)鍵屬性，例如 null/not-null、唯一性、不同值的百分比和值的范圍。
數(shù)據(jù)集所有者可以選擇提供不同的 SLA，并向消費者提供適當(dāng)?shù)奈臋n和解釋——例如，根據(jù)數(shù)據(jù)集的性質(zhì)，人們可能想要犧牲完整性來換取新鮮度（比如流式數(shù)據(jù)集）。相似地，消費者可以選擇基于這些指標(biāo)來消費數(shù)據(jù)集——基于完整性觸發(fā)器而不是簡單地基于時間觸發(fā)器來運行管道。
我們正繼續(xù)研究更復(fù)雜的檢查，包括跨數(shù)據(jù)集概念的一致性，以及在上述時間維度檢查的基礎(chǔ)上進行異常檢測。
除了質(zhì)量度量之外，擁有一種將數(shù)據(jù)集與業(yè)務(wù)不同等級的重要性關(guān)聯(lián)起來的方法也是必要的，這樣就很容易突出顯示最重要的數(shù)據(jù)。對于服務(wù)，我們就是通過分配“等級”（基于數(shù)據(jù)的業(yè)務(wù)重要性）實現(xiàn)這一點的。這些等級有助于確定停機的影響，并提供了關(guān)于哪些數(shù)據(jù)等級應(yīng)用于哪些目的的指導(dǎo)原則。例如，如果某些數(shù)據(jù)影響合規(guī)性、收入或品牌，那么它應(yīng)該被標(biāo)記為第 1 級或第 2 級。由用戶創(chuàng)建的用于不太重要的臨時搜索的臨時數(shù)據(jù)，默認(rèn)標(biāo)記為第 5 級，如果不使用則可以在一段固定時間后刪除。數(shù)據(jù)等級還確定提交的事件的級別，以及針對數(shù)據(jù)集創(chuàng)建的修復(fù) bug 的 SLA。分級的一個副產(chǎn)品是數(shù)據(jù)資產(chǎn)的系統(tǒng)性清單，我們依賴這些資產(chǎn)來做業(yè)務(wù)關(guān)鍵決策。這樣做的另一個好處是，對相似或不再作為事實來源的數(shù)據(jù)集進行顯式去重。最后，通過分級實現(xiàn)的可見性有助于我們重構(gòu)數(shù)據(jù)集，從而可以改進建模、數(shù)據(jù)粒度一致性和規(guī)范化級別。
我們已經(jīng)開發(fā)了自動化方法來為機構(gòu)生成“分級報告”，顯示需要分級的數(shù)據(jù)集、分級數(shù)據(jù)的使用情況等，作為機構(gòu)的“數(shù)據(jù)健康”的衡量指標(biāo)。我們還跟蹤這些指標(biāo)作為“工程卓越性”標(biāo)準(zhǔn)。隨著越來越多的采用和反饋，我們不斷迭代具體的定義和度量方法，進一步改進它們。
如果我們不將這些定義自動化并使其易于使用和應(yīng)用，僅僅擁有這些定義是不夠的。我們將多個現(xiàn)有的數(shù)據(jù)質(zhì)量工具整合到一個實現(xiàn)了這些定義的工具中。如果有意義，我們可以自動生成測試（對于原始數(shù)據(jù)，即由 Kafka 主題轉(zhuǎn)儲到數(shù)據(jù)倉庫的數(shù)據(jù)，除了語義測試之外，我們還可以自動生成四類測試），并且通過最小化數(shù)據(jù)集所有者的輸入簡化了測試創(chuàng)建過程。這些標(biāo)準(zhǔn)檢查為每個數(shù)據(jù)集提供了一個最小測試集，同時，該工具也為生產(chǎn)者提供了足夠的靈活性，他們只需提供一個 SQL 查詢就可以創(chuàng)建新的測試。我們學(xué)到了許多有趣的經(jīng)驗，包括如何以較低的開銷擴展這些測試，如何簡化為數(shù)據(jù)集構(gòu)建一套測試的抽象，何時調(diào)度測試以減少誤報和噪音警報，如何將這些測試應(yīng)用于流式數(shù)據(jù)集，以及我們希望在以后的文章中發(fā)布的更多內(nèi)容。
如前所述，我們有成千上萬的數(shù)據(jù)集和成千上萬的用戶。如果我們考慮其它數(shù)據(jù)資產(chǎn)——報表、機器學(xué)習(xí)特征、度量、儀表盤——我們管理的資產(chǎn)數(shù)量會大得多。我們希望確保：a) 消費者使用正確的數(shù)據(jù)做出決策，b) 生產(chǎn)者做出明智的決策以改進數(shù)據(jù)、確定錯誤修復(fù)的優(yōu)先級等。為此，我們需要一個單一的目錄，該目錄收集所有數(shù)據(jù)資產(chǎn)的元數(shù)據(jù)，并根據(jù)用戶的需求向他們提供正確的信息。事實上，我們意識到，糟糕的發(fā)現(xiàn)曾導(dǎo)致生產(chǎn)者和消費者產(chǎn)生重復(fù)、冗余數(shù)據(jù)集的惡性循環(huán)，然后這些數(shù)據(jù)集就被廢棄了。
我們希望向用戶提供關(guān)于每個數(shù)據(jù)工件（表、列、度量）的詳細(xì)元數(shù)據(jù)：
基礎(chǔ)元數(shù)據(jù)： 例如文檔、所有權(quán)信息、管道、生成數(shù)據(jù)的源代碼、示例數(shù)據(jù)、譜系和工件層
使用元數(shù)據(jù)： 關(guān)于什么人在什么時候使用這些元數(shù)據(jù)、流行查詢和一起使用的工件的統(tǒng)計
質(zhì)量元數(shù)據(jù)： 對數(shù)據(jù)進行測試，何時運行、哪些測試通過，以及數(shù)據(jù)提供的聚合 SLA
成本元數(shù)據(jù)： 用于計算和存儲數(shù)據(jù)的資源，包括貨幣成本
Bug 和 SLA： 針對工件、事件、近期預(yù)警和總體 SLA 提交的 bug，從而響應(yīng)所有者的問題
創(chuàng)建這個單一的元數(shù)據(jù)目錄并提供一個功能強大的用戶界面（具有基于上下文的搜索和發(fā)現(xiàn)功能），對于實現(xiàn)生產(chǎn)者和消費者之間的協(xié)作、減少使用數(shù)據(jù)的工作量以及提升總體數(shù)據(jù)質(zhì)量至關(guān)重要。
為了實現(xiàn)這個目標(biāo)，我們對內(nèi)部元數(shù)據(jù)目錄 Databook 的后端和 UI 進行了徹底的改進。我們對元數(shù)據(jù)詞匯表進行了標(biāo)準(zhǔn)化，使其易于向現(xiàn)有實體添加新的元數(shù)據(jù)屬性，設(shè)計了擴展性，以便以最小的工作量輕松定義新的實體類型，并將我們的大多數(shù)關(guān)鍵工具集成到該系統(tǒng)中，并將它們的元數(shù)據(jù)發(fā)布到這個中心位置，把各種數(shù)據(jù)資產(chǎn)、工具和用戶連接起來。改進后的用戶界面更清晰，并且用戶可以更方便地過濾和縮小所需數(shù)據(jù)的范圍。經(jīng)過這些改進后，工具使用量急劇增加。我們在這篇博客中詳細(xì)介紹了這些變化：Turning Metadata Into Insights with Databook。
為了了解和改進產(chǎn)品，讓我們的應(yīng)用程序打印日志來獲取實際的用戶體驗是至關(guān)重要的。我們希望測量用戶體驗，而不是推斷用戶體驗，但是每個團隊都有一個自定義的日志打印方法，導(dǎo)致在如何測量用戶體驗方面存在不一致。我們希望標(biāo)準(zhǔn)化整個應(yīng)用系統(tǒng)中各個團隊的日志打印方式，甚至“平臺化”日志打印，這樣開發(fā)者就可以在開發(fā)所有產(chǎn)品功能時免于去考慮如何通過日志打印必需信息，例如：向用戶展示了什么、與用戶交互時應(yīng)用程序的狀態(tài)、交互類型和交互持續(xù)時間。
在深入研究了 Uber 用來構(gòu)建應(yīng)用程序的移動框架之后，我們意識到，移動應(yīng)用開發(fā)框架（之前是開源的）已經(jīng)內(nèi)置了一個天然的結(jié)構(gòu)，當(dāng)用戶交互時，可以提供有關(guān)應(yīng)用程序狀態(tài)的關(guān)鍵信息。自動獲取 RIB 層次 將使我們了解應(yīng)用程序的狀態(tài)，以及哪個 RIB（大致可以將它們當(dāng)作組件）當(dāng)前是活躍的。應(yīng)用程序上的不同屏幕映射到不同的 RIB 層次。
基于這種直覺，我們開發(fā)了一個庫來捕獲當(dāng)前的 RIB 層次，將其序列化，并且自動將其附加到應(yīng)用程序觸發(fā)的每個分析事件。在接收這些信息的后端網(wǎng)關(guān)中，我們實現(xiàn)了從 RIB 層次結(jié)構(gòu)到一組靈活的元數(shù)據(jù)（例如屏幕名稱、應(yīng)用程序中階段的名稱，等等）的輕量級映射。這些元數(shù)據(jù)可以獨立演化，生產(chǎn)者或消費者都可以添加更多信息，而不必依賴移動應(yīng)用程序的更改（由于構(gòu)建和發(fā)布周期長達(dá)數(shù)周，因此更改速度慢且成本高）。在后端，網(wǎng)關(guān)在寫入 Kafka 之前，除了序列化狀態(tài)之外，還會將這些額外的元數(shù)據(jù)附加到分析事件中。網(wǎng)關(guān)上的這個映射也可以通過 API 獲得，這樣倉庫作業(yè)就可以在映射演進時回填數(shù)據(jù)。
除了上面的核心問題之外，我們還必須解決一些其它問題，這里我們將不再詳細(xì)介紹，例如：優(yōu)化序列化的 RIB 層次結(jié)構(gòu)來減少分析負(fù)載大小，使映射高效，通過自定義測試框架在應(yīng)用程序更改時保持映射正確，將 RIB 樹正確映射到狀態(tài)，對屏幕和狀態(tài)名稱進行標(biāo)準(zhǔn)化，等等。
雖然這個庫并沒有完全解決我們要解決的所有日志問題，但它確實為日志提供了一個結(jié)構(gòu)，使許多分析變得更容易，如下所述。我們正在迭代這個庫來解決提出的其它問題。
騎手漏斗分析
使用上面的日志框架生成的數(shù)據(jù)，我們能夠極大地簡化對騎手行為的漏斗分析。我們在幾個小時內(nèi)就建立了一個儀表盤，這在過去可能需要幾個星期的時間。這些數(shù)據(jù)目前正在為許多實驗監(jiān)控和其它儀表盤提供支持，讓我們可以了解用戶行為。
當(dāng)我們啟動 Data180 時，公司中有許多度量代碼庫。我們評估了這些解決方案的優(yōu)缺點，并在一個名為 uMetric 的代碼庫上進行了標(biāo)準(zhǔn)化。事實上，它不僅僅是一個代碼庫——它具有高級功能，例如讓用戶專注于 YAML 格式的定義，并通過為不同的查詢系統(tǒng)（例如 Hive/Presto/Spark）生成查詢、為度量生成流式處理和批處理管道、自動創(chuàng)建數(shù)據(jù)質(zhì)量測試等省去了大量的工作。這個系統(tǒng)正在得到更廣泛的采用，我們也在投資進一步加強它。我們正在自動化重復(fù)和近似重復(fù)的度量檢測，將此系統(tǒng)與 Databook 和其它數(shù)據(jù)消費界面集成，這樣消費者就可以直接消費度量結(jié)果，而不是復(fù)制和運行度量 SQL（調(diào)整 SQL 更容易出錯及導(dǎo)致度量重復(fù)），改進了自助服務(wù)的性質(zhì)，并在事故發(fā)生之前檢測到錯誤，等等。這種標(biāo)準(zhǔn)化幫助我們大大減少了消費時的重復(fù)和混亂。這個系統(tǒng)在這個博客中有詳細(xì)的描述——The Journey Towards Metric Standardization。
除了上面列出的更改之外，我們還實施了其它幾個工具和流程更改，以改進我們的數(shù)據(jù)文化，簡要介紹如下：
共享數(shù)據(jù)模型: 為了避免重復(fù)定義相同概念的模式（這很常見），我們改進了模式定義的工具，允許導(dǎo)入和共享現(xiàn)有類型和數(shù)據(jù)模型。我們正在構(gòu)建其它特性和流程，從而推動共享數(shù)據(jù)模型的采用，減少重復(fù)和近似重復(fù)的數(shù)據(jù)模型的創(chuàng)建。
移動分析強制代碼評審者和單元測試： 我們重新組織了移動分析事件的模式，并允許生產(chǎn)者和消費者將自己添加為強制評審者，以避免在沒有適當(dāng)評審和通知的情況下進行更改。我們還構(gòu)建了一個移動日志測試框架，以確保數(shù)據(jù)測試在構(gòu)建時運行。
強制所有權(quán)： 我們改進了數(shù)據(jù)生成的底層數(shù)據(jù)工具和界面（模式定義、Kafka 主題創(chuàng)建、創(chuàng)建數(shù)據(jù)的管道、度量創(chuàng)建、儀表盤創(chuàng)建，等等），以便在無法自動推斷所有者時強制提供所有權(quán)信息。所有權(quán)信息進一步標(biāo)準(zhǔn)化為整個公司的單一服務(wù)，跟蹤團隊和組織，而不僅僅是單個創(chuàng)建者。這一修改可以避免新增無主數(shù)據(jù)。我們進一步運行啟發(fā)式算法，將所有者分配到“廢棄”的數(shù)據(jù)集，這些數(shù)據(jù)集沒有所有者或所有者已不在公司，這使我們有望達(dá)到 100% 的所有權(quán)覆蓋率。
跨工具集成： 我們集成了工具，這樣一旦在源工具上設(shè)置了文檔、所有權(quán)和其它關(guān)鍵元數(shù)據(jù)，它就無縫地跨所有下游工具流動。我們將管道工具與標(biāo)準(zhǔn)告警和監(jiān)控工具集成在一起，使服務(wù)和數(shù)據(jù)管道在生成和管理告警方面具有一致性。
我們從這樣一個假設(shè)開始：對數(shù)據(jù)進行全面的思考——考慮跨人員和系統(tǒng)的端到端數(shù)據(jù)流——可以提高整體數(shù)據(jù)質(zhì)量。我們認(rèn)為，這一努力已經(jīng)顯示出支持這一假設(shè)的有力證據(jù)。然而，最初的工作僅僅是我們向更好的數(shù)據(jù)文化轉(zhuǎn)型之旅的開始。在這項工作取得成功的基礎(chǔ)上，我們將這個程序推廣到 Uber 不同的組織和應(yīng)用程序。項目團隊專注于分級、構(gòu)建真實數(shù)據(jù)源、提高數(shù)據(jù)質(zhì)量和數(shù)據(jù) SLA，而平臺團隊則繼續(xù)改進上述以及更多的工具。雙方共同努力來改進流程，在 Uber 建立一種強大的數(shù)據(jù)文化。舉例來說，下面是一些正在進行中的工作：
對工具進行了更多的基礎(chǔ)性改進，實現(xiàn)了更多的自動化以支持不同的數(shù)據(jù)質(zhì)量檢查；實現(xiàn)了更多的集成以減少工作量
增強應(yīng)用程序日志框架，進一步捕獲更多有關(guān)用戶在應(yīng)用程序上實際“看了什么”和“做了什么”的直觀信息
改進流程和工具，改善生產(chǎn)者和消費者之間的協(xié)作
對數(shù)據(jù)資產(chǎn)實施生命周期管理，以便從系統(tǒng)中移除未使用和不必要的工件
在工程師和數(shù)據(jù)科學(xué)家的日常數(shù)據(jù)開發(fā)流程中進一步應(yīng)用上述原則
我們希望在未來走向更好的數(shù)據(jù)文化的過程中分享更多的經(jīng)驗教訓(xùn)。
Krishna Puttaswamy 是 Uber 高級工程師。他在市場團隊中處理各種數(shù)據(jù)和實驗問題。這篇博客中描述的工作，是他在應(yīng)用數(shù)據(jù)改進 Uber 應(yīng)用程序和服務(wù)時所面臨的實際問題的解決方案。他目前領(lǐng)導(dǎo) DataNG 和一個重寫實驗平臺的項目。他以前在 Airbnb 和 LinkedIn 處理過數(shù)據(jù) / 機器學(xué)習(xí)問題。
Suresh Srinivas 是一位主要致力于數(shù)據(jù)平臺的架構(gòu)師，專注于讓用戶成功地從 Uber 的數(shù)據(jù)中實現(xiàn)價值。這篇博客中描述的工作，是這一努力的一部分。在 Uber 之前，他聯(lián)合創(chuàng)建了 Hortonworks，這是一家圍繞 Apache 開源項目建立的公司，旨在將 Hadoop 生態(tài)系統(tǒng)引入企業(yè)。Suresh 是 Apache Hadoop 和相關(guān)項目的長期貢獻者，也是 Hadoop PMC 成員之一。
原文鏈接
https://eng.uber.com/ubers-journey-toward-better-data-culture-from-first-principles/
來源：AI前線
推薦閱讀:
不是你需要中臺，而是一名合格的架構(gòu)師（附各大廠中臺建設(shè)PPT）