歐洲盛寶銀行如何基於資料網格實現分散式領域驅動架構的最佳實踐 - confluent

大規模分散式資料管理
資料網格是一種架構正規化，自 2019 年由 Zhamak Delgahni 首次提出以來，它逐漸受到關注。盛寶銀行如何從資料網格的關鍵原則開始，概述瞭如何處理這種架構正規化；盛寶如何開始將其變為現實；以及未來的挑戰的：

• 分散式領域驅動架構
  
  • 資料單體的對立面是分散的聯合架構，它迫使您重新考慮處理和所有權的位置。
  • 資料網格不是將資料從域流入中央擁有的資料湖或平臺，而是規定資料域應以易於使用的方式託管和服務其域資料集。
• 自助平臺設計
  
  • 正如《2020 年 DevOps 狀況報告》所述，DevOps的高速發展與自助服務功能密切相關，因為它使應用程式團隊更高效，控制得到改進，平臺團隊可以專注於持續的基礎設施改進。
  • 在這種情況下，盛寶的自助服務平臺超越了純粹的基礎設施，轉向專注於使領域團隊能夠釋出自己的資料資產並使用其他團隊釋出的資料資產。
• 資料與產品思維融合
  
  • 在盛寶，我們將資料視為一種產品，並相信產品的可用性可以直接歸因於它易於發現、理解和使用。鼓勵領域資料團隊將產品思維應用於他們提供的資料集，其嚴謹性與任何其他功能一

分散式領域驅動架構

與盛寶相關的資料域與任何其他投資銀行或經紀公司沒有什麼不同。交易等生產者對齊的領域代表業務的交易（事實），當事人等主資料集為此類域提供上下文，而風險等消費者對齊的域往往會消耗大量資料，但產生的資料很少（例如，指標）。

鑑於整個組織的變革步伐，我們知道我們不能依靠中央團隊為企業建立和填充規範資料模型。我們的方法必須擴充套件。相反，我們聯合了域資料的所有權及其表示和集中監督。
挑戰在於確保整體大於部分之和——域“網格化”並且不存在於真空中。圖 2 展示了盛寶的資料運營模式。其目的是“恰到好處”的治理允許：

• 消費者與生產者解耦（事件超過命令）
• 有待確定和商定的權威來源
• 出現並確保資訊可以在整個企業中有效使用的標準語言；這種標準或“無處不在”的語言是領域驅動設計 (DDD) 思想的核心，它是消除開發人員和領域專家之間障礙的一種手段
• 在共同的領域扮演這個重要的角色，我們期待在全國銀行使用標準化的基本概念

• 域團隊負責：
  
  • 確定資料集的權威來源
  • 建立相關資料模型
  • 透過資料結構向其他團隊提供資料產品
  • 修復資料質量 (DQ) 問題；問題應該從源頭上解決，而不是消費上
• 企業資料架構師負責：
  
  • 將我們的資料域整理和塑造成對盛寶具有長期價值的東西
  • 批准對物理域模型的更改
  • 與領域團隊合作開發概念模型
• 資料治理辦公室負責：
  
  • “啟用”資料域，包括識別所有權、已知資料質量問題等。

自助平臺設計
資料網格是一種與技術無關的架構正規化。在盛寶，我們採用 Confluent 作為我們資料結構的基礎層——資料域的權威介面，以及更傳統的請求-響應介面。
儘管 Apache Kafka 基於日誌的基礎很簡單，但將其作為企業主幹引入也並非沒有挑戰。我們的目的是讓領域團隊不必考慮部署聯結器的機制、生成語言繫結、如何處理個人身份資料等。這不是微不足道的，特別是考慮到開發平臺的廣度——主要是 C#，但我們已經在與使用 Python、C++ 和 Kotlin 的團隊合作。

我們的自助服務功能嚴重依賴GitOps，每個資料域都透過兩個儲存庫進行管理：

• 操作
  
  • 包含 ACL 的主題配置
  • Kafka聯結器的管理
  • 資料質量規則，使用遠大期望的DSL 表示
• 架構
  
  • Protobuf架構驗證和批准
  • 為所有支援的語言生成程式碼繫結併發布到我們的工件儲存庫

資料與產品思維融合
（資料）產品的可用性歸結為它可以被發現、理解和使用的難易程度。集中式架構的一個優點是在不同的資料域之間保持一致的使用者體驗要容易得多，並確保使用者能夠將他們的心智模型從一個域轉移到另一個域。我們的聯合架構需要一種完全不同的方法。
考慮到這一點，我們的自助服務平臺對如何在盛寶中使用 Kafka 採取了一些固執的觀點。標準管道確保在所有領域採用通用方法——樣式檢查、程式碼繫結的生成、資料質量規則執行/報告以及後設資料如何推送到資料工作臺等。
我們努力使資料資產具有自描述性，併力求明確表示概念。我們的信念是，透過在域內和跨域一致和有效地使用後設資料，我們可以提高資料的可用性和新資料產品的上市時間。從根本上說，我們不希望生產者資料的形狀發生顯著變化，至少在最初的情況下是這樣。小的改變可以帶來大的不同：

