用户建模有什么用

BRD文档（商业需求文档） 定义：BRD 是英文”Business Requirement Document“的缩写，根据英文直译过来就是”商业需求文档“的意思，指的就是基于商业目标或价值所描述的产品需求内容文档（报告），其核心的用途就是用于产品在投入研发之前，由企业高层作为决策评估的重要依据。一般来说全新的产品、未来发展有潜力的产品提供BRD！ 真相君：市场前景无限大；用户需求未满足；同类竞品没做到；好机会啊，老板 MRD（市场需求文档） 定义：MRD 是英文”Market Requirements Document“的缩写，根据英文直译过来就是”市场需求文档“的意思，主要是描述什么样的功能和特点的产品（包含产品版本）可以在市场上取得成功。一般新功能的实现，上线新的产品提供MRD！ 真相君：老板，市场真的很大，产品路线图我都规划好了，我们按照产品路线发展，肯定能成。 PRD（产品需求文档） 定义：PRD 是英文”Product Requirement Document“的缩写，根据英文直译过来就是”产品需求文档“的意思， PRD文档是产品项目由“概念化”阶段进入到“图纸化”阶段的最主要的一个文档，其作用就是“对MRD中的内容进行指标化和技术化”，这个文档的质量好坏直接影响产品能否顺利的实施完成。一般产品的功能改善、产品的细节说明提供PRD文档！ 真相君：确保文档可读性；名词不要有歧义；从概念到图纸化；设计开发全靠它。 用户场景 用户场景是什么？是人物、时间、地点、欲望、手段五要素所组成的特定关系。在xx时间（when），xx地点（where），特定类型的用户(who)萌发了某种欲望(desire)，会想通过某种手段(method)来满足欲望。 真相君：产品原型很简单；洞察用户才最难；带入场景去分析；用户心理全了然 MVP 简单的说法就是用最小的成本开发出可表达项目创意、可用且能用于表达核心理念的原型产品，功能极简而且能用于快速验证想法的最小化产品。 真相君：糟了，老板明天要验收；别慌，他不懂技术；咱先拿个半成品忽悠他。 灰度发布 定义：灰度发布（又名金丝雀发布）是指让一部分用户继续用产品特性A，一部分用户开始用产品特性B，如果用户对B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B上面来。灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度。经常与A/B测试一起使用，用于测试选择多种方案。 真相君：不知新版发布会不会挨骂？；找群白鼠测一下；如果反馈还不错；那就逐步推出它。 用户研究 定义：用户研究是指通过对用户的任务操作特性、知觉特征、认知心理特征的研究，使用户的实际需求成为产品设计的导向，使您的产品更符合用户的习惯、经验和期待。 在互联网领域内，用户研究主要应用于两个方面： 对于新产品来说，用户研究一般用来明确用户需求点，帮助设计师选定产品的设计方向； 对于已经发布的产品来说，用户研究一般用于发现产品问题，帮助设计师优化产品体验。 真相君：用户研究不简单；定性定量都精通；还得数据来建模；产品决策要靠它。 用户画像 定义：用户画像就是你的粉丝群体属性的数据，比如性别、学历、职业、收入水平、手机型号、兴趣爱好等等。是根据用户在互联网留下的种种数据，主动或被动地收集，最后加工成一系列的标签。 真相君：平时上网别乱点；行为历史有记录；根据数据贴标签；再想撕掉难上天 A / B测试 定义：AB测试是为Web或App界面或流程制作两个（A/B）或多个（A/B/n）版本，在同一时间维度，分别让组成成分相同（相似）的访客群组（目标人群）随机的访问这些版本，收集各群组的用户体验数据和业务数据，最后分析、评估出最好版本，正式采用。 真相君：不知道功能上线后效果好不好，先找一部分用户测试看看，好了再全面推广。 UCD 定义：（User Centered Design）是一种设计思维、模式，指以用户为中心的设计。是在设计过程中以用户体验为设计决策的中心，强调用户优先的设计模式。 真相君：先不要考虑盈利，先让用户用的爽再说。 智能推送 定义：将用户“个性”和“商品、服务、内容”属性进行精准的匹配，达到用户所见即所需所想的目的，缩短了信息触达用户的路径，减少用户流失，促进用户快速转化。 真相君：你想看什么，就给你推送什么。 AIOT 定义：智联网(AIOT，是AI + IOT物联网的结合) 2018年开始崛起，核心是能够运用大量传感设备，综合语音、视觉、动作、温度等数据，实现IOT设备的全自然化的人机交互。 真相君：物联网喊了好多年；体验提升太有限；如今终于有突破；人机交互成关键。 AM敏捷开发 定义：以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。 真相君：一点点来，不要想一口吃个胖子。 PLC 定义：产品生命周期（Product Life Cycle），简称PLC，是产品的市场寿命，即一种新产品从开始进入市场到被市场淘汰的整个过程。这个过程其实就是经历了一个从“启动、成长、成熟一直到衰退”的阶段。 真相君：一个产品四阶段；阶段策略各不同；快速验证和开发；尽力延长成熟期。 可用性测试 定义：让一群具有代表性的用户对产品进行典型操作，同时观察员和开发人员在一旁观察，聆听，做记录。 真相君：观察用户使用产品。 商业闭环 定义：商业闭环是围绕着顾客一系列关联性消费需求，逐一提供相应的产品予以满足的商业模式。主要在商业体系中营造循环圈，各个环节都可以相互依靠，既可以作为个体支撑点也可以协同合作。 真相君：产品分步走；逻辑真是乱；怎么讲清楚；就得靠闭环！ 互联网上半场/下半场 定义： 互联网上半场即消费互联网时代，注重的是入口和流量，线上打造； 而下半场即产业互联网时代，注重的是服务和价值，线上线下充分融合。 真相君：上半场玩的是流量，现在流量已经被占完，再看产业和互联；线上线下共融合；下半场来临！ CRUD 创建（Create）、检索（Retrieve）、更新（Update）、删除（Delete），有时候也简称“增删改查”这是面向对象设计中最常用的4个基本方法。说来这是数据库里的必备的知识，但作为互联网公司的产品经理，这也是经常会提起的功能点。 真相君：就是后台功能操作分为：增删改查和搜索。 用户任务的闭环 定义：指的是一系列帮助用户完成任务的环节，这些环节可以应对任务可能出现的各种情况。 真相君：就是用户做一件事情要能做完。 KPI 定义：KPI绩效考核，又称“关键业绩指标”考核法，是企业绩效考核的方法之一。这种方法的优点是标准比较鲜明，易于做出评估。它的缺点是对简单的工作制定标准难度较大，缺乏一定的定量性。 真相君：就是给你分配的任务。 蓝海与红海 定义：所谓蓝海，指的是未知的市场空间，即尚未有人涉足，或是只有极少人涉足并且还没有做出太大成绩的市场。这样的市场，如果成功进入，则会是一段绝佳的时期，因为这段时间内你处于绝对的垄断地位，直到你的竞争对手赶上来。做好核心业务，做足差异化，能够帮助你将你的蓝海时段尽可能地延长，保证你的利益。 所谓红海，指的是已经发展的比较成熟，竞争非常激烈的市场。通常红海里的新人很难在短时间内做出成就，除非你在某一方面比你的竞争对手优势更大，或者你让投资人和初期用户看到了你巨大的发展潜力，又或者你在另一片红海中有着极佳的口碑，现在跨界进入这个行业。 真相君：蓝海就是竞争没那么激烈，红海就是竞争很激烈，刺刀见红。 进入壁垒 定义：进入壁垒值得是进入某一市场的难度，这一高度取决于自身的技术、成本、对特定资源的占有情况，以及对手的发展程度。 真相君：就是进入的门槛到底。 商业价值 定义：商业价值指的是一款产品如何创造价值。 真相君：就是如何赚钱。 墨菲定律 定义：事情如果有变坏的可能，不管这种可能性有多小，它总会发生。 真相君：越怕出事，越会出事。 放到互联网行业通常就是这样： 凡是输入框，都会遭遇灌水、SPAM、脚本注入 凡是积分，都会被刷 凡是推到网站首页的内容，都会出现色情、政治 凡是用户间沟通的渠道，都会被广告机器人利用 而对于项目管理而言，又可能是这样： 一项工作如果只有一个人负责，这个人肯定会休假或者离职 认为没有技术难点的地方，都会成为技术难点或性能瓶颈 羊群效应 定义：头羊往哪里走，后面的羊就跟着往哪里走。 真相君：说白了，其实就是从众心理。 破窗理论 定义：如果有人打坏了一幢建筑物的窗户玻璃，而这扇窗户又得不到及时的维修，别人就可能受到某些示范性的纵容去打烂更多的窗户。 真相君：环境中的不良现象如果被放任存在，会诱使人们仿效，甚至变本加厉。 二八定律 定义：也叫巴莱多定律，19世纪末20世纪初意大利的经济学家巴莱多认为，在任何一组东西中，最重要的只占其中一小部分，约20%，其余80%尽管是多数，却是次要的。社会约80%的财富集中在20%的人手里，而80%的人只拥有20%的社会财富。80%的回报来源于20%的有效付出。这种统计的不平衡性在社会、经济及生活中无处不在，这就是二八法则。 真相君：一个人的时间和精力都是非常有限的，要想真正做好每一件事情几乎是不可能的，要学会抓住主要矛盾，合理分配我们的时间和精力。要想面面俱到还不如重点突破，把80%的资源花在能出关键效益的20%的方面，这20%的方面又能带动其余80%的发展。 马太效应 定义：指强者愈强，弱者愈弱的现象。《圣经—马太福音》中有一句名言：凡有的，还要加给他，让他有余；没有的，连他所有的，也要夺过来。社会学家从中引申出马太效应这一概念，用以描述社会生活领域中普遍存在的两极分化现象。 真相君：好的愈好，坏的愈坏，多的愈多，少的愈少。

