BI的应用深度可划分为：

数据可视化、数据分析、数据挖掘三个阶段。

在数据可视化阶段，BI的作用是将企业日常业务数据报表以可视化图表的方式予以呈现，只是单纯用可视化图表代替了Excel报表，但缺少对数据的分析。

在数据分析阶段，BI可以实现对可视化图表中的数据进行描述性统计分析、关联分析等，发现数据背后的原因，实现数据辅助业务决策。

在数据挖掘阶段，通过算法对数据进行深度挖掘和预测分析，BI和AI结合，能够对未来业务进行预测分析，实现智能业务决策。

技术选型

在技术选型阶段，首先需要关注的就是企业的数据量级，亿级、千万级、百万级数据，对应的技术方案是完全不同的。

数仓技术选型

数仓是使用第三方服务如 DataWorks，还是自己从零搭建！！！

开源免费的，其实是最贵的。

核心业务指标

最核心的是业务和财务。

在以往企业信息化建设中，经常强调“业财一体化”，其核心是把业务和财务数据打通。不少企业财务管理软件，也会在信息流基础上对沉淀的数据进行分析和展示。这其中，固然在这里有一部分 BI 的影子，比如在财务管理系统中的“阿米巴”模式下，可以基于部门（团队）、产品线等，分析各个业务单元的利润情况。

但需要注意的是，BI需要面对的问题要远比这复杂得多，绝不是靠一套企业管理软件就能解决的。

先有业务指标，再有财务指标。

业务 + 财务

产品

销售

渠道

库存 & 周转

供应链

物流

财务的两个维度

管理会计：核心是利润

财务会计：核心是现金流

BI 要解决什么问题

如何开展 BI 建设

对于很多准备或者正在规划商业智能BI项目的企业来说，业务分析需求的梳理是整个项目开始的第一步，往往也是最困难的，主要表现如下：业务部门往往提不出比较具体的分析需求，而IT部门很难深入到业务，也提不出适合业务部门的分析需求。

数据采集

用户行为数据

业务订单数据

主数据

数据建模

MySQL 建表一般都是小表，数据冗余小，磁盘利用率高。但这种情况并不适合大数据分析，因为做 MapReduce 的时候，大量的跨表join会导致 MySQL 运行极度缓慢，查询操作性能极差。

关系模型

维度模型

数据源层：亦即各个业务系统。

ODS层：

基本保持与数据源层一致的数据表结构，但是会按某种方式（存量、增量）某个频率（按天、按小时、按分钟）集成各个业务系统的数据到一个统一的地方。
DW层：

会按某一个或某几个统一的字段信息（比如：订单号，保单号，账号等），整合各个业务系统的数据到一起数据的颗粒度还是比较细节级别的。
DM层：

会面向主题分部门分模块进行数据的汇总组合。
DA层：

面向最终的上层应用。

数据模型

和数据连接一样要考虑到复用性

数据建模可以通过多表的关联实现复杂建模，但是实现不等于最优实践。

BI数据建模一般一个模型中建议不超过5个表关联，这个主要出于后期维护考虑。

如果存在特殊场景，需要10几张表做可视化建模，建议用自定义sql 先把一些复杂的逻辑在自定义sql完成。用自定义sql在可视区域建模。

数据模型最后是以宽表展示，理论上一个宽表字段不要超过30个，以服务客户的经验来说，一般模型层字段在报告上使用在5-30个之间。

这里也要说一下性能，性能提升有很多种方式，最笨的方法就是在每个细节部分都注意到。

对于不需要用到的字段尽量的不要在宽表中展示，这也是复杂场景下，推荐用自定义sql的原因。

对于数据层面，可用范围要极尽缩减，做到用多少取多少。举个例子：如果你要分析本月的订单数据，但实际上提供的表是所有订单数据。此时建议在模型层对数据进行缩减。

实际业务中，具体的建设实施，一般是采用自底向上的模式比较多，这个模式偏业务驱动，都是先有特定分析需求或特定报表需求开始，然后再到数据平台。针对特定部门，特定需求，先做一些部门的关键指标报表（尤其到现在的互联网公司更是采用敏捷开发，快速迭代），逐步再演变重构平台，所有这些在统一平台前都是会由一些特定的需求或报表而先使用起来，效果出来后，再统一规划重构数据中心、数据平台，这时的实施模式就会由原来的自底向上转变为站在更高角度的自顶向下模式了

流程规范

流程规范主要有资源创建规范，命名规范，权限分配规范。

