1 先自我介绍

2 数仓模型怎么划分

3 如何评价一个数仓是建设比较好

4 做实时开发遇到延迟问题是怎么解决的,有哪些方面可以优化

5 数据质量监控是怎么设定的,对于质量怎么判断

6 有数据治理吗,治理有啥好处,为啥要治理

7 你认为数据湖和数仓有什么区别,为啥现在很多公司在做湖仓这一套

8 你简历说的画像是怎么实现的,为啥要这样操作,画像能带来什么收益

作者:哈哈哈,你是老六 链接:https://www.nowcoder.com/feed/main/detail/d1301bc81f6149d8a29919b2b51617f5?sourceSSR=search

来源:牛客网

1. 先自我介绍一下

  • 考察知识点:自我认知与岗位匹配度、核心技术栈梳理、项目成果量化能力、求职动机与业务适配。
  • 参考回答:我有 5 年电商领域大数据开发经验,核心聚焦数仓建设、实时数据链路搭建和用户画像体系落地,熟练掌握 Hadoop/Spark/Flink 生态,以及数仓建模(维度建模)、数据治理(元数据 / 质量监控)技能。

过往核心项目:

  1. 主导某 3C 电商数仓重构:按 ODS-DWD-DWS-ADS 分层设计 “订单 - 用户 - 商品” 链路,将数据冗余减少 40%,新增业务需求响应时间从 3 天压缩至 1 天,支撑 618 大促 10 + 核心报表;
  2. 搭建实时 GMV 监控平台:用 Flink CDC 同步 MySQL 订单数据,Kafka 做消息缓冲,ES 存储结果,将数据延迟从 5 分钟降至 10 秒,大促期间助力运营实时调整广告投放,节省成本 300 万;
  3. 落地用户画像体系:设计 120 + 标签(消费能力 / 兴趣偏好等),用 Spark 离线计算 + ClickHouse 存储,支撑精准营销,使高价值用户复购率提升 22%。

了解京东在零售大数据领域的深耕,希望将数仓优化、实时开发经验应用到京东的业务场景中,助力数据驱动决策。

  • 回答注意要点
    1. 必含 “经验年限 + 核心技术 + 电商相关项目”,贴合京东业务;
    2. 项目需 “动作 + 量化成果”(如 “延迟从 5 分钟→10 秒”),避免空泛;
    3. 结尾关联 “京东业务”,体现求职针对性,而非通用模板。

2. 数仓模型怎么划分

  • 考察知识点:数仓分层逻辑(ODS/DWD/DWS 等)、建模模式(星型 / 雪花)、业务适配能力(电商场景落地)。
  • 参考回答:数仓模型划分遵循 “分层存储 + 维度建模” 原则,结合电商 “订单、用户、商品” 核心业务,分为 5 层,每层职责明确且环环相扣:
层级 全称 核心作用(电商场景) 京东 3C 业务案例
ODS 层 操作数据存储层 存放原始数据,保持业务库原貌,仅做轻量清洗(去重、格式统一) 同步 MySQL 的order表(含取消 / 支付 / 退款状态)、Kafka 用户点击日志(JSON 格式)
DWD 层 数据明细层 按业务过程拆分明细表,清洗异常数据(如金额 < 0),补充基础维度属性 dwd_order_pay(仅保留支付成功订单,补充支付方式、所属仓库 ID)、dwd_user_click(过滤 1 秒内重复点击)
DWS 层 数据服务层 按实体(用户 / 商品 / 商家)聚合宽表,预留扩展字段,支撑上层灵活查询 dws_user_30d(用户近 30 天消费金额、下单次数、偏好品牌)、dws_goods_7d(商品近 7 天销量、加购率)
ADS 层 应用数据层 针对具体业务场景(报表 / 看板 / 算法)生成结果数据,直接供下游使用 618 大促实时 GMV 看板数据、“抖音渠道新客转化率报表”、推荐算法用的 “用户商品偏好表”
公共维度层 维度表集合 存放通用维度(用户 / 商品 / 时间 / 渠道),确保全仓维度逻辑一致,避免重复建模 dim_user(用户 ID、等级、注册时间)、dim_goods(商品 ID、分类、品牌、价格带)

