云栖社区直播_个人页_阿里云开发者社区

发表了文章 2019-12-02

奶牛戴上VR眼镜“看片”，开心了可以多产奶：俄罗斯官方做了实验，拯救奶牛的冬季忧郁

云栖号：https://www.aliyun.com/#module-yedOfott8第一手的上云资讯，不同行业精选的上云企业案例库，基于众多成功案例萃取而成的最佳实践，助力您上云决策！战斗民族，是这样保护奶源的。栗子发自凹非寺量子位报道 | 公众号 QbitAI 冬天来了，奶牛忧郁了，没有心情产奶了。不是我说的，是俄罗斯有兽医专家说，他们国家的2,000万奶牛受到冬季忧郁 (Winter Blues) 的困扰，对产奶量也有影响。这可不行，毕竟俄罗斯许多地区一年到头是冬天，产奶量就没有保障了？于是，来自莫斯科的一群科学家脑洞喷发，做了史无前例的实验：奶牛戴上VR眼镜“看片”，开心了可以多产奶：俄罗斯官方做了实验他们给奶牛带上VR眼镜，播放了为奶牛定制的内容，结果发现它们的心情真的会变好。而前人的研究又多次表明，不止产奶量和心情有关，奶的质量也跟心情有关。如此说来，VR果然是充满希望的乳制品拯救计划。那么问题来了：到底看了什么“电影”？其实，这是莫斯科州农业和食品部开启的试点计划，听上去思路清奇，却是沿着科学道理走来的。官方发布的文章提到：奶牛对红色的感知更加强烈，相比之下，对绿色和蓝色系的感知要弱一些。(说好的色盲呢？) 于是，科学家们就在VR眼镜里，模拟了夏日的田野，想用绿色的主色调让奶牛平静下来。虽然不知道奶牛最喜欢怎样的景色，但俄罗斯冬天长夏天短，给奶牛看夏天也是一种直观的思路。除此之外，奶牛戴的VR眼镜是从人类版改良来的，为它们的头部结构量身定制，方便奶牛舒适地欣赏风景。初步实验的结果显示：奶牛的焦虑程度降低了，总体情绪得到了改善。另外，莫斯科郊外一家农场里的实验也证明：开心的奶牛可以多产奶。而且不止产奶量，有时产奶的质量也会因为气氛平和，而得到明显的改善。莫斯科州农业和食品部对这个项目充满希望： VR眼镜对奶牛产奶的影响，今后也会全面证明的。科学家们打算把项目的规模扩大，也想帮整个国家的乳制品产业变得更现代化。官方说，用VR眼镜养奶牛是个创新，是俄罗斯的创新。不过，在用上21世纪的技术之前，战斗民族和其他民族的农夫们，也已经用过其他方法来改善奶牛的心情了。还能怎样取悦奶牛开心的奶牛，产奶更多，质量更好，早已是业界公认的道理。一直以来，都有牛奶厂商标榜自家奶牛生长在广阔的牧草上，过着自由闲适的生活。除了常规操作之外，也有人为奶牛提供一些更优雅的服务：俄罗斯人钟爱柴可夫斯基，便给奶牛们听音乐，陶冶心性。美国人就更直接一些，喜欢用自动刷帮奶牛按摩。即便是在有了VR眼镜的今天，这些方法依然适用，简单又舒服。相比之下，在广大奶牛带上VR眼镜之前，这天马行空的新操作可能还有很长的路要走：问题出在哪里？有人问了，为什么不直接带奶牛去外面散步呢？以及，VR眼镜的续航也不是短期能解决的问题吧？还有，如果把眼镜摘下来，奶牛有了落差，心情会不会变得更差啊？看到这里，你还有什么大胆的问题？原文发布时间：2019-11-28本文作者：栗子发自凹非寺；量子位报道 | 公众号 QbitAI本文来自云栖社区合作伙伴“量子位”，了解相关信息可以关注“量子位” 云栖号：https://www.aliyun.com/#module-yedOfott8第一手的上云资讯，不同行业精选的上云企业案例库，基于众多成功案例萃取而成的最佳实践，助力您上云决策！

发表了文章 2019-12-02

大数据是否为小企业创造了竞争优势?

大数据可能成为当今小企业最具竞争力的优势，人们需要了解更多有关大数据如何提供帮助的信息。大数据正在改变各种企业的经营状况。很多企业采用大数据来比以往更快、更经济地处理某些任务。通用电气软件首席信息官Vince Campisi、美国运通高管Ash Gupta和其他许多公司都利用大数据来获得竞争优势。当然，大数据也提出了一些新的挑战。企业必须在更加快速的竞争环境中工作，因为在许多行业中，企业在大数据应用方面与其竞争对手之间通常存在着激烈的竞争。他们还必须应对一些独特的挑战，例如预测分析模型中数据偏向的固有风险。总体而言，大数据有利于各种规模的企业。企业管理人员应该意识到大数据的独特优势，并找到将其纳入其业务模型的方法。大数据为传统商业模式带来巨大变革业务成功的最关键要素是什么?这是企业获得持续发展的最重要因素。人们可能会发现大数据将在很多领域中发挥非常重要的作用。 (1)产品市场契合度–50% 如果企业不能提供符合市场需求的产品，那么也很难做好业务。幸运的是，一旦找到合适的产品，其他事情都会变得容易得多。确保企业解决紧迫的问题，提供了客户不仅想要而且愿意为之付出代价的完美安装解决方案。在尝试增加或实施其他项目之前，企业需要花费时间来解决这个问题。现在需要进行调整，在企业投入过多的时间和资源之前，其方向可能是错误的。那么大数据如何进入这个方程式呢?精明的企业正在使用大数据来改善其市场研究流程。但是，正如麻省理工学院的Ken Faro所指出的那样，企业必须首先解决某些挑战。 (2)营销与销售–10% 市场营销和销售实际上可以占到企业业务成功的90%。市场营销是使产品适应市场的重要组成部分。企业必须定位正确，必须获得对理想客户而言最重要的功能和优势。然后，必须让他们知道自己是什么。需要记住，营销与自己无关，而与其客户有关。许多精明的科技企业家却在这方面完全失败，这没有任何理由，因为大数据可以为他们提供很多帮助。企业拥有高智商的员工和强大技术工程能力并不等于能够在该领域取得成功。实际上这可能是一个巨大的障碍。除非企业将产品销售给一些技术工程师，否则还面临很多问题。企业可能需要外部人员来帮助处理困难的部分，并将其转变为消息传递方面的专家。意识和可见性是企业采用营销方法的重要组成部分。企业可以拥有历史上最好的产品，而这是迫切需要的。但是如果没有人知道这一点，那么一切都将一事无成。大数据对营销很有帮助。企业可以使用大数据来更紧密地定位其信息，并更深入地了解其受众特征。在这里，企业可以开始创建销售线索并将其添加到渠道中。但是，在使用大数据来改善营销时，需要记住：密切注意客户获取成本，否则可能使企业破产。入站咨询与证明产品市场适合度不同。在获得实际销售并且达到用户满意之前，企业不会得到它。大数据是解决这些挑战的关键。 (3)筹款–10% 创业公司的创始人和首席执行官的首要工作是确保不会缺少资金。90%或更多的创业公司由于资金短缺而倒闭，这甚至可能发生在最好的销售月份。只依靠资金并不能使企业业务获得成功。如果其业务模式存在缺陷并且仍然亏损，或者没有适合市场的产品，那么这些投资可能只是杯水车薪。它可能会让企业再向前发展一定的阶段，但这并不会使企业实现目的。企业将不得不继续投资，并且消耗更多的费用。 (4)团队建设–10% 如果企业拥有一个出色的独立工作团队，那么其成功将在很大程度上取决于团队。一支优秀的团队将为企业的成功起到至关重要的作用。一个弱小的团队只会带来痛苦，并影响企业业务的发展。首席执行官的大部分时间应该花在招聘和雇用可能获得的最佳人才上。首席执行官的另一个角色是确保建立正确的企业文化，让其团队都高效地工作。企业的员工应该致力于实现最重要的里程碑和企业的远大愿景。 (5)不断学习和自我完善– 5% 随着团队的快速发展和与客户的交流以及筹款工作，企业管理人员必须更快地成长为领导者，需要每隔几个月就能在知识和技能上取得重大飞跃。因此需要每天学习、阅读和咨询顾问，需要在有利于个人进步的所有领域上花费时间，以便每天的工作都能达到最佳状态。 (6)产量–5% 进行销售并增加资金很好。但是，也必须付出代价。企业进行宣传炒作并获得订单很容易。提供高质量产品可能是一个完全不同的局面，企业确保其产品能够满足用户需求。一旦看到成功，企业将面临来自新进入者以及规模更大、实力雄厚、资金雄厚的竞争对手的竞争。企业还必须不断创新，改善流程，并改善产品。 (7)客户服务与幸福– 5% 初创企业的主要问题之一是客户服务。客户服务部门可能是企业真正想要建立的第一个部门。否则，企业可能放弃成千上万的早期采用者，甚至更多。企业可能永远不再获得他们的支持，也无法获得公关和营销回报。 (8)规模–5% 企业必须不断成长，因为如果不成长，那么就可能退步。企业不仅需要增长来支持业务本身，还需要吸引和满足投资者并保持人才储备。当企业寻求退出并由出色的并购顾问进行指导时，这很关键。大数据对于获得业务竞争优势至关重要每个企业都希望尽一切可能脱颖而出。大数据在此过程中扮演着非常重要的角色。精明的公司需要找到创新的方法利用大数据以获得自己的优势。原文发布时间：2019-12-02本文作者：责任编辑：cres 作者：Sean Parker 本文来自阿里云云栖号&云栖社区合作伙伴“企业网D1Net”，了解相关信息可以关注“企业网D1Net”