1.资源创建规范：上面讲到的业务切割，也是一种资源创建规范的一种。在有数BI的项目中资源有数据连接，数据模型，报告。对于这些创建原则尽量用文件夹隔离，业务细分用子文件夹。对于一些公共业务模块可以见公共文件夹块。

2.命名规则规范：要做到顾名思义。在资源创建的时候，首先面临的是命名规范。

(1)资源创建命名规范：对于一些小型主题分析，尽量数据连接、模型、报告的文件夹命名保持一致。如图所示：

如果在小型主题分析中有多个细分业务。由于数据连接支持1级文件夹，数据模型和报告支持多级文件夹创建。所以命名规范如下：

为什么命名规则不采用：如一级业务-二级业务-具体业务-创建日期-创建人这样的方式命名？原因有两个：

逻辑虽然清晰，但是命名规范复杂。用文件分级形式有交互；

对于创建人，创建日期等信息可以通过后台监控方式获得，所以可以不用需要在命名中体现。

(2)字段（指标）命名规范：在BI项目中也非常重要，可以参考数仓设计字段命名规范。但是通常在大型项目中如果存在主题交叉的时候，但又要防止烟囱式开发，指标的复用是很突出的问题。

具体如何对指标进行管理，这里推荐一门课程，由郭忆老师在极客时间的《数据中台实践》。该课程在第五章具体介绍了指标管理的方法。

3.权限分配规范。如果在中大型企业中简单的权限分配往往满足不了需求。我们需要采用权限分级策略。系统内部权限设计如下：

对于小主题业务生产者或者业务方。一般授予的是一级或者二级权限，以及数据权限。

所以命名规则主要是针对一级角色和二级角色以及数据权限的命名。

（1）角色权限命名规则：级别_文件夹名_团队_权限

如：一级角色_数据BU分析_数据分析师_编辑

（2）数据权限命名规范数据链接名称_表_字段

如：超市系统_订单表_地区

数据连接

如果在一个项目中业务较多，要考虑数据连接的复用性;同时对于数据权限的限制，优先考虑通过数据连接中的用户权限来控制。而不是用BI的权限控制。

举个例子：如一个公司的重点业务数据都存在某一数据库下面，那么不同部门，不同团队关注的表是不一样的。此时建议先在数据库中创建用户。通过用户来控制业务范围。

报告展示

展示报表

单图（chart）

单图主要是对指标进行某种样式的展示，例如日活的折线图、日活的表格、多平台日活对比图等，并可以对单图进行多个维度的查询操作。它提供了：
- 维度：可以选择多个维度，向下进行钻取
- 时间：可以选择昨天、过去7天、过去30天、过去90、过去180天、过去365天以及自定义天数
- 图表样式：目前支持折线图、横向柱图、竖向柱图、表格、地图、饼图等图表
看板（dashboard）

看板能够帮助将相互关联的单图集合在一起，兼顾全面性与单独性，既能够从多个图表中发现关联，也可以对单个图表进行深入分析，方便每天查看相应的数据。看板可以供不同的业务人员实现不同的使用场景：
- 产品经理的看板可能是项目的核心指标
- 市场人员的看板可能是监控各个渠道来源指标
- 销售的看板可能是潜在客户的活跃度

自助分析

业务人员的需求是多种多样的，如果这些需求都让负责BI平台的产品经理来配置的话，既增加工作量，又有很大的沟通成本，这时候，业务人员就需要一个能够自己在平台上快速方便搭建报表的方式。

自助分析功能的核心是创建单图功能，使用人员可以选择图表样式，现在常用的图表类型有表格、折线图、柱状图（横向柱图、竖向柱图）、饼图、漏斗图、堆积图等，然后选择数据源里的数据表，把对应的数据表中的字段拖拽到时间、维度、指标栏中，然后选择查询便可以在显示区进行预览，还可以设置过滤条件，进行一些维度的过滤，并可以设置是否在前端显示。

功能性分析工具

一个完善的BI平台，不仅仅是单纯展示数据的，还要能够能为数据分析师、业务人员提供一些常用的数据分析工具，例如用户行为路径、用户分群与用户详情、系统监控等工具，可以方便使用人员方便快捷的分析更精细的业务场景。

