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

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

正所谓“数据迁移无小事”，是什么痛点促使eBay决定要启动数据仓库迁移这项工作?eBay在数据仓库迁移的过程中做了哪些尝试?又得到了哪些经验和教训?为了进一步了解eBay将数据仓库从Teradata迁移到Spark过程中的实践和经验，我们与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节省了一半的内存资源。

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

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

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

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

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

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

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

根据自动化需求，定义和采集元数据，并对元数据进行分析。提取出迁移目标表和作业的属性，比如表的大小、相关SQL文件及脚本的复杂程度，作业Pipeline信息，数据血缘等。

根据元数据分析结果制定整体迁移策略，划分自动迁移的scope，并决定迁移的顺序 。除非复杂度过高，默认采用自动迁移。无依赖关系的表先进行迁移，上游表迁移完成后才开始下游表的迁移。

创建目标表及所需中间表。

准备静态测试数据，包括目标表的前一天数据、当天增量数据和当天数据。比对动态数据是相当麻烦的，静态数据则方便得多。

把 Teradata SQL 翻译成Spark SQL。基本思想是将Teradata SQL语句解析成逻辑计划，再将逻辑计划反向转换为Spark SQL的语句。

结合表的大小等属性以及Spark集群的参数特征，生成优化的Spark作业配置参数。

将原始包含Teradata SQL的pipeline转换成调用Spark SQL的pipeline。

启动pipeline进行集成测试，验证各个作业和整个pipeline的正确性。

部署到生产环境。包括代码发布、表的建立、历史数据初始化、pipeline上线和定时调度、以及在生产环境的测试。

在连续多天数据比对通过后(默认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年，领导团队研究各种前沿的硬件技术加速云和大数据计算。

来源：InfoQ

标签： 大数据 大数据架构 代码 服务器 脚本 开发者 数据分析 网络

版权申明：本站文章部分自网络，如有侵权，请联系：west999com@outlook.com
特别注意：本站所有转载文章言论不代表本站观点！
本站所提供的图片等素材，版权归原作者所有，如需使用，请与原作者联系。