lava530BI不是一个新概念。从百度百科里的定义，商业智能的概念最早于1996年提出。关于什么是BI？这个问题你问10个人能得到20种不同的答案。我对他的最简单理解BI是一个技能，这个技能可以让你把，所以数据和业务两者缺一不可，而让这两者运作的动能就是BI软件引擎，也就是借助计算机帮助我们更好更快地通过数据了解业务，通过业务发现价值数据，循环相生。

　　很多人把BI和数据分析这两个词放在一起，看你怎样去理解，个人认为BI包含数据分析且特别强调Business商业价值的部分。不过无论你用哪个词，我们做数据分析的人员，以及所有从事财务、人力、销售、生产、运营等分析岗位的人员，我们的目标都是一致的，即把数据和业务结合起来分析输出管理决策。

　　随着计算机的发展，以PowerBI和Tableau领导的自助式商业智能软件出现大大降低了BI使用门槛。在过去的几年里，BI分析平台市场从以IT为主导到自助式服务分析发生了巨大的转变。所谓IT主导，就是传统意义上，数据分析功能的开发由企业专业IT部门和团队负责，然而开发周期长、审批流程慢，业务与IT部门间沟通成本常常是效率的障碍。

　　自助式BI商务智能使得不懂编程但具备数据分析能力和商业直觉的分析人员能够便捷而快速地提取、清理、整合各种数据源、创建复杂动态图表。在各种商务智能平台出现之前，这些都只能借助于复杂SQL脚本或者专业数据分析工具才能实现。

　　如果你对如何使用BI来解决商业分析问题感兴趣，关注微信公众号PowerBI大师。

　　如果你想继续阅读有关BI的概念感兴趣，这篇火影迷眼中的BI用查克拉让数据飞起来 - 知乎专栏可以帮你打开脑洞，以最简单的语言理解什么是BI。

　　什么是商业智能BI（ Business Intelligence ）？百度商业智能BI有很多很多官方的定义，各种解释，实际上从这么多年的经验出发，对商业智能BI的定义我认为不需要弄得很复杂，就三条：

　　第一，商业智能BI是一套完整的由数据仓库、查询报表、数据分析等组成的数据类技术解决方案。

　　第二，商业智能BI可以将企业不同业务系统（ ERP、OA、CRM 等 ）中的数据进行打通并进行有效的整合。这个打通和整合就包括了：ETL 过程、取数、业务逻辑规则像数据规则的转变、数据仓库建模等。

　　第三，最终利用合适的查询和分析工具快速准确的提供可视化分析或报表，为企业提供决策支持。

　　第一层，可视化分析展现层- 即需求层，代表用户的需求，用户要看什么，要分析什么就在这一层进行展现。

　　第二层，数据模型层- 即数据仓库层，代表数据的分析模型，完成从业务计算规则向数据计算规则的转变。

　　第三层，数据源层- 即数据层，各个业务系统底层数据库的数据通过 ETL 的方式抽取到 BI 的数据仓库中完成 ETL 过程，建模分析等等，最终支撑到前端的可视化分析展现。

　　这一点是所有企业如果规划要上商业智能BI项目的时候必须弄明白的一点，就是BI在IT信息化中到底处于一个什么样的位置呢，戳下方视频看：

　　通常情况下，我们会把企业的 IT 信息化分为两个阶段：一个是业务信息化，一个是数据信息化。这样对比讲，一般的用户更容易理解一些。

　　业务信息化- 企业使用的 ERP、CRM、OA、MES、自建的业务系统等，业务系统的建设都统称为业务信息化。业务信息化的主要作用是管理企业的业务流程，标准化、线上化，以提高生产运营效率、降低企业成本、是业务管理思路的体现，也是现代的企业管理方式。

　　数据信息化- 像我们经常所听到的大数据、商业智能 BI 、数据分析、数据挖掘等我们都统称为数据信息化。数据信息化可以帮助企业全面的了解企业的经营管理，从经验驱动到数据驱动，形成业务决策支撑，以提高决策的准确性，这是企业更高层次的企业管理方式。

　　没有业务系统的建设，就不会有数据的沉淀，就没有建设商业智能 BI 的基础。同时，商业智能 BI 的建设能够反向推动业务信息化的建设。

　　关于这一点的理解可以看下方的这个视频 - #1. 商业智能BI中的逆向思维

　　业务信息化的主要使用形式- 表单式的、以业务用户录入为主的、数据的增删改操作居多，是对业务过程数据、业务流程进行管理的软件系统。

　　数据信息化的主要使用形式- 例如商业智能BI主要是对业务结果数据进行整体分析呈现和局部洞察，旨在打通各类业务系统的数据，跨业务、跨系统整合数据。以数据查询和分析为主，通过联动、钻取、关联等图表可视化的方式来看数据指标。

　　业务信息化的主要使用对象- 一线业务执行层，更多是从业务视角出发，录入数据、记录流程、查看业务信息。

　　数据信息化的主要使用对象- 管理决策层，更多的是从管理视角通过可视化分析去定位问题、分析问题，最终形成业务决策。

