高级检索结果页
欢迎来到工程科技数字图书馆
登录 | 注册
 
您当前的位置:图书 > 数据架构知识体系指南

数据架构知识体系指南

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

封面
书名页
版权
O'Reilly Media, Inc.介绍
本书赞誉
译者序

前言
第一部分 基础
 第1章 大数据
  1.1 大数据的定义及用途
  1.2 数据成熟度
   1.2.1 第一阶段:被动反应
   1.2.2 第二阶段:信息化
   1.2.3 第三阶段:预测
   1.2.4 第四阶段:变革
  1.3 自助式商业智能
  1.4 总结
 第2章 数据架构类型
  2.1 数据架构的演进
  2.2 关系数据仓库
  2.3 数据湖
  2.4 现代数据仓库
  2.5 数据编织
  2.6 数据湖仓
  2.7 数据网格
  2.8 总结
 第3章 架构设计会议
  3.1 什么是架构设计会议
  3.2 架构设计会议的必要性
  3.3 架构设计会议的准备工作
   3.3.1 准备
   3.3.2 邀请与会者
  3.4 进行架构设计会议
   3.4.1 介绍
   3.4.2 探索
   3.4.3 白板讨论
  3.5 架构设计会议之后
  3.6 进行架构设计会议的技巧
  3.7 总结
第二部分 通用数据架构概念
 第4章 关系数据仓库
  4.1 什么是关系数据仓库
  4.2 非数据仓库案例
  4.3 自顶向下的方法
  4.4 关系数据仓库的优点
  4.5 关系数据仓库的缺点
  4.6 构建数据仓库
   4.6.1 提取数据的频率
   4.6.2 提取方法
   4.6.3 如何确定自上次提取之后的数据变化情况
  4.7 关系数据仓库之死被过分夸大了
  4.8 总结
 第5章 数据湖
  5.1 什么是数据湖
  5.2 选择数据湖的理由
  5.3 自底向上的方法
  5.4 数据湖设计的最佳实现方案
  5.5 多数据湖
   5.5.1 优点
   5.5.2 缺点
  5.6 总结
 第6章 数据存储解决方案和数据处理
  6.1 数据存储解决方案
   6.1.1 数据集市
   6.1.2 运营数据存储
   6.1.3 数据中心
  6.2 数据处理
   6.2.1 主数据管理
   6.2.2 数据虚拟化和数据联邦
   6.2.3 数据目录
   6.2.4 数据市场
  6.3 总结
 第7章 设计方法
  7.1 联机事务处理与联机分析处理
  7.2 运营数据和分析数据
  7.3 对称多处理和大规模并行处理
  7.4 Lambda架构
  7.5 Kappa架构
  7.6 混合持久化和多种数据存储
  7.7 总结
 第8章 数据建模方法
  8.1 关系建模
   8.1.1 键
   8.1.2 实体关系图
   8.1.3 规范化规则和形式
   8.1.4 跟踪变更
  8.2 维度建模
   8.2.1 事实、维度和键
   8.2.2 跟踪变更
   8.2.3 反规范化
  8.3 通用数据模型
  8.4 数据保险库
  8.5 Kimball和Inmon数据仓库方法论
   8.5.1 Inmon的自顶向下方法
   8.5.2 Kimball的自底向上方法
   8.5.3 方法选择
   8.5.4 混合模型
  8.6 方法学神话
  8.7 总结
 第9章 数据导入方法
  9.1 ETL与ELT
  9.2 反向ETL
  9.3 批量处理与实时处理
   9.3.1 批量处理的优缺点
   9.3.2 实时处理的优缺点
  9.4 数据治理
  9.5 总结
