xiaohack's Blog - SQL
type: channel
link: https://blog.xiaohack.org/tag/SQL/
items: NoETL 语义编织 vs 传统 ETL/ELT，指标平台选型深度对比
items: 指标平台选型关键与 Aloudata CAN 无宽表计算方案
items: 写给技术管理者的低代码手册系列文章（2）——第一部分：低代码诞生的背景
items: MySQL 用好 Optimizer Trace，深刻理解 SQL 优化过程！
items: BigQuery 新功能：SQL 直调 17 万 + AI 模型，3800 万行数据处理成本仅 2 美元
items: 数据工程视角：为什么公司会有几百个含义模糊的“DAU”指标？
items: 不要再纠结 LLM 准确率了：从“回答对不对”到“系统是否值得信任”
items: 本周更新｜AI 对话支持复制粘贴文件
items: 告别拼凑：记忆、检索与AI数据引擎的一站式技术栈解析（一）
items: MyBatis Dynamic SQL 入门指南

NoETL 语义编织 vs 传统 ETL/ELT，指标平台选型深度对比
type: item
date: 2026-02-10T13:07:47+08:00
description: 本文首发于 Aloudata 官方技术博客：《指标平台选型对比：NoETL 语义编织 vs 传统 ETL/ELT，如何破解数据分析不可能三角？》转载请注明出处。摘要：本文深入对比了传统 ETL/ELT 模式与 Aloudata CAN NoETL 语义编织平台在数据工程领域的核心差异。通过剖析“数据分析不可能三角”的根源，并从架构、开发、治理、成本四个维度进行技术对比，为数据架构师和决策者提供清晰的指标平台选型框架，旨在解决指标口径混乱、响应迟缓与成本高企的痛点。一、决策背景：为何传统 ETL/ELT 模式陷入“数据分析不可能三角”？在 AI 时代，海量、灵活的分析需求与依赖人工预计算物理宽表的传统数据供给模式之间，矛盾日益尖锐。企业数据团队普遍陷入一个痛苦的“不可能三角”：在“业务灵活性”、“指标口径一致性”和“性能成本”三者间，只能艰难取舍，难以兼顾。“指标口径统一说简单真不简单……财务部和销售部都在用‘收入’这个词，但你问问他们怎么算‘收入’——一个是‘含税’，一个是‘不含税’……老板看到两个部门的‘收入’差了几十万，脸色有多精彩吗？” —— 来源：FineBI 技术社区， 2025痛点表现具体如下：口径混乱，数据打架：指标逻辑硬编码在分散的 ETL 脚本和物理宽表中，导致“同名不同义”。例如，财务与运营的“GMV”定义不同，管理层决策无所适从。响应迟缓，敏捷缺失：一个新分析需求，从业务提出到数据团队排期、开发（ODS→DWD→DWS→ADS）、测试、上线，往往需要数周甚至数月。业务创新被冗长的开发链路拖累。分析固化，下钻困难：分析路径被预建的物理宽表（ADS 层）固化。若业务想从“按省份看销售额”下钻到“按城市看”，而宽表未预先聚合城市粒度，则无法实现，灵活性极差。成本高企，资源浪费：为保障报表查询性能，数据工程师不得不预建大量汇总宽表。相同明细数据被反复加工、存储，形成巨大的存储冗余与计算浪费，ADS 层日益臃肿。根因剖析：这一切的根源在于传统“物理宽表驱动”的范式。业务需求必须翻译为具体的物理表结构变更，通过人工编写 ETL/SQL 来实现。这导致了漫长的开发链路、业务与技术的沟通鸿沟，以及任何变更都牵一发而动全身的维护复杂性。引入“不可能三角”：传统模式迫使企业在三角中做出选择：要灵活分析（多建宽表）就会推高成本和加剧口径混乱；要保证口径一致和低成本（少建宽表）就会牺牲查询性能和业务灵活性。这个结构性矛盾，是当前企业数据价值释放的核心瓶颈。二、核心差异：从“物理宽表驱动”到“语义模型驱动”的范式重构要破解“不可能三角”，必须进行范式层面的革新。Aloudata CAN 的本质是基于 NoETL 语义编织的动态计算引擎，其核心是通过将业务语义与物理存储解耦，从根本上颠覆了传统以物理宽表为核心的指标生产模式。范式要素传统模式 (物理宽表驱动)Aloudata CAN (语义模型驱动)核心对象物理表（DWS/ADS 宽表）语义模型（虚拟业务事实网络）指标定义硬编码在 ETL 脚本中声明式配置（基础度量、业务限定、统计周期、衍生计算）开发动作编写 SQL/代码，物理建表零代码配置，系统自动生成 & 优化 SQL治理时机事后人工核对与文档管理事前自动判重，定义即治理架构特征烟囱式，为报表建表平台化，一处定义，处处服务Aloudata CAN 的工作机制：统一语义层：在干净的 DWD 明细数据层之上，通过声明式方式配置业务实体间的逻辑关联，构建一个“虚拟业务事实网络”。无需预先进行物理打宽。定义即开发：业务人员或数据工程师通过界面，像搭积木一样配置指标的四大语义要素（如“近 30 天”、“成功支付的”、“日均交易金额”），平台自动生成最优执行 SQL，实现零代码开发。定义即治理：在定义指标时，系统自动进行全局判重和一致性校验，确保同一个业务概念在全公司只有唯一、权威的定义，从源头杜绝口径不一。范式结论：这场变革是从“为特定报表去建物理表”的被动、烟囱式开发，转向“基于统一的语义模型按需计算”的主动、敏捷响应。三、四维深度对比：技术实现、业务效能与总拥有成本下面我们从四个关键维度，系统化对比两种技术路径带来的截然不同的业务结果。综合对比表对比维度传统 ETL/ELT 模式Aloudata CAN NoETL 语义编织对业务的影响核心架构依赖预计算的物理宽表（DWS/ADS层）统一语义层，直接基于 DWD 明细构建虚拟业务网络摆脱“为报表建表”的束缚，支持任意维度下钻与灵活分析开发模式手工编写、调试 ETL/SQL 脚本，流程冗长定义即开发：配置化声明指标，系统自动生成优化 SQL需求响应从数周缩短至分钟级，业务自助成为可能口径治理指标分散在不同数据集，依赖人工文档与沟通对齐定义即治理：一处定义，处处使用，创建时自动判重实现企业…

