有意识的解耦：存储、计算和现代数据堆栈的界限到底在哪里？
有意识的解耦：存储、计算和数据堆栈的界限在哪？
虽然没有一个正确的答案，但大多数组织的数据平台可能有一个最佳选择。继续阅读以了解可能的位置。
数据工程师在2014年发现了有意识地解耦的好处，与Gwyneth Paltrow和Chris Martin在同一时间解除婚姻关系。
当然，工程师们开始愉快地使用像Snowflake（2012年），Databricks（2013年）和BigQuery（2010年）这样的新技术解耦存储和计算。
与自有机房数据库相比，这在成本和规模方面都有巨大的优势。一家财富500强公司的数据工程经理对我表达了自有机房限制的痛苦，他说：
“我们的分析师无法在他们想要运行查询时运行查询。我们的数据仓库每天会停机12个小时，因为我们经常需要将其脱机进行数据转换和加载…我唯一能用来形容这个过程的词是痛苦。”
十年后，数据管理行业的许多创新都围绕着不同的数据平台如何耦合或解耦存储和计算（不用担心，我在下一节中会举例说明）。与此密切相关的是，这些平台如何从数据摄取和转换到数据治理和监控的相关数据服务进行打包或拆分。
为什么这些事情相关，更重要的是，为什么数据领导者应该关心？
嗯，支持和整合这些服务的连接组织通常可以在表格格式（存储）的元数据和查询/作业日志（计算）中找到。在数据平台中如何管理这些方面将在其性能、成本、易用性、合作伙伴生态系统和未来可行性方面发挥重要作用。
问什么类型的数据平台和什么级别的解耦是正确的，就像问什么是正确的格式化SQL代码的方式一样：这在很大程度上取决于个人偏好和专业要求，但有一小部分可能性将满足大多数人的需求。
我认为-在当前时刻-数据平台的范围符合亚里士多德的中庸之道。大多数人最好选择中等程度的选项，而在极端情况下操作将是为少数具有非常特殊使用案例的人提供的选择。
在深入研究为什么情况可能如此之前，让我们先看看当前的情况和最近的发展。
存储和计算数据平台的范围
一小撮人通过“云太贵了，我们回到我们的服务器架”行动登上了头条新闻。虽然这对一些人来说可能是一种合理的策略，但这种情况正在迅速减少。
就在上周，Pragmatic Engineer关注了Twitter的速率限制和可能由于将机器学习模型从GCP迁移到他们的三个数据中心而导致的用户体验问题。
能够独立扩展和使用存储和计算可以更具成本效益和性能，但在同一数据平台内具有这些独立的功能也有优势。
作为一部分即席分析请求执行的非优化SQL查询通常会在这些经过调优的平台上运行得更快。在平台级别上分离计算和存储的解耦架构可以在运行大量工作负载时非常具有成本效益，但这需要一个高度训练有素的工作人员花时间优化这些工作负载。
具有组合但解耦的存储和计算的数据平台还可以在几个关键的数据操作任务中提供更强大、集成的用户体验。以数据治理为例。这些平台提供了一个集中化的机制来进行访问控制，而解耦的架构则需要在多个查询引擎之间联合角色-这是一项非常重要的任务。
解耦但结合的方法是使Snowflake成为“一切顺利运行”的最常见评价的奥秘。难怪Snowflake最近加倍投入Unistore以处理事务工作负载，并开放Snowpark以支持Python和更多数据科学（计算）工作负载。
Databricks专注于其Spark处理框架，取得了令人惊人的增长，但添加了元数据和类似ACID的事务以及Unity目录中的治理功能后，其增长水平也不是一个巧合。他们最近也加倍投入，并使得当您写入Delta表（存储）时，该表中的元数据以Delta、Apache和Hudi可读的格式写入。
挑战者平台
这就是为什么有越来越多的最新新兴数据工程技术开始在供应商层面上将存储和计算分离的有趣之处。例如，Tabular将自己描述为“无头数据仓库”或“除计算外的一切数据仓库所需功能”。
更进一步，一些组织正在将数据湖中的Apache Iceberg表迁移到“自助管理”的后端基础架构，并使用像Trino这样的独立查询引擎。这通常是由于需要高性能和成本效益的面向客户的用例，需要进行交互式查询。
DuckDB将存储和计算结合起来，但为了开发人员的简便性和降低成本，牺牲了现代数据堆栈的近乎无限计算能力。
因此，问题仍然存在，这些创新是否有可能取代现有的云原生数据平台？
同样，答案将取决于您是谁。DuckDB是一款非常受欢迎的工具，许多数据分析师喜欢使用，但它可能不会成为构建数据平台的基石。最终，我们看到，并且我相信将继续看到如下分布：
我将通过跨现代数据堆栈和数据平台类型的几个关键维度来解释为什么。
整合的程度和目的
B2B供应商经常提到“单一视图”。在一个单一的组织中拥有多个服务是否有价值？这取决于每个服务的质量以及它如何与您的需求相对应。
单一视图的价值真正来自于将本来分散的信息统一成一个故事，或将分离的操作合并成应该是一个单一工作流程。让我们以Microsoft 365为例说明这个概念。
在其Teams协作应用程序中集成视频和电子邮件非常有价值，因为这些是会议安排和视频会议过程的核心方面。在他们的应用套件中拥有Sway是否同样有价值？同样，这取决于您对交互式报告的需求。
回到数据领域，计算和存储对于这个单一故事（数据操作的谁、什么、何时、何地、为什么、如何）以及与成本、质量和访问管理等方面相关的关键工作流程至关重要。因此，这些平台将拥有最强大的合作伙伴生态系统和更无缝的集成。除非您是那种使用Windows和Fire手机而不是iPhone和Android手机的人，否则这很可能是您的一个关键标准。
Choozle的首席执行官Adam Woods去年向我们的团队谈到了他在围绕他的数据平台建立一个强大而紧密集成的合作伙伴生态系统方面的重要性。
“我喜欢……我的数据堆栈始终保持最新状态，我永远不必应用补丁。我们能够将开发人员和数据库分析师本来会花在更新和基础架构上的时间重新投入到构建出色的客户体验上，”他说。
当然，总是有例外的情况。如果您面临大规模的边缘用例，真正的数据湖、无头仓库或其他更复杂的平台可能是理想选择。
您的语义层、数据质量、访问控制、目录、BI、转换、摄取和其他工具是否都应该捆绑在同一个平台中？我认为在这个范围内有有效的观点，但与其他部门一样，大多数数据团队将拥有一套最符合其需求的工具。
要点：
- 大多数数据领导者将优先考虑使用具有计算和存储服务的数据平台，以促进“单一故事”的实现，并支持多样化的合作伙伴生态系统。
性能与易用性
一般来说，一个平台越可定制化，它在各种用例下的表现就越好……但使用起来也越困难。这是一个难以逃避的权衡，当你将存储和计算服务分散在不同的供应商之间时，就是在做出这个权衡。
在考虑数据平台的“易用性”时，不仅要考虑平台的日常使用，还要考虑管理和定制的简易性。
根据我的经验，很多团队过度追求平台的性能。我们的技术背景让我们立刻开始像比较汽车一样比较平台：“对于这个工作负载来说，有多少马力？那个工作负载呢？”
不要误会，优化的数据平台可以转化为数百万美元的年度节省。这很重要。但是，如果你需要雇佣额外的工程师来管理S3配置，或者每个季度都需要启动一个为期数月的项目来将业务的新方面纳入你的数据平台，那也有很高的成本。
你会看到这种决策模式在开源解决方案中也是如此。前期成本可以忽略不计，但维护基础设施的时间成本可能是巨大的。
解决方案成本和工程师薪水成本是不同的，这种错误的等价性可能会在后面引发问题。有两个原因：
- 假设你的使用情况保持不变（这是一个重要的限制条件），你的解决方案成本通常保持不变，而效率则会提高。这是因为SaaS供应商不断推出新功能。另一方面，手动实现的效率随着关键参与者的离开和新团队成员的入职而逐渐下降。
- 当你大部分时间都在维护基础设施时，你的数据团队会开始迷失目标。目标慢慢地从最大化业务价值漂移到维护处于最佳状态的基础设施。越来越多的会议变成了关于基础设施的会议。专业化的基础设施技能在组织内部变得更为重要，这些专家也变得更加突出。组织文化很重要，通常是由团队正在解决的主要任务和问题所塑造的。
对于Swimply的数据负责人Michael Sheldon来说，这第二个观点尤为重要。
“因为我们作为一个数据团队有责任支持整个公司，所以我们需要一个数据堆栈来解决两个核心问题，”Michael说。“一是将来自公司各个不同部分的所有数据集中到一个稳定的地方，每个人都可以使用并参考它作为真实的数据来源。而且，二是使我们有足够的时间专注于洞察而不仅仅是数据基础设施本身。”
当然，有时你的业务用例需要优秀的性能。
高延迟的信用卡欺诈数据产品只是浪费时间。给用户带来无尽等待的客户端应用是不可接受的，可能需要你部署一个高性能的查询引擎。然而，在大多数情况下，你的数据仓库或托管的数据湖仍然可以很好地扩展。仔细检查任何声称相反的要求。
要点：
- 尽管易用性和性能是相互关联的变量，必须保持平衡，但大多数数据领导者会倾向于易用性，因为相对隐藏的维护和文化成本。你的竞争优势更多地体现在丰富和应用第一方数据，而不是维护复杂的基础设施。
捍卫MDS
我知道现代数据堆栈现在已经被批评得很时兴（而且你可能不需要它来完成任务），但尽管有其缺点，对于大多数数据团队来说，它将是最佳选择。它是快速产生价值和未来投资长期性的理想结合。
许多新兴技术都有重要价值，尽管有更狭窄的用例。看到它们如何发展和塑造数据工程实践将是令人兴奋的。
然而，尽管计算和存储需要分别运作和扩展，但将这些服务及其相应的元数据放在同一平台上会带来太多优势，太大的威力，不容忽视。
关注我在VoAGI上的更多关于数据领导、数据科学应用和相关主题的故事。订阅以便将我的故事直接发送到您的收件箱。