　　第一，没有任何一个管理决策层、领导会没事打开财务系统看财务数据，打开 OA 系统看看合同信息，高层领导不会看这些明细数据细节，也不会进到各个系统里面去看。也就是说，业务信息化不是给这一层领导来使用的。

　　第二，管理决策层是不是一定是指的企业最高层的领导，不见得，可以是企业各个组织层次中带有管理决策属性的人员。

　　消灭数据孤岛为什么就一定要用商业智能BI，谁要求要消灭数据孤岛的？业务部门会觉得有数据孤岛的问题吗？我就用我的财务系统做账，数据孤岛就孤岛呗，我喜欢孤岛，我的财务数据就我们自己看，领导看，我一点都不孤岛。我就管个库存，数据孤岛就孤岛呗，我也用不着管其他的，我的报表够看就可以，孤岛跟我有什么关系？

　　所以，我们在讲商业智能BI，讲数据孤岛的时候不是给一线业务部门讲的，而应该是给跨业务、跨部门、跨组织的这些管理层讲的，只有从他们的视角里，这些业务系统和数据才是真正的孤岛。

　　深层次的原因是什么？深层次的原因就是：这些业务信息化系统并不是为管理层服务的，是为一线业务部门服务的。管理层不是这些业务系统的用户，他们绝对不会没事一个系统一个系统的登录进去看数据，他们没有这种使用习惯，他们更不会关注到各个业务系统的微观层面。所以，大多数情况下只有这些跨组织、跨业务的管理层才会认为有数据孤岛的存在，所以是他们要求解决数据孤岛。

　　由于商业智能BI是天然解决数据孤岛问题的，所以商业智能BI是为谁服务的，是为管理层服务的数据信息化系统。商业智能BI要打破数据孤岛，全面的看数据，全面的管业务，商业智能BI就是业务管理视角的自然延伸，要广度、要深度。

　　所以，站在不同的角度，有的人认为是有数据孤岛存在的，一定要解决。有的人是不认为有数据孤岛存在的，即使存在对他们也没有影响，所以不用解决。

　　商业智能BI不是像业务系统与业务系统之间的接口开发取数方式，而是通过访问和连接业务系统数据源数据库的方式来进行取数的，不管是什么样类型的数据库，商业智能BI通过ETL连接方式连接数据库抽取业务系统原表数据到数据仓库中加工处理，最后支撑到前端的可视化分析报表展现。

　　一般不需要，基本上这么提问的都是经历过软件系统的接口对接，软件系统的接口对接是因为有的业务软件是 JAVA 开发的，有的是开发的，有的是 B/S 架构，有的是 C/S 架构。软件系统之间的接口是需要开发参与的，主要是串联不同软件的业务流程，这种接口是需要动代码的。

　　但 BI 在获取数据的接口不一样，是与业务系统软件自身无关的，是只需要访问和连接业务系统背后的数据库就可以的，直接从数据库取数，因此是不需要软件接口，或者没有软件接口访问这种概念的。

　　除非一种情况，这个业务系统是公有云，纯 SAAS 模式，这种情况下就只能通过软件对外开放的 API 接口取数了。

　　商业智能 BI 是一套完整的有数据仓库、数据分析、数据报表等组成的数据技术类的解决方案，在一个 BI 项目中，20% 的时间做前端分析报表，80% 的时间都在底层数据仓库的设计、ETL 的开发、取数开发等工作。

　　我之前就是微软 BI 技术线的，早些年的时候积累过不少的 BI 技术博客 -BIWORK 的技术博客

　　客观来讲，很多国内外报表工具都借鉴过 SSRS 的数据集模式（ 写一条 SQL 查询或者存储过程返回一个查询的结果绑定到一个数据集 Dataset 中，图表与数据集绑定，图表的字段引用自数据集 ），但这种方式也有它的限制使用场景或者使用前提，后面会陆续讲到这个问题。

　　SSAS 是解决什么的- 空间换时间的多维分析实现，OLAP、CUBE 立方体。例如在分析报表中多个维度 ( Dimension ) 可以和多个度量（ Measure ) 组合，以时间、区域、产品三个维度和销售收入这个度量为例子，在用户打开一个报表，根据报表的字段可能组合的查询就是：

　　当底层数据表数据量过大、聚合查询和复杂，各种维度和事实度量组合的 SQL 查询大量的发往数据仓库查询，这种查询效率可能会变得非常的差，因为数据查询 SQL 本身就可能需要执行很长时间，还不算返回到前端报表的中间数据传输过程、前端报表的渲染时间等等，所以通过 SSAS 实现一个 CUBE 立方体，本质就是相当于把各种维度和度量的这种聚合查询（ 各种聚合函数，可以选择 ） SQL 给提前执行了，最后将各种维度和度量 SQL 查询的值提前存储起来。前端报表连接到 CUBE 中直接使用预计算好的值就可以了，而不再需要通过 SQL 到数据仓库层查询，这就是空间换时间的原理。

　　讲到这里说明了一个什么问题，就是一套完整的 BI 实际上包括的有很多东西，有底层数据处理的 ETL 过程，也有前端可视化分析报表的。

　　单纯的拖拉拽的 BI 可视化分析工具严格来讲只能定位于个人和部门级的 BI 分析工具，因为单纯的上一个 BI 分析工具解决不了 BI 的全部，也代替不了 BI 的全部。

