这是一个创建于 2567 天前的主题，其中的信息可能已经有所发展或是发生改变。
大家好，我是卷皮的 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 都增加了
第二个例子是从商品端来看：
第一阶段我们依然只是给了报表，因为业务在野蛮增长，我只要有商品就有得卖，业绩就在涨；
第二阶段，我们提供了货品结构分析这种工具，例如一个鞋子的档期里面凉鞋和单鞋的比例，夏季转秋季时，应该凉鞋减少，单鞋增多，这就是运营的经验，那么原来人工检查的或者人工运营经验不足的，通过这个工具就能够发现，从而提高他们的工作效率；
第三个阶段，目前我们在做的就是引入竞品数据，进行销量预测，这样辅助运营能够选择更好卖的商品等等；
当然我讲得更多的是贴合我们卷皮电商业务的例子，希望大家能够理解，所以推进数据产品主要就是我说的那三个阶段和那些坑，希望群里有产品狗，能够有所感触。
关于架构演进，关于数据产品推进，卷皮的大数据之路就是这样。谢谢大家！
大家可以添加小猫助手，加入猫友会交流群（微信：maoyouhui-xxm,备注：姓名—技术方向—来源）
言归正传，我今天主要讲两个方面的内容：
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 都增加了
第二个例子是从商品端来看：
第一阶段我们依然只是给了报表，因为业务在野蛮增长，我只要有商品就有得卖，业绩就在涨；
第二阶段，我们提供了货品结构分析这种工具，例如一个鞋子的档期里面凉鞋和单鞋的比例，夏季转秋季时，应该凉鞋减少，单鞋增多，这就是运营的经验，那么原来人工检查的或者人工运营经验不足的，通过这个工具就能够发现，从而提高他们的工作效率；
第三个阶段，目前我们在做的就是引入竞品数据，进行销量预测，这样辅助运营能够选择更好卖的商品等等；
当然我讲得更多的是贴合我们卷皮电商业务的例子，希望大家能够理解，所以推进数据产品主要就是我说的那三个阶段和那些坑，希望群里有产品狗，能够有所感触。
关于架构演进，关于数据产品推进，卷皮的大数据之路就是这样。谢谢大家！
大家可以添加小猫助手，加入猫友会交流群（微信：maoyouhui-xxm,备注：姓名—技术方向—来源）
目前尚无回复
Select Language