说明

永洪BI项目不同阶段的可能报错整理。

1. 环境部署

以Centos8.1服务器环境为例，部署一套单C的永洪服务，记录并解决可能遇到的报错。

1.1. Jdk报错

建议永洪部署使用JDK9及以上版本，推荐11，如果采用系统默认的1.8open jdk，版本过低启动服务会无法查看到进程

排查原因：

1.JDK版本

2.JDK环境变量配置（11版本的jdk和jre配置同一个路径即可）

1.2. 端口占用

端口占用或是防火墙限制都可能导致无法通过设置的端口访问到服务

1.端口占用Catalina.out中有明显的提示

2.防火墙问题导致浏览器无法访问server端，需自行检查或配置server端的防火墙。

1.3. Jvm内存占用问题

同样的内存占用问题将会在Catalina.out中看到明显的提示信息

解决：修改catalina.sh文件的内存配置信息即可，当然如果是硬件配置不足只能更换服务器或提升配置

1.4. 字体

部分操作系统或是openJDK可能会由于字体配置不完全导致安装或启动服务失败，可以执行yum -install fontconfig命令安装字体。报错信息会看到明显的font报错提示。

如果服务器无法使用yum命令，需要用户安装离线字体库，字体资源请到官网或其他渠道获取。安装完成后测试fc-list，正确的输出信息如下：

1.5. 空间、读写权限等

1. 大部分环境在导入永洪安装包后，需chmod命令给.sh文件分配读写权限方可正常安装。

2. 安装服务的路径需确认该目录的读写权限是否有特殊设置，过少的权限可能导致服务在该路径下无法正常启动。

3. 磁盘I/O异常，物理机或所挂磁盘的硬件读写故障导致服务的部署或启动过程报错。

2. 数据源

1.Kerberos错误排查基本方法

1.1 检查驱动

一般情况下kerberos的驱动都是由很多jar组成。

1.2 检查数据源配置项

主要检查各项配置文件是否正确。

1.3 检查主机时间

这一步非常重要，一定要确保永洪主机和KDC主机时间（包含时区）一致。

1.4 核对keytab文件和用户名

这是本次遇到的新问题，建议大家以后都让客户提供最新的keytab文件。

1.5 核对jaas文件

一定要注意的是keyTab和principal，在本次排查中也发现需要配置useKeyTab=true。

Client {

 com.sun.security.auth.module.Krb5LoginModule required

 useKeyTab=true

 keyTab="/app/user.keytab"      --同密钥文件路径

 storeKey=true

 useTicketCache=false

 principal="yonghong@HADOOP.COM";   --同用户名

     debug=true

};

