云服务器内容精选

  • 压缩调优 CarbonData结合少数轻量级压缩算法和重量级压缩算法来压缩数据。虽然这些算法可处理任何类型的数据,但如果数据经过排序,相似值在一起出现时,就会获得更好的压缩率。 CarbonData数据加载过程中,数据基于Table中的列顺序进行排序,从而确保相似值在一起出现,以获得更好的压缩率。 由于CarbonData按照Table中定义的列顺序将数据进行排序,因此列顺序对于压缩效率起重要作用。如果低cardinality维度位于左边,那么排序后的数据分区范围较小,压缩效率较高。如果高cardinality维度位于左边,那么排序后的数据分区范围较大,压缩效率较低。
  • CarbonData查询流程 当CarbonData首次收到对某个表(例如表A)的查询任务时,系统会加载表A的索引数据到内存中,执行查询流程。当CarbonData再次收到对表A的查询任务时,系统则不需要再加载其索引数据。 在CarbonData中执行查询时,查询任务会被分成几个扫描任务。即,基于CarbonData数据存储的HDFS block对扫描任务进行分割。扫描任务由集群中的执行器执行。扫描任务可以并行、部分并行,或顺序处理,具体采用的方式取决于执行器的数量以及配置的执行器核数。 查询任务的某些部分可在独立的任务级上处理,例如select和filter。查询任务的某些部分可在独立的任务级上进行部分处理,例如group-by、count、distinct count等。 某些操作无法在任务级上处理,例如Having Clause(分组后的过滤),sort等。这些无法在任务级上处理,或只能在任务级上部分处理的操作需要在集群内跨执行器来传输数据(部分结果)。这个传送操作被称为shuffle。 任务数量越多,需要shuffle的数据就越多,会对查询性能产生不利影响。 由于任务数量取决于HDFS block的数量,而HDFS block的数量取决于每个block的大小,因此合理选择HDFS block的大小很重要,需要在提高并行性,进行shuffle操作的数据量和聚合表的大小之间达到平衡。
  • 查询性能调优 CarbonData可以通过调整各种参数来提高查询性能。大部分参数聚焦于增加并行性处理和更好地使用系统资源。 Spark Executor数量:Executor是Spark并行性的基础实体。通过增加Executor数量,集群中的并行数量也会增加。关于如何配置Executor数量,请参考Spark资料。 Executor核:每个Executor内,并行任务数受Executor核的配置控制。通过增加Executor核数,可增加并行任务数,从而提高性能。 HDFS block容量:CarbonData通过给不同的处理器分配不同的block来分配查询任务。所以一个HDFS block是一个分区单元。另外,CarbonData在Spark驱动器中,支持全局block级索引,这有助于减少需要被扫描的查询block的数量。设置较大的block容量,可提高I/O效率,但是会降低全局索引效率;设置较小的block容量,意味着更多的block数量,会降低I/O效率,但是会提高全局索引效率,同时,对于索引查询会要求更多的内存。 扫描线程数量:扫描仪(Scanner)线程控制每个任务中并行处理的数据块的数量。通过增加扫描仪线程数,可增加并行处理的数据块的数量,从而提高性能。可使用“carbon.properties”文件中的“carbon.number.of.cores”属性来配置扫描仪线程数。例如,“carbon.number.of.cores = 4”。 B-Tree缓存:为了获得更好的查询特性,可以通过B-tree LRU(least recently used,最近最少使用)缓存来优化缓存内存。在driver中,B-Tree LRU缓存配置将有助于通过释放未被访问或未使用的表segments来释放缓存。类似地,在executor中,B-Tree LRU缓存配置将有助于释放未被访问或未使用的表blocks。具体可参考表2中的参数“carbon.max.driver.lru.cache.size”和“carbon.max.executor.lru.cache.size”的详细描述。
  • 配置扫描仪线程 扫描仪线程属性决定了每个分割的数据被划分的可并行处理的数据块的数量。如果数量过多,会产生很多小数据块,性能会受到影响。如果数量过少,并行性不佳,性能也会受到影响。因此,决定扫描仪线程数时,需要考虑一个分割内的平均数据大小,选择一个使数据块不会很小的值。经验法则是将单个块大小(MB)除以250得到的值作为扫描仪线程数。 增加并行性还需考虑的重要一点是集群中实际可用的CPU核数,确保并行计算数不超过实际CPU核数的75%至80%。 CPU核数约等于: 并行任务数x扫描仪线程数。其中并行任务数为分割数和执行器数x执行器核数两者之间的较小值。
  • 数据加载性能调优 数据加载性能调优与查询性能调优差异很大。跟查询性能一样,数据加载性能也取决于可达到的并行性。在数据加载情况下,工作线程的数量决定并行的单元。因此,更多的执行器就意味着更多的执行器核数,每个执行器都可以提高数据加载性能。 同时,为了得到更好的性能,可在HDFS中配置如下参数。 表1 HDFS配置 参数 建议值 dfs.datanode.drop.cache.behind.reads false dfs.datanode.drop.cache.behind.writes false dfs.datanode.sync.behind.writes true
  • 配置扫描仪线程 扫描仪线程属性决定了每个分割的数据被划分的可并行处理的数据块的数量。如果数量过多,会产生很多小数据块,性能会受到影响。如果数量过少,并行性不佳,性能也会受到影响。因此,决定扫描仪线程数时,需要考虑一个分割内的平均数据大小,选择一个使数据块不会很小的值。经验法则是将单个块大小(MB)除以250得到的值作为扫描仪线程数。 增加并行性还需考虑的重要一点是集群中实际可用的CPU核数,确保并行计算数不超过实际CPU核数的75%至80%。 CPU核数约等于: 并行任务数x扫描仪线程数。其中并行任务数为分割数和执行器数x执行器核数两者之间的较小值。
  • 数据加载性能调优 数据加载性能调优与查询性能调优差异很大。跟查询性能一样,数据加载性能也取决于可达到的并行性。在数据加载情况下,工作线程的数量决定并行的单元。因此,更多的执行器就意味着更多的执行器核数,每个执行器都可以提高数据加载性能。 同时,为了得到更好的性能,可在HDFS中配置如下参数。 表1 HDFS配置 参数 建议值 dfs.datanode.drop.cache.behind.reads false dfs.datanode.drop.cache.behind.writes false dfs.datanode.sync.behind.writes true
  • 压缩调优 CarbonData结合少数轻量级压缩算法和重量级压缩算法来压缩数据。虽然这些算法可处理任何类型的数据,但如果数据经过排序,相似值在一起出现时,就会获得更好的压缩率。 CarbonData数据加载过程中,数据基于Table中的列顺序进行排序,从而确保相似值在一起出现,以获得更好的压缩率。 由于CarbonData按照Table中定义的列顺序将数据进行排序,因此列顺序对于压缩效率起重要作用。如果低cardinality维度位于左边,那么排序后的数据分区范围较小,压缩效率较高。如果高cardinality维度位于左边,那么排序后的数据分区范围较大,压缩效率较低。
  • 查询性能调优 CarbonData可以通过调整各种参数来提高查询性能。大部分参数聚焦于增加并行性处理和更好地使用系统资源。 Spark Executor数量:Executor是Spark并行性的基础实体。通过增加Executor数量,集群中的并行数量也会增加。关于如何配置Executor数量,请参考Spark资料。 Executor核:每个Executor内,并行任务数受Executor核的配置控制。通过增加Executor核数,可增加并行任务数,从而提高性能。 HDFS block容量:CarbonData通过给不同的处理器分配不同的block来分配查询任务。所以一个HDFS block是一个分区单元。另外,CarbonData在Spark驱动器中,支持全局block级索引,这有助于减少需要被扫描的查询block的数量。设置较大的block容量,可提高I/O效率,但是会降低全局索引效率;设置较小的block容量,意味着更多的block数量,会降低I/O效率,但是会提高全局索引效率,同时,对于索引查询会要求更多的内存。 扫描线程数量:扫描仪(Scanner)线程控制每个任务中并行处理的数据块的数量。通过增加扫描仪线程数,可增加并行处理的数据块的数量,从而提高性能。可使用“carbon.properties”文件中的“carbon.number.of.cores”属性来配置扫描仪线程数。例如,“carbon.number.of.cores = 4”。 B-Tree缓存:为了获得更好的查询特性,可以通过B-tree LRU(least recently used,最近最少使用)缓存来优化缓存内存。在driver中,B-Tree LRU缓存配置将有助于通过释放未被访问或未使用的表segments来释放缓存。类似地,在executor中,B-Tree LRU缓存配置将有助于释放未被访问或未使用的表blocks。具体可参考表2中的参数“carbon.max.driver.lru.cache.size”和“carbon.max.executor.lru.cache.size”的详细描述。
  • CarbonData查询流程 当CarbonData首次收到对某个表(例如表A)的查询任务时,系统会加载表A的索引数据到内存中,执行查询流程。当CarbonData再次收到对表A的查询任务时,系统则不需要再加载其索引数据。 在CarbonData中执行查询时,查询任务会被分成几个扫描任务。即,基于CarbonData数据存储的HDFS block对扫描任务进行分割。扫描任务由集群中的执行器执行。扫描任务可以并行、部分并行,或顺序处理,具体采用的方式取决于执行器的数量以及配置的执行器核数。 查询任务的某些部分可在独立的任务级上处理,例如select和filter。查询任务的某些部分可在独立的任务级上进行部分处理,例如group-by、count、distinct count等。 某些操作无法在任务级上处理,例如Having Clause(分组后的过滤),sort等。这些无法在任务级上处理,或只能在任务级上部分处理的操作需要在集群内跨执行器来传输数据(部分结果)。这个传送操作被称为shuffle。 任务数量越多,需要shuffle的数据就越多,会对查询性能产生不利影响。 由于任务数量取决于HDFS block的数量,而HDFS block的数量取决于每个block的大小,因此合理选择HDFS block的大小很重要,需要在提高并行性,进行shuffle操作的数据量和聚合表的大小之间达到平衡。
  • 操作步骤 用于CarbonData查询的配置介绍,详情请参见表1和表2。 表1 Shuffle过程中,启动Task的个数 参数 spark.sql.shuffle.partitions 所属配置文件 spark-defaults.conf 适用于 数据查询 场景描述 Spark shuffle时启动的Task个数。 如何调优 一般建议将该参数值设置为执行器核数的1到2倍。例如,在聚合场景中,将task个数从200减少到32,有些查询的性能可提升2倍。 表2 设置用于CarbonData查询的Executor个数、CPU核数以及内存大小 参数 spark.executor.cores spark.executor.instances spark.executor.memory 所属配置文件 spark-defaults.conf 适用于 数据查询 场景描述 设置用于CarbonData查询的Executor个数、CPU核数以及内存大小。 如何调优 在银行方案中,为每个执行器提供4个CPU内核和15GB内存,可以获得良好的性能。这2个值并不意味着越多越好,在资源有限的情况下,需要正确配置。例如,在银行方案中,每个节点有足够的32个CPU核,而只有64GB的内存,这个内存是不够的。例如,当每个执行器有4个内核和12GB内存,有时在查询期间发生垃圾收集(GC),会导致查询时间从3秒增加到超过15秒。在这种情况下需要增加内存或减少CPU内核。 用于CarbonData数据加载的配置参数,详情请参见表3、表4和表5。 表3 设置数据加载使用的CPU core数量 参数 carbon.number.of.cores.while.loading 所属配置文件 carbon.properties 适用于 数据加载 场景描述 数据加载过程中,设置处理数据使用的CPU core数量。 如何调优 如果有更多的CPU个数,那么可以增加CPU值来提高性能。例如,将该参数值从2增加到4,那么 CS V文件读取性能可以增加大约1倍。 表4 是否使用YARN本地目录进行多磁盘数据加载 参数 carbon.use.local.dir 所属配置文件 carbon.properties 适用于 数据加载 场景描述 是否使用YARN本地目录进行多磁盘数据加载。 如何调优 如果将该参数值设置为“true”,CarbonData将使用YARN本地目录进行多表加载磁盘负载平衡,以提高数据加载性能。 表5 加载时是否使用多路径 参数 carbon.use.multiple.temp.dir 所属配置文件 carbon.properties 适用于 数据加载 场景描述 是否使用多个临时目录存储sort临时文件。 如何调优 设置为true,则数据加载时使用多个临时目录存储sort临时文件。此配置能提高数据加载性能并避免磁盘单点故障。 用于CarbonData数据加载和数据查询的配置参数,详情请参见表6。 表6 设置数据加载和查询使用的CPU core数量 参数 carbon.compaction.level.threshold 所属配置文件 carbon.properties 适用于 数据加载和查询 场景描述 对于minor压缩,在阶段1中要合并的segment数量和在阶段2中要合并的已压缩的segment数量。 如何调优 每次CarbonData加载创建一个segment,如果每次加载的数据量较小,将在一段时间内生成许多小文件,影响查询性能。配置该参数将小的segment合并为一个大的segment,然后对数据进行排序,可提高查询性能。 压缩的策略根据实际的数据大小和可用资源决定。如某银行1天加载一次数据,且加载数据选择在晚上无查询时进行,有足够的资源,压缩策略可选择为6、5。 表7 使用索引缓存服务器时是否开启数据预加载 参数 carbon.indexserver.enable.prepriming 所属配置文件 carbon.properties 适用于 数据加载 场景描述 使用索引缓存服务器过程中开启数据预加载可以提升首次查询的性能。 如何调优 用户可以将该参数设置为true来开启预加载。默认情况,该参数为false。