Re【马甲问题】马甲账号清除公告 以前某社交公司查mj，就是用登陆浏览器比对。比对下登陆提交的浏览器地址，就全查出来了。 对于文本内容的比对感觉作用不大，我想过和别的组的尝试合并提交，只多出来200个提交。 ------------------------- Re【马甲问题】马甲账号清除公告 不过说句实在话，参加这么多竞赛过来，我还是第一次看到竞赛主办方用查mj的方式来抑制选手调参数过拟合训练数据集的。在最后一周更改测试集才是通用的做法吧。 我个人来说，同一策略线下验证集调好参数后，线上不会改参数超过两次，也是担心太过拟合，第二赛季就傻了。 ------------------------- Re【马甲问题】马甲账号清除公告 恩，看到规则了，话说第一季我觉得这样做可能比较好：训练集不变，然后测试集800个人随机抽样400个人作为平时的leadership排名，最后评测的时候用剩下400个人。这样刷小号也没意义了。 （突然想到回去后要跟我实验室的其他队伍说一声。。。以后LR调好W后别用我那个python脚本生成提交数据了。。。免得被当小号处理了omg ------------------------- 回22楼jiajiadidi的帖子 你不是改个参数几个队一起刷的话应该还好吧 我当初就觉得这样不好，后面多半要出乱子。浙大宣讲问主办方，现在这种情况，几条简单规则就能刷到6，我要是把这几条简单的规则告诉别人，那别人不都挤到前面，那赛季1不就没意义了？然后还有mj的问题。 宣讲的老师说，那你觉得现在极限是多少呢？是7么。mj这种问题都是小问题 后来算者说得好，规则确实能做得比较好，怎么结合规则做出更好的模型才是王道，模型不如规则只能说模型做的不够好。这个对我影响还蛮大的，也让我好好反思了一下。 我现在靠LR做到6.8，基本也没做规则了，而是想如何用以前淘宝有个做CTR预估的MLR的思路结合商品类目和用户定向做更好的结合规则的LR。 我把我python工程环境也发给同实验室的其他组了，在我基础上也有比我做的更高的，具体来说也没太问。 今天回贴，也是看到这种情况有所感想。 大家去刷规则，把推荐大赛做成overfitting大赛，这样对于自己的提高，或是解决这个实际问题，这样有意义么？我是觉得没有意义的。 跟我用同一体系方法的几个队，现在基本都做到6.9 6.8了，大家还是把精力更多放在了如何做更好的模型上。 想想最初学的PAC，一个模型如何叫好，train error低，并且train error近似于test error。这样我们才能声称自己的模型学习到了真正的target function f。而目前大家凭着test 来不断调整参数，就算把f1做到天上去，自己的模型只能说train error低了，大赛后也是毫无意义的。算法学到的那个function，也最多只能当作笑谈 看到有置顶，真是受宠若惊了。帖子里面说的MLR，是盖坤/靖世在阿里技术沙龙中分享的《海量数据下的非线性模型探索 》http://club.alibabatech.org/resource_detail.htm?topicId=106 。这个ppt非常好，我也学到不少。 顺便说说的是，在这个比赛中，我也确实学到不少。 以前我在做项目的时候，基本是对算法非常迷信的，关系好的豆瓣算法组的一个人批我机器学习理解不成熟，太喜欢炫技，我也左耳朵进右耳朵出。最近做某公司的推荐项目，我基本想都不想，就要上time SVD++做baseline，对数据也基本不做太多分析，对业务也是不屑一顾的，非常依赖feature selection算法以及高维非线性模型。 在以前kdd cup或者recsys等比赛中，也是直接上定制化的SVD，把所有数据建模在一个式子里跑SGD草草完事。 做阿里比赛最开始我也是没做太多数据分析，直接上的implicit feedback，sigmoid处理正负反馈，time SVD++以及各种复杂的处理方式。与其说是解决问题，不如是说炫技。当然结果也非常惨，只有4%。 后来才开始认真思考这个比赛的问题。品牌推荐和普通推荐到底有什么区别？打个比方，用户在一个月后会看自己以前有交互的电影的只有1%。而用户在一个月后会买自己以前有交互的品牌的却有20%。CF着力的是那没有交互行为的80%的品牌。除此外800用户，对用户的factor的估计，还是加入temporal dynamic稀释的，又能有多准呢？ 所以除了算者说的那些点外，光就这一点基本就可以判定CF在赛季1的不适合了。 这样的问题，只要好好想想就能想通的，可笑的是我第一二周还在所谓的“巧妙模型”上花费了大量的力气。这个让我反思了很久。 用我室友说我的，便是我太迷信算法了，瞧不起用excel写统计的，也瞧不起做简单数据分析然后跑简单模型的人。 这便是我在比赛中获得的教训，也是我和我同实验室的朋友在回家路上所总结的。 说实在，这个比赛我也没有太多精力参加，赛季二估计也只能每周花1天来做，毕竟实验室项目太多。所以估计最后也拿不到特别好的名次。但我觉得，这次比赛前几周给我带来的教训，便已经让我非常有收获了，至少我现在对于机器学习算法以及业务关系的理解，和比赛前已经有了很大的不同。 我现在是单挑，考虑到赛季2最近也找了一个队友，他貌似有两个小号。我也给他发短信让他回学校后赶快发邮件把这些号注销了并入我的队，毕竟也算占着前500的坑，注销了也让更多的队能进入前500。也希望其他队的朋友也再接再厉，在比赛中真正得到一些领悟和经验。愿大家都能做出更好的推荐，进一步加深对机器学习的理解 ^_^ 顺便给大家讲个竞赛的小段子开心开心=w= “阿里的比赛，有个学弟找我合了下数据，做到38名。他觉得很开心，就跟他导师说了。他导师说，才38名啊，做不到前3名就别参加竞赛丢他脸。听到这事我当时就呵呵了，you can you up，no can no bb。我导师就好多了，他要是知道我在做竞赛而不干活，不管几名肯定把我剁了。”

