BI 不是可以拖拉拽取数吗？为什么还要 SQL 取数 ? | 专家视角

36氪企服点评专家团——吕品

————正文————

BI 工具不是可以直接拖拉拽取数吗 ？为什么还要写 SQL 取数 ? 这是很多初次接触商业智能 BI 的朋友会提到的一个问题，因为在他们接触到一些 BI 市场或者产品宣传的时候，很多人就是这么来介绍BI 的。

简单来说，这个问题背后的逻辑等同于： 拿着碗和筷子不是可以直接吃饭吗 ？为什么还要自己动手做饭 ？有没有想过，即使是直接吃饭，饭总是要有人来做的吧，无论这个人是自己还是别人，“做饭”这个过程并不会少。

所以，从这个问题背后能看出来还是有很多人对于 BI 的理解还是存在一定的误区，我们可以从以下这几个角度来分析讲解一下。

可视化 BI

很多人对于 BI 的印象就停留在数据的可视化图表，但可视化图表只是 BI 的最终呈现，可视化的拖拉拽并不是 BI 的全部。

一个完整的商业智能 BI 解决的应该是端到端（ End to End ) 的问题，需要从各个业务系统的数据源取数，通过 ETL （ Extract 抽取、Transformation 转换、Loading 加载 ）的过程 将要分析的数据从规范的不可分析的、或不规范不可分析的数据最终变为规范的、可分析的形式 ，最终通过 BI 可视化拖拉拽的方式将数据进行有效的、带有逻辑性的组织形成可视化分析报表。

派可数据大屏可视化分析

而大部分的 BI 工具如果重在强调前端可视化的能力，这类 BI 工具的定位就是解决数据可视化分析展现的问题，属于 BI 前端可视化报表工具，但并不能代表 BI 的全部。

如何形象的理解 BI

如果把 BI 可视化实现的过程比作到餐厅出菜的过程，那就是：

数据源环节 vs 菜市场

从各个业务系统取数 —— 按照餐厅营业需求准备所需菜品的原材料，就需要到各个市场买菜。不同的业务系统对应不同的菜市场，不同的菜市场有不同的摊位对应的就是业务系统数据库中不同的数据表。摊位上的菜就可以理解为数据表中的数据，要分析什么就取什么样的基础数据。

数据仓库 vs 后厨仓库

数据仓库环节 —— 从各个市场买回来的菜堆在哪里呢？后厨仓库。有的菜是今天要用的，有的菜是明天要用的，所以先买回来堆起来。从各个系统抽取上来的数据也是如此，这些数据有的来源于 Oracle 系统，有的来源于 MySQL 或者 SQL Server，按照分析需求从不同的数据库抽取之后放到自己的数据仓库中集中管理起来。

ETL 过程 —— 厨师做个猪肉炖粉条不可能把整扇猪肉、一颗一颗的大白菜扔到锅里，一定是猪肉切片，大白菜去除坏掉的叶子，菜该切切，肉该剁剁剁。同时，还会备好一些辅助的佐料等原材料，最后把所有的原材料放到 *** 作台上，这个就是备菜（ 择菜、洗菜、切菜 ）的过程。

数据也是如此，把数据从各个业务系统先 抽取（ Extract ） 上来，等同于把放在不同仓库格子的菜拿过来。数据要做 转换（ Transformation ） ，比如一些脏数据的处理、格式的转换、数据计算口径的统一、指标的计算等等，就如同洗菜、择菜、切菜的过程。最后将处理之后的数据按照一定的模型或者格式 加载（ Loading ） 到指定的可被前端调用的数据表中，就如同把所有备好的菜放到一起准备下锅。

报表可视化 Reporting vs 上菜

Reporting 报表可视化就是最后的呈现，也通常视为 BI 的前端，所以也叫做 BI 前端可视化。用户需要什么样的可视化报表，就如同用户点菜一样可以高度定制化，前提是基于已有的原材料（数据）。

派可数据大屏可视化分析

所以，大家可以看到从业务系统数据取数到最后的报表呈现实际上经历了很多的阶段。 在商业智能 BI 开发过程中，80% 的时间在处理底层数据（ 跑菜市场、买菜、运菜、择菜、洗菜、切菜到备好菜 ），20% 的时间在做可视化分析报表（ 做菜 ）。 底层数据的处理重点就是 ETL 过程，而实现 ETL 过程的主要方式就是通过 ETL 工具（ 例如：Kettle、Informatica、Pentaho、IBM DataStage、Microsoft SSIS 等 ）或其它 ETL 框架结合 SQL 查询语句、Stored Procedure 存储过程等方式来组织和管理数据处理的先后顺序。

