2022农行研发中心实习记录

Hadoop

Hadoop基本概念

Hadoop是一个由Apache基金会所开发的分布式系统基础架构，是用Java语言开发的一个开源分布式计算平台，适合大数据的分布式存储和计算平台。Hadoop是目前比较常见的大数据支撑性平台，Hadoop平台提供了分布式存储（HDFS）、分布式计算（MapReduce）、任务调度（YARN）、对象存储（Ozone）和组件支撑服务（Common）。

Hadoop的框架最核心的设计就是：HDFS和MapReduce。HDFS为海量的数据提供了存储，则MapReduce为海量的数据提供了计算。把HDFS理解为一个分布式的，有冗余备份的，可以动态扩展的用来存储大规模数据的大硬盘。 把MapReduce理解成为一个计算引擎，按照MapReduce的规则编写Map计算/Reduce计算的程序，可以完成计算任务。

HDFS是Hadoop应用用到的一个最主要的分布式存储系统。一个HDFS集群主要由一个NameNode和很多个Datanode组成：Namenode管理文件系统的元数据，而Datanode存储了实际的数据。基本上，客户端联系Namenode以获取文件的元数据或修饰属性，而真正的文件I/O操作是直接和Datanode进行交互的。下面的是HDFS的架构图。

详细的HDFS架构图如下。 

Hadoop用途

大数据存储：分布式存储

日志处理：擅长日志分析

ETL:数据抽取到oracle、mysql、DB2、mongdb及主流数据库

机器学习: 比如Apache Mahout项目

搜索引擎:Hadoop + lucene实现

数据挖掘：目前比较流行的广告推荐，个性化广告推荐

Hadoop是专为离线和大规模数据分析而设计的，并不适合对几个记录随机读写的在线事务处理模式。

 

湖仓一体

湖仓一体是一种新型开放式架构，将数据湖和数据仓库的优势充分结合，它构建在数据湖低成本的数据存储架构之上，又继承了数据仓库的数据处理和管理功能，打通数据湖和数据仓库两套体系，让数据和计算在湖和仓之间自由流动。作为新一代大数据技术架构，将逐渐取代单一数据湖和数据仓库架构。

数据仓
在计算机领域，数据仓库（英语：data warehouse，也称为企业数据仓库）是用于报告和数据分析的系统，被认为是商业智能的核心组件。数据仓库是来自一个或多个不同源的集成数据的中央存储库。数据仓库将当前和历史数据存储在一起，以利各种分析方法如在线分析处理(OLAP)、数据挖掘(Data Mining)，帮助决策者能快速从大量数据中，分析出有价值的信息，帮助建构商业智能(BI)。

数据集市
每个部门自身也有对业务数据进行处理分析统计的需求，但不涉及到和其他数据，不希望在数据量大的数据仓库进行操作（因为操作慢，而且可能影响到其他人处理数据），所以建立一个新的存储系统，把数据仓库里关联自己的数据存储到这个系统，本质上算是数据仓库的一个子集。这个系统叫做数据集市。

数据湖
随着当前大量信息化发展和电子设备产品普及，产生大量的照片、视频、文档等非结构化数据，人们也想通过大数据技术找到这些数据的关系，所以设计了一个比数据仓库还要大的系统，可以把非结构化和结构化数据共同存储和做一些处理，这个系统叫做数据湖。

Hive 

hive是一个构建在Hadoop上的数据仓库工具(框架)。可以将结构化的数据文件映射成一张数据表，并可以使用类sql的方式来对这样的数据文件进行读，写以及管理（包括元数据）。这套HIVE SQL 简称HQL。hive的执行引擎可以是MR、spark、tez。

Hive的本质是将HQL转换成MapReduce任务，完成整个数据的分析查询，减少编写MapReduce的复杂度。

Gbase

