Hive

1. hive 执行sql，报错： Error while compiling statement: FAILED: ParseException line 23:13 extraneous input '(' expecting ) near ')' in subquery source 2. sql 如下 ： SELECT pxx_id, pxxx_name, xxx, creationtime, creatorid, lastxxxxntime, lxxxierid, NULL, NULL, NULL FROM ( SELECT pxx_id, pxxx_name, xxx, creationtime, creatorid, lastxxxxntime, lxxxierid, NULL, NULL NULL Row_number ( ) OVER ( PARTITION BY xxx ORDER BY xxx DESC ) AS num FROM xxx.bxxxi_xxxts_xxxce ) bcp WHERE bcp.num = 1; 3. 解决：如下图，少一个逗号： 来源： oschina 链接： https://my.oschina.net/u/4319747/blog/4270698

1.前言 Spark是基于内存的计算，而Hadoop是基于磁盘的计算；Spark是一种内存计算技术。 但是事实上，不光Spark是内存计算，Hadoop其实也是内存计算。 Spark和Hadoop的根本差异是多个任务之间的数据通信问题：Spark多个任务之间数据通信是基于内存，而Hadoop是基于磁盘。 Spark SQL比Hadoop Hive快，是有一定条件的，而且不是Spark SQL的引擎一定比Hive的引擎快，相反，Hive的HQL引擎还比Spark SQL的引擎更快。 2.内存计算技术 内存计算技术是指将数据持久化至内存RAM中进行加工处理的技术。Spark并不支持将数据持久化至内存中，我们通常所说的是spark的数据缓存技术，如将RDD数据缓存至内存，但并没有实现持久化。缓存数据是可以擦除的，擦除后同样是需要我们重新计算的。Spark的数据处理是在内存中进行的，这话并没有错，其实当前的所有操作系统的数据处理都是在内存中进行的。所以，这内存计算并不是Spark的特性。 Spark是允许我们利用缓存技术和LRU算法缓存数据的。Spark的所有运算并不是全部都在内存中，当shuffle发生的时候，数据同样是需要写入磁盘的。所以，Spark并不是基于内存的技术，而是使用了缓存机制的技术。 3. 那Spark主要快在哪里呢？ Spark最引以为豪的就是官网介绍的经典案例

大数据软件比较 分布式的简单理解 在分布式系统出现之前，只有通过不断增加单个处理机的频率和性能来缩短数据的处理时间，分布式则将一个复杂的问题切割成很多的子任务，分布到多台机器上并行处理，在保证系统稳定性的同时，最大限度提高系统的运行速度。 MapReduce 模型整体分析 关于MapReduce的内容参照即将发布的博文MapReduce 将大规模数据处理作业拆分成多个可独立运行的Map任务，分布到多个处理机上进行运行，通过shuffle机制处理并产生一定的中间结果，在通过Reduce任务混洗合并产生最终的输出文件。 优势与不足分析 优势分析： MapReduce编程模型使得任务执行和任务通信之间变得简单且规范，实现任务并行化，扩展性良好； 每次Map操作之后，产生的中间结果会保存在磁盘上，不会永久的留在内存中，这样减少内存的消耗，避免了内存溢出带来的数据丢失,同时可以更好的容错； 但是这种设计会产生一定的缺点： 一些不适合使用Map和Reduce操作来完成的问题，如处理图或者网络问题时，这些数据结构包含着各种隐性的关系：图的边、子树、节点之间的父子关系、权重等，而这些关系很难被分解为键值对在一次计算中完全表示，同时各任务依赖关系比较复杂时，会产生为了适应该处理模型对任务分解造成效率降低的情况。 另外MapReduce的明显不足： 为了保证较好的扩展性

使用hadoop job -list来列出当前hadoop正在执行的jobs 然后使用hadoop job -kill job_1546932571227_0082来杀死该job任务， 原文链接：https://blog.csdn.net/zhy_2117/java/article/details/86261441 来源： oschina 链接： https://my.oschina.net/u/4321538/blog/4270095

1、sql语句的模块解析 当我们写一个查询语句时，一般包含三个部分，select部分，from数据源部分，where限制条件部分，这三部分的内容在sql中有专门的名称： 当我们写sql时，如上图所示，在进行逻辑解析时会把sql分成三个部分，project，DataSource，Filter模块，当生成执行部分时又把他们称为:Result模块、 DataSource模块和Opertion模块。 那么在关系数据库中，当我们写完一个查询语句进行执行时，发生的过程如下图所示： 整个执行流程是：query -> Parse -> Bind -> Optimize -> Execute 1、写完sql查询语句，sql的查询引擎首先把我们的查询语句进行解析，也就是Parse过程，解析的过程是把我们写的查询语句进行分割，把project，DataSource和Filter三个部分解析出来从而形成一个逻辑解析tree，在解析的过程中还会检查我们的sql语法是否有错误，比如缺少指标字段、数据库中不包含这张数据表等。当发现有错误时立即停止解析，并报错。当顺利完成解析时，会进入到Bind过程。 2、Bind过程，通过单词我们可看出，这个过程是一个绑定的过程。为什么需要绑定过程？这个问题需要我们从软件实现的角度去思考，如果让我们来实现这个sql查询引擎，我们应该怎么做