成为一名合格的开发工程师不是一件简单的事情，需要掌握从开发到调试到优化等一系列能力，这些能力中的每一项掌握起来都需要足够的努力和经验。而要成为一名合格的机器学习算法工程师（以下简称算法工程师）更是难上加难，因为在掌握工程师的通用技能以外，还需要掌握一张不算小的机器学习算法知识网络。 下面我们就将成为一名合格的算法工程师所需的技能进行拆分，一起来看一下究竟需要掌握哪些技能才能算是一名合格的算法工程师。 1.基础开发能力 所谓算法工程师，首先需要是一名工程师，那么就要掌握所有开发工程师都需要掌握的一些能力。 有些同学对于这一点存在一些误解，认为所谓算法工程师就只需要思考和设计算法，不用在乎这些算法如何实现，而且会有人帮你来实现你想出来的算法方案。这种思想是错误的，在大多数企业的大多数职位中，算法工程师需要负责从算法设计到算法实现再到算法上线这一个全流程的工作。 笔者曾经见过一些企业实行过算法设计与算法实现相分离的组织架构，但是在这种架构下，说不清楚谁该为算法效果负责，算法设计者和算法开发者都有一肚子的苦水，具体原因不在本文的讨论范畴中，但希望大家记住的是，基础的开发技能是所有算法工程师都需要掌握的。 2.概率和统计基础 概率和统计可以说是机器学习领域的基石之一，从某个角度来看，机器学习可以看做是建立在概率思维之上的一种对不确定世界的系统性思考和认知方式。学会用概率的视角看待问题，用概率的语言描述问题，是深入理解和熟练运用机器学习技术的最重要基础之一。 概率论内容很多，但都是以具体的一个个分布为具体表现载体体现出来的，所以学好常用的概率分布及其各种性质对于学好概率非常重要。 对于离散数据，伯努利分布、二项分布、多项分布、Beta分布、狄里克莱分布以及泊松分布都是需要理解掌握的内容； 对于离线数据，高斯分布和指数分布族是比较重要的分布。这些分布贯穿着机器学习的各种模型之中，也存在于互联网和真实世界的各种数据之中，理解了数据的分布，才能知道该对它们做什么样的处理。 此外，假设检验的相关理论也需要掌握。在这个所谓的大数据时代，最能骗人的大概就是数据了，掌握了假设检验和置信区间等相关理论，才能具备分辨数据结论真伪的能力。例如两组数据是否真的存在差异，上线一个策略之后指标是否真的有提升等等。这种问题在实际工作中非常常见，不掌握相关能力的话相当于就是大数据时代的睁眼瞎。 在统计方面，一些常用的参数估计方法也需要掌握，典型的如最大似然估计、最大后验估计、EM算法等。这些理论和最优化理论一样，都是可以应用于所有模型的理论，是基础中的基础。 3.机器学习理论 虽然现在开箱即用的开源工具包越来越多，但并不意味着算法工程师就可以忽略机器学习基础理论的学习和掌握。这样做主要有两方面的意义： 掌握理论才能对各种工具、技巧灵活应用，而不是只会照搬套用。只有在这个基础上才能够真正具备搭建一套机器学习系统的能力，并对其进行持续优化。否则只能算是机器学习搬砖工人，算不得合格的工程师。出了问题也不会解决，更谈不上对系统做优化。 学习机器学习的基础理论的目的不仅仅是学会如何构建机器学习系统，更重要的是，这些基础理论里面体现的是一套思想和思维模式，其内涵包括概率性思维、矩阵化思维、最优化思维等多个子领域，这一套思维模式对于在当今这个大数据时代做数据的处理、分析和建模是非常有帮助的。如果你脑子里没有这套思维，面对大数据环境还在用老一套非概率的、标量式的思维去思考问题，那么思考的效率和深度都会非常受限。 机器学习的理论内涵和外延非常之广，绝非一篇文章可以穷尽，所以在这里我列举了一些比较核心，同时对于实际工作比较有帮助的内容进行介绍，大家可在掌握了这些基础内容之后，再不断探索学习。 4.开发语言和开发工具 掌握了足够的理论知识，还需要足够的工具来将这些理论落地，这部分我们介绍一些常用的语言和工具。 5.架构设计 最后我们花一些篇幅来谈一下机器学习系统的架构设计。 所谓机器学习系统的架构，指的是一套能够支持机器学习训练、预测、服务稳定高效运行的整体系统以及他们之间的关系。 在业务规模和复杂度发展到一定程度的时候，机器学习一定会走向系统化、平台化这个方向。这个时候就需要根据业务特点以及机器学习本身的特点来设计一套整体架构，这里面包括上游数据仓库和数据流的架构设计，以及模型训练的架构，还有线上服务的架构等等。这一套架构的学习就不像前面的内容那么简单了，没有太多现成教材可以学习，更多的是在大量实践的基础上进行抽象总结，对当前系统不断进行演化和改进。但这无疑是算法工程师职业道路上最值得为之奋斗的工作。在这里能给的建议就是多实践，多总结，多抽象，多迭代。 6.机器学习算法工程师领域现状 现在可以说是机器学习算法工程师最好的时代，各行各业对这类人才的需求都非常旺盛。典型的包括以下一些细分行业： 推荐系统。推荐系统解决的是海量数据场景下信息高效匹配分发的问题，在这个过程中，无论是候选集召回，还是结果排序，以及用户画像等等方面，机器学习都起着重要的作用。 广告系统。广告系统和推荐系统有很多类似的地方，但也有着很显著的差异，需要在考虑平台和用户之外同时考虑广告主的利益，两方变成了三方，使得一些问题变复杂了很多。它在对机器学习的利用方面也和推荐类似。 搜索系统。搜索系统的很多基础建设和上层排序方面都大量使用了机器学习技术，而且在很多网站和App中，搜索都是非常重要的流量入口，机器学习对搜索系统的优化会直接影响到整个网站的效率。 风控系统。风控，尤其是互联网金融风控是近年来兴起的机器学习的又一重要战场。不夸张地说，运用机器学习的能力可以很大程度上决定一家互联网金融企业的风控能力，而风控能力本身又是这些企业业务保障的核心竞争力，这其中的关系大家可以感受一下。 但是所谓“工资越高，责任越大”，企业对于算法工程师的要求也在逐渐提高。整体来说，一名高级别的算法工程师应该能够处理“数据获取数据分析模型训练调优模型上线”这一完整流程，并对流程中的各种环节做不断优化。一名工程师入门时可能会从上面流程中的某一个环节做起，不断扩大自己的能力范围。 除了上面列出的领域以外，还有很多传统行业也在不断挖掘机器学习解决传统问题的能力，行业的未来可谓潜力巨大。

