采访 & 撰稿|Natalie
嘉宾|俞育才
编辑|Debra
出处丨AI 前线
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 甚至可以超过专有软件。”
最后,从公司的角度讲,也希望有更加多样化多元化的投资。
下定了迁移的决心,下一步就要开始技术选型工作了,市面上开源的大数据框架、数据仓库那么多,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 的经验,俞育才总结出了企业在制定数据迁移方案时最需要考虑的几点问题:
尽管团队已经预先为大型数据仓库迁移可能会面临的问题设计了应对方案,但在真正启动数据仓库迁移后,依然遇到了很多挑战。俞育才给我们举了几个例子:
eBay 在数仓建设方面经验比较多,在大的方向上没有特别多意料之外的状况,但有些问题还是挺值得注意的。俞育才强调道:“各个系统虽说都支持标准 SQL,但实现的细节上是有些差异的。比如字符集编码,大家都支持 Unicode,但实现的方式却不一样。Teradata 使用的是 UTF-16,Spark 使用的是 UTF-8,做工具的时候需要考虑到。再比如 case sensitive,我们一般的理解就是列名,表名的大小写是否敏感,但是在 Teradata 里面,它还支持查询的内容是否大小写敏感,迁移到 Spark SQL 以后,我们就需要做些特殊的处理。”
俞育才对 eBay 整个数据仓库的自动迁移工作流程进行了梳理,主要包括以下 10 个环节。
上面中提到的第 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 经过实践得到的经验:
经过一年的努力,第一期约 30PB 的数仓迁移已经基本完成。接下来,一方面,俞育才所在的大数据团队将会将工作重心放在对 Spark 的改进和优化上,例如更好地支持 Teradata 的语法和特性、自适应执行、缓存、交互式查询等;另一方面,他们也将继续推动 eBay 的现代化数仓建设,使之更加实时化、智能化。
采访嘉宾
俞育才, eBay 大数据架构师,负责 Spark 数据平台的设计与优化。12 年软件开发经验,Apache Spark 的活跃开发者,熟悉系统软件的性能分析与调优,基于 Spark 设计和实现了自适应执行引擎和层次化存储。在加入 eBay 之前,俞育才在英特尔工作了 9 年,领导团队研究各种前沿的硬件技术加速云和大数据计算。