标签 亚马逊 下的文章

本文首发于 Aloudata 官方技术博客：《跨境电商 ROI 统筹难？NoETL 统一语义层破解亚马逊、Shopify 与广告数据孤岛》转载请注明出处。

摘要：跨境电商企业普遍面临亚马逊、Shopify、广告平台等多源数据孤岛问题，导致跨平台 ROI 计算不准、决策滞后。本文深入探讨传统ETL与物理宽表模式的局限性，并介绍如何通过 NoETL 指标平台构建统一语义层，实现业务逻辑与物理存储的解耦，从而自动化整合数据、保障指标口径一致，并实现秒级分析响应，为数据工程与敏捷分析提供新范式。

跨境电商的 ROI 统筹困境：三大痛点表现

跨境电商的日常运营是典型的多平台、高频次、强时效的“敏态”业务。企业普遍在亚马逊、Shopify/独立站、Google/Facebook/TikTok 广告平台等多条战线同时作战。然而，这种业务模式天然带来了数据割裂的顽疾，导致核心的 ROI（投资回报率）计算与统筹陷入困境。

  1. 数据割裂，全局洞察缺失

    • 平台壁垒：亚马逊的 A9 算法数据、Shopify 的店铺运营数据、各广告平台的投放与转化数据，分散在不同系统中。这些平台的 API 接口标准不一、数据格式各异，形成天然的技术壁垒。
    • 业务盲区：企业无法准确计算“全渠道 ROI”。例如，无法将 Facebook 广告的点击成本与最终在亚马逊产生的订单收入精准关联，导致营销预算分配如同“盲人摸象”，错失销售机会或造成资源浪费。

  2. 响应迟缓，错失市场时机

    • 冗长链路：传统模式下，从业务提出一个跨平台的 ROI 分析需求（如“对比 TikTok 和 Google Ads 对某新品在北美的引流效果”），到数据工程师排期、开发 ETL 脚本、物理打宽、测试上线，周期往往以“周”为单位。
    • 决策滞后：面对直播带货、节日大促等产生的“脉冲式”销售数据（可占订单总量 23% 以上），传统架构无法实现分钟级的策略调整，库存积压与断货风险并存，直接侵蚀利润。

  3. 口径混乱，信任危机凸显

    • 分散定义：为快速响应临时需求，不同分析师在不同 BI 工具或报表中自行定义“净利润”、“广告ROI”等指标，计算逻辑存在微小差异。
    • 报表打架：管理层常发现销售报表与财务报表中的同一核心指标数据对不上，IT 需要耗费大量时间排查口径差异。业务部门陷入“数据不好找、找了不敢用”的窘境，严重阻碍数据驱动文化的形成。

根因分析：传统“宽表模式”在敏态业务下的必然失效

上述痛点并非偶然，而是传统数据架构与跨境电商业务本质矛盾激化的必然结果。这一矛盾集中体现为 “数据分析的不可能三角”：业务追求极致灵活的分析，管理层要求绝对统一的口径，而工程团队需要在有限成本下保障查询性能。为了平衡，企业不得不依赖“人工预计算”的宽表模式，但这在敏态业务下已走向终结。

  1. 人工预计算的数学极限：试图通过预建物理宽表来应对 AI 智能体（Agent）或业务人员提出的发散性、非预设的分析需求（如“对比北美和欧洲市场，TikTok 与 Facebook 广告对 A 品类新客的 ROI 贡献”），物理表的数量将随维度组合呈指数级爆炸。这在工程和维护上是不可持续的穷举法。
  2. 逻辑与物理的紧耦合之殇：业务语义（如“有效订单”）被硬编码在 ETL 脚本和固化的物理宽表（DWS/ADS）中。任何业务口径的微调，都需要底层数据链路的重新开发、数据回刷和任务调度，变更成本高昂，且极易在多个宽表间产生不一致，形成沉重的“技术债务”。
  3. 人才与成本的双重压力：专业数据人才缺口巨大，而数据团队大量精力消耗在重复的宽表开发与运维中。同时，冗余的宽表加工导致企业湖仓数据平均冗余 5 倍以上，造成巨大的存储与计算资源浪费。

新范式解法：NoETL 统一语义层如何重构数据供应链

要根治数据孤岛，必须从架构层面进行范式重构。NoETL 语义编织的核心在于 将业务逻辑（逻辑定义）与物理存储和计算（物理执行）彻底解耦，在企业明细数据层（DWD）之上，构建一个统一、中立、智能的语义层。

对比维度传统宽表模式NoETL 语义编织模式
核心架构ODS -> DWD -> DWS/ADS（物理宽表） -> BIODS -> DWD -> 统一语义层（逻辑虚拟） -> BI/AI
开发方式手动编写 ETL 脚本，物理打宽声明式定义指标、维度与关联关系
灵活性维度固定，新需求需重新开发宽表（响应以周计）一个指标支持任意维度组合分析（响应以分钟计）
一致性口径分散在不同宽表，易“打架”一次定义，处处消费，口径 100% 一致
性能保障依赖预计算的宽表，无法应对发散查询基于声明式策略的智能物化加速，实现百亿明细秒级响应
总拥有成本高（重复加工、冗余存储、人力密集）低（架构简化、按需加速、自动化运维）

