Uber的工程团队对其数据复制平台进行了改造，使得该平台能够每天在混合云环境以及本地数据湖中传输数拍字节级别的数据，从而有效解决了由于工作负载快速增长而带来的扩展性问题。这一平台是基于Hadoop的开源Distcp框架构建的，目前它能够每天处理超过1拍字节的数据复制任务，并完成数十万项作业，其处理速度、可靠性以及可观测性都得到了显著提升，这使得数据分析、机器学习以及灾难恢复等工作能够在前所未有的规模上顺利开展。
Distcp是一个开源框架，它利用Hadoop的MapReduce技术，能够并行地在多个节点上复制大型数据集。文件会被分割成若干块，然后分配给在YARN容器中运行的任务进行处理。资源管理者负责分配计算资源，应用主管会监控作业的执行情况并协调文件的合并过程，而文件提交者则会在目标位置组装最终的文件结果。Uber的HiveSync团队通过对这一架构进行优化，使得它能够更好地处理规模达数拍字节的数据量：他们将一些准备工作转移到了应用主管节点上，同时并行化了文件列表生成和提交流程，从而提高了小规模数据传输的效率。
HiveSync这一技术最初是基于Airbnb的ReAir项目开发的，它通过批量复制和增量复制的方式，确保Uber的HDFS系统与云数据湖中的数据保持同步。对于规模超过256MB的数据集，HiveSync会通过异步任务并行地执行Distcp复制操作，并有专门的监控线程来跟踪复制进度。随着每天需要复制的数据量从250TB增加到了1PB以上，数据集的规模也从30,000个扩大到了144,000个，HiveSync开始面临一些延迟问题，这些问题威胁到了服务水平协议的要求，因此进一步优化运营流程和架构变得十分必要，这样才能更好地支持Uber的云迁移战略以及其主动-被动结合的数据湖管理模型。
HiveSync的架构示意图：使用Distcp进行数据复制的流程（来源：Uber官方博客文章）
为了应对扩展性挑战，HiveSync团队对Distcp框架进行了进一步优化：他们将那些消耗大量计算资源的任务，比如文件列表生成和数据分割操作，从HiveSync服务器转移到了应用主管节点上，这样一来就减少了HDFS客户端之间的竞争，使得作业提交的延迟时间降低了90%以上。同时，Copy Listing任务和Copy Committer任务也被并行化处理，这样就可以同时处理多个文件，而且还能保持文件的原有顺序，这使得文件列表生成的延迟时间缩短了60%，而文件提交的延迟时间则减少了97%以上。对于那些只需要传输少于200个文件或512MB数据量的小规模作业，Uber团队利用Hadoop的特定功能，让Copy Mapper任务直接在应用主管节点的JVM环境中运行，这样就避免了每天需要启动大量容器的问题，从而进一步提高了YARN系统的效率。
超过50%的Distcp作业都被分配给了同一个映射器来处理（来源：Uber博客文章）
这些优化措施使增量复制能力提高了五倍，从而使HiveSync在Uber进行从本地环境到云环境的迁移过程中能够顺利完成超过300 PB的数据复制任务，且没有出现任何问题。改进后的监控功能，包括作业提交情况、数据复制进度以及提交器的相关指标、内存使用情况以及数据复制的成功率等，帮助工程师们更好地监控工作负载状况，并及时预防可能出现的问题。通过压力测试、采用断路器机制、优化YARN配置以及重新安排任务执行顺序，有效解决了内存不足导致的错误、作业提交量过大以及数据复制任务运行时间过长的问题。
展望未来，HiveSync团队将重点致力于进一步提升并行处理能力、优化资源管理机制以及提高网络传输效率。计划中的改进措施包括：并行处理文件权限设置和输入数据的分割工作、将计算密集型的提交任务移至Reduce阶段进行处理，以及实现动态带宽限制功能。Uber打算将这些优化方案以开源补丁的形式分享出来，从而帮助更广泛的社区更好地应对大规模混合云环境下的数据复制挑战。工程团队指出，即使在较小的改进程度上，也能在我们这种规模的应用环境中带来显著的性能提升。这些努力充分体现了在构建复杂的多区域数据传输系统时，所需的运营创新能力和工程技术水平。