跳转至

湖仓：Lakehouse

本章所属 DDA 层：Lakehouse

问题

消费方换了，数据平台要解决的问题就换了。

过去十年，平台服务的是人。分析师写 SQL，业务看仪表盘，数据科学家取样训模型。人能从字段名猜含义，能忍 T+1，口径糊了还能打电话。机器对契约漂移敏感，也读不懂「A 表示活性还是已归档」。

没有过质检的落湖，Ontology 没东西可绑。证据索引会把空切片当成可引用原文。闭环也没数据可回流。

阿斯利华的化合物表、CSR、专利 PDF、ELN 导出，得先变成带契约的数据产品。复制一份进 AI 沙箱，只是把传递问题挪了个地方。湖仓要做的几件事很具体：契约写清字段含义，入湖质检拦住空树和未登记来源，证据和知识分腿走，避免每篇文档变成本体类。

传统方案

面向 BI 的平台大致是这样：ETL 入仓，按主题域分表，字段名扛含义，口径写在注释或 BI 语义层，新鲜度 T+1，质量靠抽检和 SLA 报表。

阿斯利华早期也是这个样子。dwd_compound 存研发代号，dwd_clinical_trial 存进度，监管文档在文档系统里。有人要查「在研的 c-Met 抑制剂」，自己写 SQL，自己在字段名里找意思。

报表时代这套能转。口径靠人脑对齐，团队的核心工作是保证 T+1 跑通。

文档更随便。CSR、SOP 当附件，扫描件和 Excel 不良反应清单靠邮件。没有统一解析，也没有「这篇能不能入库」的闸门。

为什么失效

慢不是主因。消费方变了，而且科研数据不只是表。

cmpd_status='A' 对人也许够用，对机器是黑箱。含义散在表名、字段、注释、BI 口径里，没有单一来源。

上游改字段名、改类型、改取值，是常态。没有显式契约，消费边界就不稳。

文档若静默入库，后果更难看。空语义树、版面大面积降级、来源未登记、同一 doc_id 反复追加，证据索引都会当真。引用链从第一天就脏。

每篇 PDF 直接灌进本体，图会按文档增长速度膨胀。文档是证据和候选的来源，不是世界模型。

flowchart LR
    subgraph BI["面向 BI 的传统数仓"]
        B1[字段名承载含义] --- B2[T+1 新鲜度]
        B2 --- B3[口径散落注释]
        B3 --- B4[附件当文档库]
    end
    subgraph AI["科研落湖要的东西"]
        A1[机器可读契约] --- A2[入湖质检]
        A2 --- A3[Evidence与Knowledge分腿]
        A3 --- A4[失败要大声]
    end
    BI -.对不上.-> AI

图：传统数仓和科研落湖对不上（DDA 层：Lakehouse）

新的设计思想

湖仓既要给人出报表，也要给不会猜含义的机器用，还要同时接表和文档。

数据契约是一等公民，字段和变更规则写进可校验的协议。

文档入湖是一条阶段链，不是「丢进解析器」：Detect → Route → Parse → Clean → Standardize → IngestQA → Persist。

入湖分两腿。Evidence 腿回答原文怎么说。Knowledge 腿只产候选断言，默认不进知识图。

入湖质检和发版守门分开。前者决定文档能不能进湖，后者决定事实能不能进图。

能力要切剖面。查一个企业 ID，不该先把版面引擎和向量模型全部拉起来。

架构设计

flowchart TB
    SRC[数据源与文档] --> CT[数据契约 / 来源登记]
    CT --> PIPE[Detect_Route_Parse_Clean_Standardize]
    PIPE --> QA[IngestQA]
    QA -->|通过| FORK[Persist]
    QA -.阻断.-> AL[告警与拦截]
    FORK --> EV[Evidence腿]
    FORK --> KN[Knowledge腿_extracted]
    EV --> MD[可程序消费元数据]
    EV --> LN[可追溯出处]

图：先过契约和质检，再分腿落湖（DDA 层：Lakehouse）

这一层的基本单位是数据产品。裸表不够，未质检的 PDF 也不够。先保证上层绑得住，再谈它是不是知识。

工程实践

决策表

决策 选择 放弃
入湖对象 表 + 文档内结构（PDF/Office/HTML/图） 本期把 FHIR / OMOP / VCF 临床仓当切包前提
文档命运 切证据、挂已有实体、抽候选 每篇文档 mint 本体类
质检 IngestQA 管入库，QualityGate 管发版 一个闸门两用
失败 空树、降级超阈、许可未登记则阻断 警告后继续写湖
运行时 入湖 / 抽取 / 图谱 / 索引 / 访问分剖面 一个安装面拉齐全部重依赖
编排 纯函数步骤 + 编排器管失败域 把业务逻辑写进编排器

