weixin_42435657的博客

DMLMerge。

hive数据在HDFS上的存储位置。hiveserver2操作日志位置。TODO:操作日志干嘛用的？hive下spark相关配置。hive thrift服务。命令行显示当前数据库。

动态分区(可通过这个语句查看：set hive.exec.dynamic.partition;(如果自动分区数大于这个参数，将会报错)禁用hive矢量执行：不禁用可能会到来报错：java.lang.ArrayIndexOutOfBoundsException: 28配置hive支持update、delete操作日志相关。

参考文档：https://www.docs4dev.com/docs/zh/apache-hive/3.1.1/reference/Materialized_views.html。开发一个类，实现org.apache.hive.service.auth.PasswdAuthenticationProvider接口，并重写Authenticate方法。在配置文件中开启自定义权限校验，并配置hive.server2.custom.authentication.clas指向自定义的权限校验类。

Hive的优缺点：优点：o操作接口采用类SQL语法，提供快速开发的能力（简单、容易上手）。o避免了去写MapReduce，减少开发人员的学习成本。oHive的执行延迟比较高，因此Hive常用于数据分析，对实时性要求不高的场合。oHive优势在于处理大数据，对于处理小数据没有优势，因为Hive的执行延迟比较高。oHive支持用户自定义函数，用户可以根据自己的需求来实现自己的函数。缺点：oHive的HQL表达能力有限迭代式算法无法表达。

将test 表的 S1 列的读权限授权给role_name （TABLE也可以不写）#回收role_name对数据库db_name的SELECT 权限。#将role_name 权限给予user_group用户组。#回收role_name对表test的SELECT 权限。#查看role_name 在数据库db_name中权限。#将role_name 权限给予user_name用户。#查看role_name 在表test中的权限。#查看某个用户组下所有赋予的role权限。#查看某个role下的权限信息。

表现：建了一个ORC表，插入一行数据，添加一列，修改数据，最后再查询数据。如果所在机器的hive-site.xml上没有上面面的配置，那么启动hiveserver2的时候就不会去连接metastore，这个时候hiveserver2进程内部会自己维护metastore相关的功能。也就是说：在没有配置metastore的thrift链接的时候，hiveserver2自己就会充当metastore的角色，自己完成与元数据的交互。2.ORC存储格式的表，在新增字段时，会有问题。4. sql开发注意事项。

数据倾斜优化hive的大部分优化都跟数据倾斜有关系，分为join相关、join不相关两种方式数据倾斜在代码上可能出现的地方：1、做join的时候select …卖家的二八原则，可能有些卖家有成百上千万的买家，在按卖家ID做关联的时候，会涉及到shuffle，就会出现数据倾斜2、做group by的时候hive优化的几点思路：是否可以从dw层获取数据，而不是自行到ods层加工考虑是否真的需要扫描那么多分区，计算周指标就不需要去扫描一年的分区。

该案例演绎的是用子查询代替count（distinct），避免因数据倾斜导致的性能问题。o分解count(distinct)的SQL优化（使用子查询）通过SQL-hint语法，实现对计算引擎执行过程的干预；通过数据库开放的一些配置开关，实现对计算引擎的干预。通过改写SQL，实现对计算引擎执行过程的干预；o使用grouping sets代替union。–统计不同年龄段，考取的不同分数个数。

sds 保存文件存储的基本信息，如输入格式、是否压缩等 OUTPUT_FORMAT varchar(4000) 文件输出格式 org.apache.hadoop.hive.ql.io.HiveIgnoreKeyTextOutputFormat。partitions 表分区的基本信息，比如分区名 year=2019/month=07/day=22 PART_NAME varchar(767) 分区名 hour=15/last_msisdn=0。

Hive中指定了sort by，那么在每个reducer端都会做排序，也就是说保证了局部有序好处是：执行了局部排序之后可以为接下去的全局排序提高不少的效率（其实就是做一次归并排序就可以做到全局排序了。ORDER BY 会对输入做全局排序，因此只有一个 Reduce（多个 Reduce 无法保证全局有序）会导致当输入规模较大时，需要较长的计算时间，cluster by的功能就是distribute by和sort by相结合（根据指定字段输出到不同文件里，然后对各个文件里的数据排序）

修改表说明注释字符集。– 修改分区注释字符集。– 修改表注释字符集。– 修改字段注释字符集。

ShowDescribe在hive中DATABASE|SCHEMA是等效的，可以相互替代oRESTRICT: 默认值，在数据库中存在表的时候会失败，但如果是手动复制到该数据库下的，因为元数据中并没有相关信息，所以照样可以删除成功oCASCADE: 不管是否库中有表，全部删除。

堆内存溢出可以在yarn-site.xml中设置相关参数##允许最大MapReduce字节数2048##调度器 允许最大调度内存是2个G2048##虚拟内存是所占物理内存的倍数 2048 * 2.12.1。

(1)表的定位存的是所有金牌用户那么就应该是全量表：app_api_gold_user_info_df。(2)如果定位是所有用户的金牌信息，那么app_api_user_gold_info_df (3)如果表定位是所有用户存在金牌信息的，那么app_api_user_has_gold_info_di 一般也不这么设计 (4)如果定位是金牌用户的金牌变更信息，那么app_api_gold_user_change_detail_di。o当天更新表的所需要包含的所有对象的所有数据，则为全量。

知识点：执行顺序上，group by 执行后 having，之后就会执行 distribute by 或者 cluster by。核心思路：将能合并的数据分组，而分组的关键是找到分组的起点（在这里是起始时间），之后判断当前数据是否要和上一条数据合并。– 当前数据：判断是否为新的起点，如果时间上有断点，那就是新的起点，否则不需要。因为要合并的那条数据是0，结合起点标识，就可以将数据分组。需求描述：将一组切片数据，按时间顺序存到array中，并给到下游消费。需求：将相同的多个时间段合并成一条数据。

对于一个公司或者组织来说，使用数据的用户可能成百上千，如何降低大家对于数据使用的沟通成本、如何通过规范大家的行为来降低使用数据的风险，这些问题是必须加以考虑的。作为新的大数据架构，数据湖采集和存储一切数据，既包含结构化的数据也包含非结构化（如语音、视频等）和半结构化的数据（如JSON 和XML 等），既包含原始数据又包含经过处理的、集成的数据。数据湖鼓励分析师和数据科学家对原始数据在分析沙箱中进行探索、研究、实验，对于有价值的数据，再和数据开发、管理团队一起将其转为更容易操作和使用的数据。

beeline -n xxx 指定用户之后，默认也会把任务提交到yarn的队列：root.users.xxx。

第一，选择性能评估项及各自目标，常见的评估性能指标有程序的时延和吞吐量；首先，所有调优都是相对的（要求3小时，实际2小时，看似慢也能满足要求）第二，如果系统是由多个组件和服务构成，需要分组件和服务定义性能目标；第五，优化产生性能瓶颈的程序或者系统；第三，明确当前环境下各个组件的性能；第四，分析定位性能瓶颈；第六，性能监控和告警。

分为两步：第一步，理解基本的MR 过程和原理，第二步，在日常编写SQL 的过程中，尝试将SQL拆解成计算引擎对应的算子， 拆解完和执行计划进行比对，还要和实际执行过程的算子比对，并思考自己拆解完后的算子与通过explain方式得到的算子的执行计划的异同。学习Hive 及其关联的几个组件之间的基本原理和各个组件之间的关系，并不断在练习中思考这些基本原理和性能的关系， 建立一个全链路的性能全局观。失败的优化：没有使用MULTI-TABLE-INSERT的写法，直接拆成多个简单sql，如下所示。

求出同一个商品在2021年和2022年中同一个月的售卖情况对比。从订单明细表（order_detail）中。订单明细表：order_detail。

通过商品信息表（sku_info）订单信息表（order_info）订单明细表（order_detail）分析如果有一个用户成功下单两个及两个以上的购买成功的手机订单（购买商品为xiaomi 10，apple 12，小米13）那么输出这个用户的id及第一次成功购买手机的日期和第二次成功购买手机的日期，以及购买手机成功的次数。

从商品价格变更明细表（sku_price_modify_detail），得到最近一次价格的涨幅情况，并按照涨幅升序排序。

订单明细表：order_detail。

假设今天是数据中所有日期的最大值，从用户登录明细表中的用户登录时间给各用户分级，求出各等级用户的人数。用户登录明细表：user_login_detail。流失用户：近30天未活跃但是在30天前活跃。沉睡用户：近7天未活跃但是在7天前活跃。忠实用户：近7天活跃且非新用户。新晋用户：近7天新增。

用户每天签到可以领1金币，并可以累计签到天数，连续签到的第3、7天分别可以额外领2和6金币。每连续签到7天重新累积签到天数。从用户登录明细表中求出每个用户金币总数，并按照金币总数倒序排序。

动销率定义为品类商品中一段时间内有销量的商品占当前已上架总商品数的比例（有销量的商品/已上架总商品数）。滞销率定义为品类商品中一段时间内没有销量的商品占当前已上架总商品数的比例。（没有销量的商品 / 已上架总商品数）。只要当天任一店铺有任何商品的销量就输出该天的结果从订单明细表（order_detail）和商品信息表（sku_info）表中求出国庆7天每天每个品类的商品的动销率和滞销率。

根据用户登录明细表（user_login_detail），求出平台同时在线最多的人数。

现有各直播间的用户访问记录表（live_events）如下，表中每行数据表达的信息为，一个用户何时进入了一个直播间，又在何时离开了该直播间。

现有页面浏览记录表（page_view_events）如下，表中有每个用户的每次页面访问记录。规定若同一用户的相邻两次访问记录时间间隔小于60s，则认为两次浏览记录属于同一会话。

现要求统计各用户最长的连续登录天数，间断一天也算作连续，例如：一个用户在1,3,5,6登录，则视为连续6天登录。现有各用户的登录记录表（login_events）如下，表中每行数据表达的信息是一个用户何时登录了平台。

现有各品牌优惠周期表（promotion_info）如下，其记录了每个品牌的每个优惠活动的周期，其中同一品牌的不同优惠活动的周期可能会有交叉。现要求统计每个品牌的优惠总天数，若某个品牌在同一天有多个优惠活动，则只按一天计算。

近90天指包含最大日期（以订单详情表(order_detail)中最后的日期）在内的近90天。结果中复购率保留2位小数，并按复购率倒序、商品ID升序排序。注：复购率指用户在一段时间内对某商品的重复购买比例，复购率越大，则反映出消费者对品牌的忠诚度就越高，也叫回头率。此处我们定义：某商品复购率 = 近90天内购买它至少两次的人数 ÷ 购买它的总人数。现有电商订单表（order_detail）如下。

注：出勤率指用户看直播时间超过40分钟，求出每个课程的出勤率（结果保留两位小数）。现有用户出勤表（user_login）如下。课程报名表（course_apply）如下。

注：不同时段定义：早高峰 [07:00:00 , 09:00:00)、工作时间 [09:00:00 , 17:00:00）、晚高峰 [17:00:00 ,20:00:00）、休息时间 [20:00:00 , 07:00:00） 时间区间左闭右开（即7:00:00算作早高峰，而9:00:00不算做早高峰）全部以event_time-开始打车时间为时段划分依据，平均等待接单时间和平均调度时间均保留2位小数，平均调度时间仅计算完成了的订单，结果按叫车量升序排序。司机订单信息表（get_car_order）如下。

拿到所有球队比赛的组合 每个队只比一次。现有球队表（team）如下。

最近播放日期以 end_time-结束观看时间 为准，假设为T，则最近一个月按 [T-29, T] 闭区间统计。当前配置的参数a,b,c,d分别为100、5、3、2。现有用户视频表（user_video_log）如下。找出近一个月发布的视频中热度最高的top3视频。当天日期使用视频中最大的end_time。结果中热度保留为整数，并按热度降序排序。新鲜度=1/(最近无播放天数+1)；

统计2020年每个月实际在职员工数量(只统计2020-03-31之前)，如果1个月在职天数只有1天，数量计算方式：1/当月天数。如果一个月只有一天的话，只算30分之1个人。

从订单详情表（order_detail）中查询2021年9月27号-2021年10月3号这一周所有商品每天销售情况。

从订单明细表（order_detail）中列出每个商品每个年度的购买总额。订单明细表：order_detail。