为有分区的表创建视图时,遇到的有趣的现象

sprays 2017-11-24 04:59:43
有两张结构相似的业务订单表,分别记录上海和北京分公司的数据,每次取数都要union一下很麻烦,所以想建视图将两张表union起来。两张源表都有增量更新的分区d,取数时只需取分区d=今天的数据。

我先建了如下视图。得让用户分辨每笔订单来自哪张源表吧,所以加了一个OS字段。
use XXX_DB;
drop view if exists xxx_test;
create view xxx_test (
OS comment '订单系统',
OrderID comment '订单号'
)
comment 'XXX'
as
select
'shanghai' as OS,
OrderID
from 订单表1
where d = from_unixTime(unix_Timestamp(),'yyyy-MM-dd')

union all
select
'beijing' as OS,
OrderID
from 订单表2
where d = from_unixTime(unix_Timestamp(),'yyyy-MM-dd')


基本就可以正常使用了。
但偶然发现:如果查询视图时写了where OS='shanghai',就会报错 No partition predicate found for Alias(似乎只有这样会引发报错场景)。这是没有指定分区的报错,但视图里明明指定了啊。而且分区和OS有什么关系,为什么偏偏在where OS时才报分区的错?

解决方案1:既然说我没指定分区,那在查询视图时加上
set hive.mapred.mode = nonstrict;

总行了吧。实测的确可行。但这给使用视图平添了麻烦啊。

解决方案2:OS的唯一的与众不同之处,在于它是额外添加的静态值字段,因此就受到“歧视”了?但我真的需要OS这个标记啊,于是想基于源表里的某个字段写一个表达式,只要最后恒输出'shanghai'/'beijing'就行了。试了如下3种写法:(背景:OrderID总是大于0的)
case when OrderID > 0 then 'shanghai' else 'shanghai' end as OS,
case when 1 = 1 then 'shanghai' else OrderID end as OS,
case when OrderID > 0 then 'shanghai' else OrderID end as OS,

结果是前两种仍然会报错,第三种写法成功了。看来系统还挺机灵的,如果表达式写得不够隐蔽,让系统识别出表达式恒等于某个静态值,就依然没戏。

问题是解决了,想问下为什么hive会有这种对静态值的“歧视”呢?有大神能解释下内部的机理吗?
...全文
541 1 打赏 收藏 转发到动态 举报
写回复
用AI写文章
1 条回复
切换为时间正序
请发表友善的回复…
发表回复
frankzx 2018-01-01
  • 打赏
  • 举报
