导读

对同时服务多品牌、多渠道的电商平台来说，数据平台的瓶颈往往不在某一张报表，而在不断叠加的系统和越来越长的数据链路。

Synagie就曾面临这样的难题。作为东南亚领先的电商服务企业之一，Synagie为600多个全球零售品牌提供数字化转型、渠道管理、供应链、品牌增长和数据分析服务。品牌需要随时掌握商品销售、库存变化和营销表现，Synagie的数据平台则要同时承载离线计算、在线分析、BI报表和多品牌自助分析。

原有架构由多个AnalyticDB实例与Power BI等产品组合而成。业务早期，这套架构能够满足需求；但随着品牌、渠道和数据量持续增长，多套引擎之间的数据同步、重复落盘和跨系统开发逐渐成为瓶颈。数据最快只能做到T+1，工程团队还要投入大量精力维护多套技术栈。

引入云器Lakehouse后，Synagie以Single-Engine架构统一实时与离线计算，并在云器Lakehouse中完成数据接入、开发管理、BI分析和自助分析。按内部材料口径，平台架构由4套组合简化为1个平台；数据时效从T+1提升至5分钟，数据管道开发效率提升50%，实时BI分析响应约2秒，运维成本降低70%，整体计算与平台成本降低30%。

Synagie的实践说明，数据、计算和分析链路收敛到一套平台后，时效、开发效率和成本可以同步改善。

现状与痛点

业务背景：600多个品牌背后的数据分析需求

Synagie成立于2014年，面向东南亚市场为全球零售品牌提供端到端的电商运营服务，帮助企业实现线上与线下销售的衔接。其业务覆盖数字化转型、渠道运营、供应链管理、品牌增长和数据分析，帮助品牌在区域内的主流电商平台和社交平台上保持一致的消费体验。

对Synagie来说，数据分析本身就是服务的一部分。

品牌每天都在通过Synagie回答具体的经营问题：哪些商品正在热销？哪些市场或渠道的库存即将不足？一次营销活动带来了多少销售转化？同一商品在不同平台上的表现有何差异？这些问题横跨销售、库存、营销和运营等多个环节，而且越接近实时，越能帮助品牌及时调整策略。

随着合作品牌增加到600多个，分析平台的使用者从内部团队扩展到品牌客户。平台需要处理多渠道持续汇入的数据，也要让不同团队基于同一套数据和指标开展分析。

原有架构：多套产品拼接出一条分析链路

为了同时满足离线计算、在线分析和BI报表需求，Synagie原有平台采用了多产品组合架构：订单管理系统（OMS）、PolarDB/MySQL等业务数据源，经由DtStudio与DTS完成开发和同步，再进入多个AnalyticDB实例，最后通过Workbench、DataV和Power BI等工具向内部团队与品牌用户提供查询、报表和可视化分析。

原有数据链路可以概括为：

OMS、PolarDB/MySQL等数据源 → DtStudio/DTS同步与开发 → 多个AnalyticDB实例 → Workbench、DataV、Power BI分析与展示

图1：Synagie升级前的数据架构。

这套架构让不同产品各司其职，但品牌数量、数据量和业务场景增长后，系统接口、数据复制和运维边界也随之增加。一条业务数据从产生到进入报表，要经过多个产品和多次落盘，任何一环延迟都会影响最终结果。

核心问题：四个瓶颈逐渐显现

随着业务规模扩大，Synagie逐渐遇到四个相互关联的问题。

问题一：产品与引擎过多，工程和运维精力被系统消耗。

离线计算、在线分析和BI报表分别依赖不同产品，多套AnalyticDB实例也需要独立维护。数据开发人员需要在不同工具和技术栈之间切换，运维团队则要持续保障各段同步链路和多个分析实例稳定运行。平台规模越大，需要关注的组件、任务和故障边界就越多。

问题二：用在线分析引擎承担大规模离线计算，性能与成本难以兼顾。

原有在线分析引擎对大规模批处理并不擅长。离线任务增长后，批处理性能、在线查询体验和资源成本很难同时得到保障，平台只能继续增加实例或产品，架构也随之变得更加复杂。

问题三：同步链路长、数据反复落盘，数据时效停留在T+1。

多产品架构下，数据需要在系统之间不断流转。每增加一次同步、转换和落盘，就多一段等待时间和失败风险，Synagie的数据最快只能在次日完成更新。

对零售业务来说，T+1会直接影响决策节奏。库存短缺、商品热销和营销反馈都有时间窗口，今天发生的变化如果明天才能看到，库存、渠道和推广策略就很难当天调整。

问题四：跨技术栈开发，数据需求响应速度跟不上业务变化。