• 跨領域採用一致的風格指南
• 非常強調強型別（“貨幣”帶有商業含義，“字串”沒有）
• 儘可能符合行業標準
• 記錄一切
• 禁止“魔法值”
• 在源頭捕獲資訊分類
• 連結相關概念

1. 選擇訊息格式
有很多文章討論了結構化資料的不同序列化機制的優點，例如Avro 中的 Schema Evolution、Protocol Buffers 和Martin Kleppmann 的Thrift。通常，這些與模式管理和編碼效率有關。
一個經常被忽視的考慮因素是語義註釋（又名後設資料）可以輕鬆嵌入到模式中。儘管 XSD（XML 的模式定義語言）名聲不佳，但事實證明FpML等標準在全球銀行中非常成功，因為與其他情況相比，它們允許更嚴格的訊息定義水平。事實上，鑑於 FpML 的開放性，許多人已將其用作他們自己無處不在的語言的基礎。
然而，隨著 XML 不再是必需品，我們開始尋找替代品——特別是 Confluent 當前支援的那些：Avro、JSON 和 Protocol Buffers (Protobuf)。
在考慮使用 JSON 編碼的可行性時，FpML 架構師工作組指出，根本不可能在 JSON 中表達相同的不同資料型別和語言約束集。除此之外，表達十進位制值的唯一可靠方法是將其編碼為字串。此外，JSON Schema 沒有表達自定義語義註釋的方法。由於這些原因，我們沒有考慮 JSON Schema。
在這種情況下，Avro 的表現稍好一些，尤其是與 Avro 介面定義語言 (IDL) 結合使用時，它允許架構可組合性。我們可以將語義註釋表示為鬆散型別的名稱-值對，以向型別和欄位新增額外的屬性。儘管 Avro 定義了一小組原語，但該語言已擴充套件為包括許多核心邏輯型別（十進位制、UUID、日期和時間）。
Protobuf 更進一步，允許使用“自定義選項”進行強訊息型別和欄位級註釋。這使得編譯時檢查成為可能，這當然是有利的。
另一個考慮因素是語言繫結的成熟度。雖然盛寶Saxo 最初選擇了 Avro，但我們不情願地意識到這是我們推出過程中的一個主要摩擦點。C# 和 Python 實現落後於 JVM，儘管我們確實提供了一些修復（感謝 Matt Howlett 的支援），但我們認為圍繞 C# 實現的支援會讓人分心。
Protobuf 相對於 Avro 的另一個優點是，您的繫結將遵循目標語言的型別和屬性的風格規範，而不管模式中使用的命名約定如何。儘管這似乎是一個微不足道的問題，但如果沒有正確考慮，它就是另一個摩擦源。
我們最終在 2020 年底切換到 Protobuf，不久之後它就被 Confluent Schema Registry 支援為一等公民。當然，對於感興趣的語言繫結——C#、Python、C/C++，以及隨著 Kafka Streams 越來越受到關注，JVM——我們發現這些實現比 Avro 的情況更加一致。
 

2. 自描述模式
對於那些不熟悉 Protobuf 的人，請放心，如果您已經掌握了XSD的複雜性，您會發現它就像在公園裡散步一樣。
簡而言之，無論是事件還是事件引用的型別，複雜型別都表示為“訊息”。雖然語法略有不同，但“選項”（即語義註釋）可以在訊息（型別）或欄位（屬性）級別表示。有關更多詳細資訊，請參閱Proto3 語言指南。
 

3. 命名
命名很難，但使用Uber 的樣式指南可以鼓勵一致性並提供經過深思熟慮的版本控制方法。
我們還有許多您希望在任何編碼標準中看到的準則：奇異值應該有一個單數名稱，重複欄位應該有一個複數名稱，等等。
 

4. 身份標識
企業識別符號的一致使用是使這種分散式模型工作的關鍵要求之一。畢竟，考慮一下網格這個詞背後的含義：“在正確的位置連線在一起”。識別符號唯一地標識一個實體，可以被認為是域的“主鍵”，這是我們資料網格實現背後的基本原則之一。
識別符號使用 Protobuf 的 IDL 定義如下：

// This is how we pass 'Thing' by reference
message ThingIdentifier {
    int64 id = 1;
}

5. 引用
引用可以被認為是具有較弱約束的替代識別符號。例如，PaymentReference可能是客戶提供的自由格式文字欄位。下面是一個例子：