具体实现机制：

  1. 声明式定义，虚拟关联：数据工程师无需编写 JOIN 的 ETL 脚本，直接在平台界面声明“亚马逊订单表”与“Facebook 广告点击表”的逻辑关联关系。平台据此构建一个覆盖全域的 “虚拟业务事实网络” ，业务人员面对的是一个已逻辑关联的清晰数据视图，无需关心底层物理表结构。

  2. 自动化生产，智能加速：

    • 查询生成：当业务人员拖拽指标进行 ROI 分析时，平台语义引擎自动将操作翻译为高效、优化的 SQL。
    • 性能服务：管理员可声明式地指定需要加速的指标和维度组合（如“北美区广告 ROI”），平台智能物化引擎根据声明自动创建、运维物化视图（加速表），并在查询时实现透明的智能路由与 SQL 改写，在保障极致灵活性的同时，做到对业务透明的秒级响应。该引擎支持对去重计数、比率类等不可累加指标进行物化上卷。

  3. 统一服务，一次定义处处消费：通过标准化的 Restful API 和 JDBC 接口，将经过严格治理的指标（如“跨境综合 ROI”）同时提供给：

    • BI工具：如深度融合的 FineBI、Quick BI，或通过 JDBC 对接的其他 BI 工具。
    • 业务系统：CRM、ERP 等。
    • AI数据分析助手（Agent）：提供结构化的语义 API。
    • 办公软件：通过专用插件在 WPS 表格中直接调用。
      确保全公司消费同一份“数字真理”。

四步实践路径：从数据孤岛到敏捷洞察

引入 NoETL 新范式并非一场“推倒重来”的革命，而应采用渐进式策略，平滑演进，价值驱动。

  1. 存量挂载（统一出口）：将现有稳定、性能尚可的物理宽表快速接入平台，映射为逻辑视图。价值：零开发成本，迅速建立统一的指标服务出口，解决取数混乱的燃眉之急，保护历史投资。
  2. 增量原生（敏捷响应）：所有新产生的分析需求，尤其是跨平台 ROI 归因等复杂场景，直接基于 DWD 明细数据在语义层进行声明式定义，由平台自动化生产。价值：实现 T+0 敏捷响应，从源头遏制新债产生，验证平台价值。
  3. 存量替旧（降本增效）：识别并逐步下线那些高耗能、难维护、逻辑变更频繁的“包袱型”旧宽表 ETL 任务，用语义层模型替代。价值：释放昂贵的计算与存储资源，降低总拥有成本（TCO），将“死逻辑”盘活。
  4. 生态融合（深化价值）：将语义层指标服务通过 API 广泛赋能给 BI 报表、业务运营系统及 AI 应用，构建企业级数据中枢。价值：培育数据驱动文化，实现数据价值的最大化。

案例验证：NoETL 如何驱动跨境电商与零售巨头提效

NoETL 范式并非理论空想，已在金融、零售等复杂数据场景的头部企业中得到成功验证，其解决数据整合与敏捷分析问题的能力具有普适性。

  • 某头部券商：基于 Aloudata CAN 构建指标“管研用”一体化体系，替代传统 ETL 开发，实现开发提效 50%，分析提速 10 倍，指标口径 100% 一致，为智能决策奠定了坚实的可信数据底座。
  • 麦当劳中国：构建“管研用”一体的 NoETL 指标中台，沉淀上千个标准指标，统一 API 服务覆盖 30+ 业务场景，日均支撑百万级 API 调用，驱动全域数字化运营，并为 AI 应用提供就绪的数据底座。
  • 普遍价值：据众多案例验证，实施 NoETL 指标平台可将指标上线周期从数周缩短到小时，跨部门数据争议率降低 90% 以上，从技术层面保障了战略目标的统一拆解与高效执行。

行动建议：启动你的数据架构升级

面对数据孤岛和 ROI 统筹难题，观望和修补已无法应对未来的竞争。企业应主动评估并引入 NoETL 新范式，选择一个真正具备核心能力的指标平台作为转型基座。

  1. 明确评估维度：在选型 POC 中，重点考察平台是否具备：

    • 基于明细数据的“虚拟宽表”构建能力（能否声明逻辑关联，拒绝物理打宽）。
    • 复杂指标的表达力（是否支持跨表聚合、二次聚合、动态维度筛选等）。
    • 声明式智能物化加速机制（是否基于管理员声明自动运维加速，而非全自动或全手动）。
    • 标准的开放接口（JDBC/API）和生态融合能力。
  2. 启动灯塔项目：选择一条业务价值清晰、痛点明确的业务线（如 “北美市场全渠道广告效果分析” ）作为试点。聚焦于解决跨平台数据整合与实时 ROI 分析的具体问题，快速验证平台能力与业务价值。
  3. 规划渐进路线：采用上述 “四步实践路径” ，从统一数据出口开始，逐步实现新需求的敏捷响应和旧债务的清理，最终构建企业级智能数据基座，从容应对 AI 时代的挑战。

FAQ

Q1: NoETL 和传统 ETL 最大的区别是什么？

传统 ETL 需要数据工程师手动编写脚本，将数据加工成固化的物理宽表，业务分析被限制在预建的维度组合内。NoETL 通过统一语义层，将业务逻辑（指标、维度、关联）与物理存储解耦。业务人员在语义层通过声明式、界面化的方式定义分析需求，由平台自动生成最优查询并利用智能物化加速保障性能，实现了从“人工铺路”到“系统自动驾驶”的转变。

Q2: NoETL 如何保证跨平台数据整合时的查询性能？

NoETL 并非取消所有计算，而是通过智能物化引擎将预计算升级为一种自动化性能服务。平台会根据管理员声明的加速策略，自动创建并运维最优的物化视图。当用户进行复杂 ROI 分析时，查询会被自动、透明地路由到最合适的物化结果上，从而实现对十亿级明细数据的秒级响应，同时避免人工管理物化视图的复杂度和浪费。

