AI落地的瓶颈不是智能不够是上下文不够数据给不到Agent｜Databricks访谈

记录AI变革的 2026-07-13 14:43

记录AI变革的 2026/07/13 14:43

邦小白快读

全文速览

本文核心分享了AI巨头Databricks对当前AI落地的核心判断，以及其13年发展的核心逻辑和产品开发思路，干货如下：

1.核心判断：当前AI落地的瓶颈不是模型智能不够，而是上下文不够，企业内部的数据无法到达智能体手中，只要把数据放到正确的位置，叠加智能体就能产生价值。

2.Databricks的发展逻辑：13年来一直解决同一个问题，就是数据不在它该在的位置，从Spark解决计算速度问题，到Delta Lake解决数据可靠性问题，Lakehouse合并数据湖和数据仓库，现在针对智能体时代推出Omnigent和LTAP两大新产品。

3.产品开发实操思路：不用先写大量设计文档，鼓励工程师先做原型验证，优先满足一两个真实客户的需求，跑通极端场景后再扩展，风险更低。

本文分享了To B科技品牌Databricks的发展经验，以及AI落地的产业趋势，对品牌研发、战略都有参考价值，内容总结如下：

1.品牌发展案例参考：Databricks从学术项目出发，坚持“让数据到位”的核心定位，13年四次迭代，当前年化收入达到69亿美元，同比增长80%，估值1340亿美元，覆盖70%的财富500强企业，核心竞争力是坚持开放生态，从真实需求出发。

2.产业发展趋势：当前企业级AI智能体落地的核心痛点是数据不通、上下文缺失，品牌要落地AI降本增效，核心要优先解决企业内部数据连通的问题，才能发挥智能体的价值。

3.产品研发参考：优先打磨一两个真实客户的需求，再逐步扩展，比盲目做通用产品的风险更低，更容易做出被市场接受的产品。

本文梳理了智能体时代AI基础设施领域的新动向，能帮助从业者找准增长机会，规避风险，内容总结如下：

1.当前市场机会：企业智能体落地还存在大量基础设施缺口，现有AI工具存在上下文不共享、跨工具协作难、安全机制粗糙、成本不可控、智能体无法获取业务数据库实时数据等痛点，市场需求明确，存在大量创业和增长机会。

2.可参考的商业模式和做法：走开源开放生态路线，依托社区完善各类适配，比封闭模式更有长期竞争力；产品开发先从真实客户需求切入，小步迭代验证再扩张，能有效降低创业和业务拓展风险。

3.风险提示：做AI基础设施要避免重走传统HTAP的老路，不要强行在查询引擎层合并事务处理和分析处理，避免出现性能互相拖累、丢失原有生态的问题。

本文能给工厂推进数字化转型、落地AI应用提供不少启示，也点明了新的商业机会，内容总结如下：

1.数字化落地的核心逻辑：很多工厂AI落地难，核心瓶颈不是AI智能不够，而是数据不到位，生产数据、业务数据分散在多个系统中，智能应用拿不到完整的上下文数据，这才是落地难的核心原因。

2.商业机会：工厂智能化转型过程中，数据整合基础设施存在大量缺口，帮助工厂打通不同系统的数据，把数据放到智能应用需要的位置，是非常明确的商业机会。

3.落地启示：推进数字化和AI不用一开始就做宏大的全流程方案，可以先从一两个真实场景切入，跑通核心需求后再逐步推广，能有效降低试错成本；还可以利用工厂闲置算力完成数据转换，不需要额外投入过多成本。

本文梳理了当前企业AI落地的核心痛点和新的解决方案方向，对各类企业服务、AI服务商有很高的参考价值，内容总结如下：

1.行业发展趋势：智能体已经成为企业AI落地的核心方向，但是围绕智能体的配套基础设施严重缺失，统一管理、安全管控、数据连通是当前最核心的需求缺口，市场空间很大。

2.核心客户痛点：企业现有多AI智能体体系存在上下文不互通、跨团队协作难、安全机制只有静态开关过于粗糙、成本不可控、智能体无法获取事务数据库实时业务数据等痛点，传统数据同步管道可靠性差，经常出故障。

3.可参考的解决方案：可以参考Databricks的思路，做统一的智能体管理层提供统一接口，对接不同模型，用动态上下文策略解决安全和成本管控问题，用存储层统一的架构解决数据连通问题，省去复杂的同步管道。

