深入分析數據，我們可以看到導致數據產(chǎn)品的數據流。運營(yíng)數據通常作為某種原始和非結構化數據被攝取。

在預處理步驟中，原始數據被清理并結構化為事件和實(shí)體。 事件很小、不可變且高度面向領(lǐng)域，例如OrderPurchased或ShipmentDelivered。 實(shí)體代表業(yè)務(wù)對象，例如貨物或物品，其狀態(tài)隨時(shí)間而變化。這就是為什么實(shí)體經(jīng)常被表示為一個(gè)快照列表，即歷史，最新的快照是當前狀態(tài)。

在實(shí)踐中，我們經(jīng)常會(huì )看到手動(dòng)輸入或導入的數據。例如，通過(guò)電子郵件作為 CSV 文件或業(yè)務(wù)代碼的文本描述發(fā)送的預測數據。

來(lái)自其他團隊的數據被整合為外部數據。當使用來(lái)自其他管理良好的團隊的數據產(chǎn)品時(shí)，這種集成可能會(huì )以非常輕量級的方式實(shí)現。在從遺留系統導入數據的情況下，外部區域充當反腐敗層 .

發(fā)布的數據產(chǎn)品是通過(guò)聚合事件、實(shí)體、手冊和外部數據的子集而得出的。

領(lǐng)域團隊如何將他們的運營(yíng)數據引入數據平臺？根據領(lǐng)域驅動(dòng)設計原則設計的軟件系統包含作為可變實(shí)體/聚合和不可變領(lǐng)域事件的數據。

領(lǐng)域事件非常適合被攝取到數據平臺中，因為它們代表了相關(guān)的業(yè)務(wù)事實(shí)。如果有一個(gè)消息傳遞系統，則可以通過(guò)附加一個(gè)額外的消息消費者將域事件轉發(fā)到數據平臺。數據可以實(shí)時(shí)采集、處理并轉發(fā)到數據平臺。通過(guò)這種流式攝取，數據在到達時(shí)以小批量發(fā)送，因此可立即用于分析。由于領(lǐng)域事件已經(jīng)被很好地定義，除了 PII 數據的重復數據刪除和匿名化之外，在清理和預處理方面幾乎沒(méi)有什么可做的。有時(shí)，還建議定義和攝取包含僅與分析用例相關(guān)的信息的內部分析事件，這樣就不必修改域事件。
流式攝取示例：Kafka Connect、Kafka Streams、AWS Lambda

許多業(yè)務(wù)對象作為實(shí)體和聚合保存在 SQL 或 NoSQL 數據庫中。它們的狀態(tài)會(huì )隨著(zhù)時(shí)間而變化，并且最新的狀態(tài)只保存在數據庫中。具有狀態(tài)的實(shí)體的有力候選者是文章、價(jià)格、客戶(hù)數據或裝運狀態(tài)。對于分析用例，通常需要同時(shí)擁有最新?tīng)顟B(tài)和一段時(shí)間內的狀態(tài)歷史。有幾種攝取實(shí)體的方法。一種方法是生成并發(fā)布onCreate/onUpdate/onDelete 事件每次更改實(shí)體時(shí)都使用當前狀態(tài)，例如通過(guò)添加 方面 或實(shí)體監聽(tīng)器 . 然后可以使用流式攝取來(lái)攝取上述數據。當更改操作軟件不可行時(shí)，可以使用更改數據捕獲 (CDC)直接監聽(tīng)數據庫更改并將其流式傳輸到數據平臺。
CDC 流的示例：Debezium 

最后，可以設置將數據導出到文件并將其加載到平臺中的傳統預定ELT 或 ETL 作業(yè)，其缺點(diǎn)是沒(méi)有實(shí)時(shí)數據，在導出之間沒(méi)有所有階段更改，并且需要整合導出的數據再次。但是，對于大型機等遺留系統來(lái)說(shuō)，它們是一個(gè)可行的選擇。