我們需要資料湖嗎？ 資料倉儲要做什麼？

本文是我在medium上的文章的翻譯- 資料湖入門，結果很受歡迎，可能是因為它的簡單性。 因此，我決定用俄語寫，並添加一點內容，讓一個不是資料專家的普通人清楚什麼是資料倉儲（DW），什麼是資料湖（Data Lake），以及它們是如何實現的。相處起來。

我為什麼想寫有關資料湖的文章？ 我從事數據和分析工作已經有 10 多年了，現在我肯定在劍橋的 Amazon Alexa AI 從事大數據工作，該公司位於波士頓，儘管我住在溫哥華島的維多利亞，經常訪問波士頓、西雅圖，在溫哥華，有時甚至在莫斯科，我在會議上發言。 我也會時不時寫一些東西，不過我主要是用英文寫的，而且我已經寫過了 一些書，我也有分享北美的分析趨勢的需求，有時會寫在 電報.

我一直與資料倉儲打交道，從 2015 年開始，我開始與 Amazon Web Services 密切合作，並且通常轉向雲端分析（AWS、Azure、GCP）。 自 2007 年以來，我一直在觀察分析解決方案的演變，甚至曾在資料倉儲供應商 Teradata 工作，並在 Sberbank 實施該解決方案，當時大數據與 Hadoop 就出現了。 大家開始說儲存時代已經過去了，現在一切都在Hadoop上，然後他們又開始談論Data Lake，再次強調，現在資料倉儲的終結肯定已經來臨了。 但幸運的是（也許對於一些透過 Hadoop 賺了很多錢的人來說是不幸的），資料倉儲並沒有消失。

在本文中，我們將了解什麼是資料湖。 本文面向對資料倉儲經驗很少或沒有經驗的人。

圖中是布萊德湖，這是我最喜歡的湖泊之一，雖然只去過一次，但我終生難忘。 但我們將討論另一種類型的湖泊—資料湖。 也許你們中的許多人已經不只一次聽說過這個術語，但多一個定義不會傷害任何人。

首先，以下是資料湖最受歡迎的定義：

「所有類型的原始資料的檔案儲存可供組織中的任何人分析」- Martin Fowler。

「如果你認為數據集市是一瓶水——經過淨化、包裝和包裝以方便飲用，那麼數據湖就是一個自然形式的巨大水庫。 用戶，我可以為自己收集水、深入潛水、探索」- James Dixon。

現在我們確信數據湖與分析有關，它允許我們以原始形式儲存大量數據，並且我們可以對數據進行必要且方便的存取。

我經常喜歡把事情簡單化，如果我能用簡單的語言解釋一個複雜的術語，那麼我就能自己理解它是如何運作的以及它的用途。 有一天，我在 iPhone 照片庫中閒逛，突然意識到，這是一個真正的資料湖，我甚至為會議製作了一張幻燈片：

一切都很簡單。 我們用手機拍照，照片保存在手機上，並且可以保存到iCloud（雲端檔案儲存）。 手機還收集照片元資料：顯示的內容、地理標籤、時間。 結果，我們可以使用iPhone的用戶友好介面來找到我們的照片，我們甚至可以看到指示符，例如，當我搜尋帶有「火」一詞的照片時，我找到了3張帶有火圖像的照片。 對我來說，這就像一個商業智慧工具，工作非常快速且準確。

當然，我們不能忘記安全性（授權和身份驗證），否則我們的資料很容易最終進入公共領域。 有很多關於大公司和新創公司的新聞，他們的數據由於開發人員的疏忽和未能遵循簡單的規則而被公開。

即使是這樣簡單的圖片也可以幫助我們想像什麼是資料湖、它與傳統資料倉儲的區別及其主要要素：

1. 載入資料中 （攝取）是資料湖的關鍵組成部分。 資料可以透過兩種方式進入資料倉儲－批次（間隔載入）和串流（資料流）。
2. 文件存儲 （儲存）是資料湖的主要組成部分。 我們需要儲存能夠輕鬆擴充、極其可靠且成本低廉。 例如，在AWS中它是S3。
3. 目錄和搜尋 （目錄和搜尋） - 為了避免資料沼澤（這是當我們將所有資料轉儲到一堆時，然後就無法使用它），我們需要創建一個元資料層來對資料進行分類以便用戶可以輕鬆找到他們需要分析的數據。 此外，您還可以使用其他搜尋解決方案，例如 ElasticSearch。 搜尋透過用戶友好的介面幫助用戶找到所需的數據。
4. 處理 （處理）-此步驟負責處理和轉換資料。 我們可以轉換資料、改變其結構、清理資料等等。
5. 安全 （安全）- 花時間進行解決方案的安全設計非常重要。 例如，儲存、處理和載入過程中的資料加密。 使用身份驗證和授權方法很重要。 最後，需要一個稽核工具。

從實務的角度來看，我們可以透過三個屬性來表徵資料湖：

1. 收集並儲存任何東西 — 資料湖包含所有數據，包括任何時間內未處理的原始資料和已處理/清理的資料。
2. 深層掃描 — 資料湖允許使用者探索和分析資料。
3. 彈性接入 — 資料湖為不同資料、不同場景提供靈活的存取。

現在我們可以談談資料倉儲和資料湖之間的差異。 通常人們會問：

• 那麼資料倉儲呢？
• 我們是用資料湖取代資料倉儲還是對其進行擴充？
• 沒有資料湖還可以嗎？

