降本提效 60%，ProtonBase 助力新兴企业精简架构与实时数仓转型的实践

导读：在 IoT 物联网场景，随着传感器和物联网技术的大量应用，海量 IoT 设备生产了大量的数据，比如制造业工厂生产线、新能源汽车、城市安防监控摄像头和各类机器人应用场景等。这类场景的共同特点是数据生成频繁，数据规模大，可能轻易能达到数百 TB 甚至 PB 级别。

当前大部分企业内对于大数据的解决方案都是基于 Hadoop 体系，但是 Hadoop 组件极为复杂，有较高的开发和运维门槛，对于很多企业来说成本太高。ProtonBase 在一个系统内实现了事务处理、实时数仓、数据湖分析、全文检索以及向量检索等企业级核心数据存储和查询的需求。能够支持高吞吐低延迟的实时写入，并且保证数据的一致性，在数仓场景是一个更好的数仓。因此可以用来替换 Hadoop 体系，降低系统复杂度，同时降低开发和运维等方面的成本。

01/业务背景

客户是国内机器人领域某头部公司，由于业务场景复杂和一些历史原因，当前线上的数据库产品种类较多。各个业务部门分别使用一款或者多款不同的数据库产品，经过 Sqoop 数据同步工具将数据同步到自建的 Hadoop（Hive）系统中。Hadoop 内使用传统的数仓分层设计来对数据进行分层建模、数据处理和汇总。最终的数据通过 BI 报表工具，来进行数据同步、抽取和报表展示，在公司内部提供报表展示与大盘系统，供关键的决策人员和运营人员进行一些数据分析，根据业务的发展情况来决定是否要及时做出一些业务调整。

我们通过这个客户案例来展示 ProtonBase 在替换以 Hadoop 为代表的离线数仓过程中能为客户带来的价值。

企业原大数据系统架构

上图是客户之前的大数据系统的架构图。客户的业务系统使用了 RDS MySQL、RDS PostgreSQL、MongoDB 和 Kafka 等数据产品。同时基于自购的云主机搭建了离线 Hadoop 系统。各业务系统的数据经由不同的接入服务汇聚到 Hive 中，以提供具体的数据应用，比如报表分析、即席查询和大屏展示等。

02/原有数据系统成本高、延迟高、数据处理链路长

业务数据到数仓的流转过程分批量与实时同步两条链路。批量数据同步由 Sqoop、ETL 等同步工具定时完成，实时同步由客户自建服务消费 Kafka 数据并且进行一定处理流入离线数仓。业务初期，各个数据库数据量不大，这种方式能比较好的满足业务需求。同时经由数仓 ODS、DWD、DWS 和 ADS 各层的处理，报表系统也能正常运转。但是伴随业务的飞速发展和数据量的快速增长，各种问题开始暴露出来：

1. 自建 Hadoop 成本偏高：为支持各种离线数据处理，客户自己购买多台云主机部署 Hadoop 系统和一些中间层服务组件，从最近两年的费用统计来看该部分在整体云产品中消费占比较高。
2. 数据处理链路长，问题排查不便：为定位或修正 BI 报表中的数据错误，往往需要在 Hive 数仓中层层排查，耗时耗力，效率不高。排查完 Hive 数仓后，可能发现应用在写业务库时已经出错。
3. 数据同步耗时长，时效性差：随着业务的快速发展，现有的数据同步流程逐渐暴露出以下制约因素：

• 由于当前使用的 Sqoop 工具只能进行全量同步，随着数据源的持续增加和数据量的快速增长，导致每天的所需的同步时间不断增加。
• 传统的 T+1 数据同步时效性已经无法满足业务决策需求，然而数据量的增加进一步延长了同步和建模流程的时间，这与提升报表时效性的目标背道而驰。
• 一些新业务的数据库由于数据量较大，使用 Sqoop 全量同步至 Hadoop 耗时过长。而如果直接同步至 BI 系统，则无法满足复杂数据分析的需求。
• 目前，BI 报表系统与 Hadoop 部署在阿里云，各个数据库数据源则部署在腾讯云。出于采购折扣和简化运维的需求，客户期望将所有系统统一至腾讯云。