建模模式优先用 “星型模型”:以事实表(如dwd_order_pay)为核心,关联 4-5 个维度表(用户 / 商品 / 时间 / 渠道),避免雪花模型的多表嵌套,查询效率提升 30%。

  • 回答注意要点
    1. 分层需 “对应电商业务场景”(如 3C 商品、大促订单),避免纯理论;
    2. 说明每层 “为什么存在”(如 DWD 层拆分明细是为了清洗异常数据),体现分层价值;
    3. 提及建模模式(星型 / 雪花),并解释选择原因(如星型模型查询快,适配电商高频报表需求)。

3. 如何评价一个数仓是建设得比较好

  • 考察知识点:数仓质量评估维度(一致性 / 效率 / 稳定性)、业务价值量化、技术指标落地。
  • 参考回答:评价数仓质量需兼顾 “技术指标” 和 “业务价值”,核心看 5 个可量化维度:
  1. 指标一致性(解决 “数据打架”)
    • 标准:同一指标(如 GMV)在不同部门(运营 / 财务)的计算结果差异率≤3%;
    • 落地:通过 “指标字典” 定义 GMV=∑实付金额(排除取消 / 退款订单),统一计算逻辑后,运营与财务的 GMV 差异从 12% 降至 1.5%。
  2. 查询效率(支撑高频场景)
    • 标准:90% 的 ADS 层报表查询≤10 秒,DWS 层宽表关联查询≤30 秒;
    • 优化:对dws_user_30d按用户 ID 分 100 桶、按月份分区,“用户消费明细查询” 从 5 分钟压缩至 8 秒。
  3. 业务响应速度(适配快速迭代)
    • 标准:新增业务需求(如 “视频号渠道新客转化分析”)从需求提出到数据产出≤2 天;
    • 支撑:DWS 层宽表预留扩展字段(如channel_type),新增渠道只需关联维度表,无需重构底层。
  4. 稳定性(保障核心场景不宕机)
    • 标准:核心任务(如订单数据同步、GMV 计算)SLA 达标率≥99.9%(全年故障时长≤52 分钟);
    • 措施:关键链路加监控(数据量波动超 20% 发企业微信告警)、主备任务冗余,618 大促期间零故障。
  5. 业务价值(数据驱动决策)
    • 量化:通过数仓支撑的 “精准营销” 提升转化率 15%+,“库存预警” 降低滞销率 20%+;
    • 案例:基于dws_user_30d的 “高价值流失预警用户” 标签,推送专属优惠券,用户召回率提升 22%。
  • 回答注意要点
    1. 每个维度需 “量化标准 + 落地案例”,避免说 “查询快、稳定” 等模糊表述;
    2. 关联电商核心场景(大促、精准营销),体现与京东业务的适配性;
    3. 突出 “业务价值”(如提升转化率、降低成本),而非仅谈技术指标。

