作为生意参谋联合Quick BI的初次尝试， “自助分析”面向店铺提供自助分析解决方案，支持店铺个性化数据报表制作，同时支持长周期的数据存储和分析，形成店铺专属的数据监控和分析看板，以帮助店铺提升经营效率。

“自助分析功能让店铺的数据统计与分析变得更加简单，” 厨房里的阿芬天猫旗舰店运营负责人宋福翔告诉记者，“过去需要花费1小时完成的数据统计分析工作，现在1分钟就能轻松搞定。”

生意参谋全新功能“自助分析”可自定义搭建多维数据报表

被数据拨正的参考主义 

宋福翔负责的天猫旗舰店“厨房里的阿芬”，今年六月才将目光从调味品类转向方便速食市场，目前还处于“万事开头难”阶段。

“过去，店铺一个月能有过百万的销售额，但现在一切得从0开始。”在谈到店铺转型后的销售额时，宋福翔带了些自嘲的意味，但并不是很担心现阶段的“阵痛”。

在宋福翔和团队看来，目前方便速食各品类都进入了产品重新定义、消费新一轮升级的阶段，特别是自热饭细分领域，线上市场已经初具规模，头部效应明显，“对新进入赛道的品牌来说，想要迅速起量就需要有更多不一样的抓手和推广策略。”宋福翔介绍。

然而，中式餐饮的方便熟食口味繁多，团队初期缺乏数据沉淀，只能依赖品牌定位、竞品分析和线下餐饮口味推荐来做参考，宋福翔表示，“我们将目标市场定位在一二线城市白领人群，区分现有自热米饭主流的偏重口味产品，希望以偏咸鲜口精华浓缩“捞汁”为特色的品质捞饭去细分市场，打开局面。 ”

今年天猫618消费季期间，包括迎合大众市场口味的“台式卤肉”“麻辣牛肉”，以及创新口味“鲍鱼”“花椒鸡”共四款口味捞饭商品正式上线。

第一批商品面世没多久，生意参谋就为团队带来了惊喜的商品数据反馈。宋福翔告诉记者，“数据显示，整个6月，虽然鲍鱼、花胶鸡捞饭的客单价相对比较高，但在首轮尝试过程中复购也更高，这两款产品还在多场以单口味形式的直播中被消费者要求返场。”

通过生意参谋，运营团队可以实时查看店铺整体经营数据，同时针对各个商品也能即时调用包括流量、曝光、咨询、成交、售后等整个生命周期的多维数据，依据这些数据，目前厨房里的阿芬已经开始重新梳理店铺SKU策略，并即将推出应季新品“蟹黄风味自热捞饭”，为下半年店铺的持续发力做足准备。

生意参谋数据洞察助推应季新品“蟹黄风味自热捞饭”

自助分析助力店铺经营 1分钟搞定数据分析

厨房里的阿芬天猫旗舰店的成功转型，让宋福翔更加意识到数据对于商品乃至整个店铺运营的重要性。

接触电商第七年，宋福翔其实早早就知晓如何依靠数据去调整店铺经营策略，并养成了每天通过生意参谋查看店铺数据的习惯，“从店铺流量到商品推广，再到交易端、客户体验回评……通过生意参谋的不同模块去查看统计各个端口的数据，整个一套分析下来往往需要1个多小时。”

不久前，生意参谋“自助分析”功能正式上线，作为生意参谋联手阿里云数据中台核心产品之一Quick BI的初次尝试，“自助分析”功能集结了现阶段生意参谋关于店铺的多个维度数据，店铺运营人员在可视化的操作界面，可以同步查看包括店铺流量、商品流量、跳失率等在内的100多个数据指标，并可即时调用，形成满足自身需求的数据报表。

宋福翔表示，过去需要在生意参谋不同模块进行对应数据查看和统计，但现在都能够在“自助分析”中一键选中自定义生成，“对于我们店铺运营者来说，以往需要花1小时完成的工作量，现在基本上1分钟左右就能完成，而且数据统计结果更加准确明了。”

同时针对初次接触报表搭建的店铺运营新手，“自助分析”还提供多个报表模板，可供选择使用。

在膏满堂天猫旗舰店负责人濮正阳看来，目前“自助分析”提供的两大报表类型已经能够满足店铺的大多数数据分析诉求，“生意参谋自带的数据模板侧重呈现整个店铺的核心数据，但是如果聚焦运营场景，比如商品维度、关键词维度等，其实还是需要店铺运营人员去根据自己的实际需求进行数据维度筛选和报表自主搭建，再根据最终的分析结果数据去进行商品链接推广及SKU分布的调整。”

此外，除了可自定义搭建店铺所需的报表外，“自助分析”还提供长周期数据存储能力。

“像现在对于我们店铺来说，是销售大闸蟹的旺季，今年主推的家庭分享款大闸蟹套餐，就需要去年同期相似商品的各项数据做参考，那么之后还有双11、双12、年货节等各种大促场景，自助分析模块提供的这项长周期数据存储能力，是补足了我们做同期数据比较的诉求。” 濮正阳表示。

而才组建新团队完成店铺转型的宋福翔则有更多考虑，店铺运营岗位的流动性比较大，数据交接工作通常比较复杂，“很多数据其实很难进行保存，那么自助分析现在能够为店铺存储近一年半的核心数据，这对我们整个店铺的经营来说，其实是提供了很大保障。”

