唯品会媒体营销策略研究论文

需要给你做吗

一、唯品会大数据平台规划和现状 这是唯品会大数据平台一个中长期的规划。目标很明确，我们希望从技术上能把整个大数据做成一个包含离线计算平台、流式计算平台、模型训练平台、VRE、 DMP和多种应用的完整生态链，并且希望通过这个平台，让我们公司的分析师、开发人员可以很简易地运用起来。 这是唯品会大数据平台的现状，总体和上面的规划图类似，重点在于离线平台的搭建，目前离线计算平台也已经做得差不多了。我们现在有一套很完整的数据开发平台，可以让公司的分析人员在不需要任何培训的情况下，方便地利用这个系统去挖掘大数据中的各种知识，为业务服务。除此之外，我们也有很多产品，看到图中数据产品一块，有情报中心、比价、选品、数读、魔方罗盘、仪表盘等。 二、大数据中的资源管理 大数据管理本身是一个很广的概念，涵盖了很多知识面。但资源管理是今年让唯品会特别难受的一个点，很多工作人员经过长时间的不眠不休，才最终把它解决掉。所以今天我会把资源管理作为重点，单独拿出来分享。 这里的“数据平台使用申请”打了引号，我想说的是这个“平台使用申请”在初创公司或者建设数据平台的初期，一般是很难做到这么完善的。因为我们需要用户提交很多要求，而且这些要求是明确的，包含了比如我需要什么样的资源，HDFS的存储、数据库、计算都需要多少，资源的数目是多少，要通过什么方式去访问。拿到这个申请以后，管理员会负责去分配同样的资源，比如HDFS中分配多少资源给你使用，Hive也是，如果我想要这样一个资源分配队列，需要明确分配给你的最大/最小资源是多少。 当然，这是一个理想的情况，现实却很骨感。因为这个行业的发展非常快，相信很多做大数据的同学，很多时候你是被业务和领导推着向上的，所以这时你的思考可能不是很完善，你会发现，你的理想状态是系统很强大、数据规范、流程规范、技术成熟、业务成熟，但现实呢？唯品会在半年前也是这种现状：模型的变更非常迅速，线上的那些代码实际上是我们的人员按小时为单位去做变更的。用户的能力参差不齐。有很多的历史包袱，唯品会的数据平台其实四年前就开始搭建了，其中有三年的历史包袱。同时，有大量的技术包袱，而且平台非常不稳定，掌控力差，有各种各样的瓶颈。整个大数据平台的分层也不是很明确。这是我们面临的现实。 那么，这种情况下，维护人员或者像我们这样的技术架构人员就会经常接到用户各种各样的投诉和问题。这里我列了一些用户经常会抱怨的问题： 这个任务昨天还好好的，为什么今天跑不出来了？ 2-10倍的数据量，能撑得住吗？ 怎么几千个任务都慢了？ 最近磁盘使用率急剧增加，谁在用？ 这个表好像不用了，我能删除掉吗？ 集群要扩容吗？扩多少? 当你在没有足够能力应付的情况下，面对这些问题，你是一筹莫展的。而由此也引申出今天的核心议题——资源管控。 三、资源管控中的存储资源和计算资源 做运维、DBA，或者大数据管理人员，都需要了解一个核心，那就是资源管控。做资源管控，其实和分田到户是同样的道理。当把一块田交给你，那你就在这块田里自己玩，不要到别人的田里去掺和。通过资源管控，可以实现很多目的： 从乱序到有序。 申请和分配有据可查。 规则公开透明。 数据公开透明。 有多少资源，干多少事。 有合理的KPI和惩罚机制。 ROI，资源倾斜给回报率高的项目。 以Hadoop为例。Hadoop平台是大家都在用的一个技术框架，它有哪些资源呢？总的来说，有四个模块：计算资源、存储资源、权限资源、业务资源。今天我会重点讲右侧的计算资源和存储资源。 为什么存储和计算需要关注？ 首先是NameNode。NameNode在Hadoop中相当于一个技术的管理节点，我们平台目前已经存储2亿的文件超过2亿的blocks，现在NameNode的内存使用在100G左右。在这么大的一个集群规模情况下，会遇到很多问题。 standby namenode updateCountForQuota缓慢影响主从一致性，进而影响切换（HDFS-6763） standby checkpoint缓慢导致增量blockreport汇报被skip, 影响主从一致性，进而影响切换（HDFS-7097）standby checkpoint GC导致transfer Fsimage超时失败这里列了几个问题点，都在社区被不少人提出来，我们也确实受到了影响。其中，最重要的是集群启动时，规模越大，你的启动时间可能越慢，除非你把这部分的代码全部进行重构。举个例子，可能我们的集群重启需要30分钟，因为需要每个block去上报。另外，第二个瓶颈就是资源管理，叫做ResourceManager，这也是Hadoop中的一个技术组件。唯品会现在的规模并行度是高峰期可以有一千个任务在跑，每天有将近40万的任务提交到Hadoop集群里，基本24小时内时时刻刻都有人在运行。因为现在的电商，包括现在的大数据已经不是以前那种玩法，不是你晚上跑个批处理，事情就做完了。现在大家的要求是，你能不能5分钟内跑出来，所以我的批处理在上面可能是5分钟一个力度去提交的，所以这个集群对我们来说已经不是夜间作业的集群，而是24小时专机，永远不能宕机的一个服务。部分解决问题 our patch for fairscheduler这里也列了两个问题，就不展开讲了，关键是第二个，我们提交给社区的补丁。这些问题社区还没有解决，我们这个补丁也还没有打到任何社区的版本里去，但是如果当你的集群规模非常大，运行HDFS时肯定会遇到和我们同样的问题——分配能力有瓶颈。目前我们通过这个补丁，分配能力提升到了近10-15倍。这其实很夸张，我们一直考虑的是，现在已经有几百台节点了，那能不能变到几千台？如果分配这个问题不解决，你的瓶颈永远卡在那，即使再加机器，管理也会因为瓶颈上不去，无法提升到几千台这样的规模。前面讲到了很多问题，怎么解决呢？开源节流。分两块，一块要提升各方面主机的性能，图中列出来的，包括了NameNode RPC性能、yarn的container assign性能，以及加机器。另外一块，就是要做各种优化管理。大家想，原先你就有几百个用户在用，当开放出去后，随着大数据应用的发展，不断有人去用，久而久之就会变成上万个用户在用。这时，你的存储是否被有效地利用呢？是否都是有价值的数据放在上面呢？你的计算是否都是有效的计算呢？还有人在用这样的一个任务吗？管理数据化成果给大家看一下我们在这一块的成果。理念很简单，就是做一个闭环。把整个数据仓库和Hadoop做成一个闭环，大家可以看到内圈，其实就是正常开发的一个数据仓库，你会建立任务、执行、下线，这是一个循环。而外循环是从整个任务建立时就开始对它进行管理，当你任务申请好之后，你会分配到一个队列，查看你的每一个日志。存储和计算会告诉你用了多少，同时还可以做一些智能的分析。在你的任务执行完之后，可以在系统里面看到任务的整个生命周期运行情况。基本上我们就是把整个大数据分到项目，分到人，分到数据库，分到几个任务，所有的指标都可以可视化地让你看到，也就是说，即使你只是简单地在系统里提交了一个SQL，可实际上你得到的是一个可视化、数据化的成果。你可以知道，今天我提交了多少个SQL，占用了多少资源，剩下多少文件，所有这些东西在系统里都可以看到。这样数据分析师也能主动跟你讲，今天慢了可能是因为提交的任务太多，今天提交的任务比上周多了一倍。你也能主动地在系统里找，为什么多了一倍？什么样的任务最占用资源？整个架构闭环大大降低基本架构技术人员的工作量。而当我们所有的数据都开放给数据分析师时，他们又能通过这些数据去做一些自己的分析，这也是一个闭环的形成。对很多公司来说，通过构建闭环，这一块的工作效率将会得到很大的提升。接下来重点讲两块资源的管理。一块是存储的资源，一块是计算的资源。存储资源管理一般情况下，大家在Hadoop中都是用Hive这个数据库，它对应的是后端的一些一二三级目录等数据库和表的目录。我们要怎样获取这些数据呢？从我们的角度来说，我们也是数据分析人员，我们要做的东西和其他的分析师其实是一样的，只不过我们分析的对象是系统的性能数据。我们会想要获取各种各样的性能数据，同时，我们需要去计算这些性能数据，做多维度的各种计算，然后把它推出去给用户看。存储资源基本上就是通过这几大块来收集，左边是获取到的各种存储的信息，文件、表、数据仓库、ETL、Hadoop的日志……第二步是把它转化为Hive里计算的文件元数据信息、表元数据信息、调度任务元数据信息、路径访问信息，最后得到的产出通过各种维度的计算，可以得到：维度：包括分区、表、数据库、任务、业务、人、目录层级、时间等所有维度；指标：全量、增量、趋势、平均文件大小、最大文件大小、最小文件大小、文件数目、占比等；热度：哪些表被频繁访问？哪些表3个月没人访问，是否可以下线了？安全：有没有敏感信息被非法访问。通过这一系列的存储资源管理，可以把所有的关键信息收集起来。下面，讲一下这些数据的使用，这也是我们公司目前正在践行的：容量计费通过计费来控制资源，使存储数据完整透明。消费预警，会提前知会用户。空间管理自动配置生命周期管理规则；存储格式，压缩格式选择（orc+gzip）；文件管理自动配置生命周期管理规则；小文件har归档。控制存储的价值：一方面可以解决NN“单点”瓶颈，控制服务器的数量，降低成本。如果没有加以控制，很快你的规模就会变成几百、几千，逐渐失控。另一方面，规范数据生命周期管理，统计冷热数据的使用，区别哪些数据是能删的、哪些是能归档的、哪些是被频繁使用的，都可以通过这个手段反馈给ETL生命周期管理。计算资源管理 这是yarn的一个架构图。大家都知道yarn是Hadoop的一个统一的调度管理。但yarn好像把所有资源管理的事情都搞定了，我们还需要管理什么呢？实际上，还有很多没有解决的问题。

