自我介绍1.1为什么离职？
具体项目3、详细谈数仓建模理论
数仓层次的利弊1、模型层次化
数据模型BDM的缓冲
源业务系统数据的快照、详细数据的存储和每日分区将保留最近的数据。 每个BDM表通常对应于源业务系统中的表或日志文件，而数据结构基本上对应于在线。 大多数数据快照是通过增量提取策略提取的，对于不支持增量提取策略或数据量极少的表采用了总量提取策略。 基础数据模型FDM
一种基础数据模型，用于存储源业务系统中的数据快照并永久存储数据。 对于具有更新操作的数据，使用拉链优化存储。 对于没有更新操作的数据，用流水方式保存。 通用数据模型GDM
按照京东核心业务主题星形模型或雪花模型设计方式建设的最精细业务粒度聚合层。 本层需要进行指标和维度的标准化，保证指标数据的唯一性。 聚合数据模型ADM
按维汇总的数据，使用星型或雪花型模型设计方法根据业务需要构建。 维度模型DIM
可以将维表视为用户分析数据的窗口。 维表包含事实数据表中事实记录的特性，它们既有提供说明性信息的特性，也有指定如何将事实数据表中的数据合并在一起以提供对分析人员有用的信息的特性。 维表包含有助于汇总数据的特性层次结构。 例如，包含订单信息的维表通常包含将订单分为几个类别(例如地区、州和城市)的层次结构。 在维表中，每个表都包含独立于其他维表的事实特性。 例如，“客户”维表包含有关客户层的数据。 维表中的列字段可以将信息分为不同层次结构的结构层。 临时层TMP
用于降低加工工艺计算难度、提高运行效率的临时表，用完即弃，不保存历史数据。
7中间层(运营数据模型) ODM
加工通用模型时，如果需要对多个模型中使用的通用数据进行清洗变换，则封装清洗变换逻辑，保存清洗后的数据，用于通用模型的加工，中间层数据保存历史状态。 应用数据模型APP
针对特定需求设计了APP应用程序数据模型，该数据直接用于前端报告工具，或推送到其他系统以提供相关数据支持。 数仓分层的含义：
明确数据结构体系
数据血缘追踪
减少重复开发和资源浪费(避免烟囱式开发) ) ) ) ) ) ) ) ) ) )。
简化复杂问题
统一数据口径
拉链表的设计和使用场景的优缺点
好处：您可以节约存储空间并随时恢复任何时间段的快照
缺点：拉链的表当然也面临查询性能的问题。 例如，假设我们存储了五年的拉链数据，这个表必然会变大，查询时性能会变低【查询性能差】
场景：某些字段(如订单和用户数据)发生了更改，总体变化很小
SQL优化遇到的场景：
3359 blog.csdn.net/weixin _ 42792621/article/details/112825128
UDF函数理解并使用场景：
3359 blog.csdn.net/weixin _ 42792621/article/details/112825422
京东实时流量数据流动机制：
用户打开京东APP点击流SDK收集用户信息，上报点击流服务端收集数据，一部分实时发送到Kafka，另一部分保存在当前容器的磁盘空间，离线备份。 实时向Kafka发送停机时，离线采用补充消费者消费点击流报告的实时流量数据，进行加工处理后二次发布到其他下游APP应用，简要说明Flink WaterMark机制
见附件
简单谈谈Flink的认知吧
见附件
判断SQL问题是连续洗牌登录员工- wgdxq当初总结面筋，本来把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
为：判断连续四天打卡的员工
确定连续时间的一种技术是将排序的数量减去指定时间之间的差值，从而得到最后一个值(如果连续，则为相同的值；如果不连续，则为不同的值)
选择
uid
，diff_value
，min(login_date ) as login_date_min
，max(login_date ) as login_date_max
、count(1) as nums
来自
（
选择
uid
，login_date
、(row_number ) (over ) partitionbyuidorderbylogin _ date )-datediff ) login_date，‘2020-10-01’() ) ) ) )
来自
测试
) tmp
sgroup 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 父子之间如何 分区一一对应，则为窄依赖，如果一对多，则为宽依赖，宽依赖则会遇到ShuffleJob： 根据Action 和Transform 算子进行划分，遇到Action算子则形成一个JobSpark 任务提交：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上的数据,综合来看,是写的快
Redis 了解？
底层基于跳表实现，就是链表+多级索引，通过多级索引快速定位用户查找的元素， 链表本来查询速度O(N),通过增加多级索引可使 跳表查询、插入、删除的时间复杂度为O(log n)，与平衡二叉树接近；
窗口函数了解及使用场景