MongoDB ACID事务支持 这里要有一定的关系型数据库的事务的概念，不然不一定能理解的了这里说的事务概念。 下面说一说MongoDB的事务支持，这里可能会有疑惑，前面我们在介绍MongoDB时，说MongoDB是一个NoSQL数据库，不支持事务。这里又介绍MongoDB的事务。这里要说明一下MongoDB的事务支持跟关系型数据库的事务支持是两码事，如果你已经非常了解关系型数据库的事务，通过下面一副图对比MongoDB事务跟MySQL事务的不同之处。 MongoDB是如何实现事务的ACID？ 1）MongoDB对原子性（Atomicity）的支持 原子性在Mongodb中到底是一个什么概念呢？为什么说支持但又说Mongodb的原子性是单行/文档级原子性，这里提供了一个MongoDB更新语句样例，如下图： MongoDB是如何实现事务的ACID？ 更新“username”等于“tj.tang”的文档，更新salary、jobs、hours字段。这里对于这三个字段Mongodb在执行时要么都更新要么都不更新，这个概念在MySQL中可能你没有考虑过，但在MongoDB中由于文档可以嵌套子文档可以很复杂，所以Mongodb的原子性叫单行/文档级原子性。 对于关系型数据库的多行、多文档、多语句原子性目前Mongodb是不支持的，如下情况： MongoDB是如何实现事务的ACID？ MongoDB更新条件为工资小于50万的人都把工资调整为50万，这就会牵扯到多文档更新原子性。如果当更新到Frank这个文档时，出现宕机，服务器重启之后是无法像关系型数据库那样做到数据回滚的，也就是说处理这种多文档关系型数据库事务的支持，但MongoDB不支持。那么怎么解决Mongodb这个问题呢？可以通过建模，MongoDB不是范式而是反范式的设计，通过大表和小表可以把相关的数据放到同一个文档中去。然后通过一条语句来执行操作。 2）MongoDB对一致性（consistency）的支持 对于数据一致性来说，传统数据库（单机）跟分布式数据库（MongoDB）对于数据一致性是不太一样的，怎么理解呢？如下图： MongoDB是如何实现事务的ACID？ 对于传统型数据库来说，数据一致性主要是在单机上，单机的问题主要是数据进来时的规则检验，数据不能被破坏掉。而在分布式数据库上，因为他们都是多节点分布式的，我们讲的一致性往往就是讲的各个节点之间的数据是否一致。而MongoDB在这点上做的还是不错的，MongoDB支持强一致性或最终一致性（弱一致性），MongoDB的数据一致性也叫可调一致性，什么意思呢？如下图： MongoDB是如何实现事务的ACID？ MongoDB的可调一致性，也就是可以自由选择强一致性或最终一致性，如果你的应用场景是前台的方式可以选择强一致性，如果你的应用场景是后台的方式（如报表）可以选择弱一致性。 一致性 上面我们讲到了通过将数据冗余存储到不同的节点来保证数据安全和减轻负载，下面我们来看看这样做引发的一个问题：保证数据在多个节点间的一致性是非常困难的。在实际应用中我们会遇到很多困难，同步节点可能会故障，甚至会无法恢复，网络可能会有延迟或者丢包，网络原因导致集群中的机器被分隔成两个不能互通的子域等等。在NoSQL中，通常有两个层次的一致性：第一种是强一致性，既集群中的所有机器状态同步保持一致。第二种是最终一致性，既可以允许短暂的数据不一致，但数据最终会保持一致。我们先来讲一下，在分布式集群中，为什么最终一致性通常是更合理的选择，然后再来讨论两种一致性的具体实现结节。 关于CAP理论 为什么我们会考虑削弱数据的一致性呢？其实这背后有一个关于分布式系统的理论依据。这个理论最早被Eric Brewer提出，称为CAP理论，尔后Gilbert和Lynch对CAP进行了理论证明。这一理论首先把分布式系统中的三个特性进行了如下归纳： 一致性（C）：在分布式系统中的所有数据备份，在同一时刻是否同样的值。 可用性（A）：在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。 分区容忍性（P）：集群中的某些节点在无法联系后，集群整体是否还能继续进行服务。 而CAP理论就是说在分布式存储系统中，最多只能实现上面的两点。而由于当前的网络硬件肯定会出现延迟丢包等问题，所以分区容忍性是我们必须需要实现的。所以我们只能在一致性和可用性之间进行权衡，没有NoSQL系统能同时保证这三点。 要保证数据强一致性，最简单的方法是令写操作在所有数据节点上都执行成功才能返回成功，也就是同步概念。而这时如果某个结点出现故障，那么写操作就成功不了了，需要一直等到这个节点恢复。也就是说，如果要保证强一致性，那么就无法提供7×24的高可用性。 而要保证可用性的话，就意味着节点在响应请求时，不用完全考虑整个集群中的数据是否一致。只需要以自己当前的状态进行请求响应。由于并不保证写操作在所有节点都写成功，这可能会导致各个节点的数据状态不一致。 CAP理论导致了最终一致性和强一致性两种选择。当然，事实上还有其它的选择，比如在Yahoo的PNUTS中，采用的就是松散的一致性和弱可用性结合的方法。但是我们讨论的NoSQL系统没有类似的实现，所以我们在后续不会对其进行讨论。 强一致性 强一致性的保证，要求所有数据节点对同一个key值在同一时刻有同样的value值。虽然实际上可能某些节点存储的值是不一样的，但是作为一个整体，当客户端发起对某个key的数据请求时，整个集群对这个key对应的数据会达成一致。下面就举例说明这种一致性是如何实现的。 假设在我们的集群中，一个数据会被备份到N个结点。这N个节点中的某一个可能会扮演协调器的作用。它会保证每一个数据写操作会在成功同步到W个节点后才向客户端返回成功。而当客户端读取数据时，需要至少R个节点返回同样的数据才能返回读操作成功。而NWR之间必须要满足下面关系：R＋W>N 下面举个实在的例子。比如我们设定N＝3（数据会备份到A、B、C三个结点）。比如值 employee30:salary 当前的值是20000，我们想将其修改为30000。我们设定W＝2，下面我们会对A、B、C三个节点发起写操作（employee30:salary, 30000），当A、B两个节点返回写成功后，协调器就会返回给客户端说写成功了。至于节点C，我们可以假设它从来没有收到这个写请求，他保存的依然是20000那个值。之后，当一个协调器执行一个对employee30:salary的读操作时，他还是会发三个请求给A、B、C三个节点： 如果设定R＝1，那么当C节点先返回了20000这个值时，那我们客户端实际得到了一个错误的值。 如果设定R＝2，则当协调器收到20000和30000两个值时，它会发现数据不太正确，并且会在收到第三个节点的30000的值后判断20000这个值是错误的。 所以如果要保证强一致性，在上面的应用场景中，我们需要设定R＝2，W＝2 如果写操作不能收到W个节点的成功返回，或者写操作不能得到R个一致的结果。那么协调器可能会在某个设定的过期时间之后向客户端返回操作失败，或者是等到系统慢慢调整到一致。这可能就导致系统暂时处于不可用状态。 对于R和W的不同设定，会导致系统在进行不同操作时需要不同数量的机器节点可用。比如你设定在所有备份节点上都写入才算写成功，既W＝N，那么只要有一个备份节点故障，写操作就失败了。一般设定是R＋W = N+1，这是保证强一致性的最小设定了。一些强一致性的系统设定W＝N，R＝1，这样就根本不用考虑各个节点数据可能不一致的情况了。 HBase是借助其底层的HDFS来实现其数据冗余备份的。HDFS采用的就是强一致性保证。在数据没有完全同步到N个节点前，写操作是不会返回成功的。也就是说它的W＝N，而读操作只需要读到一个值即可，也就是说它R＝1。为了不至于让写操作太慢，对多个节点的写操作是并发异步进行的。在直到所有的节点都收到了新的数据后，会自动执行一个swap操作将新数据写入。这个操作是原子性和一致性的。保证了数据在所有节点有一致的值。 最终一致性 像Voldemort，Cassandra和Riak这些类Dynamo的系统，通常都允许用户按需要设置N，R，W三个值，即使是设置成W＋R<= N也是可以的。也就是说他允许用户在强一致性和最终一致性之间自由选择。而在用户选择了最终一致性，或者是W 3）MongoDB对隔离性（isolation）的支持 在关系型数据库中，SQL2定义了四种隔离级别，分别是READ UNCOMMITTED、READ COMMITTED、REPEATABLE READ和SERIALIZABLE。但是很少有数据库厂商遵循这些标准，比如Oracle数据库就不支持READ UNCOMMITTED和REPEATABLE READ隔离级别。而MySQL支持这全部4种隔离级别。每一种级别都规定了一个事务中所做的修改，哪些在事务内核事务外是可见的，哪些是不可见的。为了尽可能减少事务间的影响，事务隔离级别越高安全性越好但是并发就越差；事务隔离级别越低，事务请求的锁越少，或者保持锁的时间就越短，这也就是为什么绝大多数数据库系统默认的事务隔离级别是RC。 下图展示了几家不同的数据库厂商的不同事物隔离级别。 MongoDB是如何实现事务的ACID？ MongoDB在3.2之前使用的是“读未提交”，这种情况下会出现“脏读”。但在MongoDB 3.2开始已经调整为“读已提交”。 下面说说每种隔离级别带来的问题： READ-UNCOMMITTED（读尚未提交的数据） 在这个级别，一个事务的修改，即使没有提交，对其他事务也都是可见的。事务可以读取未提交的数据，这也被称为“脏读（dirty read）”。这个级别会导致很多问题，从性能上来说，READ UNCOMMITTED不会比其他的级别好太多，但却缺乏其他级别的很多好处，除非真的有非常必要的理由，在实际应用中一般很少使用。 READ-COMMITTED（读已提交的数据） 在这个级别，能满足前面提到的隔离性的简单定义：一个事务开始时，只能“看见”已经提交的事务所做的修改。换句话说，一个事务从开始直到提交之前，所做的任何修改对其他事务都是不可见的。这个级别有时候也叫“不可重复读（non-repeatable read）”，因为两次执行同样的查询，可能会得到不一样的结果。 REPEATABLE-READ（可重复读） 在这个级别，保证了在同一个事务中多次读取统一记录的结果是一致的。MySQL默认使用这个级别。InnoDB和XtraDB存储引擎通过多版本并发控制MVCC（multiversion concurrency control）解决了“幻读”和“不可重复读”的问题。通过前面的学习我们知道RR级别总是读取事务开始那一刻的快照信息，也就是说这些数据数据库当前状态，这在一些对于数据的时效特别敏感的业务中，就很可能会出问题。 SERIALIZABLE（串行化） 在这个级别，它通过强制事务串行执行，避免了前面说的一系列问题。简单来说，SERIALIZABLE会在读取的每一行数据上都加锁，所以可能导致大量的超时和锁争用的问题。实际应用中也很少在本地事务中使用SERIALIABLE隔离级别，主要应用在InnoDB存储引擎的分布式事务中。 4）MongoDB对持久性（durability）的支持 对于数据持久性来说，在传统数据库中（单机）的表现为服务器任何时候发生宕机都不需要担心数据丢失的问题，因为有方式可以把数据永久保存起来了。一般都是通过日志来保证数据的持久性。通过下图来看一下传统数据库跟MongoDB对于数据持久性各自所使用的方式。 MongoDB是如何实现事务的ACID？ 从上图可以看出，MongoDB同样是使用数据进来先写日志（日志刷盘的速度是非常快）然后在写入到数据库中的这种方式来保证数据的持久性，如果出现服务器宕机，当启动服务器时会从日志中读取数据。不同的是传统数据库这种方式叫做“WAL” Write-Ahead Logging（预写日志系统），而MongoDB叫做“journal”。此外MongoDB在数据持久性上这点可能做的更好，MongoDB的复制默认节点就是三节点以上的复制集群，当数据到达主节点之后会马上同步到从节点上去。