本文梳理了数据智能平台发展的新方向和可参考的运营开发做法，能帮助平台商找准方向规避风险，内容总结如下：

1.当前企业客户对数据智能平台的核心需求：客户优先选择开放数据格式的平台，厌恶被专有格式锁定，开放生态已经成为行业共识，同时客户需要统一数据存储、支持智能体统一管理和动态安全管控。

2.平台产品开发和运营可参考做法：产品迭代坚持小步快跑，允许工程师先做原型验证再正式立项，优先满足核心真实客户的需求，跑通极端场景后再扩展功能；走开源开放路线，依托社区完善生态适配，降低自身开发成本，扩大生态覆盖面。

3.需要规避的风险：避免陷入第二系统综合征，不要盲目追求大而全的新系统，不要强行合并不同计算引擎的功能，避免出现性能互相拖累的问题。

本文披露了Databricks的发展历程和AI落地的最新产业动向，对AI基础设施、智能体领域的研究者有很高的研究价值，内容总结如下：

1.产业新动向：当前AI落地的核心矛盾已经从模型能力不足转向数据供给不足、上下文不足，智能体基础设施成为新的核心赛道，统一智能体管理、数据架构革新是当前产业界核心创新方向。

2.新商业模式和开发模式：开放数据格式已经成为产业共识，从上游数据处理切入的开放生态模式，比从下游切入的专有格式模式更有长期竞争力；开源开放的生态模式、原型先行先满足真实客户需求的开发模式，都已经被验证可行。

3.新的技术研究方向：智能体动态安全管控、亚100毫秒级实时分析查询、存储层统一的事务分析处理架构等，都诞生了新的技术方案，为后续研究提供了新的方向。

返回默认

声明：快读内容全程由AI生成，请注意甄别信息。如您发现问题，请发送邮件至 run@ebrun.com 。

我是品牌商卖家工厂服务商平台商研究者帮我再读一遍。

Quick Summary

This article shares AI giant Databricks' core outlooks on current AI adoption, as well as the core logic behind its 13-year growth and product development philosophy. Key takeaways are as follows:

1. Core outlook: The biggest bottleneck for current AI adoption is not insufficient model capability, but a lack of contextual data—enterprise internal data is not accessible to AI agents. As long as data is placed in the right location and paired with AI agents, it will generate tangible value.

2. Growth logic: Databricks has focused on solving the same problem for 13 years: data not residing where it should. Starting with Spark to accelerate computing, followed by Delta Lake to improve data reliability, then the Lakehouse architecture that unifies data lakes and data warehouses, the company has now launched two new products, Omnigent and LTAP, for the agent era.

3. Product development philosophy: Instead of starting with extensive design documents, engineers are encouraged to build prototypes for validation first, prioritize the needs of one or two real customers, test and validate the product in extreme scenarios before scaling, which reduces development risk.

This article shares B2B tech brand Databricks' growth experience and industry trends in AI adoption, offering valuable insights for brand R&D and strategy. Key takeaways are as follows:

1. Brand development case study: Starting from an academic project, Databricks has stuck to its core positioning of "getting data where it needs to be" and completed four iterations over 13 years. It currently boasts $6.9 billion in annualized revenue (80% year-over-year growth), a $134 billion valuation, and serves 70% of Fortune 500 companies. Its core competitive advantages are its commitment to open ecosystems and starting from real customer demand.

2. Industry trend: The core pain point for enterprise AI agent adoption today is disconnected data and missing contextual data. For brands looking to leverage AI for cost reduction and efficiency gains, the priority is to solve internal data connectivity first, to unlock the full value of AI agents.

3. Product R&D insights: Prioritizing refinement for one or two real customer needs before gradual scaling carries lower risk than building a generic product blindly, and makes it more likely to deliver a product the market will accept.

This article outlines new developments in AI infrastructure for the agent era, helping industry players identify growth opportunities and mitigate risks. Key takeaways are as follows:

1. Current market opportunities: There are still massive infrastructure gaps for enterprise AI agent adoption. Existing AI tools face pain points including non-shared context, difficult cross-tool collaboration, crude security mechanisms, uncontrollable costs, and inability of agents to access real-time data from business databases. With clear market demand, there are abundant opportunities for entrepreneurship and growth.

