- 自我介绍
1.1 为什么离职？
- 详细聊具体项目
3， 数仓建模 理论
- 数仓分层 好处及坏处
一、模型分层
- 缓冲数据模型 BDM
源业务系统数据的快照，保存细节数据，按天分区，会保持最近一段时间数据。一般情况下，每个BDM表对应着源业务系统的一个表或者一个日志文件，数据结构与线上基本是对应的。绝大多数的数据快照是经过增量抽取策略抽过来了，对于不支持增量抽取策略或者数据量极少的表采用全量抽取的策略。 - 基础数据模型 FDM
基础数据模型，用来保存源业务系统数据的快照，数据永久保存。对于有更新操作的数据来说，采用拉链的方式优化存储。对于没有更新操作的数据来说，采用流水方式存储。 - 通用数据模型 GDM
根据京东核心业务主题按照星型模型或雪花模型设计方式建设的最细业务粒度汇总层。在本层需要进行指标与维度的标准化，保证指标数据的唯一性。 - 聚合数据模型 ADM
根据不同的业务需求采用星型或雪花型模型设计方法构建的按维度汇总数据。 - 维度模型 DIM
维度表可以看作是用户来分析数据的窗口，维度表中包含事实数据表中事实记录的特性，有些特性提供描述性信息，有些特性指定如何汇总事实数据表数据，以便为分析者提供有用的信息，维度表包含帮助汇总数据的特性的层次结构。例如，包含订单信息的维度表通常包含将订单分为区域、省份、城市等若干类的层次结构。在维度表中，每个表都包含独立于其他维度表的事实特性，例如，客户维度表包含有关客户级别的数据。维度表中的列字段可以将信息分为不同层次的结构级。 - 临时层 TMP
用来降低加工过程计算难度，提高运行效率的临时表，用完即舍，不保存历史数据。
7 中间层(操作数据模型) ODM
在加工通用模型的时候，对于多个模型都使用到的公共数据需要清洗转换的时候，用来封装清洗转换逻辑保存清洗后的数据，供加工通用模型使用，中间层数据保存历史状态。 - 应用数据模型 APP
应用数据模型按照具体的需求进行设计，其数据直接供前端报表工具展现使用，或者推送到其他系统做相关的数据支撑。
数仓分层意义：
-
清晰数据结构体系
-
数据血缘追踪
-
减少重复开发和资源浪费（避免烟囱式开发）
-
复杂问题简单化
-
统一数据口径
-
拉链表如何设计及使用场景 好处 坏处
好处：节约存储，随时还原任意时间段快照
坏处：拉链表当然也会遇到查询性能的问题，比如说我们存放了5年的拉链数据，那么这张表势必会比较大，当查询的时候性能就比较低了 【查询性能低】
场景： 像订单和用户数据 部分字段存在变化，而且总体变化量不大 -
SQL调优遇到场景：
https://blog.csdn.net/weixin_42792621/article/details/112825128 -
UDF函数了解及使用场景：
https://blog.csdn.net/weixin_42792621/article/details/112825422 -
京东实时流量数据的流转机制：
- 用户打开京东APP
- 点击流SDK 采集用户信息上报点击流服务端
- 服务端收集数据，一份会实时发送到Kafka
- 另外一份会存到当前容器磁盘空间，离线备份，如果实时往KAfka发送宕机，会采用离线进行回补
- 下游消费者消费点击流上报的实时流量数据，进行加工处理二次分发至其他下游应用
-
简述Flink WaterMark机制
见附件 -
简单聊一下Flink认知
见附件 -
SQL题 判断连续打卡登录员工 - 杰少当初总结面筋，原来考SQL题都拿这道考，昨晚上面试官出这题我就笑场了。。。
数据格式如下
empid dt is_work
e1 2019-11-01 1
e1 2019-11-02 1
e1 2019-11-03 1
e1 2019-11-04 1
e1 2019-11-06 1
e2 2019-11-03 1
e2 2019-11-04 1
e2 2019-11-05 1
e3 2019-11-03 1
e3 2019-11-04 1
e3 2019-11-05 1
求:判断连续打卡4天的员工
连续时间判断有个技巧就是排序后的数减去指定时间下的一个差值,最后这个值,如果连续的那么这个值是一样的,如果不连续就不一样
select
uid
,diff_value
,min(login_date) as login_date_min
,max(login_date) as login_date_max
,count(1) as nums
from
(
select
uid
,login_date
,((row_number() over(partition by uid order by login_date)) - datediff(login_date,‘2020-10-01’)) diff_value
from
test
) tmps
group by
uid
,diff_value
解法二：
SELECT
empid,
continue_days
FROM
(
SELECT
*,
row_number() over(partition BY empid order by continue_days DESC) AS num --按照连续打卡天数降序排序
FROM
(
SELECT
empid,
date_sub(dk_date, rank), --用打卡日期-排序后的序号，如果值相等则表示是连续打卡,并统计连续打卡天数
COUNT(dk_date) AS continue_days --连续打卡天数
FROM
(
SELECT
empid,
dk_date,
row_number() over(partition BY empid order by dk_date) AS rank --员工号分组、按打卡日期升序排序
FROM
dev.emp_dk
)
A
GROUP BY
empid,
date_sub(dk_date, rank)
)
B
)
C
where c.continue_days >=4
-
Java Python 这些哪个是主语言，了解的如何？
-
你做Paas化项目的收获， pass化项目目前有多少人在使用
- 个人技术提升，自主学习了Java Scala
- 自主学习了前后端项目的开发和部署
- PAss化产品有两块 A 产品国内 大约100多人使用，覆盖京东内部建模团队
- B产品 就我们海外自己在开发测试，目前使用人数10个人
-
Paas化项目用到的技术栈
Java Scala Spark Hive
Python fastapi JupyterHub Tornado
TypeScript React jupyterLab -
你的专利可以具体聊聊嘛，都写了什么？
-
一种开发数据模型的框架
该专利阐述了 用Python 自动拼接大SQL的具体实现，将单表抽象为 DataTable 关联聚合的多表抽象为DataCluster 将SQL每个实现拆解为这些类对应的成员变量，内部封装数据口径，对外提供API join union group by filter 等等算子 让用户只抽象于高层次代码逻辑，不用关心具体实现，即可完成SQL对接，同时无缝对接HiveTask -
一种零代码开发数据模型的解决方案
该专利阐述了 用户如何通过点选维度&指标，即可开发数据模型的完整解决方案。具体解释生成SQL所需要每个环节如何具体实现 包括指标口径统一封装、维度自动关联、SQL拼接等等 -
一种自动生成表间有效关联方式的解决方案
该专利阐述了如何不需要调研，即可自动完成表间Join的完整解决方案， 包括底层数据加工，算法及策略选取和实现 ， 提出了构建模型间6度理论的构想 -
一种提高数据模型使用率并减少数据冗余的解决方案
该方案阐述了如何提升模型利用率，避免烟囱式开发的解决方案 - 提出了数据路由的构想 详细阐述了如何动态路由数据，避免二次开发的整体解决方案 -
基于Spark引擎进行join时优化方法
该方案阐述了 在join前，结合与或操作提前降低join时数据量，同时借用broadcast机制，降低Shuffle时传输的数据量，提升join性能的解决方案 -
一种基于历史存量脚本利用强化学习提取表间关联关系方法
该方案阐述了 算法预测 几种关联关系那种性能最好
-
-
个人发展这块你偏向什么工作？
- 实时离线均可，只要从事数据岗位就可 【怕自己脑瘫说错，这个部门不做这一块就凉了】
-
简单聊聊Spark
- RDD 弹性式分布数据集，是Spark中最基本的数据抽象，它代表一个不可变、可分区、里面的元素可并行计算的集合。RDD具有数据流模型的特点：自动容错、位置感知性调度和可伸缩性。RDD允许用户在执行多个查询时显式地将工作集缓存在内存中，后续的查询能够重用工作集，这极大地提升了查询速度。
- 在 Spark 中， 使用 DAG 来描述我们的计算逻辑。
DAG 是一组顶点和边的组合。顶点代表了 RDD， 边代表了对 RDD 的一系列操作。
DAG Scheduler 会根据 RDD 的 transformation 动作，将 DAG 分为不同的 stage，每个 stage 中分为多个 task，这些 task 可以并行运行。
- 宽窄依赖： Stage 父子之间如何 分区一一对应，则为窄依赖，如果一对多，则为宽依赖，宽依赖则会遇到Shuffle
- Job： 根据Action 和Transform 算子进行划分，遇到Action算子则形成一个Job
- Spark 任务提交：
1、构建Spark Application的运行环境，启动SparkContext
2、SparkContext向资源管理器（可以是Standalone，Mesos，Yarn）申请运行Executor资源
3、启动StandaloneExecutorbackend
4、Executor向SparkContext申请Task
5、SparkContext将应用程序分发给Executor
6、SparkContext构建成DAG图，将DAG图分解成Stage、将Taskset发送给Task Scheduler
7、最后由Task Scheduler将Task发送给Executor运行
8、Task在Executor上运行，运行完释放所有资源 - spark sql 运行原理：
核心用到了Catalyst 框架- 调用Parser 模块将 SQL 抽象转换为AST 语法树
- 调用Analysis 模块，及模式匹配 对树上每个节点进行绑定解析转换
- 调用Optimizer: 规则和 成本优化
3.1 谓词下推
3.2 列裁剪
3.3 连接重排序
3.4 常量累加
3.5 成本优化 多个逻辑执行计划 结合数据分布选出最优解 - 转物理执行计划
-
HBase了解？
hbase是写的快,因为写直接就往memstore里写,不用考虑其他,即使要往HLog里写,也是先经过memstore再到HLog
对于读,一般是先从memstore里读取,如果没有,再根据meta表里记录的表所处的region信息再取查找对应的region上的数据,综合来看,是写的快- Hbase写入速度比读取速度要快，根本原因LSM存储引擎
- 就是假定内存足够大，因此不需要每次有数据更新就必须将数据写入到磁盘中，而可以先将最新的数据驻留在内存中，等到积累到最后多之后，再使用归并排序的方式将内存内的数据合并追加到磁盘队尾
- HBase读取首先会在缓存（BlockCache）中查找，它采用了LRU（最近最少使用算法），如果缓存中没找到，会从内存中的MemStore中查找，只有这两个地方都找不到时，才会加载HFile中的内容，而上文也提到了读取HFile速度也会很快，因为节省了寻道开销。
-
Redis 了解？
底层基于跳表实现，就是链表+多级索引，通过多级索引快速定位用户查找的元素， 链表本来查询速度O(N),通过增加多级索引可使 跳表查询、插入、删除的时间复杂度为O(log n)，与平衡二叉树接近； -
窗口函数了解及使用场景
223
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
