資料倉儲上雲那些事兒

2022-01-12 18:12:56 字數 2560 閱讀 9782

資料倉儲上雲已經不是什麼新鮮概念,這裡簡單聊一聊在這個過程中需要考慮的問題。

首先,某些話題不是一兩句能說清楚,所以,這裡我們不聊以下話題:

to be or not to be, this is a question.

首先上雲肯定是有優勢的,而且是不只技術層面的優勢。

也許有人說上雲反而更貴,這也僅僅是計算方法不同導致的而已,畢竟不會所有人都會關心伺服器的採購,**商的溝通,以及續保等問題。

對於什麼樣的資料上雲,不同的公司有不同的規定。對於保守的公司這裡不做討論,不過目前大環境可以看到,這個趨勢被越來越多的公司所認可,也都有了相應的專案上雲,但還是會對能掌握命門的資料有所保留,而只是把相對能公開的資料上雲,比如跟銷售市場相關的。

首先要知道,國內的azure很多功能還是缺失的,相應的團隊正在加大力度引入更多海外版的功能。所以,在做設計,以及參考微軟的文件前,要先確認相應的功能是否已經上線,比如虛擬機器自動關閉的功能,在當前這個時間節點2023年9月還沒有在國內上線。

另外不同的專案也需要參考相應的規定。比如某些資料是不允許脫離所在國家的。

這兩個方式各有優劣,需要根據自己的情況選擇。

paas的話什麼都是現成的,同時也省去了你做底層維護的困擾,但是如果你需要底層資料的支援進行故障分析或者調優的工作,會受到很多限制,比如服務沒有響應,是不是cpu超負荷導致的。

iaas需要你從虛擬機器開始搭建,跟傳統不上雲的方式沒什麼區別,好多底層,打補丁之類的維護你需要自己考慮怎麼解決(還好微軟有現成方案)。但是獲取底層資料排查問題的時候會有更多的自由度。

如果你在範疇用iaas的話類似打補丁的運維工作怎麼處理,那麼也大可不用擔心,azure平台有現成的功能,配置下就可以,平時多監控著就行了。

另外如果你的資料倉儲是基於大資料平台構建的話,那麼推薦考慮paas平台,畢竟乙個集群的搭建和管理所花的成本還是很大的。

這也是需要考慮的乙個問題,因為你上雲了,不見得其它系統也會跟著上雲。所以當你需要獲取這些系統的資料的時候需要考慮些特殊的方式,而這些方式可能會影響到你對於大量資料的傳輸。

首先資料庫直連就不要考慮了,任何一家公司的閘道器也不會冒這個風險給你開綠燈。

那麼就需要看看所在公司層面是否提供類似的平台,比如檔案傳輸平台,或者是專線。

如果有現成的檔案傳輸平台,並且能夠保證傳輸的安全,那麼就可以考慮資料從源系統匯出的方式。

如果有了現有專線,那麼可能會方便一些。但是否能保證兩邊資料庫直連,也要看各家公司網管的脾氣。如果可行的話,那麼就需要在公司層面統一規化內網ip段的使用,確保在進行互連的時候不會衝突。

當然,如果你是微軟所說的理想情況,所有其它應用都在雲端,那麼恭喜你。

從技術層面(是的,僅僅是技術層面),資料安全需要從兩個方面去考慮。首先是資料的儲存安全。這個微軟的平台基本都支援。其次是資料的傳輸安全,這個需要根據你用到的不同產品去具體分析,基本上要確保,即使資料倉儲的內部通訊,也要保證資料的傳輸不是明文,而是加密的,所以什麼https,ssl之類的能上都上。

你的架構在雲上,那麼他就有可能被黑客騷擾嗎?這個是很有可能的,基本上如果你設定日誌,那麼就可以看到時不時有東西在嗅探你公開出來的埠,尤其是資料庫之類的埠。

要解決這個問題,首先,網路層面的設計可以參考各種最佳時間,比如對虛擬網路裡子網的劃分,管理層,應用層,資料層都分開。資料層不允許任何公網ip的請求,應用層通過內網ip對資料層進行訪問。只有管理層才有對應用層以及資料層的遠端許可權。

當然方法不只這一種,總體的思路基本都是,盡量縮小在公網暴露出來的埠,減少被掃瞄到的可能性。

這個是上不上雲你都需要考慮的。

首先如果你不上雲,那麼你可能需要去配置單獨的作業去做備份計畫。

另外有些對於儲存備份的功能,國內部分功能還沒上線,比如對於azure files的,這個在設計的時候需要留意。不過已經上線的功能已經能滿足你的大部分應用。

所以,如果在自己定義備份計畫指令碼和用平台的備份功能選擇的話,我建議用平台級功能。

這個要看你系統承諾的rto以及rpo。

跟其它平台以及虛擬化平台一樣,azure平台也提供了不錯的功能,你可以通過配置指定你的災難恢復方式。比如從上海到北京。

對於rto,雖然很少有平台能承諾乙個時間,但主流的雲廠商都會把20分鐘看成乙個重要指標。如果你去測試的話基本上你的資源在這個時間範圍內也都能恢復過來。

rpo要具體去分析。對於應用層的伺服器,比如報表服務,基本不會有什麼壓力。主要是資料層的資料倉儲。雖說平台級都是實時的資料傳輸,但是也不能保證被恢復的資料庫就是100%成功的,即使這個失敗的機率很小,那也是應該考慮的。所以對於資料倉儲伺服器,建議災難恢復以及資料庫備份都開著。

對於解決方案的判斷,需要有自己的判斷,不能盲目迷信。比如對平台市場及銷售人員,也許你只需要乙個大眾,在未來一段時間換奧迪都會感覺困難,但是偏偏就會有人跟你說這個世界的車只有賓利或者保時捷。

**方面也是很多專案關心的,還好國內平台官網上已經提供了比較詳細的**,只要你對相應的知識點都有了解,那麼來理解這些**資訊是不會有什麼難度的。

賬單,這個需要盡量多的關注,避免有些你已經不用的功能還在收費,因為有些資源不是你刪除了主資源之後也會跟著刪除的。

技術上的支援,平台方的支援也是很不錯的,如果你是訂閱使用者都有免費和收費級別的服務。對於指定問題,跟同內部的技術團隊溝通一樣,一定要讓問題盡量明確,這樣才會得到平台方最高效的回覆。

資料倉儲的那些事

一,定義 1,資料倉儲是乙個面向主題的,整合的,非易失的,隨時間變化的用來支援管理人員決策的資料集合。面向主題 乙個資料倉儲的設計總是基於主題域去進行設計的,比如說是乙個生產商的主題域就分為產品,訂單,銷售商和材料單等等,那麼資料倉儲就會基於這些主題去進行資料表的分層與分類設計 整合的 資料倉儲的資...

資料倉儲 資料倉儲部署

1 首先用下面的語句查詢是否有要建立的表空間 hospdw tab 和 hospdw idx 如果沒有,則把d database zyhip改為對應的路徑,有的話直接建立使用者 select tablespace name,file name,round bytes 1024 1024 0 size...

阿里雲odps資料倉儲 雲資料倉儲的下一步是什麼

阿里雲odps資料倉儲 如果說多雲是當今資料倉儲的戰略,那麼跨雲就是它對明天的願景。這種 來自普遍需求,即跨同一雲提供商內甚至跨不同雲的不同區域無縫移動和交換資料。諸如地理位置和雲平台不相容之類的情況阻礙了全球可訪問資料的目標。結果,公司努力在整個企業 及以後 之間安全地共享資料,管理業務位置之間的...