SQL和DataFrame-华为云

MAPREDUCE服务 MRS-cache table使用指导:回答

回答 Spark SQL可以将表cache到内存中，并且使用压缩存储来尽量减少内存压力。通过将表cache，查询可以直接从内存中读取数据，从而减少读取磁盘带来的内存开销。但需要注意的是，被cache的表会占用executor的内存。尽管在Spark SQL采用压缩存储的方式来尽量减少内存开销、缓解GC压力，但当缓存的表较大或者缓存表数量较多时，将不可避免的影响executor的稳定性。此时的最佳实践是，当不需要将表cache来实现查询加速时，应及时将表进行uncache以释放内存。可以执行命令uncache table table_name来uncache表。被cache的表也可以在Spark Driver UI的Storage标签里查看。

MAPREDUCE服务 MRS SQL和DataFrame

MAPREDUCE服务 MRS-cache table使用指导:回答

回答 Spark SQL可以将表cache到内存中，并且使用压缩存储来尽量减少内存压力。通过将表cache，查询可以直接从内存中读取数据，从而减少读取磁盘带来的内存开销。但需要注意的是，被cache的表会占用executor的内存。尽管在Spark SQL采用压缩存储的方式来尽量减少内存开销、缓解GC压力，但当缓存的表较大或者缓存表数量较多时，将不可避免的影响executor的稳定性。此时的最佳实践是，当不需要将表cache来实现查询加速时，应及时将表进行uncache以释放内存。可以执行命令uncache table table_name来uncache表。被cache的表也可以在Spark Driver UI的Storage标签里查看。

MAPREDUCE服务 MRS SQL和DataFrame

MAPREDUCE服务 MRS-在Beeline/JDBCServer模式下连续运行10T的TPCDS测试套会出现内存不足的现象:回答

回答当前在默认配置下，在内存中保留的Job和Stage的UI数据个数为1000个。当前大集群优化已增加将UI数据溢出到磁盘的优化，其溢出条件是每个Stage中的UI数据大小达到最小阈值5MB。如果每个Stage的task数较小，那么其UI数据大小可能达不到该阈值，从而导致该Stage的UI数据一直缓存在内存中，直到UI数据个数到达保留的上限值（当前默认值为1000个），旧的UI数据才会在内存中被清除。因此，在将旧的UI数据从内存中清除之前，UI数据会占用大量内存，从而导致执行10T的TPCDS测试套时出现Driver内存不足的现象。规避措施：根据业务需要，配置合适的需要保留的Job和Stage的UI数据个数，即配置“spark.ui.retainedJobs”和“spark.ui.retainedStages”参数。详细信息请参考常用参数中的表13。如果需要保留的Job和Stage的UI数据个数较多，可通过配置“spark.driver.memory”参数，适当增大Driver的内存。详细信息请参考常用参数中的表10。

MAPREDUCE服务 MRS SQL和DataFrame

MAPREDUCE服务 MRS-Spark SQL无法查询到Parquet类型的Hive表的新插入数据:回答

回答由于Spark存在一个机制，为了提高性能会缓存Parquet的元数据信息。当通过Hive或其他方式更新了Parquet表时，缓存的元数据信息未更新，导致Spark SQL查询不到新插入的数据。对于存储类型为Parquet的Hive分区表，在执行插入数据操作后，如果分区信息未改变，则缓存的元数据信息未更新，导致Spark SQL查询不到新插入的数据。解决措施：在使用Spark SQL查询之前，需执行Refresh操作更新元数据信息。 REFRESH TABLE table_name; table_name为刷新的表名，该表必须存在，否则会出错。执行查询语句时，即可获取到最新插入的数据。

MAPREDUCE服务 MRS SQL和DataFrame

MAPREDUCE服务 MRS-Spark SQL无法查询到Parquet类型的Hive表的新插入数据:回答

回答由于Spark存在一个机制，为了提高性能会缓存Parquet的元数据信息。当通过Hive或其他方式更新了Parquet表时，缓存的元数据信息未更新，导致Spark SQL查询不到新插入的数据。对于存储类型为Parquet的Hive分区表，在执行插入数据操作后，如果分区信息未改变，则缓存的元数据信息未更新，导致Spark SQL查询不到新插入的数据。解决措施：在使用Spark SQL查询之前，需执行Refresh操作更新元数据信息。 REFRESH TABLE table_name; table_name为刷新的表名，该表必须存在，否则会出错。执行查询语句时，即可获取到最新插入的数据。

MAPREDUCE服务 MRS SQL和DataFrame

MAPREDUCE服务 MRS-日期类型的字段作为过滤条件时匹配'2016-6-30'时没有查询结果:问题

问题为什么日期类型的字段作为过滤条件时匹配'2016-6-30'时没有查询结果，匹配'2016-06-30'时有查询结果。如下图所示：“select count(*)from trxfintrx2012 a where trx_dte_par='2016-6-30'”，其中trx_dte_par为日期类型的字段，当过滤条件为“where trx_dte_par='2016-6-30'”时没有查询结果，当过滤条件为“where trx_dte_par='2016-06-30'”时有查询结果。

MAPREDUCE服务 MRS SQL和DataFrame

MAPREDUCE服务 MRS-Spark SQL在不同DB都可以显示临时表:回答

