Uber案例|如何邁向更好的資料之旅 打造高效的資料生產力

一背景

Uber為數十億次乘車和送貨服務提供動力，連線數百萬乘客、企業、餐館、司機和快遞員，徹底改變了世界的出行方式。這個龐大的交通平臺的核心是大資料和資料科學，它為Uber所做的一切提供動力，例如更好的定價和匹配、欺詐檢測、降低預計到達時間等。每天收集和處理數PB的資料，成千上萬的使用者從這些資料中獲得見解並做出決策，以構建/改進這些產品。

二問題

雖然Uber能夠擴充套件其資料系統，但之前沒有足夠關注一些重要的資料問題，這些問題在規模化時變得更加重要。出現的一些具體問題包括：

• 資料重複：沒有某些關鍵資料和指標的真實來源，這導致重複、不一致，以及在使用哪些資料和指標時出現很多混亂。消費者必須透過進行大量盡職調查來彌補這一點，從而佔用解決業務問題的時間。使用自助服務工具建立的數十萬個資料集，沒有明顯表明哪些資料集很重要，加劇了這個問題。

• 發現問題：如果沒有豐富的後設資料和分面搜尋，在數十萬個資料集中發現資料是很困難的。糟糕的發現會導致重複的資料集、重複的工作以及不一致的答案，具體取決於用於回答問題的資料。

• 割裂連線的工具：資料流經許多工具、系統和組織。但工具沒有相互整合，導致重複工作和糟糕的開發人員體驗——例如，必須在多個工具之間複製和貼上文件和所有者資訊;開發人員無法自信地更改架構，因為下游如何使用它並不明顯。

• 日誌記錄不一致：移動裝置上的日誌記錄是手動完成的;日誌沒有一個結構來支援一種簡單且一致的方式來衡量實際使用者行為，從而導致推斷使用者行為的效率低下且錯誤。

• 缺乏流程：跨團隊缺乏資料工程流程導致了不同程度的成熟度和變化。跨團隊的資料質量和流程的定義或衡量沒有一致性。

• 缺乏所有權和SLA：資料集沒有得到適當的擁有——它們通常沒有質量保證，錯誤修復的SLA不一致，隨叫隨到，事件管理與Uber對服務的管理方式相去甚遠。

這些問題並不是Uber獨有的——根據我們與其他公司的工程師和資料科學家的訪談，這些都是常見問題，特別是對於那些發展非常快的公司來說。雖然由於故障/損壞的即時可見性，服務和服務質量往往會受到更多關注，但資料和相關工具往往處於次要地位。但修復它們並使它們達到服務工具/管理的嚴格水平在規模上變得極其重要，特別是如果資料在產品功能和創新中發揮著關鍵作用，就像Uber那樣。

三 解決方法

下圖顯示了從移動應用程式和服務到資料倉儲和最終消費介面的資料流架構圖。Uber最初的零碎反應嘗試僅在資料流中發生資料問題的點上解決問題，解決的是症狀而不是根本原因。Uber意識到需要一種整體方法來解決這些問題並端到端地解決問題。Uber的目標是重組資料記錄系統、工具和流程，以實現整個Uber資料質量的階梯式變化。Uber將整個端到端資料流堆疊的團隊聚集在一起，其中包括堆疊各個部分的工程師和資料科學家，最終修改了20多個現有系統。

為了將工作重點放在整體思考上，Uber獲取了與Rider應用程式上的行程和會話資訊相關的關鍵資料“片段”，並嘗試為它們建立事實來源(SoT)，並修復了應用程式上的日誌記錄。應用程式、處理資料的工具、資料本身以及將它們維護為SoT所需的流程。

四 從第一原則處理資料

與試圖隱藏資料並在服務外部暴露狹窄介面的服務不同，倉庫中的離線資料更多的是暴露來自相關服務和領域的資料以供一起分析。我們的一個重要認識是，為了做好這件事，我們不僅應該解決資料工具的問題，還應該解決資料的人員和流程方面的問題。因此我們提出了一些指導原則：

• 資料即程式碼：資料應被視為程式碼。資料工件的建立、棄用和關鍵更改應透過適當的書面文件進行設計審查流程，並考慮消費者的觀點。架構更改有強制稽核員，他們在更改落地之前簽字。模式重用、擴充套件優於建立新模式。資料工件有與之相關的測試，並且會持續進行測試。這些是我們通常應用於服務API的實踐，我們應該將同樣的嚴格性擴充套件到對資料的思考。

• 資料有明確所有者：資料就是程式碼，所有程式碼都必須擁有。每個資料工件都應該有明確的所有者、明確的目的，並且在其效用結束時應該被棄用。

• 資料質量是眾所周知的：資料工件必須具有資料質量SLA、錯誤SLA以及事件報告和管理，就像我們為服務所做的那樣。所有者有責任維護這些SLA。

