点击蓝色“有关SQL”
但是，说句不客气的话，大部分BI项目都是失败的，至少是问题重重，根本达不到客户的要求，数据质量、系统性能是首当其冲的主要问题。从业人员中，50%以上都严重不合格，做出来的东西质量也就可想而知。
1、先说架构和设计。大部分architect看多了人家的架构设计，基本上也能拼凑个architecture出来，无非4层而已：OperationalSourceSystems;DataStagingArea;DataPresentationArea;DataAccessTools，或者其变异品种，或者名称稍有不同，实质都差不多。然后是ETL的架构设计，从sourcesystems到datastagingarea，从datastagingarea到datamarts。然后是报表层的架构设计。
看似很简单是吧。但是，有多少项目组真正做过sourcesystems的datadiscovery和anomalydetection,非常详尽的调查？数据结构、主外键检查、引用完整性、值范围、列长度限制、空值检查、合法/不合法的值列表、隐含的业务规则等等。如果有多个源系统，数据一般会出现不一致，不一致有多少？有没有详细的清单？如何建立企业masterdata？如果这些都没考虑，或者做的不详尽，那么这个项目基本上可以说在忽悠客户。
源系统这关过了，接下来就是datastaging，为何要staging?如何staging?staging哪些？staging形式?staging性能？staging中要做哪些清洗、转换、一致性处理、补充、去重？在哪个环节做？先后顺序？
然后是数据加载到数据仓库/数据集市，在加载前，代理键的分配，迟到维度信息的处理，早到事实数据的处理，这些都考验设计者的智慧和经验。
但是，根据笔者的从业经验，很多项目组压根没考虑到其中的很多东西，甚至压根不知道还会有这种问题存在，所以最终做出来的东西数据质量一塌糊涂，也就丝毫不奇怪了。
好了，数据终于装载到数据仓库了，下面要做什么呢？都知道要做聚集。但是，可能的查询成千上万，你聚集哪些？聚集太多了，刷新本身就要耗费太多时间，本来是为了提高查询性能的，结果客户左等右等，最后被告知系统还在刷新聚集。本来客户每天早上要看报表的，结果你一个ETL加一个聚集处理，还有其他相关计算花了2天还没跑完，于是只好忽悠客户服务器性能不够、数据库系统内存太小，等等乱七八糟的借口，你还不如干脆建议客户每周看一次报表好了。
2、数据仓库建模
大部分建模师也都知道维度建模、去范式设计，大的方面基本上都知道。但是，建模最考验人的是细节，我就见过很多数据模型主体上还是去范式设计的，维度表、事实表都俱在，但是一深入了解，就发现建模师骨子里还是3NF的设计思维，因为除了主体之外的范式设计比比皆是。
SCD(缓慢变化维)也都知道如何处理，但是对于快速变化维表、巨型维度表、数量众多的只有很少记录的维表、复杂的层级关系处理、多对一关系的处理，就往往不知所措了。
更要命的是对于粒度的把握，要么粗了，导致最终很多查询实现不了；要么细了，导致数据太多，影响性能；或者粒度虽然对路了，但是相应的维度表粒度不匹配，于是弄出五花八门的补救办法。
3、性能调优
当丑媳妇最终见公婆的时候，老底曝光，性能不可能好，于是开始tuningperformance，左调右调，性能也改善不了多少。于是又开始忽悠客户升级服务器，加内存。
按我的观点，性能根本就不是调出来的，而是设计出来的，你从开始各种设计就有问题，到后期怎么调也是没有用的。先把数据仓库建模、聚集的设计、ETL的设计做好了，然后再从OS、DBMS、SQL三方面去优化，数据库哪些segment应该放在不同的硬盘上，如何partition，哪些聚集放到哪些partition上，SQL不能只图写着方便而不考虑其性能，该建哪些索引，建什么样的索引，这些都影响着性能。
所以大部分BI系统最终性能不好丝毫不足为奇，设计的人就不够专业或者考虑不周详，性能优化的人经验又不足，ETL开发者、报表开发者往往只会工具，对于SQL和各种脚本没有深入的掌握，这样做出来的东西性能自然好不到哪里去。
4、从业人员的问题
大部分人只会个工具，ETL工具，报表工具等等，甚至工具都没有会到很精深，更别谈真正领会其内涵。我就曾经做过一个ETL，要抽取的数据在无格式的日志文件中，而且该日志是最好的数据源。最后我写了一个perl脚本来解析数据、抽取、处理并导入到数据库，变成格式化数据。并把该perl脚本以及其他shell脚本嵌入ETLworkflow中，共同实现高效的数据抽取转换。
报表也是，简单的都会，一到极其复杂的多主题、复杂的统计就瞎了，客户的需求有时候比较怪异，非要把完全不相干的东西整到一张报表中，你还必须实现。但是从业务上考虑，他那样的需求有其合理性，你看似不相干的东西，或者认为不必要的跨行计算，他能从中一眼看出东西来。
我就曾经给银行做过一个超级复杂的报表，把各种不同的信贷，包括信用贷款、抵押贷款、贸易融资、房贷等全部在一个报表里统计，有横向的统计，有纵向的统计，还有小计，逾期的分期的上期的当期的全部在一张表当中，还要分为account-level和customer-level两种统计方式。我整整用了4层的subquery来进行各种分组统计，再把结果集作为上一层的源数据，还用了N多的集合操作。写好了之后，对于一个上千行的SQL我心里也没底，结果一运行，性能还不错，几分钟就跑出来了，业务部门的人一核对，数据也都正确。这东西，你要是仅用报表工具来实现是很困难的。
很多公司在招人时，为了节省成本，招几个水平较高的，再招一大堆刚入门的，以为这样的搭配就可以提高整体水平。我并不否认新手当中确实有学习能力强、聪明、逻辑思维能力不错的，这种人很快就能成长起来，但是大部分人你永远别指望他们能成为一个合格的软件工程师。管理也存在很大问题，软件业就是软件业，它不是制造业，你拿管理生产线的方式管理软件开发，只能带出来一支士气低落、木讷迟钝、毫无创造力、实施水平也低下的队伍来。
客户呢，比较迷信大公司，以为大公司实力雄厚有保障、有成熟的管理。其实大公司也好，小公司也好，最终做事的还是那么几个人，这几个人的素质、技术水平和责任心决定了项目的成败，大公司无非是做砸了换一拨人再上，耗得起。但问题是客户耗不起，一个好好的项目最后往往以悲剧收场，花了几百万几千万，最终性能低下，质量堪忧，莫说决策支持了，连装点个门面都嫌寒碜。
往期精彩：
本号精华合集（三）
如何写好行的SQL代码
如何提高阅读SQL源代码的快感
我在面试数据库工程师候选人时，常问的一些题
零基础SQL数据库小白，从入门到精通的学习路线与书单
预览时标签不可点收录于话题#个上一篇下一篇