网站海外推广服务深圳个人如何做网站设计

网站海外推广服务,深圳个人如何做网站设计,网站开发语言怎么查,上海免费推广网站有哪些摘要#xff1a;本文整理自 OpenAI 基础设施团队的 Shuyi Chen 和 Joey Pereira 在 Current 2025 伦敦会议上的演讲 ”Building a Stream Processing Platform at OpenAI“#xff0c;主要演讲内容为#xff1a;OpenAI 的流式基础设施 构建流处理平台的动机及遇到的挑战本文整理自 OpenAI 基础设施团队的 Shuyi Chen 和 Joey Pereira 在 Current 2025 伦敦会议上的演讲 ”Building a Stream Processing Platform at OpenAI“主要演讲内容为OpenAI 的流式基础设施构建流处理平台的动机及遇到的挑战OpenAI 的整体架构及深入解读OpenAI 业务用例以及平台未来的演进方向Tips本篇分为上下两篇点击此处跳转上篇07Flink 与 Kafka 的集成接下来我们聊聊 Kafka 连接器——需要特别说明的是这里指的是 Flink 自带的原生连接器而非 Confluent 提供的版本。如前所述我们的 Kafka 部署采用了高可用组HA Group架构多个跨区域的物理集群组成一个逻辑集群目的是确保即使其中一个集群完全失效整个系统仍能正常运行。这就带来了一个核心挑战如何让 Flink 应用适配这种多集群架构我们能否构建出真正容忍 Kafka 集群中断的流处理作业乍看之下这似乎并不难。我们只需要在 Source 和 Sink 两端“堆”几个 Kafka 连接器就行了。先看 Source 端拿到集群列表后为每个集群创建一个 Kafka Source再把它们 union 起来接入主处理逻辑——问题不就解决了吗可惜现实没那么美好。你可能已经猜到了结果——否则我也不会花时间专门讲这一段。事实上当某个 Kafka 集群宕机后不久我们的 Flink 应用就开始频繁崩溃。深入排查后我们发现根本原因在于连接器的初始化机制当 Kafka Source 启动时它会尝试获取主题的分区元数据、枚举所有分区并为每个分区创建读取任务。如果此时某个集群不可达Flink 内部对 Kafka 元数据的请求就会失败并直接抛出异常——整个作业因此被拉垮毫无容错能力可言。通过对 Kafka Source 进行定制化改造我们将其配置为在元数据请求失败时无限重试。这样一来那些已经成功初始化、正在从 Kafka 分区读取数据的任务会继续正常运行而针对故障集群的读取任务则会持续重试虽不产出数据但也不会导致作业崩溃。这已经满足了我们的首要目标保证应用持续运行。更进一步即使在某个 Kafka 集群宕机的情况下我们也能正常重启 Flink 作业——它会跳过不可达集群的分区仅对可用集群创建读取器。这让我们离理想状态又近了一步。但这还不是全部。我们的 Flink 应用在启动时会动态加载集群配置并据此构建 Kafka Source 列表。正如前文提到的由于作业拓扑依赖于这份配置一旦配置变更例如移除或新增集群就必须重启作业才能生效。为此我们引入了一个“看门狗”watchdog服务持续监听配置变化并在必要时触发作业重启。这意味着当某个集群彻底失联、确认无法恢复时我们可以直接从应用配置中将其移除彻底停止对其消费而当它恢复后只需重新加入配置配合自定义的偏移量初始器initializers就能从上次中断的位置继续消费大致如此。通过这种方式我们实际上拥有了两层容错机制运行时重试 配置驱动的动态调整。需要特别说明的是这套方案目前主要应用于不依赖水印watermark的管道。如果管道使用了水印而某个 Source 因集群宕机停止输出数据就会导致水印无法推进整个流处理逻辑被卡住。理论上可以通过设置空闲超时idle timeout来缓解但这一路径我们尚未像无水印场景那样充分验证。当然一旦故障集群恢复积压的数据会重新流入系统——不过会被标记为迟到事件late events。从设计角度看这其实提供了一种明确的权衡选择用户可以在强一致性视图和高可用性之间做出取舍。选择后者就意味着接受更多迟到数据但换来的是系统在部分基础设施失效时仍能持续运转的能力。关于 Source 端还有一点值得补充Flink 开源社区其实已经提供了一个非常实用的方案——动态 Kafka SourceDynamic Kafka Source。它将多个主题或多个集群的 Kafka 源统一抽象为一个真正的 Flink Source。你可以实现一个轻量级的元数据服务或一个简单的类动态指定当前需要消费哪些集群和主题。更重要的是它支持在运行时重新加载元数据并直接将新发现的分区分配给任务完全无需修改作业拓扑或重启作业。这意味着你不再需要依赖外部的“看门狗”来触发重启——配置变更可以实时生效灵活性大幅提升。而且这个功能是完全开源的。它的任务分配逻辑与原生 Kafka Source 高度一致分配的最小单元不是单纯的“分区”而是 分区 × 主题 × 集群 的组合能准确反映多集群拓扑结构。我们目前尚未在生产中采用它主要有两个原因一是 PyFlink 尚未提供对应的 Python 封装wrapper二是它在某些细节上仍有局限——例如无法为每个集群和主题单独配置偏移量初始器offset initializers。尽管如此它的整体表现已经相当可靠远胜于手动重启作业并喊一句“嘿醒醒加个集群”。因此我们计划尽快为 PyFlink 补齐对动态 Kafka Source 的支持并在落地过程中持续修复和优化充分释放其潜力。有了这个方案我们终于有了一条清晰可行的路径即使某个 Kafka 集群宕机Flink 作业也能无缝继续消费其他集群的数据用户几乎感知不到任何中断。现在来看 Sink 端。我们最初设想了一个看似简洁的方案通过一个分流函数将主数据流均匀拆分到多个旁路输出side outputs中再为每个 Kafka 集群分别挂载一个 Sink。理想情况下三个集群各承担约三分之一的流量——逻辑清晰实现简单当时我们甚至觉得这方案稳了……可惜现实很快给了我们一记重击。你大概已经猜到结果了一旦某个 Kafka 集群下线整个作业几乎立刻陷入停滞无法继续处理数据。更深层次的问题在于这种设计存在结构性缺陷。由于所有 Sink 共享同一个处理流水线任何一个集群出现性能波动比如网络延迟、磁盘瓶颈或限流都会通过背压backpressure传导至整个作业拖慢所有数据流。我们原本希望通过静态均分来实现负载均衡却忽略了现实环境中的异构性——不同区域的 Flink 作业与 Kafka 集群之间的写入能力差异极大有的集群吞吐迅猛有的则响应迟缓固定比例的分流非但无法均衡负载反而放大了系统短板。那我们怎么办坦白说我们“走了一条捷径”。事实上OpenAI 的大多数服务早已在使用一个统一的生产者代理它封装了重试、断路器circuit breakers、集群动态发现等高可用逻辑。于是我们直接把这个代理调用包装成一个 Flink 函数来实现 Sink 功能。当然这样做也带来了一些限制和注意事项。首先我们的代理并不真正支持基于键的自定义分区key-based custom partitioning。而如果强制使用键分区就会把某个分区的数据绑定到单一 Kafka 集群上——这与我们追求高可用的目标直接冲突。毕竟我们不想让任何一个 Kafka 集群成为系统的单点依赖。其次事务transactions目前也无法支持。要在代理中集成完整的状态管理与事务语义复杂度极高几乎得不偿失。需要特别说明的是由于我们将代理封装成了一个普通的 Flink 函数天然受限于函数的执行模型——事务性写入无法在单个函数内实现必须通过完整的 Sink 实现才能支持。最后这种方案还引入了额外的性能开销尤其是在高吞吐场景下代理层的调用链路会成为瓶颈这显然不是理想状态。 那么下一步怎么优化我们正在规划将这一能力重构为一个真正的开源 Sink 实现并计划向社区提交正式提案打造一个既高可用又高性能的标准解决方案。对于非事务性写入实现起来其实相对直接你可以替换底层的写入器writer实现让它将数据分发给多个 Kafka 集群的写入器从而构建一个写入器池。在这个池子之上你可以封装重试、故障转移、负载均衡等逻辑。更重要的是这套机制可以像“动态 Kafka 源”那样支持运行时动态配置——集群的增删、迁移等操作都能实时生效无需重启作业极大提升了运维灵活性。相比之下事务性写入的实现要复杂得多。虽然当前的 Kafka Sink 内部确实有一个生产者池pool of producers理论上可以尝试将其扩展到多集群场景但一旦引入跨集群事务就会迅速陷入各种边缘情况的泥潭事务边界如何界定故障时如何回滚不同集群间的协调如何保证这些问题目前都没有成熟的解决方案。尽管如此我们仍认为存在一条可行的技术路径——通过更精细的控制和设计未来有望实现一种既支持高可用又兼顾迁移灵活性的事务性发布方案远优于当前依赖静态配置的替代方案。 结合 Source 和 Sink 两端的实践你应该已经能感受到在真实的大规模生产环境中面对多集群、跨区域的 Kafka 架构流处理系统必须在可用性、一致性与运维效率之间做出务实权衡。而我们的探索正是为了在这条复杂路径上找到更稳健的前行方式。让我们稍作停顿重新聚焦一下为什么这些设计对我们如此关键因为在实际运行中故障不是“会不会发生”的问题而是“何时发生”的问题。中断早已成为常态而非例外。你可能经历过也可能没经历过——但在 OpenAI我们确实遇到过诸如整个区域宕机、光缆被挖断导致跨区域延迟骤增等极端情况。有时问题甚至源于我们自己的操作失误。但无论原因如何系统都必须能扛得住。正因如此我们必须从底层基础设施到上层应用全栈考虑容错能力确保流处理作业在任何异常情况下都能持续稳定运行。回顾一下我们前面提到的关键挑战Flink 集群可能失效 → 我们需要能在多个 Kubernetes 集群间自由迁移作业存储可能丢失 → 我们依赖异地复制的存储并支持主备切换Kafka 集群可能中断 → 我们通过高可用组和代理层确保任一 Kafka 集群都不是单点故障无论是在消费端还是生产端。当然脱离实际场景谈架构意义有限。接下来我们通过几个真实受益于这套设计的业务管道来看看这些能力是如何落地的。用例一实时 Embedding 生成我们有一类典型的管道用于为各类产品实时生成 Embedding。其逻辑非常直接接收输入数据调用模型服务RPC再将结果输出。这类任务之所以选择 Flink一方面是因为其 API 简洁易用但更关键的原因在于——我们需要将结果同步分发到多个下游区域而这些区域各自托管着对应的数据副本。在这个场景中数据的新鲜度远比“截至某个水印的完整视图”更重要。因此系统必须具备容忍单个 Kafka 集群故障的能力即使某个区域的集群宕机仍能继续消费其他活跃区域的数据流。这类管道通常不依赖水印也不需要对迟到数据做特殊处理我们只期望当故障集群恢复后积压的数据能自然流入并被正常处理——就像什么都没发生过一样。用例二传统 ML 特征计算另一个典型场景是传统机器学习特征的实时计算——毕竟一场不提 AI 的 OpenAI 技术分享多少有点说不过去。借助像开源项目 Chronon 这样的框架我们可以用声明式方式定义特征逻辑例如 “统计用户过去 1 小时内点击按钮的次数”然后由系统自动编译成 Flink 作业执行。这类管道同样遵循 OpenAI 内部广泛采用的 “一次计算到处分发”compute once, distribute everywhere 范式。原因很实际原始数据往往来自多个区域而下游应用可能部署在本地或需要在多个区域冗余存储同一份特征数据即便某些区域使用频率较低。特别值得注意的是输入数据本身也是跨区域分布的。这进一步强化了我们的架构要求Kafka 集群绝不能成为任一区域的单点故障——否则特征计算的完整性将直接受到威胁。07未来工作在结束本次分享之前我们想简要谈谈未来的演进方向。这一路走来我们踩过不少坑也向社区提交了一系列 issue 和 PR。其中不少集中在 PyFlink 上——比如相比 Java 版本仍存在的功能缺失或稳定性问题还有一些则涉及更细粒度的部署定制和云环境特有的挑战。但值得庆幸的是整个生态是开源的任何人都可以参与共建。虽然 PyFlink 的成熟度尚不及 Java但社区响应迅速、协作氛围良好。对我们而言它绝非“洪水猛兽”而是一个值得投入的方向——尤其当你的用户群体主要是 Python 工程师时让他们直接用熟悉的语言开发流处理作业远比说服他们转用 Scala 或 Java 来得高效。除了持续回馈开源社区我们也在思考如何提升平台自身的自动化能力。目前控制平面主要依赖部署系统调用 CLI 工具进行管理。未来我们希望构建一个统一的 Flink 应用管理平台能够智能决策诸如“这个作业该调度到哪个 Kubernetes 集群是基于负载、资源位置还是容灾策略”“何时自动扩缩容底层集群”“当某个集群异常时能否自动触发跨集群故障转移而不是半夜把工程师叫起来手动迁移”归根结底我们的目标是让平台真正“好用”。为此我们正在探索一些关键体验优化例如自助式 SQL 管道工程师打开一个 Notebook就能像写查询一样快速构建流处理逻辑完整的 PyFlink 功能支持确保异步 I/O、流式 Join、Python 3.12 兼容等能力尽快落地端到端可靠性提升包括零停机部署、动态连接器更新等。最终我们希望用户只需关注业务逻辑本身——无论是写一段 SQL 还是一个 Python 函数——而无需操心“作业怎么跑、状态怎么存、集群挂了怎么办”。平台应该默默扛下所有复杂性让开发者专注创造价值。以上就是我们今天的全部内容感谢大家的聆听现在进入问答环节欢迎提问。08QA 环节问Flink 应用程序的软件生命周期是怎样的在批处理或数据仓库场景中我们可以反复重跑全量数据、调整查询、验证结果直到输出正确为止。但在你们的 Flink 流处理架构下这个过程是如何实现的比如当我要上线一个包含新字段的新版本作业时是否需要重放 TB 级的历史数据答目前在 OpenAIPyFlink 作业默认启动时会从 Kafka 中最早的可用偏移量即保留窗口起点开始消费。我们为 Kafka 主题默认保留 7 天的数据因此大多数情况下可以通过重放这 7 天的数据来验证或更新作业逻辑。如果作业逻辑发生变更同时 Kafka 主题的 Schema 也发生了变化例如新增字段我们当前主要通过回填backfill 的方式支持数据重处理——即重新消费 Kafka 中的历史数据并应用新逻辑。不过目前我们的回填能力仅限于从 Kafka 本身读取尚不支持从数据湖等其他存储源进行重新消费。至于自动化程度当你部署新版本作业时系统还不会自动触发全量回放。是否重放、从哪里开始重放目前仍需用户手动配置。这确实是平台的一个待完善点。需要说明的是我们的 Flink 平台投入生产的时间并不长——大约从去年年底才开始规模化使用。因此在作业生命周期管理、自动化回填、Schema 演进支持等方面我们还有大量工作要做也欢迎社区和用户一起推动这些能力的落地。问你们向用户暴露的编写 Python 作业的接口是什么 你们是否集成了 Jupyter Notebook或者围绕 Jupyter Notebook 做了 CI/CD答 我们向用户暴露的接口与我们内部工程师开发 Python 项目和 Python 微服务的方式相同。他们不会去写一个 FastAPI 应用而是会使用 PyFlink API 编写一个 main.py。这是相当标准的 IDE——VS Code、IntelliJ——IDE 体验与编写微服务时完全相同只是使用的不是 FastAPI 框架而是 PyFlink 框架。因此你可以使用所有工程师在开发微服务时使用的 Python 库。人们测试或开发的一些方式通常是使用开发环境中的一些共享或可用的测试集群。所以你能够相当快速地进行推送——我认为只需几分钟就能运行一个针对测试环境的部署命令它就会带着你的本地代码在那里运行。问你们是否也提供某种能力对存储在数据湖仓中的数据进行重处理——比如用文件源或 Sink 替换 Kafka答 我们目前没有这个功能但这在你想处理更复杂的事情时基本上是必要的——比如如果你需要比 Kafka 中或你的保留期更多的历史数据。也许你出于各种原因对保留期做了相当激进的削减那么这就会变得更加具有挑战性——这基本上是必要的但我们目前还没有这样做。问你们提到的集群和处理之间的代理是开源的还是内部专有的答 它是内部的。它基本上是围绕标准 Java Kafka 客户端的一个常规脚手架包含了我们想要和需要的所有逻辑比如故障转移、断路器、身份验证、重试逻辑等。你不想为了添加一个新的 Kafka 集群或修复一个问题而去部署一百个服务——你只需部署一个代理。所以它实际上是一个轻量级的 gRPC 服务。补充一点生产者代理是内部的正如前文所提到的。但对于消费者代理我们实际上使用了 Uber 的 uForward 代理这是开源的。我们的队友在另一个演讲中介绍了我们如何利用消费者端代理来简化 OpenAI 的 Kafka 消费。问你们谈到的业务用例是假设性的还是真实的例如Embedding 生成是否真的在使用这个管道如果它们是真实的那么 Flink 替代了什么你们在早期技术中遇到了什么问题以至于需要使用 Flink答 这些用例大多是真实生产场景的简化版而且基本都属于全新构建的项目。我们并没有用 Flink Pipeline 去替换任何已有的系统而是当团队在解决新问题时往往会先尝试一些临时甚至“有点疯狂”的方案——比如在数据库里手动排队、写脚本轮询等。这时我们就会介入建议他们“不如试试用一个 Kafka 主题加一个 Flink 应用这样可能比手搓一套更简单、也更可靠。” 因此这些 Flink 应用通常服务于全新的功能或能力而非对旧系统的迁移。以 Embedding 实时生成为例在实际落地过程中我们就遇到了一个具体挑战PyFlink 目前缺乏对异步 I/O 的原生支持。为了解决这个问题我们不得不自行实现绕过方案。但与此同时我们也正积极与 Flink 社区合作推动将异步 I/O 能力正式集成到 PyFlink 中以便更好地支撑这类高并发、低延迟的典型流处理场景。问对于高可用性对于一个特定的主题你们是将主题存储在多个集群或区域中还是只在一个特定区域中答 是的每个主题的数据实际上会分布在多个区域的 Kafka 集群中。你可以把它理解为一种逻辑上的分片sharding生产时我们会根据随机策略或优先级规则将数据写入其中一个集群。如果某个集群宕机系统会自动尝试其他可用集群如果断路器已经触发甚至根本不会考虑那个故障节点。因此数据天然就是跨集群分布的。这意味着任何 Kafka 消费者——无论是否基于 Flink——都必须从多个区域同时读取数据才能获得完整的视图。 没错这正是我们构建生产者和消费者代理的核心原因把多集群拓扑这类基础设施复杂性完全封装起来对上层应用透明。用户只需像使用单个 Kafka 集群一样进行生产和消费无需关心底层到底有几个集群、哪个可用、如何路由。这些代理是独立服务吗 是的我们将其设计为独立的中间服务。这样做的好处显而易见如果重试逻辑、集群列表或故障转移策略分散在上百个业务服务里作为平台团队每次调整配置或修复问题都将是一场灾难。而通过集中式的代理服务我们可以快速迭代、统一治理所有客户端只需通过它通信即可——既降低了用户的心智负担也极大提升了平台的可维护性。问PyFlink 相比基于 Java/JVM 的 Flink 应用肯定有额外开销。你们有没有具体的性能数据能说明使用 Python 到底会带来多少资源损耗答 我们目前还没有进行正式的基准测试但从实际运行情况来看由于用户逻辑是在 Python 进程中执行的PyFlink 作业在 CPU 和内存资源消耗上确实明显高于纯 JVM 实现。正因如此对于真正大规模、高吞吐的作业我们提供了一种混合开发模式用 Python 编排作业拓扑比如定义 Source、Sink 和算子连接关系但将核心计算逻辑实现在 JVM 算子中。这样既能保留 Python 在开发效率和生态集成上的优势又能确保关键路径的性能和资源效率。事实上已经有多个团队在实践中采用了这种策略。当他们遇到作业性能瓶颈或内存不足OOM问题时第一反应往往是“能不能把这段计算密集型逻辑移到 Java 算子里”——而通常这样做并不复杂只需少量重构就能显著改善资源使用和稳定性。问 从 Kafka 的角度看你们如何应对流量高峰——比如 GPT 图像生成功能上线时的突发流量Kafka 是如何扩展以应对这类场景的答 实际上对我们而言最大的流量增长往往来自新功能或新用例的接入而非产品发布本身。虽然像 GPT 图像生成上线这样的事件确实会带来流量激增但这类情况通常比外界想象的更容易提前规划。在 OpenAI团队在设计阶段就会主动与我们沟通“我们打算做这个功能计划用 Kafka。” 这时我们会深入讨论关键问题消息量级是多少是否需要按用户或消息键保序数据保留周期多长吞吐和延迟要求如何基于这些信息我们就能提前做好容量评估、集群扩容和分区规划。正因为有这种前置协作机制大多数高流量场景都能被平稳承接实际运行中并没有出现“措手不及”的情况。回顾上篇《在 OpenAI 打造流处理平台超大规模实时计算的实践与思考》▼ 「FlinkHologres 搭建实时数仓」 ▼复制下方链接或者扫描二维码即可快速体验 “一体化的实时数仓联合解决方案”了解活动详情https://www.aliyun.com/solution/tech-solution/flink-hologres▼ 关注「Apache Flink」 ▼回复 FFA 2024 获取大会资料点击「阅读原文」跳转阿里云实时计算 Flink