如何评估数据管道的成本性能

从德国#1天气门户网站了解设计和评估成本-性能基准的最佳实践。

当然我们也会进行几次基准，我们知道最好的基准是您的查询在您的数据上运行。但是你在评估中参照的是什么呢?答案似乎很明显——成本和与云架构路线图的集成。

然而，我们发现许多企业只是度量工作流中单个服务的成本，而不是整个工作流的成本。当比较不同的架构时，运行一个完整的工作流将展示所消耗的总资源(数据引擎+计算+辅助支持功能)。

如果不知道每个体系结构的持续时间、作业失败率以及支持作业所需的人工工作量，比较两个体系结构中单个组件的列表价格最多只会产生误导。

Wetter.com案例分析

wetter.com是DACH地区排名第一的B2C天气门户网站，每月拥有高达2000万的独立用户，以及完整的跨媒体生产。为了利用数据并将其货币化，wetter.com创建了一个名为METEONOMIQS的新业务部门。有了METEONOMIQS，该公司现在可以通过开发和销售数据产品给商业客户，从他们的数据中产生新的收入流。METEONOMIQS提供天气和基于地理的数据科学服务，以解码天气、消费者行为和零售、快消品、电子商务、旅游、食品和广告客户使用的许多其他因素之间的相互关系。

METEONOMIQS的挑战

METEONOMIQS选择了亚马逊EMR来处理他们的数据，从原始摄入到清洗和汇总，为下游API用户服务。最初，EMR显然是同类中最好的基于云的Spark引擎，适合他们的AWS堆栈。

然而，这种体系结构很快就达到了它的极限。数据管道需要大量的手工工作来更新行和清理表，需要大量的DevOps工作来维护，并且由于长时间的开发周期限制了使用ML的潜力。在将ML模型从DS转移到DE时，糟糕的笔记本体验和错误风险使得同时支持多个模型变得更加困难。

然而，业务面临的最大风险是无法实现符合gdpr的自动化工作流，例如，轻松删除单个客户。相反，METEONOMIQS不得不手动清理数据，导致停机数天。GDPR的罚款高达母公司的4%全球这给母公司ProSiebenSat.1带来了很大的风险。

构建测试

METEONOMIQS求助于Databricks，看看是否有更好的方法在Amazon S3上构建数据摄取、处理和管理。与Databricks合作，他们设置了一个测试，以查看在Databricks上运行该管道的情况:

矢量分析	功能要求
设置	用户能够设置iam访问角色 能够集成到他们现有的AWS Glue数据目录作为一个亚矿
管道迁移	能够将代码从现有的管道直接迁移到Databricks，而无需进行重大的重新设计。注意:他们没有在这个测试中处理代码优化
GDPR合规	能够使用(测试)客户/应用程序id构建一个表，可以删除以满足GDPR要求(被遗忘的权利)。 能够设置自动删除作业，从所有中间和结果表中删除id，并验证结果
清理/更新	能够重新构造先前更新/清理过程的示例。 根据上面的例子建立一个清理程序，并对受影响的记录进行更新
易用性	通过使用内置功能和外部绘图库(如matplotlib)，可以轻松地在databrick -notebook中构建可视化。 能够通过将两个笔记本电脑连接到一个集群来处理多个项目/流
ML模型管理	从当前环境中选择一个现有模型，并将训练过程的代码迁移到Databricks 进行培训运行，并使用MLFlow跟踪服务器跟踪所有参数、指标和工件 可选:以当前使用的专有格式存储工件 在MLflow model Registry中注册(最佳)模型，将其设置为“生产”状态并演示批准过程 通过MLflow模型注册表演示从数据领域(模型构建)到业务领域系统(模型生产)的切换
总成本	使用PoC生成的数据和其他信息(进一步的管道/数据大小/用户数量/…)来预测基础设施成本，包括Databricks、计算和存储。

基准测试结果

不停机的数据更正/增强