回答 Spark的表管理层次如图1所示，最底层是Spark的临时表，存储着使用DataSource方式的临时表，在这一个层面中没有数据库的概念，因此对于这种类型表，表名在各个数据库中都是可见的。上层为Hive的MetaStore，该层有了各个DB之分。在每个DB中，又有Hive的临时表与Hive的持久化表，因此在Spark中允许三个层次的同名数据表。查询的时候，Spark SQL优先查看是否有Spark的临时表，再查找当前DB的Hive临时表，最后查找当前DB的Hive持久化表。图1 Spark表管理层次当Session退出时，用户操作相关的临时表将自动删除。建议用户不要手动删除临时表。删除临时表时，其优先级与查询相同，从高到低为Spark临时表、Hive临时表、Hive持久化表。如果想直接删除Hive表，不删除Spark临时表，您可以直接使用drop table DbName.TableName命令。

MAPREDUCE服务 MRS SQL和DataFrame

MAPREDUCE服务 MRS-为什么有时访问没有权限的parquet表时，在上报“Missing Privileges”错误提示之前，会运行一个Job？:回答

回答 Spark SQL对用户SQL语句的执行逻辑是：首先解析出语句中包含的表，再获取表的元数据信息，然后对权限进行检查。当表是parquet表时，元数据信息包括文件的Split信息。Split信息需要调用HDFS的接口去读取，当表包含的文件数量很多时，串行读取Split信息变得缓慢，影响性能。故对此做了优化，当表包含的文件大于一定阈值（即spark.sql.sources.parallelSplitDiscovery.threshold参数值）时，会生成一个Job，利用Executor的并行能力去读取，从而提升执行效率。由于权限检查在获取表元数据之后，因此当读取的parquet表包含的文件数量很多时，会在报“Missing Privileges”之前，运行一个Job来并行读取元数据信息。

MAPREDUCE服务 MRS SQL和DataFrame

MAPREDUCE服务 MRS-当表名为table时，执行相关操作时出现异常:问题

问题当创建了表名为table的表后，执行drop table table上报以下错误，或者执行其他操作也会出现类似错误。 16/07/12 18:56:29 ERROR SparkSQLDriver: Failed in [drop table table] java.lang.RuntimeException: [1.1] failure: identifier expected table ^ at scala.sys.package$.error(package.scala:27) at org.apache.spark.sql.catalyst.SqlParserTrait$class.parseTableIdentifier(SqlParser.scala:56) at org.apache.spark.sql.catalyst.SqlParser$.parseTableIdentifier(SqlParser.scala:485)

MAPREDUCE服务 MRS SQL和DataFrame

MAPREDUCE服务 MRS-Spark2x无法访问Spark1.5创建的DataSource表:回答

回答原因分析：这是由于Spark2x与Spark1.5存储DataSoure表信息的格式不一致导致的。Spark1.5会将schema信息分成多个part，使用path.park.0作为key进行存储，读取时再将各个part都读取出来，重新拼成完整的信息。而Spark2x直接使用相应的key获取对应的信息。这样在Spark2x中去读取Spark1.5创建的DataSource表时，就无法成功读取到key对应的信息，导致解析DataSource表信息失败。而在处理Hive格式的表时，Spark2x与Spark1.5的存储方式一致，所以Spark2x可以直接读取Spark1.5创建的表，不存在上述问题。规避措施： Spark2x可以通过创建外表的方式来创建一张指向Spark1.5表实际数据的表，这样可以实现在Spark2x中读取Spark1.5创建的DataSource表。同时，Spark1.5更新过数据后，Spark2x中访问也能感知到变化，反过来一样。这样即可实现Spark2x对Spark1.5创建的DataSource表的访问。

MAPREDUCE服务 MRS SQL和DataFrame

MAPREDUCE服务 MRS-Spark SQL无法查询到ORC类型的Hive表的新插入数据:回答

回答由于Spark存在一个机制，为了提高性能会缓存ORC的元数据信息。当通过Hive或其他方式更新了ORC表时，缓存的元数据信息未更新，导致Spark SQL查询不到新插入的数据。对于存储类型为ORC的Hive分区表，在执行插入数据操作后，如果分区信息未改变，则缓存的元数据信息未更新，导致Spark SQL查询不到新插入的数据。解决措施：在使用Spark SQL查询之前，需执行Refresh操作更新元数据信息： REFRESH TABLE table_name; table_name为刷新的表名，该表必须存在，否则会出错。执行查询语句时，即可获取到最新插入的数据。使用sqark时，执行以下命令禁用Spark优化： set spark.sql.hive.convertMetastoreOrc=false;

MAPREDUCE服务 MRS SQL和DataFrame

MapReduce服务 MRS-INSERT...SELECT操作调优:操作步骤

操作步骤可对INSERT...SELECT操作做如下的调优操作。如果建的是Hive表，将存储类型设为Parquet，从而减少执行INSERT...SELECT语句的时间。建议使用spark-sql或者在beeline/thriftserver模式下使用spark用户来执行INSERT...SELECT操作，避免执行更改文件owner的操作，从而减少执行INSERT...SELECT语句的时间。在beeline/thriftserver模式下，executor的用户跟driver是一致的，driver是thriftserver服务的一部分，是由spark用户启动的，因此其用户也是spark用户，且当前无法实现在运行时将beeline端的用户透传到executor，因此使用非spark用户时需要对文件进行更改owner为beeline端的用户，即实际用户。

MapReduce服务 MRS SQL和DataFrame调优

云服务器内容精选

SQL和DataFrame

7*24

备案

专业服务

退订

建议反馈

售前咨询热线