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

本文由36氪企服点评专家团吕品原创。

文章插图
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 可视化实现的过程比作到餐厅出菜的过程，那就是：
【专家视角|BI 不是可以拖拉拽取数吗？为什么还要 SQL 取数 ? | 报表】数据源环节 vs 菜市场
从各个业务系统取数—— 按照餐厅营业需求准备所需菜品的原材料，就需要到各个市场买菜。不同的业务系统对应不同的菜市场，不同的菜市场有不同的摊位对应的就是业务系统数据库中不同的数据表。摊位上的菜就可以理解为数据表中的数据，要分析什么就取什么样的基础数据。
数据仓库 vs 后厨仓库
数据仓库环节—— 从各个市场买回来的菜堆在哪里呢？后厨仓库。有的菜是今天要用的，有的菜是明天要用的，所以先买回来堆起来。从各个系统抽取上来的数据也是如此，这些数据有的来源于 Oracle 系统，有的来源于 MySQL 或者 SQL Server，按照分析需求从不同的数据库抽取之后放到自己的数据仓库中集中管理起来。
ETL 过程 —— 厨师做个猪肉炖粉条不可能把整扇猪肉、一颗一颗的大白菜扔到锅里，一定是猪肉切片，大白菜去除坏掉的叶子，菜该切切，肉该剁剁剁。同时，还会备好一些辅助的佐料等原材料，最后把所有的原材料放到操作台上，这个就是备菜（择菜、洗菜、切菜）的过程。
数据也是如此，把数据从各个业务系统先抽取（ Extract ）上来，等同于把放在不同仓库格子的菜拿过来。数据要做转换（ Transformation ），比如一些脏数据的处理、格式的转换、数据计算口径的统一、指标的计算等等，就如同洗菜、择菜、切菜的过程。最后将处理之后的数据按照一定的模型或者格式加载（ Loading ）到指定的可被前端调用的数据表中，就如同把所有备好的菜放到一起准备下锅。
报表可视化 Reporting vs 上菜
Reporting 报表可视化就是最后的呈现，也通常视为 BI 的前端，所以也叫做 BI 前端可视化。用户需要什么样的可视化报表，就如同用户点菜一样可以高度定制化，前提是基于已有的原材料（数据）。