基于以上问题，客户决定对现有的离线大数据系统进行升级。希望在支持异构、多源的云端数据库产品同步的基础上，降低成本，简化业务建模流程，并提升报表数据的实时性、准确性。

03/ProtonBase 实践：从离线向实时数据仓库升级转型

从前述分析中可以看出，客户当前面临的主要问题是现有的离线数据仓库解决方案架构复杂，并且随着业务的迅速扩展，已无法有效支持其决策分析的需求。这实际上是一个从离线数据仓库向实时数据仓库（Real-Time Data Warehouse，RTDW）升级转型的典型场景。

实时数据仓库是一种融合了实时数据处理技术和数据仓库理念的先进大数据解决方案。相较于传统的离线数据仓库，RTDW 能够在极短的时间框架内完成数据的处理、存储及分析工作，从而赋能企业基于最新数据快速作出决策。

在当今这个数据驱动的时代背景下，拥有实时数据仓库意味着企业能够具备即时的数据处理能力，充分发掘数据的潜在价值。通过实时数据，企业可以迅速捕捉市场动态，及时调整策略以应对竞争压力。构建实时数据仓库的核心目标在于让企业能够即时获得信息并作出响应，这一响应时间范围可缩短至几小时、几分钟乃至秒级。因此，为了适应实时数据仓库的需求，企业必须超越传统的 ETL 工具和离线数据仓库架构，采用更为先进的技术手段。

ProtonBase 结合了实时数仓和数据库的能力，提供了云原生的数据解决方案。具备高性能分布式架构，确保超低延迟和海量数据吞吐能力。提供极致弹性和按量付费选项，简化运维工作。同时，ProtonBase 自带数据同步服务，能支持多源异构数据产品导入到 ProtonBase，如 MySQL、PostgreSQL、SQL Server、Oracle 和 MongoDB 等。在全量导入模式下，可以一次性将全量数据导入 ProtonBase。在增量导入模式下，数据同步服务既可以同步上游的增量数据信息，又可以识别 DDL 变更及时应用到 ProtonBase 端以保证后续新 Schema 格式下的增量消息同步。从而使整个增量数据同步流程做到纯实时。

💡支持 Schema Evolution 的多源数据同步服务，轻松应对业务层数据变更

ProtonBase 对外提供可跨异构数据存储系统的、可靠、安全、低成本、可弹性扩展的数据同步服务，为包括数据库（MySQL、PostgreSQL、Oracle 和 MongoDB 等）、消息中间件（Kafka）和日志系统（OSS）等多种数据源提供了不同网络环境下的全量/增量数据进出通道。

ProtonBase 的数据同步服务具有以下特性：

• 支持单表、多表、整库、整实例同步
• 支持字段裁剪、字段映射、类型转换等操作
• 支持分库分表同步到一个目标逻辑表
• 支持 DDL 变更，包括新增表、新增字段、修改字段类型等操作
• 简单易用，通过前端 UI 可以比较容易的配置数据同步任务

ProtonBase 数据同步服务既支持全量数据的一次性同步，又支持实时增量数据的持续同步。增量数据同步除了要支持对不同源端的增量消息的订阅和解析，还要支持线上 DDL 变更（列变更、字段类型变更、索引变更和约束变更等）。如何同步这些变更，并且应用到目标端 ProtonBase。ProtonBase 同步工具支持了 Schema Evolution 的能力，能够应对上游业务层源端数据的各种复杂 DDL 变更的场景。在该客户场景下，ProtonBase 实时同步了上游 MySQL、PostgreSQL、MongoDB 和 Kafka 等的多个数据源，所有数据源的数据同步延迟在亚秒级。

