前言

近年来，随着云计算、大数据、互联网 + 、 AI 等技术的飞速发展，在 “ 保险 + 科技 ” 的战略驱动下，保险行业整体营收逐年攀升、竞争持续加剧，保险的本质是经营风险的行业，其业务属性高度依赖于数据的积累。步入大数据时代，保险企业可获取的数据在 “ 量级 ” 和 “ 维度 ” 上都迎来了前所未有的拓展，海量业务数据的爆发为保险企业对数据价值挖掘带来了崭新的机遇。相对结构化业务数据的处理效率，保险企业对海量非结构化数据的挖掘需求更加强烈，传统技术手段的提升不再匹配保险科技的飞速发展，非结构化数据处理技术亟待创新。

目前保险行业面临的海量非结构化业务数据主要有以下四种：

• 第一种数据，保险企业在线上线下渠道投保、承保、理赔等过程中产生的客户交易信息，如身份证照片、保单扫描件、取证文件、现场照片以及数字签名校验等。此类文件数量巨大，单文件体积偏小，而且需要长期保存。

• 第二种数据，保险企业与第三方公司的交易及对账文件，如银行代理交易、中介微投保险销售等。此类非结构化数据不仅数量巨大，并且伴随高并发、高频率、高响应的处理特征。

• 第三种数据，监管单位对保险企业要求长期保留的影像、录音等多重形式的非结构化数据，如根据《保险销售行为可回溯管理暂行办法》规定的双录数据。

• 第四种数据，保险交易系统后台数据逻辑处理产生的海量过程数据，如交易报文、保单合成过程文件、打印投递处理记录等。过程数据往往是问题交易及故障排查的有力依据，拥有一定的数据保留需求。

在保险科技初期，非结构化数据数量并未形成规模，加之保险核心系统、影像系统、中间平台等业务平面的发展限制，保险企业普遍采用 NAS 设备存储各类非结构化数据，但随着保险业务的迅猛发展，海量非结构化数据已初具规模， NAS 存储的性能、容量以及数据的可管理性会出现瓶颈。

在这次交流中，我们根据保险业的实际情况，邀请了保险行业专家、对象存储技术专家以及戴尔科技技术专家一起参与线上交流探讨。希望本次活动能够给大家带来一些参考思路，以助大家更好的决策关于海量非结构化数据存储的选型问题。

答疑集锦

一，保险业非结构化数据现状

1， NAS 存储扩容问题？

问题背景 ：我们现在用的 netapp 的 nas 存储，总的空间是 40T ，空间已经接近分配完，但整个存储空间使用才 50% （都是以 NFS 的形式分配给不同的业务）。现在再有新业务新需求了，没有空间可以分配了，这种问题咨询了厂家，说是收缩卷的空间可能不好操作。所以我们面临着 NAS 扩容的问题。问题来了，领导觉得我们的扩容不能被 NETAPP 品牌绑架，问下各位专家，有已购扩容的方法或者案例吗？

答 ： NAS 品牌扩容不能被品牌绑架？几乎不可能，暂且不论能不能混用其他品牌扩容柜，就算能混用，敢不敢混用都是一个问题，出了事谁承担？传统 NAS 除了扩容就是购买其他品牌的设备了，没法在一个品牌的机头上混用另一个品牌的扩容柜。收缩卷的操作都是高危敏感操作，极容易出问题，不要轻易尝试。

答 ： 传统的 NAS 一定会面临扩充的难题，特别是在现阶段大家数据飞涨的阶段。建议你对你的应用进行评估，看是否选择基于分布式的数据湖技术，从而一劳永逸。给你带来的优势主要有：

1 、方便扩充，容量和性能线性扩充；

2 、方便扩充节点（ 60 秒）；

3 、以后不再需要数据迁移， 这一次迁移数据你可以选择基于快照的方式迁移，速度还可以；

4 、其它的优点，比如可以随时调节容错级别，新协议支持等等。

2，能否具体谈谈 NAS 存储的瓶颈？

