华为云用户手册

注意事项 以下是可以在加载数据时使用的配置选项： DELIMITER：可以在加载命令中提供分隔符和引号字符。默认值为,。 OPTIONS('DELIMITER'=',' , 'QUOTECHAR'='"') 可使用'DELIMITER'='\t'来表示用制表符tab对 CS V数据进行分隔。 OPTIONS('DELIMITER'='\t') CarbonData也支持\001和\017作为分隔符。 对于CSV数据，分隔符为单引号（'）时，单引号必须在双引号（" "）内。例如：'DELIMITER'= "'"。 QUOTECHAR：可以在加载命令中提供分隔符和引号字符。默认值为"。 OPTIONS('DELIMITER'=',' , 'QUOTECHAR'='"') COMMENTCHAR：可以在加载命令中提供注释字符。在加载操作期间，如果在行的开头遇到注释字符，那么该行将被视为注释，并且不会被加载。默认值为＃。 OPTIONS('COMMENTCHAR'='#') FILEHEADER：如果源文件中没有表头，可在LOAD DATA命令中提供表头。 OPTIONS('FILEHEADER'='column1,column2') ESCAPECHAR：如果用户想在CSV上对Escape字符进行严格验证，可以提供Escape字符。默认值为\。 OPTIONS('ESCAPECHAR'='\') 如果在CSV数据中输入ESCAPECHAR，该ESCAPECHAR必须在双引号（" "）内。例如："a\b"。 Bad Records处理： 为了使数据处理应用程序为用户增值，不可避免地需要对数据进行某种程度的集成。在大多数情况下，数据质量问题源于生成源数据的上游（主要）系统。 有两种完全不同的方式处理Bad Data： 按照原始数据加载所有数据，之后进行除错处理。 在进入数据源的过程中，可以清理或擦除Bad Data，或者在发现Bad Data时让数据加载失败。 有多个选项可用于在CarbonData数据加载过程中清除源数据。对于CarbonData数据中的Bad Records管理，请参见表2。 表2 Bad Records Logger 配置项 默认值 描述 BAD_RECORDS_ LOG GER_ENABLE false 若设置为true，则将创建Bad Records日志文件，其中包含Bad Records的详细信息。 BAD_RECORDS_ACTION FAIL 以下为Bad Records的四种操作类型： FORCE：通过将Bad Records存储为NULL来自动校正数据。 REDIRECT：无法加载Bad Records，并将其写入BAD_RECORD_PATH下的CSV文件中，默认不开启该类型，如需使用该类型，需要设置参数carbon.enable.badrecord.action.redirect为true。 IGNORE：既不加载Bad Records也不将其写入CSV文件。 FAIL：如果发现存在Bad Records，数据加载将会失败。 说明： 在加载数据时，如果所有记录都是Bad Records，则参数BAD_RECORDS_ACTION将不起作用，加载数据操作将会失败。 IS_EMPTY_DATA_BAD_RECORD false 如果设置为“false”，则空（""或''或,,）数据将不被视为Bad Records，如果设置为“true”，则空数据将被视为Bad Records。 BAD_RECORD_PATH - 指定存储Bad Records的HDFS路径。默认值为Null。 如果启用了Bad Records日志记录或者Bad Records操作重定向，则该路径必须由用户进行配置。 示例： LOAD DATA INPATH 'filepath.csv' INTO TABLE tablename OPTIONS('BAD_RECORDS_LOGGER_ENABLE'='true', 'BAD_RECORD_PATH'='hdfs://hacluster/tmp/carbon', 'BAD_RECORDS_ACTION'='REDIRECT', 'IS_EMPTY_DATA_BAD_RECORD'='false'); 使用“REDIRECT”选项，CarbonData会将所有的Bad Records添加到单独的CSV文件中，但是该文件内容不能用于后续的数据加载，因为其内容可能无法与源记录完全匹配。用户必须清理原始源记录以便于进一步的数据提取。该选项的目的只是让用户知道哪些记录被视为Bad Records。 MAXCOLUMNS：该可选参数指定了在一行中，由CSV解析器解析的最大列数。 OPTIONS('MAXCOLUMNS'='400') 表3 MAXCOLUMNS 可选参数名称 默认值 最大值 MAXCOLUMNS 2000 20000 表4 MAXCOLUMNS可选参数的行为图 MAXCOLUMNS值 在文件Header选项中的列数 考虑的最终值 在加载项中未指定 5 2000 在加载项中未指定 6000 6000 40 7 文件header列数与MAXCOLUMNS值，两者中的最大值 22000 40 20000 60 在加载项中未指定 CSV文件第一行的列数与MAXCOLUMNS值，两者中的最大值 对于设置MAXCOLUMNS Option的最大值，要求executor具有足够的内存，否则，数据加载会由于内存不足的错误而失败。

示例 data.csv源文件数据如下所示： ID,date,country,name,phonetype,serialname,salary4,2014-01-21 00:00:00,xxx,aaa4,phone2435,ASD66902,150035,2014-01-22 00:00:00,xxx,aaa5,phone2441,ASD90633,150046,2014-03-07 00:00:00,xxx,aaa6,phone294,ASD59961,15005 CREATE TABLE carbontable(ID int, date Timestamp, country String, name String, phonetype String, serialname String,salary int) STORED AS carbondata; LOAD DATA inpath 'hdfs://hacluster/tmp/data.csv' INTO table carbontable options('DELIMITER'=',');

系统响应 由于为后台运行，ALTER TABLE COMPACTION命令不会显示压缩响应。 如果想要查看MINOR合并和MAJOR合并的响应结果，用户可以检查日志或运行SHOW SEGMENTS命令查看。 示例： +------+------------+--------------------------+------------------+------------+------------+-------------+--------------+--+| ID | Status | Load Start Time | Load Time Taken | Partition | Data Size | Index Size | File Format |+------+------------+--------------------------+------------------+------------+------------+-------------+--------------+--+| 3 | Success | 2020-09-28 22:53:26.336 | 3.726S | {} | 6.47KB | 3.30KB | columnar_v3 || 2 | Success | 2020-09-28 22:53:01.702 | 6.688S | {} | 6.47KB | 3.30KB | columnar_v3 || 1 | Compacted | 2020-09-28 22:51:15.242 | 5.82S | {} | 6.50KB | 3.43KB | columnar_v3 || 0.1 | Success | 2020-10-30 20:49:24.561 | 16.66S | {} | 12.87KB | 6.91KB | columnar_v3 || 0 | Compacted | 2020-09-28 22:51:02.6 | 6.819S | {} | 6.50KB | 3.43KB | columnar_v3 |+------+------------+--------------------------+------------------+------------+------------+-------------+--------------+--+ 其中， Compacted表示该数据已被合并。 0.1表示segment0与segment1合并之后的结果。 数据合并前后的其他操作没有差别。 被合并的segments（例如segment0和segment1）即成为无用的segments，会占用空间，因此建议合并之后使用CLEAN FILES命令进行彻底删除，再进行其他操作。CLEAN FILES命令的使用方法可参考CLEAN FILES。

注意事项 仅在没有数据丢失的情况下支持将Decimal数据类型从较低精度更改为较高精度 例如： 无效场景：将Decimal数据精度从（10,2）更改为（10,5）无效，因为在这种情况下，只有scale增加，但总位数保持不变。 有效场景：将Decimal数据精度从（10,2）更改为（12,3）有效，因为总位数增加2，但是scale仅增加1，这不会导致任何数据丢失。 将Decimal数据类型从较低精度更改为较高精度，其允许的最大精度(precision,scale)范围为(38,38)，并且只适用于不会导致数据丢失的有效提升精度的场景。

配置扫描仪线程 扫描仪线程属性决定了每个分割的数据被划分的可并行处理的数据块的数量。如果数量过多，会产生很多小数据块，性能会受到影响。如果数量过少，并行性不佳，性能也会受到影响。因此，决定扫描仪线程数时，需要考虑一个分割内的平均数据大小，选择一个使数据块不会很小的值。经验法则是将单个块大小（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”的详细描述。

参数描述 表1 ALTER TABLE COMPACTION参数描述 Parameter Description db_name 数据库名。若未指定，则选择当前数据库。 table_name 表名。 MINOR Minor合并，详见合并Segments。 MAJOR Major合并，详见合并Segments。 SEGMENT_INDEX 这会将一个segment内的所有Carbon索引文件（.carbonindex）合并为一个Carbon索引合并文件（.carbonindexmerge）。 这增强了首次查询性能。详见表1。 CUSTOM Custom合并，详见合并Segments。

示例 ALTER TABLE ProductDatabase COMPACT 'MINOR'; ALTER TABLE ProductDatabase COMPACT 'MAJOR'; ALTER TABLE ProductDatabase COMPACT 'SEGMENT_INDEX'; ALTER TABLE ProductDatabase COMPACT 'CUSTOM' WHERE SEGMENT.ID IN (0, 1);

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主要规格 表2 CarbonData主要规格 实体 测试值 测试环境 表数 10000 3个节点，每个executor 4个CPU核，20GB。Driver内存5GB，3个Executor。 总列数：107 String：75 Int：13 BigInt：7 Timestamp：6 Double：6 表的列数 2000 3个节点，每个executor4个CPU核，20GB。Driver内存5GB，3个Executor。 原始CSV文件大小的最大值 200GB 17个cluster节点，每个executor 150GB，25个CPU核。Driver内存10 GB，17个Executor。 每个文件夹的CSV文件数 100个文件夹，每个文件夹10个文件，每个文件大小50MB。 3个节点，每个executor4个CPU核，20GB。Driver内存5GB，3个Executor。 加载文件夹数 10000 3个节点，每个executor4个CPU核，20GB。Driver内存5GB，3个Executor。 数据加载所需的内存取决于以下因素： 列数 列值大小 并发（使用“carbon.number.of.cores.while.loading”进行配置） 在内存中排序的大小（使用“carbon.sort.size”进行配置） 中间缓存（使用“carbon.graph.rowset.size”进行配置） 加载包含1000万条记录和300列的8 GB CSV文件的数据，每行大小约为0.8KB的8GB CSV文件的数据，需要约为10GB的executor执行内存，也就是说，“carbon.sort.size” 配置为“100000”，所有其他前面的配置保留默认值。

二级索引表规格 表3 二级索引表规格 实体 测试值 二级索引表数量 10 二级索引表中的组合列的列数 5 二级索引表中的列名长度（单位：字符） 120 二级索引表名长度（单位：字符） 120 表中所有二级索引表的表名+列名的累积长度*（单位：字符） 3800** * Hive允许的上限值或可用资源的上限值。 ** 二级索引表使用hive注册，并以json格式的值存储在HiveSERDEPROPERTIES中。由hive支持的SERDEPROPERTIES的最大字符数为4000个字符，无法更改。

参数说明 表1 算子参数说明 参数 含义 类型 是否必填 默认值 Spark数据库 SparkSQL的数据库名称。 String 否 default Spark表名 配置SparkSQL表名。 仅支持一个SparkSQL表。 String 是 无 分区过滤器 配置分区过滤器可以导出指定分区数据，默认为空，导出整个表数据。 例如导出分区字段locale的值为“CN”或“US”的表数据，输入如下： locale = "CN" or locale = "US" String 否 - Spark输入字段 配置SparkSQL输入信息： 列名：配置SparkSQL列名。 字段名：配置输入字段名。 类型：配置字段类型。 长度：配置字段长度，字段值实际长度太长则按配置的长度截取，“类型”为“CHAR”时实际长度不足则空格补齐，“类型”为“VARCHAR”时实际长度不足则不补齐。 map 是 -

参数说明 表1 算子参数说明 参数 含义 类型 是否必填 默认值 更新字段名 需要更新的字段 string 是 无 操作符 操作符，支持“+”、“-”和“=” enum 是 + 更新值 用来更新的值 与字段类型相匹配 否 无 条件逻辑连接符 配置条件逻辑连接符，可配置“AND”或“OR”。 enum 是 AND 条件 配置过滤条件相关信息： 输入字段名：配置输入字段名，需填写上一个转换步骤生成的字段名。 操作：配置操作符。 比较值：配置比较值，可直接输入值或输入“#{已存在的字段名}”格式引用字段的具体值。 map 是 无

样例 以SPARK导出到sqlserver2014数据库为例。 在sqlserver2014上创建一张空表“test_1”用于存储SparkSQL数据。执行以下语句： create table test_1 (id int, name text, value text); 配置“Spark输入”算子，生成三个字段A、B和C： 设置了数据连接器后，单击“自动识别”，系统将自动读取数据库中的字段，可根据需要选择添加，然后根据业务场景手动进行完善或者修正即可，无需逐一手动添加。 此操作会覆盖表格内已有数据。 通过“表输出”算子，将A、B和C输出到“test_1”表中： select * from test_1;

参数说明 表1 算子参数说明 参数 含义 类型 是否必填 默认值 Hive数据库 Hive的数据库名称。 String 否 default Hive表名 配置Hive表名。 仅支持一个Hive表。 String 是 无 分区过滤器 配置分区过滤器可以导出指定分区数据，默认为空，导出整个表数据。 例如导出分区字段locale的值为“CN”或“US”的表数据，输入如下： locale = "CN" or locale = "US" String 否 - Hive输入字段 配置Hive输入信息： 列名：配置Hive列名。 字段名：配置输入字段名。 类型：配置字段类型。 长度：配置字段长度，字段值实际长度太长则按配置的长度截取，“类型”为“CHAR”时实际长度不足则空格补齐，“类型”为“VARCHAR”时实际长度不足则不补齐。 map 是 -

样例 以Hive导出到sqlserver2014数据库为例。 在sqlserver2014上创建一张空表“test_1”用于存储Hive数据。执行以下语句： create table test_1 (id int, name text, value text); 配置“Hive输入”算子，生成三个字段A、B和C： 设置了数据连接器后，单击“自动识别”，系统将自动读取数据库中的字段，可根据需要选择添加，然后根据业务场景手动进行完善或者修正即可，无需逐一手动添加。 此操作会覆盖表格内已有数据。 通过“表输出”算子，将A、B和C输出到“test_1”表中： select * from test_1;

使用Kafka客户端 以客户端安装用户，登录安装客户端的节点。 执行以下命令，切换到客户端安装目录。 cd /opt/client 执行以下命令配置环境变量。 source bigdata_env 执行以下命令，进行用户认证。（普通模式跳过此步骤） kinit 组件业务用户 执行以下命令切换到Kafka客户端安装目录。 cd Kafka/kafka/bin 执行以下命令使用客户端工具查看帮助并使用。 ./kafka-console-consumer.sh：Kafka消息读取工具 ./kafka-console-producer.sh：Kafka消息发布工具 ./kafka-topics.sh：Kafka Topic管理工具 MRS 3.x之前版本：执行以下命令，管理Kafka主题。 创建主题 sh kafka-topics.sh --create --topic 主题名称 --partitions 主题占用的分区数 --replication-factor 主题的备份个数 --zookeeper ZooKeeper角色实例所在节点IP地址:clientPort/kafka 删除主题 sh kafka-topics.sh --delete --topic 主题名称 --zookeeper ZooKeeper角色实例所在节点IP地址:clientPort/kafka 主题分区数和主题备份个数不能大于Kafka角色实例数量。 默认情况下，ZooKeeper的“clientPort”为“2181”。 ZooKeeper角色实例所在节点IP地址，填写三个角色实例其中任意一个的IP地址即可。 MRS 3.x及后续版本：使用kafka-topics.sh管理Kafka主题。 创建主题： Topic的Partition自动划分时，默认根据节点及磁盘上已有的Partition数进行均衡划分，如果期望根据磁盘容量进行Partition划分，那么需要修改Kafka服务配置“log.partition.strategy”为“capacity”。 Kafka创建Topic时，支持基于“机架感知” 和 “跨AZ特性” 两种选项组合生成分区及副本的分配方案且支持 “--zookeeper” 和 “--bootstrap-server”两种方式 禁用机架策略 & 禁用跨AZ特性 (默认策略)。 基于此策略新建的Topic的副本会完全随机分配到集群中任意节点上。 ./kafka-topics.sh --create --topic 主题名称 --partitions 主题占用的分区数 --replication-factor 主题的备份数 --zookeeper ZooKeeper的任意一个节点的业务IP:clientPort/kafka ./kafka-topics.sh --create --topic 主题名称 --partitions 主题占用的分区数 --replication-factor 主题的备份数 --bootstrap-server Kafka集群IP:21007 --command-config ../config/client.properties 其中，使用“--bootstrap-server”方式创建Topic时，需配置“rack.aware.enable=false”和“az.aware.enable=false”。 启用机架策略 & 禁用跨AZ特性。 基于此策略新建的Topic的各个Partition的Leader会在集群节点上随机分配，但会确保同一Partition的不同Replica会分配在不同的机架上，所以当使用此策略时，需保证各个机架内的节点个数一致，否则会导致节点少的机架上的机器负载远高于集群平均水平。 ./kafka-topics.sh --create --topic 主题名称 --partitions 主题占用的分区数 --replication-factor 主题的备份数 --zookeeper ZooKeeper的任意一个节点的业务IP:clientPort/kafka --enable-rack-aware ./kafka-topics.sh --create --topic 主题名称 --partitions 主题占用的分区数 --replication-factor 主题的备份数 --bootstrap-server Kafka集群IP:21007 --command-config ../config/client.properties 其中，使用 “--bootstrap-server”方式创建Topic时，需配置“rack.aware.enable=true”和“az.aware.enable=false”。 禁用机架策略 & 启用跨AZ特性。 基于此策略新建的Topic的各个Partition的Leader会在集群节点上随机分配，但会确保同一Partition的不同Replica会分配在不同的AZ上，所以当使用此策略时，需保证各个AZ内的节点个数一致，否则会导致节点少的AZ上的机器负载远高于集群平均水平。 ./kafka-topics.sh --create --topic 主题名称 --partitions 主题占用的分区数 --replication-factor 主题的备份数 --zookeeper ZooKeeper的任意一个节点的业务IP:clientPort/kafka --enable-az-aware ./kafka-topics.sh --create --topic 主题名称 --partitions 主题占用的分区数 --replication-factor 主题的备份数 --bootstrap-server Kafka集群IP:21007 --command-config ../config/client.properties 其中，使用 “--bootstrap-server”方式创建Topic时，需配置“rack.aware.enable=false”和“az.aware.enable=true”。 启用机架策略 & 启用跨AZ特性。 基于此策略新建的Topic的各个Partition的Leader会在集群节点上随机分配，但会确保同一Partition的不同Replica会分配到不同AZ内的不同RACK上，使用此策略需保证每个AZ内的每个RACK上的节点个数一致，否则会导致集群内负载不均衡。 ./kafka-topics.sh --create --topic 主题名称 --partitions 主题占用的分区数 --replication-factor 主题的备份数 --zookeeper ZooKeeper的任意一个节点的业务IP:clientPort/kafka --enable-rack-aware --enable-az-aware ./kafka-topics.sh --create --topic 主题名称 --partitions 主题占用的分区数 --replication-factor 主题的备份数 --bootstrap-server Kafka集群IP:21007 --command-config ../config/client.properties 使用 “--bootstrap-server”方式创建Topic时，需配置“rack.aware.enable=true”和“az.aware.enable=true”。 Kafka创建Topic支持 “--zookeeper” 和 “--bootstrap-server”两种方式，区别如下： “--zookeeper”方式由客户端生成副本分配方案，社区从一开始就支持这种方式，为了降低对Zookeeper组件的依赖，社区将在后续版本中删除对这种方式的支持。基于这种方式创建Topic时，可以通过 "--enable-rack-aware" 和 “--enable-az-aware”这两个选项自由组合来选用副本分配策略。注意：使用“--enable-az-aware”选项的前提是服务端开启了跨AZ特性，即服务端启动参数“az.aware.enable”为“true”,否则会执行失败。 “--bootstrap-server”方式由服务端生成副本分配方案，后续版本，社区将只支持这种方式来进行Topic管理。基于这种方式创建Topic时，不支持 "--enable-rack-aware" 和 "--enable-az-aware"选项来控制副本分配策略，支持 “rack.aware.enable”和“az.aware.enable”这两个服务启动参数组合来控制副本分配策略，需注意的是“az.aware.enable”参数不可修改，在创建集群时，如果开启跨AZ特性，会自动配置为“true”;“rack.aware.enable”参数支持用户自定义修改。 罗列主题： ./kafka-topics.sh --list --zookeeper ZooKeeper的任意一个节点的业务IP:clientPort/kafka ./kafka-topics.sh --list --bootstrap-server Kafka集群IP:21007 --command-config ../config/client.properties 查看主题： ./kafka-topics.sh --describe --zookeeper ZooKeeper的任意一个节点的业务IP:clientPort/kafka --topic 主题名称 ./kafka-topics.sh --describe --bootstrap-server Kafka集群IP:21007 --command-config ../config/client.properties --topic 主题名称 修改主题： ./kafka-topics.sh --alter --topic 主题名称 --config 配置项=配置值 --zookeeper ZooKeeper的任意一个节点的业务IP:clientPort/kafka 扩展分区： ./kafka-topics.sh --alter --topic 主题名称 --zookeeper ZooKeeper的任意一个节点的业务IP:clientPort/kafka --command-config Kafka/kafka/config/client.properties --partitions 扩展后分区个数 ./kafka-topics.sh --alter --topic 主题名称 --bootstrap-server Kafka集群IP:21007 --command-config Kafka/kafka/config/client.properties --partitions 扩展后分区个数 删除主题： ./kafka-topics.sh --delete --topic 主题名称 --zookeeper ZooKeeper的任意一个节点的业务IP:clientPort/kafka ./kafka-topics.sh --delete --topic 主题名称 --bootstrap-server Kafka集群IP:21007 --command-config ../config/client.properties

问题 HDFS调用FileInputFormat的getSplit方法的时候，出现ArrayIndexOutOfBoundsException: 0，日志如下： java.lang.ArrayIndexOutOfBoundsException: 0at org.apache.hadoop.mapred.FileInputFormat.identifyHosts(FileInputFormat.java:708)at org.apache.hadoop.mapred.FileInputFormat.getSplitHostsAndCachedHosts(FileInputFormat.java:675)at org.apache.hadoop.mapred.FileInputFormat.getSplits(FileInputFormat.java:359)at org.apache.spark.rdd.HadoopRDD.getPartitions(HadoopRDD.scala:210)at org.apache.spark.rdd.RDD$$anonfun$partitions$2.apply(RDD.scala:239)at org.apache.spark.rdd.RDD$$anonfun$partitions$2.apply(RDD.scala:237)at scala.Option.getOrElse(Option.scala:120)at org.apache.spark.rdd.RDD.partitions(RDD.scala:237)at org.apache.spark.rdd.MapPartitionsRDD.getPartitions(MapPartitionsRDD.scala:35)

回答 创建租户的时候需要关联HBase服务和Yarn队列。 例如： 新建用户user并绑定租户同名的角色。 用户user需要使用bulkload功能还需要额外权限。 以下以用户user为例： 参见“批量导入数据”章节举例，以下是一些差异点。 将数据文件目录建在“/tmp”目录下，执行以下命令： hdfs dfs -mkdir /tmp/datadirImport hdfs dfs -put data.txt /tmp/datadirImport 生成HFile的时候使用HDFS的“/tmp”目录： hbase com.huawei.hadoop.hbase.tools.bulkload.ImportData -Dimport.skip.bad.lines=true -Dimport.separator=',' -Dimport.bad.lines.output=/tmp/badline -Dimport.hfile.output=/tmp/hfile configuration.xml ImportTable /tmp/datadirImport 导入HFile的时候使用HDFS的“/tmp”目录： hbase org.apache.hadoop.hbase.mapreduce.LoadIncrementalHFiles /tmp/hfile ImportTable

回答 正常情况下，相同rowkey值的数据加载到HBase是有先后顺序的，HBase以最近的时间戳的数据为最新数据，一般的默认查询中，没有指定时间戳的，就会对相同rowkey值的数据仅返回最新数据。 使用bulkload加载数据，由于数据在内存中处理生成HFile，速度是很快的，很可能出现相同rowkey值的数据具有相同时间戳，从而造成查询结果混乱的情况。 建议在建表和数据加载时，设计好rowkey值，尽量避免在同一个数据文件中存在相同rowkey值的情况。

操作场景 对大批量、连续put的场景，配置下面的两个参数为“false”时能大量提升性能。 “hbase.regionserver.wal.durable.sync” “hbase.regionserver.hfile.durable.sync” 当提升性能时，缺点是对于DataNode（默认是3个）同时故障时，存在小概率数据丢失的现象。对数据可靠性要求高的场景请慎重配置。 本章节适用于MRS 3.x及之后版本。

问题 使用HBase客户端操作表数据的时候客户端出现类似如下异常： 2015-12-15 02:41:14,054 | WARN | [task-result-getter-2] | Lost task 2.0 in stage 58.0 (TID 3288, linux-175): org.apache.hadoop.hbase.client.RetriesExhaustedException: Failed after attempts=36, exceptions:Tue Dec 15 02:41:14 CST 2015, null, java.net.SocketTimeoutException: callTimeout=60000, callDuration=60303: row 'xxxxxx' on table 'xxxxxx' at region=xxxxxx,\x05\x1E\x80\x00\x00\x00\x80\x00\x00\x00\x00\x00\x00\x00\x80\x00\x00\x00\x00\x00\x00\x000\x00\x80\x00\x00\x00\x80\x00\x00\x00\x80\x00\x00,1449912620868.6a6b7d0c272803d8186930a3bfdb10a9., hostname=xxxxxx,16020,1449941841479, seqNum=5at org.apache.hadoop.hbase.client.RpcRetryingCallerWithReadReplicas.throwEnrichedException(RpcRetryingCallerWithReadReplicas.java:275)at org.apache.hadoop.hbase.client.ScannerCallableWithReplicas.call(ScannerCallableWithReplicas.java:223)at org.apache.hadoop.hbase.client.ScannerCallableWithReplicas.call(ScannerCallableWithReplicas.java:61)at org.apache.hadoop.hbase.client.RpcRetryingCaller.callWithoutRetries(RpcRetryingCaller.java:200)at org.apache.hadoop.hbase.client.ClientScanner.call(ClientScanner.java:323)

回答 出现该问题的主要原因为RegionServer分配的内存过小、Region数量过大导致在运行过程中内存不足，服务端对客户端的响应过慢。在RegionServer的配置文件“hbase-site.xml”中需要调整如下对应的内存分配参数。 表1 RegionServer内存调整参数 参数 描述 默认值 GC_OPTS 在启动参数中给RegionServer分配的初始内存和最大内存。 -Xms8G -Xmx8G hfile.block.cache.size 分配给HFile/StoreFile所使用的块缓存的最大heap（-Xmx setting）的百分比。 当offheap关闭时，默认值为0.25。当offheap开启时，默认值是0.1。

Hive使用WHERE条件查询超过3.2万分区的表报错 问题： Hive创建超过3.2万分区的表，执行带有WHERE分区的条件查询时出现异常，且“metastore.log”中打印的异常信息包含以下信息： Caused by: java.io.IOException: Tried to send an out-of-range integer as a 2-byte value: 32970 at org.postgresql.core.PGStream.SendInteger2(PGStream.java:199) at org.postgresql.core.v3.QueryExecutorImpl.sendParse(QueryExecutorImpl.java:1330) at org.postgresql.core.v3.QueryExecutorImpl.sendOneQuery(QueryExecutorImpl.java:1601) at org.postgresql.core.v3.QueryExecutorImpl.sendParse(QueryExecutorImpl.java:1191) at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:346) 回答： 带有分区条件的查询，Hiveserver会对分区进行优化，避免全表扫描，需要查询元数据符合条件的所有分区。 而gaussDB中提供的接口sendOneQuery，调用的sendParse方法中对参数的限制为32767，如果分区条件数超过32767就会产生异常。 父主题： Hive常见问题

