雲計算

雲計算

首次揭秘 | 淘宝新发布的躺平如何做3D场景化导购?

作者|赵斌强(乐田)出品|阿里巴巴新零售淘系技术部 赵斌强(乐田)——阿里巴巴资深算法专家,现任淘系技术部算法负责人,在内容推荐、商品导购、机器学习等方向有很多深入的工作。作为近一年来的新工作方向,「3D 场景化导购算法」是乐田在「中国计算机大会2019」的演讲,主要介绍 3D 和机器学习的结合,打造新的场景化导购的商业场景应用。 关注「淘系技术」微信公众号,回复“场景”即可获得「2019中国计算机大会-3D 场景化导购算法」专场 PPT 下载链接,赶快下载吧~ c 场景化导购 2012 年市场上开始出现导购,主要以单品形式做个性化推荐。虽然现在来看是非常普通的,但在 2012、2013 年是非常新的方式。随后在内容导购方面尝试新的突破,主要以图文、短视频、直播作为导购的载体。 随着 3D 技术日渐成熟,3D 自动理解、自动创作和渲染技术可以进一步把物理世界和虚拟世界结合起来,形成新的用户场景。我们开发了一个新的导购产品——躺平,大家可以在淘宝的搜索框搜索「躺平」,来体验 3D […]

雲計算

看云栖说云栖——数据上云、灾备上云、老艺术家们

墨菲:你是一个奴隶,尼奥,和所有人一样,你生来即为奴,你生在一座自己感知不到的监狱,囚禁意识的监狱。矩阵是什么是说不清的,你必须亲眼得见,这是你最后的机会,一旦作出选择,再无回头之路。选择蓝色药丸,到此为止,你就当是睡了一觉,醒来继续过自己的日子。选择红色药丸,继续漫游仙境,我带你见识一下这兔子洞有多深。 其实上次有关存储的话题并没有聊完,这次云栖大会和存储资源相关的论坛有两个:一个是上次的《下一代存储技术与最佳实践专场》,还有一个就是这次要聊的《数据上云与数据智能专场》,这个专场的主持人是阿里云MVP狒哥张广彬,存储行业的老前辈。首先,阿里云巴巴研究员,阿里云智能存储产品资深总监作了《数据上云与数据智能》的演讲。首先是一段引自IDC的报告,是有关数据存储位置的预测: 2020年公共云存储量将超过个人设备的总存储量,我的理解就是个人的数据都跑到公共云上去了。 2022年公共云存储量超过企业数据中心总存储量,我的理解是企业的数据也会都跑到公共云上去。 2025年公共云存储占有50%总存储量,世界上一半的数据都要存储在公共云。 为什么人们都会把数据存储在公共云,我认为是因为下面这几点: 存储在公共云更简单,存储的管理是一件很麻烦的事情。 存储在公共云更安全、更可靠,云上的多地域、多可用区、多副本架构更能保证数据的安全。 存储在公共云成本更低,可以按需使用,避免闲置浪费,同时围绕着存储系统管理运维的成本都将被云上所有的租户所分摊。 存储在公共云更有利于作数据分析,在云上可以调度更多的资源和使用更先进的技术对数据进行更高效的分析,可以加速从数据到业务价值的转换过程。 现在阿里云上有包括ESSD、SSD、高效云盘、普通云盘四种弹性块存储介质,为了让客户的使用和购买更加简单,阿里云推出了全球首个存储容量单位包。存储容量包SCU可以理解为存储世界中以PL1 级 ESSD为标准的货币体系: 1 TB SCU = 2.857 TB 高效云盘

雲計算

业务系统的带宽能力

一、云产品的默认带宽 云产品 默认最大带宽(M) 作用 ECS固定带宽 200 EIP绑定ECS,可提高ECS公网带宽 弹性公网ip 500 EIP绑定ECS,可提高ECS公网带宽 共享带宽 5000 EIP加入共享带宽后,可提升ECS公网带宽 负载均衡SLB 5000 将公网带宽灵活分配到ECS上 (温馨提示:可以通过工单形式提升单品的带宽) 二、云盘吞吐量 云盘 最大吞吐量(MB)

雲計算

助力云上开源生态 – 阿里云开源大数据平台的发展

