如何可靠地扩展您的数据平台以实现大批量

黑色星期五和网络星期一（或者我们称之为BFCM）是一年中最大的销售活动之一。对于Shopify和我们的商家来说，这也是最重要的时刻之一。放眼来看，今年，我们在超过175个国家/地区的商家在周末的销售记录中打破了创纪录的5.1亿美元以上的记录。

那是很多销售额。这也是很多数据。

Shopify数据平台BFCM的平均吞吐量提高了150％。我们作为Shopify数据平台工程（DPE）团队的使命是确保我们的商人，合作伙伴和内部团队能够快速可靠地访问数据。商家每小时赚一百万还是一百万都没关系；他们需要不间断地访问有关其业务的最相关和重要的信息。虽然这是全年必须的，但在BFCM期间会增加赌注。

创建一个可以承受当年最大销售事件的数据平台，意味着我们的平台服务需要随时准备应对负载的增加。在本文中，我们将概述为可靠地扩展我们的数据平台而准备的方法，以准备这场盛会。

Shopify的数据平台是流程和系统的跨学科组合，可收集和转换数据以供内部团队和商家使用。它允许通过熟悉的管道访问数据：

从Shopify的任何部分提取任何格式的数据。从Shopify的操作表中提取“原始”数据（例如，浏览量，结帐和订单），而无需进行任何操作。然后，数据将符合磁盘上的Apache Parquet格式。

批量或流处理数据，以形成业务洞察力的基础。数据科学家开发的模型“丰富”了批数据，并在Apache Spark或dbt中对其进行了处理。

将数据传递给我们的商人，合作伙伴和内部团队，以便他们可以使用它们快速做出重大决策。我们依靠内部的流和服务应用程序集合以及支持Shopify中面向商家的分析的库。它们得到了BigTable，GCS和CloudSQL的支持。

平均每个月，Shopify数据平台处理约8800亿条MySQL记录和1.75万亿条Kafka消息。

作为工程师，我们现在想征服所有挑战。但这并不总是现实或具有战略意义的，特别是当并非所有数据服务都需要相同水平的投资时。在Shopify，分层服务分类法以广泛的声明方式帮助我们确定可靠性和基础架构预算的优先级。它基于对我们商家的潜在影响，如下所示：

例如，此服务在外部至关重要。商户经营业务的能力

此服务是一项实验，尚处于早期开发阶段，或者可以一次性使用。例如，表情符号生成器

最高层是最高优先级。我们的提取服务（称为Longboat和Speedboat）以及面向商家的查询服务Reportify是方法1中的示例。

如上所述，每个BFCM Shopify数据平台都会收到前所未有的数据和查询量。我们的数据平台工程师今年做了一些预测工作，预测的流量是2019年的近两倍。DPE面临的挑战是确保我们的数据平台已准备好处理该数量。

对于BFCM，系统可靠性的主要风险与吞吐量要求成正比。我们称其为吞吐量风险。它使您更接近数据管道的前端，因此受影响最大的系统是我们的提取和处理系统。

有了如此激动人心的预测，我们面临的风险是数据服务面临前所未有的吞吐量压力。为了做好BFCM的准备，我们必须为即将到来的数据海啸做好准备。

我们为可靠性工程团队分配了摄取和处理系统的第1层和第2层服务准备工作。以下是我们准备受BFCM量影响最大的系统的步骤：

数据提取服务的主要操作优先级可以不同于批处理或流服务的优先级。我们先确定服务正在优化的内容。例如，如果我们要从保留期限有限的Kafka主题中提取消息，那么我们知道，提取系统首先要确保没有消息丢失，因为它们的消耗速度不够快。批处理服务不必担心，但是可能需要优先安排一个数据集与另一个数据集的交付。

对于Longboat，作为批处理数据提取服务，其主要目标是确保原始数据集在其数据新鲜度服务水平目标（SLO）定义的间隔内可用。这意味着只要提取的每个数据集不超过八个小时（默认的新鲜度SLO），Longboat就能可靠运行。对于我们主要的查询服务服务Reportify来说，其主要目标是尽快获得查询结果。它的可靠性是根据延迟SLO来衡量的。

确认主要目标后，您需要确定可以“调高或调低”以维持这些目标的内容。

在Longboat的情况下，提取作业是使用批处理调度程序进行编排的，因此第一个显而易见的杠杆是作业频率。如果发现原始生产数据集是陈旧的，则可能意味着提取作业仅需要更频繁地运行。这是特定于服务的杠杆。

Longboat的另一项特定于服务的杠杆是Longboat的“重叠间隔”配置，该配置将提取作业配置为冗余地提取记录的某些重叠范围，以捕获较晚到达的数据。指定时间（以小时为单位）。