Q3: 引入 NoETL 指标平台，对我们现有的数据仓库和 BI 工具有何影响？

NoETL 平台设计为中立、开放的基座，旨在增强而非取代现有投资。它可以无缝对接企业已有的数据湖/仓（直接读取 DWD 层），并通过标准 API/JDBC 接口与各类 BI 工具以及业务系统集成。平台成为统一的指标定义、计算和服务出口，下游 BI 工具回归为纯粹的“可视化渲染引擎”，从而打破厂商锁定，实现“一个指标，处处消费”。

Q4: NoETL 如何支持 AI 数据分析助手（Agent）？

NoETL 统一语义层为 AI 提供了结构化的、无歧义的“业务语言”和“工具”。AI Agent 不再需要直接面对复杂的物理表生成易错的 SQL，而是通过调用语义层的标准 API，传入指标、维度等参数，由平台负责精确计算并返回结果。这从根本上消除了 AI 的数据幻觉，并使其能够基于确定性的指标进行深度归因与洞察。

Key Takeaways（核心要点）

  1. 架构解耦是根本：跨境电商的 ROI 统筹难题，根源于传统“宽表模式”下业务逻辑与物理实现的紧耦合。NoETL 通过构建统一语义层，实现彻底解耦，是治本之策。
  2. 声明式驱动自动化：NoETL 的核心不是取消计算，而是通过 “声明式策略” 驱动智能物化加速与查询生成，在保障百亿数据秒级响应的同时，赋予业务前所未有的分析灵活性。
  3. 统一口径释放价值：通过 “一次定义，处处消费” 的标准化指标服务，NoETL 平台能终结数据口径混乱，建立公司级“数字真理”，为精准决策和 AI 应用提供可信底座，真正释放数据生产力。
    • *

本文首发于 Aloudata 官方技术博客，查看更多技术细节与高清图表，请访问原文链接：https://ai.noetl.cn/knowledge-base/cross-border-ecommerce-roi...

亚马逊首席执行官安迪・贾西（Andy Jassy）设想，在竞争对手纷纷推出 AI 购物代理的背景下，人工智能将通过复制实体店的 “惊喜发现感” 来改变零售业。亚马逊正在谈判向 OpenAI 投资约 100 亿美元，并与芯片使用量挂钩；与此同时，亚马逊也在开发 “帮我买”（Buy For Me）等内部工具，以维持其主导地位。这一战略转向旨在将创新与合作伙伴关系结合起来，以在未来的 AI 商务领域保持领先。

亚马逊的贾西在 AI 商务大战中前行：在购物代理竞争中押注 OpenAI

在达沃斯世界经济论坛的繁忙大厅里，亚马逊公司首席执行官安迪・贾西最近分享了他对零售业未来的愿景，强调人工智能可能会彻底改变消费者的购物方式。在一场小组讨论中，贾西指出，AI 有潜力弥合线上和线下购物体验之间的差距，并表示先进技术可能很快就能复制在实体店闲逛时那种 “偶然发现好物” 的感觉。
“在我看来，实体零售目前仍有一些优势的地方，是你可以走进店里，不知道自己想要什么，提出问题，不断细化问题，然后有人会给你推荐一些你甚至不知道存在的东西。” 据《The Information》报道，贾西这样说道。
这番评论发表之际，这家电商巨头正面临来自 OpenAI、谷歌和微软等竞争对手开发的 AI 购物代理的激烈竞争。这些工具允许用户直接在聊天界面内完成购买，对亚马逊在在线零售领域的主导地位构成潜在威胁。贾西的言论凸显了亚马逊的战略转向：它不仅在捍卫自己的地盘，还在积极探索合作伙伴关系，以在这个不断演变的领域保持领先。
最近的报道显示，亚马逊正就向 OpenAI 投资约 100 亿美元 进行深入谈判，这笔交易可能使这家 AI 公司的估值超过 5000 亿美元。据路透社 2025 年末的一篇文章详细报道，这笔潜在交易还包括 OpenAI 承诺使用亚马逊的 Trainium AI 芯片，这标志着双方技术联盟的深化。

AI 发展中的战略联盟

贾西对 AI 在提升购物体验方面作用的乐观态度，与更广泛的行业趋势一致。分析师指出，2026 年将是 AI 购物代理的关键一年，消费者将越来越多地为了便利和个性化而测试这些工具。《Modern Retail》的一篇文章指出，零售商和科技巨头正竞相完善这些代理，并押注它们会被广泛采用。
亚马逊面临的困境十分严峻：要么抵制这些可能绕过其平台的外部代理，要么整合类似功能以保留用户忠诚度。根据 CNBC 的分析，OpenAI 的 “即时结账”（Instant Checkout）和 Perplexity 的 “即时购买”（Instant Buy）等创新正在重塑交易方式，有可能将流量从传统电商网站分流。
作为回应，亚马逊一直在测试自己的功能，例如 “帮我买”（Buy For Me）选项，该功能允许用户在不离开亚马逊生态系统的情况下从第三方网站购买商品。行业观察人士在 X 上的帖子指出，这是一种防御策略，有用户注意到 AI 代理现在可以在一次对话中完成从产品研究到结账的所有操作，凸显了竞争压力。

与科技巨头的正面交锋

