保險業(yè)海量非結(jié)構(gòu)化數(shù)據(jù)的存儲選型、遷移、備份等難點解讀

一、保險業(yè)非結(jié)構(gòu)化數(shù)據(jù)現(xiàn)狀

1、NAS 存儲擴容問題

【問題詳述】我們現(xiàn)在用的 netapp 的 nas 存儲，總的空間是 40T ，空間已經(jīng)接近分配完，但整個存儲空間使用才 50% （都是以 NFS 的形式分配給不同的業(yè)務(wù)）。現(xiàn)在再有新業(yè)務(wù)新需求了，沒有空間可以分配了，這種問題咨詢了廠家，說是收縮卷的空間可能不好操作。所以我們面臨著 NAS 擴容的問題。問題來了，領(lǐng)導覺得我們的擴容不能被 NETAPP 品牌綁架，問下各位專家，有已購擴容的方法或者案例嗎？

@Jerry 某保險公司 信息技術(shù)高級主管：

NAS 品牌擴容能不能不被品牌綁架？幾乎不可能，暫且不論能不能混用其他品牌擴容柜，就算能混用，敢不敢混用都是一個問題，出了事誰承擔？傳統(tǒng) NAS 除了擴容就是購買其他品牌的設(shè)備了，沒法在一個品牌的機頭上混用另一個品牌的擴容柜。收縮卷的操作都是高危敏感操作，極容易出問題，不要輕易嘗試。

@王國明 戴爾科技集團 高級系統(tǒng)工程師：

傳統(tǒng)的 NAS 一定會面臨擴充的難題，特別是在現(xiàn)階段大家數(shù)據(jù)飛漲的階段。建議你對你的應(yīng)用進行評估，看是否選擇基于分布式的數(shù)據(jù)湖技術(shù)，從而一勞永逸。給你帶來的優(yōu)勢主要有：

1 、方便擴充，容量和性能線性擴充；

2 、方便擴充節(jié)點（ 60 秒）；

3 、以后不再需要數(shù)據(jù)遷移， 這一次遷移數(shù)據(jù)你可以選擇基于快照的方式遷移，速度還可以；

4 、其它的優(yōu)點，比如可以隨時調(diào)節(jié)容錯級別，新協(xié)議支持等等。

2、能否具體談?wù)?NAS 存儲的瓶頸？

【問題詳述】對于影像、保單等產(chǎn)生大量非結(jié)構(gòu)化數(shù)據(jù)的業(yè)務(wù)系統(tǒng)來說，有沒有經(jīng)驗或者數(shù)據(jù)可以參考， NAS 文件數(shù)量或存儲容量在怎樣的數(shù)量級， NAS 存儲可能會出現(xiàn)明顯的瓶頸？

@Jerry 某保險公司 信息技術(shù)高級主管：

1 ，性能瓶頸， NAS 機頭的瓶頸始終有限，擴容柜能持續(xù)擴容， NAS 機頭不行。

2 ， NAS 底層文件系統(tǒng)的限制，最常見的就是單目錄下文件數(shù)量超過限制了，同時文件數(shù)量增大到一定量級，讀寫效率明顯降低。 

3 ，備份問題，也是受限于機頭和備份方式，再就是 NAS 文件系統(tǒng)的訪問機制，整體效率特別低。

對于傳統(tǒng) NAS 存儲，主要看底層文件系統(tǒng)的單目錄下最大文件數(shù)限制，尤其是影像、打印這類系統(tǒng)，一旦共享目錄下文件數(shù)接近或者超過最大文件數(shù)限制，訪問效率明顯下降。其次，非結(jié)構(gòu)化數(shù)據(jù)的規(guī)模和體積會對 NAS 性能有明顯影響，同是同一文件數(shù)量規(guī)模的影像件類和打印報文結(jié)果類非結(jié)構(gòu)化數(shù)據(jù)，打印報文結(jié)果訪問效率更低。

@白光茁 戴爾科技集團 高級系統(tǒng)工程師：

一般情況下，我這邊的經(jīng)驗是百萬量級的文件。但是具體還是要看企業(yè)內(nèi)部對未來 IT 技術(shù)路線的看法和企業(yè)的實際情況。從目前市面上成熟的存儲技術(shù)來看，在海量非結(jié)構(gòu)化數(shù)據(jù)的長久保存這個場景，基本上就是對象存儲這個選擇，因為不管文件是幾萬量級，還是幾十億量級，都能夠很好的處理。在實際項目中，有的企業(yè)會優(yōu)先選擇解決當下碰到的問題，有的企業(yè)會考慮未來幾年的架構(gòu)的合理性，不同企業(yè)在進行技術(shù)選型的時候考量點不太一樣，這個會導致技術(shù)路線的選擇也不一樣。用對象存儲畢竟要涉及到應(yīng)用訪問接口的改造，有的企業(yè)在接口改造上困難很大，導致不得已繼續(xù)使用 NAS 。我自己就碰到過有的企業(yè)的軟件開發(fā)商破產(chǎn)，導致無法升級改造的事情。

@王國明 戴爾科技集團 高級系統(tǒng)工程師：

NAS ，或者說傳統(tǒng) NAS 有很多局限，這也是分布式系統(tǒng)在創(chuàng)建之時就有的追求，目的在于解決傳統(tǒng) NAS 的這些問題：

1 、性能依賴控制器，控制器會造成性能瓶頸，不能做大規(guī)模的并發(fā)負載分擔；

2 、傳統(tǒng)的容錯方式會導致更低的使用效率以及極不靈活的容錯方式，而且系統(tǒng)故障重建時間極難控制；

3 、多協(xié)議支持是硬傷，數(shù)據(jù)湖的訪問方式才是符合大數(shù)據(jù)模式的，太多的數(shù)據(jù)遷移和復制會由于數(shù)據(jù)的規(guī)模越來越大變得不可操作。