矢量分析	EMR-based架构	Databricks-based架构
设置	✔	✔
管道迁移	- - - - - -	✔
GDPR合规	✘ GDPR在停机时间内删除数小时/数天	✔ GDPR在几分钟内删除，没有停机时间
清理/更新	✘ 需要停机数天	✔
易用性	✘	✔
ML模型管理	✘	✔ 改善数据科学家和数据工程师/开发团队之间的协作
总成本	80%的EMR成本来自专门的开发和分析集群，导致不可预测的计算成本。 DataOps需要大量开发人员资源来维护。	通过集群共享，METEONOMIQS可以更有效地使用云资源 但更重要的是，他们现在可以做新的用例，如自动化GDPR合规，并以以前不可能的方式扩展他们的ML。

对于METEONOMIQS, Databricks架构的主要收益是:

1. 添加由于高水平的开发成本而没有部署在EMR上的用例(例如，自动数据更正和增强)
2. 大大减少了管道所需的人工维护量
3. 简化和自动化GDPR合规流程，现在可以在几分钟内完成，无需停机，而以前需要停机数小时/数天

此外，该团队在EMR体系结构中有很高的AWS资源消耗，因为在EMR上不可能实现共享环境。因此，团队成员必须使用专用的集群。Databricks为所有开发人员提供的共享环境，加上在共享项目(即笔记本)上工作的能力，从而更有效地利用人力和基础设施资源。

从数据科学家到数据工程团队的ML模型交接非常复杂，导致ML代码出现分歧。有了MLflow，团队现在可以轻松地移交模型并随时间跟踪更改。

此外，由于Databricks笔记本电脑更容易使用，METEONOMIQS可以使更广泛的受众访问数据湖，例如，移动应用程序团队。

作为他们的下一步之一，METEONOMIQS将寻求优化他们的代码，以进一步节省基础设施和提高性能，并考虑其他管道过渡到Databricks架构。

外卖

团队成功基准测试的关键依赖于

1. 知道他们在衡量什么:在评估不同的架构时，客户通常只会比较单个服务的清单价格(例如，比较一个Spark引擎与另一个的成本)。我们试图建议客户不要只看单个服务，而要看总作业成本(数据引擎+计算+团队生产力)与所交付的业务价值之间的关系。在这种情况下，wetter.com的数据工程团队将他们的测试与整体业务目标保持一致——确保他们的数据管道能够支持业务和监管需求，同时减少基础设施和开发人员开销。
2. 选择关键工作负载:团队没有尝试一次迁移所有的管道，而是将范围缩小到他们最紧迫的业务案例。通过这个项目，他们能够验证Databricks可以处理数据工程、机器学习，甚至是基本的业务分析，在规模、预算和及时的方式。
3. 快速交付价值:对于这个团队来说，关键是要尽快从讨论到poc再到生产，从而开始节省成本。讨论拖上几个月甚至更长的时间，既不可取，也不能很好地利用团队的时间。与Databricks合作，他们在不到三周的时间内就建立了第一个基准poc。

准备好自己进行评估了吗?

如果您希望运行自己的测试来比较不同云数据管道的成本和性能，请给我们写信(电子邮件保护)．我们可以根据您的完整工作流程为您提供定制评估，并帮助您获得任何晋升机会。评估包括:

• 技术验证:了解数据源、下游数据使用以及当前运行管道作业所需的资源
• 业务价值分析:确定公司的战略优先级，以理解技术用例(如ETL)如何驱动业务用例(如个性化、供应链效率、体验质量)。这确保了我们的sa设计的解决方案不仅适合今天的需求，而且适合您业务的持续发展。

下面是我们基于设计和评估数据管道基准测试的最佳实践的一般方法的概要。

设计测试

