下面，按照BI平台的版本迭代路线，讲一下BI建设的四个阶段：实现可拓展的展示报表（1.0版本）、自助分析功能（2.0版本）、添加功能性分析工具（3.0版本）、实现业务场景模板（4.0版本） 。
实现可拓展的展示报表
BI平台首先要完成的就是对指标的报表性展示，大家首先想到的解决方案无非是前端写页面，后端接口在数据库查询相应字段，直接吐出数据。可是，这种传统的方式太依赖于前端，如果增加一个指标，前后端修改的成本都比较高。因此，为了以后BI平台的可扩展性，可以通过前端配置json，并在API下一层添加了QueryAdapter来把Api的接口翻译成相应的Sql，然后通过Sql查询数据库的形式，来提高前端的扩展性和报表的灵活性，具体架构如下图所示：
图1 可扩展的报表架构
这里要讲两个概念，单图（chart）与看板（dashboard），单图主要是对指标进行某种样式的展示，例如日活的折线图、日活的表格、多平台日活对比图等，并可以对单图进行多个维度的查询操作，它提供了：
维度：可以选择多个维度，向下进行钻取；
时间：可以选择昨天、过去7天、过去30天、过去90、过去180天、过去365天以及自定义天数；
图表样式：目前支持折线图、横向柱图、竖向柱图、表格、地图、饼图等图表。
看板（dashboard）能够帮助将相互关联的单图集合在一起，兼顾全面性与单独性，既能够从多个图表中发现关联，也可以对单个图表进行深入分析，方便每天查看相应的数据。看板可以供不同的业务人员实现不同的使用场景：
产品经理的看板可能是项目的核心指标；
市场人员的看板可能是监控各个渠道来源指标；
销售的看板可能是潜在客户的活跃度…
对于支持自定义图表的单图（chart）而言，在前端配置的json格式中，需要明确以下几个字段：
dataSource：数据源，也就是单图（chart）要查询的数据库、数据表，它包含了数据的地址、端口、数据库格式、数据库、数据表等，是数据展现的基础。
metrics：这是是要展示的指标，包括指标的计算类型、指标的id、指标名称、指标别名等，
dimensions：指标的维度，也就是相当于Sql中的group，也就是分析人员想按照什么样的分组来查看数据。
filter：这部分是用来设置过滤器，前端报表用来筛选查询条件的，它要规定每个维度应该以何种规则来过滤，是等于、不等于、大于、小于还是包含，还要规定维度的查询字段和查询值，简单表示下就是下面这种格式，当然还有很多字段可以添加以便进一步扩展功能，具体filter的格式可以参考下图。
图2 filer格式
orders：输出结果应该以哪一个指标进行排序。通常使用时间字段来进行排序设置。
除了以上几个重要字段外，还可以设置time、limit等字段来扩展更多功能，这里就不一一详述了。
看板（dashboard）的实现逻辑也与上面相似，不同的是还添加了看板中包含哪些单图（即包含的每个chart的id），以及这些单图在看板中的位置等信息。
有了上面的支持可拓展的json配置格式，就可以在BI平台配置出符合自己需求的单图（chart）与看板（dashboard）了。至此，已经能满足日常的报表展示需求，BI平台也完成了V1版本的迭代。
自助分析功能
以上只是满足固定数据的展示，可是，数据产品经理经常面对的情况是，业务人员的需求是多种多样的，如果这些需求都让负责BI平台的产品经理来配置的话，既增加工作量，又有很大的沟通成本，这时候，业务人员就需要一个能够自己在平台上快速方便搭建报表的方式。
自助分析功能这部分主要包含创建单图（chart）和创建看板（dashboard）两部分，这两部分都是基于前期灵活可扩展的json图表配置，并在此基础上，能够创建一些复杂的计算字段，例如，想计算平均停留时长这个指标，它是由总停留时长除以dau计算而成的，总停留时长和dau都是基础指标，在数据表中是已经存在的，那么就可以定一个计算字段，命名为平均停留时长，计算公式为sum（dwell/dau），如下图3所示：
图3 创建计算字段
自助分析功能的核心是创建单图功能，使用人员可以选择图表样式，现在常用的图表类型有表格、折线图、柱状图（横向柱图、竖向柱图）、饼图、漏斗图、堆积图等，然后选择数据源里的数据表，把对应的数据表中的字段拖拽到时间、维度、指标栏中，然后选择查询便可以在显示区进行预览，还可以设置过滤条件，进行一些维度的过滤，并可以设置是否在前后端显示，具体功能见图4。
图4 创建单图（chart）页面
在基本功能的基础上，还有一些细节功能需要去优化，例如，有时候折线图从0为Y轴为起点很难看出波动，这样就可以设置指标显示的范围，让它在一定范围内显示，从而进一步缩小显示区间，突出趋势变化，另外，还可以支持一些实时数据的展示功能等。
完成创建单图功能后，就可以基于已经创建的单图上，选择已经创建的单图，动态拖拽到看板（dashboard）的合适位置，从而组成满足自己分析需求相关的看板，形成日常性报表组合。
最后不得不提一下数据源管理功能，因为所有的单图（chart）和看板（dashboard）都是基于数据源进行分析的，好的数据源管理可以提高数据源的利用率、降低重复创建数据源，进一步提高效率，并且还可以进一步拓展数据的存储形式，除了支持Mysql存储，还可以支持Druid、Phoenix等。
另外，数据源管理要考虑业务的复杂性，能够满足复杂的多表join，支持自定义SQL查询。最后，数据源管理也要注意对数据权限的控制，最好能够做到对表中字段这种细粒度的权限管理，进一步提高数据的安全性。
功能性分析工具
一个完善的BI平台，不仅仅是单纯展示数据的，还要能够能为数据分析师、业务人员提供一些常用的数据分析工具，例如用户行为路径、用户分群与用户详情、系统监控等工具，可以方便使用人员方便快捷的分析更精细的业务场景。
以用户分群和用户细查为例，日常中经常需要把满足某个或者某些条件的用户区分出来，然后查看这批用户的一些关键指标以及一些行为事件等，例如，想了解iOS平台上，最近五天内连续沉默的用户，使用人员选择这些条件组合后，就可以获取一批userid的列表，让后查看每个userid的用户属性、用户行为轨迹、用户活跃度趋势、用户阅读文章列表等信息，由于不方便透露一些用户信息，用户细查页面就以原型图的形式给予示例，见图5。当然获取某些条件下的userid对集群来说是有一定的计算压力的，要等一些时间计算完成后才能给用户显示。
图5 用户细查原型页面
业务场景模板
BI数据系统是要更方便的服务于不同的业务场景进行数据分析的，每个业务场景总会沉淀下来一套固定的分析思路和分析架构，这套固定的分析架构就可以放在BI平台上来实现，例如渠道分析、用户留存分析、用户活跃分析及日常的周月报等。通过分析模板，可以方便快速的查看数分析数据，提高效率。
例如活跃用户分析来说，根据平时的分析习惯，一般要将活跃用户拆解为不同的活跃用户群体，进一步查看活跃用户的构成及这部分用户的变化情况，从而针对每部分的不同群体进行优化和分析。例如可以按照下图的分析框架创建一个看板（dashboard），由一下七个单图（chart）组成一个日常的分析模板。
图6 活跃用户构成分析模板
梳理好分析框架后，就可以在BI平台上建立起固定的模板，很大的方便的满足了日常的业务场景分析。
搭建一个完善的BI平台，是需要不断打磨优化产品的，搭建平台的目的无非就是提高工作效率，方便大家快捷高效的获取数据，以上只是我在搭建BI平台的一些经验心得，分享出来与大家一起交流。
作为一名数据产品经理，还需要多了解业务，多使用自己的产品，如果BI平台自己使用都不方便，那么更何况数据分析师，乃至数据经验比较少的业务相关人员呢？另外，对于BI平台，以上四个阶段并不是适用于所有公司。不同的业务阶段的需求都是不一样的，初创公司没有太多的人力和时间来搭建自己的平台，可以引用市面上的第三方产品，例如友盟、BDP等，做的都已经相当成熟，还是要针对每个公司的具体阶段而定。
发表评论 取消回复