談談資料湖和資料倉儲
資料湖是近十年來出現的一個術語,用於描述大資料世界中資料分析管道的重要組成部分 。這個想法是為組織中的任何人可能需要分析的所有原始資料建立一個單一的儲存區。人們通常使用 Hadoop 來處理湖中的資料,但這個概念比 Hadoop 更廣泛。
當提到一個單一的點可以將一個組織想要分析的所有資料集中在一起時,我立即想到了資料倉儲和資料集市的概念。但是資料湖和資料倉儲之間有一個重要的區別。資料湖以資料來源提供的任何形式儲存原始資料。沒有關於資料模式的假設,每個資料來源都可以使用它喜歡的任何模式。資料的使用者需要根據自己的目的來理解這些資料。
許多資料倉儲由於模式問題而沒有取得太大進展。資料倉儲傾向於採用單一模式的概念來滿足所有分析需求,但單一的統一資料模型對於除最小組織之外的任何組織都是不切實際的。即使要為稍微複雜的域建模,也需要多個有界上下文,每個都有自己的資料模型。在分析方面,需要每個分析使用者使用對他們正在進行的分析有意義的模型。透過轉向僅儲存原始資料,這將責任推給了資料分析師。
資料倉儲的另一個問題是確保資料質量。試圖獲得權威的單一資料來源需要對不同系統如何獲取和使用資料進行大量分析。系統 A 可能適用於某些資料,而系統 B 可能適用於其他資料。這便會遇到一些規則,系統 A 更適合最近的訂單,而系統 B 更適合一個月或更早以前的訂單,除非涉及退貨。最重要的是,資料質量往往是一個主觀問題,不同的分析對資料質量問題的容忍度不同,甚至對什麼是好質量的概念也不同。
這導致了對資料湖的批判——它只是質量參差不齊的資料的垃圾場,更確切地說是資料沼澤。批評既有道理又無關緊要。新分析的熱門標題是“資料科學家”。儘管這是一個經常被濫用的頭銜,但這些人中的許多人確實擁有紮實的科學背景。任何嚴肅的科學家都知道資料質量問題。試想一下隨時間分析溫度讀數的簡單問題,必須考慮到某些氣象站的重新定位可能會微妙地影響讀數、裝置問題導致的異常、感測器不工作時的缺失時段資料。許多複雜的統計技術都是為了解決資料質量問題而建立的。科學家總是對資料質量持懷疑態度,習慣於處理有問題的資料。所以對他們來說,湖泊很重要,因為他們可以使用原始資料,並且可以慎重地應用技術來理解它,而不是一些可能弊大於利的不透明資料清理機制。
資料倉儲通常不僅會清理資料,還會將資料聚合成一種更易於分析的形式。但科學家們也傾向於反對這一點,因為聚合意味著丟棄資料。資料湖應該包含所有資料,因為不知道人們會發現什麼有價值,無論是今天還是幾年後。
它們正在被一些月末處理報告修改。所以簡而言之,資料倉儲中的這些值是無用的;科學家擔心無法進行這種比較。經過更多挖掘,發現這些報告已被儲存,因此可以提取當時所做的真實預測。這種原始資料的複雜性意味著有空間將資料整理成更易於管理的結構以及減少相當大的資料量。不應該直接訪問資料湖。因為資料是原始資料,所以需要很多技巧才能理解它。在資料湖中工作的人相對較少,因為他們發現了湖中通常有用的資料檢視,他們可以建立許多資料集市,每個資料集市都有一個針對單個有界上下文的特定模型。然後,更多的下游使用者可以將這些集市視為該上下文的權威來源。
現在,很多時候我們已經將資料湖視為跨企業整合資料的單一點,但應該指出,這並不是它最初的意圖。這個詞是 James Dixon 在 2010 年創造的,當時他打算將資料湖用於單個資料來源,多個資料來源將形成一個“水上花園”。儘管有最初的表述,但現在普遍的用法是將資料湖視為整合了許多來源。
我們應該將資料湖用於分析目的,而不是用於業務系統之間的協作。當業務系統協作時,它們應該透過為此目的設計的服務來實現,例如 RESTful HTTP 呼叫或非同步訊息傳遞。
重要的是,所有放入湖中的資料都應該有明確的時間和地點來源。每個資料項都應該清楚地跟蹤它來自哪個系統以及何時生成資料。因此,資料湖包含歷史記錄。這可能來自將業務系統事件饋送到湖中,也可能來自定期將當前狀態轉儲到湖中的系統——當源系統沒有任何時間能力但想要對其資料進行時間分析時,這種方法很有價值。
資料湖是無模式的,由源系統決定使用什麼模式,並由消費者決定如何處理由此產生的混亂。此外,源系統可以隨意更改其流入資料模式,而消費者也必須應對。顯然,我們更希望此類更改的破壞性儘可能小,但科學家更喜歡全面的資料而不是缺失資料。
資料湖將變得非常大,並且大部分儲存都圍繞著大型無模式結構的概念——這就是為什麼 Hadoop 和 HDFS 通常是人們用於資料湖的技術。資料湖中集市的一項重要任務是減少需要處理的資料量,這樣大資料分析就不必處理大量資料。
資料湖對大量原始資料的儲存引發了有關隱私和安全的尷尬問題。資料湖對駭客來說是一個誘人的目標,他們可能喜歡把選擇的資料塊吸進公共海洋。限制小型資料科學組織直接訪問資料湖可能會減少這種威脅,但無法避免該組織如何對其獲取的資料的隱私負責的問題。
來自 “ 資料驅動智慧 ”, 原文作者:曉曉;原文連結:https://mp.weixin.qq.com/s/EVBVPqO5_rO79WaOTZRErg,如有侵權,請聯絡管理員刪除。
相關文章
- 淺談資料倉儲和大資料大資料
- 資料湖+資料倉儲 = 資料湖庫架構架構
- 萬字詳解資料倉儲、資料湖、資料中臺和湖倉一體
- 資料湖和中央資料倉儲的設計
- 談談資料倉儲架構的發展和分類架構
- 資料湖會取代資料倉儲嗎?
- 資料湖 vs 資料倉儲 vs 資料庫資料庫
- 資料倉儲被淘汰了?都怪資料湖
- 關於資料湖、資料倉儲的想法
- 資料倉儲、資料湖與湖倉一體的區別與聯絡
- 奈學:資料湖和資料倉儲的區別有哪些?
- 淺談資料倉儲質量管理流程
- 資料湖 VS 資料倉儲之爭?阿里提出大資料架構新概念:湖倉一體阿里大資料架構
- 資料網格將替代資料倉儲或資料湖?- thenewstack
- 資料湖是下一代資料倉儲?
- 通俗語言解釋資料倉儲、資料湖、資料中臺
- 資料湖是誰?那資料倉儲又算什麼?
- 談談工業企業如何將資料編織與傳統資料倉儲結合
- 資料庫和資料倉儲資料庫
- 設計資料倉儲和資料倉儲的粒度
- 讀資料湖倉02資料抽象抽象
- 讀資料湖倉06資料整合
- 資料倉儲 vs 資料湖 vs 湖倉一體:如何基於自身資料策略,選擇最合適的資料管理方案?
- 一文讀懂:本地資料湖丨資料倉儲丨雲資料湖的利與弊
- 談談資料湖分散式資料治理的資料目錄應具備的四大能力分散式
- 資料倉儲和後設資料
- 資料湖 vs 倉庫 vs 資料庫資料庫
- 讀資料湖倉01讓資料可信
- 資料倉儲、資料集市、資料湖、資料中臺到底有什麼區別?
- 一文讀懂選擇資料湖還是資料倉儲
- 有了資料湖,資料倉儲究竟能不能被取代?
- NoSQL 和資料倉儲SQL
- 談談資料資產和資料產品的異同
- 漫談“資料湖”之價值與架構架構
- 淺談G行資料湖平臺建設
- 談談如何從資料湖(Data Lake)架構轉向資料網格(Data Mesh)架構架構
- 談一談資料儲存與物聯網
- 讀資料湖倉07描述性資料