2. Reference business models and practices: An open-source, open ecosystem route that leverages community support for compatibility improvements delivers stronger long-term competitiveness than a closed model. Starting product development from real customer needs and iterating on a small scale before expansion can effectively reduce risks for entrepreneurship and business expansion.

3. Risk warning: AI infrastructure providers should avoid repeating the mistakes of traditional HTAP, which attempted to merge transaction processing and analytical processing at the query engine level, leading to mutual performance degradation and the loss of the existing ecosystem.

This article offers valuable insights for factories advancing digital transformation and AI adoption, and also points out new business opportunities. Key takeaways are as follows:

1. Core logic for digital adoption: For many factories, the core bottleneck for successful AI adoption is not insufficient AI capability, but inaccessible data. Production and business data are scattered across multiple systems, leaving AI applications unable to access complete contextual data—this is the root cause of difficult AI implementation.

2. Business opportunities: There are massive gaps in data integration infrastructure during factories' intelligent transformation. Helping factories connect data across different systems and place data where AI applications need it is a clear and high-potential business opportunity.

3. Implementation insights: Factories do not need to build a grand full-process solution from the start when rolling out digitalization and AI. Instead, they can start with one or two real scenarios, validate core requirements, and expand gradually—this effectively reduces trial-and-error costs. Factories can also use idle computing power for data conversion, avoiding large upfront additional investments.

This article outlines the core pain points and new solution directions for enterprise AI adoption today, offering high reference value for all types of enterprise service and AI service providers. Key takeaways are as follows:

1. Industry development trends: AI agents have become the core direction for enterprise AI adoption, but supporting infrastructure for agents is severely lacking. Unified management, security control, and data connectivity are the most pressing unmet needs, representing huge market potential.

2. Core customer pain points: Existing multi-agent systems at enterprises suffer from disconnected context, difficult cross-team collaboration, overly crude static-only security mechanisms, uncontrollable costs, and inability of agents to access real-time business data from transaction databases. Traditional data synchronization pipelines are unreliable and prone to failure.

3. Reference solutions: Service providers can follow Databricks' approach: build a unified agent management layer with standardized APIs that connect to different models, adopt dynamic context strategies to address security and cost control needs, and leverage a unified storage layer architecture to resolve data connectivity issues, eliminating the need for complex synchronization pipelines.

This article outlines the new direction for data intelligence platform development and reference practices for operation and product development, helping platform players identify the right direction and mitigate risks. Key takeaways are as follows:

1. Core demands from enterprise customers for data intelligence platforms: Customers prioritize platforms with open data formats and strongly dislike vendor lock-in via proprietary formats. An open ecosystem has become industry consensus. At the same time, customers require unified data storage, as well as support for unified AI agent management and dynamic security control.

2. Reference practices for platform product development and operation: Adopt an iterative approach of small, fast steps, allow engineers to build prototypes for validation before formal project approval, prioritize the needs of core real customers, and expand functionality only after validating performance in extreme scenarios. Pursue an open-source, open ecosystem route, rely on the community to improve ecosystem compatibility, reduce in-house development costs, and expand ecosystem coverage.

3. Risks to avoid: Avoid falling into the "second system effect", do not blindly pursue a large, all-encompassing new system, do not forcefully merge functions from different computing engines, which would lead to mutual performance degradation.

This article discloses Databricks' growth trajectory and the latest industry developments in AI adoption, offering high research value for researchers focused on AI infrastructure and AI agents. Key takeaways are as follows:

1. New industry developments: The core contradiction of AI adoption has shifted from insufficient model capability to insufficient data supply and missing contextual data. AI agent infrastructure has become a new core track, and unified agent management and data architecture innovation are the core innovation directions in industry today.

2. New business and development models: Open data formats have become industry consensus. An open ecosystem model starting from upstream data processing delivers stronger long-term competitiveness than a proprietary format model starting from the downstream end. The open-source open ecosystem model, as well as the prototype-first development model that prioritizes real customer needs, have both been validated as viable approaches.

3. New technical research directions: New technical solutions have emerged in areas including dynamic security control for agents, sub-100-millisecond real-time analytical queries, and unified storage-layer transactional analytical processing architectures, opening up new directions for future research.

Disclaimer: The "Quick Summary" content is entirely generated by AI. Please exercise discretion when interpreting the information. For issues or corrections, please email run@ebrun.com .

I am a Brand Seller Factory Service Provider Marketplace Seller Researcher Read it again.

让数据到位，在上面放个智能体，魔法自然出现。