4. 做实时开发遇到延迟问题是怎么解决的,有哪些方面可以优化

  • 考察知识点:实时数据链路(采集 - 计算 - 存储)优化、资源配置、问题排查能力、大促场景适配。
  • 参考回答:实时延迟(如 Flink 任务延迟)需从 “采集→计算→存储→资源” 全链路拆解,以 “京东 618 订单实时监控” 为例(原延迟 5 分钟,优化后 10 秒):
  1. 采集层:减少源头阻塞(MySQL→Kafka)
    • 问题:订单峰值 2000 单 / 秒,MySQL binlog 日志堆积,CDC 同步延迟;
    • 优化:① 用 Flink CDC 2.0 替代 Canal,支持并行读取(按表分区拆分为 4 个同步任务);② 调整 MySQL binlog 格式为 ROW(减少日志体积),保留时间从 7 天缩至 3 天(降低磁盘 IO);③ 新增 binlog 监控,堆积超 10 万条立即告警。
  2. 计算层:提升 Flink 处理效率
    • 问题:Flink TaskManager 处理瓶颈,窗口计算(5 分钟滚动窗口)耗时久;
    • 优化:① 增加并行度(从 8→32,与 Kafka Topic 分区数一致);② 状态后端改用 RocksDB(替代 Memory,支持大状态存储,避免 OOM);③ 调整 Checkpoint 间隔(从 1 分钟→3 分钟,减少 Checkpoint 对计算的阻塞);④ 前置过滤(在map算子中过滤测试订单,数据量减少 15%)。
  3. 存储层:优化 ES 写入与查询
    • 问题:实时结果写入 ES 后,运营看板查询延迟(如 “实时 GMVTOP10 商品” 查 30 秒);
    • 优化:① ES 索引按 “小时” 分片(避免单索引数据量超 50GB);② 对order_time字段建倒排索引,查询时强制指定时间范围;③ 热点商品(如 iPhone 15)单独建索引,查询速度提升 5 倍。
  4. 资源层:动态适配峰值需求
    • 问题:大促峰值时 Flink CPU 利用率达 95%,任务排队;
    • 优化:① 启用 K8s 动态扩缩容(TaskManager 从 10 个→50 个,10 分钟内完成扩容);② 调整 Executor 内存(从 4G→8G),避免内存不足导致的任务重启。

优化效果:端到端延迟从 5 分钟→10 秒,大促期间运营可实时调整广告投放,无效投放成本降低 30%。

  • 回答注意要点
    1. 按 “链路环节” 拆解,每个环节需 “问题 + 具体优化动作 + 参数 / 工具”(如 Flink CDC 2.0、RocksDB);
    1. 结合 “大促峰值场景”,贴合京东 618 / 双 11 业务特点;
    2. 用 “延迟时间、成本降低” 等量化效果,证明优化价值。

5. 数据质量监控是怎么设定的,对于质量怎么判断

  • 考察知识点:数据质量维度(完整 / 准确 / 及时 / 一致)、规则设计、异常处理流程、监控工具落地。
  • 参考回答:数据质量监控围绕 “完整性、准确性、及时性、一致性”4 个核心维度,每个维度设定可量化的规则和阈值,结合电商订单场景落地:
质量维度 核心监控规则(电商订单场景) 判断标准(阈值) 监控工具与处理流程
完整性 ① 订单核心字段(order_id、user_id、amount、pay_time)非空;② 每日订单数≥前 3 天均值的 80% null 率≤0.1%;数据量波动范围 ±20% ① Hive SQL 定时校验(COUNT(CASE WHEN order_id IS NULL THEN 1 END)/COUNT(*));② 超阈值发企业微信告警,数据开发 15 分钟内响应
准确性 ① 订单金额 amount>0;② pay_time≤当前系统时间;③ 订单状态枚举值在 [' 待支付 ',' 已支付 ',' 取消 '] 内 异常值占比≤0.05% Spark 任务每日凌晨跑校验脚本,输出异常明细到data_quality_abnormal表,运营可回溯具体订单
及时性 ① ODS 层订单表同步延迟≤10 分钟(对比 MySQL 业务库数据量);② 实时 GMV 看板数据更新延迟≤30 秒 同步延迟 > 10 分钟告警;看板延迟 > 30 秒告警 ① Flink 任务监控 Checkpoint 完成时间;② 看板加 “延迟监控插件”,超阈值自动刷新任务
一致性 ① 订单表总金额 = 支付表总金额(关联 order_id 校验);② 同一用户的订单数在 DWD 层与 DWS 层一致 金额差异率≤0.5%;计数差异率≤1% 每日跑 “跨层一致性校验 SQL”,输出差异报告,24 小时内定位原因(如计算逻辑错误)

质量判断逻辑:任一维度触发阈值即判定为 “数据质量异常”,按影响范围分级处理:

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

Subscribe Now

Already have an account?