申请专栏作者
您的当前位置:主页 > 数据挖掘 > 正文

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

2018-11-02

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换算成Spar