而在阿里巴巴平台数据产品资深专家逸客看来，全新上线的“自助分析”功能一定程度上还能够拉平不同体量店铺间的数据分析、店铺经营能力，“体量较大的店铺往往很早就开始通过数据指导店铺经营，同时注重数据人才培养和组织建设；相对地，中小商家因为缺少专业数据岗位设置，往往不是特别能够对庞杂多维的店铺数据进行集中统计分析。我们希望通过不断丰富完善生意参谋的功能，并且引入更多专业讲师和分析人才的经验，去帮助更多店铺补齐这项能力，实现店铺经营效率的提升。”

未来，“自助分析”还将逐步上线更多维度数据，实现“一键式”全方位店铺经营数据统计与分析，普惠逾2000万累计用户。

数据安全软件公司Eress在2019年10月对美国安全专业人士的调查显示，约有一半的受访者表示他们的公司已经或将在今年年底前遵守CCPA。

虽然并不是所有的公司都完全合规，但这并不意味着他们无所事事。2019年11月的一项调查发现，93%的美国IT决策人员表示，他们至少已经采取了一些措施来遵守隐私法规，如CCPA或欧盟的一般数据保护法规（GDPR）。至少有一半的受访者已经采取了一些措施，比如改善现有安全技术，投资于新技术，以及改善数据处理做法。

eMarketer首席分析师Lauren Fisher表示：“就像我们在GDPR中看到的那样，遵守CCPA是大多数公司无法在2020年1月1日的最后期限之前完成的。”

对于公司来说，遵守CCPA可能是一项代价高昂的努力。根据PossibleNoW 2019年8月的数据，35%的接受调查的美国企业表示，到2020年1月1日他们仍无法满足CCPA的要求，因为他们觉得实现合规的成本太高。

但不合规也不便宜。对于每个无意违规的记录，公司可能会被罚款2500美元；对于每个故意违规记录，公司可能会被罚款7500美元。对于那些对数千或数百万条数据记录负有责任的公司来说，罚款总额可能是巨大的。

199IT.com原创编译自：eMarketer 非授权请勿转载

前言

自手Q游戏中心V6.0改版以来，产品形态发生了较大的转变，不再是纯粹通过app列表做游戏分发，而是试图通过内容来带游戏分发，全新的产品形态给推荐算法带来了许多的挑战。截至4月初，算法一期的工作已接近尾声，借此机会写下总结，一方面是将整个游戏中心的推荐逻辑进行梳理，并将其中的一些经验沉淀总结，方便回溯；另一方面也试图在梳理的过程中，整理出遇到的一些挑战，能够更加明确算法二期的一些迭代思路。

手Q游戏中心作为腾讯手游重要的分发渠道之一，既是用户发现感兴趣游戏的重要入口，同时也提供了各手游平台运营的能力。新版游戏中心不再是纯粹地通过传统app列表的方式做游戏分发，而是新增了一系列通过内容（攻略、视频、直播、礼包等）拉下载、拉活跃的场景（如图1所示）。为了更好地提升用户进入游戏中心的体验以及满足平台精细化运营（拉新、拉活、拉付费等）的需求，通过海量用户的行为流水挖掘用户游戏偏好，精准推荐用户感兴趣内容成为了必然趋势。为此，我们设计了全新的个性化推荐框架，给业务带来了显著的转化率提升。

图1：游戏中心个性化推荐场景

       为了更好地制定算法二期的迭代计划，本文主要对算法一期的工作做一个简单的复盘，一方面是将项目开展过程中的一些经验进行总结沉淀，另一方面也是想对游戏中心推荐场景中比较有挑战性的问题进行梳理，以便算法二期迭代过程中更加具有针对性。

本节主要结合游戏中心个性化推荐的算法框架（如图2所示）以及工程框架（如图3所示），对项目过程中遇到的一些问题进行总结归纳。游戏中心所采用的推荐框架是业界常见的三段式推荐逻辑：offline—nearline—online。离线层主要负责存储全量用户在游戏中心的流水数据、计算用户长期的行为属性以及训练用户的游戏偏好模型等；近线层主要是为了解决离线层计算周期长，响应速度慢的缺点，通过实时计算用户的短期兴趣，反馈到线上，从而能够对用户在游戏中心的行为做到实时反馈；在线层可以理解为推荐引擎，主要是对业务请求通过一系列的计算，返回最终的推荐结果列表，在线层可以细分为召回层—精排层—重排层结构。

图2：游戏中心个性化推荐算法架构图

图3：游戏中心个性化推荐工程架构图

• 离线层

离线层适用于用户长期兴趣的计算、离线模型的训练、模型参数的实验以及其他对时效性要求不高的任务，因此离线层主要采取HDFS+Spark的工程实现（批处理的计算方式）。业务数据通过DC或者TDBank上报，累计一定的数据量（游戏中心是以每小时为周期）周期性落地到HDFS或者TDW中以库表的形式存在，以Spark为计算引擎，对库表数据进行一系列处理后，将结果数据推送到线上存储，构成线上推荐引擎的重要数据来源。对于游戏中心这个场景，离线层的工作流可以划分为6大步骤：推荐物料的准备、数据处理、样本设计、特征提取、模型训练、数据上线。

