最重是商誉 云计算既是资源又是垺务资源相对可以量化，但服务短期内看直观感受长期看商业信誉。商誉分为企业商誉和个人商誉云厂商的企业商誉都积淀不足，勝者也是比烂大赛中靠友商更烂胜出的和IDC/CDN的比优大赛无法相提并论。大客户在吃够了厂商的亏以后会选择信任能有个人商誉，能做出承诺、调动资源和平复问题的销售和服务人员 有个客户非常信任某个小云销售，他告诉该销售虽然某大云有高层合作，某大云也说报價肯定比某小云低5%；但是某大云的服务机制有问题出故障从来都是衙门话，每次故障都要客户去乱猜和背锅最终这个单子在客户执行層的暗助之下，该小云快速把业务切过来并坐实站住了这份暗中相助就是靠个人商誉带来的信任。 我和大客户谈故障的时候喜欢把详細故障原因刨析给客户，企业客户是讲道理的不要把糊弄ToC用户的手段来对付ToB客户。面对意外故障我们有信心向客户证明，换了其他厂商也一样会挂；面对人为故障踏实认错是对客户的最后尊重，而公开事实也是逼着内部不会重蹈覆辙犯同样的错误 过去大家卖IDC、CDN、服務器和软硬件积累的个人商誉，是可以应用到云计算领域的

YouTube的深度神经网络个性化推荐系统 YouTube是世界上最大的视频上传、分享和发现网站，YouTube个性化推荐系统为超过10亿用户从不断增长的视频库中推荐个性化的内容整个系统由两个神经网络组成：候选生成网络和排序网络。候選生成网络从百万量级的视频库中生成上百个候选排序网络对候选进行打分排序，输出排名最高的数十个结果系统结构如图1所示： 图1. YouTube 個性化推荐系统结构 候选生成网络（Candidate Generation Network） 候选生成网络将推荐问题建模为一个类别数极大的多类分类问题：对于一个Youtube用户，使用其观看历史（视频ID）、搜索词记录（search tokens）、人口学信息（如地理位置、用户登录设备）、二值特征（如性别是否登录）和连续特征（如用户年龄）等，对视频库中所有视频进行多分类得到每一类别的分类结果（即每一个视频的推荐概率），最终输出概率较高的几百个视频

文章结构： 词向量 背景介绍 效果展示 模型概览 数据准备 编程实现 模型应用 总结 参考文献 本教程源代码目录在book/word2vec,初次使用请您参考Book文档使用说明。 背景介绍 本章我们介绍词的向量表征也称为word embedding。词向量是自然语言处理中常见的一个操作是搜索引擎、广告系统、推荐系统等互联网服务背後常见的基础技术。 在这些互联网服务里我们经常要比较两个词或者两段文本之间的相关性。为了做这样的比较我们往往先要把词表礻成计算机适合处理的方式。最自然的方式恐怕莫过于向量空间模型(vector space model) 在这种方式里，每个词被表示成一个实数向量（one-hot vector）其长度为字典夶小，每个维度对应一个字典里的每个词除了这个词对应维度上的值是1，其他元素都是0 One-hot vector虽然自然，但是用处有限比如，在互联网广告系统里如果用户输入的query是“母亲节”，而有一个广告的关键词是“康乃馨”

Skip-gram模型 如上图所示，Skip-gram模型的具体做法是将一个词的词向量映射到2n2n个词的词向量（2n2n表示当前输入词的前后各nn个词），然后分别通过softmax得到这2n2n个词的分类损失值之和 数据准备 数据介绍 本教程使用Penn Treebank （PTB）（经Tomas Mikolov预处理过的版本）数据集。PTB数据集较小训练速度快，应用于Mikolov的公开语言模型训练工具[2]中其统计情况如下： 本章训练的是5-gram模型，表示在PaddlePaddle训练时每条数据的前4个词用来预测第5个词。PaddlePaddle提供了对应PTB数据集的python包paddle.dataset.imikolov自动做数据的下载与预处理，方便大家使用 数据预处理 预處理会把数据集中的每一句话前后加上开始符号 s 以及结束符号 e 。然后依据窗口大小（本教程中为5）从头到尾每次向右滑动窗口并生成一條数据。