　　3. BI 就是 BI，跟数据仓库没有关系。有了 BI 就不需要数据仓库建模，业务人员就可以自己做 BI 分析，就可以拖拉拽做 BI 分析。

　　以前也总有人说 BI 就是业务驱动的，不需要 IT 人员支撑，敏捷 BI 不需要 IT 介入，不需要建数据仓库，我以前有段时间也是这么认为的。但是再沉淀了一段时间，对这种方法论进行过一段时间的追踪，最后发现其实是存在很大问题的。

　　但凡有任何 BI 的销售或者售前告诉用户，你们企业的 BI 项目不需要构建数据仓库，直接通过 BI 分析工具拖拉拽就可以搞定企业里面所有的分析，不需要 IT 人员支撑，业务人员完全可以自己搞定... 类似于敢这样承诺的，要么是对 BI 不懂，要么就是真忽悠。

　　在企业级的 BI 项目建设中，真正能做到完全靠业务人员简单拖拉拽一些就能随便实现数据可视化分析，至少在我个人从业的十几年工作经验中，95%以上的企业都做不到。我服务过的重点企业包括：SHP（ Security Health Plan )、微软（中国）、微软（美国）、VWFC（ 大众金融 ）等。

　　VWFC 做的算是非常不错的，少有的业务人员自己动手做很多报表，线上跑了几千张报表。为什么？ 因为底层数据仓库就搭建了很多年，底层数据架构相对比较规范。Business Driven 业务驱动，它的前提是什么？

　　1） 底层数据质量很规范，数据仓库架构很完整，不让业务人员碰底层数据，ETL、取数、指标计算等等统统都是 IT 部门来维护。

　　2） 业务人员通过培训要熟练掌握 BI 前端报表工具的使用，要很懂放出来的数据分析模型接口。

　　第 2）和第 3）条很多企业没有问题，第 1）条直接弄个前端 BI 工具让业务人员解决，能解决掉吗？ 很显然业务人员是不具备这种能力的。

　　这就是一到培训的时候，BI 工具使用起来很简单，但是一旦到实际的企业 BI 项目开发就发现寸步难行。因为培训的时候，给出的数据表都是经过选择的，永远都是质量很高的、规范的只需要简单左表连右表例如销售订单表、订单明细表，自然很容易把可视化报表给实现出来。

　　但是在实际企业 BI 项目分析中，分析指标的计算规则绝非简单几张表关联就可以解决的，不信的话可以挑战一下一个实际的指标计算逻辑：挑战一个 ETL 数据清洗的小案例在数据库中就一张数据表，数据理解起来也很简单，但很多 BI 开发人员做起来也需要废很大的精力，就更别谈业务人员自助 BI 分析了。

　　讲这么多不是为了一味否定自助式 BI 它的作用和能力，自助式 BI 有它的使用场景，也确实帮助我们简化了很多的 BI 工作，但从专业角度出发，特别反感是部分 BI 厂商以一种不负责任的方式反复向市场强化类似于这样的概念：BI 就是可视化报表、BI 不需要数据仓库建模、传统数据仓库建模很落后、BI 就是自助分析、BI 自助分析很简单、业务用户简单几天培训就可以学会并且想怎么分析就怎么分析...

　　从市场宣传和销售的角度来说，简化产品的复杂度和上手难度的宣传是没有问题的，有问题的是以一种错误的讲解、不专业的讲解最终误导企业接受了这些不正确的概念，并以这些不正确的概念来评估与规划 BI 项目的建设，没有充分预计到 BI 项目建设过程中可能会遇到的挑战与风险，最后导致项目的不成功与失败、反复建设。

　　我们在北京就有一个客户之前花了一百多万上了一套所谓的 BI 项目，项目上线了一年左右，到最后完全推不动，失败了。后续找到派可数据，我们给他们上了派可数据商业智能BI分析平台，这个项目我们连续做了好几期，客户还写了感谢信。之前为什么推不动、项目会失败：不重视数据仓库的规划。因为他们的业务是连续的、变动的，每年的需求都是需要动态调整的，数据持续增加，分析的深度和广度都是在不断变化，没有一个好的底层数据架构来支撑，光靠 SQL 取数、建数据集出报表的形式是不可能支撑一家企业未来 3-5 年甚至更长远的业务分析需求变化的。

　　除了这个案例之外，在我的手机上有很多之前上过 BI 最终失败、没有做好，找过来聊天吐槽的记录，是真的产品不好吗？我也客观的帮助他们分析过：这些产品本身有的是 Gartner 魔力现象 Leader 象限的产品，你说产品行不行？ 有的产品是国内商业智能 BI 领域很多年的老品牌，你说产品行不行？ 客观来讲，这些产品从我个人角度来说，这些产品其实都很优秀，产品本身是没有太大问题的。

　　问题在于，这么多从零到一需要上 BI 的企业不知道一个 BI 项目中原来还有那么多坑，很多 BI 厂商会不会去把这些点给企业客户讲清楚，一个 BI 项目到底怎么干、中间有什么样的风险、以后还会遇到什么样的问题、应该怎么解决这些问题、有什么样的方法论和手段... 如果只是为了卖一套 BI 产品或者工具，你觉得这些 BI 销售会跟客户讲这些东西吗？ 不会的，至少不会讲的太深太全，因为这么一讲把 BI 难度讲太复杂了，一旦没有讲好，反而降低了客户的信任。

