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

文章插图
派可数据大屏可视化分析
所以，大家可以看到从业务系统数据取数到最后的报表呈现实际上经历了很多的阶段。在商业智能 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 - 客户的身份证号，唯一标识 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 不是可以拖拉拽取数吗？为什么还要 SQL 取数 ? | 报表( 二 )