3、非結(jié)構(gòu)化數(shù)據(jù)備份策略及備份存儲？

【問題詳述】非結(jié)構(gòu)化數(shù)據(jù)具有文件多且容量大的特點，無論是NAS還是對象存儲，在數(shù)據(jù)備份策略和備份存儲方面有沒有合適的方案和經(jīng)驗可以參考？

@白光茁 戴爾科技集團 高級系統(tǒng)工程師：

主流的對象存儲都是能夠提供免備份功能的。一般對象存儲都是分布式的架構(gòu)，物理部件的故障不會影響的系統(tǒng)的運行，也可以通過跨站點復制實現(xiàn)站點級容災(zāi)。在邏輯保護方面，通過多版本功能可以實現(xiàn)誤修改、誤刪除數(shù)據(jù)的恢復，也可以通過 WORM 功能來保證數(shù)據(jù)不會被惡意刪除。

@cpc1989 某保險公司 存儲工程師：

從個人運維經(jīng)驗來看，拋開存儲系統(tǒng)本身存在的不可控因素，數(shù)據(jù)丟失也往往會發(fā)生在日常運維事件中，對象存儲也不例外，免備份并沒想象中可靠，可能并不適合于重要數(shù)據(jù)場景。

@白光茁 戴爾科技集團 高級系統(tǒng)工程師：

同意樓上，但是在做方案的時候，畢竟還是要考慮成本、運維等很多層面，對象存儲主要面臨的場景還是海量非結(jié)構(gòu)化數(shù)據(jù)的存儲。備份的基本邏輯就是把數(shù)據(jù)保留多份，所以我們面臨的問題就是使用什么系統(tǒng)把海量的非結(jié)構(gòu)化數(shù)據(jù)再保存一份甚至多份，而且還要考慮隨著系統(tǒng)的增多，對運維管理和構(gòu)建成本帶來的提升，以及更多的故障點。當然如果數(shù)據(jù)量小的情況下，這些問題其實就不是很嚴重。

@王國明 戴爾科技集團 高級系統(tǒng)工程師：

非結(jié)構(gòu)化數(shù)據(jù)同結(jié)構(gòu)化數(shù)據(jù)一樣，可按照不同的需求，實現(xiàn)多種方式的備份。而唯一不一樣的，只有大數(shù)據(jù)，或者說海量的非結(jié)構(gòu)化數(shù)據(jù)，由于數(shù)據(jù)量的巨大，不能用傳統(tǒng)的備份方式來處理，這時候我們會建議采用歷史數(shù)據(jù)歸檔替代傳統(tǒng)的備份，一方面保證數(shù)據(jù)保護的時間窗，同時確保數(shù)據(jù)的回溯訪問時間。

4、保險影像系統(tǒng)中存儲的大量非結(jié)構(gòu)化數(shù)據(jù)有無快速有效的備份方案？

【問題詳述】對于保險影像系統(tǒng)中存儲的大量非結(jié)構(gòu)化數(shù)據(jù)有無快速有效的備份方案，可以應(yīng)對在線數(shù)據(jù)誤刪除、惡意刪除、中病毒被篡改等問題？

@Jerry 某保險公司 信息技術(shù)高級主管：

對于影像 / 單證 / 打印類數(shù)據(jù)的快速備份問題，現(xiàn)在沒有一勞永逸的解決方案，這也是全行業(yè)面臨的數(shù)據(jù)保護難題。在此分享點經(jīng)驗僅供參考：

傳統(tǒng) NAS 存儲備份，傳統(tǒng)備份效率受制于兩個方面，一個是文件讀取 IO 的時間，由于數(shù)據(jù)量大，時間被橫向拉長。對于這點的優(yōu)化，可以考慮增加 NAS 文件的備份節(jié)點，每個節(jié)點掃描特定范圍的共享目錄，同時并行掃描將節(jié)省大量時間，但備份節(jié)點和掃描線程數(shù)并不是越多越好，根據(jù)實際測試結(jié)果調(diào)整；二個是受制于 NAS 機頭性能，硬件素質(zhì)決定無法優(yōu)化。如果是分布式 NAS ，速度會更有優(yōu)勢。傳統(tǒng)單雙機頭 NAS 則沒有很好的辦法。

對象存儲備份和恢復則很依賴對象存儲的接口和協(xié)議，業(yè)務(wù)條件允許的話，建議做好冷熱分離和數(shù)據(jù)的歸檔。

@dawey 某大型券商 技術(shù)經(jīng)理：

在海量文件環(huán)境下，傳統(tǒng)的數(shù)據(jù)備份方案無法有效備份，對象存儲采用多副本的方式進行邏輯故障防護。與傳統(tǒng)文件存儲相比，對象存儲在海量非結(jié)構(gòu)化數(shù)據(jù)長久保存場景下有著獨特的優(yōu)勢。

@白光茁 戴爾科技集團 高級系統(tǒng)工程師：

如果底層的存儲技術(shù)是對象存儲的話，可以通過多版本的方式來實現(xiàn)數(shù)據(jù)防誤刪除，或者也可以通過 WORM 的功能來防止誤刪除和惡意刪除。在病毒預(yù)防方面，對象存儲在存儲文件的時候是打散到不同物理節(jié)點來存放的，所以病毒文件無法感染同一存儲內(nèi)的其他文件，因此也可以有效的進行防病毒。

@王國明 戴爾科技集團 高級系統(tǒng)工程師：

