从搭台到唱戏，电商卷皮BI的实践演进和架构体系

目前我们BI团队处于第三层阶段，正在推进各项智慧运营数据产品的建设。

接下来介绍一下我们卷皮BI的架构体系。我们主要有五大基础平台：

一、数据采集同步平台：负责接入所有的数据源，用户行为的数据是通过埋点直接生产到kafka，数据库之间的抽取用的阿里开源的datax，实时库的同步用也是阿里开源的otter，然后竞品数据是用爬虫平台采集来的。

二、实时计算平台：我们直接上的Spark Streaming，它直接去消费kafka中的数据。虽然Spark Streaming不是真正的流计算，而是高频率的批处理，没有storm的实时性好，但是目前秒级的延迟我们还是接受的，因为Scala语言开发起来更加简洁，而且Spark后续可以支撑更多，例如我们的挖掘就直接用的SparkR。其中还涉及一些内存计算我们用的是memcached和redis，实时数据计算的数据一般直接存储到hbase或者es里面，便于更快的检索。

三、离线计算平台：主要用的hadoop平台，Mysql里面有极少量的存储过程，当前DW全部都在HDFS上，Mysql更多存储的是为报表展示的数据集市类的表。

四、数据服务平台：主要是对外的平台，报表系统，即席查询，OLAP分析系统，数据分析和挖掘等，然后BI也会给公司其他业务研发团队提供各种数据支撑，统一都是走BI自己搭建的数据服务层。

五、运维监控平台：调度系统用的阿里开源的Zeus，然后针对我们自己的需求进行很多二次开发；日志收集分析用的ELK；监控平台负责BI这边所有的硬件软件还有数据质量等等监控；当然这里还要做BI的元数据管理。

???????这五大技术平台是BI的物质基础，基于这些物质基础，才能继续产出我们的上层建筑：数据产品。

我们BI的产品体系主要有两条线，也就是两只脚走路。

先说一下数据服务线的数据产品，这部分产品主要是支撑公司内所有的数据需求，满足不同层次的人看数据的需要。因为这个也是BI的基础，基本的数据服务你满足，后面业务部门才能配合一起做其他智慧运营的数据产品。智慧运营线主要想将数据渗透到公司业务部门人员工作的每一个环节中，辅助业务部门人员能够更加好的做好运营工作。具体的应用有精准化营销系统、个性化的推荐系统、鹰眼的反欺诈系统和智能选品系统等。

以上就是我们卷皮BI的数据、架构和产品的体系。

第一是用户画像。卷皮是电商平台，我们必须要充分的了解我们的用户，所以卷皮BI也基于自有的用户消费数据、行为数据，进行相应的算法模型去挖掘用户的特征，给用户打上各种标签。当然也接入一些外部的数据来验证我们的标签。目前的用户标签,主要分为四个方面：自然属性，兴趣偏好，消费特征，生命周期。

然后基于用户画像，我们团队的精准化小组，就在做以下三个方面的事情：

1.?精准的营销：通过精准的push提升用户到达率；针对不同群体用户做专题活动；对于濒危用户进行挽留等等。

2.?个性化的推荐：业内所说的千人千面，每个人专属的商品的排序；其他的推荐场景，例如猜你喜欢和热门推荐。但是对于第一次来的用户，没有任何行为信息，更多以热门推荐为主。目前我们也在做基于用户实时的浏览行为，进行实时的商品推荐。

3.精准的服务：对于不同会员的等级进行差异化的服务，例如信用好的用户如果选择退货，那么我们可以先退钱后收货，但是对于信用等级不够高的用户，那么我们会收到货以后再退钱等；优化客服的服务，对于接入的客户，更加了解客户的信息，便于提高服务质量。

第二个，就是我们的鹰眼系统，也就是反欺诈系统。目前定位是主要是实时的甄别异常订单。鹰眼系统主要做两方面的事情，识别坏人和识别坏事。目前我们的鹰眼系统一共有4个子系统：鹰眼马甲系统、鹰眼售后系统、鹰眼订单甄别、鹰眼诚信系统。

鹰眼系统的核心模块是BRMS(业务规则管理系统)，基于规则引擎(Drools)。工作人员可通过Web?UI制定规则，形成规则库，每个规则都有个阈值。实时的数据结合数据集市的历史数据，在规则引擎里面进行判断，如果超出的规则的阈值，则进行相应的操作，如告警，转人工审核等。

