1 介绍一下自己
2 介绍一下Hadoop生态圈的技术
3 看你做了财务数据,能说说你们财务数据是怎么建设的吗
4 平时有遇到数据不准和脏数据问题吗,怎么解决的,起夜处理过吗
5 对于数据倾斜和数据治理怎么弄的
6 看你做过实时,为啥要做实时任务,离线的数据不能解决吗,实时成本怎么控制,延迟了怎么解决,有遇到过延迟问题吗
7有什么想问我的
题目来源:牛客网
答案如下:
1. 介绍一下自己
考察知识点
- 自我认知与岗位匹配度(经历、技能、目标与岗位的契合度)
- 表达逻辑性(能否简洁突出核心信息)
参考回答
我是XX大学数据科学专业的应届生,有6个月电商数据开发实习经历,核心聚焦数据仓库搭建和实时数据链路开发。
技术上,熟练掌握Hadoop生态(HDFS/Hive/Spark/Flink)、SQL(Hive SQL/MySQL)和数据建模,参与过两个核心项目:一是设计财务数据数仓,从业务库同步科目数据,清洗后构建DWD明细层和DWS汇总层,支撑财务报表自动化,将报表生成时间从3天缩短至4小时;二是搭建实时GMV监控链路,用Flink+Kafka处理订单流,解决数据倾斜问题(通过加盐打散大key),实现延迟控制在500ms内。
职业上,希望深耕零售行业数据开发,贵司在供应链数据和实时分析的布局很吸引我,也符合我“技术+业务”双成长的规划。
注意要点
- 控制在1-2分钟,按“教育→技能→核心项目→职业目标”结构,避免流水账;
- 每个经历关联具体技术(如Flink)和业务成果(如“报表时间缩短”),体现与岗位的匹配;
- 结尾关联公司业务,展现求职诚意。
2. 介绍一下Hadoop生态圈的技术(含广义/狭义概念澄清)
考察知识点
- Hadoop生态圈“狭义”与“广义”的核心区别
- 各层级组件的定位、归属及协同关系
- Spark在生态圈中的角色(是否属于、为何属于)
参考回答
Hadoop生态圈的定义需区分狭义和广义,核心差异在于“是否包含Apache Hadoop项目外的周边工具”,两者的组件构成及Spark的归属如下:
一、先澄清:狭义 vs 广义Hadoop生态圈
维度 | 狭义Hadoop生态圈 | 广义Hadoop生态圈 |
---|---|---|
定义 | 仅指Apache Hadoop项目本身包含的核心模块,是生态的“基础骨架” | 以狭义Hadoop为核心,扩展的所有分布式存储/计算/工具类项目,是完整的“数据处理生态系统” |
核心目标 | 解决分布式环境下的“大文件存储”和“批量计算”基础问题 | 覆盖数据采集、存储、计算、调度、治理等全链路需求 |
归属原则 | 仅包含Apache Hadoop社区官方维护的核心模块 | 包含所有“依赖Hadoop核心能力(如HDFS/YARN)”或“与Hadoop协同工作”的周边项目 |
二、分场景拆解生态圈组件
(1)狭义Hadoop生态圈(核心骨架,仅3大模块)
即Apache Hadoop项目官方包含的核心组件,是整个生态的基础:
- HDFS(Hadoop Distributed File System)
- 定位:分布式文件系统,解决“海量大文件存储”问题(单文件通常GB/PB级,默认块大小128MB/256MB)。
- 架构:NameNode(管理元数据)+ DataNode(存储实际数据)+ SecondaryNameNode(辅助元数据合并),通过多副本(默认3份)保障高容错。
- MapReduce
- 定位:分布式批处理计算引擎,是Hadoop早期唯一的计算组件,解决“海量数据离线批量计算”问题(如日志清洗、数据统计)。
- 局限:基于磁盘计算,延迟高(小时/天级),仅支持批处理,后续逐渐被Spark等引擎替代。
- YARN(Yet Another Resource Negotiator)
- 定位:分布式资源管理器,负责为整个Hadoop集群分配CPU、内存等资源,调度各类计算任务(MapReduce、Spark、Flink等)。
- 作用:实现“资源共享”,让多个计算引擎(如Spark和MapReduce)可同时运行在同一集群,提升资源利用率。
(2)广义Hadoop生态圈(全链路生态,含周边工具)
以狭义Hadoop的HDFS(存储)和YARN(调度)为基础,扩展出覆盖“数据采集→存储→计算→调度→治理”的全链路工具,核心组件包括:
功能层 | 核心组件 | 定位与作用(是否依赖Hadoop核心) |
---|---|---|
数据采集 | Kafka、Flume、Sqoop | - Kafka:分布式消息队列,高吞吐低延迟,用于采集业务日志/数据库变更(依赖YARN调度,数据可落地HDFS);<br>- Flume:日志采集工具,从服务器采集日志写入HDFS;<br>- Sqoop:关系型数据库(MySQL/Oracle)与HDFS的数据同步工具。 |
分布式存储 | HDFS、HBase | - HDFS:狭义核心,存储大文件;<br>- HBase:分布式NoSQL数据库,基于HDFS存储,适合随机读写小文件(如用户画像标签)。 |
计算引擎 | MapReduce、Spark、Flink | - MapReduce:狭义核心,离线批处理;<br>- Spark:基于内存的计算引擎(依赖HDFS存储数据、YARN调度资源),支持批处理(Spark Core)、SQL(Spark SQL)、流处理(Spark Streaming),速度比MapReduce快10-100倍;<br>- Flink:实时计算引擎(依赖HDFS存储Checkpoint、YARN调度),支持毫秒级流处理(如实时GMV监控)。 |
数据仓库 | Hive、Hivemall | - Hive:基于Hadoop的数据仓库工具(依赖HDFS存储、MapReduce/Spark执行计算),通过HQL(类SQL)实现离线数据分析(如财务报表)。 |
协调与调度 | Zookeeper、Oozie | - Zookeeper:分布式协调服务,为HDFS(HA选主)、Kafka(Broker管理)提供一致性支持;<br>- Oozie:工作流调度工具,调度Hive/Spark任务按依赖执行(如“先同步数据,再计算报表”)。 |
数据治理 | Apache Griffin、Atlas | - Griffin:数据质量监控工具,监控HDFS/Hive中数据的准确性、完整性;<br>- Atlas:元数据管理工具,记录Hive表血缘、字段定义。 |
(3)关键结论:Spark属于广义Hadoop生态圈
- 从狭义看:Spark不属于Apache Hadoop项目的核心模块(狭义仅含HDFS/MapReduce/YARN),是独立的计算引擎项目。
- 从广义看:Spark是Hadoop生态圈的核心组件——它依赖HDFS存储数据(如读取HDFS上的日志文件),依赖YARN调度资源(在YARN上启动Executor执行任务),且与Hive、Kafka等生态工具深度协同,是替代MapReduce的主流计算引擎,完全融入Hadoop生态的技术体系。
三、生态圈协同示例(以“用户行为分析”为例)
- 数据采集:Flume采集APP日志→Kafka暂存;Sqoop同步MySQL用户表→HDFS;
- 数据存储:日志和用户表持久化到HDFS,实时标签存储到HBase;
- 计算处理:Spark读取HDFS数据,执行离线用户行为分析(如用户留存率),结果写入Hive;Flink消费Kafka日志,实时计算用户实时点击TOP10商品;
- 资源调度:Spark和Flink任务由YARN统一分配CPU/内存;
- 分析输出:通过Hive SQL生成用户行为报表,供运营查看。
注意要点
- 面试中需主动区分“狭义/广义”:避免直接说“Spark属于/不属于Hadoop生态圈”,先澄清概念,再说明归属(广义属于,依赖HDFS/YARN;狭义不属于,独立项目)。
- 核心逻辑:判断组件是否属于广义生态圈,关键看“是否依赖Hadoop核心能力(HDFS存储、YARN调度)或与生态工具协同”,而非是否属于Apache Hadoop官方项目。
- 避免误区:Flink、HBase等虽为独立项目,但因深度依赖HDFS/YARN,均属于广义Hadoop生态圈,体现生态的“开放性”和“扩展性”。
3. 能说说你们财务数据是怎么建设的吗
考察知识点
- 财务数据的特殊性(合规性、准确性要求)
- 数据建设的流程(分层、同步、建模)
- 业务支撑场景(报表、分析、监控)
参考回答
我们财务数据建设核心围绕“合规性、准确性、可追溯”,分“数据接入→清洗建模→应用输出”三阶段,采用经典数仓分层架构:
- ODS层(原始层):
- 数据源:财务系统(如SAP)的科目表、凭证表、余额表,以及业务系统的订单支付数据(关联财务的收入确认)。
- 同步方式:① 批量同步:用Sqoop每天凌晨同步SAP的MySQL数据至Hive(按日期分区,保留原始字段,如
ods_sap_voucher_${dt}
);② 实时同步:用Debezium捕获订单支付表的binlog,通过Kafka同步至Flink,用于实时营收监控。 - 关键点:完全保留原始数据(包括删除标记、异常状态),支持数据回溯(如审计时核对原始凭证)。
- DWD层(明细层):
- 核心操作:① 清洗:过滤无效数据(如凭证号为空、金额为负的异常记录);② 脱敏:对敏感字段(如供应商银行账户)加密;③ 标准化:统一字段格式(如日期统一为
yyyy-MM-dd
,金额保留2位小数);④ 关联补全:用凭证表的account_id
关联科目字典表,补充科目名称(如“1001→库存现金”)。 - 输出表:
dwd_fin_voucher_detail
(凭证明细,含清洗后的科目、金额、业务类型)。
- 核心操作:① 清洗:过滤无效数据(如凭证号为空、金额为负的异常记录);② 脱敏:对敏感字段(如供应商银行账户)加密;③ 标准化:统一字段格式(如日期统一为
- DWS层(汇总层):
- 按业务主题聚合:① 科目余额汇总(按
account_id+dt
聚合,计算每日余额);② 收支汇总(按business_type+dt
聚合,区分营收、成本、费用);③ 部门费用汇总(按dept_id+month
聚合,支撑部门预算监控)。 - 关键点:保留聚合逻辑的可追溯性(如每个汇总指标都关联明细层的计算口径文档)。
- 按业务主题聚合:① 科目余额汇总(按
- ADS层(应用层):
- 输出形式:① 固定报表(如“月度利润表”“部门费用超标预警表”,通过Superset展示,供财务人员查看);② 数据API(如给业务部门的“区域营收接口”,支持业务方自助查询)。
- 质量保障:每天与财务系统的手工报表核对核心指标(如总营收差异率<0.1%),不一致时通过数据血缘回溯至DWD层排查。
整个建设过程中,财务部门全程参与口径定义(如“营收确认时点=支付成功时间”),确保数据符合会计准则和业务实际。
注意要点
This post is for subscribers on the 网站会员 and 成为小万的高级会员 tiers only
Subscribe NowAlready have an account? Sign In