简介面向微软DP-900认证考试Azure Data Fundamentals的PDF备考资料覆盖MCP认证体系中数据库与数据分析核心考点适合考前冲刺或日常系统学习。内容具体涉及数据分析类型描述性、诊断性、预测性、认知分析在不同业务问题中的匹配应用SQL Server数据库规范化范式1NF至BCNF/5NF的设计规则ETL提取-转换-加载数据管道的完整流程批处理适用场景与延迟权衡以及Azure认知服务语音转文本/文本转语音功能等主题。每个主题均以考题形式呈现并附带官方参考链接与答案解析方便对照学习易混淆概念。资源为单个PDF文件约18.94MB便于离线通读与重点标记。目前已有159人学习借助Hotspot、拖拽匹配等典型题型的解析读者可快速掌握作答思路提升选择题和实操类题目的答题效率。1. 为什么一份PDF解决不了DP-900备考打开这份DP-900相关的MCP备考资料时我猜你和当时的我一样第一反应是“把考点背完就去考试”。但真正刷过题、上过考场的人会告诉你DP-900是认证体系里最基础的一张证书却也是挂科率最被低估的一张。原因很简单——它的考题不直接问你“什么是分区键”而是给你一个具体业务场景让你判断该用哪种存储、该把冗余副本放在哪、该用强一致还是最终一致。纯看PDF背概念遇到这种场景题基本靠猜。这份标题里的MCP并非一个工具名而是指认证体系中“从业者”这条成长路径的配套备考资料从数据概念、关系型与非关系型存储到分析工作负载的差异。它能帮你快速圈定考纲范围但真正决定你能不能过、以及考完之后会不会用靠的是把PDF里的每一个抽象概念映射到一次真实操作里——起一个数据库、写一条查询、对比两种存储的行为差异。这篇文章就是干这个的带你从这份资料出发搭一条从概念到实验再到排查的完整备考路径不背题但能过。适合谁看打算考这张证的新手、被场景题卡住的重考者以及想用最短时间把“概念”变成“手感”的开发者。如果你期待一份押题合集可以关掉了如果你想靠一张基础证书把数据存储的底层判断力建立起来往下看。2. DP-900到底在考什么三块知识面和它们的真实权重2.1 数据概念不是考定义是考“边界判断”任何一份DP-900备考资料第一块内容一定是数据基础概念。但你要警惕这块看似送分实际是丢分重灾区。因为考题不会让你默写“结构化数据是……”这种填空而是给你一个包含订单号、客户姓名、购买时间的Excel导出文件问你这属于结构化、半结构化还是非结构化数据——听起来简单但加上“来自JSON接口”“存成CSV文件”“放在blob里给AI训练用”这些修饰判断标准就模糊了。我习惯把判断边界压缩成三句话有固定模式、能塞进表格的行列结构就是结构化数据。有层级或键值对、但字段数目不固定比如JSON、XML、YAML就是半结构化数据。没有可解析的固定模式图片、音频、视频、PDF原文就是非结构化数据。一个易错点CSV文件虽然本质是纯文本但从数据模式角度它承载的是结构化内容而一份包含订单信息的JSON文件题目的正确选项往往是半结构化。备考这条线的关键不是背分类名而是形成“先看模式再看载体”的判断顺序。资料里列出的数据存储类型对比表我会在后面的第4章给出一个可直接抄的版本。2.2 关系型与非关系型选型题的隐含规则DP-900考试大纲里关系型数据库的考察重心是表、行、列、主键、外键、索引的作用以及事务的ACID属性。非关系型则按数据模型拆成键值对、文档、列族、图四类。但真正拉开分数的是选型场景题——题目描述一个订单系统问“应该用关系型还是NoSQL为什么”。很多人靠字面意思去匹配正确率很低。这里要套用一线开发者的判断框架数据之间有明确关联、需要多表联查、必须保证转账这类操作的原子性 → 关系型。数据以单个对象为单位读改写、对事务要求宽松、需要水平扩展 → 键值对或文档型。查询模式固定、按某一维度聚合海量数据 → 列族型。核心操作是“朋友的朋友”“节点间关系链” → 图数据库。备考时不要死记“关系型更安全、NoSQL更快”这种话。题目经常反过来考一个只按用户ID读取配置信息的场景关系型反而多余一个需要复杂报表的场景纯NoSQL会很难写查询。判断标准永远是“数据形态 访问模式 事务需求”三者是否匹配。2.3 分析负载不只是“会做报表”这么简单第三块是数据分析工作负载考察点集中在数据仓库和数据湖的区别、批量处理和流式处理的适用场景、以及可视化报表背后的数据流转链路。很多看过资料的人会把“数据湖存原始数据、数据仓库存清洗后的数据”背出来但做题时遇到“实时检测信用卡欺诈”这种场景在批处理和流式之间犹豫半天。我的经验是记住两组关键词批处理定时触发、处理历史数据、吞吐量大、延迟分钟级到小时级。流处理持续到达、处理实时事件、延迟秒级甚至毫秒级、状态管理复杂。而数据仓库和数据湖之间最核心的区分维度是“schema是否预定义”。数据仓库是schema-on-write写入前必须建模数据湖是schema-on-read存进去再说读取时再解析。近年常见的“湖仓一体”趋势考试也会涉及备考时理解成“把两者的优点结合保留数据湖的灵活性同时提供数据仓库的查询性能”即可不要纠结具体实现。3. 把PDF里的概念变成能跑的实验最小环境搭建与练习路径3.1 用容器在本地搭一套练习环境三分钟起步只看资料不动手概念记忆周期撑不过一周。我一般建议备考者至少在本地把“关系型 非关系型 分析场景”各跑通一次。最省事的做法是用容器跑两个数据库实例不需要安装任何桌面客户端。# 创建练习用网络方便后续容器间通信 docker network create dp900-lab # 启动 PostgreSQL 作为关系型练习实例 docker run -d \ --name dp900-pg \ --network dp900-lab \ -e POSTGRES_USERlabuser \ -e POSTGRES_PASSWORDLabPass123 \ -e POSTGRES_DBsalesdb \ -p 5432:5432 \ postgres:16-alpine # 启动 MongoDB 作为非关系型练习实例 docker run -d \ --name dp900-mongo \ --network dp900-lab \ -e MONGO_INITDB_ROOT_USERNAMElabuser \ -e MONGO_INITDB_ROOT_PASSWORDLabPass123 \ -p 27017:27017 \ mongo:7这段命令做了什么先创建一个自定义网络让两个容器可以用容器名互相访问然后分别启动PostgreSQL和MongoDB。-e参数是注入环境变量-p参数做端口映射-d表示后台运行。postgres:16-alpine和mongo:7是镜像标签alpine版本体积更小适合本机资源有限的场景。启动后验证一下用docker ps确认两个容器都是Up状态。如果端口被占用换一个宿主端口比如-p 5433:5432后续连接时改端口即可。这个环境覆盖了你在DP-900关系型与非关系型章节里的大部分考点包括建表、插入、查询、文档CRUD、索引行为等。3.2 用一个销售订单场景对照练习同样的数据两种写法环境起来了接下来要做的不是乱敲命令而是带着DP-900考纲里的知识点去验证。我常用的练习案例是一个极简销售订单场景在两种数据库里各建一套。先看关系型这一侧-- 创建客户表主键约束体现了关系型数据库的核心约束机制 CREATE TABLE customers ( customer_id SERIAL PRIMARY KEY, customer_name VARCHAR(100) NOT NULL, region VARCHAR(50) ); -- 创建订单表外键把订单和客户关联起来 CREATE TABLE orders ( order_id SERIAL PRIMARY KEY, customer_id INTEGER REFERENCES customers(customer_id), order_amount NUMERIC(10, 2), order_date DATE ); -- 插入两条测试数据 INSERT INTO customers (customer_name, region) VALUES (Alice, 华东); INSERT INTO orders (customer_id, order_amount, order_date) VALUES (1, 199.00, 2026-01-10); -- 联查找出Alice的所有订单 SELECT c.customer_name, o.order_amount, o.order_date FROM customers c JOIN orders o ON c.customer_id o.customer_id WHERE c.customer_name Alice;这段SQL练习了主键、外键、关联查询三个DP-900高频考点。SERIAL是自增整数类型NUMERIC(10,2)表示最多10位数字、保留2位小数适合存金额。JOIN语句是本节的灵魂——关系型数据库之所以适合订单类业务正是因为这种表间关联可以高效完成。再看非关系型一侧同样的业务意图用文档模型表达// 连接MongoDB后在salesdb库中操作 db.customers.insertOne({ customer_id: 1, customer_name: Alice, region: 华东, // 订单直接嵌套在客户文档里是文档模型的典型设计 orders: [ { order_id: 1, amount: 199.00, order_date: 2026-01-10 } ] }); // 按客户名查询一次取出完整对象 db.customers.findOne( { customer_name: Alice }, { orders: 1, customer_name: 1 } );对比验证后你会发现同样的数据关系型强调“规范化拆分 关联查询”非关系型强调“按访问模式聚合 单次读取”。这正好对应DP-900里关于两种存储差异的考查方向。备考时把这两段代码跑通比反复看资料里的对比表格有用得多。3.3 分析负载练习用一条SQL体会批处理和流处理的差别分析负载部分本地没法完整跑一个数据仓库但可以用一条聚合查询把“批处理”的感觉建立起来-- 按区域统计总销售额这是典型的批量聚合操作 SELECT c.region, SUM(o.order_amount) AS total_amount FROM customers c JOIN orders o ON c.customer_id o.customer_id GROUP BY c.region ORDER BY total_amount DESC;跑完这条查询再看资料里关于批处理和流处理的定义理解会完全不一样这条SQL是“对已落盘的历史订单做汇总”是批处理的典型形态而流处理面对的是“一条订单刚产生就要立刻计算”两者在数据处理时机和延迟要求上的本质差异靠这条SQL就能直观体会。这一节的目的是让“数据仓库 vs 数据湖”“批处理 vs 流处理”这两组对比从文字记忆变成动作记忆。4. 两张必须刻进脑子的表存储选型对照与一致性模型4.1 存储选型快查表做对场景题的捷径DP-900的选择题里数据存储选型是出现频率最高的题型。我整理了一张精简对照表按“业务场景 推荐存储 核心理由”组织备考和做实验时都能直接用业务场景推荐存储方向核心判断依据电商订单、银行转账关系型数据库事务保障、表间关联、复杂查询用户会话、购物车、配置信息键值存储单点读写快速、无复杂关联商品信息、文章内容、用户资料文档数据库数据结构灵活、按对象访问物联网设备指标、日志事件流列族存储 / 时序存储时间维度写入密集、按行键扫描社交好友关系、推荐链路图数据库关系遍历是核心操作原始文件、备份、图片、训练数据对象存储非结构化、海量、廉价持久化使用这张表有一个前提题目给出的场景往往混合着多个特征要按“最强的那个约束”来选。比如“一个电商系统的订单数据”关联和事务需求占主导选关系型同样一个电商系统用户浏览历史的日志数据没有事务要求、量又大对象存储或列族存储更贴合。做题时先划出题目里最扎眼的动词——“联查”“要事务”“吞吐量极高”“不可变日志”——再对应到表里。4.2 一致性模型一份资料里最容易被跳过、却最常被考的硬知识一致性是DP-900里最“抽象”的考点也是最容易丢分的地方。核心是分清强一致性和最终一致性特性强一致性最终一致性读到的数据每次都能读到最新写入值可能短暂读到旧值写入延迟较高需要同步复制确认较低异步复制即可适用场景账户余额、库存扣减、订单状态评论计数、点赞数、推荐列表故障行为写入需多数派确认可用性受影响优先保证可用稍后补齐数据备考关键考题往往给一个“读自己刚写入的数据”场景问应该用哪种一致性。如果业务要求绝对不能读到旧值比如支付后再查余额必须强一致如果晚几秒看到新数据无所谓比如文章点赞数最终一致性更合适。资料里通常会提“CAP定理”作为理论注释但DP-900的题不会深入到证明层面你能说出“分区时要在一致性和可用性之间做取舍”就够用了。一个实操中的体会这些概念在本地单机实验里永远体现不出来因为单机数据库读写都是即时的一致性冲突只出现在分布式环境下。所以练习时做对比认知就好PostgreSQL默认提供强一致的事务语义而MongoDB在副本集环境下默认的读取策略可能读到旧数据这恰恰是考纲要你建立的差异感知。5. 避坑备考路上最常见的六个翻车现场5.1 翻车现场一背下了所有概念却卡在“判断数据类型”现象看到题目给出一份包含“PDF报告 解析后的JSON 数据库导出表”三个选项分别是结构化、半结构化、非结构化结果把JSON归到了非结构化。原因把“存储载体”和“数据模式”混为一谈。JSON虽然是一段文本但文本内部有明确的键值结构可以被程序直接解析。解决做题时先问“程序能否直接识别它的字段结构”能识别就是结构化或半结构化完全无法直接解析、需要人工或AI提取才算非结构化。图片、原始音频、扫描件都是非结构化。5.2 翻车现场二事务ACID只会背缩写题目一换场景就懵现象题目问“转账过程中系统崩溃会发生什么”选项涉及事务的回滚行为。原因只背了“原子性、一致性、隔离性、持久性”四个词没理解它们具体解决的是什么问题。解决每个性质对应一个问题记忆——原子性解决“操作做一半怎么办”一致性解决“约束是否始终成立”隔离性解决“两个事务同时写冲突怎么办”持久性解决“机器断电后数据还在不在”。把每个性质翻译成一个事故场景考场看到对应关键词就能反应。5.3 翻车现场三NoSQL选型题永远第一反应选文档数据库现象题目描述一个“返回用户最近30天浏览记录”的场景正确答案是键值存储却选了文档数据库。原因没有区分键值存储和文档存储的边界。键值存储擅长“按key取整个value”文档存储的优势在于“value内部还有可查询的字段结构”。解决看题目里有没有“按某个字段做条件查询”“只读取value的一部分”。如果有选文档数据库如果只需要“给我这个key对应的完整数据”键值存储更贴合。另外列族存储的题目特征是“扫描某一列的所有行”比如统计所有设备的最新温度。5.4 翻车现场四把“备份”和“高可用”当成同一件事现象题目问“如何保证数据库在单节点故障后继续提供服务”错选成“定期做完整备份”。原因混淆了数据恢复RPO/RTO和系统连续可用高可用的关系。备份解决的是“数据丢了能恢复”高可用解决的是“服务不能停”。解决高频考点里高可用对应“副本 故障转移”备份对应“定期导出 时间点恢复”。做题时看题干问的是“数据丢失风险”还是“服务中断风险”两者答案完全不同。5.5 翻车现场五流处理和批处理的判断只看“是不是实时”现象描述一个“每小时统计一次网页日志”的场景被判定为流处理。原因以为“时间间隔短”就是实时。其实“每小时触发一次”是典型的定时批处理即使数据本身是持续产生的。解决判断标准不是延迟长短而是“处理是否由事件到达触发”。事件一来就处理、状态持续更新的是流处理按固定时间窗口统一处理一批历史数据的是批处理。记住一句话批处理是闹钟叫醒的流处理是门铃按响的。5.6 翻车现场六资料看得懂实验不去做现象考前做模拟题正确率80%上考场看到场景题频繁在两个选项之间纠结。原因知识停留在“认识层面”没到“判断层面”。认识是看到答案觉得对判断是看到题干能独立推导出答案两者之间差的是动手。解决把本文第3章的实验环境搭起来每个考点至少对应一条真实命令或查询。做完后合上资料自己对着表结构写一条查询、写一份文档、做一次聚合再对照答案看差距。挂科的人多数不是不懂而是练习时的顺利感骗了自己。6. 把错题变成一条查询语句备考后期最该养成的习惯备考进入后半程刷题量上来之后你会发现自己反复错的不是同一个知识点而是同一类“判断逻辑”。这时候再翻整本资料是没有效率的我建议你做一个动作把每一道错题的关键场景抽出来写成一个查询或一段伪代码把脑内判断固化成一个可执行的东西。举个例子。一道题说“某阅读App需要实时显示每篇文章的点赞总数允许短暂延迟但用户量巨大”正确答案是最终一致性 计数存储。你做错了原因是把“计数”和“事务账本”弄混。这时候别只在题旁打勾而是用代码表达这道题的判断逻辑# 用条件映射把一道选型题变成可执行的逻辑判断 def choose_storage(need_transaction, need_real_time, read_old_ok): 根据业务约束返回存储选型方向 need_transaction: 是否需要强事务 need_real_time: 结果是否要求实时一致 read_old_ok: 是否允许读到短暂旧数据 if need_transaction: return 关系型数据库强一致 ACID elif need_real_time and not read_old_ok: return 强一致存储方案同步复制 elif read_old_ok: return 最终一致存储方案异步复制如键值/文档 else: return 需要结合具体延迟要求进一步判断 # 模拟上面那道的场景不需要事务允许短暂延迟 print(choose_storage( need_transactionFalse, need_real_timeFalse, read_old_okTrue )) # 输出: 最终一致存储方案异步复制如键值/文档这段代码的本质是把你对考点的判断标准压缩成一个“输入条件 → 输出结论”的函数。当你把十几道错题都这样转化之后会发现那些看上去不同的题目背后的判断函数其实是同一个。这个习惯的价值不在于写代码本身而在于强迫你把模糊的“感觉”变成明确的“条件分支”——这正是场景题考查的能力。到考前一天我不再翻整本资料只运行自己积累的这几个判断脚本反复核对输出是否符合预期。用一句自己的教训收尾备考DP-900最大的陷阱不是知识点多而是你误以为“看懂了”就等于“会判断了”。把每个考点落到一条命令、一张表、一段逻辑里那张证书本身反而不重要了重要的是你从这份备考资料里拿走的是一套不靠背也能迁移的判断能力。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/10 14:45:53 · 阅读 1.2k DP-900备考：把数据存储概念变成场景判断力
简介面向微软DP-900认证考试Azure Data Fundamentals的PDF备考资料覆盖MCP认证体系中数据库与数据分析核心考点适合考前冲刺或日常系统学习。内容具体涉及数据分析类型描述性、诊断性、预测性、认知分析在不同业务问题中的匹配应用SQL Server数据库规范化范式1NF至BCNF/5NF的设计规则ETL提取-转换-加载数据管道的完整流程批处理适用场景与延迟权衡以及Azure认知服务语音转文本/文本转语音功能等主题。每个主题均以考题形式呈现并附带官方参考链接与答案解析方便对照学习易混淆概念。资源为单个PDF文件约18.94MB便于离线通读与重点标记。目前已有159人学习借助Hotspot、拖拽匹配等典型题型的解析读者可快速掌握作答思路提升选择题和实操类题目的答题效率。1. 为什么一份PDF解决不了DP-900备考打开这份DP-900相关的MCP备考资料时我猜你和当时的我一样第一反应是“把考点背完就去考试”。但真正刷过题、上过考场的人会告诉你DP-900是认证体系里最基础的一张证书却也是挂科率最被低估的一张。原因很简单——它的考题不直接问你“什么是分区键”而是给你一个具体业务场景让你判断该用哪种存储、该把冗余副本放在哪、该用强一致还是最终一致。纯看PDF背概念遇到这种场景题基本靠猜。这份标题里的MCP并非一个工具名而是指认证体系中“从业者”这条成长路径的配套备考资料从数据概念、关系型与非关系型存储到分析工作负载的差异。它能帮你快速圈定考纲范围但真正决定你能不能过、以及考完之后会不会用靠的是把PDF里的每一个抽象概念映射到一次真实操作里——起一个数据库、写一条查询、对比两种存储的行为差异。这篇文章就是干这个的带你从这份资料出发搭一条从概念到实验再到排查的完整备考路径不背题但能过。适合谁看打算考这张证的新手、被场景题卡住的重考者以及想用最短时间把“概念”变成“手感”的开发者。如果你期待一份押题合集可以关掉了如果你想靠一张基础证书把数据存储的底层判断力建立起来往下看。2. DP-900到底在考什么三块知识面和它们的真实权重2.1 数据概念不是考定义是考“边界判断”任何一份DP-900备考资料第一块内容一定是数据基础概念。但你要警惕这块看似送分实际是丢分重灾区。因为考题不会让你默写“结构化数据是……”这种填空而是给你一个包含订单号、客户姓名、购买时间的Excel导出文件问你这属于结构化、半结构化还是非结构化数据——听起来简单但加上“来自JSON接口”“存成CSV文件”“放在blob里给AI训练用”这些修饰判断标准就模糊了。我习惯把判断边界压缩成三句话有固定模式、能塞进表格的行列结构就是结构化数据。有层级或键值对、但字段数目不固定比如JSON、XML、YAML就是半结构化数据。没有可解析的固定模式图片、音频、视频、PDF原文就是非结构化数据。一个易错点CSV文件虽然本质是纯文本但从数据模式角度它承载的是结构化内容而一份包含订单信息的JSON文件题目的正确选项往往是半结构化。备考这条线的关键不是背分类名而是形成“先看模式再看载体”的判断顺序。资料里列出的数据存储类型对比表我会在后面的第4章给出一个可直接抄的版本。2.2 关系型与非关系型选型题的隐含规则DP-900考试大纲里关系型数据库的考察重心是表、行、列、主键、外键、索引的作用以及事务的ACID属性。非关系型则按数据模型拆成键值对、文档、列族、图四类。但真正拉开分数的是选型场景题——题目描述一个订单系统问“应该用关系型还是NoSQL为什么”。很多人靠字面意思去匹配正确率很低。这里要套用一线开发者的判断框架数据之间有明确关联、需要多表联查、必须保证转账这类操作的原子性 → 关系型。数据以单个对象为单位读改写、对事务要求宽松、需要水平扩展 → 键值对或文档型。查询模式固定、按某一维度聚合海量数据 → 列族型。核心操作是“朋友的朋友”“节点间关系链” → 图数据库。备考时不要死记“关系型更安全、NoSQL更快”这种话。题目经常反过来考一个只按用户ID读取配置信息的场景关系型反而多余一个需要复杂报表的场景纯NoSQL会很难写查询。判断标准永远是“数据形态 访问模式 事务需求”三者是否匹配。2.3 分析负载不只是“会做报表”这么简单第三块是数据分析工作负载考察点集中在数据仓库和数据湖的区别、批量处理和流式处理的适用场景、以及可视化报表背后的数据流转链路。很多看过资料的人会把“数据湖存原始数据、数据仓库存清洗后的数据”背出来但做题时遇到“实时检测信用卡欺诈”这种场景在批处理和流式之间犹豫半天。我的经验是记住两组关键词批处理定时触发、处理历史数据、吞吐量大、延迟分钟级到小时级。流处理持续到达、处理实时事件、延迟秒级甚至毫秒级、状态管理复杂。而数据仓库和数据湖之间最核心的区分维度是“schema是否预定义”。数据仓库是schema-on-write写入前必须建模数据湖是schema-on-read存进去再说读取时再解析。近年常见的“湖仓一体”趋势考试也会涉及备考时理解成“把两者的优点结合保留数据湖的灵活性同时提供数据仓库的查询性能”即可不要纠结具体实现。3. 把PDF里的概念变成能跑的实验最小环境搭建与练习路径3.1 用容器在本地搭一套练习环境三分钟起步只看资料不动手概念记忆周期撑不过一周。我一般建议备考者至少在本地把“关系型 非关系型 分析场景”各跑通一次。最省事的做法是用容器跑两个数据库实例不需要安装任何桌面客户端。# 创建练习用网络方便后续容器间通信 docker network create dp900-lab # 启动 PostgreSQL 作为关系型练习实例 docker run -d \ --name dp900-pg \ --network dp900-lab \ -e POSTGRES_USERlabuser \ -e POSTGRES_PASSWORDLabPass123 \ -e POSTGRES_DBsalesdb \ -p 5432:5432 \ postgres:16-alpine # 启动 MongoDB 作为非关系型练习实例 docker run -d \ --name dp900-mongo \ --network dp900-lab \ -e MONGO_INITDB_ROOT_USERNAMElabuser \ -e MONGO_INITDB_ROOT_PASSWORDLabPass123 \ -p 27017:27017 \ mongo:7这段命令做了什么先创建一个自定义网络让两个容器可以用容器名互相访问然后分别启动PostgreSQL和MongoDB。-e参数是注入环境变量-p参数做端口映射-d表示后台运行。postgres:16-alpine和mongo:7是镜像标签alpine版本体积更小适合本机资源有限的场景。启动后验证一下用docker ps确认两个容器都是Up状态。如果端口被占用换一个宿主端口比如-p 5433:5432后续连接时改端口即可。这个环境覆盖了你在DP-900关系型与非关系型章节里的大部分考点包括建表、插入、查询、文档CRUD、索引行为等。3.2 用一个销售订单场景对照练习同样的数据两种写法环境起来了接下来要做的不是乱敲命令而是带着DP-900考纲里的知识点去验证。我常用的练习案例是一个极简销售订单场景在两种数据库里各建一套。先看关系型这一侧-- 创建客户表主键约束体现了关系型数据库的核心约束机制 CREATE TABLE customers ( customer_id SERIAL PRIMARY KEY, customer_name VARCHAR(100) NOT NULL, region VARCHAR(50) ); -- 创建订单表外键把订单和客户关联起来 CREATE TABLE orders ( order_id SERIAL PRIMARY KEY, customer_id INTEGER REFERENCES customers(customer_id), order_amount NUMERIC(10, 2), order_date DATE ); -- 插入两条测试数据 INSERT INTO customers (customer_name, region) VALUES (Alice, 华东); INSERT INTO orders (customer_id, order_amount, order_date) VALUES (1, 199.00, 2026-01-10); -- 联查找出Alice的所有订单 SELECT c.customer_name, o.order_amount, o.order_date FROM customers c JOIN orders o ON c.customer_id o.customer_id WHERE c.customer_name Alice;这段SQL练习了主键、外键、关联查询三个DP-900高频考点。SERIAL是自增整数类型NUMERIC(10,2)表示最多10位数字、保留2位小数适合存金额。JOIN语句是本节的灵魂——关系型数据库之所以适合订单类业务正是因为这种表间关联可以高效完成。再看非关系型一侧同样的业务意图用文档模型表达// 连接MongoDB后在salesdb库中操作 db.customers.insertOne({ customer_id: 1, customer_name: Alice, region: 华东, // 订单直接嵌套在客户文档里是文档模型的典型设计 orders: [ { order_id: 1, amount: 199.00, order_date: 2026-01-10 } ] }); // 按客户名查询一次取出完整对象 db.customers.findOne( { customer_name: Alice }, { orders: 1, customer_name: 1 } );对比验证后你会发现同样的数据关系型强调“规范化拆分 关联查询”非关系型强调“按访问模式聚合 单次读取”。这正好对应DP-900里关于两种存储差异的考查方向。备考时把这两段代码跑通比反复看资料里的对比表格有用得多。3.3 分析负载练习用一条SQL体会批处理和流处理的差别分析负载部分本地没法完整跑一个数据仓库但可以用一条聚合查询把“批处理”的感觉建立起来-- 按区域统计总销售额这是典型的批量聚合操作 SELECT c.region, SUM(o.order_amount) AS total_amount FROM customers c JOIN orders o ON c.customer_id o.customer_id GROUP BY c.region ORDER BY total_amount DESC;跑完这条查询再看资料里关于批处理和流处理的定义理解会完全不一样这条SQL是“对已落盘的历史订单做汇总”是批处理的典型形态而流处理面对的是“一条订单刚产生就要立刻计算”两者在数据处理时机和延迟要求上的本质差异靠这条SQL就能直观体会。这一节的目的是让“数据仓库 vs 数据湖”“批处理 vs 流处理”这两组对比从文字记忆变成动作记忆。4. 两张必须刻进脑子的表存储选型对照与一致性模型4.1 存储选型快查表做对场景题的捷径DP-900的选择题里数据存储选型是出现频率最高的题型。我整理了一张精简对照表按“业务场景 推荐存储 核心理由”组织备考和做实验时都能直接用业务场景推荐存储方向核心判断依据电商订单、银行转账关系型数据库事务保障、表间关联、复杂查询用户会话、购物车、配置信息键值存储单点读写快速、无复杂关联商品信息、文章内容、用户资料文档数据库数据结构灵活、按对象访问物联网设备指标、日志事件流列族存储 / 时序存储时间维度写入密集、按行键扫描社交好友关系、推荐链路图数据库关系遍历是核心操作原始文件、备份、图片、训练数据对象存储非结构化、海量、廉价持久化使用这张表有一个前提题目给出的场景往往混合着多个特征要按“最强的那个约束”来选。比如“一个电商系统的订单数据”关联和事务需求占主导选关系型同样一个电商系统用户浏览历史的日志数据没有事务要求、量又大对象存储或列族存储更贴合。做题时先划出题目里最扎眼的动词——“联查”“要事务”“吞吐量极高”“不可变日志”——再对应到表里。4.2 一致性模型一份资料里最容易被跳过、却最常被考的硬知识一致性是DP-900里最“抽象”的考点也是最容易丢分的地方。核心是分清强一致性和最终一致性特性强一致性最终一致性读到的数据每次都能读到最新写入值可能短暂读到旧值写入延迟较高需要同步复制确认较低异步复制即可适用场景账户余额、库存扣减、订单状态评论计数、点赞数、推荐列表故障行为写入需多数派确认可用性受影响优先保证可用稍后补齐数据备考关键考题往往给一个“读自己刚写入的数据”场景问应该用哪种一致性。如果业务要求绝对不能读到旧值比如支付后再查余额必须强一致如果晚几秒看到新数据无所谓比如文章点赞数最终一致性更合适。资料里通常会提“CAP定理”作为理论注释但DP-900的题不会深入到证明层面你能说出“分区时要在一致性和可用性之间做取舍”就够用了。一个实操中的体会这些概念在本地单机实验里永远体现不出来因为单机数据库读写都是即时的一致性冲突只出现在分布式环境下。所以练习时做对比认知就好PostgreSQL默认提供强一致的事务语义而MongoDB在副本集环境下默认的读取策略可能读到旧数据这恰恰是考纲要你建立的差异感知。5. 避坑备考路上最常见的六个翻车现场5.1 翻车现场一背下了所有概念却卡在“判断数据类型”现象看到题目给出一份包含“PDF报告 解析后的JSON 数据库导出表”三个选项分别是结构化、半结构化、非结构化结果把JSON归到了非结构化。原因把“存储载体”和“数据模式”混为一谈。JSON虽然是一段文本但文本内部有明确的键值结构可以被程序直接解析。解决做题时先问“程序能否直接识别它的字段结构”能识别就是结构化或半结构化完全无法直接解析、需要人工或AI提取才算非结构化。图片、原始音频、扫描件都是非结构化。5.2 翻车现场二事务ACID只会背缩写题目一换场景就懵现象题目问“转账过程中系统崩溃会发生什么”选项涉及事务的回滚行为。原因只背了“原子性、一致性、隔离性、持久性”四个词没理解它们具体解决的是什么问题。解决每个性质对应一个问题记忆——原子性解决“操作做一半怎么办”一致性解决“约束是否始终成立”隔离性解决“两个事务同时写冲突怎么办”持久性解决“机器断电后数据还在不在”。把每个性质翻译成一个事故场景考场看到对应关键词就能反应。5.3 翻车现场三NoSQL选型题永远第一反应选文档数据库现象题目描述一个“返回用户最近30天浏览记录”的场景正确答案是键值存储却选了文档数据库。原因没有区分键值存储和文档存储的边界。键值存储擅长“按key取整个value”文档存储的优势在于“value内部还有可查询的字段结构”。解决看题目里有没有“按某个字段做条件查询”“只读取value的一部分”。如果有选文档数据库如果只需要“给我这个key对应的完整数据”键值存储更贴合。另外列族存储的题目特征是“扫描某一列的所有行”比如统计所有设备的最新温度。5.4 翻车现场四把“备份”和“高可用”当成同一件事现象题目问“如何保证数据库在单节点故障后继续提供服务”错选成“定期做完整备份”。原因混淆了数据恢复RPO/RTO和系统连续可用高可用的关系。备份解决的是“数据丢了能恢复”高可用解决的是“服务不能停”。解决高频考点里高可用对应“副本 故障转移”备份对应“定期导出 时间点恢复”。做题时看题干问的是“数据丢失风险”还是“服务中断风险”两者答案完全不同。5.5 翻车现场五流处理和批处理的判断只看“是不是实时”现象描述一个“每小时统计一次网页日志”的场景被判定为流处理。原因以为“时间间隔短”就是实时。其实“每小时触发一次”是典型的定时批处理即使数据本身是持续产生的。解决判断标准不是延迟长短而是“处理是否由事件到达触发”。事件一来就处理、状态持续更新的是流处理按固定时间窗口统一处理一批历史数据的是批处理。记住一句话批处理是闹钟叫醒的流处理是门铃按响的。5.6 翻车现场六资料看得懂实验不去做现象考前做模拟题正确率80%上考场看到场景题频繁在两个选项之间纠结。原因知识停留在“认识层面”没到“判断层面”。认识是看到答案觉得对判断是看到题干能独立推导出答案两者之间差的是动手。解决把本文第3章的实验环境搭起来每个考点至少对应一条真实命令或查询。做完后合上资料自己对着表结构写一条查询、写一份文档、做一次聚合再对照答案看差距。挂科的人多数不是不懂而是练习时的顺利感骗了自己。6. 把错题变成一条查询语句备考后期最该养成的习惯备考进入后半程刷题量上来之后你会发现自己反复错的不是同一个知识点而是同一类“判断逻辑”。这时候再翻整本资料是没有效率的我建议你做一个动作把每一道错题的关键场景抽出来写成一个查询或一段伪代码把脑内判断固化成一个可执行的东西。举个例子。一道题说“某阅读App需要实时显示每篇文章的点赞总数允许短暂延迟但用户量巨大”正确答案是最终一致性 计数存储。你做错了原因是把“计数”和“事务账本”弄混。这时候别只在题旁打勾而是用代码表达这道题的判断逻辑# 用条件映射把一道选型题变成可执行的逻辑判断 def choose_storage(need_transaction, need_real_time, read_old_ok): 根据业务约束返回存储选型方向 need_transaction: 是否需要强事务 need_real_time: 结果是否要求实时一致 read_old_ok: 是否允许读到短暂旧数据 if need_transaction: return 关系型数据库强一致 ACID elif need_real_time and not read_old_ok: return 强一致存储方案同步复制 elif read_old_ok: return 最终一致存储方案异步复制如键值/文档 else: return 需要结合具体延迟要求进一步判断 # 模拟上面那道的场景不需要事务允许短暂延迟 print(choose_storage( need_transactionFalse, need_real_timeFalse, read_old_okTrue )) # 输出: 最终一致存储方案异步复制如键值/文档这段代码的本质是把你对考点的判断标准压缩成一个“输入条件 → 输出结论”的函数。当你把十几道错题都这样转化之后会发现那些看上去不同的题目背后的判断函数其实是同一个。这个习惯的价值不在于写代码本身而在于强迫你把模糊的“感觉”变成明确的“条件分支”——这正是场景题考查的能力。到考前一天我不再翻整本资料只运行自己积累的这几个判断脚本反复核对输出是否符合预期。用一句自己的教训收尾备考DP-900最大的陷阱不是知识点多而是你误以为“看懂了”就等于“会判断了”。把每个考点落到一条命令、一张表、一段逻辑里那张证书本身反而不重要了重要的是你从这份备考资料里拿走的是一套不靠背也能迁移的判断能力。希望帮到你。本文还有配套的精品资源点击获取