一种新颖的方法将数据湖仓分析的所有优势与数据仓库的高性能完美结合。
译自 How to Get Data Warehouse Performance on the Data Lakehouse，作者 Sida Shen 是CelerData的产品营销经理。他拥有机器学习和大数据基础设施背景的工程师，负责公司的市场研究，并与分析行业的工程师和开发人员密切合作，解决实时分析的相关挑战。
数据湖仓库架构的普及性持续增加，这一点毫不令人惊讶。它们无缝集成数据湖和数据仓库的优点的潜力，承诺为数据处理和分析带来变革性的体验。然而，这种方法也存在缺陷。本文检验了这些挑战，如查询性能和高成本，并确定了帮助数据湖仓库解决它们的新技术。
数据湖仓库用其灵活性、可扩展性和成本效益的承诺吸引了无数企业。然而，事实是，当前支持这些数据湖仓库的查询引擎在大规模低延迟或高并发分析方面未能提供查询性能。目前，这些数据湖仓库的查询引擎呈两极分化状态。一方面，我们有针对提取、转换和加载(ETL)工作流进行优化的引擎，侧重于阶段性操作。另一方面，我们看到引擎不利用现代优化技术，如单指令多数据(SIMD)指令集，这对利用现代 CPU 的全部计算能力至关重要。
这种固有的性能限制促使大多数用户将数据从数据湖仓库复制到专有数据仓库，以实现他们所需的查询性能。但这是一种昂贵的变通方法。
图1:常见的数据湖流水线
一开始，向数据仓库摄入数据看似一个简单的过程，但远非如此。这个过程需要将数据转换为仓库的特定格式，这项任务需要大量的硬件资源。此外，这种复制导致数据存储的冗余——这在成本和空间方面是一个昂贵的命题。
不仅仅是物理资源，所需的人力也同样重要。看似单调乏味的任务，如调整两个系统之间的数据类型，都可能耗尽资源。此外，这个数据摄入过程无意中引入了延迟，削弱了数据的新鲜度。
数据的完整性和准确性对任何企业来说都是至关重要的。讽刺的是，本应技术上增强其效用的向另一个数据仓库摄入数据的行为本身，对数据治理构成了严峻的挑战。您如何确保所有副本都得到一致更新？您如何防止不同副本之间的差异？您又如何在维护强大的数据治理的同时做到这一点？这些不仅仅是理论问题；它们是严峻的技术挑战，需要重大的工程努力，如果做错了，有可能影响您基于数据的决策的真实性。
数据湖仓库的查询性能固有挑战和作为变通方法的专有数据仓库的使用，正在推动越来越多的企业寻求更高效的替代方案。一种流行的方法是采用无摄入的湖仓架构。下面是它的工作原理。
数据湖查询引擎采用数据调度来实现可扩展性能，特别是在复杂的联接操作和聚合方面。然而，许多数据湖仓库引擎最初设计用于数据湖的多样且可负担的数据存储，侧重于数据转换和即席查询，将中间结果持久化到磁盘。虽然适用于批处理作业，但这种方法妨碍了湖仓库不断发展的工作负载，特别是实时的面向客户的查询。此外，基于磁盘的调度引入了延迟，阻碍了查询性能，阻碍了即时洞察。
图2:MPP与MapReduce框架
为了应对这一挑战，并直接在数据湖仓库上运行低延迟查询，拥抱装备了内存数据调度的大规模并行处理(MPP)查询引擎是一个明智之举。与传统方法不同，内存调度完全绕过磁盘持久化。这确保查询执行流畅，几乎没有等待时间。这种操作不仅高效，而且对于实现低查询延迟至关重要，使得从数据湖仓库获得即时洞察成为可能。
优化数据湖仓库查询的主要障碍之一在于从远程存储位置检索数据的高昂开销。数据湖仓库中数据的巨大规模和分布式特性使每次扫描都成为一个资源密集型任务。一个设计良好的内置数据缓存系统是必要的。缓存系统应采用分层缓存机制，不仅利用基于磁盘的缓存，还利用基于内存的缓存，减少从远程存储访问数据，从而减少延迟。
此外，此缓存框架的效用取决于它与查询引擎的集成。它不应该是一个独立的需要单独部署的模块——这可能会引入复杂性和潜在的性能瓶颈——而应该是本机内嵌于系统中的。这种内聚架构简化了操作，并确保缓存以峰值效率运行，从而为数据检索和查询执行提供尽可能好的性能。
图3:SIMD优化
像SIMD这样的系统级优化在进一步提高数据湖仓库性能方面发挥着不可或缺的作用。例如，SIMD增强使多个数据点能够并行处理统一指令。当与数据湖文件格式(如Parquet或优化的列式(ORC))中的列存储结合使用时，它允许以更大的批次处理数据，显著提高了联机分析处理(OLAP)查询的性能，特别是涉及连接操作的查询。
最后，优先考虑开源解决方案。如果要最大限度地利用数据湖仓库架构的好处，拥抱开源至关重要。数据湖仓库的固有开放性不仅体现在它支持的格式上；它提供的灵活性是它的关键优势之一。这种模块化意味着组件(包括查询引擎)可以轻松互换，使您能够保持敏捷，并随着数据分析不断发展的环境轻松适应。
所有这一切在理论上听起来不错，但在实践中呢？Trip.com的统一内部报告平台Artnova提供了一个很好的例子。
图4. 以前：业务关键工作负载摄入StarRocks
最初，Artnova使用Apache Hive作为数据湖，使用Trino作为查询引擎。然而，由于大量的数据加上低延迟的需求以及处理大量并发请求的能力，Trino在某些用例下无法满足要求。Trip.com不得不将数据复制并转移到其高性能数据仓库StarRocks中。虽然这种策略解决了一些性能问题，但也引入了更多问题:
- 尽管摄入相对较快，但数据新鲜度落后，影响查询的灵活性和及时性。
- 由于额外的摄入任务以及表模式和索引设计要求，在数据流水线中增加了复杂性。
将数据复制到另一个数据仓库很复杂且昂贵。携程最初仅将最关键的业务工作负载移动到StarRocks，但最终决定进行架构上的全面改造并扩大StarRocks的使用。
图5. 之后：StarRocks作为统一查询引擎
根据Trip.com进行的性能测试，在相同数据上使用StarRocks作为查询引擎比Trino快7.4倍。在StarRocks内置的物化视图的加速下，对业务关键用例的性能提升非常显著。
数据湖仓库的演变重塑了数据分析，结合了数据湖和数据仓库的优势。尽管它具有变革性的潜力，但诸如高效查询性能等挑战仍然存在。创新解决方案如MPP查询执行、缓存框架和系统级优化可能弥合这些差距，并使企业能够享受湖仓库的所有好处，而无需承受任何缺点。