AI 与商务的融合，使主要参与者走上了直接竞争的道路。《The Information》的一篇报道描述了谷歌、亚马逊和 OpenAI 各自如何追求不同的战略，从专有代理到协作商务模式。这场竞争还延伸到了微软，微软最近推出了 “Copilot Checkout”，允许在其 AI 聊天机器人中无缝完成购买。
GeekWire 报道了微软进入这一领域的消息，并强调其企业关系可能使其相对于亚马逊和其他公司具有优势。“微软正在推出一项新的‘Copilot Checkout’功能，让购物者可以直接在其 AI 聊天机器人内完成购买，”GeekWire 的文章指出，并强调了在 AI 驱动的商务中对零售商关系的押注。
贾西在达沃斯的亮相中也谈到了围绕 AI 投资的泡沫担忧。《The Register》的一篇最新报道援引他的话称，他承认存在炒作，但重申亚马逊致力于从中挖掘价值，即使这些交易看起来有些 “循环”。

OpenAI 合作关系动态

对 OpenAI 潜在的 100 亿美元投资不仅仅是财务上的，更是为了确保技术优势。正如《Fortune》一篇文章所引用的专家观点，这被视为亚马逊在 “下一盘大棋”。分析师查尔斯・菲茨杰拉德（Charles Fitzgerald）表示：“如果 OpenAI 中了‘彩票’，那么他们就有足够的钱来支付这笔费用。” 他指的是芯片使用协议。
这种关系建立在亚马逊现有的 AI 计划之上，包括其 AGI 团队正努力超越 Anthropic 等合作伙伴的模型。2024 年 X 上的历史帖子回顾了亚马逊对 Anthropic 的投资，但此次转向 OpenAI 表明，在 OpenAI 自身内部发生变化的背景下，亚马逊正在采取多元化战略。
《印度时报》最近的消息详细报道了 OpenAI 从其前首席技术官领导的初创公司挖走人才的情况，这表明 OpenAI 内部存在动荡，而亚马逊可能通过投资加以利用。

正在重塑零售互动的创新

除了投资之外，亚马逊还在将 AI 深度嵌入其运营中。贾西 2025 年在 X 上的帖子宣传了新的智能体式 AI（agentic AI）功能，这些功能可以通过分析数据和自动化任务来帮助卖家扩展业务。这种内部关注与外部合作伙伴关系相辅相成，旨在创造无缝的购物旅程。
《Wired》探讨了一些开发者不愿让 AI 代理作为用户互动中介的担忧，正如一篇 WIRED 文章所讨论的那样，AI 正成为下一个平台。然而，亚马逊仍在推进，AI 已用于预测需求、优化配送路线，甚至在仓库中提供协助，正如 2023 年的 X 帖子所展示的那样。
X 上的行业情绪反映了对这些进步的兴奋。有帖子称，像亚马逊这样的数字商务平台正将 AI 转变为核心基础设施，触及从推荐到配送的各个方面。

挑战与消费者采用

尽管热情高涨，但挑战依然存在。贾西在达沃斯的评论提到了实体零售仍然持有的优势，这意味着 AI 必须不断发展，才能匹配那种探索的乐趣。分析师警告称，2026 年消费者对 AI 代理的接受程度将是真正的考验，正如《Modern Retail》的分析所指出的那样。
此外，潜在的 OpenAI 交易引发了有关反垄断审查的问题，考虑到投资规模和市场影响力。路透社关于谈判的报道强调了估值方面的影响，这可能会重塑 AI 融资动态。
a16z 等风险投资公司在 X 上的帖子认为，AI 正在将在线购物模式从 “量” 转向 “质” 和个性化，亚马逊必须谨慎应对这一转变，以免被边缘化。

AI 商务整合的未来轨迹

展望未来，亚马逊的战略似乎是多方面的：投资尖端 AI 公司、开发内部工具，并适应新兴的消费者行为。贾西早些时候在 2023 年 X 帖子中对 “亚马逊在 AI 方面落后” 的说法提出质疑，这表明他一贯强调实质而非炒作。
《The Information》详细描述了亚马逊与谷歌和 OpenAI 的正面竞争，这表明可能会出现共享商务模式，但专有优势将决定胜负。正如 GeekWire 所指出的，微软的 Copilot 举措又增加了一层竞争，它将利用其企业关系。
最终，随着 AI 设备的普及，《Wired》指出开发者存在犹豫，但亚马逊的规模可能使其处于领先地位。贾西在达沃斯提出的愿景强调了 “细化问题” 和 “发现”，指向一个未来：AI 代理将充当虚拟商店助理，将在线效率与线下的惊喜发现感完美结合。

在投资与内部增长之间取得平衡

亚马逊对 OpenAI 的潜在注资并非孤立存在，而是更广泛战略推进的一部分。《Fortune》的专家强调了这种战略耐心，亚马逊押注 OpenAI 的成功将推动芯片的采用。
内部开发项目，例如 2024 年 X 帖子中提到的 Olympus LLM，表明亚马逊在合作的同时也致力于自力更生。这种双轨方式可以减轻 OpenAI 危机带来的风险，正如《印度时报》所报道的那样。
X 用户最近对亚马逊的 “帮我买” 功能表示赞赏，认为它是对 OpenAI 即时结账的反击，有助于维持生态系统的控制权。

竞争压力与市场反应

根据《Modern Retail》的说法，AI 购物大战正在升温，2026 年将是关键时期。正如 CNBC 所描述的那样，亚马逊面临的困境是：与这些代理对抗，还是加入它们。
贾西在《The Register》中对 “泡沫” 的承认反映了他在乐观中的现实态度。“当然这是一个泡沫，而且这些交易是循环的 —— 但这并不意味着亚马逊不会努力从中榨取价值。” 他说。
X 上的情绪强调了 AI 在电商基础设施中的作用，从亚马逊到沃尔玛和 Shopify 等竞争对手，正如一篇帖子所对比的那样。

