2020.11.21(整合hive的metastore搭建2)

上节课刻意的在什么外界都不用的情况下，spark自己就可以玩，外界不需要准备其它的，搭建环境，jvm都不需要，只要enableHiveSupport()，就可以包含的启动一个metastore，支持我们的DDL语句，等等操作，但是这节课主要讲贴近企业级的使用，在生产环境中是不会这么去玩的，强调一点：很多人学习架构的事情会很在意项目这件事情，但是如果学大数据，不要刻意的把项目放在心上，项目是被弱化的，大数据公司不可能启动了一个项目，为你准备了500台机器，然后把数据拷给你一份，几百T的数据，过两天又要启动一个项目，再给他准备500台机器，拷贝一份数据。在大数据里，整个公司可能就一个特别大的集群，然后所有公司数据都往里面扔，有一个平台的概念。到现在来说，已经衍生出中台的概念，项目这个词要弱化想成应用，我这家公司，有全公司所有部门web项目产生的数据，基于数据可以做很多的事情，可能是指标的分析，决策，风险评估，未来规划。无论做什么事情，是基于这些数据去推演，计算，加工的 。有的人会认为，每一项是独立的项目，之前在公司做日志项目，还做过风险评估的项目，可以这么去聊，但要往业务而不是大数据方面去带，我偏向分析哪些业务场景。但是无论业务，项目，分析的指标等等的这些事情，可以用另外一个维度的词汇代替，叫做应用。我拿着这些数据有哪些应用。
从数据在一家公司是要组建特别大的平台，我们是基于数据之上有不同的需求的时候，会开发很多的应用。随着开发应用越多，中台概念在大数据里很容易感受到的。可能有的公司没有业务平台，没有技术平台，但他迫切的需要数据平台，比如这个时候有很多的基于数据的开发，那么应用每开发一个都要从原表做起么？数据重新加工，或者每一个应用诞生都是需要所有的人员匹配，从数仓到java开发，所有环节都要接入么？这样有点累。这个时候大中台，小前台（应用），应用里面包含的技术量变低，把很多的计算从应用这个级别切出来，放到平台里去，平台也不是特别素的只包含原生的调用，可塑造型的接口，而是把公司未来很多可能出现的应用功能切出来之后，放到平台里，包成一个具备访问要求特别低，可能他只懂业务，不懂技术，只是知道要做风险评估的话需要哪些数据，哪些字段，哪些画像，哪些维度的东西，整个平台上面有标签系统，有血统系统，一大堆的东西，最终一个人，面向一个网页点几下，产生一个接口，这个接口放到前端里丰富出一个界面，小前端（应用）就出现了。
这个东西太概念了。国内做数据平台，做的比较不错的公司，做展示，实现原理和业务场景，能看见实打实的中台，不需要太多的技术就能撼动整家公司的流程。并不是要替代我们，每家公司数仓这个环节该有还是得有，中台只是一个引擎，只是在应用这个层面的时候不需要再投入大量的人了。但是在核心数据层面还是需要我们这样的人，去把数仓、平台做好，把数据准备好，但是如果一家公司频繁有前端应用开发的话，如果有一个中台就是效率极高的，仅此而已。

开始讲知识：
企业怎么去用这些技术的，spark-sql这些东西，enableHiveSupport() 等于这个元数据就在我这个application的生命周期里了，别的程序再去开发的时候，可能也要去弄一个enableHiveSupport() ，它是存一份重复的，而且数据之间还不能互访很尴尬，不可能这么去玩，所以到公司要不是平台，要不是高端一点就是中台的概念。在最开始的时候也画了一个图讲解SQL的执行流程，这里再偏向于高层次的去描述一个企业的处理过程，在一家公司，所有的数据会扔到一个统一的存储层，现在学的技术有hdfs或者hbase，hive的表是可以建在hbase上的，做一个映射关联。
有存储层之后，公司所有的设备，所有的内存，CPU，叫资源层，已知的可以接入各种技术整合的是yarn，比较公立的资源层，只要实现了它的applicatioin master接口，能够和它的resource manager通信，那个技术就能和yarn整合在一起，在资源层调度。这是两个最基础的层次，也是Hadoop生态的奠基者。这两个技术是在大数据开课前期第一阶段的 ，不复习了，一定要记住：所有的数据/资产都在这个里面准备好了，上方可能有很多垂直的应用。相应的kpi的统计，日志的分析，叫做应用层/业务层，可能每个应用是一个独立的业务，也可能几个应用是一个独立的业务，这些应用层怎么去访问下面的层次，中间差了计算层和管理层。
这个管理是比较片面的，spark-sql，更偏向于元数据的管理，一家公司这么多不同的应用，做在了一个整体的管理层上，hive的metastore，如果hive的metastore不能做到横向的全局管理的话，对数据有不同的抽象的话，会很麻烦，没必要每个项目组都重复造轮子，大家就一起使用一个metastore，不过计算层可以是MR，spark，tez。