• 提高資料生產力：資料工具的設計必須能夠最佳化生產者和消費者之間的協作，並在必要時配備強制所有者、文件和審閱者。資料工具必須與其他相關工具整合，無縫地繞過必要的後設資料。資料工具應滿足與服務相同的開發人員等級，提供在實施變更之前編寫和執行測試的能力，在投入生產之前在暫存環境中測試變更的能力，以及與現有監控/警報生態系統良好整合的能力。

• 組織級資料管理：團隊的目標應該是配備“全棧”人員，以便擁有必要的資料工程人才來從長遠角度看待資料的整個生命週期。雖然複雜的資料集可以由更集中的團隊擁有，但大多數生成資料的團隊應該以本地所有權為目標。我們應該擁有必要的培訓材料，並優先培訓工程師，使其相當熟悉基本的資料生產和消費實踐。最後，團隊領導應對他們生成和使用的資料的所有權和質量負責。

五 經驗

下面將重點介紹該計劃的一些最有用和最有趣的經驗教訓。

1.資料質量和等級

由於資料質量差，我們經歷了很多辛苦。我們已經看到過這樣的例子：實驗中不準確的測量導致大量的體力勞動，並導致驗證和糾正資料時生產力下降。事實證明，隨著大資料的廣泛使用，這個問題變得越來越普遍——IBM的一項研究和《哈佛商業評論》估計，由資料驅動的企業會因資料質量差而遭受巨大的負面影響。

為了減少繁瑣的工作和負面的業務影響，我們希望開發一種通用語言和框架來討論資料質量，以便任何人都可以以一致的期望生成或使用資料。為此，我們開發了兩個主要概念：標準資料質量檢查和資料集層的定義。

(1)資料質量

資料質量是一個複雜的主題，有許多不同的方面值得深入研究，因此我們將資料質量的討論限制在我們已經取得重大進展的領域，而忽略其他領域以供將來討論。Uber中資料生成和使用的環境對於我們選擇關注哪些資料質量領域發揮著重要作用。雖然其中一些可以轉讓給其他人，但有些則不能。資料生產者和消費者在Uber中面臨的一系列常見問題如下：如何在最新資料分析與完整資料分析之間進行權衡?鑑於我們在不同的資料中心並行執行管道，我們應該如何推理不同資料中心的資料一致性?應該對給定的資料集執行哪些語義質量檢查?我們想要選擇一組檢查來提供推理這些問題的框架。

(2)資料質量檢查

經過多次迭代，我們確定瞭如下所述的五種主要資料質量檢查型別。每個資料集都必須進行這些檢查並配置預設SLA：

• 新鮮度：資料生成與資料在目標系統中完成99.9%之間的時間延遲，包括完整性水印(預設設定為3個9)，因為簡單地最佳化新鮮度而不考慮完整性會導致質量較差的決策

• 完整性：目標系統中的行數與源系統中的行數相比的百分比

• 重複：具有重複主鍵或唯一鍵的行的百分比，在原始資料表中預設為0%重複，同時允許在建模表中存在少量重複

• 跨資料中心一致性：將當前資料中心中的資料集副本與另一個資料中心中的副本進行比較時，資料丟失的百分比

• 語義檢查：捕獲資料中欄位的關鍵屬性，例如null/not-null、唯一性、不同值的數量以及值的範圍

資料集所有者可以選擇提供不同的SLA，併為消費者提供適當的文件和推理——例如，根據資料集的性質，人們可能希望犧牲完整性來換取新鮮度。同樣，消費者可以選擇基於這些指標來使用資料集——基於完整性觸發器而不是簡單地基於時間觸發器來執行管道。

除了上述時間維度的檢查之外，我們還將繼續在跨資料集概念的一致性和異常檢測方面開展更復雜的檢查。

(3)資料集層

除了質量衡量之外，還需要有一種方法將資料集與對業務的不同重要性程度關聯起來，以便我們可以輕鬆突出顯示最重要的資料。我們已經習慣透過根據資料的業務關鍵性分配“層級”來為服務做到這一點。這些層有助於確定中斷的影響，並提供有關哪些層的資料應用於哪些目的的指南。例如，如果某些資料影響合規性、收入或品牌，則應將其標記為1級或2級。使用者為臨時探索而建立的不太重要的臨時資料集預設標記為第5層，如果不使用，可以在一段固定時間後刪除。輪胎還確定必須歸檔的事件的級別以及用於修復針對資料集建立的錯誤的SLA。分層的副產品是我們用來做出關鍵業務決策的資料資產的系統清單。此練習的另一個好處是對相似或不再作為事實來源的資料集進行顯式重複資料刪除。最後，分層帶來的可見性幫助我們重構資料集，以實現更好的建模、一致的資料粒度和標準化水平。