作者 | 智顶顶

来源 | 至顶科技

2009年，UC Berkeley计算机系的Soda Hall里，博士生Matei Zaharia在等一个机器学习任务跑完。这个任务应该几分钟结束，但在当时的标准框架MapReduce上要跑几个小时。原因他清楚：MapReduce每一步都要把中间结果写回硬盘，下一步再读出来，数据在磁盘和内存之间来回搬运，大部分时间花在了搬运上，不在计算上。数据不在它该在的地方。

Zaharia的解决方案是把数据留在内存里，让多个计算步骤直接在内存中接力，不再每步都落盘。这个想法后来变成了Apache Spark。2013年，Zaharia和另外六位Berkeley研究者创办了Databricks，把Spark从学术项目变成了商业产品。风险投资人Ben Horowitz听完演示后说，这个技术能支撑一家千亿美元的公司。他领投了1390万美元的A轮。

13年过去了，Databricks的年化收入在2026年6月达到69亿美元，同比增长80%，2025年12月Series L轮估值1340亿美元。服务超过2万家企业，覆盖70%的财富500强。但回头看这13年，Databricks做的其实是同一件事：每当技术的演进让数据需要出现在一个新的位置时，它就建一层基础设施让数据到位。从Spark到Delta Lake到Lakehouse，再到现在的Omnigent和LTAP，这个模式重复了四次。

2026年6月Data+ AI Summit上，CEO Ali Ghodsi在keynote里给出了一个判断：AI的瓶颈不是智能不够，是上下文不够。模型已经足够聪明，但企业里的数据到不了智能体手里。

这篇文章的素材来自Latent Space播客在Summit期间对Databricks两位联合创始人的深度对谈：CTO Matei Zaharia和首席架构师Reynold Xin。两人分别主导了这次Summit上最核心的两个发布：开源智能体管理平台Omnigent和数据库新架构LTAP。他们在对谈中回顾了Databricks的技术演进、当前判断和竞争策略。

从Spark到Lakehouse

回看Databricks的产品线，每一步解决的都是同一类问题：数据不在使用者需要它出现的地方。

Spark解决的是第一次"不到位"。2009年到2013年那几年，企业有了大量数据，但处理速度跟不上。MapReduce框架要求数据在每个计算步骤之间落盘再读取，计算在这头等着，数据在那头搬着，谁也快不起来。Spark把数据留在内存里，让计算直接在数据所在的地方发生。速度提升了几十倍。

Delta Lake解决的是第二次"不到位"。到了2017年前后，企业把越来越多的数据扔进了云端的数据湖，但数据湖没有事务保证：多个程序同时写入可能互相覆盖，写到一半断了就是脏数据，没有回滚能力。数据在那里，但不可靠，不能放心用。Delta Lake给数据湖加上了数据库级别的事务能力，让数据从"在那里"变成"可以信赖地在那里"。2019年在Spark+AI Summit上开源。

Lakehouse解决的是第三次"不到位"。企业的数据分散在两套系统里：数据湖存原始数据、跑机器学习，数据仓库存结构化数据、跑商业报表。同一份数据要维护两个副本，中间靠管道同步，管道一断就出问题。Lakehouse的思路是把数据湖和数据仓库合成一个系统：用开放格式存储，同时支持机器学习和SQL查询。数据只有一份，分析和训练都在同一个地方做。Matei在对谈中回顾说，Databricks每次只加一个能力：先加了存储，再加了SQL，再加了机器学习平台，每次做好再往前走。

到了2026年，"数据该在的地方"又变了。这一次，需要数据的不再只是人类分析师和机器学习流水线，还有智能体。智能体要读代码、查数据库、调用外部工具、自主决策。Ali Ghodsi在keynote上给出了四个关键词：Context（上下文）、Cost（成本）、Control（控制）、Choice（选择）。这四个词圈定了Databricks接下来要解决的问题空间。

智能体管理的基础设施还是空白

Reynold Xin讲了一个故事。有一周他从早到晚在用编码智能体，某天开车去看医生，把笔记本电脑连着手机热点放在副驾驶座上，遇到红灯就看屏幕，因为本地的工作进程不能断开。他说当时觉得"我们好像回到了编程的黑暗时代"。