　　有的时候不讲，是因为怕讲复杂了，让企业客户决策周期拉的太长了。有的时候不讲，是因为不懂。你不讲，客户不知道，客户也没有经验，后续 BI 项目建设就会出问题。

　　在一次大会上，某 BI 厂商一位高级售前技术专家在跟客户交流时说过的一句话：BI 直连不香吗？直接连接数据源不就可以做分析，不需要数据仓库。无知者无畏，实在听不下去，就打断直接沟通了一下。通过沟通，可以判断这个所谓的技术专家基本上没有做过完整的 BI 项目经验，从零到一搭建一个 BI 项目的能力等于零。以这样的一种能力跟客户来引导一个 BI 项目，这种 BI 项目的质量能有保证吗，很难的。

　　这也就是我们派可数据、我个人做视频号《吕品聊数据》的原因，客观的讲讲 BI、客观的讲讲数据，普及一下我们认为正确的 BI 知识和概念。告诉我们广大的 BI 用户，BI 到底应该怎么理解、怎么认知，BI 到底有什么样的坑需要我们的企业注意。

　　我们不能说我们派可数据在 BI 领域讲的知识和概念就一定是放之四海而皆准的，但是我们欢迎任何 BI 厂商或者任何 BI 个人爱好者就 BI 的一些知识和概念来向我们挑战，来看看派可数据所普及的一些 BI 知识概念到底对不对。如果普及的对，说明这些问题大家确实都碰到了，这些知识和概念对于企业而言就是难得的经验。如果普及的不对，不对又是在什么地方，指出来大家一起看看，一起探讨一下，我们还可以为企业做些什么。

　　早期前端技术很弱，AJAX 的实现也都需要手写，要实现一个表单内数据的点击编辑和修改需要自己用 JS DOM 操作。做报表基本上就是 JSP、ASP 脚本语言在前端嵌套 HTML 做循环输出，报表样式很原生很丑陋，稍微复杂一点的表格报表样式都需要用 JS 来调整。那个时候用过的报表像 Crystal Report 水晶报表、润乾报表等等，在前端脚本语言中有标签直接可以引用，报表生成代替了大量的手写代码。早期的前后端技术是不分家的，ASP.NET还稍微好一些，前端逐步有一些集成控件可以直接使用，JAVA 是真没有。上面说到的这个阶段大概在什么时候呢，2005年前后，2007年我觉得已经使用的很广泛了，老的 CSDN 上应该还能找到很多原始的报表标签帖子。像老一批报表还有像金峰报表 Jreport、思达报表 StyleReport 等等在国内也有一定的市场。早在 2010 年之前，有些报表厂商的收入规模就已经突破了一个亿，说明基础报表这个市场还是非常不错的。

　　那个时候的报表定位是什么，就是纯粹的 Report 报表，通过程序从后台数据库中查询返回的数据聚合 List 再到前端脚本页面上绑定一下就生成了各种报表，实际上就是用在各个业务软件系统之中的报表展示，还远远没有到 BI 分析这个层面。

　　并且还有大量的软件开发厂商实际上已经具备了很强的报表能力，不过这些报表能力并没有单独拿出来作为报表产品在市面上运营而已。

　　逐步的，随着前端技术、前端框架的完善，从传统表格技术开始到了各类柱状图、条形图、饼状图的可视化展示，到了这个阶段，报表和 BI 的边界越来越模糊。为什么？ BI 的报表展现能力也就和传统报表效果大致相当，还没有出现那种自助分析、自助拖拉拽就可以实现快速多维分析的能力。

　　这是我在天善智能的联合创始人周剑之前写过的一篇文章，基本上概括了这二十年国内 BI 市场和产品的一些发展过程。

　　讲这么多主要想说的是我们所看到的很多 BI 项目都是拿报表思维去实现的，就是 SQL 到数据集到前端展现。而真正的 BI 思维应该是什么呢？ 多维思维、模型思维，这一点决定了一个 BI 项目的最终走向，后面会具体讲到这些点。

　　商业智能 BI 到底是什么？技术？产品？还是其它？我们把对于 BI 的理解再提升一个层次：商业智能 BI 是一家企业业务和管理思维的落地。这个怎么来理解呢？简单来说，就是在可视化报表上呈现的内容就是一家企业真正关注的内容，这里面有管理高层重点关注的企业经营性的分析指标，也有某具体部门的。

　　经常会碰到有人问BI和数据仓库有什么区别，实际上这个问题的背后能反映出来一些朋友对BI的理解还是有些不准确和偏差，这个问题实际上从概念上把BI和数据仓库人为的割裂了。这种情况其实也比较正常，因为大家对BI的第一印象就是各种炫酷的可视化图表、报表，再加上市面上有很多轻量的前端可视化BI分析工具，就造成大家对BI的认知就停留在可视化这部分了。

