今年是信创的大量交付的年份，很多金融和政务服务都在进行去IOE或者说国产化，目前我正在对接一个客户的大数据系统从CDH迁移到国产化的大数据平台上来。

故事分为以下三个阶段：

1.来自前方架构师的信息同步

对客的架构师跟客户侧进行沟通，对接了客户前期的需求，并推动客户体验我们自己的大数据平台。

下一步就是讨论数据迁移的过程。

我这边就是负责数据迁移工程的。

迁移工具正在打磨过程中，当前方有客户需要进行cdh迁移时，领导很上心，想把这个项目打造成一个标杆业务。一是检验迁移工具在大数据平台上交付质量的评估，二是向其他客户展示我们自身实力，可以顺利做好cdh的迁移切换。

当我听到架构师侧同步过来的消息时，内心还是有点紧张，一是自己对迁移工具还没有正式使用过，二是当前对客户当前环境还有些疑问，无法评估是否能顺利完成迁移，三是领导关注度高，如果搞砸了，自己在这个团队的未来估计就没了。

2.研发自己客户调研的信息

经过几天的思虑，架构师也要求研发自己去客户现场调研。

我去到客户现场后，情景与自己预料的场景完全不符。

到客户现场后，客户首先让我给他们解决问题，因为他们当前实时链路和离线链路都没通，严重影响到他们后续的大数据平台的切换。

客户的核心诉求在于，借着这波国产化的大潮，把他们的大数据业务架构进行升级。

客户目前的架构是：基于sqoop进行全量离线数据同步，将分布式关系型数据库中的数据同步到hive数据仓库中。然后跑任务出报表。这个过程是每天都需要执行的，这就导致了长时间的数据同步和任务跑批过程。

客户未来架构升级：将iceberg替换hive，将实时增量同步替代全量数据同步，实现计算资源降本增效，提升业务侧报表的时效性。

这里可以看出，客户对数据迁移完全不care，他们的核心诉求在第一阶段中架构师并未同步到产研侧。

3.后续客户的平台替换过程

客户调试成功实时同步链路后，架构升级可行性没问题。

而针对数据的迁移，他们完全可以通过离线同步链路来实现，不需要额外的数据迁移工具来实现。

4.对我们的启发

把握客户核心诉求，才能让产品交付不走弯路。