Synagie服务数百个品牌和多个销售渠道，不同品牌的指标、活动和运营方式都在不断变化。一个新的分析需求往往需要跨越数据同步、离线加工、在线分析和BI展示多个环节。开发人员不仅要完成业务逻辑，还要处理不同系统之间的衔接和维护，数据管道迭代效率因此受到限制。

四个问题最终都落在同一条链路上：

• 为了覆盖不同计算负载，平台不断叠加产品和引擎；

• 多套系统又带来数据复制、重复落盘和多套开发运维方式；

• 链路越长，数据越慢，成本和故障边界也越难控制。

单独更换同步工具、增加分析实例或优化任务，只能缓解局部压力。Synagie需要调整的是多引擎并行、多产品拼接的整体架构。

升级选型逻辑

需求清单：既解决当前问题，也为业务增长留出空间

在规划下一代数据平台时，Synagie要先解决时效、成本和运维瓶颈，同时为品牌增长、业务峰谷和未来Data + AI场景留出空间。

团队明确了新平台的关键需求：

关键能力	具体要求	业务意义
统一计算架构	一套引擎同时承担离线计算与在线BI分析	减少多产品组合和跨引擎数据同步
实时与离线统一	将数据时效从T+1提升到分钟级	支撑库存、销售、营销和运营的快速决策
统一BI与自助分析	内部团队与品牌客户基于同一套数据和指标工作	降低口径不一致和重复报表建设
性能与成本平衡	在提升查询和计算性能的同时降低总体成本	让平台随数据量增长持续扩展
弹性扩缩容	能够应对零售业务明显的峰谷变化	高峰保障性能，低谷及时释放资源
面向未来演进	支持进一步扩展数据智能和AI应用	让已有数据资产继续服务新的业务场景

Synagie评估了包括完全基于开源组件自建、采用多引擎组合在内的多种方案。自建方案能够提供较高灵活性，但也意味着团队需要自行完成组件集成、性能调优和长期运维；多引擎方案能够分别处理不同负载，却难以从根本上消除数据复制、系统割裂和多套运维的问题。

选型结论

Synagie评估云器Lakehouse时，重点考察平台能否用一套架构回应这些需求。Single-Engine统一离线计算与在线分析，减少多引擎之间的数据同步；统一的数据开发和分析入口，减少跨技术栈协作；弹性扩缩容让资源随零售业务的峰谷变化，也为Data + AI场景预留空间。

云器Lakehouse将数据、计算、开发和分析能力放在同一套平台上，解决当前的数据时效、开发和运维问题，也为后续扩展留下空间。

方案落地：云器方案如何承载数据全链路

基于云器Lakehouse，Synagie将原有由多个AnalyticDB实例、开发同步工具和独立BI产品组成的架构，升级为云器方案的一体化数据平台。在云器Lakehouse内，不仅可以实现统一存储与计算，还能完成数据开发与任务管理、BI与自助分析等工作。

新的数据链路可以概括为：

批量与实时数据接入 → 云器Lakehouse统一存储与计算 → 统一开发与任务管理 → 统一BI与自助分析

图2:Synagie升级后架构图

对比维度	升级前	升级后
计算架构	多个AnalyticDB实例分别承载不同负载	Single-Engine统一离线计算与在线分析
数据链路	多段同步、转换和重复落盘	实时与离线数据统一处理
数据开发	跨DtStudio、DTS及多套分析实例协同	统一开发入口和任务管理
BI分析	Workbench、DataV、Power BI等多工具组合	统一BI与自助分析入口
资源管理	随业务增长持续扩展实例和产品组合	根据实际负载自动扩缩容
运维模式	多产品、多技术栈分别维护	一套平台、一套技术栈统一管理

云器方案从统一数据与计算、数据开发、BI分析和资源管理四个方面承载Synagie的数据全链路。

1. 统一数据与计算

云器Lakehouse是新平台的统一数据与计算底座。原来分散在多个分析实例中的实时和离线数据，能够在云器Lakehouse中完成接入、加工和查询。

原有组合式架构中，同一份数据需要在多个系统之间反复同步，以适配不同引擎。升级后，批处理、在线分析和BI基于同一份数据运行，处理路径缩短，平台也更容易保持一致和稳定。

销售、库存、营销和运营分析因此能够看到更接近实时的数据，工程团队也少了多个相互依赖的分析实例需要维护。

2. 统一开发与任务管理

云器方案提供统一的数据开发与任务管理环境。数据团队可以在同一套技术栈中完成管道开发、任务运行和日常管理，减少不同工具之间的来回切换。