(加粗字体为本地环境值）

2.常见报错

以下为几种永洪BI关于Kerbero连接出现的常见报错的可能原因和解决方案。

•出现报错，提示中包含“org.apache.hadoop.conf.Configuration”，“NoClassDefFoundError:org/apache/thrift/protocol”。

报错原因：hive驱动Jar不全；

可用解决方案：上传完整的hive驱动。

•出现报错，提示中包含“Cannot obtain password for user”。

报错原因：用户的jaas.conf中配置的是不使用keytab登录，jaas.conf中的useKeyTab属性设置为false或useKeyTab属性设置为true，keyTab属性未设置；

可用解决方案：更新jaas文件。

•出现报错，提示中包含“Unable to read HiveServer2 configs from ZooKeeper”。

报错原因：jaas文件里面配置的principal和数据源的用户名不一致。

可用解决方案：更新jaas文件。

•出现报错，提示中包含“Unsupported mechanism type PLAIN”。

报错原因：永洪BI使用非Kerberos登录访问设置了Kerberos的数据库；

可用解决方案：改为Kerberos访问。

•出现报错，提示中包含“over max connections”。

报错原因：业务量大导致连接HiveServer单个节点的连接数超过了最大连接数，需要调大连接HiveServer实例的最大连接数；

可用解决方案：登录MRS Manager页面，访问“服务管理 > Hive > 服务配置 > 参数类别（选择全部配置）”，搜索        hive.server.session.control.maxconnections配置项，修改hive.server.session.control.maxconnections配置的值到合适值，不能超过1000。保存配置并重启受影响的服务或者实例。

•连接HBase时出现“Ensure that config phoenix.schema.isNamespaceMappingEnabled is consistent on client and server”。

报错原因：在连接时设置了 phoenix.schema.isNamespaceMappingEnabled 为 true；

可用解决方案：

方案1： 推荐使用该方案，修改FusionInsight的配置，配置可以参考以下文档：

https://blog.csdn.net/zhangshenghang/article/details/97892067。

方案2：修改永洪BI配置：

先关闭永洪服务器，修改/opt/YH/Yonghong/bihome/bi.properties，增加如下配置：

phoenix.schema.isNamespaceMappingEnabled=false

关于namespace mapping的详细介绍参见如下文档：http://phoenix.apache.org/namspace_mapping.html。

3.永洪BI连接多KDC方案

将多个 KDC 的信息合并到一个 krb5.conf 中，将该文件路径配置到永洪BI【数据源】模块的【krb5文件路径】项

• 在 [realms] 条目下增加多个 Realm 对应的 KDC 信息。

➢示例：

[realms]

HADOOP.COM = {

 kdc = 192.168.1.228

 admin_server = 192.168.1.228

}

 HADOOP2.COM = {

 kdc = 192.168.1.223

 admin_server = 192.168.1.223

}

•在 [domain_realm] 配置项下增加多个 domian realm 。

➢示例：

[domain_realm]

.hadoop.com = HADOOP.COM

hadoop.com = HADOOP.COM

.hadoop2.com = HADOOP2.COM

hadoop2.com = HADOOP2.COM

• [libdefaults] 配置项下的default_realm 可以配置任意一个 KDC 的 realm 。

•在配置永洪数据源时，所有的 principal 都要指定 realm 。

➢示例：

hive/yonghong.com/HADOOP.COM

➢错误实例：

hive/yonghong.com

hive

3. 数据集

3.1. 数据集市常见问题

https://www.yonghongtech.com/real-help/Z-Suite/10.0/ch/tuningexperience.html?

3.2. 执行迁移常见报错

执行迁移的时候，报错“等待 job@XXX 超时”

永洪的MPP数据集市数据查询任务超时时间默认是“mpp.scheduler.exec.timeout=900000”，当执行大数据量迁移任务的时候，可能会超过这个时间，建议在执行数据迁移之前将这个参数添加到“bi.properties”文件中，并设置为“1800000”。

3.3. SQL数据集报错

1.执行数据失败：

g5.util.RTWrappedException:java.sql.SQLException:[Simba][ImpalaJDBCDriver](500312)Error in fetching data rows:Invalid query handle:7744ebcb1e8fc038….

原因：示例环境为impala，标红位置确定了是数据记录条数太多无法获取数据。问题出在impala即上游的数据库数据量限制，可以通过对sql语句进行where条件时间维度的限制解决。

2. 执行数据失败： 500150

Error fetching the data in buffer:Buffer Fetch Error

原因：实际问题也处在加载数据请求处，缓存中的数据过多无法正常提取，个可以通过对sql语句进行where条件时间维度的限制解决。

Sql语句、语法、逻辑、数据量等等。

3.关联报错

原因：Sql中join的表数据量和字段数都需要做筛选和删减，过多的join行数超出了系统的参数最大配置。

3.4. 组合数据集报错

数据量、字段数量、关联方式、时间维度、组合主键和组合的原始数据集个数与逻辑

3.4.1. 内存

执行SQL失败：“[Simba][ImpalaJDBCDriver](500051) ERROR processing query/statement. Error Code: ERROR_STATE, SQL state: Memory limit exceeded

原因：也是由于数据没有做数据量限制，导致提取的数据吃满了节点的内存，一方面如果想通过BI提取，应该尝试从不同维度缩小数据量；如果确有大数据量提取需求，可以使用hadoop或hive直接提取。

3.4.2. Excel数据集与sql数据集组合报错

一般不建议将二者做组合，大概率会报错，占用服务器过高的资源。

原因：excel数据集使用产品内存计算，sql数据集下推数据库计算，二者组合会将全部的关联和计算放在BI服务中执行，原本excel的内存占用以指数形式增长，必然会占满资源报错。因此，excel与其他组合建议使用，where条件in限制筛选。

4. 报告制作

4.1. 交叉表常见报错

执行数据失败：pivot.max.cells

原因：

1.汇总计算处绑定的字段过多，实际上是聚合计算过多但是也可能报出单元格的错误，容易误导。

2.单元格合并操作过多。

3.数据量太大前台预览占用的单元格过多。

4.2. 过滤、参数组件报错

4.3. 参数传递

注意传递的参数名称与本页面已有的参数组件不能重名；

部分Sql数据集中生成的参数必须要有初始值才可以正常查询数据，查询或绑定数据列为空时需检查此项。

4.4. 权限报错

原因：一般的系统建设，普通用户只分配一部分目录的读权限，而没有写权限，这控制了一些固定报表的不可修改性，因此会提示没有权限执行保存操作。

4.5. 表达式函数报错

当环境是hive等时，使用产品预定义的某些函数容易导致报错，但这些问题并非由BI产品导致，例如distinct count函数与在hive中执行本身就容易触发莫名的报错，使用过程中开发人员需自行规范和优化。

5. 查看报告

5.1. 数据项报错：数据项超数值提示

产品参数设置不超过一个值，使用参数列表及过滤列表时需注意其中每个不同的选项都会计数算作一个数据项，因此在绑定数据列时这两个组件不能绑定数据项太多的字段，组件本身的效果也不适用于展示选项过多的情况。

5.2. 渲染

部分渲染过于复杂和BI计算逻辑过多的报告可能出现此问题，在渲染慢报错的同时也可能出现组件本身的显示bug，例如：网格线、分页、图例标题、点图大小等等

5.3. 空数据

一般非参数和数据源问题导致的空数据可以自行一条条检查过滤条件，缩小范围确定导致过滤掉大量数据的异常条件是什么，详细探究原因。

5.4. 重复数据

有些情况下，例如保险的一个单号可能对应不同的流程节点，但几条记录除节点标识外的所有字段值均相同，此时如果将节点标识外的字段拉到表格中并取消聚合会出现多条一模一样的记录，此时重复数据的现象并非真实，需帮助业务用户区分。

5.5. 数据失真

一般制作报告页面看到的数据都是样本数据，设置部分过滤条件或参数限制可能也没来的及对当前页面的样本数据生效，此时应该以查看报告和导出的数据为准。

5.6. 硬件故障报错

执行数据失败：执行SQL失败：“[Simba][ImpalaJDBCDriver](500051) ERROR processing query/statement. Error Code: ERROR_STATE, SQL state: Disk I/O error on cdh111.hadoop.ccic:22000: Failed to open HDFS file

原因：如提示信息，磁盘IO故障，与系统本身无关，所连接数据源的数据读写问题。

6. 输出、订阅等协作

6.1. 输出提示转队列满

原因：部分环境由于使用系统人数过多和数据量过大，将超出一定大小的文件导出任务转换为后台转队列任务执行，完成后将在消息中心和配置邮件中提醒用户。该转队列任务并发数可以通过参数配置，超过该参数值的新增转队列请求智能等待之前的任务完成才可以开始，因此这种情况只能错峰使用。

6.2. 输出excel不成功

当数据量超出excel文件展示范围时，强行使用excel保存可能导致丢失越界的部分数据，产品会提示使用csv导出，除了不会带出dashboard等格式意外，csv的数据与使用excel无任何区别。

6.3. 输出csv加载慢

部分数据量过大的报表导出csv文件时加载非常慢，无法快速处理到下载文件页面，甚至下载的csv压缩文件超出几个G的大小，此时数据的提取并不建议使用BI，除了占用大量资源外，对业务提数的体验也不好。一方面，可以将数据从某些维度切分，分段导出；另一方面可以直接连接数据库使用hive等手段直接提数，不经过BI