以用户分群和用户细查为例，日常中经常需要把满足某个或者某些条件的用户区分出来，然后查看这批用户的一些关键指标以及一些行为事件等，例如，想了解iOS平台上，最近五天内连续沉默的用户，使用人员选择这些条件组合后，就可以获取一批userid的列表，让后查看每个userid的用户属性、用户行为轨迹、用户活跃度趋势、用户阅读文章列表等信息，由于不方便透露一些用户信息，用户细查页面就以原型图的形式给予示例，见下图。当然获取某些条件下的userid对集群来说是有一定的计算压力的，要等一些时间计算完成后才能给用户显示。

业务场景模板

BI数据系统是要更方便的服务于不同的业务场景进行数据分析的，每个业务场景总会沉淀下来一套固定的分析思路和分析架构，这套固定的分析架构就可以放在BI平台上来实现，例如渠道分析、用户留存分析、用户活跃分析及日常的周月报等。通过分析模板，可以方便快速的查看数分析数据，提高效率。

例如活跃用户分析来说，根据平时的分析习惯，一般要将活跃用户拆解为不同的活跃用户群体，进一步查看活跃用户的构成及这部分用户的变化情况，从而针对每部分的不同群体进行优化和分析。例如可以按照下图的分析框架创建一个看板（dashboard），由一下七个单图（chart）组成一个日常的分析模板。

报告

1个报告的模型尽量不要超过10个。如果超出，可以考虑分报告实现，模型尽量复用。

报告是加载当前页面的组件，所以一个报告页组件不要超过20个。能分报告页，尽量不要用tab页组件。

筛选器等组件尽量不要用数据量较大的数据模型。建议用维表。

对于开发阶段建议把报告放在私人文件夹下开发。等报告验证完成复制到公共区域。

对于离线分析报告，建议做预加载处理。

是BI的核心，一句话总结：报告是一个商业产出可以用价值衡量，所以要看性价比，因此大方向上需要做到4点。

即席查询

实施指标分析

BI 作为企业经营管理辅助工具，是在企业信息化建设已经很完善的基础上

BI 的第一步：数据可视化

BI 给人的最直观的感受，就是可视化大屏上炫丽的图形。这些图形只是做了图形化的展示，尽管并未对数据做任何处理，但清晰、易懂、直观、友好的图形，本身就是企业管理的一大飞跃。

人是视觉动物，同时人的注意力、理解能力又是有限的，用图形来给管理运营人员展示数据，要比给他们一对密密麻麻的Excel报表，效率的提升绝对是倍数级的。

BI 的第二步：决策智能化

BI 决策智能化，服务的是企业经营

BI 的核心价值，在于决策的智能化。

BI 决策智能化，本质是企业经营决策的知识沉淀。

BI 决策智能化，需要能超越过往经验，发现并解决以往处理不了的问题。

在 BI 项目实践中，笔者不止一次遇到过业务部门提出需求，就是领导层觉察到某项业务指标存在问题，但就是不知道原因出在哪里。在这类需求中，成百上千的 Excel 报表、数十万甚至上百万条数据，把业务人员折磨的死去活来，分管的部门领导面对问题也是一头雾水，被大领导追着问、却根本给不出清晰有说服力的答案，更给不出解决方案。

尤其是在一些涉及到成本费用的领域，有问题却找不到原因是一个很敏感的问题。领导永远觉得钱花得太多，也不知道钱到了那里去，中层领导只能很模糊的掌握一些信息，但是给不出数据证实自己的判断。而企业规模的快速增长，又给内部的员工吃回扣等行为提供了温床，这个时候管理层面临的压力将是空前的。我想，这也是为什么很多企业，在业务相关的 BI 建设还没完成时，甚至刚刚建好销售 BI，就立马开动做财务 BI 的重要原因。

在这类问题中，需要 BI 团队尤其是数据分析人员，对业务进行深度介入。归因分析是个体力活，需要从海量的数据中，对问题的线索进行仔细梳理，追根溯源找到问题发生的根源，并把导致结果的路径链条理清楚，并最终用清晰地图表展示出来。这对于数据分析师的个人综合能力要求是很高的，数据分析师的数据分析能力、对于业务的学习理解能力、以及科学严谨的工作态度，都是缺一不可的，这也是 BI 项目能否有更高突破的关键。

在企业 BI 建设过程中，

当然，这并不是要求一定要有数据中台才能开展 BI，

，并且数据中台建设一定是要服务于 BI 建设的，而不是反过来。

需要注意的是，在数据中台的建设理念看来，BI

中台的价值在于响应业务需求，这一点“阿里去中台化”的教训已经足够深刻。而对数据中台来说，其核心价值的第一要务就是服务于 BI，BI 团队明白这一点尤为重要。