开发入口统一后，一个新需求只需在同一套技术栈中完成，不必为每个环节维护不同的工程流程。团队可以把更多时间放在指标逻辑、数据质量和业务交付上。

对持续服务数百个品牌和多个渠道的团队来说，开发链路缩短后，新增品牌和分析需求的交付成本也会下降。

3. 统一BI与自助分析

云器方案提供统一的BI与自助分析入口。内部运营人员与品牌客户直接基于Lakehouse中的数据进行查询和分析，减少独立BI工具与不同数据副本之间的同步。

统一分析入口让日常看板和交互式查询更加流畅，也让不同用户基于同一数据源和指标体系工作，减少口径分散带来的沟通与校验成本。

对Synagie这样的平台型企业来说，这一点尤其重要。它交付的是一套供600多个品牌持续使用的数据服务，结果是否一致、及时，直接影响客户体验和运营效率。

4. 自动扩缩容：让资源规模跟着业务负载变化

在统一平台上，计算资源可以根据实际负载自动伸缩。销售旺季或营销活动期间，平台扩展资源保障数据处理与查询；需求回落后，资源随之释放。

弹性扩缩容减少高峰资源常态化带来的浪费，Single-Engine减少多套引擎的重复占用。两项能力结合后，平台在业务持续增长的同时，仍能保持可控的成本空间。

实际收益

方案上线后，Synagie的平台架构、数据时效、开发效率、查询体验和成本指标均得到改善。

1. 架构简化：从4套组合收敛到1个平台

Synagie内部材料将升级前后的架构变化概括为“4→1”：原来需要多个产品组合协同完成数据接入、离线计算、在线分析和BI交付，升级后由云器Lakehouse一体化平台承载。架构收敛减少了系统之间的接口、同步关系和故障边界，也让后续的开发与运维围绕同一套平台展开。

2. 数据时效：从T+1提升至5分钟

原有多段同步链路收敛为统一的数据处理路径后，整体数据新鲜度从T+1提升至5分钟。品牌当天就能看到经营变化，库存、销售、营销和运营分析也有了更及时的数据支撑。

数据从复盘前一天的经营情况，变成支持当天调整库存、渠道和推广策略的依据。

3. 开发效率：数据管道开发提速50%

统一技术栈与开发入口减少了跨系统开发、联调和维护工作，数据管道开发效率提升50%。面对品牌、渠道和活动不断变化的需求，团队能够更快完成数据接入、指标加工和分析交付。

4. 查询体验：实时BI分析响应约2秒

统一BI与自助分析能力直接基于数据底座提供分析服务，实时BI分析响应约2秒。内部团队和品牌用户可以更顺畅地浏览看板、进行交互式分析。

5. 运维成本：降低70%

从多产品组合转向统一平台后，需要维护的分析实例、同步关系和技术栈显著减少。工程团队无需再为多套系统分别处理运行监控、任务衔接和故障排查，运维成本降低70%。

6. 计算与平台成本：整体降低30%

Single-Engine减少了多套引擎的重复建设和资源占用，自动扩缩容则让资源规模与真实负载匹配。综合作用下，Synagie整体计算与平台成本降低30%。

7. 业务价值：为600多个品牌提供统一实时、个性化分析

新的数据平台让Synagie能够从同一数据源向600多个零售品牌提供统一、接近实时的分析服务。基于BI一体化与自助分析能力，品牌可以围绕销售、库存、营销和运营开展更细粒度、更具个性化的分析，Synagie也能够以更稳定的架构支持品牌和渠道继续增长。

总结与展望：从统一分析走向Data + AI

Synagie把多套分析系统收敛到统一的数据平台后，离线计算、在线分析、数据开发和BI交付使用同一套数据与计算底座。数据链路缩短，平台运维和资源管理也随之简化。

完成数据底座统一后，Synagie计划在同一平台上继续探索Data + AI场景。下一步方向是DataGPT对话式分析：业务用户用自然语言提出问题，系统生成查询、图表和分析结果，让自助分析从“会使用BI工具”变成“能够提出业务问题”。

对话式分析要进入业务，模型需要访问及时、一致且经过治理的数据。Synagie已经建设的统一数据与指标体系，有助于保持结果一致、可解释，并为智能运营分析、预测和AI辅助决策提供基础。

对于同样使用多套分析引擎、长期维护复杂同步链路的企业，Synagie的实践提供了一条路径：先收敛数据架构，再扩展业务场景，时效、效率和成本才有机会一起改善。

---

🎁 新用户专享福利

✅  1 TB 存储 · 1 CRU时/天计算 · 1 年全托管体验

➤ 即刻访问云器官网领取：https://www.yunqi.tech/product/one-year-package