Hive

开发中，经常进行模糊查询或者进行截取字符串进行模糊匹配，常用的就是substr函数或者substring函数。 使用语法: substr(string A, int start),substring(string A, int start) 两者用法一样,两个参数 返回值: string 说明：返回字符串A从start位置到结尾的字符串 举例： hive> select substr('abcde',3) fromlxw_dual; cde hive> select substr('abcde',-1) from lxw_dual; （和ORACLE相同，负数从最后一位开始截取） e hive> select substr('abcde',1,2) 和selectsubstr('abcde',0,2)结果一样ab，默认都是从第一位开始取. 语法: substr(string A, int start, int len),substring(string A, intstart, int len)，用法一样，三个参数 返回值: string 说明：返回字符串A从start位置开始，长度为len的字符串 举例： hive> select substr('abcde',3,2) fromlxw_dual; cd hive>select substring('abcde',-2,2)

我们在第 02 课时中使用 Flink Table & SQL 的 API 实现了最简单的 WordCount 程序。在这一课时中，将分别从 Flink Table & SQL 的背景和编程模型、常见的 API、算子和内置函数等对 Flink Table & SQL 做一个详细的讲解和概括，最后模拟了一个实际业务场景使用 Flink Table & SQL 开发。 Flink Table & SQL 概述 背景 我们在前面的课时中讲过 Flink 的分层模型，Flink 自身提供了不同级别的抽象来支持我们开发流式或者批量处理程序，下图描述了 Flink 支持的 4 种不同级别的抽象。 Table API 和 SQL 处于最顶端，是 Flink 提供的高级 API 操作。Flink SQL 是 Flink 实时计算为简化计算模型，降低用户使用实时计算门槛而设计的一套符合标准 SQL 语义的开发语言。 我们在第 04 课时中提到过，Flink 在编程模型上提供了 DataStream 和 DataSet 两套 API，并没有做到事实上的批流统一，因为用户和开发者还是开发了两套代码。正是因为 Flink Table & SQL 的加入，可以说 Flink 在某种程度上做到了事实上的批流一体。 原理 你之前可能都了解过 Hive，在离线计算场景下 Hive 几乎扛起了离线数据处理的半壁江山

大数据的测试工作： 1、模块的单独测试 2、模块间的联调测试 3、系统的性能测试：内存泄露、磁盘占用、计算效率 4、数据验证（核心） 下面对各个模块的测试工作进行单独讲解。 0. 功能测试 1. 性能测试 2. 自动化测试 3. 文档评审 4. 脚本开发 一、后台数据处理端 后端的测试重点，主要集中在数据的采集处理、标签计算效率、异常数据排查（功能），测试脚本编写（HiveQL）、自动化脚本编写（造数据、数据字段检查等） 　　1.数据的采集处理（Extract-Transform-Load） 　　　　ETL：即将数据从源系统加载到数据仓库的过程。源系统包括：数据文件（excel、log等）、RDD数据库、非RDD数据库等； 　　　　extract：从源系统提取需求数据。 　　　　transform：清洗数据（数据格式转化、异常数据处理等）。 　　　　Load：将清洗的数据加载至数据仓库。 　　　　 　　　　ETL测试：即确保根据需求将源系统的数据经过处理后加载到目标的数据是准确的。即源和目的数据之间转化过程中的数据验证。 　　　　测试类型 　　　 　　　　测试场景 　　　　 　　　　券商等金融机构，其用户每天都会产生大量的交易数据，这部分数据最初都会存储在客户的关系型数据库中（oracle），因此后台每天需要先进行数据采集，将数据采集至Hadoop的hdfs系统；数据采集过后

