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

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

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

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

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

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

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

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

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

本来客户每天早上要看报表的，结果你一个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两种统计方式。

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

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

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

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

80%数据仓库都失败，批从业者那些不堪的乱象
点击蓝色"有关SQL"关注我哟加个"星标",天天与10000人一起快乐成长图 | L | 上海乌鲁木齐路说明:本文摘自 http://www.itpub ...
应用实践 | 特步集团基于 Apache Doris 的零售数据仓库项目实践
背景特步集团有限公司是中国领先的体育用品企业之一,主要从事运动鞋.服装及配饰的设计.开发.制造和销售. 为了提高特步零售 BI 主题数据分析的准确性和时效性,降低对 SAP HANA 平台的依赖,2 ...
思科：全球近75%的物联网项目失败
据悉,随着全球物联网(IoT)生态系统的蓬勃发展,一项新的调查发现,三分之一完成的项目无法实现其目标,同时可以通过更多工作完成更多项目. 思科:全球近75%的物联网项目失败由全球网络巨头思科进行的这 ...
管理者必看！深度剖析BI与数据仓库，企业能否成功转型就看它
如果把商业智能(BI)比喻成一个房子,那么数据仓库就是它的地基.一句话总结:数据仓库是BI背后的引擎. 数据仓库: 从字面意义上即数据的仓库,是为了把操作型数据集成到统一的环境中,以提供决策型数据访问 ...
软件项目失败的心理原因
这是一篇有关软件工程领域中事务状态的评论文章.它讨论了程序员的实际挑战和实际职责.它把程序员分为四个类别:聪明.强盗.无助和愚蠢,另外两个类别是天真和无知.它讨论了程序员必须如何熟悉特定领域,不仅能够 ...
数据中台的数据仓库和商业智能BI的数据仓库有什么区别？
数据中台的数据仓库和商业智能BI的数据仓库本质上没有任何区别,都是在底层业务系统数据源和上层应用之间做了一个隔离层,进行上下两层的解耦合.从数据分析应用角度来讲,不管是大数据还是小数据,都是把业务系统 ...
戏说数据仓库，商业智能BI中数据仓库的本质是什么？
平时和朋友聊天,一谈到商业智能BI总是离不开数据仓库,有很多人不太明白数据仓库到底在商业智能BI项目中有什么作用,对数据仓库的作用有些争论,所以今天来聊聊数据仓库,探讨下数据仓库的真正用处. 数据仓库 ...
【Flink实时数仓】数据仓库项目实战《四》日志数据分流【DWD】
文章目录 [Flink实时数仓]数据仓库项目实战 <四>日志数据分流-流量域 [DWD] 1.流量域未经加工的事务事实表 1.1主要任务 1.1.1数据清洗(ETL) 1.1.2新老访客状 ...
视频教程-全新大数据企业电商数据仓库项目实战教程-大数据
全新大数据企业电商数据仓库项目实战教程张长志技术全才.擅长领域:区块链.大数据.Java等.10余年软件研发及企业培训经验,曾为多家大型企业提供企业内训如中石化,中国联通,中国移动等知名企业.拥有丰 ...

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

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

最新文章

热门文章