微软BI方案参考---来自这些年的工作经验

自我介绍:

在学校的时候从asp转到asp.net从而接触了c#.net,期间为学校和社会做过很多的门面网站和一个BS的政务系统。毕业后从事BI的开发工作,主要关注SSAS往上的部分,包括复杂的动态报表的开发,后期发现Silverlight的优势所以研究RIABI中的应用,并把地图数据也应用进项目。第一个项目就取得了意想不到的效果,也成为了在BI圈里应用RIA方案里比较早的一批吃螃蟹的人。先后经历过公安,保险,广告以及电信行业的BI

题外话:为什么博客园id是aspnetx而从事的确实BI以及silverlight相关的工作,大致的原因就是如此吧。

 

 

正题:

为什么BI,海量数据的统计和分析通过BI的方案,相比于纯TSQL的统计,可以提高查询和分析的性能,另外通过多维分析的方式可以帮助客户更好的去理解数据。

最近总被问到相关的类似问题,所以平时就总结了一些,逐渐有了不成形的积累,大致记录如下。

微软可能受到些制约,所以很多产品在国内的支持力度并不是很给力,从事相关开发的人也相对少一些。本文主要根据我这些年的经验总结,给各位做评估的项目一些参考。

根据情况的不同,文中提及的产品名称没有标注版本,但通常都指其最新版本。后续版本可能会略有变化,但根据笔者的经验不会出现在未来三年中。

 

 

微软的BI产品体系:

SQLServer

BI的核心,其中从下到上包括三个部分,SSISSSASSSRS

SSIS负责ETL以及整体BI的调度。图形话界面比较直观。

SSAS,分析服务,包括Cube和数据挖掘。它也是跟我们通常所见的表和库相同的另外一种独立的库。

SSRS,报表,包括订阅和发布等功能,最新的版本集成了dundas的一些东西,比之前效果好那么一点。

以上三个模块的开发都是通过visual studio shell

 

 

附属产品体系

Office

体现在Excel中,Visio也有一些,但未见过应用。

MOSS

Sharepoint的收费版本,微软的门户解决方案。

PPS被集成到了新版中,就是以前的普科。

 

 

按照微软的产品架构的解决方案:

Windows Server

IIS

SQLServer->SSIS-SSAS-SSRA

MOSS->PPS

Office

优点,全套微软的解决方案,各部分无缝集成。前端客户培训成本低,都是其比较熟悉的Office工具。

缺点,完全依赖于微软的体系方案。比如要用PPS的一个功能,那么就被迫要部署MOSS以及购买MOSS整个的授权,对MOSS的维护又是一定的成本。

建议,除非你已经决定了采购微软的这些产品,否则还是建议你阅读完本文。

 

 

比较常见的方案:

Windows Server

IIS

SQLServer->SSAS

ETL层自定义框架

前端利用第三方组件自行开发

优点,ETLUI自己开发,可以解决比较复杂的需求。相对来说对于UI层差别很大,比如据说微软内部很多部门就是自己用Excel去连数据。

缺点,开发维护的成本高。

 

值得提一句的是,我所最近经历的项目ETL都是由团队自己封装的框架,完全不用SSIS。这个方案微软美国总部的某些专家也有提到。而我之前团队的兄弟们,除非数据量在1000万以内,否则都是宁可自己去实现ETL

关于为什么舍弃SSIS,先前团队的兄弟们曾反映过一个细节,就是在抽取Oracle数据的时候经常半路死掉,一直找不到问题。后来咨询过一些DBA,他们说是由于Oracle的驱动版本造成的问题。我相信这么一个比较折腾人的细节,就足够让很多兄弟抛弃SSIS这个平台了。

 

 

我推荐的方案:

Windows Server

IIS

SQLServer->SSAS

ASP.NET->WebServices

Silverlight

GIS

这个是我一直推荐的BI+RIA+GIS的方案。也就是利用商业智能,加富客户端比较强的展现能力,并通过地图的辅组来为客户更好的展现数据。

需要的知识体系:

操作系统,最基本的操作和维护安装等。

数据库,BI最基本的技能。

IISBS的方案现在已经成为方案的首选,另外某些情况下SSAS也要依赖一下IIS

SQL,主要在ETL层用到,而且工作量要超过整个BI的一半以上。

MDX,这个是用来查CUBE的,如果可以数据挖掘,那么还需要DMX

