项目owner看这里,MaxCompute全表扫描新功能,给你“失误”的机会

摘要: MaxCompute发布了“ALIAS 命令”,提供了在不修改代码的前提下,在MapReduce或自定义函数(UDF) 代码中,通过某个固定的资源名读取不同资源(数据)的需求。

随着社会数据收集手段的不断丰富及完善,越来越多的行业数据被积累下来。数据规模已经增长到了传统软件行业无法承载的海量数据,达到百GB、TB乃至PB级别。

在分析海量数据场景下,由于单台服务器的处理能力限制,数据分析者通常采用分布式计算模式。但分布式的计算模型对数据分析人员提出了较高的要求,且不易维护。使用分布式模型,数据分析人员不仅需要了解业务需求,同时还需要熟悉底层计算模型。

MaxCompute的目的是为用户提供一种便捷的分析处理海量数据的能力,owner可以不必关心分布式计算细节,便可达到分析大数据的目的,这样一是减轻项目负责人的工作负担,也同时降低了企业对海量数据处理的专业人才成本。

在使用过程中,我们发现用户经常遇到这样的问题,如果一不小心写错了sql,对全表做了扫描,不仅影响效率还会对成本造成损失,因为对全表数据扫描是费用比较高的。

现在,MaxCompute发布了“ALIAS 命令”,提供了在不修改代码的前提下,在MapReduce或自定义函数(UDF) 代码中,通过某个固定的资源名读取不同资源(数据)的需求。

其实通俗的来讲就是允许项目owner对项目进行设置,可以通过允许或不允许来保障这个项目不被做全表扫描,可以节约成本,避免了初次使用MaxCompute的用户或者误操作而对全表做了扫描影响效率和成本发生。如果确实需要对全表扫描,可以把属性这里改为true,完成用户需要的全表扫描的操作。

具体操作如下:
以开关的形式,通过设置允许或禁止全表扫描。true为允许,false为禁止 项目级别控制:setproject odps.sql.allow.fullscan=false/true Session级别控制:set odps.sql.allow.fullscan=false/true

总体来说该功能对于项目owner来说,不仅可以避免资源浪费、控制计算成本,还能灵活应开启全表扫描分区表。
具体操作详情请戳这里:
https://help.aliyun.com/document_detail/27834.html

原文链接

原文地址:http://blog.51cto.com/13679539/2133783

时间: 2024-11-13 08:20:19

项目owner看这里,MaxCompute全表扫描新功能,给你“失误”的机会的相关文章

SQL 数据优化索引建suo避免全表扫描

首先什么是全表扫描和索引扫描?全表扫描所有数据过一遍才能显示数据结果,索引扫描就是索引,只需要扫描一部分数据就可以得到结果.如果数据没建立索引. 无索引的情况下搜索数据的速度和占用内存就会比用索引的检索慢和高.下面是一个例子 1:无索引的情况 Product表,里面没有任何索引,如下图: 从上图中,我悲剧的看到了,物理读是9次,也就说明走了9次硬盘,你也可以想到,走硬盘的目的是为了拿数据,逻辑读有1636次,要注意的是这里 的”次“是“页”的意思,也就是在内存中走了1636个数据页,我用dbcc

Oracle 表的访问方式(1) ---全表扫描、通过ROWID访问表

1.Oracle访问表的方式 全表扫描.通过ROWID访问表.索引扫描 2.全表扫描(Full Table Scans, FTS) 为实现全表扫描,Oracle顺序地访问表中每条记录,并检查每一条记录是否满足WHERE语句的限制条件.ORACLE采用一次读入多个数据块(database block)的方式优化全表扫描,而不是只读取一个数据块,这极大的减少了I/O总次数,提高了系统的吞吐量,所以利用多块读的方法可以十分高效地实现全表扫描.需要注意的是只有在全表扫描的情况下才能使用多块读操作.在这种

避免全表扫描的sql优化

对查询进行优化,应尽量避免全表扫描,首先应考虑在where 及order by 涉及的列上建立索引:  .尝试下面的技巧以避免优化器错选了表扫描: ·   使用ANALYZE TABLE tbl_name为扫描的表更新关键字分布. ·   对扫描的表使用FORCE INDEX告知MySQL,相对于使用给定的索引表扫描将非常耗时.            SELECT * FROM t1, t2 FORCE INDEX (index_for_column)             WHERE t1.

如何导致全表扫描原因

转一位大神的笔记. 导致表的执行计划做全表扫描的原因: u       SQL谓词列没有建相应的索引 u       谓词列建有相应的索引,但执行计划没有使用 Oracle不使用b*tree索引的情况大致如下 1:where条件中和null比较可能导致不使用索引 2:count,sum,ave,max,min等聚集操作时可能导致不使用索引 3:显示或者隐式的函数转换导致不使用索引 4:在cbo模式下,统计信息过于陈旧导致不使用索引 5:组合索引中没有使用前导列导致没有使用索引 6:访问的数据量超

为什么全表扫描成本(COST)公式里面要除以sreadtim

全表扫描的成本计算公式 如下: Cost = ( #SRds * sreadtim + #MRds * mreadtim + CPUCycles / cpuspeed ) / sreadtim 全表扫描的时候,单块读次数=0,#SRds表示单块读次数.全表扫描的成本里面,CPU消耗其实非常少,可以忽略不计,所以全表扫描的公式可以改写为: Cost = #MRds * mreadtim / sreadtim #MRds 表示多块读io次数 mreadtim 表示一次多块读耗费时间 sreadtim

oracle全表扫描166G的表只花了6分钟

如何最大限制利用cpu?如何最快速的扫描完大表.如果大表有主键,count(*)就会走主键,oracle只需要扫描主键就能完成. 假设这个表没有主键,那么count(*)的时候只能走全表扫描,数据就非常慢.这里用full(a)强制走全表来模拟. --找100G以上的分区表 SQL> @getsegsize_big Enter value for tablespace_name: Enter value for owner: Enter value for how_big_m: 100000 OW

用合适的索引避免不必要的全表扫描

Oracle数据库里大部分SQL优化的问题都可以增加或减少索引的方式来解决,但这绝不是全部.当目标SQL语句所要查询的只是目标表中的一部分数据时,通过创建合适的索引就能够避免在没有索引的情况下为查询这一小部分数据而不得不采用全表扫描的操作,这样就降低了目标SQL语句的资源消耗,同时也会缩短了执行时间. 创建一张测试表及创建一个普通的单键值B树索引: SQL> create table t1 as select * from dba_objects; Table created. SQL> cr

如何优雅的使用 参数 is null而不导致全表扫描(破坏索引)

相信大家在很多实际业务中(特别是后台系统)会使用到各种筛选条件来筛选结果集 首先添加测试数据 CREATE TABLE TempList(Id int IDENTITY,Name VARCHAR(12), Age INT) go CREATE INDEX idx_age ON TempList (Age) GO DECLARE @i INT; SET @i=0; WHILE @i<10000 BEGIN INSERT INTO TempList (Name, Age)VALUES(CAST(@i

oracle在组合索引上,只使用部分列进行查询(查询时必须包含前导列,否则会走全表扫描)

实验环境:Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production 1.创建表插入数据 SQL> create table txtx(id int,name char(2),tx char(3),id1 int,primary key(id,name,tx)); 表已创建. SQL> insert into txtx values(1,'tx','tx',1); 已创建 1 行. SQL> i