GoCardless提升資料質量與實施資料合約的7個關鍵經驗

上游資料質量挑戰
在上游遛彎時發現，工程師在修改服務時沒有意識到像刪除欄位這樣簡單的事情可能會對下游的儀表板（或其他消費者）產生重大影響。  
部分挑戰是資料是事後才想到的，但部分挑戰還在於我們最關鍵的資料是透過CDC，直接獲取自我們服務的資料庫。 
在載入資料後投資於程式碼和工具來轉換資料的問題在於，當資料表結構或資料Schema發生變化時，這些努力要麼失去價值，要麼需要重新設計。

所以有兩個問題需要解決。在流程方面，資料需要在上游服務更新期間成為一等公民，包括主動下游通訊。在技​​術方面，我們需要一種自助服務機制來提供容量並授權團隊定義應如何攝取資料。

幸運的是，軟體工程師很早就用API的概念解決了這個問題。這些本質上是帶有文件和版本控制的合同，允許消費者依賴服務而不用擔心它會在沒有警告的情況下更改並對他們的工作產生負面影響。

在 GoCardless，我們相信資料合約可以達到這個目的，但與任何重大計劃一樣，首先從工程團隊那裡收集需求是很重要的（也許也有一些銷售）。

與團隊交談
我們開始與公司的每個工程團隊交談。我們會解釋什麼是資料合約，讚美它們的好處，並徵求對設計的反饋。

我們得到了一些很棒的、可操作的反饋。 
例如，大多數團隊不想使用 AVRO，所以我們決定使用 JSON 作為合同的交換格式，因為它是可擴充套件的。隱私和安全團隊透過設計幫助我們建立隱私，特別是圍繞資料處理和分類哪個實體擁有哪個資料資產。

我們還發現這些團隊有廣泛的用例，並希望確保工具足夠靈活。事實上，他們真正想要的是自主權。 
在我們之前的設定中，一旦資料從 CDC 進入資料倉儲，資料工程師將擁有該資料以及支援下游服務所需的一切。當這些團隊想要授予服務訪問 BigQuery 或更改他們的資料時，他們需要透過我們。
這不僅是有用的反饋，而且成為資料合約模型的關鍵賣點。合同制定後，他們可以從一系列工具中進行選擇，而不必遵循我們對資料結構的看法，並真正控制自己的命運。

資料合同過程完全是自助的。首先是資料團隊使用Jsonnet來定義他們的模式、對資料進行分類並選擇他們的服務需求。將 Json 檔案合併到 Github 中後，會自動部署專用的BigQuery和PubSub資源，並透過 Kubernetes 叢集填充請求的資料。 

該過程旨在完全自動化和分散。這最大限度地減少了團隊之間的依賴關係，因此如果一個服務需要增加一個服務的工作人員，它不會影響另一個團隊的效能。

內部風險部門是最早使用新系統的團隊之一。他們使用不同功能的資料來識別和降低潛在欺詐行為的風險。以前，他們利用生產資料庫中的資料只是因為它在那裡。現在，他們在 BigQuery 中擁有了可直接管理的更具可擴充套件性的環境。
在撰寫本文時，我們已經進行了 6 個月的初步實施，並對勢頭和進展感到興奮。已經部署了大約 30 種不同的資料合約，它們現在為大約 60% 的非同步服務間通訊事件提供動力。 
我們與分析和資料科學團隊等傳統資料消費者合作取得了穩步進展，並計劃在明年某個時候停用我們的 CDC 管道時幫助他們遷移到該系統。
最重要的是，我們的資料質量已經開始提高，我們看到了一些很好的例子，消費者和生成者一起工作來設定資料要求——這在以前很少發生。 

學習到什麼
那麼，我們學到了什麼？

• 資料合同一旦確定就不會有太多的修改。這類方法的一個擔心是，會有大量的前期工作來定義模式，而這些模式無論如何都會改變。而ETL的好處是，資料可以被快速地重新安排和轉換，以適應這些新的需求，而我們的方法需要更多的變化管理。然而，我們發現，在我們目前的使用者群中，他們的需求並不經常變化。這是一個重要的發現，因為目前即使是一個模式的改變也需要一個新的合同，並提供一套新的基礎設施，這就造成了選擇綠地或遷移舊環境的問題。
• 讓自我服務變得簡單：舊的習慣是很難改變的，抗拒改變是人類的天性。即使你承諾提高資料質量，當涉及到資料，尤其是關鍵資料時，人們往往（可以理解為）厭惡風險。這就是我們使我們的自助服務流程儘可能簡單和自動化的原因之一。它消除了瓶頸，並提供了另一種激勵--自主權。
• 在變革時期引入資料合同。這可能是反直覺的，因為你可能認為組織一次只能消化這麼多變化。但是，當團隊需要新的資料流，而不是試圖遷移已經在生產中的服務時，我們最好的採用方式是。資料合同對於分散的資料團隊來說也是一個很好的系統，所以如果你的團隊正在追求任何型別的資料網格化倡議，這是一個理想的時間，以確保資料合同是它的一部分。
• 路演的幫助。為客戶著迷是如此重要，幾乎是老生常談。這對內部消費者來說也是如此。從其他資料工程團隊獲得反饋並瞭解他們的使用情況對於成功至關重要。另外，在他們開始與我們進行頭腦風暴的那一刻，他們就已經接受了。
• 從一開始就進行分類和治理，但要開始行動。確保我們從一開始就有正確的資料所有權和分類，可以避免很多潛在的混亂的複雜情況。雖然將不同類別和型別的初始資料合同模板放在一起，一開始可能會令人生畏，但一旦我們開始進行路演，這就變成了一個相對簡單的任務。
• Interservices是偉大的早期採用者，對迭代有幫助。擁有需要由其他服務驅動的服務的團隊是我們最大的採用者。他們對資料的可靠性、及時性和高質量的需求最大。雖然分析和資料科學消費者的進展較慢，但我們已經建立了勢頭，並透過關注早期採用者來迭代這一過程。
• 擁有正確的基礎設施。簡單地說，這是在GoCardless簽訂資料合同的正確時機。我們已經完成了一項倡議，將所有必要的基礎設施到位，我們的資料集中在BigQuery中。利用outbox模式和PubSub也很重要，可以確保我們的服務對服務的通訊得到備份，並與生產資料庫脫鉤。

權衡
沒有一種資料工程方法是不需要權衡的。在追求這個資料合同戰略的過程中，我們做了幾個深思熟慮的決定，包括。

• 速度與蔓延。我們正在密切關注這個系統的使用情況，但透過優先考慮速度和授權分散的團隊提供他們自己的基礎設施，有可能出現蔓延的情況。我們將根據需要減輕這種風險，但我們認為，與以前團隊被迫使用經常變化的生產資料的狀態相比，這是一個較小的罪惡。
• 承諾與變化。自助服務很容易，但資料合同流程和合同本身是為資料消費者設計的，以仔細考慮他們當前和未來的需求。改變合同的過程是有意為之的，以反映雙方在維護該合同方面的投資和承諾。
• 將所有權推向上游和跨領域。我們正在消除自己作為資料生成者和資料消費者之間的瓶頸和中間人。這種方法並沒有改變影響資料質量的核心事件集。實施服務仍然需要被修改，這些修改仍然會對下游產生影響。但是，改變的是這些合同已經把溝通和引導這些挑戰的責任轉移到了服務所有者身上，他們現在知道應該與哪些團隊協調哪些資料資產。