一、自我介绍

1.介绍总体的工作经历，做了哪些项目

2.挑一个近期的项目详细讲解

1）项目的背景/价值

2）项目的数据流向

3）项目的分层（stg,ods,dwd,dim,dws,ads）

4）主要负责的内容

5）突出贡献

各位面试官好（面试官您好），我叫xxx，2018年本科毕业于南昌航空大学软件工程专业，毕业后入职过两家公司，都是差不多2年左右，主要从事的工作内容是离线数据仓库和java后端的开发。第一家公司是北京红山信息研究院有限公司，涉及的项目有2个，一个是跟深圳司法局戒毒所有关的移动轻应用后端项目，另一个是跟陕西天元化工中心智慧工厂数仓大屏项目。上家公司是浙江未讯，涉及的两个主要项目是离线数仓基础设施建设以及基于离线数仓构建的数据应用-运营分析平台。我先说下最近做的运营分析平台项目，如果其他项目您也想了解的话我待会再给您介绍。

易借速贷运营分析平台项目是基于易借速贷app核心系统借贷业务及公司的大数据平台及离线数仓产出的数据产品。

数据源分为3大类：

业务数据：主要来源于APP server，核心信贷系统，风控系统等业务系统。

日志数据：主要是用户行为日志数据。

第三方ftp文件数据：比如地图数据和客服语音文件等。

整体的数据流向：数据采集到hdfs,hdfs提供数据存储，hive +spark提供数据计算，结合分层理论和建模理论对数据进行分层建模，最后数据同步到clickhouse，superset连接clickhouse做统计分析。

数据采集：基于平台可视化页面拖拉拽方式实现，配置采集的数据源，采集方式，目的地，资源及调度时间将数据同步到hdfs作为数据缓冲层供下游使用。

数据分层：包括stg数据缓冲层，ods数据标准层，dwd明细层，dim维表层，temp临时表层，dws轻度汇总层以及ads集市层。

stg: stg数据缓冲层主要是起到灾备的作用，后续任务需要重跑的时候直接到stg层直接取数即可，不需要重新导业务系统拉取数据。

ods: ods数据标准层主要负责数据的清洗过滤，标准化等。比如过滤用户信息中的测试脏数据，日期格式统一标准化为yyyy-MM-dd格式，用户身份信息脱敏，2000大地坐标系统一转换为wgs84坐标系等。

dwd: dwd层主要基于Kimball维度建模理论和领域建模为不同的主题域设计数据模型，存储明细事实表数据供下游使用。我们的主题域有用户域，交易域，流量域，风控域和合同域等等。我主要参与的是交易域的设计。比如交易域的主题模型有OCR认证模型，md5认证模型，用户借款申请模型等等。领域模型主要是用户行为借贷模型。

dim: dim存储的是维度表数据。用于后续的维度分析统计，比如有自定义的日期维度表，用户维度表，贷款产品维度表，渠道维度表等等。

dws: 这一层存储的是轻度汇总层数据，将多个需求公共的派生指标数据放在这一层，可以避免重复计算。我们的指标一般可以分为原子指标（业务过程+度量值+聚合逻辑，比如订单量），派生指标（原子指标+统计周期+业务限定+统计粒度  每天各省份的订单量）和衍生指标（有多个派生指标构成，一般是比率，如MD5认证通过率）。通过onedata这套指标体系标准将我们的需求拆解后，就会存在多个需求共用相同的派生指标，那就可以将业务过程和统计周期以及统计粒度相同的派生指标放在dws层，实现逻辑复用。

ads:  集市层是根据业务需求，基于dws层或者dwd层的数据进行加工，给后续的数据应用使用。

主要工作：

这里我的工作主要是和产品经理对接需求，统一指标口径对需求进行拆解后进行后续的模型设计和指标开发。同时编写相应的接口文档，数据模型文档，详细设计文档等，以及后续问题清单问题的处理及维护工作以及技术调研等。

突出贡献：

然后里面对团队比较有贡献的是用户借贷行为模型的优化。这是模型是用于后续的自定义事件分析，动态报表等功能。

优化之前：

采用的是维度建模的方式，跑批效率很慢，而且数据很难查出来，多个业务过程耦合在一块，维护起来也麻烦。

优化之后：

