Carbondata 存储结构

数据文件结构如下：

image.png image.png

索引文件结构相对比效简单，没有直接画出, 可以直接查看原码(AbstractFactDataWriter#writeIndexFile)

相对Parquet 结构而言，多了一个IndexFile, 不过看了一下源码， Index File 只能对Block级别的列进行索引， 即统计一个Block中每一列的最值， 并通过Btree组织在一起。

总结: 相对于Parquet, ORC等传释统行列混合存储的结构主要有以下改进:

• 增加了索引文件，可以在读数据块做一些预处理，但就我理解来说，这个效果很有限，索引只存储了每个数据块每一列的最值， 而且数据块之间没有排序， 在数据均匀分布的情况下这个索引我认为是一个鸡肋，还有对于点查询来说同样有也有个这个问题

• 丰富了数据类型支持，支持多种Java内置的数据类型，支持多种编码与压缩技术; 避免了Parquet文件的嵌套结构，整体上更易懂

• 优化了内存分配与效率，支持使用直接内存与内存池化技术

缺点:

1. 只适合大数据在的数仓存储，如Spark、Hive等，不适合OLAP 查询场景，在这一点在和Parquet等并没有本质区别， 不过就CarbonData的出发点来说，也并不是为OLAP场景使用。 在我看来适合OLAP查询场景的存储结构要满足以下特点:

• 适合的索引技术，比如倒排(ES)、Btree(Green plum)
• 合适的分区技术 ( Presto, HAWQ)
• 丰富的统计、如基础统计，比如说InfroBright 使用“知识网格”技术，可直接利用统计信息而不是用索引来过滤数据，虽然CarbonData也使用了统计，在我看来还远远不够

2. 支持的执行引擎目前是Hive、Spark, 支持Sink到Flink等, 生态需要进一步加强。