面试数仓必须要会的标准回答

有很多新手小白还是不是很清楚如何去介绍自己做的项目以及在面试中需要回答的问题

在这里我抽取了几个面试环节的必答题希望对大家有帮助!


前言

随着大数据的大火,现在市场的空缺越来越大,很多朋友都想转行大数据,我也刚好从事大数据行业项目,每日更新一些非常重要的知识点希望对大家有帮助

=

一、请简单介绍一下的你的项目

一般去公司面试,面试官都会问你些关于大数据的问题,以及你从事的行业,如果回答不上来基本就会凉凉 在这里写一些通用模板

模板:

          面试官您好, 我最近做了一个XXX项目, 当时主要是给XXX公司做的一个关于零售行业的项目, 项目的架构情况
        后面描述这个项目的基本情况,整体做了那些工作, 项目团队与多少个人, 负责我们大数据开发有几个人等一些基本情况, 我在这个项目中主要参与了哪一部分的工作

完整回答(5-8分钟后即可):

        面试官你好,我在最近做了一个亿万商品项目,当时主要给胖东来商贸集团做的一个汇总零售行业的项目,在这个项目里我们是基于cloudera manger搭建的大数据分析平台,在此平台上我们搭建有 hadoop hive oozie sqoop hue zookeeper 等协议大数据相关的组件,首先我们和甲方进行沟通拿到源数据,在这里我们还把数据分成了不同的模块以方便后面查找数据和调取数据,之后我们将数据导入到Oracle和Mysql中 因为考虑到数据的安全性所以我们将订单数据和支付数据存储等到Oracle中像用户模块和购物车模块我们通常存储在mysql中,之后通过sqoop将数据导入到HDFS上,基于HIVE构建ODS,DWS,DWB等数据仓库的建设,再基于presto完成统计分析的操作完成统计分析的操作,最后将统计的数据用presto来导入到mysql在这里我们也试着尝试用impala去导出数据但是存在一些瑕疵,还是选择了presto来导出 最终是通过finebi完成图表展示, 整个项目是统一基于oozie完成定时调度操作, 基于CM完成各个软件的监控管理,在这个项目中我们将整个阶段划分为两个并且对全国34家胖东来超市以及4家胖东来商场和一家胖东来家具城进行数据分析,在第一阶段中我们首先完成了初期的大数据平台的构建建初期我们只有11台机器,并且还要去完成调度平台的搭建工作,之后将源数据进行数据迁移把数据导入到Hadoop上,

我们还将整个整个销售主题的建模进行分析和操作,最后实现业务的基础销售需求指标,在第一阶段里我们的团队一共有5人 一位项目经理,3个大数据开发工程师,以及1名数据分析师共同分配完成整个项目在这一阶段我们用时2个月完成用了在这里我们主要利敏捷开发将一个大的项目分为多个小的小项目完成

        在第二阶段我们由于数据量的增大我们完成了集群的扩容将原来的11台机器扩容到28台机器

同时还完成了presto集群的搭建完成了整个数据的迁移工作 完成以销售为主题的用户 商品 促销模块满足了公司90%以上的数据需求和报表并且可支持财务的成本和利润 在这阶段总共打配有7人1为项目经理 和4位大数据工程师和2名数据分析师并且提前完成任务用时2个月在这个项目中历史5年数据为17.5tb冗余数据为65tb每日新增9.5gb左右

        

二、请描述在你的这个项目中, 你是如何完成数据采集工作的,包含全量和增量: 8分钟 (6~10分钟)

完整回答:

是这样子的在进行数据采集的时候,我首先考虑的是将数据和数据源的粒度保持相同,并且考虑到数据源有哪些表,那么我们在采集数据的时候考虑有哪些表,表中有哪些字段,在进行导入的时候还需要考虑表的同步方式以及是否需要构建分区表以及是否要采取分桶表和表怎么压缩等问题,以及考虑每一个字段的作用因为在后续的DWS中我需要什么样的字段来进行判断和聚合这都是要考虑的

首先我会考虑到每个表需要用什么样的同步方式:

在面对一些地区表或者日期表我采取全量覆盖的方式来采取数据 因为在全量覆盖的时候不需要构建分区表每次都是将源数据覆盖在一个表中因为数据量不是很大,而且不需要维护

如果我碰见的一些表只有新增的话我会采取构建分区表 比如商品贫家表以及用户登录日志表 因为再考虑到仅新增的时候需要构建分区表并且采取以日期分区 时间的设置一般和更新有关 因为数据量庞大 而且只有新增 无需关心变化

在分析一些表的时候会发现有些表的数据既有新增比如订单表 购物车表又有修改的时候 我会采取拉链表的形式进行存储因为并且按天分区因为数据存在历史变更情况 再导入数据时需要将 新增和更新的数据进行区分导入到相应的区内

这些是我首要分析的三点其次对于表的存储方式,以及是否进行压缩也要去考虑 对于数据的储存格式在这个项目中基本上是按照orc来存储的同时一小部分数据是用textfile从hdfs上导入过来的