问题背景 ：对于影像，保单等产生大量非结构化数据的业务系统来说，有没有经验或者数据可以参考， NAS 文件数量或存储容量在怎样的数量级， NAS 存储可能会出现明显的瓶颈？

答： 1 ，性能瓶颈， NAS 机头的瓶颈始终有限，扩容柜能持续扩容， NAS 机头不行。 2 ， NAS 底层文件系统的限制，最常见的就是单目录下文件数量超过限制了，同时文件数量增大到一定量级，读写效率明显降低。 3 ，备份问题，也是受限于机头和备份方式，再就是 NAS 文件系统的访问机制，整体效率特别低。

对于传统 NAS 存储，主要看底层文件系统的单目录下最大文件数限制，尤其是影像、打印这类系统，一旦共享目录下文件数接近或者超过最大文件数限制，访问效率明显下降。其次，非结构化数据的规模和体积会对 NAS 性能有明显影响，同是同一文件数量规模的影像件类和打印报文结果类非结构化数据，打印报文结果访问效率更低。

答： 一般情况下，我这边的经验是百万量级的文件。但是具体还是要看企业内部对未来 IT 技术路线的看法和企业的实际情况。从目前市面上成熟的存储技术来看，在海量非结构化数据的长久保存这个场景，基本上就是对象存储这个选择，因为不管文件是几万量级，还是几十亿量级，都能够很好的处理。在实际项目中，有的企业会优先选择解决当下碰到的问题，有的企业会考虑未来几年的架构的合理性，不同企业在进行技术选型的时候考量点不太一样，这个会导致技术路线的选择也不一样。用对象存储毕竟要涉及到应用访问接口的改造，有的企业在接口改造上困难很大，导致不得已继续使用 NAS 。我自己就碰到过有的企业的软件开发商破产，导致无法升级改造的事情。

答： NAS ，或者说传统 NAS 有很多局限，这也是分布式系统在创建之时就有的追求，目的在于解决传统 NAS 的这些问题：

1 、性能依赖控制器，控制器会造成性能瓶颈，不能做大规模的并发负载分担；

2 、传统的容错方式会导致更低的使用效率以及极不灵活的容错方式，而且系统故障重建时间极难控制；

3 、多协议支持是硬伤，数据湖的访问方式才是符合大数据模式的，太多的数据迁移和复制会由于数据的规模越来越大变得不可操作；

3，海量非结构化数据备份问题？

问题背景 ：对于保险影像系统中存储的大量非结构化数据有无快速有效的备份方案，可以应对在线数据误删除、恶意删除、中病毒被篡改等问题？

答： 对于影像 / 单证 / 打印类数据的快速备份问题，现在没有一劳永逸的解决方案，这也是全行业面临的数据保护难题。在此分享点经验仅供参考：

传统 NAS 存储备份，传统备份效率受制于两个方面，一个是文件读取 IO 的时间，由于数据量大，时间被横向拉长。对于这点的优化，可以考虑增加 NAS 文件的备份节点，每个节点扫描特定范围的共享目录，同时并行扫描将节省大量时间，但备份节点和扫描线程数并不是越多越好，根据实际测试结果调整；二个是受制于 NAS 机头性能，硬件素质决定无法优化。如果是分布式 NAS ，速度会更有优势。传统单双机头 NAS 则没有很好的办法。

对象存储备份和恢复则很依赖对象存储的接口和协议，业务条件允许的话，建议做好冷热分离和数据的归档。

答： 如果底层的存储技术是对象存储的话，可以通过多版本的方式来实现数据防误删除，或者也可以通过 WORM 的功能来防止误删除和恶意删除。在病毒预防方面，对象存储在存储文件的时候是打散到不同物理节点来存放的，所以病毒文件无法感染同一存储内的其他文件，因此也可以有效的进行防病毒。

答： 备份，换句话说，数据的安全以及历史数据的可访问，不管是不是海量，都需要考虑。由于数据的海量，会让一些传统的方式无法完成，而需要做出调整。一般说来，我们建议采用历史数据归档方式实现数据备份，传统的备份，会涉及到数据的封装，对于海量的数据会有性能和数据可访问性方面的难题，只会用在满足特定需求的数据保护上。而采用包括快照、多副本、同步容错、 NDMP 备份多种方式方式来满足不同的 RPO/RTO 要求。