首先，我们先来聊聊各类数据模型。下列相关信息参考自Emil Eifrem的博文及NoSQL数据库说明。文档类数据库传承:受Lotus Notes启发而来。数据模型:文档汇总，包括键-值汇总。实例: CouchDB, MongoDB优势: 数据建模自然、程序员易于上手、开发流程短、兼容网页模式、便于达成CRUD（即添加、查询、更新及删除的简称）。图形类数据库传承:来自 Euler 及图形理论。数据模型:节点及关系，二者结合能够保持键-值间的成对状态实例: AllegroGraph, InfoGrid, Neo4j优势:轻松玩转复杂的图形问题、处理速度快关系类数据库传承:源自 E. F. Codd在大型共享数据库中所提出的数据关系模型理论数据模型:以关系组为基础实例: VoltDB, Clustrix, MySQL优势:性能强大、联机事务处理系统扩展性好、支持SQL访问、视图直观、擅长处理交易关系、与程序员间的交互效果优异面向对象类数据库传承:源自图形数据库方面的研究成果数据模型: 对象实例: Objectivity, Gemstone优势:擅长处理复杂的对象模型、快速的键-值访问及键-功能访问并且兼具图形数据库的各类功能键-值存储传承: Amazon Dynamo中的paper概念及分布式hash表数据模型:对成对键-值的全局化汇总实例: Membase, Riak优势:尺寸掌控得当、擅长处理持续的小规模读写需求、速度快、程序员易于上手BigTable Clones传承自:谷歌BigTable中的paper概念数据模型:纵列群，即在某个表格模型中，每行在理论上至少可以有一套单独的纵列配置实例: HBase, Hypertable, Cassandra优势:尺寸掌控得当、擅长应对大规模写入负载、可用性高、支持多数据中心、支持映射简化数据结构类服务传承: 不明实例: Redis数据模型: 执行过程基于索引、列表、集合及字符串值优势:为数据库应用引入前所未有的新鲜血液网格类数据库传承:源自数据网格及元组空间研究数据模型:基于空间的构架实例: GigaSpaces, Coherence优势:优良的性能表现及上佳的交易处理扩展性我们该为自己的应用程序选择哪套方案？选择的关键在于重新思考我们的应用程序如何依据不同数据模型及不同产品进行有针对性的协同工作。即用正确的数据模型处理对应的现实任务、用正确的产品解决对应的现实问题。要探究哪类数据模型能够切实为我们的应用程序提供帮助，可以参考“到底NoSQL能在我们的工作中发挥什么作用？”一文。在这篇文章中，我试着将各种不同特性、不同功能的常用创建系统中的那些非常规的应用实例综合起来。将应用实例中的客观需求与我们的选择联系起来。这样大家就能够逆向分析出我们的基础架构中适合引入哪些产品。至于具体结论是NoSQL还是SQL，这已经不重要了。关注数据模型、产品特性以及自身需要。产品总是将各种不同的功能集中起来，因此我们很难单纯从某一类数据模型构成方式的角度直接找到最合用的那款。对功能及特性的需求存在优先级，只要对这种优先级具备较为清晰的了解，我们就能够做出最佳选择。如果我们的应用程序需要…复杂的交易：因为没人愿意承受数据丢失，或者大家更倾向于一套简单易用的交易编程模式，那么请考虑使用关系类或网格类数据库。例如:一套库存系统可能需要完整的ACID（即数据库事务执行四要素：原子性、一致性、隔离性及持久性）。顾客选中了一件产品却被告知没有库存了，这类情况显然容易引起麻烦。因为大多数时候，我们想要的并不是额外补偿、而只是选中的那件货品。若是以扩展性为优先，那么NoSQL或SQL都能应对自如。这种情况下我们需要关注那些支持向外扩展、分类处理、实时添加及移除设备、负载平衡、自动分类及整理并且容错率较高的系统。要求持续保有数据库写入功能，则需要较高的可用性。在这种情况下不妨关注BigTable类产品，其在一致性方面表现出众。如有大量的小规模持续读写要求，也就是说工作负载处于波动状态，可以关注文档类、键-值类或是那些提供快速内存访问功能的数据库。引入固态硬盘作为存储媒介也是不错的选择。以社交网络为实施重点的话，我们首先想到的就是图形类数据库；其次则是Riak这种关系类数据库。具备简单SQL功能的常驻内存式关系数据库基本上就可以满足小型数据集合的需求。Redis的集合及列表操作也能发挥作用。如果我们的应用程序需要…在访问模式及数据类型多种多样的情况下，文档类数据库比较值得考虑。这类数据库不仅灵活性好，性能表现也可圈可点。需要完备的脱机报告与大型数据集的话，首选产品是Hadoop，其次则是支持映射简化的其它产品。不过仅仅支持映射简化还不足以提供如Hadoop一样上佳的处理能力。如果业务跨越数个数据中心，Bigtable Clone及其它提供分布式选项的产品能够应对由地域距离引起的延迟现象，并具备较好的分区兼容性。要建立CRUD应用程序，首选文档类数据库。这类产品简化了从外部访问复杂数据的过程。需要内置搜索功能的话，推荐Riak。要对数据结构中的诸如列表、集合、队列及发布/订阅信息进行操作，Redis是不二之选。其具备的分布式锁定、覆盖式日志及其它各种功能都会在这类应用状态下大放异彩。将数据以便于处理的形式反馈给程序员（例如以JSON、HTTP、REST、Javascript这类形式），文档类数据库能够满足这类诉求，键-值类数据库效果次之。如果我们的应用程序需要…以直观视图的形式进行同步交易，并且具备实时数据反馈功能，VoltDB算得上一把好手。其数据汇总以及时间窗口化的表现都非常抢眼。若是需要企业级的支持及服务水平协议，我们需要着眼于特殊市场。Membase就是这样一个例子。要记录持续的数据流，却找不到必要的一致性保障？BigTable Clone交出了令人满意的答卷，因为其工作基于分布式文件系统，所以可以应对大量的写入操作。要让操作过程变得尽可能简单，答案一定在托管或平台即服务类方案之中。它们存在的目的正是处理这类要求。要向企业级客户做出推荐？不妨考虑关系类数据库，因为它们的长项就是具备解决繁杂关系问题的技术。如果需要利用动态方式建立对象之间的关系以使其具有动态特性，图形类数据库能帮上大忙。这类产品往往不需要特定的模式及模型，因此可以通过编程逐步建立。S3这类存储服务则是为支持大型媒体信息而生。相比之下NoSQL系统则往往无法处理大型二进制数据块，尽管MongoDB本身具备文件服务功能。如果我们的应用程序需要…有高效批量上传大量数据的需求？我们还是得找点有对应功能的产品。大多数产品都无法胜任，因为它们不支持批量操作。文档类数据库或是键－值类数据库能够利用流畅的模式化系统提供便捷的上传途径，因为这两类产品不仅支持可选区域、添加区域及删除区域，而且无需建立完整的模式迁移框架。要实现完整性限制，就得选择一款支持SQL DLL的产品，并在存储过程或是应用程序代码中加以运行。对于协同工作极为依赖的时候就要选择图形类数据库，因为这类产品支持在不同实体间的迅速切换。数据的移动距离较短且不必经过网络时，可以在预存程序中做出选择。预存程序在关系类、网格类、文档类甚至是键-值类数据库中都能找到。如果我们的应用程序需要…键-值存储体系擅长处理BLOB类数据的缓存及存储问题。缓存可以用于应对网页或复杂对象的存储，这种方案能够降低延迟、并且比起使用关系类数据库来说成本也较低。对于数据安全及工作状态要求较高的话可以尝试使用定制产品，并且在普遍的工作范畴（例如向上扩展、调整、分布式缓存、分区及反规范化等等）之外一定要为扩展性（或其它方面）准备解决方案。多样化的数据类型意味着我们的数据不能简单用表格来管理或是用纵列来划分，其复杂的结构及用户组成（也可能还有其它各种因素）只有文档类、键-值类以及Bigtable Clone这些数据库才能应付。上述各类数据库都具备极为灵活的数据类型处理能力。有时其它业务部门会需要进行快速关系查询，引入这种查询方式可以使我们不必为了偶尔的查看而重建一切信息。任何支持SQL的数据库都能实现这类查询。至于在云平台上运行并自动充分利用云平台的功能——这种美好的愿望目前还只能是愿望。如果我们的应用程序需要…支持辅助索引，以便通过不同的关键词查找数据，这要由关系类数据库及Cassandra推出的新辅助索引系统共同支持才能实现。创建一套处于不断增长中的数据集合（真正天文数量级的数据）然而访问量却并不大，那么Bigtable Clone是最佳选择，因为它会将数据妥善安排在分布式文件系统当中。需要整合其它类型的服务并确保数据库提供延后写入同步功能？那最好的实现方式是捕捉数据库的各种变化并将其反馈到其它系统中以保障运作的一致性。通过容错性检查了解系统对供电中断、隔离及其它故障情况的适应程度。若是当前的某项技术尚无人问津、自己却感觉大有潜力可挖，不妨在这条路上坚持走下去。这种情况有时会带来意料之外的美好前景。尝试在移动平台上工作并关注CouchDB及移动版couchbase。哪种方案更好？25%的状态改善尚不足以让我们下决心选择NoSQL。选择标准是否恰当取决于实际情况。这类标准对你的方案有指导意义吗？如果你的公司尚处于起步阶段，并且需要尽快推出自己的产品，这时不要再犹豫不决了。无论是SQL还是NoSQL都可以作为参考。