metaStore是贯穿全局的，hold住数据，hold住中间的计算，上层也可以访问它。spark是一个自己带driver（spark-sql-Driver不是core里的driver，这里更强调SQL解析的driver），并没有复用hive的driver，是完全可以独立的，只是应用了metastore。计算层里面还有hive的driver，使用自己的metastore。hive的driver底层还可以驱动spark，还可以驱动tez，MapReduce。都可以以SQL的形式，对外提供服务，都可以接受SQL的访问，基于HQL语句，但是hive的 driver 可以访问metastore，spark-sql的driver也可以访问meta store，但是向下计算的实现，hive-driver是mapreduce,spark,tez而spark-sql-Driver是spark-rdd core，这是一个逻辑拓扑图，整个推演的过程就更清楚了。
在公司会频繁的看到类似的结构，最值钱的就是hive的metastroe，因为有了它，全公司上下对元数据的管理就变得简单了，很多技术都可以在上面繁衍，比如说impala，也可以使用metastore，但是用C，C++开发的，它的计算并不是还要分层次，支持其他计算，它被制造出来就为了SQL，原生进程就在集群里，基于内存的计算方式，比spark还要快。
凸显的再重要一点，就是一定要反复练习的HQL，是一家公司技术层面 的SQL标准，在分布式大数据环境下的标准，有的人是能够完全实现它，有的人是它的子集，HQL非常完整强大，但是有一些技术能够实现，有一些技术因为计算的特征性，抛弃了一些慢的东西，有一些慢的操作就不支持了。
它的复杂度只是源于分布式的特点，主要在DDL这里，如何把公司的数据用DDL的方式管理映射起来，然后把数据还能在物理上分割、切割，比如分区分桶，查询其实函数，SQL语句这块，DQL查询这块，不趋向于某种技术。最简单的方式就是去访问hive的网站，把它所有的DDL，DML这些，语言的所有的example，用例先看一遍熟悉起来。

拓扑图理解了以后，进入物理的阶段：

到公司要有能力去策划这个事情的，有工作经验的都知道，公司很多文档，大片的这样的架构图，图有了之后，还牵扯到集群的规划，相应的所有的清单和配置一堆的东西，一步一步来的。
如果我的metastore，不是想集成在本地启动这个程序里，想推到集群里的话，集群里需要有相应的进程。最基础的层次是基础设施层，yarn和hdfs是到一家公司最先要搭建起来的，在这节课不做，就拿之前搭建的集群，一共有4台机器，namenode是前两台，datanode是234台，resourcemanager是后两台，nodemanager是234，这4台机器完成了基础设施。
下一步应该有谁？
metastore，元数据管理，元数据存储的层次，之后就可以配置hiveserver2，beeline，hive的commandline interface 这个区域是第三步：相应的driver，在这个环节的时候，有个概念，有一些不是长服务，有一些是长服务。哪些是长服务？一会儿metastore，4台里会随便挑一台启动，有了之后，下一步就是driver，拿hive自身来说有hiveserver2，来访问metastore，hiveserver2要一直运行，它就是长服务，namenode，datanode，resourcemanager这些都是长服务，整个集群一启动就一直在那里运行，等着别人使用它。但有些东西它是短服务，比如hive自己，敲hive+回车，hive的commandline interface这就是短服务，写完了结束了。driver驱动的计算层，如果driver驱动的是mapReduce，每一个作业的提交都是一个短服务临时拉起的，并不是在那里持久运行的。短服务暴露一个问题，有启动和关闭的过程，启动的时候资源是否够，相对应的spark里面，也可以是短服务，只有一个metastore在集群里，剩下的什么东西都没有，因为可以令spark on yarn，集群里只需要有yarn就可以了，提交的时候，spark计算程序是短服务，spark application是短服务，计算结束所有资源收回，driver，execute都没有了，宏观上来说spark application是短服务，什么时候计算，什么时候启动，计算完就结束。但是，再较真一下，spark的程序，application可以随着集群启动，如果我让在集群启动完之后，就立刻启动了一个spark application，但是啥事都不做在那里等着，它也会申请一批的execute，进程一直存在，不碰它的话也不消失，但是资源已经申请到位了，进程已经启动完了。这时候如果有人给它发送了一个SQL，它快速把SQL转化成rdd，变成task任务，序列化反序列化发出去，然后变成task线程来执行，就减少了很多申请资源，driver启动，分配，回调的过程，所有spark是一个幽灵，比mapreduce更好一些。

实际操作：
把meta store和hive的使用支起来，最终看到的是整家公司只有一个metastore，所有先不碰spark，把整个公司的metastore和hive数仓这块的使用，接口和所有能力支起来。回到集群中：

1.启动hive
第一台：hive使用2.3.4的版本

cd /opt/hive-2.3.4
cd conf    //看配置项

现在说的hive自己，没有spark什么事情

vi hive-site.xml

如果想把一个meta store跑起来，这个进程在启动的时候，需要哪些配置项
1.一定要告诉他一个warehourse，就是它默认库default库保存的位置，在哪个目录下创建，一般会指向hdfs某一个目录，这是第一个配置项

<property>
    <name>hive.metastore.warehouse.dir</name>
    <value>/hive/warehouse</value>
</property>
<property>

2.剩下的配置项，因为 它是元数据管理，元数据需要持久化，所有下面是一系列jdbc连接MySQL这块的。它会拿MySQL做持久层，所有下面这些配置项都是围绕MySQL持久化连接信息的，就这么两个信息就可以让metastore启动起来了，因为metastore不做SQL解析，不做其他事情，只是能知道未来的数据存在哪个目录能做映射，只需要元数据能持久化到哪个数据库里，仅此而已。

<property>
    <name>javax.jdo.option.ConnectionURL</name>
    <value>jdbc:mysql://node01:3306/hive?createDatabaseIfNotExist=true</value>
</property>