答： 主流的对象存储都是能够提供免备份功能的。一般对象存储都是分布式的架构，物理部件的故障不会影响的系统的运行，也可以通过跨站点复制实现站点级容灾。在逻辑保护方面，通过多版本功能可以实现误修改、误删除数据的恢复，也可以通过 WORM 功能来保证数据不会被恶意删除。

答： 针对于非结构化数据海量文件备份采用对象备份策略相对来讲会好些，因为对象存储扁平的目录结构在支撑海量文件上有先天优势，可以优化备份效率，且目前对象存储基本都已经实现多站点全局数据中心策略，除备份外还可以起到容灾的效果，当灾难发生时候可快速拉起存储，同时这种基于自身的备份策略避免了和备份软件集成的繁琐验证，降低建设周期。同时对象存储的备份介质的选择性也相对较高一些，如：异地的对象存储、公有云、光盘塔之类均可实现备份。

4，租赁云对象存储用于存储影像文件，是否需要本地备份？ 被问到一个问题，如果选择租赁公有云的对象存储，用于存储影像文件，是否需要本地备份？ 当时是忽悠过去了，想听听各位大拿的意见和建议。

答： 从数据安全的角度，建议还是本地有一份备份，更为安全妥当。另外从保证业务连续性的角度，建议应用也在本地有部署。

答： 取决于你的数据重要性，如果这个数据不能丢，不管你的租赁方给你讲他们有多可靠，你也需要有本地备份。同时，还需要考虑数据恢复的效率问题以及数据取回的成本问题。

答： 曾有某创业公司怒怼TX云，称其放在TX云服务器上的数据全部丢失，给其公司业务带来灾难性损失。 由此可见，一定需要进行本地备份，数据备份是最后手段，设备坏了可以换，数据丢了对公司来说是灾难性的。

二，非结构化数据方案选择

1，对象存储或 MPP 相对于 NAS ，其成本与收益是否平衡？

问题背景 ：非结构化数据迁移至对象存储或 MPP 系统后，此类数据的备份、恢复以及持久化保留相对于在传统存储上是否明显改善？主要收益如何？

答： 对象存储主要面向的是海量非结构化数据的管理，由于数量量大，导致的备份、恢复问题以及长久保存导致的数据安全性问题，对象存储都能够解决。相对于传统存储而言，数据量越大，对象存储的优势体现的越明显。从某些层面讲，对对象存储而言，管理 1PB 的数据，需要 1 个人就够了，当数据量增长到了 100PB ， 1 个人也能够管理。

答： 这是一个比较宽泛的问题，具体情况还是需要具体分析。传统 NAS 存在的局限主要包括：不支持更多的协议、容错不灵活、扩展不方便、元数据无优化等等，而这些是分布式解决方案的优势，再加上不需要数据复制而支持就地分析的优势，很多时候分布式是唯一的解决方案。而传统 NAS 的单流性能的优势，对于分布式或并行解决方案，需要采用闪存来提速，目前还会带来一定的成本上的提升。

2，对象存储，自建还是租用云上的更合适？

问题背景 ：保险公司对于非结构化数据，考虑采用分布式对象存储，可以考虑本地自建，或者租用云上的（例如阿里云的）对象存储，请问从成本和安全性、性能等方面考虑，如何做出比较科学的选择呢？

答： 金融行业一般考虑的顺序是安全性（监管要求）、性能、成本。如果存储的文件涉及敏感信息的，租用公有云肯定是不合规。

对于性能，自建和租用都不是问题，要求性能越高，投入也就越大，这是成正比的。成本没有对比过。

答： 云的话，初始成本低，可以按需购买，但无法符合金融行业的合规性要求，其次是上云容易下云难。

自建的话，初始成本高，且需要运维能力，轻松应对监管要求，能够实现一定的自主控制。各有利弊，看公司运营要求决定。从长久使用来看，自建和云综合成本不会有天差地别。

答： 抛开金融行业的合规性要求。保险且经济的做法是：

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

