数据架构知识体系指南

数据架构迭代速度加快，数据仓库、数据湖、湖仓、数据网格等技术层出不穷，不少从业者在架构选型、项目落地中屡屡碰壁。这本《数据架构知识体系指南》系统梳理了数据技术的发展脉络，完整讲解主流架构的原理、架构形态与实施要点。书中深入剖析数据建模、ETL/ELT、数据治理等核心能力，结合大量实战案例拆解项目隐患与应对方案，同时辩证解读行业热门技术，破除认知误区。无论是数据架构师、数据工程师，还是企业技术管理者，都能从中厘清技术逻辑，结合业务场景做出合理的架构决策，搭建稳定、高效、可扩展的数据体系，是数据领域进阶与实操的优质参考读本。

本书是微软资深架构师James Serra的实战力作，以厂商中立视角系统梳理数据架构的演进脉络与核心方案。全书涵盖关系数据仓库、数据湖、现代数据仓库、数据编织、数据湖仓、数据网格六大主流架构，深入解析每种架构的设计原理、适用场景、优缺点、实施成本与技术细节，同时穿插架构设计会议实操、项目成败关键、团队组织等实战内容。书中破除行业技术神话，强调人员协作与流程优化对项目的决定性作用，既为数据架构师、开发者提供科学选型指南，也为管理者提供组织与战略参考，兼具理论深度与实操价值，助力不同规模企业精准匹配数据架构，释放数据价值。

James Serra在微软担任大数据与数据仓库解决方案架构师。他在大数据、高级分析技术的落地应用领域颇具影响力，深耕现代数据仓库、数据湖仓、数据编织、数据网格等各类数据架构。

