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 类型列添加了一个全新的功能,即ARRAY
typed 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
更多详情可查看更新公告。
还没有评论,来说两句吧...