Hive SQL的执行流程

1. Parser：将sql解析为AST（抽象语法树），会进行语法校验，AST本质还是字符串
2. Analyzer：语法解析，生成QB（query block）
3. Logicl Plan：逻辑执行计划解析，生成一堆Opertator Tree
4. Logical optimizer:进行逻辑执行计划优化，生成一堆优化后的Opertator Tree
5. Phsical plan：物理执行计划解析，生成tasktree
6. Phsical Optimizer：进行物理执行计划优化，生成优化后的tasktree，该任务即是集群上的执行的作业

结论：

1. .其实这个过成和WC是非常相似的，在各自的分片中，都是把数据分割以后每个值都对应一个1得到<key,1>，再经过本地reduce（combine过程）把key一样的value=1相加，得到新的<key，values>，再经过shuffle过程，把所有分片中的<key,values>,key一致的values相加，又得到最终的<key,values>。
2. combiner其实是一个本地的reduce主要就是为了减轻reduce的负担，但并不是所有的场景都会发生combiner，例如求平均数。

作者：qq_32641659 来源：CSDN 原文：https://blog.csdn.net/qq_32641659/article/details/89421655 版权声明：本文为博主原创文章，转载请附上博文链接！

官网：https://cwiki.apache.org/confluence/display/Hive/LanguageManual+Explain

Hive SQL的执行流程

标签：target   个数   parse   适合   相加   基本   之间   本质   ble   

小编还为您整理了以下内容，可能对您也有帮助：

大数据开发工程师Hive(Hive Sql的执行顺序)

Hive中SQL的执行顺序：

（1） from ：对from左边的表和右边的表计算笛卡尔积，产生虚表VT1；

（2） on : 对虚表VT1进行on过滤，只有那些符合 的行才会被记录在虚表VT2中；

（3） join ：如果指定了outer join（比如left join、 right join），那么保留表中未匹配的行就会作为外部行添加到虚拟表VT2中，产生虚拟表VT3；

（4） where ：对虚拟表VT3进行where条件过滤。只有符合 的记录才会被插入到虚拟表VT4中；

（5） group by ：根据group by子句中的列，对VT4中的记录进行分组操作，产生VT5；

（6） having ： 对虚拟表VT5应用having过滤，只有符合 的记录才会被 插入到虚拟表VT6中；

（7） select ：执行select操作，选择指定的列，插入到虚拟表VT7中；

（8） distinct ：对VT7中的记录进行去重。产生虚拟表VT8；

（9） order ：将虚拟表VT8中的记录按照 进行排序操作，产生虚拟表VT9；

（10） limit ：取出指定行的记录，产生虚拟表VT10, 并将结果返回；

partition by 通常会用于和开窗及分析函数一起使用，partition by是在select执行完 后 的结果集上进行的；

Hive SQL语句执行顺序

Hive 中 sql 语句的执行顺序如下：

from .. where .. join .. on .. select .. group by .. select .. having .. distinct .. order by .. limit .. union/union all

下面我们通过一个 sql 语句分析下：

上面这条 sql 语句是可以成功执行的，我们看下它在 MR 中的执行顺序：

Map 阶段：

Rece 阶段：

上面这个执行顺序到底对不对呢，我们可以通过 explain 执行计划来看下，内容过多，我们分阶段来看。

我们看到 Stage-5 是根，也就是最先执行 Stage-5，Stage-2 依赖 Stage-5，Stage-0 依赖 Stage-2。

图中标 ① 处是表扫描操作，注意先扫描的 b 表，也就是 left join 后面的表，然后进行过滤操作（图中标 ② 处），我们 sql 语句中是对 a 表进行的过滤，但是 Hive 也会自动对 b 表进行相同的过滤操作，这样可以减少关联的数据量。

先扫描 a 表（图中标 ① 处）；接下来进行过滤操作 idno > '112233'（图中标 ② 处）；然后进行 left join，关联的 key 是 idno（图中标 ③ 处）；执行完关联操作之后会进行输出操作，输出的是三个字段，包括 select 的两个字段加 group by 的一个字段（图中标 ④ 处）；然后进行 group by 操作，分组方式是 hash（图中标 ⑤ 处）；然后进行排序操作，按照 idno 进行正向排序（图中标 ⑥ 处）。

首先进行 group by 操作，注意此时的分组方式是 mergepartial 合并分组（图中标 ① 处）；然后进行 select 操作，此时输出的字段只有两个了，输出的行数是 30304 行（图中标 ② 处）；接下来执行 having 的过滤操作，过滤出 count_user>1 的字段，输出的行数是 10101 行（图中标 ③ 处）；然后进行 limit *输出的行数（图中标 ④ 处）；图中标 ⑤ 处表示是否对文件压缩，false 不压缩。

*最终输出的行数为 10 行。

通过上面对 SQL 执行计划的分析，总结以下几点：

Hive SQL语句执行顺序

Hive 中 sql 语句的执行顺序如下：

from .. where .. join .. on .. select .. group by .. select .. having .. distinct .. order by .. limit .. union/union all

下面我们通过一个 sql 语句分析下：

上面这条 sql 语句是可以成功执行的，我们看下它在 MR 中的执行顺序：

Map 阶段：

Rece 阶段：

上面这个执行顺序到底对不对呢，我们可以通过 explain 执行计划来看下，内容过多，我们分阶段来看。

我们看到 Stage-5 是根，也就是最先执行 Stage-5，Stage-2 依赖 Stage-5，Stage-0 依赖 Stage-2。

图中标 ① 处是表扫描操作，注意先扫描的 b 表，也就是 left join 后面的表，然后进行过滤操作（图中标 ② 处），我们 sql 语句中是对 a 表进行的过滤，但是 Hive 也会自动对 b 表进行相同的过滤操作，这样可以减少关联的数据量。

先扫描 a 表（图中标 ① 处）；接下来进行过滤操作 idno > '112233'（图中标 ② 处）；然后进行 left join，关联的 key 是 idno（图中标 ③ 处）；执行完关联操作之后会进行输出操作，输出的是三个字段，包括 select 的两个字段加 group by 的一个字段（图中标 ④ 处）；然后进行 group by 操作，分组方式是 hash（图中标 ⑤ 处）；然后进行排序操作，按照 idno 进行正向排序（图中标 ⑥ 处）。

首先进行 group by 操作，注意此时的分组方式是 mergepartial 合并分组（图中标 ① 处）；然后进行 select 操作，此时输出的字段只有两个了，输出的行数是 30304 行（图中标 ② 处）；接下来执行 having 的过滤操作，过滤出 count_user>1 的字段，输出的行数是 10101 行（图中标 ③ 处）；然后进行 limit *输出的行数（图中标 ④ 处）；图中标 ⑤ 处表示是否对文件压缩，false 不压缩。

*最终输出的行数为 10 行。

通过上面对 SQL 执行计划的分析，总结以下几点：

SQL语句执行流程与顺序原理解析