指标平台选型关键与 Aloudata CAN 无宽表计算方案
type: item
date: 2026-02-10T11:10:29+08:00
description: 本文首发于 Aloudata 官方技术博客：《指标平台选型关键：告别宽表依赖，Aloudata CAN 如何定义复杂指标？》转载请注明出处。摘要：本文深入探讨了在数据工程实践中，面对“近7天高价值用户数”等复杂指标时，传统宽表模式的局限性。通过对比传统静态宽表计算与 Aloudata CAN NoETL 指标平台的动态语义编织架构，从指标定义能力、分析灵活性、AI适配性等维度，为数据架构师和决策者提供一套清晰的选型决策框架，旨在帮助企业破解数据分析的性能、灵活性与成本之间的“不可能三角”。一、决策背景：当复杂指标需求撞上“宽表依赖症”数据团队对以下场景绝不陌生：业务方提出“近 7 天支付金额大于 100 元的去重用户数”这类指标，分析师在 BI 工具中拖入一个新的维度组合，查询响应时间便从秒级骤降至分钟级，甚至触发超时。其根源在于，传统的“数仓+宽表+BI”模式在面对灵活多变的复杂业务逻辑时，存在结构性瓶颈，即“宽表依赖症”。“宽表依赖症”的核心困境体现在：开发效率低：为应对“指标转标签”（如“上月交易量 > 0 的用户”）或“多层嵌套聚合”（如“月日均交易额最大值”）等复杂逻辑，数据工程师需编写数百行 SQL，构建物理宽表。需求排期以周甚至月计，无法支持业务快速迭代。分析不灵活：分析路径被预建的物理宽表（ADS 层）所固化。一旦业务提出未预见的维度组合（如新增“用户等级”维度），就必须启动新一轮的宽表开发排期，严重制约了业务探索性分析。成本高昂：为满足不同分析场景，大量宽表和汇总表被重复开发，导致存储与计算资源严重浪费，形成“烟囱式”的数据资产。“在指标平台等分析场景下，数据量往往达到亿级甚至更高。查询缓慢、响应延迟成为常态，严重影响了业务人员获取数据的时效性。” —— 镜舟科技技术博客这种模式在追求极致分析性能、灵活性和成本效益之间难以找到平衡点，构成了数据分析的“不可能三角”。二、核心差异：静态宽表计算 vs 动态语义编织性能与灵活性困境的根本差异，源于底层架构的范式革新。传统模式（静态宽表计算）：其核心是 “预计算、后查询” 。数据分析师或开发人员需要预先理解业务需求，编写 SQL 或 ETL 任务，将多张表打平成物理宽表或汇总表。查询时，BI 工具直接访问这些固化好的物理表。其性能上限在宽表创建时即被锁定，且无法应对未预见的查询模式。Aloudata CAN NoETL 模式（动态语义编织）：其核心是 “声明定义、动态计算” 。基于语义编织技术，用户在界面通过 声明式策略 完成两件事：声明逻辑关联：在未打宽的 DWD 明细表之间，声明业务实体间的关联关系（如 订单表 JOIN 用户表）。声明指标逻辑：通过配置“基础度量、业务限定、统计周期、衍生计算”四大语义要素来定义指标。系统据此在逻辑层构建一个 虚拟业务事实网络（或称虚拟明细大宽表）。当业务发起查询时，语义引擎 将查询意图翻译为最优化的 SQL，并通过 智能物化引擎 透明路由至已预热的物化结果或高效执行原生查询。这是一种 “逻辑定义与物理执行解耦” 的架构。三、维度对比一：复杂指标定义能力面对复杂的业务逻辑，两种模式在定义方式、效率和维护性上存在天壤之别。对比维度传统宽表模式Aloudata CAN NoETL 模式定义方式编写数百行 SQL，人工开发，依赖资深工程师声明式配置，零代码定义，业务分析师即可完成典型场景简单聚合（如销售额、订单数）指标转标签（如“上月交易>0的用户”）、多层嵌套聚合（如“月日均最大值”）、跨表复合指标（如“渠道ROI”）开发效率低，需求排期以周/月计，响应迟缓高，分钟级完成定义与交付，实现业务自助维护成本高，逻辑变更需重写 SQL 与 ETL，牵一发而动全身低，配置化修改，系统自动同步所有下游，治理内嵌于流程核心差异解读：传统模式将复杂的业务逻辑固化在物理表结构中，变更成本极高。而 Aloudata CAN 通过语义抽象，将指标转化为可配置的要素，实现了 “定义即开发” 。例如，定义“近 30 天有购买行为的用户”这一标签，只需选择“交易金额”作为基础度量，设置“统计周期”为近 30 天，“业务限定”为“交易金额 > 0”，系统即自动生成并执行相应的去重计数逻辑，无需编写一行 JOIN 和 GROUP BY 的 SQL。四、维度对比二：分析灵活性与性能保障当业务需要自由探索数据时，两种架构对分析路径和查询性能的保障机制截然不同。传统模式：分析灵活性被物理宽表预先定义好的维度组合所限制。任何未预见的查询都可能导致性能“开盲盒”，直接扫描亿级明细，响应时间无法保障。Aloudata CAN：支持指标与维度任意组合、自由下钻。其性能通过 声明式物化策略 保障：用户可声明对特定指标和维度组合进行加速，系统据此自动编排物化任务并维护物化视图（预…