这个场景暴露了一个错位：编码智能体带来的生产力提升是巨大的，但围绕智能体的基础设施几乎是空白。工程师同时开着四五个AI助手，在Claude Code、Codex、Gemini之间来回复制粘贴。每个助手有自己的窗口、自己的历史记录、自己的权限体系。换一个模型或工具，之前的工作上下文就丢了。队友无法接入你的session。安全团队看不到智能体在做什么。花了多少钱也没有全貌。

Databricks内部出现了五六个不同团队各自搭建的智能体框架，功能大同小异。工程师的反馈是：我做的东西对自己好用极了，但队友没法用，因为没有共享服务器。

这些AI助手，业界统一叫harness，意思是"把裸模型套上缰绳、变成能干活的智能体"的那套软件。Omnigent的思路是在所有harness之上再加一层统一管理，Databricks叫它meta-harness。

Matei说Omnigent的起点有两条独立线索。一条来自内部开发：Databricks有5000多名工程师，开发基础设施团队做了一个叫Isaac的工具，封装了Claude Code和Codex，但最厉害的工程师们不满足，开始自己搭多智能体工作流。另一条来自对外产品：Matei联合带领的研究团队在做数据科学智能体Genie，同时还有大量客户项目。这些项目全都撞上了相同的问题：每隔几个月就要换模型和harness，工作记录不能分享，缺少协作层。

一开始有人觉得把编码智能体和企业智能体放在同一个框架里有点怪，但Matei认为它们面对的基础设施问题完全相同。

Omnigent的设计核心是一套统一接口，叫Common API。不管底下跑的是Claude Code还是Codex，对上面来说都一个样：往里送消息或文件，出来的是文本流或工具调用，也可以随时取消当前任务。Matei说Omnigent不试图成为一个完整技术栈，你可以在它的服务端之上接自己的界面。

Reynold写了一份愿望清单给团队："不会关闭的云沙盒""能渲染Markdown文件""能SSH进去看日志"。他说自己以前还单独开Cursor，就为了渲染Markdown。团队几乎全部实现了。

Databricks选择在Apache 2.0下开源Omnigent，逻辑和当年开源Spark一样：如果这个层封闭，别人做一个开放版本，长远一定赢。Matei举了Spark当年的例子：让社区写连接器和库，Databricks不可能有时间给上千种数据库和文件格式写适配，但社区做了，所有人受益。Omnigent在2026年6月中旬开源，第一周就有约400个合并请求，Matei估计一半不是他的团队写的。有人加了Kubernetes运行支持，多家初创公司贡献了云沙盒接入。

安全不能只靠“允许”和“禁止”

Matei花了大量时间和内部开发者、安全团队、管理层以及客户交流，发现现有智能体安全机制太粗糙：只有"允许使用这个工具"或"禁止"两种选择。但实际场景远比二选一复杂。

他举了一个例子：智能体应该能读取机密文档吗？应该能从NPM安装新包吗？应该能向公司网站发布内容吗？如果你做的就是网站代码，当然应该允许发布。但如果一个智能体同时做了这三件事，它可能读了机密文档、被恶意指令劫持（业界叫prompt注入，指攻击者在文档里藏入指令让智能体执行），然后通过发布功能泄露数据。每一项单独看都合理，组合起来就是安全事故。

Omnigent的解决方案叫上下文策略，即contextual policies，系统持续追踪session状态。策略不再是"能不能推送到营销站点"这种静态开关，而是"如果这个session刚安装了一个发布不到一天的NPM包，或者读取了大量机密文档，那就不允许推送"。

因为策略引擎追踪状态，自然可以追踪花费。Matei说他亲身经历过让一个智能体去debug问题，结果它决定读大量日志文件，一个session花了500美元。现在可以设定规则："启动一个子智能体做这件事，预算上限5美元，超了必须找我批准。"这不只是CTO个人的焦虑。Matei说他和一些咨询公司聊过，它们有10万名员工在给客户写代码，如果每人每月多花1000美元在编码智能体上，公司层面就是一笔吓人的账单。

作为CTO，Matei说自己"特别偏执但时间特别少"。他不想坐在那里审批"你要执行这个20行bash脚本吗"，也不想因为装了个奇怪的NPM包上了新闻头条。Omnigent的目标是：尽可能安全，尽可能不烦人。

智能体拿不到数据库里的数据

管理和安全这一层到位之后，下一步是数据本身。智能体要干活，得拿到数据。这就回到了Databricks的老本行：数据基础设施。