SQL语句执行流程与顺序原理解析
Oracle语句执行流程
第一步：客户端把语句发给服务器端执行
当我们在客户端执行SQL语句时，客户端会把这条SQL语句发送给服务器端，让服务器端的进程来处理这语句。也就是说，Oracle 客户端是不会做任何的操作，他的主要任务就是把客户端产生的一些SQL语句发送给服务器端。服务器进程从用户进程把信息接收到后， 在PGA 中就要此进程分配所需内存，存储相关的信息，如：在会话内存存储相关的登录信息等。
虽然在客户端也有一个数据库进程，但是，这个进程的作用跟服务器上的进程作用是不相同的，服务器上的数据库进程才会对SQL 语句进行相关的处理。不过，有个问题需要说明，就是客户端的进程跟服务器的进程是一一对应的。也就是说，在客户端连接上服务器后，在客户端与服务器端都会形成一个进程，客户端上的我们叫做客户端进程，而服务器上的我们叫做服务器进程。
第二步：语句解析
当客户端把SQL语句传送到服务器后，服务器进程会对该语句进行解析。这个解析的工作是在服务器端所进行的，解析动作又可分为很多小动作。
1）查询高速缓存（library cache）
服务器进程在接到客户端传送过来的SQL语句时，不会直接去数据库查询。服务器进程把这个SQL语句的字符转化为ASCII等效数字码，接着这个ASCII码被传递给一个HASH函数，并返回一个hash值，然后服务器进程将到shared pool中的library cache（高速缓存）中去查找是否存在相同的hash值。如果存在，服务器进程将使用这条语句已高速缓存在SHARED POOL的library cache中的已分析过的版本来执行，省去后续的解析工作，这便是软解析。若调整缓存中不存在，则需要进行后面的步骤，这便是硬解析。硬解析通常是昂贵的操作，大约占整个SQL执行的70%左右的时间，硬解析会生成执行树，执行计划，等等。
所以，采用高速数据缓存的话，可以提高SQL 语句的查询效率。其原因有两方面：一方面是从内存中读取数据要比从硬盘中的数据文件中读取数据效率要高，另一方面也是因为避免语句解析而节省了时间。
不过这里要注意一点，这个数据缓存跟有些客户端软件的数据缓存是两码事。有些客户端软件为了提高查询效率，会在应用软件的客户端设置数据缓存。由于这些数据缓存的存在，可以提高客户端应用软件的查询效率。但是，若其他人在服务器进行了相关的修改，由于应用软件数据缓存的存在，导致修改的数据不能及时反映到客户端上。从这也可以看出，应用软件的数据缓存跟数据库服务器的高速数据缓存不是一码事。
2）语句合法性检查（data dict cache）
当在高速缓存中找不到对应的SQL语句时，则服务器进程就会开始检查这条语句的合法性。这里主要是对SQL语句的语法进行检查，看看其是否合乎语法规则。如果服务器进程认为这条SQL语句不符合语法规则的时候，就会把这个错误信息反馈给客户端。在这个语法检查的过程中，不会对SQL语句中所包含的表名、列名等等进行检查，只是检查语法。
3）语言含义检查（data dict cache）
若SQL 语句符合语法上的定义的话，则服务器进程接下去会对语句中涉及的表、索引、视图等对象进行解析，并对照数据字典检查这些对象的名称以及相关结构，看看这些字段、表、视图等是否在数据库中。如果表名与列名不准确的话，则数据库会就会反馈错误信息给客户端。
所以，有时候我们写select语句的时候，若语法与表名或者列名同时写错的话，则系统是先提示说语法错误，等到语法完全正确后再提示说列名或表名错误。
4）获得对象解析锁（control structer）
当语法、语义都正确后，系统就会对我们需要查询的对象加锁。这主要是为了保障数据的一致性，防止我们在查询的过程中，其他用户对这个对象的结构发生改变。
5）数据访问权限的核对（data dict cache）
当语法、语义通过检查之后，客户端还不一定能够取得数据，服务器进程还会检查连接用户是否有这个数据访问的权限。若用户不具有数据访问权限的话，则客户端就不能够取得这些数据。要注意的是数据库服务器进程先检查语法与语义，然后才会检查访问权限。
6）确定最佳执行计划
当语法与语义都没有问题权限也匹配，服务器进程还是不会直接对数据库文件进行查询。服务器进程会根据一定的规则，对这条语句进行优化。在执行计划开发之前会有一步查询转换，如：视图合并、子查询解嵌套、谓语前推及物化视图重写查询等。为了确定采用哪个执行计划，Oracle还需要收集统计信息确定表的访问联结方法等，最终确定可能的最低成本的执行计划。
不过要注意，这个优化是有限的。一般在应用软件开发的过程中，需要对数据库的sql语句进行优化，这个优化的作用要大大地大于服务器进程的自我优化。
当服务器进程的优化器确定这条查询语句的最佳执行计划后， 就会将这条SQL语句与执行计划保存到数据高速缓存（library cache）。如此，等以后还有这个查询时，就会省略以上的语法、语义与权限检查的步骤，而直接执行SQL语句，提高SQL语句处理效率。
第三步：绑定变量赋值
如果SQL语句中使用了绑定变量，扫描绑定变量的声明，给绑定变量赋值，将变量值带入执行计划。若在解析的第一个步骤，SQL在高速缓冲中存在，则直接跳到该步骤。
第四步：语句执行
语句解析只是对SQL语句的语法进行解析，以确保服务器能够知道这条语句到底表达的是什么意思。等到语句解析完成之后，数据库服务器进程才会真正的执行这条SQL语句。
对于SELECT语句：
1）首先服务器进程要判断所需数据是否在db buffer存在，如果存在且可用，则直接获取该数据而不是从数据库文件中去查询数据，同时根据LRU 算法增加其访问计数；
2）若数据不在缓冲区中，则服务器进程将从数据库文件中查询相关数据，并把这些数据放入到数据缓冲区中（buffer cache）。
其中，若数据存在于db buffer，其可用性检查方式为：查看db buffer块的头部是否有事务，如果有事务，则从回滚段中读取数据；如果没有事务，则比较select的scn和db buffer块头部的scn，如果前者小于后者，仍然要从回滚段中读取数据；如果前者大于后者，说明这是一非脏缓存，可以直接读取这个db buffer块的中内容。
对于DML语句（insert、delete、update）：
1）检查所需的数据库是否已经被读取到缓冲区缓存中。如果已经存在缓冲区缓存，则直接执行步骤3；
2）若所需的数据库并不在缓冲区缓存中，则服务器将数据块从数据文件读取到缓冲区缓存中；
3）对想要修改的表取得的数据行锁定（Row Exclusive Lock），之后对所需要修改的数据行取得独占锁；
4）将数据的Redo记录复制到redo log buffer；
5）产生数据修改的undo数据；
6）修改db buffer；
7）dbwr将修改写入数据文件；
其中，第2步，服务器将数据从数据文件读取到db buffer经经历以下步骤：
1）首先服务器进程将在表头部请求TM锁（保证此事务执行过程其他用户不能修改表的结构），如果成功加TM锁，再请求一些行级锁（TX锁），如果TM、TX锁都成功加锁，那么才开始从数据文件读数据。
2）在读数据之前，要先为读取的文件准备好buffer空间。服务器进程需要扫描LRU list寻找free db buffer，扫描的过程中，服务器进程会把发现的所有已经被修改过的db buffer注册到dirty list中。如果free db buffer及非脏数据块缓冲区不足时，会触发dbwr将dirty buffer中指向的缓冲块写入数据文件，并且清洗掉这些缓冲区来腾出空间缓冲新读入的数据。
3）找到了足够的空闲buffer，服务器进程将从数据文件中读入这些行所在的每一个数据块（db block）（DB BLOCK是ORACLE的最小操作单元，即使你想要的数据只是DB BLOCK中很多行中的一行或几行，ORACLE也会把这个DB BLOCK中的所有行都读入Oracle DB BUFFER中）放入db buffer的空闲的区域或者覆盖已被挤出LRU list的非脏数据块缓冲区，并且排列在LRU列表的头部，也就是在数据块放入db buffer之前也是要先申请db buffer中的锁存器，成功加锁后，才能读数据到db buffer。
若数据块已经存在于db buffer cache（有时也称db buffer或db cache），即使在db buffer中找到一个没有事务，而且SCN比自己小的非脏缓存数据块，服务器进程仍然要到表的头部对这条记录申请加锁，加锁成功才能进行后续动作，如果不成功，则要等待前面的进程解锁后才能进行动作（这个时候阻塞是tx锁阻塞）。
在记redo日志时，其具体步骤如下：
1）数据被读入到db buffer后，服务器进程将该语句所影响的并被读入db buffer中的这些行数据的rowid及要更新的原值和新值及scn等信息从PGA逐条的写入redo log buffer中。在写入redo log buffer之前也要事先请求redo log buffer的锁存器，成功加锁后才开始写入。
2）当写入达到redo log buffer大小的三分之一或写入量达到1M或超过三秒后或发生检查点时或者dbwr之前发生，都会触发lgwr进程把redo log buffer的数据写入磁盘上的redo file文件中（这个时候会产生log file sync等待事件）。
3）已经被写入redo file的redo log buffer所持有的锁存器会被释放，并可被后来的写入信息覆盖，redo log buffer是循环使用的。Redo file也是循环使用的，当一个redo file写满后，lgwr进程会自动切换到下一redo file（这个时候可能出现log file switch（check point complete）等待事件）。如果是归档模式，归档进程还要将前一个写满的redo file文件的内容写到归档日志文件中（这个时候可能出现log file switch（archiving needed）。
在为事务建立undo信息时，其具体步骤如下：
1）在完成本事务所有相关的redo log buffer之后，服务器进程开始改写这个db buffer的块头部事务列表并写入scn（一开始scn是写在redo log buffer中的，并未写在db buffer）。
2）然后copy包含这个块的头部事务列表及scn信息的数据副本放入回滚段中，将这时回滚段中的信息称为数据块的“前映像”，这个“前映像”用于以后的回滚、恢复和一致性读。（回滚段可以存储在专门的回滚表空间中，这个表空间由一个或多个物理文件组成，并专用于回滚表空间，回滚段也可在其它表空间中的数据文件中开辟）。
在修改信息写入数据文件时，其具体步骤如下：
1）改写db buffer块的数据内容，并在块的头部写入回滚段的地址。
2）将db buffer指针放入dirty list。如果一个行数据多次update而未commit，则在回滚段中将会有多个“前映像”，除了第一个“前映像”含有scn信息外，其他每个"前映像"的头部都有scn信息和"前前映像"回滚段地址。一个update只对应一个scn，然后服务器进程将在dirty list中建立一条指向此db buffer块的指针（方便dbwr进程可以找到dirty list的db buffer数据块并写入数据文件中）。接着服务器进程会从数据文件中继续读入第二个数据块，重复前一数据块的动作，数据块的读入、记日志、建立回滚段、修改数据块、放入dirty list。
3）当dirty queue的长度达到阀值（一般是25%），服务器进程将通知dbwr把脏数据写出，就是释放db buffer上的锁存器，腾出更多的free db buffer。前面一直都是在说明oracle一次读一个数据块，其实oracle可以一次读入多个数据块（db_file_multiblock_read_count来设置一次读入块的个数）
当执行commit时，具体步骤如下：
1）commit触发lgwr进程，但不强制dbwr立即释放所有相应db buffer块的锁。也就是说有可能虽然已经commit了，但在随后的一段时间内dbwr还在写这条sql语句所涉及的数据块。表头部的行锁并不在commit之后立即释放，而是要等dbwr进程完成之后才释放，这就可能会出现一个用户请求另一用户已经commit的资源不成功的现象。
2）从Commit和dbwr进程结束之间的时间很短，如果恰巧在commit之后，dbwr未结束之前断电，因为commit之后的数据已经属于数据文件的内容，但这部分文件没有完全写入到数据文件中。所以需要前滚。由于commit已经触发lgwr，这些所有未来得及写入数据文件的更改会在实例重启后，由smon进程根据重做日志文件来前滚，完成之前commit未完成的工作（即把更改写入数据文件）。
3）如果未commit就断电了，因为数据已经在db buffer更改了，没有commit，说明这部分数据不属于数据文件。由于dbwr之前触发lgwr也就是只要数据更改，（肯定要先有log）所有dbwr在数据文件上的修改都会被先一步记入重做日志文件，实例重启后，SMON进程再根据重做日志文件来回滚。
其实smon的前滚回滚是根据检查点来完成的，当一个全部检查点发生的时候，首先让LGWR进程将redologbuffer中的所有缓冲（包含未提交的重做信息）写入重做日志文件，然后让dbwr进程将dbbuffer已提交的缓冲写入数据文件（不强制写未提交的）。然后更新控制文件和数据文件头部的SCN，表明当前数据库是一致的，在相邻的两个检查点之间有很多事务，有提交和未提交的。
当执行rollback时，具体步骤如下：
服务器进程会根据数据文件块和db buffer中块的头部的事务列表和SCN以及回滚段地址找到回滚段中相应的修改前的副本，并且用这些原值来还原当前数据文件中已修改但未提交的改变。如果有多个”前映像“，服务器进程会在一个“前映像”的头部找到“前前映像”的回滚段地址，一直找到同一事务下的最早的一个“前映像”为止。一旦发出了commit，用户就不能rollback，这使得commit后dbwr进程还没有全部完成的后续动作得到了保障。
第五步：提取数据
当语句执行完成之后，查询到的数据还是在服务器进程中，还没有被传送到客户端的用户进程。所以，在服务器端的进程中，有一个专门负责数据提取的一段代码。他的作用就是把查询到的数据结果返回给用户端进程，从而完成整个查询动作。
从这整个查询处理过程中，我们在数据库开发或者应用软件开发过程中，需要注意以下几点：
　　一是要了解数据库缓存跟应用软件缓存是两码事情。数据库缓存只有在数据库服务器端才存在，在客户端是不存在的。只有如此，才能够保证数据库缓存中的内容跟数据库文件的内容一致。才能够根据相关的规则，防止数据脏读、错读的发生。而应用软件所涉及的数据缓存，由于跟数据库缓存不是一码事情，所以，应用软件的数据缓存虽然可以提高数据的查询效率，但是，却打破了数据一致性的要求，有时候会发生脏读、错读等情况的发生。所以，有时候，在应用软件上有专门一个功能，用来在必要的时候清除数据缓存。不过，这个数据缓存的清除，也只是清除本机上的数据缓存，或者说，只是清除这个应用程序的数据缓存，而不会清除数据库的数据缓存。
　　二是绝大部分SQL语句都是按照这个处理过程处理的。我们DBA或者基于Oracle数据库的开发人员了解这些语句的处理过程，对于我们进行涉及到SQL语句的开发与调试，是非常有帮助的。有时候，掌握这些处理原则，可以减少我们排错的时间。特别要注意，数据库是把数据查询权限的审查放在语法语义的后面进行检查的。所以，有时会若光用数据库的权限控制原则，可能还不能满足应用软件权限控制的需要。此时，就需要应用软件的前台设置，实现权限管理的要求。而且，有时应用数据库的权限管理，也有点显得繁琐，会增加服务器处理的工作量。因此，对于记录、字段等的查询权限控制，大部分程序涉及人员喜欢在应用程序中实现，而不是在数据库上实现。
Oracle SQL语句执行顺序
(8)SELECT (9) DISTINCT (11) <select_list>
(1) FROM <left_table>
(3) <join_type> JOIN <right_table>
(2) ON <join_condition>
(4) WHERE <where_condition>
(5) GROUP BY <group_by_list>
(6) WITH {CUBE | ROLLUP}
(7) HAVING <having_condition>
(10) ORDER BY <order_by_list>
1）FROM：对FROM子句中的表执行笛卡尔积(交叉联接)，生成虚拟表VT1。
2）ON：对VT1应用ON筛选器，只有那些使为真才被插入到TV2。
3）OUTER (JOIN):如果指定了OUTER JOIN(相对于CROSS JOIN或INNER JOIN)，保留表中未找到匹配的行将作为外部行添加到VT2，生成TV3。如果FROM子句包含两个以上的表，则对上一个联接生成的结果表和下一个表重复执行步骤1到步骤3，直到处理完所有的表位置。
4）WHERE：对TV3应用WHERE筛选器，只有使为true的行才插入TV4。
5）GROUP BY：按GROUP BY子句中的列列表对TV4中的行进行分组，生成TV5。
6）CUTE|ROLLUP：把超组插入VT5，生成VT6。
7）HAVING：对VT6应用HAVING筛选器，只有使为true的组插入到VT7。
8）SELECT：处理SELECT列表，产生VT8。
9）DISTINCT：将重复的行从VT8中删除，产品VT9。
10）ORDER BY：将VT9中的行按ORDER BY子句中的列列表顺序，生成一个游标(VC10)，生成表TV11，并返回给调用者。
以上每个步骤都会产生一个虚拟表，该虚拟表被用作下一个步骤的输入。这些虚拟表对调用者(客户端应用程序或者外部查询)不可用。只有最后一步生成的表才会会给调用者。如果没有在查询中指定某一个子句，将跳过相应的步骤。

