编程知识 cdmana.com

从60%的BI和数据仓库项目失败,看出从业者那些不堪的乱象

 

BI进入国内已经有一些年头了,国内外IT巨头都纷纷抢滩这个领域,一些中小软件企业也涉足其中。零售、制造业、快消品、航空、金融、电信等行业都成为BI实施的重要领地。
但是,说句不客气的话,大部分BI项目都是失败的,至少是问题重重,根本达不到客户的要求,数据质量、系统性能是首当其冲的主要问题。

从60%的BI和数据仓库项目失败,看出从业者那些不堪的乱象

 

从业人员中,50%以上都严重不合格,做出来的东西质量也就可想而知。

1、先说架构和设计。大部分architect看多了人家的架构设计,基本上也能拼凑个architecture出来,无非4层而已:Operational Source Systems; Data Staging Area; Data Presentation Area; Data Access Tools,或者其变异品种,或者名称稍有不同,实质都差不多。

然后是ETL的架构设计和报表层的架构设计。

从60%的BI和数据仓库项目失败,看出从业者那些不堪的乱象

 


看似很简单是吧。但是,有多少项目组真正做过非常详尽的调查?数据结构、主外键检查、引用完整性、值范围、列长度限制、空值检查、合法/不合法的值列表、隐含的业务规则等等。

如果有多个源系统,数据一般会出现不一致,不一致有多少?有没有详细的清单?如何建立企业主数据?如果这些都没考虑,或者做得不详尽,那么这个项目基本上可以说在忽悠客户。
源系统这关过了,接下来就是data staging,为何要staging? 如何staging? staging哪些?staging形式? staging性能?staging中要做哪些清洗、转换、一致性处理、补充、去重?在哪个环节做?先后顺序?
然后是数据加载到数据仓库/数据集市,在加载前,代理键的分配,迟到维度信息的处理,早到事实数据的处理,这些都考验设计者的智慧和经验。

从60%的BI和数据仓库项目失败,看出从业者那些不堪的乱象

 


但是,根据笔者的从业经验,很多项目组压根没考虑到其中的很多东西,甚至压根不知道还会有这种问题存在,所以最终做出来的东西数据质量一塌糊涂,也就丝毫不奇怪了。
好了,数据终于装载到数据仓库了,下面要做什么呢?大家都知道要做剧集。

但是,可能的查询成千上万,你聚集哪些?聚集太多了,刷新本身就要耗费太多时间,本来是为了提高查询性能的,结果客户左等右等,最后被告知系统还在刷新聚集。

本来客户每天早上要看报表的,结果你一个ETL加一个聚集处理,还有其他相关计算花了2天还没跑完,于是只好忽悠客户服务器性能不够、数据库内存太小,等等乱七八糟的借口,你还不如干脆建议客户每周看一次报表好了。
2、数据仓库建模
大部分建模师也都知道维度建模、去范式设计,大的方面基本上都知道。但是,建模最考验人的是细节,我就见过很多数据模型主体上还是去范式设计的,维度表、事实表都俱在,但是一深入了解,就发现建模师骨子里还是3NF的设计思维,因为除了主体之外的范式设计比比皆是。
SCD(缓慢变化维)也都知道如何处理,但是对于快速变化维表、巨型维度表、数量众多的只有很少记录的维表、复杂的层级关系处理、多对一关系的处理,就往往不知所措了。
更要命的是对于粒度的把握,要么粗了,导致最终很多查询实现不了;要么细了,导致数据太多,影响性能;或者粒度虽然对路了,但是相应的维度表粒度不匹配,于是弄出五花八门的补救办法。
3、性能调优
当丑媳妇最终见公婆的时候,老底曝光,性能不可能好,于是开始tuning performance,左调右调,性能也改善不了多少。于是又开始忽悠客户升级服务器,加内存。
按我的观点,性能根本就不是调出来的,而是设计出来的,你从开始各种设计就有问题,到后期怎么调也是没有用的。先把数据仓库建模、聚集的设计、 ETL的设计做好了,然后再从OS、DBMS、SQL三方面去优化,数据库哪些segment应该放在不同的硬盘上,如何partition,哪些聚集放到哪些partition上,SQL不能只图写着方便而不考虑其性能,该建哪些索引,建什么样的索引,这些都影响着性能。
所以大部分BI系统最终性能不好丝毫不足为奇,设计的人就不够专业或者考虑不周详,性能优化的人经验又不足,ETL开发者、报表开发者往往只会工具,对于SQL和各种脚本没有深入的掌握,这样做出来的东西性能自然好不到哪里去。
4、从业人员的问题
大部分人只会个工具,ETL工具,报表工具等等,甚至工具都没有会到很精深,更别谈真正领会其内涵。我就曾经做过一个ETL,要抽取的数据在无格式的日志文件中,而且该日志是最好的数据源。
报表也是,简单的都会,一到极其复杂的多主题、复杂的统计就瞎了,客户的需求有时候比较怪异,非要把完全不相干的东西整到一张报表中,你还必须实现。但是从业务上考虑,他那样的需求有其合理性,你看似不相干的东西,或者认为不必要的跨行计算,他能从中一眼看出东西来。

我就曾经给银行做过一个超级复杂的报表,把各种不同的信贷全部在一个报表里统计,有横向的统计,有纵向的统计,还有小计,逾期的分期的上期的当期的全部在一张表当中,还要分为account-level和customer-level两种统计方式。

从60%的BI和数据仓库项目失败,看出从业者那些不堪的乱象

 

我整整用了4层的subquery来进行各种分组统计,再把结果集作为上一层的源数据,还用了N多的集合操作。写好了之后,对于一个上千行的SQL我心里也没底,结果一运行,性能还不错,几分钟就跑出来了,业务部门的人一核对,数据也都正确。这东西,你要是仅用报表工具来实现是很困难的。
很多公司在招人时,为了节省成本,招几个水平较高的,再招一大堆刚入门的,以为这样的搭配就可以提高整体水平。我并不否认新手当中确实有学习能力强、聪明、逻辑思维能力不错的,这种人很快就能成长起来,但是大部分人你永远别指望他们能成为一个合格的软件工程师。

管理也存在很大问题,软件业就是软件业,它不是制造业,你拿管理生产线的方式管理软件开发,只能带出来一支士气低落、木讷迟钝、毫无创造力、实施水平也低下的队伍来。
客户呢,比较迷信大公司,因为大公司实力雄厚有保障、有成熟的管理。其实大公司也好,小公司也好,最终做事的还是那么几个人,这几个人的素质、技术水平和责任心决定了项目的成败,大公司无非是做砸了换一拨人再上,耗得起。

但问题是客户耗不起,一个好好的项目最后往往以悲剧收场,花了几百万几千万,最终性能低下,质量堪忧,莫说决策支持了,连装点个门面都嫌寒碜。

 
 

 

版权声明
本文为[帆软]所创,转载请带上原文链接,感谢
https://my.oschina.net/u/4197558/blog/4711459

Scroll to Top