《《精编》构建海量数据仓库解决方案》由会员分享，可在线阅读，更多相关《《精编》构建海量数据仓库解决方案（41页珍藏版）》请在金锄头文库上搜索。
1、构建海量数据仓库解决方案 议程 介绍逻辑设计物理设计硬件问题ETL开发运行T3 OperationalDataStore 数据仓库系统的组成部分 数据仓库系统 ETL 关系型数据存储 OLAP 客户端 元数据 数据集市 数据挖掘 OperationalDataStore ODS 数据集市和多维数据集 关系型数据存储 源系统 客户端 数据仓库系统包括OLAP和客户端 数据仓库系统 ETL 关系型数据存储 OLAP 客户端为什么使用OLAP 丰富的查询功能速度对客户端多维模型的支持AnalysisServices应当是几乎所有数据仓库的组成部分 海量数据仓库的特征 数据量数以TB计的数据量需要深思
2、熟虑的管理用户数上百乃至上千的用户 要求很高的稳定性和查询性能大型的服务器或分布式系统需要数据中心级的运作管理基于因特网的访问意味着多服务器和负载均衡需要为内部 外部和公共用户提供服务关键任务仔细的数据管理以防止数据丢失 保证数据的可用性 大型数据仓库的常见问题 ETL 在分配的时间槽内完成数据处理查询性能小型数据仓库总是比大型的要快管理的复杂性索引的备份 裁剪 等 硬件成本和管理问题 议程 介绍逻辑设计物理设计硬件问题ETL开发运行T3 构建大型数据仓库的替代方法 清除无用的数据采用适当的数据粒度仅将细粒度的详细信息用于 统计取样 例如 5 的客户 一段很短的时间 如一天 对于Web日志是很
3、好的方式 设计范例 点击流数据仓库 从代理服务器日志取数据 需求 内部站点的访问起点是什么 订阅者访问哪些内部网页 订阅者访问的频率有多高 访问时间有多长 解决方法 清除所有的图像点击 仅保存主要的页面访问 清除90 的数据 以日为单位聚集页面点击 按用户 页面和参照页面分组 再削减75 数据 为详细的连接历史建立单独的模型 用一条记录表达每一次连接或访问 90天后将详细数据归档 超大型维度 超大型维度 5百万以上的成员 是数据仓库面临的巨大挑战在关系数据库或多维数据库中都是挑战大型服务的每一个客户 例如 ATM的访问者 一个服务中的每一个Web页面 例如 AOL或WebTV 随着时间的增长
4、用2型慢速变化维度对付超大型维度 50万 500万个成员 的特征用户的应用程序需要成员级的详细信息吗 通过Drillthrough提供对单个成员的详细信息访问 议程 介绍逻辑设计物理设计硬件问题ETL开发运行T3 关系数据库中的键和索引 代理 整型 键总是推荐使用代理键选用经可能小的整数减小事实表的尺寸用于维护键和索引的代价很高索引的需求ETL过程和数据的完整性Cube数据装载查询Cube的drillthrough查询索引技巧使用索引调节向导 IndexTuningWizard DistinctCountCube数据装载查询中包含ORDERBY子句优化事实表的索引例子Cube1包含Distin
5、ctCount度量值Cube2包含相同的维度和其他度量值用虚拟Cube将二者组合在一起 数据仓库的分区 RDBMS中的分区意味着将实施表分割为多个表 最适合的情况 分区和业务功能的分割一致利用时间段进行分区好处 索引 备份 数据 裁剪 和数据装载在AnalysisServices中 cube也可以进行分区推荐在大型Cube中使用并行数据处理 CubeProcessing 尤其是初始数据装载查询性能 提高查询的选择性 议程 介绍逻辑设计物理设计硬件问题ETL开发运行T3 RDBMS硬件 内存 处理器 网络 存储 大内存 大内存 大内存 RDBMS可通过WindowsAWE使用大内存 3GB以上
6、处理器将数据加载 ETL 程序设计为并行装载和处理数据网络带宽在源数据系统和RDBMS间建立高速连接将事实数据分布在多个控制器和多个磁盘上使用文件分区提高数据备份和恢复的性能 AnalysisServices硬件 内存和网络 内存 分析服务器一般最多使用4GB内存 64位硬件解决了这个问题 维度内存处理缓冲区结果集缓存网络带宽在RDBMS和Analysisserver建立高速带宽 AnalysisServices硬件 存储 存储空间需求通常MOLAPU的数据大小是源数据的20 40 ROLAP会更多但都在RDBMS中HOLAP会更少磁盘配置一个逻辑驱动器使用RAID和条带集使用多个控制器以获得
7、更高的带宽 逻辑驱动器 物理驱动器 物理驱动器 物理驱动器 AnalysisServices硬件 处理器 对于查询一个查询可能使用多个处理器部门级或更大的cube 日常 的4路服务器企业级cube 基于750GB或更多的源数据 考虑使用高性能8路服务器对于Cube处理Cube处理过程仅使用2个处理器 除非应用程序设计为并行处理分区或者RDBMS和AnalysisServices位于同一台机器上 议程 介绍逻辑设计物理设计硬件问题ETL开发运行T3 事实表的数据转换 面对极大的数据量 用最高效的代码 通常是定制的代码 进行 清除 无用 数据预聚集 调整粒度 执行其他基于记录行的操作代理键查找可能
8、使用自定义的代码可用于在删除无用数据和粒度调整后装载数据到中间表 数据装载技术 从文本文件中BulkInsert 使用TSQL使用DTSExecSQL任务BulkInsertDTS任务BCPDTS数据传输任务仅使用拷贝传输 最小化日志使用预定义的数据转换使用一个或多个ActiveX脚本 从关系数据库中T SQLSELECTINTO从DTSExecuteSQL任务中执行DTS数据传输任务仅使用拷贝传输 最小化日志使用预定义的数据转换使用一个或多个ActiveX脚本 RDBMS 更新事实表 不要更新 写入冲红事实记录 例子 Jane在Jan 15卖了5件widgets给JoeJan 16 Joe说
9、他只需要3件2条事实表记录 Jane Joe widget Jan 15 5 originalsaleJane Joe widget Jan 16 2 revision变更将自然地反映到cube中 Cube处理 初始数据装载技巧是 并行处理 需要并行处理工具最近发布的SQL2000resourcekit中包含该工具 议程 介绍逻辑设计物理设计硬件问题ETL开发运行T3 备份与恢复 RDBMS在线备份 不需要时间窗使用文件和日志备份AnalysisServices备份什么 元数据 查询日志数据如何备份 文件系统备份元数据使用SQLServer备份何时备份 重新处理选项 群集和故障转移 为何使用群
10、集 平衡负载对系统失效的容错磁盘失效是引起系统失效最可能的原因不是通过群集解决 而是使用RAID或镜像业务需求是什么 群集选择 MSCSNLB Active Active Active Standby MicrosoftClusterServices NetworkLoadBalancing 何时使用群集选项 后端系统的完整性 RDBMS MSCS数据只有一份拷贝前端的可伸缩性 可用性 AnalysisServices NLB有效的使用多台服务器所有服务器需要相同的数据拷贝 管理AnalysisServices的安全性 注意很多角色管理上的问题注意在大维度上过多的成员安全性设置多份维度数据是潜
11、在消耗内存的因素应用程序安全性在Web客户端的场景下 IIS可以管理安全性Cube安全性 议程 介绍逻辑设计物理设计硬件问题ETL开发运行T3 T3项目概述 T3项目目标 展示AnalysisServices的可伸缩性从1TB 的源数据构建Cube描述在此规模数据量上进行操作的技术使用cube展示快速的查询能力概念验证系统解决实际业务问题 模式 数据 目标 T3合作伙伴 T3数据流 UnisysES7000e ctionEnterpriseServers T3硬件配置 OLAPServer16CPU DataWarehouse8CPU WebServer8CPU TerminalServer4
12、CPU 数据概述 于实际生产数据库系统的扩展维度市场 80个市场 时间 268星期 67月 5年 产品 710 000个产品 130 000个品牌 1000个类别 500小组 100个分组 9各部门 8个事实表 在不同级别上的聚合对应于8个cube 组成一个虚拟Cube与当前生产系统的表完全一致按月分区 维度和cube 基于雪片型结构 异质的数据粒度 T3的分区设计 存储需求 39 性能 处理77亿条记录 50小时153million hr42Krows sec60 70 CPU利用率查询50 用户的工作负载 1350种查询 30秒思考时间冷cache中值响应时间0 08秒 平均1 2秒低CPU负载 查询数量还不够多 可以亲身体验 亲身感受AnalysisServer的强劲动力