特别是企业级 BI 项目建设，不仅仅是简单的 ETL 过程还需要涉及非常专业的数据架构设计、数据仓库建模、分层设计等数据仓库的构建，这里面最常用的开发语言就是 SQL。

BI 直接取数分析并不可行

很多 BI 工具会经常强调直连取数，这样就不需要写 SQL，直接通过表与表之间的关系进行表间建模，形成一个大宽表，文本类型的就是维度 Dimension，数值类型的变成度量 Measure，通过 BI 前端可视化进行拖拉拽 *** 作形成很多 Ad-hoc Report 即席报表。

在实际演示案例的时候也是如此，最常见的就是一个标准的、数据格式极为标准规范的 EXCEL 表上传一下按照上面的方式来一遍；要么就是销售订单表和销售明细表关联一下，算算订单数量、订单金额等等。

其实验证一下 BI 工具的这种直连且拖拉拽的能力到底有多强非常简单，让业务部门提几个实际的分析需求，现场拿 BI 产品从实际的业务系统中取数来验证一下是否那么容易就明白了。

以下面一个小 DEMO 为例，可以使用任意的国内外 BI 可视化分析工具尝试一下当直连到这张表的时候，是不是就可以直接、任意的进行拖拉拽分析。

案例：统计外包业务的人工效率（时长）

背景：某金融公司把一部分贷款业务外包出去给第三方公司，第三方公司业务人员每与客户联系一次，就会根据沟通的状态记录一下，形成了以下的业务数据表 DurationTime，有以下三个核心字段：

ID - 客户的身份z号，唯一标识 ID

Operation - 一个 *** 作记录，重点节点有 0034、0036、0048

Date - 一个 *** 作记录的时间日期（实际上是时间，为了简化用日期表示）

业务系统中的原始数据表

计算规则如下：

1) 计算0034-0036，0036-0048，0034-0048的时间间隔。

2) 如0036之前没有0034，不可单独计算0036-0048的时间间隔。

3) 如0036后跟着多个0048，则取到最晚的一个0048的时间间隔。

4) 如0034后跟着多个0048，则取到最早的一个0048的时间间隔。

5) ....

实际的计算规则多达 20 多种，就以上面 4 条计算规则为例，最后的计算结果是：

Transformation 表

为了得到上面的最终结果，通常往往会创建一些中间转换表，用来记录转换的过程，便于检查和纠正逻辑，这种表我们通常叫做 Transformation 表。

业务系统中的原始数据表的数据规范吗 ？非常规范。但是适合分析吗 ？并不适合。所以在 BI 分析之前要做什么？ 那就是写 SQL、ETL 取数，把这种在业务系统中规范的不可分析的、或不规范的不可分析的变成规范的、可分析的数据格式 —— 结果表。

在实际的 BI 项目开发过程中，来自各个业务系统数据源的数据大部分情况下就是一种不可直接分析的状态，与分析思维不同，他们是描述业务过程的。

还会有一种说法是：可以直连业务数据源，通过写 SQL 查询一个数据集再通过前端 BI 可视化分析工具来呈现做可视化分析报表行不行？ 我们的建议是，除了以下几种情况，不要这样做：

第一，这类可视化分析报表基本上就是一次性的，一年可能就改不了几回。

第二，本身数据量不大，使用频率也不会非常的高。

原因在于： 没有合理的建模、指标计算复用性太差、影响业务系统性能、无法应对后续日益增长和不断变化的业务分析需求，按照这种方式做的 BI 基本上不会超过两年就会面临推翻重做的风险。

所以，在使用 BI 的时候，不管是直连业务系统数据源的表进行表间关系建模，还是通过写 SQL 查询数据结果集的方式直连业务系统，在大多数情况下都不合理，BI 开发人员应极力避免采用这样的数据 *** 作方式，这些还都是在没有涉及到多异构数据源取数、主数据档案不一致、组织架构缺失补位、缓慢渐变维度等问题的前提下。

BI 直接取数分析什么样的情况下是可行的 ？

也有朋友说到，我们公司就是直连数据库取数做可视化分析的。我们让朋友回去问了一下，原来连接的是企业已经构建好的数据仓库。在这种情况下，底层的数据模型相对比较标准，数据也经过了非常良好的格式转换，可以直接使用一些前端 BI 可视化分析工具进行快速的分析，这样的一种搭配就非常好。

所以，BI 直连数据库不是不可行，但得分清楚直连的是业务系统的数据源数据库，还是直连的是已经通过 SQL 从业务系统的数据源取数和建模处理后的数据仓库、数据集市。

派可数据自助开发平台包括数据仓库与BI可视化分析

