导读

本文将分享云器Lakehouse如何重新定义实时多维分析，帮助客户实现实时、智能、全托管的数据平台。主要内容包括以下几大部分：

• 多维数据分析的发展趋势和场景解析

• 技术解析：新一代数平台Lakehouse如何支持实时分析需求

• 价值解析：让 BI+AI 分析高新鲜度，可智能优化，可面向并发的弹缩

• 对比传统实时数仓产品的收益对比，参考案例

本文探讨企业如何在高时效性业务进程中构建高效灵活的数据应用体系。我们将介绍实时数据应用的关键特点和发展趋势，总结优秀数据平台的核心特征。文章还将具体展示应用下一代数据平台的效果，实现降本增效、并构筑结合 AI 的数据分析，打造 BI+AI 基础设施。最后，我们将展望实时数据分析领域的前沿技术与行业发展趋势。

实时智能分析不可或缺，但企业面对实施的挑战和阻碍很多

瞬息万变的商业环境，数据是生命线

在当前数据驱动的瞬息万变的商业环境下，每个公司都需要理解数据的本质，做好数据分析逐渐变成企业发展的基础，做好高时效性的数据分析与决策成为企业发展的驱动力和生存的生命线。

例如，在直播时代之前，人们可能只关注前一个小时或前一天的数据。而今天的直播运营总监希望了解五分钟内直播间销量情况，判断库存备货并即时决策促销策略。业务模式推动数据分析的需求演进，要更实时的分析数据，更实时决策业务。

其次，许多数据团队不仅为公司内部运营人员提供分析结果，为公司高管提供数据报表，还要整合及建设数据报表给自己的产品用户，越来越多的数据价值被呈现给最终用户。千万个用户的不规则峰谷的查询需求且短时间内高并发查询分析使得后台系统面临巨大压力。

再次，非结构化数据的分析需求凸显，ML/AI 为非结构化数据分析开辟了新的可能性。

因此，我们应思考新一代的数据分析范式，补充传统的数据分析体系的短板，亦或重构新的数据架构及模式。

全新的实时数据分析范式

我们设想一种全新的实时数据分析范式，它具备三个主要特征：

• 更实时：业务决策需要更实时的数据分析支撑。传统离线数据是 T+1 更新，既每天刷新一次。而更实时的数据分析意味着数据的整体更新频率加速到一小时甚至一分钟。

• 更智能：更智能的分析能够开拓洞察数据的方式，囊括更多不同类型的数据。创新的场景包括报表的智能化展示，基于 ML/A I的数据挖掘，非结构化数据的内容归类与提取，等等。

• 更普惠：大数据分析将不再是个别大厂的专属能力，而可以成为一个普惠的工具。简化数据工程，数据分析和开发人员构建数据平台的复杂度，也让数据用户更简便获得洞察。

传统数据架构成为实现多维实时智能分析场景的阻碍

阻碍一：传统架构下，业务需求的多样性导致了数据架构复杂，进而限制了整体平台的能力上限。举个例子，很多数据平台维护团队增加了 20% 新机器资源加到集群中，但是所拿到的性能提升效果还不足 10% 。

阻碍二：传统的数据湖和实时数据平台不可兼得，会带来效能瓶颈。如数据湖的查询并发能力不足，数据新鲜度和写入并发度低，严重依赖缓存；集成困难，例如成千上万张异构的表，需要为每个不同的数据库编写脚本进行处理；数据实时同步和业务 schema 变化导致的运维复杂，数据整合的成本非常高。

阻碍三：传统架构通常需要预置资源，闲时浪费，忙时又不够用。即便有扩展机器的方式，但弹性能力和时效性达不到要求。

总结：企业或组织经常陷入性能-成本陷阱，即把性能不足的问题归结为资源预算不足。要知道传统的扩展方式由于上述复杂性原因，提升性能对应成本的增加是成倍的，而非线形增加。企业或许不得不因成本因素决策砍掉一些“非必要”功能，导致数据方向的创新在成本约束下难以成势。

什么原因造成了传统数据架构的成本约束，让我们详细拆解一下性能与成本。

拆解数据分析效能与成本，为什么成本这么难控

高成本是由于全链路积累的连锁反应，综合导致的高成本。数据的处理场景，包括数据采集、集成、预处理、存储、流转、并发、治理和运维。我们对每个环节进行问题拆解，详见上图。

根本原因在于组装数据工具尽管各有“专长”，但也有“合成谬误”

当前主流数据架构在提供数据服务或搭建数据分析平台时，存在数据处理和服务割裂、链路冗长等问题，导致高延迟和数据冗余。同时上一代流计算产品需要预留大量 CPU 资源，成本高昂。传统的 Hadoop 架构不适用于频繁更新的业务库场景，而新的实时数据分析工具如 Presto 、 ClickHouse 等在规模支持上有限制。

尽管每个组件都能够单独工作，也各有所长，但是对于使用工具的企业来说，合在一起使用，就会出现上述谈到的许多阻碍和问题。

总结下一代可支撑实时多维分析的数据平台需要具备哪些功能