写给技术管理者的低代码手册系列文章（2）——第一部分：低代码诞生的背景
type: item
date: 2026-02-03T15:35:09+08:00
description: 第一章 企业软件复杂度的逐步累积1.1 从硬件导向到数据导向早期的软件开发几乎完全围绕计算机硬件展开。机器语言与汇编语言要求开发者理解CPU指令、寄存器和内存地址，软件的表达方式高度依赖具体硬件体系结构，如SSE指令集中用于比较字符串的pcmpistr，无法运行在不支持SSE的CPU上。这一阶段的软件极其昂贵、开发周期漫长、可复用性极低，应用范围也因此被限制在政府、科研机构和少数大型企业的核心场景中。随着电子工业的发展，计算机开始进入企业管理领域。跨行业、跨规模推广计算机应用的关键，在于找到一种足够通用的抽象方式。1970年，来自IBM的E.F.Codd博士在ACM通讯杂志上发表的论文《大规模共享数据银行的关系型模型》，为解决这一问题提供了一种切实可行的技术路线。该路线中，现实世界中的业务单据、业务流程和管理决策，被统一抽象为数据的存储、处理与分析，而执行这些操作的软件被统称为“关系型数据库”。企业的用户只需要一个连接到数据库软件的终端，就能用一套近似于英语的、统一的语言来操作这个软件，以此实现所有的业务操作。如用户想要查询姓名中包含“李”的员工档案，需要输入 SELECT * FROM STAFFS WHERE NAME LIKE ‘%李%’ ，界面上就会呈现出纯文本呈现的员工档案信息。图：早期的数据库服务器与操作终端关系型数据库的出现，标志着企业软件第一次在抽象层面实现了规模化。通过关系模型描述业务实体及其关系，通过统一的数据操作语言处理不同业务场景，数据库成功降低了企业信息化的技术门槛，也显著扩展了软件需求的边界。1.2 “壳”的出现与复杂度外溢当数据库从档案管理走向财务、库存、成本核算等复杂业务场景时，一个新的问题随之出现：直接操作SQL对最终用户并不友好，一个业务操作需要多次打印和重复输入，导致操作员工作负荷高、出错概率大。为此，行业选择将数据库抽象为数据模型（数据模型可近似理解为数据库的结构，由数据表、列和表关系构成），在模型之上构建应用软件。这种做法很像是给数据库“套壳”，让用户操作应用，应用去操作数据库，而非用户直接操作数据库。这一决策带来了企业软件形态的根本变化。业务逻辑开始在数据库与应用程序之间重新分配，用户交互界面成为差异化竞争的核心。随着抽象度更高的新一代高级语言（如C++、Java语言）在应用层的普及，企业软件正式进入“高级语言 + 数据库”的长期技术范式。图：DOS时代的企业软件操作界面然而，这种分层结构也埋下了复杂度累积的种子：数据模型持续膨胀：一个小型订单管理系统可能只有十几张表，但经过几年演进后，堪比ERP的系统重，表数量可能增长到数百张业务规则不断叠加：每次业务流程调整都会增加新的验证规则、计算公式和例外处理逻辑交互逻辑日益复杂：从简单的表单录入发展到复杂的向导流程、多标签页面和实时校验应用规模和生命周期显著拉长：企业软件往往需要运行十年甚至更长时间，期间不断打补丁和加功能企业软件不再是一次性交付的工具，而是需要多年演进、持续维护的复杂系统。扩展链接写给技术管理者的低代码手册系列文章（1）——从软件工程视角理解低代码的价值、边界与演进路径

MySQL 用好 Optimizer Trace，深刻理解 SQL 优化过程！
type: item
date: 2026-02-02T17:17:46+08:00
description: 前面的章节（社区专栏《SQL调优》）我们已经写了很多篇幅关于 MySQL 执行计划的解读，今天我们来继续延伸介绍执行计划的链路跟踪功能，也就是 MySQL 的 Optimizer Trace。在这之前，先来回顾下 EXPLAIN 的结果：mysql:ytt>explain select * from t1 a left join y1 b on a.id = b.id where a.r1<100 order by a.r2 desc; +----+-------------+-------+------------+--------+---------------+---------+---------+----------+--------+----------+-----------------------------+ | id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra | +----+-------------+-------+------------+--------+---------------+---------+---------+----------+--------+----------+-----------------------------+ | 1 | SIMPLE | a | NULL | ALL | idx_r1 | NULL | NULL | NULL | 998222 | 50.00 | Using where; Using filesort | | 1 | SIMPLE | b | NULL | eq_ref | PRIMARY | PRIMARY | 4 | ytt.a.id | 1 | 100.00 | NULL | +----+-------------+-------+------------+--------+---------------+---------+---------+----------+--------+----------+-----------------------------+ 2 rows in set, 1 warning (0.00 sec)EXPLAIN 展示出来的核心数据有：表关联顺序优化器筛选过的索引实际使用的索引每张表依据统计信息的扫描行数Extra 额外数据提示两种执行计划（explain format=tree / explain format=json）展示出来的额外成本数据如果想快速对于 SQL 进行优化，基于以上的结果完全可以满足。但是想深入了解 MySQL 优化器为什么选择这样的执行计划，基于以上的结果就无法满足。举例说明：我想知道对于表 a 来讲，为什么有索引 idx_r1，但是实际却没有使用，而走的全表扫？两张表关联，为什么选择的顺序是表 a 驱动表 b，而不是表 b 驱动表 a？为什么字段 r2 有索引，但是依然要走排序？带着这些疑问，我们来介绍 MySQL 的 Optimizer Trace 功能。1. 什么是 Optimizer Trace？简单来讲，Optimizer Trace 是一个 SQL 执行计划的链路跟踪器，跟踪 SQL 的解析、优化、执行等过程，并且把结果记录到 MySQL 元数据表（information_schema.optimizer_trace），之后可以对这张表分析得到很多个执行计划的“为什么？”！2. 如何使用 Optimizer Trace？要使用 Optimizer Trace 功能，首先得打开控制开关。谨记：这个功能非常耗费资源，默认关闭的，可以通过调整以下变量开启：mysql:ytt>show variables like 'optimizer_trace%'; +------------------------------+----------------------------------------------------------------------------+ | Variable_name | Value | +------------------------------+----------------------------------------------------------------------------+ | optimizer_trace | enabled=off,one_line=off | | optimizer_trace_features | greedy_sear…