IT 和业务的边界就在这里，IT 负责底层数据建模、数据仓库的构建，业务基于已经建好的基础分析模型通过 BI 前端可视化分析工具来进行拖拉拽的可视化分析 *** 作。 倘若是这样，也确实实现了不通过 SQL 取数使用 BI 前端工具就可以做报表的目标。但绝对不能认为，不通过 SQL 取数就可以对接任何业务系统数据源做任何 BI 可视化分析。

所以，当一家企业底层已经有架构非常良好的数据仓库，这个时候使用一个轻量的 BI前端可视化分析工具基本上就够用了。但如果所在企业底层还没有良好的数据仓库系统，只寄希望单纯的使用一个 BI 前端可视化报表工具解决一切分析问题，这个时候就需要认真思考一下是否可行。

www.36dianping.com

原文标题：《BI 不是可以拖拉拽取数吗？为什么还要 SQL 取数 ? | 专家视角》

作者： 吕品

本文来源于36氪企服点评

上周，亿信华辰正式对外发布产品一站式数据分析平台-ABI，吸引了很多朋友的关注。ABI是亿信BI华丽的转身，它是在亿信BI的基础上，新打造的一款集数据采集、处理、分析和展示为一体的平台，能大幅度降低数据分析实施技术门槛，使复杂的工作简单化、重复的工作智能化。

那么，有朋友可能就要问了，“我使用BI4.7已经习惯了，我为什么要升级ABI呢？升级之后不知道怎么用了怎么办？”

别着急下结论，听小亿一一道来，相信看完这篇文章之后，会发现ABI真的非它不可。

界面对比

老朋友都知道，亿信BI4.7总体界面是浅蓝色，活泼开朗，自由清新，象征着BI蓬勃发展，未来可期。

而亿信ABI总体界面采用的是深蓝色，极致内敛，深沉睿智，经过了BI跳跃式的发展时期，ABI沉静了下来，向世界展示她睿智的一面。

模块对比

我们知道，亿信BI4.7中包含了分析平台、门户管理、用户权限、系统管理、运营监控等几个大模块。

而在ABI中模块规划更显得清晰易用，从数据源、数据整合、数据分析到应用发布一站式应用：

数据源模块对应着亿信BI4.7中系统管理下的数据库连接池；

数据整合是ABI中新增的数仓模块，可以对数据进行处理加工；

数据集模块主要用来统一管理主题表与维表；

数据分析模块可以在其中制作各种各样的报表分析、报告分析、敏捷分析、智能分析、可视化分析、移动应用以及数据回填等；

应用发布模块对应亿信BI4.7中的门户管理；

系统管理与亿信BI4.7基本保持一致；

工作流也是ABI中新增的模块，用户可以自行设计工作的流程，满足不同场景时工作流程会有所变化的需求，同时还可以与填报相结合，实现数据填报后的数据审批。

功能对比

ABI中不仅保留了亿信BI4.7内所有的模块功能，而且功能比亿信BI4.7都更强大了，在原来的基础上添砖加瓦。一起来看一看：

1、数据源

首先是数据源模块。ABI连接池管理对应亿信BI4.7系统管理下的数据库连接池，在这基础上还新增加了两种类型数据源：文件数据源以及接口数据源。

文件数据源

文件数据源可以支持用户上传excel、csv、txt以及db类型的数据源文件，与数据集中文件型主题表结合使用，可以将文件中的数据导入系统进行分析示。

比如在银行业务中，总行机构下的各地分行会定期上报月度数据。分行通常都是以excel的形式，将明细数据上报给总行。人工录入数据非常麻烦，通过ABI中文件数据源的方式，只需要几步就能够录入系统并展示分析了。

接口数据源

互联网上提供了很多对外公开的接口数据，为了方便用户快速提取互联网数据，ABI支持接口数据源，可通过接口获取数据，并将数据转化成规整的格式。

2、数据整合

数据整合是ABI中新增加的模块，其内置了数仓实施工具、丰富的处理转换组件，拖拽式的流程设计，轻松实现数据抽取、清洗、转换、装载及调度，可帮助政府和企业快速构建数据仓库，完成数据融合，提升数据质量，服务数据分析。

可视化的ETL过程创建

ABI提供可视化定义ETL作业信息，支持作业的试运行和断点调试等 *** 作，丰富的图形化组件能协助用户完成ETL数据加工，达到边调试边预览数据的目的。

图形化的ETL过程流设计

ETL过程流编辑器是以图形化的方式完成ETL过程的前驱后继关系和调度顺序的定义。通过简单的拖拽主题表和组件即可完成流程设计。

3、数据集