Hive SQL的各种优化方法基本 都和数据倾斜密切相关。 　　Hive的优化分为join相关的优化和join无关的优化，从项目的实际来说，join相关的优化占了Hive优化的大部分内容，而join相关的优化又分为mapjoin可以解决的join优化和mapjoin无法解决的join优化。 1、Hive优化(这是重点) 在实际的Hive SQL开发的过程中，Hive SQL 性能的问题上实际上只有一小部分和数据倾斜有关，很多时候，Hive SQL运行慢是由于开发人员对于使用的数据了解不够以及一些不良的习惯引起的。 开发人员需要确定以下几点： 1、指标是否一定要通过明细表得到,可否通过其他量级比较小的表得到,重复代码是否可以使用中间表来替代 2、开发过程中是否真的需要扫描那么多分区,举个例子你要做一张月维度表的报表,月维度数据很大,如果在测试demo中使用where月作为限制条件是不是要花很多时间,仅仅从调通代码测试样本数据的角度出发,使用where日条件量级比较小的限制条件会不会更好呢?(这个是重点,where条件的使用) 3、尽量不要使用select * from your_table这样的方式，用到哪些列就指定哪些列，另外WHERE条件中尽量添加过滤条件，以去掉无关的行，从而减少整个MapReduce任务需要处理、分发的数据量。 4、输入文件不要是大量的小文件

Hive 总结 总结人：连志鹏 2020.04.29 一、HiveJDBC客户端基本操作 1.1 HvieJDBC的登入与退出 -- 方式一：使用beeline方式 访问方式：beeline - u jdbc:hive2: //hadooop102:10000 -n atguigu 退出方式：！quit 、 ! exit 、 ctrl + c -- 方式二： 使用hive的方式 访问方式：hive 退出方式：quit； exit ； 1.2 Hive常用的交互命令 “-e” 不进入hive的交互窗口执行sql语句** “-f” 执行脚本中sql语句** 1.3 Hive数据类型 基本数据类型 Hive数据类型 Java数据类型 长度 例子 TINYINT byte 1byte有符号整数 20 SMALINT short 2byte有符号整数 20 INT int 4byte有符号整数 20 BIGINT long 8byte有符号整数 20 BOOLEAN boolean 布尔类型，true或者false TRUE FALSE FLOAT float 单精度浮点数 3.14159 DOUBLE double 双精度浮点数 3.14159 STRING string 字符系列。可以指定字符集。可以使用单引号或者双引号。 ‘now is the time’ “for all good

作者介绍 温卫斌， 就职于中国民生银行信息科技部，目前负责分布式技术平台设计与研发，主要关注分布式数据相关领域。 前言 最近几年做分布式项目，很多工作是关于OLTP（联机交易系统）场景下数据分布式架构的，疫情期间正好整理下这方面的一些设计与实践。为避免篇幅太长，本文分为设计篇和技术篇，设计篇主要偏向数据拆分的理论与方法，还有一些原则与经验。技术篇则主要会介绍分库分表中间件的设计与使用实践，以及如何构建一个完整的分布式数据服务平台。 一般来说做分布式架构，应用层是好做分布式的，因为往往都是无状态的（或者通过将数据转移到DB、缓存、MQ等方式来实现无状态），只需在流量入口、即在应用前面加一个负载均衡即可（例如Nginx、HAProxy、F5），这在大单体架构也多已具备。所以一般我们说分布式架构，一个重要的部分就是要做数据的分布式化。 传统单体集中式架构 数据的分布式不像应用那么简单，因为各节点的数据可能是不一样的，需要进行路由、解决多副本一致性，甚至多写冲突等问题。虽然实现方案复杂，不过数据的分布式本质上就两种朴素思想：复制和分片。复制技术在传统关系数据库中也很常见，主要用来做主备、双活，例如 MySQL Replication、Oracle DataGuard等。分片在数据库里也有对应产品。例如 MySQL Fabric、Oracle Sharding，但与复制相比

