数据库数据分析OLAP大数据实时分析数据仓库后端【免费下载链接】druidApache Druid: a high performance real-time analytics database.项目地址https://gitcode.com/gh_mirrors/druid7/druid点击查看免费下载本文对比 Apache Druid 与传统键值Key/Value存储在扫描 聚合类分析工作负载上的架构差异聚焦 HBase、Cassandra、OpenTSDB 等典型系统。读者将理解键值存储实现聚合查询的两种主流路线预计算查询排列、按维度键范围扫描各自的瓶颈以及 Druid 如何借助列式段文件与倒排位图索引在无需预计算的前提下支持任意深度的即席下钻drill-down查询。Druid 的列类型时间戳列、维度列与度量列分别以独立数据结构存储一、为什么键值存储也能做聚合分析Druid 高度面向扫描scan与聚合aggregation优化支持对数据集进行任意深度的下钻。这一能力在键值存储中并非天然具备通常需要借助两种方式间接实现预计算Pre-compute所有可能的用户查询排列把查询结果事先算好、直接命中对事件数据进行范围扫描Range Scan以事件维度作为键、度量作为值聚合时扫描键的范围。原文档明确指出这两种方式都能实现聚合但都付出了不同的代价——前者牺牲灵活性后者牺牲扫描效率与数据局部性。下面分别展开。二、路线一预计算查询排列快但代价高昂在预计算方案中键就是查询的确切参数值就是查询的结果。例如把(时间粒度, 维度组合, 过滤条件, 聚合函数)作为键把聚合结果作为值存入键值存储。查询时直接get即可返回速度极快。然而这种方案的成本集中在三个方面灵活性缺失预计算只能覆盖事先想到的查询即席ad-hoc探索性查询无法命中任何预先算好的结果组合爆炸对所有即席查询排列做全量预计算结果集规模会随数据集列数指数级增长预处理耗时长对复杂真实数据集做全排列预计算可能需要数小时的预处理时间。这意味着预计算 键值存储适合查询模式完全固定、且数据规模可控的场景但不适合面向分析师自由探索的分析型负载。三、路线二维度作键 范围扫描天然存在三重瓶颈第二种做法OpenTSDB 等时序数据库采用是将事件的维度作为键、事件度量作为值聚合通过在该键空间上发起范围扫描完成。原文档指出了这一模型的三处根本性限制3.1 只有前缀范围索引无法解析复杂谓词键值存储的索引模型通常只支持前缀范围prefix range过滤它可以把查询缩小到某个度量 某个时间范围但无法解析复杂谓词来进一步收窄需要精确扫描的数据行。当待扫描行数变大时这一限制会显著拉低性能。从仓库实现角度看这正是 Druid 刻意回避的短板Druid 为每个维度列维护倒排位图索引过滤不是靠扫键而是靠位图按位与AND/或OR快速求交。相关核心接口见 Filter.javagetBitmapIndex(BitmapIndexSelector)直接返回与该过滤条件匹配的行位图estimateSelectivity(BitmapIndexSelector)快速估算过滤选择性用于成本化查询规划如 search 查询的 AutoStrategysupportsBitmapIndex/supportsSelectivityEstimation判定该过滤条件能否走位图索引。也就是说Druid 的过滤器天然面向复杂谓词 精确定位行集而键值存储的前缀扫描在语义上只能做到粗粒度收窄 全量遍历剩余行。3.2 扫描放大问题由于无法用位图索引直接定位命中的行范围扫描方案在过滤条件复杂时会把大量无关行一并扫出。Druid 侧对应的优化是扫描时只解压查询真正需要的列。段文件按列组织见 segments.md时间戳列与度量列背后是经 LZ4 压缩的整型/浮点数组查询确定需要选择的行之后只需解压这些列、取出相关行、套用聚合算子即可若某列不被查询引用该列数据直接跳过。3.3 聚合下推困难局部性差大多数键值存储不支持将聚合下推到存储层因此难以获得良好的数据局部性locality——数据在网络间来回搬运聚合只能在上层完成。而 Druid 将按列扫描与就地聚合融为一体聚合算子直接作用于列数据之上天然避免了大体积行数据的搬移。四、Druid 的解法列式段文件 字典 倒排位图对于任意探索性数据分析灵活的过滤Druid 的自定义列格式使其无需预计算即可执行即席查询同一套列式格式还保证了快速列扫描这是聚合性能的关键。4.1 三段式列结构根据 segments.mdDruid 将索引存放在按时间分区的**段文件segment files中内部是彻底的列式columnar**布局——每列独立存放。维度列需要支撑过滤与分组因此每个维度由三套数据结构构成字典Dictionary把列值一律按字符串处理映射为整数 ID列数据列表Column data用字典编码后的列值序列每个不同值的位图Bitmap标记该值出现在哪些行即倒排索引。以page列为例仅两行不同的值1: Dictionary that encodes column values { Justin Bieber: 0, Ke$ha: 1 } 2: Column data [0, 0, 1, 1] 3: Bitmaps - one for each unique value of the column valueJustin Bieber: [1,1,0,0] valueKe$ha: [0,0,1,1]三套结构的职责分工字典把字符串换成紧凑整数供第 2、3 部分压缩存储位图倒排索引便于快速做 AND/OR 过滤运算直接支撑 filters.md 中描述的 Selector、And、Or、Not、Bound、In 等过滤器列数据列表服务于group by 与 TopN 查询——纯基于过滤条件的指标聚合不需要触碰第 2 部分。仓库中的 Column.java 接口清晰呈现了这一设计getDictionaryEncoding()、getGenericColumn()、getBitmapIndex()、getSpatialIndex()分别对应字典编码列、通用列、位图索引与空间索引另有TIME_COLUMN_NAME __time标识时间列BitmapIndex.java 则定义了位图索引的访问契约getCardinality()、getIndex(String)、getBitmap(int idx)等。4.2 高基数列的位图压缩注意位图部分与另外两部分的不同前两者随数据量线性增长而位图部分规模约为数据量 × 列基数。好在每一行在列数据中只有一个非零位图项因此高基数列的位图极度稀疏、高度可压缩——Druid 正是利用这一点采用 Roaring Bitmap 等专为位图设计的压缩算法。稀疏位图配合按位运算正是复杂谓词快速定位行集能落地的底层保障。4.3 多值列的扩展若数据源使用多值列一行拥有多个值段内结构相应调整列数据中该行变为数组[0,1]且该行在多个值的位图中都有非零项。这一特性让 Druid 在键值模型需要拆行或用复杂编码才能表达的维度多值场景下仍保持单行的即席过滤能力。相关说明同样见于 segments.md。五、聚合下推与即席查询的落点回到对比主线将两种方案的取舍总结如下维度预计算 键值存储维度作键 范围扫描OpenTSDB 模式Druid 列式段文件查询延迟极快直接命中结果随扫描行数恶化仅扫描命中列与行即席查询不支持仅限前缀范围过滤支持任意复杂谓词组合预处理成本随列数指数增长可能耗时数小时无无按需实时聚合聚合下推/局部性通常不支持通常不支持列内就地聚合从源码结构看Druid 把过滤 → 行集定位 → 列扫描 → 聚合整条链路收敛在同一存储引擎内过滤器产出位图Filter.java聚合算子由 AggregatorFactory 抽象定义并直接作用于列值group by、TopN、timeseries 等查询类型在此基础上构建参见 aggregations.md、groupbyquery.md、topnquery.md。相较之下键值存储天然缺少复杂谓词解析 聚合算子下推这一层这正是二者在分析场景下性能分野的结构性原因。六、选型建议若查询模式完全固定、结果集规模可控键值存储 预计算仍是可行的低成本方案若查询仅需度量 时间范围的粗粒度过滤且可接受扫描放大OpenTSDB 式的范围扫描设计足够简单实用若需要面向分析师提供任意深度的即席下钻与灵活过滤同时保持高聚合吞吐Druid 的列式段文件与倒排位图索引是更契合的架构选择。延伸阅读Druid 段文件与列式存储结构过滤器的语义与使用聚合器体系GroupBy 查询TopN 查询Druid 整体设计赞分享数据库数据分析OLAP大数据实时分析数据仓库后端【免费下载链接】druidApache Druid: a high performance real-time analytics database.项目地址https://gitcode.com/gh_mirrors/druid7/druid点击查看免费下载相关推荐Apache Druid 与键值存储HBase/Cassandra/OpenTSDB对比从扫描与聚合视角看两类系统的架构取舍Apache Druid 与键值存储HBase/Cassandra/OpenTSDB对比从扫描与聚合视角看两类系统的架构取舍 本文是 Apache Dru数据库OLAP大数据后端Druid 与 Kudu 对比分析面向 OLAP 的预聚合列式存储与面向 OLTP 的可更新行式存储Druid 与 Kudu 对比分析面向 OLAP 的预聚合列式存储与面向 OLTP 的可更新行式存储 Druid 与 Kudu 是两类设计哲学截然不同的数据存数据库数据分析OLAP大数据实时分析数据仓库后端如何选择JanusGraph存储后端Cassandra vs HBase vs BerkeleyDB终极对比指南如何选择JanusGraph存储后端Cassandra vs HBase vs BerkeleyDB终极对比指南 JanusGraph是一个基于Apache图数据库分布式数据库后端创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Druid 与键值存储（HBase/Cassandra/OpenTSDB）对比：列式存储如何破解即席聚合扫描难题
数据库数据分析OLAP大数据实时分析数据仓库后端【免费下载链接】druidApache Druid: a high performance real-time analytics database.项目地址https://gitcode.com/gh_mirrors/druid7/druid点击查看免费下载本文对比 Apache Druid 与传统键值Key/Value存储在扫描 聚合类分析工作负载上的架构差异聚焦 HBase、Cassandra、OpenTSDB 等典型系统。读者将理解键值存储实现聚合查询的两种主流路线预计算查询排列、按维度键范围扫描各自的瓶颈以及 Druid 如何借助列式段文件与倒排位图索引在无需预计算的前提下支持任意深度的即席下钻drill-down查询。Druid 的列类型时间戳列、维度列与度量列分别以独立数据结构存储一、为什么键值存储也能做聚合分析Druid 高度面向扫描scan与聚合aggregation优化支持对数据集进行任意深度的下钻。这一能力在键值存储中并非天然具备通常需要借助两种方式间接实现预计算Pre-compute所有可能的用户查询排列把查询结果事先算好、直接命中对事件数据进行范围扫描Range Scan以事件维度作为键、度量作为值聚合时扫描键的范围。原文档明确指出这两种方式都能实现聚合但都付出了不同的代价——前者牺牲灵活性后者牺牲扫描效率与数据局部性。下面分别展开。二、路线一预计算查询排列快但代价高昂在预计算方案中键就是查询的确切参数值就是查询的结果。例如把(时间粒度, 维度组合, 过滤条件, 聚合函数)作为键把聚合结果作为值存入键值存储。查询时直接get即可返回速度极快。然而这种方案的成本集中在三个方面灵活性缺失预计算只能覆盖事先想到的查询即席ad-hoc探索性查询无法命中任何预先算好的结果组合爆炸对所有即席查询排列做全量预计算结果集规模会随数据集列数指数级增长预处理耗时长对复杂真实数据集做全排列预计算可能需要数小时的预处理时间。这意味着预计算 键值存储适合查询模式完全固定、且数据规模可控的场景但不适合面向分析师自由探索的分析型负载。三、路线二维度作键 范围扫描天然存在三重瓶颈第二种做法OpenTSDB 等时序数据库采用是将事件的维度作为键、事件度量作为值聚合通过在该键空间上发起范围扫描完成。原文档指出了这一模型的三处根本性限制3.1 只有前缀范围索引无法解析复杂谓词键值存储的索引模型通常只支持前缀范围prefix range过滤它可以把查询缩小到某个度量 某个时间范围但无法解析复杂谓词来进一步收窄需要精确扫描的数据行。当待扫描行数变大时这一限制会显著拉低性能。从仓库实现角度看这正是 Druid 刻意回避的短板Druid 为每个维度列维护倒排位图索引过滤不是靠扫键而是靠位图按位与AND/或OR快速求交。相关核心接口见 Filter.javagetBitmapIndex(BitmapIndexSelector)直接返回与该过滤条件匹配的行位图estimateSelectivity(BitmapIndexSelector)快速估算过滤选择性用于成本化查询规划如 search 查询的 AutoStrategysupportsBitmapIndex/supportsSelectivityEstimation判定该过滤条件能否走位图索引。也就是说Druid 的过滤器天然面向复杂谓词 精确定位行集而键值存储的前缀扫描在语义上只能做到粗粒度收窄 全量遍历剩余行。3.2 扫描放大问题由于无法用位图索引直接定位命中的行范围扫描方案在过滤条件复杂时会把大量无关行一并扫出。Druid 侧对应的优化是扫描时只解压查询真正需要的列。段文件按列组织见 segments.md时间戳列与度量列背后是经 LZ4 压缩的整型/浮点数组查询确定需要选择的行之后只需解压这些列、取出相关行、套用聚合算子即可若某列不被查询引用该列数据直接跳过。3.3 聚合下推困难局部性差大多数键值存储不支持将聚合下推到存储层因此难以获得良好的数据局部性locality——数据在网络间来回搬运聚合只能在上层完成。而 Druid 将按列扫描与就地聚合融为一体聚合算子直接作用于列数据之上天然避免了大体积行数据的搬移。四、Druid 的解法列式段文件 字典 倒排位图对于任意探索性数据分析灵活的过滤Druid 的自定义列格式使其无需预计算即可执行即席查询同一套列式格式还保证了快速列扫描这是聚合性能的关键。4.1 三段式列结构根据 segments.mdDruid 将索引存放在按时间分区的**段文件segment files中内部是彻底的列式columnar**布局——每列独立存放。维度列需要支撑过滤与分组因此每个维度由三套数据结构构成字典Dictionary把列值一律按字符串处理映射为整数 ID列数据列表Column data用字典编码后的列值序列每个不同值的位图Bitmap标记该值出现在哪些行即倒排索引。以page列为例仅两行不同的值1: Dictionary that encodes column values { Justin Bieber: 0, Ke$ha: 1 } 2: Column data [0, 0, 1, 1] 3: Bitmaps - one for each unique value of the column valueJustin Bieber: [1,1,0,0] valueKe$ha: [0,0,1,1]三套结构的职责分工字典把字符串换成紧凑整数供第 2、3 部分压缩存储位图倒排索引便于快速做 AND/OR 过滤运算直接支撑 filters.md 中描述的 Selector、And、Or、Not、Bound、In 等过滤器列数据列表服务于group by 与 TopN 查询——纯基于过滤条件的指标聚合不需要触碰第 2 部分。仓库中的 Column.java 接口清晰呈现了这一设计getDictionaryEncoding()、getGenericColumn()、getBitmapIndex()、getSpatialIndex()分别对应字典编码列、通用列、位图索引与空间索引另有TIME_COLUMN_NAME __time标识时间列BitmapIndex.java 则定义了位图索引的访问契约getCardinality()、getIndex(String)、getBitmap(int idx)等。4.2 高基数列的位图压缩注意位图部分与另外两部分的不同前两者随数据量线性增长而位图部分规模约为数据量 × 列基数。好在每一行在列数据中只有一个非零位图项因此高基数列的位图极度稀疏、高度可压缩——Druid 正是利用这一点采用 Roaring Bitmap 等专为位图设计的压缩算法。稀疏位图配合按位运算正是复杂谓词快速定位行集能落地的底层保障。4.3 多值列的扩展若数据源使用多值列一行拥有多个值段内结构相应调整列数据中该行变为数组[0,1]且该行在多个值的位图中都有非零项。这一特性让 Druid 在键值模型需要拆行或用复杂编码才能表达的维度多值场景下仍保持单行的即席过滤能力。相关说明同样见于 segments.md。五、聚合下推与即席查询的落点回到对比主线将两种方案的取舍总结如下维度预计算 键值存储维度作键 范围扫描OpenTSDB 模式Druid 列式段文件查询延迟极快直接命中结果随扫描行数恶化仅扫描命中列与行即席查询不支持仅限前缀范围过滤支持任意复杂谓词组合预处理成本随列数指数增长可能耗时数小时无无按需实时聚合聚合下推/局部性通常不支持通常不支持列内就地聚合从源码结构看Druid 把过滤 → 行集定位 → 列扫描 → 聚合整条链路收敛在同一存储引擎内过滤器产出位图Filter.java聚合算子由 AggregatorFactory 抽象定义并直接作用于列值group by、TopN、timeseries 等查询类型在此基础上构建参见 aggregations.md、groupbyquery.md、topnquery.md。相较之下键值存储天然缺少复杂谓词解析 聚合算子下推这一层这正是二者在分析场景下性能分野的结构性原因。六、选型建议若查询模式完全固定、结果集规模可控键值存储 预计算仍是可行的低成本方案若查询仅需度量 时间范围的粗粒度过滤且可接受扫描放大OpenTSDB 式的范围扫描设计足够简单实用若需要面向分析师提供任意深度的即席下钻与灵活过滤同时保持高聚合吞吐Druid 的列式段文件与倒排位图索引是更契合的架构选择。延伸阅读Druid 段文件与列式存储结构过滤器的语义与使用聚合器体系GroupBy 查询TopN 查询Druid 整体设计赞分享数据库数据分析OLAP大数据实时分析数据仓库后端【免费下载链接】druidApache Druid: a high performance real-time analytics database.项目地址https://gitcode.com/gh_mirrors/druid7/druid点击查看免费下载相关推荐Apache Druid 与键值存储HBase/Cassandra/OpenTSDB对比从扫描与聚合视角看两类系统的架构取舍Apache Druid 与键值存储HBase/Cassandra/OpenTSDB对比从扫描与聚合视角看两类系统的架构取舍 本文是 Apache Dru数据库OLAP大数据后端Druid 与 Kudu 对比分析面向 OLAP 的预聚合列式存储与面向 OLTP 的可更新行式存储Druid 与 Kudu 对比分析面向 OLAP 的预聚合列式存储与面向 OLTP 的可更新行式存储 Druid 与 Kudu 是两类设计哲学截然不同的数据存数据库数据分析OLAP大数据实时分析数据仓库后端如何选择JanusGraph存储后端Cassandra vs HBase vs BerkeleyDB终极对比指南如何选择JanusGraph存储后端Cassandra vs HBase vs BerkeleyDB终极对比指南 JanusGraph是一个基于Apache图数据库分布式数据库后端创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考