Apache Druid 是一个分布式的、支持实时多维 OLAP 分析的数据处理系统。它既支持高速的数据实时摄入处理，也支持实时且灵活的多维数据分析查询。因此 Druid 最常用的场景就是大数据背景下、灵活快速的多维 OLAP 分析。Druid 还有一个关键的特点：它支持根据时间戳对数据进行预聚合摄入和聚合分析，因此也有用户经常在有时序数据处理分析的场景中用到它。
Apache Druid 26.0.0 现已发布，此版本包含来自 65 个贡献者的 390 多个新功能、错误修复、性能增强、文档改进和额外的测试。建议用户在升级到 Druid 26.0.0 之前，先查看升级说明和不兼容的更改。
更新亮点如下：
Auto type column schema（实验性）
作为嵌套列功能的下一个逻辑迭代，新的"auto" type column schema 和索引器已添加到本机摄取中。这种自动类型的列索引器可为给定的输入生成最合适的列，生成STRING、ARRAY<STRING>、LONG、ARRAY<LONG>、DOUBLE、ARRAY<DOUBLE>或COMPLEX<json>列，所有这些都共享一个通用的“嵌套”格式。
“auto”生成的所有列都有索引以帮助快速过滤（与经典LONG和DOUBLE列不同），并使用基于 cardinality 的阈值，尝试仅在可能实际加速查询时才使用这些索引（与经典 STRING 列不同）。
此“auto”索引器生成的COMPLEX<json>列存储简单标量类型的数组与其“json”（v4）对应物不同，将它们存储为 ARRAY 类型的列。这意味着该JSON_VALUE函数现在可以提取整个数组，例如JSON_VALUE(nested, '$.array' RETURNING BIGINT ARRAY)。目前复杂对象数组的存储方式没有变化。
这一改进还为 Druid 类型列添加了一个全新的功能，即ARRAYtyped columns；它与经典的多值STRING列不同，以 ARRAY 语义表现。当所有值都是具有相同类型元素的数组时，这些列当前只能通过“auto”类型索引器创建。
Array data type 是一种允许你在数据库表的单个列中存储多个值的数据类型。数组通常用于存储可以作为一个组轻松访问和操作的相关数据集。
此版本增加了对将ARRAY<STRING>、ARRAY<LONG>和ARRAY<DOUBLE>等原始值数组存储为专用嵌套列的支持，而不是将它们分解为单独的元素列。
#14014 #13803
这些更改会影响 26.0 中可用的两个新功能：schema auto-discovery 和 unnest。
Schema auto-discovery（实验性）
项目团队正在向 Druid 添加带有类型推断的 schema-auto discovery。使用此功能，当 schema 可用时，会检测每个传入字段的数据类型。对于可能包含添加、删除或更改字段的传入数据，你可以选择拒绝不一致的数据（“the database is always correct - rejecting bad data!”），或者可以让 schema auto-discovery 更改数据源以匹配传入的数据（“the data is always right - change the database!”）。
对于新的用例和摄取，建议使用 Schema auto-discovery。对于现有用例，则建议慎用此功能；因为 Druid 会将类似数组的值（例如["tag1", "tag2]）作为ARRAY<STRING>类型列而不是多值 (MV) 字符串，这可能会导致下游应用程序响应 MV 行为时出现问题。在有正式的迁移路径可用前，建议暂缓切换。
Schema auto-discovery 可用于本机批处理和流式摄取。
#13653 #13672 #14076
UNNEST arrays（实验性）
UNNEST 的部分酷炫之处在于它允许进行范围更广的操作，而这些操作在 Array 数据类型上是不可能的。你可以使用 UNNEST 函数 (SQL) 或unnest数据源（native）取消嵌套数组。
Unnest 将嵌套数组或表格转换为单独的行。UNNEST 函数在处理包含嵌套数组的复杂数据类型（例如 JSON）时特别有用。
例如，假设你有一个名为“orders”的表，其中有一列名为“items”，其中包含每个订单的产品数组。你可以使用 unnest 提取单个产品（“each_item”），如以下 SQL 示例所示：
SELECT order_id, each_item FROM orders, UNNEST(items) as unnested(each_item)
这会生成一个结果集，每个订单中的每个项目都有一行，其中包含订单 ID 和单个项目的列。
注意 left table/datasource 后的逗号（示例中的orders）。这是必需的。
#13268 #13943 #13934 #13922 #13892 # 13576 #13554 #13085
MSQ 的 Sort-merge join 和 hash shuffle join
现在可以通过设置上下文参数sqlJoinAlgorithm来执行排序合并算法的sortMerge，或省略它来执行 broadcast joins（默认）。
多阶段查询可以使用排序合并连接算法。使用此算法，每个成对连接都计划到其自己的阶段，并带有两个输入。与 broadcast 相比，此方法通常性能较低但可扩展性更强。
将上下文参数sqlJoinAlgorithm设置为sortMerge以使用此方法。
Broadcast hash join 类似于本机连接查询的执行方式。
#13506
字典压缩的存储改进
切换到使用 frontcoding 字典压缩（实验性）可以节省多达 30%，而对查询性能几乎没有影响。
此版本通过新的段格式版本进一步改进了indexSpec上stringEncodingStrategy的frontCoded的类型，通常具有更快的读取速度和更小的 segment size。此改进与 Druid 25.0 向后不兼容。添加了一个新的formatVersion选项，默认为当前的0版本。将formatVersion设置为1即可开始使用新版本。
#13988 #13996
此外，整体存储大小，特别是使用更大的 buckets 时，已得到改进。
13854
更多详情可查看更新公告。