資料倉儲上雲已經不是什麼新鮮概念，這裡簡單聊一聊在這個過程中需要考慮的問題。
首先，某些話題不是一兩句能說清楚，所以，這裡我們不聊以下話題：
- 技術平臺的對比。這裡我們不做任何對比分析，如不特殊說明均指Azure以及微軟相應的產品。
- 某個產品的好壞。
- 法務，合規。不同公司有不同的規定。
- 國家大事。這個我們知道就好，不在這裡聊。但是我想強調一點是，即使只搞技術，國家民族大義也是頭等大事，不然你會吃虧。
上不上雲
To be or not to be, this is a question.
首先上雲肯定是有優勢的，而且是不只技術層面的優勢。
也許有人說上雲反而更貴，這也僅僅是計算方法不同導致的而已，畢竟不會所有人都會關心伺服器的採購，供應商的溝通，以及續保等問題。
對於什麼樣的資料上雲，不同的公司有不同的規定。對於保守的公司這裡不做討論，不過目前大環境可以看到，這個趨勢被越來越多的公司所認可，也都有了相應的專案上雲，但還是會對能掌握命門的資料有所保留，而只是把相對能公開的資料上雲，比如跟銷售市場相關的。
國內 or 國外
首先要知道，國內的Azure很多功能還是缺失的，相應的團隊正在加大力度引入更多海外版的功能。所以，在做設計，以及參考微軟的文件前，要先確認相應的功能是否已經上線，比如虛擬機器自動關閉的功能，在當前這個時間節點2020年9月還沒有在國內上線。
另外不同的專案也需要參考相應的規定。比如某些資料是不允許脫離所在國家的。
PAAS or IAAS
這兩個方式各有優劣，需要根據自己的情況選擇。
PAAS的話什麼都是現成的，同時也省去了你做底層維護的困擾，但是如果你需要底層資料的支援進行故障分析或者調優的工作，會受到很多限制，比如服務沒有響應，是不是CPU超負荷導致的。
IAAS需要你從虛擬機器開始搭建，跟傳統不上雲的方式沒什麼區別，好多底層，打補丁之類的維護你需要自己考慮怎麼解決（還好微軟有現成方案）。但是獲取底層資料排查問題的時候會有更多的自由度。
如果你在範疇用IAAS的話類似打補丁的運維工作怎麼處理，那麼也大可不用擔心，Azure平臺有現成的功能，配置下就可以，平時多監控著就行了。
另外如果你的資料倉儲是基於大資料平臺構建的話，那麼推薦考慮PAAS平臺，畢竟一個叢集的搭建和管理所花的成本還是很大的。
資料聯通
這也是需要考慮的一個問題，因為你上雲了，不見得其它系統也會跟著上雲。所以當你需要獲取這些系統的資料的時候需要考慮些特殊的方式，而這些方式可能會影響到你對於大量資料的傳輸。
首先資料庫直連就不要考慮了，任何一家公司的閘道器也不會冒這個風險給你開綠燈。
那麼就需要看看所在公司層面是否提供類似的平臺，比如檔案傳輸平臺，或者是專線。
如果有現成的檔案傳輸平臺，並且能夠保證傳輸的安全，那麼就可以考慮資料從源系統匯出的方式。
如果有了現有專線，那麼可能會方便一些。但是否能保證兩邊資料庫直連，也要看各家公司網管的脾氣。如果可行的話，那麼就需要在公司層面統一規化內網IP段的使用，確保在進行互連的時候不會衝突。
當然，如果你是微軟所說的理想情況，所有其它應用都在雲端，那麼恭喜你。
資料安全
從技術層面（是的，僅僅是技術層面），資料安全需要從兩個方面去考慮。首先是資料的儲存安全。這個微軟的平臺基本都支援。其次是資料的傳輸安全，這個需要根據你用到的不同產品去具體分析，基本上要確保，即使資料倉儲的內部通訊，也要保證資料的傳輸不是明文，而是加密的，所以什麼HTTPS，SSL之類的能上都上。
網路安全
你的架構在雲上，那麼他就有可能被黑客騷擾嗎？這個是很有可能的，基本上如果你設定日誌，那麼就可以看到時不時有東西在嗅探你公開出來的埠，尤其是資料庫之類的埠。
要解決這個問題，首先，網路層面的設計可以參考各種最佳時間，比如對虛擬網路裡子網的劃分，管理層，應用層，資料層都分開。資料層不允許任何公網ip的請求，應用層通過內網ip對資料層進行訪問。只有管理層才有對應用層以及資料層的遠端許可權。
當然方法不只這一種，總體的思路基本都是，儘量縮小在公網暴露出來的埠，減少被掃描到的可能性。
資料備份
這個是上不上雲你都需要考慮的。
首先如果你不上雲，那麼你可能需要去配置單獨的作業去做備份計劃。
如果上雲的話，你也可以這麼做，但是你還有更多的選擇，比如就藉助Azure平臺的功能，這也是我推薦的。
另外有些對於儲存備份的功能，國內部分功能還沒上線，比如對於Azure Files的，這個在設計的時候需要留意。不過已經上線的功能已經能滿足你的大部分應用。
所以，如果在自己定義備份計劃指令碼和用平臺的備份功能選擇的話，我建議用平臺級功能。
災難恢復
這個要看你係統承諾的RTO以及RPO。
跟其它平臺以及虛擬化平臺一樣，Azure平臺也提供了不錯的功能，你可以通過配置指定你的災難恢復方式。比如從上海到北京。
對於RTO，雖然很少有平臺能承諾一個時間，但主流的雲廠商都會把20分鐘看成一個重要指標。如果你去測試的話基本上你的資源在這個時間範圍內也都能恢復過來。
RPO要具體去分析。對於應用層的伺服器，比如報表服務，基本不會有什麼壓力。主要是資料層的資料倉儲。雖說平臺級都是實時的資料傳輸，但是也不能保證被恢復的資料庫就是100%成功的，即使這個失敗的機率很小，那也是應該考慮的。所以對於資料倉儲伺服器，建議災難恢復以及資料庫備份都開著。
其它
對於解決方案的判斷，需要有自己的判斷，不能盲目迷信。比如對平臺市場及銷售人員，也許你只需要一個大眾，在未來一段時間換奧迪都會感覺困難，但是偏偏就會有人跟你說這個世界的車只有賓利或者保時捷。
價格方面也是很多專案關心的，還好國內平臺官網上已經提供了比較詳細的報價，只要你對相應的知識點都有了解，那麼來理解這些價格資訊是不會有什麼難度的。
賬單，這個需要儘量多的關注，避免有些你已經不用的功能還在收費，因為有些資源不是你刪除了主資源之後也會跟著刪除的。
技術上的支援，平臺方的支援也是很不錯的，如果你是訂閱使用者都有免費和收費級別的服務。對於指定問題，跟同內部的技術團隊溝通一樣，一定要讓問題儘量明確，這樣才會得到平臺方最高效的回覆。