一、唯品会大数据平台规划和现状这是唯品会大数据平台一个中长期的规划。目标很明确，我们希望从技术上能把整个大数据做成一个包含离线计算平台、流式计算平台、模型训练平台、VRE、 DMP和多种应用的完整生态链，并且希望通过这个平台，让我们公司的分析师、开发人员可以很简易地运用起来。这是唯品会大数据平台的现状，总体和上面的规划图类似，重点在于离线平台的搭建，目前离线计算平台也已经做得差不多了。我们现在有一套很完整的数据开发平台，可以让公司的分析人员在不需要任何培训的情况下，方便地利用这个系统去挖掘大数据中的各种知识，为业务服务。除此之外，我们也有很多产品，看到图中数据产品一块，有情报中心、比价、选品、数读、魔方罗盘、仪表盘等。二、大数据中的资源管理大数据管理本身是一个很广的概念，涵盖了很多知识面。但资源管理是今年让唯品会特别难受的一个点，很多工作人员经过长时间的不眠不休，才最终把它解决掉。所以今天我会把资源管理作为重点，单独拿出来分享。这里的“数据平台使用申请”打了引号，我想说的是这个“平台使用申请”在初创公司或者建设数据平台的初期，一般是很难做到这么完善的。因为我们需要用户提交很多要求，而且这些要求是明确的，包含了比如我需要什么样的资源，HDFS的存储、数据库、计算都需要多少，资源的数目是多少，要通过什么方式去访问。拿到这个申请以后，管理员会负责去分配同样的资源，比如HDFS中分配多少资源给你使用，Hive也是，如果我想要这样一个资源分配队列，需要明确分配给你的最大/最小资源是多少。当然，这是一个理想的情况，现实却很骨感。因为这个行业的发展非常快，相信很多做大数据的同学，很多时候你是被业务和领导推着向上的，所以这时你的思考可能不是很完善，你会发现，你的理想状态是系统很强大、数据规范、流程规范、技术成熟、业务成熟，但现实呢？唯品会在半年前也是这种现状：模型的变更非常迅速，线上的那些代码实际上是我们的人员按小时为单位去做变更的。用户的能力参差不齐。有很多的历史包袱，唯品会的数据平台其实四年前就开始搭建了，其中有三年的历史包袱。同时，有大量的技术包袱，而且平台非常不稳定，掌控力差，有各种各样的瓶颈。整个大数据平台的分层也不是很明确。这是我们面临的现实。那么，这种情况下，维护人员或者像我们这样的技术架构人员就会经常接到用户各种各样的投诉和问题。这里我列了一些用户经常会抱怨的问题：这个任务昨天还好好的，为什么今天跑不出来了？2-10倍的数据量，能撑得住吗？怎么几千个任务都慢了？最近磁盘使用率急剧增加，谁在用？这个表好像不用了，我能删除掉吗？集群要扩容吗？扩多少?当你在没有足够能力应付的情况下，面对这些问题，你是一筹莫展的。而由此也引申出今天的核心议题——资源管控。三、资源管控中的存储资源和计算资源做运维、DBA，或者大数据管理人员，都需要了解一个核心，那就是资源管控。做资源管控，其实和分田到户是同样的道理。当把一块田交给你，那你就在这块田里自己玩，不要到别人的田里去掺和。通过资源管控，可以实现很多目的：从乱序到有序。申请和分配有据可查。规则公开透明。数据公开透明。有多少资源，干多少事。有合理的KPI和惩罚机制。ROI，资源倾斜给回报率高的项目。以Hadoop为例。Hadoop平台是大家都在用的一个技术框架，它有哪些资源呢？总的来说，有四个模块：计算资源、存储资源、权限资源、业务资源。今天我会重点讲右侧的计算资源和存储资源。为什么存储和计算需要关注？首先是NameNode。NameNode在Hadoop中相当于一个技术的管理节点，我们平台目前已经存储2亿的文件超过2亿的blocks，现在NameNode的内存使用在100G左右。在这么大的一个集群规模情况下，会遇到很多问题。standby namenode updateCountForQuota缓慢影响主从一致性，进而影响切换（HDFS-6763）standby checkpoint缓慢导致增量blockreport汇报被skip, 影响主从一致性，进而影响切换（HDFS-7097）standby checkpoint GC导致transfer Fsimage超时失败这里列了几个问题点，都在社区被不少人提出来，我们也确实受到了影响。其中，最重要的是集群启动时，规模越大，你的启动时间可能越慢，除非你把这部分的代码全部进行重构。举个例子，可能我们的集群重启需要30分钟，因为需要每个block去上报。另外，第二个瓶颈就是资源管理，叫做ResourceManager，这也是Hadoop中的一个技术组件。唯品会现在的规模并行度是高峰期可以有一千个任务在跑，每天有将近40万的任务提交到Hadoop集群里，基本24小时内时时刻刻都有人在运行。因为现在的电商，包括现在的大数据已经不是以前那种玩法，不是你晚上跑个批处理，事情就做完了。现在大家的要求是，你能不能5分钟内跑出来，所以我的批处理在上面可能是5分钟一个力度去提交的，所以这个集群对我们来说已经不是夜间作业的集群，而是24小时专机，永远不能宕机的一个服务。部分解决问题 patch for fairscheduler这里也列了两个问题，就不展开讲了，关键是第二个，我们提交给社区的补丁。这些问题社区还没有解决，我们这个补丁也还没有打到任何社区的版本里去，但是如果当你的集群规模非常大，运行HDFS时肯定会遇到和我们同样的问题——分配能力有瓶颈。目前我们通过这个补丁，分配能力提升到了近10-15倍。这其实很夸张，我们一直考虑的是，现在已经有几百台节点了，那能不能变到几千台？如果分配这个问题不解决，你的瓶颈永远卡在那，即使再加机器，管理也会因为瓶颈上不去，无法提升到几千台这样的规模。前面讲到了很多问题，怎么解决呢？开源节流。分两块，一块要提升各方面主机的性能，图中列出来的，包括了NameNode RPC性能、yarn的container assign性能，以及加机器。另外一块，就是要做各种优化管理。大家想，原先你就有几百个用户在用，当开放出去后，随着大数据应用的发展，不断有人去用，久而久之就会变成上万个用户在用。这时，你的存储是否被有效地利用呢？是否都是有价值的数据放在上面呢？你的计算是否都是有效的计算呢？还有人在用这样的一个任务吗？管理数据化成果给大家看一下我们在这一块的成果。理念很简单，就是做一个闭环。把整个数据仓库和Hadoop做成一个闭环，大家可以看到内圈，其实就是正常开发的一个数据仓库，你会建立任务、执行、下线，这是一个循环。而外循环是从整个任务建立时就开始对它进行管理，当你任务申请好之后，你会分配到一个队列，查看你的每一个日志。存储和计算会告诉你用了多少，同时还可以做一些智能的分析。在你的任务执行完之后，可以在系统里面看到任务的整个生命周期运行情况。基本上我们就是把整个大数据分到项目，分到人，分到数据库，分到几个任务，所有的指标都可以可视化地让你看到，也就是说，即使你只是简单地在系统里提交了一个SQL，可实际上你得到的是一个可视化、数据化的成果。你可以知道，今天我提交了多少个SQL，占用了多少资源，剩下多少文件，所有这些东西在系统里都可以看到。这样数据分析师也能主动跟你讲，今天慢了可能是因为提交的任务太多，今天提交的任务比上周多了一倍。你也能主动地在系统里找，为什么多了一倍？什么样的任务最占用资源？整个架构闭环大大降低基本架构技术人员的工作量。而当我们所有的数据都开放给数据分析师时，他们又能通过这些数据去做一些自己的分析，这也是一个闭环的形成。对很多公司来说，通过构建闭环，这一块的工作效率将会得到很大的提升。接下来重点讲两块资源的管理。一块是存储的资源，一块是计算的资源。存储资源管理一般情况下，大家在Hadoop中都是用Hive这个数据库，它对应的是后端的一些一二三级目录等数据库和表的目录。我们要怎样获取这些数据呢？从我们的角度来说，我们也是数据分析人员，我们要做的东西和其他的分析师其实是一样的，只不过我们分析的对象是系统的性能数据。我们会想要获取各种各样的性能数据，同时，我们需要去计算这些性能数据，做多维度的各种计算，然后把它推出去给用户看。存储资源基本上就是通过这几大块来收集，左边是获取到的各种存储的信息，文件、表、数据仓库、ETL、Hadoop的日志……第二步是把它转化为Hive里计算的文件元数据信息、表元数据信息、调度任务元数据信息、路径访问信息，最后得到的产出通过各种维度的计算，可以得到：维度：包括分区、表、数据库、任务、业务、人、目录层级、时间等所有维度；指标：全量、增量、趋势、平均文件大小、最大文件大小、最小文件大小、文件数目、占比等；热度：哪些表被频繁访问？哪些表3个月没人访问，是否可以下线了？安全：有没有敏感信息被非法访问。通过这一系列的存储资源管理，可以把所有的关键信息收集起来。下面，讲一下这些数据的使用，这也是我们公司目前正在践行的：容量计费通过计费来控制资源，使存储数据完整透明。消费预警，会提前知会用户。空间管理自动配置生命周期管理规则；存储格式，压缩格式选择（orc+gzip）；文件管理自动配置生命周期管理规则；小文件har归档。控制存储的价值：一方面可以解决NN“单点”瓶颈，控制服务器的数量，降低成本。如果没有加以控制，很快你的规模就会变成几百、几千，逐渐失控。另一方面，规范数据生命周期管理，统计冷热数据的使用，区别哪些数据是能删的、哪些是能归档的、哪些是被频繁使用的，都可以通过这个手段反馈给ETL生命周期管理。计算资源管理这是yarn的一个架构图。大家都知道yarn是Hadoop的一个统一的调度管理。但yarn好像把所有资源管理的事情都搞定了，我们还需要管理什么呢？实际上，还有很多没有解决的问题。