# Amazon Athena + Iceberg：AI Agent 的数据底座实战 > **合规声明（生成式 AI 服务）**：前述特定亚马逊云科技生成式人工智能相关的服务目前在亚马逊云科技海外区域可用。亚马逊云科技中国区域相关云服务由西云数据和光环新网运营，具体信息以中国区域官网为准。 > > **完整资料：如果想了解更多内容可以访问:https://events.amazoncloud.cn/china-summit-on-demand/ > > **免责声明**：本摘要仅为便于您了解峰会内容而提供，我们不对其完整性及准确性作出任何保证，且不构成任何建议或结论。相关内容仅供参考，实际内容以峰会回放视频为准。 ## 一、基础信息 - **会议类型**：专题演讲 - **Persona**：数据团队 - **时间信息**：6月23日 | 14:30 - 15:00 - **标题**：Amazon Athena + Iceberg：AI Agent 的数据底座实战 - **PDF 资料**：无 - **视频回放**：有 ## 演讲人信息 ### 会议信息 - **地点**：上海世博中心（2026 亚马逊云科技中国峰会） - **日期**：2026年6月23日（Day 1） - **时间**：14:30 - 15:00 - **会议类型**：专题演讲 - **面向 Persona**：数据团队 ### 亚马逊云科技演讲人 - **周爱琳**：亚马逊云科技解决方案架构师 ### 客户 / 合作伙伴演讲人 - **张冶青**（惠普）：HP Nova 团队负责人 ## 二、会议资料 PDF 转录内容 （本场次无 PDF 资料） ## 三、会议回放视频转录内容 大家下午好 我叫周爱琳是亚马逊云科技的解决方案架构师 今天非常荣幸有这个机会和我支持的客户 Maven 来自惠普 Nova 团队的负责人 一起跟大家分享一下惠普公司如何利用亚马逊云科技的服务 在云上构建了一个数据架构的三次演进逻辑 接下来30分钟的 agenda 我们会分为三个部分 第一个部分会由我为大家花几分钟的时间 为大家介绍一下亚马逊云科技 在 AI 和数据方面的一个全栈的服务能力 然后第二部分会由 Maven Maven 会以惠普 Nova 团队负责人的角色 从他的角度毫无保留地跟大家复盘一下 HP Nova 这个团队三次数据架构演进 以及背后的决策逻辑 他们是从传统的一个 BI platform 先是做了迁移上云 接着就是基于亚马逊云科技的数据服务打造了统一的数据底座 来支撑不同的工作负载 最后现在是已经进展到 演进到了从统一的数据底座 到一个中心化的数据平台这样的一个历程 最后我会将这次架构演进 里面就是将这次架构演进做一个总结 并且映射到亚马逊云科技的服务能力 然后把其中的一些可复用的经验进行一个总结和分享 希望能给大家带来一些收获和启发 现在屏幕上大家看到的这张图 是亚马逊云科技在数据和 AI 上面的一个全栈的服务能力 底层是我们的数据和基础设施层 Data and Infrastructure 中间的 Data Foundation 亚马逊云科技我们有非常广泛的数据库和数据存储的服务 像刚刚上一个 session 我们也有讲到 比如说像 S3 Vectors 作为一个 Vector Store 右边的 AI Compute 我们除了英伟达的 GPU 我们也有自研的 Trainium、Inferentia 加速芯片 能够提供一个非常高性价比的推理和训练的能力 左边我们的 SageMaker 提供了云上的一个训练平台 然后在中间层就是关于我们 AI 和 Agent 的 Specific 的一些服务 那 Bedrock 提供了云上的一个所有的基础模型 就是 Foundation Model 的一个 API 的调用 统一的一个 API 的调用 AgentCore 可以方便企业在云上方便的快速的构建 Agentic 应用 那上层是我们的应用层 比如说像 Kiro、Q Developer 等等 那其实在我们现在这个时代上层 就是 AI 应用这层变化是非常的快的 但是无论上层的 AI 应用它是变化得多么的快 那么我们的底层其实都是依赖一个稳定高效 开放的这样的一个数据底座 那这个其实也是 Maven 接下来会带来的 惠普这个数据架构演进案例的分享的一个核心命题 就是如何利用云上的这些数据服务 结合 HP Nova 的实际情况 来进行这个数据架构的演进 那接下来我就把时间交给 Maven 由 Maven 来给大家进行更深入的一个项目的复盘 好的，感谢爱琳的一个开场 然后我呢是那个来自 HP 的 Nova Team 然后不是亚马逊的 Nova 而是我们 HP 内部的一个 Nova 的一个平台 然后我们团队主要是做什么呢 我们团队的话其实做两件事 当然我们最基础的这一个事的话 就是我们的 Nova 的这个平台 然后它是一个什么 它是一个 PC 的一个测试管理系统 也就是说我们传统的这些做测试的 都是用那些 Excel, Word 然后一些手工的方式做测试 我们 Nova 扮演的角色就是把这些东西都中心化了 然后汇聚了所有的这些在 ODM 生产 厂商的这些测试的数据 然后集中化的来管理 然后优化我们的测试 这样也会保证我们的 PC 交付出来的话 是一个比较质量比较高的这样的一个系统 当然有这么多的测试的数据的话 也就少不了数据 就是数据这些要做管理的话 我们必须把这些数据进行一些汇总 进行分析 然后所以说我们在几年前就已经开始在做 内部的数据治理平台 我们内部的团队也有 Data Engineer 然后也会来做这些事情 然后当时我们就是以 Power BI 为一个核心 然后当时做了这样的一个数据的底座 所谓的 然后我就说一下我们之前的一个东西 就是我们最早的话 都是 Nova 的整个系统 我们有好几套 大概有接近10套的系统 包括我们内部的数据中心 然后都是在 在 ODM 和我们内部的数据中心 分布式的一个管理 当然都是 On-premises 都不是在 Cloud 上面 所以说就维护起来 实际上是比较麻烦的一件事 而且部署也是很不稳定 然后还有问题就是 我们的这些执行数据也在 Nova 系统里面 然后也有这些比如说缺陷的追踪 然后还有我们产品的这些 组件这些的数据 都是在不同的内部的这些管理系统里面 还有就是我们数据处理的这些脚本 也是比较零散的 当时我们用的是 Power BI 的全家桶 Power BI 如果大家用过的话 可能会知道就是 Power BI 很方便 就展现这些做得不错 然后还有就是它的 它也提供了 Data Flow 这些 ETL 的这种拖拉拽式的 这种低代码的 这样的一些编排式的 ETL 工具 但有个问题就是 如果说我们想要把它里面的这些原始数据 都捞出来的话 其实是一个不是一个很简单的事 而且他们所用的 query 语言 也不是我们传统的 sql 大家说这些表哥表姐应该都对 sql 比较了解 但是如果涉及到 Power BI 那就是 DAX 这个是一个很冷门的一个语言 所以说这个后面也会提到 为什么会迁移 但是这个最后就是输出报表 但是静态的这种报表 或者动态的报表 就是人去看的 不是给 AI 看的 所以有三个结构性的痛点 第一个痛点就是运维孤岛 就是因为我们的数据都是 on-premises 的 都有好几套的系统 然后运维就非常的麻烦 需要我们登到每一个数据中心的服务器上 去进行运维 然后第二个就是 我们的数据在 Power BI 中 比较难以捞出来 然后第三个就是报表延迟 整个的链路还是比较长的 然后大概刷的话 差不多要大半天的时间 然后所以说为了解决这几个问题的话 我们主要分了两步 第一步就是我们的 Nova 从我们的本地的数据中心上云 然后我们采用了一个叫 Lift-and-Shift 的一个方式 当然也是亚马逊云科技团队给我们支的招 也就是说先把所有几套环境全部上云 然后上了云之后 我们再来慢慢地做一个整合 然后优化我们的代码 集中来管理我们的这些测试数据 然后第二步就是把我们的底座 现在的话就数据底座 就是我们的 ETL 的这一层 然后是用什么呢 是用 Glue 加 Athena 然后替换 Power BI 的这个数据底座 主要是包括它的 ETL 的那一层 而不是展现层 展现层它还是可以用的 下面会说 在这个转换的过程当中 亚马逊团队其实还是很给力的 当时我们预估出来 因为我们有上百个脚本 然后需要进行一个迁移 这个是一个人工来做的话 我们大概预估是要差不多一个季度的事 然后其实我们最终就花了一个月 为什么呢 因为现在有 AI 当时这个小伙伴 亚马逊的小伙伴就说 用 AI 来做也可以 然后最后我们找到了这个解决方法 就直接把一个季度的时间压缩到一个月 而且是完全整体上线 所以说这个成果也是非常惊人的 然后换了之后可以看到 以前的话我们主要是 Power BI 做一个数据底座 然后它下面是分散了离散的离线系统 也不是离线系统 就是分布式的一个系统 分布在不同的 on-premises 的系统 然后迁移之后的话 其实对于 Power BI 的展现层 是没有任何的变化的 它只是说从它的获取数据 连接到了我们的 基于 Athena 的这样的一个 数据仓库底座 然后有了这个数据底座的话 这个现代化的数据底座 然后我们还会产生出新的能力 也就是我们今天第二幕的主题 就是这个 也是我们内部的产品叫 Compass AI 然后对 就是现在我们所做的这个事 这个产品 可以看到这个一个数据底座 就是我们是用 S3 的 Iceberg 然后加 Athena 加这个 Data Catalog 组成了一个 比较大的一个 Data Warehouse 或者你也可以说是 Data Lake 这个反正大家理解 它就是一个基础 一个数据基础 传统的这个 BI 报表 还是不变的 你用任何的都可以 你用 Power BI 也可以 用其他的也可以 当然我们现在人工来看主要还是用 Power BI 这个完全没变 然后第二个就是我们的 ML 能力 这个 ML 能力的话 我们是需要原始数据的 当时也是 做这个事也是 因为我们要做 ML 能力 所以说要捞原始数据 我们当时做的决定就要迁移 但真正有用的是我们的 而且现在已经生根发芽的是我们的 Compass AI 也就是用现在大语言模型来驱动 Agent 做自然语言查询的一个 query 然后它也是 都是由数据底座来进行支持的 为什么当时选了 Athena 和 Iceberg 呢 其实当时爱琳他们团队给我们的建议 也是这个 当然还有其他的一些方案 我们最终选的这个为什么呢 第一个 成本可控 大家知道 Iceberg 它是底层是 Parquet 文件 存在 S3 上的 然后它的 S3 大家知道是成本是非常非常低 也是按量计费 就 Athena 它也是按量计费 就是你不会有一个常驻的一个 像 Redshift 或者 Postgres 这样的一个数据库 在跑在那每个月产生很多钱 这个是按量计费 你用的越多当然贵 但是用量越多会更贵一点 但是它的成本真的是非常低 然后第二个的话是大语言模型友好 就是我们为什么 之前 Power BI 不能直接用 Agent 去 query 呢 因为 DAX 是一个很冷门的一个查询语言 它像 SQL 但是它又不是 SQL 所以说当时做的时候就会出现幻觉 然后我们做的一件事就是 如果把它迁移到 Athena 之后 Athena 是天然原生支持 SQL 的 SQL 的语料非常充足 在市面上已经基本上所有的大语言模型都能支持 SQL 所以说从 我们的自然语言到 SQL 的话是非常准确的 而且幻觉率的概率非常小 然后还有就是 Athena 的集成能力 就是比如说像现在我们是用 Iceberg 加 SQL 查询 这样的查询的话有可能就相对于有些场景下会相对来说慢一点 因为它有一些额外的开销 它是查磁盘 然后如果我们要做到 比如像做到亚秒级的这些响应 我们还可以用 Athena 去进行一个切换 所以 Athena 作为一个 adapter 就前置的一个 adapter 是一个非常合理的选择 然后我们看一下就是我们的整个的 ETL 以及我们最终上到我们的 Compass Chat UI 的一个查询 主要是分两条路 可以看到上面的蓝色的 是我们的 offline 的 ETL 的流程 它是一个非常传统的 ETL 流程 传统 但是有效 就是我们有很多的依赖数据源 Nova 我们的系统 然后我们有缺陷追踪 SAT Impact 以及我们的元数据 PASA 还有其他很多系统 因为 HP 还是很大的一个组织 有非常多自己维护的这些系统 然后我们通过亚马逊云科技的 Glue 然后做一个抽取 一个 extract 直接进仓到我们的 ODS 层 Operational Data Store 然后也是存成这个 Iceberg 然后它是个进仓的一个数据 然后再用 Athena 借助线程池的 CPU 的方式进行一个 transform 然后到我们最终的这个数据仓库 就是 Data Warehouse 然后下面的红色的 就是一个 应该大家都很熟悉了 就是 UI 到 Agent 大语言模型驱动 然后用工具调用 工具调用最后生成 Query 执行 Athena 执行最后获取数据 那个 这里先说一下就是 ODS 到 DWD 的这个东西 这个可能没有做过 那个数仓的或者 BI 的小朋友 可能不是太熟悉 但是对于大规模的这种数据 就以前所谓的 Big Data 其实我们 Athena 它也是用了宽表的一个形式 因为是列式存储 所以说 但是即使是列式存储 我们也需要对它进行一个聚合 就是预聚合成 也就是 DWD 和 DWS 的一个区别 然后大概是这样的一个架构 但是它里面的驱动 主要都是通过 Athena 来做转换和 这个做聚合的 然后这里刚才那一点 其实提到有一个叫所谓的 Athena Adapter 其实说白了 它就是一个工具 就是说 为什么我们把它组成一个工具 一个 JSON schema 而不是让它直接手写代码呢 因为 因为这个 第一个考量就是 它的直接写代码成本比较高 token 占用比较大 就一段代码下去 你可以看到一些 Subquery 一些 Join 然后它要花蛮长的时间 对吧 如果说我们把它 内置成一些 Preset Defined 的一些 tool 的话 像 JSON schema 它会节省大概50% 以上的 token 然后还有就是 Raw SQL 还有一个更大的一个问题 就是它的安全性 就是你其实没办法 完全来规避它的 SQL 的执行 Agent 如果出个幻觉 你的数据库可能就泄露数据 或者是 做一些破坏性的操作 所以说我们 有一个 Athena adapter 的这样的一个 封装成一个工具的这样一个东西 然后这个是 Compass AI 的一个 自然语言查询的一个 一个 示意的一个流程 然后比如说我们 有用户用自然语言提问说 过去30天 EliteBook 有多少 P1 级缺陷 EliteBook 是我们的一个产品系列 然后 P1 就是 Priority 1 也就是一个很高等级 优先要处理等级的一个缺陷 有多少个 然后 那个 Agent 就是通过 它不直接拼接代码 它是直接 先查询 DWS 的表结构 然后再通过我们内部 内置的这些领域的 skill 然后来理解 P1 缺陷 以及产品线对应的判断 然后再去生成 JSON schema 里面的这些参数 然后来调用 然后这样就得到结果 就是它会 我们的 Adapter 会组装成 这样的一个 Raw SQL 这个 SQL 其实我们校验过的 就是如果不合法的东西 它是不会生成 会报错的 然后这个 SQL 会最终被 Athena 执行 执行了之后 然后返回缺陷 好 这个是一个真实的界面的 一个实录 然后 界面长这样 可能有点不清楚 但是大概意思就是在右上角 这个蓝色的地方 写的是 What is the pass rate across executions this week 比如说在这本周 这个测试执行的通过率是多少 然后下面这个绿色圈圈的 这个可以下拉展开的 这个是我们后面要提的 这个 sub-agent session 里面做了一些事 可能几十秒钟 上几分钟 然后就出了结果 最后捞出来这个数据 做一些总结 下面还有图表 然后这里是一个总结 就是可以看到 很快就可以出一个结果 97% 的通过率 然后我们执行到7万次这种执行 然后上下文的控制 这个其实不是今天的重点 但是之前都已经 刚才的那个 吕老师和李总都已经讲过了 就是通过一些手段 但是我们用的手段 简单但是有效 就是长上下文 就是我们的长上下文要怎么样支撑呢 我们做了一个 就是把那些 因为数据 heavy 的 就 data heavy 的这些 tool call 的话 它会产生大量的这些 result 如果把这些加到 session 里面的这些 context 里面的话 会撑满我们的上下文 所以说我们把这些 脏活累活都交给 sub-agent 去做 它可以查询数据 分析 然后生成报告 最终只把分析后的结果 返回给主 agent 然后让主 agent 来合成 这个组织文本 给用户 当然还有其他的一些 这种 technique 然后比如说 in-session compaction cross session memory 这些都是 现在都很流行的 这些技术我们未来也会再规划 好 然后说了前面的这些技术性 我们说一下方法论 就是我们做的这个方法论 其实应该也算是一个渐进式 就是不要一上来 就造火箭 然后就升空发射爆炸的 这样一个东西 就是我们先上云 上云之后 我们不要改任何的代码逻辑 也不是不要改很基础的代码逻辑 就是做到风险可控 风险完全 就是直接上云之后 还按照以前的逻辑来跑 叫原样搬上云 Lift-and-Shift 然后最后统一成一个集群 最后的 第二个的话就是我们先优化 再按负载迭代 就是这个意思 就是我们先把以前的这些 Power BI 里面的 ETL 的工作流 然后先让 AI 过一遍 过一遍之后直接扔上去 然后看输入输出 是不是跟之前一样 然后后面再来 优化 再来慢慢的优化里面的东西 但是也不是慢慢 这个要说的第三个 就是全程代码化 就是我们的 ETL 工作流 其实现在我们是做了一个 IaC 的一个就 Infrastructure as Code 架构即代码 基础设施即代码的这样的一个 一个实践 就是我们以前的 ETL 都是 如果是 Glue 的话 大家知道 就是你需要在那个 界面里面 然后直接点开 然后写一些小型的代码 但是 IaC 的话 就全程代码都在 GitHub 里面 然后我们如果说 这样做的一个非常大的好处 就是所有这些基础架构 都是由 AI 都可以借助 Agent 来辅助完成 就是我们现在的话 如果要新增一个数据源 刚才说到有三个我们主流的数据源 如果再加第四个 也是很简单的一个事 然后就直接通过这个 IaC 的方式 然后亚马逊云科技也提供了 这个 CDK 的这些东西 来协助快速的来部署 来迁移 所以说 就是这个也是刚才说过了 这个就是 以前我们是手工在做 然后就是用锤子 用螺丝刀 然后手工来做 现在就是让 AI 用 用螺丝刀 用锤子去做 然后我们就指挥一个 就像包工头一样 指挥这些 agents 去干活就行了 然后小结一下就是 我们最开始就是由一个底座 到承接负载 就是一个数据底座 到我们的 BI 到 Machine Learning 到 AI Agent 然后我们的选型的话 也是有成本可控 大语言模型友好 集成好 这个也是 Athena 加 Iceberg 这套逻辑的 一个比较重要的一些 一些优点 然后就是我们的 Athena adapter 以及我们可以用自然语言 当然了 最后是我们提到 IaC 的这个方式 可以让我们的 ETL 工程化 好 当然第三步就是 我们现在正在做的一件事 就是因为我们的 Compass AI 的数据底座 其实是一个相对来说 比较可以迁移到 其他团队 或其他产品的这样一个逻辑 主要痛点是我们 HP 其实内部的产品很多 包括 AI 产品 然后大家都想在 AI 上做一些事情 Compass AI 是一个我们在做的 然后其他的也有 所以说一个比较难的一点 就是很多团队 如果自己在做的话 就会出现这个 n×m的这样一个 o n 的 o n2 的一个复杂度 这个就是一个比较痛苦的一个事 就是每个都要重新造轮子 如果说我们现在把 Compass AI 的 这个数据底座做成一个单一的共享层 就是我们 Compass AI 的这个数据底座 不管它有什么名字 它最终就汇聚所有的这些数据源 然后最终所有的这些 AI 的 app 然后都来连这个 share 的共享数据层 这样就会事半功倍 而且还有其他的好处 然后第一个消除重复 就是我们因为都是一套数据源 都是一个数据流程 就所有的数据的管道就不用再重复造轮子了 第二个就数据质量 就所有的这些口径 这些数据统计口径都是有单一的团队来维护的 所以说任何的这些背后输出的这些数据的 这些口径的话都是一致的 然后第三个就是 我们用的这些工具的话会越来越快 我们自己的共享层也会迭代得越来越快 越来越优化 但是也不是说这样做就完全是一个完美的一个解决方案 我们刚才说了这些 我们的刚才这种方案的一个利 但是它也有弊 就是第一个 因为我们是用离线的这种方式在做 所以说它即使能做到分钟级 它也不是完全实时的 当然我也知道现在有很多方案做实时 只是我们还没去做而已 这个价格是肯定没问题的 然后第二个就是管线的维护成本 就是我们的共享层的话 其实还是需要专门的团队来维护 或者可能是我们团队 也可能是新的 Headcount 然后这些都是实打实的成本 但是我们最终权衡了一下 它的利是远远大于弊的 这边就是一个总结 就是这个 Compass 我们的项目的话 是我们的数据底座的第一个基石 我们也希望这个底座能够在未来的话 成为我们整个 HP 内部我们组织 或者甚至整个公司的一个实践 实践的一个 example 然后我这边的部分就结束了 然后就交给爱琳 好的 感谢 Maven 刚才非常精彩 并且非常详细的一个分享 怎么跳到这里了 对 对 那最后一点几分钟的时间 想跟大家做一个总结 如果我们刚才把 Maven 讲到的 123 幕统一 来看一下的话 第一幕其实我们聚焦的是一个迁移 把 On-premises 的 并且是一个分散的 ODM 上面的系统 统一迁移到云上的一个统一的架构 那在架构层 这个是相当于是传统的 这种三层架构比较常见的 第二幕是在云上结合亚马逊云科技的数据的能力 打造一个统一的数据底座 那核心的是基于 S3 的数据湖 那其他的数据服务 包括 Glue 包括 Athena 等等 这样能支持了咱们惠普 Compass AI 的这样的一个项目 那第三幕已经是从 既然我们已经有了一个统一的数据底座 那我们其实是想把这个从底座 把它演进成一个中心化的数据的平台 那大家可以看到这个架构 除了刚刚提到的 S3 Glue Athena 等等 Maven 他们团队也是大量的采用了 基础设施即代码 这是 Infrastructure as Code 的技术 然后结合 Step Functions 做了大量的编排 这样能让他们整体的运维 以及包括对接新的数据的流程 会更加顺畅以及高效 好 那我们总结了几条 想跟大家分享的经验 第一就是其实在现在的这个 AI Agent 的时代 我们说上层的这些应用 变化得非常非常的快 我们要支持的 Workload 非常的多 那其实如果我们就是 从这个第一性原理来看的话 其实我们下面的一个数据底座 才是我们的一个 Foundation 是我们的基础 所以投资下面的数据底座 可以说是投资未来所有的 AI 能力的一个地基 那第二点 大家可以看到我们其实惠普团队 他们采用的是一个先落地 再优化的思路 什么意思呢 就是并不是追求最开始要大量的开发 一步到位 而是说我们哪怕是先采用 Lift-and-Shift 的方式 先把这个 先把它做一个云上的迁移 然后再根据自己实际的负载 进行一个 在云上进行一个迭代 那最后一点呢 这个比较细节 就是 SQL 能力的工具化 就像刚刚 Maven 跟大家分享的 他们打造了一个叫 Athena Adapter 的工具接口 把对 Athena 的查询能力 封装成了 Agent 可以调用的一个工具接口 这样我们的 Agent 其实就不用自己来写 SQL 也不需要感知这种存储的细节 而只需要调用类似于像 Athena Adapter 这样的工具 即可完成查数据的一个过程 好 上面就是我们为大家总结了这个惠普 NOVA 的这个案例 然后后面应该是有一个 对有一个那个 请大家可以扫描上面的二维码给我们一个 一个反馈 对 谢谢