BigQuery 新功能：SQL 直调 17 万 + AI 模型，3800 万行数据处理成本仅 2 美元
type: item
date: 2026-01-31T11:06:44+08:00
description: Google 近期针对 BigQuery 推出了面向开源模型的第三方生成式 AI 推理功能。这一更新允许数据团队直接使用简单的 SQL 语句，部署并运行来自 Hugging Face 或 Vertex AI Model Garden 的任何模型。该接口目前处于预览阶段，其最大的亮点在于消除了对独立机器学习（ML）基础设施的需求，系统会自动启动计算资源、管理端点，并在任务完成后通过 BigQuery 的 SQL 接口自动清理资源。这项新功能解决了困扰数据团队已久的痛点。在过去，运行开源模型往往意味着需要管理 Kubernetes 集群、配置端点以及在多种工具之间反复切换。Virinchi T 在一篇关于此次发布的 Medium 文章中指出：这一过程需要多种工具协同、不同的技能储备以及巨大的运维开销。对于许多数据团队来说，这种摩擦意味着即便模型本身是免费且公开的，AI 能力依然显得遥不可及。然而，得益于 BigQuery 的 SQL 接口，整个工作流现在被简化为仅需两条 SQL 语句。用户首先通过一条 CREATE MODEL 语句来创建模型，只需指定 Hugging Face 的模型 ID（例如 sentence-transformers/all-MiniLM-L6-v2）或 Vertex AI Model Garden 中的模型名称。BigQuery 会根据默认配置自动分配计算资源，部署过程通常在 3 到 10 分钟内即可完成，具体时长取决于模型大小。部署完成后，用户可以使用 AI.GENERATE_TEXT（针对语言模型）或 AI.GENERATE_EMBEDDING（针对嵌入模型）直接对 BigQuery 表中的数据进行推理查询。平台通过 endpoint_idle_ttl 选项管理资源的生命周期，该功能会自动关闭闲置端点以节省费用。此外，在批处理任务结束后，用户还可以通过 ALTER MODEL 语句手动卸载端点。为了满足生产环境的需求，该功能还支持高度定制化。用户可以直接在 CREATE MODEL 语句中设定机器类型、副本数量以及端点闲置时间。通过 Compute Engine 预留功能，还可以锁定 GPU 实例以确保性能稳定。当不再需要某个模型时，只需执行一条简单的 DROP MODEL 语句，系统便会自动清理所有关联的 Vertex AI 资源。Google 在官方博客中将该系统描述为提供“精细的资源控制”和“自动化的资源管理”，旨在让团队在不脱离 SQL 环境的情况下，找到性能与成本之间的最佳平衡点。2025 年 9 月发布的一篇早期博客曾展示，利用类似的开源嵌入模型处理 3800 万行数据，成本仅需约 2 到 3 美元。目前，该功能已支持超过 1.3 万个 Hugging Face 文本嵌入模型和超过 17 万个文本生成模型，涵盖了 Meta 的 Llama 系列和 Google 的 Gemma 家族。需要注意的是，所选模型必须符合 Vertex AI Model Garden 的部署要求，包括区域可用性和配额限制。Virinchi T 强调了这一变革对不同角色的意义：对于数据分析师而言，你现在可以无需离开 SQL 环境，也不必等待工程资源支持，就能直接实验 ML 模型。对于数据工程师而言，构建由机器学习驱动的数据管道变得极其简单，再也不用维护独立的 ML 基础设施。此次发布标志着 BigQuery 将与 Snowflake 的 Cortex AI 以及 Databricks 的 Model Serving 展开直接竞争，后两者同样提供基于 SQL 的 ML 推理能力。而 BigQuery 的竞争优势可能在于其与 Hugging Face 庞大模型库在数据仓库内的深度集成，这对于已经在 Google Cloud 上运行业务的用户具有极强的吸引力。目前，关于 Gemma 模型的文本生成以及嵌入生成的相关文档和教程已正式上线。原文链接：https://www.infoq.com/news/2026/01/bigquery-sql-huggingface-managed/