1. 多租户场景下的分库分表与合库合表：在多租户产品中,数据平台需要支持分库分表,同时又要能够灵活地进行合库合表操作,以满足行业分析的需求。此外,为了让管理层能够实时掌握业务变化,数据库与大数据系统之间需要实现极低延迟的数据同步,要求大数据系统具备快速计算和数据推送的能力。

2. 历史数据与实时数据的无缝整合。

3. 自然语言查询和多数据源支持。

4. 多云环境下的一致性体验：数据平台需要随着业务平台一起部署到多个云服务上,如阿里云、腾讯云或 AWS 。在这种情况下,如何在不同的云环境中提供一致的用户体验,是数据平台需要考虑和解决的重要问题。

5. 开放湖仓一体架构,支持 AI 应用：为了更好地支持 AI 应用的发展,数据平台的架构应采用开放湖仓一体的设计,实现结构化数据和非结构化数据的统一管理。同时,数据分析作业和 AI 模型调用作业也需要进行统一的工作流编排,并通过统一的元数据管理来实现高效的数据治理和权限分配。

6. 弹性资源管理,降低成本。

全新Lakehouse技术解密

如何实时分析海量数据，即取即用

云器Lakehouse做了全新的设计。

• 在数据集成部分，实现了实时同步和产品化操作，例如常见的 MySQL 、 SQL Server 数据库、 PostgreSQL 数据库都可以通过平滑配置化方式实现分秒级的数据同步。

• 在数据处理部分，我们使用统一的数据管理，支持增量计算的单一引擎 SingeEngine 来解决实时、离线和不同类型的检索工作负载问题。

• 在资源控制和资源供应模式方面，采用全托管方式，并通过弹性并发方式提供相关资源，做到毫秒级的资源弹性，以及资源供给的水平份数和规格两个维度的扩缩。

Lakehouse如何支持实时 BI 及多维分析整体架构

云器提供了面向多维分析的整体架构方案。

当前的数据平台是一个多云数据平台，伴随许多客户出海，跨越多个数据平台，账户即开即用，一天内就能完成交付，并支持异构云。

• 从查询实时性来看，数据新鲜度从原来的 T+1 、 H+1 达到了秒级新鲜度。

• 查询并发度达到千级别以上，并在这种并发度基础上， BI 工具自动生成的复杂 SQL 查询，也能控制在 P99 1 秒以内。

• 从降低成本的角度来看，这是一个零运维的全托管产品，使大家能将更多精力放在数据本身的建设以及业务的考虑上，并提供非常高的 SLA 。

云器Lakehouse的三个重点功能能力解密

在低成本限定情况下全面提升数据新鲜度

• 采用了完全的白屏化无代码配置方式，支持异构数据源两两组合，上百种离线和实时的同步链路；

• 支持海量千万级别的数据库表进行整库迁移，增量同步，单表或多表同步，多实例合并同步等等一系列策略和功能，这些都是通过配置化方式即可一键同步，同步后即可查询；

• 支持 Schema Evolution ，提供了一体化的运维和监控工具，可以监控流量情况、延迟数据、同步条数、是否存在问题等情况；

• 业务库的动态变化能够实时反映在大数据中。根据多位客户的使用反馈，整体数据延迟在 0 到 20 秒左右，这是一个显著的提升，为实时业务提供了坚实的基础。

全托管弹性能力支持业务峰谷并发变化

云器产品构建了一个强大的 Serverless 库存资源池，使集群能够毫秒级地按需启动，根据并发量和 SQL 复杂度自动进行扩缩容。

用户使用时按量计费，前端查询的 JDBC 流量无需感知。

研究显示， APP 查询存在明显的峰谷模式。每天 9-11 点、 15-17:30 以及 20-21:30 是查询高峰,而月末月初是银行类 APP 数据账务查询的高峰。高峰时期的并发查询量可达低谷时期的百倍至千倍。

智能优化减少弹性并发

• 自动优化能力，简化用户操作；

• 采用 AI 技术应用于数据布局优化、缓存策略和智能数据模型优化；

• 自助化产品提供分库、分区、分桶、索引等操作的作业管理；

• 全托管减少运维负担，让开发者专注于数据业务创新。

实时分析场景用例介绍Case Study

下面简单介绍几个典型的应用场景。

电商

在电商领域，具体的包括推荐系统的实时化应用场景：进行实时用户行为分析、内容特征分析以及 A/B 测试等，会涉及不同类型的组件，包括 Spark 、 Hive 、 ClickHouse 、 Druid 等，以及一些基础服务。图中每条黄色的线代表一个独立的分析场景，构成了一个典型的 Lambda 架构。

多种引擎和这个系统组合起来建设成本是比较高的，和业务上对齐难度也比较大。云器Lakehouse的产品作为一体化平台，将实时和离线部分整合到一个数据仓库中，使用一个引擎来满足不同类型的数据分析和处理需求，提高效率并简化数据处理流程。这样有几点优势：

• 让中型电商企业可以一步到位获得完整的大型电商的数据底座能力；