第三部分 数据架构
 第10章 现代数据仓库
  10.1 现代数据仓库架构
  10.2 MDW架构的利弊
  10.3 结合RDW和数据湖
   10.3.1 数据湖
   10.3.2 关系数据仓库
  10.4 MDW的阶梯型架构
   10.4.1 增强型EDW
   10.4.2 临时数据湖加EDW
   10.4.3 一体化
  10.5 案例研究:Wilson&Gunkerk公司的MDW战略转变
   10.5.1 挑战
   10.5.2 解决方案
   10.5.3 成果
  10.6 总结
 第11章 数据编织
  11.1 数据编织架构
   11.1.1 数据访问策略
   11.1.2 元数据目录
   11.1.3 主数据管理
   11.1.4 数据虚拟化
   11.1.5 实时处理
   11.1.6 应用程序接口
   11.1.7 服务
   11.1.8 产品
  11.2 迁移到数据编织的理由
  11.3 潜在缺陷
  11.4 总结
 第12章 数据湖仓
  12.1 Delta Lake的特性
  12.2 性能提升
  12.3 数据湖仓架构
  12.4 无关系数据湖仓
  12.5 关系服务层
  12.6 总结
 第13章 数据网格基础
  13.1 去中心化框架
  13.2 数据网格技术成熟曲线
  13.3 Dehghani的数据网格四原则
   13.3.1 原则1:域所有权
   13.3.2 原则2:数据即产品
   13.3.3 原则3:自助数据基础设施即平台
   13.3.4 原则4:联邦计算管理
  13.4 “纯”数据网格
  13.5 数据域
  13.6 数据网格逻辑架构
  13.7 不同拓扑
  13.8 数据网格与数据编织
  13.9 用例
  13.10 总结
 第14章 是否该采用数据网格?神话、疑虑及未来
  14.1 神话
   14.1.1 神话:使用数据网格是快速解决所有数据难题的灵丹妙药
   14.1.2 神话:数据网格将取代数据湖和数据仓库
   14.1.3 神话:如果数据仓库都失败,数据网格将解决该问题
   14.1.4 神话:构建数据网格代表一切进行了中心化
   14.1.5 神话:可使用数据虚拟化创建数据网格
  14.2 疑虑
   14.2.1 哲学和概念问题
   14.2.2 在去中心化环境中组合数据
   14.2.3 去中心化的其他问题
   14.2.4 复杂性
   14.2.5 重复
   14.2.6 可行性
   14.2.7 人员
   14.2.8 域层面的障碍
  14.3 组织评估:应该使用数据网格吗
  14.4 成功实施数据网格的建议
  14.5 数据网格的未来
  14.6 各个数据架构的适用性
  14.7 总结
第四部分 人员、流程和技术
 第15章 人员和流程
  15.1 团队组织:分工和职责
   15.1.1 MDW、数据编织或数据湖仓的分工
   15.1.2 数据网格的分工
  15.2 项目失败的原因:隐患和预防
   15.2.1 隐患:让高管认为BI很容易
   15.2.2 隐患:使用错误的技术
   15.2.3 隐患:收集过多的业务需求
   15.2.4 隐患:收集的业务需求太少
   15.2.5 隐患:在验证内容之前就展示报告
   15.2.6 隐患:雇用经验不足的咨询公司
   15.2.7 隐患:雇用将开发外包给离岸工作者的咨询公司
   15.2.8 隐患:将项目所有权移交给顾问
   15.2.9 隐患:忽视将知识传递回组织的需求
   15.2.10 隐患:项目中途削减预算
   15.2.11 隐患:先确定截止日期,项目倒推进行
   15.2.12 隐患:构建数据仓库来反映源数据而不是业务需求
   15.2.13 隐患:向终端用户展示的解决方案存在响应慢或其他性能问题
   15.2.14 隐患:过度设计(或设计不足)的数据架构
   15.2.15 隐患:IT和业务领域之间的沟通不畅
  15.3 成功的技巧
   15.3.1 不要吝啬投资
   15.3.2 让用户参与,向用户展示结果,调动用户的积极性
   15.3.3 为新报告和仪表盘增加价值
   15.3.4 要求终端用户构建原型
   15.3.5 寻找项目支持者/赞助商
   15.3.6 制订一个旨在实现80%效率的项目计划
  15.4 总结
 第16章 技术
  16.1 选择平台
   16.1.1 开源解决方案
   16.1.2 内部部署解决方案
   16.1.3 云提供商解决方案
  16.2 云服务模型
   16.2.1 主要云服务提供商
   16.2.2 多云解决方案
  16.3 软件框架
   16.3.1 Hadoop
   16.3.2 Databricks
   16.3.3 Snowflake
  16.4 总结
作者简介
封面简介
封底

机工科技数字图书馆