不断演变的消费者期望

消费者可能很快就会期望 AI 能够无缝处理复杂的购物任务。《The Information》对达沃斯的报道援引贾西的话，强调实体零售的优势，这正推动亚马逊在数字领域进行创新。
《Wired》关于 AI 平台的文章警告称存在开发者的抵制，但亚马逊的整合可能会促进采用。
正如 X 上的帖子所暗示的那样，AI 正在从头开始重塑购物，重点放在用户体验和价格优化上 —— 而这些正是亚马逊擅长的领域。

亚马逊的战略展望

在这种高风险环境下，亚马逊与 OpenAI 的谈判代表着一场大胆的赌注。路透社详细报道了 100 亿美元的数字，并将其与芯片承诺挂钩。
《Fortune》分析师认为，这是一种长期定位，将 OpenAI 视为 “AI 领域的舒洁（Kleenex）”。
贾西的领导能力在他关于卖家工具的 X 帖子中显而易见，这使亚马逊能够将 AI 创新与零售实力结合起来，从而在竞争中脱颖而出。
正如《The Information》所概述的那样，前进的道路包括在竞争中导航，确保亚马逊在 AI 商务的演变过程中保持核心地位。

这两天技术圈里热议的一件事就是Amazon的流媒体平台Prime Video在2023年3月22日发布了一篇技术博客《规模化Prime Video的音视频监控服务，成本降低90%》，副标题：“从分布式微服务架构到单体应用程序的转变有助于实现更高的规模、弹性和降低成本”，有人把这篇文章在五一期间转到了reddit 和 hacker news 上，在Reddit上热议。这种话题与业内推崇的微服务架构形成了鲜明的对比。从“微服务架构”转“单体架构”，还是Amazon干的，这个话题足够劲爆。然后DHH在刚喷完Typescript后继续发文《即便是亚马逊也无法理解Servless或微服务》，继续抨击微服务架构，于是，瞬间引爆技术圈，登上技术圈热搜。

今天上午有好几个朋友在微信里转了三篇文章给我，如下所示：

看看这些标题就知道这些文章要的是流量而不是好好写篇文章。看到第二篇，你还真当 Prime Video 就是 Amazon 的全部么？然后，再看看这些文章后面的跟风评论，我觉得有 80%的人只看标题，而且是连原文都不看的。所以，我想我得写篇文章了……

原文解读

要认清这个问题首先是要认认真真读一读原文，Amazon Prime Video 技术团队的这篇文章并不难读，也没有太多的技术细节，但核心意思如下：

1）这个系统是一个监控系统，用于监控数据千条用户的点播视频流。主要是监控整个视频流运作的质量和效果（比如：视频损坏或是音频不同步等问题），这个监控主要是处理视频帧，所以，他们有一个微服务主要是用来把视频拆分成帧，并临时存在 S3 上，就是下图中的 Media Conversion 服务。

2）为了快速搭建系统，Prime Video团队使用了Serverless 架构，也就是著名的 AWS Lambda 和 AWS Step Functions。前置 Lambda 用来做用户请求的网关，Step Function 用来做监控（探测器），有问题后，就发 SNS 上，Step Function 从 S3 获取 Media Conversion 的数据，然后把运行结果再汇总给一个后置的 Lambda ，并存在 S3 上。

整个架构看上去非常简单 ，一点也不复杂，而且使用了 Serverless 的架构，一点服务器的影子都看不见。实话实说，这样的开发不香吗？我觉得很香啊，方便快捷，完全不理那些无聊的基础设施，直接把代码转成服务，然后用 AWS 的 Lamda + Step Function + SNS + S3 分分钟就搭出一个有模有样的监控系统了，哪里不好了？！

但是他们遇到了一个比较大的问题，就是 AWS Step Function 的伸缩问题，从文章中我看到了两个问题（注意前方高能）：

  1. 需要很多很多的并发的 AWS Step Function ，于是达到了帐户的 hard limit。
  2. AWS Step Function 按状态转换收费，所以，贵得受不了了。

注意，这里有两个关键点：1）帐户对 Step Function 有限制，2）Step Function 太贵了用不起。

然后，Prime Video 的团队开始解决问题，下面是解决的手段：

1） 把 Media Conversion  和 Step Function 全部写在一个程序里，Media Conversion 跟 Step Function 里的东西通过内存通信，不再走S3了。结果汇总到一个线程中，然后写到 S3.

2）把上面这个单体架构进行分布式部署，还是用之前的 AWS Lambda 来做入门调度。

EC2 的水平扩展没有限制，而且你想买多少 CPU/MEM 的机器由你说了算，而这些视频转码，监控分析的功能感觉就不复杂，本来就应该写在一起，这么做不更香吗？当然更香，比前面的 Serverless 的确更香，因为如下的几个原因：

  1. 不再受 Step Function 的限制了，技术在自己手里，有更大的自由度。
  2. 没有昂贵的 Step Function 云成本的确变得更低了，如果你把 Lambda 换成 Nginx 或 Spring Gateway 或是我司的 Easegress，你把 S3 换成 MinIO，你把 SNS 换成 Kafka，你的成本 还能再低。

独立思考

好了，原文解读完了，你有自己的独立思考了吗？下面是我的独立思考，供你参考：

1）AWS 的 Serverless 也好， 微服务也好，单体也好，在合适的场景也都很香。这就跟汽车一样，跑车，货车，越野车各有各的场景，你用跑车拉货，还是用货车泡妞都不是一个很好的决定。