1、推荐物料的准备

对于推荐系统来讲，第一个需要确定的就是推荐物料（也就是推荐池子）。游戏中心推荐的物品主要有两大类：第一大类就是游戏app，目前游戏中心接入算法的游戏app主要包括精品游戏、单机游戏，基本上每天变化不大，因此该类物料由业务每天例行上报更新并推送到线上存储即可。第二大类就是游戏内容了，主要包括攻略、视频、直播等，该类物料相对来讲实时性要求会高一些（新游上线当天需要内容同步更新）。目前游戏中心的内容来源数据链路如图4所示，主要来源是一些上游PGC内容的采购，经过自动Tag提取之后进入到标签内容库，算法侧直接从标签内容库获取推荐物料，目前是按小时更新。

图4：内容源数据链路

2、数据处理

熟悉推荐流程的同学可能比较清楚，数据处理过程繁琐枯燥且耗时较长，占据了整个算法开发周期60%以上的时间，贯穿整个开发流程。没入坑之前有些人可能会以为推荐算法工程师是一个高大上的职位，每天舒舒服服地看下paper，研究下算法，做下实验，特别酷。入坑之后就会发现，每天干的最多的活就是处理数据。但这也充分说明了数据处理的重要性，毕竟只有充分了解数据才能更了解业务，才能更加合理地设计你的推荐策略。这儿讲的数据处理主要包括数据验证、脏数据过滤以及数据转换等。下面主要总结一下在数据处理过程中所踩过的坑：

（1）一定要做好数据上报准确性的验证：前端同学有时候可能不是特别了解算法同学对于上报数据的诉求，所以在上报的时候可能会出现目标不一致的情况。常见的情况有：上报逻辑出错（分页feeds曝光只上报了第一条feeds的数据）、上报id错位（曝光的operid报了下载的数据），上报id缺失等。而验证数据上报准确性的常规操作就是打开游戏中心，将每个场景你有可能会用到的用户行为都操作一遍，记下操作时间，一个小时后从流水中捞出你的数据，逐一验证是否合理（噩梦）。

（2）推荐逻辑出现问题时候优先考虑数据的准确性：当推荐结果产生问题或者出现bug的时候，优先检查数据的准确性。模型的鲁棒性以及容错性一般都较高，最可能出现问题的往往是数据环节。通常都是沿着数据链路往上游逐步排查从而定位问题。

（3）对业务流水数据做一层数据中间表做解耦：算法开发过程中，最好不要直接操作operid相关的逻辑，遇上业务改上报id时（比如产品改版换了新的一套operid），改代码改的你头疼。

（4）算法接入后一定要跟产品以及前端同学再三确认算法ID的上报准确性：业务在调用推荐引擎时都会获得一个算法ID，算法ID上报的准确性直接影响效果监控报表的可信度。很多时候上了一个算法策略结果发现线上效果突然下降，排查半天才发现原来部分转化行为的算法ID上报缺失，所以这儿一定要仔细验证清楚。

（5）脏数据过滤是一门玄学：脏数据的定义通常需要根据业务场景来决定，有时候信心满满地将所有脏数据都过滤之后，线上效果反而降了，所以在过滤数据时要留个心眼（什么样才是脏数据？脏数据是不是一定没用？不要想当然，还是用线上效果说话吧！）。

（6）建立完善的报表监控体系：推荐的一个重要环节就是报表监控，不仅仅包括对效果的监控，还包括对池子的监控、核心用户的监控、item场景表现的监控等。只有建立完善的监控体系，才能在推荐结果受到挑战时快速定位问题。

图5：游戏中心报表监控体系

3、样本设计

一般来讲，推荐问题都会转换成二分类问题，也就是判断用户对某个物品是否会产生操作行为（通常一个U-I对就是一个样本），那么要训练出一个看起来合理线上效果又比较理想的二分类模型，正负样本的设计显得极其重要，下面总结一下游戏中心在设计不同场景的样本时的一些经验：

（1）如何正确定义正负样本？在纯icon推荐的场景，咋一看可以理解为用户下载了该app就是正样本，没有下载就是负样本。但仔细一想这样做会产生两个问题，第一个问题就是正负样本极其不均衡（机器学习中经典问题之一），因为用户浏览几十个app可能也就下载1个app，当然，机器学习针对正负样本不均衡问题会有很多解决方法，这儿就不展开描述了；第二个问题就是用户没有下载并不代表就是不喜欢，这儿会有几个值得推敲的地方：1）用户曝光了但是从没有产生过下载行为，可能因为是无效曝光，用户关注的焦点不在这，所以无法判断用户到底是喜欢还是不喜欢；2）用户在游戏icon曝光的场景并没有产生下载行为，但是用户产生了点击行为，从而进入到游戏详情页后产生下载行为，这样是不是可以认为用户其实是喜欢的，产生的也是正样本呢？举这么个例子主要是为了说明，对于每个不同的推荐场景来说，正负样本的设计都应该充分结合业务特性，不然容易产生有偏样本。

