面向資料架構的雲演變
版權宣告:本文為半吊子子全棧工匠(wireless_com,同公眾號)原創文章,未經允許不得轉載。 https://blog.csdn.net/wireless_com/article/details/84312868
現代資料架構的概念在過去的10多年裡發生了巨大的變化,具體可以參見公眾號“補天遺石”的《從資料倉儲到資料湖——淺談資料架構演進》一文。
把時鐘調回來,回想一下那些有許多限制的遺留資料架構的日子。 儲存是昂貴的,並且有相關的硬體成本。 計算經常涉及伺服器和更多的硬體投資。 網路是昂貴的,部署只是在場內,專有軟體和硬體都鎖定在使用者所在的所有企業。
這是一個(對許多組織來說仍然是)的世界,在這個世界上,架構只允許對高度結構化資料進行事後分析。 隨著移動和感測器等新資料型別的出現,以及機器學習和資料科學等新的分析出現,這些遺留架構中的弱點就會暴露無遺。 再加上雲端計算的出現,我們將迎來一場完美的風暴。
許多相互關聯的因素打亂了遺留的資料體系結構時代。 儲存變得更加便宜,像 Apache Hadoop 這樣的軟體成為了中心舞臺。 計算也走軟體路線,我們看到了邊緣計算的開始。 網路變得無處不在,為地球提供了3G/4G/LTE連線,部署開始成為混合動力,企業開始使用開源軟體。 隨著客戶需求的改變,這導致了一股創新熱潮,影響了供應商現代化資料架構的方向。
雲的出現創造了再次進化的需要,以便利用其獨特的特性,如脫耦儲存和計算。 因此,這導致了相互連線的資料架構,Hadoop 生態系統為 IaaS 和 PaaS 模型和創新進化,用於連線資料中心和公共雲中的部署。
由於資料具有”質量”,並且是雲迅速崛起的原因,資料架構必須再次演變,以滿足當今企業的需求,並利用雲端計算的獨特優勢。 今天的資料架構需要更多的東西來實現數字轉換、實時分析和人工智慧的夢想。 這為事先分析和驅動客戶360度檢視等用例鋪平了道路。 組織需要一個統一的混合體繫結構,用於室內、多雲和邊緣環境。 現在是重新設想資料結構的時候了,混合是一個關鍵的要求。
雲模型非常適合於敏捷性開發和高效部署,並能很好地應用於臨時工作負載。 該模型提供了一種更可預測的成本結構,適用於長期執行的工作負載。 將”雲”帶到資料中,無論資料是位於本地還是雲端。
圖1 資料架構的演變
首先,理解驅動開放混合架構的關鍵原則。
統一管理(跨本地及雲)
進行資料傳輸,部署模型的選擇是由用例驅動的,可能需要多個雲供應商。 今天,他們在辦公場所做分析。 明天,他們想要探索一個執行深度學習工作負載的雲提供商。 後天,他們想把一些工作量帶回到辦公地點,以獲得更可預測的成本模式。 人們正在用一個統一的介面,幫助他們進行混合雲之旅。 資料分析師、資料工程師、資料科學家正在使用大資料環境,他們也在尋找以人為本的經驗。 希望提供一個自助服務使用者介面,以便能夠隱藏基礎設施的複雜性,讓使用者專注於業務問題。
儲存與計算的解耦選擇
從大資料、存檔資料、備份到多協議訪問使用單一統一儲存(S3 API,Hadoop API,NFS,iSCSI)。 S3介面提供了在站點和雲中應用程式的可移植性。 每個用例具有不同的計算儲存比率。 與十年前不同,網路交換機擁有10 Gbps,40 Gbps,100 Gbps 介面,對資料密集型工作負載具有更好的流量控制。 所有這些都導致計算和儲存的分離,每個層可以獨立地擴充套件。
很多更喜歡在當地儲存某個類別的應用程式,在這種情況下,保持儲存和計算在同一伺服器中的耦合是有意義的。 考慮到遺留問題,最適合提供一個儲存架構,可以擴充套件到數萬億的檔案/物件,提供強大的一致性(不像亞馬遜S3)和許多其他的物件儲存解決方案,這需要應用程式來構建一個一致性層) ,最重要的是提供了做耦合和去耦合計算和儲存的選項。
容器化
大多數使用者希望封裝隔離和多租賃在一個易於使用的介面。 自定義的容器化應用程式可以應用到叢集,能夠進入下一個層次——整合自己的元件,如企業資料倉儲(EDW)、資料科學和工程平臺等。 有很多好處。 在雲環境中,可以在幾分鐘內建立一個按需工作的負載。 在過去,這個過程需要與伺服器管理員進行數月的協調,然後建立一個新的叢集。 這是雲敏捷性的前提,並允許簡化到一個共同的體系結構,這樣 EDW 解決方案就可以在不需要任何架構檢修的情況下執行在前臺和雲端。
共享安全和治理
可以使用像雲一樣的敏捷性部署容器化工作負載,需要一個共享和持久的安全和治理層來集中執行訪問控制和資料治理。 由於資料是通過 Hadoop 檔案系統和雲物件儲存分佈的,希望有一個共同的安全和治理控制。 當資料環境擴充套件到數百億的檔案和整個組織的共享時,需要有部門級別的安全領域——考慮一個具有自身安全和治理控制的”邏輯”資料湖。
負載敏捷性
這是開放式混合體繫結構的終極聖盃。 資料環境的存在,以便各種處理工作負載能夠執行,從噪聲中獲得洞察力或訊號,使用者可以在他們的組織得到真正的業務轉換。 許多工作負載,如 EDW,資料科學和工程平臺有不同的釋出節奏。這種架構能夠輕鬆地改變獨立於底層基礎設施的元件的軟體修改,避免一個龐大的升級,可以為大資料環境中的數以千計的租戶提供一個自我服務角色為中心的使用者介面來建立按需工作負載。
所有這些都導致了雲和本地一致的混合架構設計。
圖2 開放式混合架構
資料中心可以有多個環境或單一的環境。 一個環境包括儲存、計算、安全和治理服務以及操作服務(日誌、度量)。 用 戶可以擁有一個100個節點的環境,儲存和計算在同一伺服器中被耦合在一起,從資料本地化中獲益。 或者,使用者可以在一個儲存環境中投入50個節點和在一個計算環境中投50個節點,以便儲存環境和計算環境能夠獨立地擴充套件。 儲存環境規模達到數百億個檔案,而計算環境提供了容器化的體系結構來執行工作負載。
圖3 開放混合架構的高層視角
使用者可以擁有多個部門,分享環境,同時擁有自己的安全和治理控制元件,不讓他們的資料集相互可見(例如垂直的醫療保健)。 可能有使用者希望加入跨部門的資料集,在這種情況下,他們可以只有一個資料湖對映到一個單一的環境中。
在一個部門裡可能有成百上千的租戶需要解決一個商業問題並且需要一個工作量(比如 EDW,資料科學)。 管理員或部門級的架構師可以為資料集提供訪問控制,並使用容器在計算環境中為租戶建立一個工作負載。 現在,租戶可以訪問以人為中心的使用者介面來訪問資料集並解決他/她的業務問題。 所有的使用者介面和工作負載都可以通過開放混合架構完成。
參考資料:
https://hortonworks.com/blog/open-hybrid-architecture-bringing-cloud-native-to-on-premises/
https://hortonworks.com/blog/bringing-cloud-native-architecture-to-big-data-in-the-data-center/
相關文章
- 面向資料的架構架構
- 分散式資料庫的架構演變之路分散式資料庫架構
- 故事篇:資料庫架構演變之路資料庫架構
- 資料治理實踐:後設資料管理架構的演變架構
- 面向資料的架構DOA - eyassh架構
- 架構設計之架構的演變架構
- 資料治理:資料整合架構的演進架構
- 系統架構演變架構
- Fabric架構演變之路架構
- MyCat 啟蒙:分散式系統的資料庫架構演變分散式資料庫架構
- 雲資料庫時代:企業資料架構的雲化智慧重構和變革資料庫架構
- 新一代雲資料平臺架構演進之路架構
- 如何構建面向使用者的資料分析架構架構
- 雲端計算時代,資料中心架構三層到大二層的演變架構
- MySQL資料庫架構——高可用演進MySql資料庫架構
- 淺談網路架構及其演變架構
- SACC2022-酷克資料 牛雲飛:從分析視角的變化看銀行業資料平臺架構演進行業架構
- 面向服務的架構架構
- 如何構建零信任的雲資料架構架構
- Alluxio創始成員範斌:AI與開源背景下資料架構的演變UXAI架構
- 高併發下的伺服器架構演變伺服器架構
- Apache Druid 在 Shopee 的雲原生架構演進ApacheUI架構
- 資料基礎架構如何演進,西部資料有話說架構
- Java後端中的資料版本控制:如何管理資料結構的演變Java後端資料結構
- FunData — 電競大資料系統架構演進大資料架構
- DTCC演講 | PolarDB-X技術架構:雲原生分散式資料庫架構分散式資料庫
- 系統架構都經歷了怎樣的演變?架構
- Airbnb的架構演進AI架構
- Serverless 架構的演進Server架構
- 京東物流資料同步平臺“資料蜂巢”架構演進之路架構
- 雲原生架構下的微服務選型和演進架構微服務
- 高效能、高可用平臺架構演變史架構
- 架構演進之「微服務架構」架構微服務
- 面向架構程式設計架構程式設計
- 架構的演進, 阿里資深Java工程師表述架構的腐化之謎架構阿里Java工程師
- 架構的演進,阿里資深Java工程師表述架構的腐化之謎架構阿里Java工程師
- 雲端計算時代,資料庫架構設計有哪些改變?資料庫架構
- 今日頭條架構演進之路——高壓下的架構演進專題架構