資料倉儲架構到底選擇內部部署還是上雲?
對任何一家企業而言,建立資料倉儲都是非常必要的。隨著技術的進步,我們在這件事情上也有了很多新的選擇,比如內部部署或者基於雲。無論選擇哪種方案,最終都可以實現從資料中獲取商業智慧從而輔助決策的目的,那麼我們自然需要衡量哪種方案的價效比更高。
近兩年,傳統企業正處於數字化轉型時期,大批的系統或者工具需要更新換代,不少企業內部還殘留著傳統的、基於本地部署的資料倉儲。雖然更換為基於雲的架構需要花費一定的時間和精力,但是傳統架構其實更加複雜,需要企業IT團隊一起配置和制定規則,整個過程通常比基於雲的替代方案更加昂貴、嚴格和複雜。
相反,基於雲的資料倉儲往往更加靈活且具備更高的適應性,它們可以根據企業需求以多種方式進行配置,大部分的廠商都提供自助服務模型,並支援各種整合和附加功能,以便隨業務變化擴充套件資料分析。因此,雲資料倉儲往往更便宜、靈活且易於IT團隊管理。
當然,僅憑這些資訊,我們無法確定選擇什麼樣的架構。為了更好得了解內部部署架構與基於雲的資料倉儲的差異性,我們對其他情況進行了如下分析:
內部部署的資料倉儲架構
實際上,所有內部部署的資料倉儲都位於3-tier, 9-layer架構之上。
(對於tier和layer到底是解讀為垂直和水平還是物理和邏輯分佈,大家仁者見仁吧!)
這些層提供了收集、儲存和使用資料的一般過程。在底層,資料庫伺服器從多個來源(如財務,銷售、營銷、客戶和庫存系統)收集資料,中間層的OLAP(線上分析處理)伺服器使資料可用於分析。在頂層,使用者可以透過各種工具查詢、訪問和運算元據。
每個層都有特定的事件發生,都是動作發生層。
-
資料進入資料庫 (data source),然後提取並清理(data extraction)。
-
臨時區域進一步清理資料並在資料流入資料倉儲之前保留資料。
-
ETL過程(提取,轉換,載入)將資料從其原始狀態更改為可以透過第三方ETL工具進行分析的形式。
-
將資料載入或儲存到實際的資料倉儲(資料儲存)中。
-
應用資料邏輯,該邏輯設定了資料規則,資料顯示形式,比如顯示為表格、圖形、電子郵件、警報還是其他形式。
-
最後,後設資料和系統操作可以讓管理員瞭解資料儲存方式以及倉庫的執行模式。
對於每一層,企業IT團隊以及資料科學家必須確保系統正常執行,並保證資料安全以及經過正確處理。業務中的任何更改也將更改其收集和使用的資料,它需要手動重新配置、測試以及許多其他耗時的步驟來調整資料倉儲和相關流程。
要想維護內部部署的資料倉儲,企業內部必須具有技能和專業知識過硬的員工,同時在整個過程中還需要進行大量投資,否則,很難獲得成功。
基於雲的資料倉儲架構
雲中的資料倉儲以不同的方式構建。每個倉庫提供商都有自己獨特的結構,在多個物理伺服器、網路或軟體工具之間分配工作負載和處理資料,同時使使用者可以輕鬆訪問資料並且功能更強大。
下面介紹一些主流的雲資料倉儲是如何構建的:
-
Amazon Redshift的結構類似於傳統的資料倉儲,但它存在於雲中,透過leader節點提供資料計算叢集,該節點在所有叢集和使用者之間通訊,將查詢、資料集和應用程式分配給不同的叢集,然後將資訊和結果返回給使用者。
-
與Redshift類似,Snowflake也基於叢集體系結構構建,並作為服務提供。它將資料提取、儲存和分析整合到一個系統中,但將儲存和計算分開以實現快速擴充套件和更有效的資源利用。
-
同時,Google BigQuery使用無伺服器,資料倉儲即服務模型,整合了多個第三方工具和服務,因此使用者可以高速執行資料集上的互動式查詢。基本的體系結構是對使用者隱藏的,但基本的服務管理機器資源掃描資料列和行並返回查詢結果。
-
Microsoft Azure是一個SQL資料倉儲,它將SQL關聯式資料庫與大規模並行處理相結合,允許使用者執行復雜查詢。與其他Azure工具一起,使用者可以輕鬆地將資料儲存、傳輸和處理服務整合到自動資料管道。
由於雲資料倉儲是自助服務的,因此它們構建為使用者友好的,旨在允許使用者為現有員工定製和管理工作流程,並在需要時獲得專家幫助,這是服務的一部分。這也解釋了雲資料倉儲的初始投資和持續開支遠遠低於傳統架構的原因——企業自己無需聘請大量資料科學專家或購買和維護昂貴的硬體。
對於資料安全性要求較高的企業,可能無法放心將自己的資料交給其他雲廠商,雖然這些廠商都可以提供私有云解決方案並承諾使用者資料安全,但是企業對其的可信度或許不高,這就是內部部署方案的市場和機會。但是,隨著數字化轉型的推進,越來越多的企業開始將雲端架構傾斜。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/31077337/viewspace-2200057/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 一文讀懂選擇資料湖還是資料倉儲
- 專案管理工具,選擇本地部署還是上雲?專案管理
- 資料上雲還是本地儲存?選擇工業閘道器需要提前瞭解下
- 資料上雲,應該選擇全量抽取還是增量抽取?
- 到底什麼是實時資料倉儲?
- 構建實時資料倉儲首選,雲原生資料倉儲AnalyticDB for MySQL技術解密MySql解密
- API架構的選擇,RESTful、GraphQL還是gRPCAPI架構RESTRPC
- 資料湖+資料倉儲 = 資料湖庫架構架構
- 資料倉儲上雲那些事兒
- 資料倉儲架構分層設計架構
- 微服務架構到底應該如何選擇?微服務架構
- 資料庫內部儲存結構探索資料庫
- 資料倉儲(5)數倉Kimball與Inmon架構的對比架構
- 分層架構在資料倉儲的應用架構
- 基於雲原生架構的新一代資料倉儲平臺架構
- 如何選擇合適的雲資料庫架構與規格資料庫架構
- 企業資料儲存辦公企業雲盤是最佳選擇
- 什麼是資料倉儲
- 什麼是資料倉儲?
- 雲端資料倉儲的模式選型與建設模式
- 企業雲盤,資料儲存的必要選擇
- 資料湖 VS 資料倉儲之爭?阿里提出大資料架構新概念:湖倉一體阿里大資料架構
- 分析選擇Salesforce CRM還是Zoho CRM(上)Salesforce
- redis存json資料時選擇string還是hashRedisJSON
- 資料庫倉庫系列:(一)什麼是資料倉儲,為什麼要資料倉儲資料庫
- 深圳市教您如何選擇雲資料庫MySql的架構版本?資料庫MySql架構
- 美團DB資料同步到資料倉儲的架構與實踐架構
- 企業如何選擇合適的RPA部署架構架構
- 如何構建資料倉儲模型?模型
- 資料倉儲之大規模並行處理架構原理NY並行架構
- 部署Node應用程式選擇Heroku還是Now.sh?
- 資料倉儲 vs 資料湖 vs 湖倉一體:如何基於自身資料策略,選擇最合適的資料管理方案?
- 到底是倉庫模式好,還是MVC模式好?模式MVC
- Hive:資料倉儲構建步驟Hive
- HashData完成1500萬美元融資 加速構建雲原生資料倉儲
- 馬蜂窩資料倉儲的架構、模型與應用實踐架構模型
- GBase GCDW&阿里雲端計算巢:自動化部署雲原生資料倉儲GC阿里
- Redis 內部資料結構Redis資料結構