Scribd平台工程总监R Tyler Croy的客座博客人们往往不会对数据平台感到兴奋。人们通常认为这很像公路基础设施：没有人会考虑从A点到B点对他们有多重要，除非情况非常糟糕。想象一下当我开始听到用户的声音时我的惊讶："哇，太棒了"，"我等不及要让我的整个团队都接受它了"，或者"我们真的很兴奋！"这种热情并没有降低迁移项目的挑战性，但它肯定会使它更令人愉快。在Scribd，我们已经有了一段时间的"传统数据平台"：Hadoop混合了HDFS和少量的Hive。随着时间的推移，业务需求发生了变化，我们现在需要更多的机器学习，更多的实时数据处理，以及对团队协作交付新数据产品的更多支持；我们需要比"传统数据平台"更好的东西。我们的新数据平台是气流、数据链、三角洲湖、，还有AWS Glue Catalog，这是一套功能强大的工具，已经显著提高了我们的开发速度和协作能力。从"旧"到"新"的过渡过程中，成功和挫折各不相同，因为我们重新构建平台，摆脱了复杂性和技术债务。传统的数据平台不仅仅是我们部署的技术，它还部署在一个固定的数据中心基础设施上。数据中心中的一组静态机器在批处理工作负载高峰时快速地搅动数据，然后在空闲时浪费金钱和精力。随着公司和我们需求的增长，数据平台的"高峰"变得越来越明显，对开发者来说也更加痛苦。有些人会在去吃午饭之前，或者在一天结束的时候，提出一些问题或工作，希望他们回来后能得到结果。我刚到公司不久就注意到了一个特别严重的反模式：一些机器学习工程师会准备他们的数据集，把它们放到个人的aws3存储桶中，启动支持GPU的实例，训练他们的模型，然后在月底向他们的经理提交报销申请。如果说开发人员的恐怖故事还不够，那么操作上的情况就更糟了！许多传统的数据平台技术很难与Chef等自动化工具相结合，因此，我们的遗留数据平台缺乏适当的管理，而我们的其他生产基础设施也无法享受到。每次我们向环境中添加更多的计算机时，根据请求的不同，这个过程需要一两天的时间。因此，我们只会在真正需要时添加节点，或者在驱动器和系统故障需要时添加节点。我们传统的数据平台浪费了开发者和基础设施工程师的时间。想到如果所有这些有才华的人都致力于推进我们业务目标的项目，我们本可以做些什么，我不寒而栗。数据基础设施现代化：评估选项到2019年年中，Scribd已经聘请了一个"核心平台"团队，负责构建"实时数据平台"，以及一个由数据科学家和机器学习工程师组成的全新团队。投资于遗留数据平台的各方一致同意，我们必须"到云上"。再加上全公司范围内的迁移到AWS的计划，我们的潜在选择相对较少。我们需要一个在AWS上运行良好的数据平台，它依赖于S3，能够很好地运行我们的查询和激发作业，能够为开发人员提供某种形式的自助服务，并且能够实现我们甚至还没有想到的新的机器学习工作负载。我研究的选项可以分为两类："看起来像一个传统的数据平台，但是有了S3，而且在云端！"（不是很有说服力）。数据块因为我们知道我们的存储选项将以某种形式或方式涉及aws3，所以我们已经开始研究我们的海量数据仓库和工作负载如何与S3进行互操作。对于数据平台的使用，S3是一个很好的工具，但它并不像它的名字所暗示的那么简单。S3的最终一致性可能会给通过类似表的接口（例如Hive）访问的Parquet文件造成许多问题。其中一些问题可以用S3Guard解决，但是额外的架构复杂性让我们有些厌倦。在这段时间里，我们很幸运地注意到了Databricks对Delta湖的开源。对三角洲湖的初步评估让我们大吃一惊；我们找到了我们的储藏层。Delta Lake最终成为了通往数据链的门户，而这并不是我们最初的计算平台评估的一部分。随着我们对数据块的挖掘越来越多，我们发现了两个致命的特征：事实证明，Databricks笔记本电脑对于开发人员和分析师来说是一个杀手级的功能，他们迄今为止一直在通过共享查询来复制和粘贴到Hue中。在Databricks中优化的Spark运行时，它有助于更快地执行查询和作业，帮助我们尽快获得开发人员的结果。将Spark工作负载迁移到云端：计算成本和收益在AWS中，时间直接等于金钱。在AWS中你越早关闭一台机器，你花的钱就越少。在Databricks的销售团队的帮助下，我能够为我们现有的Spark工作负载提出一个成本模型，如果我们要将它们直接装载到AWS中而不进行重大的更改。他们声称，对于大多数传统的Spark工作负载，优化率为30-50%。"我说30%只是为了保守。出于好奇，我重构了我的成本模型，以考虑到数据块的价格和潜在的Spark作业优化。在调整了数字之后，我发现在17%的优化率下，Databricks将大大降低我们的AWS基础设施成本，从而为Databricks平台本身的成本买单。在我们最初的评估之后，我已经对Databricks提供的特性和开发人员的速度改进很感兴趣。当我运行我的模型中的数字时，我知道我不能不采用数据块！生产中从我们基于数据中心的数据平台到Databricks的道路是一条漫长的道路，我们仍在继续前行。到今天为止，我们已经将整个数据仓库回填到了Delta Lake中，这一迁移很方便地解决了HDFS中严重的小文件问题。我们有一点定制的工具，它使数据从数据中心到三角洲湖保持同步，同时我们开始转移一些更重的批处理任务。尽管批量任务迁移的道路漫长，但我们已经有新的项目直接部署在数据块上：曾经由Hue和Hive提供服务的即席内部用户查询正在被强大的Delta缓存支持集群所取代。那些以前在顺化花了很多时间的人已经开始通过共享笔记本与同龄人进行合作了。新的Spark Streaming/Delta Lake项目已经投入生产。以前不可能实现的工作负载已经开发和部署。对于我们流入卡夫卡的一些数据流，我们部署了Spark流应用程序，将这些数据直接引入Delta Lake，在那里，工作和用户在数据创建后几分钟内就可以查询到数据。对于这些工作负载，用户以前必须等待24小时的批处理周期才能完成，但现在他们可以在2-3分钟内从Delta Lake获得新的生产数据。当许多人看到这一点时，他们的想法立即转向"我可以将哪些数据更改为流以获得更实时的洞察力？"突然间，团队路线图中出现了多个项目，其中包括"为X生成数据流"或"从Y生成数据流"。对我来说，交付数据基础设施和工具的团队的成功在于，当您的用户都对使用基础设施回答他们的问题感到兴奋时，以及当他们开始考虑使用平台来解决全新的问题时。我只想说，我已经对我们的结果感到满意了！然而，一切并不像我所希望的那么乐观：我们的管理政策仍然落后于不同团队在采用数据块方面的繁荣。我们已经为开发人员提供了解决问题的极好的工具，但是我们还没有制定相应的政策来防止这些用户启动过大或价格过高的集群。这样做的能力存在于平台中，但是当考虑到一些EC2浪费与人们的时间相比的成本时，我们在尽可能快地让集群进入人们的手中方面犯了错误。下次做得更好大规模数据基础设施的重新平台化并不容易。迄今为止，我们最大的痛苦是自己造成的。我们在配置单元和基于配置单元的查询上进行了大量投资，提供了一系列定制的udf，所有这些都需要迁移到Spark和Spark SQL上。我们编写了一些工具来帮助我们自动地将配置单元查询和模板转换为sparksql，后者成功地将80%的配置单元工作负载自动转换。另外的20%我们必须手动转换，这是令人沮丧的工作。迁移过程还发现了比我自豪地承认的更多的技术债务。许多Spark工作负载仍然依赖于Spark 1（！），这些作业不使用配置单元的表接口，而是直接与HDFS通信（！），以及测试大批量作业，原始开发人员忽略了为这些作业编写任何测试（！）。就我个人而言，我期待着有一天，第一个加入的新员工永远不必看到遗留的数据平台。他们会欣喜若狂地不知道，曾经有一段时间，你不得不将查询片段复制粘贴到聊天室，等到明天才能获得新的数据，或者在完成工作时浪费时间无所事事。在即将到来的SPARK+AI峰会上，请听R.Tyler Croy谈论Scribd向基于云的流媒体数据平台的转型。在这里免费注册。Scribd也在聘请有才华的远程工程师来帮助改变