一，carbondata高效原因
carbondata文件是hdfs的列式存储格式
查询速度是spark SQL的10倍，通过多种索引技术和多次push down优化，对TB级别数据快速响应
高效的压缩，使用轻量级和和重量级压缩组合的方式，减少60~80%的空间

二。参数调优
场景一：查询时候：
a.扫描线程数量：扫描仪（Scanner）线程控制每个任务中并行处理的数据块的数量。通过增加扫描仪线程数，可增加并行处理的数据块的数量，从而提高性能。可使用“carbon.properties”文件中的“carbon.number.of.cores”属性来配置扫 描仪线程数
carbon.number.of.cores
设置原则：hdfs的block单个块大小（MB）除以250得到的值作为扫描仪线程数。
增加并行性还需考虑的重要一点是集群中实际可用的CPU核数，确保并行计算数不超过实际CPU核数的75%至80%。
CPU核数约等于：
并行任务数x扫描仪线程数。其中并行任务数为分割数（文件大小/hdfs的block大小）和执行器数（executor数量）x执行器核数（几核的）两者之间的较小值。

场景二：建表注意
创建表的时候为了提高压缩比例，可以将低基数的放在前面，这样压缩 那么排序后的数据分区范围较小，压缩效率较高。如果高cardinality维度位于左边，那么排序后的数据分区范围较大，压缩效率较低
参数 spark.sql.shuffle.partitions
所属配置文件 spark-defaults.conf
适用于 数据查询
场景描述 Spark shuffle时启动的Task个数。
调优 一般建议将该参数值设置为执行器核数的1到2倍。例如，在聚合场景中，将task个数从200减少到32，有些查询的性能可提升2 倍。

三，问题排查
1.8.8为什么并行度大于待处理的 block 数目时，CarbonData 仍需要额外的 executor？

四，问题
为什么并行度大于待处理的block数目时，CarbonData仍需要额外的executor？

回答
CarbonData块分布对于数据处理进行了如下优化：
1.优化数据处理并行度。
2.优化了读取块数据的并行性。
为了优化并行数据处理及并行读取块数据，CarbonData根据块的局域性申请
executor，因此CarbonData可获得所有节点上的executor。
为了优化并行数据处理及并行读取块数据，运用动态分配的用户需配置以下特性。
1.使用参数“spark.dynamicAllocation.executorIdleTimeout”并将此参数值设置为
15min（或平均查询时间）。
2.正确配置参数“spark.dynamicAllocation.maxExecutors”，不推荐使用默认值
（2048），否则CarbonData将申请最大数量的executor。
3.对于更大的集群，配置参数“carbon.dynamicAllocation.schedulerTimeout”为
10～15sec，默认值为5sec。
4.配置参数“carbon.scheduler.minRegisteredResourcesRatio”为0.1～1.0，默认值为0.8。只要达到此参数值，块分布可启动。

建议在hdfs-site.xml中添加
dfs.datanode.drop.cache.behind.reads false
dfs.datanode.drop.cache.behind.writes false
dfs.datanode.sync.behind.writes true