《今日国外热门科技访谈播客》
AI for Data and Data for AI: The Dual Frontier of Modern Data Engineering with Pranav Motarwar
中文主题
AI 正在把数据工程拆分成两条并行主线：一条是“用 AI 改造数据工程流程”，另一条是“为 AI 和智能体构建可消费的数据基础设施”。
基本信息
- 节目：The Data Engineering Show
- 嘉宾：未标明
- 日期：2026-06-16
- 来源：Firebolt
- 链接：https://podcasts.fame.so/e/182r2668-ai-for-data-and-data-for-ai-the-dual-frontier-of-modern-data-engineering-pranav-motarwar
一句话总结
这期访谈最核心的判断是：数据工程并没有因为生成式 AI 而消失，反而被明确分化为“服务人类分析与产品”的传统管道，以及“服务模型与智能体”的新型管道，工程师需要同时理解两者。
Highlights
- 数据工程从过去主要面向“人类消费结果”，转向同时面向“人类/产品”和“AI 代理/模型”两类消费者，这是访谈中最明确的结构性变化。
- 传统数据栈不会被完全替代，ETL、数据建模、DBT、BI 仍然存在，但 AI 工具正在显著压缩开发周期，让工程师上移到产品定义、治理和业务驱动层。
- 新一代数据工程能力不再只限于结构化数据处理，还要理解 chunking、embedding、vector store 等面向模型消费的处理链路。
- 访谈把行业演化描述为从本地基础设施到云，再到 AI 驱动的双轨数据架构；这不是一次单点工具升级，而是职责边界、交付对象和工作方式同时变化。
- 在 AI 辅助编码和低代码平台推动下，过去需要 7 到 8 人协作维护的完整管道，正越来越趋向由更少的人端到端负责。
长文笔记
这期最值得记住的一点，不是“AI 会不会取代数据工程师”，而是数据工程的服务对象已经变了。转录里，受访者先回顾了自己早期入行时的典型工作：做数据建模、规划数据设计、搭建 ETL 管道、写脚本、完成“最后一公里交付”，而这些成果最终都是给人看的，或者给产品中的人类用户使用的。这是一种典型的传统数据工程世界观：数据从源头进入处理链路，经过清洗、建模、聚合，最后进入报表、分析系统或业务应用。真正的新变化不是这套流程消失，而是现在出现了第二类消费者——模型和智能体。于是同样是“做数据管道”，目标已经从“让人能看懂、能分析、能使用”，变成还要让 AI 能检索、能理解、能调用、能在运行时消费。
受访者把这种变化明确概括为两个方向：AI for Data 和 Data for AI。前者是“用 AI 改造数据工程本身”，也就是让 AI 帮忙写 DBT、生成 ETL、缩短开发和迭代周期；后者则是“为 AI 准备数据”，也就是搭建模型消费的数据流、存储和检索系统。从转录可见，他强调这两者都重要，不能只押注其中一个。这个判断很现实，因为在企业内部，传统分析需求并没有消失：人仍然需要 BI、产品团队仍需要指标、业务仍然依赖报表与监控；与此同时，新的智能体系统、推荐系统、实时决策系统也要求另一套数据基础设施。换句话说，企业不会因为上了 LLM 就不做报表，也不会因为保留报表系统就不用向量检索、embedding 或多模态输入处理。对工程师来说，真正的门槛从“你会不会搭管道”升级为“你知不知道不同消费者需要怎样的数据形态”。
访谈中的另一个重要判断，是传统数据栈并不会被一把推翻。受访者讲得很直接：DBT、ETL、数据建模这些步骤“还是会一直存在”。这句话其实是在反驳一种常见误读——很多人一听到 AI 进入开发流程，就会把它理解为旧工具要全部淘汰。但在他的叙述里，更准确的变化是：工具链还在，交付速度和职责重心变了。他举的例子是，原本可能要花一个月构建完整数据流的工作，如今被压缩到过去所需时间的约 30%。这并不自动意味着工作量消失，而是意味着工程师可以把精力从重复性的脚本与编排中抽离出来，转到更上游的环节，比如定义产品需求、思考数据治理、判断如何驱动业务收入。也就是说，AI 并没有取消数据工程的必要性，而是把“纯实现”部分压缩了，让“问题定义”和“端到端责任”变得更值钱。
这也解释了访谈中对岗位边界变化的讨论。主持人补充的观察是，工程师与产品经理之间的分工正在变得模糊，越来越多 PM 开始写代码，越来越多工程师承担产品责任。受访者则进一步把这种趋势落到数据工程场景：过去一条完整管道也许需要 7 到 8 位工程师协作维护，如今在 AI 辅助下，单个贡献者可以拥有更完整的链路。这不是简单的人力缩减叙事，而是工作组织方式改变了。尤其在生成式编码工具提高实现速度后，团队真正的瓶颈可能不再是“写不出代码”，而是需求对齐、设计评审、跨角色沟通。于是端到端 owner 模式会变得更重要：一个人既理解业务目标，又能借助 AI 快速实现，再把结果推向生产环境。对很多中高级数据工程师而言，这意味着职业价值开始更多体现在抽象能力、优先级判断和系统整合，而不只是熟练度。
在技术层面，这期访谈把“面向人类的数据管道”和“面向 AI 的数据管道”区分得很清楚。传统世界里，数据大多是结构化的，围绕表、字段、指标和固定模式组织；而面向智能体与模型的世界里，输入可以是非结构化文件、音频、视频，几乎任何东西都可能进入处理流程。受访者特别提到，今天的数据工程师除了 ETL、DBT 这些常规技能，还需要理解 chunking、embedding，以及如何规划和优化 vector store。这段话很关键，因为它说明所谓“Data for AI”不是给数据库换个新名字，而是引入完全不同的数据准备思路：你不只是要把数据清洗干净，还要让它适合被切块、索引、检索、嵌入，并最终支持 agent 的上下文获取与推理过程。对于只熟悉结构化仓库的从业者来说，这是能力版图的一次实质扩张。
访谈还带到一个更贴近产业的观察：分析型数据库的使用方式也在分化。主持人在对话里提到，过去大企业的分析栈大致类似，常见组合是数据摄取、转换、BI 分析；而现在，越来越多软件产品会直接构建在分析引擎之上，用于实时推荐、网络安全、广告决策等场景。这与受访者提到的低延迟、实时数据需求形成呼应：系统要求已经从“离线 + 在线”进一步推向“秒级甚至毫秒级”。这意味着数据工程不再只是“把昨天的数据整理好”，而是要进入实时特征、在线服务、快速反馈回路的产品现场。这里也能看出 Firebolt、BigQuery、Databricks、Snowflake 这类平台被频繁提及的背景：它们不只是分析工具，更是新一代数据产品的底层执行环境之一。
从职业发展角度看，这期访谈给出的建议相当明确：不要在“AI for Data”和“Data for AI”之间二选一，而要把它们都纳入未来几年的技能规划。这个结论并非空泛口号，而是直接建立在转录里的岗位变化叙述上：市场已经出现了围绕 AI data engineer 的新需求，职责同时包括“用 AI agent 加速自己的数据工程流程”和“为 agent 构建数据管道”。因此，所谓“保持竞争力”，不是简单学一个热门名词，而是理解市场对数据角色的预期已经双线展开。谁还把数据工程只理解为报表层 ETL，谁就可能错过新的增长面；但谁要是只会谈 RAG、向量库、embedding，却不了解企业级治理、结构化模型、业务指标，也同样不完整。
How eBPF Empowers Developers to Observe Inside the Linux Kernel in a Safe and Unintrusive Way
中文主题
eBPF 如何在不破坏 Linux 内核稳定性的前提下，给开发者提供深入内核的观测、网络处理与安全扩展能力。
基本信息
- 节目：The InfoQ Podcast
- 嘉宾：未标明
- 日期：2026-06-22
- 来源：InfoQ
- 链接：https://soundcloud.com/infoq-channel/how-ebpf-empowers-developers
一句话总结
这期访谈把 eBPF 讲成一个折中方案：它既绕开了传统内核上游合并和内核模块的高成本，又通过编译器限制与 verifier 审核机制，尽量保证注入内核的代码不会把运行中的系统搞崩。
Highlights
- eBPF 已经不再只是 Berkeley Packet Filter 的“扩展版”，而是演化成 Linux 内核中的一整套安全扩展技术空间。
- 传统修改 Linux 行为的两条路——提交上游内核补丁或编写内核模块——都很慢、很重，且风险高，这正是 eBPF 出现的背景。
- eBPF 的安全核心在于两层护栏：编译阶段的严格限制，以及加载前由 verifier 做的大量静态检查。
- verifier 会展开循环、检查越界访问、验证执行路径，目的是确保 eBPF 代码不会无限循环、阻塞系统或破坏内核稳定性。
- 访谈把 eBPF 的价值定义为“安全地进入内核内部”：既能做深度可观测性，也能支撑更主动的安全和网络能力，而无需侵入式修改内核。
长文笔记
这期节目最适合把 eBPF 放回 Linux 演进的背景里理解。受访者一开场就先澄清名称问题：eBPF 最初确实源于 BPF，也就是 Berkeley Packet Filter，早期主要用于网络包过滤，把过滤规则附着到运行中的系统上，让它看到流量并执行匹配逻辑。但他说得很清楚，如今“扩展”已经扩得太大，eBPF 实际上已经不再像最初的 BPF，所以社区甚至更倾向于把 eBPF 当成一个独立名字，而不是执着于全称。这一段很重要，因为很多人对 eBPF 的认识还停留在“高级抓包/过滤机制”，但访谈想表达的是：它已经成了 Linux 内核里一块更通用的、可编程的扩展能力空间，网络只是其中一个起点。
为什么这件事重要？因为 Linux 内核本身是一个极度强调稳定性的系统。受访者用很长一段解释了传统改动 Linux 行为为什么困难：如果你想让某个行为成为内核的一部分，通常要拿到 Linux 源码、定位修改位置、提交 patch，接着经过相关维护者多层评审，最后还得碰到 Linus 或其他关键维护者点头。即便代码真被接收，还要等 Ubuntu、Red Hat 等发行版采用相应内核版本，你才能在实际运行环境里得到这些变化。这个链条既漫长，也没有成功保证。换句话说，Linux 之所以可靠，恰恰因为它对“往内核里放东西”极度谨慎；但这也造成现实问题：当开发者需要更快地做观测、网络功能或安全扩展时，上游流程并不适合作为日常迭代机制。
于是第二条老路是内核模块。访谈对它的评价相当务实：内核模块确实允许你在现有内核旁边“挂入”自己的代码，通过 insmod 把模块装进内核，让执行路径走到你的逻辑时触发自定义行为。但它也带来两类典型问题。第一类是工程负担：模块通常需要针对特定内核版本编译，因为内核内部结构会变化，所以如果你想覆盖很多系统版本，就要维护大量构建与兼容性工作。第二类更关键，是稳定性与风险：如果模块代码写得不好，出现无限循环、阻塞执行或不允许的操作，它可能直接拖垮运行中的系统。也就是说，内核模块给了扩展能力，但它把相当大的风险一起交给了开发者和运维团队。
eBPF 试图解决的正是这个两难：既要比上游内核合并快得多，又不能像传统内核模块那样轻易把系统打崩。为此，访谈花了最多篇幅讲它的“护栏机制”。第一道护栏发生在编译期。受访者说，哪怕你只是写一段 eBPF 代码，编译器也会先根据严格规则检查代码形态，防止越界访问或其他可能破坏系统的危险模式。这意味着并不是“任何 C 风格逻辑都能塞进内核”，而是只有符合受限模型的代码才能被编译成可加载的 eBPF 程序。第二道、更严厉的护栏是 verifier。受访者用了一个很形象的比喻：把内核想成夜店，eBPF 代码想进门，verifier 就是门口的保安。你的代码即便已经编译通过，也不代表能进内核运行；verifier 还会在加载前做大量检查，决定是否放行。
从转录内容看，verifier 的职责非常重。它会展开循环，逐步检查执行路径，尝试在变量未正常填充的情况下推演是否会发生越界内存访问，并通过大量规则确保代码不会无限循环、不会永久阻塞、不会对运行系统造成破坏。这里的关键不是“它很安全”这句空话，而是它的安全性建立在一种强约束的程序模型之上：eBPF 不是让开发者随便把逻辑塞到内核，而是在一个受控的、可分析的执行框架里运行代码。也正因为 verifier 会从代码结构上预先排查问题，eBPF 才能在“内核可编程”与“系统稳定”之间找到一个工程上可接受的平衡点。
这期访谈虽然摘录里还没完全展开案例细节，但从 show notes 与开场内容可以看出，eBPF 被强调的价值不是单一功能，而是“在不侵入系统的前提下看见系统内部”。传统上，如果你想深入文件系统、驱动、网络栈甚至安全事件，往往需要侵入式 instrumentation、修改内核、部署高风险模块，或者接受可见性不足。eBPF 的吸引力在于：它让你可以把代码挂到运行中的内核关键点上，做观测、网络处理乃至前置安全控制，同时又尽量控制崩溃风险。这也是为什么 Isovalent 这类公司会围绕它构建云原生项目：因为在容器、Kubernetes、分布式网络和运行时安全场景里，既要深度洞察，又不能破坏宿主机稳定性，eBPF 正好提供了这种基础能力。
对工程团队而言，这期节目传递出的启发很明确：eBPF 的价值不应被简化成“性能更好的可观测性工具”，而要理解为 Linux 平台层新增了一种安全扩展机制。它改变的是开发者与内核交互的方式。过去，想在内核层做定制化能力，代价要么是极高的流程成本，要么是极高的运行风险；现在，eBPF 让这件事变成“可以更快试、但仍有严格边界”的工程实践。这种模式非常符合现代基础设施演化逻辑：不是所有能力都必须等内核主线接受，也不是所有扩展都该承担内核模块式风险，而是通过受验证的运行模型，在生产环境里获得更灵活的可编程性。
Foundation Models for Structured Data
中文主题
把企业里的结构化关系型数据视作图，并用类似 Transformer 的机制做预测建模，能否让表格数据也进入“基础模型”时代。
基本信息
- 节目：Software Engineering Daily
- 嘉宾：未标明
- 日期：2026-06-23
- 来源：Software Engineering Daily
- 链接：https://softwareengineeringdaily.com/2026/06/23/foundation-models-for-structured-data/?utm_source=rss&utm_medium=rss&utm_campaign=foundation-models-for-structured-data
一句话总结
这期访谈讨论的核心不是把 LLM 套到数据库上，而是指出企业预测建模长期依赖手工特征工程和任务专用模型，而关系型深度学习希望把数据库当作图来建模，进而形成能跨任务泛化的结构化数据基础模型。
Highlights
- 预测建模广泛存在于贷款审批、欺诈检测、客户流失预测、推荐系统、医疗再入院风险等场景，哪怕准确率只提升 1% 到 2%，也可能带来巨大的业务影响。
- 受访者认为，这一领域在过去 20 到 30 年里方法论并没有发生根本变化，核心仍是手工构造特征后再做任务级预测。
- 关系型深度学习的关键想法是把数据库里的行、列、表间关系视作图结构，而非孤立表格，从而直接在关系结构上学习。
- 学术界与工业界在 AI 研究上的分工被描述得很清楚：企业擅长扩规模与产品化，学术研究更适合探索尚未被验证、但可能开辟新路径的问题。
- 受访者强调，即便在学术环境里追求探索，也要不断追问“如果这个问题被解决，谁会在现实世界里受益”。
长文笔记
这期访谈从一个很容易被忽视、但其实极其重要的 AI 子领域切入：预测建模。受访者先把问题讲得很具体——当银行评估你是否会按时还贷，当医院判断病人出院后是否会再次入院，当金融机构估算一笔交易是否欺诈，当平台预测一个用户是否会流失、是否会点击某个商品、是否可能购买某个产品，本质上都在做预测建模。这些任务有一个共同点：它们并不是像聊天机器人那样生成文本，而是在已有历史数据基础上，对未来一个尚未知晓的结果做估计。也正因此，这类系统长期是企业生产系统里非常核心、但公众关注度不如大模型高的一层能力。受访者特别强调，这类模型哪怕只提升 1% 到 2% 的准确率，也可能带来非常大的业务影响，这说明它的价值往往不是炫目的演示效果，而是悄悄发生在风险控制、利润优化和决策自动化里。
访谈中一个非常强的判断是：这个领域在过去 20 到 30 年里，底层工作方式并没有根本改变。虽然机器学习、统计学习和数据科学一直在发展，但很多企业预测系统仍建立在同一套路上：先把一个对象表示成一组特征，再让模型基于这些特征输出预测。受访者拿推荐系统举例讲得很清楚：你先为用户构造一个 profile，比如注册时间、最近登录时间、最近看过哪些商品、这些商品属于哪些类别；再为商品构造一个 profile；然后学习一个函数，输入“用户特征 + 商品特征”，输出“购买概率”。这当然是有效的，也是工业界一直在做的，但问题是，它极度依赖人工定义和工程化拼接特征。换言之，真正昂贵的部分不只在训练模型，更在于你如何从数据库里组织出适合建模的表示。
这也正是“structured data foundation models”想切入的缝隙。根据转录与简介，这条路线背后的想法是：企业里的结构化数据并不只是平铺的表格，而是由行、列、主外键关系、跨表链接构成的关系系统。把它看成图，比把它看成一张孤立表更贴近真实结构。于是，关系型深度学习试图把数据库转换成图上的学习问题，再把类似 Transformer 的注意力机制推广到这种关系结构之上。这里的关键，不是简单地把表数据喂给通用大模型，而是承认结构化企业数据是一种独特模态，需要属于自己的网络结构。受访者把这点说得很明确：自然语言处理和计算机视觉已经经历了神经网络革命，但支撑企业预测建模的表格数据层，还在大量依赖手工特征工程与任务专用模型，因此它并没有真正完成同等程度的方法论更新。
这期对“学术研究与产业研究如何分工”的讨论也很有意思，因为它解释了为什么这类方向往往首先出现在大学与创业公司，而不是传统大厂产品线里。受访者说得很直接：学术界无法在规模上与前沿实验室竞争，也不擅长直接把产品推给客户；企业与创业公司则更适合把成果产品化、规模化。但学术研究有一个不同的风险结构：它可以真正探索，可以失败，不必被绩效评估和季度目标强行约束。因此，学术界更适合回答“还有哪些路没人走过”“有哪些方向产业界因为过于保守而暂时不会去试”。这个说法并不是在神化学术，而是在说明研究组织形态会影响问题选择。尤其在今天大模型竞赛高度依赖算力、数据和资本时，结构化数据这类“现实价值高、但没有那么吸睛”的方向，反而更适合由研究者去开新路，再由创业公司承接落地。
不过，受访者也没有把学术探索说成与现实脱节的纯理论活动。他强调，自己做研究时会不断追问：如果这个问题解决了，谁会在现实世界里受益？这句话对理解整期访谈非常关键，因为结构化数据基础模型并不是一个抽象概念游戏，它直接对应大量企业的核心系统。只要企业还在用数据库存用户、订单、交易、风控事件、医疗记录、内容消费行为，这些数据就天然是关系型的、结构化的、跨表连接的。也就是说，今天被大模型光芒遮蔽的“表格与数据库”并不是边缘问题，而是商业系统最中心的数据模态之一。如果这一层真的出现更强的通用学习范式，影响很可能比一个新的聊天应用更深，因为它会进入贷款、广告、推荐、风控、客户运营、医疗决策等具体流程。
从工程视角看，这期访谈还有一层潜台词：很多所谓“AI 落地”，其实仍然在围绕非结构化内容展开，比如文本、图像、语音；但企业真正沉淀最深、最可操作、最有业务约束的数据，常常还是数据库里的结构化关系数据。因此，未来 AI 系统未必只有一条“更大的通用模型”路径，也可能出现按数据模态分化的基础模型生态。受访者提出结构化数据需要“模态专属架构”，就是在反对一种过于简单的统一论：并非所有数据都应该被同一种网络和同一种输入接口处理。对开发者和产品团队而言，这意味着如果你的核心问题属于预测、风险、推荐或运营决策，那么真正值得关注的，未必是把聊天模型塞进流程，而可能是重新思考数据库、图结构、特征工程与模型架构之间的关系。