資料庫和資料湖的關鍵概念性差異

導讀	在資料庫和資料湖的工作中，有幾個關鍵的概念性差異。在這篇文章中，讓我們來確定其中的一些差異，這些差異在第一眼看到時可能並不直觀，特別是對於具有強大關係型資料庫背景的人來說。

伺服器是一次性的。資料在雲中。

解耦儲存和計算。在談論資料湖時，這是一個典型的問題。

在傳統的資料庫系統(以及最初的基於Hadoop的資料湖)中，儲存與計算伺服器緊密結合。伺服器要麼有內建的儲存，要麼直接連線到儲存。

在現代基於雲的資料湖架構中，資料儲存和計算是獨立的。資料被儲存在雲物件儲存(例如：AWS S3、Azure Storage)中，通常是以一種開放的格式，如parquet，而計算伺服器是無狀態的，它們可以在必要時啟動/關閉。

擁有一個解耦的儲存和計算使。

1. 降低計算成本。伺服器在必要時執行。當不使用時，它們可以被關閉，從而降低了計算成本。

1. 可擴充套件性。你不必為高峰期的使用而購置硬體。伺服器/中央處理器/記憶體的數量可以根據當前的使用情況動態地增加/減少。

1. 沙盒化。相同的資料可以被多個計算伺服器/叢集同時讀取。這使得你可以讓多個團隊在不同的叢集中並行工作，讀取相同的資料，而不影響彼此。

1. RAW資料才是王道!策劃的資料只是衍生的。

在資料庫正規化中，來自源系統的資料被轉化並載入到資料庫表中後，它就不再有用了。在資料湖正規化中，RAW資料被保留為真理的源泉，最終永遠保留，因為它是真正的資產。

然而，RAW資料通常不適合商業使用者的消費，因此它要經過一個策劃過程，以提高其質量，提供結構並方便消費。經過整理的資料最終被儲存起來，供資料科學團隊、資料倉儲、報告系統以及業務使用者的一般消費使用。

典型的資料湖消費者只看到策劃過的資料，因此他們對策劃過的資料的重視程度遠遠超過產生這些資料的RAW資料。

然而，資料湖的真正資產是RAW資料(連同策展管道)，從某種意義上說，策展的資料類似於一個可以隨時重新整理的物化檢視。

主要收穫：

1. 可以在任何時候從RAW中重新建立。

1. 可以透過改進策展過程來重新建立。

1. 我們可以有多個策劃好的檢視，每個檢視都用於特定的分析。

今天做出的模式決定不會制約未來的需求

通常情況下，資訊需求會發生變化，一些原先沒有從源頭/運營系統中收集的資訊需要被分析。

在一個典型的情況下，如果原始的RAW資料沒有被儲存，歷史資料就會永遠丟失。

然而，在資料湖架構中，今天決定不把某個欄位載入到策劃的模式中，以後可以推翻，因為所有的詳細資訊都安全地儲存在資料湖的RAW區域，歷史策劃的資料可以用額外的欄位重新建立。

主要收穫：

1. 如果你現在不需要，就不要花大量的時間去建立一個通用的一刀切的策劃模式。

1. 迭代地建立一個策劃的模式，從新增你現在需要的欄位開始。

1. 當需要額外的欄位時，將它們新增到策展過程中並重新處理。

資料湖不是資料庫的替代品，每種工具都有它的優勢和致命弱點。

將資料湖用於OLTP可能是一個壞主意，就像使用資料庫來儲存數千兆位元組的非結構化資料一樣。

我希望這篇文章有助於闡明兩個系統之間的一些關鍵設計差異。

原文來自：