访问hive的另外一种方法：进入到apache-hve-2.3.2-bin.tar/bin目录下
复制一个ssh通道，在输入 ./beeline -u jdbc:hive2:// 注：第一次启动hive2和修改文件后进去需要输入hiveserve2，不然可直接输入./beeline -u jdbc:hive2://命令进入。
在jupyter里写SQL语句格式：spark.sql("SQL语句")
hive 语法（创建一个表）：设计分区，有内表和外表
CREATE [TEMPORARY] [EXTERNAL]（加上这个就是外表） TABLE [IF NOT EXISTS]（如果不存在我就去创建）
[db_name.]（如果不写数据库名，默认当前数据库）table_name
[(col_name data_type[COMMENT col_comment],…[constraint_specification])]
[COMMENT table_comment]
[PARTITIONED BY (col_name data_type[COMMENT col_comment],…)] 创建分区（相当于目录）、列名、描述
[CLUSTERED BY (col_name,col_name,…)[SORTED BY (col_name[ASC|DESC],…)] INTO num_buckets BUCKETS] 桶相当于是分区里面的文件
[LOCATION hdfs_path]指定位置，存到什么地方
create [临时表][外部表]（不写这个就是创建一个普通的内部表） table tablename
外部表特点：只是存储元数据，删除外部表只是删除了元数据，表并没有删；而内部表删除表全部都删掉。
[ROW FORMAT row_format] 数据量大，不可能一条一条插入，行进行格式化，一条一条进行拆分。
row format delimited fields terminated by ','; 以后往这个表插入数据按照，号进行拆分
load data local inpath '/home/hadoop/student.data' into table tb_student; 导入本地文件
可以这样单挑插入：
插入本地文件到表里，不是本地文件就不用写local ,在路径后 into前 可加OVERWRITE 覆盖存才数据
create table student_python5(id int,name varchar(20),sex varchar(20),age int,grade_id int)partitioned by(par string) clustered by(age) sorted by (age desc) into 5 buckets row format delimited fieldsterminated by ',';
HIVE与mysql的关系 hive常用命令整理 hive与hdfs整合过程
Hive是一个基于hadoop的数据仓库平台。通过hive，我们可以方便地进行ETL的工作。hive定义了一个类似于SQL的查询语言：HQL，能够将用户编写的QL转化为相应的Mapreduce程序基于Hadoop执行。
Hive 可以看成是从HQL到Map-Reduce的 映射器，hive并没有存贮数据
hive数据在HDFS的warehouse目录下，一个表对应一个子目录。
本地的/tmp目录存放日志和执行计划内嵌模式：元数据保持在内嵌的Derby模式，只允许一个会话连接
本地独立模式：在本地安装Mysql，把元数据放到Mysql内
远程模式：元数据放置在远程的Mysql数据库。
hive的表分为两种，内表和外表。
Hive 创建内部表时，会将数据移动到数据仓库指向的路径；若创建外部表，仅记录数据所在的路径，不对数据的位置做任何改变。
在删除表的时候，内部表的元数据和数据会被一起删除，而外部表只删除元数据，不删除数据。这样外部表相对来说更加安全些，数据组织也更加灵活，方便共享源数据。
hadoop集群中有两种节点，一种是namenode，另一种是DataNode。其中DataNode主要负责数据存储，namenode主要负责三个功能，分别是1管理元数据2维护目录树3响应客户请求
hdfs在外界看来就是普通的文件系统，可以通过路径进行数据的访问等操作，但在实际过程存储中，却是分布在各个节点上。如上图所示，是一条元数据，/test/a.log 是在hdfs文件系统中的路径，3是这个文件的副本数(副本数可以通过在配置文件中的配置来修改的)。在hdfs中，文件是进行分块存储的，如果文件过大，就要分成多块存储，每个块在文件系统中存储3个副本，以上图为例，就是分成blk_1和blk_2两个块，每个块在实际的节点中有3个副本，比如blk_1的3个副本分别存储在h0，h1，h3中。
现在由此引出一个问题，namenode中的元数据是存储在哪里的？首先，我们做个假设，如果存储在namenode节点的磁盘中，因为经常需要进行随机访问，还有响应客户请求，必然是效率过低。因此，元数据需要存放在内存中。但如果只存在内存中，一旦断点，元数据丢失，整个集群就无法工作了！！！因此必须在磁盘中有备份，在磁盘中的备份就是fsImage，存放在namenode节点对应的磁盘中。这样又会带来新的问题，当在内存中的元数据更新时，如果同时更新fsImage，就会导致效率过低，但如果不更新，就会发生一致性问题，一旦namenode节点断点，就会产生数据丢失。因此，引入edits.log文件(只进行追加操作，效率很高)。每当元数据有更新或者添加元数据时，修改内存中的元数据并追加到edits.log中。这样，一旦namenode节点断电，可以通过fsImage和edits.log的合并，合成元数据。但是，如果长时间添加数据到edit.log中，会导致该文件数据过大，效率降低，而且一旦断电，恢复元数据需要的时间过长。因此，需要定期进行fsImage和edits.log的合并，如果这个操作有namenode节点完成，又会效率过低。因此，引入一个新的节点secondaryNamenode，专门用于fsImage和edits.log的合并。
检查点处理过程的具体步骤如下
1)namenode节点每隔一定时间请求secondaryNamenode合并操作
2)secondaryNamenode请求namenode进行edits.log的滚动，这样新的编辑操作就能够进入新的文件中
3)secondaryNamenode从namenode中下载fsImage和edits.log
4)secondaryNamenode进行fsImage和edits.log的合并,成为fsImage.checkpoint文件
5)namenode下载合并后的fsImage.checkpoin文件
6)将fsImage.checkpoint和edits.new命名为原来的文件名(这样之后fsImage和内存中的元数据只差edits.new)