　　准确的来说，商业智能BI不仅仅包含前端可视化分析、报表展现的能力，更包含了底层数据仓库的建设过程。Gartner 在上世纪九十年代就已经提到了商业智能 Business Intelligence，它更多的认为：BI是一种数据类的技术解决方案，将许多来自不同企业业务系统的数据提取有分析价值的数据进行清洗、转换和加载，就是抽取Extraction、转换 Transformation、加载Loading 的ETL过程，最终合并到一个数据仓库中，按照一定的建模方式例如Inmon 的3NF 建模、Kimball 的维度建模或者两者都有的混合式架构模型，最终在这个基础上再利用合适的分析展现工具来形成各种可视化的分析报表为企业的管理决策层提供数据决策支撑。

　　所以，可以从这里能够看到数据仓库Data Warehouse 的位置是介于可视化报表和底层业务系统数据源之间的这一层，在整个BI项目解决方案中起到的是一个承上启下的作用。如果把BI比作是一个人的话，上半身特别是脸这个部分就是颜值，下半身脚踏实地吸取大地的精华，中间这部分的腰腹核心、核心力量就是数据仓库。

　　篮球之神乔丹不光光有颜值，滞空能力是顶尖的存在，才会在上篮的时候有各种让人惊叹的动作，能够支撑这些动作其实靠的是什么？就是乔丹的腰腹核心力量。

　　所以，BI在前端可视化分析层面要玩出各类精彩的动作，没有数据仓库这个核心力量的支撑是很难做到的。

　　那大家也会问到，市面上不是有很多直接链接数据源就可以拖拉拽分析的BI工具产品吗，不也一样可以做BI分析报表吗？这种独立的、单独的面向前端的BI分析工具，他们更多的定位是部门级和个人级的BI 分析工具，对于深层次的需要复杂数据处理、集成、建模等很多场景是无法解决的。最好的方式就是底层构建一套完整的数据仓库，把很多分析模型标准化，再利用这些前端BI分析工具结合起来，这样才能真正的把前端BI分析能力给释放出来。

　　很多企业认为只要买一个前端BI分析工具就可以解决企业级的BI所有问题，这个看法实际上也不可行的。可能在最开始分析场景相对简单，对接数据的复杂度不是很高的情况下这类BI分析工具没有问题。但是在企业的BI项目建设有一个特点，是一个螺旋式上升的建设过程。因为对接的业务系统可能会越来越多，分析的深度和广度会越来越多，数据的复杂度也会越来越有挑战性，这个时候没有一个很好的数据仓库架构支撑，光靠前端BI分析工具基本上是无法搞定的。

　　就像去中药店抓药一样，之所以抓药很快，是因为在抓药前，别人已经把各种原生的中药材（原始数据源的数据）分门别类清理干净放好了，这样想怎么搭配药材（维度指标组合的可视化）就很快了。

　　这样的企业在国内有很多，也是因为对BI理解的深度不够导致了在BI项目建设上一些方向性的错误，最后导致BI项目很难继续推进。

　　所以在企业中，我们需要明确我们的BI建设是面向企业级的还是个人和部门的分析工作。如果是个人数据分析师，使用这类前端BI分析工具就足够了。如果是需要构建一个企业级的BI项目，就不能只关注前端可视化分析能力这个层面，更应该关注到底层数据架构的构建，也就是数据仓库这个层面。

　　Inmon 的三范式 3NF 建模和 Kimball 的维度建模都是 BI 数据仓库建模的方法论，这两者有什么区别和联系。

　　什么样的企业适合上商业智能BI？看业务基础信息化程度和日常业务管理的细致程度和颗粒度。业务基础信息化程度就是企业自身的IT业务系统基础建设，没有业务系统的支撑，做商业智能BI就缺乏数据基础；第二就是业务管理的颗粒度，企业自身业务管理程度是不是比较细致了，急需通过商业智能BI来提升业务管理、决策支撑的效率。

　　做完商业智能BI项目，还要考虑最终如何跟老板汇报的问题，掌握商业智能BI数据分析思维框架和汇报的五个重点：用户业务层次与范围、工作成果、计划执行复盘、问题反馈、展望规划与愿景。

　　做商业智能BI还必须熟悉行业和业务知识，不结合行业业务知识，商业智能BI的项目是很难落地的。

　　BI 对数据的处理存在一定的滞后性，通常采用T+1模式，主要原因是ETL数据处理过程是需要有大量的时间损耗，通常是采用空间换时间的方式。

　　将以前按照数据仓库分层的ETL调度设计成可按单独指标并自动寻找依赖的调度就大大的增加了对个别指标调度和准实时处理的灵活性。

　　离线数据与实时处理针对的业务场景不同，背后的技术方式实现不同，资源投入也不同，了解它们之间的定位差异有助于选择合适的方案以最小的资源投入达到企业既定目标。

　　大数据、数据中台都是商业智能 BI 发展到一定阶段的产物，核心都是围绕数据，数据采集、数据处理能力、算力的提升催生了大数据，数据资产和数据服务催生了数据中台，核心的数仓建模自 BI 一脉相承未曾改变，最终出口还是 BI 可视化

