首先是，卷皮的大数据平台架构演进之路，我们BI部门是14年8月才成立的，当时只有两三个人，到目前已经五十多人了。那么随着公司业务的发展，我们的平台架构主要经历三个阶段，每个阶段有每个阶段的特点，下面我来一一介绍。

初代架构很简单，当时卷皮还处于导购阶段，公司的数据需求主要就是流量相关的报表。所以我们的架构主要是在处理我们两个PC站点的流量数据。

用户的点击数据通过埋点的JS发送到sermon中，sermon是kafka的生产者，接收到埋点的数据就直接写入kafka。这一部分是一天24小时都在接收的。然后每天凌晨，我们才会把kafka中的数据消费到hadoop集群，进行计算，最终落地到mysql进行界面展示。

初代架构我们用了hadoop,kafka,mysql，还有阿里开源的调度系统zeus。这些所有的组件都是部署在5台物理机器上面，东西都是耦合在一起的，这么小而紧凑的架构也能支撑基本的数据分析业务，且充分压榨了硬件资源，降低成本，所以这种架构特别适合初创公司。

总结一下初代架构的四点经验：

1、 我们选用了Cloudera的hadoop版本，因为Cloudera和Hortonworks、MapR一起被称为大数据基础架构工具的三架马车，可以帮助企业快速安装，配置，运行hadoop和其周边生态系统，降低公司技术成本。

Cloudera的组件安装，横向扩展，配置变更等都通过web界面完成，无需进行命令行操作。Cloudera不仅对日志进行了自动切分，且在web界面可以对日志进行查看和搜索。Cloudera通过修改Hadoop等开源组件源码进行监控埋点，对于各项服务、角色都实现了详细的监控。Cloudera版本升级提供了多种方式，包括一键升级这种傻瓜升级方式，不过生产环境须慎用。

2、 Kafka的使用问题性能问题：初期对Kafka不熟悉，性能优化不够前端雪崩效应导致Kafka崩掉，后来通过合理的硬件配置，服务端配置以及客户端参数优化等方式进行了优化。主要是优化内存的使用。带宽问题：MR程序由于是离线消费，并且每次都是全量的，对网卡带宽压力很大，但是这个也和partition设计有一定关系。设计问题：初期Topic和Partition设置随意，导致热点现象比较严重，后续结合业务，对topic和partition进行合理设计，达到了多节点的负载均衡。

3、 ZEUS关于作业调度，我们调研了例如Oozie, Azkaban等多种调度框架，但是我们最终选择了Zeus，这和我们的架构哲学有关，我们选择架构只要简单，够用就行了，太复杂的不适合我们，太笨重的也不行，从这些方面来说，Zeus比其他两个都要做得好。

4、 数据质量问题，我们通过建立全阶段的数据监控和检查，确保了BI数据质量。数据源质量把控：搭建埋点测试环境，发版前进行埋点数据测试。编写自动化测试脚本，对已上线的埋点数据进行验证。重要作业调度监控：作业执行时间过长或者延迟报警。核心数据质量检查：对关键作业输出数据进行检测，进行阻断或报警处理。

最开始很多东西都是第一次来重头搭建，所以也确实遇到了很多坑，所以总结得有点多。

然后进入第二代架构：

这个要结合一下业务，2015年3月卷皮做了两个转型：第一，从pc转型到app。第二，业务从导购转型到特卖。业务变了，那么数据的需求也就升级了，除了原来的流量的数据，现在还有很多订单的数据需求。主要的就是数据源就增加了。所以这一个阶段，我们主要多了从mysql中抽取数据，这里我们引入了阿里开源的datax和otter。

从mysql业务库抽取的数据会被上传到hadoop中进行计算，这部分主要是离线的业务。大家还会看到有一部分实时的数据会直接经过存储过程的计算进入DW和RPT。这主要是当时对于实时的需求就是实时销售的报表，所以用存储过程是完全可以满足的。流量的数据基本不变，mysql中的数据会被抽取到hadoop中进行计算，最终放入hbase或者mysql中。因为当前关系型数据库中的数据量也还不够大，我们的数据仓库在mysql和hadoop中都有一份。

但是随着业务数据量的增加，在15年下半年我们最终将DW全部迁移到了Hive上。

总结一下我们二代架构做的事情：其实主要有三个：

第一是ETL工具扩展，例如为了满足关系型数据库实时的抽取引入otter，otter是直接读取mysql的binlog来同步数据的开源工具，所以同步数据的时候是不影响业务库的；

第二是架构分层，这一阶段我们把架构分层，进行物理机解耦，数据接收层，数据计算存储层，服务层等等；

第三是数据分层，用数据仓库的思想来划分相应的ODS层，DW层和RPT层，这个阶段还没有datamarket这一层；

我们再来看下我们的第三代架构，差不多就是我们目前的架构。

首先数据源我们还增加了爬虫爬取的数据，还有我们其他业务部门的日志文件；存储层也引入ES和redis。例如es是用在ELK日志系统的，redis用在我们的风控系统；计算层，离线计算依然是hadoop为主，但是实时计算引入了spark和storm。还有一个，在计算这里我们还引入了Kylin预计算，为OLAP服务；其他的还有数据服务层：BI数据统一通过接口服务层进行调用，隐藏底层数据源细节监控平台：搭建统一业务监控平台，对大数据各项业务进行监控。

