互联网

前言 掌门1对1精耕在线教育领域，近几年业务得到了快速发展，但同时也遭遇了“成长的烦恼”。随着微服务数量不断增加，流量进一步暴增，硬件资源有点不堪重负，那么，如何实现更好的限流熔断降级等流量防护措施，这个课题就摆在了掌门人的面前。由于 Spring Cloud 体系已经演进到第二代，第一代的 Hystrix 限流熔断降级组件已经不大适合现在的业务逻辑和规模，同时它目前被 Spring Cloud 官方置于维护模式，将不再向前发展。 如何选择一个更好的限流熔断降级组件？经过对 Alibaba Sentinel、Resilience4j、Hystrix 等开源组件做了深入的调研和比较，最终选定 Alibaba Sentinel 做微服务体系 Solar 中的限流熔断降级必选组件。 Sentinel 简介 阿里巴巴中间件部门开发的新一代以流量为切入点，从流量控制、熔断降级、系统负载保护等多个维度保护服务的稳定性的分布式系统的流量防卫兵。它承接了阿里巴巴近10年的双十一大促流量的核心场景，例如秒杀（即突发流量控制在系统容量可以承受的范围）、消息削峰填谷、集群流量控制、实时熔断下游不可用应用等。它具有非常丰富的开源生态： 它和 Hystrix 相比，有如下差异： 摘自官网 Sentinel Roadmap 关于 Sentinel 如何使用，它的技术实现原理怎样等，官方文档或者民间博客、公众号文章等可以提供非常详尽且有价值的材料，这些不在本文的讨论范围内，就不一一赘述。笔者尝试结合掌门1对1现有的技术栈以及中间件一体化的战略，并着眼于强大的 Spring Cloud Alibaba 技术生态圈展开阐释。 Sentinel 深度集成 Apollo Sentinel 官方在 sentinel-datasource-apollo 模块中已经对 Apollo 做了一些扩展，主要实现了 Sentinel 规则的读取和订阅逻辑。这些并不够，我们需要对 Apollo 进行更深层次的集成。 摘自官网 在生产环境中使用 Sentinel Solar SDK 环境初始化 定制 EnvironmentPostProcessor 类，实现如下： Sentinel Dashboard 的项目名称从 Apollo AppId 的维度进行展示根据环境 env 值读取相应的配置文件，并访问对应环境的 Sentinel Dashboard 域名Sentinel Dashboard 在生产环境部署若干台 ECS 实例，阿里云 SLB 做负载均衡，实现对集群的水平扩展public class SentinelClientEnvironmentPostProcessor implements EnvironmentPostProcessor { private final ResourceLoader resourceLoader = new DefaultResourceLoader(); private static final String DEFAULT_CLASSPATH_LOCATION = "classpath:/META-INF/app.properties"; private static final String DEFAULT_LOCATION = "/META-INF/app.properties"; private static final String DEFAULT_LOG_LOCATION = "/opt/logs/"; @Override public void postProcessEnvironment(ConfigurableEnvironment environment, SpringApplication application) { try { Resource appResource = resourceLoader.getResource(DEFAULT_CLASSPATH_LOCATION); if (!appResource.exists()) { appResource = resourceLoader.getResource(DEFAULT_LOCATION); } Properties appProperties = new Properties(); appProperties.load(new InputStreamReader(appResource.getInputStream())); String appId = appProperties.getProperty("app.id"); System.setProperty("project.name", appId); System.setProperty("csp.sentinel.log.dir", DEFAULT_LOG_LOCATION + appId); Properties properties = new Properties(); String path = isOSWindows() ? "C:/opt/settings/server.properties" : "/opt/settings/server.properties"; File file = new File(path); if (file.exists() && file.canRead()) { FileInputStream fis = new FileInputStream(file); if (fis != null) { try { properties.load(new InputStreamReader(fis, Charset.defaultCharset())); } finally { fis.close(); } } } String idc = properties.getProperty("idc"); String location; String env = System.getProperty("env"); if (StringUtils.isEmpty(idc)) { if (!isBlank(env)) { env = env.trim().toLowerCase(); } else { env = System.getenv("ENV"); if (!isBlank(env)) { env = env.trim().toLowerCase(); } else { env = properties.getProperty("env"); if (!isBlank(env)) { env = env.trim(); } else { env = Env.FAT.getEnv(); } } } location = "classpath:/META-INF/sentinel-" + env + ".properties"; } else { location = "classpath:/META-INF/sentinel-" + idc + ".properties"; } Resource serverResource = resourceLoader.getResource(location); properties.load(new InputStreamReader(serverResource.getInputStream())); for (String key : properties.stringPropertyNames()) { System.setProperty(key, properties.getProperty(key)); } System.setProperty(CommonConstant.SENTINEL_VERSION_NAME, CommonConstant.SENTINEL_VERSION_VALUE); } catch (Exception e) { LOG.error(e.getMessage()); } } private boolean isBlank(String str) { return Strings.nullToEmpty(str).trim().isEmpty(); } private boolean isOSWindows() { String osName = System.getProperty("os.name"); return !isBlank(osName) && osName.startsWith("Windows"); } } ...

文 |《财经》记者 谢丽容 秋冬交替往往在一夜之间。这一年，受疫情的客观影响，数字化新旧时代的交替，从稳步推进，转变为一夜之间——数字化成为中国经济的主要驱动力，变革因为疫情而更加强烈，政府、企业都认识到数字化的迫切性。 6月9日，在2020阿里云峰会上，《财经》主编何刚对话阿里云智能总裁张建锋，张建锋认为，经此一“疫”，原本需要3到5年的数字化进程，将在未来1年之内加速完成。 在这次对话中，张建锋表达了两个核心观点。 其一，阿里云历经11年的坚定投入和发展，早已演进成一朵不一样的云，不仅提供了云代表的新型计算架构，更是诞生了钉钉这样的新型操作系统，两者深度绑定，形成一个整体，为政企提供面向数字经济时代的新型基础设施。 就像传统信息时代PC和Windows的组合一样，企业既需要云这样的新型计算结构，也需要钉钉这样的新型操作系统，这是一个整体，前者提供水电煤一样的算力基础设施，后者如同新时代的Windows，让企业可以面向大数据、面向智能、面向IoT、面向移动化，快速开发管理组织和业务的所有应用。 其二，做好这个基础设施需要强大的技术能力。他认为，阿里云在软件层面已经达到世界顶尖水平，飞天是中国唯一自研云操作系统，今年将持续加大在芯片、服务器、交换机、网络等领域的自研力度。 而“做深基础”背后逻辑并不是简单替换，是基于云的特点来构建整套基础体系，就像当年阿里巴巴“去IOE”并不是做一个新的小型机替代了旧的小型机，而是用阿里云这辆汽车超过了旧时代的马车。“做深基础”要将飞天云操作系统向下延伸定义硬件，构建数字经济时代的新型基础设施。 以下为对话全文： 经此一疫，数字化加速 何刚：这次新冠疫情的蔓延，对经济和社会带来了特别重大的影响，这些影响体现在哪些方面？ 张建锋：本来我们这次活动应该是在线下举办的，但今天我们用了相对特别的方法，也是因为疫情的影响。大家都是亲历者，但之前可能不会想到疫情会对我们造成这么大的冲击。从2月开始，中国的经济重心基本转移到抗疫上面。很多人在努力，医务工作者在前线抗疫，科技工作者在后台数字化抗疫。3、4月之后，数字化抗疫的重心从前期的“抗疫”转移到“重启”经济。到今天为止，我觉得数字化已经变成中国经济重要驱动力，包括政府、企业、学校，甚至广大的老百姓，真真切切地感受到了数字化带来的改变，线上的工作、生活，包括电子商务等，无接触经济蓬勃发展，这是疫情期间带来的巨大变化。 何刚：对于企业、社会、经济发展来讲，是否意味着一个全新重构的开始？ 张建锋：疫情并不是这个时代孤立的一件事，我们今天本来就处于数字化转型的阶段，疫情对数字化是起到了非常强的推动作用，数字化变革可能会因为疫情变得更强烈。 我之前经常琢磨，秋天是怎么变化到冬天的？是一天天的温度降下来的，还是一个突然的变化过程？后来我发现，绝大部分时候是一夜之间冷空气袭来，一场狂风冷雨，瞬间就会从秋天变成冬天，季节转换完成。 这次疫情对于数字化转型进程的影响，有这个味道。由于疫情，政府企业都认识到了数字化的迫切性和重要性，普通人也享受到了数字化转型带来的很多好处，包括居家办公，电子商务等，这些需求因疫情而加速。因为疫情，很多事情本来是需要三五年的发展过程，可能会在一年之内就完成转换。 何刚：阿里云是中国数字化进程的重要推动者和参与者，也是底层技术的构建者，全球范围内，中国的数字经济大概发展处于一个什么样的阶段？有什么跟别的国家相比不太一样的重要特征？ 张建锋：阿里巴巴本身是个数字经济的亲历者，也是一个推动者。阿里巴巴过去二十年的发展基本上伴随数字经济的发展到今天。从中国来讲，我认为是中国的数字化在全球是走在最前头。我们不管在消费领域、产业领域、政府治理、甚至农业都走在前面，我认为比大多数国家都走得要更完整。 从1999年开始，美国第一次提出政府要电子化，到现在都没有我们过去三年的数字化更深入。政府也好，治理也好，产业也好，大部分人都从数字化中得到了很好的收获，所以我觉得全社会今天对数字化要不要做、或者数字经济是不是未来，这已经达到了高度共识。 今天我们关注的重点是快速实现数字化的方式，这个行业能够根据数字化来重构自己的技术体系也好，业务体系也好，这是目前最关键的。 何刚：你提到两个词，一是全面无死角，从农业、工业、服务业包括政府、个人、社会组织；二是全速，谁能够更快速地实现数字化，谁有可能在未来获得更大的一种可能性。具体说说，从全面上云到全速重构区别是什么？ 张建锋：全面上云是一个技术性阶段，原来的基础设施从非云到云；全面重构是一个更强的深化，要重构，需要关注的面会更广，包括理念要升级，组织要升级，经营模式、运营模式要升级，而上云更多着眼于技术升级。 都要升级的话，要把原来传统的信息化手段变成数字化手段，它对管理者的思路、对于经营者的思路都是一个重塑的过程。我和我们的客户交流也是这样，我们做很多数字化的项目，我们是通过交付一个项目来帮助客户打造一支团队。因为它不是在信息化时代时简单地采购产品，帮你交付就完了；因为要用好这个产品要有一个新的理念，你要重建这个产品，要重构这个组织、重构这个业务，这个是当下未来可能是最最重要的，所以我们叫做全速重构。 何刚：由于疫情，有人提到了几个行业，发现它很繁荣，我不知道这些行业会不会率先如何来实现全面重构，比如公共卫生领域、教育领域、交通，也包括大家谈得很多的工业互联网领域。 张建锋：公共卫生领域，疫情影响因素特别明显，因为计算机系统处理问题都是类似的，第一，把数据收集上来；第二，做一些分析；第三，根据分析结果做一些结论。防疫抗疫的所有环节，我认为数字化都可以发生巨大价值。比如，政府针对密切接触人员人群做外呼提醒和通知。原来是传统的人工打电话，每个外呼员，一天的极限是200通电话；现在我们采用AI的办法，一分钟打3500个电话。对方有问题，用AI来给你回答问题，这是这样一个新型的数字化体系，这个体系以前从来没有出现过。 教育方面，因为之前大家不能返校，我们知道大学推了很多年的多媒体教育，渗透率和接受度没有那么高，疫情期间，我们跟浙江大学合作，只花了7天时间就改造了200多个教室，几万师生就通过远程教育一夜之间就实现了，当天有一百多万人次的访问量，最热门的课我听说有十万人次来观看。真的是一夜之间，以前几年做的事情现在一周就做完了，还有非常多的例子。疫情催化了需求，不过这个事情，我觉得没有疫情也必然会发生。 何刚：是不是可以理解为，疫情的发生确实是一件坏事，但也为重构提供了一些新的机会，当年非典催生电子商务业态，这次新冠是不是也会催生数字经济业态？ 张建锋：非典时我们做B2B贸易，所有的企业都不能出门推销自己的产品或者谈业务了，所以就转移到网上来了，一直发展到今天，其实也证明了零售业的这种形态比原来更高效，也是串联了大量的此前感觉和零售业没有太大关系的产业，诞生了新的行业，发挥了很大作用。我觉得像新冠之后，在线教育、在家办工、远程视频会议，它的一系列影响都是深远的。这一次刚好又在数字化转型的当下，我觉得要比那一次的SARS影响更深刻。 云钉一体：数字经济时代的PC+Windows 何刚：全速重构指的是什么，中间这一部分类似于当年操作系统？ 张建锋：很多人问云到底是什么？云的理解有很多种，它有宽泛的理解和狭义的理解，狭义的理解就是原来的服务器这些东西，用新的模式来替代了。我们今天在中国讲的云，意义要宽泛多得多，今天的云，既有云基座，也有中台，也有上面的服务。 至少从我们的角度来看，云是一个新型计算体系结构，它从原来的PC时代，包括原来大机、小机的时代，全面升级成云的形式。当然，云的特点是分布式，分布式还是互联网时代的技术。云在互联网分布式基础上更强调弹性，更强调大范围调度，复用，更强调安全性，这是云本身很重要的特点。你要怎么做好云，就要一整套的云系统，我们叫做飞天云的操作系统来管理这个东西。这也是国内唯一自研的产品。 前两年阿里在说要做中台，外面也有很多人在聊类中台概念。他们虽然不理解，总觉得这是一个好东西，所以现在但凡是一个企业都在讲中台，都在建自己的中台。 我的理解，中台是一个新型操作系统，因为我们原来做信息化系统相对来说比较简单，把业务流程理解清楚了，程序员把业务流程变成一个信息系统就可以了。今天面临一个非常大的变化，因为今天的信息系统不是一个简单的业务流问题，还有数据流，还要移动化，还要用人工智能的办法通过大数据来挖掘等，这些都是以前的信息系统没有遇到过的。 这需要新型的操作系统，我们原来叫中台，其实它是超越于原来的以windows为代表的处理系统，上面做简单的信息化的开发。从信息化到数字时代它需要一个新型的操作系统，大家面向大数据、面向智能、面向IoT、面向移动化，开发自己的应用变得更方便。 不同的行业有不同的特点，有人是零售的，有人是做工业的，它们可以在中台之上继续构建自己的系统。所以中台其实是一个云时代的、大数据时代的、智能化时代的、移动化时代的一个新型的操作系统。 何刚：我理解，一个是数据中台，基于数据的；第二是基于不同行业的，叫做业务中台。可能就是数据中台对于阿里来讲是更容易让大家来通过你们的这种计算能力和云处理的能力，来实现，而业务中台可能跟行业要有一定的结合。 张建锋：阿里巴巴也好，政府也好，很多单位也好，因为现在全社会的数据非常丰富，数据的汇聚也变得更容易。因为有新型的技术手段，分析数据有类似人工智能等更好的工具，所以现在的宏观预测可以基于微观分析来直接通过算法推导出来。 不像以前，政府也好，企业也好，要一层层汇总。今天的大数据趋势，都是大量的、微观的数据融合的做分析，所以迫切的需要一套新型的工具，是基于数据的、基于人工智能的、基于移动的，我们就认为这是一个新型的中台，新型的操作系统。 何刚：有点像你们在把PC时代英特尔和微软的事做了，是吗？ 张建锋：对，我觉得计算机的体系结构变了，上面的操作系统也变了，所以像阿里云+钉钉，就相当于以前的信息时代的PC+windows，类似于这样的一个概念。 我们相当于做了社会化的公共资源，我们一直认为，云是类似水电煤一样的公共服务，我觉得这个愿景越来越变成现实了，计算资源都公共服务化了，然后再提供一个新型的操作系统，让创新变得更容易发生了。 有很多行业今年发生了很大的变化。比如金融业。从今年开始，金融行业在积极拥抱新型的计算机体系结构，因为这是一整套从原来的PC时代、小型机时代到云时代一整套新的体系结构，这个体系结构不仅仅是技术变革，它还是一整套生态环境的重构，因为它的开发方式、理念都是一个新变化。 变化首先会发生在原来信息化做的比较好的那些行业，比如金融业、政府，他们的转型速度非常快。因为很多中小企业通用化的需求更高，不用搞广泛的定制，所以社会的公共服务也能基本满足他们的需求了。 阿里云现在有300万的客户，里面绝大部分是中小企业。对于那些中小企业来讲，这个相当于一个新型的淘宝，你原来要去做零售，要在线下开一个店，你要进货要去卖，要去做所有你不擅长的事情，例如开店租房本质上跟零售没有关系。现在中小企业在云的时代，它相当于在公共服务平台，像淘宝一样。 何刚：淘宝开店，很多事情淘宝来做。他只需要自己卖东西，发货收款。 张建锋：我觉得以后所有的行业都会齐头并进，因为它这里有现实的收益，也是一个新型创新平台。 何刚：提到疫情期间的应用，您提到远程期间的应用和教育，必须提一下钉钉，之前我用钉钉用得不是那么多，但是疫情期间审批、报销、开会各种东西，好像离了钉钉那天就没法干活了，能不能跟我分享一下，在疫情期间钉钉引发的现象级的应用，它究竟对钉钉意味着什么？ 张建锋：我觉得很多人把钉钉理解为一个沟通工具，钉钉是远远超越沟通本身的，我理解成为我刚才讲的操作系统的重要组成部分，它主要解决几个问题，它非常好地解决了移动化的问题。今天包括政府也好、企业也好，它所有的服务对象、参与对象已经发生了变化，基本上人人都有智能手机，你说政府要服务一个老百姓也好，老百姓是移动化的，可以7×24小时的通过手机接触政府的服务，那就看政府有没有提供这样的服务，通过什么样的方式来提供这样的服务。 何刚：比如说到政府部门办事情，原来要搞申请公证，原来在上班时间人得去，现在如果有手机，你们有一个政务钉钉。 张建锋：在几年前办事要找到哪个部门办事，需要找到特定的办公室去办；后来，像杭州等一些地方做办事大厅，只要到办事大厅去办就可以了；再后来，推一窗通办，把原来办事大厅中每个窗口办特定的事情，改成每个窗口可以办任何事情，这里就需要后台系统进行改造，因为要有这个能力去处理所有的事情。 再之后是移动化，手机上就可以办。手机上办带来一个新的问题，你要7×24小时可办，因为手机不用下班。 整个过程一步步发展到今天，离不开后面整个系统的改造，也离不开整个政务流程的再造，这里面数字化发挥了很大作用。钉钉在这里面扮演很重要的角色，它就是移动化，又是一个新型的，里面有通讯录，有各种各样的电子流审批，它给他们要做移动化开发提供了非常好的应用。浙江省上面有一千多个应用基于钉钉这个平台开发的，这就是操作系统的典型特征，操作系统就是我自己做掉一部分事情，大家都可以在上面做更多的事情。钉钉就是一个新型的操作系统，也是我们操作系统的重要组成部分，这就是我们这边的定位。 何刚：现在在有些地方政府信息化做得比较好的，开始大量运用政务钉钉做行政管理。我们按照这样的思路，是不是未来还有各种钉钉，金融钉钉、零售钉钉、教育钉钉、医疗钉钉，会是这样的吗？有这样的规划吗？ 张建锋：我觉得钉钉本身是一个平台，大企业可能对于自己的定制化要求非常高，所以推出了企业版。我们跟税务做了一个学习新税平台，原来有几十万的税务干部是垂管干部，税务干部要去学习、考核，要进行政策的传递，以前是一层层的，今天有这样的平台之后整个系统就管理起来了。 这样的话，对组织原来的运作模式就产生了非常深远的影响。比如说，教育系统也在用钉钉，原来教育局和学校、学校和老师、老师和家长、家长和学生，它是多方的主体，有个消息要从教育局通知到学生，之前的做法是一层一层通知下来。今天用钉钉这个平台，因为所有人在这个上面，可以非常容易地形成一个环路。我作为学生家长，在疫情期间，我也收到教育局在家学习的调查问卷，你小孩子学得怎么样？学科重不重？ 原来教育局要了解学生的情况是非常难的，现在电子化，第一可以触达我，第二可以实时地知道，因为这个问卷上去的话我们很快就分析出来了。对各行各业都有很大的影响。今天我们数字化过程中就看你的业务跟数字化怎么结合，你怎么用好这样新型的一些工具跟手段，这个我觉得是最最重要的。 钉钉我觉得它本身是个操作系统，本身是个新的平台，就看大家怎么样来用好这个平台。 何刚：其实按你刚才这样一解释，我听了钉钉能做的事太多了，大家原来做一个联络工具，做一个简单的办公流程的东西，是大大低估了它潜在的对于人、信息和业务的这种连接能力。 张建锋：这就是我们刚才那个话题，就像windows和英特尔一样，他们是深度绑定成一个整体，对于消费者和用户来说它是个整体。云就是我们刚才讲的，替代了前一代的信息时代的基础架构，今天的云是未来面向数字经济时代的新型的体系结构，这个结构中，云是承担了这样一个职能。但对于很多行业来讲，他希望上面还有一个更容易去开发自己应用的平台，因为他要解决移动化的问题，要解决很多政府要审批流程、安全等等问题，所以它需要一个新的平台，钉钉是这个平台非常非常重要的组成部分。我们讲很多企业“云钉一体”，因为它基于这个体系可以开发出它面向未来的数字化的新的系统。 何刚：阿里云+ 钉钉就是云钉一体，数字经济时代新的windows+英特尔。 张建锋：数字经济时代我觉得最大的特点就是云+新型的操作系统。 何刚：就是你们的云钉一体。现在能给我们一个数字吗，钉钉可以公开的用户有多少，企业组织有多少？ 张建锋：钉钉现在上面有1500万的组织，用户超过3亿，3亿用户用钉钉在工作、在学习，我觉得跟其他的工具非常不一样的。 何刚：所以我想它可能对于我们的大型企业显然很有用，它的连接能力，对于中小型企业，钉钉价值又在什么地方？ 张建锋：大企业因为连接比较复杂，需要一个新型手段，中小企业是整体式的管理，我看到很多餐饮企业只有几十个人，所有工作，所有事情都通过钉钉在连接。因为原来可能要买很多的垂直化的应用，比如说他要做考勤，比如说他要做财务，比如说他要做人事，今天他都不需要这些东西了，钉钉就可以搞定，钉钉本身又是一个新型平台，很多人基于钉钉开发了通用的应用，甚至不用自己开发，把那些应用组合起来就可以了，这就大大降低了信息化、数字化的门槛。 做深基础，做厚中台，做强生态 何刚：阿里云在整个数字时代一个新的使命，就是构建数字经济的基础设施，如果具体来看的话，怎么理解数字经济的基础设施，包括哪些关键的支撑？钉钉在这次的现象级的应用增长当中，一开始曾经出现了拥塞，但是阿里云很快用强大的能力把它解决了，跑得很顺畅，3亿人能也能顺畅地跑，数字经济的基础设施是不是也可以支撑我们所说全速重构的这样快速的需求？需要做哪些关键支撑？ 张建锋：我们去年提出做数字经济时代的基础设施，我们是一个公共的服务资源，这是我们做云计算一个非常强的两个特点。 刚才我们讲了，我们把云定义成一个新型计算体系，这是我们云来实现的；第二个我们要构建一个中台，做一个新型的操作系统，上面呈现各种各样行业的应用，这个前提下我们提出来自己是要做深基础，我们要把云的底座给做深，怎么做深呢？我们除了要做云的操作系统之外，我们有个飞天操作系统，要做调度等。我们还要做芯片、数据库，做路由器、交换机等，基于云的特点来构建整套的基础体系。 何刚：芯片就是去年一直在发布的AI智能芯片？ 张建锋：AI，我们可能有更多的芯片，像我们做虚拟化等有很多芯片，而且现在安全很重要，我们也有自己的一些安全的芯片等。 何刚：所以第一个叫做深基础，第二是？ 张建锋：第二是要“做厚中台”，中台作为一个新型的操作系统，要提供更多的功能，我们上面的应用才能更容易来开发，这些功能，包括AI的功能，大数据的处理，IOT的能力，移动的能力。这里面我们想把中台做得越厚，这个操作系统的功能就越强大。 还有第三，我们要做大做强生态。 最终不是阿里云来做所有事情的，我们是一个开放的体系，我们是希望软件开发上，基于云的结构、基于一个新型的操作系统，来帮助各行各业做一些应用的开发，所以我们提出“做深基础”、“做厚中台”、“做强生态”。这是我们作为数字经济时代基础的一个主要的出发点，也是一个落脚点。 何刚：今年4月20号的时候，你提出来阿里云未来要花一笔大钱，3年要花2000亿，当时把这个行业都震撼了，说有时候没钱是个事，钱多了怎么花也是一个问题。当时提到3年2000亿，要做新技术、新基建，帮助全社会做这种数字化的升级转型，为什么提出这么一个宏大的投资计划？具体会花在哪些方向？ 张建锋：这个投资看上去很大，但是对于全社会的数字经济的新基建来讲，其实并不大。我们现在整个阿里云管理有超过100多万台服务器，我们预计在3年之后就会超过300万台服务器，300万台服务器本身的投资就是个非常巨大的投资。 还要去建新型的网络、大规模IDC等等的建设，我们还要投入一些新产品的研发，像芯片之类的研发投入都是非常大的。所以看起来2000亿好像很多，3年之内可能还不够，除了这些投资之外，我们还会更多的投资在人才上。我们今年人才还继续招聘，会招聘超过5000个工程师加入阿里云。 何刚：如果我们再仔细地想一下阿里一家投了2000亿，整个社会关于数字经济的基础设施投资在你看来，比如未来3—5年，大概会是一个什么量级的规模，企业和政府分别在里面大概能够扮演什么角色？ 张建锋：这个投入可能会非常大。阿里巴巴比较集中在云计算的基础设施，还有5G也是非常大的投资，工业互联网可能是大头，我认为比消费互联网规模更大，而且对企业的影响应该也会更深远，工业互联网里有非常多行业，跟其他行业可能都不一样，这一块可能也是一个非常大的投入。 可能几万亿的投入是必须要做到的，因为没有这个投入就没有新型的基础设施，也谈不上数字经济。我们也看了2019年发的报告，2018年中国跟数字经济相关的GDP已经占到了34万亿，占中国整个GDP的三分之一，我觉得这个可能会进一步提高比例。所以说是非常大的量。 何刚：所以从整个未来趋势展望来看的话，我们看到无论是数字经济的基础设施，还是数字经济的这种应用，应该是一个非常令人激动美好的前景。 张建锋：我觉得数字化云化这是一个确定性会发生的事情，中国在这方面是走在世界的前头的。我们也有信心真正做好数字经济时代的基础设施。 推荐阅读 ...