• 数据平台无启动门槛，按量低成本实现基于数据的商品的实时推荐能力；

• 多云可扩展运行的数据平台，不用为云底座的切换额外适配。

金融风控

金融风控场景的数据综合性要求高，需要跨数据业务域进行数据分析，需要近实时的计算和多维度的数据做综合计算。

例如基于新数据或用户新行为触发规则计算，要做到迅速响应，这就要求高数据新鲜度。实时架构需要结合用户标签、购物行为标签和金融行为标签，其中金融行为标签通常是离线标签，这就要求离线与实时标签一起进行关联查询。

此外，查询并发量较高，在高并发下的数据的秒级延迟和千级别查询并发有严格要求。

云器Lakehouse的产品作为一体化平台在这个场景下，有如下优势：

• 产品化数据集成，可实现海量多数据源的实时集成，并且有易配置的方式，批量对相同类型的分库分表进行合并集成；

• 100% Serveless ，全托管存算分离架构，保障资源的高峰和低谷需求；

• 优化多表关联查询，离线和实时数据链路实现融合；

• 高并发高响应度的实时即时查询支持企业级多用户使用；

• 企业级数据资源权限管理机制和用户权限管理机制。

SaaS CRM

SaaS CRM 场景中，需要支持成百上千甚至上万个多租户。这些租户分散在不同类型的 Pod 中。传统的 BI 工具需要查询 Greenplum 或 Clickhouse 等系统，而底层服务能力是分散的，这给运维带来了许多问题。多套系统的组合使得架构变得极其复杂，数据量膨胀至两到三倍。由于每块资源较小，进行扩展时，支持的查询并发不足，资源被隔离在不同的 Pod 中，这是一个标准的 SaaS 软件数据架构。

此外，租户级别可能达到几万、几十万甚至上百万的量级，每个租户可能拥有几个到几十个表，需要同步的表就会达到千万级，实时数据同步成为了一大挑战。解决这一问题，可以进行多项优化，如之前提到的产品化数据集成方式，采用一体化模型建仓，嵌入式 BI ，以及自动优化生成的 SQL 和支持高并发查询。

某头部 SaaS CRM 企业，对接数百个数据库和数万张表，利用云器Lakehouse的实时数据集成能力，将数据新鲜度从原来的 15 分钟提升至秒级。此外，查询时间也变得更稳定，不再受限于 Greenplum 等资源隔离模式。从成本角度来看，实现了接近零运维成本的模式，使用成本也降低了约 50% 。更为重要的是，为客户提供多云一致性的体验。

云器Lakehouse目前在阿里云、腾讯云和 AWS 上均有服务，客户能够在不同的云平台上使用同一款产品进行数据处理和分析。企业内部在进行产研架构设计时，只需设计一套系统，无需熟悉多款产品，从而大大缩短了业务上线周期。

展望AI时代的数据平台架构

前文中介绍了云器Lakehouse数据平台架构的一些关键特性。综合来看，组装式的数据架构会导致数据语义处理不统一、数据仓库维护不统一，以至增加了数据开发和维护的成本。异构存储和多套元数据的存在，导致了大量计算和存储资源的冗余。此外，数据架构的复杂性使得在增加新的业务场景时，需要涉及到多个数据库或其他数据类产品的变动。

云器Lakehouse提供了一体化的数据架构解决方案，其底层是湖仓一体的架构，以统一的元数据和统一的数据管理作为基础，在此之上，采用单一引擎（single engine）的方式来支持不同场景下的数据变化和数据处理需求，包括批处理计算、流处理计算、交互式检索以及点查询等场景。

为了面向 AI 和机器学习的未来处理需求，该架构设计允许多种引擎直接集成进来，共同完成 AI 的处理、训练和服务。

从实时数仓到Lakehouse

展望未来，尤其是在 AI 时代，单纯从数据处理角度来考虑数据平台建设是不够的。业务创新需要更实时、更智能、更普惠的数据分析能力，需要新型的数据仓库模式的支持。新型数据仓库模式包括一体化的数据仓库，支持 Schema Evolution 演进、自动刷新，以及结构化数据和非结构化数据的统一管理。

从实时数仓到 Lakehouse ，保持不变的是，在 BI 方向上引入更多交互和场景化，实现更贴合业务高峰和低谷的资源供给，进一步 SaaS 化，从而降低成本；实现全链路实时化的同时保持成本可控，实现实时性和成本的平衡，实现一个低成本、全链路实时化的数据架构；另外，追求一体化、精简的数据仓库，从而将更多资源和能力投入在业务创新上。

变化的部分则包括，大语言模型将逐步深入企业应用，而 AI 相关应用需要全新的数据基础设施，AI infra 将从自行组装转变为依靠全托管平台。从数据管理和组织的角度来看，湖仓一体技术能够让管理更加一致化、多元化，同时管理结构化数据、非结构化数据、文本数据、 JSON 数据和图片数据。数据平台本身的技术也将借助智能化方式加速发展和迭代，如何利用 AI 迭代数据平台技术，也是云器重点研究的方向之一。