1 年将 30PB 数据迁移到 Spark，eBay 的经验有何可借鉴之处？

AI 前线导读：eBay 使用 Teradata 已经有二十年的历史，这个数仓系统中积累了 60PB 数据和上万张核心表，他们支撑着 eBay 最核心的商务逻辑和站点功能。从今年开始，eBay 开始将这个庞大的数仓由 Teradata 向 Spark 做迁移，使用 eBay 自己开发的工具，迁移过程中 90% 的工作都可以由自动化完成。与此同时，研究人员通过优化 Spark 框架，节省了一半的内存。

正所谓“数据迁移无小事”，是什么痛点促使 eBay 决定要启动数据仓库迁移这项工作？eBay 在数据仓库迁移的过程中做了哪些尝试？又得到了哪些经验和教训？为了进一步了解 eBay 将数据仓库从 Teradata 迁移到 Spark 过程中的实践和经验，InfoQ 与 eBay 大数据架构师俞育才聊了聊。

Teradata 在过去的二十年为 eBay 提供了非常优秀的数仓服务，支撑起了 eBay 庞大的业务规模。二十多年积累下来的数据已经将数据仓库变得非常庞大，所谓“牵一发而动全身”，哪怕只是微小的改动也会牵涉大量数据和业务逻辑，更何况是数据仓库迁移这样的大动作。

为什么决定迁移？

俞育才表示，随着业务的发展，原有的模式体现出了一些不方便的地方，这些问题促使 eBay 开始尝试数据仓库迁移的工作。

首先，技术上不够灵活。eBay 有很多自己特有的场景，供应商的软件很难为此去定制，或者需要 eBay 去适应供应商的路线图，这存在很大的局限性。如果使用开源软件，可以主动地参与开发，为自己的需求做深度的定制，更好地满足业务的发展。

其次，通过开源软件可以大大扩展数仓的能力。传统的数仓就是做批处理，但是现代的数仓是个很宽泛的概念。除了批处理，eBay 还需要处理实时数据、做图计算、做机器学习。不可能要求 Teradata 来提供这么多的功能。

另外，eBay 还可以基于开源软件对成本和性能做极致的优化。早在 2014 年的时候，eBay 就开始尝试使用开源软件。刚开始，开源软件的成本也是很高的。随着持续地优化，成本下降得很快。到 2018 年，开源软件的开销已经和供应商的专有软件差不多了。按照这个趋势，明年的开源系统的 TCO 甚至可以超过专有软件。”

最后，从公司的角度讲，也希望有更加多样化多元化的投资。

Spark 是新数据仓库的最优选择

下定了迁移的决心，下一步就要开始技术选型工作了，市面上开源的大数据框架、数据仓库那么多，eBay 最终选择了 Spark。

问及个中缘由，俞育才表示：“我们想要打造一个真正的现代化数仓，除了支持超大规模数据处理，还要能够支持实时化和智能化。Spark 提供了一站式数据处理的能力，不仅可以做传统的批处理，还可以做流处理、图计算和机器学习，这非常符合我们的期望，也是其他系统所不具备的。其次，Spark 的性能非常好。这得益于它强大的内存计算能力，以及 Catalyst、Tungsten 带来的诸多优化。另外，Spark 的社区很强大。Spark 是 Github 上最活跃的大数据框架之一，各种问题都可以得到很快的反馈。最后，在兼容性方面， Spark 对 SQL 有非常好的支持，使得我们的分析师可以很方便地迁移到 Spark 上。随着 2.0 的发布，Spark 已经日趋成熟，我们认为在这个时间点做迁移是个非常正确的选择。”

技术选型方面，eBay 做了很多尝试。一开始尝试的是 MapReduce 和 Cascading，但它们的开发周期太长了。而且分析师的强项并不是编程，他们需要花费很大的精力去学习怎么开发一个好的作业。接下来，团队又尝试了 Hive。但是 Hive 的性能不是非常好，一些案例并没能跑出来，并且 Hive 也不支持流和机器学习。Presto 在数据量不大的情况下，是可以做内存计算的，性能也很不错，但是大查询可能会直接失败，因为它是为交互式查询设计的，容错并不是第一考虑。

综合以上这些，Spark 几乎是一个不二选择。在做原型的时候，eBay 大数据团队找了一些非常核心也相对比较重的作业，用 Spark 去跑，发现不仅仅是跑下来了，而且调优之后，性能成本都还不错，这给了整个团队很大的信心。

需要 1000 个人月的数据迁移如何从不可能变为可能？

数据仓库的迁移主要包含两方面工作，一个是表的迁移，另一个是作业的迁移。

eBay 第一期迁移的数仓就有 30PB 之大，包括 5000 张的目标表、20000 张的临时表和 50000 个作业。经过估算，如果是手动迁移，大概需要 1000 个人月，相当于 50 个数据工程师，专职做迁移也需要两年，这是非常大的开销。所以必须做自动化迁移。

