数据工程中的帕累托原理

原文towardsdatascience.com/the-pareto-principle-in-data-engineering-93e7129d9630不是 Medium 会员在这里免费阅读这里 我们都听说过帕累托原理。它也被称为 80/20 法则。这个想法是你可以用 20%的努力完成 80%的工作最后 20%的工作需要其他 80%的努力。它源自一位著名经济学家的作品以至于你在学校甚至学习他们的理论。他们的名字是维尔弗雷多·帕累托。他们在学校教给你的第一件事就是与帕累托同名的另一个概念帕累托效率。https://github.com/OpenDocCN/towardsdatascience-blog-zh-2024/raw/master/docs/img/0618167caccafb60577e7bc1ab72e0f6.png维尔弗雷多·帕累托。来源维基百科如果不能在不损害任何一方福利的情况下改进结果那么该结果就被认为是帕累托有效或帕累托最优的。例如虽然对环境实施更严格的法律可能对社会来说是一个“净改善”但这些政策并不构成帕累托改进。这是因为污染环境的公司变得更糟。形式上如果一个状态没有其他状态至少使一个参与者的福祉更高而其他人的福祉更低那么这个状态就是帕累托最优的。如果存在满足这一条件的状态变化那么新的状态就被称为“帕累托改进”。当没有帕累托改进可能时该状态就是“帕累托最优”。这个想法对数据工程师和软件工程师来说非常相关。因为它很好地符合我们关于使用的基础设施的决策。通常有许多关于新软件工具和方法的吹嘘好处——这些好处伴随着警告、缺点、风险或对我们正在做的事情的负面影响。在本文的其余部分我将概述为什么在设计软件和数据架构时我们可能需要考虑帕累托改进将讨论一些例子并提供一些启示。软件和数据工程中的帕累托效率在我们这个案例中我们可以以几种方式应用帕累托效率的概念。基础设施如果对流程或基础设施的更改使基础设施的所有部分至少和之前一样好那么这种改变就是帕累托改进组织如果对流程或基础设施的更改使所有各方至少和之前一样好那么这种改变就是帕累托改进对于数据团队来说这一点非常有帮助。运营流程和决策建立在利用数据的自动化流程之上。获得业务的支持通常是实现新的数据或 AI 倡议中最困难的部分。投入时间和精力去“让它工作”之后引入新的工具或工作方式如果对现有流程产生负面影响可能会造成极大的破坏。这意味着按照上述定义应用帕累托标准可以是一个评估新工具或流程是否能为数据团队带来显著益处的有用方法。以下是一些原因。10 倍原则作为一家新成立公司的创始人我经常从团队那里听到他们只想改变已经做得很好的流程如果这能带来显著的或“10 倍”的现有工作效益。在这种情况下我们谈论的是净效益而不是帕累托效益。手动计算效益和成本、权衡利弊是一项任何在企业环境中的人都会熟悉的艰巨任务。它给试图改进现有流程的数据团队带来了决策疲劳和令人烦恼的情境切换。帕累托标准应用起来要简单得多可以用作实现 10 倍改进的方便启发式方法。诚然并非所有的帕累托改进都会导致 10 倍改进。但根据定义帕累托改进就像是向前迈出一大步而没有退步。它们都可以累积起来使事情变得更好所以这实际上并不重要。这就是我们已经在做的事情/如果它没有坏就别修它我们并没有有意识地思考它但应用帕累托标准是大多数软件和数据架构师隐含的做法。由于上述所有原因如对现有流程的破坏、实施成本等我们通常过分强调“后退步骤”或不利因素。这是明智的、合理的并且帕累托标准很好地概括了这一点。灵活性这个观点有点微妙所以如果你愿意请继续阅读。我们常见的数据和软件团队犯的一个问题是在未充分考虑灵活性之前就应用像 10 倍原则这样的原则。尽管数据或软件架构的每一次演变都代表了一个足够大的净改进但你需要采取更多步骤才能达到类似的状态。这导致了更多的实施更多的架构来回更改以及本质上更多的迁移工具的痛苦。帕累托效率与 10 倍原则示例从本地到云的迁移想象一下你在一个大型企业工作那里有许多基础设施坐在本地 SQL 服务器上为你的数据分析提供动力。云迁移正风靡一时所以你转向云。这很痛苦但隧道尽头有一个清晰的 10 倍改进。你实施了一系列云数据工具——DataDog、Snowflake、Monte Carlo、一些托管 Airflow。这不是帕累托改进。你的新云堆栈与你的本地基础设施不兼容。这意味着尽管有 10 倍的网络改进但你失去了对本地流程的可见性它们变成了一个令人烦恼的黑盒以及利用所有那些免费计算机的灵活性。随着时间的推移你意识到云成本急剧增加。有许多流程你甚至难以将其迁移到本地这些流程是业务关键流程主机房不会走远。此外你的 CEO 希望你开始做 AI。你无法从 AWS 租赁 GPU它们都已被占用但你设法将一些 GPU 运送到办公室。因此你实施了一项构建混合堆栈的倡议——一个能够利用本地和云资源的能力的堆栈。你的数据操作控制平面需要与云基础设施和本地基础设施的集成。这导致另一次代价高昂的迁移但你完成了工作并快速推进到 2030 年你将全速前进。如果我们在这种情况下应用帕累托原则云迁移可能会略微慢一些。会有一个公开的讨论讨论失去在本地运行的能力是否重要。在这种情况下确实如此。虽然这可能会稍微减缓云迁移的速度但它也提高了所选堆栈的灵活性。当我们到达 2025 年对利用现有计算能力和 GPU 进行 AI 用例的需求日益增加时数据团队本可以避免另一次迁移从而在长期内节省宝贵的时间。结论从现代数据堆栈中移行作为一名工程师我发现最令人沮丧的事情之一是像“云”和“现代数据堆栈”这样的营销术语。这些想法的吸引力不可避免地会减弱最终被其他需要学习的术语所取代。作为一名工程师我也更喜欢第一性原理。这就是为什么我喜欢“帕累托数据堆栈”的想法——一个更灵活的定义可以适应时代同时也是制定决策的绝佳方式。当然有时这里或那里的退步是不可避免的。迁移成本也隐含地被忽略了可能会很大。帕累托标准臭名昭著地限制性。数据领域发展迅速因此我们至少应该尽量避免倒退 我是Hugo LuOrchestra的首席执行官和创始人Orchestra 是数据操作的统一控制平面。