数据|数据产品：自助BI产品实践指南( 二 )

文章插图
1. BI系统架构数据源：从系统架构层级看，BI系统最底层是数据接入层，数据源是原材料，否则工具做的再好也是巧妇难为无米之炊，要支持接入常用关系型数据库，以及数据仓库的数据源。
数据模型：数据接入后，在数据模型层，做表之间的关联、字段逻辑处理、元数据信息维护，形成模型资产，把模型主题、层级分门别类管理好，方面业务快速找到目标数据源，同时需要做好模型权限、字段、行值权限管控，技术层面要把不同数据源集成到OLAP查询引擎，提升即席查询效率。
分析层：无SQL拖拽分析，业务基于数据模型，可以直接选择维度、度量、过滤条件后，直接进行数据查询，同时封装可视化图表组件，做结果的可视化展示。对于需要固化的分析结果，可以将图表保存至Dashboard，且可以对图表系列颜色、数据标签、筛选条件等进行设置。
输出层：主要包括Dashboard输出、将看板以iframe方式嵌入其他平台、数据推送&预警，以及可视化大屏。将可视化能力直接在系统内应用或跨系统复用。

文章插图
自助BI行业来说，成熟的商业化产品非常多，传统的BI分析如帆软BI、BDP、Tableau、永洪BI、亿信华辰等，云厂商阿里quickBI、网易有数、火山引擎智能数据洞察等，在产品细节功能设计的时候，可以注册账号去试用体验即可。

文章插图
四、自助BI产品从0到1的踩过的一些坑1. 数据集资产是根基对于BI产品而言，数据集资产是根基，用户去进行自助分析的前提是，有数据可以分析。在过去从0到1做BI产品初期，最大的问题是功能有了，但是没有可以供业务去查询使用的数据资产模型，自助分析、数据可视化做的再好，也不会有业务去使用。
所以，在企业内部推动BI项目时，要联动数据资产建设者(数仓开发等)，去提供可以给业务去使用的流量、订单、会员等数据模型，让用户体会到，自己取数也很简单，而且更快。
对于数据集管理模块功能设计时，需要提供全面的元数据维护、数据集分级分类检索、数据逻辑确认的能力，让用户方便地找到所需要的数据，一键申请权限，快速自助分析。
2. 自助分析要足够自助曾经，BI项目组中，产品和研发一直围绕一个到底自助分析模块应不应该支持模型关联的问题争执不休。开发的观点是应该像QuickBI一样，将所有的建模过程在数据集创建中进行，自助分析仅做可视化配置。
而产品的观点则是，自助分析除了输出可视化配置能力外，还承担了无SQL取数的功能，很多一线的业务同学，是利用自助分析取数的。数据开发在进行数据集创建时，考虑模型的通用性，会提供一些基础的明细数据，如果只能在数据集上关联，意味着业务进行分析需要关联时，需要联系数据集负责人去改模型，这个周期就很长了。
最初上线时，把自助分析模型关联以及计算字段处理的功能做了灰度隐藏，业务部门直接找过来说，没有这个功能他们就不用了。在这里，我的观点是，自助BI产品，需要包括：自助BI分析+可视化配置能力，自助BI分析，是传统AdhocSQL 取数的低代码、无SQL版本。否则，就只是做到自助可视化，而做不到自助分析。
3. 建立自研BI产品的核心竞争力业务发展早期为了更快的使用起来会外采商业化BI产品，毕竟自研的周期还是比较久的。当业务已经使用了商业化的产品，虽然经过业务发展以及老板的决策说，我们是时候自己搞一个BI产品了。