91精品国自产欧美在线观看,天干干夜夜操,日本视频一区二区三区,一级a一级a爱片免费免免高潮,日本a天堂,特色黄片网站,国产女人被躁到高潮的AV,天天撸AV

每天約有 800 萬獨立訪問者訪問 Leboncoin，到 2022 年，該網(wǎng)站每月有超過 1000 億次 HTTP 調用并且啟動和運行 700 個應用程序，使其成為訪問量最大的法國網(wǎng)站之一。

數(shù)據(jù)平臺團隊負責構建和維護平臺基礎設施以及開發(fā)內部 API，負責將 Leboncoin 的生產(chǎn)數(shù)據(jù)（大量 Kafka 事件）歸檔到所有團隊都可以訪問的非常大的數(shù)據(jù)湖中。

該解決方案在一段時間內發(fā)揮了作用，但隨后歐洲通用數(shù)據(jù)保護條例 (GDPR) 合規(guī)性成為了一個問題。法律規(guī)定，已關閉賬戶的用戶應在 3 年后被刪除，不活躍用戶應在 5 年后被刪除。由于放入湖中的數(shù)據(jù)是不可變的，因此團隊無法輕松刪除請求刪除帳戶的用戶的數(shù)據(jù)。

因此，他們決定使用 Apache Hudi 為數(shù)據(jù)湖庫構建概念驗證 (POC)，以測試這是否更適合他們的需求。

本文解釋了他們如何將 POC 轉變?yōu)樯a(chǎn)就緒的數(shù)據(jù)Lakehouse，由于數(shù)據(jù)平臺團隊和客戶之間的密切合作，該數(shù)據(jù)Lakehouse現(xiàn)已由 Leboncoin 和 Adevinta（該公司所屬的集團）的 5 個團隊使用關系管理 (CRM) 功能團隊。

為 Hudi Lakehouse 構建 POC：數(shù)據(jù)平臺團隊的為期一年的項目

適合工作的工具

為了遵守 GDPR，數(shù)據(jù)平臺團隊決定在 2022 年將舊數(shù)據(jù)湖遷移到基于開放表格式（稱為 Lakehouse）的新設計。他們可以使用三個選項，允許根據(jù)需要拍攝和刪除數(shù)據(jù)快照：Delta Lake、Apache Iceberg 和 Apache Hudi。經(jīng)過多次基準測試和測試后，團隊選擇了 Hudi。

處理速度更快

這種遷移帶來了更快、更便宜的 ETL（提取、轉換、加載）管道，因為 Hudi 自動提供適當大小的文件來解決數(shù)據(jù)湖中經(jīng)常遇到的小文件問題。由于事務查詢，表中的記錄現(xiàn)在可以更新或刪除。還提供了一些新功能，例如表索引和查詢舊表快照的能力（也稱為時間旅行功能）。

擴展數(shù)據(jù)Lakehouse的使用

由于 Lakehouse 帶來的價值，數(shù)據(jù)平臺團隊很快開始考慮將該項目用于不僅僅是存檔數(shù)據(jù)。事實上還有其他用例需要考慮。表是在數(shù)據(jù)倉庫 (Amazon Redshift) 中創(chuàng)建的，目的是刪除和更新數(shù)據(jù)，這在傳統(tǒng)數(shù)據(jù)湖中是不可能的（但現(xiàn)在在數(shù)據(jù)Lakehouse中是可能的）。數(shù)據(jù)倉庫還提供低延遲，而數(shù)據(jù)Lakehouse則能夠通過并行查詢實現(xiàn)更好的性能，且對集群大小沒有限制。

結果

Lakehouse實現(xiàn)架構

image.png

? datalake-archive，其中來自所有微服務的存儲數(shù)據(jù)按 Kafka 日期和時間分區(qū)，并使用 Apache Parquet 寫入；
? datalake-ident，根據(jù) GDPR 刪除敏感數(shù)據(jù)，并按真實事件日期和時間進行分區(qū)；
? datalake-pseudo，與 datalake-ident 相同，但個人和機密列是假名的，也按真實事件日期和時間分區(qū)。

Lakehouse新架構

在生產(chǎn)中實施 Hudi Lakehouse

第 1 階段：考慮背景

CRM 團隊當時考慮使用數(shù)據(jù)Lakehouse有兩個原因：

