在这表示我们想分享我们的经验在火花工作负载迁移最关键的集群内部Pinterest之一。这包括两个重要的软件栈的变化。首先,从HDFS改为S3存储层。第二,资源调度程序从便转向了纱线。我们将分享我们的动机的迁移、经验在解决一些技术挑战如s3性能,s3一致性,s3的访问控制来匹配HDFS的特性和性能。我们在作业提交更改地址的差异便和纱线。同时,我们优化的引发性能分析和选择最合适的EC2实例类型。毕竟,我们取得了良好的性能结果和一个平滑的迁移过程。
——嗨,每个人,我的名字叫鑫姚明,以及丹尼尔。今天我们想把你的旅程迁移集群Pinterest火花。
一个简短的介绍自己。我叫鑫么,我是一个技术主管在Pinterest广告团队。以前,我花了许多年的Facebook和Hulu。我的很多工作是专注于构建大规模分布式计算系统。——这是丹尼尔戴。我是一个科技领导Pinterest数据团队。我为Apache蜂巢和PMC成员猪,和在此之前,我在Cloudera Hortonworks和雅虎。
——在今天这个演讲,我们将讨论以下主题。首先,我们将分享我们的大数据平台的高级概述。bob体育客户端下载学习火花加入这个平台的性能。bob体育客户端下载接下来是S3最终一致的模型我们已经处理,然后我们将谈论主存储器HDFS和S3的区别,调度系统方法和纱线,我们将结束我们的谈话在Pinterest火花是如何使用。
首先,让我们来高水平的概述我们在Pinterest大数据平台。bob体育客户端下载
从搜索到眼睛,机器学习的建议,几乎每一个团队在Pinterest依赖于大数据平台以某种方式或另一个。bob体育客户端下载大数据平台团队负责提供一个bob体育客户端下载稳定、可靠、高效的生态系统工程师和分析管理他们和转换数据。Pinterest一直在构建我们自己的内部大数据平台利用开放源码项目。bob下载地址bob体育客户端下载项目我们使用HDFS存储,便和极光资源管理、调度火花蜂巢和转眼间数据处理、编目。
大数据平台,Pinterebob体育客户端下载st是不断发展的,以满足不断变化的需求的用户和做,并保持更新最新的前沿技术。在过去的一年,我们的团队一直致力于大数据平台迁移到我们的下一代。bob体育客户端下载这个图表所示的高水平,最重要的变化是改变我们的资源管理和调度系统便和交换我们的主要存储在HDFS S3。现在迁移完成了伟大的资金从性能方面的改善效率,从生存到节省成本,我们将分享我们的胜利和学习在这个谈话。
作为任何大数据平台,性能总是扮演bob体育客户端下载最重要的角色之一,我们一直在努力提供一个平台,只能运行工作性能和效率。
我们构建下一代大数据平台,提高性能和效率是最重要的目标之一。bob体育客户端下载我们不能改善,如果我们不知道是我们老集群的瓶颈。所以我们做的第一件事是确定我们的老集群的性能瓶颈。
我们把一个数据驱动的过程发现的瓶颈集群通过仪表盘指标,我们在内部和外部,我们已经确定了系统范围为我们的集群是本地磁盘IO性能瓶颈。如图表所示,没有足够的本地磁盘IO经常减慢火花工作由于缓慢的洗牌,进而使工作和整个工作流程缓慢,进而使IO结果更稀缺。如你所见,这是一个恶性循环性能,没有人希望看到在他们的系统。
理解这个项目,我们首先需要理解为什么当地IO火花性能是很重要的。所以本地磁盘通常是由几种不同的方式使用。火花洗牌写数据到本地磁盘,然后火花写也读本地磁盘为还原剂洗牌数据服务。火花也泄漏数据本地磁盘,当记忆不够大,对一些操作,如排序。
让我们看看这个问题通过一个简单的例子。这是一个简单的聚合查询,本质上它是协调表独特的id和每个id的最大价值。
核心执行映射器阶段,洗牌阶段和减速机阶段。假设我们有9 k映射器和9 k还原剂。每个映射器读取一个输入的流程和洗牌的数据存储到本地磁盘。有一个洗牌阶段,慢慢的去相同的id相同的减速器。所以每个减速器将计算每个id的最大值。为了做到这一点,每个减速器会跟所有的9 k映射器和要求标识该减速器负责,所以总的来说,所有9 k还原剂会谈9 k映射器,81年将会有会议连接。
一台机器可以同时运行多个映射器,所以如果我们放大,只关注一个地图,一台机器,在这种情况下,这台机器有30映射器,所有这些30映射器共享相同的本地磁盘的机器。mapper写道一个洗牌数据一次,然后阅读9 k *或9 k还原剂。所以总的来说,30映射器需要270 k的IO操作。只有那些操作发生在同一时间,因为每个映射过程大致相同的数据量和在同一时间完成它们。这是太多的操作我们的机器在太短的时间内。
那么,我们如何在我们自己的集群优化这个工作?
我们做了很多优化工作,其中一个最有帮助我们做优化就是调整映射器的数量和还原剂,以组合成大的小的数据操作。这里,这里是一个例子,我们减少了很多帖子映射器和还原剂9 k 3 k。
如果我们放大,只集中在一台机器上,在这种情况下,这一台机器只有10映射器,所有那些10映射器共享相同的本地磁盘的机器。一个映射器写洗牌数据一次,读3 k乘以3 k还原剂。总,火花会30 k本地磁盘操作,这是九倍比以前更好。这里需要注意的一点是,减少映射器的数量和还原剂也降低了并行性的工作。如果太低,工作不能充分利用所有分配的资源可以扭转性能。
去年,我们花了整整一个月来优化我们的最重要的工作之一。操作与四次改进优化结果是可怕的,但它需要大量的管理。这两个(低语)与数据量增加规模不太好,他们不能很容易应用于其他工作。所以不够高度本地磁盘IO如何使火花工作很难宽优化和系统性能瓶颈把造成严重的每一份工作运行这个集群。
新的集群,所以当我们没有建立新的集群,我们决心移动,删除一个集群广泛的性能瓶颈,这样每个团队可以更加关注建筑产品而不是处理性能的影响问题。
的性能瓶颈时,我们多次测试,试图找到最好的硬件配置我们的火花工作负载。最后,我们必须把它所有我们所有简单的两次5 d是本地磁盘优化带来了本地磁盘IO每秒,从3 k高达40 k。
我们的工作非常喜欢新集群,尤其是新的容易实例,乔布斯看到了25%的平均运行时改进,这是没有一个实际的结果或调优。洗牌重做什么工作甚至成本35%实现从90分钟到57分钟。的所有集群智慧挖掘本地磁盘IO的影响我们所做的绝对是最大的电脑。
如果只有一件事我希望你能记得
从这个演讲,这是衡量优化之前,我说。过早的优化是万恶之源。在我们的例子中,我们做了调查和测试用我们自己的工作负载集群。所以我们没有猜瓶颈或相反,数字告诉我们,本地磁盘IO是我们集群的瓶颈。所以切换到本地磁盘优化实例类型是一个完美的选择对于我们的工作负载。做自己的工作负载的任务自己的集群,识别瓶颈的工作负载并试图优化。
在优化方面,你可以有三个水平,集群级别、火花水平和工作水平。所以你可以优化火花在集群级别所有工作负载运行在该集群中获益。我们的例子是提高本地磁盘IO模式,性能提升25%平均所有的工作没有任何实际结果执行。接下来是火花,似乎调优映射器的数量,还原剂,CPU内存,这样做可能会产生更大的性能提升不知道工作的业务逻辑。最后但并非最不重要的,是在工作层面上,所以你可以去理解业务逻辑的工作,尽量简化,通过也许删除不必要的加入或聚合。
接下来,我想谈谈S3一致性模型,我们必须为下一代集群。
我们的新集群的一个大的变化是切换主存储在HDFS S3。
这两种存储系统不同模型一致。HDFS文件系统,这是强烈的一致。变化是立即可见,相反,提高了对象存储服务,最终一致,没有保证或改变立即可见到客户机。这可能会导致文件丢失问题甚至无需用户知道。
这是一个例子的HDFS和S3写后读一致性。在这个图表中,从左到右的时间表,右边从上到下都是客户,HDFS读者和S3读者。在这个例子中,阅读客户端发送一个颜色绿色HDFS和S3是关键。为我们不断阅读,HDFS读写完成后客户在任何给定的时间。他们总是为最终一致的读者,读颜色为绿色S3读者现在必须返回T2,绿色RT3,现在,另RT4最终,他们将始终返回红绿色。
这是什么意思,火花?这里是一个例子,一个火花工作写出五个文件在同一个文件夹中,但与另一个火花工作试图读取这些文件创建后不久,这是只写四个文件,而不是5个。在这种情况下,读者火花工作甚至不知道,错过了一个文件。
那么接下来的问题是,这是经常发生的吗?一般来说,机会清单不一致的S3文件夹是超级,超级小。S3, AWS的团队进行了一项测试,显示不一致的几率不到一百万分之一。我们还进行了S3内部一致性测试,甚至不到一个5000万的机会。
当我们设计解决这个问题,有很多考虑和平衡。
两个最重要的是写一致性和读一致性。写一致性是工作是否可以写输出始终没有错过,复制或损坏的文件。读一致性是这份工作是否能读文件到一个文件夹中,没有比它应该读或多或少的线。考虑清单也仍在继续。
正如你可以看到,有很多需要考虑。
我们有很多不同种类的解决方案相比,从简单的到非常复杂的。我不会花太多时间覆盖每个其中之一。快速的外卖,S3不是一个HDFS时需要考虑的有很多你想从HDFS开关或S3,特别是如何处理模型变化一致。您可以使用此表以后作为参考来做自己的决定时处理S3一致性模型。
为了解决这个问题,我们用了一个折衷的解决方案,结合了三种不同的工具。我们使用S3提交者,提高编写和一致性,然后我们将讨论不同的提交者之间的区别在这个演讲。我们也使用数量的文件监控以确保关键任务阅读时不要错过任何文件。在平行于这,我们广泛使用数据质量框架,以确保数据具有较高的数据质量标准。这帮助我们防止数据问题引入的所有不同的原因,包括S3。这种方法适用于我们目前的工作,不需要大量的努力来实现。然而,这种方法需要工作流主人意识到这个问题,他们需要采用这两个工作流。对于我们的长期的,我们正在调查系统实现一个复杂的解决方案来解决这个问题,比如工作从Netflix和数据从数据砖湖。
,丹尼尔将讨论我们的主要存储的两个之间的区别,HDFS和S3。——好吧,谢谢,鑫。现在让我们来比较一下性能HDFS与S3。在我们的演员,HDFS和S3实现类似的吞吐量。
然而,元数据操作是S3慢得多,特别是对移动。S3移动操作本质上是一种复制,然后删除。不幸的是,我们使用业务很多火花。这是简单的逻辑的应用程序来说,尤其明显,但产生大量的输出。例如,我们的一个火花流媒体应用,持续卡夫卡流存储。HDFS,微批处理运行时间是30秒。为我们的S3,增加到55秒。在大多数情况下,应用程序是什么都不做但移动文件,这批微管的成本。
让我们仔细看看外包移动操作。第一个移动操作每个火花是常见的应用程序,也就是说,任务成功完成后,提交者任务将文件从文件夹任务文件夹未遂。成功的完成工作之后,提交者的工作再次将它输出文件夹。这是必要的,因为我们不希望失败的结果是可见的工作或任务。
此外,一些应用程序需要更多的移动操作。例如,在我们的动态分区表插入,火花将节省工作输出到一个临时文件夹模式输出文件通过蜂巢表位置之前,这是因为火花需要找出哪些分区新添加的火花工作所以它可以添加相应的修补的元数据。
然而,我们负担不起这些移动操作,我们需要找到一些优化。有几个现有解决方案第一两个移动操作,文件输出提交者算法2,跳过这工作水平移动操作。它输出文件从任务尝试文件夹直接工作产出提交者的任务。所以我们不需要再提交者的工作。这个远程工作水平移动操作,任务水平移动操作仍然存在。然而,工作水平移动操作相比,任务级并行发生,所以它是较小的一个问题。此外,Pinterest内部,我们已经有我们的主任输出用于mapper-reduce提交者,也消除了任务级的移动操作。直接输出提交者写文件的工作输出直接尝试每一个成功的任务。然而,第一个S3方法存在某种程度的数据正确性问题。文件输出提交者算法2,如果失败,清理工作做得不恰当,成功任务输出会离开那里,所以下游工作将读取完整的结果。 For direct output committer, if file, if job fail and cleaning up is not done properly, downstream job will read incomplete or even corrupted output. A better solution is Netflix S3committer, which uses S3 multi-part upload API to upload files directly to job output location without leaving incomplete or corrupted output, even if the job fail. We also realize as a more sophisticated solution such as Netflix iceberg, which is the successor of S3committer. However, the focus of iceberg is to provide the transactional support, which we don’t really need in our use cases and also S3A committer from recent Hadoop distribution. However, it is tightly integrated with S3 guard, which adding extra operational complexity, so we decided to adopt S3committer, which solve our need, but still simple enough.
S3committer利用AWS S3多部分上传API。它包括三个阶段,首先,用户需要调用,启动多部分上传实例化,然后多部分上传一部分API,它将文件上传到S3。最后,一个轻量级完成多部分上传将告诉AWS编织成一个完整的路径,使其可见。如果出了任何差错,用户将调用abort多部分上传删除部分上传。有两个操作技巧多部分上传API的工作,首先,unfinish路径文件保存在一个单独的S3 bucket的暂存区域,直到完成多部分上传或中止调用多部分上传。并不少见火花应用死在中间,所以没有完成或中止多部分调用上传。用户无法看到部分使用通常的S3命令上传,但AWS仍将收取你的部分上传。所以重要的是要建立S3生命周期策略删除部分在一定时间后上传。第二,中止多部分上传,需要一个单独的S3许可,我们需要明确授予的许可在实践中我们经常错过。
在任务,S3提交者将编写输出到本地磁盘。任务提交者内成功后,S3上传提交者将调用路径API输出从本地磁盘上传到S3,然而,输出是不可见的,S3提交者将调用完成多部分上传后提交者的工作成功完成所有任务。这两阶段提交者像方法将确保没有损坏或不完整的文件如果应用程序失败,与此同时,我们不需要任何文件。此外,S3提交者还上传路径并行文件我们可以实现更好的吞吐量,HDFS。
不过,我们还有一个移动操作剩下的动态分区的插入。它是必需的,因为我们需要一种方法来追踪新文件夹添加火花的应用程序和添加分区元数据只蜂巢元存储的文件夹。例如,火花应用程序产生一个新的文件夹,S = 2, 2020年1月12日临时目录中。通过暂存目录清单,火花可以挑选新的文件夹,S = 2, 2020年1月12日,并将Apache元数据添加到蜂巢元商店,以及磁盘文件夹移动到表,在表的位置。摆脱这种移动操作,我们改变S3提交者写一个表级别跟踪文件记录火花产生的分区工作。工作完成后,我们可以阅读跟踪信息,我们可以阅读找出相同的信息的跟踪文件。然而,如果多个火花应用程序写入表的同时,可能会有冲突的跟踪文件。我们还没有找到一个通解,相反,我们使它在某些应用程序中,我们知道只有一个应用程序写入表在任何给定的时间。
移动操作的删除和增加上传流量,微批处理运行时从55秒减少到11秒,甚至比HDFS。
通过切换到S3,我们也遇到一些S3具体问题,速率限制503错误是一种常见的,AWS可以分区S3 bucket和前缀的支持。他们甚至可以建立一个cron作业分区一个前缀未来还不存在。然而,我们不觉得这个解决方案是一个可靠的和实现我们自己的工作水平和工作水平指数后退逻辑在S3中提交者。我们也做文件上传部分的并行度可调,所以用户可以调整他们的工作,最大化吞吐量,同时,避免超过S3。
这里是一个列表,改进我们的Netflix S3committer。除了速率限制和并行上传文件,航母路径文件上传我们刚刚提到的,我们还添加ETag检查元数据上传,以确保文件的完整性,我们修复长时间运行的应用程序的线程池泄漏。我们也删除本地生成的输出任务尽快上传完成后我们可以节省一部分本地磁盘使用情况。
切换到S3的最大好处是节省费用,我们将成本减少80%相比,HDFS。同时,S3取得更好的SL。S3的清洗SLO 4、9个可用性和11,九耐久性。相比之下,我们的HDFS只能实现3、9可用性在我们当前的支持水平和耐用性的差异甚至更高。
除了存储、资源调度器的新集群也不同,其他集群使用便和新集群使用纱。
有几件事情我们便错过。首先,我们可以管理里面每个服务便,但在纱,运行服务,如管理员、蜂巢元店是独立的实体。便加上Java sub-metering系统,极光提供了很多功能。它可以支持一个简单的工作流,长时间运行的工作和cron作业非常好。它支持滚动重启和内置应用程序健康检查。所有这些都是在纱线失踪,我们必须依靠外部工作流系统如弹球和非洲式发型,有时实现这些定制的脚本。
有几件事情我们喜欢纱,它提供了所有正在运行的应用程序的全局视图。它有更好的队列管理组织隔离,更重要的是,我们的其他集群已经使用纱线。
有更好的能见度和队列隔离,我们可以用纱更积极地使用资源,计算机集群便相比成本较低。
在我们结束谈话之前,我还有两张幻灯片显示的当前状态引发Pinterest内采用。
我们仍在早期阶段在所有Hadoop集群的负载。火花代表资源使用总量的12%。我们有一些火花流用例,但主要是批处理。
我们正积极将我们的高工作负载迁移到火花SQL。与此同时,我们正在寻找我们的级联/滚烫的工作迁移到火花,我们采用象博士火花。在我们的代码评审过程中,我们与内部集成一个股票象公制,还包括一些特性引发镜头。作为一个副作用,象博士明显增加火花历史服务器的负载,我们正在改善服务器性能历史。
