1.赋权
grant all privileges on table A to B
2.查询库中的表
select * from pg_tables where tablename like '%%'
3.新增分区
alter table A add partition ...
4.取上月最后一天
date_trunc(now())-1
5.是否用过拉链表
用过，我之前接触过的拉链表一般是订单表和用户表，在某些需求背景下，需要用到历史某一时间点的订单状态或用户信息，也就是历史快照数据，但这种表数据量又比较大
如果用普通的增量表或全量表，获取不到历史状态，如果每天保留一份数据，又会造成数据冗余，拉链表与普通表最大的区别，是他有一个开始时间，结束时间，
用于表明该条数据的有效期，如果想查某一天的历史快照数据，只需要限制该时间在开始结束时间中间即可，我们目前项目没用到拉链表订单用户表都是做成的普通增量表，获取最新数据即可
6.
数据倾斜：
表中null太多、某一数据太多、关联字段类型不匹配
业务系统至_rt：
CDM、roma、xdata
DAP上报至_cs：
flinksql、flinkjar
olap与oltp的区别
sc.textfile样例
执行计划
做数仓的，技术不是很重要，比如说用的什么etl工具、什么数据库，基本上原理都是差不多的，就算没用过，熟悉各几天也就差不多了，也就是函数、语法、使用上有些细微的差异，其实数仓的关键是
要理解业务，理解整体数仓的结构和模型的业务含义，然后会sql、会存储过程、会调优、会建模
mapreduce原理
读写文件原理
wordcont
collect_set() 与 collect_list()的使用
47.hive常用命令：
内部表/外部表/分区表的创建
Hive/hdfs/本地文件系统之间的数据导入导出
1.创建内部hive表，然后导入数据
CREATE TABLE t_hive (a int, b int, c int) ROW FORMAT DELIMITED FIELDS TERMINATED BY '\t';
补充：通过stored as parquet可以将数据保存为parquet格式
从本地导入数据到hive表
LOAD DATA LOCAL INPATH '/home/cos/demo/t_hive.txt' OVERWRITE INTO TABLE t_hive ;
从Hive表导出数据到本地文件系统
INSERT OVERWRITE LOCAL DIRECTORY '/tmp/t_hive' SELECT * FROM t_hive;
从HDFS导入数据到hive表
LOAD DATA INPATH '/user/admin/t_hive.txt' OVERWRITE INTO TABLE t_hive ;
从Hive表导出数据到HDFS
INSERT OVERWRITE DIRECTORY '/user/admin/t_hive' SELECT * FROM t_hive;
从其它hive表导入数据到hive表
INSERT OVERWRITE TABLE t_hive2 SELECT * FROM t_hive ;
**也可创建hive表的同时，从其它hive表导入数据：
CREATE TABLE t_hive AS SELECT * FROM t_hive2
2.创建外部hive表
create external table ext_student(id int ,name string) row format delimited fields terminated by '\t' location '/datax';
3.创建分区表
CREATE TABLE t_hft(
SecurityID STRING,
tradeTime STRING,
PreClosePx DOUBLE
) PARTITIONED BY (tradeDate INT)
ROW FORMAT DELIMITED FIELDS TERMINATED BY ',';
导入分区数据
load data local inpath '/home/BlueBreeze/data/t_hft_1.csv' overwrite into table t_hft partition(tradeDate=20130627);
查看分区表
SHOW PARTITIONS t_hft;
4.正则匹配表名
show tables '*t*';
5.增加一个字段
ALTER TABLE t_hive ADD COLUMNS (new_col String);
6.重命令表名
ALTER TABLE t_hive RENAME TO t_hadoop;
7.仅复制表结构不导数据
CREATE TABLE t_hive3 LIKE t_hive;
8.删表
drop table if exists t_hft;
增加分区:
ALTER TABLE book add PARTITION (category = 'zazhi') location '/user/hive/warehouse/datax.db/book/category=zazhi';
删除分区:
ALTER TABLE table_name DROP partition_spec, partition_spec,...
重命名表:
ALTER TABLE table_name RENAME TO new_table_name
修改列名:
ALTER TABLE table_name CHANGE [COLUMN] col_old_name col_new_name column_type [COMMENT col_comment] [FIRST|AFTER column_name]
增加/替换列:
ALTER TABLE table_name ADD|REPLACE COLUMNS (col_name data_type [COMMENT col_comment], ...)
查看表名，部分匹配
SHOW TABLES 'page.*';
SHOW TABLES '.*view';
查看某表的所有Partition，如果没有就报错：
SHOW PARTITIONS page_view;
查看某表结构：
DESCRIBE invites;
查看分区内容
SELECT a.foo FROM invites a WHERE a.ds='2008-08-15';
hive的udf:
1.继承UDF，重写evaluate方法，打成jar包，放入hive根目录下的auxlib（或者执行hive命令前用addjar）
2.CREATE temporary function str_md5 as 'com.lxw1234.hive.udf.HashMd5'; 将其创建成一个方法，然后既可以在sql中使用
指定执行用户：
sudo -u hdfs
7.查看系统中所有进程
Ps aux
41.给文件增加权限：
其语法格式为：chmod
olap与oltp的区别
oltp指数据库，olap指数据仓库，
像我们这边，
数据库的主要使用场景有两种，第一是用于业务系统储存业务数据，第二是用于储存数仓处理后的最终结果数据，他的实时交互性比较强
而数仓的使用场景，就是是将不同业务系统的异构数据源都抽取过来，统一建模、清洗、加工，面向主题进行离线或实时分析，为不同分析需求提供数据服务
76.数据仓库、主题域、主题的概念
数据仓库 包括 主题域 包括 主题
数据集市
就是数仓处理完后提供的dm层结果数据
134.Hive中order by，sort by，distribute by，cluster by的区别
1.order by
全局排序
2.sort by和distribute by组合使用（效果与order by一样，但是使用场景不同）
当有多个reduce时（可以通过set mapred.reduce.tasks=n来指定reduce的个数），sort by仅保证在每个reduce内排序（部分有序），distribute by的作用是控制哪些行放入哪些reduce处理的，因此distribute by经常和sort by配合使用：SELECT * FROM year distribute by year sort by year asc,temp desc
3.CLUSTER BY
关键字是DISTRIBUTE BY和SORT BY的简写，这两者可以认为对应与Hadoop的partition和sort过程。如果partition和sort的key是不同的，可以使用DISTRIBUTE BY和SORT BY分别指定（如上面的例子）
注：Distribute by和sort by配合使用的场景
1.Map输出的文件大小不均。
2.Reduce输出文件大小不均。
3.小文件过多。
4.文件超大。
136.Hive的 TRANSFORM 关键字的作用
可以在SQL中调用自写脚本的功能，适合实现Hive中没有的功能又不想写UDF的情况
如：
SELECT TRANSFORM (movieid, rate, timestring,uid) USING 'python weekday_mapper.py' AS (movieid, rate, weekday,uid) FROM t_rating;
**kafka主题中有分区，每个分区有多个副本保存在不同的服务器上；分区中有消息，每条消息在文件中的位置称为offset（偏移量）,用来在分区中唯一的标识这个消息
**将日志分区可以达到以下目的：首先这使得每个日志的数量不会太大，可以在单个服务上保存。另外每个分区可以单独发布和消费，为并发操作topic提供了一种可能。
**两个重要的配置参数：
## 数据存储的最大时间 超过这个时间 会根据log.cleanup.policy设置的策略处理数据，也就是消费端能够多久去消费数据
log.retention.minutes=7days
## Consumer归属的组ID，broker是根据group.id来判断是队列模式还是发布订阅模式，非常重要
group.id
hive调用hql脚本
./hive -d key value -f HQL文件
7、按照需求使用spark编写一下程序？
A、当前文件a.text的格式如下，请统计每个单词出现的个数和第四列每个元素出现的个数
A,b,c,d
B,b,f,e
A,a,c,f
sc.textFile(“a.text”).flatMap(_.split(“,”)).map((_,1)).ReduceByKey(_+_).foreach(println)
sc.textFile(“a.text”).map(line=>{(line.split(",")(3),1)}).reduceByKey(_+_).foreach(println)
B、HDFS中有两个文件a.text与b.text,文件的格式为(ip,username),如：a.text,b.text
a.text
127.0.0.1 xiaozhang
127.0.0.1 xiaoli
127.0.0.2 wangwu
127.0.0.3 lisi
B.text
127.0.0.4 lixiaolu
127.0.0.5 lisi
3.Spark Streaming的三种运用场景
1、无状态操作
只关注当前新生成的小批次数据，所有计算都只是基于这个批次的数据进行处理。
2、状态操作
除了当前新生成的小批次数据，但还需要用到以前所生成的所有的历史数据
3、window操作
关注窗口内的批次数据
7. “jps”命令的用处？
解答：
这个命令可以检查Namenode、Datanode、Task Tracker、 Job Tracker是否正常工作。
Hive中的left semi join替换sql中的in操作
有用户id、股票代码、买入日期三个字段，写sql求连续3日买入的用户
例如：查询不同地区三季度家电类商品销售额排名前10%的商户有哪些
表结构：商户、日期、地区、商品类别、商品名称、商品单价、商品数量
select sh,dq,
ntile(10) over (patition by dq order by xse desc) pm
from
(select sh,dq,sum(round(nvl(dj,0)*nvl(sl,0),2)) as xse from a where splb='家电' and quarter(ri)=3 group by sh,dq) t
where pm=1
cm安装cdh
3类优化方式
介绍、项目介绍（从数仓分层和数据流方面和技术栈简述，因为我们这边每个人不是固定做接入、底座、报表的，所以我刚才说的所有流程我基本上上都做过，然后业务方面我主要负责的是行为数据和订单数据）
实时数仓的实现：
flink+finebi(原来是华为云上的一个实时服务)
最底层为实时区数据
sdi为贴源层，数据和源系统保持一致
dwd为明细层，里面主要是一些事实表
dws为汇总层，里面主要是一些通用逻辑
dim为维度层，里面是一些维表
dm为集市层，里面是一些结果表
页面sql层（现在是用存储过程或finebi实现）
clickhouse简述
小数保留两位：
round()
flink sql专题
1.如何运行：
在华为云上的实时流计算服务中，可以通过sql或jar的方式运行作业
2.建表语句：
creat source/tmp/sink stream TBL_A(字段) with (配置)
3.flink sql简述：
我不负责实时，但是看过别人写的代码，我们这边flink sql其实就是将kafka数据读进表，然后用sql处理，最后将结果数据落进guass表，语法和标准sql也差不多，并且实时逻辑是不会太复杂的，
比较有特点的，就是checkpoint、窗口、eventime
4.应用场景：
我们目前应用于实时大屏（包括实时销售，直播情况统计，监控预警等)
5.checkpoint作用：
开启后可基于checkpoint进行失败恢复和数据累计
6.窗口：
主要就是翻滚窗口（数据不重）和滑动窗口（数据可重）
7.flinksql中提供了两种时间：
processing-time 系统时间 event-time 事件时间
需要在数据流中指定一个字段作为事件时间，并且由于数据可能会出现乱序，因此还需要设置watermark策略来保证一个特定最大等待时间后，触发后续的计算
报表需将主界面、下钻页面格式均印入脑海
页面效果分析：
目的：
看出某页面作为入口（一次访问路径的第一次）或整体（一次访问路径的所有页）页面的流量，成交情况
商品销售分析：
目的：
从品牌，商品，平台，渠道，物理分离，业务分类等不同维度看看订单类指标的情况
主表是订单产品表 dwd_order_product 再关联一些退换货申请表，退款申请表取到相应信息
如何建模：以退换货申请表为例
id唯一标记，也是该表的主键
退换单号 支付方式 是否保价
原始下单单号 退款方式 是否使用积分
用户id 退货类型
状态 申请日期
收货地址 退换原因
总结：将此行为涉及的所有字段加入该表
渠道销售分析
目的：
可以看出用户通过各个推广渠道产生的点击或购买行为，从而可以看出各渠道的推广效果
渠道来源包括：
返利网、百度竞价、华为商城站内信等
渠道名称是指:
具体广告页的简称
该报表分为三个页签:
渠道流量销量：从各渠道维度来看 渠道单品销量：从商品维度来看 渠道地域销量：从收货地维度来看
客单价指标:
pv：？
取页面加载类事件的action_id，进行去重后计数
uv：？
cookie_id去重后计数
购买/首次购买用户数：
订单表里user-id去重，若支付时间等于首次支付时间，则为首次支付
页面上下游分析：
目的：
分析当前页面或一类页面（首页、详情页、活动页等）的来源页流量，去向页流量以及成交页贡献情况
还可以通过url或商品名称，看出具体某一页面其流量，以及贡献和被贡献情况
uv和支付金额都支持下钻，下钻后展示的分别是 ：
uv：页面下具体页面事件分别贡献的uv及占比 支付金额：产生支付的具体商品名称和支付金额及数量
技巧
1.数仓的重点是什么：
符合建模规范，包括架构，模型，代码，命名等
2.什么是元数据管理：
我理解的元数据就是描述数据的数据，页就是将一类表的信息，比如备注、字段、字段含义、关联关系等描述信息放在一张表内，现在我们这边是没有完善的元数据管理的，就是将一些信息写在excel中
3.数仓命名规则：
层级-主题-主题业务含义-后缀 dwd_user_behavior_rt
4.数仓建模步骤:
将业务分成几个主题域，在每个主题域内梳理需要分析的业务主题 确定业务对象 确定维度 确定事实表 最后构建模型
如：零售主题域下-渠道分析主题-渠道销售分析报表
常用维度包括：
日期、平台、商品、配置、地域、渠道、用户、设备
常用事实表：(能说出宽表中主要字段)
正逆向订单表（下单数等）、行为表（pv、uv等）、注册登录表
常用模型：
1）星型模型：每一个维度都直接与事实表相连接 2）雪花模型：有一个或多个维表没有与事实表直接连接，而是通过其他维表连接到事实表
我们大部分用的是雪花模型，这种模型适用于复杂的业务场景，还可以减少数据冗余
我们所有主题域都是零售主题域（retail)主题包括用户行为、订单、登录注册等
6.如何做一个新需求：
先理清都有哪些表，本次业务涉及哪些表，怎么关联，最后分的维度和指标是什么，是否口径已经都给出
报表常见问题（项目中遇到的问题）：
1.当下钻小时折线图的时候，如果该小时无数据吗，则前端横坐标无法填充，目前的解决方案：创建一张包含所有时间的表，以此为主表，left join
2.行为订单数据关联时，不要用full join ，否则当一个有数据一个没数据时容易出问题，可以用union all合并，然后case when then 取出
3.注意删除的内容和插入的一定要完全一致，因为我们有很多数据标识，防止误删
4.前端传参格式和返回格式一定要先沟通好，否则后期还要返工
是否在存储过程里用过循环：
我们现在大部分存储过程要么是给前端调用，生成报表数据用的，要么是给lts调度跑底层数据的，大部分不怎么用循环
一般工具类的脚本才可能会用到循环，我之前写过一个，是给表配置自增分区的，因为guass分区需要自己创建，不能向hive
那样自动生成，所以我写了个存储过程，大概原理就是：我们会把需要分区的表写入一张配置表，然后写存储过程度这张表，
再根据分区系统表判断分区是否已经存在，如果不存在，再一次性创建7天的分区
执行计划如何看是否走了索引是否全表扫描：
有index则走了索引，有full scan则进行了全表扫描
1.窗口函数页面上下游逻辑
按日期、平台、cookieid、url-mark分组
按行为发生时间和行为id进行排底
用lag（）函数，求当前页面的上游来源页面
补充：也可获取当前行为的上下游行为的时间、大类、页面事件url等
补充：url-mark是用于区分是否是同一行为区间的，目前认为间隔超过两个小时的上下两条行为是不同的行为区间
2.只有点击事件才上报action-code 如果为null则为页面事件
3.大数据量下的快速查询优化 分区、列存、压缩、牵引
4.华为每日的订单、行为数据量
订单：5.6万（份内）行为：1.2亿（20分钟处理完）
报表性能优化需求
1.建表时分布方式及分布键的选择
（1）一般数据量较小的维表，由于经常会被join，因此选择replication的方式，将数据在每个DN上都存储一份
（2）除上述情况外，其余分布方式选择hush，分布键使用散列字段，使数据尽可能均匀的分布在DN上
（3）切记不能选择会被更新的字段作为分布键
（4）如何查看数据是否倾斜：按分布字段分组，最大最小相差10%以内
（5）不要新建一列seq 用作分布，因为seq会带来性能瓶颈
（6）尽量用join条件字段做分布键，以便join任务能下推到DN
2.建表时使用分区
（1）分区表是一张逻辑表，数据实际存储在分区中
（2）好处：某一分区故障不影响其余数据，提高检索效率
（3）一般使用天分区
3.数据类型的选择
（1）整形>浮点型>NUMP.EIC>字符型
（2）smallint>int
（3）用作关联的字段，数据类型必须一致，否则数据库还需动态转化
（4）尽量使用varchar（n）这种变长字符类型存储字符串
4.压缩级别
查询多：列存、中级压缩 更新多
5.加索引
6.收集统计信息
analyze语句可收集sql中涉及表的信息，存储在系统表中，以便查询优化器生成最有效的执行计划
7.查看执行计划（可以看出是否走了索引，index scan）
explan analyze（如果sql可以正常执行）
8.不写select* 而要指明字段
9.尽量不用full join
10.where条件中，要把能筛选出较少数据的条件放在前面
11.尽量把字段名放在比较条件的一边，会自动进行剪技优化
12.过滤条件中的or很费性能，（会出现全表扫描）可以改为union all合并
13.not in改为not exist （前提是关联字段不出现null值）
14.尽量避免在where中进行null值判断，否则将导致进行全表扫描，可以在null字段上赋上默认值0（如果业务允许）
15.对于连续的数值，用between 代替in
16.尽量避免在where子句中对字段进行表达式或函数操作
17.合理将where或order by中的字段添加索引，但并不是越多越好，因为在提升查询性能的同时会降低插入更新性能
18.只是where条件不同时统计数据，可以改写为case...when...
19.in/exist优化时，in对应= not in对应！=
20.join字段的数据类型必须一致
21.执行计划专题，百度搜 需要注意的是最顶层算子为date node scan 时
页面上下游的需求
1.展示出各页面的访问uv及占比
2.选择一个页面，能看到当前页，来源页，去向页的uv情况及支付金额
3.uv支持下钻，展示页面中具体的事件贡献的uv
4.支付金额支持下钻，展示产生金额的具体商品名称和数量
5.可以输入具体的商品名称，看出当前商品的来源页面及去向页面，及其pv、uv、支付金额
补：现在的所有报表，页面sql里面的用法都比较简单，分不同页面维度
按subjuct，type拿指标使用就行，最多加一些页面筛选条件和简单的指标二次计算，真正的逻辑都在下层算好了dm层
留存分析
目的：看看产品或页面保留用户的能力
如：初始行为选择：“注册” 后续行为选择“访问” 留存周期选择“7天” 时间选择“20200701”<留存周期选择“7天”
则：报表会展示20200701~20200708日符合条件的人数即20200701注册，后几天访问的人数及占比
第一天由初始行为进行过滤
后几天在第一天筛出的user-id中再次进行筛选，留存率也是和第一天人数的比值
和漏斗进行区分，漏斗是在上一天的基础上筛选的漏斗说白了就是每层筛选，主要用于分析一个多步骤过程中每一步的转化与流失情况
面试必问：
1.离职原因：
想找个非外包的更好的工作机会
2.项目中遇到的问题：
说调优、报表遇到问题、数据接入遇到问题
3.优势劣势：
优势是对整个数仓每个环节都做过，并且比较善于归纳总结
劣势是实时方面做得比较少
搜索关键词：
数据仓库、数仓、etl、大数据、数据开发、大数据工程师、hive、bi、sql、报表、数据可视化、数据分析
上下游逻辑如何算贡献：
我们有一张订单行为表，里面的主体是行为数据，然后每条行为后面都会带上他所贡献的订单编号
具体的步骤：
我们通过日期、平台、user_id、cookie_id能找到一个用户本次的全部浏览记录，如果其中有下单，那行为发生时间在本次之前下单时间之前，且在上次下单时间之后的全部浏览行为都会算作
对本订单的贡献
统一id
目的：
找出cookieid->deviceid->udid->userid单向一对一关系，比如说你之前登陆过，但是这次购买未登录，我们就可以通过之前保留下来的登录信息，获取这次未登录状态下的user_id，从而确定这是哪个用户产生的行为
实现：
1.如果遇到多对多的情况，通过窗口函数对事件发生时间倒序去第一条，认为最新的对应关系即为实际对应关系
2.源表是行为表，这些id是行为产生时直接上报的
3.在逻辑处理中主要是对异常数据进行的一些过滤，比如说判断用户id是否合法，可以和用户表进行inner join，去除不合法数据，再比如说可以过滤掉一些格式异常的数据，还有为null值重新赋值等
涉及到的表：
行为表
设备维表
用户维表
dwd_user_behavior中字段含义：
action_type:0、1、2，分别对应曝光事件、点击事件、页面加载事件
platform:平台，一般分为APP、PC、WAP（手机浏览器访问）
big_category_name/small_category_name:大类/页面，可以通过url和website字段关联页面维表，获取到当前事件是在哪个大类和页面下发生的
small_category_name_lag:当前页面的来源页面，通过lag()函数获取
url:发生页面加载事件时会有相应的url
action_occur_time:行为发生时间
sku_name:配置名
product_name:商品名
cookieid/deviceid/udid/userid:对应的id字段
注意：
页面加载事件action_code都为null
点击事件（比如切换商品配置）的url不会跳转
当页面加载为商品详情页时，从url可以获取到具体的商品，然后关联sku表可以获取到商品配置的具体信息
页面包含：详情页、首页、活动页、抢购页等
直播
目的：从活动维度，看出该活动的直播效果与下单情况
指标计算逻辑（所有行为、订单相关指标的计算逻辑都差不多是这样）：
pv：点击量，统计action_type=2的页面事件时action_id的数量
uv：用户数，统计cookie_id去重后的数量
人均观看时长：通过用户进入、离开直播间的时间计算出观看时长，求和，然后除以总uv
最高并发数：按时间分组，计算出同一时刻（同一分钟）的uv数，取最大值
评论数：取行为表中action_code为点击评论的行为数据求和，再关联行为属性表获取该行为对应的活动id，确认是该活动产生的评论
分享次数/点赞数：逻辑同上，只是action_code不同
登录注册数：从系统日志表里获取用户登录注册信息，然后关联直播活动表，限定登录注册时间在直播活动时间内，然后对user_id进行去重，即为登录数，若is_first_login=1，则为首次登录，即视为注册
下单数：过滤下单时间，对order_code进行去重统计
下单金额：过滤下单时间，对cash_pay进行求和
支付订单数：过滤支付时间、支付状态，对order_code进行去重统计
支付订单金额：过滤支付时间、支付状态，对quantity*refund_amount求和
支付取消、退货退款除了过滤的时间不同，其余逻辑同上
购买用户领券数：先从用户领券表中过滤领券时间后查出用户和券的对应数据，然后关联直播订单表，找出各直播活动中产生购买行为的用户，最后关联活动维表，取到该场直播中发放的优惠券，计数
注意：
此处cash_pay为商品支付中现金支付部分（商品总价+运费-优惠券-积分-折扣）理论上应该等于quantity*refund_amount（退款金额*数量），因为退款才是实际支付的钱
一般报表结构：
筛选框，负责增加过滤条件
折线图，横坐标为时间，纵坐标为各指标，可以看出指标按天变化情况
表格，分不同维度统计各指标数值
导出，导出一般包含汇总和按天明细
下钻，如支付金额下钻可以看出支付商品明细
涉及到的表：
dws_live_order:（直播订单表）
order_code,order_date,platform,user_id,payment_status,payment_date,order_finish_date,cash_pay,order_type,order_source,activity_id,activity_start_time,activity_end_time,积分相关字段，渠道相关字段等
dws_live_user_behavior:（直播行为表）
pt_d,platform,activity_id,behavior_id,behavior_code,action_type,action_name,cookie_id,user_id,action_occur_time,评论数，点赞数，分享数
dwd_user_behavior_content:（行为属性表）
behavior_id，行为属性key，行为属性value
dm_live_order_f:（所有dm层表都可以以此模板建表）
pt_d,date_flag,platform,live_activity_key,half_time_key,subject_type,subject_amount
造数据方案：
1.直接从生产环境dm层抽取数据到开发环境dm层
2.将开发环境所有底层表数据造好，再跑作业产生dm层数据
3.直接将开发环境数据日期进行修改，造出多天数据（优先选择）