? 1/ 他們正在從 Adobe Campaign 版本 7 遷移到版本 8。由于他們需要構建新的數(shù)據(jù)管道來為這個新的 Adobe 實例提供數(shù)據(jù)，因此是時候考慮一種新的數(shù)據(jù)架構和模型，不再源自數(shù)據(jù)倉庫，而是直接源自數(shù)據(jù)湖，并創(chuàng)建自己的數(shù)據(jù)Lakehouse，他們預先計算了 CRM 數(shù)據(jù)管道（之前位于數(shù)據(jù)倉庫中）所需的表。數(shù)據(jù)網(wǎng)格方法被用作將 CRM 數(shù)據(jù)整合到一處并消除對其他團隊不必要的依賴。
? 2/ 消除對商業(yè)智能 (BI) 團隊維護的 Redshift 數(shù)據(jù)倉庫的依賴已經(jīng)成為一個持續(xù)的主題，該團隊在上游預先計算了許多表。

第 2 階段：與數(shù)據(jù)領導者和架構師舉辦研討會

目前還不清楚將使用哪種技術來解決 CRM 團隊的問題。因此，他們與他們所在部門的數(shù)據(jù)領導者和架構師組織了研討會，以了解市場上可用的產(chǎn)品以及其他公司正在使用的產(chǎn)品。這就是他們提出 Lakehouse 解決方案的原因，該解決方案使他們能夠將所有數(shù)據(jù)整合到一個地方并管理處理，而無需依賴其他團隊。

第 3 階段：發(fā)現(xiàn)Hudi Lakehouse POC

CRM 團隊了解到數(shù)據(jù)平臺團隊已經(jīng)在致力于使用 Hudi 開發(fā)數(shù)據(jù)Lakehouse。對于 CRM 團隊來說，加入這個項目似乎是一件好事，因為他們無法在只有 3 名數(shù)據(jù)工程師的情況下從頭開始實施一項新技術，因此他們要求加入該項目。

但故事的開始并沒有我們想象的那么順利！首先，數(shù)據(jù)平臺團隊向 CRM 團隊展示了如何使用 Hudi，并告訴他們現(xiàn)在可以創(chuàng)建自己的表。但事實證明，CRM團隊需要的一些功能還沒有實現(xiàn)。當他們回到數(shù)據(jù)平臺團隊時，他們拒絕了（因為 CRM 提出了很多要求），聲稱 CRM 團隊用例不在他們的路線圖上，并且 Hudi 數(shù)據(jù)Lakehouse項目應該仍然是 POC。

第 4 階段：與數(shù)據(jù)平臺團隊建立密切關系

CRM團隊不可能再回到對BI團隊的依賴，BI團隊也不希望他們處理數(shù)據(jù)倉庫中的數(shù)據(jù)。因此，有必要繼續(xù)推進數(shù)據(jù)Lakehouse：這是他們唯一的選擇。經(jīng)過CRM和數(shù)據(jù)平臺團隊之間的多次討論，一致認為數(shù)據(jù)平臺將幫助CRM實現(xiàn)最初尚未實現(xiàn)的Hudi新功能：例如，允許他們創(chuàng)建空表的init功能對于自我管理來說是必要的。連接和回填。此外數(shù)據(jù)平臺團隊會幫助他們調試，找出為什么表處理會從幾分鐘變成一小時，而沒有任何明顯的解釋，選擇正確的索引來獲得更好的性能。

階段5：協(xié)同支持多表

此時項目中的每個 Lakehouse 表只有一個數(shù)據(jù)源表，不允許進行轉換或聚合。經(jīng)過與 CRM 團隊幾個月的合作（該團隊擁有數(shù)據(jù)平臺團隊可以應用的用例），創(chuàng)建了數(shù)據(jù)湖庫的擴展和 Airflow 插件。新產(chǎn)品接受 SQL 查詢和描述表配置的小 YAML 文件，以自動創(chuàng)建表和 Airflow DAG（有向無環(huán)圖），其中包含計劃將數(shù)據(jù)插入表的作業(yè)。

收益

生產(chǎn)中16張表

到目前為止Hudi Lakehouse 中總共有 16 個 CRM 表（共 400 個表）正在生產(chǎn)中，這些表可以像在數(shù)據(jù)倉庫中一樣進行更新或刪除。其中分類廣告表包含4100萬條活躍行，歷史數(shù)據(jù)跨度1個月。每小時更新 10k 到 130k 行，大約需要 5 分鐘。Hudi 還用于添加、更新和刪除某些儀表板活動表中的數(shù)據(jù)。

5個不同的用戶團隊

目前超過 5 個團隊使用 Leboncoin 和 Adevinta 的 Hudi Lakehouse。由于 Airflow 插件，數(shù)據(jù)平臺團隊成員自己更喜歡使用它來創(chuàng)建表（之前他們必須使用定制的 Spark 作業(yè)和 Python 腳本來創(chuàng)建 Airflow DAG）。

未來規(guī)劃

數(shù)據(jù)平臺團隊仍在致力于該項目，以使數(shù)據(jù)Lakehouse通過以下方式發(fā)展：