云栖号资讯：【点击查看更多行业资讯】 在这里您可以找到不同行业的第一手的上云资讯，还在等什么，快来！简介： 为了逃避高考，他凭借NOIP一等奖成功保送武大；大学时就负责校园门户网站的运维工作，不甘落于平凡，于是翘课创业，一举获得成功，工作之余还指导团队获得世界数学建模大赛金奖。黄胜蓝的成功似乎格外轻松，其实皆是步步为营，筹谋已久。以下为黄胜蓝的个人专访，推荐阅读（约3分钟）。一意孤行的“非主流”青春 我出身于非常传统的军人家庭，但儿时起我就比较叛逆，不喜欢接受主流价值观赋予的选项。家人总是很难理解，而我从未动摇过。 高一开始我就在策划逃避高考了，对比各种路径后选择参加奥林匹克竞赛。于是当同学都在挑灯刷题的时候，我在熬夜做计算机竞赛。好在最后获得了一等奖，得以顺利保送。当时有很多学校可以选，我家人倾向国防科技大学，但最终我选了学风自由开放的武汉大学。高三时别人开始冲刺，我进入放羊状态，开始思考大学自己要做什么。 进入大学以后，我老老实实上了一年课，同时负责武汉大学学生校园门户网站的运维工作，期间也指导团队参加世界数学建模大赛获得了金奖。不甘心大学生活就这么平凡度过，可能是骨子里的不安分吧，总想搞点事情，于是我跟两个校友一拍即合，合作创业。 剩下的3年里我翘掉所有课程，只在考试的时候出现，考前一两天集中看书，然后压着及格线顺利毕业。校招季收到了大厂的免试offer，但习惯了不走寻常路的我，还是决定继续有趣的创业生涯。 用6年改变1件小事 大家都用过我们的产品，只是不一定知道我们的名字。可能大家会意识到，以前进行网站验证的时候，需要辨认并输入复杂的验证码，近几年很多地方都改为拖动模块验证的方式，这就是我们的产品。它利用图神经网络技术区别是人为还是机器行为，来完成分析验证的过程。 极验验证诞生于武大附近的民房，2012-2015年是VC黄金期，我们利用Ipad演示拿到了20万种子轮资金，紧紧巴巴花了一年。其实现在想起来拿到融资的过程并不难，毕竟我们是平均年龄22岁的团队，毫无经验。这与时代的关系密不可分，我们运气还算不错。 创业的过程就没那么顺利了。对于当时的我们来说，每一个问题都很难，没有处理好就可能面临倒闭。一开始是技术方面，学生团队的技术基础薄弱，我们花了很多时间来打磨，提高稳定性。产品体验优化以后，市场问题又接踵而至。武汉的互联网发展资源太少，而我们又没有足够的资金混开社交圈。好在当时还有些社区论坛，为我们引流了首批客户。 当我们开拓了一批市场，就触及到竞争对手等的利益，服务器被频繁攻击，试图破解我们的验证。于是我们继续优化行为判断模型，提升服务端性能，不断完善迭代产品。现在我们的产品已经服务于游戏、直播、电商、社交媒体等20多个行业，承载每天十亿请求，涵盖20多万用户，包括KFC、几大航空公司、国家工商总局、新浪等。 年轻就是试错的资本 现在很多人不鼓励大学生创业，但我的建议恰恰相反。基于项目来说，毫无经验的大学生的确容易失败，但从个人角度出发，创业经历伴随的成长可以极大加速人生进程。人脉和经验通过常规职业路线也可以获取，但创始人的逻辑思维所带来的认知能力、战略性目光、视野与格局的成长速度，是无法相提并论的。不必过分关注结果，这份经历对于未来已经足够宝贵。 我建议大学生在校时就要提前规划好自己未来3-5年的人生，定位自己的核心优势，选几个方向来培养，可以是自己喜欢或者擅长的事情，重在坚持。依靠自己的竞争优势，超越同龄人足矣，彼时你会站在新的天地，看到更加不同的风景。 黄胜蓝的每一次选择看似乖张，其实始终都在对自己负责。他调侃自己不是一个安分的人，却可以心无旁骛做验证码6年。这位年轻的阿里云 MVP始终清晰、超前，坚定不移地靠近自己的理想人生。 我要成为阿里云 MVPlink 立即加入社群，与专家面对面，及时了解课程最新动态！ 【云栖号在线课堂 社群】https://c.tb.cn/F3.Z8gvnK

引言 本文以一张云进化历史图开场，来谈谈云原生时代消息中间件的演进路线，但本文绝对不是“开局一张图，内容全靠编”。 从虚拟化技术诞生以来，IaaS/PaaS/SaaS概念陆续被提了出来，各种容器技术层出不穷。到2015年，Cloud Native概念应运而生，一时间，各种云厂商，云服务以及云应用都加上了“云原生”前缀。 我们也一直在思考，传统的消息中间件需要做些什么才能加上云原生这个修饰词，这也是本文探讨的主题：传统的消息中间件如何持续进化为云原生的消息服务。 云原生消息服务 什么是云原生 首先来谈谈什么是云原生，云原生是一个天然适用于云计算的架构理念，实践云原生技术理念的应用可以最大化享受云计算的技术红利，包括弹性伸缩、按量付费、无厂商绑定、高SLA等。 应用在实践云原生技术理念时一般会遵循四个要素： 采取DevOps领域的最佳实践来管理研发和运维流程。通过CICD工具链做到应用的快速迭代和持续交付。采取微服务架构。采取容器及相关技术进行应用的托管。消息服务作为应用的通信基础设施，是微服务架构应用的核心依赖，也是实践云原生的核心设计理念的关键技术，通过消息服务能够让用户很容易架构出分布式的、高性能的、弹性的、鲁棒的应用程序。消息服务在云原生的重要性也导致其极可能成为应用实践云原生的阻塞点，所以消息服务的云原生化是至关重要的。 什么是云原生消息服务 先说结论，我们认为云原生消息服务是云原生的通信基础设施。2015年成立的CNCF基金会大范围推广了云原生的技术理念，并提供了一套完整的实践技术工具集，帮助开发者落地云原生理念。这套工具集收录于CNCF云原生全景图，其中消息中间件处于应用定义和开发层的Streaming和Messaging类目。 消息中间件在云原生的应用场景，主要是为微服务和EDA架构提供核心的解耦、异步和削峰的能力，在云原生全景图定义的其它层次领域，消息服务还发挥着数据通道、事件驱动、集成与被集成等重要作用。 另外云原生倡导面向性能设计，基于消息队列的异步调用能够显著降低前端业务的响应时间，提高吞吐量；基于消息队列还能实现削峰填谷，把慢服务分离到后置链路，提升整个业务链路的性能。 云原生消息服务演进方向 云原生时代对云服务有着更高的要求，传统的消息服务在云原生这个大背景下如何持续进化为云原生的消息服务，我们认为方向有这么几个： 高SLA 云原生应用将对消息这种云原生BaaS服务有更高的SLA要求，应用将假设其依赖的云原生服务具备跟云一样的可用性，从而不需要去建设备份链路来提高应用的可用性，降低架构的复杂度。只有做到与云一样的可用性，云在服务就在，才能称为真正的云原生服务。 低成本 在过去，每家公司自建消息中间件集群，或是自研的、或是开源的，需要投入巨大的研发、运维成本。云原生时代的消息服务借助Serverless等弹性技术，无需预先Book服务器资源，无需容量规划，采取按量付费这种更经济的模式将大幅度降低成本。 易用性 在云原生时代，消息服务第一步将进化成为一种所见即所得、开箱即用的服务，易用性极大的提高。接下来，消息服务将以网格的形式触达更复杂的部署环境，小到IoT设备，大到自建IDC，都能以跟公有云同样易用的方式接入消息服务，且能轻易地满足云边端一体化、跨IDC、跨云等互通需求，真正成为应用层的通信基础设施。 多样性 云原生消息服务将致力于建设大而全的消息生态，来涵盖丰富的业务场景，提供各式各样的解决方案，从而满足不同用户的多样性需求。阿里云消息队列目前建设了多个子产品线来支撑丰富的业务需求，比如消息队列RocketMQ，Kafka，微消息队列等。 标准化 容器镜像这项云原生的核心技术轻易地实现了不可变基础设施，不可变的镜像消除了IaaS层的差异，让云原生应用可以在不同的云厂商之间随意迁移。但实际上，很多云服务提供的接入形式并不是标准的，所以依赖这些非标准化云服务的应用形成了事实上的厂商锁定，这些应用在运行时是无法完成真正的按需迁移，所以只能称为某朵云上的原生应用，无法称为真正的云原生应用。因此，消息服务需要做到标准化，消除用户关于厂商锁定的担忧，目前阿里云消息队列采纳了很多社区标准，支持了多种开源的API协议，同时也在打造自己标准化接口。 总结一下，传统的消息队列将从高SLA、低成本、易用性、多样性和标准化几个方向持续进化为云原生的消息服务。 云原生消息三化 谈到云原生，离不开Kubernetes、Serverless以及Service Mesh，接下来为大家分享下我们如何利用K8S社区的生态红利，如何实践Serverless和Service Mesh技术理念。 云原生消息Kubernetes化 Kubernetes项目当下绝对是大红大紫，在容器编排和应用托管领域绝对的事实标准，整个社区也是生机盎然。所以，必须将我们的消息服务升级为K8S环境开箱即用的服务。 云原生消息Kubernetes化是指通过自定义CRD资源将有状态的消息集群托管至Kubernetes集群中，充分利用 K8S提供的部署、升级、自愈等能力提高运维效率，同时尽可能享受K8S的社区生态红利。 我们在RocketMQ开源社区也提供了CRD描述文件以及相应的Operator实现，通过这套实现，可以快速部署RocketMQ集群至K8S环境；利用K8S的能力低成本运维RocketMQ集群；也可以使用云原生的Prometheus观察集群指标。 RocketMQ完成Kubernetes化后，就变成了Kubernetes环境原生可访问的一个消息服务，将给开发者带来极大的便利性。 同时，在商业化环境，我们也正在依赖Kubeone将消息队列系列产品完成Kubernetes化。 云原生消息Serverless化 Serverless最核心的理念是“按需”，云原生消息Serverless化主要是从两个维度落地按需的概念。一方面根据业务规模自动化扩缩容实例规格、队列数等逻辑资源；另一方面，根据服务端负载自动化扩缩容计算、存储等物理资源。 逻辑资源按需扩缩容： 在用户侧，更关心的是消息实例提供的逻辑资源是否充足，比如购买的实例TPS规格是否足够，队列数量是否能满足扩展性需求。比如一个商业化的MQ实例中，可以根据用户的流量对实例规格进行自动的升降配，从2W TPS至10W TPS按需调整；也可以根据用户分布式消费者的数量规模，对逻辑队列数量进行动态调整；用户完全不需要进行容量评估。 物理资源按需扩缩容： 在云服务开发者侧，我们更关心的是如何通过Serverless降低运维成本，避免手动的机器购买、VIP申请、磁盘申请以及集群扩缩容等。在Kubernetes化完成后，可以很轻易地根据集群Load等指标自动扩容MQ 物理资源；在集群缩容的处理上，会比较麻烦，因为每个MQ 节点其实是有状态的，图中的某个PV 代表了一个CommitLog，我们在内部通过在ASI上支持PV漂移，在RocketMQ存储层支持多CommitLog挂载来完成自动化缩容。 云原生消息Mesh化 Service Mesh出发点是解决微服务架构的网络问题，将服务之间的通信问题从业务进程中进行剥离，让业务方更加专注于自身的业务逻辑。 云原生消息Mesh化将消息的富客户端能力下沉至Sidecar，将消息的服务发现、负载均衡、流量监控等职责与业务逻辑隔离，在运行时完成透明组装，同时提供细粒度的消息灰度和治理能力。 目前阿里云消息队列 RocketMQ 是国内第二个成功进入 Service Mesh 官方社区的中间件产品，在进行Envoy适配的过程中推动了Envoy社区加速对on-demand CDS的支持，创新性地使用Pop消费模式来适配Mesh的无状态网络模型。 ...

新冠病毒全球爆发 2020年注定是不平凡的一年，新型冠状病毒肆虐全球，对于每个人来说都是一场灾难。 根据丁香园统计的数据，截止到2020年5月29日，全球新冠（COVID-19）累计确诊病例5,593,631人，累计死亡353,334人。虽然中国疫情已经进入尾声，但是全球疫情新增确诊病例却呈现持续上升趋势。 毫无疑问，COVID-19不是一座城市的疫情，也不是一个国家的疫情，而是全世界的疫情，没有人能够置身事外，需要共同面对。 诊断一位患者，医生要肉眼阅读数百幅CT影像 一般来说，一个病人的CT影像包含数百张切面，即使经验丰富的医生也需要花费大约15-20分钟的时间去阅读CT影像，才能得到准确的诊断。 在新冠疫情爆发期，疑似患者的CT影像被证实成为筛查新冠肺炎的高效手段，这就代表每个医生每天需要进行批量CT影像的读片判断，无疑这个工作量是惊人的。同时依靠医生肉眼识别病灶微小的变化会花费大量时间，不仅诊断效率低，也会造成医生压力大，患者等待时间长。 50万份CT训练，澳科大开发新冠肺炎AI辅助诊断系统 在疫情初期，澳门科技大学医学院张康教授团队便携手中国科学院、国家生物信息中心、清华大学、中山大学孙逸仙纪念医院、广州再生医学与健康广东省实验室、四川大学华西医院等团队，联合应急开发了基于胸部CT和X-ray影像学的新冠肺炎AI辅助诊断系统。 该科研团队在分析了超50万份临床影像学数据的基础上，利用了深度学习、迁移学习、语义分割等多种人工智慧前沿技术，辅助临床医生进行新冠肺炎的快速诊断和定量分析。该AI模型以高精准度和高效率的优势，不仅可以辅助临床医生做诊断决策，提高诊断准确率，还可以减少其工作量，加快诊断效率，节省患者等待时间。 澳门科技大学医学院张康教授，图片源自澳科大官网 借助阿里云快速部署，实现20秒内CT影像诊断 科研团队需要让新冠肺炎AI辅助诊断系统快速上线使用，实现真正的帮助一线医生快速诊断抗击疫情。由于时间紧急，传统的线下部署方式，要进行设备及线路采购、部署、测试，再将业务部署在线下数据中心，不仅搭建周期长，而且缺乏弹性，很难满足快速部署业务的需求。 经过多次测试和研讨，阿里云以高性能计算、全球加速网络、极速存储等技术优势取得了澳科大张康团队的信赖。在全球加速网络及GPU性能的保证下，系统将影像科医生阅读CT影像缩短至20秒内，且平均准确率高达90%。 阿里云GA，30分钟实现全球加速网络部署 新冠肺炎AI辅助诊断系统想要实现一处部署，全球服务，首先要解决网络连接问题。一张稳定、高速的全球网络可以保证全球科研机构及移动办公的个人，随时随地快速上传CT文件及下载分析结果，从而实现科研成果的全球规模化应用。 阿里云为此次新冠肺炎AI诊断系统的部署提供了全球加速解决方案，通过全球加速GA产品，依托阿里巴巴遍布全球的优质传输网络，可以有效提升全球数据访问的稳定性。GA内置的TCP协议优化能力，还可以大幅提升传输性能。尤为值得一体的是，传统的专线部署周期长达数月，而采用阿里云GA构建的全球加速网络，只需要30分钟部署时间，为业务系统的快速上线提供了基础保障。 当前该系统已经在武汉市金银潭医院、中山大学孙逸仙纪念医院、中山大学第三附属医院、广州医科大附属第一医院、湖北宜昌市中心人民医院、安徽医科大学第一附属医院、新疆喀什地区第一人民医院、四川大学华西医院、澳门科技大学、美国、巴西、伊拉克等地部署，接下来会在全国及世界范围内推广应用。阿里云洛神网络团队协助高校及科研机构，用科技抗击疫情，为全球抗击COVID-19贡献一份力量。

提起压力、温度校准行业会让大部分非专业人士感到陌生。但实际上，在我们的日常生活中，很多设备都是需要经过压力检测、温度检测、过程信号检测合格之后才正式投放市场使用的， 北京康斯特仪表科技股份有限公司（以下简称康斯特）就是在这样的行业耕耘了多年。康斯特成立于2004年，康斯特专注于为全球用户提供压力、温度及过程仪表的校准及检测技术专业解决方案。2015年，公司于深交所创业板上市，股票代码300445。 一、未雨绸缪：智能制造，安全先行在智能制造的大趋势下，康斯特锐意发展，践行国际化布局的长期战略，2019年，在贸易新格局变化和全球经济增长放缓的重重压力下，公司坚持高质量扩张模式发展，继续追加研发投入，把握新一轮科技产业变革趋势，推进校准测试和科技创新的融合。通过创新赋能提升产品网络化、智能化能力，实施技术升级迭代，打造持续盈利的增值反应堆。 作为一家发展多年的制造企业，康斯特积累了大量的数据，数据存储容量快速增长，对数据安全的要求也不断提高。为了应对业务的快速发展，以及未来全球化的企业战略，康斯特在建立了自己的数据中心的同时，也不断在云端寻求新的尝试。在数据安全方面，康斯特希望采用一个更加贴近实际需求的灾备解决方案。 二、有备无患：释放混合云的技术红利为了对智能制造的趋势以及数字化的全面转型，康斯特基于专业的技术与服务能力，与阿里云合作，经过深入交流沟通后，根据康斯特自身的业务和数据的特性，最终采用了全能备份型灾备解决方案，实现本地到云端的混合云架构部署。 ▲方案架构 首先，阿里云 DR208灾备一体机经阿里云公共云级压力测试，提供了安全稳定的本地灾备空间来存放被保护服务器的复制数据，可以在外部网络不稳定时提供足够的临时存储，确保备份复制不中断。同时，可根据策略加密压缩后上传至云端，依托于阿里云的弹性扩容，节省了本地IDC机房的投入，减少本地设备采购交付周期。
其次，阿里云DR208灾备一体机结合了阿里云生态伙伴、Gartner魔力象限灾备领军厂商Commvault的备份解决方案，该方案可以为企业数据中心、远程分支机构、以及云上数据提供强有力的保护，并支持加密、压缩、重删等技术，保证数据快速、安全、高效地备份到云上。
第三，阿里云提供备份软件和硬件整体售后服务，解决了软硬件分离所导致的诊断效率低且不容易定位等问题。 三、混合云存储：鱼和熊掌，可兼得“阿里云的混合云存储产品非常适合云康斯特这样的制造企业，不仅构建了一个统一的数据管理平台，而且在数据安全方面提供了极大保障，提升了运维效率，免除了我们的后顾之忧，从而可以将更多的时间和人力投入到业务创新中。”——北京康斯特仪表科技股份有限公司 信息化部经理聂明茜随着新一轮科技革命与产业变革，以智能制造培育新动能、促进新发展，正成为全球制造业变革和科技创新的一个重要方向。在这样的时代背景下，康斯特将继续秉承“让校准更轻松”的核心理念，为客户提供校准及检测技术专业解决方案，并创造更大的价值。而在这个过程中，依托于阿里云存储产品，康斯特正在创造出更多的可能。

2020年5月DB-Engines 数据库流行度排行大家都看了吗？ 虽然 Top 10 与上月没有任何变化，但仔细观察本月的排行榜，Oracle 较上月几乎持平，仅微涨 0.02 分；相较而言，MySQL 增长明显，达到 14.29 分，比其4月份的增长（ 8.62 分）高了近 66%。 而微软的两个产品 Microsoft SQL Server 和 Microsoft Access 继续下滑，分数分别下降 5.12 分和 2.02 分；IBM Db2 也出现了 2.99 分的跌落，老牌商业数据库在全球遭受新冠病毒疫情影响下可谓有些捉襟见肘。 再看 PostgreSQL ，一改上月颓势，本月增长 4.95 分，可以说在疫情影响的经济形势下，开源数据库抗住了压力。 近一个月以来，新冠病毒引起的疫情在海外持续、快速蔓延，目前已累计确认人数超过511万、累计死亡人数超过33万。阴霾笼罩下，全球经济遭遇重创，“活久见”层出不穷，技术和就业也都不可避免的受到影响。 原计划于4月底前发布的 Oracle Database 20c 公开版本，现在也未能如期。不过 Oracle 20.3 已在云上更新，尽管大多数人可能还看不到，但事实就是如此，Oracle 从 20.1 开始，悄无声息地按照其新的版本策略，更新迭代到第3个版本号了。 此外，MySQL 8.0.20 GA版已于4月27日正式发布，除了缺陷修复外，还包括了增加SHOW_ROUTINE权限、改进hash join、加入新的索引级别的优化器提示、Performance Schema改良、X Plugin改良、InnoDB改良、二进制日志事务压缩等在内的一些新特性。开源力量不可小觑！ 按照惯例，我们再来看一下国产数据库排行榜。在国产数据库中，Top 10如下图所示。阿里云自研的云原生数据库 PolarDB 稳中上进，得分比上月有所提高，是国产数据库中的重要力量。 可以说，疫情影响下的国产数据库保持积极成长，这或许跟“新基建”的带动有关。信息技术应用创新产业作为“新基建”的重要组成部分，包括5G网络、数据中心等“新基建”被按下“快进键”，国产化数字生态建设也将加速推进，数据库特别是国产数据库必将迎来成长和发展的新机遇。 2020年的第5个月已经进行到了接近尾声，随着国内疫情防控形势向好，生产生活加快恢复，让我们重拾热情，用数据驱动美好世界！ DB-Engines数据库流行度排行关系型数据库前10位： Key-Value 数据库存储前10位： 文档类数据库存储前10位： 时序数据库前10位： 图数据库前10位： ...