2）这篇文章中的这个例子中的业务太过简单了，本来就是一两个服务就可以干完的事。就是一个转码加分析的事，要分开的话，就两个微服务就好了（一个转码一个分析），做成流式的。如果不想分，合在一起也没问题了，这个粒度是微服务没毛病。微服务的划分有好些原则，我这里只罗列几个比较重要的原则：

  • 边界上下文。微服务的粒度不能大于领域驱动里的 Bounded Context（具体是什么 大家自行 Google），也就是一个业务域。
  • 单一职责，高内聚，低耦合。把因为相同原因变化的合在一起（内聚），把不同原因变化的分开（解耦）
  • 事务和一致性。对于两个重度依赖的功能，需要完成一个事务和要保证强一致性的，最好不要拆开，要放在一起。
  • 跟组织架构匹配。把同一个团队的东西放在一起，不同团队的分开。

3）Prime Video 遇到的问题不是技术问题，而是 AWS  Step Function 处理能力不足，而且收费还很贵的问题。这个是 AWS 的产品问题，不是技术问题。或者说，这个是Prime Video滥用了Step Function的问题（本来这种大量的数据分析处理就不适合Step Function）。所以，大家不要用一个产品问题来得到微服务架构有问题的结论，这个没有因果关系。试问，如果 Step Funciton 可以无限扩展，性能也很好，而且白菜价，那么 Prime Video 团队还会有动力改成单体吗？他们不会反过来吹爆 Serverless 吗？

4）Prime Video 跟 AWS 是两个独立核算的公司，就像 Amazon 的电商和 AWS 一样，也是两个公司。Amazon 的电商和 AWS 对服务化或是微服务架构的理解和运维，我个人认为这个世界上再也找不到另外一家公司了，包括 Google 或 Microsoft。你有空可以看看本站以前的这篇文章《Steve Yegg对Amazon和Google平台的吐槽》你会了解的更多。

5）Prime Video 这个案例本质上是“下云”，下了 AWS Serverless 的云。云上的成本就是高，一个是费用问题，另一个是被锁定的问题。Prime Video 团队应该很庆幸这个监控系统并不复杂，重写起来也很快，所以，可以很快使用一个更传统的“服务化”+“云计算”的分布式架构，不然，就得像 DHH 那样咬牙下云——《Why We’re Leaving the Cloud》（他们的 SRE 的这篇博文 Our Cloud Spend in 2022说明了下云的困难和节约了多少成本）

后记

最后让我做个我自己的广告。我在过去几年的创业中，帮助了很多公司解决了这些 分布式，微服务，云原生以及云计算成本的问题，如果你也有类似问题。欢迎，跟我联系：[email protected]

另外，我们今年发布了一个平台 MegaEase Cloud，就是想让用户在不失去云计算体验的同时，通过自建高可用基础架构的方式来获得更低的成本（至少降 50%的云计算成本）。目前可以降低成本的方式：

  1. 基础软件：通过开源软件自建，
  2. 内容分发：MinIO + Cloudflare 的免费 CDN，
  3. 马上准备发布的直接与底层IDC合作的廉价GPU计算资源…

欢迎大家试用。

如何访问

注：这两个区完全独立，帐号不互通。因为网络的不可抗力，千万不要跨区使用。

产品演示

介绍文章

 

这两天技术圈里热议的一件事就是Amazon的流媒体平台Prime Video在2023年3月22日发布了一篇技术博客《规模化Prime Video的音视频监控服务，成本降低90%》，副标题：“从分布式微服务架构到单体应用程序的转变有助于实现更高的规模、弹性和降低成本”，有人把这篇文章在五一期间转到了reddit 和 hacker news 上，在Reddit上热议。这种话题与业内推崇的微服务架构形成了鲜明的对比。从“微服务架构”转“单体架构”，还是Amazon干的，这个话题足够劲爆。然后DHH在刚喷完Typescript后继续发文《即便是亚马逊也无法理解Servless或微服务》，继续抨击微服务架构，于是，瞬间引爆技术圈，登上技术圈热搜。

今天上午有好几个朋友在微信里转了三篇文章给我，如下所示：

看看这些标题就知道这些文章要的是流量而不是好好写篇文章。看到第二篇，你还真当 Prime Video 就是 Amazon 的全部么？然后，再看看这些文章后面的跟风评论，我觉得有 80%的人只看标题，而且是连原文都不看的。所以，我想我得写篇文章了……

原文解读

要认清这个问题首先是要认认真真读一读原文，Amazon Prime Video 技术团队的这篇文章并不难读，也没有太多的技术细节，但核心意思如下：

1）这个系统是一个监控系统，用于监控数据千条用户的点播视频流。主要是监控整个视频流运作的质量和效果（比如：视频损坏或是音频不同步等问题），这个监控主要是处理视频帧，所以，他们有一个微服务主要是用来把视频拆分成帧，并临时存在 S3 上，就是下图中的 Media Conversion 服务。

2）为了快速搭建系统，Prime Video团队使用了Serverless 架构，也就是著名的 AWS Lambda 和 AWS Step Functions。前置 Lambda 用来做用户请求的网关，Step Function 用来做监控（探测器），有问题后，就发 SNS 上，Step Function 从 S3 获取 Media Conversion 的数据，然后把运行结果再汇总给一个后置的 Lambda ，并存在 S3 上。

整个架构看上去非常简单 ，一点也不复杂，而且使用了 Serverless 的架构，一点服务器的影子都看不见。实话实说，这样的开发不香吗？我觉得很香啊，方便快捷，完全不理那些无聊的基础设施，直接把代码转成服务，然后用 AWS 的 Lamda + Step Function + SNS + S3 分分钟就搭出一个有模有样的监控系统了，哪里不好了？！