鹰眼的WebUI是我们自己开发的界面，便于我们的业务运营人员，基于一些现有的指标来配置规则，调整阈值。JP-drools是在drools 我们在外面封装了一层，主要是为了做到分布式部署、历史库共享和规则的热部署。

最后这个产品是OLAP分析系统，图片是一个截图，左边这边有维度和度量，通过拖拽到中间的行或者列进行生成相应的表格，右边可以把表格的数据变成各种图形。业内这种类型的分析工具其实比较多，例如Microstrategy，Tableau等。但这些都是商业的，我们更多还是基于开源来做。

我们主要用了如下几个开源的项目：

Saiku提供了一个多维分析的用户操作界面，可以通过简单拖拉拽的方式迅速生成报表，它的主要工作是根据事先配置好的schema，将用户的操作转化成MDX语句提供给Mondrian引擎执行。

Mondrian是一个OLAP分析的引擎，主要工作是根据事先配置好的schema，将输入的多维分析语句 MDX (Multidimensional Expressions )翻译成目标数据库／数据引擎的执行语言（比如SQL）。

Presto是一个分布式SQL查询引擎， 它被设计为用来专门进行高速、实时的数据分析。它支持标准的ANSI SQL，包括复杂查询、聚合（aggregation）、连接（join）和窗口函数（window functions)。

当前这个架构是我们第三个版本的架构。

第一个版本我们是直接用的Mondrian+Mysql，但是我们发现Mondrian的界面太丑了，所以在第二版加入了Saiku。但是随着业务数据量的增加，Mysql的查询性能很快就到瓶颈了，所以在第三个版本用Presto替代了Mysql。

在这套架构里面Saiku提供了界面的支持，Mondrain提供了schema到MDX的转换，并构建SQL语句，向Prestodb查询数据，Prestodb执行查询任务，返回其结果，Saiku显示结果，输出报表。整个OLAP系统我们需要关注Saiku的二次开发，Mondrain schema.xml生成及其读取数据和维表方面的优化。

但是当前这个架构目前也逐渐遇到瓶颈，对于像具体到每一个用户成单路径的数据的分析时候查询还是需要比较久的时间，所以我们现在依然在调整，希望把kylin加入进来。

kylin是apache软件基金会的顶级项目，一个开源的分布式多维分析工具。Kylin通过预计算所有合理的维度组合下各个指标的值并把计算结果存储到HBASE中的方式，大大提高分布式多维分析的查询效率。Kylin接收sql查询语句作为输入，以查询结果作为输出。对于可以离线分析的业务数据，可以用kylin的框架，而对于实时分析的业务数据还是可以用来Presto支持。

以上就是我们卷皮BI的一些经验的分享。最后送给大家一句话：数据本身不是最终价值，带有分析的数据，渗透到业务中，影响到决策才产生价值。

Q1：查询HBase中的数据有没有用什么SQL引擎呢？有的话用的是什么SQL查询引擎？

A1：我们没有用什么SQL引擎，我们主要是靠row-key的设计。

Q2：hadoop平台的部署是通过？ ambari这些吗？

A2：我们使用cloudera的版本的。

Q3：老师好，能否大概讲解一下怎么根据用户画像做推荐，这里面用到什么技术点。

A3：主要还是数据挖掘的算法，有聚类，协同过滤，商品相似度之类的算法，不过针对不同的业务场景使用的算法不一样。技术上，我们是用的sparkR。

Q4：我们现在olap目前正在使用apache kylin,saiku和kykin结合怎么样，有过调研没？

A4：Saiku直接+kylin我们还没有用过，不过应该是OK的，因为saiku主要是界面展现。

Q5：BI挖掘的用户画像和鹰眼系统，有什么离线指标来评价相关的数据质量？

A5：类似用户画像的性别，主要看两个方面，覆盖率和准确率，覆盖率提升了，也许准确率就会下降，后续我们可以持续跟踪用户的行为，或者进行一些实际的回访，来验证并优化我们的数据模型。鹰眼更多的是基于规则引擎做的。

Q6：数据meta管理是怎么做的？

A6：业务上我们对所有的数据指标口径进行统一，所有展示数据的地方都是一致的，然后对于变更等等流程都有一定的管理。

大数据杂谈?