2 、使用主要以公有云为主，自建以备份为主，可不用太过考虑性能，公有云异常，能撑起业务即可。

3 、不管云还是自建，都建议自己搭建对象存储集群，可控性上的保障会比用公有云的产品强太多。也能有效减少后期的数据迁移成本。

3，对象存储产品的选型？

问题背景 ：在对象存储方面，闭源商用产品相比于以 ceph 为代表的开源商业产品之间，在市场份额，用户，方案成熟度，性能，扩展性以及其他功能等方面是否有对比数据可以参考？

答： 不管是对象存储，还是其它存储，选型的基础条件是：“选择适合自己的产品！ " 而判断什么样的产品才是适合自己的呢，很重要的一点，是看“生态”，一方面是有前景的技术，另一方面是领先的技术，其三是有足够的人 / 厂商相互认证支持。 Ceph 作为一个被广泛使用 / 抄袭的系统，提供了块 / 文件 / 对象的所有支持，是它的优势也是它的劣势。优势在于要什么都有，劣势就是：“万金油，什么病都治，什么病都治不好”，比如在元数据优化、就地多协议访问等方面都存在问题。另一方面，还有一帮人，天天等开源社区解决他们的 Bug 。这也是很多金融业的用户选择成熟商业产品的原因。

4，不同的保险公司数据量的差异比较大，如何能够选取正确非结构化解决方案的方法？

问题背景 ：在当前保险行业，针对不同的保险公司数据量的差异比较大。如何能够选取正确非结构化解决方案的方法？具体过程的分析和思考路径，已经遇到的坑有哪些，并且给出一些实际案例进行佐证。

答： 总体而言，建设思路需要根据业务发展的需求、企业内部的人员知识储备、架构发展方向等综合来看。目前我看到比较多的企业采用的做法是资源池化，在基础架构层面尽量通过池化、标准化来构建存储资源池，来降低运维的难度和复杂度。

答： 其实，就算是同一公司，非结构化数据也是十分复杂的，有效的数据存储、治理、共享、访问都需要在统一的架构下解决，这也是数据湖方案的重要作用，通过与后端存储架构与前端存储访问的解耦，数据湖平台对用户屏蔽了数据的复杂性。数据量本身也是建设中的难点，但数据湖方案通过前后一致的扩展方式，以及不停机的容量、功能扩展，确保能够实现“按需购买，即扩即用”，让系统建设“只顾目前的需求”就好了！

答： 不同的保险公司数据量的差异较大，是一个客观事实，即使是一家保险公司不同业务条线的数据也会存在不小区别。对于非结构化解决方案的选择，个人认为还是要根据企业自身情况出发，因地制宜，并没有一种万能的方案能够彻底非结构化数据的存储问题。

各保险公司非结构化数据常见的一个情况是， DC 刚筹建那会儿体量不大，单证类非结构化数据一般简单的采用传统 NAS 来存储，随着业务的发展，受制于 NAS 机头的性能限制，各业务系统对单证的存、取、备均不同程度出现效率低下的问题，系统出现瓶颈。

对于传统 NAS 向对象存储的切换，无非是一个长痛短痛的问题，但有一点是确定的，一切不结合业务的技术更新都是耍流氓。众所周知保险核心系统提供商就那么几家，各应用接口、核心版本几乎都是基于各司业务的定制，想一刀切不现实。因此，个人建议从传统 NAS 向对象存储切换过程中加入一个过渡方案，可以是分布式 NAS ，可以是存储资源池，亦或是其他方案，重点是平滑过渡，给业务一个缓冲时间，解决传统 NAS 的性能效率问题的同时尝试对象存储的建设，两手抓。

5，不同的保险公司数据量的差异比较大，如何能够选取正确非结构化解决方案的方法？

问题背景 ：保险公司的系统很多都是采用堆叠式建设的，不同年份，不同用途。存储资源也是比较分散。有些在本机，有些使用存储，有些用云。有些在后备中心，有些在 IDC 机房，有些在自己公司机房，给运维带来较多的工作量。