云栖号资讯：【点击查看更多行业资讯】 在这里您可以找到不同行业的第一手的上云资讯，还在等什么，快来！2020年阿里云年中大促活动于6月1日正式上线啦！活动时间为：2020年6月1日至2020年6月30日主会场链接：https://www.aliyun.com/activity/618?utm_content=g_1000136221这篇攻略旨在盘点本次大促的福利，并给大家整理了一份选品指南，方便大家快速、低成本上云。 年中大促福利大起底： 领取满减大礼包，最高可减12000元；云产品优惠：云服务器低至0.9折，工商注册9.9元起，商标钜惠270元，域名新注0元起，云数据库1折起；每日签到抽iPhone 11 Pro；分享返现高达31%；云分期百万补贴，首付20%；选品指南：领取大礼包页面填写自己的业务需求和预算，商品个性化推荐；常见6大业务场景解决方案和产品组合；产品线选品；百元专区会场，免费和超低价产品试用。年中大促福利大起底1、领取满减大礼包，最高可减12000元 前往主会场点击“领12000元大礼包”，填写需求和预算，领取大礼包。 购买的时候记得先将选中的云产品加入购物车，然后通过购物车一起购买。 除了满减礼包，有可能还会有意外豪礼奥，小编还领到了Teambition的免费试用权益。 2、 云产品特惠 阿里云全线产品享特惠，其中云服务器低至0.9折，工商注册9.9元起，商标钜惠270元，域名新注0元起，云数据库1折起； 3 、每日签到抽iPhone 11 Pro 年中大促期间每日签到可以无门槛抽奖，做任务嗨可以赚双倍积分，积分可以兑换豪礼奥~ 小编刚抽到20积分，赶紧去试试自己的手气吧~ 抽奖戳：https://club.aliyun.com/ 4. 分享返现高达31% 加入云大使，分享返现高达31%，客户省钱我赚钱~ 链接https://promotion.aliyun.com/ntms/yunparter/index.html 5. 云分期百万补贴，首付20% 云分期发放百万补贴助力企业上云，费率超低，首付仅2成，轻松上云。 链接：https://www.aliyun.com/yunfenqi/promotion 如何选品？1、领取大礼包页面填写自己的业务需求和预算，商品个性化推荐； 在领取大礼包的页面填写上云需求和预算范围，可以得到个性化地商品推荐，这样就不用在众多产品中去捞适合自己的那一款啦~ 2、常见6大业务场景解决方案和产品组合 为了方便用户选品，这一届年中大促特别推出了电商专区、企业初创服务、数字新基建、业务安全、企业应用、音视频专区6大常见业务场景下的解决方案及产品组合，一站式解决了上云问题。极大地降低了用户自己选品、组合的难度，是不是很优秀呢~ 3、产品线选品 如果有明确的产品需求，可以通过主会场【口碑爆款】专区，查看适合自己的高性价比产品；也可以通过产品专场寻找需要的商品。 云服务器专场：https://www.aliyun.com/daily-act/ecs/activity_selection_618 云数据库专场：https://www.aliyun.com/database/dbfirstbuy 域名知产专场：https://tm.aliyun.com/channel/activity_618domain 企业应用中心：https://ac.aliyun.com/ 4、百元专区会场多款产品免费/超低价试用 如果想先尝试上云的用户，可以前往百元专区会场，多款免费试用和超高性价比的商品 链接：https://www.aliyun.com/activity/618/baiyuan 最后祝大家年中上云省钱又省心~ 【云栖号在线课堂】每天都有产品技术专家分享！ 课程地址：https://yqh.aliyun.com/live立即加入社群，与专家面对面，及时了解课程最新动态！ 【云栖号在线课堂 社群】https://c.tb.cn/F3.Z8gvnK

云栖号资讯：【点击查看更多行业资讯】 在这里您可以找到不同行业的第一手的上云资讯，还在等什么，快来！ 阿里妹导读：随着容器技术的快速发展和广泛应用，毫无疑问云原生技术是未来发展的必然趋势。作为国内最早布局容器技术的阿里云，无论在技术还是产品上，都取得了极大的成果。阿里云资深技术专家易立通过阿里云容器服务，分享容器技术落地的最佳实践，希望能够帮助同学们更好地理解容器技术和云原生理念，合理地设计上云架构，充分发挥云的价值。 没有集装箱，就没有全球化。——《经济学人》什么是容器？容器的英语是 Container，它的意思是集装箱。我们知道，经济全球化的基础就是现代运输体系，而其核心正是集装箱。集装箱的出现实现了物流运输的标准化，自动化，大大降低了运输的成本，使得整合全球的供应链变为可能。这就是著名经济学人谈到的“没有集装箱，就没有全球化”。 集装箱背后的标准化、模块化的理念也在推进建筑业的供应链变革。在最近，疫情爆发之后。10 天 10 夜，在武汉火神山，一个可以容纳上千床位的专科医院平地而起，在抗疫过程中发挥的重要作用。整个医院都是采用集装箱板房吊装。模块化的病房设计，预置了空调、消杀、上下水等设施，极大加速了施工速度。 容器的通俗理解 软件集装箱 ”容器技术“ 也在重塑整个软件供应链。容器作为一种轻量化的操作系统虚拟化技术，和和传统的物理机、虚拟化技术和使用方式有什么不同呢？打个比喻： 传统物理机就是独栋大别墅 一家人独占，住的舒适，不会被别人打扰。应用独占物理机，性能优异。但是缺点就是贵、交付时间长，资源利用率也不高。虚拟机就是联排住宅 每户有独立的空间，有较好的隔离性。每栋房屋之间共享水电、地基等基础设施。容积率提升了，成本下降了，交付速度也加快了。通过虚拟化技术，虚拟机中的应用可以实现安全隔离，还可以有效提升资源利用率。但是，虚拟机交付后还需进行应用配置和安装，交付速度还不够快。容器就是集装箱板房 集装箱房采用模块化设计，自带装修，可以快速搭建，随时移动。这是 2022 年卡塔尔世界杯一个体育场的设计。它将完全使用集装箱方式搭建一个可以容纳 4 万人的体育场。每个集装箱模块都在在中国生产，已经预置了看台，卫生间，酒吧等功能，在中国生产完毕后在卡塔尔组装。不但工期可以缩短 3 年，而且赛事结束后可以拆卸，搬迁到其他地方。容器利用操作系统中 cgroup，namespace 等技术实现资源隔离。容器共享操作系统内核，非常轻量，没有资源损耗，支持秒级启动，极大提升了系统的应用部署密度和弹性。容器镜像将应用和其依赖的系统组件和配置打包在一个标准化的、自包含的格式中。通过容器镜像方式进行应用分发和交付，可以让应用即开即用，并一致地运行在不同环境。容器的价值 在过去几年中，容器技术得到了越来越广泛的应用。其中最主要的 3 个核心价值是： 敏捷 天下武功唯快不破。在企业数字化转型时代，每个企业都在面临着新兴业务模式的冲击和众多的不确定性。一个成功的企业不是看他现在规模有多大，过去的战略有多成功，而是要看他是否有能力持续创新。容器技术提升了企业的 IT 架构的敏捷性，从而提升了业务敏捷性，可以加速业务创新。比如疫情期间，教育、视频、公共健康等行业的在线化出现了爆发性高速增长。通过容器技术可以很好地把握业务快速增长的机遇。在业界的统计中，使用容器技术可以实现 3~10 倍交付效率提升，这意味着企业可以进行快速迭代，低成本试错。 弹性 在互联网时代，企业 IT 系统经常需要面对电商大促、突发事件等可预期和非预期的流量增长。通过容器技术可以充分发挥云计算的弹性，通过提升部署密度和弹性来降低计算成本。比如在线教育，面对疫情之下指数级增长的流量，可以通过容器技术来缓解扩容的压力，支持数十万教师在线教学，百万学生在线学习。 可移植性 容器技术推进了云计算的标准化进程。容器已经成为应用分发和交付的标准，可以将应用与底层运行环境解耦；Kubernetes 成为资源调度和编排的标准，屏蔽了底层架构的差异性，帮助应用平滑运行在不同的基础设施上。CNCF 云原生计算基金会推出了Kubernetes一致性认证，进一步保障了不同 K8s 实现的兼容性。采用容器技术来构建云时代的应用基础设施将变得越来越容易。 Kubernetes：云原生时代的基础设施 现在 Kubernetes 已经成为了云应用操作系统，越来越多应用运行在 Kubernetes 基础之上：从无状态的 Web 应用，到交易类应用（如数据库、消息中间件），再到数据化、智能化应用。阿里经济体也基于容器技术，实现了全面的云原生上云。 阿里云容器服务介绍 阿里云容器服务产品家族可以在公共云、边缘计算和专有云环境提供企业容器平台。阿里云容器产品的核心是 Kubernetes Service - ACK 和 Serverless K8s - ASK，它们构建在阿里云的一系列基础设施能力之上，包括计算、存储、网络、安全等，并提供标准化接口、优化的能力和简化的用户体验。ACK 通过 CNCF K8s 一致性兼容认证，并提供了一系列企业关注的核心能力，比如安全治理，端到端可观测性、多云混合云等。 ...

注：以下分析基于开源 v19.15.2.2-stable 版本进行 引言ClickHouse是最近比较火的一款开源列式存储分析型数据库，它最核心的特点就是极致存储压缩率和查询性能，本人最近正在学习ClickHouse这款产品中。从我个人的视角来看存储是决定一款数据库核心竞争力、适用场景的关键所在，所以接下来我会陆续推出一系列文章来分析ClickHouse中最重要的MergeTree存储内核。本文主旨在于介绍MergeTree的存储格式，并且彻底剖析MergeTree存储的极致检索性能。 MergeTree存储MergeTree思想提到MergeTree这个词，可能大家都会联想到LSM-Tree这个数据结构，我们常用它来解决随机写磁盘的性能问题，MergeTree的核心思想和LSM-Tree相同。MergeTree存储结构需要对用户写入的数据做排序然后进行有序存储，数据有序存储带来两大核心优势： • 列存文件在按块做压缩时，排序键中的列值是连续或者重复的，使得列存块的数据压缩可以获得极致的压缩比。 • 存储有序性本身就是一种可以加速查询的索引结构，根据排序键中列的等值条件或者range条件我们可以快速找到目标行所在的近似位置区间(下文会展开详细介绍)，而且这种索引结构是不会产生额外存储开销的。 大家可以从ClickHouse的官方文档上找到一系列的MergeTree表引擎，包括基础的MergeTree，拥有数据去重能力的ReplacingMergeTree、CollapsingMergeTree、VersionedCollapsingMergeTree，拥有数据聚合能力的SummingMergeTree、AggregatingMergeTree等。但这些拥有“特殊能力”的MergeTree表引擎在存储上和基础的MergeTree其实没有任何差异，它们都是在数据Merge的过程中加入了“额外的合并逻辑”，这部分会在后续介绍MergeTree异步Merge机制的文章中详细展开介绍。 MergeTree存储结构为了方便大家理解表的存储结构，下面列举了某个POC用户的测试表DDL，我们将从这个表入手来分析MergeTree存储的内核设计。从DDL的PARTITION BY申明中我们可以看出用户按每个区服每小时粒度创建了数据分区，而每个数据分区内部的数据又是按照(action_id, scene_id, time_ts, level, uid)作为排序键进行有序存储。 CREATE TABLE user_action_log ( `time` DateTime DEFAULT CAST('1970-01-01 08:00:00', 'DateTime') COMMENT '日志时间', `action_id` UInt16 DEFAULT CAST(0, 'UInt16') COMMENT '日志行为类型id', `action_name` String DEFAULT '' COMMENT '日志行为类型名', `region_name` String DEFAULT '' COMMENT '区服名称', `uid` UInt64 DEFAULT CAST(0, 'UInt64') COMMENT '用户id', `level` UInt32 DEFAULT CAST(0, 'UInt32') COMMENT '当前等级', `trans_no` String DEFAULT '' COMMENT '事务流水号', `ext_head` String DEFAULT '' COMMENT '扩展日志head', `avatar_id` UInt32 DEFAULT CAST(0, 'UInt32') COMMENT '角色id', `scene_id` UInt32 DEFAULT CAST(0, 'UInt32') COMMENT '场景id', `time_ts` UInt64 DEFAULT CAST(0, 'UInt64') COMMENT '秒单位时间戳', index avatar_id_minmax (avatar_id) type minmax granularity 3) ENGINE = MergeTree()PARTITION BY (toYYYYMMDD(time), toHour(time), region_name)ORDER BY (action_id, scene_id, time_ts, level, uid)PRIMARY KEY (action_id, scene_id, time_ts, level);该表的MergeTree存储结构逻辑示意图如下： MergeTree表的存储结构中，每个数据分区相互独立，逻辑上没有关联。单个数据分区内部存在着多个MergeTree Data Part。这些Data Part一旦生成就是Immutable的状态，Data Part的生成和销毁主要与写入和异步Merge有关。MergeTree表的写入链路是一个极端的batch load过程，Data Part不支持单条的append insert。每次batch insert都会生成一个新的MergeTree Data Part。如果用户单次insert一条记录，那就会为那一条记录生成一个独立的Data Part，这必然是无法接受的。一般我们使用MergeTree表引擎的时候，需要在客户端做聚合进行batch写入或者在MergeTree表的基础上创建Distributed表来代理MergeTree表的写入和查询，Distributed表默认会缓存用户的写入数据，超过一定时间或者数据量再异步转发给MergeTree表。MergeTree存储引擎对数据实时可见要求非常高的场景是不太友好的。 上图展示了单个MergeTree Data Part里最核心的一部分磁盘文件(只画了action_id和avatar_id列其关的存储文件)，从功能上分主要有三个类： ...

实时历史库需求背景在当今的数字化时代，随着业务的迅速发展，每天产生的数据量会是一个惊人的数量，数据库存储的成本将会越来越大，通常的做法是对历史数据做归档，即将长期不使用的数据迁移至以文件形式存储的廉价存储设备上，比如阿里云OSS或者阿里云数据库DBS服务。 然而在部分核心业务的应用场景下，针对几个月甚至几年前的“旧”数据依旧存在实时的，低频的查询甚至更新需求，比如淘宝/天猫的历史订单查询，企业级办公软件钉钉几年前的聊天信息查询，菜鸟海量物流的历史物流订单详情等。 • 如果这时从历史备份中还原后查询，那么查询时间将会是以天为单位，可接受度为0 • 如果将这些低频但实时的查询需求的历史数据与近期活跃存储在同一套分布式数据库集群下，那么又会带来以下两大挑战 存储成本巨大，进而导致成本远大于收益，比如钉钉聊天信息数据量在高度压缩后接近50PB，很难想象这些数据不做压缩会带来多大的资金开销性能挑战巨大，随着数据量越来越大，即使针对数据做了分布式存储，单实例容量超过大概5T以后性能也会急剧下滑，进而影响到近期活跃数据的查询性能，拖垮整个集群运维难度巨大，比如针对海量数据下发一个表数据结构变更操作，很难想象全部完成需要多长时间实时历史库场景需求分析通过上面的分析，不管是冷备份还是在线历史数据混合存储在同一张物理表上的方法都是不可取的，一般实时查询历史数据库的场景，一般需要有以下几个关键特性 成本可控，历史数据的存储成本无法接受和在线库一样线性增长实时查询，历史数据的查询RT要做到与在线活跃库几乎一致查询频次较低，一般来说，越“旧”的数据查询频率越低统一查询入口，不管是活跃数据还是历史数据，查询入口保持一致改造成本需要尽可能低，最好能做到不做任何应用代码修改，可以认为历史库对程序开发人员来说是完全透明的可能存在历史数据更新需求数据规模较大，一般在100TB以上X-Engine引擎介绍X-Engine简介X-Engine是阿里云数据库产品事业部自研的联机事务处理OLTP（On-Line Transaction Processing）数据库存储引擎。作为自研数据库POLARDB的存储引擎之一，已经广泛应用在阿里集团内部诸多业务系统中，包括交易历史库、钉钉历史库等核心应用，大幅缩减了业务成本，同时也作为双十一大促的关键数据库技术，挺过了数百倍平时流量的冲击。 与传统的InnoDB引擎不同，X-Engine使用分层存储架构（LSM-Tree）。分层存储有两个比较显著的优点： 需要索引的热点数据集更小，写入性能更高。底层持久化的数据页是只读的，数据页采用紧凑存储格式，同时默认进行压缩，存储成本更低。相比InnoDB引擎，依据数据特征，使用X-Engine存储空间可降低至10%~50%，我们在著名的Link-Bench和阿里巴巴内部交易业务两个数据集上测试了X-Engine的存储空间效率。在测试中，对比开压缩的InnoDB引擎，X-Engine有着2倍空间优势，而对比未开压缩的InnoDB，X-Engine则有着3~5倍的优势。 实时历史库方案，为何不是其他高压缩引擎• 通常我们默认MySQL是当今最流行的开源数据库，大概率是在线核心数据库集群的首选。相比其他高压缩的存储引擎，引入X-Engine完全无需做任何SQL代码改造，并且支持事务，接入成本最低，学习成本几乎为0 • 写入性能更强，X-Engine相比同为LSM-tree架构的Rocksdb，有超过10倍的性能提升。 • 在存储层引入数据复用技术等，优化Compaction的性能，降低传统LSM-tree架构中Compaction动作对系统资源的冲击，保持系统性能平稳 • 引入多个层级Cache，同时结合Cach回填和预取机制，利用精细化访问机制和缓存技术，弥补传统LSM-tree引擎的读性能短板，X-Engine的点查询能力几乎与Innodb持平 下图是X-Engine与主流历史数据存储方案对比 历史数据存储选型 备份至OSS 开源HBase X-Engine 压缩率 高 高 高 是否支持查询 支持解析历史备份文件查询 高 高 实时性 N/A 较高 非常高 应用代码改造代价 N/A 很高 几乎不用修改 事务支持 N/A 仅支持单行事务 强 主要场景 冷备份 大数据生态 OLTP 实时历史数据库架构设计和实现总体架构思路基于上文对实时历史库和X-Engine的介绍，阿里云数据库团队推出以X-Engine引擎为历史数据存储核心，同时生态工具DTS作为在线/历史数据流转通道，DMS作为历史数据无风险删除的完整“实时在线-历史库”方案，针对不同的业务场景和客户需求，在具体实现上可能会有所不同，我们提供了多种实时历史库方案的具体实现。主体架构图如下，核心思路为： 久经考验的Innodb引擎作为OLTP在线库核心引擎，主要处理高频查询/更新请求，满足在线活跃数据高并发，高性能，强范围查询的业务需求阿里巴巴数据库团队自研的高压测存储引擎X-Engine作为历史库核心引擎，主要响应历史数据入库/查询/更新请求，满足历史数据冷热数据频次不一，低存储成本，高性能的业务需求(范围查询可能性能受限)统一DB接入层，根据设置的业务时间属性将请求分别转发至不同的存储引擎。针对特殊场景下的跨引擎访问，在应用层做聚合展示在线-历史数据通过阿里云提供的生态体系工具做历史数据迁移和过期数据删除，确保链路更为稳定可靠 在线库/历史库拆分方案一般来说，需要使用到实时历史库的场景，数据量都足够大到单台宿主机存放不了。在线数据库可能是根据业务水平或垂直拆分的多个RDS，也可能是一个规模较大的DRDS集群。为了尽可能地保证在线库的性能，推荐将在线库/历史库完全拆分解耦 • 历史库集群存储全量数据 • 通过DTS链路打通在线库和历史库，实时同步 • DTS链路过滤Delete操作 • 可直接使用新版DMS配置历史数据定期删除 源端为DRDS集群数据同步链路走RDS• 多条DTS链路打通底层RDS节点，同步性能强 • RDS数量较多可支持API批量创建和配置 • 链路稳定性更好 • 需要保证源端目标端库表数量一致，数据路由规则一致 ...

1.背景介绍病原体基因检测，为各种严重感染的诊断提供了基础。病原体检测流程分成五个步骤：（1）采集病人的样本，比方说静脉血，痰液，肺泡灌洗液，或者脑脊髓液等。（2）对样本进行培养，提取样本中的核酸组织。（3）通过高通量基因测序仪，对核酸序列进行测序。高通量测序为了保证精度，会将很长的核苷酸序列，切成小的分片，分别进行测序，在读取基因序列上，一般是50pb到200bp不等。（4）高通量测序之后，需要查询相关的病原体标准序列，找到匹配的基因序列。（5）通过将这些小的片段进行分析，得到全部基因片段的组成成分（即检测结果），从而为病人的疾病确诊以及精准治疗提供有力的支持。 图1. 病原体基因检测流程 对于生物分析检测来说，通常情况下，一次病原体检测，大约会生成5亿左右的75bp的基因片段。过滤掉一些人的基因组织序列之后，还需要查询1亿左右的基因片段。通常情况下，会使用nBlast [1]工具来进行基因匹配，这部分在整个病原体检测过程中，也是非常耗时的部分，大约需要2-3个小时。阿里云AnalyticDB向量版提供了一个高效的基因检索工具，大大提升了基因分析的性能，能够在几十分钟内完成整个病原体的查询检测过程。 2.基因检索应用2.1 基因检索功能图1展示了病原体基因检索的界面。当前演示包含了12182个病毒的碱基序列，我们将病毒切分成150bp的小片段（总共1590804个片段），转化成向量之后，存储到AnalyticDB中。在检索框中，用户可以输入一段基因序列，到我们当前的系统中进行检索。为了方便大家使用，我们挑了新冠病毒，艾滋病毒，埃博拉病毒和中东呼吸综合症的基因序列来进行演示，用户可以拷贝相关的序列，来检测查询的性能。 图2. 核酸查询演示 图3用户输入了一段新型冠状病毒的基因序列，可以看到排到前面的序列片段就是我们要找的新冠的病毒的序列。因为当前AnalyticDB提供高效的向量索引，系统会在毫秒级的时间内，返回相关的基因片段。 图3.基因检索结果 2.2 端到端的基因分析我们模拟了人体的基因采样，将新型冠病毒基因（塞尔维亚MT450872 [2]，美国MT450873 [3]）和中东呼吸症MERS基因（NC_019843.3 [10]），三株病毒混合在一起，打散成75bp的序列，当做测试集合。我们希望，通过当前病毒库的检索分析，能够识别出当前测试集合中包含新型冠状病毒和MERS病毒。当前系统通过匹配检测，我们生成图4。 图4. 基因匹配结果 可以看到经过检测，病毒库检索系统返回了三个基因组（NC_045512.2，NC_019843.3和NC_038294.1）。NC_045512.2（65%）是武汉海鲜市场的新型冠状病毒的基因；NC_019843.3（20%）是MERS病毒的基因；而NC_038294.1（13%）是beta型英国冠状病毒，经过查询这个是MERS病毒的另外一个名字 [8]，也属于MERS病毒。因此，通过分析，当前混合测试集合中包含了新型冠状病毒和MERS病毒。 2.3 应用架构总体设计阿里云基因检索系统的总体架构如图5所示，AnalyticDB负责整个应用的全部的结构化数据（比方说，基因序列的长度，基因的名称，基因的种类，以及基因的详细介绍，DNA或者RNA等）和基因序列产生的特征向量的存储和查询。在查询的时候，我们使用基因向量抽取模型，将基因转化成向量，在AnalyticDB库中进行粗排检索。在向量匹配的结果集中，我们使用经典的Needleman-Wunsch [4]算法进行精排，返回最相似的基因序列。 图5.基因检索系统框架 3.基因训练和查询模型3.1 基因查询过程基因模型的训练已经在上一篇文章中 [5]，进行了详细的讲解。通过训练好的DNA K-Mer模型，我们可以得到每个k-mer的向量。给定一段12bp的基因序列（如图6），我们在这段基因序列中抽取出5个8-mers。我们将这5个8-mers转成对应的向量，求和归一化之后，就是这段12bp的基因序列的最终的向量。当然，为了提升精度，我们也可以使用doc2vec [6]等学习模型来对整段基因片段进行转化。 图6.DNA序列转向量 3.2 基因精度分析我们训练了两个模型，全部病毒模型和21个病原体细菌模型（痤疮丙酸杆菌，金黄色葡萄球菌，表皮葡萄球菌，溶血葡萄球菌，大肠埃希氏菌，鲍曼不动杆菌，结核分枝杆菌，肺炎链球菌，肺炎克雷伯氏菌，流感嗜血杆菌，副流感嗜血杆菌，嗜麦芽窄食单胞菌，铜绿假单胞菌，屎肠球菌，纹带棒状杆菌，人疱疹病毒4型(EB病毒)，细环病毒，人腺病毒B组，黄曲霉，白色假丝酵母，耶氏肺孢子菌）。我们将一个基因，每隔150个bp，做一下切分。然后将150bp的小的分段，转化成向量存在库里面，进行检索。因此病毒数据集包括12182个病毒, 1590804个分段；21个细菌共275个基因，1521807个分段。 实验1（见表1）系统随机的在当前的基因库里面，取出75bp的小的片段。我们知道这75bp的基因片段是在哪个基因的哪个片段中提取的。我们将这75bp的基因段到库里面进行检索，查找返回前N个结果集中，查看是否包含这75bp的基因段对应的基因片段。Top-n的精度（Precision(n)），用公式（1）进行计算。 其中，n表示查询返回的列表的长度。u表示查询的次数，在实验中u取的是1000次。表示在第i次查询中，序列si是否出现在Top-n的列表中，出现为1，不出现为0。如果n越小，精度越高，说明我们的方法在实际中非常有效。我们可以看到，针对两个模型来说，top20的精度，都在99%以上。精度在0.99以上，对于实际检验基因片段包含物种基因是足够了的。 表1.基因查询精度检测 数据集 top 1 top 2 top 3 top 4 top 5 top 10 top 20 病毒 0.866 0.965 0.983 0.986 0.99 0.992 0.994 21个细菌 0.901 0.975 0.987 0.987 ...