数据工程视角：为什么公司会有几百个含义模糊的“DAU”指标？
type: item
date: 2026-01-30T11:46:57+08:00
description: 本文首发于 Aloudata 官方技术博客：《为什么公司会有几百个含义模糊的“DAU”指标？深度解析》转载请注明出处。摘要：企业数据治理中普遍存在数百个同名不同义的“DAU”指标，这并非管理失误，而是传统“数仓+BI”烟囱式架构的必然结果。本文将从数据工程视角，精确定义指标口径混乱的四大要素，剖析其三大结构性根源，并阐述如何通过构建基于 NoETL 语义编织技术的统一指标平台，实现“一次定义，处处使用”，从根本上解决数据分析的“不可能三角”难题。“数据孤岛导致的‘同源不同口径’问题日益严重。不同业务系统独立运行，产生的数据没有统一的描述体系。结果就是：明明是同一个‘活跃用户’指标，财务、市场和运营的口径却完全不同。这会直接导致数据驱动的决策不一致。” —— 行业分析报告当一家企业的数据团队发现，他们维护着数百个名为“DAU”（日活跃用户）或“销售额”的指标，而每个指标的计算逻辑、统计周期或业务限定都略有不同时，这通常不是某个部门或个人的失误。相反，这是传统数据架构模式下的一个必然结果。在经典的“数仓+BI”模式中，业务需求驱动着漫长的物理开发链路：一个报表需求 → 数据工程师开发 ETL 任务 → 创建特定的物理宽表（DWS/ADS 层） → BI 工具连接该宽表生成报表。这种“为特定报表建特定宽表”的烟囱式开发，将指标逻辑固化并分散在了成百上千个物理表中。每一次新的分析视角，都可能催生一张新的宽表和一个“略有不同”的指标版本。这直接导致了数据分析的“不可能三角”：在口径一致、响应敏捷和深度洞察三者之间难以兼得。精确定义：什么才是真正的“指标口径混乱”？指标口径混乱并非一个模糊的概念，它特指同一业务术语在不同数据消费场景中，其核心语义要素存在不一致，从而导致决策依据相互矛盾。一个完整的指标定义包含四大语义要素，任何一处的差异都可能导致“混乱”：基础度量：核心的聚合计算，如COUNT(DISTINCT user_id)、SUM(order_amount)。统计周期：数据统计的时间范围，如“当日”、“近7日滚动”、“本财年至今”。业务限定：对数据范围的筛选条件，如“状态为‘已支付’”、“用户渠道为‘APP’”。衍生计算：基于基础度量的二次计算，如同环比、占比、排名。例如，市场部的“DAU”可能统计所有启动 APP 的设备，而财务部的“DAU”可能只统计完成至少一次有效交易的用户。这不仅仅是“活跃”定义的差异，更是基础度量（是否去重）和业务限定（是否包含交易行为）的双重不一致。核心要素：导致指标泛滥的三大“元凶”指标混乱现象是技术架构、组织协作和工具生态三个层面因素共同作用的“完美风暴”。要素一：烟囱式的物理宽表开发这是最根本的技术原因。每个分析需求都对应一张（或多张）物理宽表，指标逻辑被硬编码在 SQL 和表结构中。当业务规则变更（如“活跃”定义调整）时，需要追溯并修改所有相关的宽表，成本极高且极易遗漏，导致历史数据对比失真。要素二：部门墙与协作断层业务方、数据分析师与数据开发团队之间缺乏统一的协作语言和平台。需求通过邮件、会议口头传递，容易产生歧义。各部门为追求自身效率，在本地数据集或临时查询中定义“自己版本”的指标，形成组织内的“数据方言”。要素三：封闭的 BI 工具内置指标主流 BI 工具为提升易用性，内置了指标定义模块。然而，这些指标定义被绑定在特定的 BI 工具前端。当企业使用多套 BI 工具（如总部用 A，业务部门用 B），或需要向 AI 大模型、自建应用提供数据服务时，这些封闭的指标定义无法被复用，形成了新的“工具孤岛”。常见误区：关于指标治理的四个错误认知许多企业意识到问题，却采用了错误的方法，反而加剧了困境。误区错误本质导致的后果误区一：建一个指标字典就够了将指标治理等同于建立静态的元数据目录（Catalog）。目录与计算脱节，业务人员查阅字典后，仍需找开发人员从物理宽表中取数，口径落地依赖人工，无法保证一致性。误区二：强制统一所有报表采用行政命令，要求所有部门立即废弃原有报表，使用统一模板。忽视业务敏捷性，引发业务部门强烈抵触，治理行动难以推进，甚至催生更隐蔽的“影子报表”。误区三：选择一个BI工具统一天下试图通过采购单一BI厂商的全套方案来解决所有问题。被单一厂商绑定，丧失技术选型灵活性；无法适应不同场景的多样化需求（如 AI 调用、嵌入式分析）。误区四：指标治理是IT部门的事认为制定标准、维护口径是数据团队的技术职责。缺乏业务方的深度参与和共识，制定的标准脱离实际业务场景，治理成果无法在业务决策中落地。企业价值：终结指标混乱带来的四大收益解决指标口径问题，远不止于“统一语言”，它能直接转化为可量化的业务与技术收益。决策一致：基于同一事实决策，彻底避免部门间因数据“对不上”而产生的无谓争论与信任损耗，提升组织…