SQL语句执行流程与顺序原理解析

SQL语句执行流程与顺序原理解析
Oracle语句执行流程
第一步：客户端把语句发给服务器端执行
当我们在客户端执行SQL语句时，客户端会把这条SQL语句发送给服务器端，让服务器端的进程来处理这语句。也就是说，Oracle 客户端是不会做任何的操作，他的主要任务就是把客户端产生的一些SQL语句发送给服务器端。服务器进程从用户进程把信息接收到后， 在PGA 中就要此进程分配所需内存，存储相关的信息，如：在会话内存存储相关的登录信息等。
虽然在客户端也有一个数据库进程，但是，这个进程的作用跟服务器上的进程作用是不相同的，服务器上的数据库进程才会对SQL 语句进行相关的处理。不过，有个问题需要说明，就是客户端的进程跟服务器的进程是一一对应的。也就是说，在客户端连接上服务器后，在客户端与服务器端都会形成一个进程，客户端上的我们叫做客户端进程，而服务器上的我们叫做服务器进程。
第二步：语句解析
当客户端把SQL语句传送到服务器后，服务器进程会对该语句进行解析。这个解析的工作是在服务器端所进行的，解析动作又可分为很多小动作。
1）查询高速缓存（library cache）
服务器进程在接到客户端传送过来的SQL语句时，不会直接去数据库查询。服务器进程把这个SQL语句的字符转化为ASCII等效数字码，接着这个ASCII码被传递给一个HASH函数，并返回一个hash值，然后服务器进程将到shared pool中的library cache（高速缓存）中去查找是否存在相同的hash值。如果存在，服务器进程将使用这条语句已高速缓存在SHARED POOL的library cache中的已分析过的版本来执行，省去后续的解析工作，这便是软解析。若调整缓存中不存在，则需要进行后面的步骤，这便是硬解析。硬解析通常是昂贵的操作，大约占整个SQL执行的70%左右的时间，硬解析会生成执行树，执行计划，等等。
所以，采用高速数据缓存的话，可以提高SQL 语句的查询效率。其原因有两方面：一方面是从内存中读取数据要比从硬盘中的数据文件中读取数据效率要高，另一方面也是因为避免语句解析而节省了时间。
不过这里要注意一点，这个数据缓存跟有些客户端软件的数据缓存是两码事。有些客户端软件为了提高查询效率，会在应用软件的客户端设置数据缓存。由于这些数据缓存的存在，可以提高客户端应用软件的查询效率。但是，若其他人在服务器进行了相关的修改，由于应用软件数据缓存的存在，导致修改的数据不能及时反映到客户端上。从这也可以看出，应用软件的数据缓存跟数据库服务器的高速数据缓存不是一码事。
2）语句合法性检查（data dict cache）
当在高速缓存中找不到对应的SQL语句时，则服务器进程就会开始检查这条语句的合法性。这里主要是对SQL语句的语法进行检查，看看其是否合乎语法规则。如果服务器进程认为这条SQL语句不符合语法规则的时候，就会把这个错误信息反馈给客户端。在这个语法检查的过程中，不会对SQL语句中所包含的表名、列名等等进行检查，只是检查语法。
3）语言含义检查（data dict cache）
若SQL 语句符合语法上的定义的话，则服务器进程接下去会对语句中涉及的表、索引、视图等对象进行解析，并对照数据字典检查这些对象的名称以及相关结构，看看这些字段、表、视图等是否在数据库中。如果表名与列名不准确的话，则数据库会就会反馈错误信息给客户端。
所以，有时候我们写select语句的时候，若语法与表名或者列名同时写错的话，则系统是先提示说语法错误，等到语法完全正确后再提示说列名或表名错误。
4）获得对象解析锁（control structer）
当语法、语义都正确后，系统就会对我们需要查询的对象加锁。这主要是为了保障数据的一致性，防止我们在查询的过程中，其他用户对这个对象的结构发生改变。
5）数据访问权限的核对（data dict cache）
当语法、语义通过检查之后，客户端还不一定能够取得数据，服务器进程还会检查连接用户是否有这个数据访问的权限。若用户不具有数据访问权限的话，则客户端就不能够取得这些数据。要注意的是数据库服务器进程先检查语法与语义，然后才会检查访问权限。
6）确定最佳执行计划
当语法与语义都没有问题权限也匹配，服务器进程还是不会直接对数据库文件进行查询。服务器进程会根据一定的规则，对这条语句进行优化。在执行计划开发之前会有一步查询转换，如：视图合并、子查询解嵌套、谓语前推及物化视图重写查询等。为了确定采用哪个执行计划，Oracle还需要收集统计信息确定表的访问联结方法等，最终确定可能的最低成本的执行计划。
不过要注意，这个优化是有限的。一般在应用软件开发的过程中，需要对数据库的sql语句进行优化，这个优化的作用要大大地大于服务器进程的自我优化。
当服务器进程的优化器确定这条查询语句的最佳执行计划后， 就会将这条SQL语句与执行计划保存到数据高速缓存（library cache）。如此，等以后还有这个查询时，就会省略以上的语法、语义与权限检查的步骤，而直接执行SQL语句，提高SQL语句处理效率。
第三步：绑定变量赋值
如果SQL语句中使用了绑定变量，扫描绑定变量的声明，给绑定变量赋值，将变量值带入执行计划。若在解析的第一个步骤，SQL在高速缓冲中存在，则直接跳到该步骤。
第四步：语句执行
语句解析只是对SQL语句的语法进行解析，以确保服务器能够知道这条语句到底表达的是什么意思。等到语句解析完成之后，数据库服务器进程才会真正的执行这条SQL语句。
对于SELECT语句：
1）首先服务器进程要判断所需数据是否在db buffer存在，如果存在且可用，则直接获取该数据而不是从数据库文件中去查询数据，同时根据LRU 算法增加其访问计数；
2）若数据不在缓冲区中，则服务器进程将从数据库文件中查询相关数据，并把这些数据放入到数据缓冲区中（buffer cache）。
其中，若数据存在于db buffer，其可用性检查方式为：查看db buffer块的头部是否有事务，如果有事务，则从回滚段中读取数据；如果没有事务，则比较select的scn和db buffer块头部的scn，如果前者小于后者，仍然要从回滚段中读取数据；如果前者大于后者，说明这是一非脏缓存，可以直接读取这个db buffer块的中内容。
对于DML语句（insert、delete、update）：
1）检查所需的数据库是否已经被读取到缓冲区缓存中。如果已经存在缓冲区缓存，则直接执行步骤3；
2）若所需的数据库并不在缓冲区缓存中，则服务器将数据块从数据文件读取到缓冲区缓存中；
3）对想要修改的表取得的数据行锁定（Row Exclusive Lock），之后对所需要修改的数据行取得独占锁；
4）将数据的Redo记录复制到redo log buffer；
5）产生数据修改的undo数据；
6）修改db buffer；
7）dbwr将修改写入数据文件；
其中，第2步，服务器将数据从数据文件读取到db buffer经经历以下步骤：
1）首先服务器进程将在表头部请求TM锁（保证此事务执行过程其他用户不能修改表的结构），如果成功加TM锁，再请求一些行级锁（TX锁），如果TM、TX锁都成功加锁，那么才开始从数据文件读数据。
2）在读数据之前，要先为读取的文件准备好buffer空间。服务器进程需要扫描LRU list寻找free db buffer，扫描的过程中，服务器进程会把发现的所有已经被修改过的db buffer注册到dirty list中。如果free db buffer及非脏数据块缓冲区不足时，会触发dbwr将dirty buffer中指向的缓冲块写入数据文件，并且清洗掉这些缓冲区来腾出空间缓冲新读入的数据。
3）找到了足够的空闲buffer，服务器进程将从数据文件中读入这些行所在的每一个数据块（db block）（DB BLOCK是ORACLE的最小操作单元，即使你想要的数据只是DB BLOCK中很多行中的一行或几行，ORACLE也会把这个DB BLOCK中的所有行都读入Oracle DB BUFFER中）放入db buffer的空闲的区域或者覆盖已被挤出LRU list的非脏数据块缓冲区，并且排列在LRU列表的头部，也就是在数据块放入db buffer之前也是要先申请db buffer中的锁存器，成功加锁后，才能读数据到db buffer。
若数据块已经存在于db buffer cache（有时也称db buffer或db cache），即使在db buffer中找到一个没有事务，而且SCN比自己小的非脏缓存数据块，服务器进程仍然要到表的头部对这条记录申请加锁，加锁成功才能进行后续动作，如果不成功，则要等待前面的进程解锁后才能进行动作（这个时候阻塞是tx锁阻塞）。
在记redo日志时，其具体步骤如下：
1）数据被读入到db buffer后，服务器进程将该语句所影响的并被读入db buffer中的这些行数据的rowid及要更新的原值和新值及scn等信息从PGA逐条的写入redo log buffer中。在写入redo log buffer之前也要事先请求redo log buffer的锁存器，成功加锁后才开始写入。
2）当写入达到redo log buffer大小的三分之一或写入量达到1M或超过三秒后或发生检查点时或者dbwr之前发生，都会触发lgwr进程把redo log buffer的数据写入磁盘上的redo file文件中（这个时候会产生log file sync等待事件）。
3）已经被写入redo file的redo log buffer所持有的锁存器会被释放，并可被后来的写入信息覆盖，redo log buffer是循环使用的。Redo file也是循环使用的，当一个redo file写满后，lgwr进程会自动切换到下一redo file（这个时候可能出现log file switch（check point complete）等待事件）。如果是归档模式，归档进程还要将前一个写满的redo file文件的内容写到归档日志文件中（这个时候可能出现log file switch（archiving needed）。
在为事务建立undo信息时，其具体步骤如下：
1）在完成本事务所有相关的redo log buffer之后，服务器进程开始改写这个db buffer的块头部事务列表并写入scn（一开始scn是写在redo log buffer中的，并未写在db buffer）。
2）然后copy包含这个块的头部事务列表及scn信息的数据副本放入回滚段中，将这时回滚段中的信息称为数据块的“前映像”，这个“前映像”用于以后的回滚、恢复和一致性读。（回滚段可以存储在专门的回滚表空间中，这个表空间由一个或多个物理文件组成，并专用于回滚表空间，回滚段也可在其它表空间中的数据文件中开辟）。
在修改信息写入数据文件时，其具体步骤如下：
1）改写db buffer块的数据内容，并在块的头部写入回滚段的地址。
2）将db buffer指针放入dirty list。如果一个行数据多次update而未commit，则在回滚段中将会有多个“前映像”，除了第一个“前映像”含有scn信息外，其他每个"前映像"的头部都有scn信息和"前前映像"回滚段地址。一个update只对应一个scn，然后服务器进程将在dirty list中建立一条指向此db buffer块的指针（方便dbwr进程可以找到dirty list的db buffer数据块并写入数据文件中）。接着服务器进程会从数据文件中继续读入第二个数据块，重复前一数据块的动作，数据块的读入、记日志、建立回滚段、修改数据块、放入dirty list。
3）当dirty queue的长度达到阀值（一般是25%），服务器进程将通知dbwr把脏数据写出，就是释放db buffer上的锁存器，腾出更多的free db buffer。前面一直都是在说明oracle一次读一个数据块，其实oracle可以一次读入多个数据块（db_file_multiblock_read_count来设置一次读入块的个数）
当执行commit时，具体步骤如下：
1）commit触发lgwr进程，但不强制dbwr立即释放所有相应db buffer块的锁。也就是说有可能虽然已经commit了，但在随后的一段时间内dbwr还在写这条sql语句所涉及的数据块。表头部的行锁并不在commit之后立即释放，而是要等dbwr进程完成之后才释放，这就可能会出现一个用户请求另一用户已经commit的资源不成功的现象。
2）从Commit和dbwr进程结束之间的时间很短，如果恰巧在commit之后，dbwr未结束之前断电，因为commit之后的数据已经属于数据文件的内容，但这部分文件没有完全写入到数据文件中。所以需要前滚。由于commit已经触发lgwr，这些所有未来得及写入数据文件的更改会在实例重启后，由smon进程根据重做日志文件来前滚，完成之前commit未完成的工作（即把更改写入数据文件）。
3）如果未commit就断电了，因为数据已经在db buffer更改了，没有commit，说明这部分数据不属于数据文件。由于dbwr之前触发lgwr也就是只要数据更改，（肯定要先有log）所有dbwr在数据文件上的修改都会被先一步记入重做日志文件，实例重启后，SMON进程再根据重做日志文件来回滚。
其实smon的前滚回滚是根据检查点来完成的，当一个全部检查点发生的时候，首先让LGWR进程将redologbuffer中的所有缓冲（包含未提交的重做信息）写入重做日志文件，然后让dbwr进程将dbbuffer已提交的缓冲写入数据文件（不强制写未提交的）。然后更新控制文件和数据文件头部的SCN，表明当前数据库是一致的，在相邻的两个检查点之间有很多事务，有提交和未提交的。
当执行rollback时，具体步骤如下：
服务器进程会根据数据文件块和db buffer中块的头部的事务列表和SCN以及回滚段地址找到回滚段中相应的修改前的副本，并且用这些原值来还原当前数据文件中已修改但未提交的改变。如果有多个”前映像“，服务器进程会在一个“前映像”的头部找到“前前映像”的回滚段地址，一直找到同一事务下的最早的一个“前映像”为止。一旦发出了commit，用户就不能rollback，这使得commit后dbwr进程还没有全部完成的后续动作得到了保障。
第五步：提取数据
当语句执行完成之后，查询到的数据还是在服务器进程中，还没有被传送到客户端的用户进程。所以，在服务器端的进程中，有一个专门负责数据提取的一段代码。他的作用就是把查询到的数据结果返回给用户端进程，从而完成整个查询动作。
从这整个查询处理过程中，我们在数据库开发或者应用软件开发过程中，需要注意以下几点：
　　一是要了解数据库缓存跟应用软件缓存是两码事情。数据库缓存只有在数据库服务器端才存在，在客户端是不存在的。只有如此，才能够保证数据库缓存中的内容跟数据库文件的内容一致。才能够根据相关的规则，防止数据脏读、错读的发生。而应用软件所涉及的数据缓存，由于跟数据库缓存不是一码事情，所以，应用软件的数据缓存虽然可以提高数据的查询效率，但是，却打破了数据一致性的要求，有时候会发生脏读、错读等情况的发生。所以，有时候，在应用软件上有专门一个功能，用来在必要的时候清除数据缓存。不过，这个数据缓存的清除，也只是清除本机上的数据缓存，或者说，只是清除这个应用程序的数据缓存，而不会清除数据库的数据缓存。
　　二是绝大部分SQL语句都是按照这个处理过程处理的。我们DBA或者基于Oracle数据库的开发人员了解这些语句的处理过程，对于我们进行涉及到SQL语句的开发与调试，是非常有帮助的。有时候，掌握这些处理原则，可以减少我们排错的时间。特别要注意，数据库是把数据查询权限的审查放在语法语义的后面进行检查的。所以，有时会若光用数据库的权限控制原则，可能还不能满足应用软件权限控制的需要。此时，就需要应用软件的前台设置，实现权限管理的要求。而且，有时应用数据库的权限管理，也有点显得繁琐，会增加服务器处理的工作量。因此，对于记录、字段等的查询权限控制，大部分程序涉及人员喜欢在应用程序中实现，而不是在数据库上实现。
Oracle SQL语句执行顺序
(8)SELECT (9) DISTINCT (11) <select_list>
(1) FROM <left_table>
(3) <join_type> JOIN <right_table>
(2) ON <join_condition>
(4) WHERE <where_condition>
(5) GROUP BY <group_by_list>
(6) WITH {CUBE | ROLLUP}
(7) HAVING <having_condition>
(10) ORDER BY <order_by_list>
1）FROM：对FROM子句中的表执行笛卡尔积(交叉联接)，生成虚拟表VT1。
2）ON：对VT1应用ON筛选器，只有那些使为真才被插入到TV2。
3）OUTER (JOIN):如果指定了OUTER JOIN(相对于CROSS JOIN或INNER JOIN)，保留表中未找到匹配的行将作为外部行添加到VT2，生成TV3。如果FROM子句包含两个以上的表，则对上一个联接生成的结果表和下一个表重复执行步骤1到步骤3，直到处理完所有的表位置。
4）WHERE：对TV3应用WHERE筛选器，只有使为true的行才插入TV4。
5）GROUP BY：按GROUP BY子句中的列列表对TV4中的行进行分组，生成TV5。
6）CUTE|ROLLUP：把超组插入VT5，生成VT6。
7）HAVING：对VT6应用HAVING筛选器，只有使为true的组插入到VT7。
8）SELECT：处理SELECT列表，产生VT8。
9）DISTINCT：将重复的行从VT8中删除，产品VT9。
10）ORDER BY：将VT9中的行按ORDER BY子句中的列列表顺序，生成一个游标(VC10)，生成表TV11，并返回给调用者。
以上每个步骤都会产生一个虚拟表，该虚拟表被用作下一个步骤的输入。这些虚拟表对调用者(客户端应用程序或者外部查询)不可用。只有最后一步生成的表才会会给调用者。如果没有在查询中指定某一个子句，将跳过相应的步骤。