发表了文章 2019-12-02

机器学习正遭遇“可重复性危机”，或已成“炼金术”？

作者 | Matthew Stewart编译 | JocelynWang “科学的第一个原则是你不能愚弄自己，然而你自己却是最容易被愚弄的人。” —— 理查德 · 费曼机器学习以其特有的优势逐渐在科学研究中得到大量应用，然而，其内在的“黑箱”特点也带来了一系列问题，有研究者认为正是机器学习的这种不可解释性导致了当下科学研究的“可重复性危机”——如果科学不可重复，那么我们还能称之为真正的科学吗？与此同时，更有研究者声称机器学习已经成为一种“炼金术”。本文基于机器学习所带来的“可重复性危机”，从“是什么”、“为什么”以及“如何做”三个层次进行了阐述，为这一危机寻找出路：可重复性和可解释性的机器学习模型。一、什么是“可重复性危机”？ “如今科学界的研究人员普遍意识到存在一种“可重复性危机”（Reproducibility Crisis）。我敢说，这其中很大一部分都来源于机器学习技术在科学中的应用。”—— Genevera Allen 莱斯大学统计与电气工程系教授机器学习方法正在取代传统的统计方法，越来越普遍地被应用到科学研究过程中，这会给科学界及其对知识的追求带来什么影响呢？一些人认为，正是机器学习技术的“黑箱”导致了科学研究的“可重复性危机”。毕竟，如果科学不可重复，那我们是否还能称之为真正的科学吗？（声明：本文是我自己基于参考文献中所参考的材料发表的一些观点。这是学术界的一个有争议的领域，欢迎大家进行建设性辩论。）科学过程的生命周期机器学习（ML）在科学研究中似乎已经无处不在，甚至在很多领域中已经替代了传统的统计方法。虽然通常来说，ML技术更易于用作分析的一项工具，但它内在的“黑箱”特点给科学家在追求真理的过程中造成了一些严重的问题。科学界的“可重复性危机”是指是指惊人数量的研究结果无法在另一组科学家团队进行的同一个实验中实现重复。这可能就意味最初的结果是错误的。一项研究表明，在全世界所有进行过的生物医学研究中，有多达 85% 的研究结果都是徒劳无获的。关于“可重复性危机”的争论可能是学术界中最接近机器学习和统计学学科间的斗争的一次争论。一位人工智能研究员甚至在一篇科学文章中声称，机器学习已经成为一种“炼金术”。（相关阅读链接：https://www.sciencemag.org/news/2018/05/ai-researchers-allege-machine-learning-alchemy?）他关于这个话题的一些论文和博客文章，都非常值得一读，比如：“大型尺度核机器的随机特征”，文章链接为：https://people.eecs.berkeley.edu/~brecht/papers/07.rah.rec.nips.pdf ML成为了科学研究一项很好的补充，使其在研究中的应用变得不可避免。ML可以被视为一个工程任务——就像一条集建模、调参、数据预处理和与元素优化于一体的流水线。ML 的目的就是寻找最优解或最优预测，而这属于科学研究的一项子集。机器学习的类型和算法本身就是科学研究的议题。与过去的统计方法一样，现在研究者们正在撰写大量各类 ML 算法和 ML 算法子类相关的科研论文。 2019年 2 月，Genevera Allen 在美国科学进步协会（AAAS）上发出了一个严重警告：科学家们正在学习基于机器学习算法来发现数据中的模式，即使这些算法只是专注于在另一个实验中无法重复的噪音。这一挑战涉及多个学科，因为机器学习在天文学、基因组学、环境科学和医疗保健等多个领域都被应用于获取发现。其中，Genevera Allen 使用的最主要的例子是基因组数据，这些数据通常是数据量非常巨大的数百 GB 或数个 TB 的数据集。她指出，当科学家使用自己不太了解的 ML 算法对基因组图谱进行聚类分析时，常常会出现似是而非、不可重复的结果。直到另一个团队进行了类似的分析研究，并得出了完全不同的结果，这才使得之前的结果变得有争议且被人质疑。这其中可能有多种原因：1.缺乏算法知识2.对数据缺乏了解3.对结果的曲解二、造成“可重复性危机”的原因 1、算法知识的欠缺缺乏算法知识的现象在机器学习应用领域显得极为普遍。如果你不明白一个算法是如何产生结果的，那又怎么能确定它有没有作弊，或者其得到的变量间相关性的结果实际上是虚假的呢？由于参数太多（深度神经网络通常有数百万个参数），这是神经网络中的一大问题。而实际上用于记数的不仅仅有参数，还有超参数，包括学习率、初始化策略、迭代次数和网络结构等项。仅仅意识到自己缺乏算法知识是不足以解决这个问题的。如果不同研究的论文中使用的是不同的网络，你又如何将这些结果进行比较？由于高维神经网络损失函数的动态结构图具有高度复杂性，即使只增加一个额外变量或改变一个超参数也会对结果产生显著的影响。 2、对数据缺乏了解缺乏数据知识也是一个巨大的难题，但这一问题可以延伸到传统的统计技术方法。数据采集中的误差——如量化误差、测量不确定性和智能体变量的使用，这是主要的问题。次优数据也常常会造成一些问题，但是了解什么样的数据适合使用什么样的算法也是非常重要的，并且这一选择可能会对结果产生重大影响。一次简单的回归检验就可以很轻松地证明这一点。通常地，在实验中会出现参数多于数据点的现象（这在基因组学中是非常正常的，因为我们有很多基因，很少数据点），如果我们使用线性回归方法，那么我们选择的正则化方式会严重影响被视作为重要的参数。如果我们使用套索回归（ LASSO Regression），该回归方法趋向于将明显不重要的变量统统变为零，从而从回归中将它们消除并提供一些变量选择。如果我们使用岭回归（ Ridge Regression），该回归方法倾向于将这些不重要的参数缩小到足够小，以至于它们可以忽略不计，但同时将它们从数据集中删除也是有必要的。如果我们使用弹性网络回归（ Elastic Net Regression，套索回归和岭回归的组合），我们将再次得到非常不同的答案。如果我们不使用任何回归，那么由于我们有比数据点更多的变量，算法显然会使得数据过拟合，因此算法将繁琐地对所有数据点进行拟合。显然，在线性回归中，可以通过置信区间、p-检验等统计测试来评估它的准确性。然而，对于神经网络来说，这些评估方式只能是一种奢侈的幻想，是不存在的。那么我们怎样才能确定我们通过神经网络得来结论的准确性如何呢？我们目前所能做的就是详细的陈述模型的架构和超参数，并将代码开源，以供其他科学家进行分析或对这个模型重新使用。 3、对结果的误解对结果的误解在科学界很常见。其中一个原因是相关性并不意味着因果关系，一般来说，两个变量A和B可能存在关联的原因有以下几点： 1）A可能是由B的出现引起的 2）B可能是由A的出现引起的 3）A和B可能是由另一个混杂变量C引起的 4）A和B可能是伪相关性两值间的相关性很容易显现出来，但产生这种结果的原因很难确定。通过在谷歌上输入伪相关性，你可以找出一些看起来非常有趣但明显十分荒谬的具有统计意义相关性例子，比如：这些似乎都是十分荒谬的相关性例子，但我想指出的是，如果将这些变量放到提供给机器学习算法进行训练的数据集中，则该算法不会考虑所述因果关系的有效性或者提出任何问题，而是很轻易地接受此相关性作为因果变量。从这个角度看，该算法很可能是不准确或者错误的，因为软件只负责识别出仅存于该数据集而不是现实世界中的模式。伪相关性的出现，正是由于人们越来越普遍地使用一些具有成千上万个变量的大型数据集。而近几年来，伪相关性发生的频率也变得惊人的多。如果我有上千个变量和数百万个数据点，那么这些数据之中不可避免的会出现相关性。算法可以锁定这些因素并将其认定为因果关系，从而有效地执行无意识的 p-hacking，而 p-hacking 是一项还没有在学术界得到认可的技术。 1、什么是 p-hackingp-hacking的做法包括获取数据集以及尽可能全面地搜索其中具有统计学意义的相关性，并将这些相关性视为科学有效。你拥有的数据越多，就越有可能在两个变量之间找到伪相关性。通常来说，科学研究包括了提出假设、收集数据以及通过对数据进行分析以确定假设是否有效。p-hacking 所做的是先进行一个实验，然后通过既得实验结果形成事后假设来解释它们所获得的数据。这样做本身是没有恶意的，但是有些时候，科学家们这么做仅仅是为了让他们能够发表更多的论文。 2、增强相关性机器学习算法的另一个问题是算法必须能够做出预测，这就好比算法不能在最后说“我什么都没找到”。这种算法框架的脆弱性意味着，无论最终特征结果多不合适，它总能找到某种可以用来解释数据的方法（需要在算法和数据正确设置的前提下实现，否则可能无法收敛）。目前，我还没听过哪个机器学习算法能够返回用户并告诉他们数据是不合适的，这项工作已经被暗定为科学家的任务——而这并不是什么公平的假设。 “那为什么还使用机器学习呢？” 这是一个很好的问题。机器学习使数据集的分析变得简易，并且 ML 算法可以帮助用户进行大量的工作。在由于数据集太大而无法使用标准统计技术进行有效分析的领域中，这一点就变得弥足珍贵。尽管它加速了科学家的工作进度，但是机器学习在预测质量上存在的问题足以抵消机器学习带来的生产效率上的提高。三、下一步可以做什么？机器学习的前景也并非完全黯淡无光。传统统计方法和数据集也一直存在着类似的问题，只是在机器学习中这些问题由于大型数据集和算法的大量使用而被放大了。这些数据集和算法可以自动找到数据的相关性，与传统技术相比，使得我们更难对找到的相关性进行解释。同时，上述这种放大也暴露了科学研究过程中有待克服的弱点。然而，研究者也在开展下一代机器学习系统的相关工作，以确保它能够评估其预测的不确定性，以及解决它的不可再现性。话虽这么说，正如只有愚昧的工人才会将他失败的原因归咎于他们使用的工具，科学家们在使用机器学习算法时也需要格外小心，以确保他们的研究结果得到证实和检验。同行评审流程的设计初衷就是为了确保这一点，而这同时也是每个研究人员的责任。研究人员需要弄清他们使用的技术并了解其局限性；如果他们不具备这些专业知识，那么去一趟统计系与某位教授进行一次交流将会让我们都收益匪浅。 Rahimi（他认为 ML是一种 “炼金术”方法）提供了一些建议来判断哪种算法最为有效，在何时最佳。他指出，研究人员应进行消融研究，即将参数依次移除，以评估其对算法的影响。Rahimi 还呼吁进行切片分析，即分析一个算法的性能，以了解对该算法在某些方面的改进会使其消耗其他方面的成本。最后，他建议运行设置了具有各种不同超参数的算法，并应汇报这些算法的所有性能。这些技术将使用 ML 算法对数据提供更强大的分析。由于科学研究过程的性质，一旦解决了这些问题，就可以最终发现并纠正以前发现的认为是准确的错误关系。准确的判断当然经受得起时间的考验。四、结语由于最终结果缺乏可重复性，机器学习方法在科学学术界确实存在问题。然而，科学家们已经意识到了这些问题，并且正在朝着更具可重复性和可解释性的机器学习模型推进相关工作，而一旦实现这一目标，神经网络将会迎来真正意义上的突破。 Genevera Allen 强调了机器智能面临的一个基本问题：数据科学家仍然不了解机器学习所采取的机制。科学界必须共同努力，以便了解这些算法究竟是如何工作的，以及如何最有效地使用它们，以确保使用这种数据驱动的方法最终得出可靠的、可重复的科学有效的结论。就连声称机器学习是“炼金术”的 Rahimi 也对其潜力充满希望。他说，“正是由于原始的炼金术才有了后面的冶金学、药物制造、纺织染色以及我们现代的玻璃制造工艺技术的发明。此外，炼金术士也认为，他们可以将普通的金属转化为黄金，而水蛭是治愈疾病的好方法。” 正如物理学家Richard Feynman1974年在加州理工学院的毕业典礼上所说， “科学的第一个原则是你不能愚弄自己，然而你自己却是最容易被愚弄的人。” 参考文献：[1] https://science-sciencemag-org.ezp-prod1.hul.harvard.edu/content/sci/365/6452/416.full.pdf[2] https://research.fb.com/wp-content/uploads/2019/05/The-Scientific-Method-in-the-Science-of-Machine-Learning.pdf?[3] https://bigdata-madesimple.com/machine-learning-disrupting-science-research-heres/[4] https://biodatamining.biomedcentral.com/track/pdf/10.1186/s13040-018-0167-7[5] https://www.sciencemag.org/news/2018/05/ai-researchers-allege-machine-learning-alchemy[6] https://www.sciencedaily.com/releases/2019/02/190215110303.htm[7] https://phys.org/news/2018-09-machine-scientific-discoveries-faster.html[8] https://www.americanscientist.org/blog/macroscope/people-cause-replication-problems-not-machine-learning[9] https://www.datanami.com/2019/02/19/machine-learning-for-science-proving-problematic/[10] https://www.quantamagazine.org/how-artificial-intelligence-is-changing-science-20190311/[11] https://ml4sci.lbl.gov/[12] https://blogs.nvidia.com/blog/2019/03/27/how-ai-machine-learning-are-advancing-academic-research/[13] https://towardsdatascience.com/a-quick-response-to-genevera-allen-about-machine-learning-causing-science-crisis-8465bbf9da82#--responses[14] https://www.hpcwire.com/2019/02/19/machine-learning-reproducability-crisis-science/via https://towardsdatascience.com/the-machine-learning-crisis-in-scientific-research-91e61691ae76 原文发布时间：2019-12-01本文作者：Matthew Stewart本文来自AI科技评论，了解相关信息可以关注“AI科技评论”