【丁宁-清华大学-阿里达摩院自然语言技术实习体验】 作者简介：丁宁，清华大学计算机科学与技术系2年级博士生，研究方向为自然语言处理、信息抽取、语言表示学习等，在ACL、EMNLP、AAAI、IJCAI等发表多篇文章，作为研究型实习生在阿里达摩院实习半年+。 实习体会 很幸运能来到阿里巴巴进行实习！组里的氛围特别好，同事和师兄师姐都非常专业、友善、亲切。无论是科研上还是工作生活上的任 何问题，都能得到慷慨的帮助。在这里，我认识了一批学术和生活上的榜样（我的主管每天都吃健康餐，而我牛肉汤泡饼），结交了志同道合的朋友（排队喝牛肉汤回来写论文的日子），见识到了IT同学的认真负责（远程帮我调试打印机，周末修电脑），见过了马云老师，也亲身经历了一次双十一奋战。阿里的科研积淀和文化氛围都让我感到收获颇丰，感谢阿里巴巴提供研究型实习生这一高水平项目，也期待更多的同学可以加入研究型实习生的大家庭。 科研心得& 工作宣传 今年在阿里巴巴所做的跨领域分词工作被ACL 2020高分接收，其中meta review说“well-written, well-motivated with strong results, sure accept”。其实这句话可以很好地总结评判科研论文好坏的标准，实际上或许现阶段的科研也并没有什么秘密，动机明确、方法得当、实验充分，就可以形成一篇不错的科研论文。当然了，如果想做出让领域内眼前一亮的工作，可能就需要一些灵光一闪了。 具体到我们的工作上来，跨领域任务往往面临目标领域精标注数据缺失的问题，具体到分词任务上来说，这种数据缺失往往会导致OOV和词的分布差异问题。本文通过弱监督启发式算法来进行远程标注，并引入对抗学习来进行降噪。本文的实验中以newswire (新闻语料)作为源领域，在5个不同的目标领域数据上都取得了较好的效果。 这个工作或许有助于我们真正的往跨领域的两个通用问题上去设计了相关的解决办法。论文名字:《Coupling Distant Annotation and Adversarial Training for Cross-Domain Chinese Word Segmentation》，具体可以查看达摩院的官方宣传~：ACL 2020有哪些值得关注的论文？ - 阿里巴巴达摩院的回答 - 知乎https://www.zhihu.com/question/385259014/answer/1190808208 另外，也宣传一下作为co-author的另一篇ACL 2020论文，是实习生同事周洁（上海交大研究生）的工作，瞄准多层级文本分类任务，设计层级敏感编码器将多层结构作为有向图建模，并且实现了一个串行和并行的版本，论文名字：Hierarchy-Aware Global Model for Hierarchical Text Classification。 还有另一个实习生同事张浩宇（国防科大博士生）在IJCAI 2020的工作，使用noisy learning的方法去进行远程监督entity typing降噪，方法非常优雅，论文名字：Learning with Noise: Improving Distantly-Supervised Fine-grained Entity Typing via Automatic Relabeling。 【杜志浩-哈尔滨工业大学-我在达摩院作实习研究僧的那些事儿】 经韩老师介绍，2019年7月，有幸进入阿里巴巴达摩院成为一名实习研究僧。如今也已半年有余，期间发生的事情仍然历历在目。从初出茅庐的不安，到积极融入的快乐，再到宠辱不惊的泰然，一路走来收获良多! 初出茅庐 其实，刚到达摩院语音算法组时，我的内心充满了不安。这种不安来自于初出茅庐的不自信，不知自己能否胜任这份工作，为公司带来效益。同时，也来自于环境转变的不适应，换了一个全新的环境，对公司内的工作方式、待人接物都不甚了解。 但是，在算法组师兄师姐的帮助下，我的这些不安很快就烟消云散了。为了能够使我尽快熟悉工作内容、了解工作方式，雷鸣师兄坚持每周四晚上为实习生开组会，拉着仕良哥、智颖等很多小伙伴一起讨论算法思路和实验中遇到的问题。我想他们应该都挺忙的吧，但还是牺牲自己休息的时间来参加组会。 刚来的那段时间，除了“雷老师，xxx麻烦审批通过一下”以外，我说的最多的恐怕就是“xx姐/哥，xxx在哪”。由于对很多事情都不了解，比如服务器怎么申请啊，oss怎么弄啊，我总是要麻烦逍北姐、遥仙哥等目之所及的小伙伴。他们一边在忙自己的工作一边还不厌其烦的告诉我，为我提供了莫大的帮助。 积极融入 在算法组这段时间，让我印象最为深刻的一句话就是“我们做事情都很直接，有什么问题，就带着方案提出来”。以前，总是被教育和鼓励发现问题，在阿里，找到问题只是完成了第一步，还需要再提出一个切实可行的解决方案。期间发生的一段小插曲让我现在依然记忆犹新。  为了准备910，语音测试组的小伙伴每天都在紧张的进行测试。其中一项是对语音实时转录及翻译软件的稳定性测试。由于已经进入应用阶段，不能在直接将数据送入到模型中，需要将语音播放出来，再由软件录音进行测试。播放的内容是马老师的演讲，对于坐在旁边的小伙伴来说既是一件好事，也是一件坏事。由于马老师的演讲实在太引人入胜了，每次他们进行测试时，我们都无法专心工作，最终只能……。 咳咳，我心想，这么下去也不是事儿啊，梦想要有，生活也得继续啊，得想想办法解决一下这个问题。我尝试了各种办法，但似乎都无法绕过功放这个问题。最终功夫不负有心人，找到了一款虚拟声卡的软件，能够将一个应用程序的音频输出直接作为另一个应用程序的输入。在熟悉过这个软件的使用方式后，我找到测试组的组长，向他提出了我现在的处境和解决方案。他告诉我，他也知道这样会打扰到周边的人，但是之前也没有太好的办法，感谢我提出的解决方案。 虽然这只是实习期间的一段小插曲，但是我依然印象深刻。通过这件事，我践行了带着方案提问题，这一阿里人所特有的工作方式，让我感觉自己正在逐渐融入到这个集体当中。 宠辱不惊 经过几个月“死去”又“活来”的做实验、写论文，我跟雷鸣师兄合作的语音增强相关工作投稿到了ICASSP 2020。这是语音信号处理领域的顶级会议，在来阿里之前，我也投稿过一次，但不幸被拒。为了准备这篇文章，雷鸣师兄跟我保持着很高互动，了解实验进度，适时的进行指导。此外，还有仕良哥帮助我进行语音畸变的评估。 2020年1月25日这一天，是我国的传统节日，春节，同时也是ICASSP出结果的日子。在得知结果前，我的内心非常忐忑。但当得知接收的喜讯时，我反而没有想象中那么兴奋，没有想象中那么高兴。我的第一反应是看看审稿人的意见，看看我专家们对我文章的看法，还有哪些不足和需要改进的地方。 我想宠辱不惊的心态应该是我在阿里的一个重要收获吧，不以物喜不以己悲。尽力做好自己该做的事儿，结果自然水到渠成。 再说两句 在阿里的这段实习使我受益匪浅。这里有乐于助人、善解人意的师兄师姐，也有认真负责、要求严格的主管Leader；有弹性自由的工作时间，也有肝到深夜的满腔热情；有最新最热的研究成果，也有成熟稳定的应用软件。这里不像实验室的象牙塔，关注技术的同时，也更关注技术如何落地、如何应用到生活中去，最终如何造福亿万用户。 韩鹏-KAUST-青春没有我之阿里巴巴天猫精灵争夺赛被迫写的研究心得 竞选宣言： 在阿里实习摸了几个月的鱼，最开心的就是又吃到了祖国的美食，虽然杭州的食物实在是太清淡了，但总比我在沙特每天吃水煮青菜不放盐要好很多。在阿里的这几个月，让我看淡了很多，发现生命里比较重要的就是长在自己脑袋上的头发，不能太年轻就失去他们。女网红我是感觉自己这辈子没机会了，毕竟流量明星也不是靠推荐算法能捧红的，也就希望能够得到这次500块钱的天猫精灵，请大家pick我。 研究心得： 多抱大腿 为了凑足300字的内心情感白描： 这个世界实在是太无聊了，尤其疫情导致的只能居家办公，我已经憋得快精神失常了，虽然平时也不是那么正常。希望这个世界早日恢复原来的美好，我还打算去越南胡志明市的日式KTV感受一下女仆装呢，希望疫情不会让这些服务业倒闭呢吧。 居然还不够300字，感觉生命浪费在写文字上要比大保健上还是好一些的，希望这些文字能够启发你，虽然我感觉也并没有什么意义，而人活着的意义又是什么呢？ 【韩镕罄-南加州大学- 阿里研究型实习生体验】 简介： 经过两年研究时间，找到了学校的教职，也找到了老婆，感谢阿里～ 2018年八月来阿里做研究型实习生，本人在南加州大学商学院读Operations Management 的Ph.D. 块两年时间做了几篇 field experiment paper， 感觉阿里有太多好玩有趣的商业问题可以讨论直接研究。 通过和阿里的合作顺利找到UIUC 伊利诺伊大学香槟分校的常任轨教职。 更神奇的是，在实习期间，随便刷个阿里妹儿的相亲帖， 加个微信 聊一聊 发现和自己一天生日。 就是你了！现在已经结婚快半年！ 三十而立，一切静好，感谢阿里！ 【马腾-清华大学- 阿里巴巴RI项目心得】 我与阿里之缘 在2019年的夏天，后来成为我主管的文侑来到清华进行交流，当时的我刚刚完成了一个学术项目的研究，正在寻求于之后的研究方向。恰好在交流会上碰见了文侑，经过一番交流之后吗，了解到操作系统团队是阿里 RDMA 技术的先行者和推广者，这正是我计划之后想要研究的方向，于是便一拍即合。由于我之前所研究的领域刚好符合是阿里目前正在做的一些项目，所以文侑提供了一个可以在阿里实习的机会。 在通过了多轮面试之后，我终于成功的入职了操作系统内核组作为学术型实习生。从2018年九月初入职至今，将近两年的时间，我也逐渐地适应了在阿里的生活，松弛有度而又充满欢乐。在这里我也结识了许多要好的朋友，并且，通过公司组织的各种聚会和团建的活动，让我解释了许多有着共同语言爱好的伙伴，大家给与了我这个新人很多的帮助和照顾，使我也渐渐地融入了这个有爱的团队。 在阿里的学术成果 在阿里实习期间，在同事们的帮助下，我顺利地完成了两个与我所在实验室合作的学术项目，并且这两个项目也幸运的产出了两篇高质量的论文，分别发表在了不同领域的高水平会议当中。 其中，第一篇论文发表在第21届Cluster会议，与2019年在美国阿尔伯克基召开。Cluster 是高性能计算方向计算机系统领域的主要会议，这个工作提出并实现了统一高效的 RDMA 消息中间件，解决了 RDMA 在实际生产过程中的一些关键可靠性和可用性问题，例如：极简的接口抽象，必要的上层消息确认机制，中间件辅助流控配合 DCQCN，结合生产系统的诊断机制等等，目前该技术已经被广泛应用在阿里巴巴基础云产品中（包括：数据库，分布式存储等）。另外一个工作则发表在了第25届 ASPLOS会议。ASPLOS 是操作系统，体系结构和编程语言三个方向综合的计算机系统领域顶级会议。这篇论文是和我所在的清华高性能所合作完成的，文章中第一次提出了利用RDMA将数据中心的NVM做disaggregation, 实现了高效的框架，同时证明了这种新架构的可行性。 在阿里的感想 阿里巴巴操作系统团队是一直致力于建立和完善系统领域工业界和学术界的纽带，并且在持续实践工业界和学术界之间的问题分享和工作互动，他们希望通过这些分析和互动能够更好地促进中国在世界计算机系统领域的整体发展和创新。作为操作系统团队中的一员，我深切了解到了先进技术对于企业发展的重要性，在实习的过程中，同我所在的实验室进行合作，我更是深深感受到只有通过学术与工业相辅相成，才能够真正让企业发展先进技术。另外一方面，经过一段时间的实习，我对所在的操作系统团队和阿里技术部门的工作有了更深入的了解，我对自己也有了进一步的规划，计划在毕业之后能够入职阿里，通过我的努力，继续在追逐技术之路上奋斗着。 【亓家鑫-新加坡南洋理工大学- 阿里云实习心得】 非常荣幸我们的研究工作*《Two causal principles for improving visual dialog》*获得了同行的认可，并收录在CVPR 2020会议中。在此要特别感谢我的教授，MReaL实验室成员以及阿里城市大脑实验室师兄师姐一直以来的支持和帮助。比起论文本身的内容，我更希望跟大家分享一年来做研究的心得和感悟，虽然目前我仍然是一个萌新，不过我希望通过萌新的角度能带给大家一些研究上的启发。 开始一个研究之前，选择方向很重要。当然，每一个方向都有自己的优缺点，比如新的方向“容易”发文章，可能将其他领域原有的方法引入加一些调整就可以达到比较高的结果。不过如果没有坚实的创新，在同行评议时，可能会受到质疑。一旦没有通过，再转投时可能发现已经落后于其他人。“老“的方向可能会感觉灌水困难，不过因为我没有真正做过经典的方向，所以不太好发表评论。根据观察，在一堆全面而又坚实的研究中找到创新点，对萌新来说确实困难，不过一旦有所突破，肯定会对这个社区产生广泛的影响。作为一个萌新，可能不会自己选择方向或者领域，所以接受导师或者主管的安排成了唯一的选择，不过要相信自己的导师和主管，因为大家都是在帮助你，而且他们经验丰富。只有当自己走完一套研究的流程，并且真正找到自己感兴趣或者觉得可以有所突破的方向，那可能才是真正属于自己的研究的开始。 当选定了方向，开始做研究的时候，清楚的了解所有有关的方法是非常重要的，因为这样可以防止你的idea被存在的方法“抄袭“。其实对一个比较成熟的研究方向来说，简单思考得到的idea一般都会被提出过。不过研究完所有存在方法后，要跳出这些方法，因为阅读他们的方法可能不是来借鉴，更多的是防止撞车，想要真正有创新，在别人的方法上改动往往是不够的，这就要求我们重新审视这个任务甚至数据集的每一个样本。当然目前即使是学术界toy的数据集也有动辄几十万的数据量，看完是不可能的，不过根据自己的思路统计一些数据特征，有时候对研究会产生很大的帮助。当觉得自己已经掌握了这个数据集或者这个任务的时候，应该是跑一些baseline来练习了。 我作为萌新，没有从零开始写，而是找了一个现成的模型开始修改，这样难度会减少很多，不过毕竟是别人的代码，还是有很多不舒服的地方，所以等自己成熟了的时候，有空的时候，一定要从头写一遍。当然我也不知道什么时候有空。当我开始修改baseline的时候，此次的研究旅行就算是上路了，在接受导师的指引的同时也可以自己不断的尝试自己的想法，因为不知道什么是有用的。我作为萌新刚开始的感受是我觉得可能我想的都有用，那一定要去试一下，所以我也建议大家多试一下，说不定真的有用呢，反正电费不花自己的。当一个东西有用的时候，就可以来思考他为什么有用了，当你想好它为什么有用并且通过了广泛的测试，就到了跟大家分享成果的时候。 当然，一个有用的idea背后可能有无数个没用的idea，至于他们为什么没用，我觉得如果实在是有兴趣，可以研究一下，但是有时候会花大量的时间。举一个实际的例子，我在去年做visual dialog比赛，大概四月份就发现了一个有用的方法，之后也顺利的拿到了第一并且在此基础上进行探究和扩展发表了自己的成果。不过同时，当时有一个效果降低的操作一直困扰着我，直到六个月以后，当然这六个月中还做了其他的事情，我才发现了它真正的原因，并且最终变成了我文章中的一句话。举这个例子的目的是，研究没有效果的idea会对研究有所帮助，不过可能会收益较低。 研究成果的发表是一个很重要的过程，它可以给领域内的同行以启发，甚至可以影响本领域之外的人，所以有时候高度总结自己的思想是一件有用的事情。比如我所做的工作我认为进行高度总结之后可以得到一个启发是：对多模态任务来说不一定所有模态都是平等的，对模型来说所存在模态也不一定是影响结果的全部。除了对自己motivation的总结，应用细节以及结果展示也是非常重要的，因为我是萌新，怎样写出一篇文章的经验肯定是不足的，所以在此不再赘述。在发表完文章之后，“售后服务“也是非常重要的一点，这也是我的教授教我的很重要的理念。因为发表的内容不是刊登出来就结束了，而是你对社区贡献的开始，之后做研究可能会发现更好的实现，或者当时的理论没有讲清楚完善，这些都可以补充到自己的代码中，让大家更好的了解你的思路和工作，或许以后还能收获好评。 此外，实验室的成员就是自己研究道路上的引导者和伙伴，会对自己的研究产生各种各样至关重要的影响，大多时候大家都不会吝惜跟你讨论分享自己的观点，有时还会亲自帮助你解决问题，所以要记得经常参加团建和小集体聚会。不过也不能太依赖别人，每当遇到问题的时候，特别是技术性的问题，还是依靠自己解决的好，毕竟未来总会离开实验室，离开乐于帮助你的人。最后，保护好自己的头发，还是要早睡早起，调不出来的bug熬夜也调不出来，不work的idea可能真的不work，没有人保证炼出来的一定是金子，不要过分影响正常的作息，毕竟这不是百米赛跑，也不能算是马拉松，而是长久的起码好几年以上要坚持的事业。不过我作为萌新才刚刚起步，依然没有体会到最艰难的时刻，不过做好心理准备还是应该的，该来的总是会来的。最后的最后希望这些浅显的经验总结能够给大家带来一点儿帮助，谢谢大家的阅读。 【田冰川-南京大学- 在阿里网络团队实习两年是一种怎样的体验？】 简介： 大家好！我是田冰川，南京大学2016级直博生，导师为田臣老师，研究方向为计算机网络。2018年6月，我以研究型实习生的身份入职阿里巴巴基础设施事业部网络研究团队，实习期间主要从事网络验证相关的研究工作，即通过形式化方法与灰度测试，来降低网络变更中的潜在风险。 2018年既是网络研究团队刚刚组建的一年，也是研究型实习生在阿里刚刚起步的一年。这年春天，经我导师田臣老师介绍，我参加了研究型实习生面试，加入了网络研究团队。 来到团队后，我参加的第一个研究项目是“金睛”，用以保障复杂ACL变更的正确性。ACL即访问控制列表，网络中的ACL决定着流量的连通性。网络架构演化有时会伴随着对ACL的迁移，如何保证迁移前后网络连通性是等价的，是困扰架构与运营部门的一大难题，而金睛项目则是为该问题而生。项目落地以来，金睛系统多次在骨干网ACL迁移中对变更方案进行了验证，并逐渐扩展至对边缘网络的验证。相关论文发表于SIGCOMM 2019主会，我在会场进行了20余分钟的演讲，与我们团队的另一篇文章HPCC共同成为阿里集团在网络领域top1学术会议主会中的首次亮相。 时间总是过的很快。转眼间，我来阿里已经两年了，自金睛之后，又陆续参与了多个研究课题。在阿里的时间越久，就越能切身体会到学术界研究与工业界研究的不同。在阿里实习以来，我接触到的所有研究课题，都不是凭空“想”出来的空中楼阁，更不是靠别人论文“启发”出来的二手课题，而是源自于真实业务的现阶段瓶颈与下一阶段发展趋势——这一点是高校科研很难做到的。 这两年间，我对科研这件事的心态也发生了进一步的变化。2017年，来到阿里之前，我的论文达到了学校博士毕业的最低要求，相当于没有了毕业之忧，对科研的心态从“先拿到博士学位再说”，变成了“想要做出点什么，不想让自己的博士5年就这么水过去”；在来到阿里，接触到工业界的前沿课题之后，我对科研的心态再一次发生了转变，变成“因为认可一件事的价值，所以想要去做好”——这已经成为一种内在的驱动力，让我在认真工作的同时，享受研究带来的乐趣。 如果一切顺利的话，我将于2021年6月博士毕业。能在阿里巴巴度过专属实习生的“三年醇”，想必也是人生中的一大成就了！ 【吴秉哲-北京大学- 吴师傅的博士研究课题：大数据时代的数据隐私研究方向初探】 加上本科的时间，不知不觉已经在燕园里面呆了八年了，明年不出意外应该就会离开学校去业界工作。准备最近以文章的形式梳理一下博士几年的研究以及生活的心路历程。由于内容比较分散，所以决定分为几个不同的部分。这次推送封面图片是16年骑行到加乌拉山口遥看喜马拉雅山脉的图片，而我在阿里的花名是风远，意为远处的风。希望多年之后，还有一颗少年的心，投入每天永不变。这次借着阿里内部一个活动的机会，写了今天的这篇稿子，为大家介绍一下我的thesis topic。 已经在蚂蚁实习了一年了，一年时光匆匆而过，而在蚂蚁金服度过的这段时光带给了我很多研究以及生活中的体验，这一年里学到的经验也将伴随着我之后的研究之路。 我本科四年是在数院度过，在研究生阶段决定转换方向到计算机系。博士的前两年一直在跌跌撞撞地寻找自己的研究方向，尝试过很多方向均以失败告终。终于在第三年的时候，误打误撞开始研究起机器学习的隐私保护问题并找到了很多灵感，开始沉淀了一些基本的研究工作。有一天我从一个朋友那里听到了她关于金服这边隐私保护机器学习的团队介绍，当时我就决定要到业界的前沿去看一看隐私保护的真实业界需求。在此之前，我已经在谷歌，IBM等公司有过多段实习的经历，但是在蚂蚁这一次实习经历，是与我自己研究方向最接近，也是时间最长的一次。借着这次约稿的机会，以此文简单总结一下自己过去两年在这一方向的研究。 隐私保护与共享学习 目前随着各种机器学习算法在集团的业务落地，许多隐私泄露与数据滥用的风险相继而来。 尤其是在蚂蚁金服这样一个拥有很多支付数据的企业，数据安全以及隐私保护的重要性更是不言而喻。站在商业合作的角度，如何实现不同公司或者部门之间的数据共享学习也是我所在的团队现在攻坚的一个问题。在这样一个研究背景下，我来到了蚂蚁金服的共享智能团队，开始和师兄师姐们从不同的维度对上述问题展开了深入的研究。 共享学习这样一个概念听起来很美好，但是实际落地起来却困难重重，需要考虑到上层软件算法的设计以及底层系统和硬件的优化，才有可能真正在实际的业务中兼顾效率和隐私保护强度。共享智能团队在这一方向上有着得天独厚的优势。一是领先的业务场景，在国际同行好多还停留在学术研究阶段时，我们团队已经和国内多家银行有了合作。另一个则是技术沉淀的领先。因为金服自身业务的特殊性，我们团队很早就开始了隐私保护机器学习和共享学习的布局，包括很多原始的技术沉淀，强大的工程团队以及学术预研团队。这些积累也使得我们能够很快地摸清最新的一些研究成果并能将其吸入到我们自己的系统当中。 我自己关于隐私保护机器学习的研究主要是围绕着三个层面展开，分别是理论，算法设计，以及系统和硬件优化。在理论层面，我主要针对现有的各种机器学习算法，建立相应的隐私泄露分析框架，比如我们在之前的工作中，针对一种常用的贝叶斯学习的算法根据雷尼差分隐私建立了隐私泄露的定量分析框架，我们进一步使用我们的框架和已有的一些泛化误差上界做了联系，从而能从多个角度去解释该算法的隐私泄露原因。在算法设计层面，我们针对各种已有的新兴算法以及场景，比如图神经网络，推荐系统建立了相应的共享学习算法，并利用我们的理论框架，对这些算法的隐私保护强度做了定量的评估。除开上层的理论和算法设计，底层的系统和硬件的优化同样是非常重要的一环。 在我们团队，我们主打基于硬件可信执行环境 (TEE)的机器学习serving系统，我针对我们当前这套服务系统，结合神经网络计算的一些特点，定制了该系统的一系列优化措施大大提升了整个系统的吞吐量。我也将其中一些措施注册了专利，并在前几天得到了内部的专利授权。除开上述介绍的学术研究方面的成果，我也参与了IEEE共享学习标准的制定会议，这也使得我从标准制定者的角度去更深地思考如何使用技术在未来社会中实现隐私与效率的兼顾。 总之，我自己很感谢能成为共享智能团队的一员，我在这里学到的最宝贵的经验就是详细地从上到下了解了这样一个大团队的合作与分工，学习他们是如何一步步从最初的需求分析，算法设计，到最后真正的业务落地。也很高兴和各位共享智能的同事度过自己博士生涯中很重要的一年。也非常感谢我的博士导师对我研究的无条件支持。回看博士这一路的艰辛，也是感慨万千。有点像自己之前高原骑行的经历，经历了爬到坡顶的缺氧与无力，终在转角处遇见了骑行途中最美的雪山风光。