// User supplied reference. Not necessarily unique
message ThingReference {
    string ref = 1;
}

6. 列舉和schemes
許多資料元素被限制為僅包含一組有限的可能值中的一個。這種受限制的值集通常稱為列舉。
Protobuf 與許多其他語言類似，支援使用列舉型別。如果值的範圍很小（例如 < 10）並且預計不會經常變化，那麼使用enum. 然而，通常預計型別將引用外部編碼方案，一個取自 FpML的概念。
schemes在 IDL 中引用如下：

// 根據 ISO 3166 由三個字元的字母程式碼表示的貨幣
// https://www.iso.org/iso-4217-currency-codes.html
// https://spec.edmcouncil.org/fibo/ontology/FND/Accounting/CurrencyAmount/Currency
message CurrencyIdentifier {
    option (metadata.coding_scheme) = "topic://reference-currency-compact-v1";
    // Alphabetic (three letter) code
    string code = 1;
}

7. 資訊分類
盛寶定義了四種資訊分類，每一種都意味著特定的敏感度。這反映在下面所示的架構中：

// Name of a natural person
message Name {
    option (metadata.msg_info_class) = INFO_CLASS_PERSONAL;
   // 一個人的名字或名字，即為他們選擇的名字
      // 出生時或隨後由他們根據出生時的名字更改的名字
    string given_name = 1;
}

8.外部模式
儘管我們已經對 Protobuf 進行了標準化，但對於某些用例，我們支援“自帶架構”的想法。在這種情況下，必須使用以下external_schema選項顯式引用所使用的實際模式：

// An example of an external schema
message EventWithExternalSchema {
    XmlString vendor_string = 1 [(metadata.external_schema) = "https://example/third-party.xsd"];
}

9.棄用
棄用是進化的一個組成部分，它讓消費者深入瞭解您未來的重大變革計劃。棄用可以在欄位或訊息級別表示，如下所示：

// An example of a deprecated attribute
message EventWithDeprecatedField {
    // Seemed like a good idea at the time. Will be removed (or reserved) at a later date
    int32 old_field = 1 [deprecated = true];
    // Much better idea
    int64 new_field = 2;
}
 
<p class="indent">[b]10.[/b]

// 該度量是以貨幣單位指定的金額（帶有
// 貨幣單位的數字）。在推斷（即未填充）貨幣的地方，對此型別的引用
// 應明確說明價格以哪種貨幣計價。
message MonetaryAmount {
    option (metadata.term_source) = TERM_SOURCE_FIBO;
    option (metadata.term_source_ref) = "https://spec.edmcouncil.org/fibo/ontology/FND/Accounting/CurrencyAmount/MonetaryAmount";
    // 財務金額
    DecimalValue amount = 1;
    // 可選的貨幣程式碼
    CurrencyIdentifier ccy = 2;
}

11. 連結詞
當我們迭代域模型時，我們可能會無意中在不同的資料域中複製概念。無論進行多少前期設計，這都是不可避免的。與其等待重大更改，還需要一種機制，使我們能夠在不影響現有生產者或消費者的情況下引用現有概念。
我們透過field_term_link選項將領域模型中的元素連結到公認的業務術語的權威定義：

// 連結到“業務術語”
message EventWithLinkedTerm {
    // 交易貨幣
    string trade_currency = 1 [(metadata.field_term_link) = "CurrencyIdentifer"];
}

12. 測量值
這種設計的價值在於我們能夠進一步利用資料。我們怎麼知道我們走在正確的道路上？在我們的案例中，盛寶已經確定了一些我們將用來衡量實現我們願景的進展的指標：

• 網格中的連線數（斷開連線的域不太可能提供更廣泛的價值）
• 生產者：消費者比率
• 建立面向消費者的資料產品的準備時間
• 資料產品度量（例如資料質量覆蓋的趨勢）
• 測試覆蓋率（應變能力）
• 等等

未來方向
儘管盛寶已經對這些想法進行了一段時間的迭代，但直到最近，隨著我們尋求解決擴充套件挑戰，採用率才有所增長。我們的主要重點是：

• 繼續降低平臺准入門檻
• 透過例如自動對帳框架增加平臺的附加值
• 與我們在資料辦公室和整個銀行的同事合作，嵌入領域思維
• 繼續與Acryl和LinkedIn DataHub社群合作，透過以下方式使 Data Workbench 成為所有資料專業人士的一站式商店：
  
  • 以領域為中心的使用者介面
  • 域健康的遊戲化
  • 模式文件的眾包改進
  • 在使用者介面中顯示資料質量規則和結果
  • 包括所有其他上游/下游平臺
• 使團隊能夠輕鬆採用 ksqlDB 等工具