（2）设计样本时应保证每个用户样本数的均衡：在app分发或者内容分发场景，容易存在一些刷量用户；该批用户频繁进入游戏中心从而产生多次操作行为，因此在设计样本时应对多次操作的U-I样本对去重，并保证每个用户样本数的均衡，从而避免模型被少数用户所带偏。

（3）样本权重的设计问题：在feeds推荐的场景中，不同推荐槽位所产生的样本权重应该有所不同；比方说首页feeds场景，用户刚进入场景时，注意力会比较集中，产生的负样本应该置信度较高，权重也较高；当用户下滑到后面feeds的时候，对feeds的内容可能会比较乏味了，产生的正样本置信度应该也是较高的，权重应该也设置较高。

（4）适当丰富样本来源的多样性：一般样本都是基于当前场景所产生的用户行为来选取的，而当前场景用户的行为某种程度是受推荐结果而影响的（“你给我推荐了王者荣耀，那么我只能喜欢王者，但是可能我更喜欢你没给我推的吃鸡呢”），随着算法的迭代，越到后面，算法其实是在迭代自身，越学越窄，这也是推荐系统经典的多样性问题。youtube所采用的一种缓解的方法就是从其他没有算法干扰的场景选取部分样本，来避免这个问题，而在游戏中心的样本设计中，都会单独开设一股没有算法干扰的小流量作为干净样本的补充。

4、特征提取

特征决定机器学习的上限，而模型只是在逼近这个上限。可想而知，特征设计的重要程度是多么的高。关于特征设计的方法论有很多，这儿就不具体讨论。这里主要介绍一下游戏中心各个场景在设计特征时候的通用思路以及为了解决首页feeds特征空间不一致时所采用的多模态embedding特征。

（1）通用特征设计思路：如图6所示。这儿需要提一下的是，游戏中心的推荐场景由于涉及平台利益，所以一般情况下，特征设计时都需要考虑特征的可解释性。

图6：特征设计思路

（2）多模态embedding特征向量：首页feeds流分发场景是一个具有挑战性的场景，其中一个比较有意思的难题就是待推荐的内容类型较多。传统的feeds推荐场景要么都是纯视频流、要么是纯文字feeds等，而游戏中心首页这儿待推荐的内容类型有攻略、视频、直播、活动、礼包等，而且每一种内容类型的二级承载页产品形态也不一致，这样会导致可提取的特征空间维度不一致。比方说视频承载页的观看时长与图文承载页的观看时长量级不一致，视频承载页有icon点击等操作而图文承载页则没有。特征空间的不一致会导致模型在打分的时候会有所偏颇，离线实验过程中发现视频由于特征维度较齐全，打分结果整体偏高。因此，为了减缓特征空间维度不一致问题，游戏中心首页feeds流引入了多模态embedding特征向量，该方法在企鹅电竞视频推荐场景已经取得了较好的效果（如图7所示）。多模态embedding特征向量的设计主要参考youtube的论文，从而获得每个user、item的低维特征向量，一方面解决item的原始特征空间维度不一致问题，另一方面也根据用户的历史行为，学习user、item的隐语义特征维度，起到信息补充的作用。

图7：多模态embedding网络

5、模型训练

好了，终于到了别人所认为的高大上的步骤了——模型训练，其实一点都不高大上，尤其是有了神盾推荐这个平台。目前神盾推荐离线算法平台已经集成了大部分常见的推荐算法，包括LR，Xgboost，FM，CF等，因此离线训练只需要准备好样本跟特征，配置好参数，就可以一键点run喝咖啡了（开玩笑开玩笑，是继续搬下一块砖）。傻瓜式的模型训练（调包侠）其实并没有太大的坑，但是有几点经验也在这稍微写一下哈：

（1）注意调参的正确姿势：目前神盾默认是将数据集划分为train跟test，如果盯着test数据集的指标来调参的话，是很有可能出现线下高线上低的情况。因为盯着test指标进行调参的话容易加入个人先验，本身就是一种过拟合的操作，正规的操作应该是将数据集划分为train-test-validation。

（2）同样的业务场景建议共用一个大模型：新版游戏中心目前有9个场景需要算法接入，如果每一个场景都单独建模的话，一来维护成本高，二来浪费人力。适当对场景问题进行归纳，训练通用模型可以有效地节省开发时间。比如说首页分类列表推荐，游戏Tab的热游列表推荐等，其实都是纯icon的推荐，可以用统一的大模型来建模。通用模型首先要考虑的问题就是样本、特征的选取，样本可能比较好设计，汇总所有场景的样本即可，最多就是根据场景特性设计不同的权重；而特征就需要好好斟酌，是分场景提取特征还是汇总后提取、不同场景特征维度不一致如何处理等。

（3）选择合适的机器学习方案：目前首页feeds是将排序问题转化为二分类问题，评估指标选取的是auc，所以优化的重点在于尽可能地将正负样本区分开（正样本排在负样本前面），但对于正样本之间谁更“正”却不是二分类模型的关注重点。神盾近来已经支持pari-wise的LTR算法，可以解决任意两样本之间置信度问题，后续可以在首页feeds场景上做尝试。

（4）选择合适的优化指标：对于视频瀑布流场景，优化的目标可以有很多，比如人均播放个数、播放率、人均播放时长，具体需要跟产品同学沟通清楚。