備份，換句話說，數(shù)據(jù)的安全以及歷史數(shù)據(jù)的可訪問，不管是不是海量，都需要考慮。由于數(shù)據(jù)的海量，會讓一些傳統(tǒng)的方式無法完成，而需要做出調(diào)整。一般說來，我們建議采用歷史數(shù)據(jù)歸檔方式實現(xiàn)數(shù)據(jù)備份，傳統(tǒng)的備份，會涉及到數(shù)據(jù)的封裝，對于海量的數(shù)據(jù)會有性能和數(shù)據(jù)可訪問性方面的難題，只會用在滿足特定需求的數(shù)據(jù)保護上。而采用包括快照、多副本、同步容錯、 NDMP 備份多種方式方式來滿足不同的 RPO/RTO 要求。

5、租賃云對象存儲用于存儲影像文件，是否需要本地備份？ 

【問題詳述】被問到一個問題，如果選擇租賃公有云的對象存儲，用于存儲影像文件，是否需要本地備份？當時是忽悠過去了，想聽聽各位大拿的意見和建議。

@dawey 某大型券商 技術(shù)經(jīng)理：

曾有某創(chuàng)業(yè)公司怒懟某云，稱其放在該云服務(wù)器上的數(shù)據(jù)全部丟失，給其公司業(yè)務(wù)帶來災(zāi)難性損失。由此可見，一定需要進行本地備份，數(shù)據(jù)備份是最后手段，設(shè)備壞了可以換，數(shù)據(jù)丟了對公司來說是災(zāi)難性的。

@白光茁 戴爾科技集團 高級系統(tǒng)工程師：

從數(shù)據(jù)安全的角度，建議還是本地有一份備份，更為安全妥當。另外從保證業(yè)務(wù)連續(xù)性的角度，建議應(yīng)用也在本地有部署。

@王國明 戴爾科技集團 高級系統(tǒng)工程師：

取決于你的數(shù)據(jù)重要性，如果這個數(shù)據(jù)不能丟，不管你的租賃方給你講他們有多可靠，你也需要有本地備份。同時，還需要考慮數(shù)據(jù)恢復的效率問題以及數(shù)據(jù)取回的成本問題。

二、非結(jié)構(gòu)化數(shù)據(jù)方案選擇

1、對象存儲或 MPP 相對于 NAS ，其成本與收益是否平衡？

【問題詳述】非結(jié)構(gòu)化數(shù)據(jù)遷移至對象存儲或 MPP 系統(tǒng)后，此類數(shù)據(jù)的備份、恢復以及持久化保留相對于在傳統(tǒng)存儲上是否明顯改善？主要收益如何？

@白光茁 戴爾科技集團 高級系統(tǒng)工程師：

對象存儲主要面向的是海量非結(jié)構(gòu)化數(shù)據(jù)的管理，由于數(shù)量量大，導致的備份、恢復問題以及長久保存導致的數(shù)據(jù)安全性問題，對象存儲都能夠解決。相對于傳統(tǒng)存儲而言，數(shù)據(jù)量越大，對象存儲的優(yōu)勢體現(xiàn)的越明顯。從某些層面講，對對象存儲而言，管理 1PB 的數(shù)據(jù)，需要 1 個人就夠了，當數(shù)據(jù)量增長到了 100PB ， 1 個人也能夠管理。

@王國明 戴爾科技集團 高級系統(tǒng)工程師：

這是一個比較寬泛的問題，具體情況還是需要具體分析。傳統(tǒng) NAS 存在的局限主要包括：不支持更多的協(xié)議、容錯不靈活、擴展不方便、元數(shù)據(jù)無優(yōu)化等等，而這些是分布式解決方案的優(yōu)勢，再加上不需要數(shù)據(jù)復制而支持就地分析的優(yōu)勢，很多時候分布式是唯一的解決方案。而傳統(tǒng) NAS 的單流性能的優(yōu)勢，對于分布式或并行解決方案，需要采用閃存來提速，目前還會帶來一定的成本上的提升。

2、對象存儲，自建還是租用云上的更合適？

【問題詳述】保險公司對于非結(jié)構(gòu)化數(shù)據(jù)，考慮采用分布式對象存儲，可以考慮本地自建，或者租用云上的（例如阿里云的）對象存儲，請問從成本和安全性、性能等方面考慮，如何做出比較科學的選擇呢？

@dawey 某大型券商 技術(shù)經(jīng)理：

金融行業(yè)一般考慮的順序是安全性（監(jiān)管要求）、性能、成本。如果存儲的文件涉及敏感信息的，租用公有云肯定是不合規(guī)的。

對于性能，自建和租用都不是問題，要求性能越高，投入也就越大，這是成正比的。成本沒有對比過。

@Jerry 某保險公司 信息技術(shù)高級主管：

云的話，初始成本低，可以按需購買，但無法符合金融行業(yè)的合規(guī)性要求，其次是上云容易下云難。

自建的話，初始成本高，且需要運維能力，輕松應(yīng)對監(jiān)管要求，能夠?qū)崿F(xiàn)一定的自主控制。各有利弊，看公司運營要求決定。從長久使用來看，自建和云綜合成本不會有天差地別。

@crasy xbo 網(wǎng)絡(luò)工程師：

拋開金融行業(yè)的合規(guī)性要求。保險且經(jīng)濟的做法是：

1 、本地自建 公有云，都使用。

2 、使用主要以公有云為主，自建以備份為主，可不用太過考慮性能，公有云異常，能撐起業(yè)務(wù)即可。

3 、不管云還是自建，都建議自己搭建對象存儲集群，可控性上的保障會比用公有云的產(chǎn)品強太多。也能有效減少后期的數(shù)據(jù)遷移成本。

3、對象存儲產(chǎn)品的選型？

【問題詳述】在對象存儲方面，閉源商用產(chǎn)品相比于以 ceph 為代表的開源商業(yè)產(chǎn)品之間，在市場份額，用戶，方案成熟度，性能，擴展性以及其他功能等方面是否有對比數(shù)據(jù)可以參考？

@王國明 戴爾科技集團 高級系統(tǒng)工程師：