本场视频地址:助力云上开源生态 – 阿里云开源大数据平台的发展 本次分享的内容主要分为四个部分: 发展历程 云上现状 云上开源生态的最佳实践 开源大数据平台的发展展望 一、发展历程在2015年,阿里巴巴刚开始做开源大数据平台的时候,摆在面前的有三种选择,分别是使用开源的Hadoop体系、CDH和HDP,以及当时的ODPS(现在的MaxCompute)。在那个时候,在大洋彼岸的AWS有一款大数据产品叫做EMR,因此阿里云当时也希望借鉴AWS的经验来做开源大数据平台,希望将大数据能力和云原生能力进行深度结合。 阿里云在2015年6月份的时候就开始研发自己的开源大数据平台并实现了第一个“镜像+脚本”的版本,这个版本可以实现在最短的时间内将Spark环境搭建起来,而且这个版本很快上线并且发布到GitHub上。当时使用的API很像现在的编排服务,但是这样服务的缺点是只能一次性搭建,因此维护起来非常麻烦。 在2015年11月份,阿里云正式将E-MapReduce独立云产品推出市场。大家都知道MapReduce的思想来自于谷歌,其代表了大数据理论,因此阿里巴巴将这款大数据产品命名为E-MapReduce,使得大家看到名字就知道其产品的主要作用。 阿里云E-MapReduce上线之后经过四年的时间发展到现在,E-MapReduce 4.0即将发布版本,并且在新版本中将会支持Hadoop 3.0以及其他新功能。 发展到今天,阿里云E-MapReduce将会为开源生态提供基础平台,在这个平台上能够让大家选择各种各样的开源产品,并且不会限制大家使用自定义的能力。此外,阿里云E-MapReduce也希望能够将阿里巴巴整个云智能平台的计算能力输出给大家,为大家提供云原生能力和弹性调度能力。未来,E-MapReduce会陆续集成各种开源技术和能力,并且会在这些开源技术之上为大家提供更好的优化的技术,一方面提高稳定性,另外一方面也提升性能,并且也会进行能力的适配。最后一点就是实现云原生的结合,大家使用开源或者自建的大数据方案往往难以和云原生技术或者基础设施进行结合或者难以获得较高的性能,因此阿里巴巴希望通过E-MapReduce能够更好地和云原生技术进行结合。 总结阿里巴巴E-MapReduce的发展历程,最开始就是实现了一个AWS EMR Like的产品,运行一年之后发现AWS的纯动态方式并不适合国内的场景,因此实现了第一次调整,更加重视常驻集群,并且强化作业合度调度能力。经过第一次调整之后,阿里云发现E-MapReduce的能力还是无法满足需求,因此在第二次调整中提供了完善的Web控制台能力,并且支持了集群的高可用和高安全,也在外围支持了Impala、Kafka、Druid等各个场景下的软件,进而可以更好地支持各个业务场景。除此之外,还支持了深度学习的场景,将经过阿里巴巴自身优化的机器学习算法提供到平台之上。如今,E-MapReduce仍在继续调整,希望能够提供更加完善的大数据平台,更加智能化的服务能力,并且使得底层更加轻量,也使得计算平台整体能力能够对外输出出去。 二、云上现状云上的生态概览下图展示了阿里云的大数据生态概览。在数据来源方面,开源方面有HDFS和Kafka,阿里巴巴则提供了OSS、SLS、RDS以及消息队列等服务。所有数据可以通过开源的Hive、Spark、Flink、Rresto、TensorFlow以及阿里巴巴的MaxCompute、Flink/TensorFlow等服务进行计算,并且还可以与阿里的自身体系如DataWorks、DataV以及QuickBI进行融合。目前,云上大数据方案可以认为是半托管的服务,阿里云能够帮助客户进行运维并且提供运维支撑服务。 多样的存储选择在阿里云上,大数据存储主要有三种选择,分别为Hadoop

雲計算

国内首个,阿里云通过分布式块存储国家标准认证

