【FIW2022精彩回顧】新基建，和而不同——保險業基礎架構關鍵技術趨勢與探索

文丨泰康保險技術專家 付傑

當前，隨著社會資訊化程式的不斷加快，企業進行數字化轉型似乎不再是一個可選項，而是一個必選項。那麼，企業應該如何轉型，“科技”又在企業數字化轉型過程中扮演了什麼樣的角色？對此，從事 IT 基礎架構管理的人很容易會想到“降本增效，科技賦能”這八個字。為此，筆者將結合自己的實際工作經驗，從從業者的角度，圍繞幾個概念來談談自己的一些想法。

一、超融合

所謂超融合架構，簡單來說，就是一組標準的伺服器透過高速網路互聯，使計算、儲存和網路融為一體。

經過多年的市場推廣，從客戶案例中可以看到，超融合在伺服器虛擬化、桌面 VDI 等傳統資料中心的私有云場景中的應用非常成熟，某些高階超融合產品可以更好地適用於效能和延遲要求更為苛刻的資料庫場景。

從最初的基於 VMware 的超融合架構解決方案到日趨完善的自有 KVM 平臺，再到雲原生，超融合已經成為資料中心的底座。

目前，超融合的主要應用場景還是基於 VMware 生態進行系統支撐，這個層面的核心價值在 VMware，而超融合只是執行的載體。筆者認為，基於超融合自身的 KVM 平臺才是其核心價值，而且很多關鍵 Features 都是基於自研 KVM 打造的，比如 Nutanix 的 AHV 和 SmartX 的 ELF，只有脫離 VMware，超融合才能更好地創造自己的價值。

筆者之前看到過一組資料和結論，比如傳統儲存市場份額因被超融合和分散式儲存蠶食而下降；相比超融合，分散式的軟體定義儲存（這裡主要指的是狹義的 SDS，類似於 Ceph）搶佔了更多的市場份額，從最終的市場份額看，SDS 的市場份額比超融合要高出好幾個百分點，在資料上給人一種 SDS 的市場空間要比超融合大的感覺。

筆者並不認同這種說法，從架構格局上講，超融合比雲端計算“矮了半截”，但勝在“短小精悍”，當下，超融合也有了更廣泛的內涵和外延，比如頭部廠商開始完善基於超融合的雲管，整合了 CMDB 和 DevOps 能力。

同時，超融合又比 SDS 高一個維度，套用一句時髦的話，超融合可以降維打擊 SDS。超融合和 SDS 不會出現在同一個客戶專案裡，二者往往井水不犯河水，實際上卻暗含競爭和替代關係。不可否認的是，每一套超融合產品都自帶分散式儲存，所以從這個角度來看，在專案落地時超融合自然就會踩踏 SDS。

筆者認為，對於大量中小企業使用者而言，在不考慮雲的情況下，無論在 IT 系統規模還是人員技能方面，使用超融合這樣經濟高效的解決方案更適合。

二、容器虛擬化

簡單來說，容器虛擬化就是在容器中實現伺服器虛擬化，透過容器驅動虛擬機器。

在容器中進行虛擬化，乍一聽似乎有些奇怪。

隨著雲原生微服務架構的逐步落地，從降本增效的角度來說，容器勢必將替代現有虛擬機器，只是這種替代目前還不絕對，有些虛擬機器不能被容器直接替代。

當下，虛擬機器仍是主流成熟的技術，換句話說，要麼 VMware，要麼其他 KVM。筆者認為，客戶應該更關注如何實現容器的規模部署，藉助容器的輕、快等特徵實現彈性計算，最終達到降本增效的目的。

三、儲存的演進

關於對儲存的理解，筆者用一個親身經歷過的案例來闡述。

多年前，筆者所在的公司構建了影像集中儲存平臺，最初影像資料是透過 SAN 做的檔案系統，考慮到後期資料增長的問題，在系統最初設計階段就以分公司為單位隔離存放資料。

有一次，伺服器在夜間發生系統當機，到現場才發現是檔案系統出了問題，掛接不上去。通常，伺服器異常當機可能會導致檔案系統損壞，為了保證資料安全，作業系統會要求檔案系統在重新掛接使用前進行 fsck 檢查和修復，以確保資料一致性。

在此情況下，只能緊急對幾十家分公司的檔案系統逐一檢查，直至距離第二天早上上班沒剩多少時間的時候，幾個資料規模大的分公司還在檢查中，也因此，公司在 2010 年左右就把這部分資料改用 NAS 儲存 。

不過 NAS 也是基於檔案系統的，同樣受制於檔案系統特性，使用 NAS 支撐非結構化資料儲存時，特別是在海量小檔案的情況下，一定要提前做好相應的儲存目錄層次設計，最好有 4～5 層的目錄，最終目的就是為了控制單一目錄中的檔案數目，降低系統開銷。