发展统一存储方案，我们也提出过，发现细化到各个系统时，就会与系统架构产生衝突。需要开发商做很多修改。有些费用还不少，有些会影响业务。综合权衡后，还是旧系统维持旧架构，新系统用新的统一存储。

非结构数据对存储的挑战是空间需求越来越快，保密要求越来越高，在这种环境下。可否分享一个用统一存储方案还是分散存储方案来来处理非结构化数据的差异，特别是风险角度，对存储安全架构上，要做什么特别配置。

答： 你现在面临的问题实际上就是数据湖架构着力解决的问题。

各个系统的存储之间互相隔离「孤岛」，数据湖让已有系统在不安装任何驱动 / 代理的前提下采用标准的访问协议将数据放置到数据湖中。

当数据放入到数据湖以后，一方面能够被传统的系统共享，另一方面也可以供新形态的应用使用。包括如深度学习这类的应用。

数据湖支持几乎所有主流的访问协议。其核心就是实现数据同专有系统之间的解耦。

补充一下：对于统一架构，我的理解就是指 Unified ，这种架构实际上就是传统的 NAS ，当初是为了满足大家在同一设备中实现 Block/File 而诞生的，只能提供相对简单的文件支持能力，无法满足数据湖架构对众多的协议需求。而对于数据安全上面，统一存储一般是基于传统 RAID 的，这种方式在数据越来越大，磁盘也越来越大的现在，越来越有问题，大量新的技术希望能解决这种问题。

数据湖支持预置策略，支持安全策略随时调整。另一方面，对于数据权限、数据共享这类的安全，商业产品都能够做到企业级，不用太担心。

答： 这个要看公司对云、自建机房、容灾中心、 IDC 机房的定位和将来的发展。其次就是对应用架构的梳理。假设在现有应用架构、数据中心架构保持不变的情况下，可以考虑用数据湖解决方案，既能在底层通过资源池化来简化运维提升利用率，又可以通过不同的协议接口对接新旧应用的需求。

6，对象存储的应用场景和行业内的应用标准？

问题背景 ：问题 1 ：在满足什么样的条件下选择使用对象存储比较合适？比如说影像文件数量或者说总的存储量？

问题 2 ：对象存储与分布式文件系统的应用场景，也有厂商向我们推荐使用分布式文件系统来做影像存储？

问题 3 ：如果选择对象存储，有哪些关键的技术指标需要关注？

答： 问题 1 ：对象存储的优势主要包括： Key 的方式使支持海量的数据处理，容易扩展，天生支持多数据中心，短链接方式适合第三平台应用、多协议访问等等。如果你的需求中有以上的一条或几条，就需要评估是否需要对象存储了。影像系统是保险业传统的 NAS 解决方案的战场，但近年来，大家都在迁移到对象平台，主要的原因是文件系统太大，跑不动了。一般来说，当一个目录下的文件数超过百万级别，从最佳做法的角度，可能就满足迁移的一个前提了。

问题 2 ：看你的主要应用。一般来说，对象存储主要使用对象协议，其它协议作为补充。分布式文件系统主要使用文件协议，同时支持其它协议，支持的对象协议一般是对象协议的子集。其二，你需要看应用，已有应用如果不改，一般来讲是支持文件的，这时候也可以选分布式文件系统存储影像，这也是主流解决方案。

问题 3 ：对象存储的产品选型，建议关注指标为：安全性、产品生态（可参见我另外一个关于选型的回复），兼容性、独到技术能力、扩展能力。

答： 关于第一个问题，我这边一般的判断标准是百万文件数量，就可以考虑使用对象存储。关于第二个问题，主要依据咱们的技术路线选择，在存储影像这个场景下，两者都可以使用。有些客户在整个系统架构上就在往多中心、多活架构上去走，所以他们最终选择了对象存储的技术路线。关于第三个问题，主要的技术指标主要关注扩展性，例如单一 Bucket 支持的对象数量，多活、基本性能。我这边接触的项目，从最终的使用上来看，一般是容量先用满。

7，对象存储的数据备份与恢复实现的方式都有哪些？