另一方面，表和作业之间是有依赖关系的。比如，想要把一张目标表迁移过来，需要把它的依赖表都先迁移过来。同时还要搞清楚依赖表用的是什么时候的数据，是当天的，还是前一天的，这是作业上的依赖。正是因为存在这样的依赖关系，eBay 采用了分层进行的自动化迁移方案，首先那些没有依赖的表和作业，然后是一级依赖，二级依赖，以此类推。

除此之外，并不是所有的表都适合做自动化迁移。在老的数仓里面，有些表和作业并不是按照标准流程构建的，这些例外情况往往不大方便在自动化框架中做统一处理。这时候，就需要和相应的开发人员沟通，或者让他们去做修改来符合标准流程，或者由他们自行手动迁移。综上所述，eBay 制定出了一个以自动化的分层迁移为主，辅之必要的手动迁移的混合迁移方案。

基于 eBay 的经验，俞育才总结出了企业在制定数据迁移方案时最需要考虑的几点问题：

1. 软硬件基础设施的架构和实现。在硬件层，eBay 采用了计算存储分离的结构，这会直接影响到接下来的服务器选型、网络拓扑及带宽设计等。在软件层，需要选择合适版本的 Hadoop、Hive、Spark 等组件。

2. 资源容量。迁移一个 30PB 的 Teradata 集群需要规划多大的 Spark 集群？在 Teradata 上，一般使用 CPU-Seconds 作为资源的度量。在开始迁移后，团队发现 Spark 集群上的内存消耗是很大的，成为了主要瓶颈，所以使用 Memory-Seconds 作为主要的资源度量。根据业务的实际情况，将 Teradata 的 CPU-Seconds 换算成 Spark 的 Memory-Seconds 就可以估算出需要的集群规模。

3. 数据质量。数仓迁移不仅仅是迁过去就了事了，还需要保证作业结果的正确性。在大规模数据的情况下，这是个相当棘手的问题，有很多细节需要考虑。

4. 迁移的效率。为了加快迁移，eBay 开发了很多的工具来帮助提升迁移的效率。这包括一套自动化的迁移框架，大部分的自动化迁移都是通过这个框架完成的，同时框架的各种功能会以 Restful API 的方式暴露出来，团队还做了一个界面去调用这些功能，这就使得手动迁移的部分也可以尽可能高效。

5. 优化集群。优化对于迁移是非常重要的，因为迁移的时候集群的资源通常都很紧张，一个优化良好的系统就可以在有限的资源中容纳更多的作业。为此，eBay 研发了两个主要的技术来做性能的优化。一个是 Spark 的自适应执行（Adaptive Execution），它可以动态的优化执行计划；另一个是 Indexed Bucket，它是对数据物理布局的优化。这两个优化为 eBay 节省了一半的内存资源。

尽管团队已经预先为大型数据仓库迁移可能会面临的问题设计了应对方案，但在真正启动数据仓库迁移后，依然遇到了很多挑战。俞育才给我们举了几个例子：

“第一，大规模数据下的正确性验证。我们可能会直观地认为，双跑验证就可以了。尽管理论上是这样，实际情况往往会复杂很多。首先，数据源是不断变化的，目标表依赖的任何一张源表数据发生了变化，结果就会不一致。所以，双跑的时间点很重要。其次，即使数据源固定，跑多次结果未必是一致的。比如，在 Spark 中有个 UDF，可以给返回每一行加上个 ID。但实际上，这并不是一个幂等操作，因为 Shuffle 不保证每次返回行的顺序，所以每次编上 ID 都是不一样的。对于这样的列，我们就不能做比较。类似这样的问题还有很多，都需要特别注意。

第二，非标准流程作业的迁移。在老的 Teradata 数仓中，大约有 10-15% 的作业并不是按照标准流程创建的，这些作业无法做自动化迁移，或者自动化的成本很高。所以，在初期做规划的时候，要尽可能收集到足够的信息，把他们都标识出来，然后尽早地联系相应的开发，或者修改作业，或者做手动迁移。

第三，开源软件的企业级特性的支持。一些企业级软件提供的易用功能，现在的 Spark、Hadoop 还没有提供。比如：监控和调试信息还不是很完善，排错起来不是那么方便；对分析师来说，他们也缺乏一个好的 IDE 帮助他们做开发。这并不全是 Spark 的问题，我们自己开发了很多外围的组件来帮助改善这些问题。”

eBay 在数仓建设方面经验比较多，在大的方向上没有特别多意料之外的状况，但有些问题还是挺值得注意的。俞育才强调道：“各个系统虽说都支持标准 SQL，但实现的细节上是有些差异的。比如字符集编码，大家都支持 Unicode，但实现的方式却不一样。Teradata 使用的是 UTF-16，Spark 使用的是 UTF-8，做工具的时候需要考虑到。再比如 case sensitive，我们一般的理解就是列名，表名的大小写是否敏感，但是在 Teradata 里面，它还支持查询的内容是否大小写敏感，迁移到 Spark SQL 以后，我们就需要做些特殊的处理。”