文章目录 前言 Hadoop ViewFs的问题痛点 Hadoop ViewFs的重载hdfs schema方式 ViewFs的mount point中心化管理问题 引用 前言 在大数据时代，随着业务的迅速扩张，很多大公司往往内部会有多cluster模式来支撑其内部的数据体量。在这期间就会涉及到一个多集群管理协调的问题，比如典型的HDFS的多集群管理。社区在早期实现的ViewFs以及后来的Router-based的功能在一定程度上能优化这块的管理。但是上述2个方案还不能完全cover住HDFS的多cluster管理的痛点问题，比如在一些用户写死在code中的地址，如何能做到纹丝不动的适配到viewfs多集群模式？本文我们来谈论谈论这个话题以及目前社区对此的解决方案。 Hadoop ViewFs的问题痛点 Hadoop ViewFs功能实现的时间可以说是非常早的了，当时最初解决的问题是在client端构建一个视图逻辑上统一的文件系统，ViewFs下不同的路径实际指向的具体的物理cluster地址。简单来说，就是我们在client端添加了一个类似mount point的映射表mapping关系。 因为是基于client side的改动，因此这会导致一个很容易出现的问题，ViewFs的重新部署更新会变得极为的麻烦，在这里面至少会涉及到如下相关服务的变更：

lead函数用于提取当前行前某行的数据 lag函数用于提取当前行后某行的数据 语法如下： lead(expression,offset,default) over(partition by ... order by ...) lag(expression,offset,default) over(partition by ... order by ... ) 例如提取前一周和后一周的数据，如下： select 　　year,week,sale, 　　lead(sale,1,NULL) over(--前一周sale partition by product,country,region order by year,week) lead_week_sale, 　　lag(sale,1,NULL) over(--后一周sale partition by product,country,region order by year,week) lag_week_sale from sales_fact a where a.country='country1' and a.product='product1' and region='region1' order by product,country,year,week 实例2： SELECT　　 　　created_at create_time

在大数据领域，hive 的位置非常重要，排名前三的大数据工具为 spark、hive、kafka 什么是hive 在大数据领域有 3 种需求场景：传输、存储、计算； hive 是一个处理海量的结构化数据的 计算 引擎； hive 是基于 hadoop 的一个数据仓库工具，他将结构化的数据 数据文件 映射为一张表，并且提供了类 sql 的查询功能； hive 提供的 sql 叫 HQL，本质是把 HQL 转换成 mapreduce； 认识 hive 需要搞清楚以下几点： 1. hive 虽然是大数据工具，但是 hive 并非分布式的，它只安装在一台机器上，当然你可以在多台机器上都安装 hive，但彼此之间没有联系； 2. 我们可以把 hive 看做 hadoop 的客户端，通过使用 hive 来使用 hadoop； 3. hive 是个计算引擎，他没有存储功能，虽然有一张表，但是我们可以认为那是一张虚拟表，表的数据存储在 hdfs，表的元数据存在 mysql 等数据库，hive 查询时通过元数据找到数据在 hdfs 中的位置，并启动 mapreduce 进行计算； hive 的工作逻辑 1. hive 的数据存储在 hdfs 2. hive 的计算通过 hadoop 完成 hive 的架构 Client：客户端，需要 jdbc 数据库； Metastore： 元数据 ，存储在

今年6月毕业，来到公司前前后后各种事情折腾下来，8月中旬才入职。本以为终于可以静下心来研究技术了，但是又把我分配到了一个几乎不做技术的解决方案部门，导致现在写代码的时间都几乎没有了，所以只能在每天下班后留在公司研究一下自己喜欢的技术，搞得特别晚才回，身心俱疲。 唉~以前天天写代码时觉得苦逼，现在没得代码写了，反而更累了。。。 言归正传，这次准备利用空余的时间，好好研究下大数据相关的技术，也算是弥补下自己的技术短板吧。这一个系列的文章是我从一个大数据小白开始学习的过程，不知道我究竟能学到哪个程度，也不清楚自己是否会半途而废，但是希望能尽量坚持下去，也希望看到这一系列博客的读者能更我一起努力，一起进步！ 首先我们来看一下spark究竟是什么。相信很多读者跟我一样，听说过hadoop，也知道spark，更知道spark是现在最火的大数据技术，所以一直有一个疑问：spark是不是替代能够hadoop的下一代大数据技术？答案是：不是！ 首先我们看看spark的官网介绍：Apache Spark is a fast and general-purpose cluster computing system. It provides high-level APIs in Java, Scala, Python and R, and an optimized engine that supports