五、HBase
1、HBase特点
Hbase是构建在HDFS上的分布式数据库，提供 高可靠性 、 高性能 、 列存储 、 可伸缩 、 实时读写 的分布式数据库系统。HBase主要用于大数据领域，MySQL 是行式存储，HBase 是列式存储。
HBase 是一种构建在 HBase 之上的分布式、面向列的存储系统，需要实时读写、随机访问超大规模数据集时，可以使用HBase。
HDFS不支持小文件，不支持并发写，不支持文件随机修改，查询效率也低 。HBase 却是一个支持百万级别高并发写入，支持实时查询，适合存储稀疏数据的分布式数据库系统。
·（1）海量存储：
HBase 单表可以有百亿行、百万列，可以在横向和纵向两个维度插入数据，具有很大的弹性。
当关系型数据库的单个表的记录在亿级时，查询和写入的性能都会呈现指数级下降，这种庞大的数据量对传统数据库来说是一种灾难，而HBase 在限定某个列的情况下对于单表存储百亿甚至更多的数据都没有性能问题； HBase 采用 LSM 树作为内部数据存储结构，这种结构会周期性地将较小文件合并成大文件，以减少对磁盘的访问。
·（2）列式存储：
HBase表的数据是基于列族进行存储的，列族是在列的方向上的划分，每个列族是单独存储的，且支持基于列的独立检索。
· （3）稀疏性：主要是针对HBase列的灵活性，在列族中，你可以指定任意多的列，在列数据为空的情况下，是不会占用存储空间的，在很大程度上节省了存储开销。
·（4）扩展性强：依赖HDFS，当磁盘空间不足的时候，只需要动态增加datanode节点就可以了，可以通过增加服务器来对集群的存储进行扩容；
HBase工作在 HDFS 之上，理所当然地支持分布式表，也继承了 HDFS 的可扩展性。HBase 的扩展是横向的，横向扩展是指在扩展时不需要提升服务器本身的性能，只需添加服务器到现有集群即可。 HBase表根据 Region 大小进行分区，分别存在集群中不同的节点上，当添加新的节点时，集群就重新调整，在新的节点启动 HBase 服务器，动态地实现扩展。这里需要指出，HBase 的扩展是热扩展，即在不停止现有服务的前提下，可以随时添加或者减少节点。
·（5）高可靠性
HBase运行在 HDFS 上，HDFS 的多副本存储可以让它在岀现故障时自动恢复，同时 HBase 内部也提供 WAL 和 Replication 机制。
WAL（Write-Ahead-Log）预写日志是在 HBase 服务器处理数据插入和删除的过程中用来记录操作内容的日志，保证了数据写入时不会因集群异常而导致写入数据的丢失；而 Replication 机制是基于日志操作来做数据同步的。
当集群中单个节点出现故障时，协调服务组件ZooKeeper通知集群的主节点，将故障节点的 HLog 中的日志信息分发到各从节点进行数据恢复。
·（6）高并发：支持高并发的读写请求
·（7）数据多版本：表中数据可以有多个版本值，默认情况下是根据版本号去区分，版本号就是插入数据的时间戳
·（8）数据类型单一：所有的数据在HBase中是以字节数组进行存储
·启动时，需要提前启动HDFS及 ZooKeeper集群
rowkey行键 -> Column Family列族 -> Column列 -> cell单元格 -> Timestamp时间戳
2、架构原理
HMaster -> HRegionServer -> Region
·（1）Client客户端 ：Client是操作HBase集群的入口
·对于管理类的操作，如表的增删改操纵，Client通过RPC与HMaster通信完成；
·对于表数据的读写操作，Client通过RPC与RegionServer交互，读写数据；
·Client类型：HBase shell、Java编程接口、Thrift、Avro、Rest等等；
·（2）ZooKeeper集群：
·实现了HMaster的高可用，多HMaster间进行主备选举；
·保存HBase元数据信息meta表，提供HBase表中region的寻址入口的线索数据；
·对HMaster和HRegionServer实现了监控
·（3）HMaster：负责Table表和Region的相关管理工作：
·关于Table：管理Client对Table的增删改的操作
·关于Region：在Region分裂后，负责新Region分配到指定的HRegionServer 上；管理HRegionServer间的负载均衡，迁移region分布；当 HRegionServer宕机后，负责其上的region的迁移
·（4）HRegionServer
·响应客户端的读写数据请求
·负责管理一系列的Region
·切分在运行过程中变大的region
·（5）Region：HBase集群中分布式存储的最小单元
·一个Region对应一个Table表的部分数据
·Region是HBase集群中分布式存储的最小单元，一个Region对应一个Table表的部分数据。
·memstore是一块 内存区域，写入的数据会先写入memstore进行缓冲，然后再把数据刷到磁盘；
·StoreFile是HFile的抽象对象，如果说到StoreFile就等于HFile，每次memstore刷写数据到磁盘，就生成对应的一个新的HFile文件出来
·一个HRegionServer会负责管理很多个region ，一个region包含很多个store，一个列族就划分成一个store，一个store里面只有一个memstore，有很多个 StoreFile ,最后数据是以很多个 HFile 这种数据结构的文件保存在HDFS上。
3、读写过程
Hbase读数据
·1、客户端首先与zk进行连接，从zk找到包含meta表的HRegionServer，连接此包含HRegionServer，读取meta表中的数据；
· 2、根据要查询信息，先找到数据对应的region信息，在找到这个region对应的regionServer，然后发送请求
·3、查找并定位到对应的region，
·4、先从memstore查找数据---如果没有从BlockCache上读取----如果也没有再到StoreFile上进行读取。
·5、从storeFile中读取到数据之后，不是直接把结果数据返回给客户端，而是把数据先写入到BlockCache中，目的是为了加快后续的查询；然后在返回结果给客户端。
Hbase写数据
·1、客户端首先与zk进行连接，从zk找到zk找到meta表的region位置，即包含meta表的HRegionServer，连接此包含HRegionServer，读取meta表中的数据；
·2、根据要查询信息，先找到数据对应的region信息，在找到这个region对应的regionServer，然后发送请求
·3、查找并定位到对应的region，
·4、写数据时，把数据分别写到HLog 和memstore各一份进行缓冲，
·5、flush：memstore达到阈值后，把数据**刷到磁盘**生成多个storeFile文件。
Region中任意一个memstore达到128MB
Region中所有Memstore的大小总和达到block.multiplier * flush.size
Region Server中HLog数量达到上限
·6、compact：
小合并：小的store file合并成相对较大的store file，
大合并：合并Store中所有的HFile为一个HFile
4、flush刷写
为了减少flush过程对读写的影响，将整个flush过程分为三个阶段：
①prepare阶段： 将Memstore中当前数据集做一个快照snapshot；再新建一个数据集CellSkipListSet。后期写入的数据都会写入新的CellSkipListSet中。
②flush阶段：将prepare阶段生成的snapshot持久化为临时文件，统一放到目录.tmp下。涉及到磁盘IO操作，相对比较耗时。
③commit阶段：将flush阶段生成的临时文件移到指定的ColumnFamily目录下，针对HFile生成对应的storefile和Reader，最后再清空prepare阶段生成的snapshot。
触发条件：
①一个MemStore的大小达到了上限128m
②一个Region中所有Memstore总和达到了上限，128*个数
③一个Region Server中所有Memstore总和超过低水位阈值
④一个Region Server中HLog数量达到上限
⑤定期1小时刷新Memstore
⑥通过shell命令flush ‘tablename’或者flush ‘region name’，手动刷写
5、campact合并
为防止小文件过多，以保证查询效率，需将这些小的store file合并成相对较大的store file，这个过程就称之为compaction。
小合并：将一些小的、相邻的StoreFile，合并成一个更大的StoreFile，对于超过了TTL的数据、更新的数据、删除的数据仅仅只是做了标记，并没有进行物理删。一次结果是更少并且更大的StoreFile，触发频率很高。
大合并：将所有的StoreFile合并成一个StoreFile， 清理三类无意义数据：被删除的数据、TTL过期数据、版本号超过设定版本号的数据。合并频率比较低，默认7天执行一次，并且性能消耗非常大，建议生产关闭(设置为0)，在应用空闲时间手动触发。一般可以是手动控制进行合并，防止出现在业务高峰期。
6、region拆分
①0.94版本前默认，region大小大于某个阈值10G；
②0.94~2.0版本默认，大小递增，regioncount^3 * 128M * 2，256M 2048M 6912M 10G；
③2.0版本默认,如果region个数等于1， 切分阈值为flush size * 2，否则为MaxRegionFileSize；
④根据rowKey前缀对数据进行分组
7、预分区
当一个table刚被创建的时候，Hbase默认的分配一个region给table。 说这个时候，所有的读写请求都会访问到同一个regionServer的同一个region中，这个时候就达不到负载均衡的效果了，集群中的其他regionServer就可能会处于比较空闲的状态。
在创建table的时候就配置好预分区，生成多个region。增加数据读写效率；负载均衡，防止数据倾斜；方便集群容灾调度region；优化Map数量
每一个region维护着startRow与endRowKey，如果加入的数据符合某个region维护的rowKey范围，则该数据交给这个region维护。
8、rowkey设计三原则
长度原则、散列原则、唯一原则
rowkey长度原则
rowkey是一个二进制码流，可以是任意字符串，最大长度64kb，实际应用中一般为10-100bytes，以byte[]形式保存，一般设计成定长。建议尽可能短；但是也不能太短，否则rowkey前缀重复的概率增大； 设计过长：会降低memstore内存的利用率和HFile存储数据的效率。
rowkey散列原则：
建议将rowkey的高位：作为散列字段，这样将提高数据均衡分布在每个RegionServer，以实现负载均衡的几率。如果没有散列字段，首字段直接是时间信息。所有的数据都会集中在一个RegionServer上，这样在数据检索的时候负载会集中在个别的RegionServer上，造成热点问题，会降低查询效率。
rowkey唯一原则：
必须在设计上保证其唯一性，rowkey是按照字典顺序排序存储的；因此，设计rowkey的时候，要充分利用这个排序的特点，可以将经常读取的数据存储到一块，将最近可能会被访问的数据放到一块
9、什么是热点
检索habse的记录首先要通过row key来定位数据行。当大量的client访问hbase集群的一个或少数几个节点，造成少数region server的读/写请求过多、负载过大，而其他region server负载却很小，就造成了“热点”现象。
热点的解决方案（预分区、加盐、哈希、反转）
预分区：目的让表的数据可以均衡的分散在集群中，而不是默认只有一个region分 布在集群的一个节点上。
加盐：在rowkey的前面增加随机数，具体就是给rowkey分配一个随机前缀以使得 它和之前的rowkey的开头不同
哈希：使同一行永远用一个前缀加盐。哈希也可以使负载分散到整个集群，但是读 却是可以预测的。使用确定的哈希可以让客户端重构完整的rowkey，可以使 用get操作准确获取某一个行数据。
反转：反转固定长度或者数字格式的rowkey。这样可以使得rowkey中经常改变的 部分（最没有意义的部分）放在前面。
10、协处理器
Hbase作为列族数据库最经常被人诟病的特性包括：无法轻易建立“二级索引”，难以执行求和、计数、排序等操作。比如，在旧版本的(<0.92)Hbase 中，统计数据表的总行数，需 要使用 Counter 方法，执行一次 MapReduce Job 才能得到。
虽然HBase在数据存储层中集成了 MapReduce，能够有效用于数据表的分布式计算。然而在很多情况下，做一些简单的相加或者聚合计算的时候， 如果直接将计算过程放置在server端，能够减少通讯开销，从而获得很好的性能提升。
于是，HBase在 0.92 之后引入了协处理器(coprocessors)，实现一些激动人心的新特性：能够轻易建立二次索引、复杂过滤器(谓词下推)以及访问控制等。
协处理器有两种：Observer协处理器 endpoint协处理器
Observer协处理器： 类似于传统数据库中的触发器，主要在服务端工作；允许集群在正常的客户端操作过程中，可以有不同的行为表现；可以实现权限管理、优先级设置、监控、ddl控制、 二级索引等功能。
endpoint协处理器；类似于传统数据库中的存储过程，主要在client端工作；允许扩展集群的能力，对客户端应用开放新的运算命令；可以实现min、 max、 avg、 sum、 distinct、 group by 等功能
协处理器的加载方式有两种：静态加载修改hbase-site.xml ；动态加载启用表aggregation，只对特定的表生效。
六、Hive
Hive是基于Hadoop的一个数据仓库工具，可以将结构化的数据文件映射为一张数据库表，并提供类SQL查询功能。本质是将SQL转换为MapReduce任务进行运算，底层由HDFS来提供数据的存储，可以理解就是一个MapReduce的客户端，通过解析hql语句，实现hdfs上面的数据的查询操作，真实的数据保存在hdfs上面的，数据的计算，使用的mr的程序。每执行一次查询，不一定会有对应的mr任务执行，有些查询，不需要mr的参与；
hive当中建库建表的元数据信息保存在mysql里面；Hive只适合用来做海量离线数据统计分析，也就是数据仓库。
1、数据仓库的基本概念
数据仓库Data Warehouse，简写为DW或DWH。数据仓库的目的是构建面向分析的集成化数据环境，为企业提供决策支持。它出于分析性报告和决策支持目的而创建。
本身并不“生产”任何数据，也不需要“消费”任何的数据，数据来源于外部，并且开放给外部应用，这也是为什么叫“仓库”，而不叫“工厂”的原因。
仓库，就是把数据拿过来，分类存好，让别人来取；数据仓库是面向主题的、集成的、非易失的和时变数据集合，用以支持管理决策。有、主要用于报表展示、用户画像、数据挖掘、实时的风控、推荐系统。
2、数据仓库与数据库区别，
（1）是OLTP与 OLAP 的区别。
OLTP（On-Line Transaction Processing，）操作型处理，叫联机事务处理，是针对具体业务在数据库联机查询、修改等日常操作。关心操作响应时间、数据安全性、完整性和并发支持的用户数等问题，数据库系统。
OLAP（On-Line Analytical Processing）分析型处理，叫联机分析处理 ，一般针对某些主题的历史数据进行分析，支持管理决策。
（2）数据库设计是尽量避免冗余。数据仓库在设计是有意引入冗余，依照分析需求，分析维度、分析指标进行设计。
（3）数据库是为捕获数据而设计，数据仓库是为分析数据而设计。
3、数据仓库分层架构
按照数据流入流出的过程，数据仓库架构可分为三层——源数据、数据仓库、数据应用。 数据仓库的数据来源于不同的源数据，并提供多样的数据应用，数据自下而上流入数据仓库后向上层开放应用，而数据仓库只是中间集成化数据管理的一个平台
·（1）源数据层（ODS）：此层数据无任何更改，直接沿用外围系统数据结构和数据，不对外开放；为临时存储层，是接口数据的临时存储区域，为后一步的数据处理做准备。
·（2）数据仓库层（DW）：也称为细节层，DW层的数据应该是一致的、准确的、干净的数据，即对源系统数据进行了清洗（去除了杂质）后的数据。
·（3）数据应用层（DA或APP）：前端应用直接读取的数据源；根据报表、专题分析需求而计算生成的数据。
数据仓库从各数据源获取数据及在数据仓库内的，数据转换和流动都可以认为是ETL（抽取Extra, 转化Transfer, 装载Load）的过程，ETL是数据仓库的流水线，也可以认为是数据仓库的血液，它维系着数据仓库中数据的新陈代谢，而数据仓库日常的管理和维护工作的大部分精力就是保持ETL的正常和稳定。
为什么要对数据仓库分层？
①复杂问题简单化、②清晰数据结构(方便管理)、③增加数据的复用性、④隔离原始数据(解耦)
·用空间换时间，通过大量的预处理来提升应用系统的用户体验（效率），因此数据仓库会存在大量冗余的数据；不分层的话，如果源业务系统的业务规则发生变化将会影响整个数据清洗过程，工作量巨大。
·通过数据分层管理可以简化数据清洗的过程，因为把原来一步的工作分到了多个步骤去完成，相当于把一个复杂的工作拆成了多个简单的工作，把一个大的黑盒变成了一个白盒，每一层的处理逻辑都相对简单和容易理解，这样我们比较容易保证每一个步骤的正确性，当数据发生错误的时候，往往我们只需要局部调整某个步骤即可。
4、怎么把hive翻译成的mr的
主要就是通过解析器的，就是将sql语法解析成为mr的任务
解析器：主要就是用于解析sql语法
编译器：将解析之后的sql语法进行编译成为MR的任务
优化器：一定的优化功能，自动的会对我们写的sql语句进行调优，调优的功能有限
执行器：提交mr的任务到yarn上面去执行的
5、hive优缺点
优点：
（1）操作接口采用类SQL语法，提供快速开发的能力（简单、容易上手）。
（2）避免了去写MapReduce，减少开发人员的学习成本。
（3）Hive支持用户自定义函数，用户可以根据自己的需求来实现自己的函数。
缺点：
（1）Hive 不支持记录级别的增删改操作；
（2）Hive 的查询延迟很严重；
（3）Hive 不支持事务；
6、hive几种表
①内部表：创建内部表的时候，没有external关键字；删除内部表的时候，会同步的删除hdfs的数据。DW层
②外部表：创建外部表的时候有external关键字；删除外部表的时候，不会删除hdfs的数据外部表删的只是表结构，数据存在hdfs，元数据在mysql。ODS层
③分区表：就是分文件夹，实际工作当中，数据一般都是按照每天进行采集的，每天的数据都会放到某一个日期文件夹。
④分桶表：就是分文件，将一个大的文件分成多个小的文件，每个文件里面保存部分数据，到时候如果需要获取数据的时候，可以直接从对应的文件里面获取即可。
分桶将整个数据内容，按照某列属性值取hash值进行区分，具有相同hash值的数据进入到同一个文件中。可以过滤掉大量不相关的文件，提高查询效率。
7、4个By区别
1）Sort By：分区内有序；
2）Order By：全局排序，只有一个Reducer；
3）Distrbute By：类似MR中Partition，进行分区，结合sort by使用。
4） Cluster By：当Distribute by和Sorts by字段相同时，可以使用Cluster by方式。Cluster by除了具有Distribute by的功能外还兼具Sort by的功能。但是排序只能是升序排序，不能指定排序规则为ASC或者DESC。
8、SparkSQL整合hive
由于hive原生是基于MapReduce的，导致其查询耗时较长。为了保留Hive的架构解决方案，并优化查询速度，采用SparkSql与hive整合(spark on hive)，通过SparkSql读取hive中表的元数据，把HiveHQL底层采用MapReduce处理任务导致性能慢的特点，改为更加强大的Spark引擎来进行相应的计算处理。
Spark SQL的其中一个分支就是Spark on Hive，就是使用Hive中HQL的解析逻辑、执行计划翻译、执行计划优化等逻辑，近似认为仅将物理执行计划从MR作业替换成了Spark作业。
Spark SQL整合hive：就是获取hive表中的元数据信息（在mysql中），然后通过Spark SQL来操作数据。
整合步骤：
1）、拷贝hive配置文件到spark
hive目录中conf目录下的hive-site.xml，hive的元数据信息在node03的mysql数据库中，而整合需要spark能够读取找到Hive的元数据以及数据存放位置
2）、拷贝mysql驱动到spark
3）启动：启动HDFS,YARN集群；启动spark集群；启动hive；启动spark sql
可以像在spark-sql中操作hive中的数据库和表，表明整合成功。
9、hive调优
①Fetch抓取：对某些情况的查询可以不必使用MapReduce计算，在全局查找、字段查找、limit查找等都不走mapreduce。
把hive-default.xml.template文件中hive.fetch.task.conversion设置成more，然后执行查询语句，查询方式都不会执行mr程序。默认是more，（老版本minimal）；设置成none，然后执行查询语句，都会执行mapreduce程序
②本地模式：如果数据量小，只启动一个Maptask
默认情况下是启用hadoop的job模式，把任务提交到集群中运行，这样会导致计算非常缓慢；开启本地模式，并执行查询语句 set hive.exec.mode.local.auto=true; //开启本地mr
③表的优化 join
老版本hive，大小表 join 时，小表放在join的左边；大表join大表 时，空 key 过滤，空 key 赋一个随机的值；map join，在Map端先进行部分聚合，最后在Reduce端得出最终结果；count distinct，使用先group by 再count的方式替换;多个表关联时，最好分拆成小段，避免大sql（无法控制中间Job）；
④使用分区剪裁、列剪裁，尽可能早地过滤掉尽可能多的数据量，避免大量数据流入外层SQL。尽量使用分区过滤，少用select *
⑤并行执行，把一个sql语句中没有相互依赖的阶段，并行去运行，提高集群资源利用率配置：set hive.exec.parallel=true; set hive.exec.parallel.thread.number=16;
⑥开启严格模式，防止用户执行，那些可能意想不到的不好的影响的查询。
配置：set hive.mapred.mode=strict;默认是非严格模式nonstrict
开启严格模式，可以禁止3种类型的查询。对于分区表，除非where语句中含有分区字段过滤条件来限制范围，否则不允许执行对于使用了order by语句的查询，要求必须使用limit语句
⑦限制笛卡尔积的查询
⑧开启数据的压缩，Hive表中间数据压缩Hive表最终输出结果压缩
⑩避免数据倾斜：合理设置Map数 ；合理设置Reduce数；小文件合并；复杂文件增加Map数 ；
11、运维如何对hive进行调度
将hive的sql定义在脚本当中；使用azkaban或者oozie进行任务的调度；监控任务调度页面。
12、Hive中split、coalesce及collect_list函数的用法（可举例）？
·split将字符串转化为数组，即：split('a,b,c,d' , ',') ==> ["a","b","c","d"]。
·coalesce(T v1, T v2, …)返回参数中的第一个非空值；如果所有值都为 NULL，那么返回NULL。
·collect_list列出该字段所有的值，不去重 => select collect_list(id) from table。
13、Count(Distinct) 去重统计
数据量小的时候无所谓，数据量大的情况下，由于COUNT DISTINCT操作需要用一个Reduce Task来完成，这一个Reduce需要处理的数据量太大，就会导致整个Job很难完成，一般COUNT DISTINCT使用先GROUP BY再COUNT的方式替换
尽量避免笛卡尔积，join的时候不加on条件，或者无效的on条件，Hive只能使用1个reducer来完成笛卡尔积
14、Group By
默认情况下，Map阶段同一Key数据分发给一个reduce，当一个key数据过大时就倾斜了。并不是所有的聚合操作都需要在Reduce端完成，很多聚合操作都可以先在Map端进行部分聚合，最后在Reduce端得出最终结果。
开启Map端聚合参数设置
（1） 是否在Map端进行聚合，默认为True hive.map.aggr = true
（2） 在Map端进行聚合操作的条目数目 hive.groupby.mapaggr.checkinterval = 100000
（3）有数据倾斜的时候进行负载均衡（默认是false） hive.groupby.skewindata = true
当选项设定为true，生成的查询计划会有两个MR Job。第一个MR Job中，Map的输出结果会随机分布到Reduce中，每个Reduce做部分聚合操作，并输出结果，这样处理的结果是相同的Group By Key有可能被分发到不同的Reduce中，从而达到负载均衡的目的；
第二个MR Job再根据预处理的数据结果按照Group By Key分布到Reduce中（这个过程可以保证相同的Group By Key被分布到同一个Reduce中），最后完成最终的聚合操作。
14、Hive有哪些方式保存元数据，各有哪些特点？
元数据：Metastore 包括：表名、表所属的数据库（默认是default）、表的拥有者、列/分区字段、表的类型（是否是外部表）、表的数据所在目录等；默认存储在自带的derby数据库中，推荐使用MySQL存储Metastore
1）、内置derby存储
不同路径启动hive，每一个 hive 拥有一套自己的元数据，无法共享hive服务和metastore服务运行在同一个进程中，derby服务也运行在该进程中.内嵌模式使用的是内嵌的Derby数据库来存储元数据，也不需要额外起Metastore服务。
在哪个目录下启动,就会在对应的目录下生成 derby.log 和 metastore.db,只有在此目录下再次启动才可以继续使用上次的元数据库。
这个是默认的，配置简单，但是一次只能一个客户端连接，适用于用来实验，不适用于生产环境。
2）、本地模式（Local）:本地安装mysql 替代derby存储元数据；
不再使用内嵌的Derby作为元数据的存储介质，而是使用其他数据库比如MySQL来存储元数据。hive服务和metastore服务运行在同一个进程中，mysql是单独的进程，可以同一台机器，也可以在远程机器上。
这种方式是一个多用户的模式，运行多个用户client连接到一个数据库中。这种方式一般作为公司内部同时使用Hive。每一个用户必须要有对MySQL的访问权利，即每一个客户端使用者需要知道MySQL的用户名和密码才行。
3）、远程模式（Remote）: 远程安装mysql 替代derby存储元数据；
Hive服务和metastore在不同的进程内，可能是不同的机器，该模式需要将hive.metastore.local设置为false，将hive.metastore.uris设置为metastore服务器URL远程元存储需要单独起metastore服务，然后每个客户端都在配置文件里配置连接到该metastore服务。将metadata作为一个单独的服务进行启动。各种客户端通过beeline来连接，连接之前无需知道数据库的密码。
仅连接远程的mysql并不能称之为“远程模式”，是否远程指的是metastore和hive服务是否在同一进程内。
网友评论