不要再纠结 LLM 准确率了：从“回答对不对”到“系统是否值得信任”
type: item
date: 2026-01-29T17:11:53+08:00
description: 生成式 AI 的投资回报远超预期？Snowflake 调研全球 1900 位企业与 IT 专业人士后发现平均 ROI 高达 41%！点击下载完整报告每个人都在努力提高大语言模型的精准度。但真正的挑战并非精度，而是上下文理解能力。在 BUILD 2025 大会上，Hex 合作伙伴工程负责人 Armin 探讨了为什么传统的方法，如评估套件或合成问题集往往不够有效，以及成功的 AI 系统是如何通过随着时间推移逐步积累上下文来构建的。由 Snowflake Cortex 提供支持的 Hex，启用了一个新的对话式分析模型，每次交互都让模型变得更聪明。通过 Hex 的 Notebook Agent 与 Threads 功能，业务用户可直接定义核心问题，而数据团队则将这些问题精炼、审计并转化为持久且值得信赖的工作流。在这个模型中，测试用例不再由数据团队闭门设计，而是由业务需求驱动并在数据工作流中自动实施，最终形成一个具有生命力的上下文系统，而非一成不变的提示词或测试集，它能随着组织共同演进。准确率不是终点Armin 开场就把矛头对准了一个常见做法：把业务用户会问的问题合成成一批样例，甚至进一步转成 SQL 查询，然后把这些喂给 LLM，用类似单元测试的方式去衡量它的准确率、稳定性与一致性。他不否认“准确性是顶层关注”，但他强调，把 LLM 当作传统软件组件来做单元测试，本身就是一个不合适的范式。原因在于，当你把业务问题硬转换为一组 SQL，并据此去构建样例与评估集时，你很难覆盖真实业务中不断变化的语义、不断扩张的问题空间，以及不同用户在不同语境下对同一指标的不同问法。更重要的是，即使你做出了一个看似通过率很高的测试集，也依然回答不了企业最在意的那件事：当它在真实环境中生成了一个结论，你如何知道它不是在胡编？你又如何知道它到底做了什么才得到这个结论？因此，Armin 把正确性从结果层拉回到系统层：你需要的不是一个靠样例证明自己正确的聊天机器人，而是一套可审计的系统，它能够随着时间变得灵活、可塑，能够让业务用户在使用中不断收敛可回答的问题类型，也能够让系统拥有被“硬化”的路径：哪些能力可以放开，哪些问题必须收紧，哪些定义需要固化，哪些数据应该进入上下文、哪些不应该。在他看来，真正有效的路线是：从一套能运行、能被观察的系统出发，让系统在使用中暴露问题、沉淀模式，再反过来加固上下文。这种思路听起来不如直接做评估来得爽快，但它更接近企业系统的真实生长方式。对话式分析如何变成“可审计的系统”为了把“可审计”讲得具体，Armin 用 Hex 的产品演示展示了对话式分析在真实系统中应该是什么形态。演示从一个非常典型的业务问题开始：假设我是营销经理，我想让系统分析销售机会的“首次触达来源”（first touch source），并做营销归因视角的拆解。这里一个很关键的动作，是他先在系统里配置模型提供方：通过密钥对（key pair）连接到 Snowflake 实例，使用 Snowflake Cortex 内托管的 Claude，并强调这是一个“walled garden”的私有网络环境。这样做的直接意义是：模型驻留在数据所在的环境里，数据可以传递给模型，同时也能让 IT 团队对数据出入边界更放心。进入线程后，Hex 并不是立刻吐出一句“结论”，而是在后台进行一系列用户不可见但决定可信度的步骤：它会先围绕可访问的元数据“思考”，查看平台上已有的 Hex 项目、仪表板或资产，判断是否存在可复用的内容；它会拉取来自数据仓库的表描述、列描述等元数据，并强调这些可以自动导入、不需要复杂配置；如果企业已经有 dbt 元数据，也可以进一步带入；随后它形成一个“漏斗式”的收敛过程：从广义元数据到相关表、再到更具体的模型信息与底层数据，最后才开始把 SQL 单元格、可能的 Python 单元格、图表与可视化逐步组织起来，用以回答最初的问题。这也解释了他在演示里专门强调的一个点：这种模式一开始会“慢”，但这是刻意设计的。因为此时系统面对的是生产数据仓库，它需要把大量上下文带进来，需要推理与迭代，而这类深度思考天然会以时间为代价。换来的收益是：它可以生成更细致、接近数据科学家或嵌入式数据分析师水平的分析过程。Armin 也提到，未来会有更偏“快速、短促回答”的迭代版本，可能更多依赖语义模型，而不是每次都在全量上下文里深挖。但在这个阶段，他们优先解决的是“在没有分析师介入的情况下，业务用户也能得到一份扎实的分析报告”。当线程生成结果后，界面里不仅有图表，还能继续做探索：拖拽维度与度量、查看底层表格数据、检查异常、做更深的切片。这时“可信度焦虑”就会自然出现：这么多信息暴露给业务用户，我怎么知道它没有幻觉？我该不该信这些 SQL？我如何让它更确定？Armin 的回答不是“相信模型”…