内存和CPU是我们可以控制的通用计算杠杆。 Longboat和Reportify在Google Kubernetes Engine上运行，因此可以要求作业请求更多的原始计算，以在计划的时间间隔内完成预期的工作量（在此讨论中，忽略了总的计算约束）。

现在我们有了一些已知的控件，我们可以使用它们来故意限制服务的资源。举例来说，为了模拟持续不间断的N倍吞吐量增长，我们可以旋转基础结构旋钮，以使我们有1 / N的计算余量，因此我们处于N倍的标称负载下。

对于Longboat的模拟，我们操纵了其“重叠间隔”配置并将其增加了三倍。在不改变工作频率的情况下，每个表突然看起来要吸收大约三倍的数据。吞吐量增加了两倍。

对于Reportify，我们利用我们的负载测试工具来模拟一些真正令人困扰的吞吐量方案，发出越来越多的查询量，如下所示：

如果对这些问题的答案中有任何一个令我们不满意，那么可靠性路线图就这样写出来：我们需要将自己的方法设计成对这些问题的满意答案。这将我们引向下一步。

服务的可靠性取决于它从中断中恢复的速度。当您的CTO盯着服务的可靠性指标时，恢复是由机器执行还是由人员执行并不重要！在故意限制资源之后，操作渠道变成了（受控）地狱，现在该该采取行动了，好像是真实的生产事件一样。

谈论缓解策略可能是一篇博客文章，但以下是我们发现最重要的原则：

每个警报必须可以直接采取行动。只是说“窗帘着火了！”不用说“把它扔出去！”等于噪音。

假设缓解睡眠的人将阅读缓解说明。简单的指令执行速度最快。

如果在受控负载测试期间有任何歧义或意外行为，则说明您发现了新的可靠性风险。您的服务不如预期的可靠。对于第1层服务，这意味着其他所有内容都会下降，这些风险应立即解决。

即使单独行动，也总是要沟通过度。其他工程师将全力以赴为您奋斗。

既然我们知道过载的基础架构会发生什么，我们就可以做出明智的决定，即该服务是否承担实际的吞吐量风险。如果我们绝对敲定该服务，并且在不冒其主要目标的风险的情况下跳过了微笑，那么我们可以不理会它（甚至缩减规模，这也会使CFO感到微笑）。

如果我们对自己的恢复能力不抱有信心，我们将发掘新的风险。该服务的开发团队可以使用此信息来计划弹性项目，并且我们可以共同扩展我们的基础架构，以最大程度地减少过渡期间的吞吐量风险。

通常，为了在基础架构方面做好准备以覆盖我们的能力，我们会进行能力规划。您可以在博客上详细了解Shopify的BFCM容量规划工作。

我们对Longboat和Reportify的缓解策略是健康的，需要对我们的负载平衡操作进行微调。

我们应该扩展集群以应对不断增加的负载，不仅来自购物者，还来自我们一些有趣的东西，例如BFCM Live Map。

我们需要调整系统，以确保商家可以通过其管理员的“分析”部分中的“实时视图”实时跟踪其在线商店的表现。

有些作业可以使用某些调优，而某些内部查询可以使用优化。

最重要的是，我们刷新了对数据服务可靠性的理解。理想情况下，没有比这更令人兴奋的了。无聊的可靠性研究是最好的。

我们希望以后能更定期地进行这些练习，因此准备BFCM并不是特别有趣。在本文中，我们以吞吐量风险为例进行了讨论，但是对数据完整性，正确性和延迟也存在其他风险。我们的目标是也能脱颖而出，因为数据的增长速度快于工程团队。 “每月成千上万的记录”变成“四百万”的速度比您预期的快。

经过几个月的严格准备，系统地改善了我们的索引，架构，查询引擎，基础架构，仪表板，剧本，SLO，事件处理和警报，我们可以自豪地说BFCM 2020顺利进行了！

在重要时刻，我们追踪了每个峰值，使我们的眼睛盯着利用率图表，并不时转动旋钮，只是为了保持利润。只有极少数的小事件不会影响商人，买家或内部团队-主要是由于我们平台的性质和我们的备用能力而导致的自我修复案例。

取得成功并非偶然，而是因为勤奋的计划，经验，好奇心以及最重要的是团队合作。

Arbab是Shopify七年的资深人士，担任可靠性工程负责人。在加入数据平台之前，他曾帮助启动Shopify付款，一些首批Shopify公共API和Shopify的零售产品。 99％的Shopifolk跟随他！

Bruno是DPE TPM，与站点可靠性工程团队一起工作。他拥有100％成功完成BFCM的记录，并计划保持这种状态。

有兴趣帮助我们扩展并解决有趣的问题吗？我们计划在2021年通过聘用2,021个新技术职位来使我们的工程团队增加一倍。在这里了解更多！

来自构建和扩展Shopify的团队的故事，Shopify是领先的基于云的多渠道商业平台，为全球超过1,000,000家企业提供支持。