　　先自我介绍一下，个人在商业智能BI领域服务超过15年，从最早接触 SQL SERVER 2005 BI 全套件（SSIS\SSRS\SSAS）至今对比研究过国内外几乎所有主流BI产品，熟悉和了解国内外BI发展趋势和现状。公开发表过很多对商业智能BI行业的分析内容，很多分析和观点被一些投资机构、BI行业研究咨询机构、咨询公司所引用并公开发表（不过没有人跟我打招呼，直接搬运了）。

　　个人早期经历过传统软件技术开发，有较强的软件、业务系统技术背景，后期转行至商业智能BI领域。迄今为止参与过最大的商业智能BI项目是浙大网新美国子公司 Insigma US 位于威斯康辛的 SHP（ Security Health Plan ) BI 项目，项目金额过亿（2200万美金）。BI服务团队总人数国内近百人，国外几十人咨询顾问团队，对于超大型BI项目架构有深入的理解。

　　这么多年经历过商业智能BI的底层数据仓库架构设计、ETL 架构设计、数据分析，也经历过产品技术研发、研发管理、市场运营、业务咨询、售前咨询、销售管理、行业研究等多个角色，已经不再单纯的从技术视角去看商业智能BI，而是结合技术、业务、行业、经营管理、财务等多个视角来审视商业智能BI。

　　这么多年一直在跑市场，一年差不多有1/2的时间在一线市场，从一线城市到三四线城市，面对面拜访沟通过的企业至少在500家以上。面对不同的企业，对商业智能BI的理解不同，会发现很难用一句话或者两句话概括商业智能BI的定义，针对不同的用户往往需要从不同的角度来解释商业智能 BI。有些点到即止，有些需要深入拔高，每个人注重的点都不一样。

　　商业智能（Business Intelligence，简称BI）正如雨后春笋般蓬勃崛起。商业智能起始于决策支持系统，早期伴随着计算机的普及，有了长足的发展。后来，IBM公司提出“数据仓库”概念，同时，硬件的扩充、软件的更新、数据库在企业的广泛应用等使商业智能真正地破茧而出。

　　近些年，在数据仓库的基础上，在线联机分析（OLAP）、数据挖掘技术开始大行其道，目前，智能商业能帮助企业做的事情已经越来越多，而且正在从传统功能向增强型功能转变、从单独的商业智能向嵌入式商业智能发展。停滞多年的BI又一次吸引了大量公司的战略视角。今天数猎哥就来说说商业智能（BI）。一、什么商业智能BI1.商业智能BI的定义BI是Business Intelligence的英文缩写，中文解释为商务智能，用来帮助企业更好地利用数据提高决策质量的技术集合，是从大量的数据中钻取信息与知识的过程。简单讲就是业务、数据、数据价值应用的过程（百度百科）。换句话来说，BI是一套完整的解决方案，可以将来自企业的不同业务系统（如ERP、CRM、OA、BPM等，包括自己开发的业务系统软件）的数据，提取出有用的数据进行整合清洗，在保证数据正确性的同时，进行数据分析和处理，并利用合适的查询和分析工具快速、准确地为企业提供报表展现与分析，为企业提供决策支持。简单概括这个过程所体现的三个大的部分就是：数据源收集，数据仓库的数据准备，可视化报表展现和数据分析（如图所示）。

　　2.商业智能BI的本质对企业来说，商业智能BI不能直接产生决策，而是利用BI处理后的数据来支持决策。核心是通过构建数据仓库平台，有效整合数据、组织数据，为分析决策提供支持并实现其价值。BI最终展现给用户的信息就是可视化报表或视图。需要注意的是，报表是一个结果，只能达到查询的效果，查询仅仅只能告诉我们结果是什么、有没有问题。而基于可视化图表背后的数据分析才能告诉我们问题的原因是什么，只要问题发现了，原因也找到了，那么企业业务人员或者管理人员如何去决策就会变得简单与轻松。3.商业智能BI的开发周期商业智能BI是一个完整的解决方案，需要进行专业项目实施与部署。既然是项目，就有开发生命周期。一个完整的商业智能BI项目需要经历以下几个阶段：

　　这里需要注意的是，在实际项目实施过程中，以上的每一个阶段都存在很大的变数，例如业务架构自底往上的调整、分析需求的变化、业务数据计算逻辑的变更等。所以商业智能BI项目如果需要顺利实施就需要权衡好客户实际资源能力、项目支持力度，客户对商业智能BI的期待，项目后期的风险，客户的实际投入和长远规划...二、商业智能BI与大数据有什么区别大数据研究机构Gartner给出了这样的定义：“大数据是需要新处理模式才能具有更强的决策力、洞察发现力和流程优化能力来适应海量、高增长率和多样化的信息资产”。商业智能BI和大数据是两个不同的概念，简单来说，BI相对于大数据更倾向于分析模式，用于决策，适合支持经营指标支撑类的问题；大数据则内涵更广，倾向于刻画个体，更多的在于个性化的决策。

