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项目官方包含的核心组件,是整个生态的基础:

  1. HDFS(Hadoop Distributed File System)
    • 定位:分布式文件系统,解决“海量大文件存储”问题(单文件通常GB/PB级,默认块大小128MB/256MB)。
    • 架构:NameNode(管理元数据)+ DataNode(存储实际数据)+ SecondaryNameNode(辅助元数据合并),通过多副本(默认3份)保障高容错。
  2. MapReduce
    • 定位:分布式批处理计算引擎,是Hadoop早期唯一的计算组件,解决“海量数据离线批量计算”问题(如日志清洗、数据统计)。
    • 局限:基于磁盘计算,延迟高(小时/天级),仅支持批处理,后续逐渐被Spark等引擎替代。
  3. 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生态的技术体系。

三、生态圈协同示例(以“用户行为分析”为例)

  1. 数据采集:Flume采集APP日志→Kafka暂存;Sqoop同步MySQL用户表→HDFS;
  2. 数据存储:日志和用户表持久化到HDFS,实时标签存储到HBase;
  3. 计算处理:Spark读取HDFS数据,执行离线用户行为分析(如用户留存率),结果写入Hive;Flink消费Kafka日志,实时计算用户实时点击TOP10商品;
  4. 资源调度:Spark和Flink任务由YARN统一分配CPU/内存;
  5. 分析输出:通过Hive SQL生成用户行为报表,供运营查看。

注意要点

  1. 面试中需主动区分“狭义/广义”:避免直接说“Spark属于/不属于Hadoop生态圈”,先澄清概念,再说明归属(广义属于,依赖HDFS/YARN;狭义不属于,独立项目)。
  2. 核心逻辑:判断组件是否属于广义生态圈,关键看“是否依赖Hadoop核心能力(HDFS存储、YARN调度)或与生态工具协同”,而非是否属于Apache Hadoop官方项目。
  3. 避免误区:Flink、HBase等虽为独立项目,但因深度依赖HDFS/YARN,均属于广义Hadoop生态圈,体现生态的“开放性”和“扩展性”。

3. 能说说你们财务数据是怎么建设的吗

考察知识点

  • 财务数据的特殊性(合规性、准确性要求)
  • 数据建设的流程(分层、同步、建模)
  • 业务支撑场景(报表、分析、监控)

参考回答

我们财务数据建设核心围绕“合规性、准确性、可追溯”,分“数据接入→清洗建模→应用输出”三阶段,采用经典数仓分层架构:

  1. ODS层(原始层)
    • 数据源:财务系统(如SAP)的科目表、凭证表、余额表,以及业务系统的订单支付数据(关联财务的收入确认)。
    • 同步方式:① 批量同步:用Sqoop每天凌晨同步SAP的MySQL数据至Hive(按日期分区,保留原始字段,如ods_sap_voucher_${dt});② 实时同步:用Debezium捕获订单支付表的binlog,通过Kafka同步至Flink,用于实时营收监控。
    • 关键点:完全保留原始数据(包括删除标记、异常状态),支持数据回溯(如审计时核对原始凭证)。
  2. DWD层(明细层)
    • 核心操作:① 清洗:过滤无效数据(如凭证号为空、金额为负的异常记录);② 脱敏:对敏感字段(如供应商银行账户)加密;③ 标准化:统一字段格式(如日期统一为yyyy-MM-dd,金额保留2位小数);④ 关联补全:用凭证表的account_id关联科目字典表,补充科目名称(如“1001→库存现金”)。
    • 输出表:dwd_fin_voucher_detail(凭证明细,含清洗后的科目、金额、业务类型)。
  3. DWS层(汇总层)
    • 按业务主题聚合:① 科目余额汇总(按account_id+dt聚合,计算每日余额);② 收支汇总(按business_type+dt聚合,区分营收、成本、费用);③ 部门费用汇总(按dept_id+month聚合,支撑部门预算监控)。
    • 关键点:保留聚合逻辑的可追溯性(如每个汇总指标都关联明细层的计算口径文档)。
  4. ADS层(应用层)
    • 输出形式:① 固定报表(如“月度利润表”“部门费用超标预警表”,通过Superset展示,供财务人员查看);② 数据API(如给业务部门的“区域营收接口”,支持业务方自助查询)。
    • 质量保障:每天与财务系统的手工报表核对核心指标(如总营收差异率<0.1%),不一致时通过数据血缘回溯至DWD层排查。

整个建设过程中,财务部门全程参与口径定义(如“营收确认时点=支付成功时间”),确保数据符合会计准则和业务实际。

注意要点

This post is for subscribers on the 网站会员 and 成为小万的高级会员 tiers only

Subscribe Now

Already have an account?