发表了文章 2019-12-02

为什么会有那么多的云计算浪费?

随着2019年即将结束，调研机构Gartner公司预测，2019年全球云计算浪费约为141亿美元。尽管由于某些原因，这个数字实际可能会高得多，但这个数字是巨大的，而2018年全球云计算浪费为129亿美元。这种浪费并没有停止的迹象。Gartner公司预计，到2021年云计算浪费将达到210亿美元。由于效率低下和一些限制，浪费了大约35%的云计算支出。云计算服务提供商还证实云计算浪费的规模不断增加，他们认为组织或个人用户积累的云计算空间超出了他们的需要。考虑到人们如何将云计算视为一种节能资源，其流失的数量更令人担忧。那么到底什么是云计算浪费?为什么会飞速增长?在本文中将讨论为什么云计算浪费如此之大，以及可以采取哪些措施来减少浪费进行探讨。什么是云计算浪费? 像其他资源浪费一样，当组织获取的云计算资源数量超出了可利用的范围时，就会产生云计算浪费。云计算浪费具有几种形式。许多云平台都犯了让资源全天候运行的错误，这些资源可以用于开发、演示、测试或培训环境，但这些云计算环境在工作完成后通常被人忘记关闭。不能责怪任何一方的过错。有几家PaaS(平台即服务)提供商与云计算用户同样也有过错。这些Paas提供商无法在不使用时关闭服务。这不仅增加了成本，而且导致大量的云计算支出浪费。开发程序是造成云计算浪费的主要原因之一。开发人员在预测需要多少云计算实例的同时，通常会选择一个规模太大的实例。需要确保没有障碍以防止平稳运行。很多人总是认为规模越大越好，最终得到的资源比要求的多。它可能与不确定性或缺乏经验有关，但其结果是相同的。在通常情况下，数据库的供应量仍高于其需求，而额外的存储空间仍处于未使用状态。有人要为此负责吗? 云计算支出是组织对云计算基础设施的累积支出。大多数云计算服务都是按流量计费的，云计算供应商根据使用情况收费。通常，大多数云计算提供商会按小时向所有客户收费，其总金额称为云支出。 Gartner公司表示，2019年的云计算支出将比去年增长3.2%。这个数字将是惊人的3.8万亿美元，而2018年是2.7万亿美元。IaaS(基础设施即服务)以27.6%的增长率处于领先地位。每天都有组织进入这个利润丰厚的市场，这进一步加速了业务增长。随着采用更多资源任务的大量增加，云计算支出将会很快增加。谁因此而受到影响? 云计算浪费造成的伤害最大。其含义是多方面的，这种现象有多种损害方式。最明显的影响是收益的降低。由于组织无法充分利用云计算，因此其资产回报率较低。较低的资产回报率(ROA)也会降低净收入，这会影响应支付给消费者的股息。在接收端，由于云计算浪费而获得的分红较小。云计算浪费同时也会影响云计算提供商的业务。Azure和AWS公共云引入了自动扩展组和其他一些选项，以确保双方都受益于云计算浪费的减少。公共云提供商在超额认购消费者时获得的收益最多。这意味着他们受益于越来越多的人采用他们现有的数据中心。一旦云计算资源大量浪费，组织就被迫生产更新、更昂贵的产品，从而降低盈利能力。云计算浪费增加的原因云计算的好处是无穷的，但这并没有消除增加云计算浪费的危险。随着越来越多的组织更喜欢基于云计算的服务而不是传统的云服务，其未来似乎令人担忧。造成巨大云浪费的几个原因 (1)缺乏全面的了解 Syncsort表示，就像孩子不了解浪费水资源一样，很多人也不知道云计算浪费会带来哪些影响，大约有62%的组织报告其云计算服务成本高于预期。通常，云计算账单通常高于人们的预期，这是因为他们对如何管理云计算资源缺乏了解。有些组织将有关其业务的所有信息都上传到了云平台上，但这种方法并不适合。人们必须知道，云计算就像是保护区，应该保留必要的内容。大多数组织都为使用的资源支付费用，这也是必须采取谨慎态度的另一个原因。人们通常会忘记，关于如何管理资源需要采取适当的策略，必须记住要有适应性和组织性，才能有效地使用云计算。仅仅因为上传更容易并不意味着组织必须上传! (2)过度配置的资源如果组织知道有多少个实例，并且所有这些实例都是用于特定目的的。由于用途不同，它们的价格也不同，规模也不同。组织倾向于囤积不必要的实例，这些实例并没有采用。它不仅会导致存储问题，而且还会增加项目成本。另一个例子是云计算本身的囤积。根据最新数据，大多数组织在实例上花费了总支出的一半左右。现在，人们可能希望知道在实例上为什么支出这么多费用。根据调查，其中约40%组织的云计算规模是实际需求的两倍。如果将其转换为数字，那么全球每年在大型实例上的花费约为53亿美元 (3)计划外的虚拟机大多数组织让虚拟机全天候运行都会感到内疚。但是，对于这些机器通常没有采取任何措施，这增加了云计算浪费。很多人还没有完全理解云计算，经验不足就说明了这一点。云计算的价格根据区域不同而不同。一些组织在世界各地都有云计算服务，但未能以最好的方式利用成本最低的云计算服务。这导致了云计算浪费和延迟问题的产生。如果用户在印度使用服务器用于美国的任何操作，则必将付出更高的成本。如果不加强措施，这些未使用资源的价格将随着时间的推移而上涨。如果组织习惯于在未使用的虚拟机完成工作后将其关闭，这非常好。最令人惊讶的是，大多数组织甚至都不愿意采取任何重大措施来改进它。 (4)闲置资源闲置资源就像那些未没有入住的公寓一样，但是租户会定期支付租金。即使没有使用多余的资金也要承担费用。云计算成本并不便宜，而且很难弄清楚这些数字到底是多少。空闲资源主要发生在开发中心，在那里实施测试、准备和其他过程。偶尔也会在生产中发生，但发生的可能性很小。空闲资源的成本占全球产生的云计算浪费的很大一部分，每年的成本为88亿美元。 (5)未使用容量云计算的工作方式不同，大多数组织都认为其工作方式与内部部署数据中心完全相同。当他们转移到云平台中时，往往会选择与之前或更高版本相同的存储。根据Koomey公司发布的调查报告，大约80%的内部部署数据中心使用的服务器容量超过了所需。这不仅会给组织带来更高的成本，而且服务提供商也会受到影响。同一份报告还指出，迁移到云平台之后，大约36%的组织为云计算支付的费用超过了所需。当组织采用按使用量付费的云计算服务方案时，为什么不能提高效率并根据需求加以利用?云计算提供商要求组织更好地处理云计算服务。像AWS和Azure这样的提供商始终会推送更新来改善云计算容量管理。尽管云计算并不是化石能源那样不可再生，但它也有其局限性。因此，为什么不高效使用它，以便其他人可以使用它而不会降低效率。人们应该意识到，云计算不能与不可再生的化石能源具有同样的命运。 (6)快照过多的问题可以在云计算环境中以三种方式创建快照：VMware的方式、写时复制、写时重定向。一旦VMware创建快照，将为新的写入操作创建一个新位置。令人痛苦的是，所有读取操作都会在提供当前块版本之前扫描现有位置和原始位置。这些快照的运行方式对于大多数用户而言是未知的，他们将其视为普通快照。它们将拍摄快照，但在不再需要时无法删除它们。人们需要研究操作系统升级的情况。用户将在升级到较新版本之前拍摄快照。如果需要，它可以回滚到上一个。在经过数天甚至数月的最新版本测试之后，他们忘记删除仍在运行的旧快照。它只会产生不必要的浪费，并导致更多的资源利用。 (7)滥用按需服务各种平台的点播服务如今不断增长。随着云计算提供商向其客户提供按需服务，新问题浮出水面。许多组织发现这样的服务有利可图而且易于部署。因此，他们倾向于在不考虑启动和停止支付费用的情况下更多地利用它。按需服务只用于紧急情况，而非一般用途。它们的成本远远高于预留资源，甚至是现货资源。现在应该注意这些成本并停止部署不必要的资源。如果有必要，则必须这样做。为什么不使用可用资源代替呢? (8)孤立资源孤立资源是那些不再有用的资源。它通常发生在组织关闭计算机之后却忘记关闭存储设备的时候。存储设备将没有其他工作要做，只会累积成本，这将导致组织最终付出更多的成本。这不仅增加了组织的成本，而且还导致了云计算资源的浪费。为了遏制此类事件，组织必须足够小心谨慎，以确保在后台不会耗尽其他云计算资源。 (9)低效的定价一般来说，如果有两种选择，人们可能更容易做出选择。但是如果具有成千上万种选择，并且必须选择一个呢?可能很难找到适合自己的。这是云计算用户最大痛苦的事情。即使大多数云计算提供商按小时收费，也将提供不同的价格，而产品的价格不会发生重大变化。有成千上万种这样的选项可供选择。有经验的组织可能知道他们在寻找什么，并且会找到最合适的选项。那些缺乏经验、并且只是因为竞争对手转向云计算而置身其中的大多数组织呢?这些组织最终选择了错误的实例规模和附加组件，这些都远远超出了他们的需要，并造成云计算浪费，导致更高的成本。结论人类可能由于粗心大意而导致一些资源濒临灭绝，每年为此花费数十亿美元，但很多人并没意识到自己的错误。如果有更好的云计算管理策略呢?如果在不使用时关掉机器将会怎么样? 制定适当的工作策略将减少组织的成本，同时也会导致消耗量的下降。当企业查看账单时，其累积的数字令人担忧。很多人可能重蹈覆辙，认为使用资源是理所当然的。它在当今似乎已经广泛使用，但是如果获得足够的吸引力，该怎么办?人们将会受到影响，而那一天将会为期不远。原文发布时间：2019-12-02本文作者：责任编辑：cres 作者：Aman Juneja本文来自云栖社区合作伙伴“企业网D1Net”，了解相关信息可以关注“企业网D1Net”