另外一个好的项目也要选对压缩方案 在这里呢 我是主要采取ZLIB和SNAPPY进行压缩如果数据写入次数大一读取次数我会采取ZLIB 或者GZ来进行压缩因为更节省空间压缩率也是很高,如果当表中的数据读写次数大于写入次数的时候我会采取snappy的形式进行压缩在这个项目中只有ODS我是采用ZIib进行压缩文件剩下的我用的都是Snappy

在这些分析中我都是一环套一环的进行数据采取的 在下面我会去考虑构建表的时候是创外表还是内标如果数据有控制权我会创建外表来保证数据的安全 如果没有则我用内表创建同时考虑是否构建分区表因为有些数据是需要进行分区同时分区表也能减少扫面的次数而提高查找的性能,同时呢因为数据量很大,难免会发生数据倾斜,在这里我会设置sql语句来避免数据发生倾斜发生,同时当我对一些表进行关联的时候有时候会发生数据效率低下 笛卡尔积过于高在这里我会设置分桶表来减少笛卡尔积 提高性能 并且在整个项目完成要对数据进行抽样调查看数据是否达到预期值我也会利用分桶来进行数据的采样

综上所述来进行数据的采集工作

3.请简单介绍一下HDFS的数据读写流程

1.首先客户端发送请求 获取块信息的位置 

2.然后namenode会进行一系列检查 比如文件是否存在 是否有权限获得

3.namenode返回datanode所存储的块信息

4.客户端找到最近的datanode 读取数据 每次读取一个packet大小的数据如果第一个datanode不能用的时候那么则找离客户端最近的第二个数据并且是异步的

5.最后关闭客户端 并且汇报不能用的datanode

1客户端数据由dlstributefilesystem保存然后发送请求 请求 上传保存数据

namenode会先去核实信息是否存在 检查路径 并且说可以保存

3.写入数据写入到fsdataoutputstream然后写入packet 

当第一个packet写入后换回一个ack应答 接收应答并且读取下一个数据接受到了数据会复制给其他的node 不过复制数据 是异步的

当第一块数据写入后 创建第二个block 接着写入数据 循环往复数据写入完后会关闭 

最后向namenode确认是否保存完成

4.请简单描述一下zookeeper中提供四种节点有那些, 以及特点是什么

(1)PERSISTENT-持久节点

除非手动删除,否则节点一直存在于 Zookeeper 上

( 2 ) EPHEMERAL- 临时节点
 临时节点的生命周期与客户端会话绑定,一旦客户端会话失效(客户端与 zookeeper 连接断开不一定会话失效),那么这个客户端创建的所有临时节点 都会被移除。
( 3 ) PERSISTENT_SEQUENTIAL- 持久顺序节点
基本特性同持久节点,只是增加了顺序属性,节点名后边会追加一个由父节点维 护的自增整型数字。
( 4 ) EPHEMERAL_SEQUENTIAL- 临时顺序节点
基本特性同临时节点,增加了顺序属性,节点名后边会追加一个由父节点维护的 自增整型数字。

zookeeper原文链接:https://blog.youkuaiyun.com/weixin_43882788/article/details/122077076
————————————————
 