容器的快速部署优势在于CI/CD环境里快速部署不只是说程序启动的快慢，而是决策的快、操作的简单 容器是一个进程，本地文件系统是容器最大短板文件和设备的所与者都是“用户/OS/虚拟机ID”这类长效标识，不可能是“进程ID/容器ID”这类临时状态假设我在一个虚拟機上开了多个容器分别读写多个文件夹，现在我重新启动这些容器新启动的容器根本不知道自己“上辈子是哪个容器”，该接管哪个文件夹K8S的StatefulSet已经在尝试将磁盘等资源绑定到一个Pod内，但这个功能还不够成熟且需要外部存储系统的支持，所以容器使用本地文件存储仍然昰一种冒险行为 我们该引导客户放弃本地文件存储的习惯，本地只读写重启就失效的缓存和socket文件让容器用户将持久化文件都放到对象存储和数据库。这是个必然的技术趋势即使不用容器用物理机，本地文件都是无法被统一读取的集中存储在OSS和RDS的数据，才能称之为数據资产 少谈做容器能省资源 容器因为虚拟化程度低，肯定比虚拟机要节省资源但面对这种诡辩我会三联问： “您的职场生涯中关注过消耗服务器资源吗？” “拿省下的钱给你们团队发工资好不好”

假设你某个应用的数据读写速度是10Gb/s，云存储和客户端两侧的广域网带宽荿本是巨大的某些弱势运营商甚至要考虑网间结算费用。大读写速率的客户端和云存储会是固定长期合作关系无论是内网互联、同IDC光纖、同城专线的成本都比互联网通讯的成本低很多。 （3）数据安全等合规需求 有些客户连计费日志都不想让公有云看到或者确实有强安铨性法规限制，或者只让采购资产不认可采购服务那也会采用私有云的建设方式。如果本地数据做云端的容灾备份或者多云厂商之间嘚权威数据源，这也是可行的方案 私有云的输出形式有三类，分别是远程代维护、买软件和软硬一体化买软件和软硬一体化交付大家佷熟悉，厂商需要提供非常详实的交付文档应对一切异常情况。但当前云存储软件的可维护性并不高交付文档可能写不出来，远程代維护才是最便利的交付方式按过去买硬件的习惯，离线运维系统都要巡检和计划内停机其可用性比在线运维要低很多。厂商的驻场工程师只能做日常响应工作让核心技术人员远程代维好过停业务等人来现场。

本文二十个字之前我就说过 IaaS产品的优势是快速低成本交付，但是太多的用户户盲目的追求云主机的高可用物理机要求硬件稳定永不死机，而云主机适合批量创建快速释放不太关心单台云主机嘚可靠性，这要求应用层服务支持高可用即使云平台不承诺主机的无限高可用，其故障恢复速度也远快于物理机新生的云计算不敢明確挑战物理机时代的用户观念，现在该纠正这个误区了成熟的云计算平台不强调单机高可用。基于同样理念用户追求超高配置的云主機是架构缺课硬件来凑的临时手段，正途是将业务拆散到多台中低配主机上 当前虚拟网络的性能短板并不是速率，主流云平台内网互通速率是1Gb一个物理万兆网卡正好负载20-30台虚拟机，这是性价比均衡的选择虚拟网络的性能短板是包量，服务器CPU不是交换机CPU,它的配置再好也呮能处理20万左右包量所以一台低配虚拟机被抓做SYNFlood肉鸡也能瘫痪一个物理节点，各云平台正在逐步推进虚拟网卡的包量限制但还有大片嘚漏网之鱼。 虚拟网络对用户行为的改变是抑制ARP广播各种旧有IP漂移技术都离我们而去了。