10月28日,记者了解到,存储国家标准——GB/T 37737-2019《信息技术云计算分布式块存储系统总体技术要求》测试认证已经取得阶段性成果,阿里云成为首个通过该标准测试的云厂商。 在不久前结束的杭州云栖大会现场,中国电子技术标准化研究院云计算研究室主任杨丽蕴透露,阿里云率先通过该认证测试,并发布了测试流程及要求。 过去一年,云计算领域多项标准正在逐步完善,存储作为云计算的基础设施之一,也迈出了坚实一步。2019年8月30日,经国家市场监督管理总局批准,GB/T37737-2019《信息技术云计算分布式块存储系统总体技术要求》正式发布,首次对块存储技术和产品进行了规范,评估范围涵盖可靠性、可用性、易用性、扩展性、兼容性和安全性等方面。 通过认证测试,意味着阿里云块存储产品在性能、安全以及可信上均达到了国家要求,可满足不同场景的云存储需求。 十年前,阿里巴巴研发了大规模分布式存储系统盘古,基于独创的分布式架构和算法,已推出多个业界领先的存储产品。例如, ESSD是全球首个百万IOPS云盘,时延降至百微秒级别,数据可靠性为9个9,同时支持快照与数据加密。 5G和AIoT时代的到来正在加速企业上云的进程。IDC报告指出,2022年公共云存储量将超过企业数据中心总存储量。阿里云拥有全球最丰富的存储产品家族,总数据存储量达数十EB,大规模应用金融、零售、制造、电信等领域。凭借多层次防护、跨区域容灾等能力连续三年入选Gartner全球云存储魔力象限,并且被列为全球领导者地位。

雲計算

1.1 云原生历史

云原生的发展历程 云原生(Cloud Native)最初来描述云上应用的典型架构与特性,随着容器、kubernetes、Serverless、FaaS技术的演进,CNCF(Cloud Native Computing Foundation ,云原生计算基金会)把云原生的概念更广泛地定义为“让应用更有弹性、容错性、观测性的基础技术,让应用更容易部署、管理的基础软件、让应用更容易编写、编排的运行框架等”,希望能够让开发者最好的利用云的资源、产品和交付能力。 下边大致梳理一下云原生的发展过程。 2004 年 ~ 2007 年,Google 已在内部大规模地使用像 Cgroups 这样的容器技术;2008 年,Google 将 Cgroups 合并进入了

雲計算

机器学习算法—KNN算法原理及阿里云PAI平台算法模块参数说明

概述: KNN算法一般也会经常被称为K邻近算法,其核心思想是根据训练集中的样本分类计算测试集中样本与训练集中所有样本的距离,根据所设定的K值选取前K个测试样本与训练样本最近的结果,结果中大多数训练样本所处在的类别即是本测试样本的类别。因训练样本的分类结果为已知因此KNN算法属于有监督学习算法。 算法原理: 1、以下图样本散点图展示训练集的整体分布情况从散点图中可以发现训练集的数据分类数量为3个类别,分别为蓝色类别、红色类别和黄色类别,训练样本总数为15个。2、导入第一个测试样本3、需要根据已知的训练样本分类结果判断测试样本的类别,因此计算测试样本与所有训练样本的距离因训练样本数量为15,所以计算完成的距离参数为15个。4、K值是KNN算法中唯一需要设定的参数,假定K值为3则在15个距离参数中选择最近的3个统计3个距离中大部分训练样本所处的分类即为本测试样本的分类,本次分类中距离最近的3个训练样本有2个属于红色类别,因此本测试样本被分类为红色5、对下一个测试样本以相同方式进行距离计算和分类 注意事项: 1、K的取值尽量为奇数以确保距离计算结果必定会有一个K个距离中包括较多的类别,比如例子中取3,则3个中有2个训练样本为红色类别以此判断测试样本属于红色类别。如K取4产生下图中的情况4个距离参数中,2个训练样本为红色类别,2个训练样本为蓝色类别,会对预测产生不利效果2、K取值过小时,较容易受噪声影响而导致误分类如图中黄色类别中有一个异常数据,如果K取值为1,则测试样本因与此异常数据距离最近,而被分类为黄色类别,从散点图中可以看到,如K为3以上,则应被分类为红色类别,因此K取值过小容易导致由过拟合而引起的误分类。3、K取值过大时,较容易受距离较远训练样本影响而导致由欠拟合产生的误分类,极端情况下,本文的例子中如果K取值为15,则代表蓝、黄、红,哪个类别的点多测试样本就被分类为哪个样本,因此K不能等于N。 算法的使用场景: 1、适合用于类别间差异较大,同类别间数据差异较小的场景2、对于类别间的界限不清晰的场景,效果好于基于线性分类的逻辑回归3、单个测试样本计算都需要计算与训练集中所有训练样本的距离,在数据量较大时会占用非常多的计算力并增加计算时间4、对于各个类别中数据数量差异较大的场景效果较差,特别在K取值又较大时,占数量优势的类别对于结果的影响非常明显 阿里云PAI平台算法模块及参数设置说明: trainTableName:训练表的表名trainFeatureColNames:训练表中的特征列名,即训练表是根据哪些特征来进行分类的trainLabelColName:训练表中标签列的列名,即训练表中的分类结果trainTablePartitions:训练表中指定哪些分区predictTableName:预测表的表名outputTableName:输出表的表名predictFeatureColNames:预测表中特征列名 ,默认与trainFeatureColNames相同,如果数据预处理做得较好,训练集和测试集中的特征列名本来就是应该相同的predictTablePartitions:预测表中指定哪些分区参与预测,默认为所有partitionsappendColNames:输出表中附加预测表的列名,默认与predictFeatureColNames相同outputTablePartition:输出表分区,默认输出表不分区K:是整个算法中唯一需要选择的参数,在模块中为可选项因为K的取值模块中默认为100,最适合的K值需要根据预测结果来进行确定enableSparse:输入表数据是否为稀疏格式 itemDelimiter:当输入表数据为稀疏格式时,kv间的分割符,默认值为空格kvDelimiter:当输入表数据为稀疏格式时,key和value的分割符,默认值冒号coreNum:节点个数,与参数memSizePerCore配对使用,默认自动计算memSizePerCore :单个节点内存大小,单位为MB 正整数,默认自动计算lifecycle:指定输出表的生命周期