但是他们遇到了一个比较大的问题，就是 AWS Step Function 的伸缩问题，从文章中我看到了两个问题（注意前方高能）：

  1. 需要很多很多的并发的 AWS Step Function ，于是达到了帐户的 hard limit。
  2. AWS Step Function 按状态转换收费，所以，贵得受不了了。

注意，这里有两个关键点：1）帐户对 Step Function 有限制，2）Step Function 太贵了用不起。

然后，Prime Video 的团队开始解决问题，下面是解决的手段：

1） 把 Media Conversion  和 Step Function 全部写在一个程序里，Media Conversion 跟 Step Function 里的东西通过内存通信，不再走S3了。结果汇总到一个线程中，然后写到 S3.

2）把上面这个单体架构进行分布式部署，还是用之前的 AWS Lambda 来做入门调度。

EC2 的水平扩展没有限制，而且你想买多少 CPU/MEM 的机器由你说了算，而这些视频转码，监控分析的功能感觉就不复杂，本来就应该写在一起，这么做不更香吗？当然更香，比前面的 Serverless 的确更香，因为如下的几个原因：

  1. 不再受 Step Function 的限制了，技术在自己手里，有更大的自由度。
  2. 没有昂贵的 Step Function 云成本的确变得更低了，如果你把 Lambda 换成 Nginx 或 Spring Gateway 或是我司的 Easegress，你把 S3 换成 MinIO，你把 SNS 换成 Kafka，你的成本 还能再低。

独立思考

好了，原文解读完了，你有自己的独立思考了吗？下面是我的独立思考，供你参考：

1）AWS 的 Serverless 也好， 微服务也好，单体也好，在合适的场景也都很香。这就跟汽车一样，跑车，货车，越野车各有各的场景，你用跑车拉货，还是用货车泡妞都不是一个很好的决定。

2）这篇文章中的这个例子中的业务太过简单了，本来就是一两个服务就可以干完的事。就是一个转码加分析的事，要分开的话，就两个微服务就好了（一个转码一个分析），做成流式的。如果不想分，合在一起也没问题了，这个粒度是微服务没毛病。微服务的划分有好些原则，我这里只罗列几个比较重要的原则：

  • 边界上下文。微服务的粒度不能大于领域驱动里的 Bounded Context（具体是什么 大家自行 Google），也就是一个业务域。
  • 单一职责，高内聚，低耦合。把因为相同原因变化的合在一起（内聚），把不同原因变化的分开（解耦）
  • 事务和一致性。对于两个重度依赖的功能，需要完成一个事务和要保证强一致性的，最好不要拆开，要放在一起。
  • 跟组织架构匹配。把同一个团队的东西放在一起，不同团队的分开。

3）Prime Video 遇到的问题不是技术问题，而是 AWS  Step Function 处理能力不足，而且收费还很贵的问题。这个是 AWS 的产品问题，不是技术问题。或者说，这个是Prime Video滥用了Step Function的问题（本来这种大量的数据分析处理就不适合Step Function）。所以，大家不要用一个产品问题来得到微服务架构有问题的结论，这个没有因果关系。试问，如果 Step Funciton 可以无限扩展，性能也很好，而且白菜价，那么 Prime Video 团队还会有动力改成单体吗？他们不会反过来吹爆 Serverless 吗？

4）Prime Video 跟 AWS 是两个独立核算的公司，就像 Amazon 的电商和 AWS 一样，也是两个公司。Amazon 的电商和 AWS 对服务化或是微服务架构的理解和运维，我个人认为这个世界上再也找不到另外一家公司了，包括 Google 或 Microsoft。你有空可以看看本站以前的这篇文章《Steve Yegg对Amazon和Google平台的吐槽》你会了解的更多。

5）Prime Video 这个案例本质上是“下云”，下了 AWS Serverless 的云。云上的成本就是高，一个是费用问题，另一个是被锁定的问题。Prime Video 团队应该很庆幸这个监控系统并不复杂，重写起来也很快，所以，可以很快使用一个更传统的“服务化”+“云计算”的分布式架构，不然，就得像 DHH 那样咬牙下云——《Why We’re Leaving the Cloud》（他们的 SRE 的这篇博文 Our Cloud Spend in 2022说明了下云的困难和节约了多少成本）

后记

最后让我做个我自己的广告。我在过去几年的创业中，帮助了很多公司解决了这些 分布式，微服务，云原生以及云计算成本的问题，如果你也有类似问题。欢迎，跟我联系：[email protected]

另外，我们今年发布了一个平台 MegaEase Cloud，就是想让用户在不失去云计算体验的同时，通过自建高可用基础架构的方式来获得更低的成本（至少降 50%的云计算成本）。目前可以降低成本的方式：

  1. 基础软件：通过开源软件自建，
  2. 内容分发：MinIO + Cloudflare 的免费 CDN，
  3. 马上准备发布的直接与底层IDC合作的廉价GPU计算资源…

欢迎大家试用。

如何访问

注：这两个区完全独立，帐号不互通。因为网络的不可抗力，千万不要跨区使用。

产品演示

介绍文章

 

（全文完）

（转载本站文章请注明作者和出处 酷 壳 – CoolShell ，请勿用于任何商业用途）

好烂啊有点差凑合看看还不错很精彩 (647 人打了分，平均分： 4.32 )