（5）避免对分类问题的过度拟合：前面已经提过，在推荐场景，经常将推荐问题转化为分类问题来处理，但是需要注意的是，推荐问题不仅仅只是分类问题。分类问题是基于历史行为来做预测，但推荐问题有时候也需要考虑跳出用户历史行为的限制，推荐一些用户意想不到的item，因此，推荐是一个系统性问题，应当避免过度拟合分类问题。

6、数据上线

数据上线可以说是推荐系统中较为核心的环节，其中会面临很多难题。这儿的数据主要指的是离线计算好的物料数据、特征数据（用户、物品）、模型数据等。目前神盾会周期性地对需要上线的数据出库到hdfs，通过数据导入服务推送到线上存储，主要是grocery（用户特征）跟共享内存ssm（物品特征以及池子数据等查询较为频繁的数据）。目前这儿会有几个小问题：

（1）数据的一致性问题：离线模型在训练的时候，会对样本数据跟特征数据做拼接，通常都是将当前周期的样本跟上一周期的特征做拼接，以天为例，也就是今天的样本会跟昨天的特征数据做拼接。但是离线数据的计算以及上线是会有时间延迟的，尤其是特征数据。有可能今天的凌晨0点到5点，线上所拉到的特征数据其实是前天的特征数据，5点之后，昨天的特征数据才计算完并更新到线上。也就是说凌晨5点之前，所产生的推荐结果其实是用前天的特征数据来计算的，那么离线训练的时候，拼接的特征数据就会与实际的数据不一致。

（2）数据的实时性问题：前面也讲了，业务数据一般会周期（按小时）落地到hdfs或者tdw以库表形式存在，基于spark进行数据处理之后又推送到线上存储，这种复杂的数据处理链路导致数据时效性得不到保证（频繁地数据落地以及数据上线所导致）。因此，离线层仅适用于对数据时效性不高的任务，比如长期兴趣的计算等。

• 近线层

前面已经提到，离线层在数据时效性以及数据一致性的问题上面临较大的挑战。本质上是由于数据频繁落地以及上线导致的延迟所引起的，给游戏中心推荐带来较大的困扰。企鹅电竞也面临同样的问题，因此，两个业务联合设计了近线层（如图8所示）。目前整个数据链路已经打通，并且也在企鹅电竞业务上试点成功。整个框架是基于kafka+spark streaming来搭建的，目前主要实现两个功能点：实时特征的提取以及实时样本特征的拼接。由于近线层不需要落地以及线上导数据服务，而是直接对业务流水进行操作后写入线上存储，因此耗时较少，基本可以做到秒级别的特征反馈，解决了离线层计算周期长的缺点，适用于用户短时兴趣的捕捉。

实时样本特征的拼接主要是为了解决数据一致性问题。离线层对样本、特征进行拼接的时候一般都是默认当前周期样本拼接上一周期的特征，当由于特征上线的延迟，有部分当前周期样本的产生其实是由t-2周期的特征所导致，因此为了保证训练数据的准确性，我们在近线层设计了实时的样本特征拼接。当用户请求时，会带上读取的特征数据，拼接到用户的操作流数据上，构成离线层的训练数据。

图8：近线层功能逻辑

• 在线层

在线层是推荐系统的关键环节，直接影响最终的推荐结果。一般分为召回层，精排层、重排层（或者是matching、ranking、rerank）。召回层一般是起到粗筛的作用，对于内容推荐来说，推荐的池子一般都是上万级别，如果直接进行模型打分的话，线上服务压力会比较大，因此，通常都会采用各种召回的策略来进行候选集的粗筛。目前游戏中心所采用的召回策略主要有标签、热度、新鲜度、CF等。精排层所干的事情就比较纯粹了，一般就是模型加载以及模型打分，对召回的物品进行一个打分排序。最后就是重排层，主要是对模型打分结果进行一个策略的调整。游戏中心的重排排层主要有以下几个逻辑：1）分类打散：首页feeds在推荐的时候，如果只由模型进行打分控制的话，容易出现游戏扎堆的现象，也就是连续几条feeds都是同款游戏，因此需要重排层来调整展示的顺序；2）流量分配：游戏的分发涉及平台的利益，每款游戏的曝光量会影响平台的收入，因此需要合理分配每款游戏的展示量；3）bandint策略：主要是用于兴趣试探，feeds场景会涉及多种内容类型，如何在推荐用户历史喜欢的内容类型以及尝试曝光新的内容类型之间做平衡是推荐系统典型的E&E问题，这儿我们设计了一个简单的bandint策略，下面会详细讲一下。4）运营策略：一些偏业务性质的运营策略也会在重排层体现。

推荐系统中会遇到一个经典的问题就是Exploitation（开发） VS Exploration（探索）问题，其中的Exploitation是基于已知最好策略，开发利用已知具有较高回报的item（贪婪、短期回报），而对于Exploration则不考虑曾经的经验，勘探潜在可能高回报的item（非贪婪、长期回报），最后的目标就是要找到Exploitation & Exploration的trade-off，以达到累计回报最大化。对于游戏中心首页feeds而言，一味推荐用户历史喜欢的内容类型或者大量尝试曝光新的内容类型都是不可行的；首先用户的兴趣可能会有所波动，过去可能喜欢视频类型，但是下一刻就可能不喜欢了；其次一味推荐用户历史喜欢的内容类型，可能会让用户产生厌倦。为了平衡两者之间的关系，我们在重排层设计了一个简单的策略，具体如图9、图10所示。