回复
学习了,竟然还有这种情况,没遇到过。继续关注,等大神来解答
SQLServer安全及性能优化 修补漏洞 安装程序补丁修补漏洞 随关注微软官方网站补丁升级 关闭不必要的端口 关闭联必要的服务 数据库引擎 SQL Server Analysis Services SQL Server Reporting Services SQL Server Integration Services SQL Server 代理 SQL Full-text Filter Daemon launcher SQL Server Browser 同开启所有服务系统性能会变得很差,根据需要手动启动或者禁用某个服务 DTC: Distributed Transaction Coordinator(分布式事务处理协调器),用于协调多个数据库、消息队列、文件系统等等资源管理器的事务,由于内部开发中并不使用这个功能,远程数据库服务器上也并不经常使用,因此建议关闭这个服务 禁用不使用的协议 Shared Memory 默认为已启用状态,这个协议只能用于本地连接,不能用于远程连接,一般用于其它协议出问题的候管理作诊断使用 TCP/IP 禁用不需要使用的协议,减少网络攻击对象 减少监听的网卡和IP地址 改变监听端口号 安全地设置账户 Windows身份验证[微软推荐的方式] 优势: 1.访问SqlServer速度更快,不用输入用户名和密码 2.可以利用Windows系统的自身工具和安全策略管理账户 3.安全确认和口令加密、审核、口令失效、最小口令长度和账号锁定 SqlServer身份验证 1.将sa账户名更改为其它账户名比如nocial,防止黑客利用sa进行攻击 2.删除不使用的账户 3.对已有账户设置安全密码[强制密码规则] 4.限制登录->远程登录、匿名登录 5.限制用户角色和权限,一般将权限设置到最低。设置角色的候不要为public角色授予任何权限,并且从sysadmin这个角色中删除windows的administrators组,提高系统安全性。 删除不必要的数据库对象 删除危险的存储过程 xp_cmdshell:执行操作系统命令,这是一个系统后门[可以移动文件位置、创建用户、提升用户权限],建议不需要则删除掉。 ole自动化存储过程 任务管理存储过程 强化文件和目录安全 数据库最终以文件的形式存储在文件系统中 使用NTFS设置权限 限制共享【不能设置为完全控制】 及审核日志 sqlserver的审核机制可以帮助跟踪并且阻止系统中没有授权的用户他的行为。比如没有授权的用户登录系统会阻止这次登录,并且把这次操作给记录下来。审核机制既能跟踪失败记录也能跟踪成功记录。所有的数据库平台均在不同程度上提供了审查功能。 跟踪用户行为 保护数据库 数据库性能优化 数据库的性能优化主要有两个方面:减少查询比较次数、减少资源的征用。 使用工具Sql Server Profiler优化数据库的性能,减少资源的征用 SqlServer Profiler的功能 Sql Server Profiler的用法  定义跟踪  登录连接、失败和断开  Select、Insert、Update和Delete语句  SQL批处理的开始或结束  写入到Sql server错误日志的错误  安全权限检查  Profiler执行的事件 让Profiler监视我们感兴趣的事件,可以监视的事件太多,监视太多会大大降低性能和增大数据,只监视与数据库的性能密切相关的哪些事件。常见的感兴趣的事件:  执行查询的性能  单个用户或应用程序的活动  逻辑磁盘的读写  语句级别上的CPU占用  Standart模板的事件类 优化数据库性能可以从五个层次来进行:  优先级一:减少数据的访问【减少磁盘访问】  优先级二:返回更少数据【减少网络传输或磁盘访问】  优先级三:减少交互次数【减少网络传输或磁盘访问】  优先级四:减少开销【减少CPU及内存开销】  优先级五:利用更多资源【增加资源】 技术上从四个方面来解决性能优化问题 1、调整数据库结构设计 2、调整应用程序结构设计 3、调整数据库SQL语句 4、调整服务器内存分配 如果不熟悉sqlserver可以使用数据库引擎优化顾问来对数据库提出优化建议,然后通过系统管理的修改达到目的。 数据库引擎优化顾问  数据库引擎优化顾问介绍  分析一个或多个数据库的工作负荷和物理实现,工作负荷可以是优化的sql语句或者sqlserver profiler的跟踪文件和数据。我们可以在运行引擎优化顾问前运用sqlserver profiler记录一些事件,然后将跟踪结果存储为文件或者数据,然后把这些提供给数据库引擎优化顾问,让它去分析。  提出合理的物理设计结构,物理设计结构包括数据库中的索引、索引视图、非聚集索引、聚集索引视图等等。对工作负荷进行分析后,数据库优化顾问会建议添加删除修改数据库的物理设计结构。推荐一组合理的物理结构以降低工作负荷的开销。从而提高数据库的性能 数据库性能优化的常见问题 如何发现问题,如何分析导致性能降低的原因仍然是数据库管理员要掌握的知识。 事务占用资源的间过长,造成阻塞 许多用户同访问数据库的候会产生大量事务,许多用户同竞争一个资源导致占用资源的间过长,造成阻塞。从而降低了数据库执行效率。产生这样的现象的原因如下: 1、多连接查询,查询期间占用多个 2、事务需要占用太多资源,容易出现多个事务占用对方资源的状况。从而导致死锁 解决之道: 1、避免多连接查询,联合过多的会在查询中占用过多的资源。很容易因为别的事务占用资源而相互等待。 2、使用统一的SQL语句规范,特别是访问的顺序要保持一致,这样可以避免互相占用资源而导致的死锁。 不合理的数据文件设置,影响事务处理的性能 当事务处理产生大量数据的候,数据文件的大小如果设置不合理将导致数据文件的不断扩展,这也会影响到事务处理的性能,进而影响到整个数据库的性能。 1、频繁操作数据库,导致日志文件增长的过快,因为日志文件记录数据库的原始操作。所以它的增长速度比数据文件要快得多。当日志文件的增长大小设置不合理的候会导致频繁地扩展文件。从而影响性能 2、查询操作比较频繁,系统数据Tempdb的大小设置不合理。 查询操作比较频繁的候系统数据Tempdb增长得会比较快,因为查询所产生的临数据都存放在这个数据库上。如果Tempdb过小当查询数据量较大的候Tempdb会自动扩展,如果遇到频繁的查询会导致Tempdb不断扩展,从而影响系统性能。这种情况我尽可能地使查询的返回结果比较小 3、大量插入数据,导致数据文件增长过快。不要设置数据文件的自动收缩,它会在忙碌的系统上导致不必要的性能开销。所以如果没有特别需要不要设置数据库的自动收缩。最好采用手动收缩。 磁盘数据组织不合理,导致磁盘的访问次数过多 数据库的磁盘访问都是按照页来访问数据的,无论访问的数据再少都是以页为单位读取,1页为8K。所以如果将经常访问的数据放在一起,数据库读取尽量少的页面就能够完成读取操作。这样效率自然就提高了。也减少了磁盘头的来回移动。否则会多次读取硬盘页面导致访问的效率降低。 对于A和B、C、D,如果经常查询A和B中的数据,那么可以将他们放在同一个文件组M中;如果经常访问C和D中的数据可以将他们放在同一个文件组N中。这样读取效率就比较高,因为一次读取就可能包含了两个中的数据,因此提高了查询效率。要解决“磁盘数据组织不合理,导致磁盘的访问次数过多”这个问题,我们可以将经常读写的数据放置在不同的磁盘上,也就是将经常在一起被多连接查询的放在同一个文件组上。这里强调:这里反复提到的“不同的磁盘”指的的是不同的磁盘,而不是同一个硬盘的不同分区。 批量导入数据的候,要进行特殊设置 当用户需要大批量导入数据的候会突然增加很多日志记录,并且如果数据上有索引,数据每增加一条记录就会在索引上增加一条数据从而降低插入的性能。解决方案: 1、大批量导入数据的候设置数据库的恢复模式为“大容量日志恢复模式” 2、导入前禁用索引,导入完毕后重建索引。

20,808

社区成员

发帖
与我相关
我的任务
社区描述
Hadoop生态大数据交流社区,致力于有Hadoop,hive,Spark,Hbase,Flink,ClickHouse,Kafka,数据仓库,大数据集群运维技术分享和交流等。致力于收集优质的博客
社区管理员
  • 分布式计算/Hadoop社区
  • 涤生大数据
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