答： 主流对象存储均采用节点式横向扩展分布式架构，以实现从小规模到大规模（ 10+PB 级）的容量和性能扩展。为了实现海量非结构化数据管理，主流对象存储均采用分布式元数据管理方式，以使得存储系统在管理海量（亿级）文件时，能够实现访问性能的稳定性。

对象存储抛弃了传统的基于树状文件系统的管理方式，通过 Key-Value 的扁平式架构来管理海量文件，保障了海量文件下文件读写的性能。为了保证在分布式系统架构下的数据安全性，对象存储通常采用纠删码或者多份副本的方式预防磁盘、节点级的硬件故障，同时通过多站点复制，保证站点级故障下数据的可用性。

此外在海量文件环境下，传统的数据备份方案无法有效备份，对象存储采用多副本的方式进行逻辑故障防护。与传统文件存储相比，对象存储在海量非结构化数据长久保存场景下有着独特的优势。

三，非结构化数据迁移的相关问题

1，非结构化数据存储迁移后如何解决数据访问问题？

问题背景 ：若将非结构化数据由传统存储迁移至对象存储或 MPP 系统，数据的层次结构、目录层级以及数据访问方式均可能发生变化，业务系统对迁移后数据的访问存在巨大隐患。在规划时如何针对性解决此类问题？

答： 对象存储抛弃了传统的基于树状文件系统的管理方式，通过 Key-Value 的扁平式架构来管理海量文件，保障了海量文件下文件读写的性能。为了保证在分布式系统架构下的数据安全性，对象存储通常采用纠删码或者多份副本的方式预防磁盘、节点级的硬件故障，同时通过多站点复制，保证站点级故障下数据的可用性。对象存储通过 API 接口进行数据访问，应用或者客户端可以直接调用访问数据，更加便捷，支持 S3 、 HDFS 、 Swift 等多种协议。

对象存储经常被比作在一家高级餐厅代客停车。当一个顾客需要代客停车时，他就把钥匙交给别人，换来一张收据。这个顾客不用知道他的车被停在哪，也不用知道在他用餐时服务员会把他的车移动多少次。在这个比喻中，一个存储对象的唯一标识符就代表顾客的收据。当需要获取数据时，只需要告诉对象存储这个唯一标识符，剩下的检索工作均由对象存储本身完成。

由于访问方式上不同，涉及存储变更后应用系统也需要进行访问方式上的改造，需要有一定的过渡期，同时也要考虑老数据的迁移问题。

答： 在数据迁移的过程中，虽然数据的访问方式、数据的层次结构以及目录层级等会发生变化，但是整个过程都是可控的。在实际操作中，比较常见的有两种方案，一种方案是通过应用进行数据迁移，这种也是最推荐的方案，应用进行迁移的时候，可以根据业务的负载灵活的控制迁移速度，也可以在迁移过程中完成对每个对象数据的校验。第二种方案是由迁移工具进行数据迁移，这种情况下需要应用进行相应的配合，首先应用需要能够同时访问源存储和目标存储，并将新增数据写入到新的目标存储中，这样保证源存储内不会有数据的新增，同时通过迁移工具来进行数据迁移，并记录源和目标访问路径的变化，并在迁移完成后，交由应用系统来更新成新的访问路径，并确认从应用端能够正常访问目标存储。整个迁移视数据量的大小可能会分批迁移，从而保证数据迁移能够顺畅完成。所以我建议要讲数据迁移视为一个服务项目来根据实际情况来处理比较好。

在实际的项目里，源存储不一定是块、 NAS 这种存储，有可能是数据库、应用，所以具体到不同企业的实际情况，迁移方法可能有很大不同。

另外有的企业会在存储和应用之间设置一个轻量级数据抽象层，这个数据抽象层可以屏蔽底层数据存储的差异，对外提供统一的面向业务的应用访问接口，这个抽象层可以兼具数据迁移的功能，从而实现底层存储技术的更换，对上层的应用而言是没有任何感知的。

