AI 时代，数据库已成为智能 Agent、RAG 系统、大模型应用和 AI 可观测平台 的基础设施。它不仅要能存结构化数据，更要能承载长上下文、向量、全文、Trace、事件流等新型数据。不仅要能分析，更要能实时检索、混合召回、在线服务和系统治理。
如果说 Apache Doris 4.0 开始顺应这一趋势，那么 Apache Doris 4.1，则是真正面向这一趋势完成了系统性演进。
这是一个面向 AI & Search 场景深度演进的重要版本。它不只是新增某几个功能，而是围绕 AI 应用落地过程中最核心的几类问题，给出了更完整、更统一的解决方案：
如何低成本存储海量 AI 数据
如何把结构化过滤、全文检索、向量检索统一在一个系统里
如何承载百万 Token 长上下文与超宽半结构化数据
如何支撑模型服务、Agent、RAG 的实时查询与可观测分析
如何继续保持 Doris 一贯领先的 OLAP 性能与湖仓能力
如何支撑 ETL 大规模离线计算与实时处理协同统一
GitHub 下载：https://github.com/apache/doris/releases 官网下载：https://doris.apache.org/download
4.1 版本将结构化查询、全文检索与向量搜索，进一步整合到统一 SQL 和统一存储体系中。
在 4.1 中，Doris 在向量索引和向量查询性能上有明显增强，其目标是让向量检索可规模化生产部署。
在性能方面，Doris 4.1 引入了 Ann Index Only Scan 优化，使向量搜索在执行过程中可以完全避免对原始列的 I/O 读取，从而显著降低查询开销。得益于这一优化，向量索引查询性能相比 4.0 提升最高可达 4 倍。
在典型测试环境（100 万向量规模、16 核 CPU、64GB 内存）下，Doris 可实现约 900QPS，同时保持 97% 的召回率，已能够稳定支撑绝大多数生产级向量检索场景。
根据 VectorDBBench 公布的数据（截至 2026 年 1 月），Doris 在索引构建速度上优于 Milvus、Qdrant、pgvector 等系统，这一优势主要得益于其数据分层架构。
在功能新增及优化上，主要聚焦于大规模数据处理及使用成本。接下来，将对这些关键能力进行详细介绍。
IVF 是大规模高维向量检索中最经典的 ANN 算法之一，核心思路是“先聚类分桶，再局部搜索”。相比 4.0 的 HNSW，IVF 可以在接受少量召回率损失的前提下，用更低的内存支撑更大规模的向量数据。
在生产环境中，其价值体现：
同样机器资源下，能支撑更大向量规模
内存成本显著下降
更适合大规模向量检索场景的落地
简要示例：如需使用 IVF 索引，请在索引属性中设置"index_type"="ivf"。
CREATE TABLE sift_1M ( id int NOT NULL, embedding array<float> NOT NULL COMMENT "", INDEX ann_index (embedding) USING ANN PROPERTIES( "index_type"="ivf", "metric_type"="l2_distance", "dim"="128", "nlist"="1024" ) ) ENGINE=OLAP DUPLICATE KEY(id) COMMENT "OLAP" DISTRIBUTED BY HASH(id) BUCKETS 1 PROPERTIES ( "replication_num" = "1" );
很多向量检索系统（如 Faiss）在千万级数据规模还能保持性能，但一旦进入百亿甚至更大规模，索引全内存的模式就会迅速推高成本。
Apache Doris 基于 IVF 进一步实现了 IVF_ON_DISK（优化方式参考 SPANN 论文）。通过内存缓存 + 本地文件系统缓存结合，以极低的成本实现了高效的向量剪枝。
在存算分离架构下，可实现低成本、高性能的超大规模向量剪枝与召回。
相比 DiskANN，更低索引构建开销，给万亿级别向量搜索提供了切实可行的新路径。
更适合 AI 知识库、推荐召回、海量 embedding 检索等场景
使用 IVF_ON_DISK 几乎与使用 IVF 相同：只需指定"index_type"="ivf_on_disk"即可。
CREATE TABLE for_ivf_on_disk ( id BIGINT NOT NULL, embedding ARRAY<FLOAT> NOT NULL, INDEX idx_emb (embedding) USING ANN PROPERTIES ( "index_type"="ivf_on_disk", "metric_type"="l2_distance", "dim"="128", "nlist"="1024" ) ) ENGINE=OLAP DUPLICATE KEY(id) DISTRIBUTED BY HASH(id) BUCKETS 8 PROPERTIES ("replication_num" = "1");
除了索引算法，Doris 还支持多种向量量化方式，包括：
INT8 标量量化
INT4 标量量化
Product Quantization( PQ)
这些能力可以在略微牺牲召回率的情况下，将索引内存占用压缩到原来的 1/4 到 1/8。配合 IVF_ON_DISK，可以进一步降低大规模向量检索的机器成本。
以下示例展示了对 128 维向量进行 PQ 压缩的 DDL：
CREATE TABLE product_quant ( id BIGINT NOT NULL, embedding ARRAY<FLOAT> NOT NULL, INDEX idx_emb (embedding) USING ANN PROPERTIES ( "index_type"="ivf_on_disk", "metric_type"="l2_distance", "dim"="128", "nlist"="1024", "quantizer"="pq", "pq_m"=64, "pq_nbits"=8 ) ) ENGINE=OLAP DUPLICATE KEY(id) DISTRIBUTED BY HASH(id) BUCKETS 8 PROPERTIES ("replication_num" = "1");
如果说向量能力解决的是“语义召回”，那么全文搜索解决的是“关键词精确定位、故障排查、日志搜索、文本分析”等场景。Doris 4.1 新增的 search() 函数，将全文搜索能力直接嵌入 SQL 中，一条 SQL 同时完成搜索过滤与聚合分析。
兼容 ES query_string 风格语法，迁移十分简单。
内置支持 TERM、PHRASE、WILDCARD、REGEXP、PREFIX、NOT、NESTED 等丰富算子，并支持任意嵌套组合
内置 BM25 相关性打分，存储层 TopN 优化，避免全量结果传输
支持嵌套搜索（Nested），配合 VARIANT 类型，可在嵌套 JSON 数组内部搜索
支持多字段搜索，支持 best_fields（精确匹配同一字段）和 cross_fields（跨字段分散匹配）两种策略。
典型用例：
-- Multi-condition: TERM + PHRASE + NOT evaluated in a single pass SELECT request_id, error_msg, latency_ms FROM inference_logs WHERE search(' level:ERROR AND error_msg:"CUDA out of memory" AND NOT module:healthcheck AND model_name:gpt* ') AND log_time > NOW() - INTERVAL 1 HOUR ORDER BY latency_ms DESC LIMIT 100; -- BM25 relevance scoring SELECT request_id, error_msg, score() AS relevance FROM inference_logs WHERE search('error_msg:"memory allocation failed" OR error_msg:"CUDA error"') ORDER BY relevance DESC LIMIT 20; -- Nested search: query inside a VARIANT array SELECT * FROM agent_logs WHERE search('NESTED(steps, status:error AND tool:code_exec)'); -- search + aggregation: filter and analyze in one query SELECT model_name, COUNT(*) AS error_count, PERCENTILE_APPROX(latency_ms, 0.99) AS p99_latency FROM inference_logs WHERE search('level:ERROR AND error_msg:"CUDA out of memory"') AND log_time > NOW() - INTERVAL 1 HOUR GROUP BY model_name ORDER BY error_count DESC;
search()返回一个布尔谓词，该谓词直接参与连接、窗口函数和子查询，从而使全文搜索成为 SQL 的标准组成部分。
在长上下文、多轮对话、RAG 和 AI Agent 等场景中，将完整交互生命周期作为单个文档存储，已成为实际需求。
Apache Doris 4.1 原生支持单行最大 100MB JSON 文档，可将完整 AI 会话数据直接存储在数据库中，包括多轮对话、长文档文本、音视频转录、Agent 执行轨迹、工具调用日志以及 RAG 上下文等，均无需拆分、无需截断，也无需依赖外部存储。
这些超大文档在写入后，可以像普通数据一样被直接查询与分析，支持过滤、条件查询、聚合以及 JOIN 等操作。大型 AI 上下文数据变成了可管理、可查询、结构化的数据资产。
依托 Doris 百万 Token 超大文本能力，带来显著变化包括：
消除对独立对象存储的依赖
移除元数据和原始内容之间的一致性维护逻辑
消除分段存储和重新组装的开发开销
实现更低的查询延迟、更强的事务性保证和更简单的运维足迹
在 Search & AI 场景中，数据往往具有超宽、稀疏、半结构化的特点，这类数据字段数量多、变化快，同时存在明显的冷热分化，对随机读、点查和高并发写入都有很高要求。
在 4.1 之前，Doris 使用 Segment V2 存储格式，将元数据集中在文件尾部（Footer）。这种设计在批量扫描场景表现良好，但在随机读取和小范围查询时，每次都需要加载完整元数据，带来额外 I/O 和解析开销，影响性能。
为此，Doris 4.1 引入 Segment V3，借鉴了 Lance 以及 Vortex 等新型文件存储格式的做法，将元数据从 footer 中分离，按需加载，解决万列场景下最容易碰到的元数据膨胀、文件打开慢和随机读开销问题。适用于超宽表、大量 VARIANT 子列、对象存储冷启动敏感、随机读较多的 AI 和车联网半结构化数据场景。
以一张包含 7,000 列、10,000 个 Segment 的超宽表为例。在 Segment 打开阶段，V3 相比 V2 实现了显著提升：
打开速度提升最高达 16 倍
内存占用降低最高达 60 倍
在超宽表和高并发访问场景中，这意味着更快的响应速度与更低的资源成本。
如何启用：在表属性中指定"storage_format" = "V3"。
CREATE TABLE table_v3 ( id BIGINT, data VARIANT ) DISTRIBUTED BY HASH(id) BUCKETS 32 PROPERTIES ( "storage_format" = "V3" );
参考文档： https://doris.apache.org/zh-CN/docs/4.x/table-design/storage-format
针对宽 JSON 中“热点 path 少、长尾 path 多”的特点，Doris 4.1 优化了 sparse 读取链路，避免长尾路径集中在单列带来的性能瓶颈。
冷热分层：热点 path 保留为列式子列，长尾 path 进入 sparse 存储，避免子列膨胀
Sparse Sharding：通过variant_sparse_hash_shard_count将长尾 path 分散到多个 sparse 列，降低单列读放大
Sparse Cache：为 sparse 列增加缓存，减少重复 I/O、解码与反序列化开销
适用于广泛的 JSON 数据，如车联网、用户画像、埋点日志等超宽 JSON 场景（字段数量极多，其中只有几十到几百个路径会被频繁查询）。
使用示例：
CREATE TABLE user_feature_wide ( uid BIGINT, features VARIANT< 'user_id' : BIGINT, 'region' : STRING, properties( 'variant_max_subcolumns_count' = '2048', 'variant_sparse_hash_shard_count' = '32' ) > ) DUPLICATE KEY(uid) DISTRIBUTED BY HASH(uid) BUCKETS 32 PROPERTIES ( "storage_format" = "V3" );
参考文档：
当半结构化数据更关注写入效率或整条 JSON 返回时，DOC 模式是更合适的选择。它保留原始 JSON，并将子列提取延迟到 compaction 阶段，从而降低写入成本、减少写放大。
延迟物化：写入阶段不立即展开子列，降低小批量写入开销。
DOC Sharding：通过 variant_doc_hash_shard_count 对 Doc Store 分片，提升整条 JSON 返回与 path 提取性能。
物化阈值控制：用 variant_doc_materialization_min_rows 控制物化阈值，低于阈值的数据延迟处理，统一在 compaction 阶段完成。
适用于 AI/LLM 输出、Trace、上下文快照、事件回放等需要频繁读取完整文档的场景。
如何配置：
使用时开启 variant_enable_doc_mode，并结合数据规模配置物化阈值与分片数；与 sparse 模式互斥，建议二选一，并配合 storage_format = "V3" 使用。
CREATE TABLE trace_archive ( ts DATETIME, trace_id STRING, span VARIANT< 'service_name' : STRING, properties( 'variant_enable_doc_mode' = 'true', 'variant_doc_materialization_min_rows' = '100000', 'variant_doc_hash_shard_count' = '32' ) > ) DUPLICATE KEY(ts, trace_id) DISTRIBUTED BY HASH(trace_id) BUCKETS 32 PROPERTIES ( "storage_format" = "V3" );
参考文档：
查询性能直接影响分析吞吐量、基础设施成本和业务响应时间，Apache Doris 4.1 在这一方向持续演进：通过减少无效计算、降低数据流动、提升执行效率，让复杂查询在真实场景中依然保持高性能。
1、多表分析场景中
在多表连接和聚合性能标准基准测试中，Doris 4.1 相比 4.0 有较好的提升：
SSB 提升 14.3%。
TPC-H 提升 22.6%
TPC-DS 提升 19.1%
2、宽表分析场景中
ClickBench 使用 100GB 的数据量和 43 个复杂查询，对列式存储、向量化执行和压缩性能进行压力测试，是业内要求最高的单表基准测试之一。
在 c7a.metal-48xl 实例测试，Apache Doris 4.1 在冷查询性能和存储空间方面排名第一。其总分排名第二，仅次于 ClickHouse（web）。
冷查询：
综合得分：
这些性能表现得益于 4.1 的系统性演进，接下来介绍较为重要的优化点。
通过 Aggregate Pushdown Through Join 将高聚合率算子拆分并下推到 Join 两侧，先对单表数据进行局部聚合，再进行关联，最后完成全局聚合。这种“先压缩、再关联”的方式，从源头减少参与 Join 的数据量，显著降低内存占用与计算延迟。
基准测试集上，整体性能提升超过 200%。超过半数的测试用例提升超过 50%。近三分之一的测试用例提升超过 100 倍。
通过智能识别最细粒度聚合组及其聚合率，在满足条件时，将执行方式从“多组并行聚合”调整为：先完成最细粒度聚合，大幅缩减数据规模，再基于结果计算其他聚合组，从而显著降低计算延迟。
基准测试集上，整体性能提升超过 10%。超过 1/5 的测试用例改进幅度超过 20%，最大改进幅度为 160%，最大回退低于 5%。
嵌套列裁剪可精确解析嵌套字段结构。当查询仅涉及某个子字段时，仅读取对应数据，跳过无关字段，从而显著减少 I/O 开销。在 Apache Doris 4.1 中，嵌套列剪枝适用于内部表以及外部 ORC 和 Parquet 数据。
基准测试集上，整体性能提升超过 60%。在个别场景下，提升幅度超 700%。
在大规模分析中，查询通常会在多次执行中重复使用相同的过滤条件，例如：
SELECT * FROM orders WHERE region = 'ASIA'; SELECT count(*) FROM orders WHERE region = 'ASIA';
这些查询在相同的段上反复执行相同的过滤逻辑，从而浪费了 CPU 和 I/O 资源。
Condition Cache 通过缓存条件在 Segment 上的过滤结果，在后续查询中直接复用，减少重复扫描与计算。复杂查询场景下整体性能提升超过 10%。
参考文档：https://doris.apache.org/docs/4.x/query-acceleration/condition-cache
在分析型工作负载中，相同的聚合查询通常会针对未更改的数据反复执行，例如：
SELECT region, SUM(revenue) FROM orders WHERE dt = '2024-01-01' GROUP BY region;
每次执行都会扫描相同的分片并重新计算相同的聚合结果，从而浪费 CPU 和 I/O。
Query Cache 会缓存执行过程中的中间聚合结果，当查询上下文一致时直接返回缓存结果，大幅降低计算与 I/O 开销。
参考文档：https://doris.apache.org/docs/4.x/query-acceleration/query-cache
Case When 是分析场景中的核心语法，用于实现复杂业务逻辑与多维条件计算。
Apache Doris 4.1 版本通过引入分支合并，分支消除，公共子表达式提取，枚举值提取和下推等优化手段。显著提升了包含 Case When 语句的执行表现。
基准测试集上，平均性能提升超过 200%。在个别场景下，提升幅度超过 50 倍。
Apache Doris 的存算分离架构目前已有超过 2000 家企业用户。随着采用率的增长，稳定性和查询性能已成为主要关注领域。4.1 版本持续投入深度优化，不断打磨架构可靠性与执行效率。
支持 File cache 元数据持久化，避免了早期版本在启动阶段重建缓存状态所带来的大量 I/O 开销。同时新增系统表information_schema.file_cache_info，通过 SQL 即可查看块级缓存明细，支持按 tablet_id、be_id、cache_path、type 等维度查询，帮助用户快速定位热点数据、缓存倾斜和异常膨胀问题。
典型用法 1：定位缓存明细，查看单个 Tablet 的缓存构成
mysql> select * from information_schema.file_cache_info where TABLET_ID = 1761571031445; +----------------------------------+---------------+-------+--------+-------------+-----------------+---------------+ * HASH * TABLET_ID * SIZE * TYPE * REMOTE_PATH * CACHE_PATH * BE_ID * +----------------------------------+---------------+-------+--------+-------------+-----------------+---------------+ * 468448215c52334ae5bee147259b1027 * 1761571031445 * 15120 * index * * /mnt/disk1/project/filecache * 1761571031251 * * 71bb73d34cd8ffe280b16dd329df5ba1 * 1761571031445 * 13117 * index * * /mnt/disk1/project/filecache * 1761571031251 * * 77c6b69d1a7c4fe740a11bab5c1bbaa3 * 1761571031445 * 12249 * index * * /mnt/disk1/project/filecache * 1761571031251 * +----------------------------------+---------------+-------+--------+-------------+-----------------------------------------------------------------------------+---------------+
典型用法 2：聚合分析缓存分布，评估节点间缓存均衡性与资源占用情况
SELECT be_id, tablet_id, type, SUM(size) AS cache_bytes FROM information_schema.file_cache_info WHERE tablet_id = 1761571031445 GROUP BY be_id, tablet_id, type ORDER BY cache_bytes DESC;
弹性伸缩：在存算分离模式下，百万级分片的扩缩容操作可在几分钟内完成。调度机制不再依赖全局分片数量，显著提升整体弹性能力。
冷查询优化：基于 Doris 页面扫描语义引入预取机制，提升内部表冷查询性能。通过参数调优，可更充分利用远端存储带宽，获得更优 I/O 表现。
大规模部署优化：对 FE 中的副本与表对象进行精简，在百万级规模下，FE 内存使用量降低 30%+。
Meta-service 性能优化：通过引入缓存机制，减少对 Meta Service 的重复请求，提升元数据访问吞吐。同时优化了存算分离模式下部分系统表的访问路径。
对象存储成本优化：在高频导入场景下，通过节点级请求合并，减少对象存储请求次数及小文件数量，整体成本最高可降低 90%。
列压缩与编码优化：引入更高效的二进制编码与预解码机制，降低运行时解码成本；默认压缩逐步切换至 ZSTD，在压缩率与解压性能之间取得更优平衡。在宽表与明细查询场景中，体现为更低存储占用与更优冷读性能。
4.1 在数据湖方向实现了重要升级，从格式支持、查询性能到生态兼容性，全面增强 Doris 作为统一湖仓分析引擎的能力。用户无需依赖 Spark 等外部引擎，仅通过 Doris SQL 即可完成 Iceberg、Paimon 等主流湖格式数据的读写与管理。
Apache Doris 4.1 为主要的开放湖格式添加了完整的生命周期管理。表创建、数据插入、更新和删除都可以通过 Doris SQL 进行操作，这是一个涵盖整个数据湖工作流程的单一引擎。
Iceberg V2/V3 完整支持：支持 INSERT、UPDATE、DELETE、MERGE INTO 等操作，并支持 Iceberg V3 中的 Deletion Vector、Row Lineage 等特性，实现数据摄入、更新与删除的全流程闭环，无需依赖外部引擎。
Paimon 库表管理：支持通过 SQL 直接进行库表管理（CREATE DATABASE / TABLE 等），后续版本将进一步支持写入能力。
参考文档：
引入了多项针对性的优化手段，显著提升了湖上数据的查询性能。
Iceberg 排序写入：支持按指定列排序写入数据，并生成排序元信息（lower/upper bounds），查询时可高效裁剪无关数据文件。在 TPC-DS 测试中，查询性能提升约 15%。
Iceberg Manifest 缓存：新增 Manifest 级元数据缓存，避免查询规划阶段对 Manifest 的重复读取与解析，显著降低 I/O 与 CPU 开销。在高频查询场景下，复杂元数据解析延迟可降至百毫秒级。
Parquet Page Cache：新增 Page Cache，将已解压的数据页缓存到内存，减少重复解压与磁盘 I/O。在高频查询场景下显著降低延迟，ClickBench 测试中整体性能提升约 20%。
参考文档：
在 4.1 版本中，Doris 进一步增强了数据互操作性与易用性：
缓存准入控制：通过多维规则（用户、Catalog、Database、Table）精细控制缓存写入，避免冷数据挤占缓存，提升热点数据命中率；规则以 JSON 文件存放于指定目录，修改后自动生效，无需重启 FE 节点。支持 EXPLAIN 可观测，便于调优
MaxCompute 数据写入：支持在 MaxCompute 外部 Catalog 中执行建表与写入操作，打通 Doris 向 MaxCompute 的数据导出链路，并支持 ARN 跨账号访问，实现与阿里云生态的高效集成。
Parquet 元数据探查：新增 Parquet 元数据 TVF，支持通过 SQL 查询分区、Row Group、列统计等信息，便于排查文件结构问题、验证分区裁剪及优化查询性能。
参考文档：
持续推进实时在线一体化，在同一引擎内统一支持交互式分析与大规模批处理，减少多系统架构复杂度。本版本进一步增强原生 ETL/ELT 能力：
MERGE INTO
支持通过单条标准 SQL MERGE INTO 完成 INSERT / UPDATE / DELETE（UPSERT），简化增量数据（如 CDC）合并流程，降低开发与维护成本。
MERGE INTO target t USING source s ON t.id = s.id WHEN MATCHED THEN UPDATE SET t.value = s.value WHEN NOT MATCHED THEN INSERT (id, value) VALUES (s.id, s.value);
Spill to Disk 增强
面向大表 Join、高基数聚合、全局排序等内存敏感场景，全面强化溢写能力：
支持多层级递归溢写（Recursive Spill），避免内存峰值压力。
全面覆盖 Join、Aggregation、Sort 等核心算子
动态触发溢写，平衡内存使用与磁盘 IO，保障查询稳定性。
在该机制增强下，Doris 实现了关键突破：单个 BE 节点 + 8GB 内存即可完成 TPC-DS 10TB 全量查询，进一步验证了其在大规模分析场景下优于 Hadoop、Greenplum、Spark 等传统方案，以更低资源成本提供更强查询性能。
Doris 4.1 在易用性上进一步增强，补齐关键分析语法，提升复杂场景下的表达能力，跨系统兼容性。
UNNEST：原生支持UNNEST 语法，简化 JSON、日志等半结构化数据中 ARRAY 或嵌套结构的分析流程，避免复杂函数改写。
SELECT user_id, tag FROM user_profile, UNNEST(tags) AS t(tag);
递归公用表表达式（Recursive CTE）：支持递归查询，适用于组织树、层级结构、图路径等场景，实现更灵活的数据遍历与关系分析。
WITH RECURSIVE org_tree AS ( SELECT id, parent_id, name FROM org WHERE parent_id IS NULL UNION ALL SELECT o.id, o.parent_id, o.name FROM org o JOIN org_tree t ON o.parent_id = t.id ) SELECT * FROM org_tree;
ASOF JOIN：支持ASOF JOIN，可按时间“最近匹配”的关联查询（<= / >=），适用于金融、IoT、监控等时序场景，实现数据对齐与最近值匹配。
SELECT t1.ts, t1.value, t2.price FROM trades t1 ASOF JOIN prices t2 ON t1.symbol = t2.symbol AND t1.ts >= t2.ts;
S3 持续导入：支持基于 S3 文件源创建持续导入 Job，系统可自动发现新增文件并持续执行导入，适用于对象存储场景下的增量数据接入。
MySQL / PostgreSQL 实时同步：支持 MySQL 和 PostgreSQL 数据库变更实时接入 Doris，覆盖全量初始化与后续增量同步，可帮助用户更便捷地构建数据库到 Doris 的实时分析链路，满足业务库实时数仓、数据汇聚和分析加速等场景需求。
文档：
自适应写入调度：支持自适应调整 MemTable Flush 线程池规模，可根据集群实时负载自动匹配更合适的写入并发度，在高写入场景下更好兼顾吞吐、资源利用率与稳定性。
主键模型多流合并更新（sequence-aware）：支持通过 sequence_mapping 实现多流合并更新。不同数据流可分别更新同一张表的不同列，并按各自顺序字段完成合并，适合实时流更新与离线补数并行写入的场景。
Routine Load 增强：支持 flexible partial update，实现非主键列的按需更新；支持动态参数调整与自适应批处理，提升高吞吐场景稳定性。
导入审计可观测性：支持将 Stream Load 记录写入审计日志系统表，便于统一查询导入历史、排查问题和做审计分析。
在全球化与多时区场景（如跨地域日志、用户行为分析、金融交易）中，时间数据往往携带明确时区信息。传统使用无时区的 DATETIME 类型，需要在应用层手动处理转换，易出错且增加开发成本。
Doris 4.1 引入 TIMESTAMPTZ（TIMESTAMP WITH TIME ZONE），提供标准化的时区时间支持：
统一存储：写入时将时间转换为 UTC 存储
自动转换：查询时根据会话时区自动转换展示
灵活输入：支持带时区或无时区时间输入，自动完成解析与转换
类型兼容：支持与 DATETIME 相互转换，并兼容现有函数使用
该设计将时区处理从应用层下沉至数据库内核，提升跨系统数据一致性，降低多时区数据处理复杂度。
Apache Doris 4.1 是面向 AI 时代的一次重要数据基础设施能力演进。从向量检索、长上下文存储，到混合检索与统一分析能力，Doris 正在逐步构建更完整的数据处理闭环。
如果你正在探索 AI 应用落地、实时分析或湖仓一体化架构，欢迎进一步了解 Apache Doris，并在实际场景中进行验证：
官网文档：https://doris.apache.org GitHub：https://github.com/apache/doris
对于希望在生产环境中获得更稳定性能与企业级支持的用户，也可以了解基于 Apache Doris 构建的云原生产品 SelectDB（www.selectdb.com），在弹性扩展、运维效率和大规模部署方面提供更完善的支持。
微信关注我们
转载内容版权归作者及来源网站所有！
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长，特征是大鼻子、头戴帽子、身穿背带裤，还留着胡子。与他的双胞胎兄弟路易基一起，长年担任任天堂的招牌角色。
为解决软件依赖安装时官方源访问速度慢的问题，腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构，目前腾讯云软件源站支持公网访问和内网访问。
Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称，一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。
Spring框架（Spring Framework）是由Rod Johnson于2002年提出的开源Java企业级应用框架，旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念，提供核心容器、应用上下文、数据访问集成等模块，支持整合Hibernate、Struts等第三方框架，其适用范围不仅限于服务器端开发，绝大多数Java应用均可从中受益。
扫码在手机上查看文章
扫描二维码，手机阅读更方便
有任何问题或合作意向欢迎联系我们
Email: 99873273@qq.com
QQ: 99873273