阿斯利华可走通的例子

化合物产品用 YAML 声明契约：

name: compound_active
owner: data-platform@asliva.example
description: 活性化合物清单，含研发代号与属性
contract:
  version: 1.2.0
  fields:
    - name: compound_id
      type: string
      business_meaning: 企业主键，对应 ASH:ENT:DC:*
      constraints: [not_null, unique]
    - name: research_code
      type: string
      business_meaning: 内部研发代号，如 ASH-001
      constraints: [not_null]
    - name: target
      type: string
      business_meaning: 作用靶点，如 c-Met
    - name: status
      type: string
      business_meaning: 研发状态
      allowed_values: [discovery, preclinical, phase1, phase2, phase3, marketed, withdrawn]
change_policy:
  breaking_change: requires_major_version
  notification: contract-broadcast@asliva.example

CSR doc_id=csr_ash001_phase1_v3 走完阶段链，应得到带 3.2 不良反应表的语义树、类型化块、来源和许可戳。IngestQA 通过后，Evidence 腿写下可还原切片；Knowledge 腿写下 extracted 断言，例如「ASH-001 treats NSCLC」。状态仍不是 validated。

同一 doc_id 重跑要先删后写。追加会让引用坐标翻倍，审计时对不上版本。

失败模式

  • 空树仍写入证据索引。引用看起来完整，点进去没有正文。
  • 缺框、OCR、表结构降级超阈值还入库。不良反应清单被拍平，没法引用。
  • 来源未登记或许可未标。候选期无法过滤，要么泄漏存在性，要么整库拒检。
  • 占位向量标成可检索。检索「能跑」，召回是噪声。
  • 为了装配词典再拉一整条文献库。入湖剖面失去独立失败域。

五项 AI 就绪特性

  1. 语义化：数据产品有机器可读的业务含义。
  2. 可治理：契约、出处、口径有单一来源。
  3. 可追溯：从消费结果能走回原始对象。
  4. 低延迟：关键链路跟得上上下文接口。
  5. 安全：按产品授权，不开放裸库。

可观测四支柱

质量在写入时校验，不靠第二天抽检。

  • Trace（WHERE）：这份 CSR 卡在路由、解析，还是质检。
  • I/O（WHAT）：进的是哪份对象，出了几棵树、几个块。
  • State（WHY）：为什么降级、为什么阻断。被否决的原因要留下。
  • Metrics（WHEN）：新鲜度、降级比例、阻断次数。

State 最容易被省。只记「失败了」，闭环以后挖不到信号。

业界路线对照

阿斯利康谈 FAIR 时，把持久标识和受控词表嵌进数据产品，而不是事后贴标签。Open PHACTS 的公开数据先进入可缓存的整合层，再经 API 对外。湖仓层只借这一条：先成为可引用的产品，再谈图谱和检索。

对象存储加表格式湖加 SQL 引擎，是一种实现，不是本层定义。换一套批处理栈，替代不了入湖阶段纪律。

最佳实践

每个产品有负责人、契约、SLA 和消费者清单。

先写契约，再写入湖作业。

IngestQA 在管道里，违约即拦截。

证据可以自动进索引。知识边另走策展。

查身份不该依赖版面引擎。

契约、质检、可观测都是长期成本。PoC 能简化，上生产前要补齐。

延伸阅读

  • Dehghani《Data Mesh》；Data Contract 社区规范。
  • 头部药企把持久标识和受控词表嵌入数据生命周期的公开讨论。
  • Trace / I/O / State / Metrics。

Checklist

  • 对外消费的数据产品是否都有显式契约？
  • 文档是否走 Detect → Route → Parse → Clean → Standardize → IngestQA → Persist？
  • IngestQA 和发版 QualityGate 是否分开？
  • 空树、降级超阈、许可未登记是否阻断？
  • 同一文档重跑是否先删后写？
  • Evidence 和 Knowledge 是否分腿，文档是否避免自动 mint 本体？
  • 入湖、抽取、图谱、索引、访问是否按剖面安装？
  • 可观测是否记下 WHY？

机器消费要契约和入湖质检。这一层是 Ontology 和证据链的地基：表和文档先成为可质检的产品。