hive sql有没有控制流程的语法

1. DDL 操作
DDL操作类型
1.2 建表：
建表
•CREATE TABLE 创建一个指定名字的表。如果相同名字的表已经存在，则抛出异常；用户可以用 IF NOT EXIST 选项来忽略这个异常
•EXTERNAL 关键字可以让用户创建一个外部表，在建表的同时指定一个指向实际数据的路径（LOCATION）
•LIKE 允许用户复制现有的表结构，但是不复制数据
•COMMENT可以为表与字段增加描述

•ROW FORMAT
DELIMITED [FIELDS TERMINATED BY char] [COLLECTION ITEMS TERMINATED BY char]
[MAP KEYS TERMINATED BY char] [LINES TERMINATED BY char]
| SERDE serde_name [WITH SERDEPROPERTIES (property_name=property_value, property_name=property_value, ...)]
用户在建表的时候可以自定义 SerDe 或者使用自带的 SerDe。如果没有指定 ROW FORMAT 或者 ROW FORMAT DELIMITED，将会使用自带的 SerDe。在建表的时候，用户还需要为表指定列，用户在指定表的列的同时也会指定自定义的 SerDe，Hive 通过 SerDe 确定表的具体的列的数据。
•STORED AS
SEQUENCEFILE
| TEXTFILE
| RCFILE
| INPUTFORMAT input_format_classname OUTPUTFORMAT output_format_classname
如果文件数据是纯文本，可以使用 STORED AS TEXTFILE。如果数据需要压缩，使用 STORED AS SEQUENCE 。