雲計算

用阿里API评测T5实例的基线性能

阿里API犹如天上的星星,数量繁多,又闪闪发光.每颗星都因其独特的光芒而耀眼,让在黑暗的夜里行走的路人,看到希望的星光;在最近举行的T5 baseline性能评测的活动中,有幸参与其中,通过赠送的代金券免费购买和使用一周的T5基线实例,并通过一些相关又好玩的API接口运行测试ECS服务器的一些基本功能;详细情况如下:本次的验证软件链接:http://xysuger.xunyun17.xyz/BaselineReviewT51C2G/BaselineReviewT51C2G.rar 第一大步,购买ECS服务器: 首先通过官方ecs购买主页,选择基线性能20%的t5-lc1m2.small类型的ecs,购买时长1周;然后选择64位的ubuntu操作系统:接着选择默认的交换机配置:最后在summary界面确认无误后,点击确认,使用代金券付费; 第二大步,通过API接口测试服务器:首先通过DescribeInstances命令,察看购买的服务器,这里可以看到服务器的状态为运行,其他配置和我们购买的一致;接着停止运行服务器,通过StopInstance命令,运行后,返回对应的requestid:通过运行查询命令,可以看到,服务器状态已经停止;然后运行StartInstance命令后,启动服务器;接着运行RebootInstance命令,可以看到,服务器的状态变为stopping,然后是starting,最后是running; 下面看一下服务器的标签功能,先用TagResources命令,给服务器打一个值为review,类型为Baseline的标签.然后,通过ListTagResources命令,察看我们打好的标签,是否正确:最后,通过UntagResources命令删除标签,在查询时,已经看不到刚才的标签了; 最后再来看看,服务器的系统事件功能,先通过CreateSimulatedSystemEvents命令,创建两个模拟系统事件; 然后通过CancelSimulatedSystemEvents命令,删除其中一个事件;(:a.ECS.SysEvent.CancelSimulatedSystemEvents.cn-hangzhou.e-bp11ebj178k4b8kihpw6. 最后通过DescribeInstanceHistoryEvents命令,察看已经运行和已经删除系统事件的历史记录: 通过上面三大类别和ECS相关的API接口测试,可以得出结论,突发型T5基线性能的ECS服务器,确实很不错,值得拥有!

雲計算

数据零丢失! 阿里云数据库RDS for MySQL 三节点企业版正式商用!

2019年10月23号,阿里云数据库RDS for MySQL 三节点企业版正式商用,RDS for MySQL三节点企业版基于Paxos协议实现数据库复制,每个事务日志确保至少同步两个节点,实现任意节点宕机后数据零丢失,数据库整体RPO为0。RDS for MySQL三节点企业版适用于数据敏感性业务,如金融行业,电商行业订单业务等。 据介绍,阿里云数据库RDS for MySQL 三节点企业版5.7 版本对数据复制算法重构,改变5.6版本基于raft算法的数据复制而代之以Paxos算法来接管副本日志。 通过协议确保不同副本之间日志一致性,数据库数据状态由日志推进,只有当日志在多数派副本持久化才认为已经达成集群一致,数据状态机也只会应用已达成多数派的日志,故三节点能够保证数据强一致,任何一个节点的不可用不会影响到集群达成一致性的决定。 另外,在技术上将第三节点只保留日志文件而无数据文件,大幅降低成本,这体现在5.7版本三节点企业版的售价要远低于5.6版本,具备很大的性价比优势。RDS for MySQL三节点企业版的架构图如下。阿里云RDS MySQL产品负责人陈招尚表示,RDS for MySQL