其实整体的架构和上次吴瑞城分享的都差不多，我们运用的开源框架都差不多，所以其实都是大同小异。

但是我们还做了一件事就是基于目前的架构做了一个开放平台，这个开放平台类似与阿里的ODPS，主要是开放数据仓库和大数据平台的资源各团队的人使用。这个和我们部门的策略也有关系，大数据BI部门不能一直是一个做报表的部门，我们更应该去挖掘数据的价值，把数据变现。所以我把平台开放给各业务部门，他们可以自己来拿到自己的数据，当然一些权限和审计的工作要做好。然后BI部门可以去做给公司带来价值的数据产品。

三个阶段介绍完了，总结一下

所以卷皮的大数据平台架构三个阶段的特点就如PPT写的，初期小而紧，中期分层&解耦，后期面向服务&开放。

如上这些词，也是我们卷皮大数据平台架构的设计哲学。

我们这里面虽然可能技术人员偏多，但是对于产品对于产品的推进方法还是要了解一些的。

首先介绍一下卷皮的数据体系，这个是产品体系的根本。

BI的数据体系有四层：

第一层是基础平台，包括BI所有的数据的接入，加工等等；

第二层是数据服务，提供报表、OLAP分析系统、自助取数平台等等；

第三层是智慧运营，主要是把数据以数据产品的方式渗透到业务部门的日常工作中；

第四层是决策支持，当然，决策支持可以说是在数据服务层和智慧运营层都在做，因为也是以数据支撑每一个小的业务的决策。但是这里的第四层的决策更多的支撑重大决策为主。

举个例子：区域策略扩张，仓库选址，新业务模式探索等等

BI的产品主要有两条线：

1、智慧运营类：主要是将数据渗透到公司运营的每一个环节中去，辅助运营人员能够更加好的做好运营工作；是对用户和商家

2、数据服务类：支撑公司内所有的数据服务，数据需求；从最基础的体系是这么设计的，但是数据产品真的那么好推进吗？

其实是难上加难的。对于数据服务类，你推出去，报表业务部门看不看，OLAP系统人家用不用？对于辅助运营的工具，对方是否配合你，协助你回收数据，进行下一轮的模型优化？在整个过程中，其实遇到的坑不比架构少。

野蛮生长阶段，业务就是抢市场，固有的经验就可以保证业绩的增长（招两个客服或者运营人员干活，比招个技术人员还便宜），产品和技术人员并不是完全的懂业务，没有找到痛点，产品规划做出来的东西伪需求，业务不爱用。技术没有承担业务KPI，尝新的方式害怕影响业绩，不是同一利益共同体，业务部门也就不带你玩了。

最后，数据产品的推出是和公司本身人员的数据化运营能力息息相关的。你跑慢了，人家要看数据你给不了。但同时你跑得太快，人家根本不知道你给他的工具怎么用，因为对数据的解读能力还不足够。

举个例子：貌似健身的私教现在普及，但是原来并不普及，但是随着经济水平的提高和人们健康的意识提升，越来越多的白领接收私教，这在前几年，大家并不一定愿意花钱的。

其实就是一个适当的时机的问题，所以就我推进的总结来说

数据产品的推进也是有三个阶段：

1、给你所需工具化，辅助运营提升数据感知的能力，能够看到想要看的数据（报表，商品的，用户的占比等等，OLAP自助分析），给你看到你所有想看到的数据情况，便于运营人员总结运营经验；

2、对于一些经验进行数据建模，降低工作量提高工作效率，经验模型化，建立合作信任感；

3、.通过分析挖掘数据做到更多，例如运营策略的补充，通过数据导向，以目标为导向 ,和业务部门一起来承担KPI，向前探索式的推进数据产品；

下面举两个例子来说明一下这个方法论：

例如我们的分群运营：

第一个阶段我们只是提供基础的数据报表，给运营人员看到想看的数据；

第二阶段，我们把他们的运营经验模型化，例如对于新客如何安排商品排序，对于老客如何排序等等，那么原来他们手工做的工作就完全可以由程序来完成，大大提高他们的效率；

第三各阶段，运营人员自身也不清楚应该怎么玩才能增长业绩的时候，他们就要求助数据了，我们就要共同去探索如何精细化运营，我如何把人群分的更细，例如这个阶段我们通过数据发现我们平台母婴用户的占比还不错，那么我把这部门用户抓出来，然后针对性的商品流排序，转化率和GMV都增加了

第二个例子是从商品端来看：

第一阶段我们依然只是给了报表，因为业务在野蛮增长，我只要有商品就有得卖，业绩就在涨；

第二阶段，我们提供了货品结构分析这种工具，例如一个鞋子的档期里面凉鞋和单鞋的比例，夏季转秋季时，应该凉鞋减少，单鞋增多，这就是运营的经验，那么原来人工检查的或者人工运营经验不足的，通过这个工具就能够发现，从而提高他们的工作效率；

第三个阶段，目前我们在做的就是引入竞品数据，进行销量预测，这样辅助运营能够选择更好卖的商品等等；

当然我讲得更多的是贴合我们卷皮电商业务的例子，希望大家能够理解，所以推进数据产品主要就是我说的那三个阶段和那些坑，希望群里有产品狗，能够有所感触。

关于架构演进，关于数据产品推进，卷皮的大数据之路就是这样。谢谢大家！