<think>好的,用户现在想要了解在数仓工作中如何进行据治理,以及常见的面试题。之前我已经帮他整理过数仓工程师的岗位介绍和据治理的文档框架,所以这次需要更深入具体的据治理方法和面试问题。 首先,我需要确认用户的需求。他可能正在准备面试,或者在工作中需要实施据治理,所以需要实用的步骤和常见的面试题目。用户可能已经有一定的基础,但需要更详细的执行方案和面试准备资料。 接下来,关于据治理的实施部分,我应该分步骤详细说明,结合之前的框架,但更具体。比如,据质量管理、元据管理、据安全、主据管理、据生命周期管理和据治理流程。每个部分需要给出具体的措施和例子,比如据质量中的校验规则,或者元据管理工具。 然后是面试题部分,需要覆盖据治理的基本概念、实施方法、工具使用、问题解决和经验案例。问题要分层次,从基础到进阶,可能用户需要应对不同难度的面试。例如,基础问题可能涉及据治理的目标,进阶问题可能涉及实际场景的处理,比如历史系统改造中的技术债务。 还要考虑用户可能的隐藏需求,比如如何展示自己的项目经验,或者在面试中如何回答行为问题。因此,在面试题中加入项目经验的问题,并给出回答建议,比如STAR法则。 需要确保回答结构清晰,分点明确,便于用户理解和应用。同时,使用之前的格式,比如分点、加粗标题、代码块和表格,保持一致性。还要注意使用中文,避免术语混淆,必要时解释缩写,比如SCD(缓慢变化维度)。 最后,检查内容是否符合用户需求,是否覆盖了据治理的关键点和常见面试问题,确保信息准确,没有遗漏重要部分。例如,据治理的步骤是否全面,面试题是否涵盖理论和实践,工具推荐是否包括开源和商业选项等。</think>以下为据治理实施方法与数仓岗位常见面试题整理,分为两大模块: --- # **I. 数仓场景下的据治理实施方法** ## 1. **治理实施框架** ```mermaid graph LR A[据治理] --> B[建立组织] A --> C[制定标准] A --> D[落地工具] A --> E[持续监控] ``` ## 2. **六大核心治理领域** ### 2.1 据质量管理 - **实施步骤**: 1. 定义质量维度(完整性/准确性/及时性) 2. 配置检测规则(如订单金额>0,用户年龄≤120) 3. 构建自动化报警(钉钉/邮件通知阈值:$ErrorRate \geq 5\%$) 4. 闭环修复流程(自动打标+人工复核) ### 2.2 元据管理 - **典型实践**: - 使用Apache Atlas构建血缘关系(表A → ETL任务 → 表B) - 维护指标字典(例:GMV=Σ(订单实付金额) 排除退款订单) ### 2.3 据安全控制 - **关键措施**: - 敏感字段加密(AES-256算法加密手机号) - 权限分级(开发人员仅见脱敏据:张三 → 张*) - 审计日志(记录所有$SELECT * FROM user_info$查询) ### 2.4 主据管理 - **实施重点**: - 统一客户ID映射(CRM系统ID ↔ 电商系统ID) - 解决SCD(缓慢变化维度)问题(类型2:新增版本记录) ### 2.5 据生命周期 - **管理策略**: - 热据:Hive分区表保留3年($dt=20230101$) - 冷据:转存至OSS/Glacier,成本降低$\frac{2}{3}$ ### 2.6 治理流程落地 - **协作机制**: - 变更评审会(涉及Schema修改需三方会签) - 据认责体系(每个指标明确Owner) --- # **II. 数仓工程师高频面试题** ## 1. **据治理基础** - **基础问题**: - 解释据治理的4A原则(可用性/Availability, 可访问性/Accessibility, 准确性/Accuracy, 敏捷性/Agility) - 星型模型 vs 雪花模型的适用场景差异 - 如何验证据清洗后的质量?(需答出抽样对比、业务规则校验等方法) - **进阶问题**: - 现有系统存在大量重复表(user_info_v1, user_info_v2...),如何治理? - 当业务部门不配合标准制定时,如何处理? - 设计一个实时据质量监控系统架构 ## 2. **技术实践类** ### SQL考察 ```sql /* 找出近30天购买次Top10但退货率>20%的用户 */ SELECT user_id, COUNT(order_id) AS order_count, SUM(CASE WHEN status='returned' THEN 1 ELSE 0 END)*1.0/COUNT(*) AS return_rate FROM orders WHERE dt BETWEEN CURRENT_DATE-30 AND CURRENT_DATE GROUP BY user_id HAVING order_count >= 5 AND return_rate > 0.2 ORDER BY order_count DESC LIMIT 10; ``` ### 场景设计 **题目**:某APP日活突然下降30%,如何通过库定位问题? **考察点**: 1. 检查据采集是否异常(埋点丢失率) 2. 维度下钻分析(新老用户/地区/渠道维度) 3. 关联外部据(是否竞品活动、服务器故障) ## 3. **工具与架构** - Hive如何实现据去重?(对比`distinct` vs `group by`执行效率) - 解释Lambda架构中批处理层与速度层的据合并逻辑 - 如何优化缓慢变化维(SCD)的存储效率? ## 4. **行为面试** - **项目深挖**: "请描述你处理过最复杂的据质量问题" **回答框架**: 1. 问题背景(错误据量级) 2. 根因分析(使用据血缘工具定位到ODS层接口变更) 3. 解决措施(回补据+增加校验规则) 4. 后续预防(建立变更评审机制) --- # **III. 关键工具推荐** ```python # 据质量检查伪代码示例 def check_null_rate(table, column, threshold=0.3): null_cnt = spark.sql(f"SELECT COUNT(*) FROM {table} WHERE {column} IS NULL").collect()[0][0] total_cnt = spark.sql(f"SELECT COUNT(*) FROM {table}").collect()[0][0] rate = null_cnt / total_cnt if rate > threshold: send_alert(f"空值率超标: {rate:.2%} > {threshold:.0%}") ``` **工具矩阵**: | 场景 | 开源方案 | 商业方案 | |--------------|-------------------|-------------------| | 据质量 | Great Expectations | Talend DQ | | 元据管理 | Apache Atlas | Collibra | | 据目录 | DataHub | Alation | | 权限管控 | Ranger | Immuta | --- **应对建议**: 1. 面试中重点展现**治理闭环思维**(发现问题 → 分析根因 → 实施解决 → 建立机制) 2. 准备1-2个真实治理案例,按STAR法则叙述 3. 关注行业规范(如《DCMM据管理能力成熟度评估模型》)
评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值