1.3 创建简单表：
　　hive> CREATE TABLE pokes (foo INT, bar STRING);
1.4 创建外部表：
创建外部表
1.5 建分区表
分区表
1.6 建Bucket表
创建Bucket表
1.7 创建表并创建索引字段ds
　　hive> CREATE TABLE invites (foo INT, bar STRING) PARTITIONED BY (ds STRING);
1.8 复制一个空表
　　CREATE TABLE empty_key_value_store
　　LIKE key_value_store;
例子
例子

导入数据表的数据格式是：字段之间是tab键分割，行之间是断行。
及要我们的文件内容格式：
100636 100890 c5c86f4cddc15eb7 yyyvybtvt
100612 100865 97cc70d411c18b6f gyvcycy
100078 100087 ecd6026a15ffddf5 qa000100

1.9 显示所有表：
　　hive> SHOW TABLES;
1.10 按正条件（正则表达式）显示表，
　　hive> SHOW TABLES '.*s';
DDL类型-修改表结构
1.21 表添加一列：
　　hive> ALTER TABLE pokes ADD COLUMNS (new_col INT);
1.22 添加一列并增加列字段注释
　　hive> ALTER TABLE invites ADD COLUMNS (new_col2 INT COMMENT 'a comment');
1.23 更改表名：
　　hive> ALTER TABLE events RENAME TO 3koobecaf;
1.24 删除列：
　　hive> DROP TABLE pokes;