本周更新｜AI 对话支持复制粘贴文件
type: item
date: 2026-01-29T15:09:02+08:00
description: 原文链接：https://www.nocobase.com/cn/blog/weekly-updates-20260129汇总一周产品更新日志，最新发布可以前往我们的博客查看。NocoBase 目前更新包括的版本更新包括三个分支：main ，next和 develop。main ：截止目前最稳定的版本，推荐安装此版本。next：包含即将发布的新功能，经过初步测试的版本，可能存在部分已知或未知问题。主要面向测试用户，用于收集反馈和进一步优化功能。适合愿意提前体验新功能并提供反馈的测试用户。develop：开发中的版本，包含最新的功能代码，可能尚未完成或存在较多不稳定因素，主要用于内部开发和快速迭代。适合对产品功能前沿发展感兴趣的技术用户，但可能存在较多问题或不完整功能，不建议在生产环境中使用。mainv1.9.40发布时间：2026-01-25🚀 优化[Office 文件预览] 支持更多文件类型在微软在线预览工具中预览 (#8500) by @mytharcher🐛 修复[client]修复 nanoid 字段在表单提交后不重新生成数据的问题 (#8491) by @katherinehhh修复级联组件必填校验重复提示的问题 (#8476) by @katherinehhh[database]修复数据表重载后使用 empty 操作符筛选报错的问题 (#8496) by @2013xile修复嵌套关联的深度更新问题 (#8492) by @chenos[文件管理器] 修复上传文件时请求中的文件名被重复解码产生的乱码问题 (#8481) by @mytharcher[数据源：主数据库] 修复在多对多关系表格区块中删除数据时，未遵循关系字段 onDelete: 'restrict' 约束的问题 (#8493) by @2013xile[区块：iframe] 修复 Iframe 添加聚合变量报错的问题 (#8482) by @zhangzhonghe[工作流：Webhook 触发器] 修复未配置请求体解析时触发器数据中该数据缺失的问题 by @mytharcher[模板打印] 复了联合角色时打印按钮权限逻辑错误 by @jiannx[工作流：审批]修复并发提交导致流程被重复恢复执行的问题 by @mytharcher修复分支模式的审批未能正确退回至指定节点的问题 by @mytharcher[迁移管理] 修复迁移异常后打印异常对象所包含 SQL 过大容易卡死进程的问题 by @cgyrocknextv2.0.0-beta.17发布时间：2026-01-29🐛 修复[client] 修复筛选相关的已知问题 (#8514) by @zhangzhonghe[AI 员工] 修复构建后系统无法启动问题 (#8523) by @cgyrock[AI: 知识库] 修复构建后系统无法启动问题 by @cgyrockv2.0.0-beta.16发布时间：2026-01-27🎉 新特性[client] 新增子表格（弹窗编辑）字段组件 (#8280) by @katherinehhh[工作流] 为移动节点增加 API (#8507) by @mytharcher🚀 优化[client]修复单元格更新导致表格整体重渲染 (#8349) by @katherinehhh改进对多子表单默认包含一个对象，无需点击 Add New，未填写时不创建记录 (#8458) by @katherinehhh[文件管理器] 为文件管理器增加可扩展的预览组件 (#8501) by @mytharcher[工作流] 修改工作流子页面的路由路径，将工作流页面都统一在 /admin/settings/workflow 路径之下 (#8519) by @mytharcher🐛 修复[client]修复筛选区块日期带时间时时间格式重复的问题 (#8506) by @zhangzhonghe修复多层级对多字段子表单字段联动规则无法使用表单变量赋值的问题。 (#8518) by @gchust修复多级弹窗及跨区块数据变更后不刷新问题。 (#8471) by @gchust修复编辑表单中配置阅读态子详情数据不能正常显示问题 (#8469) by @katherinehhh修复targetKey 可选字段的处理逻辑 (#8333) by @katherinehhh修复编辑态子表格中关系字段 Select 的 filter 参数错误问题 (#8335) by @katherinehhh[flow-engine] 修复外部数据源 filterTargetKey 为单元素数组时 FilterByTK 处理错误 (#8522) by @katherinehhh[AI 员工] 修复 AI 建模与数据源管理…

告别拼凑：记忆、检索与AI数据引擎的一站式技术栈解析（一）
type: item
date: 2026-01-29T13:44:51+08:00
description: 作者：傅榕锋，OceanBase 高级技术专家AI 开发者需要什么样的数据库在开始正式话题前，我们不妨先思考一个问题： AI 时代下开发者需要什么样的数据库？自本世纪初以来数据库需求的演变历程。Web 2.0及业务在线化的时代，强调的是一个可靠、精确的记录系统，能够精准地记录每一笔交易数据，满足典型的事务处理（TP）需求。进入移动互联网和数据智能化时代后，随着数据量的爆发式增长，海量数据分析的需求成为主流。这时，分析型（AP）数据库开始占据重要位置。AI 时代的真正到来，驱动数据库不仅要支持查询和分析功能，更需具备理解和推理的能力。快来关注我，获取 OceanBase 第一手的产品信息和技术资源，与行业大咖 “唠” 出真知！AI 时代开发者的痛点作为数据库从业者，我们需要深入分析 AI 时代下开发者对数据库的具体需求。数据类型的多维化：在传统数据库中，图片、视频、音频仅能被存储而难以有效利用。借助 AI 模型的帮助，这些非结构化数据可以转化为可检索的形式，如通过嵌入模型转换为向量，或使用大语言模型提取文本描述和标签，从而将非结构化数据转变为结构化或半结构化数据以实现高效检索。性能与规模的极致化：鉴于向量数据对内存和磁盘资源的高占用特性，在成本与性能之间寻求最佳平衡显得尤为关键。为此，亟需采用高效的算法，以优化召回率与资源成本之间的权衡关系。智能处理的内生化：例如，在 RAG 场景中，文档需先进行切片并生成向量，这通常涉及向量数据库、文档型数据库以及事务型数据库的联合使用。为了简化这一流程，理想的解决方案是让数据库自身承担更多的标准化数据处理任务，减少开发者的负担。开发流程的敏捷化：目标是让开发者更加专注于业务逻辑本身，而非陷入复杂的数据处理流程之中。AI 时代的理想数据库基于上述痛点，AI 时代的理想数据库应具备以下四个特征。多模态支持：提供统一的平台，支持多种数据类型，包括但不限于向量、全文、标量、 JSON 格式。高性能引擎：针对 AI 工作负载进行优化，确保在控制成本的前提下实现最优性能表现。智能化集成：内置 AI 运行时环境，使数据库可以直接执行复杂的智能处理任务，减少对外部系统的依赖。简易操作：设计直观易用的界面和工具，降低非专业开发者的使用门槛，促进更多领域专家参与到数据处理工作中。综上所述， AI 时代我们期待的数据库应该是强大、智能、一体化的，是数据与 AI 融合的平台。AI原生的一体化数据库是否存在正所谓“需求决定市场”，契合AI时代理想数据库特质的产品必然会出现。而就目前来看，OceanBase 新发布的 seekdb 已率先落地，不仅具备了相关核心能力，更在快速迭代中持续进化。混搜架构的轻量级、多模态的AI原生数据库OceanBase seekdb 是一款面向 AI 场景的轻量级、多模态的原生数据库，专为支持混合搜索、上下文理解与智能数据处理而设计。其整体架构分为五个核心层级，实现从数据存储到查询执行的全链路优化。1. 统一应用接口层。seekdb提供基于 SQL 的统一查询语言，兼容标准 SQL 语法，支持多模态数据的联合查询。同时，提供面向开发者的 Python SDK，具备简洁易用的 API 接口，支持 skip-by-list 等高效检索模式，显著降低开发者使用门槛。2. 支持混合负载的多模计算层。继承自 OceanBase 的成熟优化器体系，seekdb具备强大的查询规划与执行能力，在混合检索场景中，会自动进行自适应执行和查询优化，能够根据查询条件自动选择最优执行路径。同时，支持混合负载自适应执行、AI 函数调用、ACID 事务保障及灵活 UDF 扩展，满足复杂业务需求。3. 多模数据层。支持多种数据类型统一存储，实现“存即能检”，打破传统系统中不同数据类型需分库管理的局限。包括：关系表（传统结构化数据）向量（Embedding 向量）文本（原始文本内容）JSON（半结构化数据）GIS（地理空间数据）数组、位图等扩展类型4. 多模索引层。构建业界领先的多模索引体系，支持的索引类型如下。向量索引：高效支持近邻搜索（ANN），兼顾精度与性能。全文索引：支持中文分词与语义匹配。混合索引：结合向量与标量条件进行联合检索。JSON 索引：加速嵌套字段查询。二级索引、GIS 索引：满足多样化查询需求。支持多索引协同查询，在一次请求中完成跨模态数据的融合检索。5. 部署模式层。服务器模式：传统集群部署，适用于高并发、大规模生产环境。嵌入式模式：以库的形式内嵌于应用程序中，生命周期与应用一致，适合边缘计算、AI 应用快速构建等轻量化场景。OceanBase seekdb 通过“统一接口 + 多模存储 + 智能索引 + 灵活部署”的一体化设计，实现了对 AI 工作负载的端到端支持，真正做到了“一个数据库，搞定所有…