Powershell,某些东西用它来做会省很多事儿。

.netPowershell依赖这个,而且下面几样也依赖这个。

C#,封装服务,和silverlight开发用。

Silverlight,相比Flash的话,有经验的.net开发人员接触这个更快。

项目里根据需要可能需要一些第三方商业组件的支持,比如silverlightchart组件,这个购买一套现成的绝对比投入几个人月去开发合算的多。

 

 

国内BI 的现状:

首先,数据质量。这个在很多行业内都存在,数据的质量都比较愁人,比如外键的数值字段居然能出现全角的数字字段。IT力度实施不够也是一个原因,就像教老婆记账一样,老婆不会或者不愿意去做,最后即使做了,得到的数据也是没有意义的。

其次,需求。需求的混乱原因很多,对BI的不了解和对自己本身业务的认知程度。所谓知己知彼百战百胜,但很多行业以及项目实际上并不“知己”。

总之,项目很多,成功的少,大多都是为了报表和面子问题而去BI

 

 

微软的方案适合你吗?

相对于其它解决方案,可以说微软的产品确实存在些不足的地方,但是,随着SQLServer的版本演进,目前的版本来说这个差距应该已经说很小了,当然也不存在其它产品解决的了,而微软的产品解决不了的情况。

如果是遇到实在解决不了的问题,那么我觉得应该首先审视一下BI的建模,然后审视一下需求,因为大多数你费劲去解决的东西,实际上后来都不是用户所关注的,后者是纯粹的面子工程。

 

实现我的功能需要多长时间?

这个是经常被问到的问题。考虑这个问题主要还是要从几个方面来分析:数据的情况,比如数据量和数据质量等,此外还有需求的复杂程度以及业务的复杂程度,都决定时间的长短。当然这些确定了,项目才可以继续做计划。

另项目基本上都是以螺旋上升的形式来开发,很少说有第一版就成功的,这个过程是需要不断探索和积累的。

 

相关人员好招聘否以及Team的构建

很少有直接就做BI的人,但基本上都有两种情况,一种是从DBA转过来的,一种是从开发转过来的。我想我是后者。前者偏重底层,后者偏重表层。招聘的时候可以根据这个特点以及项目的情况来选择。

关于Team的构建,我见过比较多的是后边和前边分开的那种。也就是说数据库层的BI开发是管“后边”的人,做.net开发的是“前边”的人。我不反对这种划分,但是按照我的经验来说,一定要注意前后的衔接,虽然两个部分是两个队伍,但是一定要有一个认知就是大家是一个队伍,共同承担着项目的成败。而这里也需要一个天平来做一些决策,有些东西通过后边来解决,可以省很多前边的人的事,而有些东西如果前边稍微处理下,能给后边的人少很多麻烦。

 

BI有比较合适的参考资源吗?

我建议看SQLServerBooks on line,尽量看英文版吧,中文版有些细节翻译的实在不敢恭维。此外,微软的webcast也很值得在参考,虽然每节课都很长而且比较枯燥和抽象,但还是建议没事看看。

 

 

总结:

从某一个产品的角度来讲,也许微软在这小的方面做的不是很好,但是整体来说跟其它方案已经没有什么太大的差距,对,是太大的差距,差距还是有的,但是他的某些优点又足以弥补。此文从一个从业人员的经验角度出发,尽量不带任何感情色彩。部分可能带有本人在某些领域的短见,或者存在着错误以至于误人子弟,还请各位高手们指出。BI是个有潜力的领域,是个有价值的领域,国内也算个新生领域吧,圈子很小,还望有高人给予指点。

作者: aspnetx 发表于 2011-10-10 23:38 原文链接

评论: 5 查看评论 发表评论

最新新闻:
· 10大明星域名:盘点找上明星代言电商平台(2011-10-11 11:28)
· 开源的系统级编程利器:D语言(2011-10-11 11:26)
· 微软:升级至Windows 8会导致部分软件无法运行(2011-10-11 11:24)
· iPhone 4S上手视频(2011-10-11 11:23)
· 社交问答之心不死,Facebook收购社交问答服务Friend.ly(2011-10-11 11:22)

编辑推荐:分享我对领域驱动设计(DDD)的学习成果

网站导航:博客园首页  我的园子  新闻  闪存  小组  博问  知识库

你可能感兴趣的:(工作,BI,微软)