在客户部署新架构之后，ProtonBase 数据同步服务以其在前端界面配置任务的便捷方式，实现了对诸如 MySQL、PostgreSQL 和 MongoDB 等多种数据源的实时增量数据订阅，延迟低达秒级。此外，该系统还支持根据用户的具体需求，选择性地同步部分数据库或表，并允许在同步过程中重新命名目标数据库中的数据库名、模式名或表名（db/schema/table）。

💡通过物化视图简化数据建模

物化视图（Materialized View）是 PostgreSQL 提供的一个功能，它是单表索引的推广。ProtonBase 实现了物化视图的全量刷新、增量刷新和实时查询等功能。

物化视图和视图的最大区别是它不仅存储定义中的查询语句，而且会把视图的查询结果存储下来。物化视图和表的最大区别是它不支持 INSERT、UPDATE、DELETE 以及 MERGE 语句，只能通过刷新物化视图进行数据的更新。物化视图通过提前运行并存储查询结果，通过空间换时间，适用于查询优化、数仓加工、数据集成等场景。

在传统的数据仓库中，数据建模通常分为 ODS（操作数据存储）、DWD（明细数据层）、DWS（数据聚合层）以及 ADS（应用数据层）等多个层次，涵盖数据清洗、聚合与汇总等处理工作。引入 ProtonBase 后，对于数据量较小的建模任务，可以直接转化为在线实时计算。而对于那些计算量较大的建模任务，由于数据规模庞大及统计逻辑的复杂性，加上计算的结果可能要被多次查询。我们采取了物化视图加定时刷新的策略，以此替代原有的建模流程，并加速最终的报表统计查询速度。具体实施方法是在 ProtonBase 中定期执行数据清洗及宽表联接等复杂操作，随后基于这些物化视图进行实时的统计查询。

这样做的好处是可以简化架构系统的复杂度，不再需要维护之前建模和调度依赖的过程。通过物化视图的语句也可以把之前的建模流程沉淀下来，修改建模流程变成只需要调整 SQL 语句就可以完成。

💡通过托管服务降低运维复杂度

ProtonBase 以托管服务（Hosted Service）的形式提供给客户。这种方式不仅简化了使用流程，还极大地减轻了用户的运维负担。针对该用户的特定场景，ProtonBase 通过降低运维复杂度给客户带了如下价值：

1. 专注核心业务：由于企业内部资源有限，使用托管服务能够让开发团队将精力集中于报表业务的开发上，专注于提升核心竞争力，而不是耗费时间在底层基础设施的配置与管理上，或是陷入繁琐的运维工作中。这有助于显著缩短报表业务的开发与上线周期。
2. 强大的弹性伸缩能力：随着业务的增长，数据量的增加将不可避免地带来扩容需求。作为一款面向云原生设计的产品，ProtonBase 提供了简便的扩容机制——仅需在控制台进行简单的配置修改即可，扩容操作能在秒级时间内完成新节点的启动。
3. 无限存储扩展：ProtonBase 的存储架构支持无限扩展，扩展时无需数据搬迁，用户无需预先估计存储需求，也避免了因估算不足而频繁进行手动扩容的麻烦。相反，ProtonBase 依据实际使用的存储空间进行计费，确保用户可以根据实际需求灵活使用存储资源。

以下是升级前后的架构对比：

04/总结与展望使用

ProtonBase 转型现代实时数仓的落地收益

在和该机器人公司的合作过程中，ProtonBase 简化了原有基于 Hadoop 的大数据架构，节省超 60% 的成本，提升了报表数据的实时性至小时级，并简化了问题排查流程。通过支持多源数据同步、物化视图简化数据建模以及对跨云迁移的支持，ProtonBase 显著提升了系统的效率和灵活性。具体收益如下:

💡从 N 到 1，精简架构，降本 60%