1.25 增加、删除分区
•增加
ALTER TABLE table_name ADD [IF NOT EXISTS] partition_spec [ LOCATION 'location1' ] partition_spec [ LOCATION 'location2' ] ...
partition_spec:
: PARTITION (partition_col = partition_col_value, partition_col = partiton_col_value, ...)
•删除
　　ALTER TABLE table_name DROP partition_spec, partition_spec,...
1.26 重命名表
　　ALTER TABLE table_name RENAME TO new_table_name
1.27 修改列的名字、类型、位置、注释：
ALTER TABLE table_name CHANGE [COLUMN] col_old_name col_new_name column_type [COMMENT col_comment] [FIRST|AFTER column_name]
　　这个命令可以允许改变列名、数据类型、注释、列位置或者它们的任意组合
1.28 表添加一列：
　　hive> ALTER TABLE pokes ADD COLUMNS (new_col INT);
1.29 添加一列并增加列字段注释
　　hive> ALTER TABLE invites ADD COLUMNS (new_col2 INT COMMENT 'a comment');
1.30 增加/更新列
　　ALTER TABLE table_name ADD|REPLACE COLUMNS (col_name data_type [COMMENT col_comment], ...)

• ADD是代表新增一字段，字段位置在所有列后面(partition列前)
REPLACE则是表示替换表中所有字段。
1.31 增加表的元数据信息
　　ALTER TABLE table_name SET TBLPROPERTIES table_properties table_properties:
:[property_name = property_value…..]
•用户可以用这个命令向表中增加metadata
1.31改变表文件格式与组织
　　ALTER TABLE table_name SET FILEFORMAT file_format
　　ALTER TABLE table_name CLUSTERED BY(userid) SORTED BY(viewTime) INTO num_buckets BUCKETS
　　这个命令修改了表的物理存储属性
1.4 创建／删除视图
CREATE VIEW [IF NOT EXISTS] view_name [ (column_name [COMMENT column_comment], ...) ][COMMENT view_comment][TBLPROPERTIES (property_name = property_value, ...)] AS SELECT
•增加视图
•如果没有提供表名，视图列的名字将由定义的SELECT表达式自动生成
•如果修改基本表的属性，视图中不会体现，无效查询将会失败
•视图是只读的，不能用LOAD/INSERT/ALTER
•DROP VIEW view_name
•删除视图
1.5 创建数据库
　　CREATE DATABASE name
1.6 显示命令

