一、背景介绍
为什么得物需要自建大数据研发与管理平台？
得物作为一家数据驱动型互联网企业，数据使用的效率、质量、成本，极大影响了公司的商业竞争力。而数据链路上最关键的系统是计算存储引擎和数据研发平台。其中计算存储引擎决定了数据的使用成本，数据研发平台则决定了数据的交付效率、数据质量以及数据架构合理性。
得物数据生产链路
过去整套大数据基础设施我们都使用云上商业化产品（下文简称"云平台"），但在各方面已远无法匹配上得物长期的业务发展。目前得物大数据面临着如下挑战：
因此24年技术部正式启动大数据系统自建，Galaxy数据研发与管理平台为其中一个重要项目，负责面向参与数据生产的用户，提供离线和实时数据的采集同步、研发运维、加工生产、数据资产管理以及安全合规的能力，满足业务长期发展对于数据架构、数据质量、数据交付效率的诉求。
二、产品功能架构
下图为整体产品功能架构，其中蓝色部分为当前已落地功能，灰色部分为规划中的功能。
Galaxy数据研发与管理平台产品功能架构
24年立项开始至今，我们主要专注在4个最核心能力的建设，分别为：数据研发套件、数据架构技术、数据质量技术、智能化数据研发。如果把数据研发平台比喻成一辆汽车，那么这四部分的定位如下图所示：
下文会对这些关键技术实现、落地进展以及Galaxy数据研发平台的架构演进，进行解析。
三、数据建设的"驾驶舱" - 数据研发套件
3.1 系统架构解析
数据研发套件包含数据研发IDE、数据资产系统、离线任务调度系统 三部分，在平台中的定位类似于"汽车的驾驶舱"，为数据工程师提供丰富的工具集，控制全公司的数据流动与计算。整体系统架构如下图所示：
3.2 数据同步技术解析
数据同步也叫数据集成，它是Galaxy数据研发平台的核心组件之一，主要用于公司各种异构数据源与数据仓库进行数据传输，打通数据孤岛。它作为大数据链路加工的起点和终点，不仅用于数仓ODS层（Operational Data Store，保存原始数据）的入仓构建，也负责将数仓数据回流（出仓）到消费侧的各种数据源中。
离线数据同步
离线数据同步是最为主流的一种数据同步模式，以批量读写 的形式将源表以全量或增量 的形式周期性的写入目标表。目前Galaxy数据研发套件支持了多种类型数据源的离线同步，包括：
目前Galaxy数据研发套件的离线同步内核基于Spark Jar进行实现，下图为离线数据同步架构：
Galaxy数据研发套件离线数据同步架构
离线数据同步的具体实现执行流程（以MySQL同步至得物自建离线存储系统为例）：
MySQL离线同步至得物自建离线存储系统的执行流程
实时数据同步
离线数据同步存在着一些局限性，主要有：
- 对在线数据库压力大，即使是读库也可能影响线上部分业务的稳定性。而如果单独为数据入仓申请一个备库，又会带来较大的额外成本；
- 大表同步时间长（可达7小时）此类任务基本无法保障下游重要数据产出的SLA；
- 需要在短时间传输大量数据，对网络带宽依赖高；
- 数据时效差，最快也是T+H的延迟，无法满足实时报表等对时效性敏感场景的需求。
因此需要实时数据同步的能力对此类场景进行补充。我们主要支持两种实时同步方案：
1）基于业务库binlog的的实时入仓
对比离线数据入仓，基于binlog的实时入仓可以避免对数据库造成压力，减少了对网络带宽的依赖，同时对于超大规模的表可以大幅缩短基线加工时长。但此方案依然需要（小时/天）将增量数据和全量数据做Merge处理和存储，这会产生冗余的计算和存储成本 ，且时效性也较差，因此本质上只能为离线数仓场景服务。
2）实时镜像同步
通过实时计算引擎Flink CDC将变更数据实时更新到存储系统中，保持数仓ODS表和来源数据库表的增全量同步，整体架构更加简单，并减少ODS层的批计算和冗余存储成本。目前规划通过Paimon、Iceberg等开放Lakehouse能力来实现离线存储系统的实时事务性更新。根据实际业务场景，也可以直接将数据实时写入StarRocks等支持更新的OLAP数据库中。
3.3 数据研发套件任务迁移方案解析
在过去得物的全部数据加工任务全部运行在云上数据平台，因此除了对齐产品能力外，我们还需要将数据加工任务从云平台"平滑"的迁移到Galaxy研发平台。
由于调度系统的故障风险极大，一旦异常很可能由于依赖错乱导致数据异常或停止调度导致的数据产出延迟。因此我们将Galaxy研发套件的平台层迁移和调度层迁移进行解耦，以便将调度系统的迁移节奏放缓。
首先进行风险较低的研发平台层迁移，让业务可以尽快上线，便于优化数据研发流程和数据资产管理能力。此阶段任务的调度依然运行在云平台。之后再进行调度层的迁移，这个阶段用户基本无感，完成后则彻底不再依赖云平台。
因此架构上一套研发平台需要同时适配两套调度系统（云任务调度+Galaxy自研调度系统 ），并支持逐步往自研Galaxy调度的平滑演进。
为了让调度迁移的过程需要如同"数据库主备切换 "一样，尽量让用户无感，我们使用了影子节点 的方案，以实现迁移流程的业务无感、可灰度、可回滚 。影子节点本质是一个Shell任务，当调度系统启动它后，它会通过Rest API检测对方调度系统中实体节点 的状态，并与它保持状态同步。通过影子节点 ，我们可以实现按照任意调度任务id进行灰度迁移，调度迁移本质就是将云平台的实体节点替换为影子节点。如下所示：
基于"影子节点"的双调度互通方案
3.4 功能建设与迁移进展
1）功能对齐与优化
目前Galaxy研发套件已完成与原云数据研发平台的主链路功能对齐，具备数据研发与资产管理的全套流程，同时还针自建Spark引擎查询和运维、在线数据入仓等方面进行定向优化。提效成果：
临时SQL查询性能优化
通过简化调用链路+Spark Driver预启动等查询加速技术，平均每个Query可以比原云数据研发平台固定节约35s+。
减少查询等待时间：290+人日/月
在线数据入仓自动化提效
通过工单申请即可实现MySQL数据入仓。自动帮用户创建同步数据源、增/全量ODS表、同步任务、增量Merge任务，并自动赋权以及数据初始化。根据用户调研和埋点分析，每个数据入仓需求可提效30min+。
提效效果：20+人日/月
2）业务迁移进展
目前我们已完成数据平台、数据挖掘、数据分析团队的全部任务迁移（占得物全域的44%），并完成了算法团队的POC。同时还将上述团队的临时取数业务迁移到了自建Spark引擎，从而实现云上商业版计算引擎的DEV资源缩容400+cu，总计可节省临时取数计算成本约2万+/月。
四、公司数据资产的"底盘"-数据架构技术
目前，公司业务用数越来越敏捷和频繁，而数据资产却没有做到"好找敢用 "，大量的重复数据和数据烟囱也随之出现。这不仅导致大量数据二义性 问题，同时也使计算存储成本难以控制 。以离线数仓社区&交易的试点域为例，重复冗余表达到了54%，重复指标达到了35%。这本质上是缺乏数据架构体系的建设 ，数据架构是公司数据管理的"骨架"和"路线图"，它如同"汽车的底盘"，忽视数据架构可能导致数据的无序增长以及业务的决策错误。
4.1 Onedata数据架构方法论
及工具体系
Galaxy数据研发平台基于"Onedata "的数据架构方法论，建立了统一的数据采集和生产规范 ，使数据的新增更加合理、易用，提高数据的复用度、研发效率、交付质量，降低使用成本。这是一种"内啡肽"式的数据建设，前期需要花费一定时间进行数据模型的设计并遵守数据研发规范，但从业务的长远发展来看，这是必须要走的一步。
目前我们已在数据采集入仓和数据研发两个环节完成了数据架构能力建设，确保数据的入口（ODS）以及数据仓库的规范性，并再后续通过旁路数据治理的手段进行存量数据的规范化。如下图所示：
Onedata数据架构工具体系
融入了Onedata数据架构技术体系（红色部分）后的Galaxy数据研发平台架构如下图所示：
融入Onedata规范数据生产能力（红色部分）的
Galaxy研发平台技术架构
下文主要对两个关键模块，统一ODS自动化入仓平台、Onedata数据建模的实现方案进行解析。
4.2 统一ODS自动化采集入仓方案解析
ODS（Operational Data Store），为操作数据层，是整个数仓最基础的一层，是原始数据采集入仓的第一个环节。Onedata的核心理念之一是所有的数据采集有统一的规范和入口。因为随意的从在线库进行采集同步会导致大量重复的数据存储，以及过长浪费的表存储生命周期。
由于数据的采集入仓本身没有过度复杂的业务逻辑，因此Galaxy数据研发平台实现了自动化数据采集入仓能力，提供在线数据源到数仓ODS层的标准化采集和管理能力。无需研发代码的同时，产生的数据都是严格满足架构规范的。具体价值有：
- 避免重复ODS数据存储
- 通过库owner+数仓owner双重审批，避免不合理的数据入仓
- 控制ODS表生命周期，避免存储成本浪费
- 全流程自动化，提高ODS层数据研发效能
目前支持MySQL和TiDB的全量采集同步和增量采集同步 。同时，开启自动更新模式的入仓任务，还会订阅来源MySQL表的变更消息，并自动更新同步任务。关键流程如下：
自动化数据入仓流程
4.3 规范数据建模与自动化指标研发方案解析
Onedata在数据研发环节，核心采用维度建模的理论。它构建了公司级的一致性维度、标准化的事实表以及可灵活分析的汇总表和无二义性的指标。并将数据进行清晰的分层，将公司内部分散、异构的数据整合成一套可信、可复用、可分析的数据资产。其主要价值有：
- 保证维度和指标一致性：通过维度和业务过程的概念建模，确保维度表和事实表的全局唯一性；同时通过原子要素的指标建模，确保指标口径的全局无二义性。
- 提升开发效率：数据工程师无需重复构建维度表和基础事实表，直接复用数仓公共层的成果；同时指标原子要素定义完成后，指标和汇总表的代码全部可以系统自动化生成和优化，大幅提高效率，也减少出错的可能性。
- 增强数据可解释性：明确的表业务描述以及字段关联的指标和维度，以及清晰的星型/雪花模型关系，使数据的消费侧更方便的使用数据。
- 事前治理：严格根据架构规范进行数据研发，禁止重复表的新增，约束数据表的生命周期、数据依赖等，避免事后运动式治理。
Onedata核心概念、建模流程以及配合工具如下图所示：
Onedata的数据建模流程
其中最为关键部分为"指标建模"。我们将指标的口径组成拆成了三部分组成：原子指标、业务限定、统计周期 ，同时在其物化到表上的时候再确定统计粒度。通过原子要素的组合定义指标可以确保同样的指标在公司全局只会有一个，以及标识出不同的汇总表、应用表中的指标是否为同一个。另外当原子口径发生了变化，系统也可以根据血缘关系找到受影响的指标和表，让owner进行握手确认，确保口径变更一致性。例如下图所示：
1个原子指标口径变更，影响了7个关联指标、
2张表的同步变更
从上图我们也可以看到，原子口径的变更影响非常大，即使可以基于血缘进行变更握手管控，人工修改逻辑也容易改错或遗留。因此我们实现了自动化指标代码生成的能力，基于原子口径自动化生成指标及其物化表的加工逻辑。
指标代码自动化生成方案：
将指标按来源表分组，并将其的组成原子要素（原子指标+业务限定+统计周期+统计粒度）进行SQL逻辑的组装、优化、方言翻译，具体流程为：
数据建模与指标SQL生成案例：
1.数据建模
2.代码生成
3.代码优化 - 指标SQL优化规则
4.4 当前落地进展与效果
1）统一自动化ODS采集入仓
目前已实现通过工单申请的方式一键完成MySQL和TiDB的数据进行增/全量自动化采集入仓能力，无需人工编写代码即可实现规范的数据入仓。产品效果如下：
业务成果：
- 业务域落地：目前已在得物内部各域全面落地统一ODS入仓能力。2025年Q3，得物全域新增的入仓任务93.6% 是通过Galaxy自动化采集入仓平台自动化生成的；
- 表生命周期规范：25年新增ODS表生命周期定义率较24年Q4提升7.4倍，节约了大量离线存储；
- ODS存储增量控制：通过源头规范数据入仓，配合数据治理团队使数仓ODS层存储季度增幅降低：32%->8%
2）规范建模与自动化指标代码生成
目前已完成数仓规划->概念建模->明细表维度建模->指标建模->指标代码自动化生成->汇总表代码自动化生成的Onedata规范建模研发全流程，产品效果如下：
业务成果：
- 商家域数仓Onedata一期落地效果：完成了40+ 数据资产沉淀与规范化汰换改造，以及190+应用指标 定义与上架，同时沉淀了100+公共派生指标。通过数据规范化重构、二义性问题的解决以及自动化代码生成的能力，可实现商家数据需求数仓开发效率提升40+%，每迭代线上需求吞吐量提升75%->90%。
- 社区域数仓Onedata一期落地效果：完成1200+应用指标 的定义与上架，实现100%无二义性。通过精品资产的规范建设与切换，通过复用公共层数据，实现5+万/月的成本下降。由于数据二义性的解决以及资产规范度的提高，实现数仓和分析师用于口径oncall和业务取数的人力成本减少约10+人日/月。
五、数据生产的"刹车片" - 数据质量技术
得物数仓发展至今，不仅用于高管决策以及数据报表的场景，同时和得物线上业务做了非常强的耦合，各域均存在P0级资损风险场景，例如：社区数仓的运营投放、算法数仓的新品商业化、交易数仓的费率折扣、营销域、用户域等等。这些数据直接应用于线上业务，任何的数据质量问题都可能导致公司、商家、用户的利益受损，以及业务对数仓的信心丢失。
然而过往数仓的数据交付只是停留在快速提供数据以发挥业务价值这一步，业务和研发对数据质量和稳定性保障重视度严重不够，并且没有明确生产变更和数据质量校验的SOP，同时也没有健全的工具体系支撑，全靠数据工程师的自我修养，导致历史上很多核心数据加工任务没有保障或者保障不全面，不断引发P级故障。
5.1 Galaxy的数据质量工具体系
数据质量的相关工具就如同"汽车的刹车片"，可以想象没有刹车在路上行驶是如何的危险。因此我们在Galaxy数据研发平台建设之初就同步进行了数据质量工具的开发。目前所建立起来的离线数仓质量加固SOP及配合的工具如下：
离线数仓质量加固SOP
目前重点建设的2个核心功能，分别为：数据质量校验规则 ，用于监控生产数据质量并进行及时阻断止血，避免下游数据污染；以及数据变更管控流水线，在数据生产变更的环节嵌入消费场景打标、自动化风险扫描、code review、自动化数据测试、发布审批等功能，以全面保障数据质量。融入了数据质量技术体系（红色部分）后的Galaxy数据研发平台架构如下图所示：
融入数据质量能力（红色部分）后的Galaxy数据研发平台架构
5.2 当前落地进展与效果
数据质量校验规则
Galaxy数据研发平台已经实现了完善的数据质量规则校验能力，用户在Galaxy数据研发IDE上面向数据标准 进行高效的质量规则定义，系统会自动生成校验SQL随着任务的发布一起下发到调度系统中执行。同时支持了强规则（主路执行，数据异常阻断任务执行）和弱规则（旁路执行，数据异常进行告警） 两种规则运行场景，应对不同的场景诉求。产品效果如下所示：
场景覆盖方面已经实现了表非空校验、表波动校验、字段主键校验、字段非空校验、字段波动校验、字段枚举校验、自定义SQL校验等15种规则，覆盖了离线数仓100% 的校验场景。
同时通过批量导入、弱转强等提效工具帮助离线数仓团队在25年Q3新增了1200+质量规则，全量P0任务质量规则覆盖率达到96%，非P0任务86%。并结合发布管控流水线能力，实现了P0场景任务100%变更覆盖表级规则 ，且金额等高风险字段100%变更覆盖字段级规则。
数据变更流水线
目前已经完成了完整的变更管控流水线的能力，主要功能包括：消费场景打标、静态风险扫描、Code Review、冒烟测试、数据探查、数据比对、发布审核。产品效果如下所示：
其中，场景打标方面，离线数仓末端任务（ADS和回流）98.3% 打标了数据消费场景，对于全链路分析数据重要性和消费场景起到了巨大的作用；变更管控方面，静态扫描节点已实现了48个 风险扫描规则，覆盖了94% 的已知风险场景，当前系统自动化风险识别率98% （剩余为人工CR发现的问题），平均每双周可事前拦截600+起风险事件。
六、数据研发之路的"辅助驾驶"-智能化数据研发
过去10年，通过开源大数据组件的兴起，大幅度降低了企业构建大数据Infra的难度，在一定程度上实现了企业间的"数据平权" 。而在企业内部，由于数据同步、ETL研发调度、资产管理、数据治理等复杂的技术导致找数和用数门槛非常高，因此大部分场景都是提需求给数仓团队进行数据加工，那么数据团队的交付效率 就变成了公司各业务线数据化经营决策的瓶颈。
6.1 Galaxy的智能化演进路线
我们计划分3个阶段（L1～L3）建设Galaxy数据研发平台的智能化能力，来提升数据研发效率，降低业务自主进行数据研发的门槛，实现公司内部不同部门和岗位间的"数据平权" 。如下所示：
Galaxy数据研发智能化演进路径
当前我们处于L1的Copilot阶段，通过在数据研发流程中，旁路嵌入基于专家经验规则和大模型的智能SQL代码续写、智能任务诊断、智能SQL代码纠错与优化、 智能质量规则推荐 等应用，辅助用户进行高效数据研发。嵌入Copilot后的Galaxy研发平台整体架构如下，主要关注红色部分：
数据智能化L1阶段的Galaxy研发平台技术架构
下文主要对当前较为成熟的功能，智能SQL代码续写的实现方案进行解析。
6.2 智能SQL代码续写方案解析
SQL代码续写的重点在于工程链路，大模型上我们选择适合代码生成的小参数模型，当前使用了Qwen-2.5-coder，后续会进行其他模型的实验。系统流程如下：
智能SQL代码续写系统流程
关键模块功能描述：
6.3 当前落地进展与效果
目前Galaxy研发平台已经落地了智能代码续写、智能任务诊断、智能SQL纠错与优化3个Copilot应用，具体业务效果如下：
其中高活用户的智能代码续写功能开启率为98.5%，整体采纳率趋势和我们做的优化动作如下：
智能SQL续写采纳率趋势
（2025年04月25日～2025年09月09日）
七、后续规划
后续Galaxy数据研发平台会持续完善现有功能提升产品体验，同时在智能ETL Agent、Data Fabric、数据逻辑化三个前沿方向进行探索，通过技术先进性为公司数据业务带来更多的价值。
7.1 长期规划一：智能ETL Agent
核心目标：数据研发提效，并降低数据研发门槛
ETL Agent核心能力是需要将用户的自然语言业务需求翻译成数据表的SQL加工逻辑，其本质上就是"NL2SQL"的传统命题。然而，如果让大模型直接分析用户的问题，那么它需要尝试从底层混乱的物理表结构中生成目标SQL，这会将业务语义的复杂性完全压给大模型，导致同一指标因表结构理解偏差或字段映射错误而产生不同结果。
Galaxy的ETL Agent会采用"NL2Metric2SQL "的方案。通过大模型进行自然语言的解析，结合向量数据库的相似度匹配实现NL2Metric的能力，然后基于Onedata数据模型和指标语义层，将自然语言的用数需求 准确翻译为指标原子要素 （原子口径、业务限定、统计周期、统计维度），并自动构建ETL加工链路。如下图案例：
智能ETL Agent用户流程案例
这也是Galaxy智能化的L2阶段，这个阶段将数据研发分成了专家数据研发 以及智能数据研发。专家模式依然按传统SQL任务进行数据研发。而智能研发则以自然语言形式的数据需求作为输入，通过提前将Onedata数据模型存储在RAG的向量数据库中，然后根据数据需求内容进行分词，按相似度从RAG中匹配出相关的指标要素构建出提示词，并请求大模型获得正确的指标要素。
实现智能ETL Agent后的智能化L2阶段Galaxy研发平台架构（红色部分为Agent相关模块）
7.2 长期规划二：Data Fabric
核心目标：减少非必要的离线数据存储成本
传统的数据集成（数据入仓）方案是通过离线或实时数据同步工具将公司内部各数据源的数据全量或增量地抽取、清洗、加载到一个中心化的数据仓库中。但这种方案在技术上存在三个问题：
- 离线存储成本大：传统的数据集成方式，离线数仓的ODS层会拷贝全部所需在线数据的副本。然而其中很大一部分的数据仅用于短期分析，或用于对RT不敏感的查询场景，这些数据在离线数仓中物化存储的ROI极低，造成了大量存储成本浪费。
- 数据搬迁成本大：随着业务的发展，公司的数据源可能分布在不同地域、不同云环境。周期性的将海量数据同步至中心化数仓，将产生巨大的网络带宽成本和入仓等待时间。同时入仓需要与数仓工程师进行需求沟通，也存在大量协作成本。
- 数据一致性问题：数据同步有显著延迟，在离线同步的场景下，分析的数据会有天级延迟。
Data Fabric（数据编织）是一种全新的数据集成架构方案，核心理念是 "不移动数据，移动计算 "。 技术实现方案上以外表的形式来封装源端表，通过统一的元数据系统，将源端表（外表）和离线表（内表）统一管理起来，使用起来对用户无感。在执行计算时，通过Spark引擎的跨源联邦查询能力，直接从各源端数据库（一般为备库或抽数库）将数据查询回来后进行分布式计算。下图展示了Data Fabric与传统数据集成的区别：
7.3 长期规划三：数据逻辑化
核心目标：计算存储成本降低，数据研发与运维提效
通过视图或参数化视图 进行整条数据链路的构建，那么整条链路就完全不需要任何存储成本，计算成本也仅在视图查询时才发生。但这样会导致一个问题，当视图逻辑复杂，嵌套层级多时，查询效率非常低，且对相同视图的查询都需要重新计算。因此我们需要对一些关键的视图进行物化，物化后的视图，在查询时可以直接访问其物化表，实现查询性能的大幅提升。
数据逻辑化架构，会存在两层，上层为由用户定义的物理表以及虚拟视图 组成的逻辑层 ，对用户感知；下层为物理表和系统自动生成的视图物化表 组成的物理层，对用户不感知，具体如下图所示：
数据逻辑化的架构分层
数据逻辑化的关键技术之一为视图物化表的命中。当某个视图存在物化表时，需要将对应查询范围的数据直接翻译成物化表的查询，而不去展开视图查询，以提升查询性能。技术链路如下图所示：
数据逻辑化的视图物化命中改写链路
另一项关键技术为视图的物化策略与回收策略。系统需要定期通过算法识别出在满足产出时效的前提下，整体计算和存储成本最低的物化方案。例如下方案例：
数据逻辑化的视图物化与回收策略
目前全域优化场景简单且有效的算法有遗传算法、模拟退火算法等。通过评估在一定存储成本限制下，哪些视图的物化组合，可以使用整体计算cost最低。
将数据虚拟化技术和ETL Agent能力结合，我们可以实现系统自托管的智能数据研发，即Galaxy智能化的L3阶段。
往期回顾
-
从一次启动失败深入剖析：Spring循环依赖的真相｜得物技术
-
Apex AI辅助编码助手的设计和实践｜得物技术
-
从 JSON 字符串到 Java 对象：Fastjson 1.2.83 全程解析｜得物技术
-
用好 TTL Agent 不踩雷：避开内存泄露与CPU 100%两大核心坑｜得物技术
-
线程池ThreadPoolExecutor源码深度解析｜得物技术
文 /宇贤
关注得物技术，每周更新技术干货
要是觉得文章对你有帮助的话，欢迎评论转发点赞～
未经得物技术许可严禁转载，否则依法追究法律责任。