我們開發了自動化功能，為組織生成“分層報告”，顯示需要分層的資料集、疲勞資料的使用情況等，作為組織“資料健康狀況”的衡量標準。我們還將跟蹤這些指標作為我們“工程卓越”指標的一部分。隨著更多的採用和反饋，我們不斷迭代確切的定義和測量方法，並進一步改進它們。

(4)資料質量工具

如果我們不將它們自動化並使其易於使用和應用，那麼僅擁有這些定義是不夠的。我們將多個現有的資料質量工具整合為一個實現這些定義的工具。我們在有意義的地方自動生成測試(對於原始資料——將Kafka主題轉儲到倉庫中——我們可以自動生成四類測試，語義測試除外)，並可以使用資料集的最少輸入輕鬆建立新測試擁有者。雖然這些標準檢查為每個資料集提供了最少的測試集，但該工具的構建也足夠靈活，生產者只需提供SQL查詢即可建立新測試。我們學到了許多有趣的經驗教訓，包括如何以低開銷擴充套件這些測試、可以輕鬆為資料集構建一套測試的抽象、何時安排測試以減少誤報和噪音警報、這些測試如何應用於流資料集等。

2.資料手冊和後設資料

如前所述，Uber擁有數十萬個資料集和數千個使用者。如果我們考慮其他資料資產——報告、機器學習功能、指標、儀表板等——我們管理的資產數量甚至更大。我們希望確保：a)消費者使用正確的資料做出決策，b)生產者做出明智的決策來發展資料、優先修復錯誤等。為此，我們需要一個收集有關所有資料的後設資料的單一目錄資產並根據使用者的需求向他們提供正確的資訊。事實上，我們意識到，糟糕的發現此前曾導致生產者和消費者產生重複、冗餘的資料集，然後被丟棄的惡性迴圈。

我們希望向使用者提供有關每個資料工件(表、列、指標)的全面後設資料：

• 基本後設資料：例如文件、所有權資訊、管道、生成資料的原始碼、示例資料、沿襲和工件的層

• 使用後設資料：有關誰使用它、何時使用、流行查詢以及一起使用的工件的統計資訊

• 質量後設資料：對資料進行測試，何時執行，哪些透過，並彙總資料提供的SLA

• 成本後設資料：用於計算和儲存資料的資源，包括貨幣成本

• Bug和SLA：針對工件、事件、最近警報以及響應所有者問題的總體SLA提交的Bug

建立這個單一後設資料目錄並提供強大的UI以及上下文感知搜尋和發現對於實現生產者和消費者之間的協作、減少使用資料的麻煩以及整體提升資料質量至關重要。

為了實現這一目標，我們徹底改造了內部後設資料目錄Databook的後端和UI。我們標準化了後設資料詞彙，使向現有實體新增新的後設資料屬性變得容易，設計了可擴充套件性，以最少的入門工作輕鬆定義新的實體型別，並將我們的大多數關鍵工具整合到該系統中，並將其後設資料釋出到這個連線的中心位置各種資料資產、工具和使用者之間的點。改進後的使用者介面清晰地呈現資訊，並支援使用者更輕鬆地過濾和縮小所需資料的範圍。這些改進後，工具的使用量急劇增加。

3.應用程式上下文日誌記錄

為了瞭解和改進產品，讓我們的應用程式日誌記錄以捕獲實際的使用者體驗至關重要。我們想要衡量使用者體驗，而不是推斷使用者體驗，但每個團隊都有自定義日誌記錄方法，導致使用者體驗衡量方式不一致。我們希望標準化整個應用程式中跨團隊的日誌記錄方式，甚至“平臺化”日誌記錄，以便開發人員可以自由地減少考慮捕獲所有產品功能所需的日誌資訊，例如：向使用者顯示的內容、狀態使用者與應用程式互動時的應用程式的名稱、互動型別和互動持續時間。

在深入研究Uber構建應用程式的移動框架後，我們意識到移動應用程式開發框架已經內建了一個自然結構，可以在使用者體驗應用程式時提供有關應用程式狀態的關鍵資訊。自動捕獲RIB的層次結構將為我們提供應用程式的狀態以及哪些RIB(大致將它們視為元件)當前處於活動狀態。應用程式上的不同螢幕對映到不同的RIB層次結構。

基於這種直覺，我們開發了一個庫，可以捕獲當前的RIB層次結構，將其序列化，並自動將其附加到從應用程式觸發的每個分析事件。在接收這些訊息的後端閘道器中，我們實現了從RIB層次結構到一組靈活的後設資料(例如螢幕名稱、應用程式中的階段名稱等)的輕量級對映。該後設資料可以獨立發展，以由生產者或消費者新增更多資訊，而無需依賴移動應用程式更改(由於構建和釋出週期長達數週，因此速度緩慢且成本高昂)。在後端，除了序列化狀態之外，閘道器還會在寫入Kafka之前將此附加後設資料附加到分析事件。閘道器上的對映也可以透過API獲得，因此倉庫作業可以在對映發生變化時回填資料。