回答 当Standby NameNode存储元数据（命名空间）时，出现断电的情况，Standby NameNode启动失败，MD5文件会损坏。通过移除损坏的fsimage，然后启动Standby NameNode，可以修复此问题。Standby NameNode会加载先前的fsimage并重现所有的edits。 修复步骤： 移除损坏的fsimage。 rm -rf ${BIGDATA_DATA_HOME}/namenode/current/fsimage_0000000000000096 启动Standby NameNode。

Flume客户端Cgroup使用指导 加入Cgroup 执行以下命令，加入Cgroup，假设Flume客户端安装路径为“/opt/FlumeClient”，Cgroup cpu阈值设置为50%： cd /opt/FlumeClient/fusioninsight-flume-1.9.0/bin ./flume-manage.sh cgroup join 50 该命令不仅可以加入Cgroup，同时也可以更改Cgroup cpu阈值。 Cgroup cpu阈值取值范围为1~100*N之间的整数，N表示机器cpu核数。 查询Cgroup状态 执行以下命令，查询Cgroup状态，假设Flume客户端安装路径为“/opt/FlumeClient”： cd /opt/FlumeClient/fusioninsight-flume-1.9.0/bin ./flume-manage.sh cgroup status 退出Cgroup 执行以下命令，退出Cgroup，假设Flume客户端安装路径为“/opt/FlumeClient”： cd /opt/FlumeClient/fusioninsight-flume-1.9.0/bin ./flume-manage.sh cgroup exit 客户端安装完成后，会自动创建默认Cgroup。若安装客户端时未配置“-s”参数，则默认值为“-1”，表示agent进程不受cpu使用率限制。 加入、退出Cgroup时，agent进程不受影响。若agent进程未启动，加入、退出Cgroup仍然可以成功执行，待下一次agent启动时生效。 客户端卸载完成后，安装时期创建的Cgroup会自动删除。