给定同一企业内的数据管道可能根据数据的来源和最终用途而有很大差异——大型企业可能有跨越供应链、营销、产品和运营的数千个数据管道——您如何测试一个架构以确保它可以跨一系列场景、最终用户角色和用例工作?更重要的是，你如何在有限的时间内完成它?你想要的是能够尽可能快地从测试到验证，再到跨尽可能多的管道进行扩展，以降低成本和数据工程师的支持负担。

我们看到的一种方法是选择在架构上代表企业大多数管道的管道。虽然这是一个很好的考虑，但我们发现主要基于架构考虑来选择管道并不一定会带来最大的整体影响。例如，您最常见的数据管道体系结构可能用于较小的管道，这些管道不一定会驱动您的基础设施成本，也不需要数据工程师提供最多的故障排除支持。

相反，我们建议客户将基准测试的范围限制在3-5个数据管道，这主要基于以下两点考虑:

• 首先在业务关键数据工作负载上进行测试:通常第一反应是从不太重要的工作负载开始，然后随着体系结构的证明而向上移动。但是，我们建议首先在战略上、业务关键管道上运行测试，因为尽早了解架构是否能够交付必要的业务sla要好于晚些时候。一旦您证明了您可以交付重要的工作，那么将不那么关键的管道转移到新的架构就变得更容易了。但是反过来(从不那么关键到更关键)将需要验证两次——首先在初始测试中，然后在重要的工作负载中再次验证一次。
• 根据影响性能的主要压力源选择管道:是什么导致了长交货时间、工作延误或工作失败?在选择测试管道时，确保您知道当前架构的压力源是什么，并选择产生长时间延迟、高失败率和/或需要数据工程团队持续支持的代表性管道。例如，如果您是一家制造商，试图实时查看您的供应链，从零件供应商到组装到运输，但您的物联网管道需要数小时才能批量处理大量小文件，这是一个理想的测试候选对象。

评估结果

一旦选择了要测试的数据管道，要评估的关键指标是:

1. 运行一个作业的总成本:运行作业所需的总资源是多少?这意味着不仅要考虑摄取和处理的数据引擎成本，还要考虑完成数据查询的总计算和支持功能成本(如数据验证)。另外，你的管道的故障率是多少?频繁的作业失败意味着要多次重新处理数据，这会显著增加基础设施成本。
2. 运行作业的时间:在添加集群启动和数据处理以及识别和修复作业故障所需的时间之后，运行作业需要多长时间?这段时间越长，基础设施的成本就越高，但你的数据驱动真正的业务价值/洞察所需的时间也就越长。企业依赖数据来做出重要的业务决策，而交付周期长的刚性管道阻碍了业务的快速迭代。
3. 生产力:作业失败的频率是多少?数据工程师需要多长时间来查看日志以找到根本原因、排除故障并解决问题?这种生产力的损失是一种真正的成本，它会增加员工数量，再加上让数据工程师专注于基本数据可靠性问题而不是解决更高层次的业务问题的机会成本。即使作业正常运行，下游用户是否使用了最新的信息?在报告、分析和数据科学中使用数据之前，他们是否被迫重复删除和清理数据?特别是对于流数据(其中可能有乱序文件)，如何确保跨用户拥有一致的数据?
4. 可扩展性:添加新的用例或数据源是否需要完全重新设计您的数据管道，或者您是否拥有一个可以随着数据需求而发展的模式?

此外，当企业希望创建一个更经得起未来考验的架构时，他们应该关注:

• 实现的复杂性:这将是一次多大的迁徙?重组需要多复杂?建立一个新的数据管道需要多少数据工程资源，需要多长时间?您的体系结构能够多快地满足安全需求?当英国食品盒公司Guosto在Databricks上重建了到Delta Lake的ETL管道时，他们指出“整个实施，从第一次接触Databricks到投入生产运行，花了大约两个月的时间——考虑到Gousto技术的规模和适当的治理流程，这是惊人的快。”
• 可移植性:随着越来越多的企业转向多云，他们的架构跨云的可移植性如何?数据以专有格式保存是否会导致供应商锁定(即，将来转换是否需要大量成本)?