Zillow產生大量數據！ 我們是美國1.1億套房屋以及多戶出租房屋的信息來源。 就攝取和存儲而言，兩者都需要大量數據。 Zillow還使用外部數據源，包括來自Google Analytics（分析）的Clickstream數據。 Zestimate團隊在先前的博客文章中描述了他們如何使用數據作為事件流來加快Zestimates的計算。 這篇文章將詳細介紹我們如何開發用於處理點擊流數據的管道，克服規模問題以及如何構建可用於數據收集和處理的通用平臺。
來自數據庫的數據
Zillow最初成立時，我們使用了許多數據庫來存儲數據，並在前面使用了高速緩存以實現快速搜索和快速查找。 後來，我們將Amazon S3標準化為我們的數據湖提供商。
我們必須克服如何將數據庫中的數據放入數據湖的挑戰。 最初，我們轉而使用自定義Sqoop作業直接從表中提取數據並將其放入S3。 這解決了將數據導入S3的直接問題，但同時也引發了一些問題。
首先，由於Sqoop作業是由數據科學/工程組織的開發人員編寫的，他們不知道表的語義或它們如何適合產品。 而且他們必須不斷地跟上模式的變化。
其次，導出的數據的模式緊跟數據庫（DB）的模式，並且數據庫模式不一定針對數據科學/機器學習應用程序進行了優化。
由於Sqoop導出作業每天運行，並且有時會影響面向現場站點的數據庫，因此DBA必須創建這些數據庫的特殊只讀副本。 這需要更多的維護和開銷。 這些數據庫中的某些數據庫無法輕鬆複製，這迫使我們不得不從一日的舊數據庫快照中讀取數據。
直接寫入Data Lake
一些產品團隊編寫了將數據直接寫入S3的代碼。 儘管這使產品團隊可以直接發送數據，但這也意味著無需執行架構。 有些團隊寫了Json，而有些團隊寫了文本文件或csv文件。 文件的結構由團隊定義，並且不一致。 更改架構時，對於歷史數據進行回填的時間沒有一致的規則。
這還要求團隊創建和管理自己的AWS資源。 如果他們直接寫到S3，則需要創建適當的角色和憑據。 如果他們使用firehose寫入S3，則除了憑據之外還必須創建一個firehose流。
最後，人們並不瞭解數據的治理和生命週期策略。 例如，如果數據包含PII，則應將其加密。 否則，原始數據和處理後的數據應具有不同的生命週期策略。 通常，當團隊直接寫信給S3時，他們並不瞭解這些策略。
數據流平臺
為了解決以一致的形式將數據傳輸到數據湖的問題，我們開發了一種流媒體平臺即服務。 我們的目標是將流處理作為服務平臺構建和架構，以支持實時分析和機器學習應用程序。 該體系結構的主要原則如下：
建立流媒體基礎架構
我們標準化了使用Streams將數據發送到數據湖的過程。 團隊不瞭解流，相反，他們只是調用使用基礎流發送數據的REST API。 通過從消費者那裡提取底層技術，它使我們可以監視使用情況並根據需要擴展容量。 團隊可以在不瞭解基礎流技術的情況下發送事件和其他數據集。 團隊無需擔心流傳輸基礎架構，而專注於數據分析。 我們使用持久路由表將消息路由到正確的目的地。
為每個應用程序創建單獨的流
由於用戶不再參與底層的流技術，因此他們可以直接請求資源並開始使用它們。 這使他們可以獲取所需的儘可能多的流資源，並以所需的粒度使用它們。
生產者和消費者流分開
生產者流只能由基礎結構團隊訪問以進行數據轉換。 由於我們不知道訪問流的客戶端數量及其訪問方式。 將消費者流與生產者流分開創建是安全的。 這將確保使用者可以連接而不會影響接收消息的能力。 這也使我們能夠分別擴展消費者和生產者流，從而使我們能夠維護我們為數據傳輸設置的嚴格的服務水平協議（SLA）。
支持將數據發送到Kafka
我們正在組織內部的Kafka集群，以支持更多的低延遲和高吞吐量的用例。 此外，我們添加了對發送到Kafka主題作為目的地之一的支持。 這與架構註冊表緊密集成，以支持具有架構的消息並強制執行兼容性約束。
支持通用處理/歸檔方案
通常，當某人想要將數據發送到我們的系統時，他們也希望能夠輕鬆查詢它。 為了支持這一點，我們實現了"流處理即服務"範例，通過該範例，發送到我們系統的數據會自動存檔到Hive表中，並且可以使用Mode或Tableau查詢最終用戶（分析師和業務用戶）的數據。
數據目錄和發現
隨著我們的數據生產者和消費者的增長，需要進行分類，以便我們知道誰在以何種格式和架構生產數據。 我們還需要知道誰是消費者，以便進行數據治理，並能夠就上游數據集的問題或更改向數據消費者發出警報。 為了支持這一點，我們實現了一個可搜索的數據目錄，該目錄存儲了有關所有數據實體和相關上下文（包括數據沿襲）的當前元數據。 數據目錄還用於標記具有特殊特徵的數據集，例如個人身份（PI）數據和生命週期策略。
資料品質
需要檢查流入系統的所有數據的質量。 這可能包括架構檢查，數據完整性檢查以及度量標準值檢查。 我們實施了一項稱為Luminaire的數據質量服務，該服務結合了啟發式方法和模型來跟蹤數據集的質量。 它使用時間序列模型的集合來確保數據流符合我們的預期，否則，它將向上遊生產者發出警報。
當前用法
當前，我們有以下類型的數據流過該系統。
當前的挑戰
靜態基礎架構工具
我們在Zillow大量使用terraform來創建基礎結構。 這包括設置AWS資源（如運動和流水流），拆分EMR集群以處理數據等。使用terraform按需拆分資源對我們而言並不理想，尤其是因為資源請求來自外部團隊，並且 由於我們的數據湖帳戶具有共享性質，因此需要一些週轉。
為了解決這個問題，我們正在緩慢地移動團隊來使用Kafka主題，並且我們正在開發一個CICD管道，該管道可以自動創建主題並在架構註冊表中註冊Avro架構。 我們將在以後的博客文章中進一步描述此過程。
Kinesis客戶生態系統
Kinesis流允許每個分片限制容量，並通過添加更多分片來縮放。 為了最大程度地利用分片容量，建議使用Kinesis Producer庫（KPL）。 我們的初始部署使用KPL寫入運動學流。 但是，我們發現這不能很好地擴展，因為我們的服務正在寫入許多不同的流，並且KPL用於跟蹤每個流的分片和每個分片的消息緩衝的開銷導致我們的服務消耗了JVM堆資源，並且 死。 我們決定不花時間來進行更多的調整，而是決定編寫自己的KPL兼容庫，該庫提供了KPL的某些功能。 換句話說，我們決定權衡利用運動流分片容量的效率低下，以改善服務穩定性。
另外，由於其他方面（例如Python）對KPL的支持還不夠完善，因為它需要在側面運行本地語言守護程序。 由於這些問題，我們認為遷移到Kafka將使我們能夠提供分區的高利用率以及服務穩定性。
結論
通過創建數據流平臺，我們使團隊能夠輕鬆地將數據發送到數據湖。 現在，他們可以請求資源，而無需聯繫AWS Account管理員。 將驗證所有正在發送的數據的架構。 這將團隊向數據湖發送數據的速度從數週提高到了幾天。 它還使數據科學團隊能夠對我們的點擊流數據獲得新的見解，從而使個性化功能可以在房屋詳細信息頁面上顯示"相關房屋"。
(本文翻譯自feroze daud的文章《Building a Data Streaming Platform — How Zillow Sends Data to its Data Lake》，參考：https://medium.com/zillow-tech-hub/building-a-data-streaming-platform-how-zillow-sends-data-to-its-data-lake-821df8223ea2)