不管是對象存儲，還是其它存儲，選型的基礎(chǔ)條件是：“選擇適合自己的產(chǎn)品！' 而判斷什么樣的產(chǎn)品才是適合自己的呢，很重要的一點，是看“生態(tài)”，一方面是有前景的技術(shù)，另一方面是領(lǐng)先的技術(shù)，其三是有足夠的人 / 廠商相互認證支持。Ceph 作為一個被廣泛使用 / 抄襲的系統(tǒng)，提供了塊 / 文件 / 對象的所有支持，是它的優(yōu)勢也是它的劣勢。優(yōu)勢在于要什么都有，劣勢就是：“萬金油，什么病都治，什么病都治不好”，比如在元數(shù)據(jù)優(yōu)化、就地多協(xié)議訪問等方面都存在問題。另一方面，還有一幫人，天天等開源社區(qū)解決他們的 Bug 。這也是很多金融業(yè)的用戶選擇成熟商業(yè)產(chǎn)品的原因。

4、不同的保險公司數(shù)據(jù)量的差異比較大，如何能夠選取正確非結(jié)構(gòu)化解決方案的方法？

【問題詳述】在當前保險行業(yè)，針對不同的保險公司數(shù)據(jù)量的差異比較大。如何能夠選取正確非結(jié)構(gòu)化解決方案的方法？具體過程的分析和思考路徑，已經(jīng)遇到的坑有哪些，并且給出一些實際案例進行佐證。

@Jerry 某保險公司 信息技術(shù)高級主管：

不同的保險公司數(shù)據(jù)量的差異較大，是一個客觀事實，即使是一家保險公司不同業(yè)務(wù)條線的數(shù)據(jù)也會存在不小區(qū)別。對于非結(jié)構(gòu)化解決方案的選擇，個人認為還是要根據(jù)企業(yè)自身情況出發(fā)，因地制宜，并沒有一種萬能的方案能夠徹底非結(jié)構(gòu)化數(shù)據(jù)的存儲問題。

各保險公司非結(jié)構(gòu)化數(shù)據(jù)常見的一個情況是， DC 剛籌建那會兒體量不大，單證類非結(jié)構(gòu)化數(shù)據(jù)一般簡單的采用傳統(tǒng) NAS 來存儲，隨著業(yè)務(wù)的發(fā)展，受制于 NAS 機頭的性能限制，各業(yè)務(wù)系統(tǒng)對單證的存、取、備均不同程度出現(xiàn)效率低下的問題，系統(tǒng)出現(xiàn)瓶頸。

對于傳統(tǒng) NAS 向?qū)ο蟠鎯Φ那袚Q，無非是一個長痛短痛的問題，但有一點是確定的，一切不結(jié)合業(yè)務(wù)的技術(shù)更新都是耍流氓。眾所周知保險核心系統(tǒng)提供商就那么幾家，各應(yīng)用接口、核心版本幾乎都是基于各司業(yè)務(wù)的定制，想一刀切不現(xiàn)實。因此，個人建議從傳統(tǒng) NAS 向?qū)ο蟠鎯η袚Q過程中加入一個過渡方案，可以是分布式 NAS ，可以是存儲資源池，亦或是其他方案，重點是平滑過渡，給業(yè)務(wù)一個緩沖時間，解決傳統(tǒng) NAS 的性能效率問題的同時嘗試對象存儲的建設(shè)，兩手抓。

@白光茁 戴爾科技集團 高級系統(tǒng)工程師：

總體而言，建設(shè)思路需要根據(jù)業(yè)務(wù)發(fā)展的需求、企業(yè)內(nèi)部的人員知識儲備、架構(gòu)發(fā)展方向等綜合來看。目前我看到比較多的企業(yè)采用的做法是資源池化，在基礎(chǔ)架構(gòu)層面盡量通過池化、標準化來構(gòu)建存儲資源池，來降低運維的難度和復雜度。

@王國明 戴爾科技集團 高級系統(tǒng)工程師：

其實，就算是同一公司，非結(jié)構(gòu)化數(shù)據(jù)也是十分復雜的，有效的數(shù)據(jù)存儲、治理、共享、訪問都需要在統(tǒng)一的架構(gòu)下解決，這也是數(shù)據(jù)湖方案的重要作用，通過與后端存儲架構(gòu)與前端存儲訪問的解耦，數(shù)據(jù)湖平臺對用戶屏蔽了數(shù)據(jù)的復雜性。數(shù)據(jù)量本身也是建設(shè)中的難點，但數(shù)據(jù)湖方案通過前后一致的擴展方式，以及不停機的容量、功能擴展，確保能夠?qū)崿F(xiàn)“按需購買，即擴即用”，讓系統(tǒng)建設(shè)“只顧目前的需求”就好了！

5、統(tǒng)一存儲方案和分散存儲方案處理非結(jié)構(gòu)數(shù)據(jù)有什么差異？

【問題詳述】保險公司的系統(tǒng)很多都是采用堆疊式建設(shè)的，不同年份，不同用途。存儲資源也是比較分散。有些在本機，有些使用存儲，有些用云。有些在后備中心，有些在 IDC 機房，有些在自己公司機房，給運維帶來較多的工作量。

發(fā)展統(tǒng)一存儲方案，我們也提出過，發(fā)現(xiàn)細化到各個系統(tǒng)時，就會與系統(tǒng)架構(gòu)產(chǎn)生衝突。需要開發(fā)商做很多修改。有些費用還不少，有些會影響業(yè)務(wù)。綜合權(quán)衡后，還是舊系統(tǒng)維持舊架構(gòu)，新系統(tǒng)用新的統(tǒng)一存儲。