hive sql有没有控制流程的语法

1. DDL 操作
DDL操作类型
1.2 建表：
建表
•CREATE TABLE 创建一个指定名字的表。如果相同名字的表已经存在，则抛出异常；用户可以用 IF NOT EXIST 选项来忽略这个异常
•EXTERNAL 关键字可以让用户创建一个外部表，在建表的同时指定一个指向实际数据的路径（LOCATION）
•LIKE 允许用户复制现有的表结构，但是不复制数据
•COMMENT可以为表与字段增加描述

•ROW FORMAT
DELIMITED [FIELDS TERMINATED BY char] [COLLECTION ITEMS TERMINATED BY char]
[MAP KEYS TERMINATED BY char] [LINES TERMINATED BY char]
| SERDE serde_name [WITH SERDEPROPERTIES (property_name=property_value, property_name=property_value, ...)]
用户在建表的时候可以自定义 SerDe 或者使用自带的 SerDe。如果没有指定 ROW FORMAT 或者 ROW FORMAT DELIMITED，将会使用自带的 SerDe。在建表的时候，用户还需要为表指定列，用户在指定表的列的同时也会指定自定义的 SerDe，Hive 通过 SerDe 确定表的具体的列的数据。
•STORED AS
SEQUENCEFILE
| TEXTFILE
| RCFILE
| INPUTFORMAT input_format_classname OUTPUTFORMAT output_format_classname
如果文件数据是纯文本，可以使用 STORED AS TEXTFILE。如果数据需要压缩，使用 STORED AS SEQUENCE 。

1.3 创建简单表：
　　hive> CREATE TABLE pokes (foo INT, bar STRING);
1.4 创建外部表：
创建外部表
1.5 建分区表
分区表
1.6 建Bucket表
创建Bucket表
1.7 创建表并创建索引字段ds
　　hive> CREATE TABLE invites (foo INT, bar STRING) PARTITIONED BY (ds STRING);
1.8 复制一个空表
　　CREATE TABLE empty_key_value_store
　　LIKE key_value_store;
例子
例子

导入数据表的数据格式是：字段之间是tab键分割，行之间是断行。
及要我们的文件内容格式：
100636 100890 c5c86f4cddc15eb7 yyyvybtvt
100612 100865 97cc70d411c18b6f gyvcycy
100078 100087 ecd6026a15ffddf5 qa000100

1.9 显示所有表：
　　hive> SHOW TABLES;
1.10 按正条件（正则表达式）显示表，
　　hive> SHOW TABLES '.*s';
DDL类型-修改表结构
1.21 表添加一列：
　　hive> ALTER TABLE pokes ADD COLUMNS (new_col INT);
1.22 添加一列并增加列字段注释
　　hive> ALTER TABLE invites ADD COLUMNS (new_col2 INT COMMENT 'a comment');
1.23 更改表名：
　　hive> ALTER TABLE events RENAME TO 3koobecaf;
1.24 删除列：
　　hive> DROP TABLE pokes;

1.25 增加、删除分区
•增加
ALTER TABLE table_name ADD [IF NOT EXISTS] partition_spec [ LOCATION 'location1' ] partition_spec [ LOCATION 'location2' ] ...
partition_spec:
: PARTITION (partition_col = partition_col_value, partition_col = partiton_col_value, ...)
•删除
　　ALTER TABLE table_name DROP partition_spec, partition_spec,...
1.26 重命名表
　　ALTER TABLE table_name RENAME TO new_table_name
1.27 修改列的名字、类型、位置、注释：
ALTER TABLE table_name CHANGE [COLUMN] col_old_name col_new_name column_type [COMMENT col_comment] [FIRST|AFTER column_name]
　　这个命令可以允许改变列名、数据类型、注释、列位置或者它们的任意组合
1.28 表添加一列：
　　hive> ALTER TABLE pokes ADD COLUMNS (new_col INT);
1.29 添加一列并增加列字段注释
　　hive> ALTER TABLE invites ADD COLUMNS (new_col2 INT COMMENT 'a comment');
1.30 增加/更新列
　　ALTER TABLE table_name ADD|REPLACE COLUMNS (col_name data_type [COMMENT col_comment], ...)

• ADD是代表新增一字段，字段位置在所有列后面(partition列前)
REPLACE则是表示替换表中所有字段。
1.31 增加表的元数据信息
　　ALTER TABLE table_name SET TBLPROPERTIES table_properties table_properties:
:[property_name = property_value…..]
•用户可以用这个命令向表中增加metadata
1.31改变表文件格式与组织
　　ALTER TABLE table_name SET FILEFORMAT file_format
　　ALTER TABLE table_name CLUSTERED BY(userid) SORTED BY(viewTime) INTO num_buckets BUCKETS
　　这个命令修改了表的物理存储属性
1.4 创建／删除视图
CREATE VIEW [IF NOT EXISTS] view_name [ (column_name [COMMENT column_comment], ...) ][COMMENT view_comment][TBLPROPERTIES (property_name = property_value, ...)] AS SELECT
•增加视图
•如果没有提供表名，视图列的名字将由定义的SELECT表达式自动生成
•如果修改基本表的属性，视图中不会体现，无效查询将会失败
•视图是只读的，不能用LOAD/INSERT/ALTER
•DROP VIEW view_name
•删除视图
1.5 创建数据库
　　CREATE DATABASE name
1.6 显示命令

如何在Java中执行Hive命令或HiveQL

Java在1.5过后提供了ProcessBuilder根据运行时环境启动一个Process调用执行运行时环境下的命令或应用程序（1.5以前使用Runtime），关于ProcessBuilder请参考Java相关文档。调用代码如下：
String sql="show tables; select * from test_tb limit 10";
List<String> command = new ArrayList<String>();
command.add("hive");
command.add("-e");
command.add(sql);
List<String> results = new ArrayList<String>();
ProcessBuilder hiveProcessBuilder = new ProcessBuilder(command);
hiveProcess = hiveProcessBuilder.start();
BufferedReader br = new BufferedReader(new InputStreamReader(
hiveProcess.getInputStream()));
String data = null;
while ((data = br.readLine()) != null) {
results.add(data);
}
其中command可以是其它Hive命令，不一定是HiveQL。

如何在Java中执行Hive命令或HiveQL

Java在1.5过后提供了ProcessBuilder根据运行时环境启动一个Process调用执行运行时环境下的命令或应用程序（1.5以前使用Runtime），关于ProcessBuilder请参考Java相关文档。调用代码如下：
String sql="show tables; select * from test_tb limit 10";
List<String> command = new ArrayList<String>();
command.add("hive");
command.add("-e");
command.add(sql);
List<String> results = new ArrayList<String>();
ProcessBuilder hiveProcessBuilder = new ProcessBuilder(command);
hiveProcess = hiveProcessBuilder.start();
BufferedReader br = new BufferedReader(new InputStreamReader(
hiveProcess.getInputStream()));
String data = null;
while ((data = br.readLine()) != null) {
results.add(data);
}
其中command可以是其它Hive命令，不一定是HiveQL。

hive使用教程（2）--数据导入导出、查询与排序

1．语法

（1）load data:表示加载数据

（2）local:表示从本地加载数据到hive表；否则从HDFS加载数据到hive表

（3）inpath:表示加载数据的路径

（4）overwrite:表示覆盖表中已有数据，否则表示追加

（5）into table:表示加载到哪张表

