重塑数据架构：云器Lakehouse如何简化组装式架构实现性能与成本的精益平衡

图1：云器 Lakehouse 架构

• 多云独立，可以完全托管在多云环境中

• 存算分离、可弹性扩展的计算引擎和存储

• 具备数据集成、数据开发、数据资产管理、运维监控等功能的数据管理平台

• 采用增量计算技术，单引擎 Lakehouse 统一批流交互全分析场景

图2：组装式架构和云器 Lakehouse 一体化架构对比

云器一体化平台统一批、流和交互分析，简化数据分析架构。在传统组装式架构（Lambda 架构）下，企业会需要分别建立离线和实时的链路，并处理它们的混合。在这样的链路中，可能涉及多个计算引擎和存储系统，还可能有多种开发语言，有变化需求时，处理会十分繁琐而耗时。例如批处理场景中，通常使用 Hadoop 体系中的 Spark 或 Hive 等离线链路；当需要处理实时性要求较高的数据时，使用 Flink 等实时链路来处理并支持上层应用；而当同时需要历史数据和实时数据时，则需要将这两部分数据混合在一起，数据不一致、指标口径不一致等问题随之出现。为了应对如此复杂的开发环境，云器 Lakehouse 团队选择为客户提供一体化数据平台，使整个数据分析架构变得更加简单。

一体化平台统一了离线、实时链路中的数据存储，不再需要多套系统分别保存数据，从而保持了数据一致性，降低了数据冗余。

此外，云器 Lakehouse 采用存算分离 shared-everything 的架构设计，企业无需关注计算资源的扩容和分配，计算资源可以根据需求进行动态调整，并且按使用量计费，避免了按峰值需求采购计算资源，大幅降低了资源空闲率，节省了计算资源成本。一个引擎（Single-Engine）的另一个好处是，分析师不再需要在不同组件上适应多种 SQL 语法了，大幅降低了开发和运维的技术门槛，数据人员可以专注在数据分析和价值创新上。

以某电商场景数据加工为例，图3是基于一体化引擎简化架构的数据加工链路。复杂的场景统一为简洁的标准数仓架构，多样数据源数据写入原始表经过清洗加工等ETL过程，再衍生加工出 ADS 表支持上层应用。

在传统 Lambda 架构中，通常需要两条链路，一条离线加工链路完成原始表的处理，一条实时链路处理增量实时数据。最后，还需要将离线和实时数据加工结果进行汇总计算，最后提供给上层应用。

云器 Lakehouse 开发使用体验会更加简洁，举例来看：

对于同样的电商场景数据加工链路，不再需要分别建设离线加工链路和实时数据处理链路，可在实时写入数据的原始数据表上直接进行数据加工和指标分析处理。

数据加工：使用物化视图替代传统的 table 数据表，即可自动进行增量计算，使这套代码不仅可以处理离线任务，当需要变成实时任务的时候，只需要调整该物化视图的刷新时间，便可自动对距上一次刷新产生的增量数据进行处理。刷新时间的修改范围可从天级别调度到 1 分钟，在 T+1 和分钟级实时数据间灵活变化。

指标分析：建立指标分析所需的 ADS 表时，也同样使用物化视图嵌套数据加工结果的物化视图实现。开发指标分析逻辑时，全部代码都使用声明式的SQL语句编写，仅需要编写全量数据处理逻辑，结合基于物化视图的增量计算能力即可自动实现增量计算。大大降低了数据指标抽取、汇总和分析的开发难度，实现全链路的统一搭建体验。

图5：声明式全量数据处理 SQL 简化指标分析逻辑

搭建好的数据处理全链路均具备灵活在T+1到T+0范围内随时调整数据实时性的能力。可随时通过调整链路上各处理节点的物化视图刷新时间调整数据时效性。 

图6：T+1 天级别调度

+0 分钟级别调度

以下是基于上述链路生产的数据形成的BI看板。

图8：基于离线+实时一体化链路形成的BI看板

利用增量计算，T+1 轻松升级到 T+0

组装式架构（也称为 Lambda 架构）是目前业界普遍的数据平台架构方式，通过结合使用多种实时、离线等功能组件，以达到支持业务的目的。然而，在实际数据分析和处理中，我们经常陷入"数据不可能三角"的困境：

图9：数据不可能三角

与组装式架构相对的是一体化架构（也称为 Kappa 架构）——云器 Lakehouse 就是采用这样的架构设计，基于下一代增量计算技术，更好地平衡调整数据新鲜度、性能和成本。

什么是增量计算？增量计算类似于在 Lambda 架构中，我们进行的离线计算+实时计算。离线计算的结果就如在增量计算中，t0 时刻得到的存量数据计算结果，而实时计算部分就如增量计算中对 t0 到 t1 时间段数据增量变化 delta 进行同样计算得到的结果。增量计算实质上就是把原本的全量计算拆分为存量数据的计算结果和增量数据的计算结果，复用已有的存量数据计算结果，并对增量数据进行计算和结果合并，来达到节省计算量，提高 query 性能的目的。在云器 Lakehouse 中开发使用增量计算的数据链路，不需要编写增量计算的代码，而是可以使用物化视图来实现这个链路，仅编写全量数据的处理逻辑，就可以自动获得增量计算的能力。

增量计算并不是一个新的概念，Spark streaming 等产品也有采用，但云器 Lakehouse 的增量计算更“聪明”一些。在实际业务场景中，增量计算并不是时刻都优于全量计算的。比如在数据总量不大，但频繁变动的情况下，如果坚持所有计算都使用增量计算的逻辑，可能还不如全量计算更为高效。云器 Lakehouse 的增量计算更善于帮助用户“精打细算”。在云器 Lakehouse 中，每一次使用增量计算前，都会对增量计算所消耗的计算资源和可能带来的收益进行预估，并与全量计算进行成本和收益的对比，从而选择最为经济的方式。在这个机制下，开发人员可放心调整数据的增量刷新时间，而把方案选择、成本优化的工作交给平台自动分析。

利用 autoMV，秒变优化老司机，性能额外提升 9X

图12：大量业务查询中往往存在可复用的结果

AutoMV（自动的物化视图），用AI和自动化的方式解决查询性能优化问题。

有没有一种可能，将大量请求中重复的部分提取出来，创建成物化视图，然后将原始的 SQL 查询重写为使用这些物化视图保存的预计算结果，从而提高整体查询性能。可以，但是，这种优化是建立在对业务查询请求和底层数据都非常数据，有经验的数据开发人员花费大量时间进行分析和测试后才可完成的。通常我们在应接不暇的业务需求中，很难长时间专注于上述优化工作，此外，作业的需求也在不断变化，优化的效果也可能很快就会被稀释。

图13：auto MV 查询优化效果演示

问答环节