簡而言之，沒有明確的答案。 這一切都取決於具體情況、團隊的技能和預算。 例如，將資料倉儲遷移到 Oracle 到 AWS，並由 Amazon 子公司建立資料湖 - Woot - 我們的資料湖故事：Woot.com 如何在 AWS 上建置無伺服器資料湖.

另一方面，供應商 Snowflake 表示您不再需要考慮資料湖，因為他們的資料平台（直到 2020 年它是資料倉儲）允許您將資料湖和資料倉儲結合。 我與 Snowflake 的合作不多，它確實是一款可以做到這一點的獨特產品。 發行價格是另一回事。

總之，我個人的觀點是，我們仍然需要一個資料倉儲作為我們報告的主要資料來源，任何不適合的我們都儲存在資料湖中。 分析的全部作用是為企業提供輕鬆的決策途徑。 無論人們怎麼說，業務用戶使用資料倉儲比使用資料湖更有效，例如在 Amazon 中 - 有 Redshift（分析資料倉儲）和 Redshift Spectrum/Athena（基於 S3 中的資料湖的 SQL 介面）蜂巢/急速）。 這同樣適用於其他現代分析資料倉儲。

我們來看一個典型的資料倉儲架構：

這是一個經典的解決方案。 我們有一個來源系統，使用 ETL/ELT 將資料複製到分析資料倉儲並將其連接到商業智慧解決方案（我最喜歡的是 Tableau，你的呢？）。

此方案有以下缺點：

• ETL/ELT 操作需要時間和資源。
• 通常，用於在分析資料倉儲中儲存資料的記憶體並不便宜（例如 Redshift、BigQuery、Teradata），因為我們需要購買整個叢集。
• 業務用戶可以存取經過清理且經常聚合的數據，但無法存取原始數據。

當然，這一切都取決於您的情況。 如果您的資料倉儲沒有問題，那麼您根本不需要資料湖。 但是，當出現空間、電力或價格不足等問題時，您可以考慮選擇資料湖。 這就是為什麼資料湖非常受歡迎的原因。 以下是資料湖架構的範例：

使用資料湖方法，我們將原始資料載入到資料湖（批次或串流），然後根據需要處理資料。 資料湖允許業務用戶創建自己的資料轉換（ETL/ELT）或分析商業智慧解決方案中的資料（如果有必要的驅動程式）。

任何分析解決方案的目標都是為業務用戶提供服務。 因此，我們必須始終按照業務要求開展工作。 （在亞馬遜，這是原則之一——逆向工作）。

使用資料倉儲和資料湖，我們可以比較這兩種解決方案：

可以得出的主要結論是，資料倉儲並不與資料湖競爭，而是補充。 但這取決於您來決定什麼適合您的情況。 親自嘗試並得出正確的結論總是很有趣的。

我還想告訴大家我開始使用資料湖方法時的一個案例。 一切都很瑣碎，我嘗試使用 ELT 工具（我們有 Matillion ETL）和 Amazon Redshift，我的解決方案有效，但不符合要求。

我需要獲取網絡日誌，對其進行轉換並聚合以提供兩種情況的資料：

1. 行銷團隊想要分析 SEO 的機器人活動
2. IT 想要查看網站效能指標

非常簡單，非常簡單的日誌。 這是一個例子：

https 2018-07-02T22:23:00.186641Z app/my-loadbalancer/50dc6c495c0c9188 
192.168.131.39:2817 10.0.0.1:80 0.086 0.048 0.037 200 200 0 57 
"GET https://www.example.com:443/ HTTP/1.1" "curl/7.46.0" ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 
arn:aws:elasticloadbalancing:us-east-2:123456789012:targetgroup/my-targets/73e2d6bc24d8a067
"Root=1-58337281-1d84f3d73c47ec4e58577259" "www.example.com" "arn:aws:acm:us-east-2:123456789012:certificate/12345678-1234-1234-1234-123456789012"
1 2018-07-02T22:22:48.364000Z "authenticate,forward" "-" "-"

一個檔案大小為 1-4 兆位元組。

但有一個困難。 我們在全球有 7 個域名，一天內創建了 7000 個檔案。 這體積並不算多，只有 50 GB。 但我們的 Redshift 叢集的規模也很小（4 個節點）。 以傳統方式載入一個檔案大約需要一分鐘。 也就是說，問題沒有正面解決。 當我決定使用資料湖方法時就是這種情況。 解決方案看起來像這樣：

這非常簡單（我想指出的是，在雲端工作的優點是簡單）。 我用了：

• AWS Elastic Map Reduce (Hadoop) 的運算能力
• AWS S3 作為文件存儲，具有加密資料和限制存取的能力
• Spark 作為 InMemory 運算能力，PySpark 用於邏輯和資料轉換
• Spark 帶來的 Parquet
• AWS Glue Crawler 作為新資料和分割區的元資料收集器
• Redshift Spectrum 作為現有 Redshift 使用者的資料湖 SQL 介面

最小的 EMR+Spark 叢集在 30 分鐘內處理了整個檔案堆疊。 AWS還有其他案例，特別是許多與Alexa相關的案例，其中有大量資料。

最近我了解到資料湖的缺點之一是 GDPR。 問題是，當客戶端要求刪除它並且資料位於其中一個檔案中時，我們無法像資料庫中那樣使用資料操作語言和 DELETE 操作。

我希望這篇文章能夠澄清資料倉儲和資料湖之間的差異。 如果你有興趣，我可以翻譯更多我的文章或我讀過的專業人士的文章。 並介紹我使用的解決方案及其架構。

來源： www.habr.com