在 AWS 上重构数据中台，这家出海企业选择了数栈

奄蜊 · 2025-6-23 19:48:36

2024年，袋鼠云接到了一个不小的挑战。
一家货币交易所的技术负责人在通话里直接说：“我们现在业务都跑在 AWS（亚马逊云平台）上了，你们的产品（数栈大数据平台）能不能不改代码直接跑在 AWS 上？最好别重学。能跑，还得跑得快。”
出海浪潮下，这样的需求并不稀奇。真正能在 AWS 上做到“稳定、高性能、权限闭环、体验一体化”的大数据产品，至今仍是少数。这要求中国的技术公司开始走入一个新战场——不能再是提供“给中国客户用的技术”，而是需要适配全球主流云厂商的底层逻辑，用一种全球通用的方式去可靠交付。
所以袋鼠云在全面开启出海战略之后，下定决心不仅要让数栈能跑在 AWS 上，还要在 AWS 上跑得好。
不是兼容AWS，而是重做一遍适配体系

对大多数国产数据平台来说，“适配 AWS”的第一步就是找兼容层：看看 EMR 支不支持 Spark、Flink 能不能访问 Hdfs，S3或者向Yarn提交任务，再配点访问策略，就认为大功告成了。
但会很快发现，这种兼容，是一种“不确定性”的存在。
比如：S3 是最终一致性，任务写完数据后，别的任务读不到；Flink 的 checkpoint 写 S3 时丢失元数据；Glue 的 Catalog 怎么都连不上 Hive 元数据；权限策略在多个服务之间不通……
客户想要的是“业务跑得起来”，但工程师面对的，是“生态全断裂”。
于是袋鼠云决定重新来过。不是兼容 AWS，而是跟它“合拍”：真正理解 AWS 的每一层能力——从存储->调度->元数据，从AK&SK->IAM Roles认证——并逐层打通。
这不是插件级适配，而是系统级改造。

数栈对接访问AWS-EMR的认证、调度、元数据访问链路图
打造一套“全球化的数据中台”

开头提到的货币交易所的客户最终成为了数栈的首批 AWS 适配合作用户。项目初期，他们面临的典型问题不止一个：

数据调度工具三天两头挂，没人知道任务跑没跑完；
计算引擎写入 S3 的数据总有一致性问题，结果算出来总感觉差一口气；
每个业务线的数据自己接、自己处理、自己维护，一套数据平台成了十几块孤岛。

在袋鼠云看来，这不是产品的问题，而是出海数据基础设施“整体系统性”的问题。
数栈在 AWS 上的适配目标，是搭建一套真正“全球可用”的数据中台能力。所以我们拆开了五个维度，逐一重构。
存储适配：不只是能读写 S3，而是要“写得稳、读得快、控得细”

S3 是 AWS 上的默认存储选项，但它有个常被忽略的特性——最终一致性。这意味着，你刚写进去的数据，不一定立刻能读到。对于流处理、调度依赖、实时写入的作业来说，这几乎是“隐形炸弹”。
客户之前用的是开源 Hadoop 的 S3AFileSystem 接入方式，读取慢、目录杂乱、偶发数据“看不见”。袋鼠云对接了 AWS 的原生优化版本 EmrFileSystem的方式，彻底解决了这个问题。

EmrFileSystem读写 HDFS配置
EMRFS 有三点关键优势：

支持强一致性视图（Consistent View），写完立马能读，Flink/Spark 流任务更稳定；
支持目录缓存与智能分段上传，大文件写入快、列表速度更快；
支持与 IAM 和 Lake Formation 联动的权限管控，让“读写谁的数据”不再靠脚本设权限。

计算整合：不只是跑得动 Spark/Flink，而是自动弹性、精细调度

客户的数据处理任务很杂，有周期性批量任务，有高频流式计算，还有一些重资源的查询任务。最早他们用开源集群，调度器负载高就卡死，恢复得靠“看运气”。
袋鼠云帮助他们把核心任务运行在 EMR on EC2 集群上，也就是 AWS 原生的弹性 Hadoop/Spark 平台。数栈的调度系统自动识别任务资源需求，提交给 EMR，系统会自动拉起集群、运行任务、再释放资源。

