目录
1、出了一道题,一张千万数据量的表和一张抽取的新增的8万数据量的表,在不同的层里,怎么合并两张表?用sql方法?
2、数据漂移
3、你们的项目组表右多少张,数据量大概是多少
4、每天的数据量有多少
5、什么时候用到存储过程
6、你在工作中遇到过哪些报错,什么原因导致的
7、查询两千万的数据要多久
8、标签,字段,口径是同一个东西
9、什么是维度退化
10、项目的粒度
11、每天同步的表有哪些,增量数据有哪些?
12、几十亿的数据你们怎么同步?每天更新的数据量有多大?
13、取数部分是按什么取的,怎么保证抓的数据尽量少又不漏?
14、项目数据的来源是什么,需求是怎么来的,拿到需求以后怎么做的?
15、存储过程写的多吗,一个版本写多少个,一个有多少行,写过最复杂的存储过程是什么,存储过程中怎么记录日志,找出异常?
16、说说项目中做过的指标有哪些?用到的表有哪些?
17、dm层如何保证数据质量,如何保证数据时正确的?
18、怎么设计表的,怎么设计mapping的,表是谁设计的
19、存储过程如果出现异常怎么办
20、如果有10张表,关联以后,会有性能问题,问怎么优化
21、一个plsql脚本很慢,如何分析到底哪里慢
22、两个大表之间如何关联
23、左连接、右连接、内连接和外连接的区别
24、游标的使用
25、数据抽取时间间隔
26、Kettle定时任务调度
27、数据库和数据仓库的区别
28、查询最近七天登录
29、数据同步策略
30、数仓的主题域划分
31、主题域和数据域
32、Hive中三类函数(UDF分类)的区别,分别有哪些函数
33、脏数据的处理
34、数据迁移的三种类型
35、新老系统数据库表结构的变化
36、自定义函数的创建--创建函数
37、数据清洗中原数据的特点
38、数据清洗规则
39、Map Join和Reduce Join区别及优化
40、数据结构树
41、银行的十大主题划分和九大业务数据概念
42、Hive里面怎么实现update和delete
43、项目工作流程:
44、数据脱敏常见方法
45、拉链表适用情况(例如订单表、用户信息表)
46、大表一般有多大
47、每天大概多少个任务
48、数据分哪几类?
49、银行跑批的理解
50、工作流调度方式
如果千万的表格有分区,那么直接读取数据全量写入到对应的例如今天的分区中;如果是个普通的表格,那么可以使用insert into table进行数据的追加 select * from 库名.表名
1.1 定义
源数据抽取到ods层中,同一个业务日期数据中包含前一天或者后一天凌晨附近的数据或者丢失当天的变更数据。
1.2 数据漂移出现的原因
通常落地数仓的ODS表会按时间切分做分区存储,实际上往往由于时间戳字段的准确性问题导致发生数据漂移。通常有四类时间戳:
modified_time:数据库记录某条数据更新的时间。
log_time:数据库日志记录某条数据更新的时间。
proc_time:具体业务过程发生时间。
extract_time:数据记录被抽取时间。
1)同一条记录的数据抽取时间extract_time明显是晚于另外三个时间的,如果用这个字段切分,ODS某个分区中的数据会包含前一天末尾的数据,并丢失当天末尾的数据。
2)如果用数据库记录的更新时间modified_time,前台业务系统手工订正数据时可能会遗忘同步更新该时间,导致该抽取的数据被遗漏掉。
3)另外,由于网络或者系统压力问题,log_time或者modified_time可能会晚于proc_time,导致数据漂移。
4)如果我们直接使用proc_time时间进行切分,这种情况仅仅对包含一个业务过程的ODS表有效果,如果该表每条记录需要存储多个业务过程,则用proc_time切分会丢失其他发生在当天的业务过程记录。
1.多获取后一天的数据
既然很难解决数据漂移的问题,那么就在ODS每个时间分区中向前、向后多冗余一些数据,保证数据只会多不会少,而具体的数据切分让下游根据自身不同的业务场景用不同的业务时间proc_time来限制。但是这种方式会有一些数据误差,例如一个订单是当天支付的,但是第二天凌晨申请退款关闭了该订单,那么这条记录的订单状态会被更新,下游在统计支付订单状态时会出现错误。
2.通过多个时间戳字段限制时间来获取相对准确的数据
1) 首先根据log-time分别冗余前一天最后15分钟的数据和后一天凌晨开始15分钟数据,并用modified_time过滤非当天数据,确保数据不会因为系统问题而被遗漏
2) 然后根据log_time获取后一天15分钟的数据;针对此数据按照主键根据log_time做升序排列去重,因为我们要获取的是最接近当天记录变化的数据(数据库日志将保留所有变化的数据,但是落地到ODS表的是根据主键去重获取的最后状态的数据)
3) 最后将前两步结果数据做全外连接,通过限制业务时间proc_time来获取我们所需要的数据.
表大概有300张左右,数据量在百亿级别
2千多万,有多又少,具体看公司
oracle的存储过程一般是在数据的ETL过程中使用的,或者对sql语句进行优化,或者是编写一个固定功能的时候使用存储过程,然后根据存储过程的逻辑决定是否要输入或者输出的参数,如果没有输出的参数可以使用call调用,有输出的Out参数就要放在代码块中进行调用了。
存储过程里遇到异常,主键冲突,内存溢出,除数为零,系统等待某一个资源,时间超时,表空间错误,没有某张表的权限。
要看取数规则,限制条件的多少。关联表少的时候很快,几分钟就出来了。条件复杂的,关联条件多的话,要跑半个小时左右。
比如天维度退化到星期维度
粒度就是同一维度下,数据统计的粗细程度,比如 天维度相对于月维度来说,粒度就比较细。
一般事实表都是增量的。比如借记卡的开户信息表,贷记卡合同信息表,交易信息表,存款信息表等。
每天同步新开户,新合同,新的交易流水,新存款等。
增量同步,对于交易明细表每天有几千万的增量
时间戳区来取的,我们是取最近7天的数据作为增量
(华为的做法)我们是根据会计期进行取数并将数据同步到下游的目标表,一个会计期的时间是1个月
或者说 :时间戳T+1的方式。今天同步昨天的数据
数据来源于业务系统,包括个人贷款系统,公司贷款系统,票据系统,总账系统,基金理财系统等。
需求是客户先提到需求分析那里,然后需求分析师会对需求进行拆解和澄清,确认取数逻辑,然后我们会开会讨论如何实现,包括可行性分析,设计好模型表,然后我们进行开发。
嗯,我主要就是写存储过程的。
一个版本大概要写2,3个,每个7,8百行,(少的两三百行,多的上千行)
最复杂的是统计交易明细表,因为粒度比较细,涉及到的表非常多,还要对交易类型和机构进行过滤等。写了1000多行代码。
存储过程每个步骤都会记录日志,也会记录异常
客户余额,日均余额统计。表有:客户交易明细和客户信息、币种、机构、贷款合同等表
存款账户交易月汇总指标(根据存款账户不同的交易类型来统计交易笔数和交易金额)。表有:客户交易明细和客户信息、币种、机构等表。
(1)首先在开发阶段,我会仔细分析并理解需求,按照指标计算的公式完成进行开发。在这个阶段,如果我认为需求有问题或者我对需求有疑问会跟我们的产品经理进行沟通和确认
(2)开发以后,先进行单元测试,单元测试的时候我会先按照计算公式进行手工计算,然后通过代码再算一遍,对比两次计算结果,如果计算结果一致说明没有问题。
(3)之后,我们还有一个代码评审环节,可以进一步确认我们对需求的理解是否正确。
(4)进入测试阶段以后我们团的测试会进行充分的测试,对于他们发现的问题我会分析问题并解决,然后对发现的有效缺陷进行分析,看看是否在其他地方也有类似的问题,避免测试漏测,也可以提高我的代码质量。
(5)上线以后,对于我们团队的bug,我会进行分析,总结经验,避免以后再次发生类似的bug。
这个主要是设计人员设计都,设计好后目标表的字段以及来源于哪些表
(根据业务需求确定表字段,根据长度标准确定长度,然后完成表结构。Mapping和业务对接,确定规则,范围,然后根据需求和涉及的表,设计mapping,计算指标)
在plsql中使用exception,在exception中把过程数据记录到错误日志表,然后对主过程的事务做回滚,并且针对异常我们会记录异常的日志,方便后续问题的分析
可以分别每5张表进行关联,产生2个中间表,在把2个中间表进行关联
(1)通过日志,记录每步耗时,分析到底哪一步慢;
(2)然后找到最慢的sql部分,看到底是查询慢还是更新慢;
(3)如果查询慢,看select后面是否调用了其他的自定义函数,注释函数,再查性能是否提升,如果调了自定义函数之后变慢,则需要优化自定义函数的性能;
(4)如果仍然很慢,这个时候就要分析数据量的变化和执行计划,主要看数据量的变化情况,是否突然数据增量比较快,导致数据量暴增;还可以通过日志看,脚本执行的效率是否越来越慢,又分为数据量变得越来越大 或者 有人改过代码;
(5)数量多了,之前同步的方式可能需要更改;
(6)如果有人为了优化性能,建了更多的索引导致 插入数据越来越慢, 这时候需要平衡查询和更细的性能,有可能需要增加服务器的配置;
把大表的数据进行切分成小的数据,然后再对小的进行关联。可以用分区或者是分表。
left join (左连接):返回包括左表中的所有记录和右表中连接字段相等的记录。
right join (右连接):返回包括右表中的所有记录和左表中连接字段相等的记录。
inner join (等值连接或者叫内连接):只返回两个表中连接字段相等的行。
full join (全外连接):返回左右表中所有的记录和左右表中连接字段相等的记录。
Oracle数据库游标分类:静态游标和REF游标。其中静态游标分为:隐式游标、显示游标。
隐式游标:在PL/SQL块中所编写的每条sql语句都是隐式游标。
显示游标:显示游标是指在声明块中直接定义的游标。
REF游标:在定义游标时不绑定具体的查询,而是动态的打开指定类型的查询。
语法:TYPE 游标变量类型名称 IS REF CURSOR [RETURN 数据类型]
显示游标操作步骤可大致为4步:
1、声明游标:使用CURSOR定义
2、打开游标:使用OPEN操作
3、使用游标:使用循环和FETCH...INTO操作
4、关闭游标:使用CLOSE操作
用datediff设置10分钟左右间隔(根据需求,自行调整时间)。
(1)Windows用“任务计划程序”分别实现对“作业”、“转换”的定时调度。
(2)Linux上用“crontab”分别实现对“作业”、“转换”的定时调度。
数据仓库是面向主题,存储的是历史数据。数据库是面向事务,存储的都是当前在线交易的业务数据。
数据仓库是尽量引入冗余数据,保证数据的完整性,采用反范式设计。而数据库是尽量避免数据冗余,采用的是范式规则。
本质区别:数据仓库目的是为了分析数据,数据库目的是为了捕获数据;
select stu_name,count(num) num from
(select stu_name,date(createtime)-row_number() over(partition by stu_name order by createtime) num from
(select distinct stu_name,date_format(createtime,'%Y-%m-%d') createtime from login_log) t1) t2 group by stu_name having(count(1))>7;
根据数据量的变化,数据的变化情况,分类:
(1)全量表:存储完整的数据
(1)增量表:存储新增加的数据
(3)新增及变化表:存储新增加的数据和变化的数据
(4)特殊表:只需要存储一次的数据
数据同步策略:全量同步策略、增量同步策略、新增和变化同步策略、特殊策略。
数仓主题(Subject):是在较高层次上将企业信息系统中某一分析对象(重点是分析的对象)的数据进行整合、归类并分析的一种范围,属于一个抽象概念,简单点说每一个主题对应一个宏观分析领域。
主题域:通常是联系较为紧密的数据主题的集合,可以根据业务的关注点,将这些数据主题划分到不同的主题域,自下而上的方式,根据业务需求分析视角进行划分。
主题域划分:按照所属系统,按照业务或业务过程、按照部门、按照行业案例分析。
主题域:面向业务过程,将业务活动事件进行抽象的集合,如下单、支付、退款都是业务过程,针对公共明细层(DWD)进行主题划分。
数据域:面向业务分析,将业务过程或者维度进行抽象的集合,针对公共汇总层(DWS)进行数据域划分。
UDF: 一行数据对应一行数据,在select 的过程中每个函数的属性都不会再分割
UDAF:多行数据对应一行数据,典型的就是聚合函数sum,count,将多个属性值汇聚到一个数据值
UDTF: 一行数据对应多行数据,指在某种特殊情况下,将属性值,再次进行分解,形成了一个属性字段对应多行,explode函数就是典型。
数据缺失:补值、平均数、零、等比例随机数等,缺失记录则通过手工补录或者放弃。
数据重复:去重。
数据错误;异常值(区间限定发现并排除)、格式错误(格式转换)、数据不统一(人工)。
(1)结构迁移
将源库中待迁移对象的结构定义迁移至目标库(例如表、视图、触发器、存储过程等)。
(2)全量数据迁移
将源库中待迁移对象的存量数据,全部迁移到目标库中。在执行全量迁移任务时不能在源库中写入新的数据,不然容易产生数据不一的情况。
(3)增量数据迁移
将源库中自上一次迁移后的全部改动和新的增量数据进行迁移至目标库。一般增量数据迁移会保持实时同步的状态,所以迁移任务不会自动结束,需要手动结束迁移任务。
(1)新增字段和老系统表完全不存在关系
老表迁移到新表中,新表中有些必填字段在老表中没有的,需要和开发确认这些数据的填写规则(给什么默认值)
(2)新增字段是由老系统特定字段转换而来
新系统中的一些字段可能是老系统中的一些字段通过一些规则转化而来的,所以需要和开发部门确认这些转换规则
CREATE OR REPLACE FUNCTION 函数名(参数1 模式 参数类型)
RETURN 返回值类型
AS
变量1 变量类型;
变量2 变量类型;
BEGIN
函数体;
END 函数名
(1)数据重复
(2)字段名跟结构前后不一致
(3)某些记录存在字段缺失
(4)原始数据来源跟格式各不相同
(5)重点数据存在异常值
(1)确保原始数据的准确输入
(2)小心处理NA值跟字符串为空的字段
(3)检查字符型变量仅包含有效值
(4)检查数值型变量在预定范围内
(5)检查是否存在缺失数据
(6)检查并删除重复数据
(7)检查特殊值是否唯一
(8)检查是否存在无效数据
Map Join:小表复制到各个节点上,并加载到内存中;大表分片,与小表完成连接操作。(1)Join操作在map task中完成,因此无需启动reduce task。
(2)适合一个大表,一个小表的连接操作。
优点:在Reduce端处理过多的表时, 在Map端缓存多张表,提前处理业务逻辑,这样增加Map端业务,减少Reduce端数据的压力,尽可能地减少数据倾斜。
Reduce Join:map端按照连接字段进行hash,reduce端完成连接操作。
(1)Join操作在reduce task中完成;(2)适合两个大表的连接操作。
无序树:树中任意节点的子节点之间没有顺序关系,这种树称为无序树,也称为自由树。
有序树:树中任意节点的子节点之间有顺序关系,这种树称为有序树
有序树分类:完全二叉树、平衡二叉树、排序二叉树、哈夫曼树、B树。
完全二叉树
(1)二叉树:每个节点最多含有两个子树的树称为二叉树。
(2)完全二叉树:对于一棵二叉树,假设其深度为d(d>1)。除了第d层外,其它各层的节点数目均已达最大值,且第d层所有节点从左向右连续地紧密排列,这样的二叉树被称为完全二叉树。
(3)满二叉树:所有叶节点都在最底层的完全二叉树。满二叉树是特殊的完全二叉树。
平衡二叉树:当且仅当任何节点的两棵子树的高度差不大于1的二叉树。
排序二叉树:也称二叉搜索树、有序二叉树
哈夫曼树:带权路径最短的二叉树称为哈夫曼树或最优二叉树;
B树:一种对读写操作进行优化的自平衡的二叉查找树,能够保持数据有序,拥有多于两个子树。
TeraData金融数据模型(银行十大主题划分):
Teradata FS-LDM是一个成熟产品,在一个集成的模型内支持保险、银行及证券,包含十大主题:当事人、产品、协议、事件、资产、财务、机构、地域、营销、渠道。
FSDM将银行的信息分解为九大数据概念:
关系人、合约、条件、产品、地点、分类、业务方向、事件、资源项目。
(注意:Hive中一般不支持update和delete,但可以实现,有些面试官会问这个)
要实现update和delete功能,该表就必须支持ACID,而支持ACID,就必须满足以下条件:
表的存储格式必须是ORC(STORED AS ORC);
表必须进行分桶(CLUSTERED BY (col_name, col_name, …) INTO num_buckets BUCKETS);
Table property中参数transactional必须设定为True(tblproperties(‘transactional’=‘true’));
1. 客户需求
2. 产品经理写项目需求,弄成需求规格说明书。
3. 参加需求评审会议;分配工作,完成时间,需求可行性,需求的详细概念
4. 项目经理和架构写详细,概要设计文档。
5. 根据需求开始写脚本和代码
6. 设计表结构、数据类型、约束、索引、分区表、设计模型和ER图
7. 根据文档开始编写sql脚本、存储过程,函数等等,实现数据清洗转换
8. 使用白盒测试。优化效率低下的语句。
9. 提交给测试。
10. 然后就上线。
敏感数据梳理
这里我们把敏感数据分成四个维度进行梳理,用户、商家、终端、公司。
(1)用户维度:手机号码、邮件地址、账号、地址、固定电话号码等信息(此外个人隐私数据相关还有如:种族、政治观点、宗教信仰、基因等)
(2)商家维度:合同签订人,合同签订人电话等(不排除全局敏感数据:如商家团购品类等)
(3)用户终端维度:能够可能标识终端的唯一性字段,如设备id。
(4)公司角度:交易金额、代金卷密码、充值码等
确定脱敏处理方法
常见的处理方法如下几种有:
1. 适用情况
(1)数据量比较大
(2)表中的部分字段会被更新
(3)需要查看某一个时间点或者时间段的历史快照信息
查看某一个订单在历史某一个时间点的状态
某一个用户在过去某一段时间,下单次数
(4)更新的比例和频率不是很大
如果表中信息变化不是很大,每天都保留一份全量,那么每次全量中会保存很多不变的信息,对存储是极大的浪费
2. 优点
(1)满足反应数据的历史状态
(2)最大程度节省存储
接近PB
大概几百个
结构化数据、半结构化数据、非结构化数据
结构化数据:即以关系型数据库表形式管理的数据
半结构化数据:非关系模型的,有基本固定结构模式的数据,例如日志文件、XML 文档、JSON 文档、Email 等
非结构化数据:没有固定模式的数据,如 WORD、PDF、PPT、EXL,各种格式的图片、视频等
批量是相对来说,并不一定是在晚上,白天也有批量,主要是完成业务处理的。
批量的核心功能是进行核算,如总分核对、试算平衡等,这样保证全行的帐务没有偏差。
一般,为提高交易的反应时间,一些对帐清算等不需要实时入账的功能也由批量完成;同时,还有一些为了减少柜员工作量和减少高峰时期资源争夺的交易,如待收代付等,也归入批量完成的功能。一些特殊业务,如记息记提等。还有一块批量就是为了统计和管理的需要而出的一些报表。
跑批,最主要就是产生总帐, 进行总分核对。或者是进行大批量交易,如:结息,计提,代收付等(这一步可以在各分布平台做)。或者是生成报表,导出流水数据等。简单来讲就是每天结算几次,一般是在10点到12点左右。
每天系统需要跑批一次,将所有分行还有办事处的信息录入到总的计算机内,进行分析、运算。然后将第二天需要的事情发布出去(比如卡函的打印,账单的答应)
简单的任务调度
使用 linux 的 crontab 来定义调度,但是缺点比较明显,无法设置依赖复杂任务调度。且需要编写相关 shell 脚本。
复杂的任务调度
当下企业两种选择,要么自主开发工作流调度系统,要么使用开源调度系统,比如 azkaban、Apache Ooize、Zeus 等。
其中知名度比较高的是 Apache Oozie,但是其配置工作流的过程是编写大量的 XML 配置,而且代码复杂度比较高,不易于二次开发。