雲計算

中国商业银行数字化转型调查研究报告发布,网商银行联手OceanBase打造未来金融业典范

2019年10月18日,商业银行数字化转型与发展研讨会暨《中国商业银行数字化转型调查研究报告》发布会在北京召开。由中国互联网金融协会、新华社瞭望智库联合撰写的《中国商业银行数字化转型调查研究报告》(下称《报告》)正式发布,蚂蚁金服作为撰写支持机构,深度参与了《报告》的调查和研究工作。《报告》全面介绍了中国商业银行数字化转型的机遇、挑战和转型路径,并且收录了银行数字化转型的典型案例,其中包括“蚂蚁金服自主研发的金融级分布式关系数据库OceanBase助力网商银行业务发展”。 资料显示,蚂蚁金服相关技术产品及解决方案已经在金融行业得到广泛落地实施。近期成为首个登顶“数据库领域世界杯”TPC-C基准测试的中国数据库产品——蚂蚁金服自主研发的金融级分布式关系数据库OceanBase,此前就助力网商银行开创了互联网银行业务新模式。 网商银行是中国第一家核心系统基于云计算架构的商业银行,在实践中开启了新型银行商业模式,在没有一个网点的情况下,截至目前,网商银行已为超过2000万家小微企业及个体经营者提供了贷款支持。 为满足低成本、高可用、高弹性的业务需求,以及银行业的强监管要求,网商银行选择了自主可控的金融级分布式数据库 OceanBase 作为核心数据库搭建银行核心系统,达到了银行业最高容灾等级标准要求和业内领先的灾难恢复能力等级,保障了银行交易系统的稳定性和用户数据安全。 与传统的商业数据库相比,OceanBase数据库集群基于普通PC级服务器,可实现整体成本节省30%,恢复时间目标(RTO)小于30秒,恢复点目标(RPO)为0。目前,网商银行依托蚂蚁金融技术支撑已实现小微企业贷款“310”模式(3分钟申贷,1秒钟放款,全程0人工介入)。在蚂蚁金融技术加持下,网商银行每笔贷款的平均运营成本仅为2.3元,较中小企业贷款的平均人工成本2000元大幅降低。 据悉,作为蚂蚁金服自主研发的的金融级分布式关系数据库,OceanBase具备丰富的关系数据库功能,支持完整的 ACID 特性,首创的“三地五中心”城市级故障无损容灾方案正受到银行业的广泛认可,并拥有三方面的显著优势:可扩展、强一致、高可用。 可扩展:传统关系型数据库通常都采用集中式架构,多为单机数据库,容量有限,不能满足大规模水平扩展需求。OceanBase作为新一代分布式数据库的代表,采用了Shared-Nothing架构,通过对数据进行水平拆分,将数据保存到各台服务器的本地磁盘,不再依赖于高成本的共享存储,从根本上解决了单点性能瓶颈的问题,能够实现快速水平扩展,在线完成扩容、缩容,并且在扩容缩容期间不停机,从而完美的解决了扩展性的问题。 强一致:OceanBase数据库采用严格的Paxos分布式一致性协议,数据提交时在多个副本上实现强同步并持久化,任何节点故障都不会造成数据丢失,保证了RPO=0。 高可用:在OceanBase当中,每一份数据都在多地保存了多个副本,依靠Paxos多数派协议在日志层确保数据改变在各个副本之间同步,实现了城市级容灾,集群中少数派故障时数据不丢,服务不停,RPO=0(少数成员故障),RTO保证在30秒之内,这在业界达到了非常领先的水平。 OceanBase分布式数据库架构图 随着物联网、云计算等新兴产业的快速发展,金融行业的数字化转型急需构建强有力的技术支撑体系和 IT 能力。蚂蚁金服通过持续向银行业输出完整的金融科技实力,将满足更多的新兴市场需求,深化金融场景下的前沿探索。

Scroll to Top