图9：游戏中心bandit策略算法逻辑

图10：游戏中心bandit策略具体实现

        目前游戏中心个性化推荐所遇到的难点以及下一步的迭代计划主要如下：

1、外部数据的引入：1）结合第三方数据做推荐：目前游戏中心个性化推荐的依据主要是用户的场景表现、游戏内表现以及一些基础的画像数据，数据来源较为单一。引入更多的第三方业务数据（比如企鹅电竞），一方面可以丰富用户的特征维度，另一方面可以给用户带来体验上的提升（用户刚在企鹅电竞看了个吃鸡的直播，来到游戏中心就给推荐了“刺激战场”）。2）丰富推荐物料：目前游戏中心的内容来源部分存在“同质化”现象，素材类型还不是特别丰富，需要引入更多优质的外部内容。

2、多模态特征提取：游戏中心的推荐内容类型较为丰富，包括了视频、图文、活动、礼包等，如何在同一个特征向量空间对各个item进行信息抽取是目前遇到的难题之一。现有的解决方案是基于youtube的embedding网络进行user、item的embedding向量学习。该网络的输入是无序的，也就是没有考虑用户历史行为的轨迹，那么是否可以用图来表示行为的轨迹，基于graph embedding的方法获得信息更加丰富的item向量？目前业界也有若干基于graph embedding的推荐案例（手淘首页 、阿里凑单 ）。

3、内容元信息的提取：目前游戏中心对于item的特征提取要么是基于统计的特征，要么就是基于item历史行为的embedding特征或者tag提取，对于内容本体信息的提取还较为薄弱，如何有效地提取非结构化内容的信息是下一步迭代需要考虑的问题。

4、模型的快速更新：对于用户兴趣的实时捕捉，不仅依赖于数据的实时更新，同样依赖于模型的实时更新。目前线上的模型是按天例行更新，如何快速地训练模型以及部署模型是后续不可避免的问题。

5、优化指标考虑收入相关因子：当前的优化指标基本是转化率、时长等推荐系统常见的指标，但游戏中心涉及平台收入，需要综合考虑每个游戏的收益（类似广告系统中的竞价）。如何设计合理的优化指标（考虑游戏arpu、ltv等）以及在用户体验跟平台收入之间做平衡也是下一步迭代的关键。

6、流量分配问题：首页feeds场景既涉及游戏流量的分配，也涉及内容类型流量的分配，如何有效地设计流量分配方案，从而减轻重排逻辑的负担也是需要考虑的优化点。

7、拉活还是拉新：如何根据用户在游戏生命周期的不同阶段推荐合适的内容是首页feeds场景需要考虑的问题。

8、新品试探：目前我们只是在内容类型上做了一些简单的策略，后续还需要调研更加成熟的解决方案来解决E&E问题。

       本文主要是对游戏中心在算法一期的接入过程所遇到的问题做一些总结，以及梳理下一步迭代的计划。由于算法一期的重心在于算法的快速接入，因此整个个性化推荐框架中所涉及到的策略可能都略显“着急”，希望各位同行大佬多多包涵。关于游戏中心推荐问题，欢迎随时交流。

来源：腾讯QQ大数据

电子表单

虽然现在市场上有很多优秀的数据处理工具，但是Excel依然是公认最适合初学者的数据处理利器。Excel 软件中的电子表单能够有效地对数据进行结构化整理和分析。OpenNews的 Sandhya Kambhampati 与大家分享了她在使用Excel时的一些经验和心得，点击查看她的展示，并开始属于你自己的数据探索之旅吧。（OpenNews 是由Knight基金会和Mozilla联合支持的一个项目，旨在建立一个包括开发者、设计师，以及数据记者的社群，在开放的网络环境中帮助新闻事业的发展。）

数据抓取

如果在做选题时，遇到网页上有大量非电子表格形式的数据信息，又该如何处理呢？来自丹麦的记者 Nils Mulvad 说，这时你就需要 Import.io 工具来帮你抓取数据。它能够节省你的时间，把你从重复的劳动中解放出来。

数据清洗

有时你遇到的数据可能是非常杂乱的，不过不用担心， OpenRefine 能够有效帮助你清洗、结构化数据，完善数据集。更重要的是，它还是开源的哦。点击查看 Nils Mulvad 的展示，手把手教你使用这款工具。

数据库管理

你准备好和大数据打交道了么？如何处理GB、TB规模的数据集？如何进行更快捷、更综合的数据分析？来自 Vox 的开发人员 Kavya Sukumar 告诉你，这就需要数据库管理的技能了。点击查看她分享的内容吧。

网络搜索

互联网上有大量良莠不齐的信息，我们如今需要更可靠的方法去检索验证，才能避免被信息误导。路透社记者 Irene Liu 与大家分享了网络报道所需的信息核实工具和方法，包括逆向图片搜索，地理位置核实、社交网络检测等等。点击查看关于网络搜索的更多精彩内容吧。

