构建海量数据仓库解决方案课件.ppt

议程 介绍 逻辑设计 物理设计 硬件问题 ETL开发 运行 T3 数据仓库系统的组成部分? 数据仓库系统 = ETL + 关系型数据存储 + OLAP + 客户端 + 元数据 ? + 数据集市 ? + 数据挖掘 ? + Operational Data Store (ODS) ? 数据仓库系统包括OLAP和客户端 数据仓库系统 = ETL + 关系型数据存储 + OLAP + 客户端 为什么使用OLAP? 丰富的查询功能 速度 对客户端多维模型的支持 Analysis Services 应当是几乎所有数据仓库的组成部分 海量数据仓库的特征 数据量 数以TB计的数据量需要深思熟虑的管理 用户数 上百乃至上千的用户，要求很高的稳定性和查询性能 大型的服务器或分布式系统 需要数据中心级的运作管理 基于因特网的访问 意味着多服务器和负载均衡 需要为内部、外部和公共用户提供服务 关键任务 仔细的数据管理以防止数据丢失，保证数据的可用性 大型数据仓库的常见问题 ETL: 在分配的时间槽内完成数据处理 查询性能 小型数据仓库总是比大型的要快 管理的复杂性 索引的备份, “裁剪” 等. 硬件成本和管理问题 议程 介绍 逻辑设计 物理设计 硬件问题 ETL开发 运行 T3 构建大型数据仓库的替代方法 清除无用的数据 采用适当的数据粒度 仅将细粒度的详细信息用于: 统计取样 (例如： 5% 的客户) 一段很短的时间 (如一天) 对于Web日志是很好的方式 设计范例 点击流数据仓库, 从代理服务器日志取数据.需求: 内部站点的访问起点是什么？ 订阅者访问哪些内部网页？ 订阅者访问的频率有多高，访问时间有多长？ 解决方法: 清除 所有的图像点击, 仅保存主要的页面访问 (清除 90% 的数据) 以日为单位聚集页面点击, 按用户、页面和参照页面分组 (再削减 75% 数据) 为详细的连接历史建立单独的模型 (用一条记录表达每一次连接或访问) 90天后将详细数据归档 超大型维度 超大型维度 (5百万以上的成员) 是数据仓库面临的巨大挑战 在关系数据库或多维数据库中都是挑战 大型服务的每一个客户 (例如：ATT 的电信客户; M的访问者) 一个服务中的每一个Web页面(例如：AOL或WebTV) 随着时间的增长, 用2型慢速变化维度对付超大型维度(50万 – 500万个成员)的特征 用户的应用程序需要成员级的详细信息吗？ 通过Drillthrough提供对单个成员的详细信息访问 议程 介绍 逻辑设计 物理设计 硬件问题 ETL开发 运行 T3 关系数据库中的键和索引 代理 (整型)键 总是推荐使用代理键 选用经可能小的整数减小事实表的尺寸 用于维护键和索引的代价很高 索引的需求 ETL 过程和数据的完整性 Cube数据装载查询 Cube的drillthrough查询 索引技巧 使用索引调节向导(Index Tuning Wizard)!!! Distinct Count Cube数据装载查询中包含ORDER BY子句 优化事实表的索引 例子 Cube1 包含Distinct Count度量值 Cube2 包含相同的维度和其他度量值 用虚拟Cube将二者组合在一起 数据仓库的分区 RDBMS中的分区意味着将实施表分割为多个表、 最适合的情况：分区和业务功能的分割一致 利用时间段进行分区 好处: 索引, 备份, 数据 “裁剪” 和数据装载 在Analysis Services中, cube也可以进行分区 推荐在大型Cube中使用 并行数据处理(Cube Processing), 尤其是初始数据装载 查询性能，提高查询的选择性 议程 介绍 逻辑设计 物理设计 硬件问题 ETL开发 运行 T3 RDBMS硬件: 内存, 处理器, 网络, 存储 大内存!大内存!!大内存!!! RDBMS可通过Windows AWE使用大内存 (3 GB以上) 处理器 将数据加载(ETL)程序设计为并行装载和处理数据 网络带宽 在源数据系统和RDBMS间建立高速连接 将事实数据分布在多个控制器和多个磁盘上 使用文件分区提高数据备份和恢复的性能 Analysis Services硬件: 内存和网络 内存: 分析服务器一般最多使用4 GB内存 (64位硬件解决了这个问题) 维度内存 处理缓冲区 结果集缓存 网络带宽 在RDBMS和Analysis server建立高速带宽 Analysis Services硬件: 存储 存储空间需求 通常MOLAPU的数据大小是源数据的20%-40% ROLAP会更多但都在RDBMS中 HOLAP会更少 磁盘配置 一个逻辑驱动器 使用RAID和条带集 使用多个控制器以获得更高的带宽 Analysis Services硬件: 处理器 对于查询 一个查询