采用的是领域建模的方式，通过维度建模的方式是直接横向将多个业务过程join起来，耦合度太高，所以导致跑批效率特别慢。所以解决的方式要从耦合度着手，将涉及的业务过程进行纵向拆分，方法是为将多个业务过程进行子域划分，为每个业务过程单独定义一个事件编码，比如借款申请定义事件编码loanApply，这个编码最终最为表的二级分区字段，表的字段包括所有过程的事实字段和维度字段，每个业务过程统计的时候只需要关注自身业务涉及的字段，其它的字段按照数据类型取默认值即可，这个各个业务过程可以是实现并行跑批，提高了跑批效率，同时也方便后续的维护。

二、建模

常用的建模理论：

范式建模：范式建模常用于关系型数据库的设计，在数据仓库中主要应用于数据贴源层，好处是范式级别越高，数据冗余度就越低。

Kimball维度建模：Kimball维度建模主要应用数仓dw层事实表和维度表的设计

事实表建模的步骤：1）选择业务过程-》2）确认粒度-》确认维度-》确认事实

选择业务过程：

事实表是紧紧围绕业务过程进行设计的，为了还原业务细节的，所以每张事实表要先确定对应的业务过程，比如说现在拿到的指标需求是运营那边需要统计md5认证申请次数，通过次数，申请人数，通过人数。那对应的业务过程就是业务流程中借款申请前的md5认证过程。确认业务过程其实就是确定我们到时候统计指标到时候到哪里获取对应的事实数据。

确认粒度：确认粒度就是确认最终事实表的一行记录所表达的含义，原则是粒度越细越好，粒度越细，还原的业务细节就越多，能够支撑的统计需求就越丰富，模型的复用性可以得到提升。

确认维度：确认维度也就是确认事实表中的维度字段，后续需要跟维度表进行关联做各个维度的统计分析，维度一般就对应了事实所发生的环境，可以用5w1h的方式进行定位，比如MD5认证过程就可以定义为谁在什么时间什么地点用了什么设备提交了MD5认证记录，那对应的维度信息就有用户信息，日期，省份，设备类型等等。

确认事实：确认事实也就是确认业务行为产生过程中的度量值，一般都是可累加的字段，比如次数人数金额等等。

维度表设计过程：

如果是比较简单的维度信息，比如性别这种一般就采用维度退化的方式，直接将维度字段退化到事实表中，可以减少表的数量。

而对于大多数单一的维度就可以直接同步过来或者在同步的基础上进行加工即可，比如用户维度表，日期维度表等

对于存在有维度层次关联的维度表，比如贷款商品表，会有一级分类 二级分类的情况，那就以主维表的粒度最最细粒度，然后将其他相关维表的信息通过join的方式拉取到一张大的表中形成最终的维度表。

领域建模：维度建模依赖的建模理论呢还是维度建模，只是多了前期的子域划分的过程，这方面目前还在学习阶段，用的还不是特别熟。

设计原则：通过实体+业务行为来定义主题，主题内部高内聚低耦合

设立思路：

1） 确认实体。

2） 根据业务流程分析实体对应的业务行为。

①    登录

②    借款申请

③    风控认证

④    认证通过

⑤    额度申请

⑥    额度审批

⑦    放款

⑧    逾期

⑨    催收

3） 找出每种业务行为对应的计算来源，属于数据仓库中哪层的哪个表。

4） 确认计算来源后确定最后输出方式，既宽表后续是如何使用的。

5） 根据需求指标和业务行为对应的事实表设计宽表，包括

①    对业务行为进行事件定义：目的是为了作业务的垂直切分，对相同实体的不同业务事件进行分类，起到功能之间解耦的作用，方便后续的使用和维护。方法是在业务数据库中自定义事件表，这样就可以在分析云平台上随意选择事件分析。

②    确定宽表字段：对业务进行事件定义之后，也就确定了宽表的分区字段（业务日期作为一级分区，事件编码作为二级分区），然后确定表的具体字段，方式是按照实体为统计粒度，到每个行为事实表中确定可统计的事实，每个可统计值作为一个字段，汇聚在一起就形成了宽表字段。

③    宽表的算法形成：实体的一种业务行为就对应了一个算法，装载数据的时候其它的业务行为字段取0即可。比如统计用户的下单行为事件，那就到下单事实表中按照用户实体统计相关的事实比如用户下单金额，下单量等，而其它的业务过程字段比如收藏，支付等业务过程设计的事实字段取0即可。这样当需要新增业务行为事件的时候就只需要新增类似的逻辑就行，不需要修改原来的逻辑，遵循了设计模式的OCP原则，起到功能之间解耦的作用。