与亿信BI4.7不同的是，ABI将数据集单独作为一个模块。在数据集模块中可以创建主题域、主题集。新建主题集时可以设置数据期，选择连接池以及分层，方便数据的划分。维表和主题表则可以在主题集下创建或通过导入生成。

主题表的创建ABI中新增多种主题表的创建方式：SQL语句创建、批量复制、根据文件数据源创建、通过ETL过程创建以及根据接口数据源创建。

值得一提的是，我们用批量复制的方式可以大批量创建主题表，一改传统单表创建的方式。ABI可以一键选择多张数据库表自动生成多张主题表，大大节省我们构建主题维度模型的时间。

4、数据分析

与亿信BI4.7相比，ABI在数据分析模块中新加入许多新的特性，比如：即席报告、幻灯片报告、敏捷看板、看板集以及数据回填。通过这些新增的数据分析手段，不仅大大降低数据处理和分析的难度，还能从多种角度更加全方位地展现数据。

即席报告ABI中除了有word分析报告，现在还支持即席报告。即席报告是完全面向业务人员的自助式报告，自由布局排版，打造专属的word版式报告。

幻灯片报告ABI支持幻灯片报告可以像PPT一样播放，可直接引用报表分析和敏捷分析中的分析表，直接用于汇报展示。系统根据用户使用场景及需求进行深入分析，具有 *** 作简单，上手快的特点。

敏捷看板敏捷看板是ABI分析展示的重要方式之一，业务人员可以进行探索式自主分析，只需要简单拖拽维度指标就能自动生成表格、统计图等。

看板集看板集即基于相同筛选条件的多张敏捷看板的集合，是在看板功能上的一次深挖，能同时对多张敏捷看板进行对比分析，具有 *** 作简单，功能完善的特点。

数据回填通过表格、表单、列表等方式呈现的数据，可直接在结果页面对数据进行增删改等数据 *** 作，并保存到数据库表中，常应用在活动、简历、测评、收款、问卷等场景中。

下面是某公司一张人员信息采集表，我们可直接基于表单结果页面对人员信息进行增删改查，修改提交的数据可进入审核流程，确保数据的正确性和一致性。表单中还提供下拉按钮，可以选择日期岗位等信息，便于数据的录入。 *** 作结束后点击保存按钮即可保存表单。

5、应用发布

ABI将PC门户、移动门户和酷屏门户整合到应用发布模块下，在这里可以对你的门户、控件以及资源进行管理，还能设置登录页配置公众号。

很多BI工具内含的门户工具技术性很强，需要相当的编码和技术设计能力，用户学习掌握非常困难。ABI内含便捷的门户定义工具，用户只需通过简单的拖拉拽，就能自己定义个性化的门户，把想要的报表有序集成到门户中。同时ABI中提供多种样式风格和高级设置，可以对门户做全方位的规划。

6、工作流

工作流也是ABI中新增的模块，可以让多个参与者之间按照某种预定义的规则传递文档、信息或任务，这个过程自动进行，从而实现某个预期的业务目标，或者促使此目标的实现。

工作流绘制在工作流编辑工具中，用图形化的方式将实际过程或步骤描述出来，并转化成规范的工作流定义语言格式。

以下面这个请假申请的工作流为例，申请人提交请假表单后先由1级审批人进行审批，不通过则需要重新提交申请，通过则由2级审批人进行审批，不通过则需要重新提交，通过则结束流程。

工作流发起

当一个工作流编辑好后，可以在工作流中绑定回填表，数据填报后即可发起流程。在“我的流程”中可以看到已发布的工作流，每次流程发布后都会形成一个流程版本。

查询统计

在工作流发起后，我们可以在查询统计中看到已完成和未完成的工作流信息，并且可以对工作流进行删除和查看。支持多种条件的过滤，方便查找需要查看的工作流。对于未完成的工作流还可以将其挂起，该流程就不在往下进行了。

其他特性

除了增强了上述的功能模块，ABI还新增了以下特性：

跨库分析：支持跨数据库分析，实现多源数据联合查询，跨越数据鸿沟，使分析更加便利。内存计算：外部接口数据，无需落地，就能分析；缓存常用数据，提高计算效率。集成开发API：提供了上千个API接口，方便用户扩展，便于与第三方系统集成，缩短项目实施周期，降低成本。自定义平面图：地图管理中可自定义平面图，满足特定需求。组织架构图：通过组织架构图能够动态的展现组织的整体架构。总的来说，相较于亿信BI4.7，ABI在带来了许多新功能和新特性的同时，不仅没有增大 *** 作的复杂度，而且还能让你看得更舒服、用得更爽快！

---