Reynold先铺了一个背景。数据库世界分成两半。一半是OLTP，即事务处理数据库，比如Postgres、MySQL、Oracle，处理的是查找特定行、更新特定行这类操作。另一半是OLAP，即分析处理，要做的是"按门店算营收""预测未来销售"这类聚合计算。当数据量超过简单规模，在OLTP数据库上跑分析查询会把数据库压垮，所以需要把数据复制到分析系统。

连接这两个世界的标准做法叫CDC，全称Change Data Capture，读取数据库的增量日志，在分析侧重建状态。CDC是现代数据基础设施最无聊但最关键的操作之一。Reynold开玩笑说它应该叫"持续数据腐败"，Continuous Data Corruption，因为OLTP侧一旦改了数据表结构（数据库术语叫schema，比如加一列、改字段类型），CDC管道就可能处理不了，凌晨三点数据工程师就会被叫醒。Reynold在keynote上问台下谁喜欢自己的CDC管道，举手的只有两三个人。

HTAP为什么从未成功

用一个数据库同时处理事务和分析，是数据库工程师的终极梦想，业界叫HTAP。但实际做出来的HTAP系统全是妥协。Postgres有庞大的生态，Spark也有庞大的生态，如果做一个新系统，两边的生态都用不上，只能搞一个更小的专有接口，结果是两头都差。而且要在一个引擎里同时做好两种工作负载，性能上几乎不可能不互相拖累。

Databricks的新方案叫LTAP，全称Lake Transactional/Analytical Processing，2026年6月16日在Summit上发布。核心思路是：不在查询引擎层面合并，只在存储层统一。Postgres数据库的数据直接以列式格式写入开放数据湖，分析引擎可以立即读取，不需要任何管道。事务和分析各用各的计算引擎，各自独立扩展，互不干扰。

Reynold总结：Postgres还是做事务，Databricks的Lakehouse还是做分析（Lakehouse是Databricks的核心产品，把数据湖的低成本存储和数据仓库的查询能力合在一起），只是底下的存储变成了同一份数据。

理解这个突破需要知道一个背景：事务数据库通常按行存储数据，一行就是一条完整记录（比如一笔订单的所有字段），适合逐条读写。分析引擎则按列存储，同一个字段的所有值放在一起（比如把所有订单的金额排成一列），适合大规模聚合计算。两种格式各有擅长，过去需要CDC管道来做转换。

Reynold和Ali Ghodsi花了很多时间争论一个技术问题：基于收购而来的serverless Postgres技术（原Neon公司）构建的Lakebase，之前把数据以Postgres原生的行存格式写入云端对象存储，能不能改成Parquet列存格式？两人来回辩论了很多轮会议。结果一个工程师直接做了原型：存储层的缓存服务有大量闲置CPU，可以用来做行存到列存的转码。而且转码后数据压缩率大幅提高，往S3写入反而更快。没有性能开销，没有额外成本，因为CPU本来就闲着，这个争论就不用继续了。

Matei说这类事不需要启动项目、写设计文档、走正式流程。"你如果搭好了环境让人可以直接试，比写十页分析文档有用得多。"

给智能体打开数据库的视野

Matei说自己一开始对"LTAP对智能体有用"这个定位持保留态度。但在Summit晚宴上，一位澳大利亚客户告诉他：他们有很多服务日志，发现SLA下降时想用智能体调查原因，但智能体只能看到产品遥测数据，看不到数据库里实际的订单和用户行为。如果智能体能直接查询事务数据库里的业务数据，能力会提升一个量级。

另一个场景来自Matei自身经验：出过数据库事故时，工程师说"我不能在上面跑大查询，因为会让数据库雪上加霜"。LTAP解决了这个问题，因为分析查询跑在一组独立机器上，不会影响正在服务业务的事务数据库。

数据到位了，还要够快。智能体不像人类可以等几秒看报表，它们需要毫秒级响应才能嵌入实时工作流。Databricks为此从头重写了分析引擎。

这个项目内部代号Reyden（取自Reynold名字的谐音），团队戏称"Reynold's Dream Engine"，对外产品名叫Lakehouse//RT。Reynold指出市面上有合理用户基础的分析引擎几乎都有约十年历史，最初为细分场景设计，随着成功不断扩展，十年有机演化下来变成了一堆技术债。Databricks自己也不例外。计算机科学里有个经典警告叫"第二系统综合征"：你做了第一个成功的系统，第二个几乎注定失败，因为目标设得太大。