发表了文章 2019-12-02

物联网在智慧城市中如何用于交通控制?

现代技术的发展带来了城市的重大变化。智慧城市拥有最新科技成果，使人们在信息和通信技术的帮助下生活得井井有条。物联网将如何在智慧城市的交通管理中发挥重要作用呢? 智慧城市在充分利用科技的同时，确保不会以任何方式污染环境。当我们面临新的科技应用时，有没有考虑影响环境呢?答案是肯定的。支持可持续发展的基础设施城市管理部门管理整个城市离不开基础设施。可持续发展的基础设施将产生适当的节能效果，对环境的影响较小。智能基础设施和适当的城市服务将会带给市民全新的生活体验。智慧城市与传统城市之间将会有巨大的差异。智慧城市旨在为用户提供舒适的生活，同时尽可能减少对环境的危害。智慧城市的好处在于，市民也与管理人员一起，共建舒适的居住地。他们从事各种不同的工作，最终是为了建设人类美好的家园。智慧城市主要集中于有效利用所有资源，为此，物联网技术将发挥重要作用。从污染物管理到严格的控制系统，每个环节都进行了有效的优化，从而有助于城市的基础设施建设。在智慧城市中，交通管理是一件重要的事情。在交通管理中使用物联网将有效减少任何突发的交通问题，并提高运输效率。首先，让我们再次回顾一下物联网技术。物联网是如何运作的呢? 物联网技术应用非常广泛。例如，它通常用于房地产领域、交通领域，还有智能水表市场。简单的理解，物联网是一种与所有相关设备进行通信的方式。现在市场上有很多智能设备，几乎它们都可以通过物联网技术相互连接。物联网将确保从一个设备到另一个设备的通信顺利进行。我们还能够通过物联网技术与相关设备进行互动。整个物联网系统储存了非常庞大的数据。这就是为什么需要使用云技术来保存所有数据的原因。大数据分析将有助于存储信息。智慧城市主要依赖于物联网和大数据。在交通管理中使用这两种技术，将会带来重大的变化。物联网如何用于交通控制? 交通堵塞，这难道不是世界上最讨厌的事情吗?从城市居民到上班族，没有人愿意在堵车上花费大量的时间。有效的交通管理是城市管理面临的最大问题之一。虽然发达国家已经在智慧城市交通系统上开展物联网项目，试图利用大数据和物联网技术将所有的交通问题最小化。但发展中国家在这一过程中投入如此巨大的资金并不容易。无论城市大小，汽车已经成为一种必需品，人们都喜欢自己开车而不是乘坐公共交通工具，觉得这样比较方便。随着人们开始使用更多的汽车，交通问题也变得更加持久。大多数城市都通过道路上的摄像头来获取车辆有关的信息，然后传送到城市交通管理中心，利用这些信息来管理交通。如何以更好的方式组织和管理交通，最大限度减少交通堵塞呢?使用物联网的智能交通系统必须考虑很多因素。交通信号灯和物联网控制系统红绿信号灯在基于物联网的交通控制系统中起着重要的作用。交通灯上安装了气象传感器。这些传感器能探测天气的阴暗情况，并能自动调整灯光的亮度。这些红绿灯还可以记录特定地区的交通堵塞情况。安装在这些交通灯上的摄像头将捕捉特定道路上的交通流量，并将这些数据传输给后台。交通管理后台根据这些数据分析如何有效分流和减少堵塞。通过物联网实现智能停车停车是交通管理部门面临的最大问题。城市的基础设施不允许人们在任何地方随意地停放车辆。特别是在城市繁华区域，停车位的缺乏导致了严重的交通拥堵。物联网如何使智能停车成为可能?如何在现实中解决停车问题?答案很简单。物联网设备将收集停车场内所有空车位的数据，进入停车场的车辆将获得这些数据。这样，汽车就根本不需要寻找停车位了。他们可以根据提示进入停车场，然后直接去空位停车。这将减少停车场的拥堵，更容易让车主在停车场泊车。欧洲和美国的一些城市已经实施了这种智能停车技术，它们在停车问题方面取得了显著的进步。可见，物联网技术给交通管理带来了诸多好处。通过物联网提供紧急援助无论什么原因，在交通事故中失去宝贵的生命是令人悲痛的。在有些情况下，人们因为无法得到及时治疗而失去了生命。比如周围没有人，他们很难获得帮助。基于物联网的交通控制系统非常有效地解决了这个问题。道路上的传感器会检测到任何突发的事故，并立即将问题报告给交通管理系统，交通管理系统会采取进一步的措施来解决问题。如果能够及时发现问题，那么事故还有挽救的余地。因此，基于物联网技术提供紧急援助，发生在偏远地区或深夜的交通事故将会得到第一时间的处理。通过物联网解决通勤时间问题对于生活在大城市里的人来说，花几个小时去目的地已经习以为常了。解决这些长时间的通勤并不是一件容易的事。随着城市的不断发展，吸引了越来越多的来自世界各地的商业活动。根据城市商业的发展来扩大道路是不可能的。这就是人们使用大数据分析和物联网技术的原因。物联网设备将为他们提供所有可以到达目的地的路线信息，以及到达目的地所需的时间。交通是城市的命脉，利用物联网传感器有效实施智能交通管理，对于智慧城市交通领域的发展具有重要意义。原文发布时间：2019-12-02本文作者：风车云马编译本文来自云栖社区合作伙伴“51CTO”，了解相关信息可以关注“51CTO”