目录<br />序1<br />前言3<br />第一部分 基础<br />第1章 大数据11<br />1.1 大数据的定义及用途12<br />1.2 数据成熟度15<br />1.2.1 第一阶段：被动反应16<br />1.2.2 第二阶段：信息化17<br />1.2.3 第三阶段：预测17<br />1.2.4 第四阶段：变革17<br />1.3 自助式商业智能18<br />1.4 总结18<br />第2章 数据架构类型20<br />2.1 数据架构的演进21<br />2.2 关系数据仓库23<br />2.3 数据湖25<br />2.4 现代数据仓库27<br />2.5 数据编织28<br />2.6 数据湖仓28<br />2.7 数据网格29<br />2.8 总结30<br />第3章 架构设计会议31<br />3.1 什么是架构设计会议31<br />3.2 架构设计会议的必要性31<br />3.3 架构设计会议的准备工作32<br />3.3.1 准备33<br />3.3.2 邀请与会者35<br />3.4 进行架构设计会议36<br />3.4.1 介绍37<br />3.4.2 探索37<br />3.4.3 白板讨论42<br />3.5 架构设计会议之后43<br />3.6 进行架构设计会议的技巧44<br />3.7 总结46<br />第二部分 通用数据架构概念<br />第4章 关系数据仓库51<br />4.1 什么是关系数据仓库51<br />4.2 非数据仓库案例54<br />4.3 自顶向下的方法55<br />4.4 关系数据仓库的优点57<br />4.5 关系数据仓库的缺点60<br />4.6 构建数据仓库61<br />4.6.1 提取数据的频率62<br />4.6.2 提取方法62<br />4.6.3 如何确定自上次提取之后的数据变化情况63<br />4.7 关系数据仓库之死被过分夸大了64<br />4.8 总结65<br />第5章 数据湖66<br />5.1 什么是数据湖66<br />5.2 选择数据湖的理由67<br />5.3 自底向上的方法69<br />5.4 数据湖设计的最佳实现方案70<br />5.5 多数据湖76<br />5.5.1 优点77<br />5.5.2 缺点79<br />5.6 总结80<br />第6章 数据存储解决方案和数据处理81<br />6.1 数据存储解决方案82<br />6.1.1 数据集市82<br />6.1.2 运营数据存储83<br />6.1.3 数据中心85<br />6.2 数据处理87<br />6.2.1 主数据管理87<br />6.2.2 数据虚拟化和数据联邦88<br />6.2.3 数据目录93<br />6.2.4 数据市场94<br />6.3 总结95<br />第7章 设计方法97<br />7.1 联机事务处理与联机分析处理98<br />7.2 运营数据和分析数据100<br />7.3 对称多处理和大规模并行处理101<br />7.4 Lambda架构102<br />7.5 Kappa架构105<br />7.6 混合持久化和多种数据存储106<br />7.7 总结107<br />第8章 数据建模方法109<br />8.1 关系建模109<br />8.1.1 键109<br />8.1.2 实体关系图110<br />8.1.3 规范化规则和形式110<br />8.1.4 跟踪变更111<br />8.2 维度建模112<br />8.2.1 事实、维度和键113<br />8.2.2 跟踪变更114<br />8.2.3 反规范化115<br />8.3 通用数据模型117<br />8.4 数据保险库117<br />8.5 Kimball和Inmon数据仓库方法论119<br />8.5.1 Inmon的自顶向下方法120<br />8.5.2 Kimball的自底向上方法121<br />8.5.3 方法选择122<br />8.5.4 混合模型123<br />8.6 方法学神话125<br />8.7 总结128<br />第9章 数据导入方法129<br />9.1 ETL与ELT129<br />9.2 反向ETL131<br />9.3 批量处理与实时处理133<br />9.3.1 批量处理的优缺点134<br />9.3.2 实时处理的优缺点134<br />9.4 数据治理135<br />9.5 总结135<br />第三部分 数据架构<br />第10章 现代数据仓库139<br />10.1 现代数据仓库架构139<br />10.2 MDW架构的利弊144<br />10.3 结合RDW和数据湖146<br />10.3.1 数据湖146<br />10.3.2 关系数据仓库146<br />10.4 MDW的阶梯型架构147<br />10.4.1 增强型EDW147<br />10.4.2 临时数据湖加EDW149<br />10.4.3 一体化150<br />10.5 案例研究：Wilson & Gunkerk公司的MDW战略转变151<br />10.5.1 挑战151<br />10.5.2 解决方案151<br />10.5.3 成果151<br />10.6 总结152<br />第11章 数据编织154<br />11.1 数据编织架构155<br />11.1.1 数据访问策略155<br />11.1.2 元数据目录156<br />11.1.3 主数据管理157<br />11.1.4 数据虚拟化157<br />11.1.5 实时处理157<br />11.1.6 应用程序接口158<br />11.1.7 服务158<br />11.1.8 产品158<br />11.2 迁移到数据编织的理由158<br />11.3 潜在缺陷159<br />11.4 总结159<br />第12章 数据湖仓161<br />12.1 Delta Lake的特性162<br />12.2 性能提升164<br />12.3 数据湖仓架构165<br />12.4 无关系数据湖仓167<br />12.5 关系服务层169<br />12.6 总结169<br />第13章 数据网格基础171<br />13.1 去中心化框架172<br />13.2 数据网格技术成熟曲线173<br />13.3 Dehghani的数据网格四原则174<br />13.3.1 原则1：域所有权174<br />13.3.2 原则2：数据即产品175<br />13.3.3 原则3：自助数据基础设施即平台177<br />13.3.4 原则4：联邦计算管理178<br />13.4 “纯”数据网格179<br />13.5 数据域180<br />13.6 数据网格逻辑架构181<br />13.7 不同拓扑183<br />13.8 数据网格与数据编织185<br />13.9 用例185<br />13.10 总结187<br />第14章 是否该采用数据网格？神话、疑虑及未来188<br />14.1 神话188<br />14.1.1 神话：使用数据网格是快速解决所有数据难题的灵丹妙药188<br />14.1.2 神话：数据网格将取代数据湖和数据仓库189<br />14.1.3 神话：如果数据仓库都失败，数据网格将解决该问题189<br />14.1.4 神话：构建数据网格代表一切进行了中心化189<br />14.1.5 神话:可使用数据虚拟化创建数据网格189<br />14.2 疑虑190<br />14.2.1 哲学和概念问题191<br />14.2.2 在去中心化环境中组合数据192<br />14.2.3 去中心化的其他问题193<br />14.2.4 复杂性194<br />14.2.5 重复194<br />14.2.6 可行性195<br />14.2.7 人员197<br />14.2.8 域层面的障碍198<br />14.3 组织评估：应该使用数据网格吗199<br />14.4 成功实施数据网格的建议200<br />14.5 数据网格的未来202<br />14.6 各个数据架构的适用性203<br />14.7 总结204<br />第四部分 人员、流程和技术<br />第15章 人员和流程207<br />15.1 团队组织：分工和职责208<br />15.1.1 MDW、数据编织或数据湖仓的分工208<br />15.1.2 数据网格的分工210<br />15.2 项目失败的原因：隐患和预防213<br />15.2.1 隐患：让高管认为BI很容易213<br />15.2.2 隐患：使用错误的技术213<br />15.2.3 隐患：收集过多的业务需求213<br />15.2.4 隐患：收集的业务需求太少214<br />15.2.5 隐患：在验证内容之前就展示报告214<br />15.2.6 隐患：雇用经验不足的咨询公司214<br />15.2.7 隐患：雇用将开发外包给离岸工作者的咨询公司215<br />15.2.8 隐患：将项目所有权移交给顾问215<br />15.2.9 隐患：忽视将知识传递回组织的需求215<br />15.2.10 隐患：项目中途削减预算215<br />15.2.11 隐患：先确定截止日期，项目倒推进行216<br />15.2.12 隐患：构建数据仓库来反映源数据而不是业务需求216<br />15.2.13 隐患：向终端用户展示的解决方案存在响应慢或其他性能问题216<br />15.2.14 隐患：过度设计（或设计不足）的数据架构217<br />15.2.15 隐患：IT和业务领域之间的沟通不畅217<br />15.3 成功的技巧217<br />15.3.1 不要吝啬投资218<br />15.3.2 让用户参与，向用户展示结果，调动用户的积极性218<br />15.3.3 为新报告和仪表盘增加价值219<br />15.3.4 要求终端用户构建原型219<br />15.3.5 寻找项目支持者/赞助商220<br />15.3.6 制订一个旨在实现80%效率的项目计划220<br />15.4 总结220<br />第16章 技术222<br />16.1 选择平台222<br />16.1.1 开源解决方案222<br />16.1.2 内部部署解决方案225<br />16.1.3 云提供商解决方案226<br />16.2 云服务模型229<br />16.2.1 主要云服务提供商231<br />16.2.2 多云解决方案232<br />16.3 软件框架234<br />16.3.1　Hadoop234<br />16.3.2 Databricks238<br />16.3.3 Snow?ake239<br />16.4 总结241