答： 数据迁移，这是一个老生常谈的问题。非结构化数据的迁移，其实也不是什么新事物。一般来说，有两种迁移方式，一种是对用户透明的迁移，用户不需要关心数据位置，这种方式需要考虑数据的指针管理；一种是对用户不透明的，需要访问不同的数据位置以获取数据，这需要用户端和数据存储之间协商数据的访问路径。这两种方式在我们的数据湖平台中均提供。两种方式各有优先考虑的重点，具体选用哪种方式需要考虑应用场景以及应用开发的相关问题。**

2，如何提高非结构化数据迁移的效率？

问题背景 ：非结构化数据迁移过程中，影像数据（如图片、 PDF 、影像件）等典型特征数据迁移速度极慢，迁移所需时间窗口非常长，在保证业务连续性的前提下，如何有效加速由传统存储向对象存储的迁移效率？

答： 数据迁移的速度受限于源存储系统、迁移程序、网络和目标存储系统。一般情况下源存储系统会成为瓶颈，同时要保证业务能够继续对外提供服务，迁移不能对源存储系统造成压力，所以迁移的窗口都会非常长。常见的处理方法是通过修改应用访问存储逻辑，所有新增数据全部写入到目标对象存储中，旧的源存储里的数据只用于读取，不会有任何的新增数据，同时通过应用或者迁移程序进行数据迁移。

除此之外，还有的做法是把源存储或者系统的数据通过备份或者复制的方式，拷贝到一套新的系统中，专门用于数据迁移，但是这种做法投入会很高，用的也比较少。

再者就是从应用架构上解决，在底层存储系统和前端应用之间添加一个轻量级的数据抽象层，这个抽象层可以对外提供统一的数据访问接口。这个抽象层也负责在不同的存储技术之间进行数据迁移，这样不管采用何种的存储技术，都可以灵活的进行处理。

具体采用何种方式更优，还是要取决于企业的实际情况，所以我比较建议把数据迁移当成是一个服务项目来处理。**

3，关于非结构话数据 存量数据如何从传统存储迁移都非结构化存储的过程，希望能否有经验可分享下？

问题背景 ：目前传统存储上存放海量影像数据，如果在规定变更时间内将存量数据从传统存储迁移至非结构化存储，希望能否有经验可分享下。

答： 这个主要还是要看源端存储和目标端存储采用的具体技术来进行选择。如果采用最通用的方案，一般有两种，第一种就是直接通过应用进行数据迁移，第二种就是通过外部的数据迁移工具来进行迁移。一般情况下，在文件数量巨大的情况下，在规定的变更窗口内是很难完成的，因为很多情况下，源存储或者说源系统没办法支撑大量数据的同时读取。所以思路会转变成，如何在不影响生产的情况下进行数据迁移，在这种思路下，一般情况是在迁移的过程中，应用会同时接入源端存储和目标端存储，同时将所有新增数据写入到目标端存储，这样源端存储不会有任何新增数据。接下来有两种处理方式，一种就是通过数据备份或者存储拷贝将数据在其他系统上拉起，作为迁移的源端，来尽快进行数据迁移，这样不会对现有系统造成影响，但是这样也有劣势，就是成本比较高。还有一种常见的做法就是在把现有系统作为源端，通过迁移工具进行迁移。总体而言由于应用在整个迁移过程中能够正常访问所有数据，所以迁移时间的长短，对业务是没有影响的，只是在迁移完成后，进行割接的时候申请变更窗口就可以了。

还有一种解决办法就是，在存储和应用之间引入一个数据抽象层，这个抽象层会对外提供一个统一的数据访问接口，来屏蔽底层存储技术。同时这个抽象层还可以进行数据迁移，这样保证不管底层存储技术如何变化，对外的服务是统一的。当然这个方法更多的是从应用架构上去进行处理，牵扯到的部门会非常多。

答： 我们提供包括基于快照、基于并行访问等等多种迁移工具，具体使用何种工具需要看现有的详细需求。所有的工具都有成功案例可参考。举例来说，针对变更时间窗紧张的客户，我们会在设备带宽允许的情况下，增多迁移器（ Migeration Agent ）的数量，以提升迁移速度。而快照方式，我们能够以中间联接的最高速度实现数据传输。

4，大量非结构化数据迁移的问题？