在hive-0.8.0后引入了import/export命令。 Export命令可以导出一张表或分区的数据和元数据信息到一个输出位置，并且导出数据可以被移动到另一个hadoop集群或hive实例，并且可以通过import命令导入数据。 当导出一个分区表，原始数据可能在hdfs的不同位置，export/import命令也支持导出分区表的不同子分区。 本次不考虑复制功能。 语法 EXPORT TABLE tablename [PARTITION (part_column="value"[, ...])] TO 'export_target_path' IMPORT [[EXTERNAL] TABLE new_or_original_tablename [PARTITION (part_column="value"[, ...])]] FROM 'source_path' [LOCATION 'import_target_path'] 简单的导出导入 # 导出非分区表 export table tb_insert_multi_03 to '/tmp/hive/export/tb_insert_multi_03'; import from '/tmp/hive/export/tb_insert_multi_03'; # 操作过程 0: jdbc:hive2://node225:10000

在使用Hive的过程中，复制表结构和数据是很常用的操作，本文介绍两种复制表结构和数据的方法。 1、复制非分区表表结构和数据 Hive集群中原本有一张bigdata17_old表，通过下面的SQL语句可以将bigdata17_old的表结构和数据复制到bigdata17_new表： CREATE TABLE bigdata17_new AS SELECT * FROM bigdata17_old; 如果是分区表，则必须使用like关键字复制表结构，包括分区，然后用insert语句将老表的数据插入新表中。 2、复制分区表表结构和数据 复制表SQL： CREATE TABLE bigdata17_new like bigdata17_old; 复制数据sql： insert overwrite table bigdata17_new partition(dt) select * from bigdata17_old; 如果遇到bigdata17_old表数据量巨大，有T以上的级别时，上述方法的效率则比较低。下面介绍一种快速复制表结构和表数据的方法。 从旧表中复制表结构，这个和上面介绍方法是一样的： CREATE TABLE bigdata17_new like bigdata17_old; 然后使用hadoop fs - cp命令将bigdata17

由 Confluence Administrator创建, 最终由 Lars Francke修改于 八月 15, 2018 原文链接 https://cwiki.apache.org/confluence/display/Hive/LanguageManual+DML 翻译：Google Google翻译，金山软件 金山词霸 校对：南大通用 范振勇 (2018.10.6) 在Hive中，有多种方式修改数据： LOAD INSERT 从查询到目标表 从查询到目录 成从SQL蜂巢表 UPDATE DELETE MERGE 从Hive0.8起可以使用EXPORT和IMPORT命令。 一、从文件加载到表 在将数据加载到表中时，Hive不执行任何转换。当前，Load操作是纯复制/移动操作，仅将数据文件移动到与Hive表对应的位置。 1.1、 语法 LOAD DATA [ LOCAL ] INPATH ' filepath ' [ OVERWRITE ] INTO TABLE tablename [ PARTITION (partcol1=val1, partcol2=val2 ...) ] LOAD DATA [ LOCAL ] INPATH ' filepath ' [ OVERWRITE ] INTO TABLE tablename [ PARTITION (partcol1=val1,

原文链接： https://blog.csdn.net/xueyao0201/article/details/79387647 因为业务要求，需要对Hive表进行delete，在官网查询后，发现update和delete是一类问题。在此总结下如何实现Hive表的delete和update。 首先，先看下官网关于 update 和 delete 的相关说明，使用注意事项也请参考官网说明，这里只介绍如何实现相关功能。 综合上述信息，Hive自0.14版本开始支持update和delete，要执行update和delete的表必须支持ACID，而关于ACID的详细介绍，需要查看 Hive Transactions . 经过对 Hive Transactions 相关内容的分析，我提取出了以下必要信息： 综合上述信息，可以得出以下结论： 如果一个表要实现update和delete功能，该表就必须支持ACID，而支持ACID，就必须满足以下条件： 1、表的存储格式必须是ORC（STORED AS ORC）； 2、表必须进行分桶（CLUSTERED BY (col_name, col_name, ...) INTO num_buckets BUCKETS）； 3、Table property中参数transactional必须设定为True（tblproperties(

Presto 是 Facebook 推出的一个基于Java开发的大数据分布式 SQL 查询引擎，可对从数 G 到数 P 的大数据进行交互式的查询，查询的速度达到商业数据仓库的级别，据称该引擎的性能是 Hive 的 10 倍以上。Presto 可以查询包括 Hive、Cassandra 甚至是一些商业的数据存储产品，单个 Presto 查询可合并来自多个数据源的数据进行统一分析。Presto 的目标是在可期望的响应时间内返回查询结果，Facebook 在内部多个数据存储中使用 Presto 交互式查询，包括 300PB 的数据仓库，超过 1000 个 Facebook 员工每天在使用 Presto 运行超过 3 万个查询，每天扫描超过 1PB 的数据。 目录： presto架构 presto低延迟原理 presto存储插件 presto执行过程 presto引擎对比 Presto架构 Presto查询引擎是一个Master-Slave的架构，由下面三部分组成: 一个Coordinator节点 一个Discovery Server节点 多个Worker节点 Coordinator: 负责解析SQL语句，生成执行计划，分发执行任务给Worker节点执行 Discovery Server: 通常内嵌于Coordinator节点中 Worker节点: 负责实际执行查询任务