构建海量数据仓库解决方案

构建海量数据仓库解决方案沈强顾问咨询部微软(中国)有限公司议程介绍逻辑设计物理设计硬件问题ETL开发运行T3OperationalDataStore数据仓库系统的组成部分?数据仓库系统=ETL+关系型数据存储+OLAP+客户端+元数据?+数据集市?+数据挖掘?+OperationalDataStore(ODS)?数据集市和多维数据集关系型数据存储源系统客户端数据仓库系统包括OLAP和客户端数据仓库系统=ETL+关系型数据存储+OLAP+客户端为什么使用OLAP?丰富的查询功能速度对客户端多维模型的支持AnalysisServices应当是几乎所有数据仓库的组成部分海量数据仓库的特征数据量数以TB计的数据量需要深思熟虑的管理用户数上百乃至上千的用户，要求很高的稳定性和查询性能大型的服务器或分布式系统需要数据中心级的运作管理基于因特网的访问意味着多服务器和负载均衡需要为内部、外部和公共用户提供服务关键任务仔细的数据管理以防止数据丢失，保证数据的可用性大型数据仓库的常见问题ETL:在分配的时间槽内完成数据处理查询性能小型数据仓库总是比大型的要快管理的复杂性索引的备份,“裁剪”等.硬件成本和管理问题议程介绍逻辑设计物理设计硬件问题ETL开发运行T3构建大型数据仓库的替代方法清除无用的数据采用适当的数据粒度仅将细粒度的详细信息用于:统计取样(例如：5%的客户)一段很短的时间(如一天)对于Web日志是很好的方式设计范例点击流数据仓库,从代理服务器日志取数据.需求:内部站点的访问起点是什么？订阅者访问哪些内部网页？订阅者访问的频率有多高，访问时间有多长？解决方法:清除所有的图像点击,仅保存主要的页面访问(清除90%的数据)以日为单位聚集页面点击,按用户、页面和参照页面分组(再削减75%数据)为详细的连接历史建立单独的模型(用一条记录表达每一次连接或访问)90天后将详细数据归档超大型维度超大型维度(5百万以上的成员)是数据仓库面临的巨大挑战在关系数据库或多维数据库中都是挑战大型服务的每一个客户(例如：AT&T的电信客户;Microsoft.com的访问者)一个服务中的每一个Web页面(例如：AOL或WebTV)随着时间的增长,用2型慢速变化维度对付超大型维度(50万–500万个成员)的特征用户的应用程序需要成员级的详细信息吗？通过Drillthrough提供对单个成员的详细信息访问议程介绍逻辑设计物理设计硬件问题ETL开发运行T3关系数据库中的键和索引代理(整型)键总是推荐使用代理键选用经可能小的整数减小事实表的尺寸用于维护键和索引的代价很高索引的需求ETL过程和数据的完整性Cube数据装载查询Cube的drillthrough查询索引技巧使用索引调节向导(IndexTuningWizard)!!!DistinctCountCube数据装载查询中包含ORDERBY子句优化事实表的索引例子Cube1包含DistinctCount度量值Cube2包含相同的维度和其他度量值用虚拟Cube将二者组合在一起数据仓库的分区RDBMS中的分区意味着将实施表分割为多个表、最适合的情况：分区和业务功能的分割一致利用时间段进行分区好处:索引,备份,数据“裁剪”和数据装载在AnalysisServices中,cube也可以进行分区推荐在大型Cube中使用并行数据处理(CubeProcessing),尤其是初始数据装载查询性能，提高查询的选择性议程介绍逻辑设计物理设计硬件问题ETL开发运行T3RDBMS硬件:内存,处理器,网络,存储大内存!大内存!!大内存!!!RDBMS可通过WindowsAWE使用大内存(3GB以上)处理器将数据加载(ETL)程序设计为并行装载和处理数据网络带宽在源数据系统和RDBMS间建立高速连接将事实数据分布在多个控制器和多个磁盘上使用文件分区提高数据备份和恢复的性能AnalysisServices硬件:内存和网络内存:分析服务器一般最多使用4GB内存(64位硬件解决了这个问题)维度内存处理缓冲区结果集缓存网络带宽在RDBMS和Analysisserver建立高速带宽AnalysisServices硬件:存储存储空间需求通常MOLAPU的数据大小是源数据的20%-40%ROLAP会更多但都在RDBMS中HOLAP会更少磁盘配置一个逻辑驱动器使用RAID和条带集使用多个控制器以获得更高的带宽逻辑驱动器物理驱动器物理驱动器物理驱动器AnalysisServices硬件:处理器对于查询一个查询可能使用多个处理器部门级或更大的cube:“日常”的4路服务器企业级cube(基于750GB或更多的源数据):考虑使用高性能8路服务器对于Cube处理Cube处理过程仅使用2个处理器，除非应用程序设计为并行处理分区或者RDBMS和AnalysisServices位于同一台机器上议程介绍逻辑设计物理设计硬件问题ETL开发运行T3事实表的数据转换面对极大的数据量,用最高效的代码(通常是定制的代码)进行:清除“无用”数据预聚集(调整粒度)执行其他基于记录行的操作代理键查找可能使用自定义的代码可用于在删除无用数据和粒度调整后装载数据到中间表数据装载技术从文本文件中BulkInsert:使用TSQL使用DTSExecSQL任务BulkInsertDTS任务BCPDTS数据传输任务仅使用拷贝传输,最小化日志使用预定义的数据转换使用一个或多个ActiveX脚本从关系数据库中T-SQLSELECTINTO从DTSExecuteSQL任务中执行DTS数据传输任务仅使用拷贝传输,最小化日志使用预定义的数据转换使用一个或多个ActiveX脚本RDBMS:更新事实表不要更新!写入冲红事实记录！例子:Jane在Jan-15卖了5件widgets给JoeJan-16,Joe说他只需要3件2条事实表记录:Jane|Joe|widget|Jan-15|5|originalsaleJane|Joe|widget|Jan-16|-2|revision变更将自然地反映到cube中Cube处理初始数据装载技巧是----并行处理!!!需要并行处理工具最近发布的SQL2000resourcekit中包含该工具增量更新技巧是----提高选择性更新维度何时使用变化维度(Changingdimensions)变化维度(Changingdimensions)的影响增加新的事实记录对cube进行增量更新利用分区进行处理议程介绍逻辑设计物理设计硬件问题ETL开发运行T3备份与恢复RDBMS在线备份–不需要时间窗使用文件和日志备份AnalysisServices备份什么？元数据,查询日志数据如何备份？文件系统备份元数据使用SQLServer备份何时备份？重新处理选项群集和故障转移为何使用群集?平衡负载对系统失效的容错磁盘失效是引起系统失效最可能的原因不是通过群集解决,而是使用RAID或镜像业务需求是什么?群集选择MSCSNLBActiveActiveActiveStandbyMicrosoftClusterServicesNetworkLoadBalancing何时使用群集选项后端系统的完整性(RDBMS)MSCS数据只有一份拷贝前端的可伸缩性/可用性(AnalysisServices)NLB有效的使用多台服务器所有服务器需要相同的数据拷贝管理AnalysisServices的安全性注意很多角色管理上的问题注意在大维度上过多的成员安全性设置多份维度数据是潜在消耗内存的因素应用程序安全性在Web客户端的场景下,IIS可以管理安全性Cube安全性议程介绍逻辑设计物理设计硬件问题ETL开发运行T3T3项目概述展示AnalysisServices的可伸缩性从1TB+的源数据构建Cube描述在此规模数据量上进行操作的技术使用cube展示快速的查询能力概念验证系统解决实际业务问题:模式,数据,目标T3合作伙伴UnisysHTTP浏览器WebServerOLEDBforOLAPT3数据流MOLAPCubeTerminalServerRDPPC客户端OLEDBforOLAP数据仓库数据提供者的磁带UnisysES7000e-@ctionEnterpriseServersT3硬件配置OLAPServer16CPUDataWarehouse8CPUWebServer8CPUTerminalServer4CPUcLANBackboneInternetClientSystemsEMC2EnterpriseStorage3Symmetrix3830-36EnterpriseStorageNetworkEMCConnectrix3.4TB3.4TB3.4TBEMCControlCenterEDMBackupServer数据概述于实际生产数据库系统的扩展维度市场(80个市场)时间(268星期,67月,5年)产品(710,000个产品,130,000个品牌,1000个类别,500小组,100个分组,9各部门)8个事实表:在不同级别上的聚合对应于8个cube,组成一个虚拟Cube与当前生产系统的表完全一致按月分区维度和cube基于雪片型结构异质的数据粒度T3的分区设计星期月部门NosourcedataNosourcedata大类NosourcedataNosourcedata小类67月67月子类67月67月品牌67月67月项目67月x9部门67月存储需求TableRowsMBytesCubesMbytesdetail_brand_*1030093872163377Week_Brand17835detail_prodmod_*202227303182Week_Class235detail_subcat_*110304441739Week_Subgroup31detail_upc_*4881479622793767Week_Item434670month_brand_*29496701047055Month_Brand4862month_prodmod_*5082050802Month_Class66month_subcat_*2725398433Month_Subgroup29month_upc_*1428626606225316Month_Item24486Total76742277321235670MarketResearch4822147.7Billion1.2TB471GBTablestorage(relational)Cubestorage39%性能处理77亿条记录,50小时153million/hr42Krows/sec60-70%CPU利用率查询50-用户的工作负载,1350种查询,30秒思考时间冷cache中值响应时间0.08秒,平均1.2秒低CPU负载-查询数量还不够多!可以亲身体验，亲身感受AnalysisServer的强劲动力！总结SQLServerRBDMS和AnalysisServices已为海量数据仓库做好准备使用AnalysisServices做为查询引擎简化调整和管理通常需要较少的存储提高可用性和速度分析型应用的平台不同规模的ETL系统差别不太大运作成本相对较高仔细设计，精