Loading...

  数据泄漏

  日本家信用联盟因亚马逊AWSS3配置不当，逾100GB用户敏感数据公布

  网络安全公司研究员工Chris于近日发现日本国家信用联盟（NCF）托管的亚马逊AWSS3存储器因配置不当，导致逾100G用户敏感数据在线暴露，其中包含客户姓名、地址、社保号码、银行帐号或者信用报告等详细信息。据称，由日本三大著名信用机构、与整理的数千份用户信用报告也坐落其中。

  AI.type虚拟按键应用程序泄露了3100万顾客个人数据

  2017黑客入侵工具包

  据悉，安全中心的一组安全研究员工发觉，大量来源属于近期非常流行的虚拟按键应用程序AI.type的个人数据被泄漏。目前有少于3100万的顾客信息被泄露到互联网上，且无需任何密钥即可下载。

  Ai.type成立于2010年2017黑客入侵工具包，是一款可订制的个性化移动电话和平板手机后盖键盘，全球拥有少于4000万顾客。目前泄漏数据库包含：用户姓名、电话、邮件地址、设备名称型号、IP地址、GPS位置、生日、照片等等内容。此外，泄露的数据库还显示，虚拟按键应用程序也在盗取客户的通信录，包括联络人的姓名和电话号码。

  看个网站才能泄露手机号？数百万网友隐私遭侵犯

  用相机上网看几条新闻，下线之后没过几秒钟垃圾邮件、骚扰电话就不请自来，其实这都是“手机访客营销”黑色产业链在搞鬼，其借助运营商平台漏洞，非法获得公民手机号，再将信息出售，用作所谓的“精准行销”。

  据统计，2016年到2017年我国有6.88亿观众因垃圾邮件、诈骗信息、个人信息泄漏等导致的经济代价估算达915亿元。

  新加坡共享单车Obike遭黑客入侵，大量顾客信息被泄漏

  新加坡共享单车Obike日前被爆出在世界范围内遭受了黑客入侵事故，新加坡、悉尼或纽约的Obike用户的个人信息很可能已被泄漏。该袭击惨案至少持续了两周时间，许多顾客的个人信息，包括姓名、联系方法、照片和地址等已被泄漏到互联网上。

  黑客运用了“我们应用编程介面(API)中的一个安全漏洞”。如今，Obike已经关掉了该API，并降低了额外的保护程序。

  安全漏洞

  旗下的TIO运营平台存在安全漏洞，逾160万顾客敏感信息在线泄露

  据悉，全球经贸支付公司否认，公司旗下的TIO运营平台存在安全漏洞，黑客已经访问了储存在其服务器中逾160万顾客的脆弱数据2017黑客入侵工具包，包括顾客可辨识信息（PII）和部份财务细节。

  2017黑客入侵工具包

  TIO是一家基于云支付处理和讨债款管理的新西兰提供商，于2017年2月被以2.33亿英镑出售，其公司在南美地区经营着超出60,000个公共事业的汇票支付平台。

  据知情专家透露，正通知受妨碍用户并与一家消费者信用机构合作，从而为被害客户提供免费的信用监控会员资格，以便保障顾客信息安全。此外，TIO客户还可以借助官方获得更多关于数据泄漏的相关细节。

  邮件地址解析存在纰漏，影响33个电邮用户端

  法国安全研究员Sabri发现了多个被他也称为的纰漏。攻击者能借助这种漏洞诱骗邮件身份，而且在个别状况下能在顾客计算机中执行恶意代码。

  尽管远程代码执行的素养让人害怕，但实际上真正的弊端是电邮诈骗攻击。这种防御能避免所有现代反欺骗保护制度如DMARC(DKIM/SPF)或多种垃圾电邮过滤器。

  如此，攻击者才能通过由夸大用户和电邮服务器构成的短信身份来发送电邮，而这些夸大身份无法监测；进而造成钓鱼攻击和携带恶意工具的电邮更难被发觉。

  iOS11再曝安全漏洞

  之前苹果发布的iOS11更新率从而表明问题，大家升级热情相比iOS10慢了好多，之所以会这么，还是新平台问题非常多。

  开发者发觉，刚刚推送的iOS11.2正式版中，苹果继续犯下了大错误。原来，新平台中存在着严重的安全漏洞，利用这个漏洞攻击者可以轻松控制这些支持仪器，甚至是智能门锁。

  其他大事记

  《世界互联网发展报告2017》《中国互联网发展报告2017》蓝皮书正式公布

  2017黑客入侵工具包

  12月4日下午，由美国网路空间研究院编撰的《世界互联网发展报告2017》和《中国互联网发展报告2017》蓝皮书在第四届全球互联网大会上即将公布。这是全球互联网大会举行以来，首次面向世界公布互联网领域最新学术探究成果。

  人工智能的今后，冰箱也无法幸免

  新浪科技讯，全球网路安全服务厂商赛门铁克()近日称，2018年黑客将首次使用人工智能(AI)和机器学习(ML)科技发动网路防御，届时冰箱等物联网(IoT)器材也不能幸免。

  赛门铁克产品管理经理塔伦·库拉(TarunKaura)在一份申明中称，2018年黑客将首次使用人工智能科技发动防御。物联网设施被侵入后，黑客就会借助这种仪器发动DDoS防御。

  因为物联网设施采用了继电器，被侵入后，黑客可以借助音频、视频或其它输入方法，让该器材执行黑客的操作，而不是顾客希望他们做的事情。

  不仅适于发动DDoS防御和索要赔款，黑客还可以借助这种被侵入的家庭物联网设施，“持续”访问被侵入用户的手机网路。这里所说的“持续”访问，是指无论客户多么经常地对计算机进行查杀或保护，黑客就会拥有一个“后门”来访问被侵入者的网路。