（6）student:表示具体的表

（7）partition:表示上传到指定分区

2．实操案例

（0）创建一张表

（1）加载本地文件到hive

（2）加载HDFS文件到hive中

上传文件到HDFS

加载HDFS上数据

（3）加载数据覆盖表中已有的数据

上传文件到HDFS

加载数据覆盖表中已有的数据

1．创建一张分区表

2．基本插入数据

3．基本模式插入（根据单张表查询结果）

4．多插入模式（根据多张表查询结果）（有问题，只是查询单表不同分区的）

根据查询结果创建表（查询的结果会添加到新创建的表中）

1．创建表，并指定在hdfs上的位置

2．上传数据到hdfs上

3．查询数据

注意：先用export导出后，再将数据导入。

1．将查询的结果导出到本地

2．将查询的结果格式化导出到本地

3．将查询的结果导出到HDFS上(没有local)

基本语法：（hive -f/-e 执行语句或者脚本 > file）

后续..............................。

注意：Truncate只能删除管理表，不能删除外部表中数据

1．全表查询

2．选择特定列查询

注意：

（1）SQL 语言大小写不敏感。

（2）SQL 可以写在一行或者多行

（3）关键字不能被缩写也不能分行

（4）各子句一般要分行写。

（5）使用缩进提高语句的可读性。

1．重命名一个列

2．便于计算

3．紧跟列名，也可以在列名和别名之间加入关键字‘AS’

4．案例实操

查询名称和部门

（1）where针对表中的列发挥作用，查询数据；having针对查询结果中的列发挥作用，筛选数据。

（2）where后面不能写分组函数，而having后面可以使用分组函数。

（3）having只用于group by分组统计语句。

空字段赋值

5.CASE WHEN

需求

求出不同部门男女各多少人。结果如下：

创建本地emp_sex.txt，导入数据

创建hive表并导入数据

按需求查询数据

Order By：全局排序，一个Recer

1．使用 ORDER BY 子句排序

ASC（ascend）: 升序（默认）

DESC（descend）: 降序

2．ORDER BY 子句在SELECT语句的结尾

3．案例实操

（1）查询员工信息按工资升序排列

（2）查询员工信息按工资降序排列

按照员工薪水的2倍排序

按照部门和工资升序排序

Sort By：每个Recer内部进行排序，对全局结果集来说不是排序。

1．设置rece个数

2．查看设置rece个数

3．根据部门编号降序查看员工信息

4．将查询结果导入到文件中（按照部门编号降序排序）

Distribute By：类似MR中partition，进行分区，结合sort by使用。

注意，Hive要求DISTRIBUTE BY语句要写在SORT BY语句之前。

对于distribute by进行测试，一定要分配多rece进行处理，否则无法看到distribute by的效果。

案例实操：

当distribute by和sorts by字段相同时，可以使用cluster by方式。

cluster by除了具有distribute by的功能外还兼具sort by的功能。但是排序只能是升序排序，不能指定排序规则为ASC或者DESC。

1）以下两种写法等价

注意：按照部门编号分区，不一定就是固定死的数值，可以是20号和30号部门分到一个分区里面去。

如何用sql来写动态sql,本文主要是hiveql

动态SQL语句在编译时，并不知道SQL语句的内容，SQL语句的内容“不确定”，只有在运行时，才建立、解析并执行SQL语句。利用动态SQL，在存储过程中，可以动态创建表、视图、触发器等。
动态SQL主要用在以下两种场景：
编译时，无法确定SQL语句的内容
静态SQL不支持的SQL语句，就比如上面代码中的create
我们可以看到，静态SQL在编译时就已经提前检查了SQL正确性，以及涉及的数据库对象和对应的权限关系，而动态SQL则需要在运行的时候才能判断，所以，静态SQL的效率高于动态SQL。说了这么多概念的东西，我们现在就来实际看看如何编写动态SQL，以及如何运行动态SQL。

如何用sql来写动态sql,本文主要是hiveql

动态SQL语句在编译时，并不知道SQL语句的内容，SQL语句的内容“不确定”，只有在运行时，才建立、解析并执行SQL语句。利用动态SQL，在存储过程中，可以动态创建表、视图、触发器等。
动态SQL主要用在以下两种场景：
编译时，无法确定SQL语句的内容
静态SQL不支持的SQL语句，就比如上面代码中的create
我们可以看到，静态SQL在编译时就已经提前检查了SQL正确性，以及涉及的数据库对象和对应的权限关系，而动态SQL则需要在运行的时候才能判断，所以，静态SQL的效率高于动态SQL。说了这么多概念的东西，我们现在就来实际看看如何编写动态SQL，以及如何运行动态SQL。

如何通俗地理解Hive的工作原理

Hive是建立在 Hadoop 上的数据仓库基础构架。它提供了一系列的工具，可以用来进行数据提取转化加载（ETL），这是一种可以存储、查询和分析存储在 Hadoop 中的大规模数据的机制。Hive 定义了简单的类 SQL 查询语言，称为 HQL，它允许熟悉 SQL 的用户查询数据。同时，这个语言也允许熟悉 MapRece 开发者的开发自定义的 mapper 和 recer 来处理内建的 mapper 和 recer 无法完成的复杂的分析工作。

流程大致步骤为：

1. 用户提交查询等任务给Driver。

2. 编译器获得该用户的任务Plan。

3. 编译器Compiler根据用户任务去MetaStore中获取需要的Hive的元数据信息。

4. 编译器Compiler得到元数据信息，对任务进行编译，先将HiveQL转换为抽象语法树，然后将抽象语法树转换成查询块，将查询块转化为逻辑的查询计划，重写逻辑查询计划，将逻辑计划转化为物理的计划（MapRece）, 最后选择最佳的策略。

5. 将最终的计划提交给Driver。

6. Driver将计划Plan转交给ExecutionEngine去执行，获取元数据信息，提交给JobTracker或者SourceManager执行该任务，任务会直接读取HDFS中文件进行相应的操作。

7. 获取执行的结果。

8. 取得并返回执行结果。

描述将sql语句提交给mysql数据库以后数据库拿到sql语句后执行流程

我了解postgreSQL的执行流程，应该和mysql是相同的：
SQL语句在提交服务器后的流程如下：
1 进行词法分析
2进行语法分析，验证其中的属性、字段等在元数据中是否存在，并生成语法解析树
3 将语法解析树转换成逻辑执行计划
4对逻辑执行计划进行优化，得到优化后的逻辑执行计划
5根据优化后的逻辑执行计划，以及数据库中的索引等优化信息，为其中的关系代数操作符选择物理操作符和生成操作符的执行顺序，即生成查询的物理执行计划
6 将物理执行计划提交给查询执行引擎，调用物理操作符对应的函数执行查询
7 查询执行引擎将调用事务管理器、日志管理器、数据访问管理器等组件执行物理操作符的函数。
8将结果放入输出缓冲区
9返回结果数据。

描述将sql语句提交给mysql数据库以后数据库拿到sql语句后执行流程

我了解postgreSQL的执行流程，应该和mysql是相同的：
SQL语句在提交服务器后的流程如下：
1 进行词法分析
2进行语法分析，验证其中的属性、字段等在元数据中是否存在，并生成语法解析树
3 将语法解析树转换成逻辑执行计划
4对逻辑执行计划进行优化，得到优化后的逻辑执行计划
5根据优化后的逻辑执行计划，以及数据库中的索引等优化信息，为其中的关系代数操作符选择物理操作符和生成操作符的执行顺序，即生成查询的物理执行计划
6 将物理执行计划提交给查询执行引擎，调用物理操作符对应的函数执行查询
7 查询执行引擎将调用事务管理器、日志管理器、数据访问管理器等组件执行物理操作符的函数。
8将结果放入输出缓冲区
9返回结果数据。