绘制地图

空间分析能够帮助记者发掘出数据中潜藏的故事线索，地图绘制则能有效地呈现数据。纽约时报记者 Andy Lehren就经常使用美国环境系统研究所公司（ESRI）开发的工具ArcGIS 进行空间分析和地图绘制。点击查看他在大会上的展示，循序渐进地教你地图绘制。

数据可视化

如果你想用酷炫的设计图表来展示你的数据，但是团队中又缺乏一位工程师或设计师，怎么办呢？没关系，印度最大的财经类门户网站MoneyControl 的数据与社交媒体编辑 Sanjit Oberai ，整理了一份数据可视化工具表单，这些工具操作简单，效果拔群。点击查看他的分享吧。

来自：全球深度报道网

编译/程一祥

编辑/Ivan Zhai，梁思然

那么筛选海量数据集最优的工具是什么呢?我们咨询了一些数据黑客关于他们在数据分析的核心工作中最喜欢的编程语言和工具包。

R 语言

这份名单如果不以 R 开头，那就是彻头彻尾的疏忽。自 1997 年起，作为一门免费的，可替代 Matlab 或 SAS 等昂贵统计软件的语言，R 被抛弃。

但是在过去的几年中，它却成了数据科学的宠儿—甚至成了统计学家、 华尔街交易员、生物学家和硅谷开发者必不可少的工具。 随着其商业价值的不断增长和传播，诸如谷歌、Facebook、 美国银行和纽约时代周刊都在使用。

R 简单易用。通过 R ，短短几行代码就可以筛选复杂的数据集，通过成熟的模型函数处理数据，制作精美的图表进行数据可视化。简直就是 Excel 的加强灵活版。

R 最大的价值就是围绕其开发的活跃的生态圈： R 社区在持续不断地向现存丰富的函数集增添新的包和特性。据估计 R 的使用者已经超过 200 万人，最近的一项 调查也显示 R目前是数据科学领域最受欢迎的语言，大约 61% 的受访者使用 R(第二名是 Python, 占比39%)。

在华尔街，R 的使用比例也在不断增长。美国银行副总裁Niall O’Connor 说：“以往，分析员通常是熬夜研究 Excel 文件，但是现在 R 正被逐渐地应用于金融建模，尤其是作为可视化工具。R 促使了表格化分析的出局。”

作为一门数据建模语言， R 正在走向成熟，尽管在公司需要大规模产品的时候 R 能力有限，也有些人说它已经被其他语言替代了。

Metamarkets 公司的 CEO Michael Driscoll 说：“ R 擅长的是勾画，而不是搭建，在 Google 的 page rank 算法和 Facebook 的好友推荐算法实现的核心中是不会有 R 的。工程师会用 R 进行原型设计，再用 Java 或者 Python将其实现。”

Paul Butler 在 2010 年用 R 构建了一个著名的 Facebook 世界地图 ，证明了 R 在数据可视化上的强大能力。然而他并不经常使用 R。

Butler 说：“由于在处理较大数据集时缓慢且笨拙，R 在行业中已经有些沦为明日黄花了 ”

那么使用什么作为它的替代呢?看下去。

Python

如果 R 是个有点神经质的可爱的极客，那么 Python 就是它容易相处的欢快的表弟。融合了 R 快速成熟的数据挖掘能力以及更实际的产品构建能力， Python 正迅速地获得主流的呼声。 Python 更直观，且比 R 更易学，近几年其整体的生态系统发展也成长得很快，使其在统计分析上的能力超越了之前的 R 语言。

Butler 说：“Python 是行业人员正在转换发展的方向。过去两年里，很明显存在由 R 向 Python 转化的趋势”

在数据处理中，通常存在规模和技巧的权衡，Python 作为一个折中出现了。 IPython notebook 和NumPy 可以用于轻量工作的处理， 而 Python 则是中级规模数据处理的有力工具。丰富的数据交流社区也是 Python 的优势，它提供了大量的Python 工具包和特性。

美国银行利用 Python 开发新产品以及基础设施接口，同时也用于处理金融数据。O’Donnell 说：“Python 用途宽广且灵活，所以人们蜂拥而至”。

然而， Driscoll 也提到它并不是高性能的语言，偶尔才会用于装配驱动大规模的核心基础设施。

JULIA

最主流的数据科学处理语言包括 R、 Python、 Java、 Matlab和 SAS。但是这些语言仍然存在一些不足之处，而Julia 正是待以观察的新人。

对大规模商用来说， Julia 还是太晦涩了。但在谈到其取代 R 和 Python 领先地位的潜力的时候，数据极客们都会变得很激动。 Julia 是一门高级的，非常快的函数式语言。速度上比 R 快， 可能比 Python 的扩展性更高，且相对易学。

Butler 说：“Julia 正在快速上升。最终将可以用 Julia 完成任何 R 和 Python 可以完成的事”。

如今的问题是 Julia 太“年轻”了。 其数据交流社区仍处在早期发展阶段，在没有足够的包和工具之前是不足以与 R 和 Python 竞争的。

Driscoll 说：“Julia 很年轻，但正在积攒力量而且未来很可观”。

JAVA