迁移工作 90% 自动化是如何做到的？

俞育才对 eBay 整个数据仓库的自动迁移工作流程进行了梳理，主要包括以下 10 个环节。

1. 根据自动化需求，定义和采集元数据，并对元数据进行分析。提取出迁移目标表和作业的属性，比如表的大小、相关 SQL 文件及脚本的复杂程度，作业 Pipeline 信息，数据血缘等。
2. 根据元数据分析结果制定整体迁移策略，划分自动迁移的 scope，并决定迁移的顺序 。除非复杂度过高，默认采用自动迁移。无依赖关系的表先进行迁移，上游表迁移完成后才开始下游表的迁移。
3. 创建目标表及所需中间表。
4. 准备静态测试数据，包括目标表的前一天数据、当天增量数据和当天数据。比对动态数据是相当麻烦的，静态数据则方便得多。
5. 把 Teradata SQL 翻译成 Spark SQL。基本思想是将 Teradata SQL 语句解析成逻辑计划，再将逻辑计划反向转换为 Spark SQL 的语句。
6. 结合表的大小等属性以及 Spark 集群的参数特征，生成优化的 Spark 作业配置参数。
7. 将原始包含 Teradata SQL 的 pipeline 转换成调用 Spark SQL 的 pipeline。
8. 启动 pipeline 进行集成测试，验证各个作业和整个 pipeline 的正确性。
9. 部署到生产环境。包括代码发布、表的建立、历史数据初始化、pipeline 上线和定时调度、以及在生产环境的测试。
10. 在连续多天数据比对通过后（默认 7 天）发送通知给到表的负责人开始准备交接工作 ，即正式将 Teradata 的 pipeline 停止而采用 Spark 的 pipeline。

上面中提到的第 1 到第 8 步均已实现自动化，第 9、10 步由于涉及到生产环境，根据流程管理的需要，由相关同事半自动化地完成。

俞育才表示，实现自动化难度最大的环节是对元数据的抽象和定义。“因为自动化迁移项目的时间线非常紧张，一些数据转换的模式我们一开始没有考虑到，相应的元数据就没有收集，这会给后期的自动化带来不小的麻烦。另外从技术上看，自动化 SQL 翻译工具，依赖分析工具也是比较复杂的部分。”

对应上面说的每个步骤，eBay 都有相应的自动化工具：Metadata Analyzer，Table Creator，Data Mover，SQL Converter，Spark SQL Optimizer，Pipeline Generator， Data Validator 等等。这些工具基本都是 eBay 大数据团队自研的，其中还包括一个基于 Zeppelin 的集成开发环境 Dev Suite。

使用 eBay 自己开发的工具，最终数据仓库迁移过程中 90% 的工作都由自动化完成了，数仓迁移原来预计需要的 1000 个人月锐减到了 250 个人月。

人工参与的部分主要包括：自动化工具的开发和维护；非标准化流程作业的迁移；无法自动装换的 Teradata 功能，例如 Recursive Query；数据模型和 pipeline 的重构；性能的调优与优化。

当然，如此高的自动化完成率自然也给大数据工程师带来了与以往不同的挑战。传统的手动迁移任务，一般的数据工程师就可以完成，而自动化迁移会需要我们的工程师不仅仅对数据熟悉，还要具备软件开发的能力。

俞育才表示，未来完全自动化意义不是特别大，因为有一些特殊场景出现的频率不是很多，为它们做专门自动化就不是很有必要。

对于正如火如荼发展中的企业来说，如何保证数据仓库迁移过程中线上运行的业务不受影响？俞育才也给出了 eBay 经过实践得到的经验：

• 首先，环境隔离。eBay 的 Spark 环境和 Teradata 环境是完全隔离的，正在使用的 Teradata 不会受到影响。
• 其次，严格的数据比对。新的任务使能以后会和 Teradata 有一个长达七天的双跑验证。
• 最后，灰度上线。任务切换到 Spark 的 pipeline 后设置一个观察期，如果发现有问题，可以立马切换回 Teradata 的 pipeline。

结语

经过一年的努力，第一期约 30PB 的数仓迁移已经基本完成。接下来，一方面，俞育才所在的大数据团队将会将工作重心放在对 Spark 的改进和优化上，例如更好地支持 Teradata 的语法和特性、自适应执行、缓存、交互式查询等；另一方面，他们也将继续推动 eBay 的现代化数仓建设，使之更加实时化、智能化。

采访嘉宾

俞育才， eBay 大数据架构师，负责 Spark 数据平台的设计与优化。12 年软件开发经验，Apache Spark 的活跃开发者，熟悉系统软件的性能分析与调优，基于 Spark 设计和实现了自适应执行引擎和层次化存储。在加入 eBay 之前，俞育才在英特尔工作了 9 年，领导团队研究各种前沿的硬件技术加速云和大数据计算。