平台采用南大通用GBase 8a MPP Cluster分布式并行数据库集群，GBase 8a MPP Cluster采用MPP + Shared Nothing 的分布式联邦架构，节点间通过 TCP/IP 网络进行通信，每个节点采用本地磁盘来存储数据。实现非对称部署，分布式管理集群和分布式调度集群部署在coordinator集群。分布式存储集群部署在data集群。系统中的每一个节点都是相对独立的、自给的，整个系统中不存在单点瓶颈，具有非常强的扩展性。

农业银行大数据平台采用南大通用GBase 8a MPP Cluster+Hadoop混搭架构建设。

Prsesto

开源的分布式SQL查询引擎，适用于交互式分析查询。本身并不存储数据，但是可以接入多种数据源，并且支持跨数据源的级联查询只有分析计算功能，没有存储功能。Presto可以对多个数据源的数据进行查询处理，包括Hive、RDBMS（Mysql、Oracle、Tidb等）、Kafka、MongoDB、Redis等。Presto是一个低延迟高并发的内存计算引擎，相比Hive，执行效率要高很多（为什么比Hive高，原理是什么）。

 

• Coordinator
  Coordinator负责解析语句、规划查询和管理Presto工作节点的服务器。它是Presto的“大脑”，也是客户端连接以提交执行语句的节点。每个Presto进程都必须有一个Coordinator和一个或多个Worker。Coordinator节点会一直跟踪着每个Worker节点的状态和协调查询操作的执行。
• Worker
  Worker负责执行任务和处理数据。Worker节点从connector处获取数据并相互交换中间数据。Coordinator负责从Worker那里获取结果并将最终结果返回给客户端。
• Connector
  Presto以插件形式对数据存储层进行了抽象，它叫做connector。connector用于让Presto适配Hive或关系性数据库等不同的数据源。Presto包含多个内置connector：用于JMX的connector、提供对内置系统表的访问的系统connector、Hive connector和设计用于提供TPC-H基准数据的TPCH connector。
• discovery service
  用于协调Coordinator和Worker之间的服务

Presto如何支持联合查询

Presto的不同数据源联合查询的实现：通过提供Connector机制，Presto实现了完全插件化的数据源的元数据获取、注册、数据读取，不同的数据源对于Presto来说就是不同的Connector，用户操作数据源是通过Connector来操作的，同时它本身就自带了多个可以直接使用的数据源Connector，如Hive Connector，Kafka Connector，Elasticsearch Connector，MySQL Connector。借助Connector机制，Presto可以将来自一切数据源的数据计算SQL化。

Presto的一个简单的联合查询的例子

	select  
	   t2.region as region,  
	   sum(t1.sales_unit) as sales_count   
	from  
	   hive_table as t1   
	   join  
	      hbase_table as t2   
	      on t1.uid = t2.uid   
	where  
	   t2.region in   
	   (  
	      'beijing',  
	      'shanghai'  
	   )  
	group by  
	   t2.region   
	order by  
	   sales_count desc limit 100;

这段代码的简单解析：在Presto内部，SQL被解析后生成执行计划，并将Hive和HBase的数据读取任务调度到Worker上来读取HDFS和HBase的数据，这些数据随后被传输到其他Worker上完成JOIN以及其他SQL的计算（如聚合操作），由于计算过程中的数据交换的中间存储介质都是内存，而且Presto也做了很多提高并发度的优化，整体来说，计算速度还是非常快的。）

Presto和Hive比较：Presto查询速度为何比Hive快

1. 任务执行：Hive是把一个查询转化成多个MapReduce任务，然后一个接一个执行。执行的中间结果通过对磁盘的读写来同步。然而，Presto没有使用MapReduce，它是通过一个定制的查询和执行引擎来完成的。它的所有的查询处理是在内存中，这也是它的性能很高的一个主要原因。

2. 资源调度：Presto是常驻任务，接受请求立即执行，全内存并行计算；hive需要用yarn做资源调度，接受查询需要先申请资源，启动进程，并且采用mapreduce计算模型，中间结果会经过磁盘。

PrestoDB和Trino