发表了文章 2019-12-02

Delta元数据解析

作者：宋军，花名嵩林，阿里云EMR技术专家。从事Spark内核优化，对SparkCore/SprakSQL有深入了解，Spark Contributor Delta元数据解析元数据初识 Delta有自己的元数据管理，主要有6种类型的元数据Action: SetTransaction AddFile RemoveFile Metadata Protocol CommitInfo Delta的元数据统一存放在Delta的logpath下面的_delta_log文件夹中 _delta_log文件夹位置不管DeltaTable是分区表还是非分区表，_delta_log文件夹只有一个，都位于Delta的logpath下面 _delta_log文件夹内容 _delta_log文件夹下存储了所有Delta的相关元数据，如下所示 Delta每次事务commit都会产生一个json的元数据文件，文件内容包括本次commit做的所有action，比如AddFile/RemoveFile等等; 每产生一个新的json文件就会产生一个新的Delta的snapshot，snapshot的版本即该json文件中的数字，该数字必须是连续自增(不能缺失)，Delta的某个版本的snapshot是通过顺序回放所有小于等于该snapshot版本号的所有json文件得到; 每个json文件会有一个对应的crc校验文件(源码中有相关代码，但是并没有实际去写该crc) 对元数据做checkpoint时会产生新的checkpoint文件(parquet) 如下FileNames类用来管理_delta_log文件夹下相关文件的文件名:如下_delta_log文件示例: _delog_log文件内容 json文件 checkpoint parquet文件: parquet文件内容元数据解析 Actions CommitInfo Holds provenance information about changes to the table. This [[Action]] is not stored in the checkpoint and has reduced compatibility guarantees. Information stored in it is best effort (i.e. can be falsified by the writer). 如:{"commitInfo":{"timestamp":1574836330000,"operation":"STREAMING UPDATE","operationParameters":{"outputMode":"Append","queryId":"f5ef8a90-069a-4311-bd0f-4f0c93d89cfe","epochId":"0"},"isBlindAppend":true}} {"commitInfo":{"timestamp":1574824794574,"operation":"WRITE","operationParameters":{"mode":"Overwrite","partitionBy":"["date","city"]"},"isBlindAppend":false}} 每次commit一个json文件都会有一个CommitInfo，记录当前commit对Delta表的修改行为，比如示例中的operation类型有STREAMING UPDATE / WRITE等等 Protocol Used to block older clients from reading or writing the log when backwards incompatible changes are made to the protocol. Readers and writers are responsible for checking that they meet the minimum versions before performing any other operations.Since this action allows us to explicitly block older clients in the case of a breaking change to the protocol, clients should be tolerant of messages and fields that they do not understand. 如:{"protocol":{"minReaderVersion":1,"minWriterVersion":2}} 用来做Delta本身版本兼容性检查，第一个json文件00000000000000000000.json里面会有该信息，除非调用updateProtocol接口会产生一个新的Protocol Metadata Updates the metadata of the table. Only the last update to the [[Metadata]] of a table is kept. It is the responsibility of the writer to ensure that any data already present in the table is still valid after any change. 如:{"metaData":{"id":"c233ce0c-dd80-44f0-a1d2-a9404adef07e","format":{"provider":"parquet","options":{}},"schemaString":"{"type":"struct","fields":[{"name":"id","type":"long","nullable":true,"metadata":{}},{"name":"date","type":"date","nullable":true,"metadata":{}},{"name":"name","type":"string","nullable":true,"metadata":{}},{"name":"sales","type":"string","nullable":true,"metadata":{}}]}","partitionColumns":[],"configuration":{},"createdTime":1574836328664}} Delta表的schema相关信息，Delta支持schema的演化，所以如果对schema进行修改会产生新的Metadata，当生成某个版本的snapshot进行多个json文件顺序回放时，最终snapshot只会保留最新的Metadata，即以最新的Metadata中的schema为准。Schema演化规则详见文档(https://databricks.com/blog/2019/09/24/diving-into-delta-lake-schema-enforcement-evolution.html) AddFile Adds a new file to the table. When multiple [[AddFile]] file actions are seen with the same path only the metadata from the last one is kept. 如:{"add":{"path":"part-00000-c8719ced-3879-4037-b0af-d62c52224af0-c000.snappy.parquet","partitionValues":{},"size":5906,"modificationTime":1574836329955,"dataChange":true}} 分区文件{"add":{"path":"date=20190710/city=bj/part-00000-ef2cca38-7d20-4eaf-a291-81f71fc9d0b5.c000.snappy.parquet","partitionValues":{"date":"20190710","city":"bj"},"size":583,"modificationTime":1574954016825,"dataChange":true}} 记录在Delta中新增的文件 RemoveFile Logical removal of a given file from the reservoir. Acts as a tombstone before a file is deleted permanently. 记录删除掉的文件，一般在Merge/Update等操作会有RemoveFile操作。删除的文件并不会被物理删除，只是在元数据中标记该文件删除了，可以通过vacuum命令来实际物理删除超过墓碑时间的文件(默认7天) SetTransaction Sets the committed version for a given application. Used to make operations like streaming append idempotent. 如:{"txn":{"appId":"f5ef8a90-069a-4311-bd0f-4f0c93d89cfe","version":370,"lastUpdated":1574837260639}} SparkStreaming sink到Delta时，记录相关信息来实现ExactlyOnce特性元数据产生如上图所示，_delta_log文件夹下文件的一个产生演化流程，每次对Delta表进行相关修改操作(如Delte/Update等)都会生成一个json文件，记录当前修改的所有actions。 snapshot 从上面流程可以看出，Delta支持snapshot功能，即可以查看历史某个时间点状态下的Delta表数据，这个也是Delta的TimeTravel功能的基础实现，详见文档(https://databricks.com/blog/2019/02/04/introducing-delta-time-travel-for-large-scale-data-lakes.html)每个json文件对应一个snapshot版本，Delta在生成这个snapshot的时候，会将小于等于这个版本号的所有json文件按照时间顺序进行回放合并，snapshot 版本为3，那么它是有00000000000000000000.json/00000000000000000001.json/00000000000000000002.json三个按照顺序合并过来，同一个path的action会进行合并，比如0.json中有AddFile(path1), 1.json中有RemoveFile(path1)，那么snapshot版本3状态下的Delta表是不包含path1作为实际数据参与计算的。 checkpoint 每次调用OptimisticTransaction.commit(actions)时会判断当前json的版本对checkpointInterval值(可配置，默认为10)取模，如果取模为0则需要做一次checkpoint。checkpoint会将当前版本以及当前版本之前的所有json文件进行合并(仅仅是文件合并，不对内容做任何更改)到一个parquet文件，这样可以减少后续生成snapshot读取json文件的个数，并且parquet文件也带有压缩，使得存储变小。阿里巴巴开源大数据技术团队成立Apache Spark中国技术社区，定期推送精彩案例，技术专家直播，问答区数个Spark技术同学每日在线答疑，只为营造纯粹的Spark氛围，欢迎钉钉扫码加入！

发表了文章 2019-12-02

spring中，多个service发生嵌套，事务是怎么样的？

前言最近在项目中发现了一则报错：“org.springframework.transaction.UnexpectedRollbackException: Transaction rolled back because it has been marked as rollback-only”。根据报错信息来看是spring框架中的事务管理报错：事务回滚了，因为它被标记为回滚状态。报错原因多层嵌套事务中，如果使用了默认的事务传播方式，当内层事务抛出异常，外层事务捕捉并正常执行完毕时，就会报出rollback-only异常。spring框架是使用AOP的方式来管理事务，如果一个被事务管理的方法正常执行完毕，方法结束时spring会将方法中的sql进行提交。如果方法执行过程中出现异常，则回滚。spring框架的默认事务传播方式是PROPAGATION_REQUIRED：如果当前没有事务，就新建一个事务，如果已经存在一个事务中，加入到这个事务中。在项目中，一般我们都会使用默认的传播方式，这样无论外层事务和内层事务任何一个出现异常，那么所有的sql都不会执行。在嵌套事务场景中，内层事务的sql和外层事务的sql会在外层事务结束时进行提交或回滚。如果内层事务抛出异常e，在内层事务结束时，spring会把事务标记为“rollback-only”。这时如果外层事务捕捉了异常e，那么外层事务方法还会继续执行代码，直到外层事务也结束时，spring发现事务已经被标记为“rollback-only”，但方法却正常执行完毕了，这时spring就会抛出“org.springframework.transaction.UnexpectedRollbackException: Transaction rolled back because it has been marked as rollback-only”。代码示例如下： Class ServiceA { @Resource(name = "serviceB") private ServiceB b; @Transactional public void a() { try { b.b() } catch (Exception ignore) { } } } Class ServiceB { @Transactional public void b() { throw new RuntimeException(); } } 当调用a()时，就会报出“rollback-only”异常。解决方案如果希望内层事务抛出异常时中断程序执行，直接在外层事务的catch代码块中抛出e. 如果希望程序正常执行完毕，并且希望外层事务结束时全部提交，需要在内层事务中做异常捕获处理。如果希望内层事务回滚，但不影响外层事务提交，需要将内层事务的传播方式指定为PROPAGATION_NESTED。注：PROPAGATION_NESTED基于数据库savepoint实现的嵌套事务，外层事务的提交和回滚能够控制嵌内层事务，而内层事务报错时，可以返回原始savepoint，外层事务可以继续提交。附：事务传播方式@see org.springframework.transaction.annotation.Propagation 事务传播方式说明 PROPAGATION_REQUIRED 如果当前没有事务，就新建一个事务，如果已经存在一个事务中，加入到这个事务中。这是默认的传播方式 PROPAGATION_SUPPORTS 支持当前事务，如果当前没有事务，就以非事务方式执行 PROPAGATION_MANDATORY 使用当前的事务，如果当前没有事务，就抛出异常 PROPAGATION_REQUIRES_NEW 新建事务，如果当前存在事务，把当前事务挂起 PROPAGATION_NOT_SUPPORTED 以非事务方式执行操作，如果当前存在事务，就把当前事务挂起 PROPAGATION_NEVER 以非事务方式执行，如果当前存在事务，则抛出异常 PROPAGATION_SUPPORTS 支持当前事务，如果当前没有事务，就以非事务方式执行。 PROPAGATION_NESTED 如果当前存在事务，则在嵌套事务内执行。如果当前没有事务，则执行与PROPAGATION_REQUIRED类似的操作。

发表了文章 2019-11-27

云服务器ECS选型配置参考指南

现在企业信息化，使用云服务器的越来越普遍了，做为企业上云，在选择云服务器时，应该需要了解哪些方面呢？云服务器的配置选择，和网站或应用的类型、访问量、数据量大小、程序质量等因素有关，建议和您的网站或应用的开发技术人员沟通，选择最适合您的配置。如果您没有技术人员可提供建议，可以参考我们的建议进行配置选择。笔者介绍实例配置选型的流程，并针对常见应用场景给出实例配置建议。如果您的业务面向以下应用场景，可以选择图中推荐的实例。更多实例规格族，请参见实例规格族。实例结合应用场景选择，建议参考如下实例配置：均衡性能需要相对均衡的处理器与内存资源配比，可以满足大多数场景下的应用资源需求。高网络收发包应用需要高网络收发包能力，您可以根据应用场景选择更合理的计算与内存的资源配比。高性能计算需要消耗高计算资源，GPU并行计算以及高主频是该场景下的典型应用。高性能端游需要高主频处理器支持，高处理器主频可以承载更多的用户。手游、页游需要消耗高计算资源，建议选择1:2的处理器与内存配比，可以获得最优计算资源性价比。视频转发需要消耗高计算资源，建议选择1:2的处理器与内存配比，可以获得最优计算资源性价比。直播弹幕需要高网络收发包能力，您可以根据应用场景选择更合理的计算与内存的资源配比。关系型数据库需要SSD云盘或更高性能的NVMe SSD本地磁盘实现高存储IOPS和低读写延时，建议选择均衡（1:4）或内存更大（1:8）的处理器与内存配比。分布式缓存需要稳定的计算性能，建议选择均衡（1:4）或者内存更大（1:8）的处理器与内存配比。 NoSQL数据库需要SSD云盘或更高性能的NVMe SSD本地磁盘实现高存储IOPS和低读写延时，建议选择均衡（1:4）或内存更大（1:8）的处理器与内存配比。 Elasticsearch需要SSD云盘或更高性能的NVMe SSD本地磁盘实现高存储IOPS和低读写延时，建议选择均衡（1:4）或内存更大（1:8）的处理器与内存配比。 Hadoop数据节点需要高磁盘吞吐、高网络吞吐、均衡的处理器与内存配比，计算节点则更关注计算性能、网络带宽及处理器与内存配比。图片转码需要硬件并行加速能力，您可以根据应用场景选择更合理的计算与内存的资源配比。 AI深度学习训练需要高性能的NVIDIA GPU加速器，GPU与CPU比例1:8到1:12之间。通用深度学习需要高性能的NVIDIA GPU加速器，GPU与CPU比例1:4到1:48之间。图像识别推理需要高性能的NVIDIA GPU加速器，GPU与CPU比例1:4到1:12之间。语音识别语音合唱推理需要高性能的NVIDIA GPU加速器，GPU与CPU比例1:16到1:48之间。超算需要强大稳定的计算能力和高带宽低延迟的优质网络。了解清楚业务所需应用场景，建议到阿里云官网购买云服务器ECS，企业级实例限时1折！

发表了文章 2019-11-27

阿里云数据库和自建数据库有什么区别？优缺点对比

无论是企业还是个人用户都可以选择自建数据库，也可以将数据库搬到云端，比如说阿里云数据库，阿里云数据库和传统的自建数据库有什么区别？笔者来说说阿里云数据库和自建数据库的优缺点对比：阿里云数据库和自建数据库综合对比下表为二者的综合对比，包括数据库的安全性、数据库可靠性、数据库运维、资源利用率、扩容和成本方面考虑：优势对比云数据库RDS 自购服务器搭建数据库服务服务可用性 99.95% 需自行保障, 自行搭建主从复制，自建RAID等。数据可靠性 99.9999% 需自行保障，自行搭建主从复制，自建RAID等。系统安全性防DDoS攻击，流量清洗；及时修复各种数据库安全漏洞。自行部署，价格高昂；自行修复数据库安全漏洞。数据库备份自动备份自行实现，但需要寻找备份存放空间以及定期验证备份是否可恢复。软硬件投入无软硬件投入，按需付费数据库服务器成本相对较高，对于SQL Server需支付许可证费用。系统托管无托管费用每台2U服务器每年超过5000元（如果需要主从，两台服务器需超过10000元/年）。维护成本无需运维需招聘专职DBA来维护，花费大量人力成本。部署扩容即时开通，快速部署，弹性扩容，按需开通。需硬件采购、机房托管、部署机器等工作，周期较长。资源利用率按实际结算，100%利用率。考虑峰值，资源利用率很低。综上，阿里云数据库可靠性可达99.9999%，用户无需自建主从复制和RAID；阿里云数据库对于用户而言可以称得上0运维，用户无需投入人力成本到数据库运维上；从安全方面，阿里云数据库系统安全性更高；而且阿里云数据库扩容更加方便，用户无需考虑硬件升级和冗余。上云是趋势，笔者建议用户可以将数据库迁移到云上来，可以领取（代金券礼包），结算时用于抵扣订单金额。云数据库和自建数据库价格对比价格对比云数据库RDS 自购服务器搭建数据库服务硬件费用和备品配件消耗以如下实例规格为例：内存1200MB、存储空间50G（IOPS能力可达到600）的费用是2040元/年。至少需要2台据库集群，每台IOPS能力达到600的服务器费用大约是6000元。机房托管费用服务商负责，无需付费。 1U机柜空间托管费用为3000元/年，共有2台1U服务器和1台1U内网交换机需要计费。机房托管费用：3000 × 3=9000元带宽费用同一地域内，ECS和RDS可以通过内网互通，且不收取费用。但若在不同地域，ECS和RDS可以通过外网互通，需收取外网流量费用，详细收费标准请参见云数据库RDS详细价格信息。只用于内网，不产生公网费用。数据库运维工程师费用数据库维护由服务商负责，无人员成本。 1个初级DBA工程师月薪至少5000/月，如果按照当前项目占用该工程师30%的工作量：人员成本：5000 × 12× 30% = 18000元每年总费用 2040元/年 32633元/年从上表可以看出，自建数据库需要为硬件损耗、冗余及维护买单，而使用阿里云数据库无需考虑硬件消耗，运维方面无人工成本，可靠性安全性更高更省心。

发表了文章 2019-11-27

阿里云 Serverless 应用引擎（SAE）发布 v1.2.0，支持一键启停、NAS 存储、小规格实例等实用特性

近日，阿里云 Serverless 应用引擎（SAE）发布 v1.2.0版本，新版本实现了以下新功能/新特性：一键启停开发测试环境：企业开发测试环境一般晚上不常用，长期保有应用实例，闲置浪费很高。使用SAE一键启停功能，按需释放闲置资源，节省成本。 NAS 存储：通过 NAS 存储能持久化应用实例的一些数据，日志。查看应用 Events：查看 K8s 原生的 Events 事件，了解运行时的状态，方便快速定位问题。支持 0.5Core 1GiB 的小规格实例：考虑到非 Java 应用运行时的经济成本，新版本支持更小粒度的资源规格，建议仅用于开发测试环境。 WAR 包部署：支持 Tomcat 8 版本。一键启停开发测试环境在 SAE 控制台上，随着托管应用逐渐增多，存在占有资源却处于闲置状态的应用。例如应用开发完成后对其进行测试联调，完成测试联调后未将应用实例释放，随着空闲应用增多，对资源造成了大大的浪费。您可以使用一键批量启停功能将闲置应用停止释放资源。当再次需要时可以一键批量启动，继续执行相关业务。支持 NAS 存储阿里云文件存储NAS是一个可共享访问、弹性扩展、高可靠以及高性能的分布式文件系统。它基于 POSIX 文件接口，天然适配原生操作系统，提供共享访问，同时保证数据一致性和锁互斥。鉴于容器的可快速预置、容易携带，并可提供进程隔离的特点，容器非常适用于构建微服务。对于每次启动时都需要访问原始数据的容器，它们需要一个共享文件系统，使它们无论在哪个实例上运行，都可以连接到该文件系统。NAS 可提供对文件数据的持久共享访问权限，非常适合容器存储。我们知道，默认情况下，容器的数据都是非持久化的，在容器销毁以后数据也跟着丢失，在很多场景下数据丢失意味着线上灾难性事件。SAE 支持NAS 存储功能，解决了应用实例数据持久化和实例间多读共享数据的问题。查看应用事件信息 SAE 支持查看 K8s 原生的 Events 事件，帮助您了解应用运行时的状态，方便快速聚焦问题。更多内容您可以点击文档、产品详情页，了解更多有关 Serverless 应用引擎（SAE）的信息。任何有关产品的使用疑问，欢迎加入我们的客户交流钉钉群：23156632。

发表了文章 2019-11-22

12月02日云栖号头条：得算法者得天下？不如说：得数据者得天下！

今日最新云头条快讯：当下的5G依然处于行业探索的初期，究竟将在哪一个领域率先引爆尚待观察；AI成经济增长新动力，提升快餐业自动化程度；算法当然很重要，可是没有数据，你拿什么去“算”呢？一起来看最新的资讯：互联网行业，得算法者得天下？不如说：得数据者得天下算法当然很重要。可是如果没有数据，你拿什么去“算”呢？数据是继土地、劳动、资本后第四大生产要素，尽管我们常常忽略它，但其重要意义非同一般。更深一步，人工智能比拼的并不是算法，而是数据，“得数据者得天下，得数据者得算法”，互联网巨头深深把控着消费端数据，最有望在数据时代脱颖而出。万物互联将极大丰富数据的维度，数据在娱乐、商业模式等方面都有着广阔的空间。当快餐业拥抱人工智能，麦当劳如何加码布局AI？人工智能是未来几十年加速全球经济增长的新动力。麦当劳餐厅结合人工智能技术手段，整合自助点餐系统、美味特调、无现金支付、送餐到桌等元素，为顾客提供数字化、个性化和人性化的产品与服务。这与可口可乐利用大数据和人工智能来发展业务非常相似：从AI为动力的自动售货机到社交媒体监控，来决定应该关注的项目或产品。快查手机！5000多张人脸照正被贱卖，央视曝光细思极恐人脸信息可以用于刷脸支付、安防准入、身份验证等多种场景，可以说是和指纹、身份证同样重要的个人信息。可是，对人脸信息的保护显然还很不够。记者调查发现，人脸信息在网上被公开兜售，5000多张人脸，打包只要10元。 5G应用不断开放“朋友圈”，真正大规模爆发场景尚未确定从技术探索到应用落地，5G通信技术不仅引发了全球新一轮技术的竞速，也使得各项新兴技术拥有深度融合的可能，为人们的生活带来多重改变。不仅与人们备受关注的虚拟现实、自动驾驶、人工智能等新兴领域结合，亦能逐渐渗透到传统农业、日常办公中，成为提升生活便捷程度的引擎。与此同时，通过开放、连接、创新，推动应用落地也成为各个国家5G推动者的共鸣。科技部副部长李萌：5G时代更需重视科技伦理的治理科技部副部长李萌在“第十一届中国经济前瞻论坛”上称，科技伦理是科技活动必须遵守的行为准则，对科技的健康发展乃至社会的安全都有重大的影响。科技伦理是约束人的，没有好技术和坏技术之分，只有好人和坏人之分。【快速入门】一文带你读懂阿里云产品云服务器ECS入门个人版快速入门介绍如何使用ECS管理控制台创建、连接以及释放实例。【场景入门】带你了解阿里云基础场景数据迁移方案概览 RDS提供了多种数据迁移方案，可满足不同上云或迁云的业务需求，使您可以在不影响业务的情况下平滑将数据库迁移至阿里云云数据库RDS上面。将数据迁移到OSS 用户希望将历史数据迁移到用户在OSS的某个目标Bucket上。【热门案例】你爱吃的坚果上云啦——三只松鼠上云案例三只松鼠：“大促期间使用 k8s 节省资源，通过资源限定和优化，可以充分利用硬件资源，资源水位占比可以有效的控制在60%左右。线上发现问题可以快速滚动迭代，解决了服务上下线不优雅影响业务的痛点，增加了用户体验。整体感受快、稳、方便”——三只松鼠云造技术中心鼠稻米云原生架构助力花生日记双11大促花生日记：“我们架构到云原生微服务体系架构后系统整体的可靠性、稳定性、弹性和容错能力得到了很大提升，也提高了我们的IT资源利用率。帮助我们双十一平稳的支撑了平时6倍的业务高峰，峰值达到40k QPS。——花生日记技术总监文玩交易平台——微拍堂的上云之路微拍堂：“作为国内首席移动端拍卖交易平台，公司业务发展迅速，给我们在跨公有云备份这块带来了新的挑战。阿里云DBS配置灵活、功能完善，很好解决了我们手工维护痛点。”—— 杭州微拍堂文化创意有限公司数据库负责人田红阳全品类新租赁平台——人人租机的上云案例人人租机：依靠阿里小程序赋能，接入芝麻信用风控体系，风控效率大幅度提升且逾期率降低了10倍。上线至今，日订单量达到2000单，用户增长20倍，交易订单量增长15倍，实现了依托于APP和原有渠道三年都无法实现的增长规模。【最佳实践】基于众多客户上云的成功案例萃取而成的最优化企业上云指导电商网站业务安全使用阿里云实现电商网站运营期间的安全防护，包括防爬风险管理、DDoS防御、风险管理产品的能力及操作相关产品：专有网络VPC、DDoS高防IP、负载均衡 SLB 互联网、电商行业实时大数据分析使用阿里云服务实现电商网站购物数据实时分析后在大屏幕上展示，极大地增强数据的可读性相关产品：RDS、数据库备份、DataV数据可视化小程序业务实时监控使用ACK容器快速搭建小程序同时使用ARMS提升业务监控能力，实时监控小程序业务应用性能相关产品：对象存储OSS、容器服务ACK、ARMS

发表了文章 2019-08-20

探究Mysql索引底层的bmore树的非叶子节点数据为什么小于4kb

文章首发于我的个人博客，到个人博客体验更佳阅读哦 https://www.itqiankun.com/article/1564901799为什么要设置B+树的非叶子节点数据小于4kb呢，我们往下一探究竟原因如下所示因为数据库里面的索引就是使用的bmore树，所以我们使用sql语句来讲解bmore树的产生：比如有下面的两个常用的需求：根据某个值查找数据，比如select * from user where id=1234；根据区间值来查找某些数据，比如select * from user where id > 1234 and id < 2345。为了让二叉查找树支持按照区间来查找数据，我们可以对它进行这样的改造：树中的节点并不存储数据本身，而是只是作为索引。除此之外，我们把每个叶子节点串在一条链表上，链表中的数据是从小到大有序的。就像下面这样：改造之后，如果我们要求某个区间的数据。我们只需要拿区间的起始值，在树中进行查找，当查找到某个叶子节点之后，我们再顺着链表往后遍历，直到链表中的结点数据值大于区间的终止值为止。所有遍历到的数据，就是符合区间值的所有数据。但是，我们要为几千万、上亿的数据构建索引，如果将索引存储在内存中，尽管内存访问的速度非常快，查询的效率非常高，但是，占用的内存会非常多。比如，我们给一亿个数据构建二叉查找树索引，那索引中会包含大约1亿个节点，每个节点假设占用16个字节，那就需要大约1GB的内存空间。给一张表建立索引，我们需要1GB的内存空间。如果我们要给10张表建立索引，那对内存的需求是无法满足的。如何解决这个索引占用太多内存的问题呢？我们可以借助时间换空间的思路，把索引存储在硬盘中，而非内存中。我们都知道，硬盘是一个非常慢速的存储设备。通常内存的访问速度是纳秒级别的，而磁盘访问的速度是毫秒级别的。读取同样大小的数据，从磁盘中读取花费的时间，是从内存中读取所花费时间的上万倍，甚至几十万倍。所以我们通过减少访问磁盘索引的次数来减少这个访问磁盘的查询速度。怎么减少呢，就是让每个节点的读取（或者访问），都对应一次磁盘IO操作，这样树的高度就等于每次查询数据时磁盘IO操作的次数。所以我们要把bmore树创建成m叉树，因为m值越大，树的高度也就越低，如图所示，给16个数据构建二叉树索引，树的高度是4，查找一个数据，就需要4个磁盘IO操作（如果根节点存储在内存中，其他结点存储在磁盘中），如果对16个数据构建五叉树索引，那树的高度只有2，查找一个数据，对应只需要2次磁盘操作。如下图所示如果m叉树中的m是100，那对一亿个数据构建索引，树的高度也只是3，最多只要3次磁盘IO就能获取到数据。磁盘IO变少了，查找数据的效率也就提高了。但是m值也不是越大越好，因为不管是内存中的数据，还是磁盘中的数据，操作系统都是按页（一页大小通常是4KB，这个值可以通过getconfig PAGE_SIZE命令查看）来读取的，一次只会读一页的数据。如果要读取的数据量超过一页的大小，就会触发多次IO操作。所以，我们在选择m大小的时候，要尽量让每个节点的大小等于一个页的大小。读取一个节点，只需要一次磁盘IO操作。那么什么叫做一个节点的大小呢，比如下面的数据，下面的篮筐的这个节点，它里面存储的数据，就是可以存储所有子节点里面的数据，但是不包含本节点的数据，本节点的数据在本节点的父节点里面存储着。什么意思呢，看下面的图片，下面的蓝框里面的30,65其实是在下面的蓝框的父节点红框节点里面存储着，然后下面的绿色框里面的30,65其实是在父节点蓝框节点里面存储着，同时蓝框节点还存储着下面的绿色框里面的所有字节点数据，所以只要保证红框节点，蓝框节点等节点的数据大小不超过4kb就可以了,那么如果超过了怎么办呢，超过4kb大小的节点都会被mysql处理掉，这里就要去看bmore树的添加和删除了能看到这里的同学，就帮忙点个赞吧，Thanks(･ω･)ﾉ

发表了文章 2019-01-23

挂载失败-日志中显示僵尸pod的问题

问题描述：如果一个pod一直无法删除、创建不成功，且在pod所在节点查看日志文件: /var/log/messages 发现有下面的日志：如何查看Pod所在节点？ # podname="nas-static-56b6c699d6-xq4xx" # namespace="default" # nodeIp=`kubectl describe pod $podname -n $namespace | grep Node: | awk -F'/' '{print $2}'` 登录节点并查看日志： # ssh $nodeIp # tailf /var/log/messages Dec 25 16:44:48 iZ2ze65lci9pegg2wr99g9Z kubelet: E1225 16:44:48.581657 21207 kubelet_volumes.go:140] Orphaned pod "06fa705f-0821-11e9-8cd4-00163e1071ed" found, but volume paths are still present on disk : There were a total of 2 errors similar to this. Turn up verbosity to see them. 问题解读： Dec 25 16:44:48 iZ2ze65lci9pegg2wr99g9Z kubelet: E1225 16:44:48.581657 21207 kubelet_volumes.go:140] Orphaned pod "06fa705f-0821-11e9-8cd4-00163e1071ed" found, but volume paths are still present on disk : There were a total of 2 errors similar to this. Turn up verbosity to see them. 上面的错误日志表示：有2个Pod目前处于僵尸Pod状态，且最新一个podId为：06fa705f-0821-11e9-8cd4-00163e1071ed。只有处理完显示的podid后，才能显示下一个podid，所以我们需要先处理第一个pod，然后再查看/var/log/messages日志，拿到下一个有问题的podid。问题原因：Pod 异常退出，导致数据卷挂载点在卸载过程中没有清理干净，最终导致Pod沦为僵尸Pod。Kubelet的GC流程对数据卷垃圾回收实现并不完善，目前需要手动或脚本自动化实现垃圾挂载点的清理工作。解决此问题的核心为：删除报错pod的垃圾挂载点目录，但删除时确保不能误删数据。解决办法1：在问题节点上运行下面脚本： # wget https://raw.githubusercontent.com/AliyunContainerService/kubernetes-issues-solution/master/kubelet/kubelet.sh # sh kubelet.sh 解决办法2：需要对每个Pod进行如下处理： 1.查看pod挂载点： mount | grep 06fa705f-0821-11e9-8cd4-00163e1071ed 如果有挂载点存在，需要执行umount *(挂载点)，卸载； 2.查看Pod数据卷目录的残余信息： 1) ls /var/lib/kubelet/pods/06fa705f-0821-11e9-8cd4-00163e1071ed/volumes/ 看数据卷目录下面还有什么挂载目录；例如：alicloud~disk kubernetes.io~secret 2) 查看上面发现的目录下面子目录，删除子目录。例如： ls /var/lib/kubelet/pods/d9aec562-13fa-11ea-a9b7-00163e084110/volumes/alicloud~disk 下面包含：d-wz906mxhbe3qk051vmwv d-wz9d6z27o4s3d4736opw；需要删除这两个文件夹，千万注意下面情况： 3）只能删除目录为空的文件夹。如果目录不为空，说明这个文件夹还在挂载某个存储设备，或者使用了本地存储并保存了数据；如果是挂载了外置设备，需要先umount挂载设备，然后删除目录；如果是使用了本地存储，需要先将保持的数据备份、转存后删除目录； 4）为了避免误删，请使用rmdir命令，而避免使用rm -rf；例如：rmdir /var/lib/kubelet/pods/06fa705f-0821-11e9-8cd4-00163e1071ed/volumes/alicloud~disk/d-wz906mxhbe3qk051vmwv rmdir命令，可以在当目录不为空时，删除失败，更大限度的保护数据；该问题为kubelet处理数据卷时候导致的问题，目前社区正在讨论解决方案： https://github.com/kubernetes/kubernetes/issues/60987

云栖社区直播_个人页

个人介绍

擅长的技术

奶牛戴上VR眼镜“看片”，开心了可以多产奶：俄罗斯官方做了实验，拯救奶牛的冬季忧郁

大数据是否为小企业创造了竞争优势?

机器学习正遭遇“可重复性危机”，或已成“炼金术”？

为什么会有那么多的云计算浪费?

物联网在智慧城市中如何用于交通控制?

Delta元数据解析

spring中，多个service发生嵌套，事务是怎么样的？

云服务器ECS选型配置参考指南

阿里云数据库和自建数据库有什么区别？优缺点对比

阿里云 Serverless 应用引擎（SAE）发布 v1.2.0，支持一键启停、NAS 存储、小规格实例等实用特性

12月02日云栖号头条：得算法者得天下？不如说：得数据者得天下！

探究Mysql索引底层的bmore树的非叶子节点数据为什么小于4kb

挂载失败-日志中显示僵尸pod的问题

奶牛戴上VR眼镜“看片”，开心了可以多产奶：俄罗斯官方做了实验，拯救奶牛的冬季忧郁

大数据是否为小企业创造了竞争优势?

机器学习正遭遇“可重复性危机”，或已成“炼金术”？

为什么会有那么多的云计算浪费?

物联网在智慧城市中如何用于交通控制?

Delta元数据解析

spring中，多个service发生嵌套，事务是怎么样的？

云服务器ECS选型配置参考指南

阿里云数据库和自建数据库有什么区别？优缺点对比

阿里云 Serverless 应用引擎（SAE）发布 v1.2.0，支持一键启停、NAS 存储、小规格实例等实用特性

12月02日云栖号头条：得算法者得天下？不如说：得数据者得天下！

探究Mysql索引底层的bmore树的非叶子节点数据为什么小于4kb

挂载失败-日志中显示僵尸pod的问题