存储

通用数据保护条例(GDPR)是当今技术世界中的重要法规，也是泛滥在亚马逊云科技私有云当中建设解决方案的用户们所必须遵循的数据处理要求。GDPR中提出一项“删除权”，或者叫“被忘记权”条款，要求通过施行相干解决方案保障删除特定用户的集体数据。 在亚马逊云科技大数据与剖析生态系统的背景之下，每一套架构，无论其面向怎么的指标，都须要应用Amazon Simple Storage Service(Amazon S3)作为外围存储服务。只管Amazon S3领有丰盛的性能选项与完整性，但却短少一种开箱即用的机制将用户标识符同蕴含用户数据的Amazon S3对象映射起来。 在本文中，咱们将介绍一套框架，帮忙革除您组织中的亚马逊云科技托管数据湖内的各特定用户数据。此外，咱们还将独特理解一套由多种不同亚马逊云科技存储层形成的剖析解决方案，以及针对Amazon S3的示例代码。 Amazon Simple Storage Servicehttps://aws.amazon.com/cn/s3/   想要理解更多数据湖仓的相干常识？敬请关注亚马逊云科技中国峰会北京站的大数据与智能湖仓分论坛！更多最新技术公布和实际翻新的内容尽在8.19-20北京、9.15深圳分会，快来点击图片报名吧～ 参考架构为了解决数据革除框架施行中的种种挑战，咱们在这里将问题简化为一个简略用例，即如何在应用亚马逊云科技作为数据管道的平台当中实现用户数据删除。下图阐明了用例的根本状况。 咱们引入了建设并保护索引元存储库的想法，该存储库可能跟踪每位用户的记录地位，帮忙咱们高效找出这些地位，从而放大搜寻空间。 您能够应用以下架构，在组织的亚马逊云科技数据湖内删除特定用户的数据。 对于此初始版本，咱们创立了三个用户流，这些用户流负责将各项任务与适合的亚马逊云科技服务映射起来： 用户流1：实时元数据存储更新 Amazon S3 ObjectCreated或ObjectDelete事件会触发一项Amazon Lambda函数，此函数将解析对象并执行增加/更新/删除操作，以使元数据索引放弃最新。您也能够为任意其余存储层建设相似的简略工作流，具体包含Amazon Relational Database Service(RDS),Amazon Aurora或Amazon Elasticsearch Service(ES)。在本示例中，咱们应用Amazon DynamoDB与Amazon RDS for PostgreSQL作为索引元数据存储选项，这里应用的具体方法宽泛实用于其余技术场景。 Amazon Relational Database Servicehttps://aws.amazon.com/cn/rds/Amazon Aurorahttps://aws.amazon.com/cn/rds...Amazon Elasticsearch Servicehttps://aws.amazon.com/cn/ela...Amazon DynamoDBhttps://aws.amazon.com/cn/dyn...Amazon RDS for PostgreSQLhttps://aws.amazon.com/cn/rds...用户流2：革除数据 当用户要求删除其数据时，咱们会通过Amazon CloudWatch触发一个Amazon Step Functions状态机来协调工作流。第一步是触发Lambda函数，由该函数查问元数据以辨认出蕴含用户记录的存储层，并将生成的报告保留在Amazon S3报告存储桶内。接下来，由基于Lambda Node JS的工作节点创立并获取Amazon Step Functions流动，并通过Amazon Simple Email Service(SES)将带有批准及回绝链接的电子邮件发送给审核人员。 Amazon Simple Email Servicehttps://aws.amazon.com/cn/ses/下图所示为亚马逊云科技管理控制台上显示的Amazon Step Functions状态机根本架构。 审核人员从两条链接中抉择其一，而后调用Amazon API Gateway端点，由该端点调用Amazon Step Functions以复原工作流。如果抉择批准链接，则Amazon Step Functions将触发一项Lambda函数，此函数将存储桶内的报告作为输出，据此删除存储层内的对象或记录，而后更新索引元存储库。在革除作业实现之后，Amazon Simple Notification Service(SNS)会向用户发送操作胜利或失败的告诉邮件。 ...

Amazon Elastic File System (Amazon EFS)为跨Amazon Elastic Compute Cloud (EC2)实例，以及Amazon Elastic Container Service (ECS), Amazon Elastic Kubernetes Service (EKS), Amazon Fargate与Amazon Lambda等容器与无服务器服务提供一套简略、全托管的弹性数据共享文件系统。以后，客户可能利用Amazon EFS Standard存储类，通过多个地理位置互相独立的可用区取得具备最高可用性与持久性的冗余数据存储服务。 Amazon Elastic File System(Amazon EFS)https://aws.amazon.com/cn/efs/Amazon Elastic Compute Cloud(EC2)https://aws.amazon.com/ec2/Amazon Elastic Container Service(ECS)https://aws.amazon.com/ecs/Amazon Elastic Kubernetes Service(EKS)https://aws.amazon.com/cn/eks/Amazon Fargatehttps://aws.amazon.com/cn/far...Amazon Lambdahttps://aws.amazon.com/cn/lam...近期，咱们很快乐发表Amazon EFS One Zone存储类与以往的Amazon EFS Standard存储类相比，One Zone将存储老本升高达47%。以美国东部(北弗吉尼亚州)区域为例，假设您应用的数据中有80%具备肯定生命周期且拜访频率较低，则客户的理论每GB每月存储老本为0.043美元。Amazon EFS设计反对11个9(即99.999999999%)的数据持久性，Amazon EFS One Zone反对3个9(99.9%)的可用性SLA，同时放弃与Amazon EFS Standard存储类雷同的弹性、简略性、可扩展性以及生命周期治理等性能个性。 想要理解更多亚马逊云科技最新技术公布和实际翻新，敬请关注在上海、北京、深圳三地举办的2021亚马逊云科技中国峰会！点击图片报名吧～ 咱们此次推出的是两种新的可用区存储类——其一为Amazon EFS One Zone，在美国东部(北弗吉尼亚州)区域的每GB每月存储老本为0.16美元；其二为Amazon EFS One Zone-Infrequent Access(One Zone-IA)，在美国东部(北弗吉尼亚州)区域的每GB每月存储老本为0.0133美元。应用One Zone存储类的所有文件系统，都能够应用Amazon Backup配置主动备份策略，由此提供更高级别的数据保护能力；此外，由Amazon EFS控制台创立的文件系统还默认具备生命周期管理策略，可能以主动且通明的形式将拜访频率较低的文件挪动至Amazon EFS One Zone-IA存储类。通过配合生命周期治理，用户可能将低拜访频率数据的存储老本升高达92%。 ...

Amazon SageMaker 是一种齐全托管的端到端机器学习服务，数据科研人员、开发人员和机器学习专家能够疾速、大规模地构建、训练和托管机器学习模型。这极大地推动了您所有的机器学习工作，让您可能将机器学习技术迅速融入生产应用程序。Amazon SageMaker的次要工作组件包含：算法编写、模型训练、模型评估、模型托管等。 模型训练是机器学习工作流程中至关重要的一步，而为模型训练提供灵便、高效、精确的输出数据则间接决定了训练后果品质。通常，模型训练的工作不是欲速不达，而是一个动静调整，循序渐进的过程，须要重复调整以及多个部门和工作流程的合作实现。 本文中，咱们以机器学习中的图像分类算法为例，介绍典型的机器学习模型训练的输出数据筹备过程： 为了满足机器学习图像分类算法对训练和验证数据量的要求，咱们会保护一个微小的图片仓库，外面寄存着几万甚至更多的分类图片文件。数据筹备团队每天都会往仓库中减少新获取的图片文件并实现分类。同时，因为一些起因（比方，发现之前的分类谬误或者弃用一些类别），咱们也会对仓库中的图片文件进行批改或删除。 在理论的机器学习训练任务中，为了管制训练任务的工夫和规模，咱们会依据模型应用的场景，选取残缺仓库中的局部数据或者一个子集来组成训练数据集和验证数据集。 不同格局输出数据的应用差别Amazon SageMaker 的训练任务反对两种输出模式：管道模式和文件模式。 以管道模式运行训练任务的时候，训练实例不会将数据齐全下载到本地后才运行，训练实例按需从指定的管道中读取训练数据。管道模式能够减速训练实例启动和开始训练的过程，尤其是当训练数据量十分大，比方超过16TB的时候，训练实例的本地磁盘无奈承载全量的运行数据时，必须要应用管道模式能力进行训练。 接下去，咱们次要看一下Amazon SageMaker训练任务的文件模式输出，训练任务文件模式下目前反对的数据源包含：Amazon S3、Amazon EFS和Amzon FSx for Lustre 。不同的数据输出源以通道的模式提供给训练实例作为输出数据，一个训练实例能够最多配置20个不同的输出源通道，不同的通道能够应用不同的数据源类型。 咱们应用Amazon SageMaker提供的内置图像分类算法进行图像分类模型的训练，内置算法能够接管两种数据格式，一种是RecordIO格局，另一种是图片文件，对于如何解决数据到RecordIO格局能够参考MXNet的官网文档。以下咱们重点介绍图片文件的输出形式： 图像分类算法承受4个输出通道：train, validation, train_lst, validation_lst 别离对应训练数据集，验证数据集，训练数据集列表文件，验证数据集列表文件， 数据集和数据集列表文件在格局、存储模式和应用行为上有很大的差别。 数据集自身是图片文件，以某种模式的目录构造寄存，比方：按工夫、按类别、按部门等。图片文件一经生成后文件内容就固定下来，能够作为一个整体被读取，替换或删除。不同训练任务中，从图片仓库中选取局部图片组成训练数据集，同一个图片文件可能在不同的训练任务中被多次重复应用到。 数据集列表文件是一个以.lst为扩展名，文件外部以制表符(tab)作为宰割，为数据集里的图片文件提供索引信息。 一个典型的.lst索引文件格式如下： 15      1   your_image_directory/train_img_dog1.jpg231000   0   your_image_directory/train_img_cat1.jpg4522     1   your_image_directory/train_img_dog2.jpg第一列是图像文件的惟一索引号；第二列代表图像类别对应的数字号(从0开始)，比方0代表猫，1代表狗；第三列是文件门路包含了文件绝对目录和文件名。 数据集列表文件须要依据每次训练任务的实用场景生成，可能频繁被读取和批改，包含： 屡次递进的训练任务中须要向列表文件中增加更多的图片文件索引记录；因为发现分类信息谬误，须要批改局部行的信息；因为图片仓库的批改，须要替换局部行的信息；多个lst文件之间须要频繁进行diff，通过比拟输出数据的差别来确认对训练输入模型的影响；类规定扭转，原有分类细化分支或者合并到新的分类；须要在团队之间共享合作，实现对同一个.lst文件内容的确认和创立；其余一些场景。以图片模式的保留的图片仓库适宜以对象造成存储于Amazon S3上，当然，如果您心愿防止重复从Amazon S3下载大量的图片数据，或者现有的一些辅助工具是基于POSIX文件系统接口开发的，那么，Amazon EFS或Amazon FSx for Lustre同样能够提供一个简便、高效的数据长久化存储来构建您的图片仓库。 对列表文件.lst来说，须要频繁创立和批改，并可能须要联合工作流程，在多个成员之间合作的状况下实现最终文件内容的确定。因而列表文件.lst 适宜保留在具备POSIX接口的共享文件系统上，包含Amazon EFS和Amazon FSx for Lustre。当然您也能够应用S3来保留.lst文件，但思考到在文件块级别批改和读取上的便捷性以及文件分享简便性来说，在POSIX反对的共享文件系统上间接应用.lst文件的工作流程还是会更简便一些。 如何配置输出通道和数据源对于输出通道的具体配置，您能够在Amazon SageMaker控制台的训练任务创立过程中通过集成界面来具体指定： 以下是 S3作为输出通道数据源的配置： 以下是 EFS作为输出通道数据源的配置： 以下是应用 Amazon FSx for Lustre作为输出通道数据源的配置： 如果您应用编程的形式来创立和提交Amazon SageMaker的训练任务，您能够应用以下的API来构建不同的输出数据源： 1from sagemaker.inputs import FileSystemInput2from sagemaker.inputs import TrainingInput34content_type = 'application/x-image'567fs_train = FileSystemInput(file_system_id='fs-c0de3680',8                                    file_system_type='EFS',9                                    directory_path='/caltech/256_ObjectCategories',10                                    content_type=content_type,   11                                    file_system_access_mode='ro')12fs_validation = FileSystemInput(file_system_id='fs-c0de3680',13                                    file_system_type='EFS',14                                    directory_path='/caltech/256_ObjectCategories',15                                    content_type=content_type,16                                    file_system_access_mode='ro')1718fs_train_lst = TrainingInput(s3train_lst, content_type=content_type)1920fs_validation_lst = FileSystemInput(file_system_id='fs-0cd42e47a9d3be5e1',21                                    file_system_type='FSxLustre',22                                    directory_path='/k4jhtbmv/image-classification/validation_lst',23                                    content_type=content_type,24                                    file_system_access_mode='ro')252627data_channels = {'train': fs_train, 'validation': fs_validation, 28                 'train_lst': fs_train_lst, 'validation_lst':fs_validation_lst}在以上的代码例子中训练集和验证集都以文件对象模式存储于Amazon S3上。思考到lst文件的应用特点，将用于训练集的.lst列表文件寄存于EFS上，将用户验证集的.lst列表文件寄存于Amazon FSx for Lustre上。 ...

在 2020 年亚马逊云科技Re: Invent 大会上，咱们预览了 Amazon EBS io2 Block Express 卷，这为下一代服务器存储架构提供了首个专为云构建的 SAN。Amazon EBS io2 Block Express 旨在满足 Microsoft SQL Server、Oracle、SAP HANA 和 SAS Analytics on Amazon 规模最大、I/O 密集度最高、工作要害型部署的要求。预览了 Amazon EBS io2 Block Express 卷https://aws.amazon.com/blogs/... 想要理解更多亚马逊云科技最新技!术公布和实际翻新，敬请关注 2021亚马逊云科技中国峰会！点击图片报名吧～近期，亚马逊云科技非常高兴地发表正式推出 Amazon EBS io2 Block Express 卷，其中 Amazon EC2 R5b 实例由 Amazon Nitro 零碎提供反对，在 Amazon EC2 上具备最佳网络附加存储性能。 Amazon EBS io2 Block Express 卷当初还反对 io2 性能，例如多挂载卷和弹性卷。 R5b 实例https://aws.amazon.com/blogs/... Amazon Nitro 零碎https://aws.amazon.com/jp/ec2... 多挂载卷https://aws.amazon.com/blogs/...弹性卷https://aws.amazon.com/blogs/... 过来，客户必须将多个卷作为条带联合在一起能力超过单卷性能。而当初，Amazon EBS io2 卷能够满足工作要害型、性能密集型应用程序的需要，无需条带化，节俭了治理开销。借助 Amazon EBS io2 Block Express，客户能够收费在云中取得最高性能的数据块存储，同时吞吐量、IOPS 和容量比具备亚毫秒级提早的 Amazon EBS io2 卷高出四倍。 ...

作为开发人员，常常要提供各种尺寸的图像，以确保不同屏幕尺寸和分辨率的设施都有杰出的拜访体验。这样对于图片的治理就会变得非常复杂。存储在S3上的图片常常会被解决成各种尺寸，以适应网站和APP。 本文将论述一种形式，当设施拜访S3上图片的时候，会生成一张适当尺寸的图片返回设施。 理论在2017年时，亚马逊云科技公布了一个解决方案——Serverless Image Handler https://aws.amazon.com/soluti... 这个计划利用Lambda和API Gateway动静的生成的缩略图。本文所实现的性能与Serverless Image Handler完全一致，但本文利用了新公布的Graviton2机型，在领有海量工作负载且变动平缓的前提下，能够达到对老本大幅度优化。能够从下表看出Serverless Image Handler与Graviton2解决缩略图所实用的不同场景： 本解决方案劣势灵便地解决图片：只需在URL中增加须要生成的图片尺寸，即可动静生成，并且借助Graviton2降级的浮点运算性能，能够更加疾速地对图片进行解决。 优化老本：仅当一张图片须要扭转其尺寸时，才会触发并疾速生成。这样能够尽可能地节约存储空间。并且利用Graviton2解决图片，比雷同规格的Intel芯片EC2实例便宜20%。 高可靠性：本计划利用了CloudFront的Origin Group性能，确保了拜访S3对象不会呈现404的状况。并且利用Auto Scaling Group，使解决图片的Graviton2 EC2实例也放弃高可靠性。 架构概览 如果用户通过APP拜访一张原始图片，会先申请这张原始的图片的缩略图，这样能够更快加载图片。这个申请被转发至CloudFront。CloudFront有Origin Group的性能，这个性能能够让一个CloudFront散发有两个源站，如果第一个源站返回400或500，CloudFront散发会把申请转发给设定的第二个源站。利用CloudFront的Origin Group性能，咱们让S3存储桶成为第一个源站，当申请的缩略图没有找到，CloudFront会把申请转发给咱们设置的第二个源站：一个Auto Scaling Group Gravition2集群，这个集群会提取URL中信息,URL里提供的bucket名称和原始图片名称以及须要批改成的长宽，从S3存储桶找到原始图片，而后把缩图略返回并且保留回S3存储桶。 1.用户申请原始图片thumber-test.example.com/test.jpg的300像素乘以300像素缩略图，这个缩略图的URL为thumber-test.example.com/test.jpg/thumb_300_300.jpg 2.通过CloudFront散发的Origin Group，将申请转发至第一个源站S3存储桶。 3.如果缩略图S3:// thumber-test/test.jpg/thumb_300_300.jpg存在，则间接返回，整个流程完结。如果缩略图不存在，则S3存储桶返回400。 4.因为S3存储桶返回的是400，依据CloudFront Origin Group的设定，将申请转发给第二个源站：一个Auto Scaling Group Gravition2集群。 5.Gravition2集群上的应用程序对申请URL进行剖析，提取原始图片名称jpg，以及缩略图尺寸300 X 300。从S3存储桶下载原始图片S3://thumber-test/test.jpg，并对其进行尺寸批改。 6.程序在名为thumber-test 的S3存储桶中创立文件夹：“jpg/”，将缩略图thumb_300_300.jpg上传至其中。 7.同时也返回给CloudFront缩略图文件。 8.CloudFront将文件返回至用户。 部署指南1.首先咱们参考这篇blog： https://aws.amazon.com/cn/blo... 其中2.1、2.2和2.3，搭建一个基于Gravition2 EC2实例的php运行环境。如果用于生产，能够搭建一个Auto Scaling Group，但搭建ASG并不是本文重点，所以仅以单台EC2实例为例。 2.将https://github.com/nwcd-sampl... 文件放入EC2实例上的/usr/share/nginx/html/目录，并且设置为默认首页。 3.创立一个名为thumber-test的S3存储桶，在“备用域名(CNAMEs)”填入一个二级域名，并且确保子域名与S3存储桶名称统一，如：thumber-test.example.com，并上传图片jpg至存储桶。 4.关上CloudFront服务，创立一个基于thumber-test存储桶的调配。而后点击进入刚创立的调配，抉择“源和源组”，点击“创立源”，在“源域名”中填入新创建的Gravition2 EC2实例的域名。 1.在雷同页面，抉择“源组”中的“创立源组”，顺次增加S3存储桶源和EC2实例源。并在“故障转移条件”中勾选404与403。 2.在标签栏抉择“行为”，抉择默认行为，点击“编辑”，在“源或源组”处抉择刚创立的源组ID，而后保留。 3.将二级域名thumber-test.example.com的CNAME指向散发的域名。 4.此时能够进行验证，在浏览器输出https:// thumber-test.example.com/test.jpg/thumb_300_300，会返回一张长宽为300像素的图片。进入名为thumber-test的S3存储桶，能够看到多了一个名为“jpg/”的文件夹，外面有一文件名为thumb_300_300。像素尺寸能够依据需要自在批改。 论断部署实现后，咱们应用同样大小机型，c6g.large、c5.large、c5a.large，模仿客户生产环境中进行测试，测试数据集由10%的5M以下，20%的20M以上图，以及70%的5M到20M大小图片组成。通过测试能够失去以下后果（因为可能理论零碎参数、数据集等细节不同，会造成最终测试后果不同，所以隐去了测试后果具体数值）： 能够看出，c6g.large在同样大小的机型中，运行php批改图片大小程序性能最好，价格最低。并且c6g还有尺寸更小的实例，能够利用c6g实例搭建auto scaling group，其弹性粒度比另外两种实例更佳。 本篇作者 ...

客户在应用EC2过程中，难免会碰到诸如根卷损坏或操作系统配置谬误，导致无奈连贯和登录的状况。这会减少日常迁徙、重建等繁冗的工作。尤其是客户在采纳了存储优化实例(如i3、i3en、d2等)下，自建的服务下（如Hadoop、Kafka），数据失落、拷贝等老本会十分高。 这些在实例存储上低廉的数据复制操作、繁冗的迁徙重建等工作，往往是客户无奈接受的。当初依靠Amazon ReplaceRootVolume新个性，将帮忙客户解决上述问题，轻松应答呈现的各种挑战。 Amazon ReplaceRootVolume新个性简介ReplaceRootVolume是一个新个性，它容许客户替换EC2实例的EBS根卷，同时保留实例存储数据、网络和IAM配置。当实例因为启动卷问题而无法访问时，能够防止失落、复制实例存储数据。在保留实例存储数据的同时，能够将根卷还原为以前的快照。 ReplaceRootVolume性能的应用十分便捷、疾速，无需简单的操作，上面一起来具体看看在d2机型上（其余机型是雷同操作），如何配置和应用该性能。 Amazon ReplaceRootVolume配置目前最新版的Amazon Cli曾经反对ReplaceRootVolume相干操作的命令，所以第一步须要将Amazon Cli降级到最新的版本，具体介绍能够参考官网文档： https://docs.aws.amazon.com/z... 在Amazon Cli降级实现后，即能够开始应用ReplaceRootVolume创立工作了。 创立复原工作通过create-replace-root-volume-task命令，能够将实例的EBS根卷替换为最初一个已知的良好快照或启动状态。Create-replace-root-volume-task命令的输出包含instance-id和snapshot-id。Instance-id是必须的字段，snapshot-id是可选的。如果没有提供快照id，那么实例根卷将还原到其启动状态。 *如果根卷在创立了快照后，请至多保留一个快照文件，以作为复原点。 上面的命令将实例 i-055c4533f35830923的根卷，复原到其启动状态。 aws ec2 create-replace-root-volume-task [--region 实例所在区域] [--instance-id <实例ID>] 上面的命令将实例 i-055c4533f35830923的根卷，复原到指定快照状态。 aws ec2 create-replace-root-volume-task [--region 实例所在区域] [--instance-id <实例ID>] [-snapshot-id <快照ID> ] 在执行复原工作后，会看到如下输入： 查问工作执行状态： 在执行完上述命令后，能够通过如下命令查看当前任务的状态： aws ec2 describe-replace-root-volume-tasks –region “实例所在区域” –replace-root-volume-task-ids “执行完工作后输入中的TaskId” –filters Name=instance-id,Values=“实例ID”,“实例ID” 能够看到工作执行的状况 查看复原前后的各项信息，确认合乎预期 复原实现后的工作在复原实现后，首先须要查看复原的版本是否为预期版本。 而后将实例存储从新挂载到对应挂载点（如复原的零碎版本已配置主动挂载，则无需手动挂载）。 查看实例存储中的数据是否合乎预期。 应用控制台执行复原工作下面介绍了如果应用命令行来执行ReplaceRootVolume操作，该操作同样也能在控制台便捷的执行。 通过在控制台中选取须要执行的EC2，在存储信息中，找到替换根卷。 进入替换性能页面后，抉择快照ID，即可创立根卷复原工作。 在EC2的存储信息栏中，能够看到当前任务的状态。 通过上述ReplaceRootVolume的操作方法和新的个性，简略替换根卷后，即能够高效、便捷、轻松的解决实例无奈登陆、实例存储数据失落危险和迁徙老本低等问题。 本篇作者 邱萌 亚马逊云科技解决方案架构师 负责基于亚马逊云科技计划架构的征询和设计，推广亚马逊云科技平台技术和解决方案。在退出亚马逊云科技之前，曾在企业上云、互联网娱乐、媒体等行业耕耘多年，对私有云业务和架构有很深的了解。 吴金福 亚马逊云科技混合云计划架构师 负责基于亚马逊云科技的混合云计划架构的征询和设计。在退出亚马逊云科技之前，就任于大型团体企业。负责公有云数据中心的方案设计和建设，在数据中心基础设施、虚拟化、高性能计算和混合云等畛域有着多年的教训积攒。

Amazon Timestream 是一种疾速、可扩大的无服务器工夫序列数据库服务，实用于物联网和经营应用程序，应用该服务每天能够轻松存储和剖析数万亿个事件，速度进步了 1000 倍，而老本仅为关系数据库的十分之一。通过将近期数据保留在内存中，并依据用户定义的策略将历史数据移至老本优化的存储层，Amazon Timestream 为客户节俭了治理工夫序列数据生命周期的工夫和老本。Amazon Timestream 专门构建的查问引擎可用于拜访和剖析近期数据和历史数据，而无需在查问中显示指定数据是保留在内存中还是老本优化层中。Amazon Timestream 内置了工夫序列剖析函数，能够实现近乎实时地辨认数据的趋势和模式。Amazon Timestream 是无服务器服务，可主动缩放以调整容量和性能，因而无需治理底层基础设施，能够专一于构建应用程序。 本文介绍通过Timestream、Kinesis Stream托管服务和Grafana 和Flink Connector开源软件实现物联网（以PM 2.5场景为示例）时序数据实时采集、存储和剖析，其中蕴含部署架构、环境部署、数据采集、数据存储和剖析，心愿当您有类似物联网时序数据存储和剖析需要的时候，能从中取得启发，助力业务倒退。 架构Amazon Timestream 可能应用内置的剖析函数（如平滑、近似和插值）疾速剖析物联网应用程序生成的工夫序列数据。例如，智能家居设施制造商能够应用 Amazon Timestream 从设施传感器收集静止或温度数据，进行插值以辨认没有静止的工夫范畴，并揭示消费者采取措施（例如缩小热量）以节约能源。 本文物联网（以PM 2.5场景为示例），实现PM2.5数据实时采集、时序数据存储和实时剖析， 其中架构次要分成三大部分： 实时时序数据采集：通过Python数据采集程序联合Kinesis Stream和Kinesis Data Analytics for Apache Flink connector 模仿实现从PM 2.5监控设施, 将数据实时采集数据到Timestream。 时序数据存储：通过Amazon Timestream时序数据库实现时序数据存储，设定内存和磁性存储（老本优化层）存储时长，能够实现近期数据保留在内存中，并依据用户定义的策略将历史数据移至老本优化的存储层。 实时时序数据分析：通过Grafana （装置Timesteam For Grafana插件）实时拜访Timestream数据，通过Grafana丰盛的剖析图表模式，联合Amazon Timestream 内置的工夫序列剖析函数，能够实现近乎实时地辨认物联网数据的趋势和模式。 具体的架构图如下： 部署环境1.1 创立Cloudformation 请应用本人帐号 (region请抉择 us-east-1) 下载Cloudformation Yaml文件： https://bigdata-bingbing.s3-a... 其它都抉择缺省， 点击Create Stack button. Cloud Formation 创立胜利 1.2 连贯到新建的Ec2堡垒机: 批改证书文件权限 chmod 0600 [path to downloaded .pem file] ...

MRAM速度快且非易失性。实时监控的传感器数据能够实时写入，无需负载平衡或ECC开销。AEC-Q1001级合格MRAM将在发动机罩下利用的扩大温度（-40℃至125℃）内保留数据20年。意外断电不会影响数据完整性。 Everspin的汽车规AEC-Q100MRAM内存可用于赛车静止超级自行车的发动机管制单元，在每次较量之前的试运行中，燃油喷射、点火、制动和减速的传感器数据都会被测量并记录在MRAM中。依据这些数据，发动机管制单元(ECU)能够对自行车进行微调，使其在当天的个别骑手、特定赛道和确切较量条件下以最佳性能运行。 对于发动机管制单元中的要害数据存储应用Everspin的并口mram 4Mb存储器。用于AEC-Q1001级认证选项，被认为足够坚硬，能够在摩托车较量中遇到的十分高的温度环境中运行，速度足够快，能够在较量期间实时读取或写入数据，但始终是非不稳固，即便在较量期间意外断电。 Everspin的MRAM技术在极其温度范畴内十分持重牢靠，非常适合汽车市场对内存产品的要求。Everspin致力于汽车市场，提供一系列合乎AEC-Q100规范的产品。涵盖了该市场要求的各个方面。代理商英尚微电子反对提供样品测试及产品利用解决方案。

32位单片机为用户提供了丰盛的抉择，可实用于工业管制、智能家电、修建安防、医疗设施以及消费类电子产品等多方位嵌入式零碎设计。MCU通常是基于SRAM和闪存的混合应用，MCU个别状况下配置有1~2MB双块Flash存储器和256KB SRAM，在一些利用中，应用单片机片内SRAM还不够反对利用的须要，就要用外扩SRAM的形式来扩大。这时能够采纳VTI7064MSME来扩大MCU。 因为SRAM和PSRAM的异步读写接口完全相同，只是时序方面须要依据不同的芯片所规定的参数不同而做相干的设置即可。 联合单片机的FMSC内部接口信号，可应用异步形式拜访SRAM，能够选用复用或非复用形式扩大SRAM，还能够通过配置实现外扩8位总线或16位总线接口的SRAM。目前市场上非复用型16位数据总线接口的SRAM/PSRAM较为广泛。 VTI7064MSME这种封装是SOP-8的串口SRAM芯片，容量能够达到64Mbit,它反对1.8v和3.0V，SPI/QPI SRAM器件。该RAM可配置为1位输出和输入拆散或4位I/O通用接口。设施自身会执行所有必要的刷新操作。占用占用单片机的I/O脚位比拟少，较多的利用在各类产品中，性价比比拟高的一款SRAM芯片产品。代理商英尚微电子提供样品测试及技术支持。

简介：Delta Lake 和 Hudi 是风行的凋谢格局的存储层，为数据湖同时提供流式和批处理的操作，这容许咱们在数据湖上间接运行 BI 等利用，让数据分析师能够即时查问新的实时数据，从而对您的业务产生即时的洞察。MaxCompute 在湖仓一体架构中，通过反对 Delta Lake 和 Hudi 在数据湖中提供数据仓库性能。本文作者 孟硕 阿里云智能 产品专家 直播视频请点击 直播观看 一、最佳实际背景整个最佳实际是基于MaxCompute的湖仓一体架构，模仿公司应用场景。比方公司 A 应用云上关系型数据库 RDS 作为本人的业务库，同时应用阿里云 EMR 零碎做日志数据采集。将数据会集到云上对象存储 OSS 上，引入了数据湖常会用的存储机制 Delta Lake 和 Hudi 为数据湖提供流解决、批处理能力。通过 MaxCompute 查问到实时数据，即时洞察业务数据变动。 整个场景demo的架构是，云上EMR产生的实时变动的数据，包含在线数据库RDS，通过数据入湖，而后实时的把数据变动体现在归档的OSS 上。同时MaxCompute跟其余引擎一起剖析OSS上的数据。 湖仓一体架构：异构数据平台交融因为企业外部会有很多业务线，不同的部门，因为自身业务的需要及员工的技术栈几个方面的起因，导致采纳的数据架构不一样，数据平台也不一样。技术架构有Hadoop技术体系，也有云上全托管架构，所以造成不同的部门对技术架构，应用的技术平台不一样，也造成了数据割裂的状况。湖仓一体就是帮忙企业把异构数据平台做一个买通，底层数据能够互相拜访，两头元数据层也能够做到相互透视，数据能够做到自在流动。数据湖局部不只是反对EMR，也反对ESC Hadoop和云下IDC Hadoop。其中MaxCompute数据仓库也能够和数据湖EMR做一个数据买通，在用MaxCompute跟联播数据源做一个联播查问，这样能够把所有的数据在MaxCompute中做一个汇总。比方有三张表，在RDS和Hive中，共事MaxCompute里有大量事实表，如果需要是对这个三个表做一个联结查问，通过这个架构，能够很不便的做到这一点。 更快的业务洞察DataWorks 自助开明湖仓一体：5分钟买通异构数据平台（Hadoop/ DLF+OSS ）更宽泛的生态对接反对对接阿里云云原生数据湖构建（DLF）反对查问 DeltaLake、Hudi 格局反对对接更多内部联邦数据源 Hologres （RDS、HBaseUpcoming！ ）更高的性能智能 Cache 实现 OSS/ HDFS 数据拜访减速湖数据查问减速更好的综合数据开发与治理跨引擎开发和调度对立湖/仓数据开发体验对立湖/仓全局资产治理 湖仓一体的架构首先看右侧局部，是跟OSS和DLF侧的买通，因为在OSS 上咱们归档大量的半结构化和结构化的数据。有关系型数据库，有nosql数据库，能够通过DLF组件把OSS上的元数据爬取出来。相比于在MaxCompute上创立OSS表面拜访OSS数据，当初通过DLF对立自动识别OSS schema，MaxCompute间接映射这种形式，会更不便一些。一些数据的更新，schema的变更，DLF也能够自动识别到。同时DLF外面有用户权限治理，后续会陆续上线。也就是说对于OSS对接的引擎，对立的数据拜访权限会收敛到DLF里。 左侧是对Hadoop生态系统的买通，Hadoop包含阿里云半托管的EMR，开源的on ECS和IDC Hadoop，也蕴含支流的发行版CDH，也都能够做买通。下方再加上联邦数据源。通过MaxCompute能够连贯到各种各样的云上数据源，通过上传DataWorks做对立的开发和治理，以及数据治理。 这样就有一个全域数据资产视图，开发工作数据也能联通，元数据也能投射到DataWorks之上。这就是整个湖仓一体的架构。 二、相干产品介绍数据湖构建DataLakeForamtionDLF次要是针对OSS数据，做一个托管，下层对接其余引擎如EMR、Databricks、Datalnsight、PAI、MaxCompute、Hologres。这些引擎能够共享一份元数据在DLF上。后续企业能够依据不同部门，不同业务场景随便切换引擎。前期咱们也会逐步欠缺访问控制，以及一些企业级能力，比方平安，包含数据分层等。 数据入湖反对多种数据源入湖，MySQL、SLS、OTS、Kafka等离线/实时入湖，反对Delta/Hudi等多种数据湖格局数据入湖预处理，反对字段mapping/转换/自定义udf操作元数据管理对立元数据管理，解决元数据多引擎一致性问题兼容开源生态API主动生成元数据，升高应用老本访问控制集中数据拜访权限管制，多引擎对立集中式赋权数据拜访日志审计，统计数据访问信息三、最佳实际Demo整体架构企业构建和利用数据湖个别须要经验数据入湖、数据湖存储与治理、数据摸索与剖析等几个过程。次要介绍基于阿里云 MaxCompute、数据湖构建（DLF）+ 对象存储（OSS）构建一站式的数据入湖与剖析实战。其次要数据链路如下： 第一步：RDS数据筹备RDS 数据筹备，在 RDS 中创立数据库 academy\_db。在账户核心创立可能读取 employees 数据库的用户账号。通过DMS登录数据库，运行一下语句创立 anti\_fraud\_result 表，及插入大量数据。 ...

简介：以上为大家分享了阿里云容器存储的技术创新，包含 DADI 镜像减速技术，为容器规模化启动奠定了很好的根底，ESSD 云盘提供极致性能，CNFS 容器网络文件系统提供极致的用户体验。作者：徐立 云原生的翻新源泉云原生趋势下，利用容器化比例正在快速增长，Kubernetes 也已成为云原生时代新的基础设施。 Forrester 预测到 2022 年，寰球组织/公司在生产环境运行容器化利用。从明天有余 30%的比例将大幅度晋升到超过 75%，企业应用容器化的趋势势不可挡。咱们能够看到两个广泛的景象。首先，在云上托管 Kubernetes 曾经成为企业上云及运行容器的优先选择。另外，用户应用容器的形式也在扭转，从无状态利用到外围企业应用再到数据智能利用，越来越多的企业应用容器来部署生产级别、复杂度高和高性能计算的有状态利用。比方 Web 服务、内容资料库、数据库，甚至 DevOps、AI/大数据利用等。 随着基础设施从物理机到虚拟机，到以 Kubernetes 为代表的容器环境，甚至到 Serverless 的逐步演进，明天的计算和利用正在面临微小的变动。这种变动使得资源粒度越来越细，生命周期越来越短，计算按需应用。 从用户视角来看云原生带来的存储变动，最显著的就是用户应用存储界面产生上移，和利用不间接相干的存储服务从应用层下沉到云平台，用户更关怀利用。  举例来说，传统状态用户须要关怀所有硬件和软件，逐步过渡到用户关怀虚拟机、操作系统和整个应用软件栈，到明天在 Serverless 里演变成用户只关怀利用业务和代码。系统资源从物理资源层、虚拟化资源层回升到利用开发层，用户无需关怀底层的基础设施。  在这样的技术体系下，存储的能力的演变次要体现在以下 3 个方面： 1、高密虚拟机时代，一个虚拟机就对应一个残缺的存储空间，能够用其存储整个利用所须要的所有数据相干的拜访和存储需要。在Serverless 函数计算环境，利用被切分为一个个函数，对应的资源都须要存储管理，因而，存储的密度产生了很大的变动，存储密度更高。 2、弹性随着利用拆分的粒度越来越细化，存储密度逐步晋升，Serverless 函数计算大规模实例须要高并发启动，存储须要极致弹性的能力。 3、极速从Serverless 函数计算的角度来看，函数是整个过程的一个局部，生命周期天然变短。由此呈现大量短生命周期的容器实例。随着生命周期越来越短，须要存储疾速挂载/卸载，快速访问。  随着服务界面产生上移，存储管控界面被重塑，内置存储和外置存储变得更加清晰。Serverless 环境里，用户可见界面是外置存储（包含文件存储和对象存储），而内置存储（包含镜像存储和长期存储）对用户是不可见的，内置存储由阿里云来治理，提供了翻新的机会。 镜像减速的技术创新阿里巴巴容器规模化部署的挑战 阿里巴巴容器规模化部署次要面临的挑战体现在以下几个方面： 1、业务体量大。集群规模大，高达十万量级；所有利用全副容器化，并且利用镜像大，通常以数十 GB 大小为主。 2、更快的部署速度。业务规模持续增长，要求云平台能够疾速的部署利用，才可能解决业务增长，尤其双十一大促时紧急扩容，难以事先对各服务精确预估容量。 3、然而大规模的创立或者更新容器集群仍然很慢，次要起因是容器部署镜像的下载和解压很慢，次要的技术挑战如下: 工夫开销大：工夫开销 ∝ 镜像大小 * 节点数；一千节点就须要存一千份镜像；CPU 工夫开销大：gzip解压慢，且只能串行解压；I/O 压力大：下载、解压两轮写盘，包含泛滥节点同时写盘，对云盘产生“共振”； 内存占用扰动：对宿主机 page cache 产生重大扰动；然而无效数据占比少：启动时均匀仅需镜像数据的6.4%。应答以上技术挑战，大规模容器部署的要害需要形象总结为三点： 1、按需：下载解压速度足够快、数据按需拜访和按需传输。 2、增量分层：数据解耦，通过 OCI-Artifacts 规范 overlayfs 把档次做划分，增量数据，工夫资源应用更无效。 3、Remote Image ：采纳近程镜像技术，扭转镜像格局，同时缩小本地资源的耗费。 Remote Image 技术计划比照Remote Image 次要有两种技术实现的形式，一种是基于文件系统，第二种是基于块设施。Remote Image 技术计划对比方下图所示： ...

简介：函数计算作为事件驱动的全托管计算服务，其执行模式天生就与这类 Job 场景十分符合，对上述痛点进行了全方面的反对，助力“工作”的无服务器上云。作者：冯一博 工作（Jobs），是互联网服务的一种常见场景。在诸如 AI 训练、直播（视频转码）、数据荡涤（ETL）、定时巡检等场景下，工作平台是否反对疾速的高并发工作启动性能、提供较高的离线计算资源利用率以及丰盛的上下游生态是这类场景的外围痛点。函数计算作为事件驱动的全托管计算服务，其执行模式天生就与这类 Job 场景十分符合，对上述痛点进行了全方面的反对，助力“工作”的无服务器上云。 函数计算和 Serverless Jobs“Job”零碎应具备什么能力？在上述的“Job”场景中，一个工作解决零碎应该具备以下能力： 工作触发：反对灵便的工作触发形式。如反对客户端手动触发，反对事件源触发，反对定时触发等；工作编排：可能编排简单工作流程，治理子工作之间关系，如分支、并行、循环等逻辑；任务调度及状态治理：调度工作优先级，多租隔离及工作状态治理，反对多种工作并发度、限流；可能治理工作状态，管制工作的执行等；资源调度：解决工作的运行资源问题。这外面包含多种运行时反对，计算资源冷启动提早管制，在/离线工作混部，最终目标是使得零碎具备较高的资源利用率；工作可观测性：工作执行历史的查看、审计；工作的执行日志；任务调度零碎上下游生态：任务调度零碎能够天然接入上下游零碎。比方与 Kafka/ETL 生态、音讯生态等集成的能力。阿里云函数计算 Serverless Job函数计算 Jobs 能力全景图如下图所示： 图一：函数计算 Jobs 能力全景图 业界常见任务调度零碎 Job 能力比照 表一：常见任务调度零碎能力比照 在广泛状况下，像诸如一些云厂商的批量计算产品、开源的 K8s Jobs 等任务调度零碎反对的最小粒度个别是按实例级别扩缩容，并且不具备大规模工作（编排）治理的能力，因而比拟实用于低并发、重负载、超长时运行的业务（如基因计算、大规模机器学习训练）等；而一些开源流程执行引擎、大数据处理系统的任务调度往往短少弹性、多租隔离、高并发治理及可视化等一系列能力。函数计算作为免运维的 Serverless 平台，很好的联合了上述不同零碎的长处，另外 Serverless 先天的弹性能力很好的反对了工作中普遍存在的高并发波峰波谷场景的需要。 举荐最佳实际 & 客户案例AI 训练 & 推理场景的外围诉求： 同时反对实时推理 + 离线训练，实时推理对冷启动有要求；有显著的波峰波谷，计算量大，须要高并发，计算实例间根本不须要协同；个别须要容器镜像运行自定义库进行训练。案例 1：网易云音乐 - 音视频解决平台网易云音乐的音乐“发现”和“分享”性能依赖对音乐进行根底特征分析及提取。在运行这类举荐算法及数据分析时，须要依赖十分大的算力对音乐原始文件进行解决。网易云音乐音视频离线解决平台在经验了 异步解决模式- 优先及队列优化 - 算法集群虚拟化 - 算法镜像框架化 - 云原生化 这一系列演进后，抉择了函数计算作为视频平台的基础设施，无效解决了不断扩大的计算规模所带来的的难以运维、弹性差等问题。 案例 2：数据库自治服务 - 数据库巡检平台阿里云团体外部的数据库巡检平台次要用于对 sql 语句的查问、日志等进行优化剖析。整个平台工作分为离线训练及在线剖析两类次要工作，其中在线剖析业务的的计算规模达到了上万核，离线业务的每日执行时长也在 百万h。因为在线剖析、离线训练工夫上的不确定性，很难进步集群整体资源利用率，并且在业务顶峰来时须要极大的弹性算力反对。业务最初应用函数计算构建了数据库巡检平台，满足日常的 AI 在线推理及模型的离线训练任务。 案例3：分众传媒 - Serverless 图片解决业务在广告业务中，运行深度学习算法进行图片解决、比对、辨认是比拟常见的业务，这类业务往往具备数据起源多样、单实例解决工夫不确定、波峰波谷显著、工作可观测要求低等个性。采纳自购机器运行服务岂但须要思考机器的运维及资源利用率问题，还比拟难以适配多种多样的图片源，难以做到服务的疾速上线。 函数计算的多种事件源触发反对为这类业务提供了极大的便当。分众传媒采纳 OSS/MNS 触发器触发函数计算，解决数据源多样的问题。用户的图片数据能够上传至 OSS 或者 MNS，对应的触发器则会间接触发函数计算来实现图片解决工作，函数计算的弹性及按量付费模式解决了资源使用率及机器运维的懊恼。在可观测性方面，工作解决实例应用了有状态异步调用模式，对于任何已触发的工作做到了可追溯的能力，不便业务对于执行失败的工作进行排查及重试。 ...

简介：本最佳实际解说如何通过云速搭部署一个挂载CPFS的E-HPC集群：以CPFS为共享存储的E-HPC集群，在创立之前必须当时制作好装置了CPFS客户端的自定义镜像，再通过该镜像创立E-HPC集群。 中转最佳实际：【云速搭部署挂载CPFS的E-HPC】 最佳实际频道：【最佳实际频道】 这里有丰盛的企业上云最佳实际，从典型场景入门，提供一系列我的项目实际计划，升高企业上云门槛的同时满足您的需要！ 场景形容本最佳实际解说如何通过云速搭部署一个挂载CPFS的E-HPC集群：以CPFS为共享存储的E-HPC集群，在创立之前必须当时制作好装置了CPFS客户端的自定义镜像，再通过该镜像创立E-HPC集群。 业务架构 中转最佳实际 》》https://bp.aliyun.com/detail/271 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

简介：在游戏的开发和经营当中，数据库的应用场景十分多。面对游戏拜访压力、游戏合服场景、游戏排行榜等场景, 阿里云为用户提供了最佳解决方案。本文从三个方面来为大家介绍数据库游戏行业最佳实际： 游戏架构中数据库的利用和需要剖析游戏中Redis/Tair的技术水位MongoDB的游戏最佳实际一、游戏架构中数据库的利用和需要剖析游戏支流架构有三种：1.分辨别服。2.全区全服。3.寰球同服。 1.1 Alibaba Cloud Database in gaming servers （分辨别服） 见上图从上、中、下三路来介绍： 上路是当用户登陆获取游戏帐号时，能获取服务器的分区信息和版本信息等，用户的帐号和订单等存在关系型数据库PolarDB里。用户分辨别服和信息缓存到Redis/Tair的数据库里，红色是数据库用法，黄色是缓存的应用场景。 中路是游戏外围GameServer强计算型数据结构。游戏中的教训和配备会定期刷入数据库中。游戏数据的人物角色存储以Json半结构化写到数据库里，数据能够应用PolarDB和MongoDB。在GameServer有分布式锁、排行榜、选角记录等，会引入Redis 服务或阿里云的Tair。 下路很重要，游戏中有很多流动，大量的日志记录被寄存到一个剖析性数据库中。比方游戏投放流动后想看是否有成果，就要剖析数据库造成的报表。剖析性数据库很重要的作用是反作弊，防黄牛/防刷等。要做数据分析须要导入不同源，比方日志、角色、账号等。阿里云的AnalyticDB最适宜做这个工作。 见图片右上角，分辨别服游戏有点到点和跨服对战等互动信息，这种音讯零碎应用Lindorm服务区存储。 1.2 Alibaba Cloud Database in gaming servers （寰球同服） 寰球同服是各大游戏厂商重点投入的一个的架构。因为应用多种游戏平台比方PC、手机、Switch和PlayStation等游戏主机进行无缝的游戏和互动，会将用户的体验晋升到一个十分杰出的程度，国内也有这种游戏在寰球大卖。 寰球同服的架构特点是应用集中式的数据库，前端不同区域的游戏核心会将数据集中的写到对立的数据库中。寰球同服技术的外围是每个区域的Cache Server，它是晋升游戏体验的外围，会定期的将数据批量刷入后端数据库，也会将数据库中更新的条目更新到其余服。 1.3游戏行业对数据库的整体需要 游戏行业自身高度依赖内存计算和网络资源，而后才是数据库。我走访过很多游戏客户，记得有一位游戏大厂CTO和我说：“游戏里最远的间隔，不是数据到数据库的间隔，而是联通到电信的间隔”。 但尽管游戏行业整体上对数据库性能要求并不高，然而它对数据库的稳定性、平滑性和可运维水平要求十分高。 首先就是扩缩容的平滑性。因为阿里的数据库技术开始是围绕电商倒退起来的，而电商零碎和游戏零碎这两个行业在应用缓存和内存数据库的形式上却高十分不一样。举个例子说，电商对数据库容错的需要大都是“早死早超生”的哲学，做fast fail。如果拜访数据失败，数据层须要做疾速失败而不能卡住。这样用户能力疾速重试，然而如果咱们把这个逻辑套到游戏服务中，如果拜访一次两次数据库库失败了就把连贯给断了游戏用户可能就间接被踢出这局游戏了。 所以咱们专门在可扩大和高可用上做了连贯放弃能力，岂但扩缩容一直链接，在阿里星散群版Redis/Tair上即便高可用事件产生，比方Tair后端数据库做了切换，前端依然能够放弃连接不断。在Tair的扩缩容事件中，对业务侧的抖动能够达到100ms左右，根本靠近无感。像PolarDB存储计算拆散的云原生数据库也具备切换和HA一直链接的能力。这样在平滑性上就有保障了，对于用户的游戏体验来说也是一个十分大的提高。 另外一个场景是，尽管游戏行业对数据库的整体性能要求并不太刻薄。然而游戏用户也有万人团战、新区上线等热门流动，这种对数据库整体的抗压能力和平滑可扩大能力要求很高。 寰球同服的游戏对数据库的需要逐渐走向了跨域多活，古代数据库的跨域多活也成为数据库内置的外围能力之一，可能极大的简化用户的应用场景。 1.4游戏行业更青眼云数据库 游戏行业是一个迭代速度极高的行业。在一些外围的服务能力上，比方在阿里云Tair上，它的存储构造更靠近客户的数据更靠近ORM，它提供了一些封装好的分布式锁、分布式排行榜、计数服务等可能让游戏高速迭代起来。 同样，游戏用户是数据库运维操作最多的行业之一。这和游戏自身的业务特点相干，比方有些分辨别服的游戏，它的经营和拉新模式就是开新服，合旧服这种。游戏的经营流动频繁，运维大量数据搬迁、数据荡涤，有些分辨别服的服务要常常合服、滚服和版本更新，发上去也要常常备份、回档等。数据库自身就要在数据库内核上做加强，也要和周边生态做互动。当代数据库如果不把运维零碎和生态系统当成一等公民去建设，逐渐的就会被市场淘汰。 在老本上池化数据库可能更好的在资源上做配置，达到更好的资源配置。在游戏行业有两块老本被显著低估了，一块是运维老本，具备很高的弹性扩缩容的能力，能够极大的升高业务的老本开销，比方Tair就能够随着用户业务抉择内存引擎，如AEP引擎和SSD引擎。另外一块是谬误老本，实质上还是属于研发老本的一部分，具备更好的可观测性，可能通过高效规范的生态工具同样能够升高谬误老本。 二、游戏中Redis/Tair的技术水位2.1 Redis/Tair以后游戏能力技术水位大图 在面临稳定性，高速迭代和老本等问题时，云数据库有很大的劣势。在NoSQL数据库畛域，Tair和Mongo都反对Json的原生构造。另外非关系型数据库针对游戏高速迭代十分敌对，比方在运维上Tair能够做任意工夫点的数据恢复， Tair在扩缩容和容灾上都具备连贯放弃能力。数据库也撑持存算一体的能力，在Tair上具备十分多的数据模块，能够不便游戏用户做剖析和计算等。 Tair云原生内存数据齐全兼容了Redis协定和命令。Redis是游戏服务中必不可少的数据库之一，下面的架构图曾经介绍过了，它能够服务缓存和内存数据库两种场景。 然而在原生的社区Redis上，它的探活和扩缩容都十分不平滑。在云Redis上做有很大改进然而还是闪断；到了Tair上就能够做到连贯放弃、高精度探活和切换；如果自运维Redis在备份复原上，就只能全人肉运维了。云Redis能够通过很好的基础设施无感知和自动化搞掉，Tair能够很好的保障数据安全和任意工夫点的复原。针对AEP/SSD引擎，还有可调节的版同步能力在上线中，能够更好的适应数据无损场景。 云数据库具备更好的可观测性，比方Redis外面一旦遇到大Key，热Key就很难察看到。云数据库在内核上极大的晋升了可观测性，在Tair上就有更好的可控制性，比方热点在云Redis上能够被发现，在Tair上就能够应用减速能力可能霎时将单个Key的读能力晋升几十倍。这个能力来自于电商零碎中的热点散列技术，是一个简化版，但在与服务中针对游戏的场景做了更灵便的优化配置能力。游戏中并不会呈现像电商零碎中呈现全民抢茅台这种数百万级别的热点拜访，而查问缓存足以让游戏业务更好的应答突发事件和洪峰挑战。 Redis常常工作在同步链路，慢了就会间接影响体验。游戏外面遇到就要先顶过去再说，后续缓缓查缓缓修。还是那句话，尽管游戏对数据库性能要求并不高，然而保险肯定要有。 在减速开发上，自运维的Redis能够运行一些Redislabs设计的企业级模块，然而这些模块云厂商不能用。Tair上做了特地多的业内罕用的多数据模块，有一些是齐全兼容Redislabs模块，比方游戏外面罕用的Json模块齐全兼容reJSON。TairZset是一个多维度排行榜，也能够应用咱们提供的SDK做一个可扩大、高性能的分布式排行榜，它也是基于TairZset。在上线中的是TairSearch，它兼容Elasticsearch的语法，能够对寄存在Tair的内容做全文索引和分词，这样联合Tair引擎的弱小能力能够做到一个十分好的游戏体验。 2.2场景: Tair的寰球多活在游戏中的应用 上面介绍几个场景，第一个场景就是数据库多活。这个场景在全区全服的游戏外面利用的十分宽泛。 说一个切身体会，就是最近一个老牌的游戏大厂，上线了一个寰球同服的游戏。它把一个20年前的游戏重制了一下，把分辨别服改成了寰球同服，后果十分不胜利，直到明天，就是当初你去玩的时候，登陆的时候都在排队。很遗憾我是这个游戏的骨灰级玩家，我的黑眼圈大多数是因为工作导致，最近减轻了其实和这个游戏很有关系。 前两天在论坛上，他们的技术经理写了一篇十分长大略3000多个单词的文章，解释了为什么会出问题。我认真去浏览领会了好几遍，其实都是在解释业务数据在面临寰球多活时的技术挑战。既要好的体验，又要保证数据统一。如果没有一个寰球多活的数据库，那么即便是一个技术和策动都十分强的老牌游戏公司也同样会陷入困境。 如果我不是因为情怀，真的就把这个游戏退掉了，天天掉线回档是无法忍受的。应用Tair等寰球多活数据库可能给用户一个很好的体验，能够让寰球多活游戏有十分好的体感。 图中就是一个游戏客户的典型用法，中美游戏服务器的商场漫游。 2.3场景: 任意工夫点数据恢复（PITR） 第二个场景是任意工夫点的数据库复原。这个场景最早是避免删库跑路的场景。在游戏行业里用处十分宽泛，比方游戏发版本，出问题可能迅速回滚。同时咱们也开掘了游戏客户的反馈和倡议，在任意工夫点复原的时候，能够选择性的复原局部Key/Key Pattern，也能够选择性的抛弃某种类型的Key/Key Pattern都反对。这个Key级别的PITR就是专门为游戏行业定制开发的，数据库产品可能多贴着游戏的业务场景做一些能力，那么业务的幸福感晋升还是很高的，也升高了犯错机会。 2.4 Tair(Redis企业版）反对的数据结构模块 (modules) Tair作为企业级的Redis，它的一个典型的特点就是反对十分多的扩大模块，既包含简略易用能够晋升幸福感的数据结构，也包含一些行业级整体解决方案。在本次分享中我只简略说一下画圈的这几个，它们在游戏开发中常常遇到。 2.5场景：高性能分布式锁（CAS/CAD） 所有互联网利用都须要分布式锁做相似于资源竞争的解决。咱们在Redis场景下发现业内有十分多的分布式锁的实际案例，但很多都实现的有问题。次要技术点就是分布式锁删除不对，有可能会导致业务侧的资源争抢生效。咱们在Tair引擎里做了分布式锁，只须要设置一下就能缩小犯错的老本。阿里团体外部、游戏和互联网行业分布式锁用得很多，这个Tairstring模块曾经开源没有限度了，用户用Redis套上去就能够用，能够取得比拟好的收益。 2.6场景：多级排序和分布式排行榜 Redis的排行榜是所有游戏绕不开的问题，排行榜的问题是大Key很难做并行的扩大，游戏里的排行榜会成心设计地比拟深，特地不容易点到，Redis的排行榜最痛的是容易造成大Key和只能为一维数据进行排序，携带的额定数据无限。 咱们也给游戏里多维度的排序做了模块，通过模块的扩大做分布式排行榜，服务能力通过分片数和整体的资源回升做到均衡扩大，为游戏用户解决大查问的问题。 同样TairZset模块也曾经开源了，联合着Tair的SDK中分布式排行榜，用户能够很容易的利用可扩大高性能排行榜这个基础设施。也不须要保护一个专门的排行榜团队，毕竟一些中小型游戏公司并没有精力去投资一个业余的排行榜团队。 从以上的介绍咱们能够看到，数据库内核可能帮忙积淀一些能力到引擎中，那么就可能极大的简化业务的开发，这对于游戏行业的高速迭代是十分重要的。在2017年已经在数据库行业内掀起过一场轰轰烈烈的Multi-Model静止即多模数据库。多模能力大背景上就是数据库在对行业做深耕，而Tair提供的这些能力即是阿里云上诸多客户的实在需要，也同样是阿里外部零碎应用最多的数据结构。 2.7游戏的云数据库周边设施（DTS/DAS） 对于游戏的合服、滚服操作，过来都做的十分原始。要么是本人做备份、荡涤和合并，要么就是本人写个长SQL去做数据变更。这些工具、办法要么是依照约定，要么就是祖传脚本口口相传。有些原始的云服务还要提个合服工单什么的。在当代数据库生态里数据的订阅（CDC）和转换清晰（ETL）曾经是数据库生态的一部分，它通过规范的全量和增量订阅，可视化的进行过滤、映射等算子标准化的反对掉。 ...

FRAM（铁电RAM）是一种写入速度快的非易失性存储器。与传统的非易失性存储器（如 EEPROM、闪存）相比，铁电存储器不须要用于数据保留的备用电池，具备更高的读/写耐久性、更快的写入速度和更低的功耗。铁电存储器是一种具备高读写耐久性和疾速写入速度，功耗低等长处的高性能和高可靠性存储器。 本篇文章铁电存储器代理商英尚微电子介绍对于应用其余存储芯片的常见问题和解决方案。 状态：应用EEPROM问题：因为写耐久性标准的限度，难以更频繁地记录数据解决方案：应用FRAM保障10万亿读/写周期 状态：应用EEPROM问题：有突发事变或断电写入数据失落的危险解决方案：应用具备疾速写入性能的FRAM，以爱护断电写入数据 状态：应用SRAM问题：难以取出电池以保留数据解决方案：应用FRAM作为非易失性存储器 总之，铁电存储器产品为客户带来了诸如缩小开发累赘、加强客户产品性能和降低成本等益处。

作者：极光高级工程师—包利 摘要 极光推送后盾标签/别名零碎存储超过百亿条数据, 高峰期 QPS 超过 50 万, 且随着业务的倒退，存储容量和访问量还在一直减少。之前零碎存在的一些瓶颈也逐步浮现，所以近一两年继续做了很多的优化工作，最终达到十分不错的成果。近期，通过积攒和积淀后，将这一部分的工作进行总结。 背景 以后的旧零碎中次要存储标签/别名与注册 ID 的互相映射关系, 应用 Key-Value 构造存储, 思考到一个注册 ID 可能有多个标签, 同时一个标签也存在多个不同的注册 ID, 这部分数据应用 Redis 存储中的 Set 数据结构; 而一个注册 ID 只有一个别名, 同时一个别名也存在多个不同的注册 ID, 这部分数据应用 String/Set 数据结构。因为此局部数据量过大, 思考到存储老本, Redis 应用的单 Master 模式, 而最终数据的落地应用 Pika 存储(一品种 Redis 的文件存储)。Pika 与 Redis 中的数据由业务方保持一致, Redis 失常可用时, 读 Redis; 当 Redis 不可用时读 Pika, Redis 复原可用后, 从 Pika 复原数据到 Redis, 从新读 Redis。旧零碎的存储架构如下: 从下面的架构图能够看到, Redis/Pika 均采纳主从模式, 其中 Redis 只有 Master, 配置管理模块用来保护 Redis/Pika 集群的主从关系, 配置写入 ZooKeeper 中, 业务模块从 ZooKeeper 中读取配置, 不做配置变更。所有的配置变更由配置管理模块负责. 当须要迁徙, 扩容, 缩容的时候, 必须通过配置管理模块操作。这个旧零碎的优缺点如下: ...

Hello 大家好，我是 Rose，明天是假期前最初一天了，咱们聊点轻松的话题。 最近我的工作方面产生了一些变动，先说论断：我通过外部转岗的形式，正式退出到 B 站基础架构部，会去做分布式存储相干的工作了。 这是一个看似自然而然的后果，但也有点出乎我本人的意料。 一些人可能晓得，我是 19 年本科毕业的，最开始在一家小公司做 Java，而后今年初的时候，退出到 B 站做 Golang 开发，到目前为止工作两年多，都是纯业务开发。 我与存储结缘大略就是在去年的这个时候，过后我看到了一篇介绍存储模型的文章，而后本人去实际，折腾出了 rosedb 这个我的项目。 说实话，这个我的项目带给我的帮忙还是挺大的，rosedb 在 Github 上受到了一些关注，这让我有更多的能源去保护，而后继续的学习存储相干的一些常识。 几个月之前，我去看了公司的一个外部技术分享，介绍的就是 B 站自研的一个分布式 kv，这让我理解到我司外部就有专门做存储的部门。 那时还是挺感兴趣的，跟分享的主讲人也简略沟通了一下，并且把我的我的项目拿给他看了下，他过后就让我去他们部门试试。 但那时候我自认为程度还不太够，并且退出 B 站没多久，在原岗位待的工夫并不长，冒然来到太过仓促，所以就临时搁置了。 到了最近的这段时间，因为一些起因，我心田有点按捺不住了，就被动分割到存储部门，跟两位负责人都谈了一下，都示意没啥问题，而后应该是国庆假期之后就筹备过来了。 其实也小纠结了一下，这段时间也看了一些其余的机会，有两家公司开的薪资还挺合乎我的预期的，比我当初高很多，但都不是做存储，想想还是回绝了。 这一路走来，我还是想尽量保持钻研本人的趣味所在，可能把本人的趣味当做工作，也是我始终谋求的，尽管现实和理论可能存在不小的差异，然而不试试怎么晓得呢。 如果当初不试，转而去做其余的方向的话，那么当前可能也没啥机会去做存储了，我还是不太想留下这样的遗憾。 也很想联合本人的亲身经历通知大家，要不停的去折腾，去保持本人的心田，保持做一件事件，这样带来的成就感会让你继续上来，造成一个正向循环。 我的文章首发于公众号【roseduan写字的中央】，欢送关注。

世界的诞生是从盘古开天辟地开始而数据的存储则由在龟甲上刻下的第一个字开始 通过数千年倒退数据存储也从最后的龟壳、竹简等资料逐渐进化到磁带、硬盘甚至云上 在之前几千年里人们对于数据存储的需要并没那么高仅仅通过纸张就能将所有数据记录下来 随着第一台计算机面世人类进入IT时代数据开始爆炸式增长原有通过磁带存储数据的形式曾经无奈满足需要 1956年IBM创造第一款磁盘存储系统有一个衣柜那么大存储容量才5MB 随着磁盘技术的倒退磁盘的体积越来越小，容量越来越大 出于数据对立治理的需要用户开始将各种磁盘整合在大型设施中组成企业存储系统 几十年里企业存储系统在架构和技术方面都产生了很多变动其变动次要分为两个阶段 第一阶段“硬件主导的存储系统架构”硬件和软件相互绑定存储软件运行在专用硬件服务器中该阶段的存储拓展性较差如果企业须要晋升性能或存储容量就须要应用同个厂商的软硬件 第二阶段软件主导的存储系统架构不同于传统的存储架构其可能运行在规范的X86服务器中软硬件拆散用户可依据业务需要自行更换软硬件极大打消了存储软件对于专属硬件设施的依赖 于是企业用户大量应用标准化/商业化服务器代替专有硬件存储设备让数据面和管控面解耦通过对立的管控面来治理不同厂商的不同硬件大大提高了资源利用效率 通过开发API让软件管制存储资源和服务的增、删、改、查比人机界面的效率更高业务弹性伸缩能力更强 然而数据量也会随着业务进行稳定传统线下数据中心的模式已无奈撑持局部企业对数据存储的需要局部企业常常会面临性能不够、老本过高、资源节约等问题 “云”凭借其高弹性、高性能、低成本等劣势驯服了越来越多的企业用户云厂商以服务的形式对外提供存储产品租户能够通过自助服务等形式按需拜访云资源 互联网、企业级客户、自在开发者均承受、认可了这种模式 2021年3月，十四五布局出台提出要放慢数字化倒退，建设数字中国可见，越拉越多的企业基础设施将走向云化 目前寰球仍有超过60%以上的数据运行在线下很多企业因各种起因无奈享受云计算的红利 有人提出既然不不便上云为何不让云过去呢？ 阿里云应势而动，重磅推出“云定义存储”产品CDS（Cloud Defined Storage）不同于传统定义的SDS与公共云CDS能为企业线下的数据提供与云上产品无异的服务不必迁徙数据不必扭转架构只须要API接口就能打造本人的“专属云” CDS基于“盘古”构建可反对文件存储、对象存储也能同时提供块存储、日志存储等服务无需部署多套存储产品 “盘古”是阿里云自研的国内首个分布式云存储架构是阿里巴巴的对立存储底座撑持着阿里商业体的运行与成长历经多年双11峰值流量考验具备极佳的零碎稳定性、安全性与弹性能力在十多年倒退过程中，承载了数十EB存储数据量服务了上百万的用户 以云服务定义存储是想让云不再是飘忽在天上的形象而是一个看得见、摸得着能下沉到线下数据中心的状态让云在多种状态下助力企业的业务翻新 原文链接本文为阿里云原创内容，未经容许不得转载。

简介： 本文次要论述 CDS 产品中 OSS 服务在容灾方面的部署状态以及实现的其本原理。 容灾性能能够保障用户一份数据在多个中央存在冗余备份，当某个机房呈现极其异样（比方物理损毁）状况下，数据也不会呈现失落；也能够保障当某个机房呈现不可用（比方断电）时，用户向外提供的性能也根本不受影响。 前言对象存储服务（Object Storage Service，OSS）是阿里云推出的一种海量、平安、低成本、高牢靠的云存储服务，适宜寄存任意类型的文件；容量和解决能力反对任意弹性扩大，并提供多种存储类型以供选用户依据本人的业务个性去抉择，能够帮忙客户全面优化存储老本；提供数据持久性可达到 99.9999999999%(12个9)，可用性可达 99.995%。 为了更好的将私有云的这种线上能力输入到线下，让线下客户也能享受到上述微小的技术红利；同时，也为了帮忙线下客户无效的升高硬件部署老本，阿里云推出了 Cloud Define Storage(CDS)。本文次要论述 CDS 产品中 OSS 服务在容灾方面的部署状态以及实现的其本原理。容灾性能能够保障用户一份数据在多个中央存在冗余备份，当某个机房呈现极其异样（比方物理损毁）状况下，数据也不会呈现失落；也能够保障当某个机房呈现不可用（比方断电）时，用户向外提供的性能也根本不受影响 容灾原理OSS 蕴含一个十分重要的后盾服务即数据复制服务 DRS（Data Replication Service）。当用户为 Bucket 开明了数据复制服务时（每一个数据复制服务的规定咱们称之为复制边）,每当用户上传一个文件， DRS 服务都会收到告诉，而后 DRS 服务会主动异步的将该文件“搬运”到数据复制规定中的目标端，整个过程对用户齐全通明，用户无需干预。 上图是一个跨区域复制的例子，用户为源 Bucket 开明了数据复制服务并配置好了目标端 Bucket 后，DRS 会主动将数据从源 Bucket 复制到指标端 Bucket。 部署架构简略介绍一下 CDS 线下部署的物理概念。从大到小逐层顺次为Cloud(云)、Region(地区)、AZ(可用区)、Cluster(集群)，Bucket(桶)。能够用图阐明如下。里面一层能够包含一个或者多个外面一层。 上面以一朵云上面的多 Region 部署架构更为具体阐明，同一个 Region 外部的两个集群 Bucket 之间能够做同城容灾，两个不同 Rregion 外部的两个集群 Bucket 之间能够做异地容灾。 容灾状态依据用户不同的容灾场景需要，OSS 提供了不同的容灾状态，次要分为同城容灾，异地容灾(跨区域复制)，跨云复制和两地三核心 四种场景。当初别离一一介绍他们的特点。 1、同城容灾同城容灾的零碎架构如下所示： 集群 A 和集群 A' 别离部署在同一个 Region 的两个 AZ，集群布局时候这两个集群就被布局成互为容灾集群。当在任何一个集群创立 Bucket 时候，后盾都会为这个 Bucket 在两个集群之间开明好双向的数据复制边（也就是两条复制边），数据通过 Bucket 写入到任意一个集群，都能被 DRS 主动异步的复制到另外一个集群。当 Bucket所在的以后集群产生故障时候，能够通过运维平台一键切换将 Bucket 以后所在的集群切换到另外一个集群。因为 Bucket 的名字雷同，用户拜访 OSS 服务的 Endpoint 也雷同，因而用户不须要批改拜访 OSS 的域名；整个切换过程对用户通明，基本上不会影响到用户的业务。 ...

SRAM是随机存取存储器的一种。动态是指这种存储器只有放弃通电，外面贮存的数据就能够恒常放弃。当电力供应进行时，SRAM贮存的数据还是会隐没，这与在断电后还能贮存材料的ROM或闪存是不同的。SRAM不须要刷新电路即能保留它外部存储的数据。因而SRAM具备较高的性能，SRAM的速度快，个别用小容量的SRAM作为更高速CPU和较低速DRAM之间的缓存.SRAM也有许多种，如Async SRAM (异步SRAM）、Sync SRAM (同步SRAM）等。上面我司介绍一款4Mbit异步低功耗国产SRAM芯片EMI504HL08PM-55I 国产SRAM芯片EMI504HL08PM-55I应用EMI先进的全CMO工艺技术制作。工艺技术采纳 90nm Full CMOS ，位宽为512K x 8位，电源电压：4.5V ~5.5V。封装采纳32SOP，产品反对工业温度范畴和芯片级封装，以实现零碎设计的用户灵活性。同时还反对低数据放弃电压，以实现低数据放弃电流的电池备份操作。 封装引脚 对于安徽伟凌创芯（EMI）安徽伟凌创芯微电子有限责任公司是一家以市场为导向的无晶圆半导体公司。专一于利基市场（Niche market）专用SRAM芯片/小型SOC芯片及整体解决方案，第一代产品波及千兆/万兆USB网口芯片以及音视频接口芯片。提供翻新、高品质、高性价比、 供货继续稳固的芯片，并通过提供软硬件Turnkey solution，升高客户研发难度，缩短客户量产时程。产品畛域涵盖智能感知、网络可视化、信息化、信息安全、大数据分析、智能语音、利用展示、特种通信和智能建筑等。

简介：Apache Hudi 与 Apache Pulsar 联结 Meetup 杭州站来啦！将于 2021 年 8 月 28 日（周六） 13:30 ，在杭州召开，你筹备好了吗？本次 Meetup 由 StreamNative 联结阿里云组织发动，并邀请涂鸦智能、阿里云AnalyticDB数据仓库团队、Zoom等合作伙伴独特为大家出现，Apache Hudi 技术专家、Apache Pulsar PMC 成员、贡献者、社区技术专家汇聚一堂，独特探讨 Apache Hudi 与 Apache Pulsar 社区倒退、行业实际等话题。Apache Hudi 与 Apache Pulsar 联结 Meetup 杭州站来啦！将于 2021 年 8 月 28 日（周六） 13:30 ，在杭州正式召开，你筹备好了吗？ 对于Apache Hudi ：Apache Hudi是Apache 软件基金会顶级我的项目，是一个反对插入、更新、删除的增量数据湖解决框架；可助力构建高效的企业级数据湖。GitHub 地址：https://github.com/apache/hudi对于Apache Pulsar：Apache Pulsar是Apache 软件基金会顶级我的项目，下一代云原生分布式音讯流平台，集音讯、存储、轻量化函数式计算为一体，采纳计算与存储拆散架构设计，反对多租户、长久化存储、多机房跨区域数据复制，具备强一致性、高吞吐、低延时及高可扩展性等流数据存储个性。GitHub 地址：http://github.com/apache/pulsar/本次 Meetup 由 StreamNative 联结阿里云组织发动，并邀请涂鸦智能、阿里云AnalyticDB数据仓库团队、Zoom等合作伙伴独特为大家出现，Apache Hudi 技术专家、Apache Pulsar PMC 成员、贡献者、社区技术专家汇聚一堂，独特探讨 Apache Hudi 与 Apache Pulsar 社区倒退、行业实际等话题。 ...

简介：国内家居批发龙头企业竟然之家实现7大外围业务零碎全面上云工作，并实现ERP等外围业务零碎从传统商业数据库向阿里云PolarDB云数据库的替换，助力业务零碎整体解决能力晋升50%以上，弹性能力晋升3倍以上，大幅晋升应答相似双十一等大促的能力。 竟然之家是中国家居行业龙头，也是中国商业流通领域的知名品牌。截至2021年第一季度末，门店网络遍布全国29个省（市）自治区、270个城市，负责经营的家居卖场达393家，年销售总额最高超过850亿元。 随着竟然之家减速数字化转型，线上业务出现爆发式增长，自建IDC曾经难以满足理论业务倒退的须要，零碎每当面临业务顶峰，都须要提前破费大量的精力财力和工夫去做相应筹备。此外，竟然之家始终应用传统商业数据库来撑持ERP、POS等外围业务零碎，传统集中式部署、应用传统商业数据库带来的高IT建设老本、高并发撑持能力弱、弹性扩大能力弱、保护难度低等问题也逐渐裸露进去。 通过粗疏市场调研，竟然之家IT团队启动外围业务零碎全面上云工作，并决定引入阿里云PolarDB云原生数据库代替传统商业数据库。日前，通过多方团队继续攻坚，竟然之家7大外围业务零碎，超过110台服务器，10多个外围数据库集群，2.5TB数据顺利完成迁徙上云，以及云数据库的适配革新。 竟然之家IT负责人薄青松示意，外围业务零碎全面上云是一次微小的技术升级，通过本次降级解决了原有架构能力有余的卡点，对新批发的简单场景适配更强，同时升高了IT运维难度和经营老本，IT零碎的敏捷性和灵便扩大失去了质的晋升。特地是云原生数据库PolarDB的割接上线，大幅晋升了外围业务零碎的解决能力、弹性能力及扩大能力。 竟然之家董事长兼CEO汪林朋示意：“企业全面上云的趋势不可避免，咱们要被动拥抱这个趋势，实现技术底座的全面云化降级。短期看，上云有可能投入较多，但从长远看，将可能无效管制科技老本增长，撑持企业数字化转型策略真正落地。” 据理解，PolarDB是阿里云自研的云原生数据库，基于存储计算拆散架构设计，满足政企客户上云的需要。过来十多年，阿里云在产品技术畛域停顿迅猛，取得市场宽泛认可，并作为中国惟一的科技厂商胜利进入Gartner寰球数据库领导者象限。目前已有超过15万数据库客户迁徙到阿里云上，蕴含政务、批发、金融、电信、制作、物流等多个畛域的龙头企业。 ——起源：央广网 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

简介：CNFS 通过将阿里云的文件存储形象为一个 Kubernetes 对象（CRD）进行独立治理，包含创立、删除、形容、挂载，监控及扩容等运维操作，使用户能够在享受容器应用文件存储带来的便捷的同时，进步文件存储的性能和数据安全，并提供容器统一的申明式治理。对于 ACK CNFS传统的共享文件系统存在短少容量配额的准确管制、无奈复原误删文件、缺失存储卷容量性能等监控指标、无平安加密及小文件读写提早等问题。针对这些挑战，阿里云容器服务 ACK 推出了容器网络文件系统 CNFS，晋升NAS、OSS 及 CPFS 等文件系统的性能、QoS 管制。 CNFS 通过将阿里云的文件存储形象为一个 Kubernetes 对象（CRD）进行独立治理，包含创立、删除、形容、挂载，监控及扩容等运维操作，使用户能够在享受容器应用文件存储带来的便捷的同时，进步文件存储的性能和数据安全，并提供容器统一的申明式治理。 咱们举荐用户在 ACK 中应用 CNFS 治理 NAS，从而取得更好的性能和数据保护。 【体验】创立 ACK CNFS 集群，取得收费 NAS 存储空间 为了让更多企业、开发者疾速体验 ACK CNFS 带来的容器共享存储性能，ACK CNFS 正在限时凋谢 NAS 收费存储空间支付。 1、流动规定 本流动收费提供 5GB（容量型 NAS）或 1GB（性能型 NAS）的存储空间。每个地区最多可为两个 NAS 文件系统提供收费存储空间，每个账号最多 10 个收费空间可支付工夫：2021-07-01～2022-07-01有效期：1年2、支付形式 新创建 ACK（托管版） 集群用户 ：创立 ACK 集群时主动创立 CNFS 集群，随即取得绑定该集群的 5GB 容量型 NAS（或 1GB 性能型 NAS）已有 ACK（托管版）集群用户 ：可通过命令行创立CNFS，随即取得绑定该集群的 5GB 容量型 NAS（或 1GB 性能型 NAS）参考文档： https://help.aliyun.com/document\_detail/264679.html3、情谊提醒 ...

简介：2021 年 6 月 23 日，云原生计算基金会（CNCF）发表通过寰球 TOC 投票接收 KubeDL 成为 CNCF Sandbox 我的项目。KubeDL 是阿里开源的基于 Kubernetes 的 AI 工作负载治理框架，取自"Kubernetes-Deep-Learning"的缩写，心愿可能依靠阿里巴巴的场景，将大规模机器学习作业调度与治理的教训反哺社区。作者 | KubeDL 团队 2021 年 6 月 23 日，云原生计算基金会（CNCF）发表通过寰球 TOC 投票接收 KubeDL 成为 CNCF Sandbox 我的项目。KubeDL 是阿里开源的基于 Kubernetes 的 AI 工作负载治理框架，取自"Kubernetes-Deep-Learning"的缩写，心愿可能依靠阿里巴巴的场景，将大规模机器学习作业调度与治理的教训反哺社区。 我的项目地址：http://kubedl.io 我的项目介绍随着 TensorFlow, PyTorch，XGBoost 等支流 AI 框架的一直成熟，和以 GPU/TPU 为代表的多种AI异构计算芯片的井喷式涌现，人工智能正疾速进入“大规模工业化”落地的阶段。从算法工程师着手设计第一层神经网络构造，到最终上线服务于实在的利用场景，除 AI 算法的研发外还须要大量基础架构层面的零碎反对，包含数据收集和清理、分布式训练引擎、资源调度与编排、模型治理，推理服务调优，可观测等。如以下经典图例所展现，泛滥零碎组件的协同组成了残缺的机器学习流水线。 与此同时，以 Kubernetes 为代表的云原生技术蓬勃发展，通过优良的形象和弱小的可扩展性，将应用层与 IaaS（Infrastructure as a Service）层的基础设施完满解耦：利用可能以“云”的范式按需应用资源，无需关注底层基础设施的复杂性，从而解放生产力并专一于本身畛域的翻新。 Kubernetes 的呈现解决了云资源如何高效交付的问题，但对于 AI 这类自身具备高度复杂性的工作负载还无奈做到很好地原生反对，如何整合各类框架的差别并保留其通用性，同时围绕 AI 工作负载的运行时去建设一系列欠缺的周边生态及工具，业界还在一直摸索与尝试。在实践中，咱们发现了 AI 负载运行在 Kubernetes 生态中面临着如下挑战： 机器学习框架百花齐放，各自有不同的优化方向和实用场景，但在分布式训练作业的生命周期治理上又存在着诸多共性，同时针对一些高级个性也有雷同的诉求（如网络模式，镜像代码拆散，元数据长久化，缓存减速等）。为每类框架的负载独自实现 operater，各自独立过程无奈共享 state，不足全局视角，使得全局 Job 层面的调度以及队列机制难以实现。此外，不利于性能的形象和复用，在代码层面存在重复劳动。原生 Kubernetes 无奈满足离线工作多样的调度需要。Kubernetes 面向 Pod 调度的模型人造实用于微服务等 Long Running 的工作负载，但针对离线工作的高吞吐，Gang Scheduling 调度（All-Or-Nothing），Elastic Capacity 等多种调度诉求，社区演进出了多种调度计划。以机器学习分布式训练作业调度场景中极为常见的Gang Scheduling为例，社区目前就有YuniKorn，Volcano，Coscheduling 等调度器实现，提供不同的交互协定，咱们须要有插件化的伎俩来启用对应的调度协定。同时，像 PS/worker 这类依据业务特有属性，不同 role 之间有启动依赖的 DAG 编排诉求，须要在控制器中实现；分布式训练的后果往往以模型作为 output，并存储在分布式文件系统中如(阿里云 OSS/NAS)，但如何从训练作业的视角去治理模型，像容器镜像那样成为AI服务的“不可变基础设施”并实现简略且清晰的版本治理与追溯，业界还不足最佳实际。同时，“训练”与“推理”两个阶段绝对独立，算法科学家视角中的“训练->模型->推理”机器学习流水线不足断层，而“模型”作为两者的两头产物正好可能充当那个“承前启后”的角色；分布式训练尚能鼎力出奇观，但推理服务的规格配置却是一个精密活。显存量、 CPU 核数、BatchSize、线程数等变量都可能影响推理服务的品质。纯正基于资源水位的容量预估无奈反映业务的实在资源需要，因为某些引擎如 TensorFlow 会对显存进行预占。实践上存在一个服务质量与资源效力的最优平衡点，但它就像光明中的幽灵，明晓得它的存在却难以推敲。随着 GPU 虚拟化技术的成熟，这个平衡点的价值越来越凸显，更优的规格能显著提供单 GPU 卡的部署密度，节约大量的老本。推理服务自身是一种非凡的 long running 微服务状态，除了根底的 deployment 外，针对不同的推理场景还欠缺一些实例与流量的管理策略，如： ...

简介：作为业界少有的EB级数据分布式平台，MaxCompute每天撑持上千万个分布式作业的运行。这些作业特点各异，既有蕴含数十万计算节点的超大型作业，也有中小规模的分布式作业。不同用户对于不同规模/特点的作业，在运行工夫，资源应用效率，数据吞吐率等方面，也有着不同的期待。DAG作为MaxCompute执行引擎的核心技术之一，在提供了底层对立的动静执行框架的同时，实现了一个在离线混合的执行模式(Bubble Execution)，达到了均衡极致性能以及高效的资源利用率的目标。作为业界少有的EB级别数据分布式平台，MaxCompute零碎每天撑持上千万个分布式作业的运行。在这个量级的作业数目上，毫无疑问平台须要撑持的作业特点也多种多样：既有在"阿里体量"的大数据生态中独有的蕴含数十万计算节点的超大型作业，也有中小规模的分布式作业。同时不同用户对于不同规模/特点的作业，在运行工夫，资源应用效率，数据吞吐率等方面，也有着不同的期待。 Fig.1 MaxCompute线上数据分析 基于作业的不同规模，以后MaxCompute平台提供了两种不同的运行模式，下表对于这两种模式做了总结比照: Fig.2 离线(batch)模式 vs 一体化调度准实时(smode)模式 从上图能够看到，离线作业和一体化调度的准实时作业，在调度形式，数据传输，应用资源起源等多个方面，都有十分显著的区别。能够说，这两种运行形式别离代表了在海量数据场景上按需申请资源来优化吞吐量和资源利用率，以及在解决中等(大量)数据时通过计算节点的全量预拉起来(以及数据直传等伎俩减速)升高执行时延的两个极其。而这些区别，最终会通过执行工夫和作业资源利用率等方面体现进去。很显然，以高Throughput为次要优化指标的离线模式，和以谋求低Latency的准实时模式，在各方面的性能指标会有很大的区别。比方以1TB-TPCH规范benchmark为例，此报告执行工夫(性能)和资源耗费两个维度来做比拟。能够看到，准实时的(SMODE)在性能上有着非常明显的劣势(2.3X)，然而这样的性能晋升也并不是没有代价的。在TPCH这个特定的场景上，一体化执行的SMODE模式，在获取了2.3X性能晋升的同时，也耗费了3.2X的系统资源(cpu * time)。 Fig.3 性能/资源耗费比拟：离线(batch)模式 vs 一体化调度准实时(smode)模式 这个察看论断其实并不意外，或者从某种程度上是by design的。拿下图一个典型SQL产生的DAG来看，所有计算节点都在作业提交伊始就被拉起，尽管这样的调度形式容许数据得以(在须要的时候)pipeline起来，从而可能减速数据的解决。但并不是所有的执行打算里的所有上下游计算节点都能够有理想化的pipelined dataflow。事实上对于许多作业而言，除了DAG的根节点(下图中的M节点)以外，上游的计算节点在某种程度上都存在着肯定水平的节约。 Fig.4 一体化调度准实时(smode)模式下，可能的资源应用低效 这种空转造成的资源应用的低效，在数据的解决流程上存在barrier算子而无奈pipeline，以及在DAG图比拟深的状况下会尤为显著。当然对于心愿极致优化作业运行工夫的场景而言，通过更多的资源耗费，来获取极致的性能优化，在一些场景上是有其合理性的。 事实上，在一些business-critical的在线服务零碎中，为了保障服务总是能迅速响应并解决峰值数据，均匀个位数的CPU利用率也并非少见。然而对于计算平台这种量级的分布式系统，是否在极致性能以及高效的资源利用率之间，获取一个更好的均衡呢？ 答案是必定的。这就是咱们在这里要介绍的混合计算模式：Bubble Execution 1. Bubble Execution 概述DAG框架的外围架构思维，在于对执行打算的逻辑层与物理层的清晰分层设计。物理执行图是通过对逻辑图中的节点、边等的物理个性(如数据传输介质，调度机会，资源个性等)的物化来实现的。比照在Fig.2中形容的batch模式和smode模式，DAG提供了在一套灵便的调度执行框架之上，对立离线模式和准实时一体化执行模式的实现。如同下图所示，通过调整计算节点和数据连贯边的不同物理个性，不仅能对现有的两种计算模式做清晰的表述，在对其进行更通用化的扩大后，还能够摸索一种全新的混合运行模式，也就是Bubble Execution。 Fig.5 DAG框架上的多种计算模式 直观上来了解，如果咱们把一个Bubble当作一个大的调度单位，Bubble外部的资源一起申请运行，并且外部上下游节点的数据均通过网络/内存直连传输。与之绝对的，Bubbles之间连贯边上的数据传输，则通过落盘形式来传输。那么离线和准实时作业执行，其实能够认为是Bubble执行的两个极其场景：离线模式能够认为是每个stage都独自作为single-bubble的特例，而准实时框架则是将作业所有计算节点都布局到一个大Bubble外部，来做一体化调度执行的另一个极其。DAG AM曾经将两种计算模式对立到一套调度执行infra之上。使得在两种模式上进行长处互补成为可能，为引入Bubble Execution奠定了根底。 Bubble Execution通过灵便自适应的子图(Bubble)切割，在现有的两个极其之间，提供了一种选取更细粒度，更通用的调度执行办法，达到作业性能和资源利用率之间获取优化的tradeoff的办法。在依据输出数据量、算子个性、作业规模等信息进行剖析后，DAG的Bubble执行模式能够将一个离线作业切分出多个Bubbles，在Bubble外部充分利用网络/内存直连和计算节点预热等形式晋升性能。这种切分形式下，一个DAG运行图中的计算节点，能够都被切入某个Bubble，依据所在DAG中的地位被切入不同Bubbles，还能够齐全不被切入任何Bubble(仍然以传统离线作业模式运行)。这种高度灵便的混合运行模式，使整个作业的运行能更加灵便的自适应线上多种多样作业的特点，在理论生产中具备重要的意义： Bubble模式使更多作业的减速成为可能：一体化调度的准实时作业具备基于整体规模（线上默认2000）的"一刀切"式的准入条件。这一方面是出于无限资源的偏心应用，另一方面也是为了管制节点failure带来的cost。但对于中大型作业，尽管整体规模可能超过准入门限，然而其外部的不同子图，有可能是规模适合，且能够通过数据pipeline等办法来减速的。此外线上局部计算节点因为其自身的个性（比方蕴含UDF等用户逻辑须要平安沙箱），无奈应用预热的准实时资源池执行，而以后非黑即白的模式，会使得一个作业中，只有蕴含一个这种计算节点，整个作业都无奈应用减速模式执行。Bubble模式能较好的解决这些问题。Bubble模式将enable线上两个资源池的买通：以后离线资源(cold)和准实时资源池(warm)作为两种个性不同的线上资源，齐全隔离，各自治理。这种拆散的现状，可能导致资源的节约。比方对于大规模作业，因为齐全无奈利用准实时资源池，排队期待离线资源，而同时准实时资源池可能正处于闲暇状态，反之亦然。Bubble模式能通过在作业外部拉通不同资源的混合应用，使得两者各自补充，削峰填谷。Bubble模式能够整体上进步资源的利用率：从资源利用的角度来看，对于能够满足准实时模式准入的中型作业，因为准实时模式一体式调度拉起的运行模式，尽管运行速度能有所晋升，但主观上会造成肯定水平资源的空转与节约（尤其是DAG图较深以及计算逻辑有barrier时）。这种状况下，依照节点数目，计算barrier等条件，将一体化模式拆解成多个Bubble。这可能无效的缩小节点大量的空转耗费，而且在拆分条件正当的状况下，性能方面的损失也能够做到较低。Bubble模式能无效升高单个计算节点failure带来的代价：一体化的准实时模式执行，因为其数据pipeline的个性，作业的容错粒度和其调度粒度是严密挂钩的：都是all-in-one。也就是说，只有有一个节点运行失败，整个作业都要从新运行。因为作业规模越大，运行过程中可能有节点失败的概率也就越大，这样的failover粒度无疑也限度了其能反对的最大作业规模。而Bubble模式则提供了一个更好的平衡点：单个计算节点的失败，最多只影响同处于一个Bubble的节点。此外Bubble模式对于各种failover做了细粒度的各种解决，咱们将在下文形容。咱们能够通过规范的TPCH-1TB测试benchmark来直观评测Bubble执行模式的成果。在下层计算引擎(MaxCompute优化器以及runtime等)放弃不变，并且Bubble的大小维持在500（具体Bubble切分规定下文介绍）时，做一下Bubble执行模式与规范离线模式，以及准实时模式，在性能(Latency) 以及资源耗费(cpu * time)两个方面的比拟： Fig.6.a 性能(Latency)比拟：Bubble模式 vs 离线(batch)模式 vs 一体化调度准实时(smode)模式 从运行工夫来看，Bubble模式显然要远优于离线模式(整体2X的性能晋升)，而较准实时的一体化调度模式而言，Bubble的执行性能也并没有太显著的降落。当然在一些数据能够十分无效利用pipeline解决的query（比方Q5, Q8等），准实时作业还是有肯定的劣势。但SMODE作业在执行工夫上的劣势并不是没有代价的，如果同时思考资源耗费，在下图中，咱们能够看到，准实时作业的性能晋升是建设在资源耗费远远大于Bubble模式的前提之上的。而Bubble在性能远优于离线模式的同时，其资源耗费，则整体上是相近的。 Fig.6.b 资源耗费(cpu * time)比拟： Bubble模式 vs 离线(batch)模式 vs 一体化调度准实时(smode)模式 综合起来看，Bubble Execution能够很好的联合batch模式和准实时模式的长处： 在执行工夫层面，对于TPCH测试集中的任意query，bubble模式的执行工夫都比batch模式要短，整体上22个Queries总耗时缩减将近2X，靠近service mode模式的耗时；在资源耗费层面，bubble模式基本上和batch模式相当，相比于service mode模式有大幅度的缩小，整体缩减2.6X。 ...

简介：随着容器技术蓬勃发展与落地推广，越来越多企业的业务运行于容器中。作为支流部署形式之一，容器将团队的工作和关注点宰割开，开发团队只需关注利用程序逻辑和依赖项，而运维团队只需关注部署和治理，无需再为特定软件版本和应用程序特定配置等应用程序细节而胆战心惊。这意味着开发团队和运维团队能够破费更少工夫进行调试上线，将更多工夫用于向最终用户交付新性能。容器使企业能够更加轻松的进步应用程序可移植性和操作弹性。据 CNCF 的调研报告显示，73% 受访者正在应用容器来进步生产敏捷性并放慢翻新速度。作者 | 白玙 随着容器技术蓬勃发展与落地推广，越来越多企业的业务运行于容器中。作为支流部署形式之一，容器将团队的工作和关注点宰割开，开发团队只需关注利用程序逻辑和依赖项，而运维团队只需关注部署和治理，无需再为特定软件版本和应用程序特定配置等应用程序细节而胆战心惊。这意味着开发团队和运维团队能够破费更少工夫进行调试上线，将更多工夫用于向最终用户交付新性能。容器使企业能够更加轻松的进步应用程序可移植性和操作弹性。据 CNCF 的调研报告显示，73% 受访者正在应用容器来进步生产敏捷性并放慢翻新速度。 为什么咱们须要容器监测在大规模应用容器过程中，面对高动静且须要继续监测的容器化环境，建设监测体系对于维持运行环境稳固、优化资源老本具备微小意义。每个容器镜像可能有大量运行实例，因为新镜像和新版本的引入速度很快，故障很容易通过容器、应用程序和架构扩散。这使得在问题产生后，为了避免异样扩散，立刻进行问题根因定位变得至关重要。通过大量实际，咱们认为在容器应用过程中，以下组件的监测至关重要： 主机服务器；容器运行时；Orchestrator 管制立体；中间件依赖；在容器内运行的应用程序。在残缺的监测体系下，通过深刻理解指标、日志和链路，团队不仅能够理解在集群以及在容器运行时和应用程序中产生的事件，也能够为团队进行业务决策时提供数据反对，比方何时扩大/缩减实例/工作/Pod、更改实例类型。DevOps 工程师还能够通过增加自动化告警以及相干配置，来进步故障排除以及资源管理效率，比方通过被动监测内存利用率，当资源耗费靠近所设定的阈值时告诉运维团队对可用 CPU 、内存资源耗尽之前增加额定节点。这其中的价值包含： 及早发现问题，以防止零碎中断；跨云环境剖析容器健康状况；辨认调配过多/有余的可用资源的集群，调整应用程序以取得更好性能；创立智能警报，进步报警精准率，防止误报；借助监测数据进行优化，获得最佳零碎性能，升高经营老本。但在理论落地过程中，运维团队会感觉以上价值绝对通俗，仿佛现有运维工具都能达到上述目标。但针对容器相干场景，如果无奈构建相应监测体系，随着业务一直扩张，就不得不面临以下两个十分辣手的针对性问题： 1、排障工夫拖长，SLA 无奈满足。开发团队与运维团队很难理解正在运行的内容及其执行状况。保护应用程序、满足 SLA 和故障排除异样艰难。 2、可扩展性被连累，无奈实现弹性。按需疾速扩大应用程序或微服务实例的能力是容器化环境的重要要求。监测体系是掂量需要和用户体验的惟一可视化办法。扩大太晚，导致性能与用户体验的降落；过晚放大规模，又会导致资源以及老本的节约。 因而，当容器监测的问题以及价值，一直叠加且浮出水面，越来越多运维团队开始器重容器监测体系的搭建。但在理论落地容器监测这一过程中，又遇到各种各样意料之外的问题。 比方短暂存在个性带来的跟踪艰难，因为容器本身存在着复杂性，容器不仅蕴含底层代码，还蕴含利用程序运行所需的所有底层服务。随着新部署投入生产，并更改代码和底层服务，容器化应用程序会频繁更新，这就减少了出错的可能。疾速创立、疾速销毁的个性，使得在大规模简单零碎中跟踪变动变得异样艰难。 又比方，因为共享资源带来的监控艰难，因为容器应用的内存和 CPU 等资源在一台或多台主机之间共享，因而很难监控物理主机上资源耗费状况，也导致很难取得容器性能或应用程序健康状况的良好批示。 最初，就是传统工具难以满足容器监测需要。传统的监测解决方案通常不足虚拟化环境所需的指标、跟踪和日志所需的工具，容器的衰弱和性能指标及工具更是如此。 因而，联合以上的价值、问题、难点，咱们在建设容器监测体系时，须要从以下几个维度进行考量与设计： 无侵入性：监测SDK或者探针集成到业务代码是否存在侵入性，影响业务稳固下；整体性：是否能够观测整个应用程序在业务和技术平台方面的体现；多源性：是否能够从不同数据源获取相干指标和日志集进行汇总显示、剖析和警报；便捷性：是否能够关联事件和日志，发现异常并主被动地排除故障并升高损失，相干告警策略配置是否便捷。在明确业务需要以及设计监测体系过程中，有十分多开源工具供运维团队抉择，但运维团队还须要评估可能存在的业务与项目风险。这其中包含： 存在影响业务稳定性的未知危险，监测服务是否能够做到“无痕”。监测过程自身是否影响零碎失常运作。开源或自研的人力/工夫投入难以预计，关联组件或资源须要自行配置或搭建，不足相应反对与服务，随着业务一直变动，是否可能消耗更多人力及工夫老本。且面对大规模场景下性能问题，开源或企业自有团队是否能够疾速应答。阿里云 Kubernetes 监测：让容器集群监测更直观、更简略因而，基于上述洞察考量与大量实践经验，阿里云推出Kubernetes 监测服务。阿里云 Kubernetes 监测是一套针对 Kubernetes 集群开发的一站式可观测性产品。基于 Kubernetes 集群下的指标、利用链路、日志和事件，阿里云 Kubernetes 监测旨在为 IT 开发运维人员提供整体的可观测性计划。阿里云 Kubernetes 监测具备以下六大个性： 代码无侵入：通过旁路技术，无需代码埋点，即可获取到网络性能数据。多语言反对：通过内核层进行网络协议解析，反对任意语言及框架。低耗高性能：基于 eBPF 技术，以极低消耗获取网络性能数据。资源主动拓扑：通过网络拓扑，资源拓扑展现相干资源的关联状况。数据多维展示：反对可观测的各种类型数据（监测指标、链路、日志和事件）。打造关联闭环：残缺关联架构层、应用层、容器运行层、容器管控层、根底资源层相干可观测数据。与此同时，绝对于与开源容器监测，阿里云 Kubernetes 监测具备更加贴近业务场景的差异化价值： 数据量无上限：指标、链路、日志等数据独立存储，借助云存储能力确保低成本大容量存储。资源高效关联交互：通过监测网络申请，残缺构建网络拓扑，便于查看服务依赖状态，晋升运维效率。除了网络拓扑之外，3D 拓扑性能反对同时查看网络拓扑和资源拓扑，晋升问题定位速度。多样化数据组合：指标、链路、日志等数据可视化展现并自由组合，开掘运维优化点。构建残缺监测体系：与利用实时监测服务的其余子产品，独特构建残缺监测体系。利用监测关注利用语言运行时、利用框架与业务代码；Kubernetes 监测关注容器化利用的容器运行时、容器管控层与零碎调用，两个监测均服务于利用，关注利用的不同档次，两个产品互为补充。Prometheus 是指标采集，存储，查问的基础设施，利用监测与 Kubernetes 监测的指标类数据均依赖 Prometheus。 基于以上产品个性与差异化价值，咱们利用在以下场景： 通过 Kubernetes 监测的零碎默认或者自定义巡检规定，发现节点，服务与工作负载的异样。Kubernetes 监测从性能、资源、管控三个维度对节点、服务与工作负载进行异样巡检，将剖析后果直观地通过失常、正告、重大等状态配合特定色彩进行展现，帮忙运维人员直观感知用户节点，服务与工作负载运行状态。 应用 Kubernetes 监测定位服务与工作负载响应失败根因，Kubernetes 监测通过剖析网络协议对失败申请进行明细存储，利用失败申请指标关联的失败申请明细定位失败起因。应用 Kubernetes 监测定位服务与工作负载响应慢根因，Kubernetes 监测通过抓取网络链路要害门路的指标，查看 DNS 解析性能，TCP 重传率，网络包 rtt 等指标。利用网络链路要害门路的指标定位响应慢的起因，进而优化相干服务。 ...

简介：点击链接，动动手指获取白皮书～另外，实时数仓 Meetup 议题征集中！GitHub 地址  https://github.com/apache/flink 欢送大家给 Flink 点赞送 star~ 7 月 24 日，Apache Flink 社区与 PingCAP 在 DevCon 2021 技术峰会上联结公布了「基于 TiDB 与 Flink 的实时数仓最佳实际白皮书」，为企业用户构建实时数仓，应答实时洞察挑战提供最佳实际指南。 「基于 TiDB 与 Flink 的实时数仓最佳实际白皮书」下载 https://flink-learning.org.cn/ 随着数字化过程的减速，越来越多的企业正面临前所未有的数据规模挑战；日趋加剧的商业竞争，也使得内部用户和公司外部决策者都无奈依赖传统时效性不佳的离线数据分析；海量，实时，在线的数字化新常态须要更实时的数据分析，甚至是对正在产生的交易数据进行剖析，以撑持更加麻利的商业决策。 Apache Flink PMC & 阿里巴巴资深技术专家杨克特受邀缺席，并在白皮书公布典礼上示意，Apache Flink 是一个面向分布式数据流解决和批量数据处理的开源计算平台，能够反对低提早、高吞吐、高性能的流解决，广泛应用于高实时性场景下的实时计算。 PingCAP 社区事业部总经理姚维示意，TiDB 是一款当先的具备残缺 HTAP 能力的企业级分布式数据库，能够在一份数据源上同时撑持在线事务处理 (OLTP) 和在线剖析解决 (OLAP) 场景，岂但能良好地反对实时数据落地存储，也能够提供一体化的剖析能力。 借助 Flink 杰出的流批一体技术，TiDB 与 Flink 一起摸索为用户构建一个实时数仓最佳实际计划，满足了用户实时洞察实时决策的剖析需要。本次公布的 「TiDB & Flink 实时数仓最佳实际白皮书」，交融了单方的技术劣势，能够为用户提供一栈式实时数据仓库最佳实际，反对企业进行实时数据分析，助力麻利的商业决策。 开源是以后全球化背景下根底软件畛域胜利的最佳门路。Flink 间断 3 年蝉联寰球最沉闷的 Apache 开源我的项目，领有超过 20W 开发者关注。不仅如此，Flink GitHub 的星数和 Flink 的社区代码贡献者数量，在过来数年中始终放弃年均 30%+ 的增长。 ...

简介：本文将介绍AnalyticDB PostgreSQL版备份复原的原理与应用办法。一、背景AnalyticDB PostgreSQL版（简称ADB PG）是阿里云数据库团队基于PostgreSQL内核（简称PG）打造的一款云原生数据仓库产品。在数据实时交互式剖析、HTAP、ETL、BI报表生成等业务场景，ADB PG都有着独特的技术劣势。 作为一款企业级数据仓库产品，数据安全的重要性显而易见。备份复原性能是保障数据安全的根本伎俩，也是ADB PG应答突发状况进行数据库复原的重要保障。备份复原，顾名思义，是对数据库进行数据备份，以便在必要时进行数据的复原，防备于未然。以后，ADB PG的备份复原性能曾经利用在以下各个用户场景中： 因为系统故障、人为误操作造成数据被毁坏或实例不可用时，基于备份数据对实例进行复原。用户须要基于已有实例，疾速克隆出一个完全相同的实例。在节点数不变的前提下，用户须要更改源实例的规格。本文将介绍ADB PG备份复原的原理与应用办法。 二、简介ADB PG 是采纳MPP程度扩大架构的分布式数据库。ADB PG实例由一个或多个协调节点(Master)和多个计算节点(Compute Node)组成，协调节点负责接管用户申请，制订分布式执行打算并下发至计算节点，收集执行后果并返回给客户端；计算节点负责并行计算剖析与数据存储。数据在计算节点之间能够随机、哈希、复制散布。下图ADB PG的架构图: ADB PG的物理备份复原性能，基于集群的根底备份和日志备份，能够在分布式数据库持续提供服务的同时备份各个节点的数据，并保证数据的一致性。在须要时，能够将分布式数据库复原至备份的时刻。 根底备份是指对数据库所有数据进行的一个齐全拷贝。根底备份会将集群全量数据快照压缩后存储在其它离线存储介质，集群在根底备份期间不会阻塞用户的读写，因而，备份期间产生的日志也会被备份来保障根底备份的完整性。 日志备份(也称为增量备份)，是指将集群产生的日志文件备份至其余离线存储介质。日志文件记录了用户对数据库的DML与DDL操作。通过一个残缺的根底备份以及间断的日志备份，能够将新集群复原到某一历史事件点，保障了这段时间的数据安全性。 ADB PG可保障最小RPO为10分钟的备份复原。 三、原理在残缺地介绍ADB PG的备份复原原理之前，先简要地介绍单机PG的PITR(Point in Time Recovery)备份复原机制。ADB PG的备份复原机制基于单机PG的PITR原理，并退出了分布式数据一致性的保障机制。 （一）单机PG的PITR机制WAL日志： PostgreSQL数据库会将事务对数据的所有更改(包含DDL、DML等操作)记录在WAL(Write Ahead Log)日志文件中。WAL日志文件能够看作是一个有限增长的只追加文件，PG会将日志数据按固定大小切分成多个文件存储。事务的每次批改数据的操作都会被追加记录至WAL文件中，并赋予一个惟一的LSN序号(Log Sequence Number)，在事务提交时，会保障WAL日志已长久化。 这些日志文件的作用是为了让数据库在须要复原时，能够通过“重放”WAL日志来复原数据库解体时还未长久化，但对应事务已提交的数据。 复原点： 有了WAL日志能够进行“重放”操作，那么还有一个问题：须要重放到什么时候呢？这就须要复原点(restore point)来解决。 复原点相当于WAL日志中写入的一个标记，它标记了一个日志的地位。当PG对日志进行重放时，通过查看是否曾经达到这个标记点，来决定是否须要进行"重放"的操作。 以下SQL能够在WAL日志文件中创立一个名为t1的标志点： postgres=# select pg_create_restore_point('t1');LOG: restore point "t1" created at 0/2205780STATEMENT: select pg_create_restore_point('t1'); pg_create_restore_point------------------------- 0/2205780(1 row)当数据库程序回放WAL日志时，会查看以后日志蕴含此复原点名称，若已蕴含，则进行重放。另外，PG还反对复原至指定的任意工夫点，事务号，LSN序号等操作。 根底备份与增量备份： 根底备份是对数据库数据的一份残缺拷贝。能够应用pg\_basebackup工具对单机PG进行一次根底备份，备份数据可保留至本地，也可存储在其余离线存储介质(OSS)中。 $ pg_basebackup -D pg_data_dir/ -p 6000NOTICE: pg_stop_backup complete, all required WAL segments have been a增量备份是指对产生的WAL日志文件进行备份。在PG中，可通过数据库参数archive\_command来指定如何备份WAL日志数据。当PG生成一个WAL日志文件时，会通过执行archive\_command的命令来尝试备份归档该日志文件。比方，如下命令会将日志文件发送至指定的OSS。 ...

简介：Serverless 的呈现给传统企业数字化转型带了更多时机。某零售商超行业的龙头企业，其次要业务涵盖购物中心、大卖场、综合超市、规范超市、精品超市、便利店及无人值守智慧商店等零售业态，波及全渠道批发、仓储物流、餐饮、生产服务、数据服务、金融业务、跨境贸易等畛域。为了继续反对业务高速且稳固地倒退，其在疾速上云后，将外围业务革新为全 Serverless 架构的中台模式，采纳函数计算 + API 网关 + 表格存储 OTS 作为计算网络存储外围，弹性撑持日常和大促峰谷所需资源，轻松撑持 618/ 双 11/ 双 12 大促。 传统企业为什么更须要关注 Serverless为了升高技术研发老本、晋升运维效率，越来越多的企业抉择应用 Serverless 作为根底研发底座，大力发展业务。在 CNCF Serverless 钻研报告中显示，大量的国内开发人员正在将传统架构往 Serverless 上做迁徙。Serverless 的呈现给传统企业数字化转型带了更多时机。 现如今，大量尖端技术人才更偏差在互联网公司待业，传统企业又面对着大量技术升级和重构技术架构的刚需，人才缺口和技术升级之间产生了对云原生技术的需要。Serverless 的呈现抹平了研发人员在估算、运维教训上的有余。在帮忙企业反抗业务洪峰的状况下，研发人员能轻易掌控解决，不仅极大地升高了研发技术门槛，而且大规模晋升了研发效率。对于开发者而言，线上预警、流量观测等工具一应俱全，要害是免去了运维累赘，切实为宽广开发者提供了普惠技术红利。对传统企业而言，Serverless 缩短了互联网公司与传统企业之间技术竞争力的间隔。 从上云到云原生2016 年当前，随着国内公共云的迅速倒退，全面上云势不可挡。某出名大型商场在 2018~2019 年期间，把自建机房中的各个系统模块逐步迁徙到了私有云，整体架构没有太大扭转，因而迁徙工作比较顺利。 零碎全面迁徙上云后一些改良和有余不再须要关怀网络、操作系统的硬件细节比方阿里云的 ECS 会提前做调度和预警，把用户数据转移并做多份数据的备灾，避免磁盘坏掉的状况产生。 降级快捷简略比方用户应用的是 4 核的机器，当发现业务增长迅速须要做硬件降级时，就只须要做一个镜像。比方在夜间做一个磁盘快照，从新申请一台新机器，而后把快照复原下来，就能够实现一键迁徙。对用户来说这是十分快捷的形式，对开发者来说也是较好的体验。 机器扩容工夫大幅缩短下面提到的是单机扩容，比方 4 核升到 8 核、16G 升到 32G 的内存。除此之外还有横向的扩容，例如用户交易系统的 API 接口，随着业务的倒退须要由原来的 2 台机器扩到 8 台机器，这种状况下用户只需去申请机器，而后将镜像扩大到不同的机器上即可。 资源估算艰难无奈预估业务遇到大促流动时所能达到的体量，因而无奈精确计算出所需硬件的数量。 程度扩大程度扩大对研发有较高的要求。比方数据是否要做到无状态，无状态的话程度扩大会比拟容易，而如果是有状态，数据可能就须要做缓存，这就会波及到数据库相干的问题，例如数据过期、一致性等。如果对这些理解不够透彻，做程度扩大就会比拟艰难。 水位监控许多开发者在水位监控上解决得并不欠缺，如果将各个业务零碎混在一台机器上，当遇到机器水位较高，想要疾速排查问题并及时进行流控、拆分、长期修复等就显得尤为艰难。 财务预算艰难与资源估算艰难相似。 硬件降级老本高要做到用户无感无损降级，可能会波及到连贯上的解决与数据库一致性的问题。如果多个模块须要同时降级，还要留神数据结构的兼容问题。 数据库单点故障许多厂家将数据全副放在一个数据库中，如果解决不得当可能会造成单点故障。这就要做数据拆分，粗拆的话，须要留神事务和锁相干的问题，效率会大打折扣；细拆的话，做查问和排序时就会比拟艰难，给业务实现造成肯定麻烦。 业务挑战在一次年中大促时，因为线上业务用户拜访不可控，数据量过大，MySQL 单机拜访被打爆，导致了存储数据库呈现问题，影响到了多个零碎，造成了肯定的损失。因而在后续服务化革新过程中，数据库选型由 MySQL 更改为表格存储 OTS，表格存储最大的长处是用户不须要关怀访问量和机器数的比例关系。只有访问量扩充，后盾会主动扩容增扩机器，满足高并发的数据读取；在数据并发申请升高处于低峰期时，后盾就会将机器回收，用户不再须要关怀机器的数量及如何调动。 Serverless 革新 针对用户流量不可控问题，客户引入了阿里云的产品 “API 网关” ，API 网关能够针对不同渠道商做管控公布及流量管制。比方发现微信渠道流量有异样，就能够借助 API 网关进行限流。 ...

简介：有一群人尽管是应届毕业生，但手里我的项目不少，教训不浅，出身名校，将来可期。属于经常出现在新闻里的“他人家的孩子”边远而神秘。为了打消这种神秘，咱们采访了一位理工迷信霸。过后他退出阿里的时候，就拿到了阿里的“最强offer”—— “阿里星”。他就是阿里云数据库技术专家谢小龙。近几年互联网行业人才济济，每年春招秋招的时候，各大厂使出浑身解数网罗人才。 有一群人尽管是应届毕业生，但手里我的项目不少，教训不浅，出身名校，将来可期。属于经常出现在新闻里的“他人家的孩子”边远而神秘。 为了打消这种神秘，咱们采访了一位理工迷信霸。过后他退出阿里的时候，就拿到了阿里的“最强offer”—— “阿里星”。 阿里星缘起于2011年，为的是吸引最年老最顶级的人才，每年几十万工科毕业生中，能拿到阿里星offer的只有几个人。他们大都来自顶级学府，手握大量顶会论文和实习经验才有机会加入面试，而后乘风破浪通过十几轮面试，能力胜利拿到这份大佬带队、年薪上不封顶的阿里“最强offer”。 他就是阿里云数据库技术专家谢小龙。 本文依据采访内容整顿而成，点击链接即可观看残缺采访视频：游戏少年→北大毕业年薪百万：致力自身就挺难 网瘾少年上北大谢小龙，16岁考入北京大学。在他高考考数学的时候，数学答题卡填错了，但在那年物理较难的状况下，以物理满分的劣势，取得了较好的总成绩，压线考入北大。在于谢小龙交换的过程中咱们得悉，他的家庭对他始终都是齐全放养式的，他还虚心的称说本人为“走地鸡”。 “我不是特地置信智商这一说法。在学习过程中，我发现自己的记忆力比拟差，特地容易忘记知识点，所以我须要把那些知识点拿进去重复观看，保障本人不会遗记。”他认为，除了真正智商超群的人，他和其余大多数问题好的人一样，还是因为他本身花了更多的工夫在学习上。 然而，这位记忆力比拟差的人，在高中的时候尤其是高一、高二阶段，还是一名沉迷游戏的网瘾少年。这让咱们很好奇，是在什么样的契机之下，让他高中后半段的问题突飞猛进。趁着这次采访，咱们也提出了本人的疑难。对此，谢小龙也给出精确的回答：就是感觉游戏玩腻了，就开始好好学习了。一朝顿悟，谢小龙的学习思维和之前相比产生了很大的扭转，他将这种扭转称之为“口头”。他认为口头是最重要的一件事。他说比如说我明天做了十道题，有两道题不会，以前的话我就会通知本人“算了算了”、“差不多得了”。但“觉悟”之后是“这两道题我要想方法弄明确，我要去看书，要去问他人，看看到底为什么这样。”其实，当一个人认真起来做事，真的就齐全不一样，这是一种正向反馈。 在高中的前期，谢小龙在和宿管阿姨磋商后，每天晚上熄灯之后都会去楼下大厅持续学习，在他高三最疯狂的时候，每天只睡四五个小时，只有生病的时候才好劳动。“因为每个人的状况不同，我前半段落下的货色太多，前面天然要花更多工夫去补。”谢小龙说：“我感觉很多时候不是有效致力的问题，而是致力自身就是一件十分艰难的事件，不仅须要工夫，也须要天才。致力不仅仅是简略的花工夫就行，而是每天都须要长时间放弃精力的高度集中。” 因为本身的经验，面对读高二、明年高考的同学时，对于有些老师说高三曾经不太有机会提分了，谢小龙提出了其余的认识。他说：“高考，一是看你把握的知识点够不够多，二是看你做题够不够纯熟。其实那些题目没有特地难的，给你足够多的工夫，你每道题都能做得进去。我认为想要进步问题，首先第一件事件是你要搞明确本人的问题为什么没有达到预期，是哪一科的问题还是哪些知识点模块儿的问题。第二件事件是针对本人的弱点，去制订一些有针对性的学习打算。第三件事件，也是最重要同时又最难的一件事件，就是保持，制订好学习打算后肯定要保持。读书是一件比拟辛苦的事，的确有很多同学没方法保持下来。但如果不保持，可能永远就没有机会把这件事做好。” “不知985谢小龙”据说你的Title叫“不知985谢小龙”，这个是怎么回事？博士的时候，我注册了一个问答网站，发现那个问答网站上大家每天探讨什么985、211，为了参加大家的探讨，我就去网上搜了一下什么是985，什么是211。谢小龙笑道。 大学期间的谢小龙还是一位有名的“斜杠青年”，高中时候谢小龙没有想过当前要做什么样的工作，也没有人会给领导。去了北大当前，自在的学习环境下，每个人都能够去做很多尝试。谢小龙过后学过计算机、微电子、法学双学位，还尝试了新媒体以及互联网的一些创业项目。做了很多尝试之后，感觉本人对计算机还算是有一些天才，最终抉择了计算机这条路线。 然而对于一位刚入大学的新生来说，大学只有短短的四年工夫，诚然，多尝试没错，然而不肯定每个人都有足够的老本去尝试，一旦尝试错了，对大学学习生存将是一个重大打击。对于这点，谢小龙给出了他的认识：其实所谓的试错老本，最要害的要看在这个试错过程中你取得了什么。这个社会变动十分快，所有很多人不分明本人想要或者适宜走什么路，这是一个比拟常见的状态。比方有的同学给本人做了一个考验的布局，但实际上并没有真的很认真地筹备，这就是一段有效的经验。但如果他真的认真去筹备了，即便最终没考上，我仍然感觉在这个过程中他会有很多播种。要争取无效斜杠，无效横跳，让本人在每一段经验中都有成长。所以，想要在尝试过程中没有一步是白走的，那就须要你在每次尝试中认真付出，认真复盘，将每次的尝试都变成本人的一段人生经验。 大学中有些学科很难，高中期间的谢小龙感觉本人不会的常识只有致力就能学会，然而进入大学后发现不是这样。身边又有一些输送的或者特地聪慧的同学，他也会感觉总是比不上他们，起初还是通过本人致力调整心态，被动逃离内卷。“在大学这个压力较大的环境，你要学会去意识一个更加实在的本人，其实我最遗憾的就是在本科的时候没有把数学学好，有些课可能这一辈子只有一次学习的机会。”谢小龙说到。“感觉学不会就不学了，做一些适宜本人做的事。”多尝试多筹备多复盘，没有人一开始就是全能的，都是一点点保持一点点尝试出最适宜本人的路。 退出阿里，成为“阿里星”谢小龙在本科期间尝试了不同的方向后，决定从事根底软件行业，而后就开始朝着编程方面致力，之后编程能力开始突飞猛进，在阿里成为一颗新星。 （通往阿里巴巴的路） 随后，他和咱们分享他初入阿里时的一些状况。微电子业余出身的谢小龙，在初入阿里的时候，也不是一帆风顺的。阿里面试的时候，谢小龙和面试官因为面试问题的答案起了辩论。谢小龙说：“只管工作了很久，也很有教训，然而具体到这个畛域的话，我认为本人还是比拟相熟的，于是我就开始剖析他的答案为什么错，最终我还是保持本人的观点。没想到起初他对我的面试评估还挺高的。我感觉，如果一个人的工作做得足够好的话，其实这个人就是权威的，遇到他人给的倡议，齐全能够感性的剖析。” 说到这里，他向咱们介绍起他的工作：“其实数据库就是程序员的Excel，只不过数据库要解决的场景更加极其一些，要解决的数据量，要写入、查问和剖析的速度，都比咱们罕用的Excel要高好几个数量级。比方咱们团队开发的云原生数据仓库AnalyticDB,这个零碎须要在单个实例内存储PB级别数据、反对实时的简单SQL查问和数据分析业务。一方面，在写入性能、存储老本方面要有大量的技术创新。另一方面，为了实现大数据量、高性能的简单查问，对优化器、计算引擎都提出了十分高的要求。而且在云原生时代，整个零碎要十分易用、易于治理，不便扩缩容。尽管逻辑上讲，AnalyticDB的性能和Excel一样，然而所解决的数据量和场景，都十分的极其，因而有着十分大的技术挑战。”他说：“比方咱们关上外卖软件去查一个餐厅，以及后续的下单、付款等环节，数据库都会承当这个数据最终存储的工作。” 感性的保持很重要，迷茫也是很失常的，这个社会十分丰富多彩，谁也无奈在开始前就确定本人适宜干什么工作。克服这种迷茫的一个比拟好的想法，就是找一些事件去做，比如说去找一份实习，或者去找一个创业项目。想太多没有用，先去做了，失败也没有关系，最要害的是在这个过程中要保持，真的认真去做，就会有播种。谢小龙通知咱们，不是一味的保持本人的想法，就叫感性保持本人的想法。“我感觉大家不能拿本人的offer去跟他人的specialoffer去比。一些互联网公司给一些优良的应届生开的薪水，可能是一般应届生的3到5倍。然而很多同学去网上看了一个人脸识别的教程，用Python调了几个包，就去投这个算法岗了，总是有一些不切实际的期待。”谢小龙说到，正确的意识本身，找到适宜本人的路，能力有感性的保持，才会有好的播种。 身为程序员的谢小龙，对于网上许多对于程序员成家晚成家难的探讨也有所理解，然而他满不在乎，他笑道：我感觉身边的程序员在相亲市场还挺受欢迎的，很多同学都很早就结婚了。所以尽管大部分程序员没有女朋友的，然而他们都有老婆了。谢小龙也是其中一员，平时在工作上认真负责的他，在生活中也是一位温顺牢靠又爱护妻子的丈夫，他笑言别说我妻子想让我孩子和她姓，我和她姓都没问题。 相干浏览： 数澜科技全面集成阿里云AnalyticDB数据仓库 打造轻量级数据中台 对话李飞飞，揭秘国内体育赛事风“云”背地的黑科技 第三届数据库大赛翻新上云性能挑战赛 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

简介：东京 2020 奥运会行将落幕，本届奥运会因为疫情限度，东京地区赛事以无观众的空场模式举办，在无奈亲临现场的状况下，寰球观众首次以 “云上” 形式观看奥运。“云上奥运” 该如何保障赛事的生动性和现场感，缩短观众与赛场之间的间隔，随时随地捕获精彩赛事霎时？阿里云作为本届奥运会最高等级的寰球合作伙伴，撑持奥运会实现首次寰球云上转播，供各大转播商应用。同时，阿里云反对国内顶级媒体实现云上 “采编发” 整体流程的验证，为媒体跨地区协同报道提供了贵重的实战经验。 新华社作为中国国家通讯社和世界性通讯社，是此次寰球仅有的具备资格在主新闻核心展现奥运精彩霎时 6 家世界级媒体之一。东京奥运会也是新华社第一次作为国内通讯社报道奥运，新华社派出 133 人的奥运会报道团队对奥运现场进行全方位的报道，通过云技术，后方记者和前方团队能够进行密切配合，使得报道内容可能更高效实现。 针对阿里云对新华社 “云上制播” 的技术助力，具体到跨地区 “采编发” 协同制播流程的实现、摸索、验证，分为以下几步： 异地协同，网络后行媒体素材内容是否高效地传输回来，网络保障是关键所在。早在今年年初，新华社思考到信号和视频内容传输的各类需要，申请了 100Mbps 的宽带链路。而当 7 月份记者到达东京进行现场带宽测速时，后果非常不现实。百兆网络拜访国内的服务，带宽只到了 KB/s 级别，如同回归了拨号上网时代。 现场带宽测速 如何解决跨区域网络传输的问题？ 后方记者拿出了当时筹备好的 “神器”：阿里云一站式疾速上云 SDWAN 接入产品（Smart Access Gateway，简称 SAG）。 因为已在国内进行过配置和测试，因而，在报道现场，记者间接将预留的以太网插到 SAG 产品 WAN 端口，再把须要连贯的设施接入到 SAG 的 LAN 端口，便可主动获取 IP 地址，东京报道现场的设施就和国内云端提前配置好的计算、存储等资源形成了一个加密平安的内网环境。当然，还能够通过 PC 和手机等终端装置的 APP 状态，满足各类挪动终端的 point-to-site 疾速接入。 今年年初，新华社联结阿里云、优酷进行多场测试验证，通过 SAG 网关能够最大化的优化网络传输品质，升高零碎拜访时延，满足近程制作、云上生产等各类利用场景。 5 路 NDI 流接管状况下相干测试截图 Full NDI 状况推流上云延时成果 智能接入网关 SAG 是阿里云混合云 SD-WAN 解决方案的 CPE 终端设备，可同时基于互联网宽带 / 4G/5G / 专线等多种类型链路，帮忙企业平安高速接入阿里云。充分发挥阿里云网络资源劣势，就近加密接入 POP 点，优化网络品质，一站式实现跨地区、弹性、高效的分支机构及线下 IDC 互联及业务上云。 ...

简介：5 月 22 日北京站 Flink Meetup 分享的议题。 本文整顿自爱奇艺技术经理韩红根在 5 月 22 日北京站 Flink Meetup 分享的议题《Flink 在爱奇艺广告业务的实际》，内容包含： 业务场景业务实际Flink 应用过程中的问题及解决将来布局GitHub 地址 https://github.com/apache/flink 欢送大家给 Flink 点赞送 star~ 一、业务场景 实时数据在广告业务的应用场景次要能够分为四个方面： 数据大屏：包含曝光、点击、支出等外围指标的展现，以及故障率等监控指标；异样监测：因为广告投放的链路比拟⻓，所以如果链路上产生任何稳定的话，都会对整体的投放成果产生影响。除此之外，各个团队在上线过程中是否会对整体投放产生影响，都是通过异样监测零碎可能观测到的。咱们还可能观测业务指标走势是否正当，比方在库存失常的状况下，曝光是否有不同的稳定状况，这能够用来实 时发现问题;数据分析：次要用于数据赋能业务倒退。咱们能够实时剖析广告投放过程中的一些异样问题，或者基于以后的投放成果去钻研怎么优化，从而达到更好的成果;特色工程：广告算法团队次要是做一些模型训练，用于反对线上投放。技术特色最后大部分是离线，随着实时的倒退，开始把一些工程转到实时。二、业务实际业务实际次要分为两类，第一个是实时数仓，第二个是特色工程。 1. 实时数仓1.1 实时数仓 - 指标 实时数仓的指标包含数据完整性、服务稳定性和查问能力。 数据完整性：在广告业务里，实时数据次要是用于领导决策，比方广告主须要依据以后投放的实时数据，领导前面的出价或调整估算。另外，故障率的监控须要数据自身是稳固的。如果数据是稳定的，指导意义就十分差，甚至没有什么指导意义。因而完整性自身是对时效性和完整性之间做了一个衡量；服务稳定性：生产链包含数据接入、计算（多层）、数据写入、进度服务和查问服务。除此之外还有数据品质，包含数据的准确性以及数据趋势是否合乎预期；查问能力：在广告业务有多种应用场景，在不同场景里可能应用了不同的 OLAP 引擎，所以查问形式和性能的要求不统一。另外，在做数据分析的时候，除了最新最稳固的实时数据之外，同时也会实时 + 离线做剖析查问，此外还包含数据跨源和查问性能等要求。1.2 实时数仓 - 挑战 数据进度服务：须要在时效性和完整性之间做一个衡量。数据稳定性：因为生产链路比拟长，两头可能会用到多种性能组件，所以端到端的服务稳定性对整体数据准确性的影响是比拟要害的。查问性能：次要包含 OLAP 剖析能力。在理论场景中，数据表蕴含了离线和实时，单表规模达上百列，行数也是十分大的。1.3 广告数据平台架构 上图为广告数据平台根底架构图，从下往上看： 底部是数据采集层，这里与大部分公司基本一致。业务数据库次要蕴含了广告主的下单数据以及投放的策略；埋点日志和计费日志是广告投放链路过程中产生的日志；两头是数据生产的局部，数据生产的底层是大数据的基础设施，这部分由公司的一个云平台团队提供，其中蕴含 Spark / Flink 计算引擎，Babel 对立的治理平台。Talos 是实时数仓服务，RAP 和 OLAP 对应不同的实时剖析以及 OLAP 存储和查问服务。 数据生产的中间层是广告团队蕴含的一些服务，例如在生产里比拟典型的离线计算和实时计算。 离线是比拟常见的一个分层模型，调度零碎是对生产出的离线工作做无效的治理和调度。实时计算这边应用的引擎也比拟多，咱们的实时化是从 2016 年开始，过后选的是 Spark Streaming，前面随着大数据技术倒退以及公司业务需要产生了不同场景，又引入了计算引擎 Flink。实时计算底层调度依赖于云计算的 Babel 零碎，除了计算之外还会随同数据治理，包含进度治理，就是指实时计算里一个数据报表以后曾经稳固的进度到哪个工夫点。离线里其实就对应一个表，有哪些分区。血统治理包含两方面，离线包含表级别的血统以及字段血统。实时次要还是在工作层面的血统。至于生命周期治理，在离线的一个数仓里，它的计算是继续迭代的。然而数据保留工夫十分长的话，数据量对于底层的存储压力就会比拟大。数据生命周期治理次要是依据业务需要和存储老本之间做一个衡量。品质治理次要包含两方面，一部分在数据接入层，判断数据自身是否正当；另外一部分在数据进口，就是后果指标这一层。因为咱们的数据会供应其余很多团队应用，因而在数据进口这一层要保证数据计算没有问题。再下层是对立查问服务，咱们会封装很多接口进行查问。 因为数据化包含离线和实时，另外还有跨集群，所以在智能路由这里会进行一些全集群、选表以及简单查问、拆分等外围性能。查问服务会对历史查问进行热度的对立治理。这样一方面能够更应进一步服务生命周期治理，另一方面能够去看哪些数据对于业务的意义十分大。除了生命周期治理之外，它还能够领导咱们的调度零碎，比方哪些报表比拟要害，在资源缓和的时候就能够优先调度这些工作。再往上是数据利用，包含报表零碎、Add - hoc 查问、数据可视化、异样监控和上游团队。1.4 实时数仓 - 生产链路 ...

简介：近日，计算机系统构造国内顶级学术会议 USENIX ATC在线上举办。ATC 始办于1992年，是由USENIX组织的计算机系统畛域的顶级会议，至今已胜利举办31届，计算机系统畛域中Oak语言（JAVA语言的前身）、QEMU、ZooKeeper等一系列有影响力的研究成果都在USENIXATC发表或颁布。ATC 对论文要求极高，必须满足基础性奉献、前瞻性影响和松软零碎实现的要求，本次论文录取率仅为18%，寰球仅选取3篇最佳论文。ATC2021 放榜，接管率再翻新低，为18%。同时，3篇最佳论文出炉，阿里云提交的对于飞天操作系统的论文占据一席，创下了中国公司最好问题。 近日，计算机系统构造国内顶级学术会议 USENIX ATC在线上举办。ATC 始办于1992年，是由USENIX组织的计算机系统畛域的顶级会议，至今已胜利举办31届，计算机系统畛域中Oak语言（JAVA语言的前身）、QEMU、ZooKeeper等一系列有影响力的研究成果都在USENIXATC发表或颁布。ATC 对论文要求极高，必须满足基础性奉献、前瞻性影响和松软零碎实现的要求，本次论文录取率仅为18%，寰球仅选取3篇最佳论文。 阿里云提交的论文名为《Scaling Large Production Clusters withPartitioned Synchronization》（PDF版），探讨了飞天如何解决大规模计算资源的调度问题，被收录并荣获最佳论文奖，这也是ATC最佳论文首次呈现中国公司的身影。 飞天是阿里云自研的超大规模云计算操作系统，可将遍布寰球的百万级服务器连成一台超级计算机，以在线公共服务的形式为社会提供计算能力。飞天的外围服务包含分布式计算、存储、数据库、网络等，本次获奖的论文就是其中的资源调度服务。 据悉，阿里云提交的对于飞天散布式调度零碎“fuxi2.0”是阿里学术单干翻新钻研打算（AIR）与香港中文大学Jamescheng老师的合我的项目成绩。该论文探讨了业界散布式调度架构资源抵触重大和调度性能差的问题，创造性地提出了一套资源抵触解决机制，实现了调度器在集群规模上的可扩展性，同时保障极佳的调度性能和调度成果，撑持了飞天大数据平台MaxCompute单集群10万节点的规模，4万作业/秒的并发能力。 云计算最外围的问题是如何把成千上万，甚至更大规模的机器高效地组织起来，灵便进行任务调度和治理，使用户能够像应用一台机器一样应用云计算。随着数据和计算量越来越大，云计算场景也变得超大规模化，以前传统的基于核心架构的调度器受限于单点解决能力，无奈在规模上实现可扩大。 阿里云计算平台事业部研究员关涛示意：“分布式系统畛域有一个说法，每当规模扩充一个数量级，就变成了一个全新的问题。规模、利用率和公平性是调度零碎的三个外围，本次的论文基于阿里云飞天零碎的局部工作，在不损失利用率和公平性的状况下，摸索调度零碎在超大规模的可扩展性能力”。 近几年，飞天操作系统多项研究成果被国内顶会录取：2019年，数据调度论文Yugong被数据库顶级会议VLDB录取；2020年，机器学习&单机调度论文AntMan被操作系统顶级会议OSDI录取；2021年，计算调度论文Fangorn被数据库顶级会议VLDB录取。 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

简介：Dataphin作为一款企业级智能数据构建与治理产品，具备全链路实时研发能力，从2019年开始就撑持可团体天猫双11的实时计算需要，文章将具体介绍Dataphin实时计算的能力。-更多对于数智化转型、数据中台内容请退出阿里云数据中台交换群—数智俱乐部 和关注官网微信公总号（文末扫描二维码或点此退出） -阿里云数据中台官网 https://dp.alibaba.com/index 背景每当双11寰球购物狂欢节钟声响起，上千万用户涌入天猫、淘宝，晦涩的购物体验背地是阿里工程师用技术打造出的营地，撑持了每年双11所带来的数据洪峰。2020年11月1日至11月12日0:00，天猫“双11”累计总交易额达4982亿元，物流订单总量达到23.21亿单。这所有的背地都离不开实时计算技术。 Dataphin作为一款企业级智能数据构建与治理产品，具备全链路实时研发能力，从2019年开始撑持团体天猫双11的实时计算需要。就以下文介绍Dataphin实时计算的能力。 传统的数仓架构在数仓建设过程中，一般来说都是先建设离线数仓，同时围绕着离线数据构建利用。而后随着业务的倒退或者体验的优化，再建设实时计算的链路去晋升数据的时效性。 在这个过程中类似的代码写两遍就难以避免，还会呈现实时和离线口径不统一，别离保护成本增加等各种各样的问题。 传统的数仓架构流与批从存储计算中拆散带来以下的问题： 效率问题：流批底层数据模型不统一，导致应用层做大量的拼接逻辑（同比、环比、二次加工等），搭建效率低且容易出错品质问题：一个业务逻辑，两个引擎两套代码，SQL逻辑不能复用，数据一致性和品质问题难以保障老本问题：流批存储系统隔离（面向不同写入场景），提供的数据服务不一，保护老本高手工建数据同步工作，开发成本/存储老本高（两份）批处理&流解决集群无奈做到错峰，资源利用率低Dataphin流批一体劣势为解决传统数仓架构的存储计算拆散的问题，有了“流批一体”的思路： 流批存储透明化，查问逻辑完全一致，利用端接入老本大幅升高，点查/OLAP剖析对立反对 服务层对立存储，无需手工同步，无反复存储一套代码，两种计算模式，逻辑对立，灵便切换，研发效率大幅晋升流批计算资源混部，资源利用率晋升 Dataphin在Flink流批一体的能力之上额定提供了更多的平台能力，如数据源治理、元数据管理、资产血统、资产品质管制、预编译、调试等能力： 开发生产隔离：提供开发环境和生产环境隔离，保障开发环境开发的业务代码和生产相互之间不烦扰元数据管理：各零碎组件包含数据源、元表、UDX等具备权限管制性能，敏感型配置信息加密爱护。反对数据源敏感字段拜访订阅。元表、函数、资源等全副单元化可视化的治理，反对跨我的项目鉴权（字段级）调用，让使用者聚焦业务逻辑。流批一体：流批存储层的对立治理，实现模型层对立，流批代码对立、通过流批各自专属配置，生产独立有协同的额调度实例研发提效：提供了预编译的能力，提供语法校验、权限校验、字段血统提取的性能；容器化调试，反对上传自定义数据或间接生产实在生产数据用来察看作业运行、查看各个节点的输入后果反对元数据检索，作业依赖、字段血统的可视化探查稳定性及品质保障：反对流量阈值设置，避免计算资源适度竞争，防止上游零碎过载反对实时元表品质监测，可配置统计趋势监测、实时多链路比照、实时离线数据核查。开发生产隔离Dataphin反对开发生产隔离的我的项目，反对开发和生产双环境的数据源配置。这样在开发模式下，工作就会主动应用开发数据源和开发环境下的物理表；而当公布到生产环境时，Datpahin则会主动切换为生产数据源及生产环境的物理表。这个过程齐全自动化，不必手动批改代码或配置。 元数据管理Dataphin创造性的引入了实时元表和镜像表的概念，将实时研发过程中的表进行了平台化、资产化的对立治理，并简化了研发，晋升研发效率和体验。 传统实时工作研发工具须要用户反复写Create table建表语句，须要进行繁琐的输入输出表映射等操作。实时元表将实时开发工作中所有用到的数据表进行了对立表构建与治理，对立保护了所有实时元表和相干schema信息。开发者在开发过程中不必反复写DDL语句；同时，也不须要进行繁冗的输出、输入、维表映射，采纳简略的纯代码研发模式，简略的SET语句及权限申请，即可援用表数据，进行间接查问或写入数据，轻松做到一次建表，屡次援用，大幅度晋升研发效率和体验。 镜像表顾名思义则是用于保护离线表与实时表之间字段的映射关系。创立镜像表并提交公布后，就能够在流批一体的Flink工作中应用镜像表的字段，Datpahin会在编译时主动映射到流表和批表上，实现一份代码，两种计算，代码逻辑、口径变更强统一。 流批一体的代码工作除了引入实时元表与镜像表，Dataphin也反对了流批一体的工作，应用Flink引擎作为对立的流批计算引擎，在一份代码上可同时配置流+批的工作配置，基于同一份代码生成不同模式下的实例。而对于流批差异化的代码，Dataphin也提供了不同的形式给与反对。 流批一体工作中会宽泛应用镜像表，而镜像表在最终应用时会翻译为对应的流表/批表，为了适应流表/批表的多样性（流表/批表的数据源可能不一样，带来with参数中key可能不一样；流表/批表的某些设置可能不一样，比方batchSize等），能够利用tableHints进行流表/批表的对应。办法如下： set project.table.${mode}.${key} --mode: 流工作：\`stream\` 批工作：batch 举个例子，设置批工作的起停工夫： set project.table.batch.startTime='2020-11-11 00:00:00'; set project.table.batch.endTime='2020-11-12 00:00:00'; 第二种是在Dataphin的工作配置实时和离线模式别离工作参数的形式是利用工作参数进行替换。 实时品质监控Dataphin实时数据品质次要面向开发者，针对产品中实时产出的数据表，通过对产出后果进行数据品质剖析和校验，来保障数据的最终无效与精确。Dataphin反对统计趋势监测、实时多链路比照、实时离线数据核查。 统计趋势监测：趋势监测指的是基于数据趋势变动以及专家教训以捕捉稳定异样的监测形式；如 实时GMV的趋势陡增有些异样实时多链路趋势比照：实时多链路指的是在实时计算的场景中，因为数据的复原老本较高，无奈疾速从终点从新计算，因而须要应用多个计算链路，当产生计算异样时，主动/手动切换计算链路，是一种用资源换稳固的策略，当有重大的保障业务时，往往会采纳该种类型；如每年双十一大屏都会采纳多链路保障。实时离线核查：实时离线核查，是保障实时数据罕用的一种措施，因为实时计算处于一种继续运算状态，计算工夫长久且受资源与源数据的扰动较大；离线数据在逻辑、数据复用性方面能够被更好地操作，因而，为了保障实时数据的准确性，罕用离线数据与实时数据进行比照；如每年双十一前都会应用离线数据对实时数据进行校验； 双十一大屏后的Dataphin回到文章开始的天猫双十一，理解了Dataphin平台特有的能力，咱们来具体拆解Dataphin为什么能撑持天猫双十一的实时数据大屏。 快Dataphin为实时提供研发、调试、测试、运维全链路一站式服务，极大升高用户开发门槛；同时提供对立元数据管理，元数据仅需初始化一次，轻松做到一次建表，屡次援用，让开发聚焦业务逻辑，大幅度晋升研发效率和体验；另外有数据研发经验的同学都有这样的领会，很多数据口径都惊人的相似，甚至有些只是输入输出表不同，典型的场景比方主备链路，针对这种场景咱们提供了模版研发的能力，雷同逻辑封装在模版中，差别逻辑通过模版参数体现，新工作仅需援用模版配置模版参数即可，极大晋升研发效率的同时也升高了口径保护老本。基于以上能力，在双十一大屏的反对上，只管业务玩法很多，需要井喷，依然仅以2人便撑持上百需要。 稳Dataphin提供工作监控及数据品质监控全方位保障工作稳固，疾速发现问题；基于模版的主备多链路在异样产生时能够秒级切换，疾速止血；基于实时工作血统，疾速定位问题根因；基于调试、测试、细粒度资源配置，疾速验证并修复，真正做到1min发现、5min定位、10min解决。 准基于流批一体的能力，真正做到代码对立，口径对立，存储对立，数据服务接口对立，研发提效的同时，保证数据统一。 将来布局在行将公布的Flink VVP（Ververica Platform）适配版本将反对新的VVR引擎，也将在将来反对开源Flink引擎已反对更多的部署环境。Dataphin也将继续晋升实时研发的能力和体验，帮忙企业升高实时研发的门槛，开掘更多的场景，取得实时数据带来的业务价值！ 数据中台是企业数智化的必经之路，阿里巴巴认为数据中台是集方法论、工具、组织于一体的，“快”、“准”、“全”、“统”、“通”的智能大数据体系。 目前正通过阿里云对外输入系列解决方案，包含通用数据中台解决方案、批发数据中台解决方案、金融数据中台解决方案、互联网数据中台解决方案、政务数据中台解决方案等细分场景。 其中阿里云数据中台产品矩阵是以Dataphin为基座，以Quick系列为业务场景化切入，包含： - Dataphin，一站式、智能化的数据构建及治理平台；- Quick BI，随时随地 智能决策；- Quick Audience，全方位洞察、全域营销、智能增长；- Quick A+， 跨多端全域利用体验剖析及洞察的一站式数据化经营平台；- Quick Stock， 智能货品经营平台；- Quick Decision，智能决策平台；官方站点： 数据中台官网 https://dp.alibaba.com 钉钉沟通群和微信公众号 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

简介：近日，钉钉宜搭携手阿里巴巴技术公益委员会、阿里云“码上公益”平台，发动“码上公益营·低代码挑战”流动，用低代码技术升高技术公益的门槛，帮忙公益组织更低成本、更高效率地实现“技术公益”。 近日，钉钉宜搭携手阿里巴巴技术公益委员会、阿里云“码上公益”平台，发动“码上公益营·低代码挑战”流动，用低代码技术升高技术公益的门槛，帮忙公益组织更低成本、更高效率地实现“技术公益”。咱们诚挚邀请宽广低代码开发者，退出技术公益志愿者行列！用技术助力公益组织数字化，从而帮忙更多须要帮忙的人！ 点击链接，通知你咱们的故事 咱们都是码上公益爱心极客，和咱们一起用数字技术来帮忙公益机构轻松逾越数字化阻碍，助力他们帮忙更多须要帮忙的人，让咱们一起用技术助力公益，让科技更有温度！ 在阿里巴巴公益基金会的反对下，阿里巴巴技术公益委员会、阿里云“码上公益”平台联结钉钉宜搭团队，独特启动“码上公益营，低代码挑战”流动。 2021年7月26日～9月18日 招募技术公益志愿者，用宜搭为10家公益组织实现10个公益我的项目的技术需要，反对他们去帮忙更多的人。 任选1个公益我的项目，集体报名或组队报名加入均可： （1）有公益心：认可公益的价值，有反对公益组织进行数字化倒退的志愿。 （2）有低代码开发能力：有应用宜搭平台进行低代码开发的教训，或者具备肯定的惯例代码能力（注：具备惯例代码能力的同学根本可能疾速上手低代码开发，并且低代码不等于无代码，有些我的项目的细节中也会须要退出一定量的惯例代码） （3）能抽出工夫：有肯定的意愿服务工夫，可能在2021年7月-8月的业余时间参加我的项目的开发。 点击此处立刻报名 <span class="lake-card-margin-top lake-card-margin-bottom"><img src="https://ucc.alicdn.com/pic/developer-ecology/c3eed9ff1be248ffa79931a4e98cce73.png" class="image lake-drag-image" alt="图片 1.png" title="图片 1.png"></span><span class="lake-card-margin-top lake-card-margin-bottom"><img src="https://ucc.alicdn.com/pic/developer-ecology/1fdf9a0909fb4ea4b5eb68bfa26747bd.png" class="image lake-drag-image" alt="图片 2.png" title="图片 2.png"></span>【我的项目需要示例1】北京大爱清尘公益基金会：尘肺病农民求助申请治理技术需要：<span class="lake-fontsize-10">实现求助申请填报、档案存储、审批、表单汇总与导出的数字化，让尘肺病农民及家访志愿者辞别纸质申请表，求助更不便。</span>技术利用：<span class="lake-fontsize-10">宜搭表单</span>【我的项目需要示例2】北京交融联汇心智障碍者服务中心：心智阻碍救助机构信息管理技术需要：<span class="lake-fontsize-10">已收集全国2000+心智阻碍儿童痊愈救助定点服务机构信息表，须要实现数字化，让心智阻碍儿童家长能够在线查问左近的定点服务机构。</span>技术利用：<span class="lake-fontsize-10">宜搭表单</span> 前10位报名者送“云小宝”手办独立装前11-50位报名者送“云小宝”奥运纪念版徽章（样式随机）报名并胜利入选进入我的项目开发阶段的同学，还有“云小宝”手办奥运纪念版套装送上（“云小宝”手办独立装）（“云小宝”奥运纪念版徽章）（“云小宝”手办奥运纪念版套装）以上只是报名阶段的奖品哦，我的项目实现后还有更多处分！2021云栖大会的收费席位和颁奖宜搭模版永恒署名码上公益平台定制纪念品意愿服务证书公益时……流动规定详情，详见码上公益官网如果你还没有应用过宜搭，点击这里疾速入门低代码技术快来报名加入吧，献上你的一技之长！兴许，下一个重磅的技术公益我的项目，就从你的手中诞生！> 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

简介：Threat Hunting 平台的架构与设计，及以升高 IO 为指标的优化与摸索。为什么以及如何应用块索引。 本文整顿自 360 政企平安团体的大数据工程师苏军以及刘佳在 Flink Forward Asia 2020 分享的议题《基于 Flink 的 PB 级数据即席查问实际》，文章内容为： Threat Hunting 平台的架构与设计（苏军）以升高 IO 为指标的优化与摸索（刘佳）将来布局GitHub 地址 https://github.com/apache/flink 欢送大家给 Flink 点赞送 star~ 首先做一个简略的集体以及团队介绍。咱们来自 360 政企平安团体，目前次要从事 360 平安大脑的 “威逼狩猎“ 我的项目的开发工作。咱们团队接触 Flink 的工夫比拟早，在此期间，咱们基于 Flink 开发出了多款产品，并在 2017 年和 2019 年加入了于柏林举办的 Flink Forward 大会，别离介绍了咱们的 “UEBA” 以及 “AutoML” 两款产品。 本次分享次要分为两块内容： 第一局部 “Threat Hunting 平台的架构与设计” 将由苏军来为大家分享；第二局部 “以升高 IO 为指标的优化与摸索” 将由刘佳来为大家分享。一、Threat Hunting 平台的架构与设计 (苏军)第一局部内容大抵分为三个局部，别离是： 平台的演进架构设计深刻摸索索引构造1. 平台的演进 咱们认为所有技术的演变和变革都须要具体的商业问题来驱动，以下是咱们团队近几年基于 Flink 开发的几款产品： ...

简介：在当下热火朝天的金融行业中台建设浪潮中，不少金融机构对于中台建设仍存诸多迷思，中台建设将走向何方？数据资产到底该如何治理？阿里巴巴的中台建设之路应该能为金融机构带来借鉴。 日前，在阿里云举办的2021阿里云金融数据智能峰会上，阿里云智能计算平台事业部研究员关涛对阿里巴巴如何构建数据中台外围三要素中的平台技术局部进行了全盘分享，其中包含数据平台倒退的四个典型阶段，反对中台业务的四大技术挑战，以及数据平台的四大技术趋势等。文/阿里云智能计算平台事业部研究员 关涛 阿里巴巴数据平台倒退的四大阶段 构建数据中台，一个弱小的数据平台作为底座必不可少。 阿里巴巴数据平台倒退的四个阶段，肯定水平上其实也是阿里巴巴数据中台倒退的四个阶段。这四个阶段里，你能够看到阿里巴巴对本身数据的商业价值的萃取，对原有分而治之的数据系统的聚合，对计算数据资产化和数据高效利用的新思路以及对数据平台治理过程中面临的组织变革等。 阶段一：业务百花齐放，发现数据价值 2009年到2012年，阿里巴巴电商业务进入暴发期，涌现出十分多有名的业务团队，比方淘宝、1688、AliExpresss、一淘等。每个业务都是基于数据驱动的全场景业务，业务方对数据有着强烈的诉求。 那个时候，阿里巴巴技术简直都是IOE架构，外围数据系统是Oracle。2年工夫内，阿里巴巴建成了全亚洲最大的Oracle集群。然而在2010年，Oracle曾经不能满足计算的要求，有十分多数据提早和不满足性，再加上低廉的老本，没方法持续撑持业务倒退。 阿里巴巴开始认真扫视建设下一代数据平台的重要性，同时启动了两个并行我的项目：一个是“云梯1”，基于开源Hadoop技术体系，多个业务团队构建多个Hadoop集群，集群规模达到4000台服务器。 一个是“云梯2”（ODPS，现MaxCompute），作为阿里巴巴自研产品启动研发，集群规模1200台左右。蚂蚁小微贷款“牧羊犬”业务是第一个吃螃蟹的业务，上线“云梯2”的过程被称为“人肉云计算”与“分步试计算”。王坚院士2018年曾在央视《朗读者》节目朗诵《进入空气稀薄地带》，形容的就是自研数据平台那时的现状与信念。 两个我的项目在阿里巴巴外部造成竞合状态，并行摸索阿里巴巴数据平台倒退的轨迹。这个期间，所有业务方的数据简直都是垂直建设，以本人业务状态造成独立小闭环的模式飞快向前奔跑。 阶段二：业务垂直小闭环，数据孤岛浮现 2012年到2015年，阿里巴巴电商业务在飞速发展的同时，涌现出更多的新兴业务：2013年，创建菜鸟，启动“all-in 无线”策略；2014年，投资高德，与银泰合资，阿里旅行成立；2015年，推出钉钉/批发通、成立口碑、控股阿里衰弱等等。 这个期间，阿里巴巴业务蓬勃发展，造成了12个业务部门和9套不同的平台零碎，而且每套平台零碎架构都不一样，用户数字化流程须要横跨多个BU的多套数据系统。 数据孤岛景象开始日益严重，数据老本越来越高，对立的数据平台建设曾经火烧眉毛，这也是阿里巴巴数据中台的终点。 与此同时，“云梯1”和“云梯2”也正在经验大改革。 2013年3月28日，阿里巴巴团体技术保障部架构师云铮的邮件中转团体高层：“依照数据增量与将来业务增长的状况，云梯1和云梯2两套零碎的存储和计算能力将在往年6月21日达到瓶颈。”届时，许多的业务将因为技术的限度而无奈开展。 这意味着，数据平台曾经无奈再同时并行“云梯1”与“云梯2”两个我的项目，必须抉择其中1个。如果抉择“云梯1”，Hadoop的5000节点限度如何冲破？波及到金融业务，开源体系如何保障大数据的平安与可用性？跨机房计划业界无参考如何解决？业务交互频繁，跨机房如何保证数据稳固交互？ 一系列的技术难题都逐步将数据平台推向自研路线。 最终，阿里巴巴团体多个技术部门合璧，决定抉择“云梯2”挑战5K巅峰。短短几个月工夫，“云梯2”从1500台跨入5000台并冲破单物理机房限度，通过10倍压力测试，同时反对跨集群计算与高可用，为阿里巴巴将来多年的大数据倒退奠定了松软的技术根底。 5K我的项目实现技术冲破后，新的压力接踵而来。业务疾速倒退导致数据规模也急剧收缩，如何对立治理数据、对立保障数据安全、具备对立凋谢能力等问题成为数据平台思考的外围。 为此，阿里巴巴外部启动了一个比拟有名的我的项目，将所有业务部门数据都同步到对立的大数据平台，对立进行治理。这个我的项目经验了两年，波及阿里巴巴所有事业部，这个过程中，还逐步推动通用数据平台能力产品化并具备金融级平台的能力。 从过后来看，阿里巴巴建设数据平台的过程是全面对立数据的过程，也是中国第一个超大规模数据中台建设和迁徙的过程。 阶段三：数据中台撑持业务可继续倒退 2015年到2018年，阿里巴巴数据中台方法论开始确立，拉开了数据中台建设的大幕。2015年，阿里巴巴团体发表启动“中台策略”后，开始构建合乎DT时代的更灵便的“大中台，小前台”组织机制和业务机制。阿里巴巴每个经营小二都能够基于数据制订笼罩用户生命周期的数据化经营策略，生意顾问开始摸索数据业务化，更多的业务开始走向实时化。 然而，数据和计算的高速增长、资源的高速耗费带来了数据须要治理的问题。阿里巴巴的团队们开始思考怎么把数据中台的方法论落实到平台层，让数据平台撑持数据中台的建设。 数据是谁的? 谁来用? 谁来管控？数据品质由谁负责？· 平台团队和业务团队是两个团队，老本关系是什么？· 中台方法论，如何落地在数据平台落地？如何治理?· 数字增长很快，超过业务增长，怎么办？· 一张外围表12PB，每个部门复制1份，一年几千万就没了怎么办？· 我晓得要删除一半的数据，但到底是哪一半？ 这些问题的背地是数据的治理以及资产化，咱们须要一套平台零碎把方法论承载进来，真正造成统一化。在数据平台侧，DataWorks 构建大规模协同数据开发与治理的一站式能力，MaxCompute 反对服务器集群达到十万级，服务阿里团体全副BU、20多万员工的日常经营，一起撑持各项业务的可继续倒退。 阶段四：云上数据中台与业务伴生 2018年之后，整个阿里巴巴数据平台零碎曾经很成熟，平台方和业务方达成一个十分好的配合状态。业务方认可数据平台的价值，业务部门与技术部门相伴相生，数据中台服务业务达到正循环，成为数据中台建设胜利的一个标记。 阿里巴巴从2018年外部所有零碎开始上云，到2021年实现了云上数据中台与业务伴生：双11外围零碎100%上云，阿里巴巴全面云原生化；每秒53.8万笔，阿里云抗住寰球最大流量洪峰；数据中台笼罩阿里团体所有BU；经营小二及时发现问题、剖析问题，实现实时经营决策；短视频、直播等新业务持续涌现…… 能够看到，阿里巴巴的数据中台建设是胜利的，并且仍在高速向前倒退。 MaxCompute 智能数仓让双11成为日常，湖仓一体逐渐成为下一代大数据平台架构，DataWorks建设的数据中台全面服务业务，反对团体内数百个数据利用，通过全链路数据治理，以低成本增长反对团体业务高速增长。 数据平台建设的四个外围挑战一个数据中台建设的胜利与否的外围指标，不是零碎效率，不是平台效率，而是“数据效率”。 阿里巴巴次要从规模与弹性、数据的老本、数据的正确性与可维护性、数据利用率4个方面来掂量“数据效率”。 在这个外围指标下，方法论、组织、平台能力则是数据中台胜利的外围三要素。那么，数据平台要想建设好，背地到底有哪些办法，建设过程中有哪些难点须要留神？背地要做的工作其实十分多，本次仅从面向业务的4个切面做介绍，暂未波及存储、计算引擎等层面的挑战。 挑战一：数据资产管理体系对于数据资产来说，首先要解决的一个问题是：什么叫企业的数据资产？阿里巴巴的每个BU都有一个本人事业部的数据资产全景图，咱们通过一张图统管阿里巴巴99.9%计算数据资产，每个部门的存储计算成本将全副量化，间接展示在管理者的背后。 第二个问题：如何看资产？对于企业而言，资产难道就是一个个老本的数字吗？阿里巴巴通过数据资产的透视，让管理者晓得我本人的数据来源于哪，服务给谁，谁又是我最好的合作伙伴，同时又能够满足数据流动审计的需要。 第三个问题：如何进行资产的规模化？新的业务合并/收买/翻新，如何将这套资产体系疾速地复制？在DataWorks等工具中提供数据中台建模工具，可能为数据中台建设提供规范化图纸，针对不同的业务域进行划分，进行智能建模，让新业务疾速复用之前成熟的数据架构，达到资产规模化的能力。 挑战二：数据质量体系对于数据品质来说，首先要先解决的一个问题是：事先品质如何定义？金融行业常常提到一个概念叫对账，阿里巴巴数据也要对账，针对超过千万级别数据表的对账问题，咱们提了“品质规定”的概念。700多万品质规定，每天新增1万多条，人工要怎么配？阿里巴巴建设了37种规定模板，通过智能规定举荐匹配，驳回率达到75%。 第二个问题：事中品质如何执行？700多万条品质规定须要消耗大量计算资源怎么办？通过什么形式来降低成本？咱们通过智能化技术建设了数据品质调度引擎、ETL引擎，数据变更后实时触发品质监控，采纳优先级策略，进行闲暇运行。 第三个问题：预先品质如何自动化？规定写死了，但数据是活的，遇到周期性稳定和变动怎么办？咱们在数据品质建设的时候融入很多人工智能的技术，通过机器学习形式学习数据生成的样子，可能对动静阈值进行智能预测，通过算法匹配周期性稳定。 挑战三：数据安全体系对于数据安全来说，要解决如何升高应用老本，进步易用性；如何笼罩数据全生命周期；如何做权限管控；如何数据脱敏，如何辨认敏感行为进行数据溯源等问题，阿里巴巴外部积淀了超过20项不同的平安治理规定，这些规定最终可能帮忙平台在满足业务高速增长的状况下同时满足集体合规的要求。 挑战四：数据治理体系当数据治理进入深水区，数据老本增速如何不超过业务增速；如何调动全员治理的积极性，造就老本意识，在阿里巴巴，数据治理是引擎、平台和人的互相配合，引擎对算力和老本极致谋求，继续突破快速增长的数据计算与老本增长的线性关系，平台通过存储衰弱分、计算衰弱分成为团体各团队数据治理战斗的外围指标，推动人做数据治理和治理，利用平台全链路工具，构建数据治理技术经营体系。通过这样的老本报表的形式把平台层的老本和价值展现分明。 能够看出，在12年数据平台建设期间，阿里巴巴从数据的资产、品质、平安、治理等多个纬度积淀出了数据中台产品化的能力。 作为中台底座，数据平台下一站走向何方将来，作为中台的底座，数据中台将从数据智能到智能数据，“湖仓一体”满足架构灵便降级、“智能数仓”解决超大规模下的数据管理难题、“智能查问”极大升高数据分析门槛、AI的云原生化/规模化/标准化与普惠化让其成为大数据的终极进口，一直减速大数据与AI一体化的交融。 趋势一：一体两面的湖仓一体 作为下一代数据平台架构，湖仓一体满足简单现状下架构的灵便降级。数据仓库主打企业级数据，解决更精密、更经济、更高效。企业能够建设本人的数据中台，无论是引擎优化，还是数据管理，有一整套方法论以及撑持的工具。然而进入门槛很高，老本又贵，还有应用门槛。数据湖是脱胎于开源体系的技术，进入门槛和老本较低，比拟灵便，企业容易实现自建数据湖，只是数据对立存储之外，企业须要进一步做各种精细化治理，心愿数据能治理，能治理，成本低，还可运维。 如何买通数据湖和数据仓库割裂的体系，架构上交融数据湖的灵活性以及数据仓库的企业级能力，阿里巴巴提出的湖仓一体架构，对立存储和元数据，买通数据体系，利用智能数仓技术针对不同的数据和任务，做主动分类存储和解决。 趋势二：数据仓库进入“主动驾驶”时代 超大规模数据带来治理难题，传统的“DBA模式”曾经很难胜任。阿里巴巴有超过千万级别的表，很多外围数据开发工程师，一个人负责上万张表，没有方法做精细化的治理和建模，这样的零碎不能随人的形式扩大，所以将来，越来越多的AI技术会交融进大数据系统，进入“主动驾驶”时代。 趋势三：所查即所得，基于自然语言的智能数据查问阿里巴巴正在数据之上尝试构建一个超大规模的常识图谱，通过常识图谱的形式做数据到语义层的翻译，再通过NLP(自然语言解决)等技术跟用户做联合，造成一个桥梁。比方用户输出北京市互联网客户有哪些，就能够主动生成失去一份数据。阿里巴巴正试图把通过自然语言的智能查问在海量数据上用起来，规模化起来，让更多的非专业数据人员也能够独立实现数据分析工作。 趋势四：数据即智能，AI工程化的根底能力  数据须要智能的减速，AI是大数据的终极进口。咱们晓得，真正想把AI用起来是一个十分难的事件，从最后的数据衰亡、数据提炼、模型训练、模型调优，再到模型部署和服务，整个链路十分长。如果咱们有5万人能够间接应用数据，可能真正能用AI的人可能不超过5000人，那如何把AI技术随着数据赋能给业务方，这就是所谓的AI工程化。 最初总结一下，上述内容只是泛泛地提到了阿里数据中台底座建设的四个典型阶段，遇到的四大技术挑战，以及数据平台的四大技术趋势等话题，这些内容还不是阿里巴巴数据中台的全副。通过12年工夫，阿里巴巴数据平台建设曾经有了十分多的技术积攒，这些平台能力也在一直推动数据中台向智能化进化，并且还会始终向前演进，服务阿里巴巴并输入给全社会。 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

简介：Gartner 的报告显示预计到2022年将有75%数据库将采纳云数据库，与此同时，IDC预计到2024年传统部署数据库市场将达到13亿美元，企业数字化转型降级，踊跃拥抱开源、云原生数据库成为重要趋势，也是必然选择。 Gartner 的报告显示预计到2022年将有75%数据库将采纳云数据库，与此同时，IDC预计到2024年传统部署数据库市场将达到13亿美元，企业数字化转型降级，踊跃拥抱开源、云原生数据库成为重要趋势，也是必然选择。 目前阿里云数据库在私有云市场占有率已超过50%占据半壁江山。2020年阿里云数据库成为惟一一家进入Gartner数据库魔力象限领导者象限的中国厂商，荣占亚太第一寰球第三的地位。 为了更好的服务于传统部署的数据库市场，更全面的为云化各阶段政企服务，阿里云重磅推出混合云麻利版独立场景轻量化产品：麻利版数据库场景。 产品介绍 麻利版数据库场景，是阿里云提供的集交易、剖析、传输、治理于一体的企业级云数据库治理平台，帮忙企业疾速构建稳固、平安、经济的全场景数据库解决方案，帮忙企业疾速降级如Oracle、DB2、Teradata等传统数据库与数据仓库。 麻利版数据库场景 产品矩阵 外围性能 【全场景数据库引擎服务】 提供全域的数据库引擎服务蕴含阿里巴巴自研的云原生Oracle高兼容性数据库PolarDB-O、云原生分布式数据库PolarDB-X、云原生剖析型数据库AnalyticDB等，也蕴含开源数据库MySQL、Redis等，以及阿里自研的丰盛的数据库生态工具如DTS、DMS、ADAM等。 【智能化数据库治理服务】 针对所有的数据库服务提供对立的智能化治理服务，包含提供数据库实例管控能力的DBaaS服务，提供如实例生命周期治理、备份复原体系、平安加密治理、数据库日志和SQL审计、监控告警、高可用治理等外围个性，同时也包含提供DBStack平台级的运维治理（Manager），提供如平安流程（如账号平安）治理、外部设备系统管理、主机治理、数据库实例工作治理、实例资源管理、容灾治理和平台降级扩容等服务。即平台分为应用数据库服务和治理平台服务，用户可通过零碎的控制台、OpenAPI、SDK等管制链路拜访治理平台，通过实例提供的拜访连贯拜访数据库服务。 产品劣势 【丰盛的数据库引擎服务】 麻利版数据库场景提供全域数据库引擎，涵盖OLTP、OLAP、和NoSQL的数据库服务，还有分布式数据库和Oracle高兼容数据库，满足企业数据库的绝大多数场景数据库需要。 【齐备的数据库生态工具】 麻利版数据库场景的数据库生态工具体系，包含数据管理、数据库和利用迁徙工具、数据传输。数据管理提供用户治理数据库内对象和数据管理。数据库和利用迁徙工具评估从传统数据库迁徙降级到DBStack的兼容改变点。数据传输包含的数据的迁徙、同步和订阅，迁徙是指从其余数据库迁徙数据到DBStack，或者迁徙数据到其余数据库，同步是指多个数据库之间的不间断数据库同步，订阅是指提供其余零碎从数据库订阅数据的计划。 【跨平台的部署能力】 麻利版数据库场景具备跨平台部署的个性，能够部署到物理服务器或者虚拟机中，反对多种操作系统，如Linux和国产操作系统。 【云原生的管控体系】 麻利版数据库场景提供阿里云私有云数据库的所有云原生的管控能力，涵盖高可用、高牢靠、高弹性、性能、扩大能力、易管理性、性价比、平安合规等方面。 【数据库综合解决方案】 麻利版数据库场景内丰盛的数据库引擎服务和欠缺的工具生态，用户可不便的组合出面向业务和面向场景的稳固的牢靠的高性价比的综合性数据库解决方案。 利用场景 麻利版数据库场景，已反对多款数据库引擎和数据库生态工具产品，灵便的产品组合可满足于不同的利用场景。 例如在传统的流量剖析零碎须要同时引入离线计算和在线计算引擎，并通过定时ETL工作实现在线和离线数据的互通，数据冗余重大，且存在T+1的提早。麻利版数据库场景 DBStack AnalyticDB PostgreSQL 数据库引擎反对在离线一体，一套存储同时提供在线和离线计算，大幅升高业务复杂度，晋升数据的实时性。相比而言，数据时效性从T+1晋升到秒级时延，可疾速查出简略指标，复合指标和多维度指标，为整个链路提供实时百亿级数据秒级查问的在线业务。 随着企业数字化转型，企业对数据的应用会全业务全方位波及，对撑持数据存储的数据库系统的整体可靠性、可用性、存储容量、性能以及扩大都更高的要求，同时对数据库资源的利用率会更加充沛，企业也会更加冀望在一个平台中满足数据产生、解决、剖析、再利用的残缺闭环。 作为政企数智化翻新的同行者，阿里云混合云重磅推出麻利版独立场景轻量化产品-麻利版数据库场景，助力政企客户一站式疾速构建全场景数据库治理平台、满足企业各项应用需要、将引领数据库产业降级，推动企业迈入数据管理新时代。 【观看新品公布】 https://yqh.aliyun.com/live/apsara\_stack\_new\_release 【更多混合云资讯】 https://www.aliyun.com/solution/hybridcloud 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

简介：《实时数仓入门训练营》由阿里云研究员王峰、阿里云高级产品专家刘一鸣等实时计算 Flink 版和 Hologres 的多名技术/产品一线专家齐上阵，合力搭建此次训练营的课程体系，精心打磨课程内容，直击当下同学们所遇到的痛点问题。由浅入深全方位解析实时数仓的架构、场景、以及实操利用，7 门精品课程帮忙你 5 天工夫从小白成长为大牛！本文整顿自直播《Hologres性能调优实际-清芬》 视频链接:https://developer.aliyun.com/learning/course/807/detail/13889 内容简要：一、Hologres建表最佳实际 二、Hologres性能问题剖析与优化 一、Hologres建表最佳实际（一）建表优化的必要性为什么Hologres建表优化十分重要？ 首先，对于整个的查问性能以及写入性能来讲，一个好的建表跟一个比拟差的建表，性能下面有十分大的区别。 其次，建表优化须要尽早做，是因为Hologres在改 DDL的同时，有可能须要用户反复进行一些数据导入，这种反复的工作使得咱们心愿尽早实现建表优化。 最初，一个好的建表对于用户的数据存储老本也有肯定的帮忙。如果建表做得不失当，可能导致建一些不必要的Index，而后导致数据多了一些冗余的存储，从而晋升了老本。 因而，建表优化是十分重要的，这也是把它作为本文第一局部的起因。 （二）业务建模是性能优化的前提说完建表的重要性之后，咱们再看建表优化之前要去做整个业务建模的优化。在思考应用Hologres的同时，咱们要晓得通过Hologres可能解决什么样的业务问题，以及通过什么样的形式解决。 Hologres自身是一个HASP产品，在应用Hologres的同时就须要跟业务场景联合，咱们要晓得这个场景到底是剖析场景还是在线服务场景。如果是一个剖析型，就用Hologres的列存比拟敌对，如果是一个在线服务型场景，就用行存比拟敌对，这些是跟业务场景相干的。 第二个是要可能联合Hologres自身的产品劣势。Hologres是一个在线服务以及交互式剖析的产品，它并不适宜ETL以及海量数据拖取的场景。因而，在把业务往Hologres下面搬的时候，不能搬所有的场景，否则可能导致Hologres做一些不太适宜自身的事件，信赖就会不太好。 第三个是须要做一些取舍。为了达到预期的性能，可能须要做一些相似预计算或者数据加工的提前操作，缩小后续计算复杂度，放慢计算速度。 以上这些都跟事后数据建模以及整个业务冀望非亲非故。 （三）存储形式的抉择做完以上筹备工作之后，咱们须要进行Hologres治理存储形式的抉择。 Hologres自身反对两种存储形式，别离是行存和列存。 行存次要的利用场景是对主键进行高QPS查问，并且当咱们表比拟宽的时候，一次查问会读取大量列，这种场景实用Hologres是非常适合的。 除此之外， Blink的维表查问必须是用行存，因为个别状况下Blink的维表是高QPS、基于Key的查问，列存没有方法扛住这么高的压力。 列存实用于简单的交互式剖析查问，比方一个查问外面，它有关联、聚合等等各种各样的简单计算。同时它笼罩的场景十分多，包含过滤、聚合等，列存是比拟通用的存储形式。 行存次要实用于在线服务类的场景，列存次要实用于剖析型的场景，这是两个存储形式的抉择区别。 （四）优化Shard数Shard\_count: Shard实现了物理分表的成果，多个Shard并行服务查问。 减少Shard能够减少查问的分布式并行度，更多Shard不肯定查问更快，也会带来并发查问的调度开销。 说完存储形式，接下来咱们看Shard数。 Hologres在存储的时候，是把物理表分成一个个Shard存储，每个表会依照肯定的散布形式散布到所有的物理节点下面，而后每个Shard能够去并发进行查问，Shard数越多，相当于整个查问的并发度越高。然而Shard数也不是越多越好，因为它自身有一些额定的开销，所以咱们须要依据整个查表的数据量以及查问复杂度来设计每个表的Shard数。 在集群扩容的时候，比方咱们本来是128 Core的实例，扩容到256 Core之后，咱们须要对整个Shard数进行肯定的调整，这样能力享受扩容带来的性能晋升。 因为咱们整个并发度是在Shard数下面，如果实例扩容了，然而Shard数没变，那么相当于整个计算的并发度没变，这种状况会导致尽管扩容了，然而查问性能没有晋升。 个别状况下，咱们会倡议用户将Shard数设置成跟实例规格差不多的数量，比方一个64 Core的，Shard数设成40或64这种比拟贴近于实例规格的数量。当规格往上涨之后，咱们心愿Shard数也能往上涨，从而进步整个查问的并发度。 （五）优化Distribution Key而后说完Shard数之后，咱们再看一下Hologres外面十分重要的Distribution Key，它次要是用来决定数据如何分到每个Shard下面。 Distribution\_key:平衡地散发数据到多个Shard中，令查问负载更平衡，查问时间接定位到对应Shard。 如果创立了Primary Key索引（用于数据更新），默认为distribution\_key， Distribution\_key如果为空，默认是Random，Distribution\_key需是Primary Key的子集。 一个好的Distribution Key设计，首先要求用户的数据在Distribution Key上划分比拟平均。 比方用户ID或者是商品宝贝ID，个别状况下Key只有一个，所以它是十分平均的，是用来作为Distribution Key十分好的例子。然而像年龄或者性别这种就不太适宜作为Distribution Key，因为它可能会使大量的数据Shuffle到一个节点上，导致整个数据的散布不是很平均。 Distribution Key次要的作用是缩小关联查问、聚合运算里数据的Shuffle。 如果用户没有设置Distribution Key，那么咱们默认是Random，因为咱们会保障用户的数据可能尽可能平均地散布到所有Shard下面。 接下来咱们看一下Distribution Key次要的作用。 在Hologres外面咱们会有不同的表，放到不同的TableGroup外面，对于Shard数雷同的表，都会放到一个TG上面。 假如两个表做关联，如果都依照关联的Key去设计Distribution Key，那么这两个表的关联就能够做一个Local Join，如上图右边所示。所有的数据不须要做额定的Shuffle，每个表在每个Shard下面，做完关联之后间接产生后果。 如果数据量增大，之后可能须要扩容，咱们心愿在这个TG上面所有表都会进行扩容，这样能保障数据分布的一致性，维持住整个Local Join，而不会因为扩容导致做不了Local Join。 Local Join相比于非Local Join，性能差异十分大，通常会有一个数量级左右的差别。 跟Local Join最相干的就是Distribution Key的设计，如果Distribution key设计不合理时，在Join时，可能引起大量的Data Shuffle，影响效率。 如上图所示，假如表A跟表B要做一个关联，如果不是Distribution Key的场景，那么咱们就须要把表A的数据跟B的数据都依照它的Join Key做Shuffle， Shuffle会带来十分昂扬的老本，同时影响整个查问的效率。 所以通常状况下，对于须要连贯的表，能够把Join关系设为distribution key，实现Table在同一个Shard内Local Join。 ...

简介：在日前的2021阿里云金融数据智能峰会——《云原生驱动数智化经营的“增长黑马”》专场上，阿里云数据库资深技术专家魏闯先 从数据价值链路角度切入，为大家解读云原生数据仓库如何撑持数据化经营、全链路营销和阿里团体双11业务，并展现金融客户最佳实际案例和利用场景。本文内容依据演讲录音及PPT整顿而成。在日前的2021阿里云金融数据智能峰会——《云原生驱动数智化经营的“增长黑马”》专场上，阿里云数据库资深技术专家魏闯先 从数据价值链路角度切入，为大家解读云原生数据仓库如何撑持数据化经营、全链路营销和阿里团体双11业务，并展现金融客户最佳实际案例和利用场景。本文内容依据演讲录音及PPT整顿而成。 阿里云数据库资深技术专家魏闯先 一、背景与趋势（一）阿里巴巴15年云计算实际 回顾阿里巴巴十五年来云原生倒退的路线，大抵分为三个阶段。 第一个阶段是2006年～2015年的利用架构互联网化阶段，是云原生从0到1的过程。最早的时候，阿里巴巴在淘宝上做中间件，那是最早的云的雏形。过后咱们钻研的是Oracle数据库和IBM的小型机。但阿里巴巴发现一个问题，就是随着淘宝流量越来越大，Oracle的机器无奈持续满足业务需要，三个月之后，咱们的数据将存不下也算不了。这是十分重大的问题，所以过后阿里巴巴启动了去IOE的打算。 这个时候，阿里巴巴发现咱们的业务做得十分好，但技术上有很多挑战。因而，阿里巴巴在2009年成立了阿里云，自研飞天操作系统，开启云化时代，淘宝和天猫合并建设业务中台，届时三大中间件外围零碎上线。 飞天操作系统基于Apsara，是一个分布式的操作系统。在根底公共模块之上有两个最外围的服务：盘古和伏羲。盘古是存储管理服务，伏羲是资源调度服务，飞天内核之上利用的存储和资源的调配都是由盘古和伏羲治理。飞天外围服务分为：计算、存储、数据库、网络。 为了帮忙开发者便捷地构建云上利用，飞天提供了丰盛的连贯、编排服务，将这些外围服务不便地连贯和组织起来，包含：告诉、队列、资源编排、分布式事务管理等等。 飞天最顶层是阿里云打造的软件交易与交付第一平台----云市场。它如同云计算的“App Store”，用户可在阿里云官网一键开明“软件+云计算资源”。云市场上架在售商品几千个，反对镜像、容器、编排、API、SaaS、服务、下载等类型的软件与服务接入。 这就是最早的云的根底框架，也是一个云原生的架构。 从2011年开始，咱们开始做容器调度，在团体外面开始做在线业务，在线的业务开始走容器化。到了2013年，自研飞天操作系统全面撑持团体业务。 2015年，阿里云的云原生技术不单是给阿里巴巴的外部业务应用，也开始对外做商业化，以上就是第一阶段。 第二阶段是2016年～2019年的外围零碎全面云原生化阶段。 从2017年开始，咱们不只做在线了，离线也全副采纳了云原生的技术。双11购物节有大量的交易数据，这些数据的后盾剖析和前期解决都是交给离线实现。咱们基于云原生把在线和离线的底层资源池对立，撑持百万级规模电商交易。 到了2019年，阿里巴巴外围零碎100%上云，这其实十分难，因为阿里巴巴的业务量十分微小，任何一般的零碎都无奈撑持。 第三阶段是2020年至今，是全面降级下一代云原生技术的阶段。阿里巴巴成立云原生技术委员会，云原生降级为阿里技术新策略。阿里巴巴外围零碎全面应用云原生产品撑持大促。阿里云云原生技术全面降级，Serverless时代开启。 （二）阿里云对于云计算的断言阿里巴巴是怎么对待云计算的？云计算和传统技术的差异到底是什么？ 举个例子，在一个家家户户都须要挖井的村庄里，每家依据自家人口数量、大略须要的出水量、是否会有客人来等等因素，决定挖多宽的井。如果遇上家里客人比拟多或者干旱了等情况，水可能就不够用了。除了挖井的老本外，日常保护这口井，也须要很高的老本。 上述场景映射到企业中，就是企业基于本人的IT根底，还要到运营商那里买个机房，买几台服务器来撑持本人的服务。如果后续这些机器闲置的话，企业依然须要领取一大笔费用，老本十分高。 云解决的问题就是通过虚拟化的技术实现资源池化，用上方挖井例子来形容就是建一个自来水厂。自来水厂和井的差异在于，第一，供水量很大，即便来100个客人，供水量也能满足需要。第二，后期不须要投入大量老本去挖井，而是依据用水需要按量计费。即便接通自来水管道，如果不必，那么永远也不须要为它付费。 这为企业带来了两大益处，第一个是企业须要做疾速决策的时候，不必花大量工夫去“挖井”，而是开箱即用。第二是后期投入老本很低。 这就是云带来的益处，那么什么是云原生呢？ 云原生是个规范服务，很多货色咱们不须要提前布局。比方我要做数字化转型，需要很简略。我须要有人给我提供这个服务，我要多少，他给我调配多少，不须要我去做提前的筹备。随着我业务的增长，它底下的基础设施可能随之一起增长，具备十分好的弹性。这也大大地缩小企业老本与精力，能够更加专一地去做最善于的事件，大幅晋升效率。 通过以上的例子，上面这几点就十分好了解了。 首先，咱们认为容器+K8s会成为云计算的新界面，这是将来的一个趋势。 其次，整个软件生命周期也会发生变化。原来软件的生命周期很长，当初通过云原生的技术能够做到迭代速度越来越快，向下延长软硬一体化、向上延长架构现代化等都能够去做。 最初，减速企业数字化降级。原来做企业数字化转型非常复杂，可能要买机器、买数据库、买利用，须要三年五载的工夫来实现。而现在的企业数字化转型，只花短短数月的工夫，便可实现齐全转型。 （三）业界趋势：数据生产/解决正在产生量变从业界趋势上看，将来数据会产生什么变动，给利用带来什么变动？ 首先，咱们认为将来数据肯定会规模爆炸性增长。2020年寰球数据规模约为40 ZB。40 ZB是什么概念？举个例子，假如每部电影是1GB，假如全世界每个人都去看一部电影，那么这些数据量加起来大略就是40ZB。 除此之外，咱们预计2025年的寰球数据规模将会是2020年的430%，寰球数据规模每年都在增长。 第二个是数据生产/解决实时化。原先咱们可能一个月看一次报表，通过大数据，咱们能够每天看一次昨天的数据。数据越来越实时化，可能实现秒级响应。以营销场景为例，在双十一购物节场景，当商家发现店铺的某个流动不能产生成果，那么能够在一分钟或者数分钟之内调整广告或投放策略，从而达到更好的营销成果。如果数据是按天反馈，在11月12日看到数据的时候，做流动带来的成果曾经大大降低了。因而，数据实时化在这样相似的场景中，扮演着非常重要的角色，数据的实时也会带来利用的实时。 第三是数据生产/解决智能化。目前在所有数据中，非结构化数据占比80%，次要包含文本、图形、图像、音频、视频等，尤其是在当下热门的直播畛域，对非结构化数据进行智能化解决，可能晓得观众的爱好与其余信息，不便业务更好地发展。除此之外，非结构化数据以每年减少55%的速度持续增长，将来将成为数据分析十分重要的一个起源。 第四个是数据减速上云。咱们认为数据上云势不可挡，正如汽油车终将被电车代替一样。预计到2025年的时候，数据存储云上规模为49%，2023年数据库上云规模75%。 （四）业界趋势：云计算减速数据库系统演进另一个业界趋势不容疏忽：云计算减速数据库系统演进。 首先咱们看一下数据库倒退历程。早在八九十年代数据库就曾经诞生，那时候次要是商业数据库，如Oracle、IBM DB2等，这外面有些数据库还占据这现在的市场。 到90年代，开源数据库开始涌现，如PostgreSQL、MySQL等。国内用MySQL比拟多，国外用PostgreSQL比拟多。到90年代当前，数据量越来越大，原来数量小的时候可能用PostgreSQL或MySQL，单机就能够解决问题，随着数据量爆炸性增长，就须要像分布式或小型机的形式去解决大量数据和剖析问题。 数据分析的重要性体现在哪里？ 举个例子，有个数据仓库Snowflake的公司在刚上市的时候就达到1000亿美金的市值，现在也有700亿美金，对于一个只做一款产品的公司来说，这是一个十分高的市值。为什么它的市值这么高？ 前段时间和一位老师交换，他说对于当初的企业，尤其是电商或直播等互联网企业，新近他们企业最大的老本是人力，员工工资占据次要收入。但现在最大的收入是信息和数据，为了公司将来的倒退布局，须要领有大量的数据来剖析以后客户最想要什么，最须要什么，业界的倒退是什么。因而，公司须要大量购买数据、做大量的数据分析，这方面的老本曾经超过了人员老本。这也是为什么一个只做数据仓库的公司，市值可能达到700亿美金。 2000年当前大家开始用Hadoop、Spark，2010年开始呈现云原生、一体化分布式等产品，例如AWS、AnalyticDB等。 （五）业界趋势：数据仓库减速从Big Data向 Cloud-Native + Fast Data 演进 上方是数据仓库的演进历史，计算形式从离线到在线，再到离在线一体化，而后到分布式。性能从统计到AI，数据类型也从结构化到结构化与非结构化多模交融，负载从OLAP到HTAP，硬件也降级为软硬件一体化，交付从On-Premise 到Cloud - Native + Serverless。 在演进的不同过程中，有着各式各样的产品做撑持。 （六）数据库系统架构演进 上图为数据库系统架构演进，简略的逻辑能够了解为，原来是一个厂房一个人干活，起初变成一个厂房十个人干活，而后再倒退成多个厂房多集体干活，这就是整个数据仓库的倒退历史，由原来的单机变成分布式，并且一份数据多集体应用。 数据库的倒退也跟人类工作一样，原来有的店夫妻二人就能够维持，一个人负责生产，另一个人负责销售。随着倒退，店里的顾客越来越多，店还是一个店，但员工可能有十个人了。再起初，业务倒退更多大了，一下招10万个员工，而后在10个场地去干，这就是分布式云原生数据仓库。 （七）业界趋势：云原生数据库关键技术 上方是云原生数据库的关键技术。 这里简略说两个技术，首先是云原生，云原生是什么意思呢？如果某位用户买了个数据库，当业务量少的时候，或者在法定节假日不应用的时候，免费就少，而在业务量大的时候，免费就多一些。按需按量免费，这是咱们对数据仓库的一个要求。 另外一个是平安可信，举个例子，阿里巴巴有一个投资部，如果给A公司投了500万，给B公司投了100万，这些信息都是高度私密，不可对外泄露的。如果这些信息是由员工进行治理，员工存在到职的可能，而一旦到职后产生泄密行为，这在法律层面也很难追责。如何让这种高度私密的信息齐全加密，使得就算是领有最高权限的DBA也无奈查看这类信息，做到平安可信。后文将对此做具体开展。 二、云原生与大数据利用（一）业务面临的挑战 ...

简介：Gartner 的报告显示预计到2022年将有75%数据库将采纳云数据库，与此同时，IDC预计到2024年传统部署数据库市场将达到13亿美元，企业数字化转型降级，踊跃拥抱开源、云原生数据库成为重要趋势，也是必然选择。 目前阿里云数据库在私有云市场占有率已超过50%占据半壁江山。2020年阿里云数据库成为惟一一家进入Gartner数据库魔力象限领导者象限的中国厂商，荣占亚太第一寰球第三的地位。 为了更好的服务于传统部署的数据库市场，更全面的为云化各阶段政企服务，阿里云混合云与数据库团队联结重磅推出麻利版独立场景轻量化单品：麻利版数据库场景（DBStack）。Gartner 的报告显示预计到2022年将有75%数据库将采纳云数据库，与此同时，IDC预计到2024年传统部署数据库市场将达到13亿美元，企业数字化转型降级，踊跃拥抱开源、云原生数据库成为重要趋势，也是必然选择。 目前阿里云数据库在私有云市场占有率已超过50%占据半壁江山。2020年阿里云数据库成为惟一一家进入Gartner数据库魔力象限领导者象限的中国厂商，荣占亚太第一寰球第三的地位。 为了更好的服务于传统部署的数据库市场，更全面的为云化各阶段政企服务，阿里云混合云与数据库团队联结重磅推出麻利版独立场景轻量化单品：麻利版数据库场景（DBStack）。 产品介绍麻利版数据库场景（DBStack），是阿里云提供的集交易、剖析、传输、治理于一体的企业级云数据库治理平台，帮忙企业疾速构建稳固、平安、经济的全场景数据库解决方案，帮忙企业疾速降级如Oracle、DB2、Teradata等传统数据库与数据仓库。 麻利版数据库场景 DBStack产品矩阵 外围性能 DBStack数据库治理平台提供的数据库引擎方服务蕴含阿里巴巴自研的云原生Oracle高兼容性数据库PolarDB-O、云原生分布式数据库PolarDB-X、云原生剖析型数据库AnalyticDB等，也蕴含开源数据库MySQL、Redis等，以及阿里自研的丰盛的数据库生态工具如DTS、DMS、ADAM等。 麻利版数据库场景（DBStack），针对所有的数据库服务提供对立的智能化的治理服务，包含提供数据库实例管控能力的DBaaS服务，提供如实例生命周期治理、备份复原体系、平安加密治理、数据库日志和SQL审计、监控告警、高可用治理等外围个性，同时也包含提供DBStack平台级的运维治理（Manager），提供如平安流程（如账号平安）治理、外部设备系统管理、主机治理、数据库实例工作治理、实例资源管理、容灾治理和平台降级扩容等服务。即平台分为应用数据库服务和治理平台服务，用户可通过零碎的控制台、OpenAPI、SDK等管制链路拜访治理平台，通过实例提供的拜访连贯拜访数据库服务。 产品劣势 麻利版数据库场景（DBStack），产品劣势蕴含四个方面，包含丰盛的数据库引擎服务、齐备的数据库生态工具、跨平台的部署能力、和云原生的管控体系。 <1> 引擎丰盛：DBStack中提供全域数据库引擎，涵盖OLTP、OLAP、和NoSQL的数据库服务，还有分布式数据库和Oracle高兼容数据库，满足企业数据库的绝大多数场景数据库需要。 <2> 工具齐备：DBStack的数据库生态工具体系，包含数据管理、数据库和利用迁徙工具、数据传输。数据管理提供用户治理数据库内对象和数据管理。数据库和利用迁徙工具评估从传统数据库迁徙降级到DBStack的兼容改变点。数据传输包含的数据的迁徙、同步和订阅，迁徙是指从其余数据库迁徙数据到DBStack，或者迁徙数据到其余数据库，同步是指多个数据库之间的不间断数据库同步，订阅是指提供其余零碎从数据库订阅数据的计划。 <3> 跨平台部署：DBStack具备跨平台部署的个性，能够部署到物理服务器或者虚拟机中，反对多种操作系统，如Linux和国产操作系统。 <4> 云原生管控：DBStack提供阿里云私有云数据库的所有云原生的管控能力，涵盖高可用、高牢靠、高弹性、性能、扩大能力、易管理性、性价比、平安合规等方面。 <5> 一站式数据库综合解决方案：DBStack内丰盛的数据库引擎服务和欠缺的工具生态，用户可不便的组合出面向业务和面向场景的稳固的牢靠的高性价比的综合性数据库解决方案。 重要利用场景 麻利版数据库场景DBStack已反对多款数据库引擎和数据库生态工具产品，灵便的产品组合可满足于不同的利用场景。 例如在传统的流量剖析零碎须要同时引入离线计算和在线计算引擎，并通过定时ETL工作实现在线和离线数据的互通，数据冗余重大，且存在T+1的提早。麻利版数据库场景 DBStack AnalyticDB PostgreSQL 数据库引擎反对在离线一体，一套存储同时提供在线和离线计算，大幅升高业务复杂度，晋升数据的实时性。相比而言，数据时效性从T+1晋升到秒级时延，可疾速查出简略指标，复合指标和多维度指标，为整个链路提供实时百亿级数据秒级查问的在线业务。 总结 麻利版数据库场景DBStack作为对立的一站式数据库平台，必然会引领将来企业数据库降级。随着企业数字化转型，企业对数据的应用会全业务全方位波及，对撑持数据存储的数据库系统的整体可靠性、可用性、存储容量、性能以及扩大都更高的要求，同时对数据库资源的利用率会更加充沛，企业也会更加冀望在一个平台中满足数据产生、解决、剖析、再利用的残缺闭环，麻利版数据库场景DBStack平台一站式满足客户所有需要，是最佳抉择。 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

简介：《实时数仓入门训练营》由阿里云研究员王峰、阿里云高级产品专家刘一鸣等实时计算 Flink 版和 Hologres 的多名技术/产品一线专家齐上阵，合力搭建此次训练营的课程体系，精心打磨课程内容，直击当下同学们所遇到的痛点问题。由浅入深全方位解析实时数仓的架构、场景、以及实操利用，7 门精品课程帮忙你 5 天工夫从小白成长为大牛！本文整顿自直播《基于 Apache Flink + Hologres 的实时举荐零碎架构解析-秦江杰》 视频链接:https://developer.aliyun.com/learning/course/807/detail/13888 摘要：本文由实时数仓线上课程秦江杰老师演讲内容整顿。 内容简要： 一、实时举荐零碎原理 二、实时举荐零碎架构 三、基于 Apache Flink + Hologres 的实时举荐零碎关键技术实时举荐零碎原理（一）动态举荐零碎在介绍实时举荐零碎之前，先看一下动态举荐零碎是什么样子的。 上方是一个十分经典的动态举荐零碎的架构图。前端会有很多用户端的利用，这些用户会产生大量用户的行为日志，而后放到一个音讯队列外面，进入ETL。接着通过离线零碎去做一些特色生成和模型训练，最初把模型和特色推到线上零碎中，通过在线的服务就能够去调用在线推理服务去取得举荐后果。 这就是一个十分经典的动态举荐零碎运作流程，上面咱们举一个具体的例子来看动态举荐零碎到底是怎么样工作的。 如上图所示，比方在线用户的行为日志可能是一些用户的浏览和广告点击的日志，举荐零碎的目标是为了帮用户举荐广告，那么在日志外面能够看到以下用户行为： 用户1和用户2都看了PageID 200和一些其余的页面，而后用户1看了PageID 200并且点了广告2002，那么在用户日志外面通过ETL能够把这样的一系列行为给演绎进去，而后送到模型训练外面去训练模型。在训练模型的过程当中咱们会用到一些特色，在这个状况下咱们能够发现用户1和用户2都是中国的男性用户，这可能是用户维度的一个特色。 在这种状况下，咱们从日志外面看到的后果是用户在看了PageID 100后点了广告2002，并且两个用户都是中国的男性用户。因而，咱们的模型就有可能学到当中国的男性用户来看PageID 100的时候，应该要给他展现广告2002，这个行为会被训练到模型外面去。这个时候咱们会把一些用户的离线特色都推到特色库，而后把这个模型也推到线下来。 假如这里有一个用户ID4，他正好是中国的男性用户，这个特色就会被推动特色库，那模型也被推到线上。如果用户4来拜访的时候看PageID 100，推理服务会先去看用户ID4的特色，而后依据他是一个中国的男性用户，通过训练的模型，零碎就会给他推广告2002，这是一个动态举荐零碎根本的工作原理。 在这种状况下，如果产生一些变动的时候，咱们来看一下动态举荐零碎是不是可能持续很好地工作？ 假使说明天训练了用户1和用户2的特色模型，到第二天发现用户4产生了行为，依据模型外面的内容，模型会认为用户4是中国的男性用户和用户1、用户2行为统一，所以须要给他推的应该是中国男性用户的行为。但这个时候咱们发现用户4的行为其实跟用户3更像，而不是跟用户1和用户2更像。 在这种状况下，因为模型和特色都是动态的，所以为了让用户4可能跟用户3失去的行为更像，须要去从新训练模型，这会导致预测的成果被提早，因为须要从新训练用户4，才可能举荐出跟用户3更像的一些行为。 所以在这种实际操作状况下，能够看到动态举荐模型存在一些问题： 动态生成模型和特色；以分类模型为例，依据用户的相似性进行用户分类，假如同类用户有类似的趣味和行为 例如中国的男性用户有相似行为。一旦用户被划分为某个类别，则他将始终处于这个类别中，直到被新的模型训练从新分类。这种状况下，比拟难去做到很好的举荐，起因是： 用户的行为十分多元化，无奈划分到某个固定类别 1）上午为父母洽购保健品，中午为出差订酒店，早晨给家人买衣服… 2）动态零碎无奈精确将用户放到过后当刻正确的类别中。某一类别用户的行为类似，然而行为自身可能会发生变化 1）假如用户“随大流“，然而“大流”可能发生变化； 2）历史数据看进去的“大流”可能无奈精确反映线上的真实情况。（二）退出实时特色工程的举荐零碎为了解决上述问题，能够退出动静特色。那么动静特色是什么样的？举个例子阐明。 如上图所示，咱们以大流发生变化的动静特色举例。之前的模型举荐是如果中国的男性用户拜访PageID 100，就给他举荐广告2002，这是一个固定不变的行为。 在此基础上做一些变动，当进行采样实时特色的时候，这个实时特色是最近一段时间内，即当中国的男性用户拜访PageID 100的时候，他们点击最多的10个广告。这个特色没有方法在离线的时候计算出来，因为它是一个线上实时产生的用户行为。 那么在产生用户行为之后能够做一件什么事件呢？能够在中国的男性用户拜访PageID 100的时候，不单纯给他推广告2002，而是推最近这段时间中国男性用户拜访PageID 100时候点击最多的那些广告。 这样的状况下，如果中国男性用户拜访PageID 100的时候，最近拜访最多的广告是2001和2002。当用户ID来了，咱们看到他是一个中国男性用户，就有可能给他举荐广告2001，而不是广告2002了。 上述就是大流发生变化的一个例子。 同样的情理，因为零碎能够对用户的实时特色进行采样，所以能更好地判断用户过后当刻的用意。比方说，能够去看用户最近一分钟看了哪些页面，浏览哪些商品，这样的话能够实时判断用户过后当刻的想法，从而给他举荐一个更适宜他当下用意的广告。 这样的举荐零碎是不是就齐全没有问题呢？再看一个例子。 比方说方才上文提到用户1和用户2都是中国男性用户，之前假如他们的行为是相似的，在之前的历史数据外面也印证了这一点。然而当在线上真正看用户行为的时候，可能会产生什么样的状况？ 可能产生用户1和用户2的行为产生分化，分化的起因可能有很多种，但不晓得是什么起因。此时给用户1和用户2所举荐的货色可能就齐全不一样了，那是什么起因导致分化了？ 举个例子来说，如果用户1来自上海，用户2来自北京。某天北京有十分大的降温，这个时候北京用户2可能就开始搜寻秋裤，然而上海当天还是很热，上海的用户1在搜寻服装的时候，可能还是搜寻一些夏装。这个时候，中国的男性用户外面，上海用户1和北京用户2的搜寻行为就产生了一些变动。此时就须要给他们举荐不一样的广告，然而动态的模型没有方法很好地做到这一点。 因为这个模型其实是一个动态训练的模型，所以如果是一个分类模型的话，当中可能产生的类别其实是一个固定的类别，为了产生一个新的分类，就须要对模型从新进行训练。因为模型训练是离线进行的，所以可能这个训练的模型须要在第二天能力被更新，这样就会对举荐成果产生影响。 通过减少动静 feature 1）实时跟踪一类用户的行为，贴合“大流”； 2）实时追踪用户的行为表现，理解用户过后当刻的用意，并将用户划分到更适合的类别中去。然而当模型的分类形式自身发生变化时，可能无奈找到最合适的类别，须要从新训练模型减少分类。例：新产品上线频繁，业务高速成长，用户行为的散布变动比拟快。 当遇到以上问题，须要把思考的事件退出动静的模型更新，动静模型更新是怎么来做？其实是一样的情理。 ...

简介： 《实时数仓入门训练营》由阿里云研究员王峰、阿里云资深技术专家金晓军、阿里云高级产品专家刘一鸣等实时计算 Flink 版和 Hologres 的多名技术/产品一线专家齐上阵，合力搭建此次训练营的课程体系，精心打磨课程内容，直击当下同学们所遇到的痛点问题。由浅入深全方位解析实时数仓的架构、场景、以及实操利用，7 门精品课程帮忙你 5 天工夫从小白成长为大牛！ 本文整顿自直播《Hologres性能调优实际-清芬》视频链接:https://developer.aliyun.com/... 内容简要： 一、Hologres建表最佳实际 二、Hologres性能问题剖析与优化 一、Hologres建表最佳实际（一）建表优化的必要性为什么Hologres建表优化十分重要？ 首先，对于整个的查问性能以及写入性能来讲，一个好的建表跟一个比拟差的建表，性能下面有十分大的区别。 其次，建表优化须要尽早做，是因为Hologres在改 DDL的同时，有可能须要用户反复进行一些数据导入，这种反复的工作使得咱们心愿尽早实现建表优化。 最初，一个好的建表对于用户的数据存储老本也有肯定的帮忙。如果建表做得不失当，可能导致建一些不必要的Index，而后导致数据多了一些冗余的存储，从而晋升了老本。因而，建表优化是十分重要的，这也是把它作为本文第一局部的起因。 （二）业务建模是性能优化的前提说完建表的重要性之后，咱们再看建表优化之前要去做整个业务建模的优化。在思考应用Hologres的同时，咱们要晓得通过Hologres可能解决什么样的业务问题，以及通过什么样的形式解决。 Hologres自身是一个HASP产品，在应用Hologres的同时就须要跟业务场景联合，咱们要晓得这个场景到底是剖析场景还是在线服务场景。如果是一个剖析型，就用Hologres的列存比拟敌对，如果是一个在线服务型场景，就用行存比拟敌对，这些是跟业务场景相干的。 第二个是要可能联合Hologres自身的产品劣势。Hologres是一个在线服务以及交互式剖析的产品，它并不适宜ETL以及海量数据拖取的场景。因而，在把业务往Hologres下面搬的时候，不能搬所有的场景，否则可能导致Hologres做一些不太适宜自身的事件，信赖就会不太好。 第三个是须要做一些取舍。为了达到预期的性能，可能须要做一些相似预计算或者数据加工的提前操作，缩小后续计算复杂度，放慢计算速度。 以上这些都跟事后数据建模以及整个业务冀望非亲非故。 （三）存储形式的抉择做完以上筹备工作之后，咱们须要进行Hologres治理存储形式的抉择。 Hologres自身反对两种存储形式，别离是行存和列存。 行存次要的利用场景是对主键进行高QPS查问，并且当咱们表比拟宽的时候，一次查问会读取大量列，这种场景实用Hologres是非常适合的。 除此之外， Blink的维表查问必须是用行存，因为个别状况下Blink的维表是高QPS、基于Key的查问，列存没有方法扛住这么高的压力。 列存实用于简单的交互式剖析查问，比方一个查问外面，它有关联、聚合等等各种各样的简单计算。同时它笼罩的场景十分多，包含过滤、聚合等，列存是比拟通用的存储形式。行存次要实用于在线服务类的场景，列存次要实用于剖析型的场景，这是两个存储形式的抉择区别。 （四）优化Shard数Shard_count: Shard实现了物理分表的成果，多个Shard并行服务查问。减少Shard能够减少查问的分布式并行度，更多Shard不肯定查问更快，也会带来并发查问的调度开销。 说完存储形式，接下来咱们看Shard数。 Hologres在存储的时候，是把物理表分成一个个Shard存储，每个表会依照肯定的散布形式散布到所有的物理节点下面，而后每个Shard能够去并发进行查问，Shard数越多，相当于整个查问的并发度越高。然而Shard数也不是越多越好，因为它自身有一些额定的开销，所以咱们须要依据整个查表的数据量以及查问复杂度来设计每个表的Shard数。 在集群扩容的时候，比方咱们本来是128 Core的实例，扩容到256 Core之后，咱们须要对整个Shard数进行肯定的调整，这样能力享受扩容带来的性能晋升。 因为咱们整个并发度是在Shard数下面，如果实例扩容了，然而Shard数没变，那么相当于整个计算的并发度没变，这种状况会导致尽管扩容了，然而查问性能没有晋升。 个别状况下，咱们会倡议用户将Shard数设置成跟实例规格差不多的数量，比方一个64 Core的，Shard数设成40或64这种比拟贴近于实例规格的数量。当规格往上涨之后，咱们心愿Shard数也能往上涨，从而进步整个查问的并发度。 （五）优化Distribution Key而后说完Shard数之后，咱们再看一下Hologres外面十分重要的Distribution Key，它次要是用来决定数据如何分到每个Shard下面。 Distribution_key:平衡地散发数据到多个Shard中，令查问负载更平衡，查问时间接定位到对应Shard。 如果创立了Primary Key索引（用于数据更新），默认为distribution_key， Distribution_key如果为空，默认是Random，Distribution_key需是Primary Key的子集。 一个好的Distribution Key设计，首先要求用户的数据在Distribution Key上划分比拟平均。 比方用户ID或者是商品宝贝ID，个别状况下Key只有一个，所以它是十分平均的，是用来作为Distribution Key十分好的例子。然而像年龄或者性别这种就不太适宜作为Distribution Key，因为它可能会使大量的数据Shuffle到一个节点上，导致整个数据的散布不是很平均。 Distribution Key次要的作用是缩小关联查问、聚合运算里数据的Shuffle。 如果用户没有设置Distribution Key，那么咱们默认是Random，因为咱们会保障用户的数据可能尽可能平均地散布到所有Shard下面。 接下来咱们看一下Distribution Key次要的作用。 在Hologres外面咱们会有不同的表，放到不同的TableGroup外面，对于Shard数雷同的表，都会放到一个TG上面。 假如两个表做关联，如果都依照关联的Key去设计Distribution Key，那么这两个表的关联就能够做一个Local Join，如上图右边所示。所有的数据不须要做额定的Shuffle，每个表在每个Shard下面，做完关联之后间接产生后果。 如果数据量增大，之后可能须要扩容，咱们心愿在这个TG上面所有表都会进行扩容，这样能保障数据分布的一致性，维持住整个Local Join，而不会因为扩容导致做不了Local Join。 ...

简介：上海站 Flink Meetup 分享内容，如何基于Flink、对象存储、Iceberg 来构建数据湖生态。 本文整顿自 Dell 科技团体高级软件研发经理孙伟在 4 月 17 日 上海站 Flink Meetup 分享的《Iceberg 和对象存储构建数据湖计划》，文章内容为： 数据湖和 Iceberg 简介对象存储撑持 Iceberg 数据湖演示计划存储优化的一些思考GitHub 地址 https://github.com/apache/flink 欢送大家给 Flink 点赞送 star~ 一、数据湖和 Iceberg 简介1. 数据湖生态 如上图所示，对于一个成熟的数据湖生态而言： 首先咱们认为它底下应具备海量存储的能力，常见的有对象存储，私有云存储以及 HDFS；在这之上，也须要反对丰盛的数据类型，包含非结构化的图像视频，半结构化的 CSV、XML、Log，以及结构化的数据库表；除此之外，须要高效对立的元数据管理，使得计算引擎能够不便地索引到各种类型数据来做剖析。最初，咱们须要反对丰盛的计算引擎，包含 Flink、Spark、Hive、Presto 等，从而不便对接企业中已有的一些利用架构。2. 结构化数据在数据湖上的利用场景 上图为一个典型的数据湖上的利用场景。 数据源上可能会有各种数据，不同的数据源和不同格局。比如说事物数据，日志，埋点信息，IOT 等。这些数据通过一些流而后进入计算平台，这个时候它须要一个结构化的计划，把数据组织放到一个存储平台上，而后供后端的数据利用进行实时或者定时的查问。 这样的数据库计划它须要具备哪些特色呢？ 首先，能够看到数据源的类型很多，因而须要反对比拟丰盛的数据 Schema 的组织；其次，它在注入的过程中要撑持实时的数据查问，所以须要 ACID 的保障，确保不会读到一些还没写完的中间状态的脏数据；最初，例如日志这些有可能长期须要改个格局，或者加一列。相似这种状况，须要防止像传统的数仓一样，可能要把所有的数据从新提出来写一遍，从新注入到存储；而是须要一个轻量级的解决方案来达成需要。Iceberg 数据库的定位就在于实现这样的性能，于上对接计算平台，于下对接存储平台。 3. 结构化数据在数据湖上的典型解决方案 对于数据结构化组织，典型的解决形式是用数据库传统的组织形式。 如上图所示，上方有命名空间，数据库表的隔离；两头有多个表，能够提供多种数据 Schema 的保留；底下会放数据，表格须要提供 ACID 的个性，也反对部分 Schema 的演进。 4. Iceberg 表数据组织架构 快照 Metadata：表格 Schema、Partition、Partition spec、Manifest List 门路、以后快照等。Manifest List：Manifest File 门路及其 Partition，数据文件统计信息。Manifest File：Data File 门路及其每列数据高低边界。Data File：理论表内容数据，以 Parque，ORC，Avro 等格局组织。接下来具体看一下 Iceberg 是如何将数据组织起来的。如上图所示： ...

简介：随同着 5G、IoT 等技术的疾速倒退，边缘计算被越来越宽泛地利用于电信、媒体、运输、物流、农业、批发等行业和场景中，成为解决这些畛域数据传输效率的要害形式。与此同时，边缘计算状态、规模、复杂度的日益增长，边缘计算畛域的运维伎俩、运维能力对边缘业务翻新速度的撑持日趋乏力。于是，Kubernetes 迅速成为边缘计算的要害因素，帮忙企业在边缘更好地运行容器，最大化利用资源、缩短研发周期。作者｜何淋波（新胜） 背景 随同着 5G、IoT 等技术的疾速倒退，边缘计算被越来越宽泛地利用于电信、媒体、运输、物流、农业、批发等行业和场景中，成为解决这些畛域数据传输效率的要害形式。与此同时，边缘计算状态、规模、复杂度的日益增长，边缘计算畛域的运维伎俩、运维能力对边缘业务翻新速度的撑持日趋乏力。于是，Kubernetes 迅速成为边缘计算的要害因素，帮忙企业在边缘更好地运行容器，最大化利用资源、缩短研发周期。 然而，如果将原生 Kubernetes 间接利用到边缘计算场景下，依然须要解决诸多问题，比方云与边个别位于不同网络立体，同时边缘节点广泛位于防火墙外部，采纳云(核心)边协同架构，将导致原生 K8s 零碎的运维监控能力面临如下挑战： K8s 原生运维能力缺失(如 kubectl logs/exec 等无奈执行)社区支流监控运维组件无奈工作(如 Prometheus/metrics-server ) 为了帮忙企业解决原生 Kubernetes 在边缘场景下对于利用生命周期治理、云边网络连接、云边端运维协同、异构资源反对等方方面面的挑战，基于 K8s 实现的边缘计算云原生开源平台 OpenYurt 应运而生，其也是 CNCF 在边缘云原生幅员中的重要组成部分。本文将具体介绍，作为 OpenYurt 外围组件之一的 Yurt-Tunnel 如何是扩大原生 K8s 零碎在边缘场景下相干能力的。 Yurt-Tunnel 设计思路 因为边缘能够拜访云端，因而能够思考在云边构建能够反向穿透的隧道，从而保障云(核心)能够基于隧道被动拜访边缘。过后咱们也考察了很多开源的隧道计划，从能力以及生态兼容性等方面，最初咱们抉择基于 ANP设计并实现了 Yurt-Tunnel 整体解决方案，具备平安，非侵入、可扩大、传输高效等长处。 实现形式在 K8s 云边一体化架构中构建一个平安、非侵入、可扩大的反向通道解决方案，计划中至多须要包含如下能力。 云边隧道构建隧道两端证书的自治理云端组件申请被无缝倒流到隧道 Yurt-tunnel 的架构模块如下图： 3.1 云边隧道构建 当边缘的 yurt-tunnel-agent 启动时，会依据拜访地址与 yurt-tunnel-server 建设连贯并注册，并周期性检测连贯的衰弱状态以及重建连贯等。 # https://github.com/openyurtio/apiserver-network-proxy/blob/master/pkg/agent/client.go#L189# yurt-tunnel-agent的注册信息:"agentID": {nodeName}"agentIdentifiers": ipv4={nodeIP}&host={nodeName}"当 yurt-tunnel-server 收到云端组件的申请时，须要把申请转发给对应的 yurt-tunnel-agent 。因为除了转发初始申请之外，该申请 session 后续还有数据返回或者数据的继续转发(如 kubectl exec )。因而须要双向转发数据。同时须要反对并发转发云端组件的申请，象征须要为每个申请生命周期建设一个独立的标识。所以设计上个别会有两种计划。 ...

简介：数字化转型是信息技术与产业的联合。须要转型的不仅仅是各个传统的产业，也蕴含信息产业自身，如互联网公司。DevOps 是数字化转型的重要组成部分，DevOps 的体系和实际也必须服务于数字化转型的需要，这是互联网和传统产业公司的独特挑战和使命。 编者按：本文源自阿里云云效团队出品的《阿里巴巴DevOps实际指南》，扫描上方二维码或返回：https://developer.aliyun.com/topic/devops，下载完整版电子书，理解阿里十年DevOps实践经验。 数字化时代，技术已成为产业倒退的外围，技术的交付速度和品质，间接关系业务的倒退和翻新。大部分企业在布局数字化转型策略时，都会把 DevOps 作为重要一环。 DevOps 的施行必须服务于数字化转型的指标。在施行 DevOps 时，咱们首先要了解数字化转型对它的冀望和要求。 数字化转型：从信息化到数字化数字化正在深刻扭转各个产业。就影响的广度和深度，毫无疑问数字化是一次技术反动。 工业革命以来的 5 次技术反动 《技术反动与金融资本》一书回顾了工业革命以来的 5 次技术反动的历程，总结了其中的共性。每一次技术反动大抵都能够分为三个期间：导入期、转折期和开展期。数字化反动也是如此： 导入期（1971-2000）：信息化阶段，互联网从无到有数字化反动的导入期开始于 1971 年。 第一台集体计算机和第一个微处理器都诞生在 1971 年。而此前，1969 年 ARPANET 诞生，成为起初互联网的原型；1968 年 NATO 第一次软件工程会议，标记着软件工程诞生。 微处理器、PC、互联网、软件工程，数字化的根底技术元素就绪。其后 30 年是数字化反动的导入期，互联网从无到有，让寰球范畴内信息获取、流传和解决都有了若干数量级的进步。 转折期（2000-2016）：基础设施就绪，技术和治理范式筹备技术改革不可能欲速不达，它须要基础设施的全面降级，以及行业认知的深层次转变。而这往往会让技术改革遭逢高潮， 2000 年的互联网泡沫，标记着数字化反动进入了转折期。 转折期影响的是业务倒退，但技术倒退自身并没停滞。这期间包含云、大数据、AI 和 IoT 等大力发展，奠定了数字化的基础设施。数字化理念也一直深入，并开始在各个行业收获。 明天业界公认转折期曾经完结。对中国 2016 是一个标志性的年份，那一年中国的互联网网民超过 7 亿，互联网人口首次过半，再也不可能翻番了。信息产业不可能再单纯依附互联网人口红利来维持增长。数字反动必须向纵深倒退，与各个产业联合。 开展期（2016-至今）：数字化阶段，互联网从有到“无”明天，数字化反动正处于其开展期，它的要害标记是：数字化转型成为各个产业共识。人们关怀的不是要不要数字化，而是数字化如何与具体的产业联合。 2016 年是中国产业数字化转型的元年，正如马云在 2016 乌镇的互联网大会上所说，过来 30 年互联网从无到有，将来 30 年互联网从有到“无”，这里的无指的是无处不在，互联网产业和传统产业的界线正在隐没。 总结数字化反动曾经走过的历程，咱们正在从信息化向数字化转变。信息化和数字化有什么不同？ 信息化面向的是信息及互联网产业，包含企业内的信息部门。它关注的对象是信息，解决信息互联互通的问题。它最终目标是晋升信息获取、存储、解决和传递的效率。就这一指标而言，信息化做得十分杰出。 数字化面向的是全社会的所有产业，关注的对象是具体的业务，深刻具体的业务流程；解决的问题是如何精准、实时地响应用户需要。而最终目标是，同时实现最佳的客户体验，和最高的经营效率。 信息化 vs. 数字化 如上图所示，绝对信息化，数字化的要求要高许多——广度更广、深度更深、问题更简单、而指标也更高。这对 IT 技术当然也提出了更高的要求。 从信息化到数字化，DevOps 必须以反对业务麻利为指标数字化改革的后果也必须体现在业务上。数字化要做的是赋能业务，带来用户体验和运作效率的同步晋升。 在规模化生产时代，体验（尤其是个性化的体验）与经营效率原本就是一对矛盾。咱们以就义个性化需要体验为代价，带来规模化和标准化的效率。 数字化将有机会为彻底化解体验和效率的矛盾，精准和实时的响应多样化的用户需要，同时还要进步组织的运作效率，实现最佳体验和最高效率的对立。咱们把这样的能力称为业务麻利。 业务麻利的指标 业务麻利要求组织全方位的转变，比方构建产业的全量、多维度和实时的数据采集和解决体系；建设合乎数字化时代快速反应的组织构造等；实现线上和线下业务的的交融；IT 交付、运行能力的降级等。 ...

简介：随着云原生时代的到来，微服务曾经成为利用架构的支流，Nacos也凭借简略易用、稳固牢靠、性能卓越的外围竞争力成为国内微服务畛域首选的注册核心和配置核心；Nacos2.0更是把性能做到极致，让业务疾速倒退的用户再也不必放心性能问题；同时阿里云MSE也提供Nacos2.0托管服务，一键开明享受阿里十年积淀微服务所有能力！微服务引擎 MSE 专业版公布，反对 Nacos 2.0 ，相比根底版，专业版具备更高的 SLA 保障，性能晋升十倍，99.95%可用性，配置能力进一步加强，新用户首购8折，点击“查看详情”，理解更多相干信息。 作者|风卿 前言MSE从2020年1月公布Nacos1.1.3版本引擎，反对在私有云环境全托管的形式应用Nacos作为注册核心。2020年7月公布Nacos1.2.1版本反对元配置数据管理，反对微服务利用在运行时动静批改配置信息和路由规定等。随着用户的深刻应用，Nacos1.X版本的性能问题也慢慢裸露进去。通过对1.X版本的内核革新，Nacos2.0专业版性能晋升10倍，根本能满足用户对微服务场景的性能要求。 除了性能的晋升，专业版具备更高的SLA保障，并且在配置数据上具备更高的安全性，同时通过MCP协定与Istio生态买通，作为Istio的注册核心。 MSE Nacos1.X根底版架构整体1.X架构能够粗略分为五层，别离是接入层、通信层、性能层、同步层和长久化层。 用户通过接入层拜访Nacos，比方SDK、SCA、Dubbo、Console，Nacos也提供了HTTP协定的open API拜访形式。通信层蕴含HTTP和UDP，Nacos次要通过HTTP进行通信，少部分服务推送性能会用到UDP。性能层目前有Naming和Config两大部分，别离提供服务发现和配置管理能力。同步层蕴含AP模式的Distro协定（服务注册）和CP模式的Raft协定（服务元信息），以及配置告诉的Notify同步形式Nacos的数据长久化有用到Mysql、Derby和本地文件，配置数据、用户信息、权限数据存储在Mysql或者Derby中，长久化的服务数据则寄存在本地文件 MSE Nacos1.X根底版架构问题目前1.X的架构存在几个问题： 每个服务实例都通过心跳续约，在Dubbo场景每个接口对应一个服务，当Dubbo的利用接口数较多时须要心跳续约TPS会很高。心跳续约感知时缩短，须要达到续约超时工夫能力删除实例，个别须要15S，时效性较差通过UDP推送变更数据不牢靠，须要客户端定时进行数据全量对账保证数据的正确性，大量有效查问，整体服务的QPS很高通信形式基于HTTP短链接的形式，Nacos侧开释连贯会进入TIME\_WAIT状态，当QPS较高时会有连贯耗尽导致报错的危险，当然这里通过SDK引入HTTP连接池能缓解，但不能根治配置的长轮询形式会导致相干数据进入JVM Old区申请和开释内存，引起频繁的CMS GC MSE Nacos2.0专业版架构及新模型1.X架构的问题外围点在于连贯模型上，2.0架构降级为长连贯模型，在通信层通过gRPC和RSocket实现长连贯数据传输和推送能力，在连贯层新减少申请处理器、流控和负载平衡等性能 2.0架构解决的问题： 利用POD依照长连贯维度进行心跳续约，不须要依照实例级，大大降低反复申请长连贯断开时能够疾速感知到，不必期待续约超时时长就能够移除实例NIO流式推送机制绝对于UDP更牢靠，并且能够升高利用对账数据频率没有连贯重复创立的开销，大幅升高TIME\_WAIT连贯多问题长连贯也解决了配置模块长轮询CMS GC问题2.0架构带来的问题： 绝对于Tomcat HTTP短连贯模型，长连贯模型须要本人治理连贯状态，减少了复杂性长连贯gRPC基于HTTP2.0 Stream，绝对于HTTP的open API可观测性和易用性升高了 2.0架构整体来说升高了资源开销，进步了零碎吞吐量，在性能上有大幅晋升，但同时也减少了复杂度 MSE Nacos2.0专业版性能Nacos分为服务发现模块和配置管理模块，这里先对服务发现场景进行性能测试。 应用200台施压机，每个施压机模仿500个客户端，每个客户端注册5个服务，订阅5个服务，最高能够提供10W个长连贯、50W个服务实例和订阅者压测场景 服务发现压测次要压变更态和稳固态两种场景： 变更态：施压机施压阶段会大量连贯Nacos注册和订阅服务，这个阶段服务端的压力绝对会比拟大，须要看整体注册和订阅是否最终齐全胜利。稳固态：当施压机申请都胜利之后就会进入稳固状态，客户端和服务端之间只须要维持长连贯心跳即可，这个阶段服务端的压力会比拟小。如果在变更态服务端的压力过大会产生申请超时、连贯断开等问题，不能进入稳固态服务发现也会在MSE上对低版本做降级，比照降级前后的性能变动曲线，这样的性能比照更直观 配置管理模块在理论应用中是写少读多的场景，次要瓶颈点在单台机器性能上，压测场景次要基于单台机器的读性能和连贯撑持数 应用200台施压机，每台施压机能够模仿200个客户端，每个客户端订阅200个配置，发动配置订阅和读配置申请 在服务发现场景比照根底版和专业版在2C4G、4C8G和8C16G规格下的性能数据状况。 这里最大的TPS和实例数都是服务能保障高可用稳固运行的数据，大略会是最大值的一半或者三分之二，也就是说挂一台机器也能够失常运行。 稳固运行时反对规模晋升7倍，实际上最大反对规模晋升7-10倍 还有一个场景是对3节点2C4G MSE Nacos降级前后的比照，次要分为三个阶段： 第一个阶段客户端应用1.X版本，MSE Nacos应用根底版，实例数从0->6000->10000，最初到14000最大值无奈持续增大，Server CPU达到80-90%，客户端一直报错，接着升高实例数到6000第二阶段降级MSE Nacos根底版到专业版，实例数达到14000无奈持续增大，性能压测性能曲线差别不大第三阶段在放弃实例数为14000的状态下，分批降级客户端到2.0版本，CPU指标曲线一直降落至20%左右，并且整体处于稳固态无报错 从降级前后的性能曲线感触MSE Nacos2.0专业版性能有晋升较大。最初整体的压测状况，相较于根底版，专业版服务发现性能晋升10倍，配置管理晋升7倍 MSE Nacos平滑降级专业版对于新用户能够间接创立专业版实例，老用户则能够通过MSE"实例变更"一键降级。MSE会在后盾对POD降级，因为V1V2数据结构不一样，在一开始的时候Nacos数据默认是双写的，在降级过程中数据会从V1同步到V2，降级实现后数据会从V2同步V1，最初MSE会敞开双写逻辑，整体流程都是主动。 SLB的服务端口最初也会减少GRPC 9848端口，此时利用SDK能够从1.X版本升级到2.0版本，整体客户端服务端降级到2.0架构 版本之间的兼容性状况，整体的兼容准则是高版本的服务端兼容低版本客户端，然而高版本客户端不肯定能拜访低版本服务端： 1.X客户端能够拜访根底版，也能够拜访专业版2.0客户端能够拜访专业版，然而不能拜访根底版 Nacos配置平安治理上一期岛风同学解说了配置权限管制，整体MSE Nacos通过阿里云RAM奴才账号体系来做权限管制，这期我次要讲一下Nacos的配置加密性能。 用户在应用配置数据时可能会将用户信息、数据库明码等敏感信息寄存到Nacos中，而Nacos存储配置数据都是明文传输、明文存储的，在数据库内容透露或者传输层抓包时会导致敏感配置数据项透露，整体平安危险十分高。 罕用的HTTPS协定能解决传输平安，但解决不了存储平安，这里间接在客户端进行加密，这样在传输和存储的过程中数据都是加密的。 ...

简介：Nacos 2.0 通过降级通信协议和框架、数据模型的形式将性能晋升了约 10 倍，解决继 Nacos 1.0 公布逐渐裸露的性能问题。本文通过压测 Nacos 1.0，Nacos 1.0 降级 Nacos 2.0 过程中，Nacos 2.0 进行全面性能比照，直观的展现 Nacos 2.0 所带来的性能晋升。作者｜席翁 Nacos 2.0 通过降级通信协议和框架、数据模型的形式将性能晋升了约 10 倍，解决继 Nacos 1.0 公布逐渐裸露的性能问题。本文通过压测 Nacos 1.0，Nacos 1.0 降级 Nacos 2.0 过程中，Nacos 2.0 进行全面性能比照，直观的展现 Nacos 2.0 所带来的性能晋升。 压测筹备 环境筹备 为了不便 Nacos 部署降级和展现外围性能指标，咱们是从阿里云微服务引擎 MSE（\_https://cn.aliyun.com/product/aliware/mse\_）中购买的一个 2 核 CPU+4G 内存的三节点 Nacos 集群。 压测模型 为了展现不同规模下的零碎体现，咱们采纳逐渐增压的形式进行压测，将压力分为 3个批次进行逐渐启动，并察看每个批次下集群的运行体现。同时会在压力集群之外，再减少一个 Dubbo 服务的 Demo ，并应用 Jmeter 以 100 TPS 的压力不停的调用，以模仿不同压力下，对理论业务调用存在的可能影响。 压测过程中，会在适当的时候对服务端和客户端进行降级；服务端的降级将间接应用 MSE 提供的一键降级性能，客户端的降级会应用分批次轮流重启的形式进行。 ...

简介：整顿自 5 月 29 日 阿里云开发者大会，秦江杰和刘童璇的分享，内容包含实时举荐零碎的原理以及什么是实时举荐零碎、整体零碎的架构及如何在阿里云下面实现，以及对于深度学习的细节介绍 本文整顿自 5 月 29 日阿里云开发者大会，大数据与 AI 一体化平台分论坛，秦江杰和刘童璇带来的《基于实时深度学习的举荐零碎架构设计和技术演进》。分享内容如下： 实时举荐零碎的原理以及什么是实时举荐零碎整体零碎的架构及如何在阿里云下面实现对于深度学习的细节介绍。GitHub 地址 https://github.com/apache/flink 欢送大家给 Flink 点赞送 star~ 一、实时举荐零碎的原理在介绍实时举荐零碎的原理之前，先来看一个传统、经典的动态举荐零碎。 用户的行为日志会呈现在音讯队列里，而后被ETL到特色生成和模型训练中。这部分的数据是离线的，离线的模型更新和特色更新会被推到在线零碎外面，比方特色库和在线推理的服务中，而后去服务在线的搜寻推广应用。这个举荐零碎自身是一个服务，前端展现的服务推广应用可能有搜寻举荐、广告举荐等。那么这个动态零碎到底是怎么工作的？咱们来看上面的例子。 1. 动态举荐零碎 截取当初用户的行为日志，倒入离线零碎中去做特色生成和模型训练，这段日志示意用户 1 和用户 2 同时浏览了 page#200 这个页面和其余一些页面，其中用户 1 浏览了 page#100 并且点击了 ads#2002。那么这个日志会被 ETL 到离线，而后送去做特色生成和模型训练。生成的特色和模型外面会看到，用户 1 和用户 2 都是中国男性用户，“中国男性”是这两个用户的一个特色，这个学习模型最终后果是：中国男性用户浏览了 page#100 的时候，须要给他推 ads#2002。这外面的逻辑就是把类似用户的行为归到一起，阐明这类用户应该有同样的行为。 用户特色推动特色库建设的模型，在推送至在线服务里的时候如果有一个用户 4 呈现，在线推理的服务就会到特色库外面去查这个用户的特色，查到的特色可能是这个用户正好是中国的男性用户，模型之前学到了中国男性用户拜访 page#100 时候要推 ads#2002，所以会依据学习模型给用户 4 举荐了 ads#2002。以上就是动态举荐零碎的根本工作流程。 然而这个零碎也有一些问题，比方第一天的模型训练实现后，发现用户 4 第二天的行为其实跟用户 3 更像，不是和用户 1、用户 2 相似 。然而之前模型训练的后果是中国男性用户拜访 page#100 时候要推 ads#2002，并且会默认进行这种举荐。只有通过第二次模型计算后能力发现用户 4 和用户 3 比拟像，这时再进行新的举荐，是有提早的。这是因为模型和特色都是动态的。 ...

简介：作为软硬一体的公共云本地化部署服务，阿里云云盒应用与公共云统一的架构，为用户提供了与公共云统一的产品、统一的体验，同时满足客户数据本地部署、海量数据就近解决、业务低延时等需要。阿里云云盒更多内容：https://yqh.aliyun.com/live/cloudbox 6月30日，阿里云发表本地化部署服务阿里云云盒Cloud Box正式上线。从即日起，用户通过阿里云官网下单即可购买。 各行业上云已成趋势，随着大数据、人工智能、物联网、5G 等技术的疾速倒退，大部分公司将数字化转型列为企业的优先策略，上云是其中的重要局部。但因为受限于合规、带宽、延时和老本等要求，一些企业须要将局部业务部署在本地机房，但同时又心愿在本地机房取得公共云统一的应用体验。云盒就是为解决这一难题而生。 云盒是阿里云公共云的延长，部署在用户的数据中心，让用户在本人的机房即可享受到专属的公共云服务。 云盒：公共云的延长，统一的体验作为软硬一体的公共云本地化部署服务，阿里云云盒应用与公共云统一的架构，为用户提供了与公共云统一的产品、统一的体验，同时满足客户数据本地部署、海量数据就近解决、业务低延时等需要。 技术架构上，云盒基于阿里云自研的神龙架构，不仅能够帮忙用户在本地机房取得弹性伸缩的能力，还可取得弱小的计算能力、高I/O性能和稳定性；阿里公共云上有数百万台服务器，和数十年的数据积攒，在达摩院算法加持下，可对云盒内的服务器进行故障预测，甚至提前隔离，准确率达70%以上。 同时，通过阿里云自研的网络设备将云盒和本地IT设施对接，可满足超低延时的网络需要。 应用体验上，用户能够通过公共云的控制台来治理云盒内计算、网络、存储的全生命周期；共用一套账号体系，通过跨账号形式实现云上云下资源共享，客户的应用非常便捷。 目前，云盒次要提供计算、存储、网络三大根底产品；其余PaaS、SaaS类产品也能够在公共云管制台上依据须要部署到云盒。 专有网络VPC互联，兼具合规与便捷在安全性方面，云盒人造继承了公共云的平安组、密钥对、根底防护等安全措施。其次，通过公共云控制台对云盒内的所有操作均可查可审计。 合规是局部企业将业务部署在自有机房的重要起因之一，用户能够应用阿里云云盒将数据存储在本地机房，实现企业级的网络隔离，间接内网拜访利用，很好地满足了非凡行业客户的监管需要。 在此之外，云盒又极为灵便。通过专有网络（VPC），云盒与公共云互联互通，做到云上云下业务无缝迁徙；同时，云盒内的实例，通过交换机和用户本地的IDC无缝互联，实践最大物理带宽可达160G。 云盒目前提供三年全预付和半预付的形式，帮忙客户防止自建IDC机房的一次性投入。客户在公共云控制台下单购买云盒后，阿里云依据对应的资源量，在工厂内进行软硬件的预装置后，将以整机柜的形式送达客户指定的数据中心。 阿里云工程师在现场进行简略装置调试后，用户即可在公共云管制台上查看与治理云盒内的云资源。 为数据本地解决、低延时等场景设计各行业上云已成趋势，公共云有着弹性、便捷的特点，能够帮忙客户最疾速地享受到最新科技。然而，无论是国内或国外，都存在着大量企业的某些工作负载可能须要在外部数据中心部署，因而，阿里云推出了云盒这款产品，兼具两者的劣势。据阿里云弹性计算产品专家介绍，云盒次要有四类利用场景： 1、数据须要本地解决：因带宽、老本、数据量、工夫等因素无奈将数据传输到公共云解决，如本地AI模型训练、视频产业园区等。 2、低延时：本地设施须要与控制系统疾速实时交互，如工业制作、仓库治理等。 3、合规要求：局部非凡行业，须要将数据部署在园区或本地机房，如：行业协会、交通航空、医院等。 4、多分支机构：IT基础设施散布在不同地区或不太不便运维的地区而须要对立治理运维升高运维老本的诉求，如智能小区、工厂、高速路监控等。 事实上，企业对于计算的要求曾经从“场景的全笼罩”扩大到了“地点的无处不在”，阿里云布局了“云、边、端”全场景笼罩的能力，推出了云盒和本地Region等一系列新的部署和经营状态。将来，阿里云会将公共云延长到更加广大的空间，与客户一起为行将到来的边缘计算、5G 时代做好筹备。 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

简介：“收钱吧到账100万”成为一般商家最想听到的声音。 你有多久没摸过现金了？ 中国互联网络信息中心公布的第47次《中国互联网络倒退情况统计报告》数据显示，截至2020年12月，我国挪动领取用户规模达到8.54亿；中国人民银行公布的数据显示，截止到2020年年底，我国挪动领取业务1232.20亿笔，金额432.16万亿元。 这些数据与咱们每个人都非亲非故，下班路上的早餐、小区里的停车费、假日的一场电影、深夜小吃摊上的一份夜宵……挪动领取早已成为社会的重要基础设施，组成了大街小巷的人间烟火气，你也肯定听过机器收回的“收钱吧到账X元”的声音。 收钱吧成立于2013年，是聚合领取行业的开创者，目前已渗入百万线下商家，为数亿民众赋能。 随着挪动领取的逐渐成熟，收钱吧积淀了大量的门店交易数据。收钱吧将这些数据高效利用，面向商家推出挪动领取收款、营销管理软件、广告、供应链、共享充电宝、商家社区等服务。现在，收钱吧曾经从晚期的聚合领取服务商，倒退成为数字化门店综合服务商，让百万级的中小型商家实现了最根底的数字化转型。 面对千亿级别的数据量，以及每天超过3200万笔交易的数据增量，收钱吧如何实现海量存储和账单查问？让咱们一起走进收钱吧，去摸索背地的故事吧。 以下为「超级探访」第四期——《阿里云数据库助力收钱吧，如何帮数亿用户管好账本？》的节选对白。 1.帮数亿用户管好账本张一甲：收钱吧目前服务多少商户、用户的规模有多少？ 收钱吧CTO/高级副总裁常建龙：收钱吧服务网络曾经笼罩中国境内660个城市，服务400万线下实体商家，日均服务3200万人次，累计服务200亿人次，从集体消费者到夫妻店到国内连锁品牌，都能看到收钱吧的身影。 张一甲：如何存储和治理因而产生的海量账单呢？ *毛宇-收钱吧开发总监：*这要抓住两个要害。首先须要一个集中存储和治理领取账单的数据中心。 其次，收钱吧笼罩了不同的客户类型，咱们须要想方法满足不同用户的差异化需要。 因而，收钱吧自主研发了分级账户零碎，可具体统计各品牌、各分店、各收银员收款数据，清晰记录每一笔账目，并可依据财务要求定制对账单，解决客户关怀的痛点问题。 张一甲：领取是一个很敏感的业务，商家和消费者都十分关怀本人账本。收钱吧如何保障用户的财产平安，解决用户的后顾之忧？ *毛宇-收钱吧开发总监：*针对财产平安，收钱吧强调的是治理和掌控，老板不必到店也能把握详情——近程管账、管店、管人。收钱吧APP提供日账单、月账单和所有收款记录，不便对账。APP随时随地查看所有交易信息，收银员、老板都不便。 张一甲：在研发这个零碎时遇到的最大挑战是什么？ *毛宇-收钱吧开发总监：*次要挑战有三个，第一是存储可靠性，第二是存储老本，第三是海量数据下的多维组合实时查问。 存储可靠性毫无疑问十分重要。试想如果账单失落，客户的帐单、银行的帐单、商家的帐单等齐全无奈核查和查问，这是不可承受的。 对于存储老本，咱们目前曾经存储了千亿级别的数据，每日新增3200万数据，这个数据增量十分大，对存储老本的挑战也十分大。 此外，不同的客户有不同维度的数据查问需要。B端的查问量绝对较小，但查问维度简单；C端用户的查问量比拟大，但业务逻辑绝对简略。 对于连锁商家，须要反对品牌、门店、收银员、工夫等多个维度的随机组合查问；对于消费者，须要反对基于工夫范畴的账单查问。通过总结，收钱吧须要反对30+维度的随机组合查问，能力满足目前多品种用户的查问需要。 张一甲：收钱吧怎么解决这些问题？ *毛宇-收钱吧开发总监：通过大量的调研、剖析和测试验证，比照了不同的技术和产品，咱们最终抉择应用阿里云的云原生多模数据库Lindorm*作为存储核心来构建整套账单零碎，零碎目前曾经上线运行1年多。 抉择Lindorm次要有三点考量：Lindorm基于多正本技术，提供99.99999999%的数据可靠性，一共10个9； Lindorm具备最大10：1的压缩比，再联合冷热拆散能力，将6个月前的历史账单转化为冷数据进行存储，综合存储老本降落2/3； Lindorm提供了一体化的账单检索计划，能主动针对账单数据创立适合的索引，反对30多个维度随机组合的实时查问。 张一甲：6个月前的历史账单被高度压缩了，还能够被检索到？ *毛宇-收钱吧开发总监：*是的。有了阿里云Lindorm的保障，海量存储与实时查问，不再是矛盾。 2.海量数据辅助停工决策张一甲：2020年因为疫情，线下门店都或多或少遇到了经营的艰难，收钱吧作为服务线下商家的企业，给商家提供了哪些帮忙呢？ 毛宇-收钱吧开发总监：收钱吧致力于用网络和数据力量帮忙线下商家经营生意，基于领取后产生的原生流量，推出了《全国线下商业生产指数的追踪数据》，能实时反馈线下商业生产的活跃度。 这个数据一方面提供给政府，辅助政府制订反对中小微企业停工复产的政策；另一方面凋谢给咱们的宽广商家用户，帮忙商家无效地制订正当的停工打算。 张一甲：这个指数是怎么计算出来的，如何保证数据的准确性和实时性？ 毛宇-收钱吧开发总监：收钱吧的业务笼罩线下生产的各行各业，咱们基于存储在Lindorm中的海量生产数据，依据肯定的经济计量模型，实时计算失去商业生产指数。 张一甲：Lindorm仍然在这个零碎里施展了重要作用？ 毛宇-收钱吧开发总监：是的，整个零碎的存储和计算都是围绕Lindorm来构建的。咱们的所有数据都存储在Lindorm上，基于它提供的存储计算一体化计划，能轻松对接计算生态，帮忙咱们疾速构建出一套数据处理架构，反对应用服务上线。 Lindorm同时提供了kv构造的宽表存储，兼容HDFS文件存储，SQL查问和数据检索性能，咱们的源数据、维表都存储在Lindorm上，计算失去的后果表也写回到Lindorm中提供给下层业务查问应用。无效防止数据迁徙，简化零碎架构。 基于Lindorm构建的这套计划，开发上线工夫比预计缩短了一半。 3.数字时代想致富，做好数据库张一甲：2020年阿里云公布了Lindorm，它有什么特点？ 阿里云智能资深技术专家/Lindorm研发负责人沈春辉：Lindorm是阿里云公布的第一款自主研发的NoSQL产品，基于存储计算拆散、多模共享交融的云原生架构，反对海量数据的低成本存储解决，反对丰盛的数据检索能力，反对一键对接计算生态，进行交互式、批处理、流解决等计算解决，帮忙用户疾速构建出一套数据处理架构，在互联网、物联网场景中处于刚需。 同时，Lindorm尽管是自主研发，但十分动摇地拥抱开源生态，数据拜访接口反对SQL、HDFS、HBase、CQL、OpenTSDB等开源规范，简略易用，无需额定的学习老本。 张一甲：阿里自主研发的数据库是出于本身电商业务的需要，从自有业务到to B服务，阿里云如何放弃对需要的敏锐洞察？ 阿里云智能资深技术专家/Lindorm研发负责人沈春辉：从用户中来，到用户中去，这是产品继续迭代的不变逻辑。在to B服务过程中，除了稳定性、老本诉求之外，咱们比拟难听到客户间接通知你要什么，这是一个很大的挑战。而数据库间接连贯业务，其需要是大量存在的。 为此，咱们次要借助两个形式：一个是实地走访。数据库部门有一支专家服务团队，会定期访问客户进行业务技术交换，及时理解产品的应用状况和诉求，探讨近程沟通与协同的效率优化计划； 另一个是趋势预判，包含行业趋势、技术趋势。比方Lindorm在物联网方向预投了很多技术研发，指标是数量级地晋升终端设备的时序数据、地位数据的解决效率，存在肯定的提前预测性，同时会随同行业倒退与利用反馈做适时调整。 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

简介：揭秘Hologres优化COPY的技术原理，实现批量导入性能晋升5倍+Hologres（中文名交互式剖析）是阿里云自研的一站式实时数仓，这个云原生零碎交融了实时服务和剖析大数据的场景，全面兼容PostgreSQL协定并与大数据生态无缝买通，能用同一套数据架构同时反对实时写入实时查问以及实时离线联邦剖析。它的呈现简化了业务的架构，为业务提供实时决策的能力，让大数据施展出更大的商业价值。从阿里团体诞生到云上商业化，随着业务的倒退和技术的演进，Hologres也在继续一直优化核心技术竞争力，为了让大家更加理解Hologres，咱们打算继续推出Hologres底层技术原理揭秘系列，从高性能存储引擎到高效率查问引擎，高吞吐写入到高QPS查问等，全方位解读Hologres，请大家继续关注！ 往期精彩内容： 2020年VLDB的论文《Alibaba Hologres: A cloud-Native Service for Hybrid Serving/Analytical Processing》Hologres揭秘：首次公开！阿里巴巴云原生实时数仓核心技术揭秘Hologres揭秘：首次揭秘云原生Hologres存储引擎Hologres揭秘：Hologres高效率分布式查问引擎Hologres揭秘：高性能原生减速MaxCompute外围原理[ ](https://topic.atatech.org/art... 本期咱们将带来Hologers COPY导入性能优化实现性能晋升5+倍方面的技术原理解读。背景在PostgreSQL中，COPY命令用于文本文件数据导入，其在PG生态外面有着重要的作用： 完满兼容PG几十种数据类型，包含自定义类型等等。文本解析导入细节思考的十分欠缺，也是业界标杆。业务价值，业务集成的成本低，psql一条命令或者copy manager等等无需第三方的集成依赖。日常开发测试中高频应用，比方tpch测试，性能验证，线上问题复现等。Hologres齐全兼容PG(PostgreSQL)生态，反对应用COPY命令导入数据，然而在PostgreSQL中，COPY的导入性能差强人意，只有20MB/s。而大数据处理场景，往往须要高性能的写入，PG的COPY写入性能不能满足理论业务。 基于此，Hologres对COPY写入性能进行了优化，以达到高性能、高可用的目标。本文将会介绍Hologres对COPY命令优化的技术原理，从而实现导入性能5倍+。 COPY瓶颈定位在晚期版本中，COPY导入在Hologres的实现流程图如下：执行流程： 1.FE（FrontEnd，前端节点）负责接管用户的申请，数据流入，以及具体的解析工作(包含分行，拆列，类型Format解析等)。 2.FE把实现解析的数据转成Arrow写入到Shuffle Service。 3.HQE（Hologres Query Engine）从Shuffle Service获取数据，并依据散布键实现Shuffle。 4.SE（Storage Engine）把数据流写入Pangu。 在COPY工作的过程中，可能看到FE的过程始终处于CPU打满的状态，下图是性能调试时的记录： 能够确定以下瓶颈： Shuffle Service两头节点引入的性能损耗。如上图的红框局部，须要将PG的外部数据结构HeapTuple转换成Arrow并写入Shuffle Service。PG解析自身的耗时，比方，I/O，对数据流切分，依照类型Format解析等等。革新技术难点定位了瓶颈之后，联合Hologres现有技术架构，要晋升性能，次要有以下几个难点： PostgreSQL的过程模型，有很多Global Runtime Context，多线程革新老本高。类型解析依赖PostgreSQL类型零碎，所以无奈简略的利用第三方文本解析库减速，比方Arrow。FE Meta治理过程中，须要PostgreSQL零碎表和COPY的交互，从而保障PostgreSQL COPY零碎表的行为稳固及正确性。Hologres优化计划为了冲破下面的难点，从而解决导入效率的问题，Hologres针对FE做了优化，次要是解耦FE工作流程： 保障Request过程只负责，接管申请，数据流入以及简略的数据切分；文本解析的工作交给具备PG计算能力反对的PQE分布式执行，优化后的执行计划如图：优化后，数据通过COPY导入Hologres的执行流程如下：FE负责接管用户申请，并把流入的数据按行切片，并写入共享队列Queue。Coordinator把FE和PQE调度到同一台机器，这样Queue能以Shared Memory的形式实现，FE和PQE交互更高效。PQE从Queue外面获取对应的切片，并实现拆行，分列，以及具体类型解析。HQE从PQE拖取数据，并计算散布并Shuffle。SE负责把流入数据写入到Pangu。5倍+性能晋升通过对系统的优化，Hologres的COPY导入性能有了质的飞跃。以TPCH lineitem表为例，1亿条数据，文件13G，COPY导入性能如下： **能够从图中看到，优化后，Hologres COPY上传速度能达200MB/s+，相比PostgreSQL快5倍以上！ ** 总结Hologres致力于一站式实时数仓，在数据接入上有着十分宏大的生态家族，反对多种异构数据源的离线、实时写入，包含DataWorks数据集成、Flink、MaxCompute等丰盛的写入形式。在大数据场景中，Hologres齐全兼容PostgreSQL的COPY命令，并在此基础之上，对系统优化，实现了COPY导入性能比PG快5倍+。COPY命令形式导入数据，为Hologres数据接入生态又新增一种形式，满足业务高性能写入需要，助力疾速搭建企业级实时数仓。 作者：郑晓文（鲁来） 现从事交互式剖析Hologres引擎研发工作。 后续咱们将会陆续推出无关Hologres的技术底层原理揭秘系列，具体布局如下，敬请继续关注！ Hologres揭秘：首次公开！阿里巴巴云原生实时数仓核心技术揭秘Hologres揭秘：首次揭秘云原生Hologres存储引擎Hologres揭秘：深度解析高效率分布式查问引擎Hologres揭秘：高性能原生减速MaxCompute外围原理Hologres揭秘：如何利用COPY实现高效率导入（本文）Hologres揭秘：__如何反对高吞吐UpsertHologres揭秘：__如何反对在线服务场景的超高QPSHologres揭秘：__如何反对高并发查问Hologres揭秘：__如何反对高可用架构Hologres揭秘：__如何反对资源隔离，反对多种负载Hologres揭秘：__向量检索引擎Proxima原理与应用实际Hologres揭秘：__读懂执行打算，查问性能翻十倍Hologres揭秘：__分布式系统如何设计Shard与Table GroupHologres揭秘：__如何反对更多Postgres生态扩大包Hologres揭秘：高吞吐写入Hologres的N种姿态......感谢您的浏览，也欢送应用体验Hologres，能够参考使用手册。 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

简介：2025年私有云或将服务中国过半数字经济 阿里云研究院 高级策略总监 麻芃 2020年，疫情“黑天鹅”对寰球经济社会运行造成激烈冲击，但数字经济的引擎作用却逆势凸显。去年我国数字经济整体规模达到39.2万亿元，实现9.7%的高速增长，是同期GDP增速的3.2倍，数字经济占GDP比重同比晋升2.4个百分点，达到38.6%。 作为数字技术的重要组成部分，云计算曾经成为数字经济倒退的要害撑持。2019年，寰球35个次要经济体的私有云市场规模与其数字经济体量呈显著的线性关系（见图1）。然而，我国作为第二大经济体奉献了寰球GDP的16.3%（世界银行，2019年数据），但私有云市场规模仅占寰球的5.1%（IDC，2019年数据），与经济体量极不匹配，这可能成为制约我国数字经济倒退的突出问题。基于此，本文比照中国和美国的云计算市场倒退现状，剖析中美云计算市场差别产生的深层次起因，并对中国云计算市场的发展前景进行探讨。 图1 2019年寰球35个次要经济体的私有云市场规模与数字经济体量 注：私有云市场规模数据来自IDC，数字经济体量数据来自中国信息通信研究院，数据均通过对数化计算解决 01 市场规模、私有云占比、SaaS占比（一）中国私有云市场规模仅为美国的10.8%IDC数据显示，2020年，中国私有云市场规模为193.8亿美元，仅相当于同年美国私有云市场规模的10.8%（见图2）。但过来5年，中国私有云市场规模年复合增长率高达61.1%，显著高于美国的23.8%。 图2 2016—2020年中美私有云市场规模及增长率比照 数据起源：IDC （二）中国私有云公有云平分秋色，美国私有云是相对支流信息通信研究院数据显示，2019年中国云计算整体市场规模为1334.5亿元，其中私有云市场规模首次超过公有云，两者之比为1.07：1。因为公有云的市场边界绝对不清晰，少数市场钻研机构没有披露美国公有云市场规模数据。在此，应用公有云部署开销与私有云部署开销的比值，来反映二者市场规模的绝对大小，美国2019年该比值为28.7%（作为比照，中国为70.3%），即美国公有云市场规模显著小于私有云，私有云是美国用户上云的首选项。 （三）中国私有云IaaS占比超六成，美国私有云SaaS占比近七成2020年，中国私有云中IaaS、PaaS、SaaS的市场规模占比别离为61.6%、12.9%和25.5%， IaaS占比最高且近5年来比重仍继续晋升，从2016年的49.6%回升至2020年的61.6%（见图3）；而同年美国私有云中IaaS、PaaS、SaaS的市场规模占比别离为16.6%、16.4%、67.1%， SaaS占比最高但近5年比重继续升高，已从2016年的79.3%降落至2020年的67.1%。 图3 2016—2020年中美私有云市场IaaS、PaaS、SaaS占比变动 数据起源：IDC 02 影响中国云市场的因素（一）中国企业生命周期较短，对数字技术的投入优先级低据美国《财产》杂志报道，美国中小企业平均寿命不到7年，大企业平均寿命有余40年；而中国中小企业的平均寿命仅2.5年，团体企业的平均寿命仅7-8年。美国每年开张的企业约10万家，而中国每年有100万家企业倒闭。中国企业特地是中小企业的生存压力远高于美国企业，这使得中国企业在进行投资决策时，更偏向于把资金投向回报成果间接且显著的中央，如营销渠道的拓展等。对于数字化这种周期绝对较长且回报并不直观的收入，通常并不是中国企业的优先选择，甚至不是必选项。 （二）中国劳动力老本仍较低，企业偏向应用人力而非技术手段解决问题根据美国劳工统计局的公开信息，2018年美国居民人均收入为3.6万美元，其中 “非农就业人口”年收入约5万美元。作为比照，只管中国近年来人均可摆布支出一直晋升，但2018年居民人均可摆布支出仅为28228元（约合4266美元），城镇居民人均可摆布支出仅为39251元（约合5931美元），中国的劳动力老本只是美国的12%左右。然而，中美两国的数字化产品和服务的费用却相差无几。在此背景下，中国企业在面对业务需要时，更偏向于应用劳动力而非信息技术的形式去应答解决——与信息业务零碎相比，应用人力的形式只管效率低下，但短期老本低廉且资源易于复用。 （三）服务业的数字化程度高于其余产业，美国的服务业占比高于中国无论是中国还是寰球，数字化的倒退都是衰亡并昌盛于个人用户；相应地，在商业机构中，离个人用户越近的行业和业务，其数字化的程度也越高，即在国民经济中，第三产业的数字化程度和对云的使用量通常高于第二产业和第一产业。中国信息通信研究院的钻研也证实了这一点：2019年，寰球农业、工业和服务业的数字经济渗透率别离为7.5%、23.5%和39.4%。而中美两国目前的产业结构差别显著：2020年，美国第一、二、三产业增加值占GDP的比重顺次为0.8%、17.7%和81.5%，同年中国的占比程度则顺次为7.7%、37.8%和54.5%（见图4），数字化程度最高、云使用量最多的服务业在美国的产业结构占比显著高于中国。 图4 2020年中美两国国民经济三次产业结构比照 数据起源：中国国家统计局、美国商务部经济剖析局 （四）中国信息基础设施单薄，云化和信息化同步倒退信息化是数字化的根底和前置倒退阶段，美国通过在上世纪八九十年代对信息技术的大规模投入，奠定了松软的信息化根底：数据显示，1993年美国的大公司均已实现办公自动化；90年代前期，世界500强企业中近80%已应用ERP（Enterprise Resource Planning，企业资源管理）软件。在云时代降临前，美国曾经实现信息技术基础设施的建设遍及。而中国在2014年云计算开始衰亡时，整个社会的信息技术基础设施仍在大兴建设中尚未欠缺，这使得近年来中国信息技术基础设施投资和云计算根本同步倒退，IaaS在中国云计算市场中长期占据主导地位。 （五）市场供应能力差距显著，中国产业生态尚在襁褓期产业链不欠缺、供应能力有余，是导致中国云计算市场规模小、SaaS占比低的另一个重要起因。中国云计算产业中的服务器CPU、内存等外围硬件和数据库、中间件等根底软件对国外产品依赖度高，如英特尔占我国服务器CPU芯片市场97%以上的份额。共性根底产品的供应尚能够通过全球化供给解决，而业务利用市场的供应仍在艰巨摸索中：中国的产业门类齐全、个性化需要多，国外SaaS产品只能满足多数需要，而外乡SaaS厂商大多没有亲身经历过信息化时代，不足软件标准化教训，整体SaaS市场目前仍处于指标用户抉择、产品打磨甚至商业模式验证的初期倒退阶段，SaaS供应无论是质还是量均无奈满足市场需求。 03云计算重塑数字产业生态，私有云服务过半数字经济（一）云计算市场规模将持续增长，带动中国信息技术市场收入显著进步1. 数字经济的产业渗透率晋升将拉动云计算市场空间信息通信研究院的钻研结果表明，2019年中国一产、二产、三产的数字经济渗透率别离为8.2%、19.5%和37.8%，除一产的数字经济渗透率略高于寰球平均水平（7.5%）外，二产、三产均低于寰球平均水平（23.5%、39.4%），三次产业的数字经济渗透率更是全副显著低于以美国为代表的发达国家程度（一产13.3%、二产33.0%、三产46.7%），如图5所示。将来几年，在“继续强化农业根底位置”和“放弃制造业比重根本稳固”等国家“十四五”布局的领导下，预计中国三次产业结构比例将根本稳固，服务业占比会略有进步。在此基础上，三次产业的数字化程度将全面晋升，作为数字经济基础设施的云计算得以广泛应用。 图5 2019年中国、寰球和发达国家的三次产业数字经济渗透率比照 数据起源：中国信息通信研究院 2. 新基建为云计算倒退带来空前时机以后，国家放慢部署“新基建”，助力产业降级、培养经济倒退新动能。云计算是新基建的重要组成部分，同时也通过资源管理整合、技术环境部署、网络连接优化、算力弹性调度等方面的劣势能力，成为新基建价值实现和效用晋升的要害撑持。“十四五”是新基建的集中建设装置期，据中国电子信息产业倒退研究院预计，到2025年新基建间接投资将达10万亿元左右，带动投资累计或超17万亿元。在新基建国家策略的引领下，整个社会在将来一段时间内将加大在云计算畛域的投资规模。 3. 快速增长的数据量将撑持云计算的利用空间依据IDC钻研，中国在2020年产生的数据量达13.1ZB，占当年寰球数据总量的21.4%；将来5年，中国数据量将继续快速增长，年复合增长率高达24.4%，超过寰球年复合增长率22.9%，是寰球数据量增长最快的区域之一（见图6）。数据须要通过信息技术基础架构的计算、存储等解决能力施展价值成为生产因素，而云计算已是信息技术基础架构的支流模式——2019年中国云基础架构投资首次超过传统信息技术基础架构投资。快速增长的数据量将撑持中国云计算市场的倒退。 图6 2020—2025年中国数据量及增速预测 数据起源：IDC 将来几年，中国的云计算市场将疾速倒退，进而带动中国的信息技术市场规模持续增长。据中国信息通信研究院预测，到2023年，中国的云计算市场规模将达到3754.2亿元，相比2019年增长1.8倍，2019—2023年复合增长率将高达29.5%。在云计算倒退的带动下，中国信息技术市场规模将持续增长，预计2024年将达到5477.8亿美元，相比2020年扩充23.6%，如图7所示。 图7 2019—2024年中国信息技术市场规模与增长率预测 数据起源：IDC （二）2025年私有云或将服务中国过半数字经济，成为要害基础设施1. 企业数字化意识加强，私有云成为数字化最佳入口在从天而降的新冠疫情中，数字经济所展现出的弱小生命力重塑了人们对数字化的认知，即数字化不再只是企业寻求更好倒退的可选项，而已成为企业面对不确定性的必备生存能力。在企业特地是中小企业构建数字化能力时，私有云具备无可比拟的劣势：其按需付费的模式将传统信息技术我的项目的Capex（Capital Expenditure，资本性支出）转变为Opex（Operating Expense，经营收入），无效升高企业资金压力；而相较于公有云，私有云老本更低、无需保护、扩展性好，是企业低成本疾速取得数字化能力的最佳抉择。 2.劳动力老本一直晋升，私有云劣势逐步浮现只管相较于美国，中国的劳动力老本依然足够低廉，但近年来已继续攀升，特地是2012年以来中国劳动年龄人口连年降落，能够预感，中国的劳动力老本将来将持续回升。与此同时，数字化的产品和解决方案在摩尔定律和边际效应的双重作用下，性能一直晋升而价格一路走低。此消彼长之下，企业将从新扫视劳动力和数字技术两种形式，日渐偏向于通过数字技术手段解决问题，特地是老本劣势显著、利用生态丰盛的私有云。 3.大型政企愈发器重个人用户服务，相干业务偏向私有云部署中国的政府和大型企业进行数字化转型时，通常构建对立的公有云平台，借助该平台买通业务零碎进步流程效率。时至今日，公有云的次要行业用户包含政府、金融等，都愈发强调对公众的服务能力，如政府心愿通过“互联网+政务服务”推动治理现代化和职能转变。而私有云对个人用户的笼罩程度和服务能力是公有云无奈代替的，将来大型政企会把越来越多的个人用户业务部署在私有云上。 在上述等多重因素的独特作用下，中国的私有云市场将实现高速增长。IDC预计2024年中国私有云市场将达到659.5亿美元，是2020年市场规模的3.5倍（见图8）。数字经济的存在和倒退依赖于算力和数据，而信息技术基础设施硬件是承载算力和数据的物理单元。近年来，中国私有云IaaS在信息技术基础设施硬件开销中的占比逐年晋升，2020年已达25.7%，IDC预计2024年私有云IaaS占信息技术基础设施硬件的比重将达到45.3%，如图9所示。思考到私有云IaaS市场规模增速远高于信息技术基础设施硬件市场规模增速，加之私有云服务中有近四成是以PaaS或SaaS模式提供，其相应的硬件资源并不齐全由IaaS承载，由此可见，私有云或将于2025年服务中国过半数字经济体量，成为至关重要的数字经济基础设施。 图8 2020—2024年中国私有云市场规模与增速 数据起源：IDC 图9 2019—2024年私有云IaaS占信息技术基础设施硬件比例变动预测 数据起源：IDC （三）云计算将引领新一轮技术创新，重塑数字产业生态1. 云计算成为我国构筑信息技术产业倒退新劣势的突破口云计算作为新型基础设施的外围环节，是大数据、人工智能等新一代数字技术的要害底座。在以云为外围的新技术体系下，中国通过把握技术更新带来的历史时机，迅速放大了与发达国家信息技术产业的差距——在IDC颁布的2020年寰球私有云IaaS市场服务商前7名中，有3家来自中国。这使得中国无望从原来欧美长期主导的以大型机为外围的旧有技术体系中解围，以云计算为突破口抢占下一个科技制高点。 2. 借助云对产业链上下游产品的弱小定义能力，我国数字产业无望做大做强云计算能够向下定义芯片、存储和网络等外围硬件的演进，向上从新布局操作系统、数据库、中间件、大数据平台等根底软件的倒退门路。外围硬件方面，我国云计算产业已成规模，能为服务器CPU等芯片提供倒退空间：利用分布式部署容错性强的特点，单个芯片故障不会影响整体性能，云计算人造成为芯片产业的最佳试验场和孵化器，在此推动下，以“含光800”为代表的芯片已实现规模化利用。与此同时，简直所有软件特地是根底软件都须要进行云上重塑，这为我国软件行业提供了“换道超车”的契机：以数据库为例，过来中国市场长期被国外巨头垄断，进入云时代后，我国数据库产品“PolarDB”已位列寰球云数据库市场份额第三，跻身寰球一流行列。 3. 云的定位从信息根底资源向数字化操作系统扩大，SaaS成为厂商发力重点长期以来，云计算被视为一种普惠、灵便的根底资源，而随着整个社会数字化转型的继续推动，仅是根底资源的云化已不能满足企业需要，企业更加冀望业务利用零碎的全面云化。 云计算被视为可提供“数字化底座+数字化操作系统”的社会翻新平台。其中，底座解决的是算力撑持问题，操作系统则为企业提供富集的应用服务，帮忙企业实现业务降级、经营提效、体验优化和组织降级。相应的，云计算的重心随之上移，SaaS成为厂商发力重点：传统软件厂商如用友、金蝶等均以云为外围策略继续推动转型；SaaS守业公司数量快速增长；互联网厂商则以钉钉等协同办公产品为平台，通过构建生态为用户提供行业解决方案。将来几年，中国SaaS市场生态将日渐成型，服务能力疾速晋升。 ...

简介：6月25日，记者采访获悉，经中国信息通信研究院（以下简称“信通院”）的严格测试评定，阿里云数据库利用迁徙服务顺利通过了“数据库利用迁徙服务能力”评测，总得分在所有参评厂商中排名第一，问题定级为最高级别的先进级（3级）。 6月25日，记者采访获悉，经中国信息通信研究院（以下简称“信通院”）的严格测试评定，阿里云数据库利用迁徙服务顺利通过了“数据库利用迁徙服务能力”评测，总得分在所有参评厂商中排名第一，问题定级为最高级别的先进级（3级）。 随着数据库技术与高速网络通信、云计算等信息技术一直深入交融，数据库及利用零碎的存在模式愈发丰盛多样。因为企业数字化转型、数据库产品或架构变更等需要，数据库之间互相迁徙已成为常态化趋势。 “数据库利用迁徙服务能力”评测分级由信通院主导发动，服务能力共分为6大能力域，16个能力项，共154个测试用例，要求数据库产品具备全方位、高标准、高可靠性的迁徙能力，让用户更容易地将线下传统数据库无损迁徙上云。 据悉，阿里云数据库利用迁徙服务在此次评测中共通过了153项测试用例，凭借当先的产品自动化能力，以靠近满分的问题达到了国内首批评测最高级别——先进级，各项评测均超过各规范的最高要求。 阿里云数据库利用迁徙解决方案是阿里云基于内外部多年数据库和利用迁徙教训，帮忙传统数据库和利用迁徙上云的自研全链路解决方案产品，由数据传输服务DTS、数据库和利用迁徙ADAM组成。 阿里云数据库利用迁徙解决方案架构图 阿里云数据传输产品DTS联合利用和数据库迁徙能力，造成一站式异构数据库迁徙服务，帮忙企业剖析整个IT零碎架构，实现迁徙评估、构造和SQL转换、零停机数据迁徙等全流程服务，显著升高迁徙技术难度和老本，将不确定变为可评估可把控可执行，减速企业技术升级。 目前阿里云数据库利用迁徙解决方案已宽泛服务交通、电力、海关、税务、政务、物流、金融、运营商、互联网等畛域的客户，帮忙客户最大限度升高数据库和利用上云的危险、技术难度和施行周期，实现自助式一键上云。 此外，阿里云PolarDB-X云原生分布式数据库也于近日实现了信通院主导的《分布式事务数据库稳定性专项评测》，高分通过全副测试项目。PolarDB-X 是由阿里自主研发的云原生分布式数据库，是一款基于云架构理念，并同时反对在线事务处理与在线剖析解决 (Hybrid Transactional and Analytical Processing, HTAP）的交融型分布式数据库产品，具备金融级数据高可用、分布式程度扩大、混合负载、低成本存储和极致弹性等能力。 公开材料显示，阿里云自主研发了PolarDB、AnalyticDB、Lindorm、GDB、DAS等云数据库产品，并作为中国惟一的科技厂商胜利进入Gartner寰球数据库领导者象限。过来十多年，阿里云在产品技术畛域停顿迅猛，取得市场宽泛认可，目前已有超过70万个数据库实例迁徙到阿里云上，蕴含政务、批发、金融、电信、制作、物流等多个畛域的龙头企业。 点击这里理解对于ADAM的更多信息 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

简介：近日，阿里云PolarDB-X云原生分布式数据库实现中国信通院《分布式事务数据库稳定性专项评测》，高分通过全副测试项目。随着麻利开发和DevOps模式在IT畛域迅速遍及，使得数据产品的迭代周期显著缩短，零碎中存在潜藏缺点的危险升高。稳定性测试测验了被测产品在极限异样场景下继续提供稳固服务的能力。 中国信通院于2020年开始了基于混沌工程的稳定性测试平台的自主研发工作，并于2021年正式实现并投入使用。平台反对按配置的模式向分布式系统随机屡次地注入不同类别的扰动，注入扰动的品种为生产环境中常见的故障类型，笼罩计算、存储及网络等多个方面。 通过中国信息通信研究院的业余评测，阿里云PolarDB-X云原生分布式数据库在生产环境常见故障场景下外围业务的分布式事务性能、数据强统一等方面，全副满足分布式事务性数据库稳定性测试要求，率先高分通过了全副测试项目。 PolarDB-X 是由阿里巴巴自主研发的云原生分布式数据库，是一款基于云架构理念，并同时反对在线事务处理与在线剖析解决 (Hybrid Transactional and Analytical Processing, HTAP）的交融型分布式数据库产品，具备金融级数据高可用、分布式程度扩大、混合负载、低成本存储和极致弹性等能力，保持以兼容MySQL开源生态构建分布式能力。专一解决海量数据存储、超高并发吞吐、大表瓶颈以及简单计算效率等数据库瓶颈难题。PolarDB-X 非常重视简洁易用的客户体验，日前公布的通明分布式能力，能够使客户以应用传统集中式数据库的习惯，低成本应用云原生分布式数据库。此外，PolarDB-X 以超高并发拜访、海量数据存储、灵便弹性伸缩的技术特点，经验12载双十一极限负载场景打磨，且广泛应用于多个大型政务民生类业务。 阿里云自主研发了PolarDB-X云原生分布式数据库，并作为中国惟一的科技厂商进入2020年Gartner寰球数据库领导者象限。过来十多年，阿里云在产品技术畛域停顿迅猛，取得市场宽泛认可，目前已有超过70万个数据库实例迁徙到阿里云上，蕴含政务、批发、金融、电信、制作、物流等多个畛域的龙头企业。 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

简介：通过引入MaxCompute和Quick BI，大东解决了以往数据查问即刻导致数据库闪崩的情况，还搭建起欠缺的报表体系，稳固应答高频、高并发的数据分析。大东鞋业一季大概有500款的新品。大区下辖的各个分公司要对这500款新品进行订货数量的提报，而这个数字来自于以往的教训和高层下达的KPI。分公司确定了每款的订货数量，接下来就要思考如何首铺，什么样的鞋放在什么样的门店也靠教训撑持。通过一段时间的销售能力后置的依据经营情况对滞销款进行补单，补单量仍旧是靠人为教训或者既定规定。 在守业初期依据人的教训做一些较为激进的决策，让大东在市场疾速扩容，屡创佳绩。但当业务趋近饱和，越来越多的竞争对手涌现，教训上的“激进”和“不稳固”就会变成一种赌博，一旦没有赌准，便会面临微小的损失。 只有数据能帮忙决策实现继续且极致的精细化大东创立了全资子公司屹创，负责大东主品牌和子品牌的数字营销技术与经营。 “数据化也有不同的倒退阶段，就像开车一样，一开始认路靠的是老司机对肯定区域相熟的记忆，而后有了能够按图索骥的地图，之后是数字化的导航，最初就是实现主动驾驶了。咱们当初利用AI+BI走在了数字化导航的阶段。“ 屹翻新批发总经理汤叶青说到。 Quick BI助力数字营销与经营2019年，大数据引擎在大东团体拉通，这是一个0到1的过程。 通过引入MaxCompute和Quick BI，将报表取数从业务零碎中彻底剥离，岂但解决了以往数据查问即刻导致数据库闪崩的情况，还搭建起欠缺的报表体系，稳固应答高频、高并发的数据分析。 Quick BI能力大图 营销治理数据门户搭建 112家分公司全笼罩具备业余能力的数字营销技术与经营团队与分公司业务人员充沛调研之后，为商品首铺、补货、调价等等场景设计多套欠缺的指标体系，在Quick BI后盾连贯多种数据源，实现简单的数据建模与计算，产出数据报表，并搭建残缺的数据门户。 数字营销技术与经营团队实现对立建设后，而后通过Quick BI的空间治理、行级权限治理，平安的将数据下放至112家分公司，再由分公司商品部门随业务需要的变动自主抉择重要的数据指标，通过利落拽的形式，零SQL的产出数据报表，并个性化的欠缺营销治理数据门户。 营销治理数据门户测试数据样板 在这套机制运行的过程中，数字营销技术与经营团队的数据分析师会接到分公司提出的新指标开发需要，发现有的需要视角独特，十分值得大家借鉴。为了激励更多的人参加数字化经营的思考，团体举办了指标体系利用的评比。 在同一个大区的同一时间段，各个分公司都在做同一件事。比方冬季首铺，大家须要通过数据的反对，将商品铺至各个门店。而在这时候，他们最关怀的数据指标是什么，会制作出怎么的报表，在首铺环节产生了怎么的价值？ 这就是一个适宜业务横向评比和经验交流的机会，也是数字营销技术与经营团队积淀剖析模版的好机会。 智能算法调价 优化库存构造 进步出货效率Quick BI能为大东提供良好的数据可视化及仪表板的反对。除了报表和自助剖析服务外，Quick BI还提供了局部人工智能能力。 鞋品的价格在其全生命周期中会历经次数不等的调节，而调价的起因和调至的价格会受到很多因素的影响。 调价前通常会设置一个指标，蕴含销量与均价，再将一些变动的场景因子思考进去，比方温度、天气、上架时长、节假日等等。再与现有的店铺和商品纬度的业务数据联合，通过算法模块进行定价的计算，最初输入调价模型，以及调价后的业务评估指标和模型评估指标，用于对调价后销售体现的复盘。 设定的指标和须要被思考的动静场景因子，是每次调价都不尽相同的变量。这一过程通过Quick BI的数据填报性能输出，该模块提供增、删、改、查以及审批、导出性能。输出的数据被间接存储于RDS数据库。 与存储的业务数据一起在大东的自建智能算法模型中计算出调价模型，实现价格审批流程，将模型导入SAP生成调价倡议。灵便的数据填报和批改能够强化从数据调整到智能再到剖析的闭环。 算法产出的业务评估指标和模型评估指标由Quick BI搭建可视化报表，出现调价后的销售指标实现状态和细节数据变动的洞察。以杭州地区2021年秋季调价为例，零碎产出的调价倡议驳回率为75.7%，调价后销量达成率95.6%。汤总提到的主动驾驶，也呈现端倪。 高频日报、周报生产提效散布在112家分公司的商品部是高度数据化的部门，在这里每天都要产出日报，领导铺货、补货、调货的决策，每周还要产出周报向上汇报。 以往，须要向总部IT提交数据开发的需要，从开发取数，再到制作报表，少则须要2小时。当初，Quick BI中“分析师”角色凋谢给商品团队经理进行自助剖析，通过抉择适宜的可视化图表或电子表格，利用控件进行条件束缚，仅需拖拽指标即可在30分钟内实现日报。适宜公开的数据后果还能够通过钉钉群进行宽泛推送，触达更多的人群。 钉钉群推送报表 反对丰盛数据源直连凋谢是Quick BI始终保持的方向，这在反对的数据源类型上也能洞见一二。晚期，因为老本因素，大东会抉择多种数据库存储不同的业务数据，早在BI工具选型调研时发现很多BI产品不能反对现有数据库。而Quick BI笼罩的数据源多达38种，并且迭代速度很快，简直每次发版都会新增数据源类型。随着业务的倒退，大东开始了更多的尝试，目前利用数据湖DLA订阅友盟SDK埋点数据，友盟采集到的数据，会回流至数据湖DLA，Quick BI能够直连数据湖，读取友盟端实时RT数据明细表，在线依据营销场景剖析需要，创立数据集进行在线多维分析。 大东鞋业在顺应时代倒退的路线上，始终走在积极探索数智化转型的前列。围绕用户价值，大东鞋业充分利用数据和技术思维疾速洞察指标客户的潜在需要，进行商业模式再造，重塑价值链，真正实现“7天快时尚”。 更多数据性能能够直连 智能可视化平台Quick BI理解：https://dp.alibaba.com/product/quickbi 数据中台是企业数智化的必经之路，阿里巴巴认为数据中台是集方法论、工具、组织于一体的，“快”、“准”、“全”、“统”、“通”的智能大数据体系。 目前正通过阿里云对外输入系列解决方案，包含通用数据中台解决方案、批发数据中台解决方案、金融数据中台解决方案、互联网数据中台解决方案、政务数据中台解决方案等细分场景。 其中阿里云数据中台产品矩阵是以Dataphin为基座，以Quick系列为业务场景化切入，包含： - Dataphin，一站式、智能化的数据构建及治理平台；- Quick BI，随时随地 智能决策；- Quick Audience，全方位洞察、全域营销、智能增长；- Quick A+， 跨多端全域利用体验剖析及洞察的一站式数据化经营平台；- Quick Stock， 智能货品经营平台；- Quick Decision，智能决策平台；官方站点： ...

简介：阿里云国内云峰会重磅公布在 6 月 8 日举办的 2021 阿里云国内云峰会（2021 ALIBABA CLOUD SUMMIT）上，阿里云公布了直播解决方案等 20 多种产品、解决方案以及降级，推出了全新的一站式电商直播解决方案，帮忙寰球各类规模的商家上线高互动性直播渠道，进一步帮忙企业进行数字化之旅。 阿里云智能视频云资深技术专家何亚亮堂相本次峰会，就近年间视频行业的次要趋势，及短视频和电商直播两个解决方案进行分享。 新趋势下：视频解决方案的窘境 “内容视频化、交互线上化” 曾经成为社会倒退的显性趋势，浸透在人们的日常生活和企业的倒退转型中，而 2020 年的疫情突起全面减速了 “新内容、新交互、新增长” 的演变过程。 依据 Cisco 提供的数据，预测到 2022 年，82% 的互联网流量将由视频形成。公众尤其是年轻一代更偏向于通过视频来获取信息、社交、玩游戏等。疫情期间，大量流动从线下转至线上，放弃社交间隔以及居家的生存形式推动了视频聊天、视频游戏以及视频信息流的倒退，而随同着 RTC、直播以及 AR/VR 技术的倒退，视频已成为新交互的路径。因而，公众对于视频的需要大幅晋升，视频的大时代在减速到来。 面对简单的视频制作流程以及多样化的业务场景，如果用传统的办法构建视频服务，企业常会遇到 “高资源耗费”、“高技术壁垒” 和 “高经营老本” 这 “三高” 问题。传统解决方案需大量资本投资基础设施，计算、存储和带宽的搭建都须要较高的预付费用，但当面临需要稳定时，企业将很难扩充或扩大服务。此外，视频波及多个深层技术追踪，如视频编码和解码、视频传输、视频加密、CDN（内容散发网络）等。对此，阿里云视频云提供了全面的解决方案，通过基础设施即服务 (IaaS) + 平台即服务（PaaS） + 软件即服务 (SaaS) 的整套计划来解决这些问题。 直面技术挑战：短视频产出更高效 短视频近几年的倒退十分迅猛，并被广泛应用于各个场景中，包含社区内容分享，电商直播，新闻，体育赛事以及即时通信。但创作高质量的短视频并非易事，次要面临着视频制作老本高、耗时长、短少易用的视频编辑工具和疾速交付及对立用户体验的能力等几大挑战。 在短视频的解决方案下，阿里云视频云的全功能多平台 SDK 为用户提供了简略疾速的办法来创立短视频，这其中领有十分多的内置非凡性能和成果。阿里云大规模内容散发网络（CDN）在寰球 70 多个国家和地区领有超过 2,800 个节点。通过内容散发网络 (CDN)，即便网络环境不佳，也能够疾速上传视频。视频一经上传，将在云中失去解决。在云端，视频被数字版权治理技术爱护和阿里云专有的转码技术 “窄带高清” 转码，在升高比特率的同时保障了图像品质，从而实现低带宽老本下的高清晰度体验。 同时，阿里云视频云领有智能的媒资治理和数据分析系统，来帮忙客户治理有价值的视频资源，并对用户在低端到高端的任何设施的播放体验进行了优化，播放端 SDK 能够提供晦涩的播放体验，实现视频秒开。 阿里云视频云曾为 KUMA 提供了高效的短视频解决方案。KUMA 作为菲律宾当先的挪动社交平台，以往的次要业务为直播，在看到 UGC 短视频的后劲后，KUMA 心愿在不破费大量估算的前提下，增加相干内容来晋升其社区活动品质以及 APP 的用户粘性。对此，阿里云视频云为其提供了一套短视频解决方案，在短时间内帮忙 KUMA 将短视频性能增加至他们的平台中，并优化了在菲律宾的 CDN 减速链接，确保其有一个疾速和晦涩的上传以及回放体验。 ...

简介：阿里云研发的下一代云原生数据库PolarDB Serverless的论文被ACM SIGMOD录用，标记着阿里云PolarDB数据库在最新一代架构上当先于业界其余云厂商。近日获悉，阿里云研发的下一代云原生数据库PolarDB Serverless的论文被ACM SIGMOD录用，标记着阿里云PolarDB数据库在最新一代架构上当先于业界其余云厂商。 ACM SIGMOD数据管理国内会议（Special Interest Group on Management Of Data.）由美国计算机协会（ACM）数据管理业余委员会（SIGMOD）发动，是数据库畛域具备最高学术位置的国际性会议。此次论文被录用，SIGMOD认为PolarDB Serverless是第一个采纳软硬件联合技术和分布式内存架构的云数据库，指引了下一代数据库服务的方向。 PolarDB Serverless是业内首个提出并实现的下一代云数据库架构，这标记着阿里云第一次引领了云数据库架构的演进，而非部分的优化翻新。目前PolarDB Serverless已实现了整体开发和验证，正在进行商业化工作，行将公布。 阿里云数据库产品事业部总负责人李飞飞示意，云计算的实质是存储，计算，内存等资源的解耦和池化，帮忙用户最大限度地实现弹性变配、超高并发等能力。PolarDB Serverless在业内首次实现了内存与计算/存储的解耦，内存进一步池化，造成三层池化，使得弹性能力有数量级的晋升，同时内存池化大幅度降低了老本，实现了齐全地按量应用和按需弹性。 由学术界和工业界最顶级的数据库专家组成的SIGMOD评审委员会对本文给出极高的评估：这是第一个采纳RDMA+分布式共享内存池技术来升高复原工夫的云数据库，本文具体论证了反对内存弹性和数据中心资源解耦的几种技术，论文中的内存解耦及其解决方案是一个十分有创意的话题。这是寰球数据库最高顶会对PolarDB Serverless的认可，也证实了基于分布式共享内存的下一代架构是云数据库将来的方向。 此外，本届SIGMOD还录用了云原生日志数据库系统LogStore的论文，LogStore是PolarDB审计和性能诊断日志数据的存储系统，利用云原生架构和创新性的流量调配和查问优化算法，使得多租户海量日志的低成本超长周期存储和高效查问剖析可能同时实现。在LogStore的撑持下，PolarDB为客户提供了欠缺的SQL日志审计和问题诊断服务。 作为中国惟一进入2020年Gartner寰球数据库领导者象限的阿里云数据库，PolarDB是其研发的下一代云原生数据库，也是国内首个云原生数据库。PolarDB的技术实力也屡获权威认可，曾获2019年世界互联网大会当先科技成果奖，2020年中国电子学会“科技进步一等奖”， 相干研究成果被SIGMOD等国内顶级数据库会议屡次收录。 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

简介：面向银行、保险、券商和私募的高频数据高性能一站式解决方案。金融市场L1/L2的报价和交易数据是量化交易钻研十分重要的数据，随着数字业务疾速演进，具备时序特色的交易数据激增，对底层数据库和量化剖析零碎提出了更高的要求。传统的关系数据库撑持这样的数据量级，即使分库分表，查问性能也远远无奈达到要求。罕用列存NoSQL数据库能够解决这个数据量级的存储，然而这类通用的存储引擎不足对时序数据的敌对反对，在查问和计算方面都存在重大的有余，且无奈反对对量化金融场景实时业务计算、流批一体剖析、多源数据交融剖析。 阿里云原生多模数据库Lindorm联结浙江智臾DolphinDB公布金融高频交易数据量化剖析与解决计划，通过云原生形式整合DolphinDB实时高效的数据处理能力和Lindorm多模海量数据交融存储剖析能力，集成了功能强大的编程语言和高容量高速度的流数据分析系统，为金融场景海量时序数据的量化剖析计算提供一站式解决方案。计划操作简略，可扩展性强，具备良好的容错能力及优异的多用户并发拜访能力。 计划劣势能力数据库存储 高吞吐低提早的列式内存引擎。列式混合引擎（基于内存和磁盘）为存储海量数据的数据仓库提供了优越性能。灵便的分区计划：反对值分区、范畴分区、列表分区、哈希分区和组合分区。反对单表百万级别的分区数，大大缩减对海量数据的检索响应工夫。库内剖析：可在数据库中进行简单的编程和运算，防止数据迁徙的耗时。提供多种SQL性能的扩大，包含非同时连贯、窗口连贯、透视表、复合列等。反对同一个分区数据库内多表疾速联结。数据压缩。反对多用户并发拜访。每个用户以给定的权限在独立的会话中工作。元数据高可用：多个管制节点应用Raft协定实现强一致性。分区数据高可用：一个数据库能够蕴含上百万个分区，分区的多正本之间应用改进的二阶段提交协定实现分区正本的强一致性。运维高可用：在线减少服务器节点，在线均衡节点间数据，在线为分区数据表减少字段。数据库的增量备份机制：当分区正本数为N的时候，在N-1个节点宕机的状况下，保证系统仍能够继续写入和读取。应用内嵌的分布式文件系统主动治理分区数据及其正本，为分布式计算提供负载平衡和容错能力。数据库内数据分析 编程语言功能强大且表达能力丰盛。反对命令式编程、函数式编程、向量编程、SQL编程和RPC（近程函数调用）编程。编程语言的语法与SQL和Python十分类似，易上手易使用。内置1000多个函数，涵盖绝大多数罕用的数据处理、数据分析、机器学习等性能，以及文件调用与数据库治理等性能。通过内存引擎、数据本地化、细粒度数据分区和并行计算实现高速的分布式计算。提供即时编译版本，极大减速for-loop, while-loop与if-else等语句的执行速度。反对多种计算模型，包含pipeline、map-reduce和迭代计算。为动态数据分布式计算提供快照隔离。通过在多任务中共享内存的数据副原本进步零碎吞吐量。可便捷地剖析分布式数据。在单个节点上编写脚本后，无需编译和部署即可在整个集群上执行。流数据无缝集成流数据和数据库表。能够应用SQL查问本地流数据或分布式流数据。内置工夫序列、横截面、异样检测以及响应式状态引擎等多种流数据聚合引擎。可应用DolphinDB中的用户自定义函数解决信息。亚毫秒级的信息提早。应用实时数据更新历史数据仓库只有亚秒级提早。能够从任意偏移量重现历史信息。提供可配置的选项（如分区、工作线程、队列）用于流量管制和性能调优。生态 提供多种编程API，包含C++、Python、Java、C#、Go和Excel等。已有的pandas程序只需做大量改变即可通过pandas API (orca) 在DolphinDB中运行。提供多种插件，包含MySQL、ODBC、HDF5、Parquet等。内置Web服务器，用于集群治理、性能监控和数据拜访。提供DolphinDB GUI与VS Code插件等IDE（集成开发环境）用于数据分析。通过内置函数、Web接口或Prometheus实现系统监控。版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

简介： Hologres+Flink+DataWorks实时数仓新计划为伊的家业务带来了对立数据、对立服务、对立治理、对立存储的价值，真的做到了开箱即用，所见即所得！GitHub 地址 https://github.com/apache/flink 欢送大家给 Flink 点赞送 star~ 广州伊的家网络科技有限公司是一家专一于服务女性的B2B2C电商平台，业务范围包含护肤、彩妆、养分美容食品、私人定制服装、跨境电商等畛域。自2008年孵化我的项目，2011年5月上线天猫商城，全国8大配送核心，妍诗美、妍膳等品牌陆续成立，并于2013年上线了伊的家自主电商平台，2020年全面启动品牌降级。伊的家以互联网主动式服务营销，打造护肤老师与客户强连贯关系，从上到下严格贯彻以品质及业余为根底，以社交信赖做连贯，以服务取得认可的经营思路，通过继续的翻新和积攒，成为社交电商翘楚。 业务场景与痛点剖析伊的家是一家集开发、设计、经营、销售于一体一个B2B2B的电商平台，服务百万级会员之外，还同时反对上千级别经销商和代理商，业务利用多、数据量大、数据查问并发要求高。 伊的家技术部门在近3年经验了高速倒退，在倒退过程中，始终保持业务优先，为此也进行了利用整合、拆分微服务、聚合分布式应用的多种技术升级革新，目前整个部门现状剖析如下： 架构方面：多语言、多数据源、技术升级的业务入侵问题显著；数据方面：利用拆分引发的数据孤岛问题，继而造成大量的数据复制、从新建设问题；利用方面：从业绩的角度登程，业务方心愿及时精确地看见业绩数据，对实时性有了较高需要；效率方面：体系化的流程与工具诉求愈发强烈；老本方面：次要问题是既懂大数据又懂业务的人才招聘难，团队建设老本高 伊的家近几年业务高速增长，数据量激增，业务复杂度也随之增大，解决在以后大数据架构之下，“人才储备难”、“业务降级受限于已有技术”、“双11流动压力大”等痛点问题已火烧眉毛。 产品选型伊的家技术部门对于技术升级革新的需要有十分明确清晰的定义，次要围绕关存储弹性扩缩容、查问性能优化、OLAP、学习老本、查问响应、可扩大等角度进行开展，外围关注以下3个问题： 1）如何疾速实现数据荡涤 2）如何疾速精准实现数据校验 3）如何疾速进行故障复原解决 在技术选型时始终保持“技术选型是第一生产力”的准则，深信技术储备没有最好只有更好，深信技术选型是决定能力差异化所在，保持进步一次性把事件做对的能力，深信凋谢分享、认知降级的重要性。 晚期耶基于Hadoop、HBase、Kafaka、Azkaban、Spark、Greenplum等开源大数据产品进行了许多摸索尝试，通过性能比照最终采纳了Greenplum，但最终发现Greenplum并发能力差，只适宜剖析场景，并不适宜高并发的查问服务。 起初，在阿里云大数据计算平台团队的倡议下，伊的家技术部进行了全面架构降级，整个架构由DataWorks、实时计算Flink和Hologres组成，架构简略、学习老本非常低，仅通过SQL即可轻松跑通全链路。 上面将会给大家介绍，阿里云技术产品在伊的家落地的场景最佳实际 最佳实际一、客户零碎实际伊的家原客户关系管理系统（CRM）次要基于MySQL、MQ、Canal以及自研利用组成，为反对业务零碎切断式降级，技术部门自主研发了一套消息中间件，保护老本较高；基于Binlog、MQ、OLAP等产品自定义的数据开发流程过程繁琐简单、保护老本极高，且因为零碎要求数据有序对荡涤的并发产生了肯定的限度。 基于Hologres+DataWorks+实时计算Flink进行架构降级后，间接通过DataWorks数据集成将数据库数据实时写入Hologres，而后通过实时计算Flink订阅Hologres做进一步实时荡涤，把后果表更新到数据库，即可间接服务业务。 整体架构清晰简略、数据精准、端到端纯实时、存储剖析一体化、托管式运维、全自动工具作业，原零碎15人花了3个月才实现我的项目上线，以后架构仅需2天即部署实现。 二、BI业绩零碎实际BI业绩零碎也能够了解为实时GMV大屏，业务数据次要有两方面的要求： 实时精准，业绩计算绝不允许出错。原架构如下图图所示，原始数据层通过Binlog，再通过Canal套件实时写入MQ，之后依据业务域进行业务数据分层和荡涤。任务调度零碎更新业绩的程序为“日-月-季度-年”，这个看似完满的计划理论存在着几个问题： 实时性问题：看似实时，其实过程中可能存在5~10分钟的提早；并发问题：生产的并发有肯定限度。运维问题：如果图中的某个环节呈现问题，可能会导致系统也跟着呈现问题。数据荡涤时效问题：荡涤脚本运行一次可能须要数分钟，这期间可能会产生许多其余事件。下图为降级后的BI业绩零碎新架构。通过DataWorks实时同步明细数据至Hologres，基于Hologres数据再减少一份实时计算Flink的实时ETL作业，即可实现“日-月-季度-年”数据的加工，最初基于Hologres对下层利用提供剖析查问服务。整个零碎纯实时调度、实时性高、秒级提早、全SQL开发、数据校验高效。 三、实时利用数仓架构实际伊的家的技术部门也始终在思考如何让利用开发人员也具备大数据开发能力，如何让大数据不仅仅为大数据团队所用，还同时为利用开发团队所用。 基于实时计算FLink+Hologres+DataWorks实时数仓架构的落地，晋升了数据底盘的可复用性，进步了应答业务变动的数据动静调整的灵活性，与利用团队独特构建起带数据的利用零碎。 四、团体数仓架构实际伊的家数仓团队服务在电商业务的同时，还须要反对团体外部业务。团体数仓平台如市场支流数仓架构、基于开源大数据体系构建，目前也曾经全面降级为Hologres+实时计算Flink+DataWorks实时数仓架构。 业务价值与赋能Hologres+实时计算Flink+DataWorks实时数仓新计划为业务上带来的价值次要如下： 对立数据：一套计划就能反对残缺流程，明细表、维度表等数据对立、有序对立服务：由Hologers间接提供各种线上服务，包含数据分析，数据服务等，缩小接口建设。对立存储：以Hologres为对立存储，多数据源都能间接写入到Hologres，无冗余存储，节约老本对立治理：DataWorks提供统一标准、对立作业和对立监控等，为大数据开发平台提供对立治理。从业务上来说，新的大数据计划真的做到了开箱即用，所见即所得。 展望未来在大数据畛域，数据规模和业务复杂性是同时制约查问性能的关键因素，在这个过程中，唯有咱们的开发人员一直打磨本人的数据模型，当数据模型达到肯定成熟度，性能问题即可迎刃而解。 最初，心愿大家拥抱技术、拥抱变动、赢在模型，数据服务业务，数据服务利用，让咱们为利用而生，为利用而战。 作者：刘松森 ，伊的家CTO，高级工程师，副教授职称，国内多所高校客座教授 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

简介：将来的企业应用是什么样子，如何让企业员工0成本低代码搭建企业本人的零碎，当初由企业实现贴合本身业务倒退的零碎，变得如此简略。咱们请来阿里钉钉事业部的资深专家为咱们解说交融云原生、钉原生与生态aPaaS能力的钉钉利用开发平台，以及钉钉宜搭业务互联互通的翻新实际，并现场一一解答咱们心中的纳闷，期待嘉宾们的精彩的分享。.jpg") 流动介绍： 在企业数字化信息化飞速发展的明天，企业面对数字化降级，如何在日常治理中缩小纸质传递，如何让表格流转更快捷，如何晋升企业的办公效率和合作能力，同时解决因门店扩散、员工流动性低等因素，面临数据难以全面归集存储、流程不通顺、企业信息易泄露等一系列难题。当初，通过钉钉宜搭这一低代码利用构建平台，企业能够用更不便、快捷的形式，从点到面建设业务全生命周期的数字化管理机制。 将来的企业应用是什么样子，如何让企业员工0成本低代码搭建企业本人的零碎，当初由企业实现贴合本身业务倒退的零碎，变得如此简略。咱们请来阿里钉钉事业部的资深专家为咱们解说交融云原生、钉原生与生态aPaaS能力的钉钉利用开发平台，以及钉钉宜搭业务互联互通的翻新实际，并现场一一解答咱们心中的纳闷，期待嘉宾们的精彩的分享。 流动工夫：6月26号（周六）14:00-17:00 流动地点：西安软件新城软件研发基地2期阿里巴巴大楼19楼华山论剑会议室 报名链接：https://hd.aliyun.com/form/598 或流动行报名：http://hdxu.cn/4Fh2k 流动流程： 13:00~14:00  签到 14:00~14:10  介绍阿里云开发者社区 14:10~14:40 《钉钉搭低代码利用广场与开发者服务框架》南浩淼（法善），钉钉开发者生态经营专家 14:40~15:10 《钉钉服务窗产品介绍》王清雪，钉钉事业部产品管理中心 15:10~15:20  阿里云开发者社区（ACE西安同城会班委）现场招募 15:20~15:50 《钉钉助力账款管家，实现企业应收应付账款精细化治理》张明，西安朋克信息科技有限公司 COO 15:50~16:20 《低代码如何打造数字化餐饮最佳实际》林昕岚，上海鸿欢网络有限公司副总经理 16:20~16:50 《云开发让前端成为钉钉利用的全栈开发者》王义林（宁中），阿里云云开发平台架构师，高级技术专家 16:50~17:00  抽奖-合影-流动完结 流动奖品： 阿里云双肩包、T恤等 阿里云ACE 阿里云ACE即全称 Alibaba Cloud Engineer，是意为阿里云的工程师、代表着云计算的建设者。同时“ACE”又是扑克牌中的“A”，因而阿里云ACE也寓意着是云计算畛域王牌的一群人。在线上，ACE领有专属的页面和29个社群，承载论坛及专栏等内容； 在线下，ACE通过组织丰盛的流动，包含技术沙龙、TechDay、Meetup、官网互动等来造成本地化的开发者的学习、社交平台。 通过ACE组织的各种流动，ACE用户能够结识本地的开发者，播种前沿常识，积攒行业教训，并加深对阿里云的理解。 流动海报： 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

简介：占超群，花名离哲，阿里巴巴团体研究员，数据库OLAP产品部负责人。离哲说，这个花名的由来，是武侠小说里的一个人物。他不是天性过人那种角色，却凭借本人的保持和致力，最终达到了高峰。在云技术这个战场上，数据库是核心技术厮杀最强烈的新战场。在阿里，离哲始终保持长期主义的技术态度，最终率领研发团队，研发的产品云原生数据仓库AnalyticDB和云原生数据湖剖析Dala Lake Analytics失去广泛应用，取得浙江省科技进步一等奖，技术上也实现了对TPC榜单的逆袭。 2011年退出阿里巴巴，在近10年工夫始终从事数据仓库、数据湖根底平台钻研、研发、产品化相干工作。目前在阿里云数据库事业部次要负责数据仓库与数据湖相干产品的研发；达摩院数据库与存储实验室研究员。 数据库这个词你可能有些生疏，但其实，所有的古代生存背地，都暗藏着数据库的服务。你的每一次生产、每一次股票交易、每一条微博动静，都离不开数据库。 人类的倒退跟数据非亲非故，人类最早的时候，是从结绳记事开始；到起初，能够把文字记录到甲骨文上；再到起初咱们开始有了计算机。从人类诞生开始，人类就在不停地记录信息，其实那就是数据库的雏形。 1960年阿波罗登月打算，美国航空航天局NASA为了记录整个航天过程中的所有信息，联结 IBM 研发出了第一代数据库——IMS。随后数据库技术开始进入民用畛域并失去广泛应用。 Q：您过后为什么抉择退出阿里？ 占超群：应该是在11年左右，那时候意识很多淘宝的敌人，过后整个淘宝其实也倒退很快。我记得印象中如同在2011年的时候，淘宝的日独立UV超过1.2个亿，而后那时候我感觉可能淘宝是最有机会去实现一个很重要的技术冲破的中央。 Q：在阿里工作近十年，您有遇到什么窘境吗？ 占超群：印象中比拟粗浅的窘境是在刚来的第五个月的时候，原本主管要求我是两个月要上线的。然而我做了五个月还没上线。那时候产生了第一次理念的抵触。 其实主管给我要求做一个为单个业务服务的数据处理技术，还不能称之为数据库系统，他说你把这事件做好就够了。我过后跟主管讲，这个事件不是为单个业务服务的一个模块，而应该是一个平台型的设计和平台型的零碎。咱们俩一起聊了很久，最终我感觉还是很侥幸的，大家还是达成了统一，主管感觉这个事件有价值。 所以我过后第一天就依照一个数据库的状态去倒推明天该怎么做，思考到描述语言(SQL)、优化器、存储引擎、执行引擎，从最开始反对一个到两个到20个业务，到明天的500多个，团体的剖析业务根本都笼罩了。 Q：2019年，阿里巴巴的AnalyticDB数据库荣登TPC-DS榜单第一，终于突破了甲骨文和微软在数据库畛域的霸主位置。您过后怎么想到要去冲击TPC榜单？ 占超群：18年的10月份，我记得是在一个早晨，我拉了团队几个外围的骨干，我说咱们要去冲击一下 TPC，打磨下咱们端到端的技术，依照国际标准进行极致与严格刻薄的端到端验证。 过后他们都比拟拥护，他们看了报告感觉好多货色都看不大懂，甚至第一反馈不是很了解背地考查什么？要用什么技术去解决？这个外面其实挑战是很大的，但我说这个事件咱们必须去，我说这是咱们很重要的一个飞跃点和技术验证点，这些技术通用化是能够很好地打磨产品，也会对客户产生很大的价值。 Q：很多人可能会感觉去挑战一个长期被国外巨头垄断的数据库技术榜单，您是给本人定了一个过高的指标，您中途是否有想过放弃？ 占超群：我是很动摇的。但过程真的十分苦楚。我花了大部分工夫和大家在我的项目室或开电话会，一项一项地抠细节，一项一项去做架构的review。 Q：徒步之旅和冲击 TPC 有什么殊途同归之处？ 占超群：我以前走过一次徒步，就是去过玄奘之路，让我毕生的印象粗浅的事件就是徒步第三天，起点是个风车镇，从露营的中央你就能看到那个起点，然而你就怎么走都走不过去。登程的时候还很开心感觉一下子就能看到起点应该很快就能实现，然而走到中午发现，他们说你才走了一半不到，所以那天很多人都放弃了，就走到一半就放弃了；我走到一半的时候，我也感觉特地好受。 我在中途劳动了很久，心里也很想放弃。因为我这么多年的一个性情，就是再难，只有定了，我是爬过来也好，还是走过来也好，然而肯定要去到起点。所以中途劳动了特地长时间，起初还是爬起来接着走，印象中走到天黑才走到起点。 咱们走向国际化就这种感觉，你晓得对手是谁，他做成咋样了，然而你就是不晓得该怎么走过来。就是你跑一段发现，这段对手曾经五年前走过了。再跑一段，发现对手七年前走过了，就这种感觉，是其实很让人又兴奋又失望的那种。 最终是在2019年的4月份，咱们就正式实现了，并且成果还十分好，拿到了性能和性价比寰球第一。 Q：每一次的产业革命都随同着基础设施的更迭，而在数据库畛域，也正产生着这样一场从旧到新、从传统到云端的技术巨变。您是怎么对待这样的转变？ 占超群：云计算其实在重构整个数据库的体系结构。以前数据库的构造是什么样子呢？磁盘、CPU、内存都是单机的，要么 Scale up 扩大单机资源如内存等，要么 Scale out 扩大物理机数量。但明天云计算基础设施变动会呈现什么呢？存储是能够共享和按需付费的，计算也能够依照实时的申请弹性扩大。它把整个体系结构都变了，云原生加分布式技术对于数据库来说是微小的时机，这个货色其实是咱们在以后，最有机会能超过国外厂商的一个新赛道。 Q：您总共招聘过多少人？ 占超群：我看零碎应该超过1500人。无论是侠客行、百年阿里，上了很多场课。 Q：您选人的规范是什么？ 占超群：实际上就是很多人分不清什么叫常识，什么叫教训，什么叫能力，什么叫后劲。比方我看了一本书或一篇Paper，这只能叫一个常识；而后我做了某件事情，用到这些常识，这叫教训。能力是什么呢？就是说，我做了这件事件总结进去的技术和教训，我在B、C、D、E我的项目中复制了，这个就叫能力。基于这些能力，而后在面临一个未知的时候，我也能做得很好，这叫后劲。这是咱们要去深刻开掘进去的货色，因为咱们面临很多未知挑战，须要更多人一起去解决。 Q：您有什么特地的解压形式吗？ 占超群：待的工夫越长，缓缓会造成一个思维惯性和执行惯性，也会失去刚入职的那种锐气和勇气，这是我最怕的一件事件。以前在西溪园区的时候，那个时候比方我在面临一些压力或者有很大挑战和抉择的时候，我都会看一下九号馆的雕像，更多时候想想我是不是背了太多包袱了。 其实我跟大家一样，也是从一个基层的同学成长起来的，过程中肯定会碰到很多的冤屈，包含老板不肯定了解，包含被业务方否定和批评，包含各种内外部的技术 PK，这个过程中也是经验了很多心田的纠结徘徊。 很多时候我也想过放弃。但这个过程中，比方咱们的技术用到城市大脑让这个城市更平安，让城市的治理效率更高；技术用到邮政等让整个邮政的物流效率更低等。其实背地都是有十分大的技术冲破和翻新，这些技术在一步步地扭转民生，在反对企业数字化，承载很多客户对咱们的信赖与托付，让很多美妙的事件产生。这些是能让我在很多时候，在冤屈和徘徊的时候坚持下去最大的能源。 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

简介：Hologres+Flink+DataWorks实时数仓新计划为伊的家业务带来了对立数据、对立服务、对立治理、对立存储的价值，真的做到了开箱即用，所见即所得！广州伊的家网络科技有限公司是一家专一于服务女性的B2B2C电商平台，业务范围包含护肤、彩妆、养分美容食品、私人定制服装、跨境电商等畛域。自2008年孵化我的项目，2011年5月上线天猫商城，全国8大配送核心，妍诗美、妍膳等品牌陆续成立，并于2013年上线了伊的家自主电商平台，2020年全面启动品牌降级。伊的家以互联网主动式服务营销，打造护肤老师与客户强连贯关系，从上到下严格贯彻以品质及业余为根底，以社交信赖做连贯，以服务取得认可的经营思路，通过继续的翻新和积攒，成为社交电商翘楚。 业务场景与痛点剖析伊的家是一家集开发、设计、经营、销售于一体一个B2B2B的电商平台，服务百万级会员之外，还同时反对上千级别经销商和代理商，业务利用多、数据量大、数据查问并发要求高。 伊的家技术部门在近3年经验了高速倒退，在倒退过程中，始终保持业务优先，为此也进行了利用整合、拆分微服务、聚合分布式应用的多种技术升级革新，目前整个部门现状剖析如下： 架构方面：多语言、多数据源、技术升级的业务入侵问题显著； 数据方面：利用拆分引发的数据孤岛问题，继而造成大量的数据复制、从新建设问题； 利用方面：从业绩的角度登程，业务方心愿及时精确地看见业绩数据，对实时性有了较高需要； 效率方面：体系化的流程与工具诉求愈发强烈； 老本方面：次要问题是既懂大数据又懂业务的人才招聘难，团队建设老本高 伊的家近几年业务高速增长，数据量激增，业务复杂度也随之增大，解决在以后大数据架构之下，“人才储备难”、“业务降级受限于已有技术”、“双11流动压力大”等痛点问题已火烧眉毛。 产品选型伊的家技术部门对于技术升级革新的需要有十分明确清晰的定义，次要围绕关存储弹性扩缩容、查问性能优化、OLAP、学习老本、查问响应、可扩大等角度进行开展，外围关注以下3个问题： 1）如何疾速实现数据荡涤 2）如何疾速精准实现数据校验 3）如何疾速进行故障复原解决 在技术选型时始终保持“技术选型是第一生产力”的准则，深信技术储备没有最好只有更好，深信技术选型是决定能力差异化所在，保持进步一次性把事件做对的能力，深信凋谢分享、认知降级的重要性。 晚期耶基于Hadoop、HBase、Kafaka、Azkaban、Spark、Greenplum等开源大数据产品进行了许多摸索尝试，通过性能比照最终采纳了Greenplum，但最终发现Greenplum并发能力差，只适宜剖析场景，并不适宜高并发的查问服务。 起初，在阿里云大数据计算平台团队的倡议下，伊的家技术部进行了全面架构降级，整个架构由DataWorks、实时计算Flink和Hologres组成，架构简略、学习老本非常低，仅通过SQL即可轻松跑通全链路。 上面将会给大家介绍，阿里云技术产品在伊的家落地的场景最佳实际 最佳实际一、客户零碎实际伊的家原客户关系管理系统（CRM）次要基于MySQL、MQ、Canal以及自研利用组成，为反对业务零碎切断式降级，技术部门自主研发了一套消息中间件，保护老本较高；基于Binlog、MQ、OLAP等产品自定义的数据开发流程过程繁琐简单、保护老本极高，且因为零碎要求数据有序对荡涤的并发产生了肯定的限度。 基于Hologres+DataWorks+实时计算Flink进行架构降级后，间接通过DataWorks数据集成将数据库数据实时写入Hologres，而后通过实时计算Flink订阅Hologres做进一步实时荡涤，把后果表更新到数据库，即可间接服务业务。 整体架构清晰简略、数据精准、端到端纯实时、存储剖析一体化、托管式运维、全自动工具作业，原零碎15人花了3个月才实现我的项目上线，以后架构仅需2天即部署实现。 二、BI业绩零碎实际BI业绩零碎也能够了解为实时GMV大屏，业务数据次要有两方面的要求： 实时精准，业绩计算绝不允许出错。原架构如下图图所示，原始数据层通过Binlog，再通过Canal套件实时写入MQ，之后依据业务域进行业务数据分层和荡涤。任务调度零碎更新业绩的程序为“日-月-季度-年”，这个看似完满的计划理论存在着几个问题： 实时性问题：看似实时，其实过程中可能存在5~10分钟的提早；并发问题：生产的并发有肯定限度。运维问题：如果图中的某个环节呈现问题，可能会导致系统也跟着呈现问题。数据荡涤时效问题：荡涤脚本运行一次可能须要数分钟，这期间可能会产生许多其余事件。 下图为降级后的BI业绩零碎新架构。通过DataWorks实时同步明细数据至Hologres，基于Hologres数据再减少一份实时计算Flink的实时ETL作业，即可实现“日-月-季度-年”数据的加工，最初基于Hologres对下层利用提供剖析查问服务。整个零碎纯实时调度、实时性高、秒级提早、全SQL开发、数据校验高效。 三、实时利用数仓架构实际伊的家的技术部门也始终在思考如何让利用开发人员也具备大数据开发能力，如何让大数据不仅仅为大数据团队所用，还同时为利用开发团队所用。 基于实时计算FLink+Hologres+DataWorks实时数仓架构的落地，晋升了数据底盘的可复用性，进步了应答业务变动的数据动静调整的灵活性，与利用团队独特构建起带数据的利用零碎。 四、团体数仓架构实际伊的家数仓团队服务在电商业务的同时，还须要反对团体外部业务。团体数仓平台如市场支流数仓架构、基于开源大数据体系构建，目前也曾经全面降级为Hologres+实时计算Flink+DataWorks实时数仓架构。 业务价值与赋能Hologres+实时计算Flink+DataWorks实时数仓新计划为业务上带来的价值次要如下： 对立数据：一套计划就能反对残缺流程，明细表、维度表等数据对立、有序对立服务：由Hologers间接提供各种线上服务，包含数据分析，数据服务等，缩小接口建设。对立存储：以Hologres为对立存储，多数据源都能间接写入到Hologres，无冗余存储，节约老本对立治理：DataWorks提供统一标准、对立作业和对立监控等，为大数据开发平台提供对立治理。从业务上来说，新的大数据计划真的做到了开箱即用，所见即所得。 展望未来在大数据畛域，数据规模和业务复杂性是同时制约查问性能的关键因素，在这个过程中，唯有咱们的开发人员一直打磨本人的数据模型，当数据模型达到肯定成熟度，性能问题即可迎刃而解。 最初，心愿大家拥抱技术、拥抱变动、赢在模型，数据服务业务，数据服务利用，让咱们为利用而生，为利用而战。 作者：刘松森 ，伊的家CTO，高级工程师，副教授职称，国内多所高校客座教授 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

简介：最佳实际，以DLA为例子。DLA致力于帮忙客户构建低成本、简略易用、弹性的数据平台，比传统Hadoop至多节约50%的老本。其中DLA Meta反对云上15+种数据数据源（OSS、HDFS、DB、DW）的对立视图，引入多租户、元数据发现，谋求边际老本为0，收费提供应用。DLA Lakehouse基于Apache Hudi实现，次要指标是提供高效的湖仓，反对CDC及音讯的增量写入，目前这块在加紧产品化中。DLA Serverless Presto是基于Apache PrestoDB研发的，次要是做联邦交互式查问与轻量级ETL。背景数据湖以后在国内外是比拟热的计划，MarketsandMarkets _（https://www.marketsandmarkets.com/Market-Reports/data-lakes-market-213787749.html）_市场调研显示预计数据湖市场规模在2024年会从2019年的79亿美金增长到201亿美金。一些企业曾经构建了本人的云原生数据湖计划，无效解决了业务痛点；还有很多企业在构建或者打算构建本人的数据湖。Gartner 2020年公布的报告显示_（https://www.gartner.com/smarterwithgartner/the-best-ways-to-organize-your-data-structures/）_目前曾经有39%的用户在应用数据湖，34%的用户思考在1年内应用数据湖。随着对象存储等云原生存储技术的成熟，一开始大家会先把结构化、半结构化、图片、视频等数据存储在对象存储中。当须要对这些数据进行剖析时，会抉择比方Hadoop或者阿里云的云原生数据湖剖析服务DLA进行数据处理。对象存储相比部署HDFS在剖析性能下面有肯定的劣势，目前业界做了宽泛的摸索和落地。 一、基于对象存储剖析面临的挑战1、什么是数据湖Wikipedia上说数据湖是一类存储数据天然/原始格局的零碎或存储，通常是对象块或者文件，包含原始零碎所产生的原始数据拷贝以及为了各类工作而产生的转换数据，包含来自于关系型数据库中的结构化数据（行和列）、半结构化数据（如CSV、日志、XML、JSON）、非结构化数据（如email、文档、PDF、图像、音频、视频）。 从下面能够总结出数据湖具备以下个性： 数据起源：原始数据、转换数据数据类型：结构化数据、半结构化数据、非结构化数据、二进制数据湖存储：可扩大的海量数据存储服务2、数据湖剖析计划架构 次要包含五个模块： 数据源：原始数据存储模块，包含结构化数据（Database等）、半结构化（File、日志等）、非结构化（音视频等）；数据集成：为了将数据对立到数据湖存储及治理，目前数据集成次要分为三种状态表面关联、ETL、异步元数据构建；数据湖存储：目前业界数据湖存储包含对象存储以及自建HDFS。随着云原生的演进，对象存储在扩展性、老本、免运维有大量的优化，目前客户更多的抉择云原生对象存储作为数据湖存储底座，而不是自建HDFS。元数据管理：元数据管理，作为连贯数据集成、存储和剖析引擎的总线；数据分析引擎：目前有丰盛的剖析引擎，比方Spark、Hadoop、Presto等。3、面向对象存储剖析面临的挑战对象存储相比HDFS为了保障高扩展性，在元数据管理方面抉择的是扁平的形式；元数据管理没有保护目录构造，因而能够做到元数据服务的程度扩大，而不像HDFS的NameNode会有单点瓶颈。同时对象存储相比HDFS能够做到免运维，按需进行存储和读取，构建齐全的存储计算拆散架构。然而面向剖析与计算也带来了一些问题： List慢：对象存储依照目录/进行list相比HDFS怎么慢这么多？申请次数过多：剖析计算的时候怎么对象存储的申请次数费用比计算费用还要高？Rename慢：Spark、Hadoop剖析写入数据怎么始终卡在commit阶段？读取慢：1TB数据的剖析，相比自建的HDFS集群竟然要慢这么多！......4、业界面向对象存储剖析优化现状下面这些是大家基于对象存储构建数据湖剖析计划遇到的典型问题。解决这些问题须要了解对象存储相比传统HDFS的架构区别进行针对性的优化。目前业界做了大量的摸索和实际： JuiceFS：保护独立的元数据服务，应用对象存储作为存储介质。通过独立元数据服务来提供高效的文件治理语义，比方list、rename等。然而须要部署额定服务，所有的剖析读取对象存储依赖该服务；Hadoop：因为Hadoop、Spark写入数据应用的是基于OutputCommitter两阶段提交协定，在OutputCommitter V1版本在commitTask以及commitJob会进行两次rename。在对象存储下面进行rename会进行对象的拷贝，老本很高。因而提出了OutputCommitter V2，该算法只用做一次rename，然而在commitjob过程中断会产生脏数据；Alluxio：通过部署独立的Cache服务，将近程的对象存储文件Cache到本地，剖析计算本地读取数据减速；HUDI：以后呈现的HUDI、Delta Lake、Iceberg通过metadata的形式将dataset的文件元信息独立存储来躲避list操作 ，同时提供和传统数据库相似的ACID以及读写隔离性；阿里云云原生数据湖剖析服务DLA：DLA服务在读写对象存储OSS下面做了大量的优化，包含Rename优化、InputStream优化、Data Cache等。二、DLA面向对象存储OSS的架构优化因为对象存储面向剖析场景具备下面的问题，DLA构建了对立的DLA FS层来解决对象存储元信息拜访、Rename、读取慢等问题。DLA FS同时反对DLA的Serverless Spark进行ETL读写、DLA Serverless Presto数据交互式查问、Lakehouse入湖建仓数据的高效读取等。面向对象存储OSS的架构优化整体分为四层： 数据湖存储OSS：存储结构化、半结构化、非结构化，以及通过DLA Lakehouse入湖建仓的HUDI格局；DLA FS：对立解决面向对象存储OSS的剖析优化问题，包含Rename优化、Read Buffer、Data Cache、File List优化等；剖析负载：DLA Serverless Spark次要读取OSS中的数据ETL后再写回OSS，Serverless Presto次要对OSS下面建仓的数据进行交互式查问；业务场景：基于DLA的双引擎Spark和Presto能够反对多种模式的业务场景。 三、DLA FS面向对象存储OSS优化技术解析上面次要介绍DLA FS面向对象存储OSS的优化技术： 1、Rename优化在Hadoop生态中应用OutputCommitter接口来保障写入过程的数据一致性，它的原理相似于二阶段提交协定。 开源Hadoop提供了Hadoop FileSystem的实现来读写OSS文件，它默认应用的OutputCommitter的实现是FileOutputCommitter。为了数据一致性，不让用户看到两头后果，在执行task时先把后果输入到一个长期工作目录，所有task都确认输入实现时，再由driver对立将长期工作目录rename到生产数据门路中去。如下图： 因为OSS相比HDFS它的Rename操作非常低廉，是copy&delete操作，而HDFS则是NameNode上的一个元数据操作。在DLA的剖析引擎持续应用开源Hadoop的FileOutputCommitter性能很差，为了解决这个问题，咱们决定在DLA FS中引入OSS Multipart Upload个性来优化写入性能。 3.1 DLA FS反对Multipart Upload模式写入OSS对象阿里云OSS反对Multipart Upload性能，原理是把一个文件宰割成多个数据片并发上传，上传实现后，让用户本人抉择一个机会调用Multipart Upload的实现接口，将这些数据片合并成原来的文件，以此来进步文件写入OSS的吞吐。因为Multipart Upload能够管制文件对用户可见的机会，所以咱们能够利用它代替rename操作来优化DLA FS在OutputCommitter场景写OSS时的性能。 基于Multipart Upload实现的OutputCommitter，整个算法流程如下图： 利用OSS Multipart Upload，有以下几个益处： 写入文件不须要屡次拷贝。能够看到，原本低廉的rename操作曾经不须要了，写入文件不须要copy&delete。另外相比于rename，OSS 的completeMultipartUpload接口是一个十分轻量的操作。呈现数据不统一的几率更小。尽管如果一次要写入多个文件，此时进行completeMultipartUpload依然不是原子性操作，然而相比于原先的rename会copy数据，他的工夫窗口会缩短很多，呈现数据不统一的几率会小很多，能够满足绝大部分场景。rename中的文件元信息相干操作不再须要。通过咱们的统计，算法1中一个文件的元数据操作能够从13次降落到6次，算法2则能够从8次降落到4次。OSS Multipart Upload中管制用户可见性的接口是CompleteMultipartUpload和abortMultipartUpload,这种接口的语义相似于commit/abort。Hadoop FileSystem标准接口没有提供commit/abort这样的语义。 为了解决这个问题，咱们在DLA FS中引入Semi-Transaction层。 3.2 DLA FS引入Semi-Transaction层后面有提到过，OutputCommitter相似于一个二阶段提交协定，因而咱们能够把这个过程形象为一个分布式事务。能够了解为Driver开启一个全局事务，各个Executor开启各自的本地事务，当Driver收到所有本地事务实现的信息之后，会提交这个全局事务。 ...

简介：Hologres技术揭秘系列继续更新中，本期咱们将带来Hologres高性能原生减速查问MaxCompute的技术原理解析。Hologres（中文名交互式剖析）是阿里云自研的一站式实时数仓，这个云原生零碎交融了实时服务和剖析大数据的场景，全面兼容PostgreSQL协定并与大数据生态无缝买通，能用同一套数据架构同时反对实时写入实时查问以及实时离线联邦剖析。它的呈现简化了业务的架构，与此同时为业务提供实时决策的能力，让大数据施展出更大的商业价值。从阿里团体诞生到云上商业化，随着业务的倒退和技术的演进，Hologres也在继续一直优化核心技术竞争力，为了让大家更加理解Hologres，咱们打算继续推出Hologres底层技术原理揭秘系列，从高性能存储引擎到高效率查问引擎，高吞吐写入到高QPS查问等，全方位解读Hologres，请大家继续关注！ 往期精彩内容： 2020年VLDB的论文《Alibaba Hologres: A cloud-Native Service for Hybrid Serving/Analytical Processing》Hologres揭秘：首次公开！阿里巴巴云原生实时数仓核心技术揭秘Hologres揭秘：首次揭秘云原生Hologres存储引擎Hologres揭秘：Hologres高效率分布式查问引擎本期咱们将带来Hologres高性能原生减速查问MaxCompute的技术原理解析。 随着数据收集伎俩不断丰富，行业数据大量积攒，数据规模已增长到了传统软件行业无奈承载的海量数据（TB、PB、EB）级别，MaxCompute（原名ODPS）也因而应运而生，致力于批量结构化数据的存储和计算，提供海量数据仓库的解决方案及剖析建模服务，是一种疾速、齐全托管的EB级数据仓库解决方案。 Hologres在离线大数据场景上与MaxCompute人造无缝交融，无需数据导入导出就能实现减速查问MaxCompute，全兼容拜访各种MaxCompute文件格式，实现对PB级离线数据的毫秒级交互式剖析。而这所有的背地，都离不开Hologres背地的执行器SQE（S Query Engine），通过SQE实现对MaxCompute的Native拜访，而后再联合Hologres高性能分布式执行引擎HQE的解决，达到极致性能。 Hologres减速查问MaxCompute次要有以下几个劣势： 高性能：能够间接对MaxCompute数据减速查问，具备亚秒级响应的查问性能，在OLAP场景能够间接即席查问，满足绝大多数报表等剖析场景。低成本：MaxCompute通过数年的倒退，用户在MaxCompute上存储了大量数据，不须要冗余一份存储可间接进行拜访；另一方面用户能够只需将局部高性能场景的数据迁徙到SSD上，报表等剖析场景的数据能够存储在MaxCompute进一步降低成本。更高效：实现对MaxCompute的Native拜访，无需迁徙和导入数据，就能够高性能和全兼容的拜访各种MaxCompute文件格式，以及Hash/Range Clustered Table等简单表，升高用户的应用老本。SQE 架构介绍 如上图所示是SQE的整体架构，能够看出整个架构也是非常简单。MaxCompute的数据对立存储在Pangu，当Hologres执行一条Query去减速查问MaxCompute的数据时，在Hologres端： Hologres Frontend通过RPC向SQE Master申请获取Meta等相干信息。Hologres Blackhole 通过 RPC 向 SQEExecutor 申请获取具体的数据相干信息。SQE由两种角色的过程组成:SQE Master负责解决Meta相干的申请，次要负责获取表、分区元数据、鉴权以及文件分片等性能。SQE Executor作为SQE的外围，负责具体读取数据申请，波及Block Cache、预读取、UDF 解决、表达式下推解决、索引解决、Metric、Meter等等性能。MaxCompute表面引擎外围技术创新基于SQE的架构，能做到对MaxCompute的数据高性能减速查问，次要是基于以下技术创新劣势： 1）形象分布式表面 联合MaxCompute的分布式个性，Hologres形象了一个分布式的表面，来反对拜访MaxCompute分布式数据。目前可反对拜访跨集群的MaxCompute分布式盘古文件，并按MaxCompute计算集群就近读取。 2）和 MaxCompute Meta无缝互通，反对带版本的元数据缓存 SQE和MaxCompute 的 Meta 无缝互通，能够做到 Meta 和 Data 实时获取，反对通过Import Foreign Schema命令，主动同步MaxCompute的元数据到Hologres的表面，实现表面的主动创立，构造自动更新。 3）反对UDF/表达式下推 SQE 通过反对 UDF/表达式下推，来实现用户自定义的UDF计算；将表达式下推能够缩小无用的数据传输带来的开销，进一步晋升性能。 4）异步ORC Reader，异步prefetch 目前MaxCompute大部分数据为ORC格局，在Hologres V0.10及以上版本，Hologres更新了执行引擎，应用异步 Reader 进行更高效的异步读取，还反对异步prefetch，进一步升高读取提早；此外Hologres反对了 IO 合并、LazyRead、Lazy Decoding 等一些列的优化技术手段，来升高在 IO 在整个查问上的提早，以带来极致性能。 5）反对Block Cache 为了防止每次读数据都用IO到文件中取，SQE同样应用BlockCache把罕用和最近用的数据放在内存中，缩小不必要的IO，放慢读的性能。在同一个节点内，通过一致性Hash实现将雷同拜访的数据共享一个Block Cache。 比方在Scan 场景可带来2倍以上的性能晋升，大大晋升查问性能。 ...

简介：相比去年，国外 Serverless 的应用群体在迅速扩充，函数执行时长一直减少，应用形式也越加成熟，开发者工具也更佳凋谢。向幕前 作者 | 望宸 本文是对 Datadog 最新的一份 Serverless 报告的解读，欢送大家留言探讨。 每项新技术的产生和演进过程中，都会有他本人的拥趸，也会有持怀疑论者。Serverless 的美在于他能够尽可能的解放客户在基础设施上的投入，只需专一于本人的业务，让技术产生更多商业价值，同时，客户只须要真正为使用量付费，毋庸让计算资源常驻。 “Datadog 上一半的 AWS 客户应用了 Lambda，80% 的 AWS 容器客户应用了 Lambda。” 是的，这个数据来自 Datadog 去年的一份调研报告，主观反映了 Serverless 在海内市场的落地过程。一年之后，Datadog 公布了第二份 Serverless 调研报告，咱们来一起看看 Serverless 在海内的最新进展，这对于无论是曾经投入建设 Serverless，还是仍处于张望状态的决策者和使用者而言，兴许都能取得一些参考。 观点一：Lambda 的调用频率比两年前高 3.5 倍，运行时长达 900 小时 / 天Serverless 的应用深度如何来定义？自 2019 年以来，始终在应用 Lambda 的企业已大大提高了其使用率。均匀而言，到 2021 年初，这些公司每天调用函数的次数是两年前的 3.5 倍。此外，在同一组 Lambda 用户中，每家企业的性能均匀每天均匀运行达 900 个小时。 一般云服务器，是按服务器的租用配置和租用时长进行免费的，其中，租用配置是根据 vCPU 和内存定价。 而函数计算则不同，按应用过程中的调用次数和函数运行时长免费的。因而，调用次数和函数运行时长是掂量客户应用 Serverless 深度的指标。报告中未提供每天调用次数绝对值的信息，但咱们能够根据每天运行 900 小时运行时长的数据，对客户在 Serverless 的生产做一个区间预估。 以阿里云函数计算的免费规范来计算，应用预付费模式： 每 1 GB 计算力的实例运行 1 秒所需的费用是 0.00003167 元，以内存规格 1GB，每天运行 900 小时来计算，预计将生产 102.6 元，年度生产是 3.7 万，再搭上存储、网络、平安、数据库等其余云产品的生产，曾经是一个中型企业的云上收入了。此外，函数的调用次数所产生的费用通常不会太多，尤其是 Python 这类和 AI 建模相干的函数利用，阿里云函数计算每天调用 100 万次的费用是 13.3 元。 ...

简介：5月29日阿里云开发者大会上，阿里巴巴团体副总裁、阿里云数据库产品事业部负责人李飞飞演讲实录。一、浅谈云原生（一）云原生，是将来应用云的规范形式 我认为云原生是将来应用云的规范形式，云计算资源无处不在、取之不尽、用之不竭，不必关怀云资源在哪里、有多少。就像明天咱们应用自来水一样，没有⼈会费尽心思思考水从哪里来。 （二）阿里云全面引领云原生分布式数据库倒退方向阿里云在云原生数据库畛域做了多年的实际、尝试与摸索，与开发者一起成长。咱们认为接下来云原生数据库必须关注和倒退的畛域有以下五个： 1）云原生分布式 将云原生和分布式技术深度交融，将Share Nothing、Share Storage、Share Everything架构深度交融。 2）智能化 利用AI、机器学习的技术，让数据库系统可能实现主动驾驶的能力，让开发者能够更好地治理和应用数据库的服务，如主动调参、索引举荐、异样检测等。 3）平安可信 平安可信的能力非常重要，比如说如何确保数据是全链路的、加密的、平安的，在存储、传输、计算过程中都可能提供平安可信的能力。 4）在离线一体化 缩小数据链路，数据从在线解决、到在线剖析、到离线的存储，是否提供一体化的体验，让开发者能够更简略、更便捷地拜访和解决数据。 5）物联网多模 面对AIOT、物联网、车联网的蓬勃发展，是否打造一个面向开发者与利用的物联网多模的数据库。 以上是咱们认为接下来十分重要的五个方向，也正因为在这些方向的耕耘，阿里云在去年取得了Gartner寰球数据库领导者的冲破。 二、阿里云数据库 – 数据管理生命周期置信对于任何一个开发者而言，在数据层面最关怀的是数据管理生命周期。上面站在开发者的视角，论述数据的全链路生命周期到底是什么。 第一步是数据的生产和集成，在这一步如何更高效地做数据集成、数据荡涤、数据传输、数据备份。当做完这步当前，下一步是数据的实时处理，这外面就是咱们十分相熟的传统关系型数据库、在线交易、OLTP等。紧接着就是数据分析和发现，用户如何做数据脱敏、数据的血缘关系等。 以上就是数据管理的生命全周期，咱们在下面构建不同的解决方案，和开发者、合作伙伴一起面向利用、行业、客户去打造最终的Killer APP。 上面就从生命周期的各个阶段来论述一下咱们为开发者提供了哪些工具，开发者基于这些工具能够做哪些事件。 （一）数据生产与集成 数据生产与集成是数据的第一生命周期，就像新生儿一样，数据来到这个世界必须要经验采集，而后是存储和解决。 如上图所示，在这个过程中阿里云提供了DTS(Data Transmission Service)，反对17种以上不同的数据源，能够做实时增量或者全量的同步，让利用十分简洁地实现数据从多元异构的数据源到多元异构的指标端实时的数据同步。 DBS能够实现跨云的备份、云上云下数据备份的对立，让数据在多云多端之间无缝流动。 DMS(Database Management Service)能够帮忙用户做工作编排、数据分析、血统剖析等一系列事件。 以上形成了阿里云在数据生产和集成的根底能力。 （二）数据实时处理数据生产和集成之后是数据的实时处理。 作为开发者，咱们最关怀的就是确保在任何状况下，在线交易场景的利用永远在线、数据永远不失落，在这里咱们提供了不同的抉择。 1）云数据库 RDS：提供企业级数据库自治能力 首先，阿里云提供本人的云数据库RDS。 每个云厂商都有RDS，阿里云的RDS和其余RDS有什么不同呢？ 倒退到云原生数据库2.0，阿里云RDS最大的特点就是提供企业级的数据库自治能力(Autonomous Database Service)。 首先，通过Kubernetes构建一个云原生的管控平台，所有的管控能力都进行了微服务化和容器化部署，这样能够屏蔽底层多元异构的资源，为开发者提供一个云原生的开发环境和部署环境。 在这个下面，咱们利用AI和Machine Learning的技术，构建了主动驾驶数据库平台。为开发者提供了许多能力，比方主动压测，咱们能够主动生成压测数据，让它的工作负载与在实在环境简直一样，这样开发者能够更好地调测在线零碎。另外，咱们提供了索引举荐、参数调优等一系列自动化自治服务能力。 此外，困扰开发者的许多问题，比方在线利用运行速度变得很慢，线程池被打满等，通过DAS(Database Autonomy Service)能够帮忙开发者更快更好地发现与解决。 2）云原生关系型数据库 PolarDB 除了阿里云RDS之外，云原生数据库2.0最外围的能力之一就是云原生关系型数据库PolarDB。 为了让开发者可能更好地在PolarDB上开发利用，咱们确保PolarDB 100% 兼容 MySQL、100% 兼容 PostgreSQL、高度兼容 Oracle 语法，让开发者实现轻松上云。 很多企业和开发者有向寰球部署的需要，比方在线教育、游戏，须要咱们的利用可能就近服务用户，阿里云推出了寰球部署的能力，称为Global Database。这示意PolarDB能够实现跨AZ(Available Zone)的部署，实现RPO等于0，非常低的RTO。通过跨AZ的能力数据实时同步，能够实现用户在开发者的利用上就近拜访。 ...

简介：Docker 解决了单个容器的镜像化问题，而 sealer 通过把整个集群打包，实现了分布式软件的 Build Share Run。作者 | fanux.中弈 什么是集群镜像顾名思义，和操作系统 .iso 镜像或 Docker 镜像相似，集群镜像是用肯定的技术手段把整个集群的所有文件以肯定格局打成的一个资源包。 比照单机和集群会发现一些的乏味景象： 单机有计算、存储、网络等驱动；集群有 CNI/CSI/CRI 实现像是集群的驱动。单机有 ubuntu centos 操作系统；集群中能够把 Kubernetes 看成云操作系统。单机上能够运行 docker 容器或虚拟机；相当于一个运行的实例，集群上也有运行着 K8s 的实例。单机上有虚拟机镜像，docker 镜像；随着云计算技术的倒退，集群上也会形象出相似的镜像技术。以基于 Kubernetes 的集群镜像为例，外面蕴含了除操作系统以外的所有文件： docker 依赖的二进制与 systemd 配置、dockerd 配置，以及一个公有的容器镜像仓库。Kubernetes 外围组件二进制、容器镜像、kubelet system 配置等。利用须要用到的 yaml 配置或 helm chart，以及利用的容器镜像。其它脚本、配置与二进制工具等利用运行须要的所有依赖。同样，集群镜像运行时必定不是起一个容器或者装在一台机器上，而是这个镜像能够间接装置到多台服务器上或者间接对接到私有云的基础设施上。 sealer 介绍sealer是阿里巴巴开源的集群镜像的一个实现形式，我的项目地址：_https://github.com/alibaba/sealer_ Docker 解决了单个容器的镜像化问题，而 sealer 通过把整个集群打包，实现了分布式软件的 Build Share Run!!! 试想咱们要去交付一个 SaaS 利用，它依赖了 MySQL/ES/Redis 这些数据库和中间件，所有货色都在 Kubernetes 上进行编排，如果没有集群镜像时，要做如下操作： 找个工具去装置 K8s 集群helm install mysql es redis... 如果是离线环境可能还须要导入容器镜像kubectl apply yoursaas看似如同也没那么简单，但其实从整个我的项目交付的角度来说，以上操作是面向过程极易出错的。 当初如果提供另外一个形式，只需一条命令就可解决下面的问题，你会不会用？ ...

简介：通过云原生技术，真正为企业带来更多的业务价值，助力企业整体的业务翻新。作者：李小平 前天我加入了信通院的云原生产业大会，在会场上十分感叹，加入会议的企业十分多，并且来自于各行各业。我想起2019年的时候，我在搜索引擎上搜寻“云原生”这个词，那时的搜寻频率还比拟低，而2019年又是“云原生”在国内开始飞速发展的一年。而往年的云原生会场上，曾经有十分多的企业来加入，这些企业在技术、产品、生态中都在利用云原生，所以说，整个“云原生”曾经从最开始的技术变成了行业，当初倒退成了比拟大的产业，并且这个产业的规模每年以十分快的速度在增长。 在明天，可能有很多咨询机构、企业，或者是集体开发者都在解读“云原生”，兴许很多人对“云原生”都有比拟深刻的意识了。大家都能够认同的是，云原生必定与云无关，然而它扭转了什么，为企业带来什么价值呢？最外围的点应该是能够扭转企业的利用架构；还有一种可能是不扭转利用架构，只是把整个运维体系基于“云原生”进行重塑。但所有的这些，背地的目标都是为了减速企业的价值发明过程，简略的说，和制作企业改进生产线是一样的，外围点就是改进咱们作为软件企业的生产线。 阿里在云原生的实际从2006年就开始了。咱们在做云原生的过程中积攒了很多教训，咱们认为，明天云原生对于企业数字翻新次要提供5个方面价值： 一是资源弹性。弹性这个词大家很容易了解，实际上弹性有不同的层面。比如说基于虚拟机的弹性，提供的弹性能力是分钟级的，如果基于这些技术的利用是毫秒级的，那么分钟级只解决了资源弹性问题，整个利用高可用问题还须要进一步解决。如果说弹性到了利用的层面，到了毫秒级，高可用问题也失去肯定水平的解决。 除此以外，零碎的稳定性也是大家十分关注的方面。云原生就是把整个软件结构过程中非功能性个性拉进去放到云原生产品下来，帮忙利用开发从非功能性处理过程中解脱进去，更多的专一在功能性。同样的，云原生有很多工具理念，能够让咱们变得更好，整个软件开发从代码到上线的工夫大幅缩短。同样的，明天在基于云原生可观测性下面咱们会积攒十分多的数据，这些数据能够联合机器学习这些能力，帮忙咱们改善企业的用户体验。这些对于业务来讲会带来比拟大的价值。 阿里云原生的实际历程明天，云原生在CNCF、国内相干的开源、还有三方组织的推动下，能够让一家企业在做技术选型的时候有十分多的选项。大家通常会面临一个问题，在这么多抉择外面，要真正达到生产可用的目标到底选谁？特地是当咱们的业务须要在十分短的工夫内里就上线，在业务高速倒退的阶段，咱们应该选什么样的架构，选什么样的开源凋谢的产品，这个是摆在宽广企业技术决策者以及架构师背后的难题。 在云原生畛域中，阿里云是绝对比拟早开始做自研的。从2006年到2009年互联网的中间件开始倒退，到阿里云正式成立，整个过程中咱们通过云原生解决很多业务问题。通过利用云原生相干技术，从晚期很好地反对了淘宝的高速倒退，到了2015年当前很好地反对了阿里的中台建设，以及到明天随着阿里巴巴整个生产零碎、外围零碎全副100%上云，这个过程中咱们使用的云原生技术，像容器技术、微服务技术支持的规模都是百万级以上。 相干调研显示，这样的云原生落地规模在寰球范畴内都是十分当先的。实际上，对于很多企业来讲，兴许用不到这些规模，然而阿里通过解决这样的大规模下的性能、稳定性问题，积攒了十分多的硬核技术，最终可能把这些技术转变成了产品，通过阿里云对外输入，服务于各行各业的广大客户。 咱们认为，云原生对于整个软件的扭转，或者对软件公司的开发流程的扭转是十分十分粗浅的。首先K8s曾经变成了软件交付的规范界面，它扭转的不止是运维，而是从CICD到后续公布上线整个生产链条。因为所有生产流程失去扭转，以及很多企业通过云原生技术重塑了软件架构，使得软件架构从传统架构变成了新的、咱们称之为现代化的利用架构，因而云原生能够通过这种生产工具的改进进一步扭转企业的生产关系，最终影响企业，使得企业在软件开发过程中失去了极大的提速。 阿里云在云原生实际过程中，积攒了很强的技术竞争力，体现在这些方面： 一，咱们有十分多的技术解决“云原生”畛域外面的稳定性问题、可靠性问题，大规模下的高并发问题等。同时，咱们会把所有的这些技术通过开源凋谢的模式输入，因为咱们晓得在云原生的世界，企业须要的是开源凋谢的技术，而不是被像阿里这样独自一个厂商所锁定的技术。这个过程中咱们基于开源凋谢技术标准积攒了很多产品的硬核能力。在产品上，除了大家看到的基于云原生利用架构里，还包含云原生数据库、云原生大数据等。 在云原生相干的畛域有比拟多的测评，在这些测评里，例如阿里云容器产品ACK，在去年Gartner评测中拿到满分，寰球厂商中只有两个厂商拿到满分，阿里云是其中之一。新兴的计算状态畛域中，往年阿里云进入 Forrester FaaS 领导者象限，函数计算取得了寰球 FaaS 产品最高分。 在可观测性里，阿里云代表国内云厂商进入Gartner APM象限。所有这些三方评估从另外一个层面反映了阿里云产品的能力。容器架构上咱们基于开源凋谢的 K8s 的技术体系，基于阿里云的硬件做深度的优化，在比拟多的畛域和场景里为宽广 K8s 利用提供服务。咱们把在K8s集群外面超大规模集群治理的能力输入到 ACK 产品外面，使得阿里云的客户在治理集群的时候，能够解脱大规模集群的治理复杂性问题。 比方完满日记，作为美妆行业的独角兽公司，他们的业务倒退速度十分快，但在业务疾速倒退过程中，他们面临的问题就是在大促的场景中怎么更好地预留资源，以及在大促时怎么样比拟好地解决新上线的一些性能，一些需要的稳定性问题。在这个过程中，他们利用PTS作为压测，所有利用跑在ACK平台下面，通过压测模仿大促的流量，从而可能把整个大促从须要投入较大的状态晋升到具备能够常态化的做大促压测的能力，也通过这个能力使得零碎稳定性相干问题失去疾速收敛。 云原生中间件从微服务、音讯到各种利用工具以外，依据企业常见的IT场景，云原生中间件也提供了很多解决方案。阿里云中间件诞生于团体内的大规模调用场景，同时兼容开源，并且融入了更多产品能力，例如在整个大促过程中体现优异的可观测性、高可用能力等，都属于云原生中间件产品体系。 同样在中间件畛域里，咱们也和较多企业客户有相应的单干。畅捷通是一家做Saas的企业，迄今曾经为超过四百万的小微企业做了云管。ToB类型的利用复杂度较高，最大的问题就是整个软件的公布频率是十分快的，怎么样在高频软件公布上面可能比拟好的解决软件的各种BUG，或者解决设计上的有余带来的稳定性的问题，这是在后期探讨过程中畅捷通提出来的关注点。通过利用云原生中间件，不仅解决了整个利用的可观测性问题，并且让利用具备360度无死角可观测能力，通过利用探测可能疾速发现在整个压测过程中各种可能的不稳固危险，从而使得相应危险失去疾速的收敛。 Serverless很多学术机构在Serverless畛域深入研究，咱们预感Serverless极有可能会成为下一代支流技术趋势。阿里云在Serverless畛域里做到业界当先的毫秒级计费，以及在整个阿里云底层做深度优化，使客户的利用真正达到了智能的弹性、极致的运维和大幅晋升开发效率。阿里云也和许多企业客户达成深度单干，进行Serverless落地实际，通过帮忙客户将利用迁到Serverless技术体系上，达到比拟快的利用部署；同时，把利用的稳定性问题、运维都委托给Serverless这样的云产品去解决。 解决方案云原生在疾速倒退过程中，只有通过一直的技术创新、产品翻新，才有可能使得云原生技术更好的服务于宽广的企业客户。明天，阿里云对外公布四大解决方案：全链路压测解决方案、异地多活解决方案、资源混部解决方案、可观测解决方案。这些解决方案能够高效地解决在传统畛域里还没有很好解决的问题。比方全链路压测，大家都晓得全链路压测是个好货色，比拟大的问题是在利用压测过程中使利用革新最小，甚至不要做革新，所以这次阿里云降级的全链路压测就能够帮忙企业应用解决这些问题。 明天企业在不断深入地应用云当前，不论私有云还是专有云上，都会碰到整体 CPU 利用率不高的问题，混部就使得各种离线工作和在线工作能够部署在一起，各自享受资源调度的劣势，使得整体机房的CPU利用率失去比拟大的晋升。在这个过程中要解决混部之后带来的稳定性问题、资源占用问题。阿里是比拟早地利用大规模的混部，像撑持电商双十一的云原生产品。明天咱们也是把混部能力变成解决方案对外输入。 大家都晓得，阿里是比拟早实现了单元化的架构，通过单元化架构实现了多活。明天咱们把单元化整体的架构能力作为多活的解决方案，同时，这样的多活不仅能够反对自有数据中心、公有云的场景，也可能反对私有云和混合云场景实现整个利用的多活。 可观测性始终都是大家特地关注的话题，因为通过可观测性使得咱们能够被动发现在零碎的运行过程中可能呈现的各类危险。明天，阿里云降级的可观测性计划包含从拨测到各种前端的性能监控，始终延长到后端利用，甚至延长到云服务里。 产品升级除了解决方案的翻新以外，咱们在相应的云原生产品下面也做了比拟多的降级。容器 ACK备份容灾核心全新公布，为容器用户提供集群、利用和数据的完整性爱护： 1、反对主动剖析利用依赖的元数据及存储，实现秒级创立利用+数据的一致性快照； 2、反对创立备份打算，主动按预设工夫点创立备份； 3、齐全兼容Kubernetes，并反对多集群、多地区、跨数据中心进行备份和复原。 容器镜像ACR公布企业级 Serverless 构建服务，大幅晋升云原生制品的构建效率和体验： 1、反对多操作系统、多架构镜像的矩阵构建，反对大规模并发工作构建。 2、反对多级缓存的构建减速，均匀构建提速 30%。 3、反对主动构建减速镜像，实现 AI 等大镜像秒级按需加载，均匀启动工夫缩小 60 %。 在微服务畛域，越来越多的利用思考采纳服务网格技术。用户心愿服务网格在开源技术之上有更强的微服务治理能力，因而阿里云推出专业版 ASM Pro，具备加强多协定反对，晋升动静扩大能力，精细化服务治理，欠缺零信赖平安体系。专业版相比去年公布的一般版，在性能及规模上均有显著晋升，与开源的差异化竞争力进一步加强，升高用户在生产环境落地服务网格的门槛。 Gartner预测，将来事件驱动将成为业务开发的支流架构。企业客户上云过程中对于低代码、无服务器弹性利用架构，如何轻量集成泛滥异构云服务的数据流有着明确的痛点和诉求。基于此趋势，阿里云公布了事件总线 EventBridge这款产品，其指标在于对立阿里云云服务、第三方 SaaS 厂商、用户自定义的事件规范，通过规范、弹性、轻量的外围能力帮忙用户疾速低成本获取并解决海量事件，驱动业务开发。 在过来的一段时间，咱们对 EventBridge的产品能力做了进一步的裁减和降级： 在事件生态集成的规模方面，新增 60+ 云产品官网事件源接入，涵盖计算、存储、网络、数据库等支流云产品；在事件触达和解决形式上，内置了十多种过滤匹配转换逻辑，并且新增了跨网络、跨地区、跨账号等深度触达形式，不便企业大客户做深层次的平安、隔离等定制；在此基础上，阿里云 EventBridge首次推出事件驱动利用核心，内置常见的事件驱动利用模板，用户无需代码和部署即可简略配置实现常见的事件 ETL 解决、数据同步等场景性能。 ...

简介：本文探讨了如何让技术一号位可能从实践上、以宏观的视角看清日常工作非亲非故的事物的倒退法则，从而为适应法则办事或者创造条件突破法则提供理论依据。往期技术一号位方法论系列文章： 「技术人生」第1篇：什么是技术一号位？ 「技术人生」第2篇：学会剖析事物的实质 「技术人生」第3篇：解决问题的法则总结 本期文章篇幅较长，倡议珍藏浏览。 背景本期文章将接上期《「技术人生」第3篇：解决问题的法则总结》持续探讨技术、业务、组织的个别法则及应答策略。须要留神的是，以下内容为集体实际后果的总结和剖析，受限于集体能力和教训无限，在形容法则的过程中，可能会存在维度的缺失；或者以后形容的法则所波及的维度并不是某些读者认知中的重点，因为事物不同的维度在不同角色和级别的人的认知中重要水平不同，即：PD和研发对于同一件事件的侧重点不同；P6到P11对于同一件事件，很大概率看重的侧重点不同，咱们特地欢送不同档次的同学分享你眼中的法则进去指引其他人实际。 而对于明天本文接下来要探讨的内容，须要大家辩证地去对待，并且在探讨初始须要从新对齐以后事物的探讨范畴：以后对组织、业务和技术的法则的探讨，限定在“技术团队leader率领研发团队负责某个业务或负责某个业务的一部分”的状况下，“技术”一词指代研发人员应用的信息化技术；“业务”一词指代研发人员应用信息化技术解决的问题域的统称，“组织”一词指代技术团队 Leader 率领的团队（可能是跨团队的组织）。 同时依然须要留神的是： 上述范畴中提到的组织、技术、业务没有加上“规模”相干的限度，能够了解为，任何规模都合乎上面探讨的法则，即咱们探讨的是个别法则。同时，不同规模，即团队规模、业务规模、技术深度实质上都是非凡条件，非凡条件的存在可能会触发非凡的法则，然而还是那句话，非凡法则存在并不影响对个别法则的探讨。并且受限于自己以后理论的实际状况，不同规模所触发的非凡法则并没有全副都直观感触过（实际缺失），也没有看过相似的书籍（实践输出缺失），所以不在本文内进行相干非凡法则的探讨。不排除将来有了更多的实际会来欠缺，同时更欢送有实践经验的人整顿总结成法则分享进去。 上述范畴中提到的剖析问题的主体是技术 leader，所以对于其余角色类型的同学而言，探讨之后造成的论断须要辩证地去了解，可能有很大部分都是相通的（留神不是雷同，而是相通，象征能够互相借鉴），然而同时也有一部分是不实用的，是和探讨的主体自身的特殊性相干的。而这种特殊性对于其余类型的角色并非没有意义，恰恰相反，这可能是比拟宏观地、间接地理解另外一种角色的十分无效的路径。即经营一号位或产品一号位或业务一号位能够看到技术一号位所负责的事件中的个别法则和非凡法则，而个别法则大概率相通，而理解非凡法则是了解彼此差异性的在宏观层面的认知。 业务的倒退法则及应答策略业务的倒退法则业务的生命周期如下图所示： 看图时，须要留神以下内容： 图中的曲线仅用于定性分析，非定量分析的准确图表，因而生命周期中各阶段的长度、和业务规模、利润规模的比例关系也都是示意型的，而非准确的比例关系。不同的业务，生命周期长短可能不同，各阶段继续的工夫也不同，业务方冀望各阶段持续时间长短也不同，须要具体问题具体分析。不同的业务，利润呈现的工夫和业务生命周期的阶段对应关系不同，利润规模和生命周期各阶段对应关系也不同，须要具体问题具体分析。 在此基础上，咱们简略用语言讲清楚业务倒退过程是怎么的： 启动期启动期能够粗略分为立项期和验证期。 立项期个别都是业务侧如PD或者经营发动，要做很多事件，例如围绕业务产生的价值是什么、指标客户是哪些、如何交付给客户、如何收取对应的费用继而维持业务运行上来，这个过程往往还须要联合大环境的要求补充更多细节，即以后事物的主要矛盾次要矛盾的剖析解决要合乎大环境的主次矛盾，即以后事物倒退法则遵循于事物所属大环境的倒退法则，因而须要联合组织策略、组织价值、业务所属大业务的战略目标等一系列大环境的要求来实现立项信息的筹备。 如果持续探讨，就会波及到这个探讨事物的实质剖析，咱们前面有精力的状况下会新开文章去剖析，本篇内容不再开展。这个阶段的次要作用就是通过正当的业务模式设计拉通各方对新业务的认知，获取组织的反对。优良的技术一号位会在这个阶段就染指进来，为业务发起者，通常是业务一号位，提供必须的技术视角的剖析和反对。 验证期个别是在立项通过后。次要是通过疾速的产品原型的实现，证实业务模式是行得通的，证实业务或产品是能解决客户问题，并且指标客户群体的客户代表是违心为这种产品付费的。这个阶段个别会投入大量的研发人员来做对应的信息系统来撑持业务的运行。研发团队个别从这个阶段开始做深度染指，并且相较其余角色的团队而言，研发团队在该阶段是配角。 发展期当启动期内实现了价值证实之后，接下来的重点就是如何将单个客户验证的业务模式疾速地规模化复制到更多的客户场景中，从而可能让业务在肯定工夫内实现业务规模的暴发。研发团队在这个阶段会次要解决零碎齐备性的问题，因为波及到越多的客户，新的共性的场景就会越多，为了承接规模化的用户而须要补充对应的业务场景的撑持。这些补充的业务场景，往往是技术系统核心畛域的补充以及撑持。 同时，这个阶段的配角不再是研发团队，意味着研发团队的体现逐渐从次要口头方逐渐转变到幕后成为根底参与方，而其余团队如经营、PD、销售、客服等团队会独特入场互相协同形成以后阶段的配角。所以研发团队除了反对客户自身的业务需要外，还承当着业务上下游合作角色的需要的信息化工作，这一点往往是老手技术一号位可能会漠视的点。 平台期当业务通过规模化复制推广造成肯定规模当前，增长会逐渐受限于指标客户群体规模，规模增长达到下限，逐渐趋于平缓，同时利润曲线也应该在此阶段之前转正并且在以后阶段达到最大。这个阶段谋求的不再是规模化增长，而是开始持续谋求利润的最大化，降本提效往往变成该阶段的主旋律，而很多业务环节和参与方也往往会在“降本”提出当前，呈现较多的矛盾，呈现较多的问题，实质上是之前的几个业务阶段中留下的隐患，即：为了达到业务指标而采纳了看似过后荒诞不经然而实际上对整体无害的形式。 这个问题看似是短期利益和长期利益的抵触，然而对于技术一号位而言，须要寻找既能满足长期利益又能兼顾短期利益的计划，并且肯定是以长期利益为宗旨的，作为次要做事准则的，而不能反过来。其余的业务参与方应该放弃同样的认知，并以之作为实际行动准则。 业务进入平台期之后，随着整个业务进入成熟周期，很多流程逐步完善，组织撑持逐步形成体系，这套配套的组织和流程能让业务持续安稳地倒退上来，并且尽可能维持成熟期的长度，然而同样也会带来新的问题，即组织僵化后，业务对市场、客户的变动的感知敏感度降落；针对客户、市场变动的决策被提早或者阻滞；最终后果就是业务当初产生的价值不再可能满足目标群体的要求，如果不做任何调整和干涉的话，业务进入衰退期是必然的。这个阶段，业务和技术都不是破局的要害，而是组织自身。 衰退期业务进入衰退期没啥好说的，技术团队须要思考的一个问题就是，业务经验残缺的生命周期而做没了是自然规律，那么对应的技术是否也须要随着业务的沦亡而沦亡？如果技术和业务耦合度太高，那么业务沦亡天然会株连技术，而导致后续新的业务无奈利用起来。 所以不管从哪个方面思考，都须要在技术设计和实现过程中，将技术体系进行系统性的、结构性的分层，底层的通用技术和通用的业务服务自身要做到业务无关，而业务相干的局部要构建成通用的业务畛域，确保业务变动当前，畛域依然是可用的，因为业务畛域自身是业务内核的反馈，只对业务实质相干的事件负责；而最上层的和产品展现层相干的内容都束缚到最上层的业务利用中，业务利用中对产品的展现和交互负责，对场景化的技术需要负责。 沦亡期如果业务进入沦亡期没啥好说的，及时转身止损，投入正当的资源善后即可。 各阶段的主要矛盾次要矛盾剖析在整个业务发展过程中，不同阶段的主要矛盾不同，不同的矛盾须要用不同的形式解决。咱们这里只探讨最根本的状况，为的是寻找法则。在理论业务的发展过程中，很可能业务属于某个阶段，然而在其余条件的作用下，主要矛盾产生了变动，这一点并不意味着咱们明天探讨的内容没有意义，因为矛盾的普遍性和矛盾的特殊性自身都是客观存在的，不能因为特殊性而漠视普遍性，当然也不能因为理解了普遍性，就不再关注特殊性。 启动期：前半段有无是主要矛盾，业务价值证实是次要矛盾；后半段业务的价值证实是主要矛盾（业务是否可行），业务规模化倒退、大规模获取收益是次要矛盾。发展期：业务规模化复制从而高效发明商业价值是主要矛盾，业务老本管制和价值变现效率是次要矛盾。平台期：业务老本和价值变现效率是主要矛盾，其余问题是次要矛盾（组织等）。衰退期&沦亡期：业务进入平台期，如果不可能基于过来的业务求变求新适应新的市场环境，则业务很快会衰败，则业务的可继续倒退就成了业务的主要矛盾。各阶段的应答策略及如何突破法则3.1 从总体上看如何突破法则业务生命周期的各阶段并不是肯定必须要串行的，也不是有明确的界线的，所以对于某些业务，能够多阶段并行推开。 比方业务一号位能够从一开始就基于过来的业务教训和组织教训提供业务保障的流程和标准，在业务进入平台期之前即具备相干的组织保障能力；技术一号位能够在开始即构建良好的架构设计，关注业务特色，理解业务特色对技术架构的影响，也理解不同业务阶段对技术架构的影响，从而在起步阶段即实现整体设计，从而让架构设计具备前瞻性，同时基于理论状况逐步推进架构向终态的演进。简而言之，就是：既然晓得了前面哪些事件必须要干，那么在最开始的时候在解决主要矛盾的时候就棘手逐渐干掉，而不是非要重复地踏入业务倒逼技术架构扭转的圈子外面。 在生产力无限的状况下，能够减速某些阶段，压缩这些阶段继续的工夫，然而永远要晓得它是无奈跳过的。 作为业务一号位或者技术一号位，要晓得在不把握更高的生产力的状况下，业务每个生命周期都是不可跳过的，主观能动性不能让某个阶段凭空隐没，加人进来也不能让某个阶段凭空隐没，都只能是用资源老本来换工夫。要么就是压缩那些投入期的环节；要么就是缩短那些回报期的环节，然而无论如何不能扭转这些环节本来的生命周期。 所以当决策者发现主观能动性和砸人进去都不好使，都不能达到你想要的成果的时候，很大可能不是团队执行力不够强，而是做执行的人生产力不够高，至于为什么生产力不够高，是受到了生产关系的制约，还是自身在生产力方面的投入有余所以积攒无限，那就要具体问题具体分析了。 当然还有一种可能，就是决策者本人不晓得本人做的事件的客观规律是什么，主观认知上达不到这个高度，所以只能出于集体志愿和设想来提出不切实际、不符合规律的要求。当然，辩证地去看，即使是这种最极其的状况呈现了，也最终还是因为生产力不够先进，如果足够先进了，再夸大的要求、再不切实际的要求其实都能实现。 在生产力很先进的状况下，能够跳过某些阶段，或者连续某些阶段的持续时间，然而要关注高生产力带来的老本问题。 在生产力进步到肯定水平的时候，业务生命周期内的某些环节能够借助生产力跳过，而这种跳过并不是这个环节凭空隐没了，而是曾经被高级的生产力做掉了。例如能够利用成熟的中间件服务来解决分布式系统中的各种问题，而不须要反复从新做一遍。先进的生产力自身造成也是有其自有的生命周期和阶段的，在初步呈现阶段，先进生产力带来的各种老本必定是高的，甚至会高到无奈大规模推广，而随着先进生产力自身一直倒退，随着周围环境对先进生产力的适配，先进生产力的应用老本逐渐降落到正当的范畴内。因而在决定应用先进生产力影响业务生命周期的某些阶段的时候，须要关注投入的老本。 随着生产力的晋升，生命周期的每个阶段仍然能够持续细分为多个阶段，并且生产力越高，参加业务的各方能够管制和干涉的业务生命周期的粒度就会越细，能够管制的维度也越多。 如何了解这句话呢？首先要明确到底什么是生产力。生产力不是单纯地指技术人员把握的技术，而是以 “劳动者”——就是指人、“劳动资料”——就是指人应用的工具、“劳动对象”——就是指被人应用工具扭转的对象为因素，形成的概念。 所以生产力的晋升蕴含了人的晋升、人应用的工具（对于研发同学而言就是技术，对于PD或经营同学而言就是你们的工作方法论）的晋升。所以当人变得更强、工具变得更先进当前，能够革新的对象的粒度就越小，能够革新的对象的维度也就越多。 这是普世的个别法则，想想物理上化学上随着生产力的晋升人类能够革新的对象的维度和粒度是如何演变的。而这个法则在业务上的体现就是技术能力更强、PD经营方法论更先进更适宜业务的团队，可能感知并管制业务的更多的维度，业务的倒退周期也会拆解地更细。这一点其实是最和咱们日常工作最为非亲非故的一个法则。 咱们能够利用这个法则来针对“生产力不够先进的业务”构建构造上的劣势，例如在业务的“启动期”，生产力落后的一方在解决零碎有无问题时，而生产力先进的一方曾经同时在着手解决塑造品牌形象等问题。 这些问题看起来不是主要矛盾甚至都算不上次要矛盾的维度的事件，之所以在同样的业务倒退阶段，两种团队解决的问题齐全不一样，起因就是在于生产力的差别，即：落后的一方在以后阶段解决骨干问题时，先进的一方曾经解决了主要矛盾并实现了多轮“由主到次”的解决过程，而每一轮“由主到次”的过程，都是拓宽问题维度、拆分问题粒度的过程。这种劣势是结构性的，比工夫上发力更早而造成的后手劣势更高级，也更难被追上。同样的，这个法则也会在技术上同样起到作用，上面在探讨技术的个别法则的时候，会提到这个法则的具体体现。 3.2 从具体的倒退阶段上看整体应答策略启动期：尽可能利用现有积攒或与三方单干减速或跳过启动期。发展期：具体问题具体分析，与非凡法则无关。平台期：做好孵化新业务的技术筹备和业务筹备，防止业务进入衰退期当前组织随着业务沦亡而价值升高。沦亡期：利用转型或孵化新业务形成第二业务曲线，从而在宏观上看到以后组织的业务规模没有产生消退。4 从整个业务倒退的法则来看，技术一号位须要具备哪些能力从业务倒退法则来看，技术一号位的能力大多数和做业务相干，同时和宏观的技术架构及落地把控能力相干，具体如下： 剖析业务实质的能力，即能看清业务外部主要矛盾次要矛盾，能依据业务外部和外部环境的互相关联和相互影响来判断业务将来的发展趋势。剖析业务各参与方的外围利益诉求，可能正当利用商业模式尽可能多的均衡各方利益诉求，并从技术零碎上针对这种业务模式给与反对。剖析业务各参与方的外围利益诉求，可能应用指标别离体现各方的外围利益诉求，并且可能以体系化的维度将指标拆解，防止看问题的片面化；同时可能分阶段理清不同阶段的重点指标并在技术支持上予以歪斜，防止看问题动态化。在业务初期，可能联合业务的问题域，实现正当的业务领域建模；并且联合市场调研及业务发展趋势，正当设计零碎架构，体现出架构的前瞻性和扩展性。同时要开始做技术生产力上的长线投入，借短期业务需要落地长期技术布局。在业务中期，逐步完善业务撑持维度，全方位构建支撑体系。将支撑体系解决方案化，并且将业务撑持解决方案跨业务复用。同时利用业务初期投入的生产力的晋升，来推动业务倒退。在业务末期，可能实现技术侧的积淀，并且有能力孵化出新的技术产品。技术的演进法则及对应的应答策略 对于技术一号位而言，技术畛域是本职畛域，探讨技术畛域的法则时，要充沛联合组织、业务对技术的影响来谈。因为组织特色、业务特色独特决定了技术特色。在咱们开始谈个别法则时，先把“技术”这两个字讲清楚，不是要讲概念，而是要讲这两个字在不同语境下的侧重点，而后别离从不同的视角来探讨他们具备的法则。 咱们常见的研发过程分类来看，一种是业务研发过程，一种是技术研发过程。两者在某个层面恪守同样的个别法则，同时也因为各自受生产对象的不同而别离有“各自的个别法则”。留神，这里讲“各自个别法则”是指探讨范畴别离限定在各自的话题之内，而在更大的技术范畴上看，它们则是非凡法则。 为了能清晰地讲清楚业务研发过程中的技术和技术研发过程中的技术到底有什么个别法则，咱们先明确二者之间的辩证关系，对立大家的认知，为前面的探讨扫清阻碍。 从实质上讲，所有的研发过程都是业务研发过程，技术研发过程只是业务研发过程的一种非凡状况。业务研发过程服务的对象，是客户的业务人员，要解决的问题域集中在宽泛的客户业务畛域上；技术研发过程服务的对象，是客户的技术人员（请辩证地、狭义地了解客户，不要狭窄的了解客户二字），要解决的问题域集中在狭窄的技术畛域内。即：业务研发过程的内核是业务问题，技术研发过程的内核是技术问题，而技术问题是一种非凡的业务问题。 业务研发中的技术解决的对象是个别的客户业务需要；技术研发中的技术解决的对象是非凡的技术需要。技术研发过程中的技术的特殊性在于需要不是间接来源于客户在业务发展过程遇到的业务问题，而是来源于客户在业务发展过程中遇到的非凡畛域的、业余的技术问题。 技术研发过程中的技术的一般性在于不论需要从哪来，需要类型是什么，需要有什么特色，都属于狭义的业务需要，因而技术研发畛域中的技术也同样恪守业务开发畛域中的技术所恪守的个别法则。 业务研发过程和技术研发过程在肯定的条件下和非凡的阶段是会互相转换的：业务研发过程一直由主到次地解决问题，最终问题的畛域会聚焦在繁多技术问题上，变成技术研发过程；而技术研发过程一直由主到次地解决问题，最终会在进行对外价值传递时变成业务研发过程。所以业务研发过程的次要问题是对外传递业务价值，主要问题是技术在某些畛域的先进性；而技术研发过程恰恰相反，其次要问题是在以后技术畛域的先进性，其次才是自身价值的对外传递，因为其价值自身是基于它本身的先进性的。这就是业务研发和技术研发的对立统一的过程，互相演变的过程。 当然这个演变过程不是产生在集体身上的，而是产生在组织身上的，并且随着这个过程的演变，组织外部也会分化演变，即：业务研发团队外部最终会呈现专门做技术攻坚的小团队；技术研发团队外部也最终会呈现专门做业务产品的小团队；这一演变法则，为所有研发人员抉择团队提供了宏观的指引，要辩证地对待做业务和做技术，如果想做技术，在业务团队一样能做；如果想做业务，在技术团队也一样能够；问题就在于你集体是否能看到以后组织的技术、业务演变趋势，机会往往就呈现在业务研发过程向技术研发过程转变的时候，或者技术研发过程向业务研发过程转变的时候。 业务需要对技术畛域的综合度、广度的要求，形成了业务研发过程中的技术的特殊性；技术需要对技术畛域的业余度、深度的要求，形成了技术研发中的技术的特殊性。 对以上内容的认知对齐当前，咱们就能够别离探讨业务研发过程中的技术有什么样的个别法则、技术研发过程中的技术有什么个别法则了。 1 技术的演进法则1.1 业务研发过程中的技术的法则受业务复杂度和业务生命周期的影响，业务研发过程中的技术整体出现模型简单、反对维度多的特色，因而“简单业务模型的畛域设计”、“横跨多个业务生命周期的技术架构演进”、“多维度全方位撑持、保障、驱动业务倒退”是三个显著的特点。 从单个业务生命周期来看，业务研发过程波及到的技术从繁多维度向多维度演变；除了要应用技术实现业务的数字化，还须要从研发效力、经营效力、稳定性建设、业务危险管制、财税法撑持等方面进行技术上的撑持（这些撑持，很多都是业务上下游参与方不感知的），随着业务逐渐进入成熟期，利用从单体利用向微服务转化；技术的发展趋势，从简略的“把业务跑起来”，逐步形成全方位撑持业务倒退的技术解决方案。技术自身也从满足“有无问题”的粗暴模式，逐渐演进到解决“降本提效问题”的精密模式，这是一个由主到次的过程，也是生产力晋升的一个过程。这就是业务研发过程中的个别法则。 如果一个研发团队同时负责多个业务，那么在做业务的过程中，逐渐会造成一些多个业务都会复用到的业务服务，这些业务服务畛域绝对独立，性能通用，各种业务都须要用到，最终逐步形成业务中间件。例如文件服务（基于OSS封装或其余存储服务封装）、在线签约服务、权限服务、音讯核心、待办核心等等。这个过程实质上就是业务研发过程中，技术“从单维度利用演变为多维度的解决方案”的根底上，持续从“单业务实用演变为多业务复用”的过程。 如果一个研发团队或技术一号位先后负责多个业务，那么某个业务自身的畛域常识不再那么重要，“如何在没有任何业务背景和教训的前提下实现简单业务领域建模”变成了技术一号位须要重点构建的外围能力之一。因而业务研发过程中，对于业务建模的方法论是泛滥技术中的一个十分重要的维度，特地是对于撑持多个不同业务的人而言，该维度的能力是外围能力，是区别于技术研发人员的外围差别点之一。当然因为业务研发过程和技术研发过程会有转换，所以不同状况下的外围维度会发生变化，须要具体问题具体分析。 以上提到的法则是和组织的生命周期相干的，组织稳固，就能沿着单个业务倒退的生命周期实现技术从单维度利用到多维度利用的积攒；组织有能力承接多个业务，那么就会自然而然地走上解决方案复用的路线，而解决方案的复用带来的益处就是生产力晋升当前反哺业务，可能减速业务的某些阶段的倒退。同时，要看到技术演进的过程和其宿主——即技术人员所在团队无关，所以A组织具备了什么样的能力，不代表B组织也会具备同样的能力，如何拉通各组织之间的生产力，在技术的多组织复用的根底上，确保各组织的创新性和独立性，是最顶层的技术一号位的外围命题之一。 不同于技术产品，很少有团队能走完业务研发过程中的技术演进过程。往往是成熟业务的团队才可能走残缺个过程。例如淘系的星环目前就是处于整个过程的比拟靠后的阶段。那么再往后还有么？再往后，就会持续遵循事物演变的法则，以后的主次矛盾解决当前，新的主次矛盾会呈现，所以随着资源和工夫的继续投入，过来不是骨干的问题，会在当初成为骨干问题被解决，随着问题域的一直细分，技术畛域也会随之一直聚焦，最终演变为技术研发过程。所以其实星环是从业务研发过程中演进或孵化进去的技术产品。这一点（业务研发过程和技术研发过程的互相转变过程）在之前曾经讲过了，不再反复开展。 ...

简介：OceanBase实现OLAP和OLTP双重能力并行后，向数据管理畛域多模方向迈出第一步。近日，在数据库OceanBase3.0峰会上，OceanBase CEO杨冰发表首个时序数据库产品CeresDB正式商用。该数据库将为用户提供安全可靠的数据查问和存储管理服务，解决监控运维、物联网等场景中，工夫序列数据的高吞吐、横向扩大等难题。 这是OceanBase实现OLAP和OLTP双重能力并行后，向数据管理畛域多模方向迈出的第一步。 时序数据库全称为工夫序列数据库，次要用于治理和存储工夫序列数据（反映事物随工夫变动而变动的过程），其中物联网、工业物联网、监控运维等是时序数据常见的利用场景。而时序数据库可能解决这些物联网设施数据的高吞吐、高频次的写入存储需要。 此次公布的OceanBase 时序数据库（CeresDB），是基于 OceanBase 分布式存储引擎底座的时序数据库产品，用来治理和存储工夫序列数据，提供高性能读写、低成本存储、丰盛的多维查问和剖析能力等性能。无效解决海量规模时序数据的存储老本高，读写效率低的问题，同时具备程度扩大和异地容灾的能力，实用于物联网 IoT、运维监控、金融剖析等行业场景。 此外，CeresDB 在时序数据上采纳业界当先的时序压缩算法，做到了对实时数据靠近10倍的压缩率（无损压缩），并通过设计创新性的多层存储计划，别离实现了纯内存、非易失内存、磁盘以及近程存储的多级存储架构，为客户提供灵便的、高度可伸缩的部署架构计划。 “时序数据库CeresDB具备有限程度扩大和异地容灾的能力” OceanBase CEO杨冰示意，“将来，咱们将朝着时序HTAP交融以及schema less的方向继续演进，并提供更加丰盛的行业专属算子和算法能力，并联结生态搭档提供对应的行业解决方案，帮忙企业打造具备极致性能和丰盛多样的行业时序数据管理解决方案。” 据悉，OceanBase是蚂蚁自主研发的分布式数据库，经验过阿里超大规模业务场景、支付宝金融级场景以及双11等战斗的历练，并于2017年开始对外输入。目前该产品已在多家机构落地利用，包含中国工商银行、山东挪动、福建挪动、数字江西、中国石化、中华财险、人保衰弱、浙商证券、天津银行、西安银行、常熟农商行、东莞银行等。 11年倒退，OceanBase曾经成为世界领先的数据库产品。2019年和2020年间断刷新事务处理工作（TPC-C）基准测试世界纪录。 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

简介：在数据库OceanBase3.0峰会上，蚂蚁团体自主研发的分布式数据库OceanBase首次从技术、商业和生态三个维度对将来倒退策略进行了系统性论述。同时，OceanBase发表正式开源，并成立OceanBase开源社区，社区官网同步上线，300万行外围代码向社区凋谢。近日，在数据库OceanBase3.0峰会上，蚂蚁团体自主研发的分布式数据库OceanBase首次从技术、商业和生态三个维度对将来倒退策略进行了系统性论述。同时，OceanBase发表正式开源，并成立OceanBase开源社区，社区官网同步上线，300万行外围代码向社区凋谢。 将来三年专一外围分布式革新CEO杨冰示意，OceanBase将继续保持自研凋谢之路，在将来3年内，专一企业外围分布式革新。同时，发表开释科技红利，7月启动全新价格体系，公共云版本将推出价格更低的存算拆散版本。 此次推出的最新3.0版本产品，让OceanBase同时具备了在事务处理和数据分析两类工作的高性能能力，降级为一款反对 HTAP 混合负载的企业级分布式数据库。和过来相比，事务处理性能晋升50%，数据分析性能晋升10倍。将来，用户业务无论是事务型还是剖析型，只有一套零碎就能够应答数字化转型过程中“海量、实时、在线”的业务需要。 Gartner 认为， HTAP （Hybrid Transactional/Analytical Processing，即混合事务 / 剖析解决）数据库将成为数据库畛域的重要发展趋势，一个集成的数据平台将会减速数字化转型。 在各个领域深入数字化转型过程中， 外围零碎的分布式革新是十分要害的一环。过来一年的单干案例显示，随着自主研发分布式技术的逐渐成熟，一直利用、优化和欠缺，OceanBase帮忙客户进行外围零碎数字化革新时，在可靠性、可扩展性等方面的劣势越来越显著。 杨冰走漏，“在以后规模和技术红利根底上，咱们心愿以更低的价格与门槛，给予客户更强的数据库能力进行外围零碎的分布式革新。外围零碎革新不仅能让企业实现整体零碎齐全自主掌控。更能在业务稳定性、连续性不升高的前提下，撑持业务麻利，最初达到每单笔交易/每个账户老本降落的指标”。 开源300万行外围代码大会现场，CEO杨冰还发表自研数据库OceanBase正式开源，并成立OceanBase开源社区，社区官网同步上线。 据理解，开源曾经回升为OceanBase重要的技术策略。OceanBase数据库创始人阳振坤示意，蚂蚁自研数据库OceanBase致力于打造企业级开源数据库，同时与合作伙伴一起严密单干，疾速发行商业版本，满足行业客户对数据库高性能、高牢靠、交融解决的业务诉求。 据介绍，开发者在开源社区可能残缺应用OceanBase数据库内核。此次开源采纳业界通用Open Core模式。开源范畴蕴含数据库内核、分布式组件和接口驱动，并提供残缺的SQL引擎、事务引擎和存储引擎，反对多正本、分布式事务、高性能、扩大能力、故障复原、优化器、多活容灾、语法兼容等核心技术，开源300万行外围代码。 OceanBase采纳木兰公共协定 MulanPubL-2.0 版，协定容许所有社区参与者对代码进行自在批改、应用和援用。OceanBase社区同时成立了技术委员会，欢送所有开发者奉献代码和文档。 “越来越多优良的产品退出到开源社区，有利于我国开源生态的建设以及开源人才的造就。”北大计算机系传授、木兰开源许可证次要发起人周明辉示意，中国从开源社区中受害良多。目前咱们有更多的能力，那咱们就能够承当多一点的责任，让开源界、让世界更好。 阳振坤走漏，“心愿更多贡献者退出，独特构建一个可能交融多元化技术架构的企业级开源数据库社区。OceanBase开源版将于商业版独特演进，愿和寰球开发者、搭档独特演化出丰盛的数据处理产品，促成社区的凋敝。” 据悉，OceanBase是蚂蚁自主研发的分布式数据库，经验过阿里超大规模业务场景、支付宝金融级场景以及双11等战斗的历练，并于2017年开始对外输入。目前该产品已在多家机构落地利用，包含中国工商银行、山东挪动、福建挪动、数字江西、中国石化、中华财险、人保衰弱、浙商证券、天津银行、西安银行、常熟农商行、东莞银行等。 11年倒退，OceanBase曾经成为世界领先的数据库产品。2019年和2020年间断刷新事务处理工作（TPC-C）基准测试世界纪录。 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

简介：在云原生时代，充分利用边缘节点的计算和存储能力，联合冷热数据拆散实现高性价比的数据价值摸索曾经逐步成为 APM 畛域的支流。作者：夏明（涯海） 调用链记录了残缺的申请状态及流转信息，是一座微小的数据宝库。然而，其宏大的数据量带来的老本及性能问题是每个理论利用 Tracing 同学绕不开的难题。如何以最低的老本，按需记录最有价值的链路及其关联数据，是本文探讨的次要话题。外围关键词是：边缘计算 + 冷热数据拆散。如果你正面临全量存储调用链老本过高，而采样后查不到数据或图表不准等问题，请急躁读完本文，置信会给你带来一些启发。 边缘计算，记录更有价值的数据边缘计算，顾名思义就是在边缘节点进行数据计算，赶时髦的话也能够称之为“计算左移”。在网络带宽受限，传输开销与全局数据热点难以解决的背景下，边缘计算是寻求老本与价值均衡最优解的一种无效办法。 Tracing 畛域最罕用的边缘计算就是在用户过程内进行数据过滤和剖析。而在私有云环境，用户集群或专有网络外部的数据加工也属于边缘计算，这样能够节俭大量的公网传输开销，并扩散全局数据计算的压力。 此外，从数据层面看，边缘计算一方面能够筛选出更有价值的数据，另一方面能够通过加工提炼数据的深层价值，以最小的老本记录最有价值的数据。 筛选更有价值的数据链路数据的价值散布是不平均的。据不齐全统计，调用链的理论查问率小于百万分之一。全量存储数据不仅会造成微小的老本节约，也会显著影响整条数据链路的性能及稳定性。如下列举两种常见的筛选策略。 基于链路数据特色进行调用链采样上报（Tag-based Sampling）。比方错/慢调用全采，特定服务每秒前N次采样，特定业务场景自定义采样等。下图展现了阿里云 ARMS 自定义采样配置页面，用户能够依据本身须要自在定制存储策略，理论存储老本通常小于原始数据的 5%。 异样场景下主动保留关联数据现场。咱们在诊断问题根因时，除了调用链之外，还须要联合日志、异样堆栈、本地办法耗时、内存快照等关联信息进行综合判断。如果每一次申请的关联信息全都记录下来，大概率会造成零碎的解体。因而，是否通过边缘计算主动保留异样场景下的快照现场是掂量 Tracing 产品优劣的重要规范之一。如下图所示，阿里云 ARMS 产品提供了慢调用线程分析，内存异样 HeapDump等能力。 无论哪种筛选策略，其核心思想都是通过边缘节点的数据计算，抛弃无用或低价值数据，保留异样现场或满足特定条件的高价值数据。这种基于数据价值的选择性上报策略性价比远高于全量数据上报，将来可能会成为 Tracing 的支流趋势。 提炼数据价值除了数据筛选，在边缘节点进行数据加工，比方预聚合和压缩，同样能够在满足用户需要的前提下，无效节俭传输和存储老本。 预聚合统计：在客户端进行预聚合的最大益处，就是在不损失数据精度的同时大幅缩小数据上报量。比方，对调用链进行 1% 采样后，依然能够提供精准的服务概览/上下游等监控告警能力。数据压缩：对反复呈现的长文本（如异样堆栈，SQL 语句）进行压缩编码，也能够无效升高网络开销。联合非关键字段模糊化解决成果更佳。冷热数据拆散，低成本满足个性化的后聚合剖析需要边缘计算能够满足大部分预聚合剖析场景，然而无奈满足多样化的后聚合剖析需要，比方某个业务须要统计耗时大于3秒的接口及起源散布，这种个性化的后聚合剖析规定是无奈穷举的。而当咱们无奈事后定义剖析规定时，貌似就只能采纳老本极高的全量原始数据存储。难道就没有优化的空间么？答案是有的，接下来咱们就介绍一种低成本解决后聚合剖析问题的计划——冷热数据拆散。 冷热数据拆散计划简述冷热数据拆散的价值根底在于用户的查问行为满足工夫上的局部性原理。简略了解就是，最近的数据最常被查问，冷数据查问概率较小。例如，因为问题诊断的时效性，50% 以上的链路查问剖析产生在 30分钟内，7天之后的链路查问通常集中在错慢调用链。实践根底成立，接下来探讨如何实现冷热数据拆散。 首先，热数据存在时效性，如果只需记录最近一段时间内的热数据，对于存储空间的要求就会降落很多。另外，在私有云环境下，不同用户的数据人造具备隔离性。因而，在用户 VPC 外部的热数据计算和存储计划就具备更优的性价比。 其次，冷数据的查问具备指向性，能够通过不同的采样策略筛选出满足诊断需要的冷数据进行长久化存储。例如错慢采样，特定业务场景采样等。因为冷数据存储周期较长，对稳定性要求较高，能够思考在 Region 内对立治理。 综上所述，热数据存储周期短，成本低，但能够满足实时全量后聚合剖析需要；而冷数据通过精准采样后数据总量大幅降落，通常只有原始数据量的 1% ~10%，并能够满足大多数场景的诊断诉求。两相结合，实现了老本与体验的均衡最优解。国内外当先的 APM 产品，如 ARMS、Datadog、Lightstep 均采纳了冷热数据拆散的存储计划。 热数据实时全量分析链路明细数据蕴含了最残缺最丰盛的的调用信息，APM 畛域最罕用的服务面板、上下游依赖、利用拓扑等视图均是基于链路明细数据统计得出。基于链路明细数据的后聚合剖析能够依据用户个性化需要更无效的定位问题。然而，后聚合剖析的最大挑战是要基于全量数据进行统计，否则会呈现样本歪斜导致最终论断离理论相差甚远。 阿里云 ARMS 作为 2021 年 Gartner APM 魔力象限中国惟一入选云厂商，提供了 30分钟内热数据全量分析的能力，能够实现各种条件组合下的过滤与聚合，如下图所示： 冷数据长久化采样剖析全量调用链的长久化存储老本十分高，而前文提到 30分钟后调用链的理论查问率有余百万分之一，并且大多数的查问集中在错慢调用链，或满足特定业务特色的链路，置信常常排查链路问题的同学会有同感。因而，咱们应该只保留大量满足精准采样规定的调用链，从而极大的节俭冷数据长久化存储老本。 那么精准采样应该如何实现呢？业界罕用的办法次要分为头部采样（Head-based Sampling）和尾部采样（Tail-based Sampling）两种。头部采样个别在客户端 Agent 等边缘节点进行，例如依据接口服务进行限流采样或固定比例采样；而尾部采样通常基于全量热数据进行过滤，如错慢全采等。 ...

简介：本文会介绍 Kubernetes 可观测性零碎的构建，以及基于阿里云云产品实现 Kubernetes 可观测零碎构建的最佳实际。作者：佳旭 阿里云容器服务技术专家 引言Kubernetes 在生产环境利用的遍及度越来越广、复杂度越来越高，随之而来的稳定性保障挑战也越来越大。 如何构建全面深刻的可观测性架构和体系，是晋升零碎稳定性的要害之因素一。ACK将可观测性最佳实际进行积淀，以阿里云产品性能的能力对用户透出，可观测性工具和服务成为基础设施，赋能并帮忙用户应用产品性能，晋升用户 Kubernetes 集群的稳定性保障和应用体验。 本文会介绍 Kubernetes 可观测性零碎的构建，以及基于阿里云云产品实现 Kubernetes 可观测零碎构建的最佳实际。 Kubernetes 零碎的可观测性架构Kubernetes 零碎对于可观测性方面的挑战包含： K8s 零碎架构的复杂性。零碎包含管制面和数据面，各自蕴含多个互相通信的组件，管制面和数据间之间通过 kube-apiserver 进行桥接聚合。动态性。Pod、Service 等资源动态创建以及调配 IP，Pod 重建后也会调配新的资源和 IP，这就须要基于动静服务发现来获取监测对象。微服务架构。利用依照微服务架构分解成多个组件，每个组件正本数能够依据弹性进行主动或者人工控制。针对 Kubernetes 零碎可观测性的挑战，尤其在集群规模快速增长的状况下，高效牢靠的 Kubernetes 零碎可观测性能力，是零碎稳定性保障的基石。 那么，如何晋升建设生产环境下的 Kubernetes 零碎可观测性能力呢？ Kubernetes 零碎的可观测性计划包含指标、日志、链路追踪、K8s Event 事件、NPD 框架等形式。每种形式能够从不同维度透视 Kubernetes 零碎的状态和数据。在生产环境，咱们通常须要综合应用各种形式，有时候还要使用多种形式联动观测，造成欠缺平面的可观测性体系，进步对各种场景的覆盖度，进而晋升 Kubernetes 零碎的整体稳定性。上面会概述生产环境下对 K8s 零碎的可观测性解决方案。 指标（Metrics）Prometheus 是业界指标类数据采集计划的事实标准，是开源的零碎监测和报警框架，灵感源自 Google 的 Borgmon 监测零碎。2012 年，SoundCloud 的 Google 前员工发明了 Prometheus，并作为社区开源我的项目进行开发。2015 年，该我的项目正式公布。2016 年，Prometheus 退出 CNCF 云原生计算基金会。 Prometheus 具备以下个性： 多维的数据模型（基于工夫序列的 Key、Value 键值对）灵便的查问和聚合语言 PromQL提供本地存储和分布式存储通过基于 HTTP 的 Pull 模型采集工夫序列数据可利用 Pushgateway（Prometheus 的可选中间件）实现 Push 模式可通过动静服务发现或动态配置发现指标机器反对多种图表和数据大盘Prometheus 能够周期性采集组件裸露在 HTTP(s) 端点的/metrics 上面的指标数据，并存储到 TSDB，实现基于 PromQL 的查问和聚合性能。 ...

简介：背景自从五十年前关系型数据模型被创造进去后，凭借优良的表达能力和清晰易懂的个性让其很快在数据库市场中锋芒毕露，迅速占领市场，成为各行各业的支流数据存储系统。在这五十年内，数据库架构、表达方式、存储构造、优化器等方面都有了长足的倒退，然而索引构造的倒退绝对迟缓了一些，更多的倒退是基于现有的索引根底去优化查问优化器。倒退了三十年后进入互联网和挪动互联网时代，数据规模呈爆发式增长，随即产生了非关系型数据背景自从五十年前关系型数据模型被创造进去后，凭借优良的表达能力和清晰易懂的个性让其很快在数据库市场中锋芒毕露，迅速占领市场，成为各行各业的支流数据存储系统。在这五十年内，数据库架构、表达方式、存储构造、优化器等方面都有了长足的倒退，然而索引构造的倒退绝对迟缓了一些，更多的倒退是基于现有的索引根底去优化查问优化器。 倒退了三十年后进入互联网和挪动互联网时代，数据规模呈爆发式增长，随即产生了非关系型数据库（NoSQL），NoSQL 的呈现补充了原有数据库在规模上的有余，然而这些 NoSQL 的索引构造原理依然同传统关系数据库相似，都是基于原有表构造构建二级索引。 无论是关系型数据库的二级索引还是 NoSQL 数据库的二级索引根本都是基于原有表构造的主键列重排，这样都会在索引能力上存在短板：一是最左匹配准则的限度了索引性能，二是须要提前确定好查问列，并且将要查问列组合后构建多个二级索引，如果在查问时呈现了无奈匹配索引的状况则性能会大幅降落，于是就呈现了疾恶如仇的慢查问，慢查问会重大影响用户体验和数据库自身的稳定性。 为了解决上述问题，有一种架构是引入搜索引擎，比方 Elasticsearch 、Solr（衰退期） 或其余云搜寻零碎等，应用搜索引擎的倒排索引来反对读时索引：任意列的自由组合查问，还能反对地理位置查问、全文检索。因为搜索引擎是专门为查问优化的零碎，查问性能会更加稳固一些。然而这种做法也存在一些问题，甚至有些问题很多人都没有意识到： 数据的可靠性：对于数据库而言，保证数据不丢是最外围的要求，然而对于搜索引擎则不是，大部分搜索引擎都存在丢数据的问题。查问后果的残缺度：搜索引擎的外围指标是查问性能，所以会优先保障查问性能，而非数据残缺度，所以局部搜索引擎存在为了保障延时而提前停止查问申请的状况。性能的稳定性隐患：大部分开源产品或者商业产品，为了吸引客户所以最热衷的是不停出新性能，局部性能在小数据量级上没问题，然而数据量增多后，可能会有很重大的稳定性隐患，比方打爆内存，打爆CPU或者让整个集群卡死等等问题，最要害的是如果不是十分业余的专家，很难提前预估到这些隐患，最终都是在一次次的故障中缓缓摸索理解，更辣手的是永远都不晓得还有多少坑未踩过。运维的复杂度：搜寻畛域是一个专业性很强的畛域，尽管局部产品的易用性很好，然而对于运维人员的专业性要求很高，很多人摸索了几年还仅仅是入门，当遇到问题时依然无奈疾速定位并且解决，甚至都不晓得哪个环节出了问题（基本看不到更细粒度的监控指标也就无奈晓得到底哪个环节出了问题），而且也很难在业务上线前提前发现危险，最终的后果可能是两败俱伤：运维人员很累，业务的问题依然很多。架构的复杂度：为了让数据从数据库同步到搜索引擎，须要引入一个同步零碎，这样至多须要治理三个零碎，而且须要治理同步的状态和时效性，这个复杂度和费用都会减少不少。另一种计划是双写数据库和搜索引擎，然而这个外面要解决比较复杂的一致性问题。同时，研发须要读写两个不同的零碎。下面这种架构曾经意识到了传统数据库的有余，并且找到了一种解决办法，只是解决办法依然有很大有余。 这里为什么不更进一步，将搜索引擎的能力引入数据库系统中？如果这个能够，那么上述的问题就会迎刃而解，云消雾散。 基于上述的思路，阿里云历经十年自研的非关系型（NoSQL）结构化数据表存储服务 Tablestore 在三年前胜利引入了搜索引擎的外围能力：倒排索引、BKD 索引 等，将搜索引擎的能力齐全植入了 NoSQL 数据库中。 这个能力在表格存储（Tablestore）中称为：多元索引（SearchIndex）。 至此，表格存储具备了两大能力：宽表和多元索引，其中宽表引擎相似于 Bigtable，次要面向的是数据的高牢靠存储，解决的是数据规模和扩大问题，而多元索引解决的是数据的查问检索的效率和灵便问题。 以后表格存储的残缺架构和能力大图如下： 价值Tablestore 的多元索引绝对于传统计划，除了补救了上述说的数据库加搜索引擎计划中的所有毛病外，还在其余一些方面存在微小的劣势： 一个零碎，多种能力反对：既能提供数据库级别的数据可靠性，又能提供搜索引擎具备的丰盛查问能力。应用层架构更简略：数据存储和查问只须要一个零碎即可，运维、研发甚至是财务的工作都会更加简略。查问能力丰盛：反对十分丰盛的查问性能、排序和统计聚合等。能够满足绝大部分的在线查问和轻量级剖析场景的需要。性能更好：不论是存储还是查问性能，都要比业界开源产品更优，比方 Count 性能比业界最好的 Elasticsearch 还要快 10 倍以上。和 DLA 联合提供简单剖析能力：阿里云数据湖剖析产品 DLA 目前能够将大部分 SQL 的算子下推到多元索引中，能够大幅晋升 DLA 中剖析 SQL 的性能，以后 Tablestore 是 DLA 惟一能够下推 limit、agg、sort 等算子的数据系统，联合 DLA 就能够提供更加简单的剖析能力。ALL IN ONE 的价值：一份数据同时反对了在线写入查问、离线导入导出、轻量级剖析和基于 DLA 的残缺 SQL 剖析能力。这些能力在 Tablestore 中会做多重相应隔离，防止相互影响。因为是一个零碎，客户研发、运维和财务管理上都会更加简略。研发效率晋升：除了下面这些比拟显著的劣势外，还有一个很大的劣势是能够大幅提高研发效率：不再须要额定部署零碎，不再须要学习多种不同零碎的接口和行为，不在须要关注同步链路的提早，不在须要思考运维等等。从客户的反馈来看，应用多元索引后，一个根底性能的研发周期能够从一个月缩小到一周工夫，大幅提高产品上线的速度。性能和能力表格存储是阿里云重金打造的分布式 NoSQL 产品，外围指标是打造一款海量数据平台，能够反对在线、离线和轻量级剖析。心愿能基于 ALL IN ONE 的设计理念实现客户在大规模结构化数据存储和查问方面的一站式需要。 多元索引在表格存储产品中的外围定位是数据价值发现，提供了查问和剖析的能力： 查问能力以后多元索引在查问方面的能力比拟丰盛，没有传统数据库和各种其余 NoSQL 的最左匹配准则限度，只有建了索引的列就能任意列组合查问，应用体验上大幅晋升。 同时也反对了数组类型（Array）和相似 Json 的嵌套类型，能够更容易适配各种应用层的模型，研发效率会更高一些。 除此之外，还有一个传统数据库不具备的能力，那就是丰盛的分词能力和全文检索性能，全文检索性能反对依照相关性分数排序，或者依照任意列排序后果，其中相关性算法应用了 BM25 算法。 在以后挪动互联网、物联网和车联网疾速倒退的期间，不少利用或者业务中都须要地理位置查问，比方查问四周的人或者电子围栏的需要，这个时候就须要应用地理位置查问的性能，这个性能在多元索引中也有提供，在写入时指定列为 GeoPoint类型，而后查问的时候就能够应用丰盛的地理位置查问，而且地理位置查问能够和其余索引列一起查问或过滤，比方和工夫联合。 多元索引的查问能力根本具备了目前现存的最残缺的查问性能，因为是自研零碎，如果有新的业务场景或者新的查问需要，咱们的疾速研发能力也能够尽快让新性能推出。 实时剖析能力多元索引也为在线场景提供了轻量级的实时剖析的能力，次要实用在查问提早要求毫秒到秒级别的场景中。 反对根底统计聚合：Min、Max、Sum、Avg、Count、DinstinctCount、GroupBy 等。反对高级统计聚合：直方图统计、百分位统计等。咱们的局部轻量级剖析性能性能绝对于开源零碎有 10 倍以上的性能晋升。 更重要的是这些轻量级剖析相干的申请在外部执行的时候会和其余在线申请隔离开，不会影响在线申请的可用性。 如果某些场景须要查问总数或者分组等等，则能够间接应用多元索引，不必再引入其余零碎。 SQL 剖析能力有些场景中须要 SQL 剖析能力，然而不太在意工夫，分钟级别返回也能够承受，这个时候能够应用多元索引 + 阿里云数据湖剖析 DLA 实现残缺剖析能力。DLA 是一个 Severless 的剖析零碎，反对规范的 SQL 能力，能够将算子下推到底层的存储系统或者数据库的。以后表格存储的多元索引实现了 DLA SQL 中大部分算子，也是 Limit 、Sort、Min、Max、Sum、Avg、Count、DinstinctCount、GroupBy 等算子惟一能够下推到存储层的数据存储系统。 多元索引和 DLA 联合的剖析性能实用于秒级到分组级提早的简单剖析申请。而多元索引本身的轻量级剖析能力实用于毫秒到秒级提早的简答剖析场景。 更具体的 DLA 和多元索引的应用能够参考这篇文章《Tablestore计算下推》。 高并发导出能力在一些场景中，客户须要将满足条件的数据疾速的导出到内部零碎，做一些其余操作，比方设施数据导出后可能须要为这些设施发送告诉，待剖析数据导出到内部的计算零碎后做更负责的剖析解决和报表生成等。如果在导出前，在存储系统中就能过滤掉无用数据，疾速筛选出最终的数据汇合，那么性能和老本都会更加有劣势。 为了满足这类场景的需要，咱们研发了并发导出性能：ParallelScan。该接口具备下列三个根底能力： 反对残缺的查问性能：包含 Search 接口反对的所有 Query 性能。能够将无用的数据提前在存储层过滤掉，缩小要传输的数据量和老本，提供性能。高吞吐：线上最高能够反对 1000万行/秒的筛选导出。断点续传：如果在读取过程中呈现谬误，此时能够反对从出错的地位从新读取，具备断点续传能力。上述特色也让 ParallelScan 在下列场景中能够施展出最大的劣势： 设施核心： 有时候利用须要挑选出满足某些条件的设施或者App，为他们推送一些告诉或者降级信息，这个时候零碎须要反对任意条件的自由组合，也要反对疾速的从数据库中拉取出大量设施。计算零碎：比方 Spark、Presto、DLA 等计算零碎如果呈现简单的 SQL 查问，能够应用 ParallelScan 下推局部算子，将算子过滤后的残余后果疾速的拉取到计算零碎内存中做二次计算，大幅降低成本和晋升性能。动静批改 Schema 和 A/B Test除了性能外，咱们在易用性方面也在一直投入，心愿能够大幅简化客户的应用体验和晋升研发、运维效率等。客户应用了多元索引后，因为多元索引是强 Schema 的产品，如果后续业务须要变更字段，比方新增、删除、批改类型、批改列名等场景时，须要先新建一个索引，等索引数据都追上后，验证没问题，而后再线上做变更，将线上应用的索引换到新索引上，这个过程尽管能够解决问题，然而存在两个致命的问题： 容易引发故障：可能切换的时候切换错了索引，也有可能新索引有问题，这些都能够导致线上服务呈现问题，引发故障，产生损失。效率极低：这个过程全副要靠人力去做，持续时间长，而且因为是线上变更，每一步都要认认真真，稍一不注意可能会搞错，须要重来。基本上每一个强 Schema 的零碎都会面临这样的问题，这个问题尽管看起来是一个小问题，然而对于用户而言则是一个很痛很痛的点，每个用户每个月痛一次，如果有几千个客户，那么每个月破费在这件事件上的工夫和精力就会十分恐怖。为了真正的让客户用起来难受，简化应用，解客户之痛，晋升使用者的幸福度，咱们推出了动静批改 Schema性能。 以后咱们的动静批改 Schema 性能具备下列三大性能： 反对新增列、删除列、批改列类型、批改类名字、批改路由键等性能。反对新旧索引的 A/B Test。能够将原索引的流量切局部到新索引上，用于验证新索引的可用性和提早状况。新索引切换时智能揭示能力，防止客户提前切换导致的数据回退问题。上述性能目前曾经上线，开始邀测中，短短一个月工夫内，曾经有几十个客户在应用，大幅简化了客户的应用和升高了危险，好评一直。预计六月份会齐全对外开放。接下来咱们会有一篇专门文章介绍动静批改 schema 的能力和应用。 场景减少了多元索引后，表格存储在一些场景中的适配度变得十分高。 订单对于小数据量的订单，比方小于 2000 万行的能够间接用 MySQL，如果更大量的数据量，甚至几十亿、几百亿行的订单数据应用表格存储的多元索引会更好。 某互联网公司以后领有上百亿条历史订单数据，将来随着业务增长订单量预计每年会翻倍，以后架构是基于 MySQL 的分库分表来实现的，然而存在一些痛点：1）分库分表越来越简单，带来的运维压力也越来越大；2）慢申请越来越多，用户的投诉不间断。3）大客户的查问常常超时。为了解决这些痛点，客户将最新一天的订单存储在 MySQL，将全量订单数据通过 DTS 实时同步到表格存储，查问应用多元索引性能，带来了超出预期的益处：一是不再须要思考将来的扩容问题；二是不再须要运维，主须要关注业务研发即可，效率大幅晋升；三是查问性能最大晋升了55倍；四是彻底消除了慢申请，用户的投诉也不再有了；五是能够间接联合 DLA 或者 MaxCompute 做更简单的剖析。 更具体的订单场景介绍：《大规模订单零碎解读-架构篇》。 设施元数据表格存储的多元索引在去年新推出了并发导出性能，联合之前的个性，使表格存储在设施元数据管理方面具备了很大的竞争力。 某公司领有几百亿设施 APP 信息，这些设施信息会实时更新，每秒更新最大会达到 50万行/s，当有流动或者突发事件时，须要疾速圈选出指标APP进行音讯推送，圈选的时候须要 具备 1 分钟内从几百亿设施中圈选出 2 亿台设施的能力。以后架构中多套零碎组合应用，存在一些痛点：1）零碎泛滥，包含了多套存储和查问零碎、大数据计算零碎等，治理简单，老本昂扬。2）时效性查，大规模圈选都是小时级别，满足不了日益增长的经营需要。3）随着业务增长更新量越来越大，原有零碎瓶颈越来越大。客户通过半年调研后，将整个零碎搬迁到了表格存储，利用多元索引的查问和导出能力做实时查问和在线圈选，带来了超出预期的成果：1）零碎数量缩小到一个零碎，研发和运维复杂度大幅升高，稳定性更高；2）圈选时效性从小时级别升高到分钟级别。3）更新速率能够线性扩大，不在成为瓶颈。 音讯音讯类型存储（IM、Feed流、告诉等）是表格存储上客户量最多的的场景之一，表格存储的高牢靠存储、实时扩大能力、自增列性能能够大幅简化存储库、同步库架构以及多元索引提供全方位查问能力让音讯数据能够一站式解决存储、同步和搜寻的所有需要。 基于上述劣势，阿里巴巴团体外部的大部分 IM 零碎的存储、同步和搜寻零碎都基于表格存储，比方外部的钉钉，内部的泛滥互联网和物联网客户等。 下图是一个经典的音讯架构图： 最初多元索引以后反对阿里云官网控制台或者SDK创立，如果是首次应用，能够参考多元索引快手入门文章，行将公布。 咱们有一个钉钉公开交换群，大家能够退出放弃一个更好的沟通交流，钉钉群号：23307953。 对于重要客户咱们会收费提供专家服务群，在群外面会有表格存储各个模块的外围研发专家，会第一工夫解决技术或者稳定性上的问题，为客户提供一个绝佳的应用体验。 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

简介：6月4日，以“开启分布式云新时代”为主题2021云边协同大会在北京举办，本次大会由中国信息通信研究院主办。阿里云边缘云计算高级技术专家周哲受邀参会，分享了阿里云在边缘云计算的摸索，介绍边缘云次要产品的交互状态，如何在云基础设施降级过程中的演进，面向企业客户提供最佳业务体验。6月4日，以“开启分布式云新时代”为主题2021云边协同大会在北京举办，本次大会由中国信息通信研究院主办。阿里云边缘云计算高级技术专家周哲受邀参会，分享了阿里云在边缘云计算的摸索，介绍边缘云次要产品的交互状态，如何在云基础设施降级过程中的演进，面向企业客户提供最佳业务体验。 随着新型基础设施的建设放慢，放慢数字化转型已成为全行业共识。5G网络对挪动宽带的加强、海量终端互联以及对于高牢靠低时延连贯的需要，让边缘云的价值将日益凸显。 阿里云基础设施降级 阿里云通过12个年的倒退，在云计算技术和丰盛状态上有了多层演进，通过打造自主研发飞天云计算操作系统，面向不同行业客户场景提供多种状态服务，即核心Region、本地Region、边缘云节点和现场计算节点，让客户在多种状态的云上共享所有产品。 边缘云是由大规模地区扩散的边缘云节点互相协同组成分布式云，具备可近程管控、平安可信、规范易用等特点。 长期深耕边缘云畛域 阿里云边缘云节点是依靠于阿里云CDN弱小的节点网络和长期的技术积攒积淀的根底上进行的产品和技术演进。 阿里云作为国内当先CDN服务商，在智能调度、拓朴感知、故障逃逸、分布式管控、自动化的装机运维配置等技术方面有很深的积淀，联合阿里云飞天操作系统的小型化、交融计算能力以及弱小网络的多点协同能力，实现从CDN向边缘云的产品状态演进。 产品状态变动背地是客户需要发生变化，企业应用上云产生新的业务场景和大量数据，对于云的接入时延的响应速度有了更高要求，意味着须要在凑近用户的边缘侧提供更多算力需要。随着场景变动和技术演进，第一个是云原生技术，它让大量无状态的服务能够在边缘进行卸载。同时又有了云计算技术的成熟，能够进行相应的资源隔离，不论是虚机、容器还是沙盒的形式，具备更好的资源隔离和交付能力。 基于此造成两个体系：CDN内容散发体系和边缘计算产品体系。CDN内容散发体系有动态页面减速、对流媒体做缓存和减速的直播、点播减速、对动静内容做减速的动静减速，以及提供内容平安、网络安全的平安减速产品；边缘计算体系蕴含提供在边缘提供计算虚拟化的边缘云节点、对视频图片做算力卸载和边缘缓存的视图计算产品以及其余边缘利用。 同时，阿里云领有遍布寰球2800+边缘云节点，确保客户业务可能触达寰球用户。通过对CDN做全面云化，CDN节点升级成边缘云节点，客户在应用原有CDN资源时可享受更多边缘计算服务。 阿里云边缘云节点服务的产品矩阵 在谈到边缘云的产品矩阵时，周哲示意：在IaaS层面有规范的边缘云节点服务ENS，它是一个小型的分布式云节点服务。边缘云节点ENS底座提供了对立资源建设、对立资源库存、对立对外资源交付能力，使各种利用场景可能像应用对立操作系统一样应用ENS资源。目前阿里云边缘云节点服务上，已构建了很多利用场景产品，包含CDN产品体系、云通信场景、视图计算场景、云游戏以及跟合作伙伴共建的翻新场景。 阿里云边缘云节点的实质提供了边缘根底计算、存储、网络能力，无论是部署规模和利用场景都跟公共云核心Region有很大区别，将来边缘云倒退空间微小，须要基于更多行业了解和认知，能力打造贴合用户产品计划。 丰盛的边缘云产品状态匹配不同场景需要 阿里云边缘云节点能够对外提供的产品服务蕴含基于公共云一站式服务和“软件+硬件”整体交付服务。 基于公共云一站式服务是客户能够通过阿里云的官网管制台上间接获取的边缘云节点产品服务，由阿里建设经营，通过云化技术提供一站式解决方案； “软件+硬件”整体交付服务-边缘云联节点，可帮忙企业级客户疾速构建其本地基础设施，基于边缘云开展业务翻新、市场拓展及商业摸索，助力客户业务转型。 因而，无论哪种产品服务模式，取决于客户理论业务需要，阿里云始终都为客户提供统一产品应用服务。 边缘云节点服务技术特色 阿里云边缘云节点服务的技术特色分两层：一层是硬件体系上的技术储备，一层是在软件体系上的技术储备。 边缘云节点在部署过程中存在多种异构资源的场景，这就要求具备所有异构硬件的兼容和治理。阿里云边缘云节点不仅反对全自研的硬件体系，如超交融网关、超交融服务器，还反对纳管规范的第三方服务器。 同时，联合边缘云部署的网络场景要求，单个边缘云节点不肯定满足高牢靠要求。边缘云要面对的场景能够有肯定的容灾能力，有肯定的对节点的容忍能力，确保肯定的可用性就能够实现边缘云节点的部署。最终在面向客户的可用性交付，须要通过网络、调度能力和下层的管控去协同实现。 在软件体系里，阿里云边缘云节点服务反对多点协同、云网一体的调度和治理。在Cloudlet节点零碎中，反对多功能交融，蕴含交融计算、VM和容器的交融、存储的交融，并且在Cloudlet中蕴含平安能力。 同时还反对百万节点、千万机器，还有边缘云的小型化节点设计，这都是面向简单的网络、广散布的覆盖范围的需要。Master的管控零碎能对这么大规模异构的资源实现相应的协同，能提供统一标准的服务。 最上层BOSS零碎，可用于“软件+硬件”整体交付服务场景。 云网一体化技术利用 周哲强调，云网一体化是边缘云十分重要的技术点。云网的一体化次要体现在：一是对于地位的要求，自身边缘云服务对地位是无感的，尽管客户场景是地位强需要的，它肯定是有地位属性；二是对于节点间的合作是齐全基于网络。同时，边缘云在档次上还承载了跟运营商的MEC节点，以及跟核心Region和本地Region之间的承接关系。这种承接关系、数据流向以及利用门路的路由都是通过云网一体技术去实现的。网络中单个节点都能够认为是不可信的或者是能够短时间下线的，这就须要云网一体化调度能力确保边缘云节点服务的高可用性。 在边缘云上依靠成熟的SDN技术，提供高可用协同以及云原生网络。云原生是推动当初的云计算更多的分层倒退的很重要的技术方向。正是因为云原生技术的衰亡和越来越多的人开始把本人过来的软件、零碎或者是平台向云原生的形式去演进，对资源的应用形式才开始产生了变动，它能够去分拆本人有状态和无状态的服务，也能够分拆本人哪些货色是须要强延时和终端算力或者是边缘算力能够实现的。协同高可用是基于SDN，不论是在现场的节点接入还是在边缘云的节点接入，整个数据流动都能够在网络上无缝的实现。 面向未来技术演进 面向未来，阿里云边缘云节点服务会持续朝着分布式部署、节点自治与协同、小型化计算等方向倒退，面向行业客户提供稳固、牢靠、平安的服务。 演讲最初，周哲表白了面向未来的神往：阿里云心愿能和产业链合作伙伴一起致力，通过产品、技术、资源的深度交融，独特建设边缘云利用生态，让更多有翻新、有价值的企业应用部署运行在边缘云节点上，推动边缘云产业倒退。 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

简介： 随着现代化过程减速，企业业务规模和迭代速度也今非昔比，在已具备肯定规模的中大型电力系统中，会面临着数字化降级的压力，包含简单组织架构治理、计算资源弹性扩大、IT运维提效等需要。基于电力行业属性部署一朵专属于行业的云，这朵云既具备专有云的本地化部署的平安稳固个性，又可享有私有云按需应用云服务及按使用量付费的灵便能力。但当波及到大规模或跨多个地区的云平台部署场景，在不同的地区、数据中心部署业务就会面临不少问题。阿里云混合云是如何通过专有云的区域（Region）逻辑来造成多Region架构+混合云多云治理平台能力，以此实现多区域部署一朵专有云，解决大型用户多数据中心部署产生的问题？ 日本导演矢口史靖曾拍过一部自劫难喜剧电影《生存家族》，讲述了某天寰球忽然停电，所有用电工具都进行了工作，一个普通家庭为了求生从东京流亡到鹿儿岛的故事。尽管表演略带夸大，但没有电后世界的停摆让人印象粗浅，电力已成为与人类社会深度绑定的重要行业。 电力系统作为电能生产与生产的中枢，波及到发电、输电、变电、配电和用电的简单网络环节。为了撑持这套简单的体系，电力系统在各环节还具备相应的信息与控制系统，对电能的生产过程进行测量、调节、管制、爱护、通信和调度，以时刻保障用户取得平安、优质的电能。 而在传统电力企业中，仍以老旧“烟囱式”建设架构模式为大多数，各信息与控制系统间独立运行，数据规范不对立，扩散建设和治理导致一个个“数据孤岛”的造成，极大的节约了人力和物理资源。 同时，随着现代化过程减速，企业业务规模和迭代速度也今非昔比，在已具备肯定规模的中大型电力系统中，会面临着数字化降级的压力，包含简单组织架构治理、计算资源弹性扩大、IT运维提效等需要。 目前通常做法是基于电力行业属性部署一朵专属于行业的云，这朵云既具备专有云的本地化部署的平安稳固个性，又可享有私有云按需应用云服务及按使用量付费的灵便能力。但在应用过程中经常会波及到大规模或跨多个地区的云平台部署场景，在不同的地区、数据中心部署业务就会面临如下几个问题： 1、各个不同地区的云资源如何对立治理，权限调配与用户理论应用场景和组织架构的匹配； 2、高可用性的保障，当某个数据中心呈现故障或劫难时，其余数据中心可失常对外提供服务； 3、合规要求，多个数据中心的对立治理和权限调配等须要合乎用户外部规定，以及法律法规的要求； 4、许多利用或业务的拜访须要跨多个数据中心协同工作，如何实现各个数据中心之间的资源联动和共享； 阿里云混合云通过专有云的区域（Region）逻辑来造成多Region架构+混合云多云治理平台能力，以此实现多区域部署一朵专有云，解决大型用户多数据中心部署产生问题。 专有云区域（Region）在架构设计上分为核心Region和一般Region。专有云多Region具备以下特点： •一朵云，提供对立管控，对立运维，以及对立监控的能力。 •一致性，与阿里公共云的架构保持一致。 •兼容性，向前兼容单Region的部署状态，向后反对多Region的扩大部署。 •可用性，故障域隔离，当核心Region呈现故障的状况下，不影响云平台已申请云实例资源的应用。当一般Region呈现问题的状况下，不影响其余Region的应用。 多Region架构偏重云管控层面的对立，由一个核心进行对立治理、对立运维、对立计量等。 根底服务的读写服务部署在核心，一般Region的根底服务只须要部署服务节点和提供读服务，由核心Region对立管控运维。 在核心Region进行对立管控运维阿里云混合云治理平台（Apsara Uni-manager）则可对多Region进行无效治理，混合云治理平台致力打造千人千面，具备个性化体验的企业对立云治理入口，从利用、云资源、硬件等进行全局智能优化，实现资源配置的最佳配比和智能危险预警能力，为客户提供监管控一体化的智能指挥，赋能企业业务。 面对大型电力系统中的简单组织架构治理，核心Region能够看做是组织的司令部，而混合云治理平台就是驻扎在司令部的智能指挥官。其次要采纳了分权分域治理模型，在云资源应用和保护层面能够使领有一个区域资源管理权限的管理员只能治理本人所辖区域的设施以及应用相干的性能，不能治理其余区域的资源和设施。在业务和数据配置层面让各个治理区域的管理员也同样只需关注本区域的业务和数据等资源，无受权时不能查看、批改其余区域的资源。 通过混合云治理平台，造成集中管理形式下的分域合作模式，使核心Region和一般Region以省为单位建设、跨本地网部署、资源共享和协同治理，节俭配套投资。 同时，利用Region中心化治理或边缘Region自治治理的灵便切换和配置能力，能够让保护治理更灵便，充分利用区域运维资源，进步区域运维效率，加重核心Region所在的区域的产品应用和运维压力，从而优化跨区域合作的运维流程。 目前，阿里云混合云已通过多Region架构+混合云多云治理平台计划服务了多家电力行业的龙头企业，如助力南方电网搭建了业界首个齐全基于互联网新技术的调度自动化零碎根底平台，实现76套调度零碎云化和迁徙，总体建设老本节约上亿元。云化的SCADA零碎每秒解决音讯超过6万，全零碎70秒一键布署，10秒疾速扩容。日前负荷预测AI准确率高达97%，超过人工预测程度。 用电作为国计民生中的必要一环，现在已对电力系统的数字化、自动化与智能化提出了更高要求，阿里云混合云致力于促成发输变配及用电和调度环节的数据收集、输送、贮存和利用能力，进而使企业的业务解决自动化、经营治理信息化、战略决策科学化。 注： 专有云的区域（Region）指的是依据地理位置，把某个地区的基础设施服务的汇合称为一个区域。各个区域间互相独立，能够依照多种维度进行划分，通常依照数据中心所在的城市进行划分，专有云服务基于区域地理位置就近部署各种利用；也能够依照合规要求进行划分，通过抉择不同区域存储数据，来满足法规遵循要求。 阿里云混合云为政企提供量身打造的混合云解决方案 从建好云、管好云、用好云三大维度提供客户视角的一体化云平台服务 更多产品资讯，返回【混合云官网】 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

简介：从阿里团体诞生到云上商业化，随着业务的倒退和技术的演进，Hologres也在继续一直优化核心技术竞争力，为了让大家更加理解Hologres，咱们打算继续推出Hologers底层技术原理揭秘系列，从高性能存储引擎到高效率查问引擎，高吞吐写入到高QPS查问等，全方位解读Hologers，请大家继续关注！Hologres（中文名交互式剖析）是阿里云自研的一站式实时数仓，这个云原生零碎交融了实时服务和剖析大数据的场景，全面兼容PostgreSQL协定并与大数据生态无缝买通，能用同一套数据架构同时反对实时写入实时查问以及实时离线联邦剖析。它的呈现简化了业务的架构，与此同时为业务提供实时决策的能力，让大数据施展出更大的商业价值。从阿里团体诞生到云上商业化，随着业务的倒退和技术的演进，Hologres也在继续一直优化核心技术竞争力，为了让大家更加理解Hologres，咱们打算继续推出Hologers底层技术原理揭秘系列，从高性能存储引擎到高效率查问引擎，高吞吐写入到高QPS查问等，全方位解读Hologers，请大家继续关注！ 往期精彩内容： 2020年VLDB的论文《Alibaba Hologres: A cloud-Native Service for Hybrid Serving/Analytical Processing》Hologres揭秘：首次公开！阿里巴巴云原生实时数仓核心技术揭秘Hologres揭秘：首次揭秘云原生Hologres存储引擎本期咱们将带来Hologers高效率分布式查问引擎的技术原理解析。 Hologres作为HSAP服务剖析一体化的落地最佳实际，其查问引擎是一个齐全自研的执行引擎，它的外围设计指标是反对所有类型的分布式剖析和服务查问，并做到极致查问性能。为了做到这一点，咱们借鉴了各种分布式查问零碎，包含剖析型数据库，实时数仓等，汲取了各方面的劣势从零开始打造出一个全新的执行引擎。 为什么要抉择从零开始做一个新的查问引擎？开源的分布式剖析查问零碎次要有两大类： 一类是传统的 Massively Parallel Processing 零碎，可能反对通用的 SQL 查问，然而对实时场景反对不够好，性能不够现实。一类是 Apache Druid 和 ClickHouse这些实时数仓，是专门为实时场景设计和优化的，可能比拟好地反对一些常见的单表实时查问，然而简单查问的性能比拟差。另外大数据生态圈基于 MapReduce 的引擎比拟适宜批处理 ETL，个别不太适宜在线服务和多维分析的场景，性能也差不少。Hologres 执行引擎是在一个能反对简单查问和上述高性能实时服务查问的通用架构，先首先实现了罕用的实时数仓场景，深刻优化并用外部 Benchmark 验证了性能和稳定性超过包含专用实时数仓的其它竞品之后，再扩大到其它简单查问的反对。扩大的过程中，在不可避免地零碎变得越来越简单的同时，也用 Benchmark 帮忙放弃简略实时查问的性能没有回退。如果在已有的查问引擎上做改良，因为很多架构和设计上的抉择曾经定型，牵一发而动全身，就很难达到这样的成果。 Hologres执行引擎从开发到落地实际面临了十分多的挑战，但也给咱们提供了机会把这个畛域的各种新进展都联合利用起来，并超过已有零碎做到对各种查问类型的高性能解决，其背地次要是基于以下特点： 分布式执行模型：一个和存储计算拆散架构配合的分布式执行模型。执行打算由异步算子组成的执行图 DAG（有向无环图） 示意，能够表白各种简单查问，并且完满适配 Hologres 的数据存储模型，不便对接查问优化器，利用业界各种查问优化技术。全异步执行：端到端的全异步解决框架，能够防止高并发零碎的瓶颈，充分利用资源，并且最大可能地防止存储计算拆散零碎带来的读数据提早的影响。向量化和列解决：算子外部解决数据时最大可能地应用向量化执行，和存储引擎的深度集成，通过灵便的执行模型，充分利用各种索引，并且最大化地提早向量物化和提早计算，防止不必要的读数据和计算。自适应增量解决：对常见实时数据利用查问模式的自适应增量解决。特定查问深度优化：对一些查问模式的独特优化上面将会对各个模块一一介绍。 分布式执行模型Hologres 是可能弹性有限程度扩大数据量和计算能力的零碎，须要可能反对高效的分布式查问。 Hologres 查问引擎执行的是由优化器生成的分布式执行打算。执行打算由算子组成。因为 Hologres 的一个表的数据会依据 Distribution Key 散布在多个 Shard 上，每个 Shard 内又能够蕴含很多 Segment，执行打算也会反映这样的构造，并散布到数据所在的节点去执行。每个Table Shard 会被加载到一个计算节点，数据会被缓存到这个节点的内存和本地存储。因为是存储计算拆散的架构，如果一个节点出错，其服务的 Shard 能够被从新加载到任意一个计算节点，只是相当于清空了缓存。 例如一个比较简单的查问。 select key, count(value) as total from table1 group by key order by total desc limit 100。如果是单机数据库，能够用这样的执行打算。如果数据和计算散布在多个节点上，就须要更简单的执行打算。 ...

简介：本文将会讲述共享充电宝创始企业复电科技如何基于Flink+Hologres构建对立数据服务减速的实时数仓作者：陈健新，复电科技数据仓库开发工程师，目前专一于负责复电科技大数据平台离线和实时架构的整合。 深圳复电科技有限公司（以下简称“复电科技”）是共享充电宝行业创始企业，次要业务笼罩充电宝自助租赁、定制商场导航机开发、广告展现设施及广告流传等服务。复电科技领有业内立体化产品线，大中小机柜以及桌面型，目前全国超过90%的城市实现业务服务落地，注册用户超2亿人，实现全场景用户需要。 一、大数据平台介绍（一）倒退历程复电科技大数据平台的倒退历程次要分为以下三个阶段： 1.离散0.X Greenplum 为什么说离散？因为之前没有一个对立的大数据平台来反对数据服务，而是由每个业务开发线自行取数或者做一些计算，并用一个低配版的Greenplum离线服务来维持日常的数据需要。 2.离线1.0 EMR 之后架构降级为离线1.0 EMR，这里的EMR指的是阿里云由大数据组成的弹性分布式混合集群服务，包含Hadoop、HiveSpark离线计算等常见组件。 阿里云EMR次要解决咱们三个痛点：一是存储计算资源的程度可扩大；二是解决了后面各个业务线异构数据带来的开发保护问题，由平台对立荡涤入仓；三是咱们能够建设本人的数仓分层体系，划分一个主题域，为咱们的指标零碎打好根底。 3.实时、对立 2.0 Flink+Hologres 以后正经验的“Flink+Hologres”实时数仓，这也是本文分享的外围。它为咱们大数据平台带来了两个质的扭转，一是实时计算，二是对立数据服务。基于这两点，咱们减速常识数据摸索，促成业务疾速倒退。 （二）平台能力总的概括来说，2.0版本的大数据平台提供了以下能力： 1）数据集成 平台当初反对应用实时或者离线的形式集成业务数据库或业务数据的日志。 2）数据开发 平台现已反对基于Spark的离线计算以及基于Flink的实时计算。 3）数据服务 数据服务次要由两局部组成：一部分是由Impala提供的剖析服务和即席剖析的能力，另一部分是Hologres提供的针对业务数据的交互式剖析能力。 4）数据利用 同时平台能够间接对接常见的BI工具，业务零碎也能疾速地集成对接。 （三）获得成就大数据平台提供的能力给咱们带来了不少成就，总结为以下五点： 1）横向扩大 大数据平台的外围就是分布式架构，这样咱们可能低成本地程度扩大存储或者计算资源。 2）资源共享 能够整合所有服务器可用的资源。以前的架构是每个业务部门本人保护一套集群，这样会造成一些节约，难以保障可靠性，而且运费老本较高，当初由平台对立调度。 3）数据共享 整合了业务部门所有的业务数据以及业务日志等其余异构数据源数据，由平台对立荡涤对接。 4）服务共享 数据共享之后就由平台对立对外输入服务，各个业务线无需自行反复开发，就能疾速失去平台提供的数据撑持。 5）平安保障 由平台提供对立的平安认证等受权机制，能够做到对不同人进行不同水平的细粒度受权，保障数据安全。 二、企业业务对数据方面的需要随着业务的疾速倒退，构建对立的实时数仓火烧眉毛，综合0.x、1.0版本的平台架构，综合业务的当初倒退和将来趋势判断，构建2.x版本数据平台的需要次要集中在以下几个方面： 1）实时大屏 实时大屏须要替换旧的准实时大屏，采纳更牢靠、低提早的技术计划。 2）对立数据服务 高性能、高并发和高可用的数据服务成为企业数字化转型对立数据门户的要害，须要构建一个对立的数据门户，对立对外输入。 3）实时数仓 数据时效性在企业经营中的重要性日益凸现，须要响应更快更及时。 三、实时数仓和对立数据服务技术计划（一）整体技术架构技术架构次要分为四个局部，别离是数据ETL、实时数仓、离线数仓和数据利用。 数据ETL是对业务数据库和业务日志进行实时处理，对立应用Flink实时计算，实时数仓中数据实时处理后进入Hologres存储与剖析业务冷数据存储在Hive离线数仓，并同步到Hologres做进一步的数据分析解决由Hologres对立对接罕用的 BI工具，如Tableau、Quick BI、DataV和业务零碎等。 （二）实时数仓数据模型如上所示，实时数仓和离线数仓有一些类似的中央，只不过少一些其它层的链路。 第一层是原始数据层，数据起源有两种类型，一种是业务库的Binlog，第二种是服务器的业务日志，对立用Kafka作为存储介质。第二层是数据明细层，将原始数据层Kafka外面的信息进行ETL提取，作为实时明细存储至Kafka。这样做的目标是为了不便上游不同消费者同时订阅，同时不便后续应用层的应用。维表数据也是通过Hologres存储，来满足上面的数据关联或者条件过滤。第三是数据应用层，这里除了买通Hologres，还应用了Hologres对接了Hive，由Hologres对立提供下层应用服务。（三）整体技术架构数据流上面的数据流图能够具象加深整体架构的布局和数仓模型整体的数据流向。 从图中能够看出，次要分为三个模块，第一个是集成解决，第二个是实时数仓，第三块是数据利用。 从数据的流入流出看到次要的外围有两点： 第一个外围是Flink的实时计算：能够从Kafka获取，或者间接Flink cdt读取MySQL Binlog数据，或者间接再写回Kafka集群，这是一个外围。第二个外围是对立数据服务：当初对立数据服务是由Hologres实现，防止数据孤岛产生的问题，或者一致性难以保护等，也减速了离线数据的剖析。 四、具体实际细节（一）大数据技术选型计划执行分为两个局部：实时与服务剖析。实时方面咱们抉择了阿里云Flink全托管的形式，它次要有以下几方面长处： 1）状态治理与容错机制； 2）Table API和Flink SQL反对； 3）高吞吐低提早； 4）Exactly Once语义反对； 5）流批一体； 6）全托管等增值服务。 服务剖析方面咱们抉择了阿里云Hologres交互式剖析，它带来了几点益处： 1）极速响应分析； 2）高并发读写； 3）计算存储拆散； 4）简略易用。 ...

简介：阿里云Quick BI再度入选，并持续成为该畛域惟一入选魔力象限的中国企业，文章将为大家具体介绍上云数据分析首选产品 Quick BI的外围能力。日前,国内权威剖析机构Gartner公布2021年商业智能和剖析平台魔力象限报告，阿里云Quick BI再度入选，并持续成为该畛域惟一入选魔力象限的中国企业。Gartner ABI畛域魔力象限的评比条件全面且严苛。Gartner将围绕厂商们各个维度的能力进行打分，并将体现优先突出的厂商纳入魔力象限。 为让大家更全面理解Quick BI，从以开展进行论述。 Quick BI是专为云上用户量身打造的智能数据分析和可视化BI产品，帮忙企业疾速实现从传统的数据分析到数据云化+剖析云化的转变，将企业的业务数据产出后以最快的速度被推送到各组织侧生产应用。 1、从阿里外部上云孵化而来BI在阿里巴巴外部是重要的数据分析工具，利用在一线小二与管理层工作的方方面面，BI工具是数据化经营和数据化决策的根底。 Quick BI吸取了阿里巴巴外部BI设计与利用的教训，产品孵化后通过阿里云对外部企业提供服务。在从IOE时代到分布式数据存储和计算时代过渡的过程中，阿里巴巴发现市场上的BI工具无奈满足大数据量计算和疾速剖析的需要，并且单个工具的能力比拟繁多，无奈满足各种复杂多变的场景。而那时的阿里巴巴，各个业务的需要爆炸式增长，急需一款即便没有数据开发和剖析背景的人员也能应用的取数工具。 于是决定自研一套在分布式数据存储框架上的取数工具。 之后一段时间外部不同BU的数据分析类的工具百花齐放，有的面向于简单的表格，有的用于疾速的制作报表，有的只能搭建挪动端的报表。 在登月（阿里外部数据全副迁徙到ODPS）之后，阿里巴巴推出了阿里外部对立的云上BI剖析工具，并且在团体外部一直演变，直至不仅能在各业务线的决策分析中发挥作用，还能贴合电商营销和行业经营构建专题性的数据分析产品。也可间接服务于技术、经营、产品等角色的一线员工疾速连贯数据生成报表。最终倒退成10万员工疾速上手的功能强大的BI平台。 除了关注外部员工以外，在服务淘宝、天猫的商家时，发现数据作为企业根底资源，并没有被很好的生产和应用。从2017年开始，更为普世的面向全行业的根底数据分析工具Quick BI开始向云上的客户提供SaaS服务，当初除了公共云，还以麻利专有云、规范专有云和独立部署的形式向非阿里云客户提供BI服务。 2、数据联结剖析能力Quick BI并非是将外部BI产品一成不变的搬到云上，适宜于大型互联网公司的外部产品不肯定适宜宽泛的阿里云上客户。 一开始，Quick BI的定位是帮忙客户剖析他们在阿里云上存储的数据，所以按照阿里云数据存储的类型进行了全面的接入。 业务自身建设在阿里云上的企业，数据会存储在各种云数据库和存储中，阿里云提供了多种抉择，帮忙大型企业进行数据的批量解决和流式解决，解决后的后果也会存储在阿里云上，比方Maxcompute、RDS、ADB、Hbase或Hologres等，不同类型的存储提供了对于亿、百亿和千亿以上量级的存储和计算能力。 事实状态下有的客户还在迁徙上云过程中或者自身就是混合部署，他们还有局部数据存储在本地，这就须要对本地和云上的数据进行联结剖析，Quick BI通过自建的查问引擎，以及和阿里云Data Lake Analytics产品的单干，提供了较强的对异构数据进行联结剖析的能力。 3、如何利用Quick BI 构建数据分析体系对于大多数被动发动或统一规划的数据中心，数据分析体系或者说报表体系个别是从无序到有序，或者从有序到无序再到有序的门路建设起来的。 IT团队或者数据分析师首先基于对业务的了解，建设面向业务的报表体系，这种固定的报表体系只能满足局部业务的需要，其余需要则须要配置长期报表。随着业务的变动有越来越多的报表须要上线和下线，本来对立固定的报表体系也变得越来越凌乱无序，此时又再须要进行重构。 良性演进建设起来的数据分析体系，个别包含决策分析、业务专题剖析和长期报表。决策分析和业务专题剖析通常会用固定的数据产品造成报表体系，由业余的数据团队保护，能够放弃较长周期的稳固。而长期报表能够随着业务的变动长期创立和沦亡，当业务稳固后对应的长期报表再积淀到固定报表体系中。 领有简单场景解决能力的Quick BI提供了多种数据分析能力，包含：仪表板、电子表格、自助剖析、大屏、自助取数等。 仪表板可创立剖析思路经明确的、有肯定数据逻辑的报表或者数据产品；电子表格适宜款式简单，甚至须要对单元格级进行调整的场景，比方银行报送的报表、政府单位逐级填报汇总的报表，只有相熟Excel不须要会写SQL也能轻松配置；自助剖析适宜剖析维度和指标都比拟多的大宽表，由数据团队构建并保障大宽表的产出，业务人员随着业务需要随时组合不同维度和指标，能够定位数据稳定起因，也可分组汇总数据等。这些剖析不须要固化，即剖析即走；还有一些场景须要导出大量数据，再进行后续剖析或者导入其余零碎，比方用户名单、订单明细等，动辄几百万上千万，这时应用自助取数就能够不便的实现。Quick BI最新产品大图 数据分析和可视化后果能在多种渠道被应用。不止能够在PC浏览器拜访，还能够在挪动环境下通过手机端拜访（可视化成果主动适配手机屏）。针对工厂、会议室、流动现场等场合，还能够投像至电视屏。 无论是通过导出、分享还是订阅，当数据发生变化或呈现稳定时，便会被动推送给关注这组数据的人。当企业在应用钉钉或者企业微信时，Quick BI能够和他们很好的集成，进步业务沟通中查看数据、剖析数据的效率。Quick BI能够给群或单个用户被动发送音讯，也能够用零碎告诉的形式发送信息。 钉钉群甚至能够设置智能机器人，群成员向Quick BI机器人发问，即可查找数据和报表。 4、Quick BI 的数据可视化能力可视化是BI产品的外围能力，Quick BI认为数据可视化应该从简略的数据出现向疾速的数据分析进行降级，而0代码交互式的可视化操作面板能够显著晋升数据分析的效率。 除了通过交互式的操作（钻取、联动、跳转）疾速发现数据之间的关联和组成，Quick BI进一步提供全新的疾速洞察形式。新增的指标拆解图能够帮忙用户自定义剖析的指标和纬度，用户能够随时调整剖析的维度和拆解的程序，在指标呈现稳定和异样时可能疾速定位影响因素。 5、生意顾问自助剖析生意顾问自助剖析性能针对在团体电商平台开店的卖家推出，Quick BI 和生意顾问联结打造了生意顾问自助剖析模块。当天猫、淘宝的卖家在应用生意顾问进行店铺数据化经营过程中，面对现有报表无奈满足需要时，能够通过利落拽的模式，0代码的对生意顾问内的数据进行自助剖析。以前卖家只能勾选维度和指标，抉择工夫周期，将数据下载到本地再进行剖析。当初，在线即可实现剖析，做好的仪表板页面也能保留在生意顾问中。目前有近两千家店铺因而受害。 6、钉钉2021年初，Quick BI和钉钉团队单干。在钉钉利用市场推出“智能报表”利用，帮忙在钉钉上的百万企业剖析在钉钉中产生的工作、表单、流程等数据，并反对将钉钉中产生的数据和企业自有的业务数据进行交融剖析。 产品详情：https://dp.alibaba.com/product/quickbi 产品体验：https://www.aliyun.com/product/bigdata/bi 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

简介：阿里巴巴提出的OneData方法论帮忙企业捋清了数据全生命周期的治理思路，更将其植入到产品Dataphin（智能数据构建与治理）中，通过阿里云为企业提供服务。 Dataphin 智能数据构建与治理平台 面向各行各业大数据建设、治理及利用诉求，一站式提供从数据接入到数据生产全链路的智能数据构建与治理的大数据能力，包含产品、技术和方法论等，助力打造规范对立、死记硬背、资产化、服务化、闭环自优化的智能数据体系，以驱动翻新。 Dataphin产品中转：https://www.aliyun.com/product/dataphin 艰难是最好的教练阿里巴巴从2008年开始建设自有的大数据体系，致力于构建好数据服务多样的业务。一路上，经验了各种各样的艰难。 技术陷在长期取数不可知：阿里外部已经通过建设专门的“长期取数需要管理系统”，给每个业务线调配长期取数的工夫额度，每次还没到月底,额度曾经为零，业务同学追着数据技术同学加班取数的状况时有发生......为了扭转这一场面，专门建设了“业务人员SQL技能培训”，心愿用这样的形式让业务人员本人把握长期取数技能，美其名曰“赋能”。而这背地的实质是：资源。 数据口径定义有差异：已经就因为数据口径差别，差点造成商家损失。商家在后盾看到的数据预测，显示能够达到流动报名要求，于是提前备货，筹备大干一场，然而最终报名却没有通过，起因是小二侧的数据口径与商家侧的数据口径不统一，小二零碎评估商家的数据未达标，导致不通过。尽管最终通过协调解决了问题。但这背地的实质是：规范。 加班做报表，汇报还被骂加班取数是常态，通常取数破费2-3小时，而之后的核查差别则要花费微小精力，动辄1-2天；最初的汇报环节，也会因为一些口径差别及数据品质问题造成难堪，甚至会呈现谬误数据导致决策失误的状况。这背地的实质是：品质。 除了上述这几个典型的场景，阿里巴巴也曾因业务增长而呈现数据量暴发增长，对数据不治理不治理，意味着数据的存储和计算成本一直攀升。老本，也是大数据畛域面临的艰难之一。 摸索中前行，实战中积淀带着克服困难的信心，阿里巴巴开始了B2B业务数据建设、电商业务数据建设、阿里系业务数据建设。过程中，边摸索、边积淀、边前行，通过更体系化的数据建设晋升数据品质，升高数据重构的危险，晋升数据服务的效率。经验近十年的打磨，基于实战，阿里巴巴积淀了OneData大数据建设的方法论（OneModel+OneID+OneService)。OneModel通过对数据体系化架构、数据元素标准定义、数据指标结构化拆解，对数据进行对立的构建及治理；OneID通过建设实体对象、对象相干的行为数据及标签构建办法，对企业的外围商业因素进行资产化；对数据资产进行对立的主题式数据单元构建，配置构建数据API并提供API服务，以晋升数据资产生产的便捷性，晋升数据资产价值。 克服痛点 发明当先的大数据能力 随着寰球数字化过程的减速，企业面临着更加严厉的市场竞争，而数智化转型所遇到的窘境也曾是阿里巴巴最后之痛。于是，阿里云数据中台应运而生，与各行各业的企业在数据畛域发展了单干，解决企业凸显的数据问题： ●数据规范问题：烟囱式开发及部分业务服务撑持，导致指标同名不同口径问题频发；历史上不同业务零碎逐渐迭代上线，雷同对象属性编码不统一等问题突出； ●数据品质问题：反复建设导致工作链简短、工作繁多，计算资源缓和，数据时效性不好；口径梳理定义的文档积淀到开发代码实现之间存在脱节，数据准确性保障危险高； ●需要响应问题：烟囱式开发周期长、效率低，面向利用的服务化有余，导致业务响应速度慢，业务不称心的同时技术又感觉没有积淀与成长；既懂业务又懂数据的人才有余，需要了解到开发实现波及大量沟通，服务效率较差； ●老本资源问题：烟囱式开发的反复建设节约技术资源；上线难下线更难，源零碎或业务变更不能及时反映到数据上，加之数据不规范，研发保护难上加难的同时，大量无用计算和存储造成资源节约。 阿里巴巴提出的OneData方法论帮忙企业捋清了数据全生命周期的治理思路，更将其植入到产品Dataphin（智能数据构建与治理）中，通过阿里云为企业提供服务。 Dataphin除了大数据处理全链路波及到的数据集成、开发、公布、调度、运维能力，同时提供了数据标准定义、逻辑模型定义、代码自动化生成、数据主题式服务能力，高效地实现好数据的构建。 Dataphin产品外围模块 Dataphin自2018年问世以来，已倒退出了饱满的大图，到目前为止经验了多轮大版本升级，产品外围的能力模块清晰浮现。 1、环境适配 最底层为Dataphin的环境适配能力。Dataphin反对不同的云环境，为不同规模以及不同部署要求的客户提供不同的抉择，包含公共云多租户、公共云VPC、专有云企业版及麻利版，以及本地IDC部署。 2、引擎反对 在云环境之上，依据不同的云环境能够反对不同的计算引擎。离线的计算引擎包含阿里云MaxCompute，Hadoop生态引擎包含阿里云E-MapReduce、CDH5、CDH6、以及行将反对的FusionInsight、CDP等。实时计算引擎反对阿里云Blink和Flinkvvp。开源版本的Flink也行将反对。 3、数据构建 基于不同的云环境和计算引擎，Dataphin提供了大数据处理全链路波及的数据集成、开发、公布、调度、运维能力，提供了数据标准定义、逻辑模型定义、代码自动化生成、主题是查问的数据构建能力。 4、资产 Dataphin提供了配套的资产地图、资产血统、资产品质治理和监控、资源老本治理和提效的资产治理能力，并提供了配置化的资产服务研发和治理能力，可将数据资产疾速服务业务、反哺业务。 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

简介：如何通过 Apache Pulsar 原生的存储计算拆散的架构提供批流交融的根底，以及 Apache Pulsar 如何与 Flink 联合，实现批流一体的计算。 简介：StreamNative 联结创始人翟佳在本次演讲中介绍了下一代云原生音讯流平台 Apache Pulsar，并解说如何通过 Apache Pulsar 原生的存储计算拆散的架构提供批流交融的根底，以及 Apache Pulsar 如何与 Flink 联合，实现批流一体的计算。 GitHub 地址 https://github.com/apache/flink 欢送大家给 Flink 点赞送 star~ Apache Pulsar 绝对比拟新，它于 2017 年退出 Apache 软件基金会，2018 年才从 Apache 软件基金会毕业并成为一个顶级我的项目。Pulsar 因为原生采纳了存储计算拆散的架构，并且有专门为音讯和流设计的存储引擎 BookKeeper，联合 Pulsar 自身的企业级个性，失去了越来越多开发者的关注。明天的分享分为 3 个局部： Apache Pulsar 是什么；Pulsar 的数据视图；Pulsar 与 Flink 的批流交融。一、Apache Pulsar 是什么下图是属于音讯畛域的开源工具，从事音讯或者基础设施的开发者对这些肯定不会生疏。尽管 Pulsar 在 2012 年开始开发，直到 2016 年才开源，但它在跟大家见面之前曾经在雅虎的线上运行了很长时间。这也是为什么它一开源就失去了很多开发者关注的起因，它曾经是一个通过线上测验的零碎。 Pulsar 跟其余音讯零碎最基本的不同在于两个方面： 一方面，Pulsar 采纳存储计算拆散的云原生架构；另一方面，Pulsar 有专门为音讯而设计的存储引擎，Apache BookKeeper。架构下图展现了 Pulsar 存储计算拆散的架构： 首先在计算层，Pulsar Broker 不保留任何状态数据、不做任何数据存储，咱们也称之为服务层。其次，Pulsar 领有一个专门为音讯和流设计的存储引擎 BookKeeper，咱们也称之为数据层。 ...

简介：5月29日，阿里云开发者大会上，阿里云数据库发表「云原生数据库 2.0：一站式全链路数据管理与服务」的全新品牌理念及开源云原生数据库能力，首次从客户场景视角提出了一站式在线数据管理平台的理念。目前，阿里云领有国内最弱小和丰盛的云数据库产品家族，涵盖关系型数据库、非关系型数据库、数据仓库、数据库生态工具四大版块，能够为企业数据生产和集成、实时处理、剖析与发现、开发与治理提供全链路生命周期的服务。 数据生产和集成数据的生产和集成是数据的第一生命周期，就像一个新生儿一样，数据来到这个世界首先必须要经验采集，而后经验存储和解决。阿里云数据传输DTS、数据管理DMS和数据库备份DBS等工具形成了数据生产和集成的根底能力。通过对30+数据源的混合云对立治理，实现数据采集、异构数据实时传输、异地多活、数据跨云备份或备份上云等多样的解决方案，通过DMS提供的数据库DevOps能力可晋升数据安全性和研发协同效率。 数据实时处理在实现数据的生产和集成天然就到了数据的实时处理，在线交易场景如何确保利用永远在线、数据永远不失落，这一步肯定是大家最关怀的问题。在这里阿里云数据库提供了不同的抉择。 阿里云RDS是国内规模最大、最稳固的云数据库，反对MySQL、PG、SQL Server等引擎，撑持阿里巴巴经济体疾速倒退十余年，提供99.99%的高可用和RPO=0的企业级能力。云原生数据库2.0时代，阿里云RDS最大的特点是提供企业级的数据库自治能力，通过AI和机器学习的技术，构建了主动驾驶数据库平台，反对问题主动修复、主动调优。 阿里云自研云原生关系型数据库PolarDB采纳存储计算拆散、软硬一体化设计，既领有分布式设计的低成本劣势，又具备集中式的易用性，可满足大规模利用场景需要。计算能力最高可扩大至1000核以上，存储容量最高可达100TB，集群版单库最多可扩大到16个节点，性能比MySQL高6倍。PolarDB系列产品已间断多年稳固撑持天猫双11，解决峰值高达创纪录的1.4亿次/秒。 数据分析和发现当积攒了大量的交易数据当前，如何在数据外面发现信息为业务发明更大的价值，就到了数据分析和发现这个生命周期阶段。 云原生数据仓库AnalyticDB，基于存储计算拆散架构，在离线一体化，一份存储数据满足交互式剖析、实时更新、高并发点查及离线计算等多种计算能力，解决了传统剖析零碎架构简单，构建门槛高、老本高的问题，1TB能够低至114元/月。云原生数据库2.0还可通过数据湖技术发现和剖析离线数据，构建湖仓一体的解决方案。 数据开发和治理最初是数据的开发和治理，通过数据管理服务DMS，企业可对在线数据资产对立治理，包含元数据管理、平安脱敏和血统剖析，实现低门槛按需建仓，麻利剖析的能力。 一站式在线数据管理平台带来的最大变动是企业可能用数据库的形式进行大数据量的治理。DMS对立治理数据库和数据仓库，让数据自在流动。与传统数据集成不同，DMS能够在源端数据库DDL或扩缩容等运维变更对链路无感知，并且内置ETL能力缩短数据链路，同时还可通过跨库查问将源端数据库的表间接作为数仓ODS层参加计算，免去数据物理搬迁的问题，真正实现按需建仓、麻利剖析。DMS还反对灵便的工作编排和数据开发、报表展现。随着数据积攒，DMS可周期性归档数据到云原生多模数据库Lindorm或OSS，利用数据湖剖析对DBS备份数据进行价值开掘，对数据进行全生命周期治理，施展数据价值。 一站式在线数据管理平台，通过对立治理在线数据资产，进行全链路的平安和血统治理，构建库仓一体、在离线一体的存储和计算能力，将大大降低企业数据处理和剖析的门槛，帮忙企业更好地施展数据价值，助力企业数字化转型。 阿里云数据库负责人李飞飞示意：“云原生数据库2.0，咱们要从原子产品差异化走向一站式全链路的数据管理与服务，让开发者和客户能够从数据中挖掘价值，让数据可能无缝地流动起来，这是咱们的理念，也是咱们的使命。” 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

简介：封神-外围性能 | 钉钉告警+数据网关 1. 开发背景1.1 用户痛点①租户侧运维能力弱 问题：租户侧，客户没有有效途径，及时地获取实例级的状态、性能、容量的数据。 现状：每日固定工夫，驻场须要人肉收集数据，钉钉定时推送给客户。 ②问题排查效率低 问题：利用业务有问题，云平台产品失常，客户并不认可，须要帮忙客户解决问题。 现状：发现利用实例呈现性能、容量被打满的问题，这个排查过程往往简短， 效率很低。 ③监控能力缺失 问题：云平台监控不全，容量治理、性能治理等报表能力缺失。 现状：驻场须要通过大量人肉巡检，或者编写脚本。 ④监控 形式时效性低 问题：业务侧总会优先于利用与云平台感知到故障，运维十分被动 。 现状：客户发现问题，告诉利用，利用查看后，再溯源到云平台，排查链路串行并且低效。 1.2 解决方案①保障业务稳固 通过云产品的服务能力的变动状况及业务仿真模型的建设，提前预知客户业务衰弱度，低于基线后便会触发告警。 ②SLA化展现 触发阈值主动报警，量化产品健康状况。 2. 开发设计2.1 零碎架构图1：零碎架构图 封神零碎架构如图1所示，分为CLIENT与SERVER端两大模块。 CLINET端：部署在经典网铜雀容器内，通过定时工作管制去采集云内各产品数据。SERVER端：部署在VPC内ECS上，零碎框架为FLASK，分为数据处理与数据存储两大部分。 ①数据处理是指通过提供API承受CLIENT的数据并进行入库操作以及数据的前端展现。 ②数据存储是指借助阿里云RDS数据库，对数据进行长久化操作作。 2.2 业务架构图2：业务架构图 封神业务架构如如2所示，分为五大板块。 姜子牙：租户侧告警，次要包含ECS、RDS等云产品实例性能以及业务相干告警。申公豹：运维侧告警，次要包含云产品衰弱状态、水位容量等相干告警。雷震子：硬件告警，次要包含坏盘，物理机带外等告警。比 干：平安告警，次要来自云盾相干安全类告警。杨 戬：故障告警，次要对各产品数据进行SLA算法解决，设置P0,P1等级故障阈值。3. 钉钉告警3.1 告警分类机器人创立形式可参考文后材料[1]理解详情。 姜子牙 申公豹 雷震子 比 干 杨 戬 3.2 告警展现图3：姜子牙 图4：申公豹 图5：雷震子 图6：比干 图7：杨戬-1 图7：杨戬-2 图7：杨戬-3 图7：杨戬-4 4. 数据网关数据网关分为两大模块：获取数据、接收数据。 获取数据分为告警数据、全量数据、性能数据。 ①告警数据：别离对应钉钉机器人推送的告警信息，封装成相应的数据格式，以API接口模式对外提供数据。 ②全量数据：数据库源表数据，不做任何加工解决，以API接口模式对外提供数据，可操作性较高。 ③性能数据：产品性能数据会定期存储到时序数据库，存储工夫长，可查问历史性能数据。 接收数据：提供对外API接管客户自定义监控数据，封装成MARKDOWN格局，实时进行钉钉告警。4.1 获取数据4.1.1 告警数据4.1.1.1 申请接口申请形式：POST申请 URL地址： http://{ip}:{port}/api/v1/sea... ip:封神ecs\_ip port:9170 PARAM：参数列表可查看文后材料[2]理解详情。 ...

简介：视频云驱动智媒翻新 5 月 27 日，CCBN（第二十八届中国国内广播电视信息网络展览会）在北京隆重召开，在本次的 “CCBN 年度创新奖” 评比中，阿里云视频云凭借 AI 编辑部的传媒行业业余解决方案取得 CCBN 产品翻新卓越奖。 随着技术的倒退，5G、4K、AI 等新技术的翻新及利用，曾经是媒体行业转型的共识。面对 9.86 亿手机网民，充分发挥 5G 网络技术劣势，构建手机小屏和电视大屏交融流传的全媒体散发体系成为媒体行业发展趋势。在新的流传模式下，用户更偏向于个性化的视听需要，这对传媒行业内容制作时效和制作产量带来新的要求与挑战。如何使用人工智能和数据技术晋升视频的制作时效和制作产量，成为 AI 编辑部媒体交融转型的重点工作之一。 生产制作是整个制播流程的外围，它连贯了采集，播放和存储，也只有让制作过程全面云化之后，能力真正晋升交融媒体的效率。在整个交融媒体制播流程当中，新降级的 AI 编辑部 2.0 交融了短视频制作和高码率精编，通过大量应用 AI 技术，实现大小屏的双向互动和交融生产。同时，交融云、端协同生产的形式，减速整个内容生产的效率。 从实际操作层面，AI 编辑部通过真 4K 的云端制作、4K 视频加强、云上融媒短视频制作三个细分方面来实现： 首先，在 4K 云端制作的基础设施方面，AI 编辑部做的次要翻新是引入了 SCC 高性能计算和 CPFS 并行文件系统。针对云端制作的高性能需要，实现计算节点与存储节点之间低延时互联，满足更佳的制作体验，同时防止虚拟化损失，进一步晋升性能。针对云端制作的高存储容量和带宽需要，CPFS 提供随存储节点的线性裁减吞吐能力，单集群最大 300GB/s 吞吐能力。AI 编辑部提供了丰盛的适配于传媒业务的资源，包含 FPGA、GPU 等各类个性化硬件设施，以满足不同业务诉求。此外，AI 编辑部针对 GPU 进行了大量的优化，包含 GPU 的虚拟化，共享以及赤化，可能极大的晋升 GPU 的利用率，升高云端制作的老本。 其次，在 4K 视频加强方面，AI 编辑部次要通过视频超分，视频插帧和色调加强三个核心技术，来全面晋升 1080p 及更低质量视频的画质，在帧率、分辨率以及色调三个方面全副达到超高清视频要求。AI 编辑部提供的 4K 加强能力，既满足业余规范，也就是总局在《4K 超高清电视节目制作技术 施行指南》中的规范定义，也满足行业内业余的技审和监看要求，在满足主观参数规范的同时，在主观视觉体验上有显著晋升，包含细节还原、噪声克制、画面晦涩、视频亮度、色调对比度和明暗细节放弃等。在 AI 视频超分方面，AI 编辑部采纳深度学习的形式，对画面进行无损放大，可能实现分辨率 4 倍晋升，对人像、场景等细节进行修复还原的同时，可能克制块噪声、压缩噪声等画质伤害，使画面更锐利。AI 编辑部翻新的提出了重点部位的加强，以最小代价，做到最有成果，如重点优化人像面部，对人的皮肤纹理、毛发细节等实现更好的修复还原。 ...

简介：2021年5月15日，以“置信边缘的力量”为主题的寰球边缘计算大会在深圳胜利召开。 阿里云资深技术专家李克，分享阿里云在边缘云计算的摸索和实际，如何为行业提供广覆盖、低成本、高牢靠的边缘基础设施。2021年5月15日，以“置信边缘的力量”为主题的寰球边缘计算大会在深圳胜利召开。 阿里云资深技术专家李克，分享阿里云在边缘云计算的摸索和实际，如何为行业提供广覆盖、低成本、高牢靠的边缘基础设施。 Gartner依照地位不同划分3种计算场景，别离是Near Edge、Far Edge、Cloud，对应着终端计算、IDC计算和核心云计算。其中Near Edge是规范服务器或设施，在间隔端侧最近的中央，例如在工厂和园区，能够为任何Arm，X86设施；而Far Edge是规范的IDC节点，而Cloud是公共云或专有云服务，特色为资源集中、中心化治理。 边缘云计算是一种Far Edge的场景，次要是利用运营商的资源构建小型化的云节点，提供计算、网络、存储能力。 边缘云处在核心云和终端之间。起到承前启后的作用，一方面能够将核心计算下沉到边缘，另一方面也能够把端侧计算上移到边缘。 边缘云计算通过边缘节点的流量卸载，能够实现对5G流量的本地化解决和散发，防止海量流量对骨干网路的冲击，可能提供大带宽的解决方案。边缘云计算通过分布式架构，实现对海量终端高并发的分布式解决，深刻场景的本地化计算能力，将进一步晋升计算的效率。而边缘云计算人造的就近部署，也能满足5G低延时解决的场景化需要，提供10ms乃至于ms以内的响应时延。 除了业务场景上对边缘云计算的需要外，另外一个促使边缘场景疾速倒退的推动力是老本，核心机房的规模都很大，一次性的CAPEX和后续的OPEX老本都十分高，而且核心个别都是BGP带宽，而边缘节点，机器配置不必太高，节点规模也较小，个别几十台左右，网络也是复线接入，所以在老本上具备肯定的劣势。 阿里云领有遍布寰球的边缘云计算节点，边缘云计算具备分布式个性，节点数量和散布的广度决定了边缘云整体提供的场景丰盛度。同时阿里云可能十分不便地将合作伙伴的基础设施引入到阿里边缘云生态中，反对更多的本地场景落地。 数字孪生与物理终端的协同计算 新计算须要具备新的个性：业务在线化、数据精细化和数据疾速决策。 数据在线化是企业数据化转型的第一步，须要将业务进行数据化形容，提炼进去指标进行跟踪；数据精细化是数据分析肯定要足够细粒度，否则无奈发现其中的渺小变动，一般来讲须要细化到一个独立的设施和连贯；数据疾速决策是边缘计算的外围特色，实现人、事、物的疾速决策，比方依据用户行为，进行商品的举荐，依据某个设施的异样，疾速实现复原，让客户无感知。 边缘云计算可能提供足够的计算能力，通过对边缘算力的调度，基于物理终端接入地位、边缘节点地位和算力状态进行边缘算力与物理终端的匹配和协同调度，在物理世界和数字世界之间建设起映射，以最小的时延获取数据，最快的剖析和下发响应，让用户领有与设施本地操作统一的业务体验。 数据就近缓存解决 新存储指的是可能在边缘上存储和应用数据，边缘场景的数据特色是数据产生和生产个别具备本地化特色，所以须要在边缘上提供存储的解决方案。边缘云存储可能提供交融存储能力，即一台设施上同时反对块存储、文件存储和对象存储等能力，节点之间可实现主动的数据迁徙和备份。 大量的视频图像类数据都是在边缘上进行解决和存储的，如编解码，人脸车辆辨认，结构化的数据回存到核心，原始数据在边缘，当须要的时候能够间接在边缘进行检索。 通过这种形式，一方面使得数据处理变快，另一方面无效降低成本。 分布式节点的多边协同网络 基于边缘节点构建一张新型的传输网，具备平安、高质量、低成本和疾速容灾性。边缘云的网络分为三段： 第一个是边缘和设施之间，是一种网关的角色，可能反对平安、规范的接入形式； 第二个是边缘和边缘之间，可能动静的选路布局和容灾调度，实现任意两点的最佳传输； 第三个是边缘和核心之间，可能承诺大流量的场景，做好骨干网的流量布局。 通过跟运营商严密单干，基于运营商的MEC节点、5G切片等外围能力，构建‘云-边-端’ 一体的交融网络。 李克通过2个具体场景解说了阿里云边缘云计算在实践中如何解决的业务痛点。 场景一是自在视角的在线赛事直播计划，在往年CUBA全明星赛直播过程中，观众能够在任意手机上自在拖拽视角，实现自在视角的观看体验。传统计划对设施硬件和带宽传输要求较高，须要同时下载和解决多路摄像头数据流，硬件老本高无奈推广，并能功耗高耗电快。而通过边缘计算节点ENS实现多路视频的近程渲染，缩小手机的解决工作以及下载量。 场景二是云利用和云游戏通过边缘计算节点ENS来提供地位无感的服务接口，疾速创立一路设施，终端和设施之间通过音讯指令的形式进行近程操控。一方面，用户在升高设施的硬件老本，可能体验到大型的游戏；另一方面对于内容厂商能够疾速的推广新游戏和利用无需依赖硬件的芯片和存储能力，对于云计算厂商，也能够比拟好的进行资源复用，只对在线的终端才启动影子设施。目前在云游戏畛域，曾经撑持了PC端游和手游，向下对接各种异构资源，如GPU和ARM设施，向上提供了对立的资源和利用应用规范。 阿里云一直开掘边缘云计算在垂直畛域中的场景化利用，推动各行业利用架构降级。已在智慧交通，公共事业畛域，新批发，新教育和智能家庭上都有了很好的落地实际。 多云协同的边缘云计算体系 在构建生态上，李克心愿通过一套残缺的生态，可能撑持各行各业的边缘落地。一方面，阿里云会踊跃拥抱云原生，提供规范的容器和k8s接口，制订利用的编排、服务注册和发现流程，让业务更加标准和不便的应用边缘云计算的能力；另一方面会和资源提供方做好生态单干，制订资源的对接规范，除了自建节点，将来还有大量的单干节点，以及第三方节点。通过这种多云交融的对接，能够实现资源的流动，在应答双十一类似的突发流动时能够有足够的弹性。目前阿里云已跟运营商在MEC节点上开展了深度单干，在某些区域已实现资源的互联互通。 演讲最初，李克表白了面向未来的神往：阿里云咱们心愿能和更多的行业合作伙伴一起，通过产品、技术、资源的深度交融，提供丰盛的边缘能力，撑持边缘利用场景利用，为客户继续发明价值。 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

简介：飞天是由阿里云自主研发、服务寰球的超大规模通用计算操作系统，反对多种状态，即核心Region、本地Region、边缘云节点和现场计算节点，让客户在多种状态的云上共享所有产品。2021年5月28 日，在以 " 云上翻新 " 为主题的阿里云峰会上，阿里云智能总裁张建锋称，阿里云提供一体化的飞天架构，目前飞天操作系统正在全面兼容 X86、Arm、RISC-V 等多种芯片架构，要让算力无处不在。 飞天是由阿里云自主研发、服务寰球的超大规模通用计算操作系统，反对多种状态，即核心Region、本地Region、边缘云节点和现场计算节点，让客户在多种状态的云上共享所有产品。 在下午进行的边缘云撑持低延时场景业务分论坛中，阿里云携手中国电信、国网信通产业团体、华数传媒以及阿里巴巴云游戏等产业合作伙伴，针对边缘云的全栈技术趋势和商业利用进行了深入探讨。 阿里云智能边缘云资深专家郝冲示意：边缘云是由大规模地区扩散的边缘云节点互相协同组成分布式云，具备可近程管控、平安可信、规范易用等特点。 阿里云提供边缘云产品蕴含反对边缘根底计算、存储、网络的边缘云节点服务ENS以及构建的各类场景利用，蕴含CDN产品服务、云通信、视图计算、云游戏、云桌面、云智能终端等，目前已广泛应用于城市、娱乐、电商、游戏、体育、金融、政企、广电、电力等十多个行业。 边缘云节点是飞天提供的凑近用户的边缘计算服务，依靠阿里云遍布寰球的2800+边缘云节点，通过凑近客户侧的去中心化小型云计算平台能力，实现了广覆盖、低时延、大带宽的技术特点，为用户提供平安、稳固、牢靠的边缘节点计算和寰球内容散发减速服务，帮忙客户解决在音视频、游戏、终端虚拟化等利用场景中遇到的算力、网络、部署和时延问题。 阿里云边缘云节点还反对“软件+硬件”整体交付服务-边缘云联节点，可帮忙企业级客户疾速构建其本地基础设施，基于边缘云开展业务翻新、市场拓展及商业摸索，助力客户业务转型。 中国电信江苏政企客户撑持部主任陈美作为演讲嘉宾缺席，分享了江苏电信在施展云网协同的独特劣势，借助5G、宽带的网络广覆盖，以及中国电信分布式云体系的密集部署，摸索边缘云特有的技术属性和业务状态。陈美示意：在5G时代，中国电信天翼云在江苏将和阿里云基于高清互动视频、电商购物等畛域独特发展宽泛深刻的边缘云技术钻研，打造全新业务场景和极致用户体验。 国网信通产业团体北京分公司首席运营官石生玺也分享了跟阿里云在边缘云方面的业务单干，国网信通产业团体基于电网变电站打造的边缘云计算节点，构建云边协同整体架构，打造电力分布式边缘算力服务，面向各行业发展边缘云业务开发拓展翻新，通过提供松软的海量根底资源，让算力像电力一样触手可及。 不仅如此，华数传媒智慧家庭事业部总监陈虹分享基于阿里云边缘云节点的广电传媒行业翻新实际，华数传媒围绕网络智能化、业务交融化、产业生态化三大方向，以“云+端“的产品升级为外围切入点，将边缘云计算能力延长至智慧家庭生态级、社区级、城市级的利用场景，从新定义人们对广电行业的认知和了解。 在分论坛的最初，阿里巴巴云游戏资深技术专家彭卫作为云游戏平台畛域的技术大咖，分享了阿里巴巴云游戏平台能力建设、技术演进以及泛游戏行业客户“游戏上云”实际。基于阿里云技术底座的云游戏PaaS服务平台，具备低门槛、高质量、生态反对三大劣势，依靠阿里云边缘云技术能力，用户通过简略交互设施即可享受即点即玩、运行晦涩等最佳游戏体验。 当下，放慢行业数字化转型与翻新已成为全行业共识。阿里云边缘云节点ENS将持续朝着分布式部署、节点自治与协同、小型化计算等方向倒退。阿里云心愿能和产业链合作伙伴一起，发展边缘云畛域前沿技术单干，打造面向未来、面向多行业的边缘云价值利用场景，独特推动边缘云产业倒退。 点击浏览原文或者复制下方链接观看专场嘉宾精彩回放： https://summit.aliyun.com/2021/session/714 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

简介：只有本人吃本人的狗粮，本人做的货色才不“”。Serverless Devs 自倒退之处到当初，曾经经验了几个月的工夫，在这几个月，Serverless Devs 的成长是迅速的，这很大一部分的起因是“咱们在吃本人的狗粮”，咱们置信，如果本人都用不爽的货色，大家肯定很难用的起来。 作者 | 江昱 起源 | 阿里巴巴云原生公众号 只有本人吃本人的狗粮，本人做的货色才不“”。Serverless Devs 自倒退之处到当初，曾经经验了几个月的工夫，在这几个月，Serverless Devs 的成长是迅速的，这很大一部分的起因是“咱们在吃本人的狗粮”，咱们置信，如果本人都用不爽的货色，大家肯定很难用的起来。 明天这篇文章，是一个对于 Serverless Devs 官网建设的文章，文章很简略，也很乏味。 什么是 Serverless Devs? 「Serverless Devs」是由阿里云开源的 Serverless 开发者平台，致力于为开发者提供弱小的工具链体系。通过该平台，开发者能够一键体验多云 Serverless 产品，极速部署 Serverless 我的项目。Serverless Devs 让开发者以更短的门路体验到多个支流云厂商 Serverless 产品，以更快的速度创立和部署 Serverless 利用，以更简略、更自动化的办法进行项目管理和运维，Serverless 我的项目通过该平台实现全自动化后，可节俭 99.9% 的治理老本。 Github 地址：https://github.com/serverless-devsGitee 地址：https://gitee.com/organizations/serverless-devs/projectsServerless Devs 官网：https://www.serverless-devs.comServerless Devs 与 Docusaurus 家喻户晓，开源我的项目的官网不宜太简单，其实简简单单的就好，所以咱们通过了很长时间的比照，最终抉择了 Docusaurus 作为官网的框架选型。那么问题来了，咱们选型完结之后，咱们要如何来建设官网？ 通过一些简略的调研，咱们决定用 Serverless Devs 建设 Serverless Devs 官网，并将其部署到 Serverless 架构上，很绕嘴是吧？然而，这个过程却真的很“经典”： 咱们通过 Serverless devs 初始化了 Docusaurus：s init devsapp/website-docusaurus，这一部分能够参考文档：https://github.com/devsapp/website-example。 讲真，尽管也就是一行代码的事件，然而整个初始化还是比拟“赏心悦目”的，作为一个 Serverless 利用全生命周期的工具，Serverless Devs 在脚手架和疏导层面还是下了很多功夫的： ...

简介：在巍峨的数据库大厦体系中，查问优化器和事务体系是两堵重要的承重墙，二者是如此重要以至于整个数据库体系结构设计中大量的数据结构、机制和个性都是围绕着二者搭建起来的。他们一个负责如何更快的查问到数据，更无效的组织起底层数据体系；一个负责平安、稳固、长久的存储数据，为用户的读写并发提供逻辑实现。咱们明天摸索的主题是事务体系，然而事务体系太过宏大，咱们须要分成若干次的内容。本文就针对PolarDB事务体系中的原子性进行分析。 作者 | 佑熙 起源 | 阿里技术公众号 一 前言在巍峨的数据库大厦体系中，查问优化器和事务体系是两堵重要的承重墙，二者是如此重要以至于整个数据库体系结构设计中大量的数据结构、机制和个性都是围绕着二者搭建起来的。他们一个负责如何更快的查问到数据，更无效的组织起底层数据体系；一个负责平安、稳固、长久的存储数据，为用户的读写并发提供逻辑实现。咱们明天摸索的主题是事务体系，然而事务体系太过宏大，咱们须要分成若干次的内容。本文就针对PolarDB事务体系中的原子性进行分析。 二 问题在浏览本文之前，首先提出几个重要的问题，这几个问题或者在接触数据库之前你也已经纳闷过。然而已经这些问题的答案可能只是简略的被诸如“预写日志”，“解体复原机制”等简略的答案答复过了，本文心愿可能更深一步的探讨这些机制的实现及外在原理。 数据库原子性到底是如何保障的？应用了哪些非凡的数据结构？为什么要用？为什么我写入胜利的数据可能被保障不失落？为什么数据库解体后能够残缺的复原进去逻辑上我曾经提交的数据？更进一步，什么是逻辑上已提交的数据？哪一个步骤才算是真正的提交？三 背景1 原子性在ACID中的地位赫赫有名的ACID个性被提出后这个概念一直的被援用（最后被写入SQL92规范），这四种个性能够大略概括出人们心中对于数据库最外围的诉求。本文要讲的原子性便是其中第一个个性，咱们先关注原子性在事务ACID中的地位。 这是集体对于数据库ACID个性关系的了解，我认为数据库ACID个性其实能够分为两个视角去定义，其中AID（原子、长久、隔离）个性是从事务自身的视角去定义，而C（统一）个性是从用户的视角去定义。上面我会别离谈下本人的了解。 原子性：咱们还是从这些个性的概念登程去探讨，原子性的概念是一个事务要么执行胜利，要么执行失败，即All or nothing。这种特质咱们能够用一个最小的事务模型去定义进去，咱们假如有一个事务，咱们通过一套机制可能实现它真正的提交或回滚，这个目标就达成了，用户只是通过咱们的零碎进行了一次提交，而原子性的重心不在于事务胜利或失败自身；而是保障了事务体系只承受胜利或失败两种状态，而且有相应的策略来保障胜利或失败的物理后果和逻辑后果是统一的。原子性能够通过最小事务单元的个性定义进去，是整个事务体系的基石。持久性：而持久性指的是事务一旦提交后就能够永恒的保留在数据库中。持久性的范畴与视角简直与原子性是统一的，其实也导致了二者在概念和实现上也是严密相连的。二者都肯定意义上保障了数据的统一和可恢复性，而界线便是事务提交的时刻。举例来说，一个数据目前的状态是T，如果某个事务A试图将状态更新到T+1，如果这个事务A失败了，那么数据库状态回到T，这是原子性保障的；如果事务A提交胜利了，那么事务状态变成T+1的那一刻，这个是原子性保障的；而一旦事务状态变成T+1且事务胜利提交，事务曾经完结不再存在原子性，这个T+1的状态就是由持久性负责保障。从这个角度能够推断原子性保障了事务提交前数据的解体复原，而持久性保障了事务提交后的解体复原。隔离性：隔离性同样是定义在事务层面的一个机制，给事务并发提供了某种程度的隔离保障。隔离性的实质是避免事务并发会导致不统一的状态。因为不是本文的重点这里不做详述。一致性：相较于其余几个个性很非凡，一致性的概念是数据库在通过一个或多个事务后，数据库必须放弃在一致性的状态。如果从事务的角度去了解，保障了AID就能够保障事务是可串行、可复原、原子性的，然而这种事务状态的一致性就是真正的一致性吗？毁坏了AID就肯定毁坏C，然而反之AID都保障了C肯定会被保障吗？如果答案是是的话那这个概念就会失去它的意义。咱们能够保障AID来保障事务是统一的，然而是否可能证实事务的统一肯定保证数据的统一呢？另外数据统一这个概念通过事务很难去精确定义，而如果通过用户层面就很好定义。数据统一就是用户认为数据库中数据任何时候的状态是满足其业务逻辑的。比方银行存款不能是正数，所以用户定义了一个非负束缚。我认为这是概念设计者的一个留白，偏向于将一致性视为一种高阶指标。本文次要还是围绕原子性进行，而两头波及到解体复原的话题可能会波及到持久性。隔离性和一致性本文不探讨，在可见性的局部咱们默认数据库具备实现的隔离性，即可串行化的隔离级别。 2 原子性的外在要求下面讲了很多对于数据库事务个性的了解，上面进入咱们的主题原子性。咱们还是须要拿方才的例子来持续论述原子性。目前数据库的状态是T，当初心愿通过一个事务A将数据状态降级为T+1。咱们探讨这个过程的原子性。 如果咱们要保障这个事务是原子的，那么咱们能够定义三个要求，只有满足了下者，才能够说这个事务是原子性的： 数据库存在一个事务真正胜利提交的工夫点。在这个工夫点之前开启的事务（或者获取的快照）只应该看到T状态，这个工夫点之后开启的事务（或者获取的快照），只应该看到T+1状态。在这个工夫点之前任何时候的解体，数据库都应该可能回到T状态；在这个工夫点之后任何时候解体，数据库都应该能回到T+1状态。留神这个工夫点咱们并没有定义进去，甚至咱们都不能确定2/3中的这个工夫点是不是同一个工夫点。咱们能确定的是这个工夫点肯定存在，否则就没方法说事务是原子性的，原子性确定了提交/回滚必须有一个确定的工夫点。另外依据咱们方才的形容，能够揣测出2中的工夫点，咱们能够定义为原子性位点。因为原子性位点之前的提交咱们不可见，之后可见，那么这个原子性位点对于数据库中其余事务来说就是该事务提交的工夫点；而3中的位点能够定位为持久性位点，因为这合乎持久性对于解体复原的定义。即对于持久性来说，3这个位点后事务曾经提交了。 四 原子性计划探讨1 从两种简略的计划说起首先咱们从两个简略的计划来谈起原子性，这一步的目标是试图阐明为什么咱们接下来每一步介绍的数据结构都是为了实现原子性必不可少的。 简略Direct IO 构想咱们存在这样一个数据库，每次用户操作都会把数据写到磁盘中。咱们把这种形式叫做简略Direct IO，简略的意思是指咱们没有记录任何数据日志而只记录了数据自身。假如初始的数据版本是T，这样当咱们插入了一些数据之后如果产生了数据解体，磁盘上会写着一个T+0.5版本的数据页，并且咱们没有任何方法去回滚或持续进行后续的操作。这样失败的CASE无疑突破了原子性，因为目前的状态既不是提交也不是回滚而是一个介于两头的状态，所以这是一次失败的尝试。 简略Buffer IO 接下来咱们有了一种新的计划，这种计划叫做简略Buffer IO。同样咱们没有日志，然而咱们退出了一个新的数据结构叫做“共享缓存池”。这样当咱们每次写数据页的时候并不是间接把数据写到数据库上，而是写到了shared buffer pool 中；这样会有不言而喻的劣势，首先读写效率会大大的进步，咱们每次写都不用期待数据页实在的写入磁盘，而能够异步的进行；其次如果数据库在事务未提交前回滚或者解体掉了，咱们只须要抛弃掉shared buffer pool中的数据，只有当数据库胜利提交时，它才能够真正的把数据刷到磁盘上，这样从可见性和解体恢复性上看，咱们看似曾经满足了要求。 然而上述计划还是有一个难以解决的问题，即数据落盘这件事并不像咱们设想的这么简略。比方shared buffer pool中有10个脏页，咱们能够通过存储技术来保障单个页面的刷盘是原子的，然而在这10个页面的两头任何时候数据库都可能解体。继而不管咱们何时决定数据落盘，只有数据落盘的过程中机器产生了解体，这个数据都可能在磁盘上产生一个T+0.5的版本，并且咱们在重启后还是没方法去重做或者回滚。 下面两个例子的论述仿佛注定了数据库没有方法通过不依赖其余构造的状况下保证数据的一致性（还有一种风行的计划是SQLite数据库的Shadow Paging技术，这里不探讨），所以如果想解决这些问题，咱们须要引入下一个重要的数据结构，数据日志。 2 预写日志 + Buffer IO计划计划总览 咱们在Buffer IO的根底上引入了数据日志这样的数据结构，用来解决数据不统一的问题。 在数据缓存的局部与之前的想法一样，不同的是咱们在写数据之前会额定记录一个xlog buffer。这些xlog buffer是一个有序列的日志，他的序列号被称为lsn，咱们会把这个数据对应的日志lsn记录在数据页面上。每一个数据页页面都记录了更新它最新的日志序号。这一个性是为了保障日志与数据的一致性。 构想一下，如果咱们可能引入的日志与数据版本是完全一致的，并且保证数据日志先于日志长久化，那么不管何时数据解体咱们都能够通过这个统一的日志页复原进去。这样就能够解决之前说的数据解体问题。不管事务提交前或者提交后解体，咱们都能够通过回放日志的计划来回放出正确的数据版本，这样就能够实现解体复原的原子性。另外对于可见性的局部咱们能够通过多版本快照的形式实现。保证数据日志和数据统一并不容易，上面咱们具体讲下如何保障，还有解体时数据如何复原。 事务提交与管制刷脏 WAL日志被设计进去的目标是为了保证数据的可恢复性，而为了保障WAL日志与数据的一致性，当数据缓存被长久化到磁盘时，长久化的数据页对应的WAL日志必须先一步被长久化到磁盘中，这句话论述了管制刷脏的实质含意。 数据库后盾存在这样一个过程叫做checkpoint过程，其周期性的进行checkpoint操作。当checkpoint产生的时候，它会向xlog日志中写入一条checkpoint日志，这条checkpoint日志蕴含了以后的REDO位点。checkpoint保障了以后所有脏数据曾经被刷到了磁盘当中。进行第一次插入操作，此时共享内存找不到这个页面，它会把这个页面从磁盘加载到共享内存中，之后写入本次插入的输出，并且插入一条写数据的xlog到xlog buffer中，将这个表的日志标记从LSN0降级到LSN1。在事务提交的时刻，事务会写入一条事务提交日志，之后wal buffer pool上所有本次事务提交的WAL日志会一并被刷到磁盘上。之后插入第二条数据B，他会插入一条写数据的xlog到xlog buffer中，将这个表的日志标记从LSN1降级到LSN2。同3一样的操作。之后如果数据库失常运行，接下来的bgwriter/checkpoint过程会把数据页异步的刷到磁盘上；而一旦数据库产生解体，因为A、B两条日志对应的数据日志与事务提交日志都曾经被刷到了磁盘上，所以能够通过日志回放在shared buffer pool中从新回放出这些数据，之后异步写入磁盘。 ...

简介：一个合格的性能测试专员该具备哪些技能？性能测试真的仅仅只有测试吗？没那么简略！我是阿里云弹性计算性能测试负责人西邪。 我从 2018 年开始组建阿里云弹性计算的性能测试团队，从要一周实现一组性能测试，到只需 1 分钟就能够触发一组全自动性能测试，到最初后果整顿一键搞定，外部命名为开天斧。 当初开天斧曾经承当整个弹性计算所有的性能测试工作：新技术、新设施、新规格等等，保障了线上的性能稳定性。在性能测试的同时，还要负责解决客户的性能问题。期间还负责了“变形金刚”这个我的项目，把物理机的底层资源管理产品化了，使得当初线上变幻无穷的规格，只需一个模板就能够简略实现。 这里就先跟大家分享下这 3 年在性能测试上的一些播种。 什么是性能测试？性能测试不同于功能测试，功能测试验证的是某个性能是否实现，性能测试验证的是某个性能是否达到。 验证性能就须要很多性能“标尺”，如掂量 CPU 性能：通过 SPEC CPU，UnixBench 等；掂量网络性能用 netperf，iperf，sockperf 等等；掂量存储性能最好用的是 fio，掂量内存带宽性能则是 stream。 上述说的都 micro Benchmark，通常如果某块做的不好，就能够间接提缺点给相干的团队去优化；而客户理论感知的是实在业务场景，那就须要去模仿客户的场景，比方客户常常应用的是 nginx，redis，MySQL 等，通过理论的场景测试，来验证以后服务器的优劣。通过做好性能测试，能力建设本人的底气，做好性能剖析，能力晓得哪里单薄，从而往哪里发力！ 性能测试要做哪些？性能的重要性无需多言，我就间接略过了。一个服务器有 5 大块：CPU、内存、存储、网络、OS。对，就是验证这些模块的性能，下面也简略介绍了下该用哪些工具进行性能测试。然而对于性能测试而言，如果仅仅是一个测试，那太简略了，实际上还须要思考很多。 性能次要能够看以下几个方面： 用什么工具来验证？性能测试的齐备性如何保障？如何疾速继续构建性能测试，手工跑就间接废了，工程化如何构建？性能测试怎么设计？如何针对性去设计？性能测试其实是去测试一个预期。进去的性能数据怎么剖析，重点关注哪个？性能有差别？为什么有差别？虚拟化问题，物理机问题，OS 问题，Benchmark 问题？还是...如何去剖析异样性能数据？这个问题个别是通用业务团队的架构师能力解。可能光谈问题还是形象了点，我再具体举几个例子。 先谈与 CPU 相干： ● Intel、AMD、ARM 差别？指令差别 ● CPU 不同代数差别 ● CPU 主频、基频、睿频、P0-n、P0-1 ● CPU 是否 PIN 住 ● 超线程开关：底层开关、OS 开关 ● NUMA 架构：membind、interleave... ● 电源策略: performance、powersave、C-State 分割 ● TDP: 睿频不符预期时看下 TDP 是否限制住了，很有用！ ● L3 Cache 大小 ● 内存带宽、内存时延 ...

简介：2025年私有云或将服务中国过半数字经济 阿里云研究院 高级策略总监 麻芃 2020年，疫情“黑天鹅”对寰球经济社会运行造成激烈冲击，但数字经济的引擎作用却逆势凸显。去年我国数字经济整体规模达到39.2万亿元，实现9.7%的高速增长，是同期GDP增速的3.2倍，数字经济占GDP比重同比晋升2.4个百分点，达到38.6%。 作为数字技术的重要组成部分，云计算曾经成为数字经济倒退的要害撑持。2019年，寰球35个次要经济体的私有云市场规模与其数字经济体量呈显著的线性关系（见图1）。然而，我国作为第二大经济体奉献了寰球GDP的16.3%（世界银行，2019年数据），但私有云市场规模仅占寰球的5.1%（IDC，2019年数据），与经济体量极不匹配，这可能成为制约我国数字经济倒退的突出问题。基于此，本文比照中国和美国的云计算市场倒退现状，剖析中美云计算市场差别产生的深层次起因，并对中国云计算市场的发展前景进行探讨。 图1 2019年寰球35个次要经济体的私有云市场规模与数字经济体量 注：私有云市场规模数据来自IDC，数字经济体量数据来自中国信息通信研究院，数据均通过对数化计算解决 01 市场规模、私有云占比、SaaS占比（一）中国私有云市场规模仅为美国的10.8%IDC数据显示，2020年，中国私有云市场规模为193.8亿美元，仅相当于同年美国私有云市场规模的10.8%（见图2）。但过来5年，中国私有云市场规模年复合增长率高达61.1%，显著高于美国的23.8%。 图2 2016—2020年中美私有云市场规模及增长率比照 数据起源：IDC （二）中国私有云公有云平分秋色，美国私有云是相对支流信息通信研究院数据显示，2019年中国云计算整体市场规模为1334.5亿元，其中私有云市场规模首次超过公有云，两者之比为1.07：1。因为公有云的市场边界绝对不清晰，少数市场钻研机构没有披露美国公有云市场规模数据。在此，应用公有云部署开销与私有云部署开销的比值，来反映二者市场规模的绝对大小，美国2019年该比值为28.7%（作为比照，中国为70.3%），即美国公有云市场规模显著小于私有云，私有云是美国用户上云的首选项。 （三）中国私有云IaaS占比超六成，美国私有云SaaS占比近七成2020年，中国私有云中IaaS、PaaS、SaaS的市场规模占比别离为61.6%、12.9%和25.5%， IaaS占比最高且近5年来比重仍继续晋升，从2016年的49.6%回升至2020年的61.6%（见图3）；而同年美国私有云中IaaS、PaaS、SaaS的市场规模占比别离为16.6%、16.4%、67.1%， SaaS占比最高但近5年比重继续升高，已从2016年的79.3%降落至2020年的67.1%。 图3 2016—2020年中美私有云市场IaaS、PaaS、SaaS占比变动 数据起源：IDC 02 影响中国云市场的因素（一）中国企业生命周期较短，对数字技术的投入优先级低据美国《财产》杂志报道，美国中小企业平均寿命不到7年，大企业平均寿命有余40年；而中国中小企业的平均寿命仅2.5年，团体企业的平均寿命仅7-8年。美国每年开张的企业约10万家，而中国每年有100万家企业倒闭。中国企业特地是中小企业的生存压力远高于美国企业，这使得中国企业在进行投资决策时，更偏向于把资金投向回报成果间接且显著的中央，如营销渠道的拓展等。对于数字化这种周期绝对较长且回报并不直观的收入，通常并不是中国企业的优先选择，甚至不是必选项。 （二）中国劳动力老本仍较低，企业偏向应用人力而非技术手段解决问题根据美国劳工统计局的公开信息，2018年美国居民人均收入为3.6万美元，其中 “非农就业人口”年收入约5万美元。作为比照，只管中国近年来人均可摆布支出一直晋升，但2018年居民人均可摆布支出仅为28228元（约合4266美元），城镇居民人均可摆布支出仅为39251元（约合5931美元），中国的劳动力老本只是美国的12%左右。然而，中美两国的数字化产品和服务的费用却相差无几。在此背景下，中国企业在面对业务需要时，更偏向于应用劳动力而非信息技术的形式去应答解决——与信息业务零碎相比，应用人力的形式只管效率低下，但短期老本低廉且资源易于复用。 （三）服务业的数字化程度高于其余产业，美国的服务业占比高于中国无论是中国还是寰球，数字化的倒退都是衰亡并昌盛于个人用户；相应地，在商业机构中，离个人用户越近的行业和业务，其数字化的程度也越高，即在国民经济中，第三产业的数字化程度和对云的使用量通常高于第二产业和第一产业。中国信息通信研究院的钻研也证实了这一点：2019年，寰球农业、工业和服务业的数字经济渗透率别离为7.5%、23.5%和39.4%。而中美两国目前的产业结构差别显著：2020年，美国第一、二、三产业增加值占GDP的比重顺次为0.8%、17.7%和81.5%，同年中国的占比程度则顺次为7.7%、37.8%和54.5%（见图4），数字化程度最高、云使用量最多的服务业在美国的产业结构占比显著高于中国。 图4 2020年中美两国国民经济三次产业结构比照 数据起源：中国国家统计局、美国商务部经济剖析局 （四）中国信息基础设施单薄，云化和信息化同步倒退信息化是数字化的根底和前置倒退阶段，美国通过在上世纪八九十年代对信息技术的大规模投入，奠定了松软的信息化根底：数据显示，1993年美国的大公司均已实现办公自动化；90年代前期，世界500强企业中近80%已应用ERP（Enterprise Resource Planning，企业资源管理）软件。在云时代降临前，美国曾经实现信息技术基础设施的建设遍及。而中国在2014年云计算开始衰亡时，整个社会的信息技术基础设施仍在大兴建设中尚未欠缺，这使得近年来中国信息技术基础设施投资和云计算根本同步倒退，IaaS在中国云计算市场中长期占据主导地位。 （五）市场供应能力差距显著，中国产业生态尚在襁褓期产业链不欠缺、供应能力有余，是导致中国云计算市场规模小、SaaS占比低的另一个重要起因。中国云计算产业中的服务器CPU、内存等外围硬件和数据库、中间件等根底软件对国外产品依赖度高，如英特尔占我国服务器CPU芯片市场97%以上的份额。共性根底产品的供应尚能够通过全球化供给解决，而业务利用市场的供应仍在艰巨摸索中：中国的产业门类齐全、个性化需要多，国外SaaS产品只能满足多数需要，而外乡SaaS厂商大多没有亲身经历过信息化时代，不足软件标准化教训，整体SaaS市场目前仍处于指标用户抉择、产品打磨甚至商业模式验证的初期倒退阶段，SaaS供应无论是质还是量均无奈满足市场需求。 03云计算重塑数字产业生态，私有云服务过半数字经济（一）云计算市场规模将持续增长，带动中国信息技术市场收入显著进步1. 数字经济的产业渗透率晋升将拉动云计算市场空间信息通信研究院的钻研结果表明，2019年中国一产、二产、三产的数字经济渗透率别离为8.2%、19.5%和37.8%，除一产的数字经济渗透率略高于寰球平均水平（7.5%）外，二产、三产均低于寰球平均水平（23.5%、39.4%），三次产业的数字经济渗透率更是全副显著低于以美国为代表的发达国家程度（一产13.3%、二产33.0%、三产46.7%），如图5所示。将来几年，在“继续强化农业根底位置”和“放弃制造业比重根本稳固”等国家“十四五”布局的领导下，预计中国三次产业结构比例将根本稳固，服务业占比会略有进步。在此基础上，三次产业的数字化程度将全面晋升，作为数字经济基础设施的云计算得以广泛应用。 图5 2019年中国、寰球和发达国家的三次产业数字经济渗透率比照 数据起源：中国信息通信研究院 2. 新基建为云计算倒退带来空前时机以后，国家放慢部署“新基建”，助力产业降级、培养经济倒退新动能。云计算是新基建的重要组成部分，同时也通过资源管理整合、技术环境部署、网络连接优化、算力弹性调度等方面的劣势能力，成为新基建价值实现和效用晋升的要害撑持。“十四五”是新基建的集中建设装置期，据中国电子信息产业倒退研究院预计，到2025年新基建间接投资将达10万亿元左右，带动投资累计或超17万亿元。在新基建国家策略的引领下，整个社会在将来一段时间内将加大在云计算畛域的投资规模。 3. 快速增长的数据量将撑持云计算的利用空间依据IDC钻研，中国在2020年产生的数据量达13.1ZB，占当年寰球数据总量的21.4%；将来5年，中国数据量将继续快速增长，年复合增长率高达24.4%，超过寰球年复合增长率22.9%，是寰球数据量增长最快的区域之一（见图6）。数据须要通过信息技术基础架构的计算、存储等解决能力施展价值成为生产因素，而云计算已是信息技术基础架构的支流模式——2019年中国云基础架构投资首次超过传统信息技术基础架构投资。快速增长的数据量将撑持中国云计算市场的倒退。 图6 2020—2025年中国数据量及增速预测 数据起源：IDC 将来几年，中国的云计算市场将疾速倒退，进而带动中国的信息技术市场规模持续增长。据中国信息通信研究院预测，到2023年，中国的云计算市场规模将达到3754.2亿元，相比2019年增长1.8倍，2019—2023年复合增长率将高达29.5%。在云计算倒退的带动下，中国信息技术市场规模将持续增长，预计2024年将达到5477.8亿美元，相比2020年扩充23.6%，如图7所示。 图7 2019—2024年中国信息技术市场规模与增长率预测 数据起源：IDC （二）2025年私有云或将服务中国过半数字经济，成为要害基础设施1. 企业数字化意识加强，私有云成为数字化最佳入口在从天而降的新冠疫情中，数字经济所展现出的弱小生命力重塑了人们对数字化的认知，即数字化不再只是企业寻求更好倒退的可选项，而已成为企业面对不确定性的必备生存能力。在企业特地是中小企业构建数字化能力时，私有云具备无可比拟的劣势：其按需付费的模式将传统信息技术我的项目的Capex（Capital Expenditure，资本性支出）转变为Opex（Operating Expense，经营收入），无效升高企业资金压力；而相较于公有云，私有云老本更低、无需保护、扩展性好，是企业低成本疾速取得数字化能力的最佳抉择。 2.劳动力老本一直晋升，私有云劣势逐步浮现只管相较于美国，中国的劳动力老本依然足够低廉，但近年来已继续攀升，特地是2012年以来中国劳动年龄人口连年降落，能够预感，中国的劳动力老本将来将持续回升。与此同时，数字化的产品和解决方案在摩尔定律和边际效应的双重作用下，性能一直晋升而价格一路走低。此消彼长之下，企业将从新扫视劳动力和数字技术两种形式，日渐偏向于通过数字技术手段解决问题，特地是老本劣势显著、利用生态丰盛的私有云。 3.大型政企愈发器重个人用户服务，相干业务偏向私有云部署中国的政府和大型企业进行数字化转型时，通常构建对立的公有云平台，借助该平台买通业务零碎进步流程效率。时至今日，公有云的次要行业用户包含政府、金融等，都愈发强调对公众的服务能力，如政府心愿通过“互联网+政务服务”推动治理现代化和职能转变。而私有云对个人用户的笼罩程度和服务能力是公有云无奈代替的，将来大型政企会把越来越多的个人用户业务部署在私有云上。 在上述等多重因素的独特作用下，中国的私有云市场将实现高速增长。IDC预计2024年中国私有云市场将达到659.5亿美元，是2020年市场规模的3.5倍（见图8）。数字经济的存在和倒退依赖于算力和数据，而信息技术基础设施硬件是承载算力和数据的物理单元。近年来，中国私有云IaaS在信息技术基础设施硬件开销中的占比逐年晋升，2020年已达25.7%，IDC预计2024年私有云IaaS占信息技术基础设施硬件的比重将达到45.3%，如图9所示。思考到私有云IaaS市场规模增速远高于信息技术基础设施硬件市场规模增速，加之私有云服务中有近四成是以PaaS或SaaS模式提供，其相应的硬件资源并不齐全由IaaS承载，由此可见，私有云或将于2025年服务中国过半数字经济体量，成为至关重要的数字经济基础设施。 图8 2020—2024年中国私有云市场规模与增速 数据起源：IDC 图9 2019—2024年私有云IaaS占信息技术基础设施硬件比例变动预测 数据起源：IDC （三）云计算将引领新一轮技术创新，重塑数字产业生态1. 云计算成为我国构筑信息技术产业倒退新劣势的突破口云计算作为新型基础设施的外围环节，是大数据、人工智能等新一代数字技术的要害底座。在以云为外围的新技术体系下，中国通过把握技术更新带来的历史时机，迅速放大了与发达国家信息技术产业的差距——在IDC颁布的2020年寰球私有云IaaS市场服务商前7名中，有3家来自中国。这使得中国无望从原来欧美长期主导的以大型机为外围的旧有技术体系中解围，以云计算为突破口抢占下一个科技制高点。 2. 借助云对产业链上下游产品的弱小定义能力，我国数字产业无望做大做强云计算能够向下定义芯片、存储和网络等外围硬件的演进，向上从新布局操作系统、数据库、中间件、大数据平台等根底软件的倒退门路。外围硬件方面，我国云计算产业已成规模，能为服务器CPU等芯片提供倒退空间：利用分布式部署容错性强的特点，单个芯片故障不会影响整体性能，云计算人造成为芯片产业的最佳试验场和孵化器，在此推动下，以“含光800”为代表的芯片已实现规模化利用。与此同时，简直所有软件特地是根底软件都须要进行云上重塑，这为我国软件行业提供了“换道超车”的契机：以数据库为例，过来中国市场长期被国外巨头垄断，进入云时代后，我国数据库产品“PolarDB”已位列寰球云数据库市场份额第三，跻身寰球一流行列。 3. 云的定位从信息根底资源向数字化操作系统扩大，SaaS成为厂商发力重点长期以来，云计算被视为一种普惠、灵便的根底资源，而随着整个社会数字化转型的继续推动，仅是根底资源的云化已不能满足企业需要，企业更加冀望业务利用零碎的全面云化。 云计算被视为可提供“数字化底座+数字化操作系统”的社会翻新平台。其中，底座解决的是算力撑持问题，操作系统则为企业提供富集的应用服务，帮忙企业实现业务降级、经营提效、体验优化和组织降级。相应的，云计算的重心随之上移，SaaS成为厂商发力重点：传统软件厂商如用友、金蝶等均以云为外围策略继续推动转型；SaaS守业公司数量快速增长；互联网厂商则以钉钉等协同办公产品为平台，通过构建生态为用户提供行业解决方案。将来几年，中国SaaS市场生态将日渐成型，服务能力疾速晋升。 ...

简介：顾名思义，和操作系统 .iso 镜像或 Docker 镜像相似，集群镜像是用肯定的技术手段把整个集群的所有文件以肯定格局打成的一个资源包。 作者 | fanux.中弈 起源 | 阿里巴巴云原生公众号 什么是集群镜像 顾名思义，和操作系统 .iso 镜像或 Docker 镜像相似，集群镜像是用肯定的技术手段把整个集群的所有文件以肯定格局打成的一个资源包。 比照单机和集群会发现一些的乏味景象： 单机有计算、存储、网络等驱动；集群有 CNI/CSI/CRI 实现像是集群的驱动。单机有 ubuntu centos 操作系统；集群中能够把 Kubernetes 看成云操作系统。单机上能够运行 docker 容器或虚拟机；相当于一个运行的实例，集群上也有运行着 K8s 的实例。单机上有虚拟机镜像，docker 镜像；随着云计算技术的倒退，集群上也会形象出相似的镜像技术。以基于 Kubernetes 的集群镜像为例，外面蕴含了除操作系统以外的所有文件： docker 依赖的二进制与 systemd 配置、dockerd 配置，以及一个公有的容器镜像仓库。Kubernetes 外围组件二进制、容器镜像、kubelet system 配置等。利用须要用到的 yaml 配置或 helm chart，以及利用的容器镜像。其它脚本、配置与二进制工具等利用运行须要的所有依赖。同样，集群镜像运行时必定不是起一个容器或者装在一台机器上，而是这个镜像能够间接装置到多台服务器上或者间接对接到私有云的基础设施上。 sealer 介绍 sealer是阿里巴巴开源的集群镜像的一个实现形式，我的项目地址：\_https://github.com/alibaba/sealer\_ 。 Docker 解决了单个容器的镜像化问题，而 sealer 通过把整个集群打包，实现了分布式软件的 Build Share Run!!! 试想咱们要去交付一个 SaaS 利用，它依赖了 MySQL/ES/Redis 这些数据库和中间件，所有货色都在 Kubernetes 上进行编排，如果没有集群镜像时，要做如下操作： ...

简介：Ganos空天数据库引擎是李飞飞率领的达摩院数据库与存储实验室研发的新一代地位智能引擎，采纳了平台即服务、多模交融、计算下推和云原生全新解决架构，为政府、企事业单位、泛互联网客户提供挪动对象、空间/时空、遥感多模态数据混合存储、查问与剖析服务，解决空天大数据应用流程简单、应用门槛高、利用效率低等问题，次要利用于城市治理、交通物流、自然资源、航空航天、物联信息等畛域。 作者 | 谢炯 起源 | 阿里技术公众号 Ganos空天数据库引擎是李飞飞率领的达摩院数据库与存储实验室研发的新一代地位智能引擎，采纳了平台即服务、多模交融、计算下推和云原生全新解决架构，为政府、企事业单位、泛互联网客户提供挪动对象、空间/时空、遥感多模态数据混合存储、查问与剖析服务，解决空天大数据应用流程简单、应用门槛高、利用效率低等问题，次要利用于城市治理、交通物流、自然资源、航空航天、物联信息等畛域。 一 研发背景1 什么是空天大数据随着挪动互联网、地位感知技术、对地观测技术的疾速倒退，以挪动对象、空间/时空、遥感为代表的空天传感数据呈爆发式增长，成为新基建和数字化框架的重要根底。 广义上，空天数据（aerospace data）次要来自天基和空基，例如基于天基平台的GNSS（寰球导航卫星零碎）数据等，基于空基平台的航拍影像、视频数据等。狭义上，咱们将空天数据定义为涵盖Spatial（空，即天文空间）和Space（天，即宇宙空间）的地海空天各类与地位相干数据，也即本文所述空天大数据。天问一号携祝融号在火星的登陆将为咱们传来大量火星遥感影像和空间信息，使大家最直观地感触到来自地球之外的空天大数据。 以空天大数据助力疫情防控为例，咱们能够利用人、车等挪动对象的轨迹数据进行流传源追踪和疑似人群排查；利用海事通信卫星提供的AIS船舶动静数据分析疫情对港口贸易的影响等等。在这类简单剖析场景中，遥感影像、挪动对象、物联通信等新型空天传感数据的疾速获取、存储与高效查询处理为智能辅助决策起到关键作用。 2 空天大数据面临的挑战数据结构简单多样难以治理 相比文本型、图片型等非结构化数据，空天数据具备类型多样、高度非结构化、大单体、多维度等特色，给一体化数据管理和高效查问检索提出了极大挑战。例如： 百万点形成的超大简单实体化对象，如长江/黄河、简单修建、灌区等；千万点形成的挪动对象时空轨迹，如车、船、航空器等超长行程数据；万亿像素形成的大范畴高分辨遥感影像间断笼罩……数据动态变化要求更高维度计算 传统空间数据更多表白动态地物，如河流、铁路、修建等。随着挪动APP和IoT等技术的遍及利用，以时空挪动对象（人、车、船等）为代表的动态数据越来越多。记录地位的动态变化，须要零碎提供时空建模、时空索引和时空剖析计算能力。 大数据和大计算场景性能不佳 非结构化、大对象和动态性决定了空天数据的潜在大体量，单表小则千万级，大则百亿级场景将不再是个别现象，因而，对系统的存储老本、弹性能力、读写效率必将提出更高要求。当大规模数据要求提供在线化剖析计算服务，传统基于离线预处理（如离线切片）形式的生产和利用流程将面临极大挑战。 智能化须要多模态数据交融治理 文本、时序、时空、图（Graph）等多模态数据交融治理和跨模查问剖析是智能化的重要根底。单模态数据智能化无奈无效撑持简单业务知识发现并真正探寻事物倒退法则和趋势，因而，从部分模型专业化到全局多模通用化仍存在较大鸿沟，须要从根底数据库状态层面倒退全新架构。 3 达摩院独创空天数据库针对此，达摩院研发新一代空天数据库引擎Ganos，从数据库与存储最底层解决空天数据的一体化治理、疾速穿插交融查问以及高效剖析解决挑战，实现 “亿级规模”地物多边形全图快显拜访、秒级效率的“千万平方公里”遥感影像时空动静拼图等先进技术，具备“一体化交融治理、大规模弹性服务、核心技术自主可控”等劣势，可面向空、天、地、海全域空间利用，成为撑持天联网和星云产业倒退的新型数据库基础设施。 二 空天数据处理架构演进1995年，美国ESRI公司为了满足2B市场需求，革命性地推出了空间数据引擎SDE——基于商业关系数据库+中间件架构建模咱们的世界，影响了一代人。20多年过来了，随着Hadoop、Spark以及分布式数据库技术的演进，分布式空间数据引擎近年来失去了疾速倒退，在一些大规模空间数据分析解决场景中施展了独特劣势。那么，空间数据处理的下一站演进将去哪里？ 咱们认为，将空天信息处理融入PaaS服务（Platform as Services），以云数据库与存储平台为外围解决空天数据的实时接入、高效存储和弹性计算，是撑持时空信息云化架构向纵深倒退的必然趋势。咱们将之合成为平台即服务、多模交融、计算下推和云原生四个方向的架构演进。 1 平台即服务与传统基于通用数据库作为存储，外置中间件状态的时空数据引擎计划不同，新一代空天数据库引擎采纳了平台即服务架构。该架构将空天引擎内置于云上OLTP数据库、OLAP数据仓库、数据湖以及NoSQL多模数据库等不同零碎，相比传统计划在易用性、计算效率和事务一致性解决上存在先天劣势，且将来基于SQL标准化也能疾速建设跨平台能力。通过产品组合可提供从在线解决到在线剖析，到离线计算再到离线存储的海量空天大数据解决方案。 2 多模交融传统时空数据处理以地理信息系统（GIS）或遥感图像处理平台软件为外围，强调平台专业性，但因为业余强化，造成业余度较高的半封闭零碎，也会反向弱化和其余多模类型数据的交融解决能力；从IT视角登程，空天/时空数据将去中心化，成为各类多模数据的一类，并借助数据库建设普适关联，升高业余门槛。通过普适关联，将空天/时空数据与通用数据、文本、时序、图等多模数据一体化治理和解决，这种泛时空求解能力为大数据简单业务开发将提供更大灵活性。 3 计算下推计算下推是IT技术架构演进的一个重要趋势。将空间信息系统业务要害计算下推数据库与大数据系统，让计算离数据更近，能够间接利用存储计算下推、并行化解决、GPU/FPGA异构计算减速能力实现数据本地计算，岂但能升高因大量两头后果数据网络传输导致的IO提早，也能简化业务逻辑并整体晋升业务零碎性能。 4 云原生新一代空天数据库引擎脱胎于私有云，并由私有云走向混合云。咱们认为，数据要灵便，算法补；算法要灵便，算力补。举个例子，传统空天数据利用须要大量做切片预处理，导致数据利用不灵便。为了数据更灵便，业界引入了事后动态缓存+动静切片的算法，但这种算法显然很简单；那么算法要灵便，必须要算力补，即借助足够弹性的算力来保障繁多算法的纯正性和普适性。这就要借助云原生能力。云原生的实质是资源池化，即通过资源池化实现弹性服务和规模化。云服务的实质就是算力经济。 三 积沙成塔，做好底座遵循平台即服务、多模交融、计算下推和云原生理念，达摩院设计并实现了新一代空天数据库引擎Ganos。咱们在寰球空天网格编码、空天多模并行查询处理、大规模矢量图形快显减速等空天数据处理关键技术上一直摸索并技术冲破，建设了数据存储、索引、查问、剖析和可视化撑持技术体系，在空天多模态数据处理外围畛域造成差异化竞争力。 1 整体框架Ganos取名于大地女神盖亚（Gaea）和工夫之神柯罗诺斯（Chronos），代表空间+工夫的深度联合。它并不是一款独立的云产品，而是一套空天\时空\多维数据存储与解决解决方案。零碎底层提供了撑持海陆空天大规模数据存储能力，包含批量疾速写入、空天多维表白、多维时空索引和冷热多级存储等，下层提供数据治理、交批查询处理以及剖析计算与操作。 Ganos能力框架 从产品构造上，Ganos将空天数据处理能力融入云关系型数据库RDS PG、云原生关系型数据库PolarDB、云原生数据仓库AnalyticDB PostgreSQL、多模数据库Lindorm、数据湖剖析DLA，基于产品组合构建空天数据库大数据一体化底座。进一步联结AI Earth（达摩院公布的首个泛自然资源行业AI引擎）、OSS对象存储、以及微服务框架等技术生态体系，为用户构建免切片存储、时空一体、动静计算、智能剖析全新架构的云原生空天大数据平台提供了外围能力撑持，可广泛应用于城市治理、自然资源、应急治理、交通物流等不同行业。 Ganos生态系统 2 空天多模与寰球网格编码单一化模型已无奈满足以后数字化新场景利用，Ganos从底层开发空天多模型引擎，已原生反对10多大类空天数据的存储、查问和剖析计算。在此基础上，基于与多模数据库Lindorm集成，实现键值、宽表、时序、时空、搜寻、文件等多模数据的一体化治理和解决。 空天多模型引擎 在此基础上，Ganos基于GeoSOT寰球网格剖分实践，联合PolarDB引入了一种全新的网格数据类型geomgrid，反对空天对象打码和网格对象计算等操作。空天网格码是在GeoSOT地球空间剖分实践根底上倒退出的一种离散化、多尺度区域地位标识和度量体系。该体系的外围是用一种新的办法，将地心至地上6万公里的地球空间剖分成数以兆亿个大小不等、多尺度、高精度的网格群，同时为每一个网格赋予寰球惟一的整形数标识编码。零碎能够无缝对接北京大学/旋极伏羲基于GeoSOT的网格大数据平台构建空天数据库-网格大数据一体化解决方案。原生网格数据类型的引入加强了空天数据库的对立时空标识能力、空天计算减速能力和基于地球空间网格的数据共享能力。 空天网格剖分示意图 3 存计拆散与多级并行计算减速基于PolarDB，Ganos采纳了存计拆散和分布式共享存储架构。计算和存储拆散，将原有一体化设计的数据库的各个组件（计算/内存/存储）齐全解耦，造成可独立伸缩的资源池。同时，为升高存计拆散带来的写入和查问提早，共享存储系统采纳了端到端全用户态模式，交融了 RDMA、SPDK 等高速数据传输和存取软硬件技术，以及与近存储计算介质硬件联合的DB解决下推技术，无效地晋升了空天数据的存储规模和解决能力 。 基于存计拆散和分布式共享存储架构，Ganos进一步将两阶段查问加强和多节点并行查问有机联合，实现了跨节点空天并行查询处理框架。其中，三管齐下晋升数据并行处理性能： 采纳分布式共享存储架构无效防止了数据跨节点shuffle带来的网络IO开销；基于拓扑索引的粗过滤加精过滤两阶段查问大幅晋升空天数据查问过滤性能；跨节点并行、节点内并行加算子级并行造成多级并行框架。经权威第三方测评结果表明，2亿级图斑做叠加剖析并统计面积，采纳80过程并行计算，10分钟即可出后果（两头蕴含裁剪出7800万超大后果集），比传统大数据计划至多快出一个数量级。 基于两阶段优化的跨节点并行查询处理框架 ...

简介：5月20日，郑州商品交易所（以下简称“郑商所”）日前与阿里云达成技术单干，通过引入阿里云AnalyticDB云原生数据仓库，进一步晋升郑商所数据平台数据分析效率和用户体验。5月20日，郑州商品交易所（以下简称“郑商所”）日前与阿里云达成技术单干，通过引入阿里云AnalyticDB云原生数据仓库，进一步晋升郑商所数据平台数据分析效率和用户体验。 据记者理解，郑商所是国务院批准成立的首家期货市场试点单位，由中国证监会治理，是重要的国家金融基础设施之一，交易产品范畴笼罩粮、棉、油、糖、果、能源、化工等多个畛域。截至2021年3月底，郑商所累计成交量为6.3亿手，成交金额为24.1万亿元 。 随着所内大宗商品范畴及交易量的快速增长，郑商所原先的数据平台在多年运行后，容量曾经靠近饱和，无奈高效撑持数据深度剖析、即席查问等服务，并且存在扩容周期长、老本低等问题。 综合考量之下，郑商所决定引入阿里云AnalyticDB云原生数据仓库，作为底层存储计算撑持平台，以保障郑商所数据平台数据分析效率和用户体验。 郑商所相干技术负责人指出：“阿里云AnalyticDB在后期内部测试中性能体现良好，产品成熟度高，并且在金融行业领有多个胜利落地案例，置信将为郑商所数据平台建设提供无力的技术撑持。” 据理解，AnalyticDB是阿里云旗下通过大规模验证的剖析类数据库，在权威评测机构TPC组织的TPC-DS和TPC-H测试中取得性能和性价比寰球第一的问题。AnalyticDB撑持多年双十一购物节海量数据分析，在阿里团体多业务场景中取得宽泛应用，并且宽泛服务于期货、证券、银行、保险等畛域的客户，助力客户实现数据价值在线化。 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

简介：与时代并肩的数字创新者 数字翻新的时代，每个行业都涌现出一批“数字创新者”。他们在这个时代里站进去，发明了新观点、新赛道、新价值，他们彼此并肩，更与时代并肩。 这个五月，阿里云联结《智族GQ》杂志，邀请了十位#与时代并肩的数字创新者#，用一本数字翻新特辑，记录数字创新者涌动的时代。 **李佳琦 电商主播 站在 数字浪头之前 ** 成为“李佳琦”之前，李佳琦并无心将本人推向任何洪流的前端——只管这一场面现在是不争的事实，也有有数人将他称为流量时代塑造的必然。这位28岁的年轻人，以语言与数字作为与世界沟通的介质，与这个时代的前沿浪潮一直交汇。 李佳琦只做一件事：让抉择变得容易。在你抉择之前他曾经充沛筛选过，以丰盛的教训与牢靠的谈吐驯服顾客的心。没有多余的话，只给精准的倡议，“这支肯定要买。”语气斩钉截铁。 这句话起初到底能带他去多远的中央，那时的李佳琦还不晓得。登程前，并不是所有人都筹备好了。并非所有主播都学习过数字之下庞杂而简约的算法内核——但每个人都在全力以赴尝试靠近。它悄无声息地隐匿在一波又一波挤进直播间的人流中，日复一日地上涨累积，再转化成为任何你可能设想或设想不到的商业可能。 现在李佳琦直播已超千场，当初做主播也吃过苦头。不会剪辑折腾到中午、口干舌燥观看者寥寥，低迷期间并不算短暂。一次偶尔的小二人工举荐，他开始在屏幕上看见观看人数、曝光量数字令人咋舌地飞快增长，但李佳琦深知其间心路漫长。点击量、转化率、观看人数、GMV，以及每天花三四个小时试用的产品数量……有数的数字开始追着他向前。最开始李佳琦被动地领会到数字的存在，但起初事件就不再一样。流量是硬数据。能让没急躁的观众在直播间停留一小时的秘诀，李佳琦靠数据解答，也开始被动靠数据自我证实。 但流量逻辑自身也一直有突飞猛进的变动。怎么办？李佳琦一贯是个临场反馈很强的人。他把本人称为李佳琦方程式，一个高速运转且按需反馈的高效处理器。直播时李佳琦通常不看摄像机，他的眼光集中在评论区及流量屏幕，针对观众评论疾速做出反馈。什么问得最多、哪句解说反馈最热烈、最无效带动观众下单积极性的关键词是什么，屏幕高速滚动，他必须在分秒之间抓住要害。脑海中过滤一遍，记住，下播盘点，工夫长了，就形成无比贵重的一手教训，并且永远追随前端变动即时更新。 往年的李佳琦不再只是李佳琦。他在一次采访中说，直播让他意识到，“中国女生从跟着他人学如何让本人变美，到当初曾经是本人懂得如何让本人变美了。”他的尾音判若两人地拖得很长，带着即刻打动的鼓励力，嘴角上扬，眼神热切。好像那些产品不再只是商品，而是由李佳琦流传进来的美的痕迹。 **聂星华 阿里巴巴驻平顺特派员 数字农业 县长直播和在线教育 ** 聂星华在2019年通过了他职业生涯最高规格的面试——阿里巴巴驻平顺特派员。面试官是阿里巴巴团体的3个合伙人，面试官通过后，合伙人决定最初拍板录取。第一批阿里的脱贫特派员有4个，聂星华是其中之一。2019年6月，聂星华坐火车到郑州，转车到安阳，再坐汽车到达平顺，这个夹在两座大山之间的国家级贫苦县城。 两个月，他跑遍了平顺县下的12个乡镇，深度调研了40 多个村庄。他去教育局、农业局、卫健委、电商办，理解它们对本人主管工作的认识，存在哪些问题，接下来有什么打算，聂星华再找出阿里能够提供帮忙的中央。最迫切的是电商卖货。 聂星华决定动员当地村民做电商，直播卖货。 来平顺之前，聂星华搞了一次直播，把平顺的党参、花椒芽菜、驴肉酱带进薇娅的直播间。他认为，要帮忙当地脱贫，首先要影响村民的意识，但当他分割平顺村民的时候，发现居然没有人据说过淘宝直播，最初，只有一家网店报名加入，那个侥幸的店主通过薇娅直播卖出了50 多万元的产品。 聂星华晓得，仅仅通过大主播公益卖货不能从根本上为平顺脱贫，他认为“扭转意识是要害，特地是领导干部的意识”。 2019年7月23 日，县长秦军第一次走进直播间，3小时销售额超过100万元。秦军十分震撼，说真没想到，对着手机这么吆喝一下能卖这么多农产品，看来咱们的产品的确有市场需求。起初，秦军开政府工作会议都会提到倒退电商。 这两年，平顺县举办了二十多期电商培训班，电商培训五千多人次， 全县新增了四百多家网店。2019 年， 平顺县的电商销售额超过了1 个亿，2020 年达到1.78 亿元。 除了电商，聂星华还为平顺县的中小学搭建了钉钉数智化教育平台。他发现平顺简直每个学校都有电脑、电子白板，但匹配的软件和线上优质课程资源较少。尤其是农村学校，老师资源匮乏，只有数学、语文等主科老师，没有专职老师教自然科学、艺术、音乐等副科。遍及钉钉当前，孩子们能够在平台享受到和城市雷同的教育资源。 2020 年6 月，聂星华的任职期满了，县长心愿他再留任一年，他许可了。接下来，平顺县将建设数字化农业示范基地，使用阿里云的数据能力，晋升农产品的品质。比方，在地块上搁置传感器，监测土壤的肥力、湿度，再依据这些数据决定何时施肥、何时浇水，迷信地领导农民种植。 **薛兆丰 经济学家 被时代浪潮推动 ** 薛兆丰被认为是经济学赛道的“爆款”。2015年，他的经济专栏文集登陆罗辑思维。2017年2月，他在“失去”APP上开设《薛兆丰的经济学课》。到2021年2月，在4年工夫里，有超过53万人退出学习， 是“失去”APP订阅人数最多的付费音频课程，亦成为常识付费畛域的标志性作品。 2018年，薛兆丰登上综艺节目《奇葩说》第五季。因为书籍踏入常识付费畛域，继而接到综艺节目邀请，这些时机与契机环环相扣。三段式的经验简直等分了薛兆丰近十年的生命，也对应着十年里传播媒介从文字到音频再到视频的进化迭代。 “我没有那么高瞻远瞩，我并没有洞察数字时代的支流。我经常是被动的，只管我也早有筹备。”被时代和科技的倒退裹挟前行，薛兆丰本人的故事和他经常分享的工业革命的故事一样，是技术与时代对个体的成就。 2016年8月，罗振宇专门约薛兆丰，压服他开启付费专栏。他向薛兆丰列举了一系列理由：普通话带点儿口音不是问题；能够把打磨课程的过程视为撰写著述的过程；课程品质有团队把关，等等。在此之前，在罗辑思维售卖的著述，也让薛兆丰意识到，这个平台上汇集了一大群爱学习的人。 真正动起来是在当年11月。薛兆丰如临大敌，专门组建了一支“团队”，做出了他心目中的“第一讲”。发给过后负责课程品质把关的曾捷，没想到对方斩钉截铁地回复他，“不行”。站在寒风里，他和曾捷打了一个小时的电话，不行的理由没有听明确，他只记得对方说的一句话：“你改得再好，念得再好，都是念的。” 为了阐明如何不念稿子“说”经济学，曾捷把薛兆丰请去公司，拉上产品经理小娴，一起进录音棚。对着麦克风，薛兆丰一句话也说不出来。“我对曾捷说，先把你的麦克风关了，我通知你我想说什么。我说完，曾捷通知我，不必关啊，你就这么说。这就开启了我‘说’经济学的第一课。” 2017年2月，《薛兆丰的经济学课》在“失去”正式上线。按照以往的教学教训，薛兆丰的课程循序渐进。一上来讲战俘营，讲马粪抢夺，讲铅笔的故事，这些看似与经济学无关的故事和“闲笔”，环环相扣，通往价格、需要定律和一个又一个经济学常识。用如此深入浅出的语言为公众解说经济学，《薛兆丰的经济学课》开了先河。2017年5月，订阅用户达到10万；11月，订阅用户超过20万。 **樊东卫 中国科学院 国家天文台副研究员 “上云 ” 让全民地理变成可能 ** 樊东卫往年35岁，广西壮族人。他从小就喜爱地理，他的父母都是老师，家里没有田地，同学忙农活的时候，他就一个人闷在家里看《十万个为什么》，其中和地理相干的常识，他特地感兴趣，他想晓得宇宙是怎么来的，将来又会走到哪里去。 上大学时，他抉择在广西师范大学读计算机专业，其间选修了一门地理基础知识的课。到了大四，他的很多同学都当了老师，而他决定考研。有一天早晨，他在网上搜寻发现中科院国家天文台在招研究生，其中包含了计算机相关钻研方向，他决定报考，第二年，他到了北京。 樊东卫的钻研方向是地理信息技术，这是一个交叉学科，通过地理数据的解决和剖析，在大规模的地理星表之间寻找关联。每个望远镜观测的数据量十分宏大，不同的设施有不同的数据表，樊东卫的钻研方向就是这些数据之间的关联，这样就能通过不同望远镜的数据观测到同一颗星的信息，再对这颗星做进一步的剖析。 “咱们是搞计算机的人里最懂地理的，又是搞地理的外面最懂计算机的。”樊东卫说。 2015年，樊东卫和共事们开发了公众超新星搜查我的项目，地理爱好者只须要登录网站，就能够在线搜查超新星。 搜查超新星十分考验急躁和目力，爱好者须要认真查看天体所在位置的历史图和当晚观测的新图片，如果新图上显示出显著的亮斑，这个亮斑就可能是超新星。爱好者把这个发现上报给管理员，由管理员作进一步判断。 目前，星明天文台发现了3颗彗星，7颗小行星，52颗超新星。其中通过运行在阿里云平台上的公众超新星搜查我的项目发现的超新星或新星有32颗。第一个通过该我的项目搜查到超新星的是来自石家庄的10岁小朋友廖家明。发现者当中还有一位很励志的“95后”湖北小伙赵经远，他患有“肌张力阻碍”，无奈失常听、说和行走。在网站上，他发现了4颗超新星、2颗新星，看完了31万张图。通过数据平台， 渺小的人类个体足不出户，也能摸索茫茫宇宙。 随着观测设施和技术的倒退，天文学家获取、存储、解决的数据量越来越宏大，须要大量使用如云存储、云计算等技术进步计算能力。2009年，中国建成了郭守敬望远镜（LAMOST），这是世界上光谱获取率最高的地理望远镜，中国也因而领有世界上最大的光谱数据库。2016年在贵州，“天眼”FAST落成，是世界上最大的射电望远镜。 2016年，国家天文台和阿里云达成了策略单干，通过虚构天文台的模式共享数据，独特推动天文学科研和科普教育工作。 “阿里云是一个很好的大数据处理平台”，樊东卫说。此外，国家天文台也建了本人的专有云平台，一些不罕用的数据存储在专有云，其余数据， 尤其像公众超新星搜查我的项目这样的数据就存储在阿里云。 ...

简介：Vineyard 是一个专为云原生环境下大数据分析场景中端到端工作流提供内存数据共享的分布式引擎，咱们很快乐发表 Vineyard 在 2021 年 4 月 27 日被云原生基金会（CNCF）TOC 承受为沙箱（Sandbox）我的项目。 作者 | Vineyard 团队 起源 | 阿里巴巴云原生公众号 Vineyard 是一个专为云原生环境下大数据分析场景中端到端工作流提供内存数据共享的分布式引擎，咱们很快乐发表 Vineyard 在 2021 年 4 月 27 日被云原生基金会（CNCF）TOC 承受为沙箱（Sandbox）我的项目。 Vineyard 我的项目开源地址： https://github.com/alibaba/v6d 我的项目介绍现有的大数据分析场景中，对于端到端工作，不同的子工作之间通常应用例如 HDFS、S3、OSS 这样的分布式文件系统或对象存储系统，来共享工作之间的两头数据，这种形式在运行效率和研发效率上存在诸多问题，以下图所示的一个风控作业工作流为例： 工作流中不同工作之间为了共享两头数据，前一个工作将后果写入文件系统，实现之后，后一个再将文件读出作为输出，这个过程带来了额定的序列化及反序列化、内存拷贝、以及网络、IO 的开销，咱们从历史工作中察看到有超过 60% 的工作为此破费了 40% 以上的执行工夫。对于生产环境，为了高效地解决某一个特定范式的问题往往会引入一个新零碎（例如分布式图计算），但这样的零碎往往难以间接与工作流中的其余零碎无缝连接，须要很多反复的 IO、数据格式转换和适配的研发工作。应用内部文件系统共享数据给工作流带来了额定的中断，因为往往只有当一个工作齐全写完所有后果，下一个工作能力开始读取和计算，这使得跨工作的流水线并行无奈被利用。现有的分布式文件系统在共享两头数据时，特地是在云原生环境下，并没有很好的解决分布式数据的地位问题，造成网络开销的节约，从而升高端到端执行效率。为了解决现有大数据分析工作流中存在的上述问题，咱们设计和实现了分布式内存数据共享引擎 Vineyard。 Vineyard 从以下三个角度来应答上述几个问题： 为了使端到端工作流中工作之间的数据共享更加高效，Vineyard 通过内存映射的形式，支持系统间零拷贝的数据共享，省去了额定的 IO 开销。为了简化新计算引擎接入现有零碎所须要的适配和开发，Vineyard 对常见的数据类型，提供了开箱即用的形象，例如 Tensor、DataFrame、Graph，等等，从而不同计算引擎之间共享两头后果不再须要额定的序列化和反序列。同时，Vineyard 将 IO、数据迁徙、快照等可复用的组件以插件的模式实现，使其可能很灵便地按需注册到计算引擎中去，升高与计算引擎自身无关的开发成本。Vineyard 提供一系列 operators，来实现更高效灵便的数据共享。例如 Pipeline operator 实现了跨工作的流水线并行，使得后续工作能够随着前序工作输入的产生，同时进行计算，进步了端到端整体效率。Vineyard 与 Kubernetes 集成，通过 Scheduler Plugin，让工作的调度可能感知所须要的数据的局部性，在 Kubernetes 让单个工作的 Pod 尽可能地调度到与 Pod 所需的输出数据对其的机器上，来减小数据迁徙须要的网络开销，晋升端到端性能。在初步的比照试验中，相比于应用 HDFS 来共享两头数据，对于评测工作，Vineyard 可能大幅升高用于替换两头后果引入的额定开销，对于整个工作流的端到端工夫有 1.34 倍的晋升。 ...

简介：台湾作家林清玄在承受记者采访的时候，如此评估本人 30 多年写作生涯：“第一个十年我才华横溢，‘贼光闪现’，令周边黯然失色；第二个十年，我终于‘宝光现形’，不再去抢风头，反而与身边的漂亮井水不犯河水；进入第三个十年，热闹落尽见真醇，我进入了‘醇光初现’的阶段，真正体味到了境界之美”。 作者 |  韩堂、柘远、陶醉 起源 | 阿里巴巴云原生公众号 前言台湾作家林清玄在承受记者采访的时候，如此评估本人 30 多年写作生涯：“第一个十年我才华横溢，‘贼光闪现’，令周边黯然失色；第二个十年，我终于‘宝光现形’，不再去抢风头，反而与身边的漂亮井水不犯河水；进入第三个十年，热闹落尽见真醇，我进入了‘醇光初现’的阶段，真正体味到了境界之美”。 长夜有穷，真水无香。领略过了 K8s“身在江湖”的那种触目惊心以及它那生态系统的繁花似锦，该是回过头来体味高可用体系境界之美的时候了。毕竟仅能经得起敲打还是不能独步武林的！ 在 K8s 高可用畛域有一个问题被大家所熟知，那就是 K8s 单集群规模带来的 SLO 问题，如何继续保障？明天就以单集群的规模增长带来的高可用挑战来作为引子来给大家一个体感。 ASI 单集群规模撑持超过社区的 5000 台，这是个十分有意思且具备极大挑战的事件，对须要进行 K8s 生产化的同学，甚至具备 K8s 生产化教训的同学来说，肯定会是个感兴趣的话题。回看 ASI 单集群规模从 100 到 10000 的倒退之路，随同着业务的增长和翻新带来的每一次集群规模增长，都在逐渐使咱们的压力和挑战产生量变。 ASI：Alibaba Serverless infrastructure，阿里巴巴针对云原生利用设计的对立基础设施，ASI 是阿里公共云服务 ACK 的阿里团体企业版。 大家晓得 K8s 社区只可能撑持五千个节点，当超过这个规模时，会呈现各种性能瓶颈问题，比方： etcd 呈现大量的读写提早。kube-apiserver 查问 pods/nodes 延时很高，甚至导致 etcd oom。控制器无奈及时感知数据变动，如呈现 watch 数据提早。以电商场景为例，100 节点增长到 4 千节点的时候，咱们提前针对 ASI apiserver 的客户端和服务端做了大量的性能优化，从 apiserver 客户端的角度优先拜访本地 cache，在客户端去做负载平衡；apiserver 服务端次要做了 watch 优化和 cache 索引优化；在 etcd 内核上利用并发读晋升单 etcd 集群读解决能力，基于 hashmap 的 freelist 治理新算法进步 etcd 存储下限，基于 raft learner 技术来进步多备能力等等。 从 4 千节点增长到 8 千节点，咱们又做了 qps 限流治理和容量治理优化、etcd 单资源对象存储拆分、组件标准全生命周期落地通过客户端的标准束缚升高对 apiserver 的压力和以及穿透到 etcd 的压力等等。 终于迎来 8 千节点增长到上万节点的时刻，咱们开始热火朝天地发展 etcdcompact 算法优化；etcd 单节点多 multiboltdb 的架构优化，apiserver 的服务端数据压缩，通过组件治理升高 etcd 写放大等；同时开始打造常态化的压测服务能力，继续答复 ASI 的 SLO。 这些例子在高可用挑战中司空见惯，列出的能力也只是其中一小部分，你兴许很难看到能力之间的关联和底层的演进逻辑。当然，更多的能力建设积淀到了咱们的零碎和机制当中。本篇文章会作为一个开始，以综述的模式分享咱们在建设 ASI 全局高可用体系中的几个要害局部，再往后会有针对性地对进行技术点和演进路线的详解。如果大家有什么问题或者心愿理解的局部，欢送在评论区留言。 ...

简介：上一篇《详解 WebRTC 传输平安机制：一文读懂 DTLS 协定》具体论述了 DTLS。本文将联合 DTLS 开发中遇到的问题，具体解读 DTLS 的一些根底概念以及 Fragment 的机制，并进一步深究 DTLS 协定。作者｜泰一 审校｜进学、莫战 前言最近在做 J 和 G 这两套 RTC 零碎的 DTLS-SRTP 握手加密工作，要求应用 CA 机构颁发的证书。在本机调试的过程中发现：G 零碎应用 CA 证书，DTLS 握手胜利，而 J 零碎则握手失败。 通过几番调试与剖析，定位到了起因：J 零碎相较于 G 零碎多了一个 TURN 转发模块，该模块设置的接收缓冲区的上限值为 1600 字节，而 CA 证书的大小则有近 3000 字节，因而 TURN 模块转发给客户端的证书不残缺，导致 DTLS 握手失败。 大家都晓得， WebRTC 的 DTLS 应用的是自签名的证书，这个证书个别不会太大，如下图所示，只有 286 字节。 然而，如果要应用 CA 颁发的证书，那么这个证书可能会很大，如下图所示，竟达到了 2772 字节，显然超出了 TURN 模块的接收缓冲区的大小。 上图中，你可能留神到了这个 CA 证书被分成了两片（two fragments），这其实是 DTLS 协定层做的。不过值得思考的是，CA 证书的每一片的大小都未超出 TURN 模块接收缓冲区的 1600 字节的限度，然而为什么 J 零碎的 TURN 转发模块仍然会接管失败呢？ ...

简介：淘宝搜寻举荐、视频搜寻背地应用了什么样的检索技术？非结构化数据检索，向量检索，以及多模态检索，它们到底解决了什么问题？明天由阿里达摩院的科学家从业务问题登程，抽丝剥茧，深度揭秘达摩院外部技术，向量检索引擎 Proxima，以及在阿里云凋谢搜寻产品行业模板能力的实际利用~技术分享： 王绍翾(大沙) 阿里达摩院机器智能实验室 资深技术专家肖允锋(鹤冲) 阿里达摩院机器智能实验室 资深技术专家阿里云搜寻举荐产品： 凋谢搜寻（OpenSearch）：https://www.aliyun.com/page-source/data-intelligence/activity/edusearch5. 技术瞻望随着 AI 技术的广泛应用以及数据规模的一直增长，向量检索作为深度学习中的支流办法，其具备的泛检索和多模态搜寻的能力也将进一步失去施展。物理世界的实体和特色，通过向量化技术进行表征和组合，映射到数字世界，借助计算机进行计算和检索，开掘潜在逻辑和隐式关系，更智能的服务于人类社会。 将来，向量检索除了要面对数据规模的一直增长，算法上仍须要解决混合空间检索、稠密空间检索、超高维、泛一致性等问题。工程上，面对的场景将越来越宽泛，也越来越简单，如何造成强有力的系统化体系，贯通场景和利用，将是向量检索下一步倒退的重点。 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

简介：很多人看着 K8s 成为最热门的开源技术，都纷纷开始学习 K8s，但也有很多人在埋怨 K8s 太简单了。用 CNCF 新晋 TOC 张磊的话来说：这里的基本问题在于，K8s 的定位是“平台的平台”（The Platform for Platform），所以其外围性能、服务的对象是根底平台工程师，而非业务研发人员与运维人员；它的申明式 API 设计、CRD Operator 体系，也是为了不便根底平台工程师接入和构建新基础设施能力而设计的。这就导致作为这些能力的最终使用者-业务研发人员，实际上跟 K8s 外围定位之间存在显著的错位。 起源 | 阿里巴巴云原生公众号 很多人看着 K8s 成为最热门的开源技术，都纷纷开始学习 K8s，但也有很多人在埋怨 K8s 太简单了。用 CNCF 新晋 TOC 张磊的话来说：这里的基本问题在于，K8s 的定位是“平台的平台”（The Platform for Platform），所以其外围性能、服务的对象是根底平台工程师，而非业务研发人员与运维人员；它的申明式 API 设计、CRD Operator 体系，也是为了不便根底平台工程师接入和构建新基础设施能力而设计的。这就导致作为这些能力的最终使用者-业务研发人员，实际上跟 K8s 外围定位之间存在显著的错位。 与传统中间件从业务研发的视角登程不同，云原生的基础设施反动是自底而上的，所以K8s 具备与生俱来的“高门槛”个性。它始于那些比“云计算”还是要底层的容器根底设计构建理念，而后逐层向上对底层的计算、存储、网络进行的对立的形象，成为咱们 K8s 中的 Pod、NetworkPolicy、Volume 等概念。同样，市面上的大家能够找到的许多课程，都像在“强制”大家成为“K8s 专家”，不是以用户视角来形容与部署利用。 所以，问题来了，作为一个后端业务开发，K8s 要了解到什么深度、会用到什么水平？如何在这个简单而宏大的我的项目中抓到主线，用好 K8s? 面对这个问题，在云原生技术公开课的根底上，咱们联结阿里云容器团队、马哥教育联结出品了面向后端业务开发的 K8s 在线体验教程，不仅能对症下药地让后端业务开发同学更好地上手 K8s，还能助力有需要的开发者疾速通关 Linux 和 CNCF 基金会推出的 Kubernetes 应用程序开发者认证 (CKAD)。 在线教程亮点自带运行环境你只须要关怀教程内容自身，无需为繁琐的运行环境筹备工作浪费时间。所有试验都在一个当时筹备好运行环境的容器中运行。 ...