写在前面： 最近，数据湖的概念非常热，许多前线的同学都在讨论数据湖应该怎么建？阿里云有没有成熟的数据湖解决方案？阿里云的数据湖解决方案到底有没有实际落地的案例？怎么理解数据湖？数据湖和大数据平台有什么不同？头部的云计算玩家都各自推出了什么样的数据湖解决方案？带着这些问题，我们尝试写了这样一篇文章，希望能抛砖引玉，引起大家一些思考和共鸣。感谢南靖同学为本文编写了5.1节的案例，感谢西壁的review。 本文包括七个小节：1、什么是数据湖；2、数据湖的基本特征；3、数据湖基本架构；4、各厂商的数据湖解决方案；5、典型的数据湖应用场景；6、数据湖建设的基本过程；7、总结。受限于个人水平，谬误在所难免，欢迎同学们一起探讨，批评指正，不吝赐教。 一、什么是数据湖数据湖是目前比较热的一个概念，许多企业都在构建或者计划构建自己的数据湖。但是在计划构建数据湖之前，搞清楚什么是数据湖，明确一个数据湖项目的基本组成，进而设计数据湖的基本架构，对于数据湖的构建至关重要。关于什么是数据湖，有如下定义。 Wikipedia是这样定义的： A data lake is a system or repository of data stored in its natural/raw format,[1] usually object blobs or files. A data lake is usually a single store of all enterprise data including raw copies of source system data and transformed data used for tasks such as reporting, visualization, advanced analytics and machine learning. A data lake can include structured data from relational databases (rows and columns), semi-structured data (CSV, logs, XML, JSON), unstructured data (emails, documents, PDFs) and binary data (images, audio, video). [2]A data swamp is a deteriorated and unmanaged data lake that is either inaccessible to its intended users or is providing little value ...

随着取消省界收费站工程落成，我国逐步迈进全国高速公路“一张网”运行感知新时代。借助交通强国和“撤站”政策，2019年12月，广东联合电服和阿里云共同宣布，全国首个高速不停车收费AI稽核项目正式落地广东，在业内率先使用AI和大数据技术准确处理高速公路不停车收费的稽核工作。 # 案例背景：联合电服的挑战与机遇 广东联合电服负责广东省公路联网收费和电子不停车收费的实施工作，是省内唯一发行汽车ETC粤通卡的企业，同时还负责省内高速公路联网收费清分结算的工作，是全国高速公路联网收费体系中的广东省联网中心营运实体。在全国取消省界收费站的工作中，联合电服作为广东撤站工作组的核心落地团队，承担了大量的具体任务，推进了高速公路收费站的ETC发行工作。 # 业务痛点：收费稽查和追缴难度变大 随着省界收费站的取消，以及ETC上车潮的爆发，高速公路的路网服务从省域路网扩大到全国一张网，导致收费稽查和追缴难度变大。 精准问题：收费的准确性依赖于路侧的收费设施设备，对车辆识别要求更高，仅识别车牌已不满足新场景下的稽核要求。如何准确地对车辆身份进行识别，规避收费逃费，有效地进行稽核，是业内要面对的问题。效率问题：按照新的收费技术要求，车辆图片、视频带来以往数十倍的存储和计算压力，稽核的效率急需提升。系统压力：广东省每天600多万交易流水，翻倍到过亿，15倍以上的增长；半年新增1000万用户，需要IT资源快速支持发卡业务，发卡、收费系统压力倍增。稽核需求：公路院报告显示，目前逃费约为3万/km/年，广东省每年逃费2.5亿，占收入总比的 0.5%，行业协会打逃，目前实现追缴不到1亿，每年损失超过5个亿，收费稽核业务需求倍增。 # 解决方案：解决高速撤站收费痛点 视频识别技术：广东联合电服与阿里云合作，借助阿里云全球领先的视频识别技术，精确感知车辆特征，建设智能化稽核分析系统，发现车辆以套牌、遮牌等形式偷逃费的行为。数据技术：在图片、视频全部上云的基础上，还原车辆在全路网的行驶轨迹，突破以往单个设备只能提供有限依据的限制，堵住车辆换卡逃费、绕路逃费的漏洞。边缘计算：在边缘节点上提供稳定的计算能力，通过实时数据处理，缓解图片、视频传输上云的流量压力。案例创新：全国首个高速不停车收费AI稽核项目省域范围AI稽核：国内首家在省域范围内落地，利用人工智能和大数据技术对高速公路偷漏逃费行为进行稽核分析，并投入实际运行的AI大稽查系统。云边一体、全局协同。全广东省的100多个路段布设了边缘计算能力，同时在省联网中心布设了中心技术节点，实时获取信息，进行相应的处理。多源推理，轨迹还原。融合路段RSU数据、视频图像数据、互联网地图数据，还原车辆行驶轨迹。以图搜图。融合车辆特征识别、车辆通行行为识别等多种技术，实现车辆身份的准确推理。特征档案。建立基于路网车辆特征的档案库，一车一档案，一行一轨迹，自动、准确识别各类通行异常行为。一键稽查，准确高效。通过多源推理还原车辆行驶，形成证据链，高效协助通行费稽查补缴。 # 方案价值：为高速公路收费稽核业务智能化升级带来新动能 （1）新技术实现稽查业务智能化升级 资源使用：所有资源按需使用，上云后贴合业务流量曲线准备计算资源，成本大幅优化。大数据融合稽查：全路网覆盖的摄像头轨迹还原与分析提供实时与离线的轨迹还原、重点货车的偷逃费行为研判，为稽核中心提供科技手段提高打击成效并减少工作压力。 （2）“云边一体”部署模式得到最佳资源性价比分布式和低延时计算：边缘计算聚焦实时、短周期数据的分析，能够更好地支撑本地业务的实时智能化处理与执行。效率更高：由于边缘计算距离龙门架、路段业主分析系统更近，在边缘节点处实现了对数据的过滤和分析，因此效率更高。缓解流量压力：在进行云端传输时通过边缘节点进行一部分简单数据处理，进而缩短设备响应时间，减少从设备到云端的数据流量。 （3）以数据资源为核心推动联合电服融合创新发展项目总体将在数据融合和资源整合的基础上，推动数据开放共享，提升联合电服的数据分析能力，为将来数据中台的建设奠定最为坚实的数据能力，并为有效处理复杂的业务问题提供新的手段。 除广东高速外，阿里云还与诸多地区高速达成合作，致力于“更聪明”的道路。在以智慧高速与自由流收费和省界收费站里面的场景中，阿里云还落地了包括云计算技术、自主可控的飞天云平台，稽核平台、收费的方案等，更好实现路段级数字化运营。 广东联合电服总经理李斌表示：“云计算、人工智能等新技术为高速公路收费稽核业务智能化升级、高速智慧运营带来了新的可能，这次与阿里云的合作也将为联合电服在数字化转型上提供更多想象空间。” 阿里云智慧交通专题上线啦！方案全景、体验中心、客户案例、上云模式、架构师咨询……更多详情，进入专题！