非結(jié)構(gòu)數(shù)據(jù)對存儲的挑戰(zhàn)是空間需求越來越快，保密要求越來越高，在這種環(huán)境下。可否分享一個用統(tǒng)一存儲方案還是分散存儲方案來來處理非結(jié)構(gòu)化數(shù)據(jù)的差異，特別是風險角度，對存儲安全架構(gòu)上，要做什么特別配置。

@王國明 戴爾科技集團 高級系統(tǒng)工程師：

你現(xiàn)在面臨的問題實際上就是數(shù)據(jù)湖架構(gòu)著力解決的問題。

各個系統(tǒng)的存儲之間互相隔離「孤島」，數(shù)據(jù)湖讓已有系統(tǒng)在不安裝任何驅(qū)動 / 代理的前提下采用標準的訪問協(xié)議將數(shù)據(jù)放置到數(shù)據(jù)湖中。

當數(shù)據(jù)放入到數(shù)據(jù)湖以后，一方面能夠被傳統(tǒng)的系統(tǒng)共享，另一方面也可以供新形態(tài)的應(yīng)用使用。包括如深度學習這類的應(yīng)用。

數(shù)據(jù)湖支持幾乎所有主流的訪問協(xié)議。其核心就是實現(xiàn)數(shù)據(jù)同專有系統(tǒng)之間的解耦。

補充一下：對于統(tǒng)一架構(gòu)，我的理解就是指 Unified ，這種架構(gòu)實際上就是傳統(tǒng)的 NAS ，當初是為了滿足大家在同一設(shè)備中實現(xiàn) Block/File 而誕生的，只能提供相對簡單的文件支持能力，無法滿足數(shù)據(jù)湖架構(gòu)對眾多的協(xié)議需求。而對于數(shù)據(jù)安全上面，統(tǒng)一存儲一般是基于傳統(tǒng) RAID 的，這種方式在數(shù)據(jù)越來越大，磁盤也越來越大的現(xiàn)在，越來越有問題，大量新的技術(shù)希望能解決這種問題。

數(shù)據(jù)湖支持預(yù)置策略，支持安全策略隨時調(diào)整。另一方面，對于數(shù)據(jù)權(quán)限、數(shù)據(jù)共享這類的安全，商業(yè)產(chǎn)品都能夠做到企業(yè)級，不用太擔心。

@白光茁 戴爾科技集團 高級系統(tǒng)工程師：

這個要看公司對云、自建機房、容災(zāi)中心、 IDC 機房的定位和將來的發(fā)展。其次就是對應(yīng)用架構(gòu)的梳理。假設(shè)在現(xiàn)有應(yīng)用架構(gòu)、數(shù)據(jù)中心架構(gòu)保持不變的情況下，可以考慮用數(shù)據(jù)湖解決方案，既能在底層通過資源池化來簡化運維提升利用率，又可以通過不同的協(xié)議接口對接新舊應(yīng)用的需求。

6、對象存儲的應(yīng)用場景和行業(yè)內(nèi)的應(yīng)用標準？

【問題詳述】問題 1 ：在滿足什么樣的條件下選擇使用對象存儲比較合適？比如說影像文件數(shù)量或者說總的存儲量？

問題 2 ：對象存儲與分布式文件系統(tǒng)的應(yīng)用場景，也有廠商向我們推薦使用分布式文件系統(tǒng)來做影像存儲？

問題 3 ：如果選擇對象存儲，有哪些關(guān)鍵的技術(shù)指標需要關(guān)注？

@王國明 戴爾科技集團 高級系統(tǒng)工程師：

問題 1 ：對象存儲的優(yōu)勢主要包括：Key 的方式使支持海量的數(shù)據(jù)處理，容易擴展，天生支持多數(shù)據(jù)中心，短鏈接方式適合第三平臺應(yīng)用、多協(xié)議訪問等等。如果你的需求中有以上的一條或幾條，就需要評估是否需要對象存儲了。影像系統(tǒng)是保險業(yè)傳統(tǒng)的 NAS 解決方案的戰(zhàn)場，但近年來，大家都在遷移到對象平臺，主要的原因是文件系統(tǒng)太大，跑不動了。一般來說，當一個目錄下的文件數(shù)超過百萬級別，從最佳做法的角度，可能就滿足遷移的一個前提了。

問題 2 ：看你的主要應(yīng)用。一般來說，對象存儲主要使用對象協(xié)議，其它協(xié)議作為補充。分布式文件系統(tǒng)主要使用文件協(xié)議，同時支持其它協(xié)議，支持的對象協(xié)議一般是對象協(xié)議的子集。其二，你需要看應(yīng)用，已有應(yīng)用如果不改，一般來講是支持文件的，這時候也可以選分布式文件系統(tǒng)存儲影像，這也是主流解決方案。

問題 3 ：對象存儲的產(chǎn)品選型，建議關(guān)注指標為：安全性、產(chǎn)品生態(tài)（可參見我另外一個關(guān)于選型的回復），兼容性、獨到技術(shù)能力、擴展能力。

@白光茁 戴爾科技集團 高級系統(tǒng)工程師：

關(guān)于第一個問題，我這邊一般的判斷標準是百萬文件數(shù)量，就可以考慮使用對象存儲。關(guān)于第二個問題，主要依據(jù)咱們的技術(shù)路線選擇，在存儲影像這個場景下，兩者都可以使用。有些客戶在整個系統(tǒng)架構(gòu)上就在往多中心、多活架構(gòu)上去走，所以他們最終選擇了對象存儲的技術(shù)路線。關(guān)于第三個問題，主要的技術(shù)指標主要關(guān)注擴展性，例如單一 Bucket 支持的對象數(shù)量，多活、基本性能。我這邊接觸的項目，從最終的使用上來看，一般是容量先用滿。

7、對象存儲的數(shù)據(jù)備份與恢復實現(xiàn)的方式都有哪些？

@dawey 某大型券商 技術(shù)經(jīng)理：

