微信号:mtydev

介绍:猫友会官方公众号; 猫友会致力于帮助优秀的人才回来,帮助优秀的企业进来,最终改变武汉互联网行业环境

卷皮的大数据之路

2017-04-19 12:44 光谷猫友会

猫友会希望建立更多高质量垂直细分社群,本次是"大数据学习交流付费群"的第一次分享。


“大数据学习交流付费群”由猫友会联合,斗鱼数据平台总监吴瑞诚,卷皮BI技术总监柴楹,盛天网络大数据平台负责人王欢发起,希望带动武汉的技术分享氛围, 欢迎大家加入!文末有入群方式





大家好,我是卷皮的BI总监柴楹,今天给大家分享一下卷皮的大数据之路。简单来说就是踩过的一些坑。因为我们需要站在巨人的肩膀上看问题,虽然我们卷皮现在还算不上巨人,但是在折扣电商行业目前做得还不错,那么我们的数据团队随着公司的成长而踩过的坑,也应该是各位能够吸收的经验,从而降低一点各位在大数据的路上走弯路的几率。

言归正传,我今天主要讲两个方面的内容:

1、卷皮技术架构的演进之路

2、卷皮的数据产品之路

首先是,卷皮的大数据平台架构演进之路,我们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都增加了

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

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

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

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

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

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


 
光谷猫友会 更多文章 猫友会直播|硅谷工程师对话光谷工程师系列之一“揭开神秘面纱” 武汉精英企业技术峰会|北京小聚,8号见! 武汉精选招聘|绿盟科技 武汉最全、最具潜力的互联网公司整理 斗鱼大数据的玩法
猜您喜欢 细谈产品"返回原地"设计 编写属于你自己的R函数 ~~~~~~圣诞夜惊喜~~~~~~ 『面向对象』征友活动:10 位对 IT 男有意向的单身妹纸 基于Redis的分布式锁到底安全吗(下)?