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

对象存储抛弃了传统的基于树状文件系统的管理方式，通过Key-Value的扁平式架构来管理海量文件，保障了海量文件下文件读写的性能。为了保证在分布式系统架构下的数据安全性，对象存储通常采用纠删码或者多份副本的方式预防磁盘、节点级的硬件故障，同时通过多站点复制，保证站点级故障下数据的可用性。
对象存储通过 API接口进行数据访问，应用或者客户端可以直接调用访问数据，更加便捷，支持S3、HDFS、Swift等多种协议。
对象存储经常被比作在一家高级餐厅代客停车。当一个顾客需要代客停车时，他就把钥匙交给别人，换来一张收据。这个顾客不用知道他的车被停在哪，也不用知道在他用餐时服务员会把他的车移动多少次。在这个比喻中，一个存储对象的唯一标识符就代表顾客的收据。当需要获取数据时，只需要告诉对象存储这个唯一标识符，剩下的检索工作均由对象存储本身完成。

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

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

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

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

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