注：以下分析基于开源 v19.15.2.2-stable 版本进行 引言ClickHouse内核分析系列文章，继上一篇文章 MergeTree查询链路 之后，这次我将为大家介绍MergeTree存储引擎的异步Merge和Mutation机制。建议读者先补充上一篇文章的基础知识，这样会比较容易理解。 MergeTree Mutation功能介绍在上一篇系列文章中，我已经介绍过ClickHouse内核中的MergeTree存储一旦生成一个Data Part，这个Data Part就不可再更改了。所以从MergeTree存储内核层面，ClickHouse就不擅长做数据更新删除操作。但是绝大部分用户场景中，难免会出现需要手动订正、修复数据的场景。所以ClickHouse为用户设计了一套离线异步机制来支持低频的Mutation(改、删)操作。 Mutation命令执行ALTER TABLE [db.]table DELETE WHERE filter_expr;ALTER TABLE [db.]table UPDATE column1 = expr1 [, ...] WHERE filter_expr;ClickHouse的方言把Delete和Update操作也加入到了Alter Table的范畴中，它并不支持裸的Delete或者Update操作。当用户执行一个如上的Mutation操作获得返回时，ClickHouse内核其实只做了两件事情： 检查Mutation操作是否合法；保存Mutation命令到存储文件中，唤醒一个异步处理merge和mutation的工作线程；两者的主体逻辑分别在MutationsInterpreter::validate函数和StorageMergeTree::mutate函数中。 MutationsInterpreter::validate函数dry run一个异步Mutation执行的全过程，其中涉及到检查Mutation是否合法的判断原则是列值更新后记录的分区键和排序键不能有变化。因为分区键和排序键一旦发生变化，就会导致多个Data Part之间之间Merge逻辑的复杂化。剩余的Mutation执行过程可以看做是打开一个Data Part的BlockInputStream，在这个BlockStream的基础上封装删除操作的FilterBlockInputStream，再加上更新操作的ExpressionBlockInputStream，最后把数据通过BlockOutputStream写回到新的Data Part中。这里简单介绍一下ClickHouse的计算层实现，整体上它是一个火山模型的计算引擎，数据的各种filer、投影、join、agg都是通过BlockStrem抽象实现，在BlockStream中数据是按照Block进行传输处理的，而Block中的数据又是按照列模式组织，这使得ClickHouse在单列的计算上可以批量化并使用一些SIMD指令加速。BlockOutputStream承担了MergeTree Data Part列存写入和索引构建的全部工作，我会在后续的文章中会详细展开介绍ClickHouse计算层中各类功能的BlockStream，以及BlockOutputStream中构建索引的实现细节。 在Mutation命令的执行过程中，我们可以看到MergeTree会把整条Alter命令保存到存储文件夹下，然后创建一个MergeTreeMutationEntry对象保存到表的待修改状态中，最后唤醒一个异步处理merge和 mutation的工作线程。这里有一个关键的问题，因为Mutation的实际操作是异步发生的，在用户的Alter命令返回之后仍然会有数据写入，系统如何在异步订正的过程中排除掉Alter命令之后写入的数据呢？下一节中我会介绍MergeTree中Data Part的Version机制，它可以在Data Part级别解决上面的问题。但是因为ClickHouse写入链路的异步性，ClickHouse仍然无法保证Alter命令前Insert的每条纪录都被更新，只能确保Alter命令前已经存在的Data Part都会被订正，推荐用户只用来订正T+1场景的离线数据。 异步Merge&MutationBatch Insert和Mutation的数据一致性struct MergeTreePartInfo{ String partition_id; Int64 min_block = 0; Int64 max_block = 0; UInt32 level = 0; Int64 mutation = 0; /// If the part has been mutated or contains mutated parts, is equal to mutation version number. ... /// Get block number that can be used to determine which mutations we still need to apply to this part /// (all mutations with version greater than this block number). Int64 getDataVersion() const { return mutation ? mutation : min_block; } ... bool operator<(const MergeTreePartInfo & rhs) const { return std::forward_as_tuple(partition_id, min_block, max_block, level, mutation) < std::forward_as_tuple(rhs.partition_id, rhs.min_block, rhs.max_block, rhs.level, rhs.mutation); }}在具体展开MergeTree的异步merge和mutation机制之前，先需要详细介绍一下MergeTree中对Data Part的管理方式。每个Data Part都有一个MergeTreePartInfo对象来保存它的meta信息，MergeTreePartInfo类的结构如上方代码所示。 ...

阿里云数据库专属集群专属链接云专属数据库，重新定义云数据库新形态数据库是一个有着超过40年历史的悠久行业，前期一直被传统的如Oracle等少数几家厂商把持。云计算的先行者AWS在2009年率先推出RDS服务（Relational Database Service ），商业上通过云计算的模式颠覆了传统license交付的模式，产品上通过全托管的服务模式，在技术和产品上帮助客户代维数据库，颠覆了客户自运维的模式，降低了客户使用数据库的门槛，使得客户聚焦到业务本身，生产力得到了极大的提高。 阿里云作为国内云数据库的领导者，在2010年推出了阿里云RDS服务，经过10年的发展，阿里云RDS已经发展成为了一个完整的价值体系，支持MySQL、MariaDB、SQL Server、PostgreSQL等，并由此发展出来一系列NoSQL、OLAP、工具等产品。今天的阿里云数据库已经名列全球云数据库Top 3，比肩AWS和Azure等国际重量级玩家。 当前上云已经成为一种趋势，而在上云的过程中，数据库则被认为是非常重要的一环。越来越多的中大型客户，尤其是在传统行业中，客户在线下或者云上自建数据库，有自己使用数据库的习惯、熟悉的工具集和监控运维体系，如何在提供便捷、灵活的云数据库服务的同时，兼顾企业客户对于数据库自主可控制、安全合规性诉求，使得客户能够对接现有的监控运维体系、数据库专业工具。这一次，在迎接中大型企业上云的浪潮中，阿里云数据走在了时代的前列，创新提出了云数据库专属集群新形态，在完全兼容云数据库所有能力的基础上，再次释放技术创新的价值，让客户享受到资源专属、灵活可定制的超级能力。 为了释放技术创新的洪荒之力，云数据库专属集群从五个方面入手： 一、业内首创客户自主可控、无缝对接监控运维系统当前大部分云厂商提供的数据库服务是对客户透明下层的主机和操作系统，阿里云数据库专属集群通过开放OS权限，使得客户能够保留原有的数据库管理模式。 通过堡垒机让客户可以登陆和管理数据库实例所在主机，一个堡垒机可登录多个数据库主机（如下图所示）。堡垒机的主要作用是记录用户的所有行为，用户所有的命令都必须经过堡垒机，不开放数据库主机公网访问，保障数据库主机的安全性。 云数据库专属集群开放OS权限，让客户获得更多自主可控的权限，可充分发挥客户DBA的价值，及时解决数据库问题。 二、做性价比最高的数据库，进一步降低企业TCO数据库一般都采用单独部署的形态，在实际使用过程中每个数据库实例均预留了一定量的CPU资源，CPU利用率基本在50%左右，造成资源的闲置和浪费。现有的系统架构，无法既满足业务的实际需要，又进一步降低TCO。 1、提供资源超配专属集群主机内部通过系统的调度，利用业务本身高低峰，实现“犬牙交错”的部署形式，使得资源得到最大化利用，可以获得比实际物理资源要多的资源，同时进一步降低TCO。 专属集群主机的超配能力，当CPU超配300%时，仅相当于同等规格ECS 50%的成本支出。专属集群主机上部署的数据库内核和原PaaS上的数据库实例相同，都是阿里云加强的企业版，相比官方企业版相当于每年节省数十万的License费用。 2、混合部署多种数据库很多客户不止使用一种数据库，经常出现MySQL+Redis，MySQL+PostgreSQL这样组合使用，从业务角度来看进行不同类型数据库混合部署，这样更加贴近业务实际。 专属集群将支持不同的数据库如MySQL，PostgreSQL，Redis进行混合部署，后续更加扩展到OLTP和OLAP的混合部署，进一步满足不同客户的实际需求。 三、做最灵活的数据库，让客户充分享受灵活定制的能力传统全托管云数据库，给所有客户尽力提供一个最优质的服务，但是大中型客户天然的业务复杂度，让通用策略和方法变得捉襟见肘，只有结合业务的平台才能获得最佳成本和效益。云数据库专属集群会逐渐将底层平台的能力释放出来，让客户可以结合业务灵活地去定制，比如超卖策略，备份策略，HA策略，带宽任意用满，CPU/Memory灵活配比，只读任意副本等等。以资源调度策略为例： 云数据库专属集群提供灵活的资源调度策略，大促时利用均衡型策略分摊新购的机器压力，平时利用紧凑型策略充分利用资源，最高节省60%的整体成本；专属集群灵活的资源弹性策略可解燃眉之急，本地快速弹升CPU、IOPS等资源，DBA干预系统资源分配解决业务问题。 四、做最安全的数据库云数据库专属集群将底层物理机整体调度给单个客户使用，让客户在公共云上享受类似私有云一样完全隔离的专属物理资源，实现CPU、内存，带宽完全独占。 五、做最稳定的数据库，享受全托管服务一样的体验阿里集团在长期服务电商业务的过程中，积累了丰富的数据库经验和版本，今天通过云计算技术将集团的版本同时释放出来，云数据库专属集群和RDS一样，除了提供开源的MySQL、PostgreSQL、Redis等这些数据库之外，分别提供对应的阿里集团内部的版本，三节点企业版本，Tair等。相比社区版本，这些企业版本在稳定性、性能等企业能力上有本质的提升，典型有： 1、 MySQL企业版本相对于开源版1.5倍的性能提升，最高4个9的高可用性，满足客户高性能、高可用性要求。 2、 Tair相比Redis提供3x性能提升的高性能版本和90%混合存储的能力。 写在最后云数据库专属集群是阿里云专为大中型企业用户定制优化的解决方案，填补了市场空白，具有资源独享、自主可运维、多数据库混合部署等特点。让用户既享受到云数据库的灵活性，又满足企业对数据库合规性、高性能和安全性要求。在推出的短短的几个月时间，就受到了众多大中型的客户信任和欢迎。云专属数据库浪潮已经势不可挡，接下来会持续推出客户急需的能力，阿里云诚意打造，让云数据库专属集群成为上云标配。

背景 Spark on MaxCompute可以访问位于阿里云VPC内的实例（例如ECS、HBase、RDS）,默认MaxCompute底层网络和外网是隔离的，Spark on MaxCompute提供了一种方案通过配置spark.hadoop.odps.cupid.vpc.domain.list来访问阿里云的vpc网络环境的Hbase。Hbase标准版和增强版的配置不同，本文通过访问阿里云的标准版和增强版的Hbase简单的描述需要加的配置。 Hbase标准版 环境准备 Hbase的网络环境是存在vpc下的，所以我们首先要添加安全组开放端口2181、10600、16020.同时Hbase有白名单限制我们需要把对应的MaxCompute的IP加入到Hbase的白名单。 设置对应vpc的安全组 找到对应的vpc id然后添加安全组设置端口 添加Hbase的白名单 在hbase的白名单添加 100.104.0.0/16 创建Hbase表 create 'test','cf' 编写Spark程序 需要的Hbase依赖 <dependency> <groupId>org.apache.hbase</groupId> <artifactId>hbase-mapreduce</artifactId> <version>2.0.2</version></dependency> <dependency> <groupId>com.aliyun.hbase</groupId> <artifactId>alihbase-client</artifactId> <version>2.0.5</version></dependency>编写代码 object App { def main(args: Array[String]) { val spark = SparkSession .builder() .appName("HbaseTest") .config("spark.sql.catalogImplementation", "odps") .config("spark.hadoop.odps.end.point","http://service.cn.maxcompute.aliyun.com/api") .config("spark.hadoop.odps.runtime.end.point","http://service.cn.maxcompute.aliyun-inc.com/api") .getOrCreate()val sc = spark.sparkContextval config = HBaseConfiguration.create()val zkAddress = "hb-2zecxg2ltnpeg8me4-master\*-\*\*\*:2181,hb-2zecxg2ltnpeg8me4-master\*-\*\*\*:2181,hb-2zecxg2ltnpeg8me4-master\*-\*\*\*:2181"config.set(HConstants.ZOOKEEPER\_QUORUM, zkAddress);val jobConf = new JobConf(config)jobConf.setOutputFormat(classOf\[TableOutputFormat\])jobConf.set(TableOutputFormat.OUTPUT\_TABLE,"test")try{ import spark.\_ spark.sql("select '7', 88 ").rdd.map(row => { val name= row(0).asInstanceOf\[String\] val id = row(1).asInstanceOf\[Integer\] val put = new Put(Bytes.toBytes(id)) put.addColumn(Bytes.toBytes("cf"), Bytes.toBytes(id), Bytes.toBytes(name)) (new ImmutableBytesWritable, put) }).saveAsHadoopDataset(jobConf)} finally { sc.stop()}}} ...

作者 | 声东 阿里云售后技术专家 <关注阿里巴巴云原生公众号，回复 排查 即可下载电子书> 《深入浅出 Kubernetes》一书共汇集 12 篇技术文章，帮助你一次搞懂 6 个核心原理，吃透基础理论，一次学会 6 个典型问题的华丽操作！ Istio is the future！基本上，我相信对云原生技术趋势有些微判断的同学，都会有这个觉悟。其背后的逻辑其实是比较简单的：当容器集群，特别是 Kubernetes 成为事实上的标准之后，应用必然会不断的复杂化，服务治理肯定会成为强需求。 Istio 的现状是，聊的人很多，用的人其实很少。所以导致我们能看到的文章，讲道理的很多，讲实际踩坑经验的极少。阿里云售后团队作为一线踩坑团队，分享问题排查经验，我们责无旁贷。这篇文章，我就跟大家聊一个简单 Istio 问题的排查过程，权当抛砖。 二分之一活的微服务 问题是这样的，用户在自己的测试集群里安装了 Istio，并依照官方文档部署 bookinfo 应用来上手 Istio。部署之后，用户执行 kubectl get pods 命令，发现所有的 Pod 都只有二分之一个容器是 READY 的。 # kubectl get pods NAME READY STATUS RESTARTS AGE details-v1-68868454f5-94hzd 1/2 Running 0 1m productpage-v1-5cb458d74f-28nlz 1/2 Running 0 1m ratings-v1-76f4c9765f-gjjsc 1/2 Running 0 1m reviews-v1-56f6855586-dplsf 1/2 Running 0 1m reviews-v2-65c9df47f8-zdgbw 1/2 Running 0 1m reviews-v3-6cf47594fd-cvrtf 1/2 Running 0 1m 如果从来都没有注意过 READY 这一列的话，我们大概会有两个疑惑：2 在这里是什么意思，以及 1/2 到底意味着什么。 简单来讲，这里的 READY 列，给出的是每个 Pod 内部容器的 Readiness，即就绪状态。每个集群节点上的 kubelet 会根据容器本身 Readiness 规则的定义，分别是 tcp、http 或 exec 的方式，来确认对应容器的 Readiness 情况。 更具体一点，kubelet 作为运行在每个节点上的进程，以 tcp/http 的方式（节点网络命名空间到 Pod 网络命名空间）访问容器定义的接口，或者在容器的 namespace 里执行 exec 定义的命令，来确定容器是否就绪。 ...

发布会传送门 进入直播间还有好礼等你拿！ EDAS产品免费试用：https://www.aliyun.com/activity/middleware/edaspromotiononmay 首届云原生编程挑战赛正式开战！立即报名瓜分330000现金奖：https://tianchi.aliyun.com/specials/promotion/cloudnative#problem-definition 观看《云原生架构师培训课程》领取新用户折扣：https://yqh.aliyun.com/live/AlibabaCloudNative 云原生的发展速度日新月异，要用好却绝非轻而易举，当开发者开始使用云原生或向云原生架构迁移时，往往会面临一些困境： 第一，云原生对于软件产品存在约束，如必须满足容器化，12要素等，因此要让一个遗留系统适配云原生体系，不免会需要做一些改造，其中甚至会涉及到开发模式的转变，对部分团队而言，转变的过程可能充满挑战。第二，K8s复杂性足以让很多开发者望而却步，而只有对其有较好的掌握才能发挥好云原生带来的优势，否则可能导致系统难以维护，甚至因错误的配置引发故障。而让开发者的技术水平紧跟K8s的发展速度，这本身也需要持续投入，这些额外的投入也背离了让开发只关注业务的初衷。第三，虽然开源社区给云原生贡献了丰富的能力组件，但对于线上业务，尤其是企业级的服务来说，开源组件的性能，可靠性和可维护性能否经得住考验，以及运维团队是否有能力对这些开源组件兜底，这也是在技术选型前所必须做的考虑。总之，了解云原生和K8s只是开始，想要将云原生在业务落地，发挥云原生的价值，选择一条合理的“原生化”路径，才是开发者要关注的核心问题。 阿里巴巴对于云原生的运用起步很早，对于在具有大规模，高可靠和分布式特征的系统上应用云原生技术有丰富经验。EDAS作为出品自阿里巴巴云原生团队，阿里云上aPaaS的旗舰产品，在早期也提供了容器和K8s的支持能力。近期随着EDAS 3.0版本的重磅发布，更是将云原生融入了EDAS的功能核心，致力于帮助业务进行云原生落地，立足云原生平台打造更强大的应用管理能力，释放技术红利，服务广大开发者。 下文将通过一些示例，带领大家一窥究竟，看EDAS如何帮开发者“躺着”进入云原生时代，玩转云原生。“纯粹”的云原生 无法否认，EDAS是阿里云平台上的商业化产品，而云原生主要由开源社区所倡导，两者显然出自泾渭分明的两个阵营，那“纯粹”是在掩耳盗铃？ 其实不然，商业化与开源并非水火不容，相反在很多领域他们总是相辅相成，这个话题并非本文关注的重点，若抛开“出身”的因素，我们理解的“纯粹”指的是： 在原生的体系下，对资源进行组合和抽象，抽象后的资源也不脱离原生体系不侵入，不限制，不破坏已有云原生资源的使用约定得益于K8s的开放性，EDAS实现的原理并不复杂，用户只需要在K8s配置资源（应用），通过声明式的配置将其置于期望的状态上，EDAS就能感知变更，自动维护并调整状态，使其最终与用户期望一致，从而达到管控应用的目的，这一切并不需要修改K8s的版本，只需要安装EDAS提供的扩展即可。 下面从两方面来具体介绍EDAS的做法和因之带来的优势。 云原生应用定义 前文提到，EDAS将应用抽象成了资源，这个过程中，应用定义的设计是至关重要的。在声明式的规则下，应用定义需要能覆盖软件生命周期过程中每个主体的配置，状态和关系的描述，并保证良好的可读性，因此，它必须归纳自大量应用，复杂场景和长久维护的经验总结，也只有这样才能保证定义不脱离实际，能被高效的推演到其他应用上。 EDAS没有重复造轮子，选择了“开放应用模型（OAM）”这一开放标准来作为应用定义，并选择与之共建的方式来丰富标准的内容。可以说，EDAS是OAM在阿里云上的一个实现。 对于开发者来说，EDAS使用OAM提供了两大好处： OAM消除了厂商平台对开发者的绑定，虽然不同平台能支持的运维特征以及底层实现方式各部相同，但只要厂商都遵循同样的标准，同一份应用配置是可以在不同的平台之间进行迁移的。因此对于EDAS上产生的应用，是可以被迁移到其他同样遵循OAM规范的平台的，针对其他平台迁移EDAS的场景也同理。OAM隐藏了特定的底层workload类型，通过更高的抽象层次避免了直接操作底层K8s的复杂性，提供了独立的ApplicationConfiguration资源，通过对Component（组件）配置Trait（运维特征）来施加不同的运维能力，Component和Trait的设计较好的分离了开发和运维团队的关注点，让应用生命周期中的配置和协作工作变得更为简单。由于ApplicationConfiguration也是K8s自定义资源（CR），所以开发者可以直接使用kubectl工具对其进行增删查改操作，EDAS遵循K8s面向终态的设计原则，最终将应用调整到预期的状态，对开发者来说操作应用与操作常规的Deployment资源并没有差异，也可以非常方便的与其他CI/CD工具或者GitOps工作流相集成。 下面给出了一份EDAS的应用yaml示例片段，通过kubectl apply这样一份配置即可创建一个用指定Jar包部署的EDAS应用： apiVersion: core.oam.dev/v1alpha1 kind: ApplicationConfiguration metadata: name: helloedas namespace: default spec: components: componentName: stateless-component instanceName: group-1 parameterValues: name: packageVersion value: '{"buildPackageUrl":"http://demo.oss-cn-hangzhou-internal.aliyuncs.com/prod/demo/SPRING_CLOUD_PROVIDER.jar","showName":"2020-05-07 20:20:18","type":"war","url":"http://demo.oss-cn-hangzhou-internal.aliyuncs.com/prod/demo/SPRING_CLOUD_PROVIDER.jar"}'name: artifactFormat value: FatJarname: softwareComponents value: '[{"componentId":"5","componentKey":"Open JDK 8","createTime":0,"desc":"Open JDK 8","downloadUrl":"http://edas-hz.oss-cn-hangzhou.aliyuncs.com/agent/prod/files/jdk-8u65-linux-x64.rpm","expired":false,"id":"5","imageId":"","md5":"1e587aca2514a612b10935813b1cef28","type":"JDK","version":"8"}]'name: replicas value: "1"name: showName value: helloedasname: description value: ""traits:* name: rollout properties: * name: auto value: "true" * name: batches value: "1"* name: imagebuilder properties: * name: tag value: helloedas-1588854022 * name: registry value: registry-vpc.ap-northeast-1.aliyuncs.com * name: baseImage value: registry-vpc.cn-hangzhou.aliyuncs.com/edas\_unified/edas-openjdk:8-1.0 * name: timeout value: "900"Deployment编辑 ...

前言：更多关于数智化转型、数据中台内容可扫码加群一起探讨 阿里云数据中台官网 https://dp.alibaba.com/index （作者：友盟+） “消费升级”是近年来的中国消费市场热门词汇，消费升级的同时也驱动了内容消费升级。在这样的大众消费市场下，一款主打技术类内容的短视频App——好兔视频应运而生。作为非BATT系的初创型企业，如何在竞争激烈的视频行业破局，实现逆风翻盘？ 好兔视频选择牵手友盟+，深度融合行业应用大数据，建立设备质量分层等数据应用模型，帮助处于初创期的好兔视频解决数据应用、拉新、留存等运营难题，实现发展突围。 好兔视频瞄准了时下内容消费升级的大趋势，专注于精选实用小视频, 生活技能分享，希望给那些热爱生活的人提供一些高品质的内容，深受国内高知人群欢迎。 机遇与挑战并存，视频行业大数据壁垒亟待破局 互联网巨头掌控互联网应用和服务的绝大部分数据资源，BATT系App占据了用户使用时长的70%，不难发现数据规模马太效应越来越严重，中小型App开发企业难以靠一己之力突破互联网巨头的“数据霸权”。 这主要体现在以下几个方面：首先，中小型企业日活可能只有几十万到数百万不等，难以与BATT系应用的亿级数据集竞争；同时，中小型企业缺乏横向和纵向完整的用户画像，对于新推广的每个用户而言都是全新用户，冷启动硬伤凸显，难以做到千人千面的用户服务，而BATT系的用户画像已经非常完整，根据海量用户的产品矩阵，可以大概猜测出用户的收入、喜好等用户画像。 最关键的是，缺少大数据加持，中小型App经常会处于盲人摸象的状态，这是因为当前的网络应用已经不是一个数据孤岛，而是在不同行业或不同领域上相互依赖和关联，如果仅仅依靠单一垂直App获取单一局部数据集往往会导致认知偏差，而不是 站在一个全网数据下看待问题，导致你认为的通常并不是你认为的，就像盲人摸象一样。无法全面洞悉偏好，更无法进行精准化、个性化、智能化的内容推荐。 时长即数据，友盟云助力好兔视频数据短板变长板 时长即数据的发展背景下，中小型App要突破必须有数据能力加持，尤其需要关注天生的大数据短板，以谋求破局。为此，好兔视频携手友盟+，通过深度融合数据来解决视频应用所面临的行业痛点。 借助阿里云的PaaS平台，形成一个全域的行业应用大数据，建立好兔视频专属的大数据库，将数据短板转化为长板。在友盟云之上（集成领先的阿里云技术，将互联网企业业务数据与行为数据的无缝融合）打通好兔视频的业务数据与行为数据，使得好兔视频可以在“云上”进行建模和一系列计算，计算出可使用的标签并改善内容推荐机制，提升产品的使用体验。 此外，通过与友盟+的行为数据打通，好兔视频可以勾勒出完整的画像，减少认知偏差，为产品运营以及用户服务等方面提供数据支撑。比如，IN的数据包括了一些设备的使用时长、Push等信息，好兔视频可能自身无法获取到系统的数据，通过友盟+就能了解到设备的安装、价值等数据，实现对流失的预测分析，给用户提供最及时的视频内容。 精耕细作大数据富矿，赋能好兔视频构建拉新留存新通道 当下，经历了流量主导下的跑马圈地后，以精品化的内容策略撬动用户数据新增长，正在成为视频应用新的成长通道。然而，面对网络虚拟环境，单单凭借一个App的局部数据，一方面会导致用户认知偏差，容易把用户带偏。另一方面又要针对作弊、营销、非自然人的机器操作等方式做出应对方案，帮忙企业更好地专注核心业务用户体验本身。诚然，大数据的应用和服务创新成了解决视频行业痛点的关键。 在以往，传统型的数据服务需要大量的调研时间和成本，并且难以对原始数据进行二次开发利用，造成数据资源闲置，并加重中小企业的研发负担。在友盟云之上，好兔视频不仅能够更快捷地获取海量的数据资源，还能进一步挖掘数据背后的富矿。 例如，好兔视频能够通过“云上”平台数据模型对现有数据进行二次计算，一方面多维度洞察用户需求并构建完整用户画像，弥补与BATT四大巨头之间在用户画像上的差距，实现千人千面的智能化推荐，满足用户更加个性化的需求；另一方面可以通过数据风控，精准识别风险设备，实现对设备质量进行分层评估，促进用户与内容运营的良性互动，提升次日留存率。 值得一提的是，友盟+与好兔视频基于大数据所构建的设备质量分层评估模型，通过90天的设备日志检测全网的设备行为，多维度的指标衡量、地域、活跃、设备的可在线、累计渠道和黑名单等来评估数据质量，可将设备价值分为A、B、C、D四类设备。 从价值流上看，A类设备到C类设备的占比基本呈下降的趋势，但到了D类设备，也就是低价值设备，却有了一个提升。其实，D类设备所有的操作都更加类似于A类设备，也就是高价值设备。好兔认为这可能与线上是一个虚拟的环境有关，生活在社会顶层和社会底层环境的设备，在线上的行为可能是类似的，有待下一步分析。 在这种情况下，好兔如果单看一个应用内的局部数据，就容易导致认知的偏差，将用户导向机制引偏。同时，从不同分层设备应用内行为数据也能看出，作弊设备由于各项数据都非常高，特别是设备使用时长，可能超过高价值设备，对用户识别有较高的干扰。 通过友盟+的加持，好兔就能获取到视频分类的播放数据，从而更精准地识别作弊设备。可以看出，由于好兔主要提供生活技能类视频，价值越高的设备对好兔App提供的生活窍门、美食、百科、健康等内容的喜好就越来越高。只有作弊设备是特例，其播放数据相对比较平均，无法看出其喜好。凭借这一点，好兔就能比较明显地发现可能是设备的操作，避开用户引导的误区。 通过设备分层的数据融合实践，好兔视频得以全方位实现单一App无法做到的识别作弊设备或营销行为等非自然人操作方式，帮助好兔视频把所有的运营精力和营销精力集中在A类高价值设备，拉新和促活也有更明确的指标和有效的策略指导，开辟一条快速成长的新通道。 提升短视频应用的企业竞争力，大数据融合扮演着至关重要的角色。随着越来越多的大数据服务能力的开放和加持，友盟+不仅能够帮助视频应用实现更多的创新，而且在大数据的风控、精准营销以及用户运营服务上也能够更加精益求精，持续为中小型App企业提供技术支持。 未来，友盟+携手好兔视频所打造的深度数据融合“样板间”会被广泛应用于各行各业。 数据中台是企业数智化的新基建，阿里巴巴认为数据中台是集方法论、工具、组织于一体的，“快”、“准”、“全”、“统”、“通”的智能大数据体系。目前正通过阿里云数据中台解决方案对外输出，包括零售、金融、互联网、政务等领域，其中核心产品有： Dataphin，一站式、智能化的数据构建及管理平台；Quick BI，随时随地 智能决策；Quick Audience，全方位洞察、全域营销、智能增长；Quick A+， 跨多端全域应用体验分析及洞察的一站式数据化运营平台； 官方站点：数据中台官网 https://dp.alibaba.com

“两会”期间， “新基建”（即新型基础设施建设）被频频提及，并且被首次写入《政府工作报告》，国家提出了对 "新基建" 的 2020 计划 ，具体指： 加强新型基础设施建设，发展新一代信息网络，拓展 5G 应用，建设充电桩，推广新能源汽车，激发新消费需求、助力产业升级。 作为“新基建”的重要内容，具有高速率、低时延、大带宽等特点的5G网络将迈入快速发展的新阶段。而随着5G网络的发展，一些相关行业也将随之出现变革。以视频监控行业为例： 首先，超高清视频时代到来 不断变化的市场需求使得视频图像逐步从标清、走向高清甚至超高清。5G网络技术的普及还将推进超高清视频的传输效率进一步提升，从而解决数据提取及进行分析应用时，因为图像的清晰度不够而无法使用的问题。 其次，智能化成为发展趋势。 人脸识别、行为识别、车牌识别、目标分类等人工智能算法的快速发展，使得安防智能化成为了近两年最为明显的一个发展趋势。 根据IDC的相关预测， AI摄像头将持续高速增长，并大量替换传统摄像头。智能视频监控技术近几年来被广泛研究并开始实际应用，通过将AI相关的视觉技术融入视频监控系统，可以对视频数据流进行图像处理、目标分析，实现自动检测、目标跟踪等目的，对视频监控系统进行实时控制，变被动监控为主动监控。在机场、高速公路等场景中，对于摄像头高清化的要求进一步提高，高清摄像头不仅提高日常工作的效率，同时也让机器视觉技术有了用武之地，进一步挖掘数据相关价值。 第三，混合云成为更好的落地方式。 以阿里云所提供的视频监控数据的云端直接存储解决方案为例。该方案针对安防行业大规模集中式或分布式存储需求而推出，提供存储虚拟化管理功能，将所有存储节点空间合并成一个存储虚拟池，对外提供海量存储空间管理。云存储管理解决方案的存储节点以云架构为基础，专注于视频、图片等文件的存储业务，集节点虚拟化、视频图片管理，结构化数据存储于一体，具有高性能、高可靠、高密度、高扩展性、高易用性等特点。 此外，阿里云同样支持混合云存储方式部署。线下采用标准化设备部署，并且与合作伙伴视频监控平台通过专线进行平台级联，视频数据直接存入云端对象存储中。在文件的生命周期管理上，文件定期删除动作可以由平台侧软件定期发起。当客户端需要调取历史视频回放时，首先查询线下平台对应设备录像信息，其次通过线下平台通过专线从阿里云存储中调取。 2019年，某市政府与阿里巴巴集团签署合作框架协协议，通过“人工智能+城市大脑”、区域互联网医疗和移动支付城市等多个合作项目，在数据基础设施、民生服务、城市治理、智慧产业等领域全方位开展合作，力争将该市打造成利用人工智能促进民生普惠、城市精治的全国典范。 在安防监控场景中，使用混合云存储阵列进行线下部署。 视频监控数据可以无缝写入阿里云混合存储产品，可实现云上云下的数据流转，云上无缝扩容。同时，不管在云上还是云下的存储数据，都可以无缝与阿里云AI产品地雀一体机、数据智能AI平台等无缝对接，进行智能分析。 首先，该方案可以做到成本以及时间上的节省。采用混合云方案，节省本地IDC机柜空间，降低用电功耗压力，数据无缝上云，进而大幅缩短存储项目扩容周期；在前期投入上，采用按月付费的方式减少资金压力；云上存储可保证高达12个9的可靠性，保证业务的连续运行。 其次，运用数据智能缓解城市建设中的焦点和难点问题，优化城市综合治理能力和公共服务水平；利用云计算、移动互联网、视觉人工智能、物联网等技术，在智慧旅游、安全校园、智慧城市、工业互联网、智能制造等领域开展合作。 事实上，技术推动的“新基建”改造早已开始。比如被人们广为熟知的杭州城市大脑，现在已经被全球23个城市所引进。在疫情期间，阿里云更是全力投入数字经济新基建，将阿里巴巴20年建设的技术能力带给全社会，帮助政府和企业建设面向未来的新型基础设施。

近日，阿里云杨敬宇在CSDN阿里云核心技术竞争力在线峰会上进行了《5G基础设施-阿里云边缘计算的技术演进之路》主题演讲，针对5G时代下，行业和技术的趋势、边缘计算产业通识以及阿里云边缘计算从过去到未来的技术演进之路进行分享。 5G+AI需求推动边缘计算不断向前 算力分布形态发生根本变化 回顾历史，自从1994年接入互联网，已经有20多年的时间，从应用场景看，终端从PC时代走到了移动时代，也包括电视、摄像头、IoT等终端。而背后的基础设施也从早期的自建服务器，到当前全站上云这种模式。整体看来，网络架构是云、端两层架构。 当5G来临，消费互联网逐渐向产业互联网延伸，物联网、工业互联网、车联网、医疗健康、在线教育、企业远程视频会议等大带宽、低时延、大流量的场景被激活，原有的云、端两层网络架构很难满足新的产业互联网之下对低时延、低成本以及本地化计算的需求，这就促成了边缘计算出现的第一波应用。与此同时，5G的一个关键特性是，与2G、3G、4G的管道形式不同，5G允许在基站或者网络中的任何位置进行分流，所以5G也为边缘计算提供了技术上的可行性。以上两点，是边缘计算在5G时代走上风口的最核心原因。 在云、端两层网络架构中，计算要么发生是在云上，要么在手机、PC、电视机等终端上面，随着IoT万物智联的普及，工业互联网、车联网、智能家居、智慧城市、自动驾驶、云办公、3D视频等新型的产业应用出现之后，全部的计算发生在云端可能无法满足时延要求，而全部发生在端侧，对端的要求又比较高。 所以，计算从原本的云端两层结构，逐渐迁移到基站以上和云以下的位置，在城市这样的位置实现距离与效率的平衡，演变成云、边、端三层结构，这将是未来主流的计算分布形态。 杨敬宇： 2020年是划时代的一年，是从消费互联网走向产业互联网的转折之年，也是边缘计算领域真正乘风而行的一年，期待5G边缘计算能够规模商用和真正落地。 边缘计算行业通识：技术架构、产业协同与应用场景 前面也提到，5G原生支持在通信管道内分流做边缘计算，技术上具备了计算下沉到基站的可能性。也就是，在4G之前，在通信网络中一头是端，一头是云。如果把通信网络比作一条高速公路，它是没有服务区的，所有的信息流都是从这条高速公路上流转运行。5G有一个非常好的特性，就是允许在高速公路上修建服务区，当信息在基站的位置，就可以把它分流出来进行本地计算，可以在社区网格、街道乡镇、地市区县、省会城市等等整个通信网络的任何一个位置实现计算。 在场景方面，未来沉浸式消费计算和产业互联网会涌现大量的“低时延高可靠/大带宽/大连接，低成本，属地化”等边缘计算需求。未来5G边缘计算有一些产业应用会大量的涌现。同时，终端的计算上云，比如云游戏、云桌面等应用场景，不管是对用户的成本，还是企业和设备的成本与维护来讲，都是最佳的状态。 边缘计算产业上下游有众多参与者，主要包括运营商、云厂商、专业服务厂商以及设备和芯片商等，分别从各自的优势来为边缘计算产业发展提供助力。 云厂商一直提供一种按需付费的云服务，随着产业互联网的到来，云厂商会结合边缘计算将云服务进一步延伸和拓展，大型、集中的计算还是交由云中心来完成，对于时延、成本、本地化计算有强需求的则放在边缘来完成。于运营商来讲，边缘计算是在运营商的城域网或5G核心网、基站等位置去计算，计算就发生在运营商的整个网络体系里面，无论是国外还是国内的三大运营商，目前对边缘计算的投入都是非常大的。而专业服务厂商包括一些CDN厂商，他原来定义的计算其实是放在地级市这种IDC之中，还不是严格意义上的通信互联网的边缘，同样也是一种边缘。另外，边缘计算之中有一部分是设备，比如在网关领域做边缘计算，这就涉及到了设备商和芯片厂商的领域了。 现阶段边缘计算的应用场景大约分两大类，一类是需要在全国各地，甚至全球各地去部署这种分布式计算资源，典型应用就是CDN内容分发网络，它其实就是在分布式节点上去提供内容缓存与转发。未来在线教育、在线会议和其他场景也是分布式互联网应用的核心场景。另外一类就是产业应用，对计算有本地化、低时延的诉求，可能在10公里、百公里范围内就要完成计算，比如视频汇聚、智慧园区等等场景。 边缘节点服务：开放、标准、灵活、易用的边缘云操作系统 谈到公共云与边缘云的区别以及边缘云的主要技术特征和挑战，杨敬宇认为主要有四点。 第一，公共云与边缘云都是大规模，但是规模属性不同。公共云是中心式的大规模的云，通常由少量的大资源去构成，而边缘计算通常是由大量的小节点组成。同时，从技术上来讲，公共云的整个的保障体系、机房、电力、网络环境和边缘云所处环境是不太一样的，所以边缘云与公共云的建设、资产管理逻辑都有所不同，这也是它非常大的一个挑战。 第二，边缘云并不是每1个小节点是一朵云，杨敬宇所认为的边缘云，是上万个节点或者上百万的节点组成的一朵云。所以边缘云是需要基于不可靠互联网的形成集中管理、统一调度的，甚至当边缘节点出现网络中断的时候还能够脱网自治。 第三，边缘计算要承接物联网、车联网各种各样的网络连接需求，所以边缘计算要解决如何去做5G网络分流的问题，包括计算什么样的流量需要分流，分流计算完之后又该怎样录流，它不是简单的提供一个计算服务，而是要云网一体的去提供给客户去使用。 第四，从客户的使用方法上来讲，以往公共云大家习惯的方式是：买一个region、几台机器，还有一个IP，就会知道它在哪里。但是边缘计算如果沿用这样的形式其实是可能会是一个灾难。 杨敬宇做了个恰当的比喻：实际上，使用边缘计算就应该像我们使用电话一样，当电话的时候我一定会使用一个4G或一个基站，甚至当开车的时候，手机连着基站还是会不断发生变化，但是作为使用者并不会关心基站在什么位置，我只是享受了打电话这个服务，我希望服务对我而言是无感的。所以，对于这种大规模边缘计算基础设施来讲，不是简单地去卖用户一个一个节点的计算能力，而需要考虑如何提供给用户一个在体验上更加无缝、在成本上有极大帮助的这么一套计算体系。我们一直将ENS比喻成一个操作系统，操作系统它的特点就是我的应用程序是基于进程、线程来使用CPU和内存，用户不用关心这个程序到底在CPU的哪个核上以及它用哪个时间片去计算。所以，ENS操作系统要做的就是算力的管理以及算力的无缝使用，这是比公共云更难处理的一部分。 如上图所右侧示，阿里云ENS最底层仍然是各种各样的基础设施，基于这个基础设施以及阿里云的虚拟化、以及在网络计算存储安全方面的技术沉淀，在上面形成一个大规模、分布式的未知未知无感的、屏蔽底下资源差异、规模差异和使用差异的一个边缘云操作系统或者边缘计算平台。通过能力的开放以及运维联动，为上层应用提供了一套更便于使用的基础设施。 阿里云是从2017年开始进行技术上的打磨，并且基于遍布全球的CDN节点去改造为边缘计算节点，经过2年的发展，在2019年时，阿里云边缘计算其实做到了中国300多个地级市的全域覆盖，将计算的时延控制在10毫秒以内。也就是当用户去看视频，可能25帧的视频需要播放40毫秒，那么10毫秒就会让用户的视觉上毫无换帧的感知，对于云游戏、云桌面等应用，可以在时延上得到极大的满足。 边缘计算的概念近几年十分火热，但是各家在理解定义上，包括所实现的技术栈上，还是存在一定的差距。为了边缘计算行业积极良性的发展，阿里云在行业标准化方面也投入了大量的精力。2018年12月，阿里云牵头发布了边缘云白皮书，在行业内首次定义了边缘云计算的概念。在2019年9月的云栖大会上，阿里云联合20多家单位对边缘云计算的通用技术要求标准进行发布，同时在12月份，阿里云也获得了由中国电子技术标准化研究院颁发的首批《边缘云标准符合性测试证书》，也意味着阿里云在推进边缘云领域标准化建设上更进一步。 杨敬宇认为：阿里云边缘计算是要构建城市计算，也就是以地级市为单位的去逐渐部署边缘云基础设施，为阿里巴巴经济体与行业客户的各类应用落实到边缘云提供助力，去赋能5G时代万物智联的智慧城市生活更快来临。

“唯有热爱，可抵岁月漫长”。 2020 年 5 月 25 日，阿里巴巴编程之夏（Alibaba Summer of Code，以下简称 ASoC ）第二期正式上线，项目规模再度升级，来自开源社区的 Apache Dubbo、Apache RocketMQ、Dragonfly、Nacos 等明星开源项目多达 20 个；导师阵容配置豪华，来自阿里巴巴集团的技术专家、开源社区核心成员、Apache 孵化器导师等多达 32 位；领域涉及微服务、容器、AI 等多个热点方向，旨在联合开源社区打造诚意满满、公平公正的开源实习平台，以阿里巴巴开源技术力量为“推手”，让中国开源社区和开发者精英受到世界范围内的认可。 阿里巴巴于 2019 年举办了首届 ASoC，开启了中国企业在国际开源实习的新风潮，拉动了高校学生投身开源社区共建的极大热情。与受美国国家法案限制的 GSoC 不同的是，ASoC 申请人不限国籍，面向对象为全球年满 18 周岁的高校学生群体，本科生、硕士和博士研究生均可申请。只要是通过最终评估的学员，均可获得与阿里巴巴实习生同等的奖学金，并有可能获得阿里巴巴技术大神面授的机会。 （编程之夏开源项目一览） 1. 谁适合报名 脑洞巨大、想法多多、动手能力强、编程一级棒，既能仰望星空又能脚踏实地的热血青年。 2. 你将有机会获得 一笔丰厚的奖学金；一条进入阿里云的绿色招聘通道；一个具有重要价值的开源贡献者证书；一份参与国际开源基金会顶级项目的难得经历；这些收获，不仅仅是未来求职简历上浓墨重彩的一笔，更是向高阶开源贡献者晋级的闪亮起点。 （导师授予学员开源贡献者证书，阿里巴巴副总裁、阿里开源开放委员会委员长贾扬清致辞） 3. 活动流程 ASoC 活动日期为 2020 年 5 月 25 日 - 9 月 5 日，学生可以利用暑期时间参与到开源项目中，全程线上协作，无需线下参与。 05-25，查看开源项目 idea list 并提交提案；06-30，零点截止提交提案，只接收官网申请；07-07，公布入选名单，以收取确认邮件为准；07-12，项目启动，须保证每周 40 个小时的 coding 工作；08-01，项目中期评估，导师在线保驾护航；08-28，项目最终评估，综合打分多维评估；08-31，宣布最终结果，公布结业名单；09-05，结业典礼，更多惊喜。4. 报名方式 ...

发布会传送门 产品详情 云原生技术，注重用户体验，提升研发效率 环境搭建是算法研发过程中的重要一环，这里除了硬件选型外，软件环境的安装配置，后续升级往往会耗费不少时间。DSW借助阿里云ECS，Docker和Kubernetes等云原生技术，能够在2，3分钟内帮用户完成环境搭建。用户可以根据算法需要和成本考虑， 选择阿里云ECS提供的包括CPU和异构计算GPU在内的所有资源规格。不仅支持预付费，还支持后付费。 DSW还配置了10多种适用于不同AI场景的典型软件环境配置， 包括Tensorflow和PyTorch等主流训练框架的不同版本组合，供用户选择。作为高度开放的开发环境，DSW开放sudo权限给用户、支持任意第三方库安装。 为了满足不同水平层次和开发习惯的算法用户，结合可视化，交互式编程和命令行输入，DSW提供了3种编程入口：WebIde适用于工程化要求比较高的项目；JupyterLab适用于快速POC试验；Terminal入口可用于快速执行Shell命令，运行程序和简单的编辑等。 DSW还开发和预装了各种JupyterLab和WebIDE插件， 比如广受深度学习开发者喜爱的可视化工具Tensorboard，用户在DSW内通过Launcher，Commands打开，甚至还可以使用%tensorboard魔法命令直接在Notebook中开启等多种方式使用Tensorboard。不仅支持本地文件，还可以打开存放在OSS，ODPS里的训练日志。针对算法同学使用Python比较多的特点， DSW的WebIDE内安装了Python插件， 可以直接在浏览器内在线调试，单步跟踪程序运行。用户还可以根据需要，自主安装需要的任意插件。 DSW支持多种数据源读写，包括NAS， OSS，云盘和MaxCompute，尤其是内置了dswmagic魔法命令可以让用户在ipynb文件中使用SQL语句读写MaxCompute表中数据，预置的SQL编辑器支持语法高亮、智能提示、自动补全等功能，还支持运行带变量替换功能的Sql脚本。查询结果自动以最友好的图形化展示。 为了节省资源成本，用户可以利用停机不收费功能，在实例闲置不用时关机保存环境， 需要时再一键快速恢复。此外， DSW支持用户自定义镜像安装，可以基于之前保存或定制的环境创建实例。 DSW在公有云上支持了多次百队以上规模的天池大赛，在阿里集团内同样也承接着比赛，经过千锤百炼，证明不仅适合个人和团队研发，也支持大规模算法竞赛和教育培训。 安全性和稳定性是用户比较关心的问题，DSW使用的计算，存储和网络资源，完全是使用用户自己的账号购买，并部署到用户自己的vpc内部， 可以方便与用户其他数据打通。用户间完全隔离，还具备非常好的安全性。基于阿里云ECS和容器服务， 稳定性有保障。 集成PAI的各能力组件，加速业务落地 身为PAI这个大家庭的一员， DSW除了完成单机开发训练功能之外， 还内置部分PAI的基础能力。比如用户可以直接在实例内利用PAI视觉类算法包EasyVision进行图像分类训练评估、预测； 通过自动调参AutoML进行算法超参数自动调优；用户甚至能够无感知的享受PAI编译优化算法组件TAO提供的训练过程中的算子优化。最后， DSW还提供了供算法直接读取MaxCompute表数据的CommonIO组件，支持TableRecordDataSet， TableReader，TableWriter等标准接口，方便训练程序直接提交到PAI的分布式训练集群。 可以预见，在不久的将来， 会有更多的PAI算法包内置进DSW基础镜像内。 DSW也会依赖PAI SDK，围绕数据读取，加工，模型训练， 模型管理以及在线服务等AI研发生产流程的关键环节，为用户提供像Pipeline搭建，调度和管理之类的一条龙服务。

DSW 2.0：面向AI研发的集成开发平台 DSW（Data Science Workshop）是阿里巴巴PAI团队根据多年的AI算法和产品研发经验积累，围绕提高AI算法研发效率，降低研发成本而推出的一款适用于各类AI开发者的云端机器学习集成开发环境。DSW2.0是借助阿里云ECS，Docker和Kubernetes等云原生技术，能够在几分钟内帮用户完成环境搭建，相对DSW1.0开放更高的开发权限，满足各个层面客户的使用需求。 云原生架构DSW借助阿里云ECS，Docker和Kubernetes等云原生技术，能够在几分钟内帮用户完成环境搭建。用户可以根据算法需要和成本考虑，选择阿里云ECS提供的包括CPU和异构计算GPU在内的所有资源规格。 满足不同层次开发习惯结合交互式编程和命令行输入，DSW提供了三种编程入口： WebIde适用于工程化要求比较高的项目；JupyterLab适用于快速POC试验；Terminal入口可用于快速执行Shell命令，运行程序和简单的编辑等。 预装丰富插件DSW还开发和预装了各种JupyterLab和WebIDE插件，比如广受深度学习开发者喜爱的可视化工具Tensorboard，用户在DSW内通过Launcher，Commands打开，甚至还可以使用%tensorboard魔法命令直接在Notebook中开启等多种方式使用Tensorboard。不仅支持本地文件，还可以打开存放在OSS，ODPS里的训练日志。针对算法同学使用Python比较多的特点， DSW的WebIDE内安装了Python插件，可以直接在浏览器内在线调试，单步跟踪程序运行。用户还可以根据需要，自主安装需要的任意插件。 支持多种数据源读写NAS， OSS，云盘和MaxCompute，尤其是内置了dswmagic魔法命令可以让用户在ipynb文件中使用SQL语句读写MaxCompute表中数据，预置的SQL编辑器支持语法高亮、智能提示、自动补全等功能，还支持运行带变量替换功能的Sql脚本。查询结果自动以最友好的图形化展示。 Alink：流批一体机器学习算法平台 Alink拥有丰富的批式算法和流式算法，能够帮助数据分析和应用开发人员能够从数据处理、特征工程、模型训练、预测，端到端地完成整个流程。Alink提供的功能算法模块中，每一个模块都包含流式和批式算法。比如线性回归，包含批式线性回归训练，流式线性回归预测和批式线性回归预测。另外，Alink算法覆盖分类、回归、聚类、评估、统计分析、特征工程、异常检测、文本、在线学习、关联分析等经典领域，是一个通用的机器学习算法平台。 算法性能我们从下图中可以看出在回归算法中，Alink算法性能最高优于Spark 1.38倍；分类算法中Alink大多数算法性能优于Spark，最高优于2.52倍；聚类算法Alink算法性能最高优于Spark 1.85倍；协同过滤Alink算法性能最高优于Spark 2.26倍。 Flink VS Spark算法性能 更友好的交互式体验我们提供两种用户使用界面：web和PyAlink。Web界面提供拖拽的方式创建试验，通过对每一个组件进行配置完成整个试验的参数配置。在各个算法节点旁，我们用闪烁的小灯泡?表示“运行中”的状态，用对勾✅表示“运行完成”的状态。一般情况下，只有批式（batch）组件才有可能运行结束。基于各个组件的运行状态，可以十分方便地判断当前实验运行到了什么程度。 同时为了满足脚本用户的需求，我们提供了PyAlink on notebook，用户可以通过PyAlink的python包使用Alink。PyAlink支持单机运行，也支持集群提交。并且打通Operator(Alink算子)和DataFrame的接口，从而使得Alink整个算法流程无缝融入python。PyAlink也提供使用Python函数来调用UDF或者UDTF。 阿里云机器学习PAI是覆盖人工智能全链路的产品家族，自上线以来，受到广大AI开发者的喜爱，经过千锤百炼，证明不仅适合个人和团队研发，也支持大规模算法竞赛和教育培训。本次重磅发布的PAIDSW2.0和商业版Alink致力成为最懂用户的轻量化AI服务，包含数据处理、建模、训练、模型优化、在线预测等多种产品版块，为用户提供一站式体验服务。 发布会传送门 产品详情www.aliyun.com

在2020年，你的数据仓库和基础设施需要满足哪些需求？ 我们总结了几下几点： 首先，当下的企业正快速转向更实时化的模式，这要求企业具备对线上流式数据进行低延迟处理的能力，以满足实时（real-time）或近实时（near-real-time）的数据分析需求。人们对从数据产生到数据可用之间延迟的容忍度越来越低。曾经几个小时甚至几天的延误不再被接受。用户期待的是几分钟甚至几秒钟的数据端到端体验。 第二，数据基础设施需要具备同时处理线上和线下数据的能力，两种模式在实际应用中都不可或缺。除了上面提到的流处理，用户也需要批处理做即席查询（ad-hoc query）和数据挖掘。数据基础设施不应该要求用户二选一，而应该提供两个选项并且都是高质量的。 第三，数据工程师、数据科学家、分析师和运维人员都在渴望一套统一的数据技术栈，以便更轻松的使用。大数据领域的技术栈已经支离破碎很多年了，企业可能有一套流处理系统，一套批处理系统，一套线上数据分析系统。这基本都是由于当年流处理框架不够成熟而被迫采用过时的 lambda 架构造成的问题。现在不同了，流处理已成为主流，终端用户不必再学习多种技能和维护各种复杂的工具和数据处理管道（data pipeline）。用户渴望的是一套统一的简单易学易维护的方案。 如果你对以上问题深有同感，那说明这篇文章很适合你。我们来看看如何真正解决这个问题。 接下来我将带各位了解下 Flink 与 Hive 生产级别的整合工作。 Flink 与 Hive 生产级整合Flink 一直遵循“ 流优先，批是流的一个特例”的思想理念。在这一思想的指导下，Flink 将最先进的流式处理技术运用到批处理中，使得 Flink 的批处理能力一早就令人印象深刻。特别是在 Flink 1.10 中我们基本完成了从1.9开始的对 Blink planner 的整合工作后，Flink SQL 的批处理能力更上一层楼。 Hive 在大数据生态中已成为标准的数据仓库组件。它不仅仅是一个 SQL 引擎，也是一个数据管理系统。但由于自身的局限，Hive 在当下面临很大的挑战，也无法满足的用户需求。 基于此，我们从 Flink 1.9 推出了 Flink 和 Hive 整合的 beta 版本。在过去几个月中，我们基于用户的反馈，在各个方面都对产品进行了加强。我很高兴的宣布，Flink 和 Hive 的整合在 Flink 1.10 版本中能实现生产可用！ 下面来为大家介绍一些细节。 统一的元数据管理Hive Metastore 已逐渐成为 Hadoop 生态中元数据管理的中枢。很多公司都用 Hive Metastore 管理他们的 Hive 甚至非 Hive 的元数据。 ...

作者 | 许晓斌 阿里云高级技术专家 本文整理自《Serverless 技术公开课》第 1 讲，点击开始学习。 关注 “Serverless” 公众号，回复 入门 ，即可获取 Serverless 系列文章 PPT。 传统单体应用架构 十多年前主流的应用架构都是单体应用，部署形式就是一台服务器加一个数据库，在这种架构下，运维人员会小心翼翼地维护这台服务器，以保证服务的可用性。 （单体架构） 随着业务的增长，这种最简单的单体应用架构很快就面临两个问题。首先，这里只有一台服务器，如果这台服务器出现故障，例如硬件损坏，那么整个服务就会不可用；其次，业务量变大之后，一台服务器的资源很快会无法承载所有流量。 解决这两个问题最直接的方法就是在流量入口加一个负载均衡器，使单体应用同时部署到多台服务器上，这样服务器的单点问题就解决了，与此同时，这个单体应用也具备了水平伸缩的能力。 （单体架构-水平伸缩） 微服务架构 1. 微服务架构演进出通用服务 随着业务的进一步增长，更多的研发人员加入到团队中，共同在单体应用上开发特性。由于单体应用内的代码没有明确的物理边界，大家很快就会遇到各种冲突，需要人工协调，以及大量的 conflict merge 操作，研发效率直线下降。 因此大家开始把单体应用拆分成一个个可以独立开发、独立测试、独立部署的微服务应用，服务和服务之间通过 API 通讯，如 HTTP、GRPC 或者 DUBBO。基于领域驱动设计中 Bounded Context 拆分的微服务架构能够大幅提升中大型团队的研发效率。 2. 微服务架构给运维带来挑战 应用从单体架构演进到微服务架构，从物理的角度看，分布式就成了默认选项，这时应用架构师就不得不面对分布式带来的新挑战。在这个过程中，大家都会开始使用一些分布式服务和框架，例如缓存服务 Redis，配置服务 ACM，状态协调服务 ZooKeeper，消息服务 Kafka，还有通讯框架如 GRPC 或者 DUBBO，以及分布式追踪系统等。 除分布式环境带来的挑战之外，微服务架构给运维也带来新挑战。研发人员原来只需要运维一个应用，现在可能需要运维十个甚至更多的应用，这意味着安全 patch 升级、容量评估、故障诊断等事务的工作量呈现成倍增长，这时，应用分发标准、生命周期标准、观测标准、自动化弹性等能力的重要性也更加凸显。 （微服务架构） 云原生 1. 基于云产品架构 一个架构是否是云原生，就看这个架构是否是长在云上的，这是对“云原生”的简单理解。这个“长在云上”不是简单地说用云的 IaaS 层服务，比如简单的 ECS、OSS 这些基本的计算存储；而是应该理解成有没有使用云上的分布式服务，比如 Redis、Kafka 等，这些才是直接影响到业务架构的服务。微服务架构下，分布式服务是必要的，原来大家都是自己研发这样的服务，或者基于开源版本自己运维这样的服务。而到了云原生时代，业务则可以直接使用云服务。 另外两个不得不提的技术就是 Docker 和 Kubenetes，其中，前者标准化了应用分发的标准，不论是 Spring Boot 写的应用，还是 NodeJS 写的应用，都以镜像的方式分发；而后者在前者的技术上又定义了应用生命周期的标准，一个应用从启动到上线，到健康检查，再到下线，都有了统一的标准。 2. 应用生命周期托管 有了应用分发的标准和生命周期的标准，云就能提供标准化的应用托管服务。包括应用的版本管理、发布、上线后的观测、自愈等。例如对于无状态的应用来说，一个底层物理节点的故障根本不会影响到研发，因为应用托管服务基于标准化应用生命周期可以自动完成腾挪工作，在故障物理节点上将应用的容器下线，在新的物理节点上启动同等数量的应用容器。可以看出，云原生进一步释放了价值红利。 在此基础上，由于应用托管服务能够感知到应用运行期的数据，例如业务流量的并发、cpu load、内存占用等，业务就可以配置基于这些指标的伸缩规则，再由平台执行这些规则，根据业务流量的实际情况增加或者减少容器数量，这就是最基本的 auto scaling——自动伸缩。这能够帮助用户避免在业务低峰期限制资源，节省成本，提升运维效率。 本文总结 在架构的演进过程中，研发运维人员逐渐把关注点从机器上移走，希望更多地由平台系统管理机器，而不是由人去管理，这就是一个对 Serverless 的朴素理解。 作者简介 许晓斌，阿里云高级技术专家。目前负责阿里集团 Serverless 研发运维平台建设，在这之前负责 AliExpress 微服务架构、Spring Boot 框架、研发效率提升工作。《 Maven 实战》作者，曾经是 Maven 中央仓库的维护者。 【关注有礼】 关注 “Serverless” 公众号，后台回复 抽奖 ，将有机会获得“纽曼蓝牙音响”、“阿里云全自动定制雨伞”、“淘公仔”，5 月 25 日 10:00 开奖，快来试试运气吧！ ...

作者:陈戊超（仲卓） 深度学习技术在当代社会发挥的作用越来越大。目前深度学习被广泛应用于个性化推荐、商品搜索、人脸识别、机器翻译、自动驾驶等多个领域，此外还在向社会各个领域迅速渗透。 背景 当前，深度学习的应用越来越多样化，随之涌现出诸多优秀的计算框架。其中 TensorFlow，PyTorch，MXNeT 作为广泛使用的框架更是备受瞩目。在将深度学习应用于实际业务的过程中，往往需要结合数据处理相关的计算框架如：模型训练之前需要对训练数据进行加工生成训练样本，模型预测过程中需要对处理数据的一些指标进行监控等。在这样的情况下，数据处理和模型训练分别需要使用不同的计算引擎，增加了用户使用的难度。 本文将分享如何使用一套引擎搞定机器学习全流程的解决方案。 先介绍一下典型的机器学习工作流程。如图所示，整个流程包含特征工程、模型训练、离线或者是在线预测等环节。 在此过程中，无论是特征工程、模型训练还是模型预测，中间都会产生日志。需要先用数据处理引擎比如 Flink 对这些日志进行分析，然后进入特征工程。再使用深度学习的计算引擎 TensorFlow 进行模型训练和模型预测。当模型训练好了以后再用 TensorFlow serving 做在线的打分。 上述流程虽然可以跑通，但也存在一定的问题，比如： 同一个机器学习项目在做特征工程、模型训练、模型预测时需要用到 Flink 和 TensorFlow 两个计算引擎，部署相对而言更复杂。TensorFlow 在分布式的支持上还不够友好，运行过程中需要指定机器的 IP 地址和端口号；而实际生产过程经常是运行在一个调度系统上比如 Yarn，需要动态分配 IP 地址和端口号。TensorFlow 的分布式运行缺乏自动的 failover 机制。针对以上问题，我们通过结合 Flink 和 TensorFlow，将 TensorFlow 的程序跑在 Flink 集群上的这种方式来解决，整体流程如下： 特征工程用 Flink 去执行，模型训练和模型的准实时预测目标使 TensorFlow 计算引擎可以跑在 Flink 集群上。这样就可以用 Flink 一套计算引擎去支持模型训练和模型的预测，部署上更简单的同时也节约了资源。 Flink 计算简介 Flink 是一款开源大数据分布式计算引擎，在 Flink 里所有的计算都抽象成 operator，如上图所示，数据读取的节点叫 source operator，输出数据的节点叫 sink operator。source 和 sink 中间有多种多样的 Flink operator 去处理，上图的计算拓扑包含了三个 source 和两个 sink。 ...

面试，一个令人大多数同学头疼的问题，要么成功进入心仪公司，要么沮丧与其失之交臂。但是，如果能在面试前就能知道面试官将会问的问题，然后可以好好提前准备，这种感觉是不是特别棒？ 之前社区帮大家汇总了目前 15 家重量级公司的招聘需求更新在社区招聘帖，也收到了很多同学的反馈： “投了一堆简历，但是都没面试机会” “面试官说是想招高阶人才” “**哎，感觉像我这种毕业年限短， 公司又是小公司，本科也不太好的，找工作太难了**” 最后只能总结： “我不优秀，我连面试机会都没有” 也太南南南了！ 那么究竟怎么积累技术实力，成为 Flink 高级开发，拿下心仪公司的 offer 呢？小松鼠征集了 Flink 用人主管的核心诉求并提供一份超级清晰、实用的学习路径。虽然我们都不会读心术，但破解面试难题也有思路可寻！ Tips：2020 Flink 最新招聘信息查看请见下方链接，内推或有招聘需求的公司可联系小松鼠（微信ID:Ververica2019）投递 JD～ 2020 最新 Flink 招聘岗位汇总： https://juejin.im/post/5df9e25fe51d4557f5450274 01 了解用人主管的需求 在收集招聘信息时小松鼠了解到用人主管的核心需求以及面试了部分同学之后的感受，总结下来主要分为以下方面： 经验都偏少，缺乏复杂场景的历练在用 Flink 做数据开发，但没有底层修改经验想招比较高阶的对 Flink 底层有深入研究的同学，但是高阶的太难找需要有深入研究、改造经验的也可以，独立完成问题排查与任务调优请注意关键词！「复杂场景历练」、「底层修改经验」、「高阶」、「问题排查与调优」，这是当前大多数岗位对 Flink 开发同学的预期，相当于划重点呐！除了解用人主管的核心需求外，我们也需要结合自身基础，找对合适的岗位方向。 02 找对岗位方向 小松鼠总结了市面上大多数招聘内容，对这些岗位进行分析并整合，可以看到如下表格内容。总体上分为3个方向： （不完全统计，仅供参考） 众所周知，平台开发或底层引擎开发都需要对 Flink 有钻研精神，需要持续专注地深耕，对技术深度、技术原理掌握甚至是源码能力要求都较高。 相对而言，业务类的开发则更关注具体应用场景，大多是在平台的基础上进行业务场景的应用开发，对底层、源码的要求相对较低。 总体上，无论选择哪种技术方向，扎实的语言功底都是基础，而对开源社区的贡献、对 Flink 生态有深入了解等都将成为 blingbling 的加分项。 03 从小白到 Flink 高级开发，应该掌握哪些技术？ 如果你了解到自己与用人主管的核心需求存在哪些差异，或者有自己倾向的岗位方向，那么恭喜你已成功完成心理建设。第三部分，小松鼠邀请了 Apache Flink PMC 程鹤群（军长）来帮大家解决“从小白到 Flink 高级开发，应该掌握哪些技术？”这个核心问题，此处感谢 Apache Flink PMC 伍翀（云邪）的反馈与建议。 首先，送你一份 X-mind！公众号后台回复关键字「面试」，可以下载 PDF 版本～ ...

随着越来越多的企业拥抱容器、拥抱云原生技术，享受技术带来的弹性、敏捷、可移植的便利，但是在实现容器技术生产落地时，很难规避以下痛点问题： １、 运维复杂度：需要自建一个高可用的镜像服务去面对峰值流量等弹性场景，并且实时关注及时扩容；当面对全球多地域部署的场景，还要运维管理复杂的网络拓扑图。 ２、 安全风险：容器具备有高密部署、高动态、自动恢复等一些特性，会给业务安全带来极大的挑战。 ３、 生态闭环：容器镜像的托管、部署、运行时监控需要一整套的解决方案。 容器镜像服务企业版（ACR　EE）将从四个维度解决以上痛点问题： １、 云原生制品托管：提供多架构容器镜像托管支持，多版本Helm　Chart的托管；提供从源代码到标准容器镜像构建服务，也支持海外构建、智能构建、自动化构建、多阶段构建等构建能力。 ２、 多维度安全保障：提供制品加密存储；支持镜像安全扫描，多维度扫描保障镜像内容安全；此外提供镜像加签能力，保障整个镜像分发链路上的安全可信；细粒度网络访问控制管理，保障公网和VPC端网络下的访问安全。 ３、 加速应用分发：覆盖在全球主要地域、提供多种同步策略和网络链路优化，保障镜像分发的高效、稳定、安全；单集群、多节点的场景下支持多种大规模分发。 ４、 提效应用交付：DevSecOps全面升级；提供云原生交付链的能力，支持全链路可观测、可追踪、可设置；多种策略支持，保障安全交付。 企业版( ACR EE)，是解决云原生应用制品安全托管与高效分发的最热方案，目前众多行业 Top 企业已在大规模使用。 选择容器镜像企业版（ACR　EE），享受容器技术带来的便利的同时，轻松规避容器技术生产落地伴随的问题。活动期间新购享9.5折优惠，续费享9折优惠哟～(包年直享8.5折优惠) 产品购买传送门：https://www.aliyun.com/product/acr 优惠直享链接：https://common-buy.aliyun.com/?commodityCode=acr_ee_public_cn 了解更多 ：https://help.aliyun.com/document_detail/60945.html

作为一名云运维工程师，在攻克OSS的道路上难免会遇到"天花板"。放轻松，《OSS运维基础实战手册》帮你轻松解决！本书透彻解析OSS核心概念，十二心法打开全新运维视角，力求帮助云运维工程师们打破能力上升瓶颈。 本书兼顾理论与实践，通过讲授运维实战十二心法，以更加直观，具体的方式帮助读者快速上手，带领读者在本书中领略作者的缜密思路，并学会用这种思路来应对各种不期而遇的OSS难题。 《OSS运维基础实战手册》的作者，阿里云工程师韩笠，具有多年对象存储运维以及 SDK 开发经验，目前专注存储，SDK 调优领域。 点此下载电子书 本书秉承直观透彻、循序渐进、基础知识与案例实践紧密结合的讲授特色，手把手指导读者从零开始轻松入门OSS。 目录 1.OSS的五个核心优势 阿里云对象存储服务（Object Storage Service，简称 OSS），OSS 具有与平台无关的 RESTful API 接口，可以在任何应用、任何时间、任何地点存储和访问任意类型的数据。本次电子书的第一章节就带大家揭秘oss的五个核心优势，快速入门oss。 2.简单易用，API 调配全掌握 OSS 支持 RESTFUL API 形式调用，基本上服务端控制台上的功能配置，都可以通过 API 完成配置操作。也可以通过 OpenAPI 对文件进行集群的管理，结果用户访问控制台（RAM policy）加强客户的安全屏蔽，文中对支持的API进行整合，轻松掌握API 调配。 3.6个基础名词带你入门OSS 掌握这六个产品名词， oss问题无处可藏 4.实操前须知的10项使用限制 了解实操前须知的10项使用限制，精准快速上手OSS 5.两大经典错误场景的镜像回溯 OSS 回源功能，也称镜像回源，本章节介绍两种主要功能，一种是 404 回源，另外是重定向回源 6.学会自动刷新配置，解决几十万用户存储问题 阅读本章节内容，教你在保证 CDN 缓存下的文件在原站（OSS）更新的情况下自动更新的方法。 7.5个场景全面了解跨域配置 经常遇到有跨域的问题，老生长谈，却又屡禁不止，谈到跨域我们就了解下它是什么？ 8.不同场景下的OSS 事件通知功能实现 通过自定义关注的Object信息，第一时间掌握不同场景下的OSS 事件通知 9.如何兼得bucket policy简单易操作和精细权限粒度 本章节带你走近了解bucket policy ，揭秘其简单易操作和精细权限粒度的真相。 10.低价高效！OSS如何处理视频 媒体处理（ApsaraVideo Media Processing，原MTS）是一种多媒体数据处理服务。它以经济、弹性和高可扩展的音视频转换方法，帮助您将存储于OSS的音视频转码成适合在PC、TV以及移动终端上播放的格式。本章节分享OSS处理视频的秘诀。 11.动静分离——实现全站加速 全站加速（DCDN） 与 OSS 是常见的站点动静分离的方式，可以实现将静态资源存储在 OSS 上，并通过 DCDN 加速 OSS 实现静态资源的访问加速效果。如果是动态业务，可以通过最短路由上传回传； ...

简介 在今年2月初，SLS 已经发布针对新冠病毒肺炎疫情国内动态展示分析 APP，目前该能力全面开放给政府、社区、第三方平台和开放者进行广泛应用，完全免费开放。还没有关注过的同学可以通过以下链接了解背景： 新冠病毒疫情分析 APP 官方文档云栖博文、直播最近，随着新冠病毒肺炎疫情在全球爆发，SLS 又推出了跟踪关注全球范围疫情动态的分析大盘。与国内大盘主要关注国内疫情（数据来源于央视新闻、人民日报、各省市卫健委公告）相比，国际疫情大盘则是跟踪关注全球范围的疫情动态，数据来源是被国际上广泛引用的约翰·霍普金斯大学开源数据集。 SLS 阿里云日志服务（SLS）是针对日志类数据的一站式服务，无需开发就能快捷完成海量日志数据的采集、消费、投递以及查询分析等功能，提升运维、运营效率。日志服务主要包括实时采集与消费、数据投递、查询与实时分析等功能，适用于从实时监控到数据仓库的各种开发、运维、运营与安全场景。 作为日志分析中台，日志服务提供了一站式的数据采集、加工、查询分析、AI计算、可视化，并支持互联互通。 亮点 1. 提供规整的疫情数据，并每天定时同步更新 SLS 已经将疫情相关数据进行收集和规整，每天定时更新，并形成可视化平台覆盖全球各个国家/地区、省份/州的疫情信息。你只需要专注在数据的分析和展示，其它繁琐的细节 SLS 都已经处理好。 2. 预定义丰富数据大盘、并支持自定义 内置多份数据大盘并支持自定义提供全球各个国家/地区、省份/州疫情态势。支持交互式查询分析、自定义报表、深钻与告警等。 全球疫情态势概览 各国家/地区的疫情详情 3. 数据平台开放，互联互通 数据平台开放，互联互通日志服务是开放的，可以和大量其他环境的系统、三方应用或开源进行对接。提供易扩展的数据分析、存储、可视化平台能力，如DataV、Blink、OSS、流计算、Grafana、SOC等。 4. 完全免费 完全免费疫情服务应用以及相关资源数据，包括仪表盘、告警等功能完全免费。 数据 导入和规整 可能有一些同学只关注对 COVID-19 疫情的数据分析，也想要上手试一试，但是对于如何从各个数据源获取并处理数据不了解，又或者对 SLS 的 SQL 不是很熟练。为了帮助这部分同学方便快捷的实现数据分析，SLS 已经将疫情相关数据进行收集和规整，并且每天定时更新。你只需要专注在数据的分析和展示，其它繁琐的细节 SLS 都已经处理好。 数据样例 type: Country/Region Casesversion: v2020-04-17T11:55:36Last Update: 2020-04-09 01:12:20Country/Region: ChinaCountry/Region (ch): 中国LatLng: 35.000074,104.999927Confirmed: 83798Confirmed Hist: [644, 923, 1409, 2079, 2882]Confirmed Trend: {"2020-01-23": 644, "2020-01-24": 923, "2020-01-25": 1409, "2020-01-26": 2079, "2020-01-27": 2882}New Confirmed Hist: [95, 279, 486, 670, 803]New Confirmed Trend: {"2020-01-23": 95, "2020-01-24": 279, "2020-01-25": 486, "2020-01-26": 670, "2020-01-27": 803}Deaths: 3352Deaths Hist: [18, 26, 42, 56, 82]Deaths Trend: {"2020-01-23": 18, "2020-01-24": 26, "2020-01-25": 42, "2020-01-26": 56, "2020-01-27": 82}Recovered: 78556Recovered Hist: [30, 36, 39, 49, 58]Recovered Trend: {"2020-01-23": 30, "2020-01-24": 36, "2020-01-25": 39, "2020-01-26": 49, "2020-01-27": 58} ...

“每个人的时间都是有限的，在有限的时间里选择一项值得投入的技术会变得尤为重要。” 笔者从 2008 年开始工作到现在也有 12 个年头了，一路走来都在和数据打交道，做过很多大数据底层框架内核的开发（Hadoop，Pig，Hive，Tez，Spark），也做过多年上层数据计算框架（Livy, Zeppelin）以及数据应用开发，包括数据处理，数据分析以及机器学习。现在是 Apache Member 以及多个 Apache 项目的 PMC 。2018 年加入阿里巴巴实时计算团队专注在 Flink 的研发。 今天我想结合自己过去的职业经历来聊聊如何评估一项技术是否值得学习。我一直在大数据这个圈子，从最初的 Hadoop 到后来的 Hadoop 生态项目 Pig，Hive，Tez，然后又到新一代的计算引擎 Spark ，再到最近在做的 Flink ，大数据计算引擎贯穿我的整个职业生涯。我个人来说是比较幸运的，在每个阶段都在做比较火的技术，当时更多的是凭着自己的兴趣和直觉在选择技术类型。现在回过头来看我觉得需要从下面 3 个大的纬度来评估一项技术是否值得学习。 1、技术深度 2、生态广度 3、进化能力 01 技术深度 技术深度是指这项技术的根基是否扎实，护城河是否够宽够深，是否很容易被其他技术所替代。通俗的来说就是这项技术是否解决了其他技术所不能解决的有重要价值的问题。这里有两个要点： 1、这个问题没有人能解，是这项技术首先解决了这个问题。 2、解决这个问题能够带来重大价值。 拿我职业生涯开始阶段学习的 Hadoop 为例。当时 Hadoop 刚出来的时候是一项革命性的技术，因为当时除了 Google 宣称自己内部有一套 GFS 和 MapReduce 系统外，业界其他公司都没有一套完整的海量数据解决方案。而随着互联网技术的发展，数据量与日俱增，处理海量数据的能力迫在眉睫。Hadoop 的诞生正好解决了这一燃眉之急。 随着技术的发展， Hadoop 的处理海量数据能力的优势慢慢被人习惯，相反 Hadoop 存在的缺陷被人不断诟病（性能差，MapReduce 编写复杂等等）。而这时候Spark应运而生，解决了 Hadoop MapReduce 计算引擎的顽疾。Spark 远超过 Hadoop 的计算性能以及极其优雅简单的 API 迎合了当时用户的需求，受到了广大大数据工程师的热捧。 现在我在阿里巴巴从事的是关于 Flink 的研发工作，主要原因是我看到了工业界对实时性的需求以及 Flink 在实时计算这个领域的霸主地位。之前大数据遇到的最大挑战在于数据规模大（所以大家会称之为“大数据”），经过工业界多年的努力和实践，规模大这个问题基本已经解决了。接下来几年，更大的挑战在于速度，也就是实时性。而大数据的实时性并不是指简单的传输数据或者处理数据的实时性，而是从端到端的实时，任何一个步骤速度慢了，就影响整个大数据系统的实时性。 在 Flink 看来， Everything is stream 。Flink 的以 Stream 为核心的架构是业界独一无二的，由此而产生的性能优越，高扩展性，端到端 Exactly Once 等特性，更是使得 Flink 在流计算领域是当之无愧的王者。 目前主流的流计算引擎有 3 个：Flink、Storm 和 SparkStreaming 。 ...

网络安全态势严峻，常见的五大网络攻击风险类型赵伟认为，企业线上服务所面临的安全风险，主要来自以下五个方面： DDoS攻击DDoS攻击类型已有20多年历史，它攻击方式简单直接，通过伪造报文直接拥塞企业上联带宽。随着IoT等终端设备增多，网络攻击量也愈发凶猛。根据阿里云安全中心报告显示，在2019年，超过100G的攻击已经比较常见，而且超过 500G 的攻击也已经成为常态。一旦企业服务面临这种情况，上联带宽被打满，正常请求无法承接，就会导致企业服务无法正常提供线上服务。因此，防御DDoS 攻击依然是企业首先要投入去应对的问题。 CC攻击相比于四层DDoS攻击伪造报文，CC攻击通过向受害的服务器发送大量请求来耗尽服务器的资源宝库CPU、内存等。常见的方式是访问需要服务器进行数据库查询的相关请求，这种情况想服务器负载以及资源消耗会很快飙升，导致服务器响应变慢甚至不可用。 Web攻击常见的 Web 攻击包括SQL 注入、跨站脚本攻击XSS、跨站请求伪造CSRF等。与DDoS和CC以大量报文发起的攻击相比，Web 攻击主要是利用 Web 设计的漏洞达到攻击的目标。一旦攻击行为实施成功，要么网站的数据库内容泄露，或者网页被挂马。数据库内容泄露严重影响企业的数据安全，网页被挂马会影响企业网站的安全形象以及被搜索引擎降权等。 恶意爬虫根据阿里云安全中心的报告数据显示，2019年，恶意爬虫在房产、交通、游戏、电商、资讯论坛等几个行业中的占比都超过50%。恶意爬虫通过去爬取网站核心的内容，比如电商的价格信息等，对信息进行窃取，同时也加重服务器的负担。 劫持篡改劫持和篡改比较常见，当网站被第三方劫持后，流量会被引流到其他网站上，导致网站的用户访问流量减少，用户流失。同时，对于传媒、政务网站来说，内容被篡改会引发极大的政策风险。 企业线上业务需要构建多层次纵深防护面对愈发严峻的网络安全态势，为了应对以上安全风险，企业在关注线上业务的流畅、稳定的同时，也要构建多层次纵深防护体系，从各个层面建立响应的应对措施和防护机制。 在网络层，需要进行DDoS攻击的清洗和处理，当造成更严重影响需要通过切换IP以及联合黑洞机制去缓解。在传输层，相较于传统明文传输，通过https的支持去进行传输层面加密，来避免证书伪造。在应用层，需要进行CC防护、防爬、业务防刷的能力部署，防止恶意攻击者刷带宽的情况发生，避免经济和业务损失。贴近源站的防护方面，需要部署WAF和防篡改，对源站和内容进行防护。 企业需要在网络层、传输层、应用层等多层次构建防护能力，同时在应用层，对于不同场景要有不同防护措施。 基于CDN构建边缘安全+高防中心防护安全架构基于对纵深防护的理解，阿里云CDN的安全架构是基于CDN分布式节点实现的边缘安全防护机制，同时联动高防清洗中心进行防护。 如下图所示，整体安全架构第一层防护就是构建在全球CDN节点上，将更多安全能力加强在边缘节点上，通过多层次多维度流量数据统计和攻击检测的能力，包括DDoS、HTTP访问信息等数据汇总到安全大脑，安全大脑再对数据进行综合分析，针对不同层次的攻击下发相应的动态防御策略到边缘节点。与此同时，边缘节点自身也会进行自动防御和清洗。另外，整体安全架构将WAF和防篡改能力部署在回源节点上，对攻击到达源站之前进行防御。如果源站希望只在CDN服务之下，不想暴露在公网上，整体架构也会基于CDN提供源站高级防护能力，避免源站被恶意扫描者被发现。 对于金融、政府等场景，需要具备大流量抗D的能力，CDN有海量边缘节点通过自己的调度和清洗能力把大部分DDoS攻击给消化掉。当一旦出现更严重的DDoS攻击时，安全大脑会指导智能调度，将被攻击的流量切换到高级防护节点去清洗。 阿里云CDN安全架构三个核心能力在以上的CDN安全架构基础之上，赵伟也对DDoS防护智能调度、Web防护以及机器流量管理三个核心能力进行解读。 一、DDoS防护智能调度：边缘节点分布式抗D与高防中心大流量抗D联动 DDoS防护智能调度的策略是，业务流量缺省通过CDN分发，最大程度确保加速效果和用户体验，而当检测到大流量 DDoS 攻击之后，智能调度会判断严重程度并决策由高防进行 DDoS清洗，同时根据攻击情况进行区域调度或全局调度，而当DDoS 攻击停止后，智能调度系统会自动决策将高防服务的业务流量调度回 CDN 边缘节点，尽最大可能的保证正常加速效果。 DDoS防护智能调度最核心就是边缘加速、智能调度、T级防护三块，边缘加速的基础上具备充分的DDoS攻击检测以及智能调度的能力，决策什么时候进行高防去清洗，严重的攻击进入T级防护中心进行清洗。目前方案已经在金融行业、传媒行业沉淀了典型客户。 二、Web防护——八层安全功能，层层过滤恶意请求 Web防护的策略是通过层层过滤，来抵御恶意请求。第一层是精准访问控制，指具体对http请求的拦截策略；第二层是区域封禁，对业务无效区或者异常地域请求进行拦截；第三层IP信誉系统，是利用阿里云多年积累的互联网IP大数据画像，对恶意行为进行分类并对IP进行拦截；第四层是黑名单系统，是对某些UA或者IP进行拦截，以上四层都属于精确拦截；第五层是频次控制，对相对高频且访问异常IP进行拦截；第六层是对于互联网机器流量进行管理，阻断恶意爬虫；第七第八层是WAF和源站高级防护，对于源站进行更深层次的防护。 赵伟认为：CDN边缘节点是最接近互联网用户的，在所有的访问请求中，可能有正常用户的请求，当然也会存在爬虫、注入、跨站的访问请求，经过以上逐层的防护策略，过滤掉相应恶意请求，最终可以达到只有正常请求返回源站的效果。 三、机器流量管理——识别互联网Bot流量，阻断恶意爬虫 机器流量管理部署在边缘，当各种互联网访问进入CDN边缘节点之后，机器流量管理系统会提取最原始的Client信息，分析信息计算Client特征值，并与阿里云安全积累的机器流量特征库进行匹配，最终识别结果，正常访问、搜索引擎、商业爬虫这些行为是网站期望的行为，会被放行，而恶意爬虫会被拦截。在处置动作上，机器流量管理相比当前常见嵌入在正常页面中的行为，侵入性有所降低，支持相对平滑的接入。 下图是一个实际的案例，在执行机器流量管理策略的时候，首先会对某域名进行流量分析，左侧图是针对某域名开启机器流量分析后，识别出超过 82% 的请求为恶意爬虫，然后开启拦截机器流量中的恶意爬虫流量后，如右侧图所示，域名峰值带宽下降超过80%。 CDN目前已经是互联网流量的主要入口，把安全能力注入CDN边缘节点，为客户提供一站式安全加速解决方案成为行业大势所趋。在发布会的最后，赵伟分享到：未来，阿里云政企安全加速解决方案将在场景化、便捷化、智能化三个方面深耕，为客户提供更贴近需求的、更快捷省心的、更智能高效的安全策略，让CDN可以成为每个企业在线服务的第一道防线，来保障企业应用的安全、稳定运行。 点击回顾发布会详情 活动福利： 2020年6月30日前，CDN加速10Mbps以内带宽免费试用1个月，30Gbps DDoS防护、高级版WAF试用1周，并赠送一次漏洞扫描服务，总名额限100个，先到先得。 点击填写表单参与活动 答疑钉钉群：34249460

5月初B站一位UP主资料泄露，并在知乎引起广泛的讨论，蒲公英也参与了一下，提出可以用NAS备份，结果惨遭质疑：人家就用的NAS还被泄露，那组建NAS有什么用？ 经过深入分析，这个锅NAS不背，其中另有隐情！ NAS被攻击的原因 首先经过专业人士分析，NAS被攻击存在两种情况： 第一种情况 计算机已经被病毒感染，或者病毒已经入侵内网。那攻击NAS里的文件轻而易举。 第二种情况 NAS服务器开启了暴露在外网的功能，黑客通过外网攻击勒索。 对于第一种情况，只能说做好备份或者不要点击陌生的链接、软件等。而今天就谈谈第二种多数NAS被攻击的原因。 暴露在公网的危害 黑客从外网怎么攻击NAS？一般是通过端口。 如果说IP代表具体某台电脑，那端口就是访问该电脑各种服务的入口，而防火墙就是门卫，不让病毒轻而易举的进门！ 比如2017年永恒之蓝爆发，通过samba协议文件共享的445端口进行传播，当时给出的方法就是关闭对应端口，或者通过防火墙阻断对应端口的流量。 而上面B站UP主的NAS直接放在了公网上，并且开启了windows远程桌面的3389端口，而且使用了弱密码，刚上线的第一天就被攻破。所以这并不是说NAS不安全！ 常见的解决方案 组建虚拟专用网 跨公网搭建一条加密隧道，使两端局域网互通就可以了。因为跨越公网的隧道是加密的，这个隧道的安全性就能得到保障。 这样，从公司访问家里的nas资源就相当于局域网访问。家里的nas在公网没有暴露危险端口，这样也能保证nas在公网的安全了，但是操作起来复杂。 比如用蒲公英把两个不同的区域的设备组在一个局域网里，这样等于组建了一个内网，访问起来非常方便。

作者 | 冬岛  阿里巴巴技术专家 导读：托管 Knative 开箱即用，您不需要为这些常驻实例付出任何成本。结合 SLB 云产品提供 Gateway 的能力以及基于突发性能型实例的保留规格功能，极大的节省您的 IaaS 开支，您支付的每一分钱都没有浪费。<关注阿里巴巴云原生公众号，回复 报告 即可下载完整调查报告> CNCF 发布的年度调查报告显示 2019 年 Serverless 技术进一步获得了更大的认可。其中 41% 的受访者表示已经在使用 Serverless，另外 20% 的受访者表示计划在未来 12-18 个月内会采用 Serverless 技术。而在众多开源的 Serverless 项目中 Knative 是最受欢迎的一个。如下图所示， Knative 占据了 34% 的份额，遥遥领先于第二名 OpenFaaS，Knative 是自己搭建 Serverless 平台的首选。 Knative 之所以这么受欢迎和容器的生态不无关系。和 FaaS 模式不同的是 Knative 不要求用户对应用做非常大的改造，只要用户的应用完成了容器化就能部署在 Knative 中。并且 Knative 在 Kubernetes 之上提供了更聚焦的应用模型，让用户无需为应用的升级、流量灰度花费精力，这一切都是自动完成的。 云主机的发展历程在云计算出现之前，企业想要在互联网上对外提供服务需要先在 IDC 租赁物理机，然后再把应用部署在 IDC 的物理机上。而物理机的性能在过去十几年里始终保持着摩尔定律的速度在增长。这就导致单个应用根本无法充分利用整个物理机的资源。所以就需要有一种技术解决资源利用率的问题。简单的想如果一个应用不够就多部署几个。但在同一个物理机下多个应用混合部署会带来很多问题，比如： 端口冲突资源隔离系统依赖以及运维困难虚拟机的出现就很好的解决了上述问题，通过虚拟机技术可以在同一个物理机上虚拟出多个主机，每一个主机只部署一个应用，这样一台物理机不但可以部署多个应用，还能保证应用之间的独立性。 随着企业的发展，一家企业可能会维护很多应用。而每一个应用需要很多的发布、升级、回滚等操作，同时这些应用可能还需要在不同的地域分别部署一套。这就带来了很多运维负担，这些运维难题首当其冲的就是应用的运行环境。所以后来出现了容器技术，容器技术通过内核级别的轻量级隔离能力不但具备与 VM 几乎同等的隔离体验，还带来了一个巨大的创新就是容器镜像。通过容器镜像可以非常容易的复制应用的运行环境，开发人员只需要把应用的依赖都做到镜像中，当镜像运行的时候直接使用自带的依赖提供服务。这就解决了应用发布、升级和回滚以及多地域部署等过程中的运行环境问题。 当人们开始大规模使用容器技术之后发现大大减轻了维护实例运行环境的负担，此时最大的问题就是应用多实例的协调以及多个应用之间的协调。所以容器技术普及不久 Kubernetes 就出现了，和以往的 VM、容器技术不同，Kubernetes 天然就是一个分布式面向终态的设计，不是单机上的能力。Kubernetes 对 IaaS 的资源分配抽象了更友好的 API，用户无需关心具体的分配细节，Kubernetes Controller 会根据面向终态的生命自动完成分配和故障转移以及负载均衡等。这使得应用开发人员无需关心具体的实例是运行在哪里，只要在需要的时候 Kubernetes 能够分配出资源即可。 ...

技术编辑：芒果果丨发自 思否编辑部SegmentFault 思否报道丨公众号：SegmentFault 来自澳大利亚 Monash、Swinburne 和 RMIT 大学的一组研究人员称，他们已经使用一种名为微梳的光学芯片成功测试并记录了世界上最快的 44.2 Tbps 互联网数据速度。 这项发现发表在《自然通讯》杂志上，揭示了数据速度如何支持墨尔本 180 万个家庭的高速互联网连接，用户可以在几秒钟内下载 1000 部高清电影。 新型光学芯片体积更小，可替代 80 台 红外激光器研究人员称，微梳被称为比现有电信硬件更小、更轻的设备，可以代替 80 台红外激光器，并在对国家宽带网络所用网络进行镜像的基础设施中进行了负载测试。 研究人员将微梳放在 RMIT 墨尔本市校区和 Monash 大学 Clayton 校区之间 76.6 公里的暗光纤中。微梳用于模仿彩虹状的红外激光，因此每个“激光”都具有用作单独通信通道的能力。 为了模拟测试期间的互联网使用高峰，研究人员通过 4THz 带宽的每个通道发送了最大的数据。 地下光纤或成网络通信骨干能力，可支持远程通信该研究的首席作者  Monash 大学电气和计算机系统工程讲师 Bill Corcoran 认为，这项研究证明，地下光纤将成为现在和将来通信网络的骨干能力。他说：“我们已经开发了可扩展以满足未来需求的产品。我们在这里谈论的不仅是 Netflix，还包括我们使用其通信网络的更广泛的规模。这些数据可用于自动驾驶汽车和未来的交通运输，并可帮助医药，教育，金融和电子商务行业，以及使我们能够与几公里外的孙子们一起阅读。” RMIT 的 Arnan Mitchell 表示，该项目的未来目标是在不增加大小、重量或成本的前提下，将当前的发送器从每秒数百 GB 扩展到每秒数十 TB。他说：“从长远来看，我们希望制造出集成的光子芯片，从而能够以最小的成本在现有的光纤链路上实现这种数据速率。” 澳大利亚其他能源替代研究其他研究方面，悉尼大学的科学家测试了如何提高钙钛矿太阳能电池的热稳定性，使其有可能被用作硅基太阳能电池的替代品。 实验中使用的某些钙钛矿细胞的样品。 悉尼大学纳米科学系主任 John Hooke 表示：“钙钛矿是太阳能系统的一个非常有希望的前景。它们非常便宜，比硅薄 500 倍，因此具有柔韧性和超轻量。它们还具有巨大的能量使能特性和较高的太阳能转化率。” 科学家使用带有压力密封的聚合物玻璃毯来抑制钙钛矿细胞的分解，这一过程称为除气。 悉尼大学纳米科学主席 Ho-Baillie 说：“这一过程，称为’除气’，是我们开发该技术并提高其耐用性的工作的中心部分。我一直对探索如何将钙钛矿太阳能电池结合到隔热玻璃（例如真空玻璃）中感兴趣。因此，我们需要了解这些材料的除气性能。” 该测试还能够确定钙钛矿太阳能电池是否能够在相对湿度为 85％ 的情况下以及在 -40 度至 85 度之间的温度下进行 75 次循环后能否存活超过 1800 小时。 ...

有不少读者反馈，参考上篇文章《Hive 终于等来了 Flink》部署 Flink 并集成 Hive 时，出现一些 bug 以及兼容性等问题。虽已等来，却未可用。所以笔者增加了这一篇文章，作为姊妹篇。 回顾 在上篇文章中，笔者使用的 CDH 版本为 5.16.2，其中 Hive 版本为 1.1.0（CDH 5.x 系列 Hive 版本都不高于 1.1.0，是不是不可理解），Flink 源代码本身对 Hive 1.1.0 版本兼容性不好，存在不少问题。为了兼容目前版本，笔者基于 CDH 5.16.2 环境，对 Flink 代码进行了修改，重新打包并部署。 其实经过很多开源项目的实战，比如 Apache Atlas，Apache Spark 等，Hive 1.2.x 和 Hive 1.1.x 在大部分情况下，替换一些 Jar 包，是可以解决兼容性的问题。对于笔者的环境来说，可以使用 Hive 1.2.1 版本的一些 Jar 包来代替 Hive 1.1.0 版本的 Jar 包。在本篇文章的开始部分，笔者会解决这个问题，然后再补充上篇文章缺少的实战内容。 剪不断理还乱的问题 根据读者的反馈，笔者将所有的问题总结为三类： Flink 如何连接 Hive 除了 API 外，有没有类似 spark-sql 命令识别不到 Hadoop 环境或配置文件找不到依赖包、类或方法找不到1. Flink 如何连接 Hive 有的读者不太清楚，如何配置 Flink 连接 Hive 的 Catalog，这里补充一个完整的 conf/sql-client-hive.yaml 示例： catalogs: - name: staginghive type: hive hive-conf-dir: /etc/hive/conf hive-version: 1.2.1 execution: planner: blink type: batch time-characteristic: event-time periodic-watermarks-interval: 200 result-mode: table max-table-result-rows: 1000000 parallelism: 1 max-parallelism: 128 min-idle-state-retention: 0 max-idle-state-retention: 0 current-catalog: staginghive current-database: ssb restart-strategy: type: fallback deployment: response-timeout: 5000 gateway-address: "" gateway-port: 0 m: yarn-cluster yn: 2 ys: 5 yjm: 1024 ytm: 2048 sql-client-hive.yaml 配置文件里面包含： ...

文章将从云计算基建、大数据基建、数据构建、数据管理、数据应用5个角度，阐述数据架构师的必备技能和素养。 云计算基建 传统的IT架构已存在几十年，随着企业业务的快速发展，对于业务的可用性要求越来越高，对于成本的压力也越来大。是否存在一种方式能以更低成本、更高性能和可用性的方式支持新时代的企业信息化要求？ 部分互联网公司由于自身业务快速发展的原因，做了大量尝试。阿里巴巴率先发起的“去IOE运动”：将IBM机器替换成云上服务器，将ORACLE数据库替换成云上数据库，将EMC存储替换成云上存储服务器。带来的不仅仅是成本的降低，同时也提供了更加稳定、安全的环境。云计算作为信息时代的水、电、煤已成为行业共识。随着云计算的兴起，企业全面上云的拐点已到。作为一名合格的数据架构师，对云计算基础设施需要有充分的理解。 首先，相较于传统的服务器，架构师需要了解云上是如何实现稳定、弹性、安全、成本、易用、扩展的云上服务器的。还包括如何实现物理资源的虚拟化，如何通过弹性伸缩从容面对业务的峰谷，如何通过多地域多可用区实现容灾等。另外，数据架构师需要能评估服务器所需资源类型，通过技术调研和论证，得出所需要的服务器的资源，例如面对不同的业务和技术场景，企业需要的是紧凑型、通用型、均衡型、内存型、独享型哪种类型的服务器。其次，网络同样也是数据架构师必须掌握的基础知识，如何设计安全的网络机制、如何规划合理的网络配置、如何进行可靠的网络连接（包括不同虚拟网络之间以及与客户本地IDC进行连接方式等），都是数据架构师在工作中会遇到的各种挑战。最后，数据架构师需要了解各种云上数据库（包括关系型数据库、NoSQL数据库等）的应用场景、产品特性等。以及如何保障其可靠性，安全性、可用性、扩展性、成本。另外还有对象存储产品的特性，如何对视频、图片等数据进行有效的管理。如何通过CDN等手段提高用户访问响应速度。大数据基建 大数据借着云计算的东风，也开始在信息时代发挥越来越重要的地位。阿里巴巴提出的数据中台概念和实践，也在云上落地开花。面对体量巨大、时效要求高、形式多样化、价值密度低的企业大数据，对于数据架构师，需要在采集、计算、存储等基础技术的原理和应用场景形成自己的知识体系。 首先，数据架构师需要了解业界通用的PC端和无线端采集、爬虫采集等场景的具体方案。理解从埋点申请、可视化埋点实施、验证、发布到监控的全生命周期管理。其次，对于离线计算和实时计算的模式和原理，以及对应场景的离线计算和实时计算的产品都应该熟悉掌握，在洞察客户需求后，能合理的做计算模式的选择和判断。最后，大数据在存储上与业务系统在场景和目标上的本质区别，需要理解如HDFS的大数据存储原理、MPP架构的原理和常用场景、消息中间件用于实时计算的方式等。数据构建 数据架构师很重要的职责就是思考如何对数据做合理有效的构建，形成标准、统一、可公用、可理解的公共数据，让业务能够尽情在建设好的数据上驰骋沙场，利用数据创造出业务价值。 首先，好的数据体系能够对数据进行有效的横向分层，合理的纵向分类。通过数据体系的构建，能够让数据生产者更合理高效的组织数据，数据消费者能更有效的理解和获取所需数据，数据管理者能更高效的管理好数据。因此数据架构师需要能从全局上对数据体系有个整体上长远的规划。其次，数据需要能够被更好的组织和使用还需要有合理的数据建模方法论的支撑，例如基于维度建模的数据构建方式能够让数据以事实表和维度表的方式的方式向上提供数据服务，并且预先通过基于分析对象的汇总数据能够提供统一标准的业务指标定义。数据架构师需要有理解业务、抽象实体、形成模型的知识体系，并且在遇到问题时能从合理性、可扩展性、易用性、可理解性等各种角度给出模型设计的合理解决方案。最后，就算数据架构师不需要做代码开发，可是这个能力是对数据架构师最基本的要求，只有充分理解了数据加工的整个过程，才能基于数据的思维去设计好数据体系。在碰到项目开发同学遇到数据处理问题时，能够及时提供有效的帮助，对于建立项目中的信任关系也起到了关键的作用。数据管理 数据质量是数据能被信任的关键，也是数据中台建设能否成功的关键。因此数据架构师需要设计事前、事中和事后的数据质量检测和处理机制，保证数据在完整性、准确性、及时性、一致性上满足业务的要求。 数据架构师还需要保证数据治理能够形成有效的闭环，从发现治理问题、推送给责任人、引导治理动作、治理效果评估、到下一次进行新的治理问题发现，根本上杜绝数据“有人生、没人养”的困局。就像环境治理一样，只有基于体系化的长效机制才能还我们绿水青山。 数据是一把双刃剑，因为它在给业务带来价值的同时，数据安全的问题是另一把可致企业于死地的利剑。数据架构师要对数据安全规划做在最前头，从数据产生到消亡全生命周期进行安全制度和流程的规划，同时需要通过如差分隐私、保序脱敏等各种技术手段保障数据安全。 数据只有让业务充分使用才能产生价值，因此首先数据架构师需要思考如何提高数据的易用性，包括从数据的业务视角组织形式、数据标准口径的定义方式、基于元数据帮助业务理解数据等方式。再次，数据是有成本的，因此需要能够更好的衡量数据带来的价值，形成数据资产ROI，再配合相应的数据运营手段，才能让数据资产化和价值化互相促进发展，相爱相生。 数据应用 数据架构师需要能够让数据更好的服务业务，但是应抛弃疲于奔命于各种跑数取数的深渊中，需要能跳出一个个单点的需求，能更全面的思考如何主动服务业务。 首先，数据架构师需要有很强的业务理解能力，对客户的业务能基于行业视角有清晰的理解，并且能基于理解做进一步的抽象，抽象出业务的本质。其次，数据架构师能从业务方的需求、对业务和数据的理解沉淀出一系列的分析思路。也需要能通过算法结合数据，思考如何进行数据的深度挖掘，挖掘出高价值数据。最终能将思路和方法通过产品化的方式沉淀，主动服务业务，与业务共创数据价值。最后，数据的本质是为了赋能商业、创造商业，因此数据架构师需要有一定的商业思维，能理解数据如何使商业更加智能，如何驱动商业的发展，如何创造新的商业形态。总结 技术到业务，方法论到产品化，全局规划到细节把控，数据架构师需要在大数据的方方面面都承担起重要的作用。更重要的是，需要有对大数据行业未来的信心、对职业发展方向的恒心、对漫长落地过程的耐心、对赋能商业的热心。 阿里巴巴数据中台团队，致力于输出阿里云数据智能的最佳实践，助力每个企业建设自己的数据中台，进而共同实现新时代下的智能商业！ 阿里巴巴数据中台解决方案，核心产品： Dataphin，以阿里巴巴大数据核心方法论OneData为内核驱动，提供一站式数据构建与管理能力；Quick BI，集阿里巴巴数据分析经验沉淀，提供一站式数据分析与展现能力；Quick Audience，集阿里巴巴消费者洞察及营销经验，提供一站式人群圈选、洞察及营销投放能力，连接阿里巴巴商业，实现用户增长。

【以下为分享实录，有删节】 Git工作流概述及AGit-Flow的优势 目前，Git已成为源代码管理的标准和基础设施。“为什么Git能这么成功”？Git的创建者Linux在Git十周年的一次采访中，道出了其中的奥秘： The big thing about distributed source control is that it makes one of the main issues with SCM’s go away – the politics around “who can make changes.” 他认为Git能成功最关键的不是因为它更快、更安全，也不是因为Git是分布式的，而是解决了“到底谁能够贡献代码”这个问题。传统的集中式版本控制系统只能针对核心用户开放写授权，长期来看这对项目做大、做强是不利的。而Git改变了传统版本控制系统不能够让跟多开发者贡献代码这个顽疾，让“只读用户”也可以通过“代码评审”的方式参与到项目开发中。 当前业界有两种最常用Git 工作流：GitHub和Gerrit。他们都具备仓库的授权模型简单，只读用户可参与代码贡献的特点。 如上图所示，我对这两种GIT工作流做了优劣势分析： ** 代码评审模式不同：** GitHub 的代码评审称为 “pull request”，每个特性改动生成一次代码评审。 Gerrit 的代码评审称为 “Change”，每个提交生都会生成一个“变更单”，这个变更单就是一次代码评审。 工作流类型不同： GitHub 的工作流属于分布式，当开发者需要参与项目的时候，虽然没有“写”的权限，但是可以通过“Fork”的方式创建一个个人仓库（派生仓库），他就可以在这个派生仓库中去创建代码分支，创建pull request。GitHub 底层采用的是原生的 Git（即 CGit）。 Gerrit 的工作流是集中式，所有用户工作在统一管控的集中式仓库中。Gerrit 要求用户在本地克隆仓库中安装一个 “commit-msg” 钩子，以便在生成的提交中插入唯一的“Change-Id”，向服务器推送要使用特殊的 git push 命令。Gerrit 采用的是 JGit（Java 的 Git 实现）。 ...

政企网络化、在线化面临哪些挑战？ 政企涵盖了政府、金融、传媒以及传统企业等几个行业，随着“互联网+”业态的迅速发展，政企数字化转型正当时，特别是在新冠疫情的影响下，各行各业线上业务运营能力的建设步伐进一步加快，架构网络化与业务在线化已经成为政企不可或缺的能力。 具体到各个业务场景中，在政务领域，国家大力推进网上业务来实现数字化治理，向公众提供流畅、稳定的在线服务，以增强其服务水平和效率，提升公众满意度；在金融行业，网上银行、手机支付、移动证券、网上营业厅等新兴的金融类应用在飞速发展，更多的交易、认证、审核等业务流程在互联网上完成；在广电传媒领域，依托带宽提速以及近年来区县融媒体业务的发展，基于互联网的广电新媒体、融媒体在产业中的地位日益提升，互联网上的访问体验以及安全性越发关键；在传统企业领域，借助数字化转型实现能效提升的过程，将经历数字化、网络化、智能化这几个阶段，其中网络化进程中的设备互联、业务联网上云、企业在线营销及服务等场景，成为了传统企业的首要任务。 与此同时，我国对网络安全的监管也在持续不断地加强，且非常强调自主可控，特别是关键信息基础设施（指面向互联网、面向公众提供网络信息服务或者支撑通信、金融、交通、公用事业等重要行业的信息系统或工业控制系统），对国家安全、经济安全、社会稳定、公众健康和安全至关重要。4月27日，由网信办、工信部，中国人民银行，广电总局，国密局、密码局等12个部委，联合制定了《网络安全审查办法》，对党政机关业务系统、网上金融、传媒新闻网站、企事业单位网站和办公系统等关键信息基础设施的网络安全审查提出了进一步明确的安全监管要求，值得政企行业高度重视。 综上所述，在政企行业面对的核心挑战是：既要在线开放，又要流畅稳定，还要安全合规。如何帮助政企行业更好地满足安全和加速两方面的需求，确保互联网之上的传输安全和用户访问体验，这也是云计算从业者们格外关注和需要解决的问题。 政企安全加速解决方案的整体架构 阿里云本次发布的政企安全加速解决方案是兼顾了加速、安全与合规的一站式解决方案。其集成了静态加速、全站加速，包括四层IP应用加速和七层WebSocket加速等能力，可以全面提升用户访问效率，同时，集成了边缘WAF、DDoS攻击防护、分布式CC攻击防护等安全能力，在传输安全层面支持国密算法https安全机制，可以有效帮助政府、传媒等领域提升防篡改、防爬虫能力，规避相应内容安全风险。 政企安全加速解决方案在安全合规、稳定极速和省力省心三个维度赋能政企客户。首先，凭借上述安全能力帮助客户抵挡来自互联网的恶意攻击，保障业务可用性不受损，确保内容和数据的安全，同时丰富、全面的安全特性也可以帮助客户去满足高规格的等保合规要求；其次，依托阿里云CDN在资源、技术的储备以及多年沉淀的最佳实践，可以为政企行业的用户提供稳定极速的访问体验。第三，解决方案也为政企行业构建了专业的服务队伍，团队具备多个国家部委、大型股份制银行、央媒等大型项目的最佳实践经验，可以提供日常服务、应急响应、重大活动护航以及多重安全保障支撑。同时，产品方案无需部署设备，通过API和控制台快速接入应用系统，技术对接十分简单便捷。 政企安全加速解决方案的应用场景及行业价值 场景一：政务类平台政企安全加速解决方案服务于各类政务门户、电子政务、一网通办等应用，以及党建学习类、在线教育类平台，帮助其缓解95%以上网络流量压力，有效屏蔽用户激增带来的访问瓶颈问题，并对源站进行隐藏和保护。同时，基于国密算法https实现传输链路层加密，有效防劫持、防篡改，保护网站内容安全。此外，通过UA/IP黑白名单/Refer防盗链，以及DRM数字版权管理等安全机制，多维度防止视频盗播，保护优质版权内容不受侵害。 场景二：金融在金融领域，银行、证券、保险机构的门户网站、手机app以及交易认证审核、金融双录、内部培训等业务场景下，有着严格的等保合规要求，SSL证书及国密要求较高，政企安全加速解决方案提供端到端的国密https传输加密解决方案，包括keyless、双证书、IPv6等在等保合规中要求比较明确的安全特性。同时，解决方案基于DDoS/CC防护以及边缘WAF，帮助金融机构应对网络攻击，保证业务安全稳定不中断。此外，解决方案集成全站加速，基于七层/四层加速有效提高交易成功率至 99.9%，缩短交易时长30%以上，优化金融企业跨国以及大规模交易、访问下的用户体验。 场景三：广电传媒在广电传媒领域，广电新媒体平台、地方传媒以及区县融媒应用中普遍面临着https普及率不高、内容篡改风险、版权视频的盗播盗链、视频流畅率等技术挑战，政企安全加速解决方案通过国密https传输加密有效防止劫持和篡改，同时基于UA/IP黑白名单/Refer防盗链，以及DRM数字版权管理等安全机制，确保优质版权内容不被盗播盗链。 场景四：企业办公传统企业的业务场景，如零售、车企、能源、航空等行业，其在线化可以分为企业内部在线办公以及外部面向客户的各种服务、应用这两个部分。政企安全加速解决方案可以基于全站加速，七层/四层加速来支持跨区域、跨运营商的系统协同和API加速，改善平台访问体验。同时，在安全方面，解决方案中集成的边缘WAF能力，可以有效实现防爬虫、防刷、WEB系统入侵的防护，避免因企业网站被爬、平台被刷而导致的核心数据泄露，确保企业数据及源站的安全。 阿里云政企安全加速解决方案已经广泛应用于政务平台、网上银行、零售、航空等领域之中，帮助客户满足合规性、安全性以及用户访问体验的要求，赋能线上业务以极速、安全、可靠地互联网体验，助力更多政企抓住数字化发展机遇，在数字化转型中获得先机。 点击回顾发布会详情 活动福利： 2020年6月30日前，CDN加速10Mbps以内带宽免费试用1个月，30Gbps DDoS防护、高级版WAF试用1周，并赠送一次漏洞扫描服务，总名额限100个，先到先得。 点击填写表单参与活动 答疑钉钉群：34249460