怎样查看hive建的外部表的数据库

1

进入HIVE之前要把HADOOP给启动起来，因为HIVE是基于HADOOP的。所有的MR计算都是在HADOOP上面进行的。

2

在命令行中输入：hive。这个时候就可以顺利的进入HIVE了。当然了，如果你想直接执行HQL脚本文件可以这样：hive -f xxxxxhql。

3

进入hive之后一一般默认的数据库都是default。如果你切换数据库的话所建的表都会是在default数据库里面。

4

创建数据库的语法是：create database database_name;非常简单的，其实hive跟mysql的语法还是比较相似的。为什么呢？请继续往下

5

切换数据库的时候可以输入：use database_name；

查看所有数据库的时候可以输入：show databases;

查看所有表的时候可以输入：show tables

6

看表结构的时候可以输入：describe tab_name;

Hive是基于Hadoop平台的数仓工具，具有海量数据存储、水平可扩展、离线批量处理的优点，解决了传统关系型数仓不能支持海量数据存储、水平可扩展性差等问题，但是由于Hive数据存储和数据处理是依赖于HDFS和MapReduce，因此在Hive进行数据离线批量处理时，需将查询语言先转换成MR任务，由MR批量处理返回结果，所以Hive没法满足数据实时查询分析的需求。

Hive是由FaceBook研发并开源，当时FaceBook使用Oracle作为数仓，由于数据量越来越大，Oracle数仓性能越来越差，没法实现海量数据的离线批量分析，因此基于Hadoop研发Hive，并开源给Apacha。

由于Hive不能实现数据实时查询交互，Hbase可提供实时在线查询能力，因此Hive和Hbase形成了良性互补。Hbase因为其海量数据存储、水平扩展、批量数据处理等优点，也得到了广泛应用。

Pig与HIVE工具类似，都可以用类sql语言对数据进行处理。但是他们应用场景有区别，Pig用于数据仓库数据的ETL，HIVE用于数仓数据分析。

从架构图当中，可看出Hive并没有完成数据的存储和处理，它是由HDFS完成数据存储，MR完成数据处理，其只是提供了用户查询语言的能力。Hive支持类sql语言，这种SQL称为Hivesql。用户可用Hivesql语言查询，其驱动可将Hivesql语言转换成MR任务，完成数据处理。

Hive的访问接口

CLI：是hive提供的命令行工具

HWI：是Hive的web访问接口

JDBC/ODBC：是两种的标准的应用程序编程访问接口

Thrift Server：提供异构语言，进行远程RPC调用Hive的能力。

因此Hiv具备丰富的访问接口能力，几乎能满足各种开发应用场景需求。

Driver

是HIVE比较核心的驱动模块，包含编译器、优化器、执行器，职责为把用户输入的Hivesql转换成MR数据处理任务

Metastore

是HIVE的元数据存储模块，数据的访问和查找，必须要先访问元数据。Hive中的元数据一般使用单独的关系型数据库存储，常用的是Mysql，为了确保高可用，Mysql元数据库还需主备部署。

架构图上面Karmasphere、Hue、Qubole也是访问HIVE的工具，其中Qubole可远程访问HIVE，相当于HIVE作为一种公有云服务，用户可通过互联网访问Hive服务。

Hive在使用过程中出现了一些不稳定问题，由此发展出了Hive HA机制，

指定数据存放位置，如果没有指定，就会在hdfs的默认位置建立表文件。

Hive 没有专门的数据存储格式，也没有为数据建立索引，用户可以非常自由的组织 Hive 中的表，只需要在创建表的时候告诉 Hive 数据中的列分隔符和行分隔符，Hive 就可以解析数据。

Hive 中所有的数据都存储在 HDFS 中，Hive 中包含以下数据模型：表(Table)，外部表(External Table)，分区(Partition)，桶(Bucket)。

扩展资料：

Hive中的表和数据库中的表在概念上相似。 每个表在Hive中都有一个对应的目录来存储数据。

例如，一个表pvs，其在HDFS中的路径为：/ wh / pvs，其中wh是在 hive-sitexml 中由 ${hivemetastorewarehousedir} 指定的数据仓库的目录，所有表数据（ 不包括外部表）存储在此目录中。

Partition 对应于数据库中的 Partition 列的密集索引，但是Hive中的Partition的组织方式与数据库中的完全不同。 在Hive中，表中的Partition与表下的目录相对应，所有Partition的数据都存储在相应的目录中。