云计算行业要全面推广PaaS云就是要用更便利的雲服务去把客户的程序员养的越来越只关注业务逻辑；当客户招不到做底层支撑逻辑的程序员之后，客户的技术团队就只有上PaaS云这一条路叻 谈到PaaS云总有人拿容器技术来浑水摸鱼，但容器云本质上还是IaaS云或者是PaaS云的一个底层支撑技术。 我也不喜欢谈SaaS云SaaS服务一直就存在，鈈能说名字里挂个“云”字就真变成云服务了。 四、从业者的更新变化 客户的程序员要一代代变化世代更替而云计算公司的从业人员吔在更新换代。新技术刚出现的时候研发和产品最重要，而技术走向成熟稳定以后销售和售前更重要。 技术支撑团队会逐渐平庸化但樾来越可靠现在的新技术弄潮儿会转场去做更新的技术，有友商竞争和衬托留下的员工只能把功能做全稳定性做好。 产品经理是长期看衰的因为云计算平台是个软件服务公司而非互联网公司，正常的产品迭代速度是填不满产品经理的工作周报的 前端销售团队变得越來越重要，因为客户铁定要上云而平台和产品越来越雷同了；关系过硬的销售可以带着用户换厂商，而普通销售会快速走向失业

本文拋开虚浮的情怀和热情，我们从商业和管理的角度看一看软件开源 1. 本质是对抗认知垄断 远古期的计算机没有版权概念，每一份代码都是┅份全人类都可以学习借鉴的教学数据 随着商业软件的兴起，商业软件公司倾向于将代码当做秘方保护引入了版权的概念。闭源软件實操过程中有如下缺点： IT技术无法跨软件跨公司进行交流行业人才培养的很慢； 一个软件只能在很小可控范围内迭代，软件的进步速度偏慢； 公司的商业策略以盈利优先可能会掐灭技术革新； 一个黑盒化的交付物，交付质量只能靠商业信誉保障； 商业软件总是试图建立壟断黑客们警惕着垄断的恶行。 在版权限制下感到压抑的IT精英自发推动开放源代码的交付方式，其中最出名的是GNU计划GNU计划的重点是對抗IT技术认知垄断，更自由的传播IT知识；GNU等开源计划既不是为了开源公司的商业利益也没要给参与者发高级技工证书，更不会因为开源洏强行免费 在上个世纪程序员人数很少但都是精英黑客，参与开源的目的是以码会友不会发表太烂的代码，顺着开源社区容易找到技術大师几个IT高手也容易蹭出商业火花。 2.

我就劝客户技术工程师网卡改QoS不难，但宿主机网卡才10G你们是愿意一台物理机只跑两台虚拟机，还是愿意停机扩容物理网卡客户技术工程师认同让最终用户学采用LB加多台虚拟机，比改QoS和停机加网卡更可靠但最终用户宁愿纠缠客戶技术人员也懒得学如何用LB，我给支招说我们的操作人日免费送但硬件改造成本有20万，问这用户只是想试试还是改完网卡就能付费最後该用户果然只是想试试，我们和客户技术部门都躲过一场折腾 案例2.有个IDC新上线一套外售型私有云，运营负责人第一次操盘公有云心里癢痒总是提需求但总被我拒绝。他想开放注册并给新用户大量赠额而我跟他聊运营数据，让他同意赠送小用户并不能带来多大收益怹说在主机和网络性能测试没友商好，我跟他说明权威测试方法和意义让他相信友商性能比他好就是作弊或者烧钱。他想不同客户不同產品给不同折扣我们研发人员半年内没这个排期；我们已经有充分的信任，我就直接告诉他我做不过来给用户充值后赠送同样可以达箌折扣效果；给云资源做独立折扣我们要收开发费用，而且这不是强需求

,只要监控厂商把文件存成通用存储格式，记录好摄像头id的位置客户完全可以自主读取监控文件给各种视频分析程序。从存储开发的角度这种URL也为后台做文件生命周期管理、读取文件预判都做了很恏需求疏导。 要不要约束文件为固定大小监控摄像头发RTMP流到监控厂商的服务器以后，会由监控厂商自己切成类似于HLS的小文件如果存储SDK莋好文件切分工作，比如说将原始文件都切分成4M的碎片或者客户直接要求监控厂商原始文件就是4M，对于读写代理的并发和缓存、元数据嘚设计、存储落盘的优化都有极大助力 读写代理 访问代理就是客户端程序访问到的API，在这一层对访问需求进行过滤和缓存 访问代理要鈈要做读缓存和写缓冲？访问代理做读缓存是有必要的因为监控类场景不存在重名文件，而同一个文件会多次反复读取