凌晨两点，券商研究员小刘被电话惊醒：“美股出了份行业报告，对A股新能源板块开盘会有冲击。老板让你八点前出一份快评，要有龙头持仓变化、机构观点转向、相关研报梳理。”
小刘打开电脑。行情终端拉资金流向，Excel手工对比。金融数据库调公募持仓明细，PDF季报手动翻。研报系统搜新能源、光伏，标题筛选后一篇篇翻。舆情平台查公告和新闻，逐个判断相关性。
凌晨五点半，素材拼凑完毕。距离交稿两个半小时。他的时间分配是三分写报告，七分捞数据。这不是在分析市场，是在和信息割裂搏斗。
我拉着小刘看完了今天的OceanBase发布会，跟他说，你的困境也许可以解决。
证券数据的五种语言
一笔投资决策涉及五套系统，各说各的语言。
- 行情数据在行情终端，这是时序数据，每秒数万笔，用专用金融API，不跟你说SQL。
- 持仓与交易在核心系统，关系型数据，说SQL，但和行情系统时间戳对不齐。
- 研报与公告在资讯平台，PDF和Word，只能标题检索，语义搜索几乎为零。
- 舆情与另类数据散落各处，文本、图片、流数据，格式五花八门。
- 产业链关联在知识图谱，图数据，需要专门图查询语法。
当小刘想查北向资金持续加仓且机构评级上调且无减持公告的锂电公司的时候，这条查询同时涉及日频资金流（温数据）、机构研报（冷数据）、上市公司公告（冷数据）。传统架构下，要么靠ETL搬运，要么手工分三次查询再拼接。
五种数据，五种语言，五座孤岛。你说他是研究员，他说他是搬运工。哪怕用AI工具解决效率也不见得提高。
拆温度隔离墙
证券数据有独特的时间分层，毫秒级行情是热数据，必须在内存上跑。日频K线和持仓是温数据。五年前的年报和交易记录是冷数据，极少访问，但即便业务用不上，按照监管要求必须保留。
传统架构下，热数据在交易库，温数据在数仓，冷数据在对象存储。三套存储，三种访问方式。Hadoop的数据怎么和Oracle还有Redis关联起来，还得有效率是个极大的难题。
我看 Lakebase 最核心的思路，就是把这道温度墙给打穿。不是把冷数据全搬到热存储里烧钱，而是元数据、权限、表结构全打通。你写一条SQL，不用管数据是在NVMe的实时库里，还是在对象存储里躺了五年的年报文件里，优化器自己去调度。说白了就是数据分层放，但查询入口只有一个。
还有个很实用的点是数据分支，跟Git分支逻辑差不多。以前回测新因子要么拷一份数据占空间，要么直接在生产库上跑有风险，现在可以直接拉个分支出来跑实验，跑完有用就合，没用就扔，完全不碰主干数据。这个功能对量化团队来说，确实是戳中痛点了。
小刘想做的那个跨温区查询，不再需要知道数据在哪。一次查询，湖仓共答。
让研报开口说话
证券业是文档密集型行业。每天产出的研报、公告、招股书以万计。过去这些文档语义上不可查。研究员想找对锂电行业持谨慎乐观、但提示了产能过剩风险的研报，关键词只能匹配“锂电”“产能过剩”，无法区分“乐观”和“谨慎乐观”。
AI改变了这一切。大模型可以提取核心观点、判断情感倾向、标注风险信号。但关键问题是：在哪里做这件事？如果把每天上万份研报导出、送外部AI平台处理、再写回，批处理链路跑几个小时。到结果出来，市场可能风向变了。
OceanBase的做法是把AI能力种进数据库。
多模表可以做到一张表同时容纳结构化列（股票代码、市值）、时序列（日频资金流向）、向量列（公司特征嵌入）、文本列（研报全文、公告全文、新闻快讯）。一张表，就是一家公司的完整画像。
AI列更进一步，大模型的理解能力以列的形式引入数据库。财报PDF存进去，自动提取营收增长率、毛利率变化、现金流趋势。深度研报存进去，自动识别核心观点、评级变化、目标价调整和风险提示。新闻快讯存进去，自动判断利好利空和影响程度。
加工发生在数据存储的地方。存进去的那一刻，理解就发生了。对小刘来说，过去需要几小时手动翻阅的PDF，现在已被AI列自动标注。他打开的是一张机构观点对比表，能够直接找到哪家加仓、哪家撤退、评级上调原因、风险提示集中在哪。
不当搬运工，也就不用再两点起床。
当数据库的消费者变成AI研究员
证券业正见证Agent从辅助工具走向独立决策。
按照大家的规划，将来量化策略Agent可独立完成因子挖掘、回测验证和信号生成。投研Agent可7×24小时追踪特定行业信息，在重要事件发生时自动生成简报。风控Agent可持续监控组合风险敞口，在极端行情时触发对冲。
但这些 Agent 真要跑在生产环境，不是光有大模型就行，底层数据库得扛住三个最实际的问题。
首先是响应速度。风控这种场景差一秒都不行，Agent 做判断要同时拉实时行情、持仓成本、研报观点、新闻情绪、产业链关系，跨好几种数据类型。要是分开查再拼接，延迟根本压不住，必须一次查询就能把所有上下文都取回来，百毫秒内出结果。
然后是不能乱碰生产数据。Agent 跑回测、做实验是常事，总不能每次都拷一份全量数据。前面说的数据分支刚好能用 —— 每个 Agent 拉个独立分支随便跑，验证有用再合并，没用直接删掉，全程不碰主干的实时数据，风险就控住了。
最后是资源效率。真给每个行业、每个组合配一个 Agent，几十上百个是常态，但大部分时间它们都在等事件触发，总不能一直占着资源。靠逻辑库和资源隔离，闲的时候几乎不耗算力，有事件毫秒级唤醒，规模化的成本才压得下来。
分布式架构，动态扩容，资源隔离，这些OceanBase本来就具备的能力，加上现在Agent能力，让这些场景成为了可能。
让SQL和Spark在同一份数据上对话
证券业数据处理需求极其多元，实时行情接入需要极低延迟写入，日内风控需要毫秒级结构化查询，盘后归因需要大规模聚合，量化因子挖掘需要Python数值计算和机器学习库。监管报送需要标准SQL。
没有单一引擎能满足所有需求。
按照今天发布会OceanBase的介绍，能够支持S3兼容对象存储与Iceberg开放表格式。那么Spark就可以通过Iceberg直接读取历史行情和财报做批量因子计算，结果写回后在线查询立即可见。Python生态可读取数据做量化回测，Flink可读取实时流做复杂事件处理。Ray可做分布式训练。
不同计算引擎各自负责擅长的任务，但不需要数据复制、格式转换、多套存储。仍然还是我之前的观点，过往的数据仓库和数据中台，都是建立在数据可以搬运的基础上，但是一旦数据来不及搬运的时候，开放查询，用不同的语言和工具就成了刚需。
一幅未来图景
把OceanBase这三个能力组合在一起，未来可以支撑这样的场景：
智能研报生成。 真落地的话，我判断最先跑通的就是隔夜快评这个场景。凌晨美股那边出了异动，行情阈值触发Agent自动启动。 不用人爬数据了，实时行情、资金流向直接库里取，一周内的研报观点、公告利好利空AI列早就标好了，连产业链上下游的联动关系都能直接查。最后出来的肯定不是成品报告，是个带数据的草稿框架，核心数据和观点都列好，研究员早上到了直接审核、补逻辑、加自己的判断。当然前提是底层的研报解析准确率得够，产业链图谱也得先搭扎实，不然出来的东西错漏多，反而要花时间核对。但哪怕只省掉翻研报、拉数据这一半功夫，对凌晨赶稿的研究员来说也已经是解放了。
量化这边的感受会更直接。比如研究员想验证一个新因子，机构调研密度叠加上分析师评级调整，能不能跑出超额收益？以前要从好几个系统里扒数据、对齐时间戳，光数据准备就要一两天。现在调研关系在图模型里，评级数据AI列早就结构化好了，行情就是原生时序列，一条SQL就能把所有数据拉齐。
回测更简单，直接开个数据分支跑，不用动生产数据，也不用等运维腾环境。以前按天算的流程，现在几十分钟就能出结果，试错成本低太多了。
本质上能够解决市场快速变动但是人跟不上的困境。
结语
证券业是信息的行业。信息获取速度、处理质量、关联深度，直接决定盈亏。
但过去二十年，信息系统一直在做加法，行情一套，交易一套，资讯一套，风控一套。每套有自己的存储、接口、语言。系统越加越多，代价就是信息关联越来越弱。研究员不是在分析市场，是在拼凑碎片。
OceanBase湖仓一体+AI，做的不是再多加一套系统，而是改变逻辑本身。
说到底，它不是在原来的系统上再加一层AI，而是把数据底座的逻辑给换了。所有数据类型在同一个底座上打通，所有计算引擎能直接读同一份数据，AI的理解能力长在数据存储的地方，Agent不用再当数据搬运工，直接在库里完成判断和执行。
金融巴别塔，需要拆除，怎么拆，OceanBase给了我一个答案。