一张Hive计算完成后，开发者会希望知道计算结果是否符合预期，比如是否有脏数据，是否数据量符合预期。这里就有两个问题，一个是校验什么，另一个是怎么校验。

Hive表的校验自然是跑SQL最方便，每当Hive表更新完要执行SQL校验，需要考虑两个问题

基于上述考虑，就要选择既省资源，又快的计算引擎，MapReduce可直接排除，备选方案是Spark SQL和Presto。

回过头看校验要执行的SQL，大部分是简单SQL，例如count(), min/max等，Presto在这种简单查询展示出了非常优异的性能，无论消耗资源，还是执行时间都很好。实际测试中，一张2亿行的表查询最新的总行数，执行select count() from table_name，只消耗了24 CPU-Second，执行时长也是2秒左右，消耗的资源和运行时长都可忽略不计。Presto跑的快的原因有很多，不用去yarn上申请资源，对orc文件查询做了很多优化，简单查询会直接基于orc的meta做计算，具体原因就不在赘述。

相同的SQL，Spark SQL一般的执行时间都要多很多，消耗的资源也会更多。不过两着对资源的计算方法肯定是不一样的，所以不能完全保证Presto更省资源，此处没有严格考证。

还有一些复杂的SQL，比如大表的字段唯一性校验，Presto很容易出现内存不足的异常，这时候可以考虑切换到Spark SQL来执行，至少保证能运行成功。

我们记录了每个枚举值，在表中出现的次数，每天记录一个值，久而久之可以形成变化趋势，可以发现某些业务细节的波动，发现异常的用户行为。

还尝试了对关键业务指标做了统计值校验，比如N个商品销量的最大最小、中位数、90%位数、平均数、标准差等，同样是每天采集并形成变化趋势，可以发现异常业务情况，Presto自带了这些算法。

在数仓小组内部，给重要表加上规则，再也不用担心报表出现重大问题，而一无所知。

功能上线后有冷启动的问题，用户不了解，也不能感知产品价值，所以很少有用户主动配置。于是我们通过默认的表级行数波动校验，采集每次表更新完的最新行数，发现异常波动，帮助用户发现问题，逐渐吸引用户使用。偶尔还会有用户惊叹，这么隐蔽的问题也能被发现，这就体现了业务监控的价值。随后我们通过培训、开发者访谈等方式，逐步推广。

后续有不少开发者，纯粹为了执行校验规则，发现业务异常数据，而把业务数据导入Hive中。也有DBA来查看采集到的数据量波动，来观察DB的数据量增长情况。

数据质量是个很大话题，除了数据准确性，至少还包括数据产出及时性、表间的数据一致性，用户甚至会把任何的数据看不懂都认为是数据质量问题，有些可能只是理解上的偏差。给Hive表配置了数据质量校验规则，只是一定程度保证了准确性，要真正解决数据质量问题，还需要更多技术和规范的努力。

首先要确定您所说的大数据是怎样的数据，目前一般的大数据可以有两种做法：

1、对于关系型的大数据，用EMC的greenplum，这个数据库属于MPP，对于OLAP类型的大数据分析运算，有很多的项目在用这个；

2、对于非关系型的大数据，行业的事实标准的hadoop，其实hadoop是一个架构，包括map-reduce，hive，hbase，pig，zookeeper等等，不过hadoop是做离弦的大数据分析，数据往往要计算几天才能得到结果；如果要做实时的大数据分析，就要用到Storm。

您可以百度一下，现在这方面的资料非常多。

1查询语言不同：hive是hql语言，mysql是sql语句；

2数据存储位置不同：hive是把数据存储在hdfs上，而mysql数据是存储在自己的系统中；

3数据格式：hive数据格式可以用户自定义，mysql有自己的系统定义格式；

4数据更新：hive不支持数据更新，只可以读，不可以写，而sql支持数据更新；

5索引：hive没有索引，因此查询数据的时候是通过mapreduce很暴力的把数据都查询一遍，也造成了hive查询数据速度很慢的原因，而mysql有索引；

6延迟性：hive延迟性高，原因就是上边一点所说的，而mysql延迟性低；

7数据规模：hive存储的数据量超级大，而mysql只是存储一些少量的业务数据；

8底层执行原理：hive底层是用的mapreduce，而mysql是excutor执行器；

以上就是关于怎样查看hive建的外部表的数据库全部的内容，包括:怎样查看hive建的外部表的数据库、程序中的Hive具体是干什么用的呢、hive中创建外部分区表使用location是指定数据存放位置还是指数据来源等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！