问题背景 ：现有保险影像系统中存储的非结构化数据至少是百万或千万个文件量级，想问下对于这种量级的文件，是否有稳妥的迁移方案，可以保证将所有数据完整迁移至对象存储，并且迁移后可以提供验证。

答： 我这边做过的项目里，一般迁移方案分两种，第一种是由应用进行迁移，第二种是以迁移服务项目的方式进行迁移。基本的迁移思路是新数据写入到对象存储，老的存储只用于读取，这样整个迁移的数据集就是一个固定的数据集，这样便于并发进行迁移处理，在整个迁移过程中，迁移工具会保证数据能够完整把数据迁移到对象存储。我比较建议把数据迁移当成一个迁移服务项目来看，因为迁移过程还是有很多需要协调工作来做。数据的验证的话，迁移工具是会来做。但是在最终割接以前，还是要请应用部门也进行一次数据验证。

此外有的企业会在底层存储和上层应用之间添加一个很轻量的数据抽象层，来屏蔽底层不同存储技术的差异，对外封装成一个面向应用的统一访问接口。同时这个抽象层会提供数据在不同存储或者不同存储技术之间进行迁移的功能。这样不管是底层存储技术如何变迁，对上层应用基本是没有任何影响的。当然这种做法需要从整个应用架构角度去设计规划。具体采用哪种方案还是要取决于每个企业自己内部的实际情况。

答： 采用数据湖的其中一个重要优势就是不再需要做数据迁移。而对于传统的解决方案，对于大量的非结构化数据迁移，是一个费时费力的工作。针对这种情况，我们提供了一些工具，帮助用户来做数据迁移，如基于快照和迁移、基于并行访问的迁移等等，需要根据具体的情况来选用。

四，非结构化数据解决方案相关问题

1， DellEMC ECS 对象存储相比 Ceph 商用方案、 HDS 、华为等对象存储产品的优势有哪些？

答： 1 ） Dell EMC 在 Garner 的分布文件 & 对象存储的魔力象限中多年一直处于领导象限的第一位置。这是市场对 Dell EMC 对象存储的认可。 ECS 扩展了 S3 的支持：允许用户在 bucket 层面自定义元数据（ meta data ） . 这些自定义的 Meta data 跟系统级的 Meta data 一道，可以让用户以更简单的方式从 bucket 中批量过滤并提取符合一定条件的对象。

2 ）华为的 FusionStorage 通过融入 OpenStack 云基础架构，兼容 Amazon S3 。 CEPH 是开源的文件，对象，块存储的技术方案，它在支持方面弱于 Dell EMC ECS 那样的商业化对象存储方案。

3 ） HDS 的对象存储 (HCP) 采用双控存储作为对象存储基础，对象存储 的 横向扩展会受限 。另外，它也不支持 HDFS (ECS 提供 HDFS 的协议支持）。**

2， PowerScale 适用的保险场景有哪些？

答： PowerScale 作为数据湖平台的核心组成部分，在保险行业有很多的应用场景，从传统的影像系统、数据分析到新型的用户画像、智能风控，都可以使用 PowerScale 来搭建数据湖平台。

PowerScale 继承了 Isilon 近 20 年的积累，通过更强悍的闪存性能，更经济的数据缩减，更全面的协议支持，更懂你的数据管理，是非结构化数据湖平台的不二之选。

3，能否谈谈 PowerScale 与 isilon 在技术原理上的差异？

问题背景：能否谈谈 PowerScale 与 isilon 在技术原理上的差异？在 EMC 数据湖方案中这两者的地位又如何？

答： PowerScale 是新的平台，是基于 Isilon 的基础上的一次进化。 PowerScale 采用 OneFS 9.0 ，同时提供 PowerScale 专用硬件和 Isilon 硬件的支持，二者支持混装。 OneFS 9 在继承 Isilon 以前的优点前提下，提供了诸多新的特性，如 S3 的支持，在线数据缩减等等。

在数据湖解决方案中， PowerScale 会是我们 Isilon 、 ECS 、 SDP 的有力补充，提高了需求覆盖以及更好的投入产出比。