隨著公司業務的快速發展，影像檔案飛速增加， NAS 在儲存容量和 inode 等方面都受到了挑戰，而且隨著影像檔案數量的增多，這個痛點愈發明顯。2017 年，公司最終選擇把這部分資料遷移到了物件儲存，目前的儲存容量是 2PB，物件數量是 20 億。

結構化資料的儲存有兩個方向，一個是用於支撐虛擬機器和容器，另一個是用於支撐資料庫。傳統 SAN 儲存支撐傳統集中式資料庫，而對於分散式資料庫，本地盤替換了 SAN。

四、統一儲存

最早提出統一儲存的是 NetApp，其形式是“NAS + SAN”的統一，這個階段可以看成是統一儲存的 1.0 時代；後來出現了開源 SDS、Ceph，統一儲存就變成了“SAN + NAS + 物件儲存”的統一，這個階段可以看成是統一儲存的 2.0 時代；最近幾年出現了一個新名詞——Alluxio，筆者把它定義為統一儲存 3.0 時代。

如圖 1 所示，在 Alluxio 之上是大資料和人工智慧的運算框架，使 Alluxio 可以跟 Spark、Hive 和 TensorFlow 進行適配。在 Alluxio 之下是對各種型別儲存協議的轉義和封裝，主要是三類：Hadoop 生態的 HDFS，NAS 的 NetApp 和物件儲存 S3、Ceph 等。而處在中間起到穿針引線作用的就是像 Alluxio 這樣的資料編排平臺。

圖 1 統一儲存 3.0：存算分離新高度

傳統環境中非結構化資料共享解決方案中最簡單的就是 NAS，但在大資料時代，非結構化資料或者半結構化資料儲存和計算的量遠遠超過了結構化資料，HDFS 大行其道，成了主流。筆者認為，企業中的確有很多資料孤島，缺少有效的統籌。Alluxio 解決了 HDFS、NAS 和物件儲存的異構整合。

五、資料湖

近年來，“資料湖”這個詞很火。業界對於資料湖的理解也不盡相同，有人認為 Hadoop 是資料湖，有人認為 S3 也是資料湖。從線上公有云的應用情況來看，S3 是主流儲存，而從線下私有云的應用情況來看，Hadoop 似乎更有優勢。

對於網際網路，HDFS 系統的確在叢集擴充套件性、支援應用標準上存在一些侷限性。畢竟，Hadoop 技術已經出現了很多年，當下的軟硬體環境已與當初大不相同，系統重構也在情理之中。

Ozone 給使用者提供了一個新選擇。Ozone 與 Alluxio 類似，也相容支援 S3 和 HDFS 的 API。因為上述特性，Ozone 可以“透明”地支援現有 Hadoop 生態中如 Spark 和 Hive 等上層計算框架，無需修改應用程式碼。Ozone 既是 Hadoop 的最佳化升級版，又能“分層”解決海量小檔案的物件儲存，再加上對雲原生 CSI 的支援，使其成為了新一代“融合”儲存。

從最近了解的技術發展趨勢看，筆者認為，面向未來的資料湖技術應該是向上相容多種主流計算框架，平滑支撐多種應用場景，向下對接不同的儲存引擎，實現資料訪問介面的標準化。這種承上啟下、統一標準的儲存技術將成為下一代資料湖的顯著特徵。

六、資料治理

傳統的資料倉、資料湖乃至湖倉一體這些技術，本質上還是資料庫和大資料的有機結合，其功能除了用技術解決資料的時效性問題、用服務產生資料價值外，還有一個很重要的點，就是實現資料治理。

Atlas 是 Hortonworks 公司貢獻給 Apache 的一個開源專案，是一個企業大資料治理的服務框架。Atlas 的核心是資料治理，透過對後設資料（描述資料的資料，對資料庫來說，後設資料簡單理解就是系統表裡的資料）的管理、分類和建模，最終構建出企業的資料資產目錄（Metadata Catalog）。

後設資料管理的目的就是幫助企業管理資料資產。員工如何才能知道企業有什麼資料，這些資料在哪兒，指標的定義和統計口徑是什麼？顯然，如果企業有一個像 Atlas 這樣的“資料字典”，相關人員就可以快速瞭解資料，形成共識。對於資料倉儲運維人員來說，面對從 ODS 到 ADS 的多個資料層，除了命名規範外，識別表與表、欄位與欄位之間的“血緣關係”，進行資料穿透，都依賴“資料字典”。

總之，可以認為 Atlas 的技術核心是圖資料庫的應用實現以及整個大資料系統的後設資料複製。