主流對象存儲均采用節(jié)點式橫向擴展分布式架構(gòu)，以實現(xiàn)從小規(guī)模到大規(guī)模（ 10 PB 級）的容量和性能擴展。為了實現(xiàn)海量非結(jié)構(gòu)化數(shù)據(jù)管理，主流對象存儲均采用分布式元數(shù)據(jù)管理方式，以使得存儲系統(tǒng)在管理海量（億級）文件時，能夠?qū)崿F(xiàn)訪問性能的穩(wěn)定性。

對象存儲拋棄了傳統(tǒng)的基于樹狀文件系統(tǒng)的管理方式，通過 Key-Value 的扁平式架構(gòu)來管理海量文件，保障了海量文件下文件讀寫的性能。為了保證在分布式系統(tǒng)架構(gòu)下的數(shù)據(jù)安全性，對象存儲通常采用糾刪碼或者多份副本的方式預(yù)防磁盤、節(jié)點級的硬件故障，同時通過多站點復制，保證站點級故障下數(shù)據(jù)的可用性。

此外在海量文件環(huán)境下，傳統(tǒng)的數(shù)據(jù)備份方案無法有效備份，對象存儲采用多副本的方式進行邏輯故障防護。與傳統(tǒng)文件存儲相比，對象存儲在海量非結(jié)構(gòu)化數(shù)據(jù)長久保存場景下有著獨特的優(yōu)勢。

三、非結(jié)構(gòu)化數(shù)據(jù)遷移的相關(guān)問題

1、非結(jié)構(gòu)化數(shù)據(jù)存儲遷移后如何解決數(shù)據(jù)訪問問題？

【問題詳述】若將非結(jié)構(gòu)化數(shù)據(jù)由傳統(tǒng)存儲遷移至對象存儲或 MPP 系統(tǒng)，數(shù)據(jù)的層次結(jié)構(gòu)、目錄層級以及數(shù)據(jù)訪問方式均可能發(fā)生變化，業(yè)務(wù)系統(tǒng)對遷移后數(shù)據(jù)的訪問存在巨大隱患。在規(guī)劃時如何針對性解決此類問題？

@dawey 某大型券商 技術(shù)經(jīng)理：

對象存儲拋棄了傳統(tǒng)的基于樹狀文件系統(tǒng)的管理方式，通過 Key-Value 的扁平式架構(gòu)來管理海量文件，保障了海量文件下文件讀寫的性能。為了保證在分布式系統(tǒng)架構(gòu)下的數(shù)據(jù)安全性，對象存儲通常采用糾刪碼或者多份副本的方式預(yù)防磁盤、節(jié)點級的硬件故障，同時通過多站點復制，保證站點級故障下數(shù)據(jù)的可用性。對象存儲通過 API 接口進行數(shù)據(jù)訪問，應(yīng)用或者客戶端可以直接調(diào)用訪問數(shù)據(jù)，更加便捷，支持 S3 、 HDFS 、 Swift 等多種協(xié)議。

對象存儲經(jīng)常被比作在一家高級餐廳代客停車。當一個顧客需要代客停車時，他就把鑰匙交給別人，換來一張收據(jù)。這個顧客不用知道他的車被停在哪，也不用知道在他用餐時服務(wù)員會把他的車移動多少次。在這個比喻中，一個存儲對象的唯一標識符就代表顧客的收據(jù)。當需要獲取數(shù)據(jù)時，只需要告訴對象存儲這個唯一標識符，剩下的檢索工作均由對象存儲本身完成。

由于訪問方式上不同，涉及存儲變更后應(yīng)用系統(tǒng)也需要進行訪問方式上的改造，需要有一定的過渡期，同時也要考慮老數(shù)據(jù)的遷移問題。

@白光茁 戴爾科技集團 高級系統(tǒng)工程師：

在數(shù)據(jù)遷移的過程中，雖然數(shù)據(jù)的訪問方式、數(shù)據(jù)的層次結(jié)構(gòu)以及目錄層級等會發(fā)生變化，但是整個過程都是可控的。在實際操作中，比較常見的有兩種方案，一種方案是通過應(yīng)用進行數(shù)據(jù)遷移，這種也是最推薦的方案，應(yīng)用進行遷移的時候，可以根據(jù)業(yè)務(wù)的負載靈活的控制遷移速度，也可以在遷移過程中完成對每個對象數(shù)據(jù)的校驗。第二種方案是由遷移工具進行數(shù)據(jù)遷移，這種情況下需要應(yīng)用進行相應(yīng)的配合，首先應(yīng)用需要能夠同時訪問源存儲和目標存儲，并將新增數(shù)據(jù)寫入到新的目標存儲中，這樣保證源存儲內(nèi)不會有數(shù)據(jù)的新增，同時通過遷移工具來進行數(shù)據(jù)遷移，并記錄源和目標訪問路徑的變化，并在遷移完成后，交由應(yīng)用系統(tǒng)來更新成新的訪問路徑，并確認從應(yīng)用端能夠正常訪問目標存儲。整個遷移視數(shù)據(jù)量的大小可能會分批遷移，從而保證數(shù)據(jù)遷移能夠順暢完成。所以我建議要講數(shù)據(jù)遷移視為一個服務(wù)項目來根據(jù)實際情況來處理比較好。

在實際的項目里，源存儲不一定是塊、 NAS 這種存儲，有可能是數(shù)據(jù)庫、應(yīng)用，所以具體到不同企業(yè)的實際情況，遷移方法可能有很大不同。

另外有的企業(yè)會在存儲和應(yīng)用之間設(shè)置一個輕量級數(shù)據(jù)抽象層，這個數(shù)據(jù)抽象層可以屏蔽底層數(shù)據(jù)存儲的差異，對外提供統(tǒng)一的面向業(yè)務(wù)的應(yīng)用訪問接口，這個抽象層可以兼具數(shù)據(jù)遷移的功能，從而實現(xiàn)底層存儲技術(shù)的更換，對上層的應(yīng)用而言是沒有任何感知的。