PrestoDB是2013年Facebook的三个核心工程师创造和开源出来的，在Facebook内部，它的应用规模是很庞大的（部署了多个集群，总节点数10000+台），这三个工程师一直想把Presto发扬光大，但是一直到了2019年，他们感觉到公司好像不怎么给力，同时期的三个开源大数据技术Spark、Flink、Kafka都已经创建了自己的商业化公司推广到家喻户晓了，如果说哪家公司在力推Presto，可能只有一家叫Teradata的小公司。无奈之下，这三位核心工程师离职加入了刚成立两年的Starburst公司，这家公司Fork了Presto的项目源码，取名为PrestoSQL，创建了自己的代码仓库和官方网站，在做商业化运营的Presto。后因为各种争端，更名PrestoSQL为Trino。

Presto源码与接口开发

Presto加载插件的过程：

Plugin加载：

Presto将支持的所有插件类型封装在一个统一的接口中：Plugin，

当Presto启动的时候从以下路径加载Plugin:(PluginManager.loadPlugins)

 

其中installedPluginsDir通过以下配置项配置：

 plugins通过以下配置项配置：

plugin.bundles配置在config.properties配置文件，默认在开发环境是各个插件模块对应的pom文件路径，用于从maven仓库加载依赖的jar包。在生产环境部署时候，通常指定插件目录即可。将每种插件依赖的三方包放在$installedPluginsDir/<pluginName>目录下，将插件的配置文件放在$PrestoHome/etc/ 路径下，pluginName 为插件的名称。但是针对不同的插件类型，配置文件放置的位置略有不同，比如：

对于名称为mysql的connector插件，其配置文件为$PrestoHome/etc/catalog/mysql.properties。因为每种插件依赖的包位于不同的路径，根据不同的类加载器加载 就可以避免包冲突问题：

 

 

 

最终处理落到方法：installPlugin(Plugin plugin)，在该方法中将所有支持的插件按照类型分别存放到不同的manager的Factories，如Connector插件存放到ConnectorManager，Event Listener存放到EventListenerManager中。所谓Factories其实就是一个内存Map，比如ConnectorManager的

private final ConcurrentMap<String, ConnectorFactory> connectorFactories = new ConcurrentHashMap<>();

和EventListenerManager的private final Map<String, EventListenerFactory> eventListenerFactories = new ConcurrentHashMap<>();

在DevelopmentPluginsProvider中的这个方法：

 

该方法调用的方法discoverPlugins和writePluginServices分别实现了插件声明的发现和写入。

Catalog加载

从Connector的加载流程，我们了解到所有的ConnectorFactory都被注册到ConnectorFactory的Map内存结构中。但真正能够使用该Connector还需要加载Catalog，所谓Catalog就是Presto的数据源类别，Presto通过如下三级结构来定义数据表：

 

比如每个mysql实例都是一个catalog，每个mysql实例都有独立的域名、端口和登录账号等信息，schema 类比每个mysql实例的数据库。因此不同的Catalog可以使用同一个 Connector，Connector实例由ConnectorFactory来创建。所有的catalog的配置文件都位于$PrestoHome/etc/catalog路径下，加载流程从StaticCatalogStore的loadCatalogs方法开始：

 

 

trino –gbase-connector

SPI ：Service Provider Interface 服务提供发现接口

SPI用于实现连接器，只要Connector实现SPI接口就可以讲Presto与外部数据连接。

 开发过程

 

只写GbaseClient，GbaseClient里有五个主要文件调用关系可以表示如下：GbaseModule是一调用Gbase这几个实现类的一个类。

 

 GbaseClient和MysqlClient几乎是一样的。

遇到的问题：

1.开发的时候，引入依赖的过程，很麻烦，整了很久，有些依赖引入不了。

2.部署的之后，连接不上数据源，hive连接不上：修改配置文件，不用xml的配置文件；连接不上hbase，提供的配置数据源连接的方法不行，怎么都不可以，后来发现hbase他们关了，我没有权限操作hbase。