操作步骤 参数入口：执行批量加载任务时，在BulkLoad命令行中加入如下参数。 表1 增强BulkLoad效率的配置项 参数 描述 配置的值 -Dimporttsv.mapper.class 用户自定义mapper通过把键值对的构造从mapper移动到reducer以帮助提高性能。mapper只需要把每一行的原始文本发送给reducer，reducer解析每一行的每一条记录并创建键值对。 说明： 当该值配置为“org.apache.hadoop.hbase.mapreduce.TsvImporterByteMapper”时，只在执行没有HBASE_CELL_VISIBILITY OR HBASE_CELL_TTL选项的批量加载命令时使用。使用“org.apache.hadoop.hbase.mapreduce.TsvImporterByteMapper”时可以得到更好的性能。 org.apache.hadoop.hbase.mapreduce.TsvImporterByteMapper 和 org.apache.hadoop.hbase.mapreduce.TsvImporterTextMapper

配置描述 请参考修改集群服务配置参数，进入HDFS的“全部配置”页面，在搜索框中输入参数名称。 表1 NameNode blacklisting的相关参数 参数 描述 默认值 dfs.client.failover.proxy.provider.[nameservice ID] 利用已通过的协议创建namenode代理的Client Failover proxy provider类。 将参数值设置为“org.apache.hadoop.hdfs.server.namenode.ha.BlackListingFailoverProxyProvider”， 可使用从NameNode支持读的特性。 org.apache.hadoop.hdfs.server.namenode.ha.AdaptiveFailoverProxyProvider