Reyden团队换了一种造数据库的方式。传统做法是读学术论文、了解最新算法和数据结构，拼在一起看效果。问题是论文里表现好的算法可能在70%的工作负载上好用，在另外30%上反而更差。他们的做法是先造一个"工厂"：用Databricks十年积累的查询trace数据（团队统计为千万亿级数据点）训练了一个机器学习模型，这个模型可以快速预测任何算法组合在任何查询类型上的表现。在实现阶段选出对实际工作负载最有效的算法，在运行时动态分派最合适的执行路径。Beta版基准测试显示，可以在每秒处理12000次查询的负载下做到亚100毫秒延迟。

从上游出发

swyx在对谈中问了一个直接的问题：Snowflake也在做存算分离，也在做分析数据库，你们凭什么跑在前面？

Matei的回答指向了一个创立之初就做出的选择：开放格式。Databricks从来没有专有数据格式，从Parquet起步，演进到Delta和Iceberg。Snowflake一开始选择了专有存储，优化最有价值的结构化数据，服务管理层和财务人员的快速查询。

Databricks起家靠的是Spark，一个开源的大规模数据处理引擎，由几位创始人在UC Berkeley读博时开发。Spark的强项是把海量数据分散到成百上千台机器上并行处理，适合批量数据摄入和复杂计算。数据存在开放格式里，下游谁都可以读。曾经两家互相列为合作伙伴：用Databricks做摄入和计算，用Snowflake做SQL查询和可视化。后来客户开始问"为什么我需要另一个东西"，两家各自进入了对方领地。

Matei认为从上游出发比从下游出发更有优势。已经有了大规模摄入和开放生态，往下游加SQL查询和可视化能力，比反过来容易。而企业客户如果IT系统已经存在三十年，经历过被Oracle锁定的痛苦，选技术底座时会优先考虑开放格式。Reynold补充说，开放数据格式在五六年前还有争议，Snowflake有一位联合创始人专门写了一篇博客叫"Choosing Open Wisely"来反对。现在开放格式已经成为企业共识。

先为一两个客户做到可用

Matei和Reynold都强调了一种产品开发哲学：先为一两个真实客户做到可用，再从那里扩展。Reynold举了Clean Room的例子，这是Databricks的数据安全共享产品，最初只为两个客户开发。他说行业里有人认为过拟合一两个客户风险很大，但"过拟合的风险远小于另一个方向的风险：什么都做，最后一个客户都没有"。

Delta Lake早期也是同样的模式。Matei回忆，大约2017到2018年间，当时最大的客户需要一个独立于公司其余网络的云端系统来存储和查询安全事件，给出了每秒事件量和数据新鲜度要求。这个工作负载远大于Databricks当时的任何场景。工程师Michael Armbrust（Delta Lake的创建者）专门为这个客户做到了可用，一旦这个极端场景跑通，其他客户的需求自然就覆盖了。

Reynold评估产品团队时问的第一个问题永远是：你的目标客户是谁？你和他们在互发短信吗？

这种文化在公司规模到了5000多名工程师之后依然保持着。Matei说很多重大产品（包括Omnigent和LTAP的关键原型）都是先有人做出可工作的东西，再来讨论要不要正式立项。LTAP的行存转列存原型就是典型，既没有设计文档也没有正式立项，一个工程师自己做了出来，然后拿结果说话。

Ben Horowitz在Databricks还在早期时曾说"这家公司应该值一万亿，你们在贱卖"。swyx说Horowitz不会对每家公司都这么说。Matei回应：我们很幸运有Ben的支持。

Reynold在对谈的最后说："Once you can get the data in the right place,let's slap some agent on top.Magic will come out." 让数据到位，在上面放个智能体，魔法自然出现。

这句话听起来太简单了。但Databricks从Spark到Delta Lake到Lakehouse再到Omnigent和LTAP，13年做的事情确实可以归结为一条：在每一代技术变革中，找到数据应该出现但还没出现的位置，然后建一层基础设施把它送到那里。这些基础设施工作从来不是最吸引眼球的部分，但回过头看，它们往往是价值最集中的部分。

到了智能体时代，数据下一次需要出现在哪里，答案还在变化中。

注：文/记录AI变革的，文章来源：至顶头条，本文为作者独立观点，不代表亿邦动力立场。

文章来源：至顶头条