新書推薦：
《
视觉美食家：商业摄影实战与创意解析
》
售價：HK$
132.2
《
中国经济发展的新阶段：机会与选择
》
售價：HK$
99.7
《
DK月季玫瑰百科
》
售價：HK$
210.6
《
为你想要的生活
》
售價：HK$
66.1
《
关键改变：如何实现自我蜕变
》
售價：HK$
77.3
《
超加工人群：为什么有些食物让人一吃就停不下来
》
售價：HK$
99.7
《
历史的教训（浓缩《文明的故事》精华，总结历史教训的独特见解）
》
售價：HK$
62.7
《
不在场证明谜案（超绝CP陷入冤案！日本文坛超新星推理作家——辻堂梦代表作首次引进！）
》
售價：HK$
58.2
|
| 編輯推薦： |
本书详解Greenplum构建实时数据仓库，涉及的具体技术包括：
MySQL主从复制，保证为业务系统提供可靠的数据库服务，并提供数据来源。Canal Server实时获取增量MySQL binlog，并将其传入Kafka消息队列。Kafka将消息持久化，同时提供可伸缩、高吞吐的消息服务。Canal ClientAdapter负责消费Kafka中的消息，将数据流传输到Greenplum。Greenplum提供实时ETL功能，自动维护操作数据存储、维度表与事实表。Greenplum数据库权限与角色管理、数据导入导出、性能优化、监控与维护。Greenplum集成机器学习库MADlib，对数据进行分析与挖掘。
|
| 內容簡介： |
Greenplum分布式数据库具有可选存储模式、事务支持、并行查询与数据装载、容错与故障转移、数据库统计、过程化语言扩展等方面的功能特性，因此Greenplum成为一款理想的分析型数据库产品。
本书详解Greenplum数据仓库构建与数据分析技术，配套示例源码。 本书共分10章。内容包括数据仓库简介、数据仓库设计基础、Greenplum与数据仓库、Greenplum安装部署、实时数据同步、实时数据装载、维度表技术、事实表技术、Greenplum运维与监控、集成机器学习库MADlib。
本书适合Greenplum初学者、大数据分析系统设计与开发、数据仓库系统设计与开发、DBA、架构师等相关技术人员阅读，也适合高等院校大数据相关专业的师生作为实训教材。
|
| 關於作者： |
|
王雪迎 ，毕业于中国地质大学计算机专业，高级工程师，20年数据库、数据仓库相关技术工作经验。先后供职于北京现代商业信息技术有限公司、北京在线九州信息技术服务有限公司、华北计算技术研究所、北京优贝在线网络科技有限公司，担任DBA、数据架构师等职位。著有图书《Greenplum构建实时数据仓库实践》《Hadoop构建数据仓库实践》《HAWQ数据仓库与数据挖掘实战》《SQL机器学习库MADlib技术解析》《MySQL高可用实践》。
|
| 目錄：
|
第1章 数据仓库简介 1
1.1 什么是数据仓库 1
1.1.1 数据仓库的定义 2
1.1.2 建立数据仓库的原因 3
1.2 操作型系统与分析型系统 5
1.2.1 操作型系统 5
1.2.2 分析型系统 7
1.2.3 操作型系统和分析型系统的对比 8
1.3 抽取—转换—装载 10
1.3.1 数据抽取 10
1.3.2 数据转换 12
1.3.3 数据装载 13
1.3.4 开发ETL系统的方法 13
1.4 数据仓库架构 14
1.4.1 基本架构 14
1.4.2 主要数据仓库架构 15
1.4.3 操作型数据存储 19
1.5 实时数据仓库 19
1.5.1 流式处理 20
1.5.2 实时计算 21
1.5.3 实时数据仓库解决方案 24
1.6 小结 26
第2章 数据仓库设计基础 27
2.1 关系数据模型 27
2.1.1 关系数据模型中的结构 27
2.1.2 关系完整性 30
2.1.3 关系数据库语言 31
2.1.4 规范化 32
2.1.5 关系数据模型与数据仓库 34
2.2 维度数据模型 36
2.2.1 维度数据模型建模过程 36
2.2.2 维度规范化 37
2.2.3 维度数据模型的特点 38
2.2.4 星型模式 39
2.2.5 雪花模式 41
2.3 Data Vault模型 43
2.3.1 Data Vault模型简介 43
2.3.2 Data Vault模型的组成部分 43
2.3.3 Data Vault模型的特点 45
2.3.4 Data Vault模型的构建 45
2.3.5 Data Vault模型实例 46
2.4 数据集市 50
2.5 数据仓库实施步骤 51
2.6 小结 54
第3章 Greenplum与数据仓库 55
3.1 Greenplum简介 55
3.1.1 历史与现状 55
3.1.2 MPP——一切皆并行 56
3.2 Greenplum系统架构 57
3.2.1 Greenplum与PostgreSQL 57
3.2.2 Master 58
3.2.3 Segment 58
3.2.4 Interconnect 59
3.3 Greenplum功能特性 59
3.3.1 存储模式 59
3.3.2 事务与并发控制 63
3.3.3 并行查询 69
3.3.4 并行数据装载 72
3.3.5 冗余与故障转移 73
3.3.6 数据库统计 76
3.4 为什么选择Greenplum 79
3.4.1 Greenplum还是SQL-on-Hadoop 79
3.4.2 适合DBA的解决方案 82
3.4.3 Greenplum的局限 86
3.5 小结 87
第4章 Greenplum安装部署 88
4.1 平台需求 88
4.1.1 操作系统 88
4.1.2 硬件和网络 89
4.1.3 文件系统 90
4.2 容量评估 90
4.2.1 可用磁盘空间 91
4.2.2 用户数据容量 91
4.2.3 元数据和日志空间 92
4.2.4 RAID划分最佳实践 92
4.3 操作系统配置 93
4.3.1 安装操作系统 94
4.3.2 禁用SELinux和防火墙 95
4.3.3 操作系统推荐配置 95
4.3.4 时钟同步 99
4.3.5 创建Greenplum管理员账号 100
4.3.6 安装JDK（可选） 101
4.4 安装Greenplum软件 101
4.4.1 安装软件包 101
4.4.2 配置免密SSH 102
4.4.3 确认软件安装 103
4.5 初始化Greenplum数据库系统 103
4.5.1 创建数据存储区 103
4.5.2 验证系统 104
4.5.3 初始化数据库 106
4.5.4 设置Greenplum环境变量 108
4.6 允许客户端连接 109
4.7 修改Greenplum配置参数 110
4.8 后续步骤 112
4.8.1 创建临时表空间 112
4.8.2 创建数据库用户 113
4.9 Greenplum升级 114
4.9.1 升级条件 114
4.9.2 升级步骤 114
4.10 小结 114
第5章 实时数据同步 116
5.1 数据抽取方式 116
5.1.1 基于源数据的CDC 117
5.1.2 基于触发器的CDC 118
5.1.3 基于快照的CDC 119
5.1.4 基于日志的CDC 119
5.2 MySQL数据复制 120
5.2.1 复制的用途 121
5.2.2 二进制日志binlog 121
5.2.3 复制的步骤 122
5.3 使用Kafka 124
5.3.1 Kafka基本概念 124
5.3.2 Kafka消费者与分区 127
5.4 选择主题分区数 129
5.4.1 使用单分区 129
5.4.2 如何选定分区数量 131
5.5 Maxwell Kafka Bireme 132
5.5.1 总体架构 132
5.5.2 Maxwell安装配置 135
5.5.3 Bireme安装配置 137
5.5.4 如何保证数据的顺序消费 141
5.5.5 实时CDC 142
5.6 Canal Server Kafka Canal ClientAdapter 148
5.6.1 总体架构 148
5.6.2 Canal Server安装配置 150
5.6.3 Canal ClientAdapter安装配置 152
5.6.4 配置HA模式 154
5.6.5 实时CDC 157
5.6.6 消费延迟监控 158
5.7 小结 161
第6章 实时数据装载 162
6.1 建立数据仓库示例模型 163
6.1.1 业务场景 163
6.1.2 建立数据库表 165
6.1.3 生成日期维度数据 173
6.2 初始装载 173
6.2.1 数据源映射 174
6.2.2 确定SCD处理方法 174
6.2.3 实现代理键 175
6.2.4 执行初始装载 175
6.3 实时装载 178
6.3.1 识别数据源与装载类型 178
6.3.2 配置增量数据同步 179
6.3.3 在Greenplum中创建规则 180
6.3.4 启动实时装载 183
6.3.5 测试 184
6.4 动态分区滚动 187
6.5 小结 189
第7章 维度表技术 190
7.1 增加列 190
7.2 维度子集 197
7.3 角色扮演维度 200
7.4 层次维度 205
7.4.1 固定深度的层次 205
7.4.2 多路径的层次 207
7.4.3 参差不齐的层次 209
7.5 退化维度 211
7.6 杂项维度 215
7.7 维度合并 220
7.8 分段维度 225
7.9 小结 230
第8章 事实表技术 231
8.1 事实表概述 231
8.2 周期快照 232
8.3 累积快照 236
8.4 无事实的事实表 245
8.5 迟到的事实 248
8.6 累积度量 256
8.7 小结 262
第9章 Greenplum运维与监控 263
9.1 权限与角色管理 263
9.1.1 Greenplum中的角色与权限 263
9.1.2 管理角色及其成员 264
9.1.3 管理对象权限 266
9.1.4 口令加密 267
9.2 数据导入导出 268
9.2.1 file://协议及其外部表 268
9.2.2 gpfdist及其外部表 270
9.2.3 基于Web的外部表 271
9.2.4 外部表错误处理 274
9.2.5 使用gpload导入数据 274
9.2.6 使用COPY互拷数据 276
9.2.7 导出数据 278
9.2.8 格式化数据文件 280
9.3 性能优化 281
9.3.1 常用优化手段 281
9.3.2 控制溢出文件 283
9.3.3 查询剖析 283
9.4 例行监控 287
9.4.1 检查系统状态 287
9.4.2 检查磁盘空间使用 289
9.4.3 检查数据分布倾斜 290
9.4.4 查看数据库对象的元数据信息 292
9.4.5 查看会话的内存使用信息 292
9.4.6 查看工作文件使用信息 293
9.4.7 查看服务器日志文件 293
9.5 例行维护 296
9.5.1 定期VACUUM 296
9.5.2 定期维护系统目录 297
9.5.3 加强的系统目录维护 297
9.5.4 为查询优化执行VACUUM与ANALYZE 298
9.5.5 自动收集统计信息 299
9.5.6 重建索引 299
9.5.7 管理数据库日志文件 299
9.6 推荐的监控与维护任务 300
9.6.1 数据库实例状态监控 300
9.6.2 硬件和操作系统监控 301
9.6.3 系统目录表监控 302
9.6.4 数据库维护 302
9.6.5 补丁与升级 303
9.7 小结 304
第10章 集成机器学习库MADlib 305
10.1 MADlib的基本概念 305
10.1.1 MADlib是什么 305
10.1.2 MADlib的设计思想 306
10.1.3 MADlib的工作原理 307
10.1.4 MADlib的执行流程 308
10.1.5 MADlib的基础架构 308
10.2 MADlib的功能 309
10.2.1 MADlib支持的模型类型 309
10.2.2 MADlib主要的功能模块 310
10.3 MADlib的安装与卸载 313
10.3.1 确定安装平台 313
10.3.2 安装MADlib 314
10.3.3 卸载MADlib 315
10.4 MADlib示例——使用矩阵分解实现用户推荐 316
10.4.1 低秩矩阵分解 316
10.4.2 奇异值分解 325
10.5 模型评估 339
10.5.1 交叉验证 340
10.5.2 MADlib的交叉验证相关函数 342
10.5.3 交叉验证示例 344
10.6 小结 346
|
| 內容試閱：
|
从Bill Inmon在1991年提出数据仓库的概念起，至今已有三十年的时间。在这期间人们所面对的数据，以及处理数据的方法都发生了翻天覆地的变化。起初数据仓库系统运行在单机或小型集群之上，程序以批处理方式周期性运行ETL作业。最为常见的执行方式是在每天业务低峰期处理前一天产生的业务数据，即所谓的T 1模式。后来随着互联网和移动终端等应用的普及，需要处理的数据量不断增大，出现了大数据的概念，以Hadoop及其生态圈组件为代表的新一代分布式大数据处理平台逐渐流行。近年来随着业务领域的不断拓展，人们对数据分析的实时性要求越来越高，离线批处理方式所产生的延时已不能满足需求。以Hadoop为代表的分布式框架并没有给出实时计算解决方案，于是便出现了Storm、Spark Streaming、Flink等实时计算框架，可提供秒级的响应时间，在此基础上实时数据仓库应运而生。
作为DBA，我更倾向于采用一种不编程、组件少、门槛低、易上手、纯SQL，并能处理包含历史全量数据的方案，用来实现实时数据仓库。不可否认，SQL仍然是数据库、数据仓库中最常使用的开发语言，也是传统数据库工程师或DBA的必会语言，从它出现至今一直被广泛使用。首先，SQL有坚实的关系代数作为理论基础，经过几十年的积累，查询优化器已经相当成熟。再者，对于开发者，SQL作为典型的非过程语言，其语法相对简单，但语义却相当丰富。据统计95%的数据分析问题都能用SQL解决，这是一个相当惊人的结论。
本书介绍的实现方案能满足以上所有要求，涉及的具体技术包括：MySQL主从复制，保证为业务系统提供可靠的数据库服务，并提供数据来源；Canal Server实时获取增量MySQL binlog，并将其传入Kafka消息队列；Kafka将消息持久化，同时提供可伸缩、高吞吐的消息服务；Canal ClientAdapter负责消费Kafka中的消息，将数据流传输到Greenplum数据库；Greenplum作为数据仓库系统，提供实时ETL功能，自动维护操作数据存储（ODS）、维度表与事实表。
Greenplum分布式数据库采用无共享（Shared-Nothing）的大规模并行处理（MPP）架构，能充分利用集群的硬件资源，将并行处理发挥到极致。Greenplum具有可选存储模式、事务支持、并行查询与数据装载、容错与故障转移、数据库统计、过程化语言扩展等方面的功能特性，正是它们支撑Greenplum成为一款理想的分析型数据库产品。
本书内容
全书共分10章。第1章说明数据仓库相关的基本概念，包括数据仓库定义、操作型系统与分析型系统、ETL、数据仓库架构等。第2章介绍三种主流的数据仓库设计模型，即关系数据模型、维度数据模型和DATA VAULT模型。第3章介绍Greenplum系统架构、功能特性、主要优缺点，以及为何适用于数据仓库应用。第4章详解Greenplum的安装部署问题。第5章介绍实时数据同步的实现，包括MySQL数据复制在实时数据仓库架构中所起的作用，如何使用Kafaka，以及Maxwell Kafka Bireme和Canal Server Kafka Canal ClientAdapter两种具体实现。第6章用一个销售订单示例说明如何使用Greenplum的规则（rule）实现实时自动数据装载。第7章和第8章分别详解多维数据仓库中常见的维度表和事实表技术，及其在Greenplum中的实现。第9章介绍Greenplum主要的、例行的与推荐的运维与监控工作。第10章作为完整数据分析体系的组成部分，介绍如何在Greenplum中集成MADlib，实现基于SQL的机器学习。
读者对象
本书所定位的读者是大数据分析系统设计和开发、数据仓库系统设计和开发、DBA、架构师等相关技术人员。所有的描绘场景与实验环境都基于Linux操作系统。假设读者已具有一定的数据库、数据仓库、SQL与Linux基础。
源码下载
本书配套的源码，需要使用微信扫描下面二维码获取，可按扫描后的页面提示，把下载链接转发到自己的邮箱中下载。如果发现问题或疑问，请电子邮件联系booksaga@163.com，邮件主题为“Greenplum构建实时数据仓库实践”。
致谢
在本书编写过程中，得到了很多人的帮助与支持。首先，感谢我所在的公司——优贝在线提供的平台和环境，感谢同事们在工作中的鼎力相助。没有那里的环境和团队，也就不会有这本书。其次，感谢清华大学出版社图格事业部的老师和编辑们，他们的辛勤工作使得本书得以尽早与读者见面。再次，感谢CSDN提供的技术分享平台，给我有一个将博客文章整理成书的机会。最后，感谢家人对我一如既往的支持。
由于水平有限，疏漏之处在所难免，希望读者批评指正。
编 者
2022年5月
1.4 数据仓库架构
前面三节介绍了数据仓库、操作型系统、分析型系统、ETL等概念，也指出了分析型系统的数据源一般来自数据仓库，而数据仓库的数据来自于操作型系统。本节将从技术角度讨论数据仓库的组成和架构。
1.4.1 基本架构
“架构”是什么？这个问题从来就没有一个准确的答案。在软件行业中，一种被普遍接受的架构定义是指系统的一个或多个结构。结构中包括软件的构建（构建是指软件的设计与实现），构建的外部可以看到属性以及它们之间的相互关系。这里参考此定义，把数据仓库架构理解成构成数据仓库的组件及其之间的关系，那么就有了如图1-1所示的数据仓库架构图。
图1-1 数据仓库架构
图1-1中显示的整个数据仓库环境，包括操作型系统和数据仓库系统两大部分。操作型系统的数据由各种形式的业务数据组成，这其中可能有关系数据库、TXT或CSV文件、HTML或XML文档，还可能存在外部系统的数据，比如网络爬虫抓取来的互联网数据等，数据可能是结构化、半结构化、非结构化的。这些数据经过抽取、转换和装载（ETL）过程进入数据仓库系统。
这里把ETL过程分成了抽取和转换、装载两个部分。抽取过程负责从操作型系统获取数据，该过程一般不做数据聚合和汇总，但是会按照主题进行集成，物理上是将操作型系统的数据全量或增量复制到数据仓库系统的RDS（Raw Data Stores）中。转换、装载过程将对数据进行清洗、过滤、汇总、统一格式化等一系列转换操作，使数据转化为适合查询的格式，然后装载进数据仓库系统的TDS（Transformed Data Stores）中。传统数据仓库的基本模式是首先用一些过程将操作型系统的数据抽取到文件，然后用另一些过程将这些文件转化成MySQL或Oracle这样的关系数据库的记录，最后用第三部分过程把数据导入进数据仓库。
RDS是原始数据存储的意思。将原始数据保存到数据仓库里是个不错的想法。ETL过程的bug或系统中的其他错误是不可避免的，保留原始数据使得追踪并修改这些错误成为可能。有时，数据仓库的用户会有查询细节数据的需求，这些细节数据的粒度与操作型系统的相同。有了RDS，这种需求就很容易实现，用户可以查询RDS里的数据且不会影响业务系统的正常运行。这里的RDS实际上是起到了操作型数据存储（Operational Data Store，ODS）的作用，关于ODS相关内容将在1.4.3小节详细论述。
TDS意为转换后的数据存储。这是真正的数据仓库中的数据。大量的用户会在经过转换的数据集上处理他们的日常查询。如果前面的工作做得好，这些数据将以保证最重要的和最频繁的查询能够快速执行的方式构建出来。
这里的原始数据存储和转换后的数据存储是逻辑概念，它们可能物理存储在一起，也可能分开。当原始数据存储和转换后的数据存储物理上分开时，它们不必使用同样的软硬件。传统数据仓库中，原始数据存储通常是本地文件系统，原始数据被组织进相应的目录中，这些目录是基于数据从哪里抽取或何时抽取建立（例如以日期作为文件或目录名称的一部分）；转换后的数据存储一般是某种关系数据库。
自动化调度组件的作用是自动定期重复执行ETL过程。不同角色的数据仓库用户对数据的更新频率要求也会有所不同，财务主管需要每月的营收汇总报告，而销售人员想看到每天的产品销售数据。作为通用的需求，所有数据仓库系统都应该能够建立周期性自动执行的工作流作业。传统数据仓库一般利用操作系统自带的调度功能（如Linux的cron或Windows的计划任务）来实现作业自动执行。
数据目录有时也被称为元数据存储，它可以提供一份数据仓库中数据的清单。用户通过它可以快速解决这些问题：什么类型的数据被存储在哪里？数据集的构建有何区别？数据最后的访问或更新时间，等等。此外，还可以通过数据目录感知数据是如何被操作和转换的。一个好的数据目录是让用户体验到系统易用性的关键。
查询引擎组件负责实际执行用户查询。传统数据仓库中，它可能是存储转换后数据的Oracle、MySQL等关系数据库系统内置的查询引擎，还可能是以固定时间间隔向其导入数据的OLAP立方体，如Essbase cube。
用户界面指的是最终用户所使用的接口程序。可能是一个GUI软件，如BI套件中的客户端软件，也可能就是一个浏览器。
1.4.2 主要数据仓库架构
在数据仓库技术演化过程中，产生了几种主要的架构方法，包括数据集市架构、Inmon企业信息工厂架构、Kimball数据仓库架构和混合型数据仓库架构。
数据集市架构
数据集市是按主题域组织的数据集合，用于支持部门级的决策。有两种类型的数据集市：独立数据集市和从属数据集市。
独立数据集市集中于部门所关心的单一主题域，数据以部门为基础部署，无须考虑企业级别的信息共享与集成。例如，制造部门、人力资源部门和其他部门都各自有他们自己的数据集市。独立数据集市从一个主题域或一个部门的多个事务系统获取数据，用以支持特定部门的业务分析需要。一个独立数据集市的设计既可以使用实体关系模型，也可以使用多维模型。数据分析或商业智能工具直接从数据集市查询数据，并将查询结果显示给用户。一个典型的独立数据集市架构如图1-2所示。
图1-2 独立数据集市架构
因为一个部门的业务相对于整个企业来说要简单得多，数据量也小得多，所以建立部门的独立数据集市具有周期短、见效快的特点。如果从企业整体的视角来观察这些数据集市，我们会看到每个部门使用不同的技术，建立不同的ETL过程，处理不同的事务系统，而在多个独立的数据集市之间还会存在数据的交叉与重叠，甚至会有数据不一致的情况。从业务角度看，当部门的分析需求扩展，或者需要分析跨部门或跨主题域的数据时，独立数据集市会显得力不从心。而当数据存在歧义，比如同一个产品，在A部门和B部门的定义不同时，将无法在部门间进行信息比较。
另外一种数据集市是从属数据集市。如Bill Inmon所说，从属数据集市的数据来源于数据仓库。数据仓库里的数据经过整合、重构、汇总后传递给从属数据集市。从属数据集市的架构如图1-3所示。
图1-3 从属数据集市架构
建立从属数据集市的好处主要有：
性能：当数据仓库的查询性能出现问题，可以考虑建立几个从属数据集市，将查询从数据仓库移出到数据集市。安全：每个部门可以完全控制自己的数据。数据一致：因为每个数据集市的数据来源都是同一个数据仓库，有效消除了数据不一致的情况。Inmon企业信息工厂架构
Inmon企业信息工厂架构如图1-4所示。
图1-4 Inmon企业信息工厂架构
我们来看图1-4中的组件是如何协同工作的。
应用系统：这些应用是组织中的操作型系统，用来支撑业务。它们收集业务处理过程中产生的销售、市场、材料、物流等数据，并将数据以多种形式进行存储。操作型系统也叫源系统，为数据仓库提供数据。ETL过程：ETL过程从操作型系统抽取数据，然后将数据转换成一种标准形式，最终将转换后的数据装载到企业级数据仓库中。ETL是周期性运行的批处理过程。企业级数据仓库：是该架构中的核心组件。正如Inmon数据仓库所定义的，企业级数据仓库是一个细节数据的集成资源库，其中的数据以最低粒度级别被捕获，存储在满足三范式设计的关系数据库中。部门级数据集市：是面向主题数据的部门级视图，数据从企业级数据仓库获取。数据在进入部门数据集市时可能进行聚合。数据集市使用多维模型设计，用于数据分析。重要的一点是，所有的报表工具、BI工具或其他数据分析应用，都从数据集市查询数据，而不是直接查询企业级数据仓库。Kimball 数据仓库架构
Kimball数据仓库架构如图1-5所示。
图1-5 Kimball数据仓库架构
对比图1-4可以看到，Kimball与Inmon两种架构的主要区别在于核心数据仓库的设计和建立。Kimball的数据仓库包含高粒度的企业数据，使用多维模型设计，这也意味着数据仓库由星型模式的维度表和事实表构成。分析系统或报表工具可以直接访问多维数据仓库里的数据。在此架构中的数据集市也与Inmon中的不同。这里的数据集市是一个逻辑概念，只是多维数据仓库中的主题域划分，并没有自己的物理存储，也可以说是虚拟的数据集市。
混合型数据仓库架构
混合型数据仓库架构如图1-6所示。
图1-6 混合型数据仓库架构
所谓的混合型结构，指的是在一个数据仓库环境中，联合使用Inmon和Kimball两种架构。从架构图可以看到，这种架构将Inmon方法中的数据集市部分替换成了一个多维数据仓库，而数据集市则是多维数据仓库上的逻辑视图。使用这种架构的好处是，既可以利用规范化设计消除数据冗余，保证数据的粒度足够细，又可以利用多维结构更灵活地在企业级数据仓库实现报表和分析。
|
|
購物車/收銀台(0) | 在線留言板
| 付款方式
| 運費計算
| 聯絡我們
| 幫助中心 |
加入書簽
HOME
新書上架