MyBatis Dynamic SQL 入门指南
type: item
date: 2026-01-27T16:32:10+08:00
description: MyBatis Dynamic SQL 是一种类型安全的 Java 领域特定语言（DSL），用于通过编程方式构建 SQL 查询，而非编写 SQL 字符串或基于 XML 的动态查询。它在运行时使用流畅的 Java 构建器生成 SQL，同时仍通过标准的 MyBatis 映射器执行。与手动拼接字符串或复杂的 XML 逻辑相比，这使得查询构建更安全、更易于重构，并且更不容易出错。由于查询是用 Java 编写的，列名和表引用通过强类型的元数据类在编译时进行验证，这提供了更好的 IDE 支持并减少了运行时 SQL 错误。本文将解释 MyBatis Dynamic SQL，并展示如何在 Java 应用程序中使用它。1. 使用 MyBatis Dynamic SQL 可以做什么？MyBatis Dynamic SQL 支持大多数常见的 SQL 操作，包括 SELECT、INSERT、UPDATE 和 DELETE，以及连接、子查询、分页、排序、条件过滤和批量操作。它允许我们逐步构建查询，仅在某些参数存在时添加条件，这使其成为搜索界面和过滤 API 的理想选择。它直接与 MyBatis 映射器接口集成，意味着我们仍然可以受益于结果映射、事务处理和连接管理。由于它生成标准的 SQL，因此适用于 MyBatis 支持的任何数据库，没有供应商锁定的问题。1.1 MyBatis Dynamic SQL 的工作原理Dynamic SQL 基于两个组件：表元数据类和 DSL 构建器。元数据类用 Java 描述表和列。DSL 构建器使用这些类以流畅、类型安全的方式组装 SQL 语句。DSL 不直接执行 SQL。相反，它生成语句提供者对象，例如 SelectStatementProvider 或 InsertStatementProvider。这些对象被传递给使用 @SelectProvider、@InsertProvider 及类似注解标注的映射器方法，然后 MyBatis 使用其正常的执行引擎来执行这些语句。2. 项目设置与依赖Maven 依赖<dependency> <groupId>org.mybatis</groupId> <artifactId>mybatis</artifactId> <version>3.5.15</version> </dependency> <dependency> <groupId>org.mybatis.dynamic-sql</groupId> <artifactId>mybatis-dynamic-sql</artifactId> <version>1.5.2</version> </dependency> <dependency> <groupId>com.h2database</groupId> <artifactId>h2</artifactId> <version>2.4.240</version> <scope>runtime</scope> </dependency>这些依赖项包括 MyBatis 本身、Dynamic SQL DSL 以及一个用于测试的嵌入式数据库。注意数据库驱动可以替换为 MySQL、PostgreSQL 或任何其他支持的数据库。MyBatis Dynamic SQL 不依赖于数据库类型，仅依赖于标准 SQL 生成。数据库模式schema.sqlCREATE TABLE users ( id BIGINT AUTO_INCREMENT PRIMARY KEY, username VARCHAR(50) NOT NULL, email VARCHAR(100), age INT ); INSERT INTO users(username, email, age) VALUES ('thomas', 'thomas@jcg.com', 30), ('benjamin', 'benjamin@jcg.com', 22), ('charles', 'charles@jcg.com', 17);此脚本创建一个简单的表并插入测试数据。内存中的 H2 数据库将在启动时执行此脚本，因此无需外部依赖即可测试查询。领域模型public class User { private Long id; private String username; private String email; private Integer age; // Getter 和 Setter 方法... }这个 POJO 代表数据库中的一行。MyBatis 会自动使用匹配的字段名将列映射到字段，因此本例不需要额外的结果映射。3. 用于 Dynamic SQL 的表元数据下面的类以类型安全的方式定义数据库表及其列，允许在构建查询时被 …