【FIW2022精彩回顾】新基建，和而不同——保险行业基础架构关键技术趋势与探索分享

以下文章来源于 FCC30+ ，作者付杰

9 月 21—23 日，第一届“金融现代化 IT 基础架构转型论坛（FinTech Infrastructure Wave 2022）”成功举办。该论坛由中国信息通信研究院云计算与大数据研究所、《中国金融电脑》杂志社主办，北京志凌海纳科技有限公司（SmartX）与北京鲲鹏联合创新中心协办。论坛分为三大专场，覆盖银行、保险、证券、基金、期货、信托六大金融细分行业，内容涵盖多云平台建设、核心业务系统信创转型、超融合关键场景落地、核心业务 K8s 改造、数据中心零信任安全、基础设施即代码等前沿话题。

泰康保险技术专家、IT 自媒体作者付杰发表了题为《新基建，和而不同》的主题演讲。

文丨泰康保险技术专家 付杰

当前，随着社会信息化进程的不断加快，企业进行数字化转型似乎不再是一个可选项，而是一个必选项。那么，企业应该如何转型，“科技”又在企业数字化转型过程中扮演了什么样的角色？对此，从事 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。笔者认为，客户应该更关注如何实现容器的规模部署，借助容器的轻、快等特征实现弹性计算，最终达到降本增效的目的。

推荐阅读：

三、存储的演进

从数据存储的形态来看，存储主要包括存储局域网络（Storage Area Network，SAN）、网络附加存储（Network Attached Storage，NAS）和对象存储三种。

关于对存储的理解，笔者用一个亲身经历过的案例来阐述。

多年前，笔者所在的公司构建了影像集中存储平台，最初影像数据是通过 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 的技术核心是图数据库的应用实现以及整个大数据系统的元数据复制。

推荐阅读：

以上内容大多来源于作者的公众号——“落风潭”，感兴趣的朋友可以添加作者个人微信。

推荐阅读：