摘要：来自法国的Pathway 和我们之前介绍的Bytewax的架构设计非常类似，基于Rust 引擎，并由differential Dataflow驱动，来实现：真正统一的批处理与流处理——在两种模式下使用完全相同的代码。
来自法国的Pathway 和我们之前介绍的Bytewax的架构设计非常类似，基于 Rust 引擎，并由 differential Dataflow 驱动，来实现：真正统一的批处理与流处理——在两种模式下使用完全相同的代码。
2019 年，Zuzanna Stamirowska在法国国家科学研究中心（CNRS）攻读博士，研究海运贸易预测时，发现了一个关键的基础设施缺口：当时没有任何软件能够高效处理 AI 系统所需的流数据，而物流行业对此迫切需要。于是，在 2020 年，NavAlgo SAS（对外称为 Pathway） 成立，汇聚了一批顶尖的技术人才，包括 Jan Chorowski（曾与诺贝尔奖得主 Geoff Hinton 合著论文）、Adrian Kosowski（23 岁即获 Inria 终身职位）等知名学者。
2022 年，公司获得 420 万欧元的 Pre-Seed 融资，早期投资人中包括 Łukasz Kaiser（如果你发现这个字母L上有些脏东西，不要试图擦拭你的显示器）——Transformer 架构的共同发明人，也是 ChatGPT 中“T”的来源。这并非偶然：Kaiser 认识到，实时、自适应的 AI 系统需要与传统批处理工具完全不同的数据处理基础设施。
Pathway 于 2023 年 1 月 16 日 在 PyPI 上发布 v0.0.x 公测版，定位为通用型流处理框架。首年重点在于构建核心能力与获取企业客户，并成功赢得包括北约（NATO）（2023 年 10 月宣布）、法国邮政（La Poste）、法国达飞海运集团（CMA CGM） 等重量级客户。值得注意的是，这些并非试点项目：例如法国邮政在 2024 巴黎奥运会期间，使用 Pathway 管理物流，处理 1600 万条 IoT 数据点和每日 400+ 次卡车调度，并将成本降低了 50%。
随着 2024 年 RAG 与大语言模型（LLM）应用的爆发，Pathway 抓住了时机。2024 年 3 月，Pathway 发布 Adaptive RAG 技术，在保持准确率的同时，将 LLM Token 成本降低了 4 倍。这使 Pathway 在企业级 AI 浪潮中占据了理想位置。
2024 年 8 月，Pathway 加入 Linux 基金会的企业级 AI 开放平台（OPEA），与 Intel、HuggingFace 等巨头并肩。随后在 2024 年 11 月，Pathway 完成 1000 万美元种子轮融资（由 TQ Ventures 领投），并将总部从巴黎迁至美国Menlo Park，同时保留欧洲的研发团队。
产品主要版本的时间线如下：
2023 年 1 月：公开发布 v0.0.x，具备核心流处理功能2023 年全年：框架稳定性提升、连接器生态扩展、企业级客户落地2024 年 3 月：Adaptive RAG 发布，入选 Intel Ignite Europe2024 年 8 月：加入 Linux Foundation OPEA2024 年 10 月：支持 YAML 配置模板，实现零代码 LLM 流水线搭建（v0.22-0.23）2024 年 11 月：获 1000 万美元种子轮融资，总部迁至硅谷2024 年 12 月：支持 Confluent Schema Registry，新增 MQTT 连接器（v0.24）2025 年 1 月：新增 QuestDB 连接器、支持 Model Context Protocol 服务器（v0.25）2025 年内规划：性能优化、反压控制、基于时间的数据管理算子（v0.26）Pathway 主仓库在 GitHub 上已获得 约 4.4 万颗星，但社区讨论活跃度相对星数仍偏低。公司目前已在欧洲与北美拥有 25+ 名团队成员，客户群体不断扩大，涵盖 国防、物流、金融、科技等多个行业。
4.4 万颗星是一个相当了不起的数字，已经面世15年的Apache Spark只有4.2万，而几乎同一时期出生的Apache Flink只有2.5万，虽然Github的点赞不是衡量开源项目的唯一标准，Pathway的这个数据真的让人瞋目。我觉得这和它紧靠AI大模型的市场和产品思路密切相关。简单说，Pathway成功就是坐在了风口上，起飞了。
Pathway的LLM 流水线与基于实时数据的 RAG 应用，是 Pathway 增长最快的应用场景。
该框架提供专门的 LLM 工具包（xpack），包含解析器、嵌入器、分割器，以及最关键的——内置实时向量索引，无需依赖独立的向量数据库。
Pathway 团队研发的 Adaptive RAG 技术通过动态调整文档数量，在保持准确率的同时，将 Token 成本降低了 4 倍。
在企业级 RAG 场景中，Pathway 可直接连接 sharepoint、Google Drive 或 S3 存储，系统能自动检测文档变更并实时重新索引，确保 AI 助手始终使用最新信息，而非过时的快照。
同时，Pathway 还提供开箱即用的模板，支持多种 RAG 场景：
多模态 RAG 与 GPT-4o：从 PDF 中提取表格和图表本地私有 RAG：兼容 Mistral、Ollama 等模型金融文档分析：通过 unstructured-to-SQL 流水线实现结构化处理Pathway是流数据处理紧密拥抱AI的一个成功案例。从这个角度来看它就像是LlamaIndex的流式版本。
Pathway 的核心是基于表的声明式 API， 围绕三个概念：
Schema：定义数据结构，具备完整类型安全，支持 Python 类型注解或专门的 Schema 类。Table：表示不可变的数据集合，类似 pandas DataFrame，但为流处理而设计。Transformation：通过已有表创建新表，自动处理增量更新。这种设计对于熟悉 pandas 或 SQL 的 Python 开发者来说非常自然。
import pathway as pwclass InputSchema(pw.Schema):value: intcategory: str# 从流数据源读取input_table = pw.io.csv.read('./data/', schema=InputSchema, mode="streaming")# 使用熟悉的操作进行转换filtered = input_table.filter(input_table.value > 0)result = filtered.groupby(filtered.category).reduce(filtered.category,sum_value=pw.reducers.sum(filtered.value),count=pw.reducers.count)# 写入输出pw.io.jsonlines.write(result, "output.jsonl")# 执行计算pw.run只需将 mode="streaming" 改为 mode="static"，同一段代码即可运行批处理。这种统一范式消除了 Lambda 架构的复杂性，无需为开发与生产维护两套代码。
高级有状态操作
Pathway 在传统上需要复杂手写代码的场景表现出色：
时间关联（ASOF Join）：根据时间接近度匹配记录：result = t1.asof_join_left(t2,t1.event_time,t2.event_time,t1.key == t2.key,defaults={t2.value: -1}).select(left_value=t1.value,right_value=t2.value,time_diff=t1.event_time - t2.event_time)窗口聚合：支持滚动窗口、滑动窗口、会话窗口，语法简洁。去重操作：deduplicate 支持自定义函数，实现复杂逻辑。UDF（用户自定义函数）：无缝集成任意 Python 库，包括 pandas、NumPy、scikit-learn、PyTorch、TensorFlow。LLM 与 RAG 能力
Pathway 提供 生产级 LLM 工具包（xpack）：
from pathway.xpacks.llm import llms, embeddersfrom pathway.xpacks.llm.document_store import DocumentStore# 配置向量嵌入与文档存储embedder = embedders.OPENAIEmbedder(api_key=os.environ["OPENAI_API_KEY"])doc_store = DocumentStore# 结合检索queries_with_docs = queries.select(docs=doc_store.retrieve(pw.this.query, k=3))# 生成答案model = llms.OpenAIChat(model="gpt-4o-mini", api_key=os.environ["OPENAI_API_KEY"])result = queries.select(answer=model(pw.this.prompt))支持 OpenAI、Anthropic、Mistral、Ollama 等多家 LLM 提供商，接口统一。内置文档解析器、分割器、实时向量索引，免去了外部向量数据库依赖。
开发体验优势
交互式 Notebook 支持：可通过 pw.debug.table_from_markdown 和 compute_and_print 在静态数据上测试逻辑，再部署到流环境。内置监控面板：跟踪消息数、每个连接器的延迟，日志聚合，兼容 OpenTelemetry。类型提示：支持 IDE 自动补全和 mypy 静态检查。source https://pathway.com/developers/templates/rag/unstructured-to-structured
上图是一个Pathway RAG Pipeline的例子。
Pathway支持类似Benthos（Redpanda Connect）的声明式pipeline配置，主要通过YAML配置文件实现，让你无需编写Python代码就能搭建复杂的数据处理流程。
根据文档，Pathway的app.yaml配置文件采用声明式设计，涵盖完整的RAG pipeline：
# 完整的声明式配置示例sources:- kind: filesystempath: /dataformat: jsonlmode: streaming- kind: gdrivecredentials: service-account.jsonfolder_id: xxxrefresh_interval: 60- kind: sharepoint # 企业版功能site_url: https://company.sharepoint.com- kind: s3bucket: my-bucket- kind: kafkatopic: documentsllm:provider: openaimodel: gpt-3.5-turbotemperature: 0.0api_key: ${OPENAI_API_KEY}embeddings:provider: openaimodel: text-embedding-ada-002dimensions: 1536parsing:chunk_size: 400chunk_overlap: 50splitter: token_countadaptive_rag:n_starting_documents: 2factor: 2max_iterations: 5strict_prompt: truecaching:backend: diskpath: /cacheserver:host: 0.0.0.0port: 8080Pathway性能优秀，准测试结果十分突出：在 PageRank 流式计算 中比 Flink 快 30–90 倍，在 回填计算（backfilling） 中快 20 倍，LiveJournal PageRank（480 万节点、6900 万边）是真实复杂图处理场景。在 Flink 会崩溃或超时的情况下，Pathway 可在几分钟内完成，展现出在混合工作负载下的实用优势。尤其在 迭代计算场景（如图算法）中，Pathway 的 差分计算引擎（Differential Computation） 发挥了最大威力。虽然简单的 ETL 工作负载差距不如显著，但企业采用流处理框架的核心价值本就不在简单场景。
开发者生产力具备优势，Python 开发者可轻松上手流处理，相比之下，Flink 需要：安装 Java → 配置集群 → 学习 JobManager/TaskManager 架构 → 编写部署描述 → 跨 JVM 调试。
对于熟悉 Python 而不熟悉 Java 的数据科学家与机器学习工程师，Pathway 的生产力优势极为明显。其统一批流模型可以在本地用批数据测试，生产中仅需切换到流模式无需维护两套代码，也避免 Lambda 架构的同步复杂度。
此外，Pathway 还支持 Notebook 交互式开发流任务，可在静态数据上原型设计与可视化结果，然后一键切换为流模式。相比 Flink 的“编译-提交-祈祷” 循环或 Spark 的微批延迟，这种体验更具现代感。
Pathway 在 RAG（检索增强生成） 应用方面具备行业领先的整合能力：
内置 向量索引，无需外部向量数据库；实时文档同步（SharePoint、Google Drive）在文档更新数秒内自动重建索引；Adaptive RAG 技术 可在保持准确率的同时将 Token 成本降低 4 倍；提供多种模板：多模态 RAG、本地私有 RAG、企业级 RAG，帮助团队从数月缩短到数日实现生产部署。我们也看看它的局限与风险
文档与监控：
核心文档良好，但高级主题（如性能调优、分布式调试、迁移指南）深度不足；运维手册尚不如 Flink 或 Spark 十年积累的全面；监控工具不如 Flink 的 metrics 与 debug 工具成熟；最大可支撑规模尚未明示，目前案例多为中等规模部署。许可限制：
Pathway 采用 BSL 1.1 商业源代码许可（非真正开源），4 年后才转为 Apache 2.0；若用于“数据流处理服务”或商业转售需购买授权；某些功能（如 SharePoint 连接器、高级监控、Exactly-once 保证）仅限企业版；对强调完全开源合规的团队，这可能是障碍。内存架构限制：
全内存管道虽然高性能，但受制于内存容量；大窗口或无界聚合状态可能耗尽内存；文档未详细说明内存溢出或状态落盘机制。基准测试偏差：
多数基准测试由官方发布，独立验证有限；主要聚焦有利于差分计算的任务（如 PageRank、WordCount）；缺乏通用负载（CEP、ETL）的公开对比；尚无第三方基准套件（如 Yahoo Benchmark，Nexmark）的验证。Pathway和我之前给大家介绍的Bytewax无论从技术架构还是市场方向都十分接近
都是Python + Rust混合架构：都是基于Rust和Timely Dataflow都是流处理框架：两者都定位于实时数据流处理，对标Apache Flink/Spark Streaming都提供dataflow编程模型：DAG结构，stateful/stateless operators都支持Docker/K8s部署：云原生设计可是为什么两者的发展天差地别呢？我想，大概有以下的原因
市场定位与时机Pathway抓住了AI浪潮："Live AI"概念完美契合2024-2025的GenAI企业落地需求——LLM需要实时更新的私有数据RAG（检索增强生成）成为企业AI的杀手级应用，Pathway提供ready-to-run的RAG模板Adaptive RAG技术实现4x成本降低，直击企业痛点Bytewax困在传统流处理市场：流处理是成熟市场，已有Kafka Streams、Flink、Spark等巨头定位为"Python版Flink"缺乏差异化价值主张2022年推出时AI还未爆发，错过最佳时间窗口产品策略Pathway：垂直深入AI场景：提供开箱即用的LLM App模板：Multimodal RAG、Adaptive RAG、Unstructured-to-SQL等原生集成Kafka、S3、SharePoint、Google Drive、PostgreSQL等300+数据源从框架到完整解决方案的转变Bytewax：通用流处理工具：提供基础operators（map、filter、join、window）需要开发者自己组装完整应用学习曲线与Flink类似，但生态不如Flink成熟客户获取与GTM策略Pathway：企业优先+开发者社区双轮驱动：NATO、Intel等标杆客户带来强大背书AWS和Azure Marketplace原生可用Gartner认可提升企业信任度主动搬到硅谷接近决策者和资本Bytewax：开发者社区为主，企业牵引不足：缺少公开案例研究没有明确的企业销售策略GitHub Fund投资更侧重开源影响力而非商业化技术叙事与融资能力Pathway的故事更性感："Live AI systems that think and learn in real-time as humans do"CEO预测"Live AI将成为2025年关键趋势"联合创始人包括诺贝尔奖得主Geoff Hinton的合作者Jan ChorowskiBytewax的故事相对平淡："Python stream processing"——缺乏独特性没有与当前AI热潮建立强关联创始人Zander Matheson背景扎实（GitHub、Heroku），但缺少学术明星效应生态系统整合Pathway构建了完整的AI工具链：不仅是数据处理，还包括向量索引、LLM编排、Prompt工程与OpenAI、Anthropic API无缝集成，支持Ollama本地模型成为"AI基础设施"而非"数据管道"Bytewax仍是孤立的数据工具：需要配合其他工具（向量数据库、LLM框架）缺少端到端解决方案Bytewax的沉寂不是技术失败，而是战略定位失误。在AI革命的大背景下：
做通用工具的不如做垂直方案做基础设施不如做完整产品开源社区优先不如商业化优先Pathway的成功证明：在技术创业中，选对赛道比做对技术更重要。当所有人都在问"如何让LLM使用最新数据"时，Pathway恰好有答案；而当人们问"如何处理流数据"时，Flink已经给出了答案，Bytewax只是又一个选择。尽管技术栈相似，但Pathway已经不在"流处理框架"这个类别竞争，而是在更高维度的"AI基础设施"赛道上快速奔跑。
来源：闻数起舞
