2025年数据设计类岗位考试题库及答案

2025年数据设计类岗位考试题库及答案一、单项选择题（每题2分，共20分）1.以下关于关系型数据库与非关系型数据库的描述中，错误的是：A.关系型数据库支持ACID特性，适合事务性场景B.非关系型数据库通常采用键值对、文档、列族等存储模型C.MySQL的InnoDB引擎支持行级锁，MyISAM引擎支持表级锁D.MongoDB作为文档型数据库，严格遵循关系模型的范式要求答案：D（MongoDB是NoSQL数据库，不严格遵循关系模型范式）2.在数据库设计中，若一个关系模式满足所有属性不可再分，且不存在部分函数依赖，则该模式至少满足：A.1NFB.2NFC.3NFD.BCNF答案：B（2NF要求消除非主属性对候选键的部分函数依赖，且已满足1NF的原子性）3.以下不属于数据仓库维度建模中“维度表”典型属性的是：A.时间维度（如订单日期）B.地理维度（如用户所在城市）C.度量值（如订单金额）D.产品维度（如商品分类）答案：C（度量值属于事实表的指标，维度表存储描述性属性）4.在设计分布式数据库时，若需重点优化读性能，通常优先考虑的分片策略是：A.按主键哈希分片B.按时间范围分片C.按业务线垂直分片D.按热点数据单独分片答案：D（热点数据单独分片可减少竞争，提升读效率；哈希分片侧重负载均衡，时间分片适合时序场景）5.关于数据质量的“一致性”维度，以下描述正确的是：A.数据在不同系统间格式、含义保持统一B.数据覆盖所需业务场景的完整程度C.数据与真实业务事件的匹配程度D.数据在需要时可及时获取的能力答案：A（一致性强调跨系统/跨表的逻辑统一；完整性是覆盖程度，准确性是与真实匹配，及时性是获取时效）6.设计ETL流程时，“慢变维度（SCD）”处理的核心目标是：A.减少存储空间占用B.保留维度历史变化轨迹C.提升实时处理效率D.避免事实表重复计算答案：B（慢变维度通过版本管理记录维度属性的历史变更，如用户地址修改后保留旧地址）7.以下数据结构中，适合实现“最近最少使用（LRU）缓存”的是：A.哈希表+双向链表B.平衡二叉搜索树C.堆结构D.跳表答案：A（哈希表快速查找，双向链表维护访问顺序，共同实现O(1)时间复杂度的插入、删除和查询）8.在设计大数据实时处理架构时，若需支持“exactly-once”语义，关键依赖的技术是：A.检查点（Checkpoint）与事务性输出B.消息队列的持久化存储C.分布式锁机制D.数据倾斜优化答案：A（Checkpoint保存状态快照，事务性输出确保数据仅提交一次，是实现exactly-once的核心）9.以下关于主索引与辅助索引的描述中，错误的是：A.主索引基于表的主键建立，通常是唯一的B.辅助索引基于非主键字段建立，可能包含重复值C.主索引的叶子节点存储表的完整数据（如InnoDB的聚簇索引）D.辅助索引的叶子节点一定存储主键值（如InnoDB的二级索引）答案：D（InnoDB二级索引叶子节点存储主键值，但其他数据库如SQLServer的非聚簇索引可能存储行定位符）10.设计数据脱敏方案时，对用户身份证号的脱敏策略最合理的是：A.直接删除B.替换为固定值（如“”）C.保留前3位和后4位，中间用“”填充（如4201234）D.随机提供假身份证号答案：C（保留部分有效信息既满足业务需求，又保护隐私；直接删除或随机提供可能破坏数据可用性）二、简答题（每题8分，共40分）1.简述ER模型向关系模型转换的主要步骤，并说明如何处理多对多（M:N）联系。答案：步骤：①将实体转换为关系表，实体属性作为表字段，主键对应实体标识符；②将联系转换为关系表，联系的属性作为字段，两端实体的主键作为外键；③处理1:1、1:N、M:N等不同类型的联系。处理M:N联系：需创建独立的联系表，包含两端实体的主键（作为联合主键）及联系的属性。例如，学生（学号）与课程（课程号）的多对多联系“选课”，转换为选课表（学号，课程号，成绩），其中学号和课程号是外键，联合主键。2.数据仓库设计中，“星型模型”与“雪花模型”的区别是什么？各自适用场景是什么？答案：区别：星型模型的维度表直接与事实表关联，维度表无层次划分；雪花模型的维度表进一步规范化，拆分为多个子维度表（如地区维度拆分为国家、省份、城市三级表），通过外键关联。适用场景：星型模型适合查询性能要求高、业务逻辑简单的场景（如报表快速查询），冗余存储换取查询效率；雪花模型适合数据一致性要求高、维度层次复杂的场景（如需要严格管理维度层级的金融分析），但可能增加查询复杂度。3.设计数据接口时，如何保证数据传输的安全性？请列举至少4种技术手段。答案：①传输加密：使用HTTPS（TLS/SSL）或私有加密协议（如SM4）对传输数据加密；②身份认证：采用APIKey、OAuth2.0（如JWT令牌）或双向SSL认证（客户端证书）验证调用方身份；③权限控制：基于RBAC（角色权限控制）或ABAC（属性权限控制）限制接口访问范围（如仅允许查询特定字段）；④流量监控：通过API网关记录请求日志，检测异常调用（如高频请求、越权访问）并触发限流或封禁；⑤数据脱敏：对接口返回的敏感数据（如手机号、身份证号）进行脱敏处理（如部分隐藏、哈希转换）。4.什么是数据倾斜？在分布式计算（如Spark）中，如何诊断和解决数据倾斜问题？答案：数据倾斜指分布式任务中，部分节点处理的数据量远大于其他节点，导致任务延迟甚至失败。诊断方法：①查看任务日志，定位执行时间过长的Stage；②通过SparkWebUI分析各分区数据量（如ShuffleReadSize/Records指标）；③检查数据分布（如GROUPBY、JOIN的键值频率，是否存在高频Key）。解决方法：①对高频Key添加随机前缀，分散到多个分区处理后再聚合；②调整并行度（增加分区数），均衡数据分布；③使用广播变量优化小表JOIN，避免Shuffle；④过滤异常值（如无效的NULLKey）；⑤采用自定义分区器，根据业务规则重新分区。5.设计实时数据湖时，需要考虑哪些关键技术点？请从存储、计算、元数据管理三个维度说明。答案：存储维度：选择支持事务的存储格式（如DeltaLake、Iceberg），支持ACID特性；分层存储（热数据SSD、冷数据HDFS/对象存储）优化成本；计算维度：集成实时计算引擎（如Flink、SparkStreaming），支持批流统一处理；设计合理的Watermark机制处理延迟数据；元数据管理：使用中央元数据服务（如ApacheAtlas）记录数据血缘、schema变更；支持版本控制（如时间旅行查询）和分区元数据优化（减少元数据读取开销）。三、案例分析题（每题20分，共40分）案例1：某电商公司需设计用户行为数据分析平台，目标是支持“用户从浏览商品到下单支付”全链路转化分析。已知用户行为包括：页面浏览（page_view）、商品点击（item_click）、加入购物车（add_cart）、下单（order）、支付（payment）。要求设计底层数据模型，并回答以下问题：（1）采用维度建模，需设计哪些维度表？列举核心维度字段。（2）设计事实表的结构，说明事实类型（可加性、半可加性、不可加性）。（3）如何处理用户行为的时间戳（如用户跨天浏览和支付）？答案：（1）维度表设计：用户维度：用户ID、注册时间、性别、年龄、会员等级（用于分析不同用户群体的转化差异）；时间维度：日期、星期、小时、节假日标识（用于时间序列分析）；商品维度：商品ID、类目、价格、品牌（用于分析商品的转化表现）；页面维度：页面ID、页面类型（首页/详情页）、所属业务线（用于分析页面流量质量）；设备维度：设备ID、操作系统、浏览器类型（用于分析不同设备的转化差异）。（2）事实表结构：事实表命名为user_behavior_fact，核心字段包括：事件ID（主键）；用户ID（外键，关联用户维度）；商品ID（外键，关联商品维度，若为页面浏览则可为NULL）；页面ID（外键，关联页面维度）；设备ID（外键，关联设备维度）；事件时间戳（关联时间维度）；事件类型（page_view/item_click等，枚举值）；事实指标：事件次数（可加性，用于统计各环节数量）、支付金额（可加性，仅payment事件有效）、购物车商品数量（半可加性，add_cart事件记录，不可按时间求和）。（3）时间戳处理：事实表中存储原始事件时间戳（精确到毫秒），用于明细查询；关联时间维度时，按事件发生的“自然时间”（如浏览发生在23:50，支付在次日00:10，则浏览关联前一天的时间维度，支付关联次日的时间维度）；对于跨天转化分析（如从当天浏览到次日支付），可通过用户ID和会话ID（若有）关联不同时间点的事件，计算转化时长。案例2：某银行需设计交易系统数据库，要求支持“实时转账”业务（用户A转用户B，需扣减A余额、增加B余额），同时需满足高并发（日均1000万笔）和数据一致性要求。请回答：（1）选择关系型数据库还是分布式数据库？说明理由。（2）设计表结构（至少包含用户表、交易表），并标注主键、索引。（3）如何保证转账操作的原子性（ACID中的A）？（4）若出现“用户A余额不足”的情况，如何设计异常处理流程？答案：（1）数据库选型：选择关系型数据库（如MySQLInnoDB）。理由：实时转账需严格的事务支持（ACID），关系型数据库的事务实现更成熟；日均1000万笔在垂直扩展（高性能服务器）或读写分离架构下可满足，分布式数据库的分布式事务（如2PC）可能增加延迟，不适合高频实时场景。（2）表结构设计：用户表（user_account）：user_id（主键，BIGINT，自增）；username（VARCHAR(50)，唯一索引，用于登录）；balance（DECIMAL(18,2)，NOTNULL，当前余额）；create_time（DATETIME，普通索引，用于统计）；update_time（DATETIME，记录最后更新时间）。交易表（transaction_record）：trans_id（主键，CHAR(32)，UUID提供，全局唯一）；from_user_id（BIGINT，外键关联user_account.user_id，索引，用于查询出账记录）；to_user_id（BIGINT，外键关联user_account.user_id，索引，用于查询入账记录）；amount（DECIMAL(18,2)，交易金额）；trans_time（DATETIME，索引，用于按时间查询）；status（TINYINT，0=处理中，1=成功，2=失败，索引）；remark（VARCHAR(255)，备注）。（3）原子性保证：使用数据库事务（BEGIN/COMMIT/ROLLBACK），将转账操作封装为一个事务：①检查A的余额是否≥转账金额（SELECTbalanceFROMuser_accountWHEREuser_id=AFORUPDATE，行锁防止并发修改）；②若余额足够，扣减A的余额（UPDATEuser_accountSETbalance=balance-amountWHEREuser_id=A）；③增加B的余额（UPDATEuser_accountSETbalance=balance+amountWHEREuser_id=B）；④插入交易记录（INSERTINTOtransaction_record...）；⑤提交事务（COMMIT）；若任意步骤失败（如余额不足、网络中断），回滚事务（ROLLBACK），确保A和B的余额状态一致。（4）异常处理流程：①预检查