随着数据源和数据量的增长，以及数据驱动方向越来越被认为是竞争的必要条件，平台供应商之间为我们的数据提供主要存储库的战争非常激烈。 战争有几个方面，其中之一是分析。 而在这个范围内，数据仓库和数据湖阵营是主要的参战者。
数据仓库方面很强大，因为它包括 Teradata 和 Vertica（现在是 Micro Focus 的一部分）等坚定的现有供应商、所有三大云提供商（AWS、Google Cloud、Microsoft Azure）和行业宠儿 Snowflake 的组合。 在数据湖方面，Cloudera 和 Databricks 等独立提供商可能是最具代表性的竞争对手。
几个月前，Databricks 表示它取得了创纪录的性能基准测试结果，使其在这场战斗中取得了胜利，击败了数据仓库模型和拥护它的供应商。 虽然这不再是最新消息，但仍有必要对公告进行一些分析。
不要只是踩水
虽然数据湖（和 Databricks 喜欢称其自己的平台为“lakehouse”）的支持者可能会批评仓库已经过时，但后者经过了时间考验并享有一定的主导地位。 这将举证责任放在了数据湖端，以证明它可以处理与具有竞争力的性能的仓库相同的工作负载。
Databricks 现在相信它有这样的证据。 去年 11 月，该公司公布了一组由交易处理性能委员会 (TPC) 标准审核并基于其标准的基准测试结果。 这些测试是针对相对较新的——甚至是最近改进的——Databricks SQL 平台运行的，该平台是上述 lakehouse 架构的公司基础。 具体来说，基准配置使用 Databricks SQL 8.3，其中包括 Databricks 专有的 Photon 引擎，这是一个向量处理、查询处理器优化的替代品，用于替代用 C++ 编写的 Spark SQL。
具体来说，Databricks SQL，以及一般的 lakehouse 架构，以数据湖技术为核心，结合增强功能——如 ACID 合规性、写回和矢量处理——有助于提供与数据仓库平台的功能对等。 Databricks SQL 仍然使用运行基于 Spark 的 Databricks Runtime 的机器集群，但它针对数据仓库和商业智能 (BI) 用例中常见的查询类型和用户需求模式优化了这些集群上的节点。
DS、FTW
Databricks 使用了稳定的 TPC-DS 测试，长期以来一直是数据仓库系统基准测试的行业标准。 基准测试是在一个非常强大的 256 节点、2112 核心 Databricks SQL 集群上进行的，Databricks 为其云基础设施定价超过 500 万美元。 顺便说一句，“DS”代表“决策支持”，这是术语商业智能的前身，考虑到 Databricks SQL 的设计和使命，它是非常合适的。
Databricks 对基准测试结果进行了描述，称它为在任何平台（无论是仓库、湖还是湖屋）上执行的 TPC-DS 性能创造了新的世界纪录。
在 Databricks 的 TPC-DS 基准测试运行规模上，之前的性能记录保持者是阿里巴巴。 这家中国互联网和电子商务巨头在 100TB（每小时决策支持查询，基于涉及 100TB 数据的查询）中取得了 14,861,137 QphDS 的结果，使用了自己定制的——也相当强大的——数据仓库 系统。
与此同时，Databricks 宣布它在 100TB 时取得了 32,941,245 QphDS 的成绩——是阿里巴巴业绩的两倍多。 该公司表示，它在一个系统上这样做，其成本比阿里巴巴的自酿啤酒平台低 10%。 虽然基准测试由 Databricks 自己进行，但结果由 TPC 审核。
在 Databricks 看来，它创下了历史记录。
该公司进一步认为，现在应该清除所有阻止客户使用 lakehouse 平台代替仓库平台的障碍。 这很重要，因为即使在提倡 lakehouse 方法时，Databricks 之前也承认仓库平台在某些工作负载方面表现更好，而且该公司明白这种性能不足会阻止客户转向 lakehouse。
面对雪花
Databricks 清楚地感觉到这些基准测试结果使其成功经得起数据仓库宠儿 Snowflake 的考验。 说到这一点，除了 TPC 基准测试结果本身，Databricks 还吹捧巴塞罗那超级计算中心 (BSC) 所做的比较 Databricks SQL 和 Snowflake 的工作。 Databricks 表示，这项基于 TPC-DS 基准测试但未经 TPC 审核的工作表明，Databricks SQL 的速度提高了 2.7 倍（请参阅下图，摘自 Databricks 博客文章中有关该主题的文章）。 BSC 还报告说，Databricks SQL 集群在性价比方面比类似规模的 Snowflake 设置好 12 倍。
这里有很多旋转，但 TPC 和 BSC 结果确实表明 lakehouse 架构可以承担这些 BI 工作负载。 这很重要，因为大多数基于 Spark 的系统（包括 Databricks）以前最适合分析领域的数据工程、机器学习和间歇性查询。 让这样一个系统来服务持续的分析工作负载，或涉及多个相互构建的查询的临时分析，是很难实现的。
如果问题是这是否意味着湖屋现在可以完全替代仓库，那么答案就不清楚了。
这种不明确的主要原因与客户的意见有关，为什么以前湖或湖屋不是一个合适的替代品。 是的，对于某些人来说，坚持使用仓库的原因是性能，而这套 TPC 基准测试可能会解决这些问题并影响支持它们的客户。
形式问题
对于其他客户，标准更多地是关于范例——包括数据建模和某种意义上的数据治理——而不是关于性能。 湖的精神是以开放格式的命名文件的形式存储数据，这样数据就可以与一系列数据库和分析引擎兼容，并可以被它们使用。 而且由于数据以文件形式存储在磁盘或云存储中，因此减少了对其建模的需求（和意愿）。
这使得数据不那么正式，通常很少受到审查，也很少经过审查。 控制更加委托，更容易放入数据。（数据湖的这些特征也适用于 Lakehouse 场景。）
数据仓库更正式、更受控制，通常会强制执行更明确、更全面的数据模型。 它不够敏捷，这让用户感到沮丧，但它也有更多的过滤器，可以与普遍更高的数据质量和用户信任度相关联。
一个拥有价值 500 万美元基础设施和海量数据的系统或许能够在阿里巴巴的基准测试中表现出色，但这并不是大多数客户需要或能够负担得起的。 它确实表明 Databricks SQL 可以承担巨大的工作负载，对于某些客户而言，这本身就很重要。
Databricks 基准测试结果的重要性可以通过适当的问题框架得到最好的理解。 Databricks 将其定义为：“哪种模型占主导地位？” 但也许问题是：“哪种模型更能吸引特定客户，尤其是特定用例？” 接下来是：“现在两种型号的性能都足够了吗？”
最终，大多数企业可能会受益于数据仓库和数据湖（屋）。 仓库可以是经过高度审查、仔细整合和建模的数据的存储库，以驱动报告、操作仪表板和“已知未知”领域中的临时查询。 与此同时，Lakes 和 lakehouses 可以容纳更多的数据、更短的入职流程、更少的“写时建模”，并可用于探索性分析和即兴可视化。
胜利，而不是赢家
TPC 结果清楚地表明，这两种模型都运行良好，提供了出色的结果，可以在需要时进行交互，并且可以使用相同的 BI 工具。 它们还具有成本效益、云优先、弹性和敏捷性。 但是，即使仓库/湖屋问题不需要非此即彼的选择，供应商这样看也有好处：对相同客户和相同工作负载的竞争会导致持续创新，从而使客户受益。
TPC 基准是否是最佳选择的最终仲裁者将取决于买方的标准。 但无论如何，Databricks 的 TPC-DS 结果令人印象深刻。 它们是行业的里程碑，也是确保供应商采用持续改进方法的强制功能，无论他们是在兜售湖、湖屋还是仓库。