　　三、企业为什么需要商业智能BI其实，企业内部有大量的机会可以通过优化业务流程和集中决策来节省资金。在业务遭遇大挫折时，商业智能BI能带来一线曙光，产出显著的投资回报率ROI。例如，阿尔伯克基市的就业者使用商业智能BI软件来识别机会以减少使用手机通话，加班及其他营运开支，三年期间为这个城市节省了200万美元。同样地，在商业智能BI工具的帮助下，丰田汽车公司意识到对它的运货商双倍地付费，于2000年总数达812,000美元。利用商业智能BI来揭示业务流程中存在的缺陷的企业，与仅用商业智能BI来监控会发生什么事情的企业相比，在成功的竞争中处于更有利的地位。商业智能BI在企业中的应用主要表现在如下3个方面：1.可视化报表的展现在BI中，使用柱状图、饼状图、折线图、二维表格等图形可视化的方式将企业日常的业务数据（财务、供应链、人力、运营、市场、销售、产品等）全面展现出来，再通过各种数据分析维度筛选、关联、跳转、钻取等方式查看各类业务指标。

　　这些分析展现内容基本上是围绕各个业务部门日常工作展开的，这里面有很多的业务分析内容可能需要复杂的计算规则，需要从不同的业务系统获取数据，并且这些数据在业务系统软件中都是很难直观看到的。这个层次的可视化报表分析就是一种呈现，让用户对日常的业务有一个清晰、直接、准确的认知，同时解放了业务人员手工利用Excel的各种函数做汇总分析、制图的工作，提高了工作效率。比如，财务部门会关心今年的营业收入、目标完成率、营业毛利润率、净资产收益率等；销售部门会关心销售金额、订单数量、销售毛利、回款率等；采购部门会关心采购入库金额、退货情况、应付账款等等。2.数据的“异常”分析数据的异常分析利用的是对比分析法。业务人员通过可视化报表呈现，如果发现了一些数据指标反映出来的情况超出了日常经验判断。这时就需要要对这些 异常 数据进行有目的的分析，通过相关联的维度、指标使用钻取、关联等分析方式探索出可能存在的原因。例如，一个网站或产品，正常情况下每个月的平均用户注册量是10万左右。但是发现在今年的 8 月份，会员注册量达到了 23 万，这就是一种 异常，远远超过经验判断和预期。这时我们就要去分析判断是因为市场部门的推广，还是做了大型促销活动导致的。当然除了正向的异常，也有可能出现负向“异常”，比如注册量只有5万，这时也是需要我们通过分析找到原因，并在以后避免发生类似的情况。最终业务人员通过一次或者多次的维度和指标图表构建，逐步形成了一种比较可靠的、固化的分析模型。这个阶段的业务人员不再是被动接受来自图表中反映的信息，而是通过异常数据来定位到背后的一个业务问题，数据和业务在这个层次开始有了直接对应关系，这时可以利用数据图表之间的逻辑性关系寻找解决方法，提高企业的经营效率。3.业务建模分析业务建模分析通常是由精通业务的业务人员提出，通过合理的建模找出业务中可能存在的问题，将其反映在可视化报表上，并最后要回归到业务，形成决策并不断优化的一个过程。业务建模简单来说也可以理解为一种业务分析的逻辑思维模型，只是用数据、图表化的方式将它们有效组织起来去验证我们对业务分析的逻辑判断。它可由一个或多个图表组成，也可通过一组或多组数据图表支撑，依据企业的业务模型来确定。业务建模分析区别于前两点，它是一种更深层次的业务数据的主动设计和探索分析。需要更加深入业务，围绕一个一个业务分析场景展开，对业务的认知要足够深。这里需要注意的是具体的分析场景很难由专业的BI开发人员来提出。业务分析建模需要由专业的业务人员且具备数据分析思维意识的人员来推进和主导，再辅助合适的数据分析、挖掘或统计工具，这样商业智能BI的价值才能在企业得到充分的发挥，数据的价值也才会得到充分的体现。四、商业智能BI的工作原理那么BI到底是如何工作的？商业智能BI是一个复杂的技术集合，它包含ETL、DW、OLAP、DM等多个环节（这里的几个名词后文会有详细解释）。如图所示，简单的说，就是把交易系统已经发生过的数据，通过ETL工具抽取到主题明确的数据仓库中，OLAP处理后生成Cube或报表，透过Portal展现给用户，用户利用这些经过分类（Classification）、聚集（Clustering）、描述和可视化（Description and Visualization）的数据，支持业务决策。

　　1.ODS（Operational Data Store）ODS是数据仓库体系结构中的一个可选部分，ODS具备数据仓库的部分特征和OLTP系统的部分特征，它是“面向主题的、集成的、当前或接近当前的、不断变化的”数据。一般在带有ODS的系统体系结构中，ODS都设计都有如下特点：（1）在业务系统和数据仓库之间的数据过渡层：如果业务数据来源比较复杂，一般采用构造ODS的方法来实现收集当前需要处理的数据。如下述数据来源：①业务数据库种类繁多。业务交易系统使用了不同种的数据库，如DB2、Informix、Oracle、SQL server、文本等；②不同的应用系统、不同的地理位置；③订阅数据源；④批量还原非传统数据库数据……等等。用于存放从业务系统直接抽取出来的数据，这些数据从数据结构、数据之间的逻辑关系上都与业务系统基本保持一致。（2） 保存当前或接近当前的细节数据，以供查询或ETL检错使用。（3） 数据存储周期性。ODS中存储的数据都是临时的，每次ETL之前都要清空ODS中存储的数据。2.ETL（Extract Transform Load）操作型业务数据库（DB）到数据仓库（DW）的过程称之为ETL，它实现数据的抽取，转换及装载工作。①抽取：将数据从各种原始的业务系统中读取出来；②转换：按照预先设计好的规则将抽取得数据进行转换、清洗，以及处理一些冗余、歧义的数据，使本来异构的数据格式能统一起来；③装载：将转换完的数据按计划增量或全部的导入到数据仓库中；3.DW（Data Warehouse） 数据仓库数据仓库的官方定义是一个面向主题的(Subject Oriented)、集成的(Integrate)、相对稳定的(Non-Volatile)、反映历史变化(Time Variant)的数据集合，用于支持管理决策。数据仓库的特点：面向主题；集成；非易失；时间轴。数据库与数据仓库的区别：