@王國明 戴爾科技集團 高級系統(tǒng)工程師：

數(shù)據(jù)遷移，這是一個老生常談的問題。非結(jié)構(gòu)化數(shù)據(jù)的遷移，其實也不是什么新事物。一般來說，有兩種遷移方式，一種是對用戶透明的遷移，用戶不需要關(guān)心數(shù)據(jù)位置，這種方式需要考慮數(shù)據(jù)的指針管理；一種是對用戶不透明的，需要訪問不同的數(shù)據(jù)位置以獲取數(shù)據(jù)，這需要用戶端和數(shù)據(jù)存儲之間協(xié)商數(shù)據(jù)的訪問路徑。這兩種方式在我們的數(shù)據(jù)湖平臺中均提供。兩種方式各有優(yōu)先考慮的重點，具體選用哪種方式需要考慮應(yīng)用場景以及應(yīng)用開發(fā)的相關(guān)問題。

2、如何提高非結(jié)構(gòu)化數(shù)據(jù)遷移的效率？

【問題詳述】非結(jié)構(gòu)化數(shù)據(jù)遷移過程中，影像數(shù)據(jù)（如圖片、 PDF 、影像件）等典型特征數(shù)據(jù)遷移速度極慢，遷移所需時間窗口非常長，在保證業(yè)務(wù)連續(xù)性的前提下，如何有效加速由傳統(tǒng)存儲向?qū)ο蟠鎯Φ倪w移效率？

@白光茁 戴爾科技集團 高級系統(tǒng)工程師：

數(shù)據(jù)遷移的速度受限于源存儲系統(tǒng)、遷移程序、網(wǎng)絡(luò)和目標存儲系統(tǒng)。一般情況下源存儲系統(tǒng)會成為瓶頸，同時要保證業(yè)務(wù)能夠繼續(xù)對外提供服務(wù)，遷移不能對源存儲系統(tǒng)造成壓力，所以遷移的窗口都會非常長。常見的處理方法是通過修改應(yīng)用訪問存儲邏輯，所有新增數(shù)據(jù)全部寫入到目標對象存儲中，舊的源存儲里的數(shù)據(jù)只用于讀取，不會有任何的新增數(shù)據(jù)，同時通過應(yīng)用或者遷移程序進行數(shù)據(jù)遷移。

除此之外，還有的做法是把源存儲或者系統(tǒng)的數(shù)據(jù)通過備份或者復制的方式，拷貝到一套新的系統(tǒng)中，專門用于數(shù)據(jù)遷移，但是這種做法投入會很高，用的也比較少。

再者就是從應(yīng)用架構(gòu)上解決，在底層存儲系統(tǒng)和前端應(yīng)用之間添加一個輕量級的數(shù)據(jù)抽象層，這個抽象層可以對外提供統(tǒng)一的數(shù)據(jù)訪問接口。這個抽象層也負責在不同的存儲技術(shù)之間進行數(shù)據(jù)遷移，這樣不管采用何種的存儲技術(shù)，都可以靈活的進行處理。

具體采用何種方式更優(yōu)，還是要取決于企業(yè)的實際情況，所以我比較建議把數(shù)據(jù)遷移當成是一個服務(wù)項目來處理。

3、關(guān)于非結(jié)構(gòu)化數(shù)據(jù)，存量數(shù)據(jù)如何從傳統(tǒng)存儲遷移到非結(jié)構(gòu)化存儲？

【問題詳述】目前傳統(tǒng)存儲上存放海量影像數(shù)據(jù)，如果在規(guī)定變更時間內(nèi)將存量數(shù)據(jù)從傳統(tǒng)存儲遷移至非結(jié)構(gòu)化存儲，希望能否有經(jīng)驗可分享下。

@白光茁 戴爾科技集團 高級系統(tǒng)工程師：

這個主要還是要看源端存儲和目標端存儲采用的具體技術(shù)來進行選擇。如果采用最通用的方案，一般有兩種，第一種就是直接通過應(yīng)用進行數(shù)據(jù)遷移，第二種就是通過外部的數(shù)據(jù)遷移工具來進行遷移。一般情況下，在文件數(shù)量巨大的情況下，在規(guī)定的變更窗口內(nèi)是很難完成的，因為很多情況下，源存儲或者說源系統(tǒng)沒辦法支撐大量數(shù)據(jù)的同時讀取。所以思路會轉(zhuǎn)變成，如何在不影響生產(chǎn)的情況下進行數(shù)據(jù)遷移，在這種思路下，一般情況是在遷移的過程中，應(yīng)用會同時接入源端存儲和目標端存儲，同時將所有新增數(shù)據(jù)寫入到目標端存儲，這樣源端存儲不會有任何新增數(shù)據(jù)。接下來有兩種處理方式，一種就是通過數(shù)據(jù)備份或者存儲拷貝將數(shù)據(jù)在其他系統(tǒng)上拉起，作為遷移的源端，來盡快進行數(shù)據(jù)遷移，這樣不會對現(xiàn)有系統(tǒng)造成影響，但是這樣也有劣勢，就是成本比較高。還有一種常見的做法就是在把現(xiàn)有系統(tǒng)作為源端，通過遷移工具進行遷移?？傮w而言由于應(yīng)用在整個遷移過程中能夠正常訪問所有數(shù)據(jù)，所以遷移時間的長短，對業(yè)務(wù)是沒有影響的，只是在遷移完成后，進行割接的時候申請變更窗口就可以了。