AWS EMR集群对接
对客户而言，效果非常直观：

计算资源弹性拉升，不用担心凌晨高峰资源不够；
作业失败自动重试+告警，运维压力大幅下降；
EMR 成本按分钟计费，资源利用率提升 40%+。

一句话总结就是：以前靠人盯着调度器跑，现在调度器自己知道怎么跑最合适。
元数据对接：用 Glue Catalog 做平台级数据资产管理器

元数据听起来抽象，但对于有几十上百个表、成千上万个字段的业务平台来说，“我有哪些表？结构是不是最新的？别的团队能不能也用？”这就是数据工程的真实日常。
数栈原本用自建 Hive Metastore 管理表结构，迁到 AWS EMR后，我们对接了 Glue Catalog，把所有表的结构、分区、存储路径、Schema 变更，统一托管到 Glue 里。

Glue Catalog数据源构建

Glue Catalog元数据构建
这带来两个立竿见影的好处：

不用再维护一个独立的元数据库，Glue 是 serverless 的，自动托管、高可用；
所有在 S3、Redshift、Athena 上的数据分析工具，都可以用 Glue 的元数据，真正实现数据资产“一处定义、处处可用”。

而且 Glue 自带自动 Schema 爬虫（Crawler），文件一落地，表结构自动生成，再也不需要工程师人肉注册。
权限控制：不是“能防”，而是“可管理、可审计、可精细分发”

数据权限在出海场景里从不是锦上添花，而是刚需，尤其是面向多团队、多角色甚至多租户的系统。

通过AK&SK的方式构建Glue Catalog
袋鼠云能够支持AK&SK和IAM的认证以及结合IAM Poclic+数据库自身权限管理实现资源+数据库级别的访问控制：

安全效果得到增强，IAM+数据库双重认证，凭证泄密也无法通过非法IP进行访问，能够实现最小权限的安全落地。
运维管理能力提升，统一的身份管理，基于IAM策略实现动态授权，通过aws审计报告自动生成来提神自动化水平。
业务合规效果增强，满足了监管需求，实现了多租户隔离防止跨租户泄密，审计日志的追踪链路完整。
成本优化效果明显，资源利用率提升，运维成本降低，安全事件损失减少。

这让客户在面对“谁能看交易金额、谁能查链上地址”这样的问题时，不用再靠信任——权限系统自己就能给出答案。
产品体验：界面没变，但能力变了

袋鼠云做了那么多 AWS 原生集成，对客户来说最直观的感受其实是：“体验没变。”
拖拽建模、任务调度、血缘分析、实时开发、资产管理……界面还是那个数栈，学习成本没有提升。但背后的一切都已经跑在 AWS 上，跑得更稳定、更弹性、更安全。

实时开发Catalog管理
客户说：“用你们的产品，我不用去理解 EMR 里 Spark 怎么配置，Glue Catalog 怎么建表，权限策略怎么穿透，这就够了。”
出海这件事，技术不能只是“能跑”

“能跑”，是底线；“能跑好”，才是出海平台的基本功。
数栈与 AWS 的联合适配，不是为了解决某一个技术问题，而是为了解决出海企业在 “高弹性 + 高安全 + 高治理要求”环境下构建统一数据中台的需求。
袋鼠云不想把国产技术硬搬过去，而是要在全球通用的云体系下，让真正想在海外落地的数据业务，有一块稳定、弹性、好用的“数字地基”。
这不是兼容，这是重构。这不是跑通，而是跑赢。
越来越多的中国企业正在走向全球，这也是数栈为什么要在 AWS 上，重做一遍中台的真正原因。袋鼠云相信，真正的出海能力，绝不是简单的“向外复制”，而是深度嵌入全球云生态、以业务为核心进行技术重构。未来，数栈还会继续拓展全球主流云平台的适配能力，为更多出海企业构建属于他们的全球数智基建。

来源：程序园用户自行投稿发布，如果侵权，请联系站长删除
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！

账号		自动登录	找回密码
密码			立即注册

在 AWS 上重构数据中台，这家出海企业选择了数栈

浏览过的版块

签约作者