　　即联机分析处理，是BI的一种全新的数据封装方式，直接产物是报表或Cube（如图所示），是使分析人员、管理人员或执行人员能够从多角度对信息进行快速、一致、交互地存取,从而获得对数据的更深入了解的一类软件技术。说到OLAP，我们会很自然地想起OLTP（联机事务处理系统），现在来比较一下OLTP与OLAP的区别，如下所述：

　　数据查询是最简单的BI应用，输出可视化报表是BI最直接的产物，根据数据连接，加工过程及用途，应用模式大致可以分为以下四种：①格式报表：带格式的数据集合，如：交叉表等；②在线分析：多维数据集合，如：Cube等；③数据可视化：信息以尽可能多的形式展现出来，目的是使决策者通过图形这种直观的表现方式迅速获得信息中蕴藏的知识，如柱图，仪表盘等；④数据挖掘：从大量的数据中，抽取出潜在的、有价值的知识（模型或规则）的过程。五、商业智能BI项目的实施步骤1.业务分析需求的把控对于很多准备或者正在规划商业智能BI项目的企业来说，业务分析需求的梳理是整个项目开始的第一步，往往也是最困难的，主要表现如下：业务部门往往提不出比较具体的分析需求，而IT部门很难深入到业务，也提不出适合业务部门的分析需求。BI项目需求分析涉及到很多部门，有的时候内部资源的沟通、协调都是很困难的...那如何能够非常清晰的梳理好一个完整的业务分析需求，并且能够用业务部门能够理解的语言进行有效沟通？正确的做法是，提供方案的原型图，这样能激发业务人员说出需求的欲望，并让双方站在可以相互理解的角度沟通，最终出来的效果也能更好的符合企业的期望。2.数据资源的整合清洗企业的数据可能是来自外部系统，也可能来自内部的不同业务系统，比如CRM系统、ERP系统，或者业务人员的Execl表格， 这些统称为数据源。这些数据通过ETL工具原封不动的抽取到一个叫做ODS或者STAGING的数据库先存放起来。这里需要注意数据是存放在一些数据表中，但是并不是所有的数据都需要抽取出来，只有有用的数据才会被抽取。涉及到一些数据需要去重、合并计算、格式转换，比如 15/10/22 转换成 2015-10-22等都属于转化阶段；加载阶段是，最后把数据统一加载到数据仓库 中。

　　3.数据仓库的架构设计数据仓库的开发，可以理解为一种技术，也可以理解为一种方法论或解决方案。在商业智能BI中，数据仓库就是最核心的那一层，起到的就是一个承上启下的作用。往下承接各类数据源中的数据，往上支撑各类可视化分析报表。数据仓库的构建水平将直接影响到商业智能BI项目的整体质量。4.可视化分析报表逻辑设计这里的可视化分析报表的逻辑设计主要是依据前期的业务人员搭建的数据指标体系而定，主题利用常见的可视化图表来做业务数据的展现，这里DataHunter就能帮到你了。Data Analytics是一个轻量级业务数据可视化平台，可一键快速接入企业本地和云端内外部Execl/CSV等数据文件，无需编程仅需简单的拖拽即可制作酷炫的数据可视化看板，用直观的数据帮你做更好的决策。

　　六、小结商业智能BI的表象是可视化分析报表的呈现，但它的本质还是业务问题、管理问题。商业智能BI数据分析来源于业务，通过数据呈现发现业务问题，比如好的或不好的，经验之内或之外的 ，然后再次回到业务，重新优化提升业务运营的一个过程，这就是在商业智能 BI 中数据到信息、信息产生决策、决策产生价值的真正内涵。

　　Gartner定义的商业智能是描述了一系列的概念和方法，通过应用基于事实的支持系统来辅助商业决策的制定。商业智能技术提供使企业迅速分析数据的技术和方法，包括收集、管理和分析数据，将这些数据转化为有用的信息，然后分发到企业各处。

　　BI系统在大多数企业都是部署在展现层和应用层。比如BI工具FineBI提供从底层数据到前端展示，期间经历数据整合、数据清洗（ETL）到数据缓存以及最后的数据展现和前端分析，以及移动端、大屏的解决方案。

　　通过即席查询、OLAP分析和数据挖掘技术，对各指标进行关联分析，挖掘联系关系。