ProtonBase 作为实时数仓，比较好的解决了用户的多平台问题，全面统一了技术栈，实现实时与离线技术栈的一体化。除了支持报表查询，还能作为在线的数据库产品提供即席查询和高并发 Serving 查询的能力。之前客户为了部署大数据离线系统，每年成本较高，替换为 ProtonBase 后节省超过 60% 的成本。ProtonBase 自带的同步工具，支持已有的 MySQL、PostgreSQL 和 MongoDB 等业务源的数据同步，简化掉了原有的中间服务层，也极大降低了客户数据系统的复杂度。

💡简化运维，高效排查问题

原系统下，一旦出问题整个排查链路中涉及的产品较多，排查步骤比较复杂。在报表端发现问题后，排查链路一般从大数据离线系统开始逐层排查。比如大数据系统内排查 ADS、DWD、ODS 各层的数据处理是否异常，定时同步任务是否正常，消费 Kafka 数据写入 Hive 的后端自建同步服务是否正常等。替换 ProtonBase 后，只需要在数据库中使用 SQL 验证数据正确性，就能很容易定位数据丢失问题和业务源端表的正确性问题，极大简化问题排查链路，提升问题排查效率。

💡实时数仓，T+1 Day 到实时决策

在基于 Hadoop 的离线大数据系统下，受限于全量数据同步和离线数据处理时间，BI 报表数据的实时性为天级别。在业务迅速发展的时候，一些依赖报表数据的关键决策不能很快做出，一定程度上影响了业务。ProtonBase 通过对存储格式、索引、优化器、执行引擎等进行了深度的优化，支持在实时数据写入的同时提供良好的查询性能。客户场景在替换 ProtonBase 方案后，数据实时流入 ProtonBase，报表的时效性由天提升到小时。

💡多云中立，跨云迁移

ProtonBase 支持多云环境部署，这意味着如果客户未来有迁移至其他云平台的计划，可以借助 ProtonBase 提供的迁移工具，以相对较低的成本实现跨云迁移。相比传统的迁移流程——首先需在目标云平台上寻找相应的数据库产品，然后重新导入数据并进行数据校验，ProtonBase 的解决方案能够显著减少云迁移所需的工作量。

05/未来展望

未来，ProtonBase 将尝试在客户场景下进行以下两个合作，来进一步帮助客户降本增效、简化运维。

💡替换在线业务库

ProtonBase 作为一款支持混合负载的数据库引擎，在数据库领域展现出了显著的优势。在数据库领域，ProtonBase 是一个更好的数据库，其具备出色的水平扩展能力与分布式事务，可以根据业务需求动态增加计算节点。ProtonBase 的这些特性使其成为替换现有在线业务库的理想选择。通过直接使用 ProtonBase 作为在线业务库，可以省去数据同步的环节，从而避免数据冗余，降低存储成本。这一改变不仅简化了数据管理流程，还提高了数据处理的效率。

目前在该客户的业务场景下，ProtonBase 是作为一个数仓来使用的。各个业务仍然使用了不同的数据库产品，比如 MySQL、PostgreSQL 和 MongoDB 等。这些在线业务库后续也可以逐步迁移到 ProtonBase 。ProtonBase 通过只读实例功能可以对写入流量和报表查询流量进行物理隔离，确保写操作的高效执行，同时也保证了报表分析的即时性和准确性。

💡冷热数据分层

针对大型任务表中大量历史数据，客户目前会进行定期的手动归档。归档的策略需要精心设计，以确保正确地选择哪些数据进行归档，以及如何归档。这涉及到表结构的设计、索引管理以及与应用程序的交互等方面，增加了管理复杂度。在执行归档操作期间，可能需要暂停某些数据库服务，这会导致应用程序不可用，影响用户体验和业务运营。ProtonBase 计划引入冷热分层的存储策略。通过为分区子表指定不同的存储介质，可以实现冷热分层的功能。将不常用的历史数据自动迁移到成本更低的存储介质，如 S3 上的冷存储。这种策略不仅能够显著降低存储成本，还能提高数据管理的效率，避免手动归档的操作，减轻运维人员的工作负担。