還有一種解決辦法就是，在存儲和應(yīng)用之間引入一個數(shù)據(jù)抽象層，這個抽象層會對外提供一個統(tǒng)一的數(shù)據(jù)訪問接口，來屏蔽底層存儲技術(shù)。同時這個抽象層還可以進行數(shù)據(jù)遷移，這樣保證不管底層存儲技術(shù)如何變化，對外的服務(wù)是統(tǒng)一的。當然這個方法更多的是從應(yīng)用架構(gòu)上去進行處理，牽扯到的部門會非常多。

@王國明 戴爾科技集團 高級系統(tǒng)工程師：

我們提供包括基于快照、基于并行訪問等等多種遷移工具，具體使用何種工具需要看現(xiàn)有的詳細需求。所有的工具都有成功案例可參考。舉例來說，針對變更時間窗緊張的客戶，我們會在設(shè)備帶寬允許的情況下，增多遷移器（ Migeration Agent ）的數(shù)量，以提升遷移速度。而快照方式，我們能夠以中間聯(lián)接的最高速度實現(xiàn)數(shù)據(jù)傳輸。

4、大量非結(jié)構(gòu)化數(shù)據(jù)遷移的問題？

【問題詳述】現(xiàn)有保險影像系統(tǒng)中存儲的非結(jié)構(gòu)化數(shù)據(jù)至少是百萬或千萬個文件量級，想問下對于這種量級的文件，是否有穩(wěn)妥的遷移方案，可以保證將所有數(shù)據(jù)完整遷移至對象存儲，并且遷移后可以提供驗證。

@白光茁 戴爾科技集團 高級系統(tǒng)工程師：

我這邊做過的項目里，一般遷移方案分兩種，第一種是由應(yīng)用進行遷移，第二種是以遷移服務(wù)項目的方式進行遷移?；镜倪w移思路是新數(shù)據(jù)寫入到對象存儲，老的存儲只用于讀取，這樣整個遷移的數(shù)據(jù)集就是一個固定的數(shù)據(jù)集，這樣便于并發(fā)進行遷移處理，在整個遷移過程中，遷移工具會保證數(shù)據(jù)能夠完整把數(shù)據(jù)遷移到對象存儲。我比較建議把數(shù)據(jù)遷移當成一個遷移服務(wù)項目來看，因為遷移過程還是有很多需要協(xié)調(diào)工作來做。數(shù)據(jù)的驗證的話，遷移工具是會來做。但是在最終割接以前，還是要請應(yīng)用部門也進行一次數(shù)據(jù)驗證。

此外有的企業(yè)會在底層存儲和上層應(yīng)用之間添加一個很輕量的數(shù)據(jù)抽象層，來屏蔽底層不同存儲技術(shù)的差異，對外封裝成一個面向應(yīng)用的統(tǒng)一訪問接口。同時這個抽象層會提供數(shù)據(jù)在不同存儲或者不同存儲技術(shù)之間進行遷移的功能。這樣不管是底層存儲技術(shù)如何變遷，對上層應(yīng)用基本是沒有任何影響的。當然這種做法需要從整個應(yīng)用架構(gòu)角度去設(shè)計規(guī)劃。具體采用哪種方案還是要取決于每個企業(yè)自己內(nèi)部的實際情況。

@王國明 戴爾科技集團 高級系統(tǒng)工程師：

采用數(shù)據(jù)湖的其中一個重要優(yōu)勢就是不再需要做數(shù)據(jù)遷移。而對于傳統(tǒng)的解決方案，對于大量的非結(jié)構(gòu)化數(shù)據(jù)遷移，是一個費時費力的工作。針對這種情況，我們提供了一些工具，幫助用戶來做數(shù)據(jù)遷移，如基于快照和遷移、基于并行訪問的遷移等等，需要根據(jù)具體的情況來選用。

四、非結(jié)構(gòu)化數(shù)據(jù)解決方案相關(guān)問題

1、DellEMC ECS 對象存儲有什么優(yōu)勢？

@dawey 某大型券商 技術(shù)經(jīng)理：

Dell EMC 在 Garner 的分布文件 & 對象存儲的魔力象限中多年一直處于領(lǐng)導象限的第一位置。這是市場對 Dell EMC 對象存儲的認可。ECS 擴展了 S3 的支持：允許用戶在 bucket 層面自定義元數(shù)據(jù)（ meta data ） . 這些自定義的 Meta data 跟系統(tǒng)級的 Meta data 一道，可以讓用戶以更簡單的方式從 bucket 中批量過濾并提取符合一定條件的對象。

2、PowerScale 適用的保險場景有哪些？

@王國明 戴爾科技集團 高級系統(tǒng)工程師：

PowerScale 作為數(shù)據(jù)湖平臺的核心組成部分，在保險行業(yè)有很多的應(yīng)用場景，從傳統(tǒng)的影像系統(tǒng)、數(shù)據(jù)分析到新型的用戶畫像、智能風控，都可以使用 PowerScale 來搭建數(shù)據(jù)湖平臺。

3、PowerScale 與 isilon 在技術(shù)原理上有什么差異？在 EMC 數(shù)據(jù)湖方案中這兩者的地位又如何？

@王國明 戴爾科技集團 高級系統(tǒng)工程師：

PowerScale 是新的平臺，是基于 Isilon 的基礎(chǔ)上的一次進化。PowerScale 采用 OneFS 9.0 ，同時提供 PowerScale 專用硬件和 Isilon 硬件的支持，二者支持混裝。OneFS 9 在繼承 Isilon 以前的優(yōu)點前提下，提供了諸多新的特性，如 S3 的支持，在線數(shù)據(jù)縮減等等。

在數(shù)據(jù)湖解決方案中， PowerScale 會是我們 Isilon 、 ECS 、 SDP 的有力補充，提高了需求覆蓋以及更好的投入產(chǎn)出比。

原題：大數(shù)據(jù)時代下保險業(yè)海量非結(jié)構(gòu)化存儲選型策略線上交流問答總結(jié)