BI数据可视化工具应该如何选择

派可数据

推荐人群：企业选型、数据分析师、相关业务人员、

派可数据是国内专业的低代码数据仓库开发平台+敏捷BI可视化分析平台，国产商业智能BI软件产品，具备端到端（End-to-End)的产品与服务能力，包括：企业级数据仓库平台、三端可视化分析（PC端、移动端、大屏端）自助设计能力、中国式报表、填报与数据补录平台。

企业级数据仓库平台-快速原型可视化设计建模、零代码的数据仓库建模设计与开发、维度与指标体系管理、血缘分析、ETL调度平台等，无需人工开发数据仓库，极大的提升了BI项目中数据仓库的开发效率，为企业构建一个高度可扩展的、专业的企业级数据仓库。

2三端可视化分析（PC端、移动端、大屏端）-用户可以基于数据仓库的分析模型，快速的通过自助拖拉拽式的方式即可完成可视化分析页面的设计与开发，包括几十种常见可视化图表、颜色模板、主题模板、水印管理等。快速实现可视化图表的联动、钻取、切换等多维分析效果，无需任何的代码实现，可视化图表完全组件化。移动端可以快速与企业微信、钉钉、企业APP等实现集成，完美的用户体验。

3中国式报表-支持各种行列扩展二维报表、交叉报表、复杂中国式报表的设计与展现。

4填报与数据补录平台-快速实现数据填报的设计与流程审批功能。

可视化效果：

实际展示：

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 前端可视化报表工具解决一切分析问题，这个时候就需要认真思考一下是否可行。

>

从技术实施角度看，主要包含“理”“采”“存”“管”“用”这五个，即业务和数据资源梳理、数据采集清洗、数据库设计和存储、数据管理、数据使用。

数据资源梳理：数据治理的第一个步骤是从业务的视角厘清组织的数据资源环境和数据资源清单，包含组织机构、业务事项、信息系统，以及以数据库、网页、文件和 API 接口形式存在的数据项资源，本步骤的输出物为分门别类的数据资源清单。

数据采集清洗：通过可视化的 ETL 工具（例如阿里的 DataX，Pentaho Data Integration）将数据从来源端经过抽取 (extract)、转换 (transform)、加载 (load) 至目的端的过程，目的是将散落和零乱的数据集中存储起来。

基础库主题库建设：一般情况下，可以将数据分为基础数据、业务主题数据和分析数据。基础数据一般指的是核心实体数据，或称主数据，例如智慧城市中的人口、法人、地理信息、信用、电子证照等数据。主题数据一般指的是某个业务主题数据，例如市场监督管理局的食品监管、质量监督检查、企业综合监管等数据。而分析数据指的是基于业务主题数据综合分析而得的分析结果数据，例如市场监督管理局的企业综合评价、产业区域分布、高危企业分布等。那么基础库和主题库的建设就是在对业务理解的基础上，基于易存储、易管理、易使用的原则抽像数据存储结构，说白了，就是基于一定的原则设计数据库表结构，然后再根据数据资源清单设计数据采集清洗流程，将整洁干净的数据存储到数据库或数据仓库中。

元数据管理：元数据管理是对基础库和主题库中的数据项属性的管理，同时，将数据项的业务含义与数据项进行了关联，便于业务人员也能够理解数据库中的数据字段含义，并且，元数据是后面提到的自动化数据共享、数据交换和商业智能（BI）的基础。需要注意的是，元数据管理一般是对基础库和主题库中（即核心数据资产）的数据项属性的管理，而数据资源清单是对各类数据来源的数据项的管理。

血缘追踪：数据被业务场景使用时，发现数据错误，数据治理团队需要快速定位数据来源，修复数据错误。那么数据治理团队需要知道业务团队的数据来自于哪个核心库，核心库的数据又来自于哪个数据源头。我们的实践是在元数据和数据资源清单之间建立关联关系，且业务团队使用的数据项由元数据组合配置而来，这样，就建立了数据使用场景与数据源头之间的血缘关系。 数据资源目录：数据资源目录一般应用于数据共享的场景，例如政府部门之间的数据共享，数据资源目录是基于业务场景和行业规范而创建，同时依托于元数据和基础库主题而实现自动化的数据申请和使用。

质量管理：数据价值的成功发掘必须依托于高质量的数据，唯有准确、完整、一致的数据才有使用价值。因此，需要从多维度来分析数据的质量，例如：偏移量、非空检查、值域检查、规范性检查、重复性检查、关联关系检查、离群值检查、波动检查等等。需要注意的是，优秀的数据质量模型的设计必须依赖于对业务的深刻理解，在技术上也推荐使用大数据相关技术来保障检测性能和降低对业务系统的性能影响，例如 Hadoop，MapReduce，HBase 等。

商业智能（BI）：数据治理的目的是使用，对于一个大型的数据仓库来说，数据使用的场景和需求是多变的，那么可以使用 BI 类的产品快速获取需要的数据，并分析形成报表，像派可数据就属于专业的BI厂商。

数据共享交换：数据共享包括组织内部和组织之间的数据共享，共享方式也分为库表、文件和 API 接口三种共享方式，库表共享比较直接粗暴，文件共享方式通过 ETL 工具做一个反向的数据交换也就可以实现。我们比较推荐的是 API 接口共享方式，在这种方式下，能够让中心数据仓库保留数据所有权，把数据使用权通过 API 接口的形式进行了转移。API 接口共享可以使用 API 网关实现，常见的功能是自动化的接口生成、申请审核、限流、限并发、多用户隔离、调用统计、调用审计、黑白名单、调用监控、质量监控等等。

先说说传统BI，其做法是IT人员事先根据分析需求来进行建模以及做二次表，提前汇总好数据，业务人员在前端查看分析结果报表，这带来的最大问题就是：

1业务人员查看的报表相对静态，分析的维度和度量的计算方式已在建模时预先设定好，不能更改，比如定好了是求和或求平均数，想改成求方差必须回去修改模型；

2分析需求变更时，业务人员不能直接调整报表，需要IT人员重新建模或修改已有分析模型，耗时较长，响应速度较久。

而敏捷BI是采取轻量建模、N个视图的方法，不建二次表，数据连进来直接可以进行分析，并且业务人员可以实时调整分析的维度和度量的计算方式，极大增加灵活性，真正做到和数据对话。技术上理解，就是采用了列存储，分布式计算，比如像FineBI，就是通过动态生成的位图索引技术来处理字符串等类型的数据，通过NIO内存映射文件技术来快速处理数字类型的数据，关键是自动建模，处理起来快。

敏捷BI，像国内的话，以FineBI为代表，自动建模，所有维度，所有指标，索引关联都在一开始就建立好，所以在做分析的时候可以方便创建维度，查看分析的时候也可以方便查看切换维度。

以上就是关于BI数据可视化工具应该如何选择全部的内容，包括:BI数据可视化工具应该如何选择、BI 不是可以拖拉拽取数吗为什么还要 SQL 取数 | 专家视角、如何有效的进行数据治理和数据管控等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！