BI系统，即商业智能系统，用来将企业或业务中现有的数据进行有效的整合，快速准确的提供报表并提供决策依据，帮助企业做出明智的业务经营决策。传统的BI系统提供商有Oracle，IBM，Microsoft，MicroStrategy等。

图1 畅思数据中心分层示意图

BI系统的挑战在于数据量以及计算的效率。结合目前大数据方面的成就，这些问题已经得到的较好的解决。有能力的企业现在完全可以自己搭建自有的BI系统。

本文以畅思平台BI系统为例为大家介绍下BI平台的搭建。

BI系统主要分为数据收集、ETL以及存储入库、任务调度、可视化等部分。

1 数据收集

数据收集需要考虑如下几个问题。

数据源有哪些?

数据的收集方式?

数据的时效性、准确性、完整性?

1.1 数据源

数据源包括三大类：第一方数据，第二方数据，第三方数据。

第一方数据，主要是广告主、媒体回传的用户行为数据。数据一般包括用户注册、登录、关卡等事件信息，可以通过对此类数据的分析，为应用运营提供统计指标，指导运营工作，如果与广告投放数据联合，可以进行广告及用户后续效果的持续追踪以及评估;

第二方数据，主要是广告平台展示、点击、激活等数据，这类数据可用于分析广告平台各个项目在各类媒体上的表现使用，对流量进行评估，如果流量比较稳定，亦可用于创建用户画像使用;

第三方数据主要是其他平台合作数据，该类数据包括用户标签合作接入，基本流量数据。

1.2 数据收集

第一方数据可通过应用集成SDK采集、或者应用方直接回调等方式进行数据的收集。

第二方数据主要是两种方式：广告SDK以及广告API

第三方数据一般采用API、第三方存储(AWS S3， 阿里云存储)、RSYNC等方式进行批量传输。

1.3 数据的时效性、准确性、完整性

对于第一方数据，一般按周期进行传输，除非BI系统提供实时服务，按周期传输的数据可以满足绝大部分数据分析的需求。

而第二方数据，由于平台一般需要进行实时的监测，对数据的时效性以及准确性，要求相对比较高，对于时效性，基本要达到实时传输。因为实时传输经常会由于网络的问题，导致数据传输的错乱或者丢失，此时一般还需要引入离线机制进行数据的再传输，以保证数据的准确性以及完整性。

一般来讲，对于指标或者质量要求非常高的数据以及结果，一般采用离线传输和计算的方式，实时计算则提供具有指导意义的误差再可容忍范围之内的服务。

1.4解决方案示例

以畅思广告平台为例，如图2所示

图2 日志收集示意图

第一方和第二方数据。离线分析，采用批量传输和获取的方式进行数据收集;实时分析，则使用Flume进行数据的收集。第三方数据，则通过第三方可靠性存储作为媒介如阿里云、百度云、AWS等来进行中转，对于第三方需要实时获取信息的，则采用API的方式进行通信。

2 ETL

Extract-Transform-Load的缩写，在数据仓库中对数据进行抽取、转换、并加载到数据仓库中。其主要目的是对数据进行清洗，并按照预先定义好的数据仓库模型将数据进行规整化，以便进行后续的分析。

现在市面是流行的ETL工具代表有: Kettle，Talend，Informatica， Datastage等。但对于平台类的ETL，需要比较多的定制化操作，并且需要对数据进行特殊的解析或者映射，这些特殊需求导致上述的ETL工具使用起来比较麻烦。所以大家一般会自己进行ETL工具的定制开发。

2.1 ETL需考虑的因素

首先，确定数据仓库的模型。要从仓库的效率、兼容性、扩展性等多方面进行考虑。效率上考虑，把最经常使用或者分析的字段以单独列的形式设计到模型中，并对数据进行时时间片等维度的切分;兼容性方面则一般将字段的类型设置为字符串;扩展性方面，要保留足够的字段或者特殊的兼容性较强的字段供将来使用。

其次，要准备好ETL使用的存储以及计算框架。对于数据量较大的情况，建议基于Hadoop、Cassandra等文件系统进行存储，Pregel、Yarn、Mesos等分布式计算框架进行ETL的操作。

第三，存储的数据格式。使用原始的数据文件，还是使用压缩的格式;对于原始的文件，一般的分布式计算平台会自动进行切分，而对于部分压缩格式，则不支持文件的切分。这时候就需要在存储与计算效率之间进行折中，如果集群存储量有限，则使用压缩文件，但可通过自动切分文件然后压缩上传的方式来提高计算效率。

第四，ETL数据索引信息。需要提供外部的索引信息来指导分析人员进行数据的获取以及分析。一般采用的方式是在数据库中存储数据仓库各个分区的信息供分析人员查询。

2.2 畅思ETL

畅思的ETL主要是基于Hive，建立数据表，数据表中的各个字段是广告平台或者接入方数据映射之后的字段，并预留Map结构体字段满足将来的扩展需求。考虑到数据仓库纵向、横向分析的可能，对数据进行平台、时间、类型的切分。

在存储以及计算框架方面，选用的hadoop生态圈的相关实现。存储使用hdfs或者hbase，计算框架则采用Yarn。

存储的数据格式。目前压缩格式较多，例如gz, scrapy, lzo,bz2等，考虑到存储容量尤其是IO方面的需求，畅思对原始数据进行了最高级别的压缩，并通过对压缩数据分块来提高计算效率。而对于数据仓库中的数据，则采用lzo压缩，该压缩Mapreduce可进行自动切分。

数据索引信息。使用mysql进行索引的存储，并在全局记录数据仓库数据的开始结束时间。

3 BI任务调度系统

BI系统需要支持OLAP，提供复杂的分析操作，并提供直观易懂的查询结果，为决策提供支撑。如何从数据仓库中快速有效的分析提取结果，是任务调度系统需要解决的问题。

3.1 考虑因素

首先，以什么方式让分析人员调用。SQL的方式最为简洁，并且因为大家对关系型数据库比较熟悉，并且SQL在语法以及语意方面都比较完善，培训资料较多。分析人员可以以较小的代价入门。

第二，权限控制。对数据源、数据表等进行权限控制，防止用户越界访问。

第三，结果存储。存储要稳健，并且能提供高并发的读写请求。

第四，结果反馈。分析人员获取结果之后，以什么方式呈现给分析人员，出错之后如何处理。

第五，任务调度，“调度”最为重要，需要考虑任务是否需要周期性调度，并根据任务的优先级、任务等待的时间等因素考虑任务调度的顺序。

3.2 畅思任务调度系统，如图3所示

图3 BI调度平台系统

畅思调度平台以交互的方式提供任务提交功能。交互界面划分权限，用户通过界面操作将指定优先级及必须字段操作转化为以SQL命令为主的任务序列提请到任务后台。

在任务调度方面，通过任务的优先级、调度周期等进行任务的分发，把不同的级别的任务分发到不同的消息队列中。任务执行端则从消息队列中获取执行任务。

任务调度的结果，则根据用户指定的方式进行存储或操作。如果指定为邮件发送，如果执行成功，则将结果以邮件的方式发送给配置的相关人员;如果是存储入库，则将结果存储到mysql，并根据需要加载到缓存，供后续分析或者展示。

4 可视化系统

可视化统除了提供报表的展示、导出等功能，还要提供多维度、同比、环比等对比分析功能。BI系统产生的结果，价值的体现很大程度上体现在可视化方面。最终的可视化版本需要与产品、运营进行需求调研之后，根据业务的实际需要，提炼需要展示的维度。