除了上述核心問題之外，我們還必須解決其他一些問題，這裡我們不會詳細介紹這些問題，例如：最佳化序列化RIB層次結構以減少分析有效負載大小，提高對映效率，保持對映正確應用程式透過自定義測試框架進行更改，將RIB樹對映到正確的狀態、標準化螢幕和狀態名稱等方面存在一些複雜的問題。

雖然這個庫並沒有完全解決我們想要解決的所有日誌記錄問題，但它確實提供了一種日誌結構，使許多分析變得更加容易，如下所述。我們正在迭代這個庫來解決概述的其他問題。

(1)乘客漏斗分析

使用上面的日誌框架生成的資料，我們能夠大大簡化對Rider行為的漏斗分析。我們在幾個小時內就構建了一個儀表板，而在過去，這需要花費幾周的時間。這些資料目前為許多實驗監控和其他儀表板提供支援，以瞭解使用者行為。

(2)公制標準化

當我們開始Data180時，我們公司有許多指標儲存庫。我們評估了這些解決方案的優缺點，並在名為uMetric的單一儲存庫上進行了標準化。事實上，它不僅僅是一個儲存庫-它具有高階功能，例如讓使用者專注於YAML格式的定義，並透過為Hive/Presto/Spark等不同查詢系統生成查詢、生成流來消除大量繁瑣的工作指標的批次管道、自動建立資料質量測試等。該系統正在得到更廣泛的採用，我們也在投資以進一步增強它。我們正在自動執行重複和接近重複的指標檢測，將該系統與Databook和其他資料消費介面整合，以便消費者可以只消費指標結果，而不是複製和執行指標的SQL(這樣更容易犯錯誤並透過以下方式重複指標)調整SQL)、改進自助服務性質以及在著陸差異之前檢測錯誤等。這種標準化幫助我們顯著減少了使用時的重複和混亂。

4.其他工具和流程變更

除了上面列出的更改之外，我們還實施了其他幾項工具和流程更改來改進我們的資料文化，簡要描述如下：

(1)共享資料模型：為了避免相同概念的模式定義重複(這種情況很常見)，我們改進了模式定義工具，以允許匯入和共享現有型別和資料模型。我們現在正在構建額外的功能和流程，以推動共享資料模型的採用，並減少重複和接近重複資料模型的建立。

移動分析強制程式碼審查者和單元測試：我們重新組織了移動分析事件的架構，並允許生產者和消費者將自己新增為強制審查者，以避免在沒有適當審查和通知的情況下推出更改。我們還構建了一個移動日誌測試框架，以確保資料測試在構建時執行。

(2)強制所有權：我們在資料生產的根本上改進了資料工具和表面(模式定義、Kafka主題建立、建立資料的管道、指標建立、儀表板建立等)，以便在我們無法自動推斷所有者時強制執行所有權資訊。所有權資訊進一步標準化為整個公司的單一服務，並跟蹤團隊和組織，而不僅僅是個人建立者。此更改消除了新的無主資料。我們進一步執行啟發式方法，將所有者分配給沒有所有者或不再在公司的所有者的“廢棄”資料集，從而使我們有望達到100%的所有權覆蓋率。

(3)跨工具整合：我們整合了工具，以便一旦在源工具中設定文件、所有權和其他關鍵後設資料，它就可以無縫地流過所有下游工具。我們將管道工具與標準警報和監控工具整合在一起，因此服務和資料管道的警報生成和管理方式保持一致。

六 展望

我們首先假設全面思考資料，考慮跨人員和系統的完整端到端資料流可以帶來更高的整體資料質量。我們相信，這項工作已顯示出支援該假設的有力證據。然而，最初的工作僅僅是我們邁向更好的資料文化轉型之旅的開始。在這項工作取得成功的基礎上，我們將此計劃在Uber上推廣到不同的組織和應用程式。專案團隊專注於分層、構建真實資料來源、提高資料質量和資料SLA，而平臺團隊則繼續改進上述工具及其他工具。雙方共同努力改進流程，在Uber建立強大的資料文化。正在進行的工作的一些例子包括：

• 對工具進行更多基礎性改進，並提高自動化程度，以支援不同的資料質量檢查;更多整合以減少勞累

• 增強應用程式日誌框架，以進一步捕獲有關使用者在應用程式上實際“看到”和“執行”的內容的更多視覺資訊

• 流程和工具改進以改善生產者和消費者之間的協作

• 強制執行資料資產的生命週期，以便從我們的系統中刪除未使用和不必要的工件

• 在工程師和資料科學家的日常資料開發工作流程中進一步採用上述原則