在硅谷最大的科技公司里，Java 和基于 Java 的框架构成了其底层的技术骨架。Driscoll 说：“如果深入观察Twitter，Linkedin 或者 Facebook，你会发现 Java 是他们公司数据引擎架构的基础语言”。

Java 并没有 R 和 Python 那样的数据可视化的能力， 同时也不是最好的用于统计模型的语言。但是如果需要进行原型的基础开发和构建大规模系统， Java 往往是最好的选择。

HADOOP 和 HIVE

为了满足数据处理的巨大需求，基于 Java 的工具群涌而现。 作为基于 Java 的框架，Hadoop 在批处理领域成为热点。Hadoop 比其他处理工具速度要慢，但是它非常精确且被广泛的应用于后台分析，它很好的融合了 Hive， 一个运行在 Hadoop 上的基于查询的框架。

SCALA

Scala 是另一个基于 Java的语言，和 Java 很相似，它正在逐渐成长为大规模机器学习或高级算法的工具。它是函数式语言，也能够构建健壮的系统。

Driscoll 说：“Java 就像是直接用钢筋进行搭建， Scala 则像是在处理黏土原材料，可以将其放进窖中烧制成钢筋”。

KAFKA 和 STORM

当需要快速、实时分析时怎么办?Kafka 可以帮助你。它已经发展了大概五年时间，但最近才成为一个流处理的流行框架。

Kafka 诞生于 Linkedin 公司的内部项目，是一个快速查询系统。至于 Kafka 的缺点呢? 它太快了，实时的操作也导致了自身的错误，且偶尔还会遗失信息。

Driscoll 说：“在精度和速度之间总需要做权衡，所以硅谷所有的大公司一般都双管齐下： 用 kafka 和 Storm 进行实时处理，用 Hadoop 做批处理系统，虽然会慢一点但却十分精确”。

Storm 是另一个用 Scala 写的框架，且它在硅谷以擅长流处理而受到极大的关注。毫无疑问， Twitter， 一个对快速消息处理有着巨大兴趣的公司会收购了 Storm。

荣幸的提到：

MATLAB

MATLAB 已经存在很长时间了，尽管价格昂贵，但它仍在某些特定领域被广泛使用： 机器学习研究、信号处理、图像识别等领域。

OCTAVE

Octave 与 Matlab 非常相似，只不过它是免费的。然而除了信号处理的学术圈之外很少见到使用。

GO

GO 是另外一个获得关注的新手。它由 Google 开发，与 C 有一定渊源，且在构建稳定系统方面与 Java 和 Python 展开了竞争。

199IT大数据导航，汇集1000多款与数据相关的工具（http://hao.199it.com/ ），欢迎分享收藏！

具体特点分析如下：

一、收入保持稳定增长，增幅有一定回升

今年前5个月，我国软件产业实现软件业务收入8608亿元，同比增长27.2%，增速低于去年同期1个百分点，但比1-4月提高1.2个百分点。其中，5月份完成软件业务收入2087.7亿元，同比增长30.8%，比4月份提高5.6个百分点，环比增长12.5%。

二、运营类服务持续快速发展，嵌入式系统软件增长加快

1-5月，数据处理和运营服务实现收入1480亿元，同比增长38.4%，高于全行业增速11.2个百分点，占全行业比重(17.2%)比去年同期提高1.4个百分点。嵌入式系统软件实现收入1407亿元，同比增长28.8%，高于去年同期2.4个百分点。软件产品和信息系统集成服务增长较为平稳，分别实现收入2864和1774亿元，同比增长24.3%和23.8%。信息技术咨询服务略有波动，实现收入788亿元，同比增长26.3%，增速比1-4月回落5.4个百分点。

三、软件出口和外包服务持续低位增长，5月开始有回升趋势

自2011年下半年以来，软件出口增速始终在20%以下，低于全行业增速10个百分点，今年前4个月增速连续下滑，但5月份开始有所回升。1-5月，软件业实现出口134亿美元，同比增长11.5%，增速低于去年同期9个百分点，但比1-4月上升1.3个百分点。其中，外包服务出口29.4亿美元，同比增长26.4%，增速低于去年同期20.1个百分点，但比1-4月上升2.8个百分点。

四、西部地区增势突出，中部地区下滑明显

西部地区软件业持续高速增长，1-5月完成软件业务收入857亿元，同比增长31.2%，增速高出全国平均水平4个百分点，其中重庆、陕西增速均超过30%;中部地区增长乏力，2011全年仅有两个月增速超过全国平均水平，今年前5个月完成软件业务收入214亿元，同比增长16.5%，增速低于去年同期12个百分点，低于全国平均水平10.7个百分点，占比(2.5%)比去年同期下降0.2个百分点;东部地区和东北三省保持平稳增长，分别完成软件业务收入6717和820亿元，同比增长26.9%和28.1%。

五、中心城市增长较快，服务化发展领先全国

1-5月，全国15个副省级中心城市实现软件业务收入4783亿元，同比增长28.9%，增速比1-4月提高2.2个百分点，高于全国平均水平1.7个百分点。中心城市软件产业的服务化态势更为明显，信息技术咨询服务、数据处理和运营服务收入增速分别达32.7%和36.2%，两项占全部收入比重达到27.2%，超过全国平均水平0.8个百分点。