Lakehouse 架构
分区 Amazon S3 存储桶（raw、curated、semantic），Athena 或 Redshift Spectrum 上的 Iceberg，medallion 或领域驱动布局，AWS Glue 中的目录与血缘。
- S3
- Redshift
- Lake Formation
- Glue
数据与 AI · 企业数据平台
让 SAP 数据干净落地的 Lakehouse。
AWS 上的 Lakehouse，以 SAP Datasphere 和 BW 为受治理的数据源，由最懂您 SAP 数据的团队构建。
Phoenix 以 SAP 数据工程师第一、云工程师第二的身份交付企业数据平台建设。Lakehouse 位于 AWS 上（Amazon S3、Redshift、Lake Formation、Glue 和 Athena），由 SAP Datasphere 和 BW 提供受治理的数据源。
两点让这不同于普通的数据平台建设：13 年以上的 SAP 数据血缘经验，以及将房地产存储占用削减 70%+ 且丝毫不影响应用访问的厚重归档与迁移记录。
服务范围。
SAP 源集成
以 SAP Datasphere 和 BW 为受治理的数据源，并在合适时直接抽取 S/4HANA CDS：ODP、Datasphere 复制流和 CDC 管道。
- Datasphere
- BW
- S/4HANA CDS
数据迁移与归档
历史 SAP 数据迁移到 Amazon S3 分层存储，热数据保留在 HANA。用户看到的应用不变；TCO 下降，生命周期延长。
- SAP ILM
- S3 Glacier
- 70%+ cuts
治理与访问
Lake Formation 细粒度访问、列级脱敏、PII 遮蔽，以及业务用户真正能查询的数据目录界面。
- Lake Formation
- RBAC
- PII masking
交付方法。
-
01
评估
架构扫描、数据源盘点、用例候选清单、目标 Lakehouse 架构。
-
02
落地
Bronze 层上线：SAP 与非 SAP 数据源带着血缘和质量检查进入 S3。
-
03
建模
Silver + Gold 层、目录和语义模型发布，供 BI 和下游 ML 使用。
-
04
运营
以 AMS 模式持续运行：管道监控、治理执行、成本合理配置。
明确的交付物。
每个项目都交付具体的成果物，而非一堆幻灯片。
- 针对您的 SAP + 非 SAP 数据源组合调校的参考架构与运行手册
- Amazon S3 上含 bronze / silver / gold 分区的运行中 Lakehouse
- 端到端测试过的 SAP Datasphere + BW 集成模式
- 带血缘的数据目录：AWS Glue + Lake Formation
- 查询时强制执行的 PII 脱敏和基于角色的访问策略
- 可选：含 S3 分层和目标存储占用削减的归档计划
常见问题
我们的 Lakehouse 必须运行在 AWS 上吗？
AWS 是 Phoenix 优化的平台：S3 作为存储底座，Redshift 或 Athena 作为计算，Glue 和 Lake Formation 负责目录与治理。当客户标准要求时我们也能在其他云上交付，但参考架构和加速器是 AWS 原生的。
能用 SAP Datasphere 和 BW 作为数据源，而不是推倒重来吗？
可以，这正是推荐模式。Datasphere 和 BW 继续作为受治理的 SAP 数据源；Phoenix 通过复制流、CDC 或基于 ODP 的抽取器将它们接入 Lakehouse。不强制淘汰仍在正常工作的系统；Lakehouse 成为围绕它们的分析底座。
你们提到 70%+ 的存储占用削减，如何做到？
SAP 归档项目：将历史数据从 HANA / 应用存储迁移到 Amazon S3 分层存储（S3、S3 Glacier Instant Retrieval、S3 Glacier）。通过 read-through 保留应用体验，热数据保留在 HANA。这是房地产本地部署系统的真实客户成果。
所有数据进入 Lakehouse 后，访问如何控制？
Lake Formation 提供行列级细粒度访问，PII 列级脱敏，以及与您现有 IAM 设置对齐的基于角色的访问。业务用户在相同权限下查询目录界面。
典型建设周期多长？
第一个 bronze 区（带血缘的原始摄取）通常在 6 到 10 周内落地。随后 silver + gold + 目录按用例分波次推进。归档项目是独立工作流，周期因系统规模而异。
