Criteo在大規模資料工程最佳化上經驗 - Nam

Criteo 資料包告的基礎架構
每當有廣告要向使用者展示時，Criteo 就會參與拍賣，我們會出價購買該展示可能性。這就是我們所說的投標請求。
每過一分鐘，Criteo 的 TLA（頂級應用程式）就會透過我們的 Kafka 傳送——這是一個事件流平臺，有4 億次投標請求、200 萬次顯示和大約2萬次網際網路上的點選。
所有這些數字和未處理的資料都將透過我們的資料管道進入 Criteo 資料基礎設施。

Criteo 報告管道的簡化工作流程

上圖是我們報告資料架構的最簡化版本。我們有兩個主要的儲存系統：一個是 HDFS（Hadoop 檔案系統），另一個是 Vertica。
為了在不丟失任何資訊的情況下將資料從一個系統傳輸到另一個系統，我們擁有一套可靠的內部資料編排和資料質量監控工具（檢視這個關於我們的資料排程程式的精彩系列）。這些子系統就像運轉良好的機器上的齒輪一樣工作，以提供最新的業務報告。
在這些應用程式的底層，我們使用 Scala、Python 和一點點 Java 編寫程式碼。SQL 是必須的，我們也在 Spark 應用程式中練習微調一些對資源敏感的引數。

上圖是我們所有自動化工作在記憶體和計算能力方面的預測。

右上角是我們最繁重的工作之一。要使作業完成一個執行週期，需要一個 CPU 42 天。但是由於我們的分散式系統，這項工作只執行了一個多小時。
我們的報告基礎架構並不複雜，但我們必須處理兩件事：資料增長和計算限制。
我們的資料增長並且呈指數增長。我的老經理曾經告訴我，我們的 Hadoop 資料中心有大約 230 PB 的資料。在我拿到它之前，我不知道它有多大。而且這個數字越來越大。儘管我們努力清理遺留資料，但趨勢仍然是積極的。所以我們每天都問自己的問題是：如何讓我們的大資料變得更小？

我們擁有的資料越多，我們的應用程式執行得越慢。這很快就會成為瓶頸，而我們的硬體是唯一的限制。我們可以不斷增加更多的機器，但是計算能力跟不上資料的增長速度。

我們需要針對大規模進行最佳化！

如何進行大規模資料最佳化
為了回答本文開頭提出的問題，我們需要將可用的資料及時、可靠且持續地呈現在我們的客戶面前。
資料工程不是花哨的工作。這都是汗水和繁瑣的過程。但它使整個事情繼續進行。我們很高興擁有我們的基礎設施和站點可靠性工程師。畢竟，他們為我們奠定了堅實的基礎。在該架構上，我們可以構建持久的資料管道。
但我們自己也有一套資料工程方面的最佳實踐。這些技術要麼來自多年的經驗，要麼來自某個人的專業知識。中間什麼都沒有。
這些原則幫助我們解決了大規模測量的答案。

1、資料分割槽
我們的報告渠道實際上是離線報告。這意味著我們會及時更新資料，但不是實時更新。終端使用者會期望資料可用性有一個小的延遲（這稱為延遲，但我們將在其他時間討論）。
當我們進行離線資料處理時，我們是批次進行的。每小時，每天，甚至每週。然後我們將資料儲存在相應的批處理中。這稱為資料分割槽。它有很多用途，但大多數情況下它對操作有很大幫助。
當您將資料儲存在小盒子中時，您可以透過指定盒子編號確切地知道在哪裡可以找到您的資料。如果您希望修改、替換、刪除，甚至只是除錯，那麼在資料的某個孤立部分而不是整個表上執行此操作要容易得多。

結論：分割槽資料有助於查詢執行得更快，管道更不容易出錯。

2、資料建模
當我們談論報告資料時，在 Criteo，我們總是談論兩件事：維度和指標。
指標是反映營銷活動績效的真實值。它們是點選次數、展示次數或銷售次數。維度是指標可以分解成的投影。它們是裝置環境、活動型別或產品類別。
在 Criteo，為了使維度和指標協調工作，我們採用了通用的資料建模模式。該模型由一個包含許多指標和一些鍵的事實表組成。然後我們使用這些鍵與另一組維度表進行連線。這項工作產生了一個分析儀表板，其中包含可以分解為任何可用維度的指標。

3、資料質量控制

什麼是壞資料？
答：資料錯誤、資料不完整或根本沒有資料。
如果您顯示的只是虛假資訊，那麼您的分析視覺化就沒有任何價值。我們在 Criteo 瞭解這一點，並且我們已針對質量差的資料採取了認真的措施。我們每天檢查資料的一致性和穩定性。

• 一致性反映了我們的資料在多個資料集中的同質性程度。透過將一組彙總值與定義的事實來源進行比較，我們確保我們的報告始終具有可信賴的資料。
• 穩定性反映了我們的資料不易波動的事實。我們檢查指標的聚合值是否在合理範圍內。