浅谈海量数据的微软商务智能解决方案

SQL SERVER一直被看做中小型企业的首选，由于微软sql server 2008的推出，笔者越来越感觉微软要把数据库做大做强的决心，而且我感觉微软的解决方案慢慢的向中大型企业发展。

海量数据库对任何数据库对充满了挑战，如果没有一个很好的构架，不管你说db2还是teredata都难以承受，笔者有幸参与海量数据的项目，有项目每天大概有30g的增量，有些项目大概每天有200g的增量，笔者最近也荣幸的做了中国某地方移动bi构架的咨询工作，也得到SQL Customer Advisory Team的支持。海量数据如何优化呢：有以下几点值得参考：

数据仓库、ETL:每天有海量的数据（TB）的数据要导入到dw里去，在性能方面肯定会存在各种瓶颈

1、将文件组分布在尽可能多的不同的物理磁盘（spindles）上，以在数据访问时获得尽可能高的I/O吞吐量

2、日志文件组使用RAID1+0（或RAID1）卷，以获得更好的写入性能；对数据文件组，RAID1+0同样可以带来最佳的性能，但出于存储容量的限制，使用RAID5来存储数据文件以获得更大的存储空间，将日志文件组单独存放。这样可以确保I/O的顺序写入，将获得更佳的性能（这点非常重要，一般的企业的服务器都是raid5，在服务器存储规划上可以建议客户用一块磁盘来做 raid 0+1，来存放日志，如果有磁盘柜那就更方便了）

3、文件组中文件的数量与CPU核的数量保持1:1的比例关系

4、迁移tempdb，大数据量在写入时tempdb会迅速膨胀，有时候会将此逻辑分区填满，所以尽量迁移到别的足够大的磁盘上，tempdb的设置，可以参考下表。注意：将tempdb的恢复模式设置成simple

tempdb 文件大小

FILEGROWTH 增量

0 至 100 MB

10 MB

100 至 200 MB

20 MB

200 MB 或更多

10%*

5、虽然现在有了磁盘柜，数据的存储已经不是什么问题了，但是sql server 2008的强大的数据页压缩技术，让人兴废，笔者在实际的项目中800g的表，可以压缩240g以内。

6、ulkInsert数据组件可以减少cpu的使用，在cpu是瓶颈时可以考虑采用这种方式

7、分区技术，如果每天有4000w条数据的增量，可以考虑每天一个分区，然后这个分区和cube的分区对应，已获得最佳的性能。

ANALYSIS SERVICE优化：

1、分区是CUBE中的数据子集。分区中的数据可来自不同的表甚至不同的数据库。存储和聚合也可以以分区为单位设计。通过对分区进行并行处理，可以大大加快在多处理器上的处理性能。在查询时，Analysis Service也可应针对分区上定义的Slice优化查询，如果大数据量可以考虑一下每天一个分区，然后使用DDL来处理这个分区。

2、良好的聚合设计有利于查询性能。在设计聚合时，我们使用了常用的方式：先使用Aggregation Design Wizard生成部分通用聚合，再进行基于使用的优化。因为我们报表的都是通过mdx来检索数据，cube的聚合的规则是非常复杂的，在初期很难得到最佳性能的聚合，经过一短时间，我们就可以知道语句经常检索那个范围的聚合，这样子的聚合就更有针对性。

3、cube的层级关系设计一定要按照逐层来聚合，这样是优化的配置

4、Analysis Services将所有数据存储在一个逻辑目录中存储模式的选择在设计中非常重要。MOLAP方式将原数据的一份拷贝、索引及聚合存放在分析服务器上；ROLAP不存储原数据的拷贝，计算出的聚合也存放在关系数据库中；HOLAP是两者的综合：不存储原数据的拷贝，但计算出的聚合存放在分析服务器上。出于对查询性能的考虑，我们在测试中使用了MOLAP。因为数据是按多维方式存放，查询速度会快于其他两种方式

5、mdx语句功能强大，笔者自认为比较熟悉mdx，mdx的优化比较多，在这里就不详细说明了

还有好多，省略一万行

构架上的设计：

对移动、电信、互联网上网行为分析来讲，数据时海量的，一般分为 ods层、dw层、dm层、cube、report。这样做主要是为了粗粒度和细粒度数据分离，当然ods层存储最明细数据，dm层粒度是最高的。

就说到这吧，以后有机会再说吧