Sql | 乐趣区

关于sql:Fact-Table-数据表什么意思

与 Fact Table 对应的表是 Dimension Table。这 2 个表是数据仓库的两个概念，为数据仓库的两种类型表。从保留数据的角度来说，实质上没区别，都是表。区别次要在数据和用处上，Fact Table 用来存 fact 数据，就是一些能够计量的数据和可加性数据，数据数量，金额等。 Dimension Table 用来存描述性的数据，比如说用来形容 Fact 表中的数据，如区域，销售代表，产品等。 https://www.ossez.com/t/fact-...

关于sql:高基数数据特性是什么意思

在 SQL 中，基数（cardinality）的定义为一个数据列中举世无双数据的数量。高基数（High-Cardinality）的定义为在一个数据列中的数据基本上不反复，或者说反复率非常低。例如咱们常见的辨认号，邮件地址，用户名等都能够被认为是高基数数据。例如咱们常定义的 USERS 数据表中的 USER_ID 字段，这个字段中的数据通常被定义为 1 到 n。每一次一个新的用户被作为记录插入到 USERS 表中，一个新的记录将会被创立，字段 USER_ID 将会应用一个新的数据来标识这个被插入的数据。因为 USER_ID 中插入的数据是举世无双的，因而这个字段的数据技术就能够被思考认为是高基数（High-Cardinality）数据。 https://www.ossez.com/t/topic...

关于sql:王炸结营实时计算-Flink-版-Hologres实时数仓入门训练营课程内容合集

简介：阿里云超强专家阵容倾力打造的实时数仓 “王炸组合”，现已将所有课程整理出来供同学们学习～5 月份，实时计算 Flink 版 + Hologres 组建 “王炸组合”，联合推出的《实时数仓入门训练营》受到了宽广开发者同学们激情的关注。训练营的全部内容曾经整顿在文章开端处～《实时数仓入门训练营》视频课程回顾视频链接:https://developer.aliyun.com/learning/course/807 本次训练营邀请了阿里云研究员王峰、阿里云资深技术专家金晓军等技术大咖作为讲课嘉宾。课程内容由浅入深全方位解析实时数仓的架构、场景、以及实操利用；7 ⻔精品课程帮忙学员 5 天工夫从小白成⻓为大牛! 精品的内容促使训练营十分受大家的欢送，课程完结后一直有同学私信，没有赶上报名怎么办。为满足大家求知学习的劲头，《实时数仓入门训练营》在 6 月份又加推了一期！然而，这仍旧抵挡不住同学们的学习激情，还是一直有小伙伴留言，两期训练营都错过了，还有没有方法学习到实时数仓的课程。不必放心！咱们现将《实时数仓入门训练营》的课程内容全副整顿了进去，供各位小伙伴学习参考！超强嘉宾阵容：阿里云研究员王峰、阿里云资深技术专家金晓军、阿里云高级产品专家刘一鸣等实时计算 Flink 版和 Hologres 的多名技术/产品一线专家齐上阵，合力搭建此次训练营的课程体系，精心打磨课程内容，直击当下同学们所遇到的痛点问题。超级干货内容：零根底的同学不要愁，本次入门训练营只需 5 天工夫 7 门课，就能帮忙你实现从 0 到 1 疾速上手搭建实时数仓。以下是本系列课程的内容概括：不会是 ”望而生畏“。讲课嘉宾别离解说 Flink 与 Hologres 的架构与原理，以及数仓架构的演进，再深度解析如何降级到 Flink + Hologres 实时数仓。内容由浅入深，小白也能轻易了解！不只是 “略懂略懂”。技术专家手把手实操演示，例如 Flink SQL 上手示例，Flink 读写 Hologres 上手示例等；还会将日常开发中可能遇到的各种典型问题都一一解惑，例如开发 Flink SQL 过程中常见问题和解决办法，Hologres 常见性能问题剖析等。有问题咱就解决，回绝只懂皮毛！不再是 “夸夸其谈”。产品专家将从实时数仓演变史，到基于 Flink + Hologres 实时数仓举荐架构，再到营销剖析实时数仓实际，全方位讲授如何将实时数仓利用到实际，助力互联网的实时决策和精准营销。实时数仓自身再好，不会使用也不行！课程链接：以下是《实时数仓入门训练营》的所有课程链接，同学们自行珍藏～【第一课】《实时计算 Flink 版总体介绍》【第二课】《Hologres 总体架构》【第三课】《基于 Flink + Hologres 的实时举荐零碎架构解析》 ...

关于sql:实时数仓入门训练营Hologres-数据导入导出实践

关于sql:Flink-Iceberg腾讯百亿级实时数据入湖实战

简介：上海站 Flink Meetup 分享内容，腾讯数据湖的百亿级数据场景落地的案例分享。本文整顿自腾讯数据湖研发高级工程师陈俊杰在 4 月 17 日上海站 Flink Meetup 分享的《百亿级实时数据入湖实战》，文章内容为：腾讯数据湖介绍百亿级数据场景落地将来布局总结GitHub 地址 https://github.com/apache/flink 欢送大家给 Flink 点赞送 star~ 一、腾讯数据湖介绍从上图能够看进去，整个平台比拟大，包含了数据接入、下层的剖析、两头的治理 (如工作治理，剖析治理和引擎治理)，再到最上层的 Table Format。二、百亿级数据落地场景落地1. 传统平台架构如上图所示，过来的传统平台架构无非是两种，一种是 Lambda 架构，一种是 Kappa 架构： Lambda 架构中，批和流是离开的，所以运维要有两套集群，一套是 For Spark/Hive，一套是 For Flink。这存在几个问题：第一是运维的老本比拟大；第二是开发成本。例如在业务方面，一会要写 Spark，一会要写 Flink 或者 SQL，总体来说，开发成本对数据分析人员不是特地敌对。第二个是 Kappa 架构。其实就是音讯队列，到底层的传输，再到前面去做一些剖析。它的特点是比拟快，基于 Kafka 有肯定的实时性。这两种架构各有利弊，最大的问题是存储可能会不对立，导致数据链路割裂。目前咱们平台曾经接入了 Iceberg，上面会依据不同场景，论述遇到的问题及解决的过程。 2. 场景一: 手 Q 平安数据入湖手机 QQ 平安数据入湖是一个十分典型的场景。目前的业务场景是音讯队列 TubeMQ 通过 Flink 落地成 ODS 到 Iceberg，而后再用 Flink 做一些用户表的关联，之后做成一个宽表去做一些查问，放到 COS 中，可能会在 BI 场景做一些剖析。 ...

关于sql:实时数仓入门训练营实时数仓助力互联网实时决策和精准营销

简介：《实时数仓入门训练营》由阿里云研究员王峰、阿里云高级产品专家刘一鸣等实时计算 Flink 版和 Hologres 的多名技术/产品一线专家齐上阵，合力搭建此次训练营的课程体系，精心打磨课程内容，直击当下同学们所遇到的痛点问题。由浅入深全方位解析实时数仓的架构、场景、以及实操利用，7 门精品课程帮忙你 5 天工夫从小白成长为大牛！本文整顿自直播《实时数仓助力互联网实时决策和精准营销-合一》视频链接:https://developer.aliyun.com/learning/course/807/detail/13886 近年来，实时数仓是互联网的热门话题，次要利用场景次要是在实时决策和营销等畛域，这些畛域对数据分析的精密度、实时性都有很高的要求，是走在技术前沿的畛域。业务在线化、经营精细化推动数仓实时化、交互化咱们先看一下过来几年数据分析倒退的一些趋势，如上图所示。能够看到，数据分析根本的趋势是从批处理向交互式剖析、流计算的方向演进。在10年前，大数据更多的是解决规模的问题，通过并行计算的技术解决海量的数据，那个时候咱们更多的是在做数据的荡涤，数据模型的设计，对剖析的需要并不太多。现在，咱们的大数据团队基本上都变成了数据分析的团队，对数据模型的积淀，对交互式剖析的反对能力，对查问响应提早的反对效率，对QPS的要求都会越来越多。数据分析也并不只是数据存下来再剖析，也有很多计算前置，先有逻辑后有计算的场景。比方在双11的时候，在多少秒有多少成交量，这样一个典型的场景就不是先有交易数据后有计算量的问题，肯定是随着交易而产生实时计算结果的过程。因而，交互式剖析和流计算简直是一个并行后退的过程，这两种新的场景对背地技术有很多不一样的要求。批处理更多的是考究并行度，在交互式剖析畛域里边，咱们开始有很多的预计算、内存计算、索引等技术，所以这个也是推动了整个大数据技术的演进。总结来看，数据分析撑持着越来越多的在线业务，在线业务包含咱们任何时候关上手机，手机屏幕里边举荐的产品、展现的广告，这些都是须要在几毫秒之内返回后果，靠数据智能举荐进去，如果不举荐的话点击率、转化率肯定非常低。因而，咱们的数据业务在撑持越来越多的在线业务，在线业务对查问提早、QPS、精密度都有十分高的要求，这也推动着数仓向实时化、交互化方向演进。阿里巴巴典型实时数仓场景在阿里巴巴有很少数仓的应用场景，例如双11的实时GMV大屏。GMV只是一个结论性的数字，实际上对数据分析师而言，这个工作只是刚刚开始。咱们要向下剖析，是什么产品，在什么渠道，针对什么样的人群，以什么样的促销伎俩，达成这样的转化成果，有哪些转化成果没有达成，等等一系列剖析。这些剖析其实十分的细粒度，是精细化剖析的成果。剖析之后，就会对所有的商品、人群做一些标签化，通过标签化咱们下一步能够去领导在线的利用去做举荐、剖析、圈选等等，所以有很多数据中台的业务也会产生。还有一类业务是偏监控类业务，订单忽然抖动、增长，网络品质的抖动，视频直播的一些监控等，这些也是实时数仓典型的利用场景。大数据实时数仓体系的“纷纷杂乱”过来咱们建设实时数仓的时候参考过很多公司，阿里巴巴也是走过很简单的一条路线。上方是我画的架构图，第一次看的时候挺兴奋的，那个时候本人是个大数据架构师，可能画出这么多个箭头是很体现功力的一件事件。但当真正去做这样一个零碎的时候，发现这个零碎的开发效率、运维效率十分令人抓狂。这套零碎从左上角演变开始，音讯从消息中间件收集，之后是一个离线加工的过程，那个时候咱们还没有很多实时的技术，首先要先解决规模的问题。通过离线的加工，咱们会把加工的后果集变成小的后果集，存到MySQL和Redis，这是一个典型的加工服务二元化的体系。通过把数据变成小数据之后，能力对外提供下层的利用，包含报表利用、举荐利用等。之后数据分析须要实时化，光靠这种“T+1”的离线加工不可能满足需要，数据越实时越有上下文，价值越大。这个时候就有很多计算前置的技术被采纳，例如Flink。通过Flink间接生产Kafka里的事件，通过事件驱动的形式做计算，因为Flink是分布式的，因而可扩展性十分好，它能够通过计算前置，通过事件驱动的形式，能够把端到端的提早做到极致。而后咱们会把后果集也存到一个介质外面，通过Flink加工的后果集是一个十分精简的构造，个别是以kv6构造为主，放在HBase、Cassandra这样的零碎，这样的系统对上提供的大屏报表是最快的。比如说双11的大屏，相对不能等成交几千万、几亿条记录之后再去做统计，否则查问性能肯定无奈满足。因而，咱们一开始都会加工成如以每秒每个渠道为粒度的原始数据集，原始数据集在做大屏剖析的时候，就能够从一个很大的数据集变成一个很小的数据集，性能达到极致。当初咱们看到有解决规模，有处理速度，这两者看起来外表上都满足肯定需要，但其实老本也是不小的。如果想要计算足够地快，须要把计算前置，这样的话数据模型的灵便度就会缩小，因为咱们曾经通过Flink把所有的数据汇聚成一个后果集了。例如，如果有些业务逻辑一开始没有定义好，比方刚开始剖析的是某三个维度的聚合，如果后续想剖析第四个维度的聚合，因为提前没有计算好，因而无奈进行剖析，所以这里就义了灵活性。此时就有一些相比HBase更灵便，又比Hive实时性更好的技术会被采纳，例如ClickHouse、Druid。数据能够实时写入，写入之后也提供肯定的交互式剖析、自助式剖析的能力。咱们会发现，数据处理将同一份数据扩散在三个不同的介质，包含离线解决的介质，近实时处理的介质和全实时处理介质。三个介质往往须要三个团队来保护，三个团队随着工夫产生人员的变动，数据加工逻辑肯定会有多多少少的调整，造成的后果就是，咱们会发现同一个指标通过三个不同渠道产生的计算结果不统一，这个事件简直每个公司都会产生。这还只是外表的问题，对于分析师来说更苦楚，他须要应用不同的数据，拜访不同的零碎，学习不同的接口，甚至是有不同的访问控制机制，这对分析师来说就十分不不便。因而，很多公司都要搭一套所谓的数据中台，通过中台来屏蔽底下物理引擎上的不同，这种状况下Presto、Drill这种联邦计算技术就会被采纳。联邦计算技术有着二十多年的倒退历史，从最晚期的数据信息系统集成到数据虚拟化，技术始终在倒退。这个技术是一套数据不挪动、计算挪动的技术，听起来很美妙，然而当真正在生产上应用的时候会发现，这套零碎的查问体验是不可预期的，咱们不晓得通过零碎查问上来数据是快还是慢，因为它把查问下压到不同的引擎，如果下压到Hive，就没那么快，要是下压到ClickHouse可能就比拟快。所以这对一个分析师来说，他不晓得这个零碎的预期是什么，叫不可预期性。例如，以前关上报表可能用了5秒钟，另外一次可能用了5分钟，这种状况会让分析师不晓得到5分钟的时候是失常还是不失常。如果跑在Hive上，就叫失常，如果跑在Drill上，就叫不失常。不可预期性也让这个零碎很难进入生产的畛域，所以这个时候咱们不得以，还要是通过数据做一次汇聚，变成小的后果集去剖析。咱们看到，整个链路实际上是由多个组件层层嵌套、层层依赖组成的，除了方才提到的不同团队保护会造成数据口径不统一的状况，对数据保护的老本也会变得十分高。常常遇到的状况有，咱们看到报表上某个数字可能是不正确的，比方某天这个指标忽然增长或下滑很多，这时没人能确认两头是数据品质出问题，还是加工逻辑出问题，或者是数据同步链路出错了，因为两头链路太长了。数据源头如果批改一个字段，从新补一个数据，那么每一个环节都要重跑，所以说这套架构如果是运行失常就没有问题，然而一旦数据品质有问题或者数据调度上出问题，环环依赖，这让整个运维老本变得十分高。同时，懂这么多技术的人才难找且贵，常常产生的状况是一个公司辛苦造就出这样的人才，之后就被其余大厂挖走了，这样的人才从招聘到造就都十分艰难。以上是这套架构的现状。明天大数据的简单，让人想起60年代下面这套架构让我想起60年代，那个时候数据库根本还没有诞生，70年代末期才诞生了关系型数据库。 60年代咱们是怎么治理数据的状态？在60年代，每个程序员要本人写状态保护。有的人用文件系统，然而光用文件系统会十分离散，保护起来也十分难，因为数据之间是有关系的。这个时候还有一些网状结构的零碎呈现，通过一个文件能够跳到另外一个文件去，然而网络结构治理起来也绝对比较复杂，因为循环、嵌套等等。除此之外还有层级构造，也是一种数据类型的形容形式。所以能够看到，60年代的程序员本人治理数据状态，其实老本很高。到了80年代，咱们基本上不会再这么干了，因为咱们晓得所有的状态尽量都存在数据库里，也是因为关系型数据库让这件事件变得简略了很多。只管咱们有很多种关系型数据库，但根本都是以SQL接口为主，这让咱们整个数据的存储、查问、治理等老本急剧下降。这件事件在过来20年又产生了一些不少变动，从大数据的时代到NoSQL到NewSQL，诞生了各种各样的技术，如Hadoop、Spark、Redis等，这让数据畛域蓬勃发展。然而我总感觉这个中央隐含了一些问题，可能将来不肯定是这样。目前大数据倒退蓬勃但不对立，所以我在想将来是不是能够把大数据技术绝对收拢一些，用一种更有描述性的形式来解决问题，而不是让每个程序员都去学习不同的组件，学习几十种不同的接口，配置上千个参数。为了进步开发效率，或者在将来咱们有必要将这些技术进一步收拢简化。实时数仓外围需要：时效性咱们回过头看一看，脱离这些技术组件，实时数仓到底有什么业务上的需要，针对这些业务需要能够要求什么样的数据架构。什么是实时？很多人认为实时剖析就是从数据产生到可能被剖析的工夫足够短，其实这并不齐全精确。我认为实时数仓分为两种实时，一种叫端到端的提早短，另外一种实时也能够称为准时，就是当咱们真正剖析数据的时候，可能拿到无效的数据，并且可能得出结论，这就能够叫准时。第一种实时是偏技术的概念，然而咱们的业务肯定须要这么低的提早吗？通常状况下，业务并不是每秒钟都在做决策，业务当咱们关上报表，咱们看数那一刻，这一刻咱们关怀的数据可能是过来的一天，上一个小时，5分钟之前，或者是一秒钟之前的。但教训通知咱们，99%的数据分析如果能做到5分钟的提早，根本能满足业务上的数据分析需要。在剖析场景是这样的，如果是在线服务的场景，这必定是不够的。所以大多数公司里兴许并不要求那么实时，因为这背地的老本是不一样的。因为一旦要的是端到端的提早，就肯定须要很多计算前置的业务逻辑，不能等数据都存下来之后再去查问，因为要求提早十分地短，咱们必须要把很多数据提前汇聚、加工、拉宽，能力让数据分析的时候计算量足够小，才能够做到提早足够地短。所以如果谋求的是端到端的提早，要做很多计算前置的工作。方才咱们提到，如果计算全副前置，灵活性会有损失，所以这件事是有老本的。相对来说，如果谋求的是一个准时的零碎，那能够把一部分的计算逻辑后置，换取的是一个灵便剖析的场景。例如双11的时候只是为了谋求延时，那咱们只会把最初一个GMV存下来，这是一种场景，这事就完结了。但这件事不合乎公司要求，公司肯定要出具体的报告，须要晓得什么时候卖的好，什么时候卖的不好。所以这种状况下，全副提前预计算的形式必定是不适宜的，须要有更多的明细数据可能存下来，咱们能够做更多的交互式剖析、关联剖析、摸索式剖析，所以说这两套零碎背地的需要是不一样的。相对来说，我感觉绝大部分公司要的其实是个准时的零碎，它须要具备计算后置的能力，具备实时写入、写入即可剖析的能力，哪怕剖析的效率不是那么高，还要具备灵便剖析的能力。实时数仓外围需要：数据品质数据品质是实时数仓建设里很重要的一环，方才提到如果不谋求数据品质，只谋求时效性的话，一开始通过计算前置加工成一个后果集，这个后果集通知咱们GMV达到了100亿，绝大部分老板是不敢相信的，因为这100亿背地可能是数据品质出问题，也可能是计算逻辑写错了，所以说零碎要可能保证数据品质。数据品质分两个方面，一个是多久发现品质问题，另一个是多久修改品质问题，这两个解决思路是不太一样的。如果想发现数据品质问题，就须要让计算过程的状态可能被长久化，就心愿数据仓库引擎里边可能有明细，以及汇总数据可能落盘，这些数据能够被查看。这样的话，当老板问指标为什么增长这么多，到底是哪个客户带来的增长，你就能够通过这些明细的数据去查看起因，剖析数据时如果发现错了是否修改，这也是很要害的问题。有些零碎只能看不能改，这是很多大数据系统的通病。大数据系统在解决规模性问题十分好，然而解决小的问题，如更正数据就特地地难。因为它每次更正都是须要很大的数据块为单位，或者是没有主键，将整个文件替换，所以更新起来的确比拟难。发现问题和修改问题相比，我更心愿一个零碎可能具备修改数据问题的能力。修改问题就是在发现数据品质的时候，能够简略地更新数据的状态，比如说单行数据的更新，单列数据的更新，批量的更新等，有很简略的形式做数据的刷新。数据刷新的状态这个事件常常会产生，例如上游数据品质有问题，加工逻辑写错了等，都须要做数据刷新的工作。其次，我也心愿数据修改的时候尽量可能只修改一个零碎就好。方才咱们看到，一份数据的数据源出错了之后，它要在后端4~5个环节重复流转，这意味着一旦数据出错了之后，在4~5个环节外面都要做数据修改的工作，这外面的数据存在大量的冗余和不统一，要修改的话每个环节都要修改，这也是特地简单的一件事件。所以咱们心愿数仓的状态尽量只存一个中央，这样话我只修改一处就能够了。实时数仓外围需要：老本优化老本分为三局部，别离是开发成本、运维老本和人力老本。开发成本示意咱们想要业务需要多久能上线。做同样一件事，是须要一个团队还是一个人，是须要一周还是一天，所以开发成本是很多公司很关怀的一件事件，如果开发不进去，就意味着很多业务的需要是被压抑或者是克制的。咱们心愿IT同学不须要再很疲乏地响应业务团队取数的要求。常常产生的状况是，等数据真正加工完之后，业务团队反馈说数据加工得不对，等IT同学好不容易修改对了之后，业务团队示意流动完结了，想看的数据曾经没有意义了。因而，好的数仓零碎肯定是技术和业务解耦，技术团队保障数据平台运行的稳固牢靠，而业务团队的取数尽量要自助化，本人通过拖拽的形式生成感兴趣的报表，这是咱们认为良好的零碎。只有通过这样的形式来升高开发的门槛，让更多的人本人去取数，实现数据资产的可复用，业务自助开发。 ...

关于sql:实时数仓入门训练营实时计算-Flink-版-SQL-实践

关于sql:回顾-Apache-Flink-x-TiDB-Meetup-北京站

简介：7.10 日 Apache Flink x TiDB Meetup 视频 & PPT 来啦GitHub 地址 https://github.com/apache/flink 欢送大家给 Flink 点赞送 star~ 7 月 10 日，Apache Flink x TiDB Meetup 北京站圆满结束！来自阿里巴巴、TiDB、奇虎 360、知乎、网易的 5 位老师带同学们深刻摸索了 Flink + TiDB 在行业中的更多可能性，以及 Flink SQL 和 Flink-CDC 架构的感悟与实际等。加入本场 Meetup 的同学能够说是播种满满，不仅意识了超多各行各业的开发者小伙伴，还能够与行业资深大咖面对面交换，积攒已久的疑难当场取得了解答！议题回顾：社区活动 | Apache Flink Meetup 7.10 北京站，Flink x TiDB 专场等你来！流动亮点：网易互娱联合 JFlink 与 TiDB，反对精确稳固的实时计算业务。Flink + TiDB 如何搭建实时数仓的数据链路。Flink x TiDB 在知乎的的端到端实时计算。Flink SQL 在奇虎 360 的实际。详解 Flink CDC，以及 Flink CDC 2.0 的设计方案。▼ 现场精彩照片 ▼ ...

关于sql:Hologres基于TPCH的性能测试介绍

简介：本文将会介绍在Hologres中如何基于TPCH数据集做性能测试，并提供测试后果参考，不便您进行产品规格选型。背景信息TPC-H（商业智能计算测试）是美国交易解决效力委员会（TPC,Transaction Processing Performance Council）组织制订的用来模仿决策反对类利用的一个测试集。目前在学术界和工业界广泛采纳它来评估决策反对技术方面利用的性能。TPC-H 是依据实在的生产运行环境来建模，模仿了一套销售零碎的数据仓库。其共蕴含 8 张表，数据量可设定从 1G~3T 不等。其基准测试共蕴含了22个查问，次要评估指标各个查问的响应工夫，即从提交查问到后果返回所需工夫。其测试后果可综合反映零碎解决查问时的能力。详情参考TPCH 文档。数据集介绍该数据集蕴含如下 8 张表，互相间的关系如下图所示。测试详情测试数据量阐明测试数据量会间接影响测试后果，TPC-H 的生成工具中应用 SF ( scale factor ) 管制生成数据的数据量的大小，1 SF 对应 1 GB。留神：以上提及的数据量仅仅为原始数据的数据量，不包含索引等空间占用，所以筹备环境时，须要预留更多的空间。测试环境本次测试应用了独享实例（按量付费）的实例，因为仅为测试示意应用，所以计算资源配置抉择了8核32G。测试场景本测试场景次要蕴含3局部： OLAP查问场景测试，次要应用列存表，间接应用TPCH测试中的22条查问；Key/Value点查场景测试，次要应用行存表，针对orders应用行存表后，进行主键过滤的点查；根底环境筹备该步骤次要用于筹备OLAP查问场景和Key/Value点查场景所需的数据；根底环境筹备1. 创立 ECS 实例登陆阿里云，创立一个 ECS 实例，用于数据生成、向 Hologres 导入数据、客户端测试。倡议规格： ecs.g6.4xlarge 规格CentOS 7.9 零碎ESSD 数据盘，具体数据容量依据须要测试的数据量大小决定倡议 ECS 与 Hologres 实例用雷同 Region 和 VPC 网络2. 创立 Hologres 实例登陆阿里云，进入 Hologres 产品控制台，点击新增引擎实例抉择配置，并填写实例名称，具体阐明请参考官网文档。3. 创立测试数据库在创立实例后，您须要登陆您创立的 Hologres 实例，创立一个数据库，本测试中命名数据库为tpch_1sf，具体操作步骤请参考官网文档生成 TPC-H 数据1. 筹备数据生成工具近程链接 ECS 实例更新所有库yum update装置 gityum install git装置gccyum install gcc下载 TPC-H 数据生成代码git clone https://github.com/gregrahn/tpch-kit.git进入数据生成工具代码目录cd tpch-kit/dbgen编译数据生成工具代码make2. 生成数据编译胜利后，您能够应用如下代码查看代码生成工具的相干参数。./dbgen --help本次测试仅生成 1 GB 数据，所以运行如下代码生成数据。./dbgen -vf -s 1如您须要生成更多数据量的数据，能够调整 SF 的参数，例如您能够应用如下代码生成 1 T 数据./dbgen -vf -s 1000个别状况下，32CU 能够跑 TPCH SF10，256CU 能够跑 TPCH SF50数据生成后，您能够应用如下代码查看生成的文件。能够看到生成工具生成了 8 个数据文件，每个数据文件都对应一张数据集中的表。ls | grep '.*.tbl'OLAP查问场景测试筹备数据1. 创立表因为本文次要应用 psql 进行数据导入操作，须要先在 ECS 中运行如下命令装置 psqlyum install postgresql-server装置 psql 后，您能够应用如下命令登陆 Hologres 实例PGUSER=<AccessID> PGPASSWORD=<AccessKey> psql -p <Port> -h <Endpoint> -d <Database>应用psql连贯Hologres后，您能够应用如下建表语句创立数据库表DROP TABLE IF EXISTS LINEITEM;BEGIN;CREATE TABLE LINEITEM( L_ORDERKEY INT NOT NULL, L_PARTKEY INT NOT NULL, L_SUPPKEY INT NOT NULL, L_LINENUMBER INT NOT NULL, L_QUANTITY DECIMAL(15,2) NOT NULL, L_EXTENDEDPRICE DECIMAL(15,2) NOT NULL, L_DISCOUNT DECIMAL(15,2) NOT NULL, L_TAX DECIMAL(15,2) NOT NULL, L_RETURNFLAG TEXT NOT NULL, L_LINESTATUS TEXT NOT NULL, L_SHIPDATE TIMESTAMPTZ NOT NULL, L_COMMITDATE TIMESTAMPTZ NOT NULL, L_RECEIPTDATE TIMESTAMPTZ NOT NULL, L_SHIPINSTRUCT TEXT NOT NULL, L_SHIPMODE TEXT NOT NULL, L_COMMENT TEXT NOT NULL, PRIMARY KEY (L_ORDERKEY,L_LINENUMBER));CALL set_table_property('LINEITEM', 'clustering_key', 'L_SHIPDATE,L_ORDERKEY');CALL set_table_property('LINEITEM', 'segment_key', 'L_SHIPDATE');CALL set_table_property('LINEITEM', 'distribution_key', 'L_ORDERKEY');CALL set_table_property('LINEITEM', 'bitmap_columns', 'L_ORDERKEY,L_PARTKEY,L_SUPPKEY,L_LINENUMBER,L_RETURNFLAG,L_LINESTATUS,L_SHIPINSTRUCT,L_SHIPMODE,L_COMMENT');CALL set_table_property('LINEITEM', 'dictionary_encoding_columns', 'L_RETURNFLAG,L_LINESTATUS,L_SHIPINSTRUCT,L_SHIPMODE,L_COMMENT');CALL set_table_property('LINEITEM', 'time_to_live_in_seconds', '31536000');COMMIT;DROP TABLE IF EXISTS ORDERS;BEGIN;CREATE TABLE ORDERS( O_ORDERKEY INT NOT NULL PRIMARY KEY, O_CUSTKEY INT NOT NULL, O_ORDERSTATUS TEXT NOT NULL, O_TOTALPRICE DECIMAL(15,2) NOT NULL, O_ORDERDATE timestamptz NOT NULL, O_ORDERPRIORITY TEXT NOT NULL, O_CLERK TEXT NOT NULL, O_SHIPPRIORITY INT NOT NULL, O_COMMENT TEXT NOT NULL);CALL set_table_property('ORDERS', 'segment_key', 'O_ORDERDATE');CALL set_table_property('ORDERS', 'distribution_key', 'O_ORDERKEY');CALL set_table_property('ORDERS', 'colocate_with', 'LINEITEM');CALL set_table_property('ORDERS', 'bitmap_columns', 'O_ORDERKEY,O_CUSTKEY,O_ORDERSTATUS,O_ORDERPRIORITY,O_CLERK,O_SHIPPRIORITY,O_COMMENT');CALL set_table_property('ORDERS', 'dictionary_encoding_columns', 'O_ORDERSTATUS,O_ORDERPRIORITY,O_CLERK,O_COMMENT');CALL set_table_property('ORDERS', 'time_to_live_in_seconds', '31536000');COMMIT;DROP TABLE IF EXISTS PARTSUPP;BEGIN;CREATE TABLE PARTSUPP( PS_PARTKEY INT NOT NULL, PS_SUPPKEY INT NOT NULL, PS_AVAILQTY INT NOT NULL, PS_SUPPLYCOST DECIMAL(15,2) NOT NULL, PS_COMMENT TEXT NOT NULL, PRIMARY KEY(PS_PARTKEY,PS_SUPPKEY));CALL set_table_property('PARTSUPP', 'distribution_key', 'PS_PARTKEY');CALL set_table_property('PARTSUPP', 'colocate_with', 'LINEITEM');CALL set_table_property('PARTSUPP', 'bitmap_columns', 'PS_PARTKEY,PS_SUPPKEY,PS_AVAILQTY,PS_COMMENT');CALL set_table_property('PARTSUPP', 'dictionary_encoding_columns', 'PS_COMMENT');CALL set_table_property('PARTSUPP', 'time_to_live_in_seconds', '31536000');COMMIT;DROP TABLE IF EXISTS PART;BEGIN;CREATE TABLE PART( P_PARTKEY INT NOT NULL PRIMARY KEY, P_NAME TEXT NOT NULL, P_MFGR TEXT NOT NULL, P_BRAND TEXT NOT NULL, P_TYPE TEXT NOT NULL, P_SIZE INT NOT NULL, P_CONTAINER TEXT NOT NULL, P_RETAILPRICE DECIMAL(15,2) NOT NULL, P_COMMENT TEXT NOT NULL);CALL set_table_property('PART', 'distribution_key', 'P_PARTKEY');CALL set_table_property('PART', 'colocate_with', 'LINEITEM');CALL set_table_property('PART', 'bitmap_columns', 'P_PARTKEY,P_SIZE,P_NAME,P_MFGR,P_BRAND,P_TYPE,P_CONTAINER,P_COMMENT');CALL set_table_property('PART', 'dictionary_encoding_columns', 'P_NAME,P_MFGR,P_BRAND,P_TYPE,P_CONTAINER,P_COMMENT');CALL set_table_property('PART', 'time_to_live_in_seconds', '31536000');COMMIT;DROP TABLE IF EXISTS CUSTOMER;BEGIN;CREATE TABLE CUSTOMER( C_CUSTKEY INT NOT NULL PRIMARY KEY, C_NAME TEXT NOT NULL, C_ADDRESS TEXT NOT NULL, C_NATIONKEY INT NOT NULL, C_PHONE TEXT NOT NULL, C_ACCTBAL DECIMAL(15,2) NOT NULL, C_MKTSEGMENT TEXT NOT NULL, C_COMMENT TEXT NOT NULL);CALL set_table_property('CUSTOMER', 'distribution_key', 'C_CUSTKEY');CALL set_table_property('CUSTOMER', 'colocate_with', 'LINEITEM');CALL set_table_property('CUSTOMER', 'bitmap_columns', 'C_CUSTKEY,C_NATIONKEY,C_NAME,C_ADDRESS,C_PHONE,C_MKTSEGMENT,C_COMMENT');CALL set_table_property('CUSTOMER', 'dictionary_encoding_columns', 'C_NAME,C_ADDRESS,C_PHONE,C_MKTSEGMENT,C_COMMENT');CALL set_table_property('CUSTOMER', 'time_to_live_in_seconds', '31536000');COMMIT;DROP TABLE IF EXISTS SUPPLIER;BEGIN;CREATE TABLE SUPPLIER( S_SUPPKEY INT NOT NULL PRIMARY KEY, S_NAME TEXT NOT NULL, S_ADDRESS TEXT NOT NULL, S_NATIONKEY INT NOT NULL, S_PHONE TEXT NOT NULL, S_ACCTBAL DECIMAL(15,2) NOT NULL, S_COMMENT TEXT NOT NULL);CALL set_table_property('SUPPLIER', 'distribution_key', 'S_SUPPKEY');CALL set_table_property('SUPPLIER', 'colocate_with', 'LINEITEM');CALL set_table_property('SUPPLIER', 'bitmap_columns', 'S_SUPPKEY,S_NAME,S_ADDRESS,S_NATIONKEY,S_PHONE,S_COMMENT');CALL set_table_property('SUPPLIER', 'dictionary_encoding_columns', 'S_NAME,S_ADDRESS,S_PHONE,S_COMMENT');CALL set_table_property('SUPPLIER', 'time_to_live_in_seconds', '31536000');COMMIT;DROP TABLE IF EXISTS NATION;BEGIN;CREATE TABLE NATION( N_NATIONKEY INT NOT NULL PRIMARY KEY, N_NAME text NOT NULL, N_REGIONKEY INT NOT NULL, N_COMMENT text NOT NULL);CALL set_table_property('NATION', 'distribution_key', 'N_NATIONKEY');CALL set_table_property('NATION', 'colocate_with', 'LINEITEM');CALL set_table_property('NATION', 'bitmap_columns', 'N_NATIONKEY,N_NAME,N_REGIONKEY,N_COMMENT');CALL set_table_property('NATION', 'dictionary_encoding_columns', 'N_NAME,N_COMMENT');CALL set_table_property('NATION', 'time_to_live_in_seconds', '31536000');COMMIT;DROP TABLE IF EXISTS REGION;BEGIN;CREATE TABLE REGION( R_REGIONKEY INT NOT NULL PRIMARY KEY, R_NAME TEXT NOT NULL, R_COMMENT TEXT);CALL set_table_property('REGION', 'distribution_key', 'R_REGIONKEY');CALL set_table_property('REGION', 'colocate_with', 'LINEITEM');CALL set_table_property('REGION', 'bitmap_columns', 'R_REGIONKEY,R_NAME,R_COMMENT');CALL set_table_property('REGION', 'dictionary_encoding_columns', 'R_NAME,R_COMMENT');CALL set_table_property('REGION', 'time_to_live_in_seconds', '31536000');COMMIT;创立结束后，您能在 psql 中应用如下代码查看是否创立胜利tpch_1sf=# \dt若胜利，事实成果如下tpch_1sf=# \dt List of relations Schema | Name | Type | Owner --------+----------+-------+-------------------- public | customer | table | tpch_1sf_developer public | lineitem | table | tpch_1sf_developer public | nation | table | tpch_1sf_developer public | orders | table | tpch_1sf_developer public | part | table | tpch_1sf_developer public | partsupp | table | tpch_1sf_developer public | region | table | tpch_1sf_developer public | supplier | table | tpch_1sf_developer(8 rows)2. 导入数据本测试计划次要应用 COPY FROM STDIN 的形式导入数据具体能够参考官网文档。此处会将此前生成的 tbl 数据文件导入 Hologres 中创立的表中。您能够在数据生成工具的目录中参考如下 shell脚本导入数据for i in `ls *.tbl`; do echo $i; name=`echo $i| cut -d'.' -f1`; PGUSER=<AccessID> PGPASSWORD=<AccessKey> psql -p <Port> -h <Endpoint> -d <Database> -c "COPY $name from stdin with delimiter '|' csv;" < $i;done至此您已实现数据导入3. 收集统计信息为了更好的执行查问，能够在 psql 中应用如下语句，使 Hologres 收集各张表特色信息。vacuum region;vacuum nation;vacuum supplier;vacuum customer;vacuum part;vacuum partsupp;vacuum orders;vacuum lineitem;analyze nation;analyze region;analyze lineitem;analyze orders;analyze customer;analyze part;analyze partsupp;analyze supplier;执行查问为了不便统计查问信息，须要应用pgbench工具，您能够应用如下命令装置pgbench（如果测试机上已有pgbench，请确保版本大于9.6以上，最好大版本是13以上，否则以下测试会遇到各种不兼容）yum install postgresql-contrib为了不便查问，您能够间接通过以下连贯，下载所需的22条SQLtpch\_data\_tpch\_query.zip ...

关于sql:RDS-PostgreSQL一键大版本升级技术解密

简介：内容简要：一、PostgreSQL行业地位二、PostgreSQL版本升级背景三、PostgreSQL版本升级解密四、PostgreSQL版本升级成绩一、PostgreSQL行业地位（一）行业地位在探讨PostgreSQL（上面简称为PG）在整个数据库行业的地位之前，咱们先看一下阿里云数据库在寰球的数据库行业里的地位。魔力象限领导者 *Gartner 2020，阿里云数据库挺进寰球数据库魔力象限领导者 PG年度最佳产品奖 *2020 PG亚洲大会上，阿里云数据库专属集群MyBase荣膺“PG年度最佳产品奖” 接下来,咱们看一下PG数据库在行业中的地位。寰球数据库排行 *PostgreSQL间断3年取得的最佳数据库在开源数据库排名TOP2地位，寰球风行度趋势排名TOP4 广泛应用 *PG数据库宽泛使用于各行各业，蕴含:计算机软件、信息技术及服务、医疗及衰弱、金融服务、高等教育、通信服务等畛域（二）RDS PG VS 自建PG 在大抵理解PG在行业的地位后，接下来再看看阿里云RDS PG和自建PG相比有哪些方面的长处。 *如上图所示，绝对于自建PG，RDS PG的劣势次要体现在可靠性、安全性、智能化和丰盛插件四个方面 1.可靠性 RDS PG提供了Logical Slot Failover能力，在主备模式下，当实例产生HA切换当前，Logical Slot能够持续为用户提供数据同步，这解决了自建PG在HA切换时无奈做到数据增量同步的问题。 RDS PG的Standby反对多上游结点，当HA切换当前，仍然能够放弃只读实例读写拆散性能, 不影响只读节点的数据同步。一键大版本升级使得咱们的用户能够产品化地一键降级到更高版本的PG，享受PG更新版本的个性与稳定性。 2.安全性安全性次要分为三个方面。首先，RDS PG提供云盘加密性能，用户只须要提供一个Key，RDS PG就能够应用这个用户自定义的Key对数据进行落盘加密。其次，咱们公布了SSL自定义证书性能，提供客户端以及服务端的自定义证书，提供客户端和服务端防假装,晋升数据库安全性。最初，RDS PG提供SGX全加密，这个性能是基于硬件的加密技术，使数据在全链路上进行加密。 3.智能化阿里云RDS的整个产品系列都提供了DAS服务。帮忙用户在应用数据库的过程提供诊断优化能力，DAS能够帮忙用户自发现、自诊断、自优化、自决策地解决用户数据库的问题。 4.丰盛插件 RDS PG的Ganos时空引擎插件提供了时空数据的存储、检索、查问以及剖析能力。第二个插件是PASE高效向量检索插件。第三个插件是oss\_fdw，实现数据冷热拆散的场景，将冷数据存储在更为高价的OSS上，在RDS PG上能够对OSS上的数据进行查问剖析。通过以上能够发现，相较自建PG，RDS PG在可靠性、安全性、智能化、插件丰盛度方面劣势显著。二、PostgreSQL版本升级背景 PostgreSQL的降级性能源于用户应用中遇到的一些问题，在降级中咱们也面临许多挑战。 1.遇到的问题老版本：过期不保护过低的数据库版本,稳定性挑战, 比方: 1）PG 9.4，版本过老2）低版本，供应链问题3）社区不保护，无人兜底高版本：新个性用户对于高版本、新个性的强力需要, 比方: 1）增量排序2）并行索引垃圾回收3）索引deduplicate能力4）分区表、聚合性能晋升 2.面临的挑战 ...

关于sql:SQL请求行为识别新功能帮助解决异常SQL检测之大海捞针问题

简介：对于异样SQL中存在的业务属性的相似性以及盘根错节的影响与被影响的关系，理分明问题SQL与各种资源的异常现象的流传关系是具备挑战的。DAS团队依然在如何找到异样SQL这个课题上持续进行了钻研和摸索，在摸索的过程中咱们提供了一个新的剖析性能SQL申请行为辨认帮忙用户更好的定位SQL问题。业务背景:DAS(Database autonomy service)为上百万数据库实例的稳固运行保驾护航，其中精准定位数据库运行过程中的异样SQL是DAS最根本的性能。数据库90%以上的问题都来源于数据库的异样申请，无论是双十一的团体海量交易申请行为，还是用户业务变动的申请行为，每时每刻都影响着数据库的性能。主动驾驶汽车通过感知路况图像变动的行为来把握车的方向，而主动驾驶数据库通过感知和辨认用户申请行为来一直修复优化数据库的各种问题，为云数据库保驾护航。如何从海量数据库中的海量申请定位出不同数据库引擎不同场景的问题是多年以来困扰DBA的难题。在举荐畛域，通过剖析用户的行为习惯代替了机械式网页展现精准举荐给用户冀望的文字/视频/产品，晋升用户体验和产品转化率，同样下一代数据库主动驾驶平台也须要剖析用户申请行为，用户开发业务行为，举荐出相应优化修复扩容等操作，晋升主动驾驶数据库的效率，让数据库更快更稳更平安。所以从用户申请行为和业务行为登程，在海量数据库实例的海量申请中进行数据挖掘是一个十分值得深入研究的课题，同时也是数据库主动驾驶平台十分依赖的底层技术能力, 向上撑持DAS数据库自治服务各个场景的自治能力。 DAS这这些年提供了多个对SQL数据进行剖析的L2性能包含：专业版SQL洞察，全量SQL，慢日志，一键诊断，锁剖析，会话等。每一个性能积淀了DBA在不同角度剖析不同问题的办法，不同实例，不同业务诊断问题的办法略有不同。对于并不是很相熟DB运维的用户来说，DAS在提供一个对立高效简略的形式去帮忙用户去定位问题。咱们联合SQL变慢的多指标特色，提出一种基于特色类似度匹配的办法 VLDB 2020 积淀到自治核心性能当中, 但对于异样SQL中存在的业务属性的相似性以及盘根错节的影响与被影响的关系，理分明问题SQL与各种资源的异常现象的流传关系是具备挑战的问题，DAS团队依然在如何找到异样SQL这个课题上持续进行了钻研和摸索，在摸索的过程中咱们提供了一个新的剖析性能SQL申请行为辨认帮忙用户更好的定位SQL问题。问题形容:以下图为例，实例CPU呈现尖刺突增的景象，数据库有cpu打满潜在危险，当用户的申请量较少或者申请的SQL模式较少的时候，通过指标的排序筛选是很容易找到问题SQL的，但当用户的全量SQL模板超过上万甚至上亿条，用户通过以后DAS页面无奈疾速定位异样SQL，咱们须要通过更多数据提供更高效的形式，来定位异样申请。当用户应用DAS专业版SQL洞察的性能的时候，即便咱们将全量SQL流水，压缩聚合成模板，模板的数量也是惊人的，咱们能够看到大量特色趋势相近的模板。所以如果咱们依据SQL的申请行为将模板进一步压缩，这样用户能够更好的定位异样SQL的问题目前DAS产品性能和业界AWS Azure等其余产品都有初步的异样SQL定位能力，通过对采集的SQL数据在各个维度的排序，让用户本人定位数据库问题，这种形式对于80%以上简略的数据库问题是无效的，然而在简单业务场景和DBA都很难定位的数据库问题成果是很差的。以阿里云外部管控的元数据库集群实例为例，往年均匀每月产生10屡次的CPU打满问题，全年产生数次性能相干的故障问题，然而每次的问题都不同，有时候DBA只能找到景象，难以疾速定位问题根因。所以通过对用户申请行为的剖析，会更好的迭代DAS数据库自治服务产品，解决咱们简单场景的数据库性能问题，进步整个数据库各个引擎的稳定性，易用性，效率。业界产品:AWS: RDS： Performance Insight 和目前DAS产品性能一样，采集的数据维度相似，通过Top N ranking的形式进行异样SQL定位，没有SQL申请行为剖析性能 Azure: Query Performance Insight 通过取Top N的形式对SQL申请进行定位，能够定位到60%的显著问题，然而无奈定位SQL申请简单业务的数据库问题，没有SQL申请行为剖析性能腾讯云：DB Brain性能，和目前DAS现有性能相似，没有SQL申请行为剖析性能华为云：Database Admin Service，和目前DAS现有性能相似，没有SQL申请行为剖析性能挑战&难点Challenges: 规模化挑战:The sea of performance issues in the sea of queries from the sea of the databases 用户的业务申请丰盛，如何从海量数据库实例中的海量申请中定位多种数据库引擎的性能问题。监控诊断挑战：7*24 real time anomaly detection => 7*24 root cause analysis in near real time 针对潜在的SQL申请导致的数据库性能问题，根因定位须要做到近实时问题定位。 ...

关于sql:功能更新｜DAS推出全局Workload优化功能实现SQL自动诊断

简介：DAS推出了全局Workload优化性能，能够及时检测到数据库的负载变动，辨认到新增SQL、执行变动的SQL以及性能不佳的SQL，并综合思考SQL的执行频率和相干SQL信息，给出优化倡议。背景日常的数据库优化中，在数据库的表上创立适合的索引是解决慢SQL查问问题的一种十分重要且罕用的计划。在处理过程中，DBA或者开发人员通常会依据实例上的慢SQL信息进行优化，DAS主动SQL优化性能曾经实现了依据慢SQL进行主动诊断，并创立适合的索引。但该计划会面临如下几个挑战：数据采集问题：一些业务SQL并没有达到慢SQL采集的阈值（比方1s），而这些SQL查问自身没有很好的利用索引，查问效率不高，依然有很大的优化空间。在并发量增大或者表数据增多的状况下，这些查问很容易造成实例性能忽然好转而引起故障。写入代价问题：在创立索引时通常更重视进步数据读取的效率，而疏忽索引保护对写入性能的影响和空间占用的老本，对于写多读少的表，创立太多索引反而会影响零碎吞吐。workload变动问题：索引一旦创立，通常状况下很少变动，而业务却始终在动态变化中。随着业务一直迭代变动，一些索引可能不再有SQL应用，或者应用频率很低，此时须要引入更优的索引设计来晋升数据库的解决性能。为了解决上述问题，DAS推出了全局Workload优化性能，它能够及时检测到数据库的负载变动，辨认到新增SQL、执行变动的SQL以及性能不佳的SQL，并综合思考SQL的执行频率和相干SQL信息，给出优化倡议。解决方案介绍全局Workload优化，次要由三局部组成。 Workload检测：依据数据库实例上和Workload相干的性能指标(如RT，CPU等)以及全量SQL相干指标(执行次数、执行耗时、扫描行数等)，训练数据模型，实时检测Workload的SQL执行状况，从而辨认新增SQL、执行变动的SQL，以及整个负载变动的周期。如下图所示，全量SQL执行情况指标在period1和period2呈周期性状态，至period3，执行情况发生变化。全局Workload优化，依据数据训练模型，轻松实现辨认负载变动的工夫区间。全局诊断：全局诊断优化则依据数据库在某一时间范畴内的全副SQL执行状况，综合思考SQL的查问和写入性能以及空间占用状况，举荐最优索引组合，从而从SQL角度最大限度进步数据库的性能，升高数据库导致的问题的概率。智能压测：智能压测能够回放实例上某个时间段内的全副SQL（该性能会在相干文章中具体解读），将全局诊断和智能压测联合后，零碎能够在测试实例上依据诊断倡议主动创立索引，回放历史流量并比照驳回倡议前后的SQL执行状况，生成测试报告。具体实现触发机会全局workload诊断反对用户自定义触发和零碎自动检测触发两种模式：用户触发能够依据业务需要制订工夫区间，触发全局诊断获取优化倡议；自动检测会实时监测实例的负载信息，检测到数据库有异样SQL呈现，或者发现Workload整体趋势变动，及时触发全局workload诊断。其中异样SQL包含：(1) 新增SQL；(2) 执行次数占比浮动20%以上SQL；(3) 执行均匀RT浮动20%以上SQL等。通过自动检测机制，能够帮忙用户及时发现结构设计落后于业务变动的场景，缩小故障产生的概率以及资源节约。数据起源全局workload诊断的数据起源是SQL审计，包含SQL类型、SQL模版、执行次数以及SQL性能信息等。SQL审计会记录诊断工夫内执行的所有SQL，因而能够发现不是慢SQL但性能欠佳的SQL问题。关联SQL剖析通过解析SQL模版和元数据，能够剖析出SQL、表、列之间的拜访关系，从而失去可能相互影响的SQL汇合。通过关联性剖析，能够无效地缩小后续求解问题的复杂度，同时为索引上线后的性能跟踪服务提供根底的数据反对。候选索引生成及代价评估该模块和前面的优化求解是全局workload优化的外围模块。在单SQL的索引举荐中能够依据一些规定或者教训来举荐索引，也能获得肯定的成果，但基于全局workload的优化基于规定的办法就简直有效了，必须可能将代价进行量化。咱们基于DAS实现的外置优化器，能够做到疾速精确的解析语法树、采样收集统计信息、生成候选索引以及计算应用某个索引的代价。优化求解在确定候选索引集以及索引代价的状况下，抉择最有索引汇合的过程能够等价为一个背包问题的变种。抉择某个索引的收益等价为放入背包物品的价值，因为创立一个索引既能够给查问带来正收益也会对写入和空间老本带来副收益，因而价值能够是负数也能够是正数。背包的容量是一个表上最多建设索引的阈值（用户设置或零碎默认，并非数据库存储束缚）。咱们的指标是使得背包中物品价值最大。另外须要留神的是，当抉择一个索引后，它会对其余索引的价值产生影响，因而在每次迭代抉择物品时须要依据曾经存在索引的状况，更新残余待选索引的价值。索引I代价 = 执行次数 * （a*读收益 - b*写代价 - c*空间占用）成果验证为了保障优化倡议的有效性，咱们和智能压测性能整合到一起，提供疾速不便的验证计划。智能压测系统会主动搭建测试实例上并同步实在数据，而后在测试上主动驳回优化倡议，回放诊断时间段内的全量SQL并采集SQL执行的性能数据，最初比照生成测试报告。这种计划的益处是既保证了测试场景和线上业务的一致性，又不会对线上运行业务造成影响，同时还能预估驳回倡议后产生的影响。示例比方表1中存在6条SQL，如果独立的看每一条SQL，失去的优化索引可能为表2中的4条索引；而从workload维度来看，索引能够合并为表3的两条索引。两种后果比照，整体RT降落14.45%，索引空间节俭50%。 SQL2 ： idx\_is\_deleted\_gmt\_modified (is\_deleted, gmt\_modified) SQL4 : idx\_name(name) SQL5: idx\_name\_id\_birth\_date (name, id, birth\_date) SQL6: idx\_name\_nick\_name （name, nick\_name） idx\_is\_deleted\_gmt\_modified (is\_deleted, gmt\_modified) idx\_name\_id\_birth\_date (name, id, birth\_date) 将来打算全局Workload优化将来会打造主动优化的闭环，包含workload异样检测、全局workload诊断、智能压测成果评估，主动驳回倡议、成果跟踪及异样解决。另外，目前全局workload优化思考了SQL执行频率，SQL查问和写入的影响，但没有思考固定参数或者参数歪斜等问题，前面能够进一步将这些业务属性纳入到思考因素当中。 ...

关于sql:一文读懂阿里云数据库Autoscaling是如何工作的

简介：阿里云数据库实现了其特有的Autosaling能力，该能力由数据库内核、管控及DAS（数据库自治服务）团队独特构建，内核及管控团队提供了数据库Autoscaling的根底能力，DAS则负责性能数据的监测、Scaling决策算法的实现及Scaling后果的出现。本文将从Autosaling的工作流程和落地等方面，具体论述Autosaling相干常识。1. 前言Gartner预测到2023年，寰球3/4的数据库都会跑在云上，云原生数据库最大的劣势之一便是人造领有云计算的弹性能力，数据库能够像水、电、煤一样随取随用，而Autosaling能力便是弹性的极致体现。数据库的Autoscaling能力是指数据库处于业务高峰期时，主动扩容减少实例资源；在业务负载回落时，主动开释资源以降低成本。业界的云厂商AWS与Azure在其局部云数据库上实现了Autoscaling能力，阿里云数据库同样实现了其特有的Autosaling能力，该能力由数据库内核、管控及DAS（数据库自治服务）团队独特构建，内核及管控团队提供了数据库Autoscaling的根底能力，DAS则负责性能数据的监测、Scaling决策算法的实现及Scaling后果的出现。DAS（Database Autonomy Service）是一种基于机器学习和专家教训实现数据库自感知、自修复、自优化、自运维及自平安的云服务，帮忙用户打消数据库治理的复杂性及人工操作引发的服务故障，无效保障数据库服务的稳固、平安及高效。其解决方案架构如图1.所示，Autoscaling/Serverless能力在其中属于“自运维”的局部。图1. DAS的解决方案架构 2. Autosaling的工作流程数据库Autoscaling整体的工作流程可定义为如图2.所示的三个阶段，即“When：何时触发Scaling”、“How：采取哪种形式Scaling”及“What：Scaling到哪个规格”。何时触发Scaling即确定数据库实例的扩容与回缩的机会，通常的做法是通过观测数据库实例的性能指标，在实例的负载高峰期执行扩容操作、在负载回落时执行回缩操作，这是常见的Reative被动式触发形式，除此之外咱们还实现了基于预测的Proactive主动式触发形式。对于触发机会在2.1章节会进行具体的介绍。Scaling的形式通常有ScaleOut（程度扩缩容）与ScaleUp（垂直扩缩容）两种模式。以分布式数据库PolarDB为例，ScaleOut的实现模式是减少只读节点的数量，例如由2个只读节点减少至4个只读节点，该形式次要实用于实例负载以读流量占主导的情景；ScaleUp的实现模式是降级实例的CPU与内存规格，如由2核4GB降级至8核16GB，该形式次要实用于实例负载以写流量占主导的情景。对于Scaling形式在2.2章节会进行具体的介绍。在扩容形式确定后须要抉择适合的规格，来使实例的负载降至正当的水位。例如对于ScaleOut形式，须要确定减少多少个实例节点；对于ScaleUp形式，须要确定降级实例的CPU核数与内存，以确定降级至哪种实例规格。对于扩容规格的抉择在2.3章节会进行具体的介绍。图2. Autoscaling的工作流程图示 2.1 Autoscaling的触发机会2.1.1 Reactive被动式触发（基于察看）基于察看的Reactive被动式触发是以后Autoscaling次要的实现模式，由用户为不同的实例设置不同的扩、缩容触发条件。对于计算性能扩容，用户能够通过设置触发CPU阈值、观测窗口长度、规格下限、只读节点数量下限及静默期等选项来配置合乎业务负载的触发条件；对于存储空间扩容，用户能够通过设置空间的扩容触发阈值及扩容下限来满足实例业务的增长，并防止磁盘资源的节约。被动式触发的配置选项在3.2章节会进行具体的展现。 Reactive被动式触发的长处是实现绝对容易、用户接受度高，但如图3.所示，被动式触发也存在其毛病，通常Scaling操作在达到用户配置的观测条件后才会真正执行，而Scaling操作的执行也须要肯定的工夫，在这段时间内用户的实例可能曾经处于高负载较长时间，这会在肯定水平上影响用户业务的稳定性。图3. 被动式触发的扩容资源比照图示 2.1.2 Proactive主动式触发（基于预测）解决Reactive被动式触发的办法便是Proactive主动式触发，如图4.所示，通过对实例负载的预测，在预测实例负载行将处于顶峰前的一段时间，便提前对实例执行扩容操作，使实例可能安稳度过整个业务高峰期。周期性workload是基于预测的形式中最典型的利用场景（线上具备周期性特色的实例约占40%），DAS应用了达摩院智能数据库实验室同学实现的周期性检测算法，该算法联合了频域和时域信息，准确率达到了80%以上。例如对具备“天级别”周期性特色的线上实例，Autoscaling服务会在实例每天的业务高峰期开始之前进行扩容，以使实例更好地应答周期性的业务峰值。图4. 主动式触发的扩容资源比照图示咱们同样在RDS-MySQL的存储空间扩容里实现了基于预测的形式，基于实例过来一段时间的磁盘使用量指标，应用机器学习算法预测出实例在接下来的一段时间内存储空间会达到的最大值，并会依据该预测值进行扩容容量的抉择，能够防止实例空间快速增长带来的影响。图5. 基于磁盘使用量趋势的预测 2.2 Autoscaling的形式决策DAS的Autoscaling形式有ScaleOut与ScaleUp两种，在给出Scaling计划的同时也会联合Workload全局决策分析模块给出更多的诊断倡议（如SQL主动限流、SQL索引倡议等等）。如图6.所示是Scaling形式的决策示意图，该示意图以PolarDB数据库作为示例。PolarDB数据库采纳的是计算存储拆散的一写多读的分布式集群架构，一个集群蕴含一个主节点和多个只读节点，主节点解决读写申请，只读节点仅解决读申请。图6.所示的“性能数据监测模块”会一直的监测集群的各项性能指标，并判断以后时刻的实例负载是否满足2.1章节所述的Autoscaling触发条件，当满足触发条件时，会进入到图6.中的Workload剖析模块，该模块会对实例以后的Workload进行剖析，通过实例的会话数量、QPS、CPU使用率、锁等指标来判断实例处于高负载的起因，若判断实例是因为死锁、大量慢SQL或大事务等起因导致的高负载，则在举荐Autoscaling倡议的同时也会推出SQL限流或SQL优化倡议，使实例迅速故障自愈以升高危险。在Autoscaling形式的决策生成模块，会判断采取何种Scaling形式更无效。以PolarDB数据库为例，该模块会通过实例的性能指标以及实例的主库爱护、事务拆分、零碎语句、聚合函数或自定义集群等特色来判断集群以后的负载散布，若判断实例以后以读流量占主导，则会执行ScaleOut操作减少集群的只读节点数量；若判断实例以后以写流量占主导，则会执行ScaleUp操作来降级集群的规格。ScaleOut与ScaleUp决策的抉择是一个很简单的问题，除了思考实例以后的负载散布外，还须要思考到用户设置的扩容规格下限及只读节点数量下限，为此咱们也引入了一个成果追踪与决策反馈模块，在每次决策判断时，会剖析该实例历史上的扩容形式及扩容成果，以此来对以后的Scaling形式抉择算法进行肯定的调整。图6. PolarDB的Scaling形式决策示意图 2.3 Autoscaling的规格抉择2.3.1 ScaleUp决策算法ScaleUp决策算法是指当确定对数据库实例执行ScaleUp操作时，依据实例的workload负载及实例元数据等信息，为以后实例抉择适合的规格参数，以使实例以后的workload达到给定的束缚。最开始DAS Autoscaling的ScaleUp决策算法基于规定实现，以PolarDB数据库为例，PolarDB集群以后有8种实例规格，采纳基于规定的决策算法在后期足够用；但同时咱们也摸索了基于机器学习/深度学习的分类模型，因为随着数据库技术最终迭代至Serverless状态，数据库的可用规格数量会十分宏大，分类算法在这种场景下会有很大的用武之地。如图7.及图8.所示，咱们以后实现了基于性能数据的数据库规格离线训练模型及实时举荐模型，通过对自定义CPU使用率的范畴标注，参考DAS之前落地的AutoTune主动调参算法，在标注数据集进行模型分类，并通过实现的proxy流量转发工具进行验证，以后的分类算法曾经获得了超过80%的准确率。图7. 基于性能数据的数据库规格ScaleUp模型离线训练示意图图8. 基于性能数据的数据库规格ScaleUp实时举荐办法示意图 2.3.2 ScaleOut决策算法ScaleOut决策算法与ScaleUp决策算法的思路相似，实质问题是确定减少多少个只读节点，能使实例以后的workload负载降至正当的水位。在ScaleOut决策算法里，咱们同样实现了基于规定的与基于分类的算法，分类算法的思维与2.3.1章节里形容的根本相似，基于规定的算法思维则如图9.所示，首先咱们须要确定与读流量最相干的指标，这里选取的是com\_select、qps及rows\_read指标，s\_i示意第i个节点读相干指标的表征值，c\_i示意第i个节点的指标束缚表征值（通常应用CPU使用率、RT等间接反馈业务性能的指标），f指指标函数，算法的指标便是确定减少多少个只读节点X，能使整个集群的负载降至f函数确定的范畴。该计算方法明确且无效，算法上线后，以变配后集群的CPU负载是否降至正当水位作为评估条件，算法的准确率达到了85%以上，在确定采取ScaleOut变配形式后，ScaleOut决策算法新增的只读节点根本都能处于“恰好饱和”的工作负载，可能无效的晋升数据库实例的吞吐。图9. 基于性能数据的数据库节点数量ScaleOut举荐算法示意图 3. 落地3.1 实现架构Autoscaling能力集成在DAS服务里，整个服务波及异样检测、全局决策、Autoscaling服务、底层管控执行多个模块，如图10.所示是DAS Autoscaling的服务能力架构。异样检测模块是DAS所有诊断优化服务（Autoscaling、SQL限流、SQL优化、空间优化等）的入口，该模块会7*24小时对监控指标、SQL、锁、日志及运维事件等进行实时检测，并会基于AI的算法对其中的趋势如Spike、Seasonaliy、Trend及Meanshift等进行预测及剖析；DAS的全局决策模块会依据实例以后的workload负载给出最佳的诊断倡议；当由全局决策模块确定执行Autoscaling操作时，则会进入到第2章节介绍的Autoscaling工作流程，最终通过数据库底层的管控服务来实现实例的扩、缩容。图10. DAS及AutoScaling的服务能力架构 3.2 产品计划本章节将介绍Autoscaling性能在DAS里的开启形式。如图11.所示是DAS的阿里云官网产品首页，在该界面能够看到DAS提供的所有性能，如“实例监控”、“申请剖析”、“智能压测”等等，点击“实例监控”选项能够查看用户接入的所有数据库实例。咱们点击具体的实例id链接并抉择“自治核心”选项，能够看到如图12.及图13.所示的PolarDB主动扩、缩容设置及RDS-MySQL主动扩容设置，对于PolarDB实例，用户能够设置扩容规格下限、只读节点数量下限、观测窗口及静默期等选项，对于RDS-MySQL实例，用户能够设置触发阈值、规格下限及存储容量下限等选项。图11. DAS产品首页图12. PolarDB主动扩、缩容设置图示图13. RDS-MySQL主动扩、缩容设置图示 3.3 成果案例本章节将介绍两个具体的线上案例。如图14.所示为线上PolarDB实例的计算规格Autoscaling触发示意图，在05:00-07:00的时间段，实例的负载缓缓回升，最终CPU使用率超过了80%，在07:00时触发了主动扩容操作，后盾的Autoscaling服务判断实例以后读流量占主导，于是执行了ScaleOut操作，为集群减少了两个只读节点，通过图示能够看到，减少节点后集群的负载显著降落，CPU使用率降至了50%左右；在之后的2个小时里，实例的业务流量持续减少，导致实例负载持续在迟缓回升，于是在09:00的时候再次达到了扩容的触发条件，此时后盾服务判断实例以后写流量占主导，于是执行了ScaleUp操作，将集群的规格由4核8GB降级到8核16GB，由图示能够看到规格降级后实例的负载趋于稳定，并维持了近17个小时，之后实例的负载降落并触发了主动回缩操作，后盾Autoscaling服务将实例的规格由8核16GB降至4核8GB，并缩小了两个只读节点。Autoscaing服务在后盾会主动运行，无需人工干预，在负载高峰期扩容、在负载低谷时回缩，晋升业务稳定性的同时升高了用户的老本。图14. 线上PolarDB 程度扩容、垂直扩容成果示意图 ...

关于sql:数据库自治服务DAS论文入选全球顶会SIGMOD领航数据库自动驾驶新时代

简介：近日，智能数据库和DAS团队研发的智能调参ResTune零碎论文被SIGMOD 2021录用，SIGMOD是数据库三大顶会之首，是三大顶会中惟一一个Double Blind Review的，其权威性毋庸置疑。近日，智能数据库和DAS团队研发的智能调参ResTune零碎论文被SIGMOD 2021录用，SIGMOD是数据库三大顶会之首，是三大顶会中惟一一个Double Blind Review的，其权威性毋庸置疑。 ResTune论文的录用，阐明了咱们在智能化数据库管控方向的技术积攒和深度，也是阿里云自治数据库和智能化运维里程碑式的一步。目前，智能调参性能曾经在数据库自治服务（DAS）上落地，是业界第一个正式上线的数据库配置参数智能调参性能，进一步阐明了阿里云自治数据库方向的技术当先性。 1. 概述调参服务在阿里丰盛的业务场景中有着宽泛的利用，如数据库系统的性能与配置参数优化、机器学习模型/深度神经网络的超参抉择、举荐零碎和云调度零碎中参数的自适应调节、工业管制和供应链中的仿真优化和参数优化等。如何在生产环境中反对客户理论需要，是学术界AI for system的一个钻研热点。往年，由达摩院-数据库与存储实验室-智能数据库团队研发的ResTune智能调参工作（ResTune: Resource Oriented Tuning Boosted by Meta-Learning for Cloud Databases，地址： https://dl.acm.org/doi/pdf/10.1145/3448016.3457291__），次要针对OLTP数据库系统的性能参数进行调优，波及RDS MySQL、RDS PostgreSQL、PolarDB MySQL、PolarDB-O等数据库系统，该工作发表在数据库畛域的顶级会议SIGMOD2021(Research Track)，并在阿里云数据库自治服务DAS产品中技术落地。 2. 背景数据库系统如MySQL提供200多个配置参数，不同的参数组合与一直变动的业务负载特色，独特决定着数据库系统的性能和资源应用。针对团体内的业务，通常DBA会依据不同的业务，按人工教训手动抉择一组适宜的参数。随着数据库上云的减速，业务越来越多样化，仅仅依赖于DBA人工调参遇到程度扩大的瓶颈制约。同时，因为DBA教训的差异性，很难对多种多样的业务负载都找出最优参数。云厂商要做到“客户第一”，自动化的调参性能至关重要：在不同的实例环境下对工夫上一直变动的多样业务负载，自适应的提供个性化的优化参数。数据库系统调参须要同时思考性能(如Transactions per second/TPS、Latency)和资源应用(CPU、Memory、IO)的状况。性能优化诚然重要，但实在负载的TPS往往受用户的request rate所限，很难达到峰值性能。图1是两个参数下不同取值的TPS和CPU利用率，能够看到，在TPS最高的红色区域对应的CPU利用率变动较大，从15%到75%。而在TPS雷同的状况下，资源利用率有很大优化空间。从老本角度，TCO(Total Cost of Ownership)是云数据库的重要指标，也是云数据库的次要劣势。优化资源应用对缩小云数据库的TCO，进步老本劣势有着重要意义。事实上，咱们发现云上大多数实例都存在Over-Provision的状况。此外，资源应用过高可能会造成云数据库的异样和资源争抢带来的性能降落；优化数据库的资源应用可能无效缩小甚至防止此类情况引发的故障，进步稳定性。 3. 挑战咱们剖析了调参的指标是同时思考优化资源使用率和性能，上文也提到性能如TPS往往会被客户端的request rate所限而达不到峰值性能。因而，咱们须要找出资源利用率最小的数据库配置参数，并且满足SLA的要求。另一方面，调参自身须要尽可能快（不然违反了升高资源应用），通常的调参零碎须要上百步迭代来找出好的配置，每一步迭代约3-5分钟回放workload，这样通常须要天级别的工夫进行调参训练。但如果想解决在线troubleshoot的需要，往往须要在1个小时内找出问题，进行复原。作为云厂商，咱们基于已有业务负载调参的历史数据，采纳常识迁徙学习，可无效减速调参过程，从而尽可能快地找出好的数据库参数配置。 4. 相干工作数据库调参是最近钻研绝对热门的畛域，在过来几年中有不少工作发表。这些工作依照技术思路次要能够分为三大类：基于搜寻的启发式办法、基于贝叶斯优化的办法、基于强化学习(Reinforcement Learning)模型的办法。基于搜寻的启发式办法：该类办法通常基于启发式思路，通过给定的规定算法进行搜寻来找出优化参数，这一工作的代表是BestConfig[3]零碎。这类办法依赖于对workload以及参数对性能影响的先验假如，但在理论中特地是云场景，往往很难为每个workload进行非凡优化和特色工程。这类办法在搜寻一组新参数的时候，没有思考到之前采样到数据的散布，因而效率不高。基于贝叶斯优化的办法：该类办法的代表是iTuned[4]和CMU的Andy Pavlo实验室的SIGMOD17工作OtterTune[5]。贝叶斯优化将调参看作是一个黑盒优化问题，通过代理函数模仿参数和指标间的函数，并设计采集函数来最小化采样步数。这类办法没有思考以优化资源为指标的调参，只思考了优化峰值性能。在理论中，除了压测和大促的极其场景，通常用户对TPS是无感的，TPS往往达不到峰值，因而仅思考性能作为指标还不够。OtterTune零碎还提出了基于Internel Metric（数据库状态表的指标）的mapping的计划来利用已有数据，这种mapping办法利用来自同一硬件类型的历史数据，没有充分利用云厂商丰盛的数据资源。另一方面，这种形式依赖于预测进去的Internel Metric的相似性计算，在数据点较少的状况下容易不精确。基于强化学习的办法：这类办法是最近数据库调参的热门方向，次要包含SIGMOD18的工作CDBTune[6]和VLDB19的QTune[7]工作。通过将Internal Metrics(state)到Knobs(action)的关系形象成一个policy neural network和一个value network来反馈，将数据库调参问题转化成一个马尔科夫决策过程，一直地自我训练，学习出最优参数。一方面，这类工作没有思考优化资源。另一方面，更重要的是调参问题并不是一个带状态的马尔科夫决策过程，因为参数间接决定了数据库性能，不须要简单的状态空间，不同于强化学习须要通过解bellman equation来优化模型累计取得的Reward。在这些工作中，往往须要上千步迭代找出好的参数，这难以满足咱们在生产环境中进行调参的要求。5. 问题定义和算法概述咱们将问题定义成带限度的优化问题如下，其中限度条件常数可通过设定为默认配置参数下的TPS和Latency值。 ResTune将最优化资源应用并满足SLA转化成带限度的优化 (Constrained Bayesian Optimization) 问题。相比于传统的贝叶斯优化算法，这里采纳了带限度的 EI 函数 (Constrained EI, CEI)，咱们将限度信息退出了罕用的 EI 效用函数(Acqusition Function)。详见论文的第五章内容。另一方面，为了更好地利用已有数据，ResTune还设计了动态权重和动静权重相结合的高斯加权模型。通过ensemble历史的高斯过程模型，加权均匀出指标workload的surrogate函数。这里最外围的问题是如何定义权重。在冷启动时（没有察看数据时），动态权重学习会依据工作工作负载的 meta-feature 间隔调配权重。meta-feature 的计算须要通过工作负载的剖析，失去工作负载特征向量。 ...

关于sql:COMP524JAN21

COMP524-JAN21 Safety and Dependability University of LiverpoolCOMP524-JAN21 Continuous Assessment 2Coordinator: Fabio PapacchiniAssessment InformationAssignment Number 2 (of 2)Weighting 15%Assignment Circulated 21/06/2021Deadline 14/07/2021 at 5pm BST (GMT +1)Submission Mode Please submit your solutions electronically on Canvas. You submissionshould have two files: (1) a ZIP file containing executables (the .pm and.pctl files) for the models and properties, and (2) a PDF/DOC/DOCX filethat contains the results and explanations.Submission necessary in order tosatisfy Module requirements?NoLate Submission Penalty Standard UoL Late Penalties policy appliesPlagiarism and Collusion Please be aware of the University guidelines on plagiarism and collusion. COMP524-JAN21 Safety and Dependability University of LiverpoolTask DescriptionEight and a Half – Simplified Variation of Seven and a Half. Eight and a half 1 is a spin-the-wheelgame between a player and the bank. It is played with the wheel depicted below (i.e., the wheel is dividedinto 12 equal slices, each slice has a value between 1 and 8, or the value of 12 ). The game consists of tworounds: in a first round, the player can spin the wheel several times, in the second round the bank can spinthe wheel several times.Figure 1: The 8 + 12 wheelThe player’s round. Starting with a score of 0, the player canrepeatedly? spin the wheel? add the number pointed by the marker to their score.After adding the number to their score, the player can eitherfinish their round, or repeat the above process. However, the playerloses immediately if their score exceeds 8 + 12 .The bank’s round. Starting with a score of 0, the bank can (sim-ilar to the player in the previous round) repeatedly spin the wheel add the number pointed by the marker to the bank’s score.The bank has to keep on spinning the wheel until the bank’s score reaches or exceeds the player’s score.The bank haswon if the bank’s score at this time does not exceed 8 + 12 andlost if the bank’s score at this time exceeds 8 + 12 . ...

关于sql:数据库自治服务DAS年度新版本数据库自动驾驶进入规模化时代

简介：在明天的发布会上，针对用户的外围痛点，DAS新公布了8大外围自治性能，包含7x24小时异样检测、主动SQL限流、主动SQL优化、主动空间优化、主动弹性伸缩、智能调参、智能压测、实时审计等，为企业的SQL问题、数据库负载问题、空间问题、容量评估、平安审计，从异样发现、根因定位、自修复/自优化/自平安，既能实现疾速止损，又会继续一直的对数据库进行优化，无需人工干预，让企业像体验“主动驾驶”一样应用数据库，数据库治理老本升高90％。阿里云云盒更多内容：https://yqh.aliyun.com/live/cloudbox 2020年4月，阿里云数据库自治服务DAS 正式公布，开启数据库“主动驾驶”新时代。通过一年的工夫，数据库自治服务DAS的辅助自治模式曾经反对阿里云全网100%的高可用实例，并且曾经有超过5000的客户，运行在DAS的自治模式，即受权DAS进行数据库的自修复、自优化、自运维和自平安。让数据库施展最优的效力，依赖很多数据库业余畛域常识，对于大部分企业和利用开发者而言，仍然充斥挑战，如故障诊断，疾速定位根因并进行无效的止损；业务疾速迭代过程中的数据库的继续调优、SQL Review等，都是十分耗时耗力且须要7x24小时值守的能力，因而，数据库走向自治是一个必然趋势。如果说，传统数据库向云数据库的转变是“汽车换马车”，那么DAS就是给“汽车”加上了“主动驾驶”的引擎，领有了“主动驾驶”的能力。在明天的发布会上，针对用户的外围痛点，DAS新公布了8大外围自治性能，包含7x24小时异样检测、主动SQL限流、主动SQL优化、主动空间优化、主动弹性伸缩、智能调参、智能压测、实时审计等，为企业的SQL问题、数据库负载问题、空间问题、容量评估、平安审计，从异样发现、根因定位、自修复/自优化/自平安，既能实现疾速止损，又会继续一直的对数据库进行优化，无需人工干预，让企业像体验“主动驾驶”一样应用数据库，数据库治理老本升高90％。 SQL问题——以无人值守形式，实现数据库继续优化数据库性能问题70%以上是SQL问题，然而传统计划上面不足无效的止损伎俩，并且不具备提前预防、继续优化的可能性。 DAS通过异样SQL的定位、异样SQL主动限流、主动SQL优化、后果验证，笼罩解决SQL问题的各个环节，实现及时发现、疾速止损、继续优化和可验证。数据库负载问题——实现全链路主动弹性伸缩，应答业务负载变动对于绝大多数企业来说，数据库都是骨干零碎，数据库负载飙升，会对业务造成微小的损失，然而基于阈值的告警形式，存在异样发现提早大的问题，往往不能在负载发生变化的时候，疾速发现并及时采纳止损措施。 DAS的7x24小时异样检测，能够1分钟内检测到数据库异样，并且反对全链路主动弹性伸缩（包含带宽、Porxy、CPU/内存/IO、节点等等），可能疾速解决数据库负载问题，保障业务继续可用。空间问题——数据库空间问题的自修复、自优化数据库空间问题，影响着数据库的性能和老本，DAS针对数据库常见的空间问题，提供了残缺的“治本”+“治标”的自修复、自优化计划，节俭数据库应用老本的同时，晋升数据库的性能。 DAS全方位自治能力助力企业用户施展数据库最优效力随着数据时代的降临，各个企业在业务高速增长的过程中都会不可避免地遇到数据库品种繁多、数据监测艰难、运维老本昂扬等常见数据库运维痛点。过来一年中，DAS已与5000+企业建设单干，为其提供业余且高效的数据库治理服务。咱们以出名 “AI+教育”上市公司英语流畅说和知名企业服务提供商用友用友为例，为大家展现DAS作为数据库性能优化利器，如何破解用户性能痛点，升高运维老本。流畅说：流畅说基于DAS构建了数据库运维体系和工具。该体系针对全局workload，采纳实在的业务流量和场景继续优化，实现主动跟踪和回滚的流程闭环，实现主动SQL Review和主动优化，让数据库实现真正的”自治“。在操作流程上，DAS的标准化无感接入和监控流程，无效躲避作业过程中人为脱漏及误操作的可能性。整套数据库运维体系因DAS对立接入和治理、主动诊断、主动SQL Review和优化等特色，真正做到业余且高效，大大加重了流畅说DBA日常工作量。流畅说基础架构负责人孙文杰示意：“DAS的引入使流畅说数据库整体性能失去优化，运维人效大幅晋升，并帮忙数据库治理团队从沉重的日常工作中开释人力，实现团队转型降级。DAS帮流畅说更聪慧、更业余、更高效地应用数据库服务。” 用友：DAS轻量级、个性化的智能压测服务，帮忙用友营销云应用实在业务场景和流量评估MySQL数据库迁徙到PolarDB的数据库容量和兼容性。在此过程中，DAS低负载捕捉实在业务流量、通过学习主动生成压测流量、反对写流量回放压测和语法主动转换，都有助于各项评估预见到可能存在的危险，多维度、高视角、全方位地为数据库迁徙保驾护航。容量评估方面，更是在智能压测期间依据业务需要精准评估了PolarDB规格，躲避了潜在的性能危险，精准评估迁徙实例规格，防止了不必要的IT资源节约。整个过程中，DAS始终为用友的数据库迁徙保驾护航，提前发现兼容性、性能危险，实现正当的容量评估。最终，顺利完成数据库迁徙的业务布局。 DAS诚挚邀你进入数据库“主动驾驶”时代仅仅用时一年，DAS便取得了5000+客户的信赖，迈入数据库“主动驾驶”时代。除去时代的需要，这份胜利背地还有一些必然因素。阿里巴巴外部纷繁复杂的业务场景、超过10万的数据库实例、疾速迭代的业务、超级热点“双十一”等等，都给DAS提供了举世无双、不可代替的“主动驾驶”训练场，帮忙DAS锻炼主动驾驶的能力。尽管DAS在2020年才公布，但其实早在2017年就开始研发了。在阿里巴巴外部，DAS经验了3年不间断的锻炼，撑持了3个双十一，主动优化了超过4900w的慢SQL，主动回收了4.6 PB的空间，主动优化了12%的内存。此外，达摩院前沿钻研的转化，用户业务类型的多样性、数据库的复杂性等等，都给数据库的主动驾驶带来了微小的挑战，其中很多问题对于业余的DBA都是难题，而DAS抉择了迎难而上，走在时代后面，事后解决所有问题。DAS由阿里云和达摩院联结研发，在异样检测、SQL诊断、根因定位等等核心技术下面取得了微小的冲破。过来3年，DAS相干研发团队在数据库国内顶级会议发表了4篇论文，包含SIGMOD、VLDB大会等。在过来半年多的工夫里，DAS每天进行数千亿次的异样检测，进行至多20万次以上的SQL诊断和优化，累计已帮忙用户主动解决10000+的故障，实现1分钟发现、5分钟定位、10分钟止损，无需用户人工干预，最大限度地保障数据库继续可用的阶段性指标。将来必将是数据库全自治的时代，DAS也将继续以数据库主动驾驶为指标，一直为其减少自感知、自决策、自复原、自优化和自平安的自治能力，为用户和行业解决更深层次的需要。相干浏览：深度技术揭秘 | 大促狂欢背地，如何无效评估并布局数据库计算资源？重磅 | 数据库自治服务DAS论文入选寰球顶会SIGMOD，领航“数据库主动驾驶”新时代干货｜SQL申请行为辨认新性能上线，帮忙解决异样SQL检测之海底捞针问题性能更新｜DAS推出全局Workload优化性能，实现SQL主动诊断干货｜一文读懂阿里云数据库Autoscaling是如何工作的版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

关于sql:干货｜SQL请求行为识别新功能上线帮助解决异常SQL检测之大海捞针问题

简介：对于异样SQL中存在的业务属性的相似性以及盘根错节的影响与被影响的关系，理分明问题SQL与各种资源的异常现象的流传关系是具备挑战的。DAS团队依然在如何找到异样SQL这个课题上持续进行了钻研和摸索，在摸索的过程中咱们提供了一个新的剖析性能SQL申请行为辨认帮忙用户更好的定位SQL问题。业务背景:DAS(Database autonomy service)为上百万数据库实例的稳固运行保驾护航，其中精准定位数据库运行过程中的异样SQL是DAS最根本的性能。数据库90%以上的问题都来源于数据库的异样申请，无论是双十一的团体海量交易申请行为，还是用户业务变动的申请行为，每时每刻都影响着数据库的性能。主动驾驶汽车通过感知路况图像变动的行为来把握车的方向，而主动驾驶数据库通过感知和辨认用户申请行为来一直修复优化数据库的各种问题，为云数据库保驾护航。如何从海量数据库中的海量申请定位出不同数据库引擎不同场景的问题是多年以来困扰DBA的难题。在举荐畛域，通过剖析用户的行为习惯代替了机械式网页展现精准举荐给用户冀望的文字/视频/产品，晋升用户体验和产品转化率，同样下一代数据库主动驾驶平台也须要剖析用户申请行为，用户开发业务行为，举荐出相应优化修复扩容等操作，晋升主动驾驶数据库的效率，让数据库更快更稳更平安。所以从用户申请行为和业务行为登程，在海量数据库实例的海量申请中进行数据挖掘是一个十分值得深入研究的课题，同时也是数据库主动驾驶平台十分依赖的底层技术能力, 向上撑持DAS数据库自治服务各个场景的自治能力。 DAS这这些年提供了多个对SQL数据进行剖析的L2性能包含：专业版SQL洞察，全量SQL，慢日志，一键诊断，锁剖析，会话等。每一个性能积淀了DBA在不同角度剖析不同问题的办法，不同实例，不同业务诊断问题的办法略有不同。对于并不是很相熟DB运维的用户来说，DAS在提供一个对立高效简略的形式去帮忙用户去定位问题。咱们联合SQL变慢的多指标特色，提出一种基于特色类似度匹配的办法 VLDB 2020 积淀到自治核心性能当中, 但对于异样SQL中存在的业务属性的相似性以及盘根错节的影响与被影响的关系，理分明问题SQL与各种资源的异常现象的流传关系是具备挑战的问题，DAS团队依然在如何找到异样SQL这个课题上持续进行了钻研和摸索，在摸索的过程中咱们提供了一个新的剖析性能SQL申请行为辨认帮忙用户更好的定位SQL问题。问题形容:以下图为例，实例CPU呈现尖刺突增的景象，数据库有cpu打满潜在危险，当用户的申请量较少或者申请的SQL模式较少的时候，通过指标的排序筛选是很容易找到问题SQL的，但当用户的全量SQL模板超过上万甚至上亿条，用户通过以后DAS页面无奈疾速定位异样SQL，咱们须要通过更多数据提供更高效的形式，来定位异样申请。当用户应用DAS专业版SQL洞察的性能的时候，即便咱们将全量SQL流水，压缩聚合成模板，模板的数量也是惊人的，咱们能够看到大量特色趋势相近的模板。所以如果咱们依据SQL的申请行为将模板进一步压缩，这样用户能够更好的定位异样SQL的问题目前DAS产品性能和业界AWS Azure等其余产品都有初步的异样SQL定位能力，通过对采集的SQL数据在各个维度的排序，让用户本人定位数据库问题，这种形式对于80%以上简略的数据库问题是无效的，然而在简单业务场景和DBA都很难定位的数据库问题成果是很差的。以阿里云外部管控的元数据库集群实例为例，往年均匀每月产生10屡次的CPU打满问题，全年产生数次性能相干的故障问题，然而每次的问题都不同，有时候DBA只能找到景象，难以疾速定位问题根因。所以通过对用户申请行为的剖析，会更好的迭代DAS数据库自治服务产品，解决咱们简单场景的数据库性能问题，进步整个数据库各个引擎的稳定性，易用性，效率。业界产品:AWS: RDS： Performance Insight和目前DAS产品性能一样，采集的数据维度相似，通过Top N ranking的形式进行异样SQL定位，没有SQL申请行为剖析性能 Azure: Query Performance Insight通过取Top N的形式对SQL申请进行定位，能够定位到60%的显著问题，然而无奈定位SQL申请简单业务的数据库问题，没有SQL申请行为剖析性能腾讯云：DB Brain性能，和目前DAS现有性能相似，没有SQL申请行为剖析性能华为云：Database Admin Service，和目前DAS现有性能相似，没有SQL申请行为剖析性能挑战&难点Challenges: 规模化挑战: The sea of performance issues in the sea of queries from the sea of the databases 用户的业务申请丰盛，如何从海量数据库实例中的海量申请中定位多种数据库引擎的性能问题。监控诊断挑战： 724 real time anomaly detection => 724 root cause analysis in near real time 针对潜在的SQL申请导致的数据库性能问题，根因定位须要做到近实时问题定位。 ...

关于sql:商业化十周年阿里云RDS推出企业级自治数据库

简介：近日，阿里云发表RDS数据库品牌降级打算，推出云原生企业级自治数据库。明天也是阿里云RDS商业化十周年。据理解，阿里云是国内首家提供自治服务的数据库厂商，基于人工智能和机器学习技术，阿里云RDS数据库提供主动降级、主动调优等100%数据库主动驾驶能力。云原生数据库2.0时代，阿里云RDS通过企业级的自治能力为客户提供更快、更稳、更平安的数据库服务。近日，阿里云发表RDS数据库品牌降级打算，推出云原生企业级自治数据库。明天也是阿里云RDS商业化十周年。据理解，阿里云是国内首家提供自治服务的数据库厂商，基于人工智能和机器学习技术，阿里云RDS数据库提供主动降级、主动调优等100%数据库主动驾驶能力。云原生数据库2.0时代，阿里云RDS通过企业级的自治能力为客户提供更快、更稳、更平安的数据库服务。十年前，基于MySQL打造了AliSQL分支，阿里巴巴推出第一款云数据库产品RDS MySQL，开启了数据库国产化之路。十年后，阿里云RDS数据库曾经成为国内规模最大、最稳固的云数据库，反对MySQL、PostgreSQL、MariaDB和SQL Server四款引擎。作为阿里云最受欢迎的产品之一，RDS数据库为阿里巴巴经济体提供最松软的撑持，历经多年双11高并发场景的历练，还服务了互联网、金融、电商、企业ERP、物流、酒店、高科技等各个行业的12万客户，有超过40万实例。十年再登程，在核心技术层面，阿里云RDS数据库提供基于Database Autonomy Service（简称DAS）的云原生企业级自治能力。以汽车行业的主动驾驶技术为例，主动驾驶个别分为L1-L5五个级别，目前最高级别的主动驾驶也只能达到 L3 级，即在特定的环境中实现局部主动驾驶的操作，而阿里云RDS在数据库畛域曾经先行一步，实现了100%“主动驾驶”。阿里云RDS数据库基于人工智能和机器学习技术可实现企业级自治，让数据库主动降级、主动调优、主动压测、SQL诊断优化、主动扩缩容、主动限流，此外还提供索引举荐、参数调优等一系列自治服务能力。采纳该服务的用户将可能：升高运维老本：齐全自治能让企业升高90%的运维老本。保障稳固平安：提供99.99%的高可用和RPO=0的企业级能力。SQL主动限流能够保障突发流量场景下数据库的稳固运行，为问题定位争取贵重的工夫。促成业务翻新：帮忙业务团队、DBA团队从日常的数据库保护等繁琐的工作中解脱进去，专一于开掘更多数据价值。开发者也能够更快的定位更新、发现数据库的性能问题，无需手动调优，节约更多工夫。目前，阿里云RDS数据库的自治服务已在虎扑、汇付天下、江门农商银行等客户中广泛应用。国内热门的体育互联网平台虎扑通过阿里云RDS弹性伸缩能力，疾速响应业务资源需要，有效应对NBA季后赛、欧洲杯等热点赛事期间流量超过10倍突增的压力。虎扑CEO殷学斌示意：“阿里云RDS数据库提供企业级的稳定性和可靠性，搭配智能化运维管理工具，极大升高了咱们的运维人力投入，使咱们能够专一于业务平台建设，阿里云RDS数据库是虎扑上云的最佳抉择。” 阿里云数据库事业部负责人李飞飞示意：“阿里云RDS在过来十余年为阿里巴巴经济体的简单业务、海量数据和双11洪峰提供了松软的撑持，会集了阿里云数据库团队最丰盛的教训。阿里云RDS的自治数据服务为客户提供了更稳固、更平安的零碎，实现了99.99%的高可用性和RPO=0的企业级能力，赋能客户极大水平升高企业老本，帮忙开发者和DBA进步生产力，专一业务翻新。” 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

关于sql:深度技术揭秘-大促狂欢背后如何有效评估并规划数据库计算资源

简介：通过“双11”、“618”这类互联网促销流动的验证，越来越多的互联网公司采纳不定期营销流动来刺激生产，达到晋升营收能力的指标。然而，在每一次业务狂欢的背地，如何迷信地为促销流动筹备相应的计算资源就变成了困扰开发人员的常态问题。此外，据Gartner统计，在疫情的影响下越来越多的企业开始减速要害业务模块从本地云往私有云上迁徙，以晋升企业服务的稳定性和容灾能力。如何无效评估并布局计算能力、计算引擎、带宽等要害资源的容量成为了云场景下的一项技术挑战。1. 背景通过“双11”、“618”这类互联网促销流动的验证，越来越多的互联网公司采纳不定期营销流动来刺激生产，达到晋升营收能力的指标。然而，在每一次业务狂欢的背地，如何迷信地为促销流动筹备相应的计算资源就变成了困扰开发人员的常态问题。此外，据Gartner统计，在疫情的影响下越来越多的企业开始减速要害业务模块从本地云往私有云上迁徙，以晋升企业服务的稳定性和容灾能力。如何无效评估并布局计算能力、计算引擎、带宽等要害资源的容量成为了云场景下的一项技术挑战。针对这个场景，阿里云数据库自治服务团队（DAS）推出了智能压测服务，致力于解决大促场景下计算资源评估问题、迁徙上云的离线资源容量布局、跨引擎迁徙等数据库选型评估问题。DAS（Database Autonomy Service）是一种基于机器学习和专家教训实现数据库自感知、自修复、自优化、自运维及自平安的云服务，帮忙用户打消数据库治理的复杂性及人工操作引发的服务故障，无效保障数据库服务的稳固、平安及高效，解决方案架构见图1。 2. 智能压测的组成压测，即压力测试，是确立零碎稳定性的一种测试方法，通常在零碎失常运作范畴之外进行，以考查其性能极限和隐患。个别针对网络服务器测试从传统的意义来讲是对网络服务器一直施加“压力”的测试，是通过确定一个零碎的瓶颈或者不能承受的性能点，来取得零碎能提供的最大服务级别的测试。在数据库场景下，压测通常指的是对数据库的性能进行测试，通过对数据库服务器一直进步执行SQL的数量和并发度，来测试既定规格下的数据库是否能够继续稳固地对外提供服务，并基于测试后果做出相应的决策，包含调整数据库规格、部署状态、业务SQL优化等等。通常状况下，实现一次压测次要波及到三个要害局部：压测数据筹备、流量回放和后果剖析，如图2所示。图2 智能压测的要害组成压测数据：在数据库场景下，流量数据为SQL语句，但仅有执行时SQL语句是不够的。SQL语句在数据库内的执行过程中，实在数据分布和库表索引都会影响其执行工夫。因而，数据库场景下，压测数据蕴含了数据库的库表构造、库表内数据、索引和SQL执行语句。此外，在一些有严格平安要求的非凡场景下，仅表构造容许复用，而具体原始数据不能被用于流量压测。针对这种状况，咱们提出了智能生成数据的算法，产出合乎原始数据散布的模仿数据用于回放。流量回放技术：传统性能压测过程中，因为未对SQL执行语句依照原始流量的并发状况和执行秩序做限度，呈现压测与原始业务流量成果差别较大的景象，导致单次数据库资源评估工作中通常会进行屡次压测，而后对性能后果数据求均匀后再评估资源。这种办法须要消耗大量的测试工夫，并且须要测试人员具备肯定的数据库教训，通常须要DBA进行操作。针对这一问题，DAS对单次压测进行技术改良，通过压测幂等技术确保压测回放后的性能体现与原始业务流量性能相近，且毋庸屡次回放，大幅节俭了资源评估的工夫并升高了对数据库压测教训的要求。压测后果剖析：无效的后果剖析能够帮忙用户正当的抉择资源规格，并发现业务流量回放过程中存在的隐患。数据库的要害性能参数、要害性能指标的比照、SQL优化倡议等数据可帮忙用户了解资源差别和潜在优化点，辅助做出后续决策。 3. 智能压测技术底细3.1. 智能数据生成技术对于数据库性能压测，业界存在很多开源的工具，例如Sysbench、mysqlslap、tpcc等。这类工具均能够通过并发大量数据库连贯联合肯定的查问语句来制作出肯定的SQL流量，达到模仿业务高强度应用数据库的成果。但模仿场景下的性能体现通常和业务理论性能体现相差较大，故模仿压测不能满足计算资源评估的要求。利用业务数据库中的实在数据进行压测成为资源评估的根本条件。针对阿里云数据库用户，可通过SQL审计性能，不便的获取压测所须要的数据。而对于云下或阿里云ECS自建数据库的用户，较难获取历史上的库表数据或流量数据来做压测，甚至在一些有严格平安数据要求的场景下，连原始数据和SQL流量数据都是不被容许应用的。目前，咱们在单表查问场景下采纳智能数据生成技术来产出合乎业务数据分布的数据，可用于压测并评估资源。这个算法的前提是，须要咱们已知一些SQL模版，以及这些SQL模版对应的执行指标，如RT，rows\_sent，rows\_affected等，咱们心愿实例化这些SQL模版来生成SQL，使得这些SQL在指标库表上执行时能失去类似的执行指标（这里咱们假如同一模版的SQL都会以雷同的执行打算来执行）。如图3所示，咱们须要搜寻相应的参数a和b来实例化这条SQL模版，使得在给定数据执行时返回行数为1。图3 SQL模板在搜寻SQL参数的时候，对于点查问/点更新，能够间接利用主键和惟一键来做参数搜寻。而对于返回行数/更新行数大于1行的状况，咱们应用基于采样的基数预计办法来预计实例化后SQL的返回/更新行数，进而进行SQL模版实例化的参数搜寻。图4是咱们对于钉钉一个读写业务在早高峰期的流量生成压测，能够看到流量生成压测和实在业务在多个指标上都有类似的体现，证实生成的数据能够无效的模仿线上实在数据。图4 基于生成数据的压测成果 3.2. 压测幂等技术在数据筹备实现之后，如何无效且可反复的进行流量回放是智能压测中的另一项核心技术。只管业内已有的开源工具均能够通过并发大量数据库连贯联合肯定的查问语句来制作出肯定的SQL流量，达到模仿业务高强度应用数据库的成果。然而，在应用了实在的且有肯定数据歪斜的业务模型之后，会发现一个比较严重的问题：如果屡次测试同一个模型同一份数据在RDS MySQL下的性能成果，在数据有歪斜的状况下，两边的性能曲线很可能对不上。例如，第一轮压测在A工夫点查到了某一个数据，而第二次压测很可能在B工夫点才查到，这样对剖析问题就有了很大烦扰，如图5所示，两条曲线尽管压力差不多，然而抖动频率齐全不统一，不利于剖析。图5 同一个数据库实例上跑两次雷同的测试模型的成果针对这种状况，咱们提出了压测幂等的概念，即雷同的测试，无论运行多少次，产生的SQL是完全一致的。在幂等状况下，每个工夫点产生的SQL文本是完全相同的（假如数据库解决能力完全一致），并且整个压测工作中，所有SQL的执行程序是统一的。目前做到了线程级别完全一致，不同线程之间从性能和需要的角度思考没有实现强统一。在幂等技术的加持下，DAS智能压测能够针对前文形容的场景能够做到一致性的压测，成果如图6。图6 同一个数据库实例上跑两次雷同的智能压测的成果压测幂等的技术次要从压测线程生成逻辑、总申请数、写入最终一致性这三方面进行解决，让压测过程中能够确保每个线程外部呈现的随机数的程序都是一样的，并且不同线程之间不一样；通过放弃线程中申请量总数统一，达到确保总申请量固定的成果；再联合自定义主键和约定update区间的形式，躲避了自增主键和update抵触问题，确保了压测完结后的数据最终一致性。 4. 产品落地4.1. 产品流程介绍完智能压测的组成部分和对应的核心技术之后，上面来看DAS是如何将智能压测落地成产品。从压测的流程来看，整个智能压测的过程能够分为筹备阶段、SQL解决阶段、回放阶段和成果评估阶段，如图7所示。图7 智能压测产品流程筹备阶段次要是解决压测的机器环境问题，波及从购买ECS机器、筹备压测指标实例、配置ECS机器上的运行环境等。目前DAS的智能压测可依据压测流量的QPS和回放时长，自主抉择适合的ECS机器并主动配置运行环境，也容许用户采纳利用自有机器进行压测。在筹备压测指标实例环节，当初DAS可通过RDS备份复原、DTS同步的形式来自助帮忙用户筹备好指标实例，也容许用户自在指定压测实例。 SQL解决阶段则次要是对压测应用的全量SQL明细数据做压测前的数据筹备，基于SQL洞察明细或者智能算法生成的SQL数据做预处理，包含prepared statement语句去重、日志剔除、事务语句合并等等操作。在回放阶段次要是利用压测幂等技术将流量进行回放，提供了实时的数据库性能数据和压测机器负载状况，便于用户理解压测进度。在此环节中，DAS将智能调参算法与压测进行了联合，用户可通过该性能实现参数调优的性能，具体算法实现将在后续文章独自介绍。成果评估阶段次要是解读压测过程中的指标数据，DAS对业务调优中罕用的性能参数和要害性能指标做了比照，帮助用户做出资源评估决策。对于压测过程中发现的慢SQL、锁等问题，DAS也提供了相应的改良倡议和解决办法，对用户优化业务也提供了信息辅助。 4.2 产品应用用户能够在DAS控制台的左侧菜单“智能压测”进行应用，如图8。目前DAS反对RDS MySQL和PolarDB MySQL压测，其余关系型数据库引擎的反对正在开发中。图8 智能压测界面在压测完结之后，用户能够通过工作详情查看到指标实例与源实例的性能数据比照以及要害参数的比照，如图9所示。图9 压测后的成果比照 4.3. 产品计费目前DAS智能压测性能未独自免费，压测流程中新创建的ECS、RDS均依照对应产品官网中以按量计费的规范进行计费，无额定服务费用。如前文所述，压测依赖源端全量SQL明细数据或相应库表根底构造数据，故该服务仅须要压测源端实例开启DAS专业版性能即可。 4.4. 客户案例DAS智能压测服务自2020年上线以来，次要客户为云上头部客户，已累计为近百个客户提供服务，次要包含上云资源评估、业务大促评估、引擎切换评估、数据库操作验证等场景。 5. 将来布局接下来，智能压测将减少反对的数据库引擎，笼罩云上的所有关系型数据库引擎；同时，智能压测将会贴近客户的实在业务问题，与用户上云、资源评估、引擎举荐等场景亲密联合，并提供相应的压测评估倡议和报告，与企业客户一起构建大规模场景下的数据库容量布局能力。 7月7日14点数据库自治服务DAS年度重磅公布 DAS自治胜似闲庭信步数据库主动驾驶进入规模化时代扫描下图二维码或点击“这里”预约观看直播版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

关于sql:union-分页groupjoin-复杂查询net-coreframework

union 分页/group/join 简单查问(.net core/framework)unoin是一个比拟非凡的查问，对union进行分页，关联，分组须要在最里面包装一层，如果对union后果再进行其它关联，分组，复杂度直线回升，解决此问题装置nuget包：CRLusing CRL;以下为默认数据源实现如果应用ef core和ado.net 见:Data/EFTest · hubroxxl/CRL - 码云 - 开源中国 (gitee.com) 定义数据源 var builder = DBConfigRegister.GetInstance();builder.RegisterDBAccessBuild(dbLocation => { return new DBAccessBuild(DBType.MSSQL, "server=.;database=testDb; uid=sa;pwd=123;"); });定义对象管理器 public class ProductRepository:BaseProvider<ProductData>{ public static ProductRepository Instance { get { return new ProductRepository(); } }}通过GetLambdaQuery办法创立ILambdaQuery ILambdaQuery能实现子查问和嵌套查问，只有合乎T-SQL语义逻辑，能够应用ILambdaQueryResultSelect有限叠加如： join后groupjoin后再joingroup后再joinjoin一个group后果join一个union后果对union进行group再join...简略的union var query = ProductRepository.Instance.GetLambdaQuery().Where(b => b.Id < 200); var query2 = query.CreateQuery<Code.Order>().Where(b => b.Id < 200); var view1 = query.Select(b => new { a1 = b.Id, a2 = b.ProductName }); var view2 = query2.Select(b => new { a1 = b.Id, a2 = b.Remark }); var result = view1.Union(view2).OrderBy(b => b.a1).OrderBy(b => b.a2, false).ToList(); var sql = query.PrintQuery();生成SQL为 ...

关于sql:数据库导入导出之数据处理

背景：最近在做后端开发。常遇到的就是数据库数据导入导出。这里具体记录一下通过图形化工具进行导入导出的步骤。工具：Excel,SQLServer图形化工具。先放张胖虎的照片压阵！数据库导入Excel数据（1）先把Excel表头字段名解决成须要的字段名。这样导入进数据库就不必更改名称了。（2）关上须要导入数据的数据库。抉择工作-导入数据（3）顺次跟着以下截图的箭头步骤走(多图预警....)(4) 数据库刷新后查下刚刚导入的表。这样数据就导入胜利啦~数据库导出数据(1) 需要：依据某某条件查出来某某表的数据，整体导出到Excel里。先查进去所须要导出的数据。而后点击下图箭头的地位。抉择连同题目一起复制。而后创立空的Excel表，粘贴进去就能够了。 (2) 需要：把某个表的数据处理成SQL脚本语句。默认关上的窗口就会有解决好的脚本语句啦。备注：如果需要是只须要架构不须要数据的话。在下面截图步骤中有个设置脚本编写选项。抉择为仅限架构就好啦。

关于sql:MaxCompute-挑战使用SQL进行序列数据处理

简介：MaxCompute 挑战应用SQL进行序列数据处理--而不是用MR和函数日常编写数据加工工作，次要的办法就是应用SQL。第一是因为本人对SQL把握的比拟好（十多年数据开发教训，就这几个关键字，也不敢跟他人说本人不行），所以，MR和函数波及不多。在接触MaxCompute这些年，写过的函数应该不超过10个，次要还是因为本人JAVA程度挫。记得早些年写过一个身份证号码校验函数，过后有个我的项目反馈一段SQL原来2分钟，应用我的函数就变成12分钟了。过后这个项目组还找到MaxCompute的研发，研发负责人又找到我，让我把我的代码调优下。我很惶恐啊，我是什么渣，我本人心里晓得啊。最初还是厚着脸皮求研发帮我优化了下，性能终于改良了。这当前，我更不敢随机作函数了，毕竟MaxCompute官网倡议尽可能应用SQL，SQL是优化过的办法，本人用MR和自定义函数性能是很难保障的。这也导致我至今在这方面也是渣渣，当然我认为错不在我，我只是听了“妈妈”的话而已。最近很微妙，接连有两个我的项目遇到了序列值计算的问题，还都是要求不能应用函数和MR。共事把问题送给我，我发现光读懂题都要半天（题目有点绕），不在一线搞开发太久了，有点陌生了。同样的问题，第一次搞了一天，第二次还搞了半天，没说很快能搞进去的，未免有点丢范。所以，总结进去跟大家分享下。先说下什么是序列值的解决。表中的记录自身是无序的，然而业务上数据都是有序的，一般来说工夫就是一个天然的序列。比方利用我一天的作息的时点记录，计算我一天吃了几次饭，吃了多久。乍一看，如同要写个函数。问题模仿如下：问题：吃了几次饭，都吃了多久？条件：1-两个“吃饭”状态距离在1小时内，算作一顿饭 2-最初一个“吃饭”状态后的下一个其余状态的开始工夫，是“吃饭”的完结工夫通过下面的剖析，咱们能够失去后果：大概吃了四次饭，因为早晨吃饭的工夫很长，依照规定算作吃了两次饭（第四次看起来是去撸串了）。我是怎么做的呢？第一步，我先把无关的信息剔除了，第1行、第4行、最初1行。第二步，后我利用数据是间断的工夫的特质，找到了状态的完结工夫。第三步，我辨认了状态距离1小时这个特色，辨认出了一个“吃饭”中混淆的其余无关状态，并且还剖析失去第三个“吃饭”和第四个“吃饭”状态是两个独立的状态。那么用SQL怎么实现？排序是肯定的了，要排序还要解决状态，必须应用窗口函数。能选的窗口函数仿佛只有lag、lead。窗口函数： LAG 按偏移量取以后行之前第几行的值。 LEAD 按偏移量取以后行之后第几行的值。官网文档：https://help.aliyun.com/docum... 即使有了这个函数，还有一个问题很头疼，函数须要指定偏移量，而这个问题外面并不知道到底会呈现多少个状态。是不是也没有用呢？看看再说。问题合成合成如下：应用LAG\LEAD函数取到前一条记录和后一条记录的状态和工夫，剖析记录： 1-以后状态不是“吃饭”，上一个状态也不是“吃饭”，记录不保留。 2-以后状态不是“吃饭”，上一个状态是“吃饭”，为上一个状态提供完结工夫，记录不保留。 3-以后状态是“吃饭”，记录上一个和下一个状态都是“吃饭”，记录不保留。 4-以后状态是“吃饭”，记录下一个状态工夫，作为以后状态完结工夫，记录保留。如下图：而后咱们就失去了上面一个表格：很显著，这不是咱们最初须要的。尽管咱们找到了状态为“吃饭”的行，并且通过窗口函数给它找到了状态的完结理论。然而表格还须要再作一次解决，能力变成咱们想要的后果。再次应用LAG\LEAD函数，咱们须要把距离在1小时内的“吃饭”状态进行合并。问题再次合成合成如下：应用LAG\LEAD函数取到前一条记录和后一条记录的开始和完结工夫，剖析记录： 1-以后记录的“开始工夫”减去上个时点的“完结工夫”，如果小于1小时，该行记录不保留。这一行记录的状态须要与上一行合并为一次“吃饭”状态。下图中绿色标注行。 2-下个时点的“开始工夫”减去以后记录的“完结工夫”，如果小于1小时，该行记录与下一行记录合并。批改以后时点“吃饭”状态的完结工夫为下一个时点的完结工夫。下图橙色标注行。而后咱们失去了上面的表格：不论之前咱们想的多简单，须要用什么循环或者递归逻辑实现，然而当初问题解决了。咱们通过这个表格答复了最开始题目的问题。这个人吃过4次饭，开始工夫别离是7点10分、12点25分、17点40分、19点45分，每次继续的工夫大概都在1小时。这个过程就是一个找到须要的信息，剔除无关信息的过程，只不过这个where有点简单。其实从剖析问题的角度来看，这个问题自身就有点简单，搞懂问题个别都须要肯定的工夫。从实现问题的角度来看，应用高级语言JAVA或者python实现更容易点，循环撸一遍有什么解决不了的（一遍不够再来一遍）。用SQL实现，看起来有点简单（可能是我长年应用SQL语言的起因，我感觉我如同剖析问题的过程跟实现的过程是一样的。），然而代码量肯定是起码的（性能可能也是最佳的）。再从可维护性下来综合比拟，还是应用SQL实现更优。所以，前面再遇到相似的问题，你应该能够搞定了。如果有点艰难，至多你能够再回过头来看下这个例子，毕竟我花了良久来设计。 SQL问题解答： with ta as(select*from values(1001,'06:05:00','sleep'),(1001,'07:10:00','eat'),(1001,'08:15:00','phone'),(1001,'11:20:00','phone'),(1001,'12:25:00','eat'),(1001,'12:40:00','phone'),(1001,'13:30:00','eat'),(1001,'13:35:00','sleep'),(1001,'17:40:00','eat'),(1001,'18:05:00','eat'),(1001,'18:25:00','eat'),(1001,'18:30:00','phone'),(1001,'19:45:00','eat'),(1001,'20:55:00','phone'),(1001,'22:00:00','sleep')t(id,stime,stat))-- 5 计算依据前后记录的工夫，判断记录是否要被合并selectid,stime,case whens2<=60 thenetime2 else etime end asetime,statfrom(-- 4 计算前后记录的时间差selectid,stime,etime,stat,datediff(stime,etime1,'mi') ass1,datediff(stime2,etime,'mi') ass2,etime2from(-- 3 计算前后记录的工夫selectid,stime,etime,stat,lag (stime,1) over(partition byid order by stime asc)as stime1,lag (etime,1) over(partition byid order by stime asc)as etime1,lead(stime,1) over(partition byid order by stime asc)as stime2,lead(etime,1) over(partition byid order by stime asc)as etime2from(-- 2 辨认前后记录状态，找到状态完结工夫selectid,stime,stat,lead(stime,1) over(partition byid order by stime asc)as etime,lag (stat,1) over(partition byid order by stime asc)as stat1,lead(stat,1) over(partition byid order by stime asc)as stat2from(-- 1 把字符串转工夫selectid,to_date(concat('2021-06-29 ',stime),'yyyy-mm-dd hh:mi:ss') asstime,stat fromta)t1)t2wherestat='eat' and not(stat='eat' andstat1='eat' andstat2='eat'))t3)t4wheres1 >60 ors1 is null;原文链接本文为阿里云原创内容，未经容许不得转载。 ...

关于sql:COMP1121-Databases

COMP1121 Databases COURSEWORK 2 (10% of module)Submission deadline: 10.00am Tuesday 26th March 2019To be submitted as hard copy (printed) through the Coursework Post Box in the Long Roomor the DEC-10 Lab. Attach a Coursework Header Sheet.Information about using SQLite has been given in the lectures and you need to understand thisbefore you start. Typing sqlite3 at the Linux prompt on a computer in a School of Computinglab will start sqlite.PART APart A is about tables which store data about the cost of products in a shop (Table 2 below),and the number of each of these products bought by one person on a particular shopping trip(Table 1 below).Table 1:Product QuantityDogfood 1Milk 2Soup 5Cheese 1Table 2:Product PriceFishfood 123Soup 657Dogfood 210Eggs 230Cheese 120Rhubarb 255Milk 135Bananas 200Apples 290Lettuce 10 ...

关于sql:深入解读-Flink-SQL-113

简介：Apache Flink 社区 5 月 22 日北京站 Meetup 分享内容整顿，深刻解读 Flink SQL 1.13 中 5 个 FLIP 的实用更新和重要改良。本文由社区志愿者陈政羽整顿，Apache Flink 社区在 5 月份公布了 1.13 版本，带来了很多新的变动。文章整顿自徐榜江(雪尽) 5 月 22 日在北京的 Flink Meetup 分享的《深刻解读 Flink SQL 1.13》，内容包含： Flink SQL 1.13 概览外围 feature 解读重要改良解读Flink SQL 1.14 将来布局总结GitHub 地址 https://github.com/apache/flink 欢送大家给 Flink 点赞送 star~ 一、Flink SQL 1.13 概览 Flink 1.13 是一个社区大版本，解决的 issue 在 1000 个以上，通过上图咱们能够看到，解决的问题大部分是对于 Table/SQL 模块，一共 400 多个 issue 占了总体的 37% 左右。这些 issue 次要围绕了 5 个 FLIP 开展，在本文中咱们也会依据这 5 个方面进行介绍，它们别离是： ...

关于sql:sql-标签的使用

条件 <choose> <when test="isUpload"> </when> <otherwise> </otherwise> </choose> choose标签是按程序判断其外部when标签中的test条件出否成立，如果有一个成立，则 choose 完结。当 choose 中所有 when 的条件都不满则时，则执行 otherwise 中的sql。相似于Java 的 switch 语句，choose 为 switch，when 为 case，otherwise 则为 default。 <where> <if> <where> <if test="id != null ">id=#{id}</if> <if test="name != null and name.length()>0" >and name=#{name}</if> <if test="gender != null and gender.length()>0">and gender = #{gender}</if> </where>函数IFNULL() 函数用于判断第一个表达式是否为 NULL，如果为 NULL 则返回第二个参数的值，如果不为 NULL 则返回第一个参数的值。去余 <trim prefix="" suffix="" suffixOverrides="" prefixOverrides=""></trim>prefix:在trim标签内sql语句加上前缀。suffix: 在trim标签内sql语句加上后缀。suffixOverrides:指定去除多余的后缀内容，如：suffixOverrides=","，去除trim标签内sql语句多余的后缀","。汇合in 搭配<foreach> 传递多个参数item：汇合中元素迭代时的别名，该参数为必选。index：在list和数组中,index是元素的序号，在map中，index是元素的key，该参数可选open：foreach代码的开始符号，个别是(和close=")"合用。罕用在in(),values()时。该参数可选separator：元素之间的分隔符，例如在in()的时候，separator=","会主动在元素两头用“,“隔开，防止手动输出逗号导致sql谬误，如in(1,2,)这样。该参数可选。close: foreach代码的敞开符号，个别是)和open="("合用。罕用在in(),values()时。该参数可选。collection: 要做foreach的对象，作为入参时，List对象默认用"list"代替作为键，数组对象有"array"代替作为键，Map对象没有默认的键。当然在作为入参时能够应用 @Param("keyName")来设置键，设置keyName后，list,array将会生效。除了入参这种状况外，还有一种作为参数对象的某个字段的时候。举个例子：如果User有属性List ids。入参是User对象，那么这个collection = "ids".如果User有属性Ids ids;其中Ids是个对象，Ids有个属性List id;入参是User对象，那么collection = "ids.id"获取某个要害值在mapper文件加useGeneratedKeys="true" keyProperty="id"。这里是获取的id

关于sql:重磅-数据库自治服务DAS论文入选全球顶会SIGMOD

关于sql:PolarDBX-20-全局-Binlog-和备份恢复能力解读

简介：PolarDB-X 2.0 针对数据孤岛问题提供了全局 Binlog 能力，该能力为上游生态提供了与 MySQL Binlog 完全一致的增量日志生产体验。针对数据损坏问题提供了实例级、表级、SQL 级和行级等不同粒度的数据恢复能力，包含一致性备份复原、表回收站、SQL 闪回、Flashback Query 等。发布会传送门：https://yqh.aliyun.com/live/polardbx2021 背景咱们作为开发者都理解或相熟后盾零碎，后盾零碎能够形象为两个组成部分：一个是业务零碎，该局部负责解决零碎的业务逻辑，在现代化的架构中，该局部通常设计成可程度扩大的无状态节点；另一个是数据库系统，该局部负责存储系统的状态，这其中便包含最外围的业务数据。站在数据库的视角，数据的流入包含两个局部，一个是业务零碎的实时写入，这是外围数据起源的次要局部；另一个是从上游数据系统一次性或周期性导入的数据。因为这些外围数据在这里首次产生，所以这个数据库也被称为 SSOT（Single Source of Truth）。 SSOT 是后盾零碎中最重要的数据资产，那么随之便产生两个问题须要妥善处理。第一个问题是，作为最重要的资产，通常咱们须要将这些数据实时同步到其余零碎进行 BI 剖析等进一步的解决，如果没有这样的实时同步机制，那么这份数据将成为数据孤岛。第二个问题是，这份数据可能因为各种起因受到毁坏，比方硬件故障或软件 Bug 导致的数据损坏、不当操作引起的数据损坏、谬误 SQL 引起的数据错乱等，提供多种机制保障这份数据的平安显得十分必要。全局 BinlogPolarDB-X 是一款高度兼容 MySQL 生态的分布式数据库产品，所以咱们首先来看下 MySQL 是如果解决数据孤岛问题的。从 DB-Engines 排行榜能够看出，MySQL 的风行度比其余开源数据库的总和还要高，这意味着 MySQL 的生态十分凋敝，比方 MySQL 的上游零碎有 Kafka、MySQL 备节点、Canal 多种数据同步工具、Pulsar 等等。MySQL 通过 Binlog 机制实现了与上游零碎的实时增量数据同步。Binlog 能够看做是一个音讯队列，队列中按程序保留了 MySQL 中具体的增量变更信息，通过生产这个队列，上游零碎或工具实现了与 MySQL 的实时数据同步，这样的机制也称为 CDC（Change Data Capture），即增量数据捕获。分布式数据库提供 CDC 能力绝对于单机有更高的复杂度。一个分布式数据库通常蕴含多个节点，这些节点会产生多个增量日志队列，那么上游如果要生产多个队列会波及几个问题。因为是多个队列，那么上游生产时多个队列内变更事件的程序如何确定？分布式事务的变更可能波及多个队列，如果要保障生产时事务的完整性，那么如何发现并合并同一个事务的变更事件？零碎产生了扩缩容（也就是队列的增减）上游如何正确处理？DDL 会波及多个队列，上游如何准确辨认出每个队列 Schema 变动前后的地位并协调好生产进度？面对这些问题，分布式数据库的 CDC 能力须要在实现难度、反对个性、易用性等方面做 trade-off。通常来说，给上游提供多个队列、不保障事务完整性仅提供最终一致性、提供自定义格局的增量日志是一种较易实现的计划，但该计划会对上游生产提出更高的要求，比方要开发相应的生产代码或工具、须要思考多个队列的协同问题等。一种体验更敌对的形式是，通过提供与 MySQL Binlog 完全一致体验的 CDC 能力，让上游能够像生产 MySQL Binlog 一样通明的生产分布式数据库的增量变更，从而极大升高数据同步链路的搭建老本，这也是 PolarDB-X 2.0 采纳的计划，咱们称为全局 Binlog。 ...

关于sql:Mysql数据库按时间点恢复实战

简介：Mysql数据库按工夫点复原实战对于任何一家企业来讲，数据都是最贵重的财产。如何爱护数据完整性，数据不受损坏，在产生故障时，如何保住数据，在产生误操作，黑客入侵，数据篡改等场景时，如何基于咱们的备份来进行数据恢复，是每个技术人员须要关注的关键点。阿里云致力于服务客户，为客户数据库提供间断数据保护、低成本的备份服务。它能够为多种环境的数据提供强有力的爱护，以及强力复原。在产生数据失落、数据损坏的极其状况下，RDS管控平台具备一键还原的性能，基于客户设置的须要复原的工夫点，进行数据全方位复原。 1. 按工夫点复原的技术实现如果客户在某工夫节点因为误操作，导致数据失落，RDS管控服务是如何进行复原的呢？按工夫点复原的整体思路如下：一次残缺的数据恢复是由物理备份+binlog复原+binlog裁剪形成的。图1 首先获取到可用的备份集，将备份集利用到指标实例上，而后再指标实例重放须要复原的binlog文件，最初通过binlog裁剪的模式利用sql文件，实现整体的复原。 2. 按工夫点复原的管控流程1. 创立用于复原的目标实例当咱们须要整体复原源数据库数据时，咱们首先须要创立一个与源实例同规格、同网络环境的指标实例。为什么要这样做? 因为备份复原属于高危操作，如果间接还原到源实例，一旦呈现备份集不可用、binlog缺失等等问题，那么不仅失落数据无奈找回，甚至原数据都无奈完整保住，所以强烈建议应用新实例来进行复原！ 2. 明确备份复原工夫点当客户在执行了一系列数据库操作之后，如误删除、误批改等，操作之后无感知，等到业务受损、故障产生时，如何定位到过后操作的精确工夫点用于数据恢复呢？形式1：能够通过日志审计性能找到对应的误操作工夫点。形式2：能够将binlog解析成文本，查问对应的误操作工夫点。 3. 通过备份历史获取可用的备份集个别状况下，基于业务的重要水平，客户在云上会布局好本人的数据库备份周期，RDS管控会基于用户抉择的复原工夫点主动寻找可用的物理备份集。可见备份对于数据库的高可用和劫难复原是重中之重的！ 4. 获取备份集对应的binlog点位专有云的备份个别都基于xtrabackup工具进行备份。xtrabackup具备热备份、复原快等特点，同时会将备份完结时利用binlog的文件和点位写入相应文件中。RDS管控会将该binlogfile和binlogpos等信息写入数据库，当须要备份复原时，会间接获取该点位进行复原。如下图所示：图2 5. 将备份集还原至目标实例1-4步骤为筹备工作，上面开始正式的复原数据。复原数据的第一步是将获取的可用的全量物理备份集下载至目标实例上，并应用xtrabackup工具进行还原。 //首先要进行目标实例上的mysql过程 systemctl stop mysql //而后合并数据,假如备份解压在/root/backup/目录下,能够指定须要复原的实例端口，需加--defaults-file参数指定，默认3306。 innobackupex --apply-log /root/backup/ //删除原目录文件 rm -rf /data/mysql //还原数据集,还原数据到哪个目录是基于配置文件my.cnf的datadir决定的。该字段肯定要查看是否精确 innobackupex --copy-back /root/backup/ //目录赋权 chown -R mysql:mysql /data/mysql 6. 验证还原是否胜利管控服务须要验证还原是否胜利，再决定是否须要向下操作，验证步骤也很简略粗犷，间接查看备份复原日志中是否有ERROR,并且最初一行是否为completed OK! 如下图，为一次胜利的备份复原。图3 7. 获取用于复原的binlog日志此步骤至关重要，关乎复原是否胜利，数据是否残缺。那么RDS管控服务如何获取正确的binlog来进行复原呢？咱们来看下图。图4 例如以后咱们的备份中总共有8个binlog备份(000-008)，首先通过物理备份记录的binlog的filename和pos来获取第一个binlog，如上图中的binlog004；而后通过客户设置的须要复原的工夫点的timestamp，来找到对应的最初一个binlog，如上图中的binlog007；最初将binlog004,binlog005,binlog006,binlog007这四个binlog备份下载到目标实例上进行复原。如果获取了谬误的binlog日志用于复原，比方误将binlog003/binlog005设置成了第一个binlog，那么binlog003/binlog005上执行的dml语句会在新实例上从新执行一次，复原的数据就会增多或缺失；比方误将binlog0006或者binlog0008设置成了最初一个binlog，那么复原的数据会缺失，且无奈达到预期成果。 8. 重放relaylog将下载的binlog复制到新实例的logdir中，并将除最初一个binlog(笼罩复原工夫点的binlog)之外的binlog重命名为relaylog，而后应用新实例重放这些relaylog。 //将binlog重命名,relaylog文件名可在mysql实例中执行show variables like '%relay%'查看. rename mysql-bin MySQL2-relay-bin mysql-bin* ...

关于sql:PolarDBX-20使用一个透明的分布式数据库是一种什么体验

简介：通明分布式，是PolarDB-X行将公布的能力，它能让利用在应用PolarDB-X的过程中，犹如应用单机数据库个别的体验。与传统的中间件类型的“分布式数据库”相比，有了通明分布式能力的PolarDB-X，不再须要利用思考分区键的概念，利用能够齐全将单机MySQL上开发的建表语句、利用代码间接迁徙到PolarDB-X上运行起来。本文将为大家介绍PolarDB-X通明分布式的新体验。PolarDB-X 2.0视频解读：https://yqh.aliyun.com/live/polardbx2021 通明分布式，是PolarDB-X行将公布的能力，它能让利用在应用PolarDB-X的过程中，犹如应用单机数据库个别的体验。与传统的中间件类型的“分布式数据库”相比，有了通明分布式能力的PolarDB-X，不再须要利用思考分区键的概念，利用能够齐全将单机MySQL上开发的建表语句、利用代码间接迁徙到PolarDB-X上运行起来。本文将为大家介绍PolarDB-X通明分布式的新体验。在PolarDB-X上装置一个WordPressWordPress是一个开源的博客软件，它应用MySQL作为其数据库。操作是在PolarDB-X上装置一个WordPress，来体验PolarDB-X的通明分布式能力。咱们将遵循简略的三步走：不批改DDL间接建表不批改利用间接跑起来做下压测，做下调优总结如下：应用官网的WordPress镜像，不做任何批改，其安装程序就能主动的在PolarDB-X上实现建表、数据初始化等工作，其应用的都是规范的MySQL语法。对此WordPress进行压测，PolarDB-X的各项监控数据显示，各节点处于的负载、数据量均处于平衡的状态。通过PolarDB-X提供的SQL剖析、DAS等工具，能够不便的找到零碎中热点SQL。DBA能够间接通过创立索引、批改数据分布等DDL语句对系统性能做进一步的优化，不须要批改利用。PolarDB-X实现通明分布式的武器上面为大家分享下，PolarDB-X是如何实现通明分布式的。通明数据分区PolarDB-X是一个典型的Share Nothing的分布式数据库，其简化架构如下：其外围组件为无状态的计算节点CN，与有状态的存储节点DN。要理解PolarDB-X的通明分布式能力，首先要理解数据在PolarDB-X上是如何散布的。在PolarDB-X中，一个表由多个索引组成，包含主键、二级索引等。PolarDB-X会对每个索引进行独立的进行分区，其分区键为索引的key。例如一个典型的电商场景，订单表，领有一个主键（id），两个索引（seller\_id与buyer\_id）： create table orders ( id bigint, buyer_id varchar comment '买家', seller_id varchar comment '卖家', primary key(id), index sdx(seller_id), index bdx(buyer_id))对于主键索引，会依照id对其进行分区对于索引sdx，会依照seller\_id进行分区对于索引bdx，会依照buyer\_id进行分区如下图所示：对索引进行分片之后，PolarDB-X会将这些分片打散到不同的存储节点里，并会依照数据量等信息进行负载平衡，如下图所示：在PolarDB-X中，建表语句中能够不思考分区键，PolarDB-X也能主动的对表进行分片与负载平衡。因而，利用迁徙PolarDB-X时，能够将单机MySQL中的建表语句导出，不须要批改间接在PolarDB-X中执行即可。通明的分布式事务分布式事务是PolarDB-X中的最重要的根底能力，它宽泛的利用于业务内，防止了业务对事务代码进行革新；同时，PolarDB-X外部也用事务来实现索引。 PolarDB-X的分布式事务有以下几个特色：与Spanner一样，满足内部一致性这种最强的一致性级别语法与MySQL齐全兼容，无需对利用进行革新行为上反对兼容MySQL的RC与RR级别 PolarDB-X分布式事务的原理咱们专栏有很多介绍的文章，在此不再赘述。对其原理感兴趣的同学能够参考这几篇文章： https://zhuanlan.zhihu.com/p/329978215 https://zhuanlan.zhihu.com/p/338535541 https://zhuanlan.zhihu.com/p/355413022 Online DDLPolarDB-X反对类型丰盛的Online DDL，这里介绍一些有代表性的DDL类型。索引保护与单机MySQL的索引有所差别，PolarDB-X的索引均为全局索引，蕴含以下几种类型：一般索引惟一索引聚簇索引其中聚簇索引是PolarDB-X绝对于MySQL的一种新类型的索引，它会蕴含表中的所有列，从而防止了回表的代价。 PolarDB-X中对索引的创立都通过DDL来实现，并且都是Online的，不会阻塞业务。例如：创立一个一般的索引：CREATE INDEX idx1 ON t1(name)创立一个聚簇的索引：CREATE CLUSTERED INDEX idx1 ON t1(name)INSTANT ADD COLUMN加列操作是业务中最为常见的DDL类型。在MySQL中，加列操作的耗时是与数据量相干的（MySQL8.0中在表的最初面加列是INSTANT的）。在PolarDB-X中，在任意地位加列都是INSTANT的，这个代表加列操作为恒定的秒级耗时，与数据量无关，不会对业务产生任何影响。分区调整PolarDB-X反对4种表的散布策略，Hash、Range、List、Broadcast。因为Hash能防止间断写入的热点，PolarDB-X默认应用Hash策略，大多数状况下，此策略可能很好的满足零碎的性能须要。 ...

关于sql:唯品会在-Flink-容器化与平台化上的建设实践

简介：唯品会 Flink 的容器化实际利用，Flink SQL 平台化建设，以及在实时数仓和试验平台上的利用案例。转自dbaplus社群公众号作者：王康，唯品会数据平台高级开发工程师 GitHub 地址 https://github.com/apache/flink 欢送大家给 Flink 点赞送 star~ 自 2017 年起，为保障外部业务在平时和大促期间的安稳运行，唯品会就开始基于 Kubernetes 深刻打造高性能、稳固、牢靠、易用的实时计算平台，当初的平台反对 Flink、Spark、Storm 等支流框架。本文将分为五个方面，分享唯品会 Flink 的容器化实际利用以及产品化教训：倒退概览Flink 容器化实际Flink SQL 平台化建设利用案例将来布局一、倒退概览1、集群规模在集群规模方面，咱们有 2000+ 的物理机，次要部署 Kubernetes 异地双活的集群，利用 Kubernetes 的 namespaces，labels 和 taints 等实现业务隔离以及初步的计算负载隔离。 Flink 工作数、Flink SQL 工作数、Storm 工作数、Spark 工作数，这些线上实时利用加起来有 1000 多个。目前咱们次要反对 Flink SQL 这一块，因为 SQL 化是一个趋势，所以咱们要反对 SQL 工作的上线平台。 2、平台架构咱们从下往上进行解析实时计算平台的整体架构：资源调度层（最底层）实际上是用 deployment 的模式运行 Kubernetes 上，平台尽管反对 yarn 调度，然而 yarn 调度与批工作共享资源，所以支流工作还是运行在 Kubernetes 上的。并且，yarn 调度这一层次要是离线部署的一套 yarn 集群。在 2017 年的时候，咱们自研了 Flink on Kubernetes 的一套计划，因为底层调度分了两层，所以在大促资源缓和的时候，实时跟离线就能够做一个资源的借调。 ...

关于sql:Flink-和-Iceberg-如何解决数据入湖面临的挑战

简介：4.17 上海站 Meetup 胡争老师分享内容：数据入湖的挑战有哪些，以及如何用 Flink + Iceberg 解决此类问题。GitHub 地址 https://github.com/apache/flink 欢送大家给 Flink 点赞送 star~ 一、数据入湖的外围挑战数据实时入湖能够分成三个局部，别离是数据源、数据管道和数据湖（数仓），本文的内容将围绕这三局部开展。 1. Case #1：程序 BUG 导致数据传输中断首先，当数据源通过数据管道传到数据湖（数仓）时，很有可能会遇到作业有 BUG 的状况，导致数据传到一半，对业务造成影响；第二个问题是当遇到这种状况的时候，如何重起作业，并保证数据不反复也不缺失，残缺地同步到数据湖（数仓）中。2. Case #2：数据变更太苦楚数据变更当产生数据变更的状况时，会给整条链路带来较大的压力和挑战。以下图为例，原先是一个表定义了两个字段，别离是 ID 和 NAME。此时，业务方面的同学示意须要将地址加上，以不便更好地开掘用户的价值。首先，咱们须要把 Source 表加上一个列 Address，而后再把到 Kafka 两头的链路加上链，而后批改作业并重启。接着整条链路得一路改过去，增加新列，批改作业并重启，最初把数据湖（数仓）里的所有数据全副更新，从而实现新增列。这个过程的操作不仅耗时，而且会引入一个问题，就是如何保证数据的隔离性，在变更的过程中不会对剖析作业的读取造成影响。分区变更如下图所示，数仓外面的表是以 “月” 为单位进行分区，当初心愿改成以 “天” 为单位做分区，这可能就须要将很多零碎的数据全副更新一遍，而后再用新的策略进行分区，这个过程非常耗时。 3. Case #3：越来越慢的近实时报表？当业务须要更加近实时的报表时，须要将数据的导入周期，从 “天” 改到 “小时”，甚至 “分钟” 级别，这可能会带来一系列问题。如上图所示，首先带来的第一个问题是：文件数以肉眼可见的速度增长，这将对里面的零碎造成越来越大的压力。压力次要体现在两个方面：第一个压力是，启动剖析作业越来越慢，Hive Metastore 面临扩大难题，如下图所示。随着小文件越来越多，应用中心化的 Metastore 的瓶颈会越来越重大，这会造成启动剖析作业越来越慢，因为启动作业的时候，会把所有的小文件原数据都扫一遍。第二是因为 Metastore 是中心化的零碎，很容易碰到 Metastore 扩大难题。例如 Hive，可能就要想方法扩前面的 MySQL，造成较大的保护老本和开销。第二个压力是扫描剖析作业越来越慢。随着小文件减少，在剖析作业起来之后，会发现扫描的过程越来越慢。实质是因为小文件大量减少，导致扫描作业在很多个 Datanode 之间频繁切换。 ...

关于sql:详细解析CISC-332CMPE-332-–Database

CISC 332/CMPE 332 –Database Management Systems Quiz #2April 4, 2018 No questions will be answered during the quiz.There are several versions of the quiz. Do not rely on your neighbours' choices – they may not be correct for your version! Many of the questions on this exam are multiple choice. For each of these questions you can indicate two responses. The primary response will be awarded more points than the secondary response. You may provide only one (1) response per row. If you mark more than one response in a row, that row will receive zero (0) points. ...

关于sql:编译优化-LLVM代码生成技术详解及在数据库中的应用

简介：作者：长别1. 前言随着IT基础设施的倒退，古代的数据处理系统须要解决更多的数据、反对更为简单的算法。数据量的增长和算法的复杂化，为数据分析系统带来了严厉的性能挑战。近年来，咱们能够在数据库、大数据系统和AI平台等畛域看到很多性能优化的技术，技术涵盖体系结构、编译技术和高性能计算等畛域。作为编译优化技术的代表，本文次要介绍基于LLVM的代码生成技术（简称Codeden）。 LLVM是一款十分风行的开源编译器框架，反对多种语言和底层硬件。开发者能够基于LLVM搭建本人的编译框架并进行二次开发，将不同的语言或者逻辑编译成运行在多种硬件上的可执行文件。对于Codegen技术来说，咱们次要关注LLVM IR的格局以及生成LLVM IR的API。在本文的如下局部，咱们首先对LLVM IR进行介绍，而后介绍Codegen技术的原理和应用场景，最初咱们介绍在阿里云自研的云原生数据仓库产品AnalyticDB PostgreSQL中，Codegen的典型利用场景。 2. LLVM IR简介及上手教程在编译器实践与实际中，IR是十分重要的一环。IR的全称叫做Intermediate Representation，翻译过去叫“两头示意”。对于一个编译器来说，从下层形象的高级语言到底层的汇编语言，要经验很多个环节(pass)，经验不同的表现形式。而编译优化技术有很多种，每种技术作用的编译环节不同。然而IR是一个显著的分水岭。IR以上的编译优化，不须要关怀底层硬件的细节，比方硬件的指令集、寄存器文件大小等。IR以下的编译优化，须要和硬件打交道。LLVM最为驰名是它的IR的设计。得益于奇妙地IR设计，LLVM向上能够反对不同的语言，向下能够反对不同的硬件，而且不同的语言能够复用IR层的优化算法。上图展现了LLVM的一个框架图。LLVM把整个编译过程分为三步：（1）前端，把高级语言转换为IR。(2）中端，在IR层做优化。(3) 后端，把IR转化为对应的硬件平台的汇编语言。因而LLVM的扩展性很好。比方你要实现一个名为toyc的语言、心愿运行在ARM平台上，你只须要实现一个toyc->LLVM IR的前端，其余局部调LLVM的模块就能够了。或者你要搞一个新的硬件平台，那么只须要搞定LLVM IR->新硬件这一阶段，而后该硬件就能够反对很多种现存的语言。因而，IR是LLVM最有竞争力的中央，同时也是学习应用LLVM Codegen的最外围的中央。 2.1 LLVM IR基本知识LLVM的IR格局十分像汇编，对于学习过汇编语言的同学来说，学会应用LLVM IR进行编程非常容易。对于没学过汇编语言的同学，也不必放心，汇编其实并不难。汇编难的不是学会，而是工程实现。因为汇编语言的开发难度，会随着工程复杂度的晋升呈指数级回升。接下来咱们须要理解IR中最重要的三局部，指令格局、Basic Block & CFG，还有SSA。残缺的LLVM IR信息请参考https://llvm.org/docs/LangRef.html。指令格局。LLVM IR提供了一种相似于汇编语言的三地址码式的指令格局。上面的代码片段是一个非常简单的用LLVM IR实现的函数，该函数的输出是5个i32类型(int32)的整数，函数的性能是计算这5个数的和并返回。LLVM IR是反对一些根本的数据类型的，比方i8、i32、浮点数等。LLVM IR中得变量的命名是以 "%"结尾，默认%0是函数的第一个参数、%1是第二个参数，顺次类推。机器生成的变量个别是以数字进行命名，如果是手写的话，能够依据本人的爱好抉择适合的命名办法。LLVM IR的指令格局包含操作符、类型、输出、返回值。例如 "%6 = add i32 %0, %1"的操作符号是"add"、类型是"i32"、输出是"%0"和“%1”、返回值是"%6"。总的来说，IR反对一些根本的指令，而后编译器通过这些根本指令的来实现一些简单的运算。例如，咱们在C中写一个形如“A * B + C”的表达式在LLVM IR中是通过一条乘法和一条加法指令来实现的，另外可能也包含一些类型转换指令。 define i32 @ir_add(i32, i32, i32, i32, i32){ %6 = add i32 %0, %1 %7 = add i32 %6, %2 %8 = add i32 %7, %3 %9 = add i32 %8, %4 ret i32 %9}Basic Block & CFG。理解了IR的指令格局当前，接下来咱们须要理解两个概念：Basic Block(基本块，简称BB)和Control Flow Graph(控制流图，CFG)。下图(左)展现了一个简略的C语言函数，下图（中）是应用clang编译进去的对应的LLVM IR，下图（右）是应用graphviz画进去的CFG。联合这张图，咱们解释下Basic Block和CFG的概念。 ...

关于sql:Apache-Flink-Meetup-710-北京站Flink-x-TiDB-专场等你来

简介：7 月 10 日，Apache Flink Meetup 北京站，不见不散～Flink，近年来广受欢迎，是最受认可的大数据计算引擎之一；TiDB 作为开源的 NewSQL 数据库也以其优良的横向扩大能力和高可用特点，颇受业界的好评。那么当 Flink 遇上 TiDB，会迸发出怎么的火花呢？ Apache Flink 社区 Meetup 北京站又来啦 7月10日 | 北京 | 线下 Flink x TiDB 专场本场 Meetup 将由 Flink 社区与 TiDB 社区合办。判若两人，咱们邀请了各行业的技术大牛，来自阿里巴巴、TiDB、360、知乎、网易的 5 位技术专家将围绕 Flink 和 TiDB，分享如何实现精确稳固的实时计算业务、如何搭建实时数仓数据链路的最佳实际、如何利用两者的特点实现端对端实时计算的闭环交付，以及 Flink SQL 和 Flink-CDC 架构的感悟与实际等。 ■ 流动亮点超多实用干货，Flink + TiDB 的结合能擦出怎么的火花，且看各位技术专家聚焦实时数据业务撑持、实时数仓、端到端实时计算等场景，用实践联合实际解析 Flink + TiDB 在各场景的利用。流动模式多样化，线下线上同步开启，同城可参加线下 Meetup 面对面交换，异地也可在线观看直播，精彩内容不错过；丰盛周边等你拿，报名加入就有机会取得超多 Flink 社区定制的精美周边！特地鸣谢 360 提供场地 **■ 流动议程 ** ▼ 立刻报名 ▼ https://1712399719478.huodongxing.com/event/6601410216600 Fli 嘉宾及议题介绍《JFlink on TiDB——便捷牢靠的实时数据业务撑持》林佳网易互娱技术核心实时开发工程师 Apache Flink Contributor 【嘉宾简介】林佳，网易互娱计费数据核心实时业务负责人，实时开发框架 JFlink-SDK 和实时业务平台 JFlink 的主程。 ...

关于sql:汽车之家基于-Flink-Iceberg-的湖仓一体架构实践

简介：由汽车之家实时计算平台负责人邸星星在 4 月 17 日上海站 Meetup 分享的，基于 Flink + Iceberg 的湖仓一体架构实际。内容简要：一、数据仓库架构降级的背景二、基于 Iceberg 的湖仓一体架构实际三、总结与收益四、后续布局 GitHub 地址 https://github.com/apache/flink 欢送大家给 Flink 点赞送 star~ 一、数据仓库架构降级的背景1. 基于 Hive 的数据仓库的痛点原有的数据仓库齐全基于 Hive 建造而成，次要存在三大痛点：痛点一：不反对 ACID 1）不反对 Upsert 场景； 2）不反对 Row-level delete，数据修改老本高。痛点二：时效性难以晋升 1）数据难以做到准实时可见； 2）无奈增量读取，无奈实现存储层面的流批对立； 3）无奈反对分钟级提早的数据分析场景。痛点三：Table Evolution 1）写入型 Schema，对 Schema 变更反对不好； 2）Partition Spec 变更反对不敌对。 2. Iceberg 要害个性Iceberg 次要有四大要害个性：反对 ACID 语义、增量快照机制、凋谢的表格局和流批接口反对。反对 ACID 语义不会读到不残缺的 Commit；基于乐观锁反对并发 Commit；Row-level delete，反对 Upsert。增量快照机制 Commit 后数据即可见（分钟级）；可回溯历史快照。凋谢的表格局数据格式：parquet、orc、avro计算引擎：Spark、Flink、Hive、Trino/Presto流批接口反对 ...

关于sql:阿里云峰会-统一召回引擎在搜索场景的应用实践

简介：淘宝每次的搜寻行为在后端都会有大量的数据计算和解决才会召回合乎用户需要的搜寻后果，当面对的业务越来越多如何在工程体系上一直演变满足不同业务的需要？特邀阿里巴巴技术专家介绍对立召回引擎，带你理解如何应答~特邀嘉宾：项昭贵（项公）-阿里巴巴高级技术专家视频地址: https://summit.aliyun.com/2021/session/689 AI Online Serving工程体系阿里自研的整套搜寻工程体系-AI Online Serving体系，目前撑持起海内外阿里电商全副的搜寻、举荐、广告业务，时刻置身大数据主战场，疏导成交占据团体电商大盘主体；此外，作为中台技术中坚，AI·OS已是包含电商、阿里云、优酷、菜鸟、盒马、钉钉等等在内全团体的基础设施，更为重要的是，AI·OS体系的云产品（凋谢搜寻和智能举荐）矩阵通过阿里云服务于寰球开发者，在稳定性和工程效率上都是行业领先水平。对立召回引擎对立引擎架构及演化过程左图是搜索引擎HA3和举荐引擎BE的不同执行流程，咱们将各引擎性能形象成算子，把根底性能造成公共算子库，用户能够间接复用和依据业务需要开发，造成右图的Suez框架。对立召回引擎的特点1.查问流程DAG化与深度学习执行引擎对立搜寻性能形象成算子对立算子库，反对算子粒度的复用和开发2.多种查问表达方式 SQLTuringSDK等..... 能够灵便定制执行流程，减速业务迭代速度对立召回引擎的利用实际召回引擎面临的挑战既要，又要，还要数据收缩：文档数据，算法数据深度学习的利用：召回，粗排，精排稳固高效：高可用，时效性，低提早传统解决方案及问题数据规模收缩体现在数据维度越来越多。例如电商搜寻畛域以前只思考商家、商品两个维度，当初还须要思考物流、地位等维度。传统引擎解决把这些数据在离线解决join成一张大宽表推给在线做索引构建和查问服务，这会有个问题，很可能呈现一个辅表数据更新导致大量的主表数据更新，从而呈现写数据扩充的问题，对在线服务的时效性有很大的挑战，在一些场景上很难失去满足，尤其大促场景很难满足要求低提早高时效的需要。传统解决方案：将数据按肯定维度拆分通过多个引擎实例去提供服务，由业务方来将一次查问拆分成多个申请拜访多个引擎，实现搜寻后果。存在的问题：呈现大量数据的序列化；数据可能会有截断，导致成果受损；例如外卖平台搜寻，发现想搜寻的店铺因为配送工夫或间隔起因没有match上，导致用意搜寻菜单没有体现，用户体验不佳；数据规模收缩另一个体现是数据质变大，数据质变大导致单个搜寻加载提供查问的工夫变多。传统解决方案：一个是将索引进行扩裂，可能带来申请的拆分和后果的合并，随着个数越来越多，耗时越来越大，逐步成为技术瓶颈。另一个是当搜寻个数多时，整个集群的稳定性和可用性受到侵害，对用户而言存在查问后果不稳固状况。对立召回引擎解决方案引擎反对多张表通过一个引擎外面在线同时加载多张表，每张表的索引构建、更新、切换、加载都是独立的；查问时通过在线多表join形式，能够在一次查问时拿到全局的信息，包含店铺信息，商品信息都能失去充分运用，匹配最合乎用户需要的召回后果；采纳SQL表白查问流程开发者应用简略复用SQL生态根底性能 3.并行查问，升高提早的利器把索引数据按肯定维度切分，在解决用户的查问申请时能够依据不同的切分并行的查问，从而升高整个查问的提早，也防止了通过扩裂的形式带来的问题。 4.向量召回，深度学习在召回阶段利用在信息丰盛的明天，咱们的查问引擎光靠文本查问很难满足业务的需要采纳达摩院自研的向量检索内核-Proxima，具备超大规模数据向量索引的构建，提供高性能的在线向量检索能力；在原来文本召回根底上，减少向量召回，能够实现对文档召回率和准确率的兼顾，同时能够在每一路排序外面进行较好的灵便配置，获得好的搜寻成果对立召回引擎在举荐场景的利用打造个性化举荐成果的召回引擎对立召回引擎的云上实际阿里云凋谢搜寻凋谢搜寻（OpenSearch）是基于阿里巴巴自主研发的大规模分布式搜索引擎搭建的一站式智能搜寻业务开发平台，通过内置各行业的查问语义了解、机器学习排序算法等能力，提供充沛凋谢的引擎能力，助力开发者疾速搭建更高性能、更高搜寻基线成果的智能搜寻服务。凋谢搜寻在电商行业利用电商行业搜寻产品化落地，用户无需各方向技术摸索，只需按模板接入即可领有更优搜寻服务；内置更高质量算法模型，免去大量的数据标注与模型训练工作，间接内置淘系搜索算法能力；反对个性化搜寻与服务能力，通过引擎侧的多路召回能力，实现搜寻后果、下拉提醒、底纹词等重要服务；反对用户自行训练的NLP模型导入凋谢搜寻，灵便满足业务开发者需要；阿里巴巴自研引擎零碎，解决海量数据、高并发、海量用户申请，性能优于开源计划；依据电商行变动，一直迭代更新原有能力，提供更高时效性的服务保障；凋谢搜寻在教育搜题场景利用反对文本索引、图片向量索引、公式索引多路召回后果，升高文本搜题、拍照搜题场景的无后果；教育查问剖析全套能力，解决准确率较低问题，可定制排序脚本，深度优化召回后果排序成果；用户灵便配置的向量+文本召回，疾速晋升搜寻零碎成果；排序插件开发-Cava语言，更强的定制能力，更易于保护，轻松实现业务排序需要；按量付费，即时失效，保障高峰期搜寻稳固同时，不须要提前购买大量资源，无老本累赘；反对千亿体量数据搜寻的毫秒级响应，实时数据更新秒级可见；版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

关于sql:比开源快30倍的自研SQL-Parser设计与实践

简介： SQL作为一种畛域语言，最早用于关系型数据库，方便管理结构化数据；SQL由多种不同的类型的语言组成，包含数据定义语言，数据管制语言、数据操作语言；各数据库产品都有不同的申明和实现；用户能够很不便的应用SQL操作数据，数据库系统中的词法语法分析器负责剖析和了解SQL文本的含意，包含词法剖析、语法分析、语义剖析3局部。作者 | 林夕起源 | 阿里技术公众号 SQL（Structured Query Language）作为一种畛域语言（编程语言），最早用于关系型数据库，方便管理结构化数据；SQL由多种不同的类型的语言组成，包含数据定义语言，数据管制语言、数据操作语言；各数据库产品都有不同的申明和实现；用户能够很不便的应用SQL操作数据，数据库系统中的词法语法分析器负责剖析和了解SQL文本的含意，包含词法剖析、语法分析、语义剖析3局部。通过词法语法分析器生成AST（Abstract Syntax Tree），会被优化器解决生成生成执行打算，再由执行引擎执行，下图以MySQL架构为例展现词法语法分析器所处的地位。本文通过介绍词法语法分析器技术和业界的做法，以及过来应用主动生成的词法语法分析器遇到的问题，分享自研SQL Parser的设计与实际，以及其带来的性能和性能的晋升。一业界产品如何开发SQL Parser？依照解析器代码开发方式，可分为以下两种： 1 主动生成为不便开发词法、语法分析的过程，业界有许多词法、语法分析工具，例如：Flex、Lex、Bison工具罕用于生成以C、C++作为目标语言的词法、语法代码；如果以Java作为目标语言，能够应用比拟风行的ANTLR和JavaCC等工具，ANTLR、JavaCC工具都以用户编写的词法语法规定文件作为输出，其中语法文件须要满足EBNF（extended Backus–Naur form）[1]语法规定，这2个工具应用LL(k) (Left-to-right, Leftmost derivation)[2] 算法“自顶向下[3]”解析SQL文本并构建SQL AST， Presto，Spark、Hive等数据库和大数据系统多采纳该形式生成。生成的代码蕴含词法和语法解析局部，语义剖析还须要联合Meta数据，各数据库内核本人解决；更多主动生成工具的性能和算法比照[4]在参考文献中。 2 手工编写与主动生成工具不同，InfluxDB、H2、Clickhouse等风行的数据库的SQL Parser组件均是手工编写而成。长处：代码逻辑清晰，不便开发人员调试和排错；性能更好：有更多代码优化的空间交给开发人员，能够应用更优良的算法和数据结构晋升性能；自主可控：无licence束缚，可读性和可维护性更高；不须要额定依赖第三方词法语法代码生成工具。有余：对开发人员的技术要求较高，需理解编译原理技术；开发工作量较大，实现MySQL罕用语法的各类分支，须要投入很多工夫和精力；须要长时间、大规模测试才会趋于稳定。二问题与挑战1 简单查问的性能问题在实时剖析型数据库的理论生产环境中，常常须要解决数以千行的简单查问申请或者深层嵌套的查问申请，主动生成的解析器，因为状态机治理简单，线程堆栈太深，导致个别查问申请在词法语法解析阶段性能降落重大。 2 大批量写入吞吐问题剖析型数据库要稳固解决大批量、高并发写入的场景，要求SQL Parser组件有很好的性能和稳定性，咱们尝试应用过ANTLR，JavaCC等工具生成SQL 的词法语法解析器，大批量写入时，values子句在解析过程会产生太多AST长期对象，导致垃圾回收耗时的问题。 3 Query Rewriting的灵活性问题须要疾速不便的遍历AST树，找到合乎某种规定的叶子节点，批改改节点，主动生成的解析器并不能很灵便的反对。主动生成的代码可读性差，排查问题老本高，简单查问场景下，性能有余，影响零碎稳定性和版本迭代速度；在设计之初，咱们放弃了主动生成的技术计划，齐全手工编写词法语法解析器。三自研词法语法分析器的技术要点主动生成工具次要解决生成下图中左侧的 SQL Parser Core和 SQL Tree Nodes的局部，右侧featrues的局部须要开发同学解决，当右侧性能（例如：SQL rewriting）对左侧有的Tree nodes的更改性能有更多的需要时，想批改主动生成的代码，则无从下手。主动生成工具是面向生成通用语法解析器而设计的，针对SQL这一特定畛域语言，有特定的优化技术晋升稳定性和性能，从设计之初，咱们抉择LL(k)作为语法分析的算法，其自顶向下的个性，在手工编写分析器时，逻辑清晰，代码易读，不便开发和保护，LL(k)的“左递归”问题，可通过手工断定循环编程的形式防止。 1 词法和语法分析词法剖析中，Lexer继续读取间断SQL 文本，将具备某特色的一段间断文本标识为Token，并标识Token的类别，比方赋值语句 x = 30，通过词法剖析后x, = , 30 别离被标识为ID、等号操作符、数值常量；尤其在辨认标识符（变量，表名，列名等）和保留字（TABLE，FROM，SELECT等）须要对字符串进行重复比照。主动生成工具在这一阶段应用DFA（Deterministic Finite Automaton）和事后定义的词法文件，确定每个Token的值和类型，手工编写解析器不须要额定保护一个状态机，应用分支预测，缩小计算量和调用堆栈的深度。语法分析器会应用词法剖析中的Token作为输出，以SQL语法形容作为规定，自顶向下，顺次将非叶子节点开展，构建语法树，整个过程就像是走迷宫，只有一个正确入口和进口，走完迷宫后，会生成一个正确的AST。 ...

关于sql:Flink-Iceberg-在去哪儿的实时数仓实践

简介：本文介绍去哪儿数据平台在应用 Flink + Iceberg 0.11 的一些实际。作者：余东摘要：本文介绍去哪儿数据平台在应用 Flink + Iceberg 0.11 的一些实际。内容包含：背景及痛点Iceberg 架构痛点一：Kafka 数据失落痛点二：近实时 Hive 压力大Iceberg 优化实际总结GitHub 地址 https://github.com/apache/flink 欢送大家给 Flink 点赞送 star~ 一、背景及痛点1. 背景咱们在应用 Flink 做实时数仓以及数据传输过程中，遇到了一些问题：比方 Kafka 数据失落，Flink 联合 Hive 的近实时数仓性能等。Iceberg 0.11 的新个性解决了这些业务场景碰到的问题。比照 Kafka 来说，Iceberg 在某些特定场景有本人的劣势，在此咱们做了一些基于 Iceberg 的实际分享。 2. 原架构计划原先的架构采纳 Kafka 存储实时数据，其中包含日志、订单、车票等数据。而后用 Flink SQL 或者 Flink datastream 生产数据进行流转。外部自研了提交 SQL 和 Datastream 的平台，通过该平台提交实时作业。 3. 痛点Kafka 存储老本高且数据量大。Kafka 因为压力大将数据过期工夫设置的比拟短，当数据产生反压，积压等状况时，如果在肯定的工夫内没生产数据导致数据过期，会造成数据失落。Flink 在 Hive 上做了近实时的读写反对。为了分担 Kafka 压力，将一些实时性不太高的数据放入 Hive，让 Hive 做分钟级的分区。然而随着元数据一直减少，Hive metadata 的压力日益显著，查问也变得更慢，且存储 Hive 元数据的数据库压力也变大。二、Iceberg 架构1. Iceberg 架构解析 ...

关于sql:Scheduled-SQL-SLS-大规模日志上的全局分析与调度

简介：本文总结了大规模日志全局剖析的需要，探讨SLS上现有的典型剖析计划，并延长到 SLS 原生数据处理计划，介绍 Schedueld SQL 性能与最佳实际。大规模日志全局剖析的需要数据大规模与时效性基于工夫的数据（日志、指标）在与日俱增后的数量是惊人的。以 SLB 七层拜访日志为例，每一个HTTP/HTTPS 拜访申请会记录一条 access log，假如每天产生1000万条数据，则一年为36亿条数据。一方面，长时间的数据存储须要微小的存储空间，而通过缩小存储周期的形式升高存储空间，尽管管制了存储老本，但也失落了有价值的历史数据。另一方面，大量的数据将造成剖析上的性能压力。大部分时序数据具备时效性特色。历史数据能够承受分钟或小时级别的精度，而新产生的数据须要更高的精度（例如监控、线上问题考察）。数据经营、分析师须要存储全量的数据以备剖析，历史数据间接 TTL 删除是可能最差的抉择。例如 Elasticsearch rollup、时序数据库的降精度用于解决这部分问题。一份数据在多种场景应用对于同一份日志，可能被多种用户角色在多种场景下应用到： • 实时的数据，须要反对关键词告警、时序数据 ML 巡检、日志上下文查问。• 亚秒级提早粒度上，有全文关键词的查问、交互式 SQL 统计分析的需要。• 以天为单位，须要对日志做经营剖析，计算转化率、设计经营策略。• 一周前的产生的数据，大部分时候不再会被触碰到，在反对偶然的历史指标查看以外，审计场景下对全量日志的存储也是必须项。一份数据，多处应用，既要满足业务需要，老本也是须要关怀的。自定义业务剖析云上日志设施面对的客户群出现多样化，自定义的业务需要举例如下： • 电商：计算七日留存率，业务拜访 SQL 审计日志对用户信息脱敏，等等。• 在线教育：多平台终端（android、ios、PC）埋点数据的规整，直播课堂生命周期内的异样诊断，等等。• 游戏：按游戏的数据散发存储，全文搜寻反对工单考察，等等。阿里云 SLS 是云原生观测剖析平台，为Log/Metric/Trace等数据提供大规模、低成本、实时平台化服务，一站式提供数据采集、加工、剖析、告警可视化与投递性能。咱们将以业务为指标的数据处理演绎为两类需要：• ETL：将非结构化的日志做预处理，为日志信息增加业务字段，数据脱敏与散发等。• 剖析：全局数据大表上的查问和 SQL 剖析，反对布尔搜寻、window、aggregate 操作等。 SLS 上的典型剖析计划对于 ETL、剖析这两类计算工作，除了交互式剖析以外，还须要常驻作业模式来处理结果落盘。依据不同的业务需要，这里总结了几种常见的 SLS 数据分析计划。数仓 "T+1" 对于后果实时性不敏感的业务，有较多采纳数仓计划：数据通过 SLS 实时入库，集中化存储。全托管数据投递到 MaxCompute。业务布局小时级或天级的计算工作，生成上游表，产出业务报表等后果。流计算以 Flink、Spark Streaming（continuous mode）、Kafka Streams 为代表的实时计算零碎，在数据处理语义（exactly-once）、计算结果修改上的能力弱小。该计划会用到 SLS 百 ms 秒级端到端提早的 pub/sub 能力：数据实时推送到 SLS 日志库。启动流计算工作，从多个 shard 实时生产数据。流计算工作依据算子组合状况（stateless、statefull、groupby 等）切分多个拓扑执行，可能波及到数据 shuffle、watermark、state store 等机制。这个计划在算子丰盛度、实时能力、性能上综合体现全面，是一把牛刀，例如在电商实时大屏场景上是十分好的抉择。 ...

关于sql:基于-Scheduled-SQL-对-VPC-FlowLog-实现细粒度时间窗口分析

简介：针对VPC FlowLog的五元组和捕捉窗口信息，在剖析时应用不同工夫窗口精度，可能失去不一样的流量特色，本文介绍一种办法将原始采集日志的工夫窗口做拆分，之后重新聚合为新的日志做剖析，达到更细粒度的剖析成果。背景阿里云专有网络（VPC）提供流日志性能，反对VPC网络中弹性网卡流量、VPC流量及交换机流量的记录与存储。对流日志剖析能够监控访问控制规定、监控网络流量和排查网络故障。流日志性能捕捉的流量信息以日志形式写入SLS（阿里云日志服务）中。每条日志会捕捉特定捕捉窗口中的特定五元组网络流，捕捉窗口大概为10分钟，该段时间内流日志性能先聚合数据，再公布日志。在 SLS 上能够通过关键词搜寻对指定指标地址被回绝的申请：也能够通过 SLS 的 SQL 进行统计分析，但这里波及一个捕捉窗口的问题，例如上面两条流日志（字段做了简化）： Log#1start: 2021-05-31 00:00:00 end: 2021-05-31 00:08:30bytes: 9000packets: 18Log#2start: 2021-05-31 00:02:30 end: 2021-05-31 00:03:15bytes: 5000packets: 10采集窗口内产生的 bytes，落到 start 工夫点下来或是均匀落到整个采集窗口，对于流量剖析后果会产生显著的差别：依据不同的业务背景，能够有不同的抉择：一种办法是按采集窗口开始工夫计算，办法简略，select from_unixtime(start - start % 60) as dt, sum(bytes) as total_bytes group by dt order by dt asc limit 1000。另一种较为简单，拆分采集窗口后计算，本文介绍基于 SLS SQL 拆分日志后重新聚合的剖析实际。计划如下是一条 start 与 end 相差501的日志，示意采集窗口横跨了 502 个秒级时间段（start、end 是左闭右闭区间）：利用数据函数 sequence 能够生成一个工夫序列到 ta 字段：接着将 ta 序列做 unest 开展，失去 502 条日志： ...

关于sql:Flink-在有赞的实践和应用

简介：本文介绍了Flink 在有赞的实际和利用，内容包含：Flink 的容器化革新和实际、Flink SQL 的实际和利用、将来布局。作者：沈磊简介：明天次要分享的内容是 Flink 在有赞的实际和利用。内容包含： Flink 的容器化革新和实际Flink SQL 的实际和利用将来布局。GitHub 地址 https://github.com/apache/flink 欢送大家给 Flink 点赞送 star~ 一、Flink 的容器化革新和实际1. 有赞的集群演进历史2014 年 7 月，第一个 Storm 工作正式上线；2016 年，引入 Spark Streaming，运行在 Hadoop Yarn；2018 年，引入了 Flink，作业模式为 Flink on Yarn Per Job；2020 年 6 月，实现了 100% Flink Jar 工作 K8s 化， K8s 作为 Flink Jar 默认计算资源，Flink SQL 工作 On Yarn，Flink 对立实时开发；2020 年 11 月，Storm 集群正式下线。原先的 storm 工作全副都迁徙到了 Flink；2021 年，咱们打算把所有的 Flink 工作 K8s 化。 ...

关于sql:官宣｜Apache-Flink-1130-正式发布流处理应用更加简单高效

简介：Flink 1.13.0 版本让流解决利用的应用像一般利用一样简略和天然，并且让用户能够更好地了解流作业的性能。翻译 | 高赟 Review | 朱翥、马国维 GitHub 地址 https://github.com/apache/flink 欢送大家给 Flink 点赞送 star~ Flink 1.13 公布了！Flink 1.13 包含了超过 200 名贡献者所提交的 1000 多项修复和优化。这一版本中，Flink 的一个次要指标获得了重要停顿，即让流解决利用的应用和一般利用一样简略和天然。Flink 1.13 新引入的被动扩缩容使得流作业的扩缩容和其它利用一样简略，用户仅须要批改并发度即可。这个版本还包含一系列重要改变使用户能够更好的了解流作业的性能。当流作业的性能不迭预期的时候，这些改变能够使用户能够更好的剖析起因。这些改变包含用于辨认瓶颈节点的负载和反压可视化、剖析算子热点代码的 CPU 火焰图和剖析 State Backend 状态的 State 拜访性能指标。除了这些个性外，Flink 社区还增加了大量的其它优化，咱们会在本文后续探讨其中的一些。咱们心愿用户能够享受新的版本和个性带来的便当，在本文最初，咱们还会介绍降级Flink版本须要留神的一些变动。咱们激励用户下载试用新版 Flink 并且通过邮件列表和 JIRA 来反馈遇到的问题。重要个性被动扩缩容Flink 我的项目的一个初始指标，就是心愿流解决利用能够像一般利用一样简略和天然，被动扩缩容是 Flink 针对这一指标上的最新进展。当思考资源管理和局部的时候，Flink 有两种可能的模式。用户能够将 Flink 利用部署到 k8s、yarn 等资源管理零碎之上，并且由 Flink 被动的来治理资源并按需分配和开释资源。这一模式对于常常扭转资源需要的作业和利用十分有用，比方批作业和实时 SQL 查问。在这种模式下，Flink 所启动的 Worker 数量是由利用设置的并发度决定的。在 Flink 中咱们将这一模式叫做被动扩缩容。对于长时间运行的流解决利用，一种更适宜的模型是用户只须要将作业像其它的长期运行的服务一样启动起来，而不须要思考是部署在 k8s、yarn 还是其它的资源管理平台上，并且不须要思考须要申请的资源的数量。相同，它的规模是由所调配的 worker 数量来决定的。当 worker 数量发生变化时，Flink 主动的改变利用的并发度。在 Flink 中咱们将这一模式叫做被动扩缩容。 ...

关于sql:官宣｜Apache-Flink-1130-正式发布流处理应用更加简单高效

关于sql:阿里云贾扬清大数据AI工程化让数据从成本变为资产

简介：近年来，数字经济倒退迅速，企业转型背地频频涌现「数字力量」的身影。云计算、大数据、人工智能的疾速交融造成了数字经济的新基建，也为数字经济倒退带来了新的时机。近年来，数字经济倒退迅速，企业转型背地频频涌现「数字力量」的身影。云计算、大数据、人工智能的疾速交融造成了数字经济的新基建，也为数字经济倒退带来了新的时机。 5 月 20 日，阿里巴巴副总裁、阿里云计算平台负责人贾扬清在媒体沟通会做了《科技翻新时代的数字力量》演讲，本文对其演讲内容做了精简编辑，以飨读者。 01 科技翻新时代的数字力量咱们先来意识一家修建公司。说修建公司的起因是，每一次工业革命往前降级、向前倒退的背地，最重要的其实是现有行业怎么变革本人的生产力。建筑行业是十分典型的一个例子，明天说了那么多大数据和 AI，到底能给他们带来什么样的价值？这家公司叫中建三局一公司，是国家基建中的外围力量，始终以修建速度跟效率著称。 30 多年以前，1985 年，就以「三天一层楼」建造了深圳第一座超高层地标性修建、过后「中国高楼之最」——深圳国贸大厦。 1996 年，又以「九天四个结构层」的速度缔造了过后亚洲第一、世界第四高楼——深圳地王大厦，将中国建筑业从个别超高层推向可与世界摩天大楼相媲美的领先水平。放眼全国乃至世界，都有他们的作品，承建了十分多咱们耳熟能详的标杆性修建：国家体育馆（鸟巢）、央视新址 CCTV 大楼…… 除了地标性修建，他们还建了机场、地铁、高速、医院（雷神山医院）、学校（清华美院）、办公大楼（阿里腾讯新浪挪动等办公大楼）…… 中建三局一公司高效的修建能力，给咱们带来十分大的价值。几十年过来了，建筑设计变得越来越新，砖瓦构造变成了钢筋混凝土构造，中建三局一公司对建筑行业的了解也始终在向前倒退。30 多年前，他们依附人与工夫的赛跑；现在，他们依附数据的流动。去年，中建三局一公司联手阿里云，独特建设数据中台。造一座高楼，有十分多的物质在流转，从一粒沙子到砖头、玻璃、钢筋、螺丝、各种工程机械，怎么让它们更高效地流转起来，是修建公司都会遇到的问题。不仅如此，他们还须要思考怎么晋升建造工艺、晋升翻新的修建办法，以及通过数字化能力，来治理修建过程、建筑物料等一系列问题。阿里云基于一站式数据开发和综合治理平台 DataWorks 打造的数据中台，为中建三局一公司建设了一个「数字孪生体」，用数据和算法来预测，何时补沙子、何时调配工程机械，以及做其余经营治理方面的事件。明天，咱们看到，中国整个修建市场有 10 万家修建公司，除了中建三局一公司这种大型的标杆企业，还有很多中小型的修建公司，从业人员共有 5000 余万。帮忙这些中小型企业从传统的、小作坊式的、刀耕火种的模式变成像中建三局一公司那样，是阿里云心愿在数据方面做的一些事件。咱们置信把阿里云数据中台建设的外围能力，和各行各业的专业知识联合起来之后，能够帮忙更多企业，就像中建三局一公司一样实现数字化转型。 02 「一体两面」，助力企业用好数据尽管每个人都在提大数据，每个人也都感觉本人在用大数据，但其实谁也不晓得大数据到底该怎么用。阿里云打造了一系列将数据用起来的「武器」，心愿通过云上数据综合治理及智能化，赋予企业数字力量。企业常常面临的挑战是，建了很多系统的数据系统，表格、Word、照片、视频等异构数据存在 Excel、数据仓库等不同的数据库里，最初成为「数据孤岛」。因而，企业在建设数据中台时，常常会在技术、业务、组织三方面遇到挑战。技术上，数据怎么买通；业务上，不同口径的数据如何总结；组织上，怎么把寄存在不同地点的数据对立治理起来。商业公司常常遇到的一个挑战是——算支出会面临财务、证监会等各种各样的不同口径，经营同学须要去看不同状况的营业额，这些最初都会下沉到一句 SQL 语言或者一个数据工作上。这些工作如果不统一，最初就会呈现数据的不统一，后果的不统一，口径的不统一，都是一系列问题。从技术角度来讲，咱们逐步构建了一套残缺的数据处理体系，叫「一体两面」。「一体」是指一体化的数据开发和数据综合治理平台 DataWorks，各种各样的行业利用都基于这个平台搭建。 DataWorks 迄今为止曾经累积了约 8 万名用户。每天阿里大略有 1/4 的员工在 DataWorks 上做数据开发和利用。一体化的开发平台下，有两种不同的数据组织状态——数据仓库和数据湖，即所谓「两面」。「数据仓库」的概念很早以前就有了，能够将其了解为一个微小的 Excel 表格或者一堆微小的 Excel 表格。阿里很早以前就建了本人的数据仓库 MaxCompute，它是「飞天」的重要组成部分之一，曾经积淀了十分好的大规模数据仓库能力。在 MaxCompute 的演进过程中，对数据进行实时剖析的需要诞生了。比方说，双 11 时，促销策略要依据用户的购买行为进行及时调整。于是，几年前，咱们开发了一套实时计算引擎 Flink。Flink 最开始是由德国一个团队做的，当初阿里巴巴和德国团队一起，持续把 Flink 作为一个开源的流计算施行规范往前推动。 ...

关于sql:数据库存储过程

什么是数据库存储过程？其实定义很简略：就是一段定义好的SQL代码，能够被多次重复调用咱们还能够定义可能承受参数的存储过程，这样就能够更加灵便的解决需要。语法CREATE PROCEDURE procedure_nameASsql_statementGO;EXEC procedure_name;例子CREATE PROCEDURE SelectAllCustomersASSELECT * FROM CustomersGO;EXEC SelectAllCustomers;

关于sql:Hologres如何基于roaringbitmap实现超高基数UV计算

简介：本文将会介绍Hologres基于roaringbitmap实现超高基数的UV计算RoaringBitmap是一种压缩位图索引，RoaringBitmap本身的数据压缩和去重个性非常适宜对于大数据下uv计算。其次要原理如下：对于32bit数, RoaringBitmap会结构2^16个桶，对应32位数的高16位；32位数的低16位则映射到对应桶的一个bit上。单个桶的容量由桶中的已有的最大数值决定bitmap把32位数用1位示意，能够大大地压缩数据大小。bitmap位运算为去重提供了伎俩。主体思维（T+1）：把上一天的所有数据依据最大的查问维度聚合出的uid后果放入RoaringBitmap中，把RoaringBitmap和查问维度寄存在聚合后果表（每天百万条）。之后查问时，利用Hologres弱小的列存计算间接依照查问维度去查问聚合后果表，对其中要害的RoaringBitmap字段做or运算进行去重后并统计基数，即可得出对应用户数UV，count条数即可计算得出PV，达到亚秒级查问。只需进行一次最细粒度的预聚合计算，也只生成一份最细粒度的预聚合后果表。得益于Hologres的实时计算能力，该计划下预计算所需的次数和空间都达到较低的开销。 Hologres计算UV、PV计划详情图1 Hologres基于RoaringBitmap计算pv uv流程 1.创立相干根底表1）应用RoaringBitmap前须要创立RoaringBitmap extention，语法如下，同时该性能须要Hologres 0.10版本。 CREATE EXTENSION IF NOT EXISTS roaringbitmap;2）创立表ods\_app为明细源表，寄存用户每天大量的明细数据（按天分区），其DDL如下： BEGIN;CREATE TABLE IF NOT EXISTS public.ods_app ( uid text, country text, prov text, city text, channel text, operator text, brand text, ip text, click_time text, year text, month text, day text, ymd text NOT NULL);CALL set_table_property('public.ods_app', 'bitmap_columns', 'country,prov,city,channel,operator,brand,ip,click_time, year, month, day, ymd');--distribution_key依据需要设置，依据该表的实时查问需要，从什么维度做分片可能获得较好成果即可CALL set_table_property('public.ods_app', 'distribution_key', 'uid');--用于做where过滤条件，蕴含残缺年月日工夫字段举荐设为clustering_key和event_time_columnCALL set_table_property('public.ods_app', 'clustering_key', 'ymd');CALL set_table_property('public.ods_app', 'event_time_column', 'ymd');CALL set_table_property('public.ods_app', 'orientation', 'column');COMMIT;3）创立表uid\_mapping为uid映射表，uid映射表用于映射uid到32位int类型。 ...

关于sql:数据库SQL-Server

参考资料windows环境SQL Server 2019 装置教程

关于sql:基于FlinkClickHouse构建实时游戏数据分析最佳实践

简介：本实际介绍如何疾速收集海量用户行为数据，实现秒级响应的实时用户行为剖析，并通过实时流计算、云数据库ClickHouse等技术进行深刻开掘和剖析，失去用户特色和画像，实现个性化零碎举荐服务。中转最佳实际：【基于Flink+ClickHouse构建实时游戏数据分析最佳实际】最佳实际频道：【最佳实际频道】这里有丰盛的企业上云最佳实际，从典型场景入门，提供一系列我的项目实际计划，升高企业上云门槛的同时满足您的需要！场景形容在互联网、游戏行业中，经常须要对用户行为日志进行剖析，通过数据挖掘，来更好地反对业务经营，比方用户轨迹，热力求，登录行为剖析，实时业务大屏等。当业务数据量达到千亿规模时，经常导致剖析不实时，均匀响应工夫长达10分钟，影响业务的失常经营和倒退。计划劣势通过云数据库ClickHouse替换原有Presto数仓，比照开源Presto性能晋升20倍。利用云数据库ClickHouse极致剖析性能，千亿级数据分析从10分钟缩短到30秒。云数据库ClickHouse批量写入效率高，反对业务顶峰每小时230亿的用户数据写入。云数据库ClickHouse开箱即用，免运维，寰球多Region部署，疾速反对新游戏开服。产品列表专有网络VPC弹性公网IP EIP云服务器ECS音讯队列Kafka版云数据库ClickHouse实时计算Flink版Quick BI数据可视化剖析平台业务架构中转最佳实际》》版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

关于sql:快成物流科技-x-mPaaS-小程序容器加持下的技术架构提质增效

简介：大前端团队如何选型技术？如何疾速上手？如何高效协同？让咱们看看快成科技如何解决这一问题。导言从 2017 年开始，GMTC“挪动技术大会”就更名为“大前端技术大会”。倒退至今，混合开发、原生开发、前端开发等概念正在深度交融，组成“大前端”团队。大前端团队如何选型技术？如何疾速上手？如何高效协同？让咱们看看快成科技如何解决这一问题。缘起两地三团队快成科技是网络货运畛域的领军科技企业，畛域排名市场前三，平台有 3w+ 大宗商品货主，将货单公布到平台，由 60w+ 的卡车司机接单承运，每年产生 120亿的运费交易额。以司机端为例，须要承载从发单抢单到从进出场治理，从在途门路监控到金融白条加油加气等一系列互相强关联、流程链条长的业务。这些工作由两地三个研发团队，独特分工协作实现。在 7*24 小时不间断的客户服务和每月 2-3 次发版的高度迭代中，技术框架瓶颈逐步凸显，具体包含：在零碎框架方面，初始框架是原生 App+HTML5，传统 web 存在启动白屏和性能响应不晦涩，大大降低了用户体验；在发版周期方面，研发部门多，产品链条长，局部企业须要更多的共性定制化服务导致发版期待周期不统一，频繁的发包更新不仅升高了经营效率，也给客户带来了频繁更新的困扰；在体验一致性方面，原生开发依赖零碎框架，因为原生个性不同，而导致各厂商多渠道平台中差异化凸显，多平台性能、体验差异较大；在多部门合作方面，罕用开发语言、前端 JavaScript 框架等不尽相同，不能及时依据需要张弛和上线 DDL 来灵便调配技术人员合作开发。在快成科技业务继续高速倒退的背景下，优良的技术架构是“提质增效”的保障，零碎重构势在必行。快成的小伙伴们开始寻找优良的架构，解决场景问题。选型四维度快成小伙伴针对发现的问题，探讨出四个选型维度：框架成熟度：简略来说，就是这个新技术是否靠谱，百亿的业务压力，没有太多的试错空间；迁徙老本：如果想得到新技术带来的收益，须要咱们付出什么代价，例如新技术的学习老本、原来架构的革新老本等；社区气氛：次要是看跟进这个技术的人够不够多、文档资料是否丰盛、遇到问题是否失去帮忙等；考量根底上兼顾性能、跨平台和动态性。定好技术选型考量指标之后，团队对常见的跨平台计划诸如 React Native、Weex、Flutter 和小程序进行了一系列的调研以及 Demo 制作，横向比拟如下： 技术选型调研后果React Native 和 Weex<ul><li>启动工夫慢、帧率不如原生；</li><li>迁徙老本较大，开发者需封装一层较重的中间层，对研发人员要求较高。</li></ul>Flutter性能和效率至上然而动态化能力十分无限。小程序自身并非一种跨平台开发计划，无奈利用自身 app 关上，更看重渠道劣势。 正在进入技术选型窘境的时候，快成物流科技偶尔接触到了源自支付宝技术框架的mPaaS，通过应用 mPaaS 小程序容器，整合 mPaaS 框架、离线包和复用 h5 插件，依靠于性能强劲的 web 渲染引擎，完满合乎了咱们对技术选型的冀望与要求。 # 入手试试看选定技术选型之后，在重构初期，针对我的项目工程建设以及划分上，咱们共事之间进行了一场强烈的头脑风暴，最终选定了在多部门合作前提下进行轻量组件化并行开发多个小程序并进行动静下发的计划。快成团队从协同、技术等多角度，进行框架的逐渐导入。如需理解残缺内容详情，欢送观看 CodeHub#5 全程回放 ### 1. 多团队协同### 2. 实在场景测试真机预览与调试问题，首先要设置好白名单，设置形式可参考文档，而后在原生端依据文档进行相应的配置和代码书写，最初须要留神的是 IDE 生成的二维码须要应用咱们 App 的扫码能力扫描（可接入 mPaaS 的扫码组件），用支付宝扫一扫是打不开的。`ScanService service = LauncherApplicationAgent.getInstance().getMicroApplicationContext() .findServiceByInterface(ScanService.class.getName());ScanRequest scanRequest = new ScanRequest();scanRequest.setScanType(ScanRequest.ScanType.QRCODE);service.scan(this, scanRequest, new ScanCallback() { @Override public void onScanResult(boolean success, Intent result) { if (result == null || !success) { showScanError(); return; } Uri uri = result.getData(); if (uri == null) { showScanError(); return; } // 启动预览或调试小程序，第二个参数为小程序启动参数 MPTinyHelper.getInstance().launchIdeQRCode(uri, new Bundle()); }});` ### 3. 外围问题解决在同一小程序不同页面跳转传参的时候咱们遇到了大参数传递被截断的问题。通过剖析是小程序对路由跳转 API 进行了参数携带长度的限度，起初咱们抉择应用缓存 my.setStorage 来进行大批量参数的存取应用，这里须要留神的是同一小程序缓存下限为 10MB，在适合的中央应用 my.clearStorage 革除缓存尤为重要。 ### 4. 优雅的交互晋升在 UI 开发上，咱们心愿小程序页面更靠近于原生，所以咱们进行了小程序的自定义导航栏的开发，这部分是须要原生端来实现的，倡议下载官网 Demo 配合文档来进行开发。咱们还遇到过一个令人印象比拟粗浅的 UI 问题，在 iOS 设施上进行表单类多 input 组件页面开发时，会呈现输出错行的状况：通过查阅文档，发现这是个兼容性问题，对于须要启动键盘的组件，如 input、textarea 等，目前默认应用的是原生键盘。如果键盘和组件的交互存在异样，可在组件中增加 enableNative="{{false}}" 属性，即可复原到应用 WKWebview 的键盘。同时因为应用的是零碎键盘，也就不能应用 mPaaS 提供的数字键盘等，键盘相干目前不再专门适配。 # 将来可期应用 mPaaS 小程序容器下的「快成司机」界面预览随着技术的一直演进和降级，看似开发变得越来越简略便捷，缩小了反复无意义的工作，理论反而特地考验开发人员剖析定位解决问题的能力，创新能力和学习能力。但目前 mPaaS 小程序比照支付宝小程序还是存在肯定的差距，在兼容性和 H5 框架上还存在一些小问题，也心愿 mPaaS 及小程序框架能一直演进，将来可期！ **E · N · D ** * > 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

关于sql:SQL大全MySQL基础持续更新中

SQL根底创立数据库默认字符集 create database DATABASE_NAME; create database 数据库名;设置字符集编码 create database DATABASE_NAME character set utf8; create database 数据库名 character set utf8;查看数据库信息show create database DATABASE_NAME;show create database 数据库名;删除数据库drop database DATABASE_NAME;drop database 数据库名;查问所有数据库show databases;应用数据库/进入数据库use DATABASE_NAME;use 数据库名;查问库中存在什么表show tables;创立新表 create table TABLE_NAME( column1 type1 [not null] [primary key], column2 type2 [not null], ...);删除表drop database TABLE_NAME;drop database 表名;查问所有表show tables;批改表名alter table 旧表名 rename to 新表名;alter table OLD_TABLENAME rename to NEW_TABLENAME;查问创表语句show create table TABLE_NAME;show create table 表名;查问表构造 desc TABLE_NAME;desc 表名;减少一个列/减少一个字段 ...

关于sql:数据库SQL-Server

参考资料1.简介SQL Server 是 Microsoft 开发的一个关系数据库管理系统(RDBMS)，当初是世界上最为罕用的数据库；SQL Server 是一个高度可扩大的产品，能够从一个繁多的笔记本电脑上运行的任何货色或以高倍云服务器网络，或在两者之间任何货色。尽管说是“任何货色”，然而依然要满足相干的软件和硬件的要求；SQL Server 1.0 在1989年公布，至今 SQL Server 已成为一个真正的企业信息化平台。SQL Server 2014 包含内置的商务智能工具，以及一系列的剖析和报告工具，能够创立数据库、备份、复制、安全性更好以及更多。2.装置SQL Server 2019 装置教程_windows装置和设置用户明码 3.应用Microsoft SQL Server用户界面操作 4.跨网近程连贯Sql Server 数据库之间如何进行跨网近程连贯拜访 5.SQL server数据实时同步到mysqlSQL server数据库导入MySQL 6.

关于sql:实操指南-Resource-Queue如何实现对AnalyticDB-PostgreSQL的资源管理

简介：作者：阿里云数据库OLAP产品部 - 子华一背景AnalyticDB PostgreSQL版（简称ADB PG）是阿里云数据库团队基于PostgreSQL内核（简称PG）打造的一款云原生数据仓库产品。在数据实时交互式剖析、HTAP、ETL、BI报表生成等业务场景，ADB PG都有着独特的技术劣势，在金融、物流、泛互联网等行业都有宽泛的利用，是传统数仓上云、去O去T、替换自建Greenplum的标杆云上数据仓库产品。数据仓库产品是数据分析系统的重要组件之一，各类线上业务对数据仓库产品的稳定性、可用性具备很高的要求。不足无效的资源管理机制会导致数据库产品的稳定性降落，产生例如连接数打满OS限度、内存不足、过程卡死等问题，从而影响产品的可用性。 Resource Queue（资源队列）是ADB PG的一种资源管理形式，可能对数据库的CPU、内存等资源进行限度，对多租户资源限度、保障数据库稳固运行具备肯定的作用。顾名思义，Resource Queue以队列模式对运行在数据库集群上的SQL进行资源管理。对于每个用户，他的所有连贯只能归属于一个队列。而对于每个队列可能治理多个用户的连贯。没有显示指定资源队列的用户，会归属于默认资源队列治理。通过限度每个队列的资源总量，咱们能够达到限度某类业务或者某个用户应用的资源总量的目标。咱们以ADB PG某在线交易平台类客户A为例，介绍Resource Queue的应用。客户A基于ADB PG构建数据仓库，日常运行三类业务：以交易数据入库为代表的实时类业务；用于撑持决策分析的报表类业务；以及用于实时大屏展现的可视化类业务。咱们依据三类业务的不同特点，按如下策略配置资源队列。客户A的实时类业务的典型代表是，交易数据经Kafka->Flink->ADB PG链路实时写入ADB PG。这类业务的典型特点是，峰值并发比拟大，单个SQL资源耗费小。在进行资源队列限度前，业务高峰期常常产生忽然进步的并发查问打满数据库连贯，造成高可用探活查问执行失败，引发实例不可用。对于这类业务咱们将其关联到一个高CPU权重、大并发限度（平安阈值内）、单个SQL内存份额低的队列。既保证数据的疾速入库，又避免流量洪峰造成零碎不稳固。客户A的另一类典型业务是报表类、ETL类业务，这类业务会在实时类业务的低峰期进行调度，生成报表以提供决策反对。这类业务波及的数据量较大，耗费内存量和产生的临时文件量大。对于这类业务，咱们将其关联到低CPU权重、低并发限度，然而内存份额高的队列，在满足业务须要的同时，管制内存应用下限；除此之外，客户还基于ADB PG数据仓库反对数据的实时可视化展现，这类可视化计划往往具备十分稳固的并发，然而对查问的延时具备肯定的要求。对于这类业务，咱们将其资源队列设定为高CPU权重，低并发限度，以及宽泛的优化器查问打算耗费份额，最大水平为其生成良好的查问打算，以保障业务稳固。接下来，本文会具体介绍Resource Queue的应用形式、状态监控，以及它的实现机制。二 Resource Queue简介Resource Queue反对通过SQL配置，反对进行四种类型的资源限度：并发限度、CPU限度、内存限度和查问打算限度。用户能够通过SQL在数据库内定义多个资源队列，并设置每个资源队列的资源限度。在一个数据库中，每个资源队列能够关联一个或多个数据库用户，而每个数据库用户只能归属于单个资源队列。另外，并不是所有提交到资源队列的SQL都会受到队列限度的限度，数据库只会限度SELECT、SELECT INTO、CREATE TABLE AS SELECT、DECLARE CURSOR、INSERT、UPDATE 和DELETE这些类型SQL的资源利用。另外，在执行EXPLAIN ANALYZE命令期跑的SQL也会被资源队列排除。资源队列反对的资源限度配置如下：配置名配置阐明MEMORY_LIMIT队列中所有查问所应用的内存总量。ACTIVE_STATEMENTS队列中容许同时运行的查问数。超出该设置值的查问须要排队期待执行。PRIORITY队列的CPU应用优先级，能够设置为以下级别：LOW、MEDIUM、HIGH 和MAX。默认值为MEDIUM，优先级越高的队列会被调配越高的CPU份额。MAX_COST查问打算耗费限度。通过SQL语句定义一个新的资源队列：`CREATE RESOURCE QUEUE etl WITH (ACTIVE_STATEMENTS=3, MEMORY_LIMIT='1GB', PRIORITY=LOW, MAX_COST=-1.0);`ACTIVE\_STATEMENTS：队列中容许同时运行的查问数，即队列中容许并发查问的最大并发值。数据库容许超出ACTIVE\_STATEMENTS数目、然而少于数据库最大连接数MAX\_CONNECTIONS数目的链接连贯到数据库，然而这部分SQL连贯并不会立即开始运行，而是排队期待。 MAX\_COST：查问打算Cost限度。数据库优化器会为每个查问计算Cost，如果该Cost总量超过了资源队列所设定的的MAX\_COST的值，该查问就会被回绝。ADB PG的默认配置为0，即不受限制。 Memory Limit：ADB PG能够通过设置statement\_mem来决定每条SQL在每个Segment上应用的内存下限。Memory Limit既没有默认值，也能够不指定。在MEMORY\_LIMIT参数没有被配置时，一个资源队列中的一条SQL所容许的内存大小，由statement\_mem参数决定： * 如果一个资源队列没有设置MEMORY\_LIMIT的话，每个资源所调配到的内存大小就是statement\_mem的服务器配置参数，一个资源队列的可用内存大小是依据statement\_mem和ACTIVE\_STATEMENTS的计算结果。 * 当资源队列有设置MEMORY\_LIMIT时，单个SQL所应用的内存量会由队列中的平均分配值(MEMORY\_LIMIT/ACTIVE\_STATEMENTS)和statement\_mem中的最大值决定，具体计算形式能够参考前面实现章节。资源队列中能够并行执行的查问数会受到该队列的可用内存限度。举个例子：对于队列etl，设置STATEMENTS=3， MEMORY\_LIMIT=2.1G；那么在没有设置statement\_mem的状况下，每个查问默认应用内存700MB。 SQL1进入队列，应用内存700MB，此时队列残余内存1.4G； SQL2进入队列，设置statement\_mem为1.0GB，此时队列残余内存为0.4GB；此时，队列残余内存无奈满足SQL3的内存应用需要（默认700GB），那么尽管队列中并行查问数没有达到队列限度，SQL3仍然无奈执行，须要排队期待。 PRIORITY：数据库运行的SQL会依照其所在资源队列的优先权设置来共享可用的CPU资源。当一个来自高优先权队列的语句进入到流动运行语句分组中时，它能够失去可用CPU中较高的份额，同时也会升高具备较低优先权设置队列中曾经在运行的语句失去的份额。查问的绝对尺寸或复杂度不影响CPU的调配。如果一个简略的低代价的查问与一个大型的简单查问同时运行，并且它们的优先权设置雷同，它们将被调配等同份额的可用CPU资源。当一个新的查问变成流动时，CPU份额将会被从新计算，然而优先权相等的查问仍将失去等量的CPU。例如，管理员创立三个资源队列：streaming、etl、prod，并相应地配置为以下优先权： * streaming — 低优先权 * etl— 高优先权 * prod — 最大优先权当数据库中只有etl队列中有查问1和2同时运行时，它们有相等份额的CPU，因为它们的优先权设置相等：上图中显示的百分数都是近似值。高、低和中优先权队列的CPU应用并不总是精确地用这些比例计算出来。当一个streaming队列中的查问开始运行时，在etl队列中两个查问仍然放弃相等的CPU份额，而低优先级的query3则会以较低CPU份额运行。而当最高优先级队列prod中有查问进入队列之后，其CPU应用会被调整以阐明其最大优先权设置。它可能是一个非常简单的查问，但直到它实现前，它都将要求最大份额的CPU。而其余查问的优先级则会被调整为较低的CPU份额。# # 三 Resource Queue应用## ## 3.1 创立资源队列 ADB PG容许用户应用SQL创立资源队列，并指定各类资源限度。应用CREATE RESOURCE QUEUE命令来创立新的资源队列。 ### 创立带有并发限度的队列带有ACTIVE\_STATEMENTS设置的资源队列会限度指派给该队列的角色所执行的并发查问数量。`CREATE RESOURCE QUEUE etl WITH (ACTIVE_STATEMENTS=3);`这意味着对于所有被调配到etl资源队列的角色，在任意给定时刻只能有三个流动查问被运行在这个零碎上。如果这个队列曾经有三个查问在运行并且一个角色在该队列中提交第四个查问，则第四个查问只有等到一个槽被释放出来后能力运行。### ### 创立带有内存限度的队列带有MEMORY\_LIMIT设置的资源队列管制所有通过该队列提交的查问的总内存。在与ACTIVE\_STATEMENTS联结应用时，每个查问被调配的默认内存量为：MEMORY\_LIMIT /ACTIVE\_STATEMENTS。例如，要创立一个流动查问限度为10且总内存限度为2000MB的资源队列（每个查问将在执行时被调配200MB的Segment主机内存）：`CREATE RESOURCE QUEUE etl WITH (ACTIVE_STATEMENTS=10, MEMORY_LIMIT='2000MB');`另外gp\_vmem\_protect\_limit参数会限度一个Segment上调配的内存总大小。该参数的优先级更高，如果这个参数超标，查问可能会被勾销。### ### 设置优先级为了管制一个资源队列对可用CPU资源的耗费，用户能够指派一个适合的优先级。`ALTER RESOURCE QUEUE etl WITH (PRIORITY=LOW);ALTER RESOURCE QUEUE etl WITH (PRIORITY=MAX);`## 3.2 指派角色（用户）到资源队列一旦创立了一个资源队列，用户必须把角色（用户）指派到它们适合的资源队列。如果没有显式地把角色指派给资源队列，它们将进入默认资源队列pg\_default。应用ALTER ROLE或者CREATE ROLE命令来指派角色到资源队列。例如：`ALTER ROLE name RESOURCE QUEUE queue_name;CREATE ROLE name WITH LOGIN RESOURCE QUEUE queue_name;`### 从资源队列移除角色所有用户都必须被指派到资源队列。如果没有被显式指派到一个特定队列，用户将会进入到默认的资源队列pg\_default。如果用户想要从一个资源队列移除一个角色并且把它们放在默认队列中，能够将该角色的队列指派改成none。例如：`ALTER ROLE role_name RESOURCE QUEUE none;`## 3.3 批改资源队列在资源队列被创立后，用户能够应用ALTER RESOURCE QUEUE命令更改队列限度，或应用DROP RESOURCE QUEUE命令移除一个资源队列。 ### 批改资源队列配置 ALTER RESOURCE QUEUE命令更改资源队列的限度。要更改一个资源队列的限度，能够为该队列指定想要的新值。例如：`ALTER RESOURCE QUEUE etl WITH (ACTIVE_STATEMENTS=5);ALTER RESOURCE QUEUE etl WITH (PRIORITY=MAX);`### 删除资源队列 DROP RESOURCE QUEUE命令能够删除资源队列。要删除一个资源队列，该队列不能有指派给它的角色，也不能有任何语句在其中期待。`DROP RESOURCE QUEUE etl;`# 四 Resource Queue状态监控## ## 4.1 查看队列中的语句和资源队列状态 gp\_toolkit.gp\_resqueue\_status视图容许用户查看一个负载治理资源队列的状态和流动。对于一个特定资源队列，它展现有多少查问在期待运行以及零碎中以后有多少查问是流动的。要查看零碎中创立的资源队列、它们的限度属性和以后状态：`SELECT * FROM gp_toolkit.gp_resqueue_status;`## 4.2 查看资源队列统计信息如果想要继续跟踪资源队列的统计信息和性能，用户能够应用pg\_stat\_resqueues零碎视图来查看在资源队列应用上收集的统计信息。`SELECT * FROM pg_stat_resqueues;`## 4.3 查看指派到资源队列的角色要查看指派给资源队列的角色，执行下列在pg\_roles和gp\_toolkit.gp\_resqueue\_status系统目录表上的查问：`SELECT rolname, rsqname FROM pg_roles, gp_toolkit.gp_resqueue_status WHERE pg_roles.rolresqueue=gp_toolkit.gp_resqueue_status.queueid;`## 4.4 查看资源队列的期待查问用户能够看到所有资源队列的所有以后沉闷的以及在期待的查问：`SELECT * FROM gp_toolkit.gp_locks_on_resqueue WHERE lorwaiting='true';`如果这个查问不返回后果，那就意味着以后没有语句在资源队列中期待。 ## 4.5 查看流动语句的优先权查看以后正在被执行的语句并且提供优先权、会话ID和其余信息：`SELECT * FROM gp_toolkit.gp_resq_priority_statement;`## 4.6 重置流动语句的优先权用户能够应用函数gp\_adjust\_priority(session\_id,statement\_count,priority)调整以后正在被执行的语句的优先权。应用这个函数，用户能够晋升或者升高任意查问的优先权。例如：`SELECT gp_adjust_priority(12, 10000, 'LOW');`在这个函数的参数中，session\_id代表会话id, statement\_count代表要调整的SQL在session中的序号，priority是待调整的优先级。能够通过gp\_resq\_priority\_statement视图查问现有语句的上述信息。`select * from gp_toolkit.gp_resq_priority_statement;`# 五 Resource Queue实现 ADB PG数据库是MPP架构，整体分为一个或多个Master，以及多个segment，数据在多个segment之间能够随机、哈希、复制散布。在ADB PG中，Resource Queue的资源限度级别是语句级别，即在整条SQL执行的任何时刻，不论是否处于事务中，均会受到资源队列的限度。如上文所述，Resource Group反对对并发、CPU和内存等进行限度，本节会具体介绍对这些资源进行限度的实现细节。 ## 5.1 并发限度 ADBPG数据库是多过程模型，分布式数据库的每个节点会启动多个子过程，各个子过程通过共享内存、共享信号量、共享音讯队列的形式实现过程间通信。 Resource Queue基于分布式锁实现。在ADBPG中所有的SQL连贯首先会达到Master节点，在通过解析、优化，达到执行器层面时，会首先尝试获取ResQueueLock类型的排他锁。在单个ADB PG节点中，同一时间只能有一个过程获取到ResQueueLock类型的排他锁，而每个过程只会蕴含单个线程。在取得ResQueueLock类型的排他锁之后，执行SQL的后盾过程会读取及更新共享内存中的值，特地是队列中并发执行语句的计数值。若资源短缺，则会在更新完共享内存中对应资源队列中的资源使用量之后，开释ResQueueLock，开始SQL的理论执行；若资源有余，比方以后队列中正在运行的SQL数量曾经达到了所设定的并发上限值，对应的后盾过程则会sleep排队期待其余query执行结束后开释资源。 ## 5.2 内存限度对于内存的限度的实现形式与对并发限度的实现形式大体是统一的，只是对于判断资源队列中是否有资源来运行提交的SQL的形式有一些区别。对于某个Resource Queue中的SQL，可能应用的内存下限计算如下： 1）如果没有设定resource queue的memory\_limit值，那么间接取数据库的statement\_mem值；2）如果设定了resource queue的memory limit值，则依据所设定的resource queue的memory\_limit值，计算资源组可能应用的内存总量；用总量除以resource queue设定的并发数，失去单条SQL所能利用的上限值。再将这个上限值与statement\_mem取一个最大值，作为SQL最终应用的内存上限值。 ## 5.3 CPU限度 Resource Queue的CPU限度是一个很有意思的实现。ADB PG专门为Resource Queue CPU限度的性能拉起了一个专门的过程：sweeper过程来监控各个后盾过程的CPU应用，以及调节各个后盾过程的CPU份额。这个过程是一个与数据库高度独立的过程，它没有加载一些缓存、资源类的货色，也无奈开启事务或者查零碎表，它的流动就是不停的读写共享内存，计算各个过程的CPU应用，更改CPU调配份额。各个理论执行SQL的后盾过程(backend)会依据所计算的CPU份额去休眠肯定的工夫，从而调节各个SQL理论的CPU使用率。这个过程的主体流程如上，他的流程非常简单，就是一直地sweep和sleep。各个理论执行SQL的backend过程在启动时，会在共享内存中注册一些状态，并在执行过程中执行零碎调用getrusage等，更新CPU应用状态；sweeper过程会依据这些共享内存状态，以及所设定的资源队列CPU利用值，在共享内存中更新对应backend过程的CPU份额(targetCPU)。而在backend运行过程中，则会调用BackoffBackend，依据CPU份额来进行一段时间的休眠，从而调节整体的CPU利用率。在运行过程中，分布式数据库的每个计算节点都会有一个sweeper过程来调节每个节点的CPU调用，使资源队列的CPU配置全局无效。# # 六总结资源管理对于数据库集群的多租户治理、资源细粒度调配具备很重要的价值。Resource Queue可能对分布式数据库进行整体的资源管理和管制，在多租户隔离、保障数据库整体安稳运行具备肯定的价值。除了Resource Queue的资源管理形式外，ADB PG还反对 Resource Group 的资源管理形式，可能进行更精密的资源管制。Resource Group现已在专有云环境提供应用，后续会逐渐在私有云提供能力。后续咱们会介绍Resource Group的根本应用和最佳实际。> 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

关于sql:实操指南-Resource-Queue如何实现对AnalyticDB-PostgreSQL的资源管理

关于sql:从TDSQL看分布式数据库的技术之美

导语 | 每一个时间段总是一个新时代，新技术层出不穷使得数据库技术焕发新生。Spanner、CockroachDB、TDSQL等分布式数据库正是这个时代的弄潮儿。本文由腾讯云数据库专家工程师李海翔在 Techo TVP开发者峰会「数据的冰与火之歌——从在线数据库技术，到海量数据分析技术」的《分布式数据库的演进》演讲分享整顿而成，带大家品尝分布式数据库架构、前沿技术和TDSQL技术实际，感触分布式数据库的技术之美。点击可观看精彩演讲视频一、分布式数据库架构我明天所分享的内容次要集中在数据库技术层面，和腾讯近十年的分布式数据库技术倒退非亲非故，次要有三方面：第一是分布式数据库的历史倒退和演进；第二是分布式数据库里较外围的技术内容，包含相干的内容知识点；第三是腾讯TDSQL在前沿方面所做的工作。TDSQL是一个基于HTAP的分布式数据库系统，尤其强调强统一。2017-2018年咱们提出过“全时态数据库”的概念，过后提出实现了一个叫做HTAC的混合事务剖析处集群架构，HTAC和HTAP十分靠近，在工程方面咱们称为HTAC，用一个实践的名词来概括就是HTAP（混合事务剖析解决零碎），所以在那时咱们就曾经推出本人的原创性产品，而这个产品这两年的演变始终专一于强一致性，在去年咱们推出了兼具实践与实际的产品，分明解释了“强统一”这个概念。该技术对应的产品，外部通过一段时间打磨后，载有该项技术的TDSQL将在TDSQL私有云等产品中很快推出。 1. 分布式系统经典架构概述先来看第一局部，分布式数据库的倒退演进。这幅图在阐明什么？外面在谈一些基础架构：Shared Nothing、Shared Memory、Shared Disk、Shared Everything。这些是什么？最早从哪里来？硬件层面是做软件的根底，硬件层面的倒退决定着软件技术的倒退，硬件层面把一些根本的框架搭好后，数据库的软件或者说应用层、零碎层的软件都会在下面叠加，就像搭积木一样，一块一块地往上垒。对于数据库外部其实也是这样的，分模块、分档次，之后这些货色都能够搭建在一起。然而数据库有着紧耦合性较强的特点，搭在一起后就很难拆开，然而当初做分布式数据库的一个趋势是要尝试把这些货色拆分，再像搭积木一样往上垒，哪个中央须要什么样的组件，就去建设这样的组件，模块与模块之间要解耦，解耦之后更易搭建，把这个零碎搭得在未来更具扩展性。分布式数据库系统的底层根底是和硬件严密相干的。 2. 分布式系统架构经典支流技术我从技术的角度展现一下数据库的代表技术。在这幅图中，第一个人是数据库界图灵奖的第二位得主——关系模型的创始人科德博士，他在1970年的时候以一篇论文奠定了关系型数据库的根底。1974年时有两个典型的技术诞生，一个是SQL语言，另外一个是事务处理技术。50多年前，数据库界第三位图灵奖得主James Gray开始钻研事务处理，并对失去了一系列的开创性的成绩，所以事务处理奠基于70年代，直至今日。同年，IBM同样诞生了一个开创性的技术，就是咱们所熟知的SQL，SQL这个概念是从IBM在做数据库的钻研起就开始提出的结构化查询语言。再往后，是ER模型，ER模型是实体关系模型，可能帮忙咱们做数据库利用的建模。然而，在数据库技术的倒退过程当中呈现了很多模型，包含后面说的1970年之前的关系模型、层次模型，再往前的网状模型，这些模型和ER模型产生的初衷是一样的，都是要从数据、数据档次的角度与实体世界进行映射，以让数据世界具备表白、计算实体世界的能力。只不过ER模型在倒退过程中只被人们用于了关系建模（教科书撷取了精髓展现，读者的了解水平不再能全面粗浅），但它背地蕴含的内容其实和关系模型、层次模型是雷同的，如果咱们回顾历史还原其初衷，则能从历史当中看到的一些根本的货色。到了1980年，数据库界呈现基于代价的查问优化技术，它可能较好的选出一个近乎最优的执行打算。尔后，数据库又演变出了基于火山模型的执行器，推动数据库的技术进一步倒退。从这副图中能够看出，数据库技术倒退基本上是从没有事务到有事务概念这条主线上推动的，到了1993年的时候有了AP和TP的分叉，这归功于科德博士，他除了提出关系模型，又提出了OLAP的概念——在线剖析事务处理，以前的主线就变成了OLTP和OLAP两条分支。随着时光的持续推移，2014年，有意思的事呈现了，一个并不是学术研究机构而是对行业的钻研机构——Gartner，推出一个概念：HTAP，冀望在事务型的零碎上加强剖析的性能。这个概念这几年大火，仿佛在补救事务型数据库的重事务处理弱剖析能力的缺点（概念分家，指导思想发生变化，看来还是有害处的）。人们总是有一个美妙志愿，在一个零碎内搞定所有的事件。这同人类的需要和一直变动的认知存在关系。但在这之前，2012年谷歌的Spanner零碎诞生了，它标记着人们从不要SQL到拥抱SQL拥抱数据库的事务处理技术，演变成了New SQL零碎。前述这些技术，是数据库的经典技术，无论单机数据库还是分布式数据库，都基于这些基础性的技术。尽管TDSQL是一个分布式数据库，但外面90%甚至更多的根底外围性能来自于单机数据库系统，所以技术的演进其实是踏着后面的根底而一直演变的，分布式数据库的技术离不开后面咱们谈到的关系模型、事务处理等根底技术。因而我认为做分布式数据库离不开单机数据库系统，意识分布式数据库要先从单机数据库系统动手，单机数据库系统实际上就有了分布式数据库的五脏六腑，它曾经比拟全面。只是分布式数据库在根底技术之上，因零碎架构的变动，有了一些新挑战。上面，咱们以MySQL的数据库系统架构为例，来分享单机数据库系统蕴含了哪些模块和组件。左上角的SQL是一个入口，它执行完的后果在这个箱子里转了一圈后将后果返回用户，进入到数据库系统里。右边的是MySQL Server，左边是它的存储引擎，实际上整个数据库能够分为三层：右边的Server，左边的存储引擎，存储引擎上面和操作系统紧密结合的是和内部文件相干的一部分内容。Server在接管用户的SQL语句并解析，就像编译器，对于SQL语句做解析失去一棵语法树，这棵语法树通过查问优化器的转换变成逻辑查问打算，再变成物理查问打算，过程中会做很多优化，就像子查问优化，表达式怎么去重、化简等工作。再往后它就要交给执行器去执行，执行器实际上和存储系统是严密绑定的，存储系统的两大部分，一部分是执行器，各种SQL语句的执行，DDL、DML、DQL等，它的执行过程当中又受到横向的事务处理与它正交的组合，在事务处理零碎的管制之下，各种SQL语句高并发地执行，并通过各种模块。模块从底层往上看，数据库系统最底层的是一个文件，因为它要存在操作系统上，而操作系统上是以文件为单位来组织数据的，所以大家能够看到最底层的是一些物理文件，物理文件有它的格局，格局上就有数据库本人定义的各种数据格式。数据能够分为两局部，一部分是用户数据，一部分是数据库系统本身要保护的日志数据，数据能够读入写出有物理的IO产生，其要和存储引擎，也就是执行器加存储系统打交道。数据被读入后进入内存，不同的数据库有其本人特定的数据格式，这须要access解析格局，初始面对的是一个一个物理页面，把它们先加载到缓存区里，而后做格局的转化，物理页面被解析成一个一个的记录和列，便于下层对它进行计算。当这些解析实现后，比方有两个客户端连进来，那就有读写同样数据的可能，因而有并发存在，就可能会产生数据异样，事务处理零碎这时候就要产生作用——防止数据异样、保证数据的一致性，通过计算之后再把后果通过SQL Server向上返回。作为一个分布式数据库系统而言，它离不开这个执行过程，也离不开这外面所蕴含的根底模块和组件。数据库系统是倒退和逐步演进的。实际上晚期做单机数据库的大家都相熟主从架构，MySQL的主从架构是基于逻辑和物理混合的，但更多是偏差逻辑地做主从架构的数据传输。而后纯正的单机数据库系统推动了一步，成为近似于散布的，物理节点曾经变成多个，然而一主多备，多备只能去做读，还不是纯正的分布式数据库系统，所以数据库系统实际上架构的倒退分成两代，第一代是纯的单机零碎，第二代是分布式系统，介于第一代和第二代之间就有这么一个过渡性的阶段，我把它称之为1.5代，然而它还归属于单机数据库系统，所以有了这样一个主从架构。典型的每一个数据库都做了基于物理日志的，像Oracle、PG流复制等，但MySQL基于逻辑日志这样的格局去做主从构造的。时光推移到七八年前，亚马逊的Aurora零碎诞生，它实质上还是主从架构、一主多备式的，提高的中央在于做成了一个云上的存算拆散的零碎。所以1.5时代的产品，典型的代表是相似于晚期的主从+Aurora这种架构，这是一个过渡时代。再往后咱们会进入到真正的分布式数据库时代，它典型的标记是什么？是多写，在每一个节点上都平等地看待，能够在每一个节点上写，这外面的技术就又有多种，有的是伪的分布式，其把事务的所有写操作集中在繁多的节点下来做，真的分布式是利用分布式并发拜访控制算法，在每一个节点下来做数据一致性的保障。 3. 小结数据库根本架构的演进就是经验了这么一个过程，总结一下，反过来从技术角度来看到底是什么因素在推动分布式数据库系统的演进。其实数据库系统有一些外在的、本质性的需要在推动它，咱们以前说数据库系统外面有“三高一易”，高牢靠、高可用、高性能、易用性等等，这些根底因素在推动着分布式技术一直地向前倒退，到起初演化成分布式数据库系统的时候，对于程度扩大的要求提上日程，所以我的第一个总结是针对扩大，不仅是垂直扩大，而且要程度扩大，所以对于扩展性下的多读多写场景，使得分布式数据库的构造变成纯正的每一个节点都是对等的构造。在散布零碎里要考究可用性，包含数据层面的可用如共识协定下的数据多正本机制、也包含整个零碎性能层面的可用。如果以较少的投入取得高的性能，那就能够对外撑持更多的业务，老本就会更低。所以对于数据库外在原生的要求从单机数据库系统到分布式数据库系统始终没有产生过变动。这是我分享的第一局部。二、分布式事务与一致性1. 数据异样第二局部，咱们来看看分布式数据库系统外面的技术层面会蕴含一些什么样的内容。事务型分布式数据库系统外面最外围的，肯定是事务处理技术。数据库的操作通过形象当前就有两种，一种是读操作，一种是写操作，当有了并发存在的时候，至多有两个事务读写同样数据项的时候，就可能产生数据异样。右边的图在说当读写在两个事务的正交之下，就是2×2四种状况，四种状况里只有读和读不会产生数据异样，其余的组合都会产生数据异样，这是数据异样产生的起因。因为有并发读写雷同的数据项，事务处理就是要解决这样的问题。事务处理有ACID四个个性，其中的C是一致性，I是隔离性，其实C和I是雷同的内容，就像硬币的两个面，保障统一、保障隔离，隔离级别弱一点，一致性会差一点，会容许一些数据异样存在，也就是左边这部分示意的，一些特定的数据异常现象会产生。这幅图总结了局部数据异常现象，但实际上数据异样不只是这么一点点，TDSQL在做的一项工作是：系统化地钻研数据异样到底有多少种。目前为止人类都不可能解释分明数据异样到底有多少。 SQL规范定义了四种数据异样、四种隔离级别，James Gray在里1995年的一篇论文定义了八种数据异样、八种隔离级别，在这种状况下，如果忽然又发现第9个数据异样，依照SQL规范，它应该被放在这两个体系下的哪一个隔离级别之下？这样的问题在目前是不能答复的，而这也是TDSQL在做分布式数据库研发过程当中所遇到的、所要解决的问题，只有答复了这样的问题之后，一个零碎能力真正做到强统一，所幸咱们目前对这样的一个根底问题有了明确的答案，并且秉持腾讯开源精力，把这项钻研后果开源到了3TS零碎（Tencent Transaction Processing Testbed System）。解决数据异样的一些技术就是并发拜访控制算法，而并发拜访控制算法又有很多，比方基于封闭的、基于工夫戳的、基于乐观机制的等等。TDSQL开源的零碎是做根底技术钻研的，即腾讯事务处理试验床，咱们的零碎叫做3TS，取方才我说的那几个词外面的第一个字母T，所以有三个T，就是3TS。而解决分布式数据库系统外面和事务相干的技术，比拟重要的还有一种数据异样——读半已提交。读半已提交这样的数据异样是基于物理散布的零碎上产生的，在一个节点上某个数据项曾经提交了，转账的另一个节点上的还没提交，这时来第二个事务去读这两个节点，肯定能读到已提交的那个节点上的数据，然而读不到未提交节点上的数据，也就是在未提交节点上所读到的数据是旧的数据，旧的数据和已提交的新数据二者之间不能保证数据一致性，所以会产生称之为读半已提交的数据异样，这就是分布式数据库在事务处理层面即一致性方面要解决的问题。 2. 短少一致性面临的挑战与业界解决方案但分布式数据库系统面临的不只这些问题。因为数据库从一个集中式零碎扩大变成了每一个都逻辑独立的子系统，但对外它的行为还像一个物理繁多的数据库系统要体现的一样，这就面临着新的挑战。单机数据库系统上做事务处理要保障ACID，分布式系统外面也要保障ACID，然而分布式系统外面要有分布式一致性，如：线性统一、程序统一、因果统一，还有读后写、写后读等等，而这两个碰到一起就会产生新的问题，这是分布式系统要解决的。不只是下面提及的问题，咱们面对的问题更为简单。例如，如下这张图详情了各种分布式一致性的概念，很简单，这外面大概有近60种分布式一致性，光把这幅图弄清楚、把每一种一致性弄清楚，曾经不容易了，再和事务的ACID联合，难度就会更大。业界对于分布式事务的一致性，是有钻研的。如下图，我大略解释一下这幅图的内容：左上角事务一致性，左下角分布式一致性，右上角有个隔离级别下的事务一致性问题，这是数据库里要解决的事件，但偏偏就在该图这个红色方框，分布式一致性和事务处理外面联合的这些中央目前为止没有相干的实践和技术来撑持，而这些也正是TDSQL在做分布式数据库系统当中致力于解决的问题。比照业界谷歌的Spanner，Spanner做到了真的强统一，这是目前我看到的惟一的强统一零碎，唯二是TDSQL。Spanner做到了线性统一加ACID数据一致性的交融，业界实际上早有这个概念叫做严格可串行化，它能在全局层面保障分布式系统下数据的一致性，这才是真的强统一（请留神，这里强调全局，即从任何一个节点看去读取数据，大家都能读到一样的后果，不可能不同节点取得不同的察看后果）。然而如果对Spanner做一个测试或者实践推导，会发现Spanner零碎的事务处理性能十分差。Spanner能用到什么中央？就是用到非实时性广告零碎数据的解决下面，然而大家据说过Spanner用到过金融零碎外面吗？没有，此种背景下，就对TDSQL形成新挑战了，因为TDSQL要用到金融零碎业务外面，咱们既要保障正确性，又要保障性能。而做分布式数据库还面临着做高并发执行器须要的技术MPP。从一开始咱们就提到了数据库基于硬件零碎搭建，受限于硬件，作为分布式数据库，还面临什么问题？咱们在钻研它和新硬件有什么关系，方才盖老师谈到了Oracle21c，21c做了长久化内存和数据库的联合，但它是单机的联合，而TDSQL要做和分布式系统的联合。比方晚期和SSD这样的硬件联合，当初和长久化内存、和RDMA联合，都是咱们在做的事件。所有这些事件都有一个外在的需要驱动，就是数据量的变动。数据量的变动有几个层面，第一个很重要，但大家可能并没有齐全感触到，就是元数据。对于一个分布式数据库系统来讲，元数据会剧增，也会对数据库提出一些新的挑战，不仅如此，数据库系统外面还有什么？咱们晓得大家都在谈AI for DB，这时AI零碎肯定须要大量的数据，这大量的数据就要有一个存储，有些零碎是把AI所需数据存储在数据库之外，而咱们在思考，是否存储在数据库之内？如果能又以什么模式存储？这都是作为分布式技术要钻研、思考的根底问题。三、基于HTAP的TDSQL强一致性技术实际所以分布式数据库蕴含了比拟多的内容：事务处理数据量的存储层面、计算层面等方面的问题，基于这些需要，咱们开展了根底钻研，做了TDSQL的HTAC零碎，外面蕴含多种多样内容。这是咱们零碎的根底架构图，它看起来像一个单机零碎，然而外面会有很多小的细节，能够看出其是一个分布式系统。在这个零碎里会蕴含多种多样的技术，其中外围的就是我方才谈到的和事务处理相干的——怎么保障强统一。而依据咱们的钻研，发现数据异样有无数个，无穷尽的货色，怎么去认知？这又造成新的挑战。TDSQL在做的一项工作事就是对数据异样归类，把数据异样分成无限的若干种，对它进行认知，基于这样的认知就能够定义什么叫隔离级别、什么叫一致性，怎么去影响、对待现有所有的并发拜访控制算法，怎么和分布式一致性去联合，这都是TDSQL在研的一些根底技术，也是方才谈到的一致性技术外面的根底内容。 ...

关于sql:自建Hive数据仓库跨版本迁移到阿里云Databricks数据洞察

简介：客户在IDC或者私有云环境自建Hadoop集群构建数据仓库和剖析零碎，购买阿里云Databricks数据洞察集群之后，波及到数仓数据和元数据的迁徙以及Hive版本的勘误更新。中转最佳实际：【自建Hive数据仓库跨版本迁徙到阿里云Databricks数据洞察】最佳实际频道：【最佳实际频道】这里有丰盛的企业上云最佳实际，从典型场景入门，提供一系列我的项目实际计划，升高企业上云门槛的同时满足您的需要！场景形容客户在IDC或者私有云环境自建Hadoop集群构建数据仓库和剖析零碎，购买阿里云Databricks数据洞察集群之后，波及到数仓数据和元数据的迁徙以及Hive版本的勘误更新。实际劣势全托管Spark集群免运维，节俭人力老本。Databricks数据洞察与阿里云其余产品（OSS、RDS、MaxCompute、EMR）进行深度整合，反对以这些产品为数据源的输出和输入。应用Databricks Runtime商业版引擎相比开源Spark性能有3-5倍的晋升。产品列表Databricks 数据洞察云服务器ECS文件存储HDFS对象存储OSS专有网络VPC业务架构中转最佳实际》》版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

关于sql:5天让你技能加满的王炸组合速来

简介：《实时数仓入门训练营》，实践与实际的摩擦，概念与案例的碰撞，从 0 到1 疾速上手，让本人技能加点，速来报名！随着数字化业务的扩张，企业的数据量出现爆发式增长，作为 “数据智能” 中必不可少的一环，数据仓库曾经成为企业数据倒退到肯定规模后必然提供的根底服务之一。不过，都 2021 年了，你还在应用过期的传统数仓？亦或是想动手先进的实时数仓，却苦于没有入门路径？机会来了！5 月 24 日，实时计算 Flink 版 + Hologres 组建 “王炸组合”，联合推出《实时数仓入门训练营》！由阿里云计算平台事业部研究员蒋晓伟出品，邀请阿里云研究员王峰、阿里云资深技术专家金晓军等阿里云专家作为讲课嘉宾，由浅入深全方位解析实时数仓的架构、场景、以及实操利用，7 门精品课程帮忙你 5 天工夫从小白成长为大牛！另外，实现打卡工作还有天猫精灵、Flink 定制 polo 衫、结营证书等礼品等你来拿！扫码立刻报名流动亮点一．超强嘉宾阵容《实时数仓入门训练营》由阿里云研究员蒋晓伟出品。阿里云研究员王峰、阿里云资深技术专家金晓军、阿里云高级产品专家刘一鸣等实时计算 Flink 版和 Hologres 的多名技术/产品一线专家齐上阵，合力搭建此次训练营的课程体系，精心打磨课程内容，直击当下同学们所遇到的痛点问题。二．超级干货内容零根底的同学不要愁，本次入门训练营只需 5 天工夫 7 门课，就能帮忙你实现从 0 到 1 疾速上手搭建实时数仓。以下是本系列课程的内容概括：不会是 ”望而生畏“。讲课嘉宾别离解说 Flink 与 Hologres 的架构与原理，以及数仓架构的演进，再深度解析如何降级到 Flink + Hologres 实时数仓。内容由浅入深，小白也能轻易了解！不只是 “略懂略懂”。技术专家手把手实操演示，例如 Flink SQL 上手示例，Flink 读写 Hologres 上手示例等；还会将日常开发中可能遇到的各种典型问题都一一解惑，例如开发 Flink SQL 过程中常见问题和解决办法，Hologres 常见性能问题剖析等。有问题咱就解决，回绝只懂皮毛！不再是 “夸夸其谈”。产品专家将从实时数仓演变史，到基于 Flink + Hologres 实时数仓举荐架构，再到营销剖析实时数仓实际，全方位讲授如何将实时数仓利用到实际，助力互联网的实时决策和精准营销。实时数仓自身再好，不会使用也不行！三．超棒结营礼品动动你的手指，实现 5 步打卡工作，Flink 定制 polo 衫或天猫精灵带回家！全副课程完结后还会有结营考试，帮忙你牢记课程中所学的常识，并在实践中实现疾速上手，让这所有干货不会成为 ”过眼云烟“。还能够间接支付由开发者社区与计算平台事业部联结独家颁发的结业证书（电子版）。至此，礼品 get！新技能 get！ ...

关于sql:Flink-on-Zeppelin-系列之Yarn-Application-模式支持

简介：Zeppelin 如何实现并应用 Yarn Application 模式。作者：章剑锋（简锋）去年 Flink Forward 在讲 Flink on Zeppelin 这个我的项目的将来时咱们谈到了对Application 模式的反对，明天就有一个好消息要通知大家，社区曾经实现了这一Feature，欢送大家退出 Flink on Zeppelin 的钉钉群（32803524），下载最新版来应用这个Feature。 GitHub 地址 https://github.com/apache/flink 欢送大家给 Flink 点赞送 star~ Application mode 是 Flink 1.11 之后引入的新的运行模式，所要解决的问题就是缩小客户端的压力，把用户的 main 函数运行在 JobManager 里而不是在用户客户端。这种模式是非常适合 Flink on Zeppelin 的，因为 Flink on Zeppelin 的客户端就是 Flink interpreter 过程，而 Flink interpreter 是一个 long running 的 main 函数，一直承受来自前端的命令，进行相应的操作（比方提交 Job，进行 Job 等等）。接下来咱们就要具体讲下 Zeppelin 如何实现了 Yarn Application 模式，以及如何应用这一模式。一、架构在讲 Yarn Application 模式架构的时候，咱们顺便来讲下 Flink on Zeppelin 的架构演变过程。 ...

关于sql:Flink-实时计算在微博的应用

简介：微博通过将 Flink 实时流计算框架跟业务场景相结合，在平台化、服务化方面做了很大的工作，在开发效率、稳定性方面也做了很多优化。咱们通过模块化设计和平台化开发，进步开发效率。微博机器学习研发核心数据计算负责人，高级零碎工程师曹富强为大家带来 Flink 实时计算在微博的利用介绍。内容包含： 1、微博介绍 2、数据计算平台介绍 3、Flink 在数据计算平台的典型利用 GitHub 地址 https://github.com/apache/flink 欢送大家给 Flink 点赞送 star~ 一、微博介绍本次给大家带来的分享是 Flink 实时计算在微博的利用。微博是中国当先的社交媒体平台，目前的日沉闷用户是 2.41 亿，月沉闷用户是 5.5 亿，其中移动用户占比超过了 94%。二、数据计算平台介绍1. 数据计算平台详情下图为数据计算平台的架构图。首先是调度，这块基于 K8s 和 Yarn 别离部署了实时数据处理的 Flink、Storm，以及用于离线解决的 SQL 服务。在集群之上，咱们部署了微博的 AI 平台，通过这个平台去对作业、数据、资源、样本等进行治理。在平台之上咱们构建了一些服务，通过服务化的形式去反对各个业务方。 1.实时计算这边的服务次要包含数据同步、内容去重、多模态内容了解、实时特色生成、实时样本拼接、流式模型训练，这些是跟业务关系比拟严密的服务。另外，还反对 Flink 实时计算和 Storm 实时计算，这些是比拟通用的根底计算框架。 2.离线这部分，联合 Hive 的 SQL，SparkSQL 构建一个 SQL 计算服务，目前曾经反对了微博外部绝大多数的业务方。数据的输入是采纳数仓、特色工程这些数据中台的组建，对外提供数据输入。整体上来说，目前咱们在线跑的实时计算的作业将近 1000 多个，离线作业超过了 5000 多个，每天解决的数据量超过了 3 PB。 2. 数据计算上面两张图是数据计算，其中一个是实时计算，另外一个是离线计算。实时计算次要包含实时的特色生成，多媒体特色生成和实时样本生成，这些跟业务关系比拟严密。另外，也提供一些根底的 flink 实时计算和 storm 实时计算。离线计算次要包含 SQL 计算。次要包含 SQL 的即席查问、数据生成、数据查问和表治理。表治理次要就是数仓的治理，包含表的元数据的治理，表的应用权限，还有表的上下游的血缘关系。 3. 实时特色如下图所示，咱们基于 Flink 和 Storm 构建了一个实时特色生成的服务。整体上来说，它会分为作业详情、输出源特色生成、输入和资源配置。用户依照咱们当时定义好的接口去开发特色生成的 UDF 就能够。其余的像输出、特色写入，都是平台主动提供的，用户只须要在页面上配置就好。另外，平台会提供输出数据源的监控、作业的异样监控、特色写入监控、特色读取监控等，这些都是主动生成的。 ...

关于sql:5月24日起每晚8点实时数仓入门训练营见

关于sql:深度解析PolarDB数据库并行查询技术

简介：随着数据规模的不断扩大，用户SQL的执行工夫越来越长，这不仅对数据库的优化能力提出更高的要求，并且对数据库的执行模式也提出了新的挑战。本文将介绍基于代价进行并行优化、并行执行的云数据库的并行查问引擎的关键问题和核心技术。作者 | 智邻起源 | 阿里技术公众号一背景随着数据规模的不断扩大，用户SQL的执行工夫越来越长，这不仅对数据库的优化能力提出更高的要求，并且对数据库的执行模式也提出了新的挑战。随着数据库在云上的蓬勃发展，越来越多的传统用户迁徙到云上，享受云上弹性扩大的红利，然而随着业务的疾速扩张，却发现即便动静减少了很多资源，但SQL的执行工夫还是越来越慢，并没有随着资源的投入达到预期的成果。不言而喻，尽管新增了很多资源，但这些资源并没用被充分利用，很多传统的商业数据库，如Oracle、SQL Server等都提供对并行查问引擎的反对，以充分利用系统资源，达到减速SQL执行的成果。本文次要介绍基于代价进行并行优化、并行执行的云数据库的并行查问引擎的关键问题和核心技术。二如何将查问并行起来对于一个类OLAP的查问，不言而喻的是它通常是对大批量数据的查问，数据量大意味着数据远大于数据库的内存容量，大部分数据可能无奈缓存到数据库的缓冲区中，而必须在查问执行时才动静加载到缓冲区中，这样就会造成大量IO操作，而IO操作又是最耗时的，因而首先要思考的就是如何能减速IO操作。因为硬件的限度，每次IO的耗时根本是固定的，尽管还有程序IO和随机IO的区别，但在SSD曾经流行的明天，两者的差别也在逐步靠近。那么还有没有其它形式能够减速IO呢? 显然并行IO是一个简单易行的办法，如果多个线程能够同时发动IO，每个线程只读取局部数据，这样就能够疾速的将数据读到数据库的缓冲区中。并行读取数据的示意如上图所示，每个worker代表一个线程，如果数据曾经有partition分区，能够每个线程读取一个partition；也能够将全副数据按固定大小进行分片，比方按一个数据页面大小，而后每个线程以Round-robin模式轮询读取一个分片。这里须要留神的是，按已有partition调配给不同worker可能会导致每个worker解决的数据不平均，而按Round-robin模式进行轮询，如果分片设置的比拟小，相对来说就比拟容易做到每个worker解决的数据比拟平均。如果只是将数据读取到缓冲区中，而不是立刻进行后续解决，那么这些数据就会因缓冲区爆满导致数据被换出，从而失去减速IO的意义。因而，在并行读取数据的同时，必须同时并行的解决这些数据，这是并行查问减速的根底。传统的优化器只能生成串行的执行打算，为了实现并行读取数据，同时并行处理数据，首先必须对现有的优化器进行革新，让优化器能够生成咱们须要的并行打算。比方抉择哪个表或哪些表能够并行读取，并且通过并行读取会带来足够的收益；或者哪些操作能够并行执行，并且能够带来足够的收益。并不是说并行化革新肯定会有收益，比方对一个数据量很小的表，可能只是几行，如果也对它进行并行读取的话，并行执行所须要的多线程构建再加上线程间的数据同步等所须要的代价可能远大于所失去的收益，总体来说，并行执行会须要更多的资源和工夫，这就得失相当了。因而查问打算的并行化必须是基于代价的，否则可能会导致更重大的性能进化问题。三如何抉择并行扫描的表抉择并行扫描的表是生成并行打算的重要根底，通过基于并行扫描代价的计算和比拟，抉择能够并行扫描的表作为候选，是并行执行打算迭代的第一步。基于新的并行代价，兴许会有更优的JOIN程序抉择，尤其是当参加JOIN的表的数量比拟多时，这须要更多额定的迭代空间，为避免优化过程耗费太多的工夫，放弃原有打算的JOIN程序是一个不错的抉择。另外，对于参加JOIN的每张表，因为表的拜访办法不同，比方全表扫描、Ref索引扫描，Range索引扫描等，这些都会影响到最终并行扫描的代价。通常咱们抉择最大的那张表作为并行表，这样并行扫描的收益最大，当然也能够抉择多个表同时做并行扫描，前面会持续探讨更简单的状况。上面以查问年度生产TOP 10的用户为例： SELECT c.c_name, sum(o.o_totalprice) as s FROM customer c, orders o WHERE c.c_custkey = o.o_custkey AND o_orderdate >= '1996-01-01' AND o_orderdate <= '1996-12-31' GROUP BY c.c_name ORDER BY s DESC LIMIT 10;其中orders表为订单表，数据很多，这类表也被称之为事实表，customer表为客户表，数据绝对较少，这类表也被称之为维度表。那么此SQL的并行执行打算如下图所示：从打算中能够看出orders表会做并行扫描，由32个workers线程来执行，每个worker只扫描orders表的一部分数据分片，而后与customer表按o_custkey做index lookup进行JOIN，JOIN的后果发送到一个collector组件，而后由collector组件持续做后续的GROUP BY、ORDER BY及LIMIT操作。四抉择多表并行的JOIN将一张表做并行扫描之后，就会想为什么只能抉择一张表？如果SQL中有2张或更多的FACT表，能不能能够将FACT表都做并行扫描呢？答案是当然能够。以上面SQL为例： SELECT o.o_custkey, sum(l.l_extendedprice) as s FROM orders o, lineitem l WHERE o.o_custkey = l.l_orderkey GROUP BY o.o_custkey ORDER BY s LIMIT 10;其中orders表和lineitem表都是数据量很大的事实表，此SQL的并行执行打算如下图所示： ...

关于sql:如何从-0-到-1-开发-PyFlink-API-作业

简介：以 Flink 1.12 为例，介绍如何应用 Python 语言，通过 PyFlink API 来开发 Flink 作业。 Apache Flink 作为以后最风行的流批对立的计算引擎，在实时 ETL、事件处理、数据分析、CEP、实时机器学习等畛域都有着宽泛的利用。从 Flink 1.9 开始，Apache Flink 社区开始在原有的 Java、Scala、SQL 等编程语言的根底之上，提供对于 Python 语言的反对。通过 Flink 1.9 ～ 1.12 以及行将公布的 1.13 版本的多个版本的开发，目前 PyFlink API 的性能曾经日趋完善，能够满足绝大多数状况下 Python 用户的需要。接下来，咱们以 Flink 1.12 为例，介绍如何应用 Python 语言，通过 PyFlink API 来开发 Flink 作业。内容包含：环境筹备作业开发作业提交问题排查总结GitHub 地址 https://github.com/apache/flink 欢送大家给 Flink 点赞送 star~ 环境筹备第一步：装置 PythonPyFlink 仅反对 Python 3.5+，您首先须要确认您的开发环境是否已装置了 Python 3.5+，如果没有的话，首先须要装置 Python 3.5+。第二步：装置 JDK咱们晓得 Flink 的运行时是应用 Java 语言开发的，所以为了执行 Flink 作业，您还须要装置 JDK。Flink 提供了对于 JDK 8 以及 JDK 11 的全面反对，您须要确认您的开发环境中是否曾经装置了上述版本的 JDK，如果没有的话，首先须要装置 JDK。 ...

关于sql:Apache-Flink-Meetup113-新版本发布-x-互娱场景实践分享的开发者盛筵

简介： Flink 1.13 版本新性能的深刻解读+Flink 在互娱行业典型实际利用。对于宽广的 Flink 开发者同学来说，什么内容是最期待的？什么信息又是最有用的？最期待的内容，天然是 Flink 1.13 新版本的公布，全新性能的上线！最有用的信息，天然是实践联合企业实际的案例分享！更刺激的是！将这两者相结合能碰撞出怎么的火花？ Apache Flink 社区 1.13 新版本公布 Meetup 来啦！ 5月22日 | 北京 | 线下 1.13 新版本 + 互娱场景实际分享，不容错过的开发者盛筵！本次 Meetup 分为高低两场，嘉宾别离来自阿里巴巴、字节跳动、快手、爱奇艺和小红书。上半场将由 4 位技术专家带来 Flink 1.13 版本新性能的深刻解读。例如 Winddow TVF，DataStream & Table API 交互等；下半场将另有 4 位资深行业技术专家分享 Flink 在互娱行业中的实际利用。全方位解析包含精准举荐、实时数仓、数据分析等在内的行业面临的典型问题。【流动亮点】超多实用干货，一方面第一工夫 get 到 1.13 版本新 feature 和性能晋升；另一方面也能够学习到如何摸索 Flink 在互娱场景中的实际利用，包含精准举荐，实时数仓等，从实践走向实战；流动模式多样化，线下线上同步开启，同城可参加线下 Meetup 面对面交换，异地也可在线观看直播，精彩内容不错过；丰盛周边等你拿，报名加入就有机会取得超多 Flink 社区定制的精美周边！▼ 立刻报名 ▼ https://1712399719478.huodongxing.com/event/1594531547711 嘉宾及议题介绍王峰｜阿里巴巴研究员出品人简介： ...

关于sql:Flink-在唯品会的实践

简介：Flink 在唯品会的容器化实际利用以及产品化教训。唯品会自 2017 年开始基于 k8s 深刻打造高性能、稳固、牢靠、易用的实时计算平台，反对唯品会外部业务在平时以及大促的安稳运行。现平台反对 Flink、Spark、Storm 等支流框架。本文次要分享 Flink 的容器化实际利用以及产品化教训。内容包含：倒退概览Flink 容器化实际Flink SQL 平台化建设利用案例将来布局GitHub 地址 https://github.com/apache/flink 欢送大家给 Flink 点赞送 star~ 一、倒退概览平台反对公司外部所有部门的实时计算利用。次要的业务包含实时大屏、举荐、试验平台、实时监控和实时数据荡涤等。 1.1 集群规模平台现有异地双机房双集群，具备 2000 多的物理机节点，利用 k8s 的 namespaces，labels 和 taints 等，实现业务隔离以及初步的计算负载隔离。目前线上实时利用有大略 1000 个，平台最近次要反对 Flink SQL 工作的上线。 1.2 平台架构上图是唯品会实时计算平台的整体架构。最底层是计算工作节点的资源调度层，理论是以 deployment 的模式运行在 k8s 上，平台尽管反对 yarn 调度，然而 yarn 调度是与批工作共享资源，所以支流工作还是运行在 k8s 上。存储层这一层，反对公司外部基于 kafka 实时数据 vms，基于 binlog 的 vdp 数据和原生 kafka 作为音讯总线，状态存储在 hdfs 上，数据次要存入 redis，mysql，hbase，kudu，clickhouse 等。计算引擎层，平台反对 Flink，Spark，Storm 支流框架容器化，提供了一些框架的封装和组件等。每个框架会都会反对几个版本的镜像满足不同的业务需要。平台层提供作业配置、调度、版本治理、容器监控、job 监控、告警、日志等性能，提供多租户的资源管理（quota，label 治理），提供 kafka 监控。在 Flink 1.11 版本之前，平台自建元数据管理系统为 Flink SQL 治理 schema，1.11 版本开始，通过 hive metastore 与公司元数据管理系统交融。最上层就是各个业务的应用层。 ...

关于sql:贝壳基于-Flink-的实时计算演进之路

简介：贝壳找房在实时计算之路上的平台建设以及实时数仓利用。摘要：贝壳找房大数据平台实时计算负责人刘力云带来的分享内容是贝壳找房的实时计算演进之路，内容如下：倒退历程平台建设实时数仓及其利用场景事件驱动场景将来布局GitHub 地址 https://github.com/apache/flink 欢送大家给 Flink 点赞送 star~ 一、倒退历程首先是平台的倒退历程。最早是因为业务方在实时计算方面有比拟多的业务场景，包含业务方自研的实时工作，须要自行开发、部署及保护，咱们的大数据部门也会承接客户大数据的实时开发需要。这些看起来都是一些烟囱式的开发架构（即每个业务线之间由不同的开发团队独立建设，技术栈不同，互不分割），不足对立的工作管控，也很难保留开发过程中积攒的技术积淀。因而，咱们在 18 年时上线了基于 Spark Streaming 的实时计算平台，对立部署治理实时计算工作。之后咱们又在此基础上提供了工作开发性能 - 标准化的 SQL 语言（SQL 1.0），以进步数据开发效率。随着咱们承接的工作越来越多，咱们也发现了 Spark Streaming 的一些应用问题，次要是其 Checkpoint 是同步的，有时会造成比拟大的提早。此外，Kafka 生产的 Offset 数据存在 Checkpoint，很难做到工作细粒度的监控，比方生产状态的获取，于是咱们开始转向 Flink。 19 年，咱们的平台开始反对 Flink 工作，并且很快提供了基于 Flink 1.8 的 SQL 2.0 性能，包含 DDL 定义和维表关联。接下来，在 SQL 2.0 的根底上，咱们开始了实时数仓的建设。今年初，在收集了业务方的需要场景后，咱们认为在实时事件处理方面需要明确，而且目前的实现也存在较多的弊病，因而咱们开始着手事件处理平台的开发。往年公布的 Flink 1.11 在 SQL 方面有很大的晋升，咱们在其根底上正在开发一套对立的 SQL（3.0）。目前平台反对的部门涵盖了贝壳绝大部分的业务方，反对各种场景，包含人店相干的房源、客源、经纪人、风控以及经营等。目前平台反对的我的项目有 30 多个。在 SQL2.0 后，平台上的工作数有显著增长，达到 800 多个。因为贝壳所有的流量数据、用户行为剖析、以及数仓的建设都是通过平台来构建的，所以数据量很大，每天解决的音讯达 2500 亿条，单任务的音讯吞吐量峰值达 3 百万。 ...

关于sql:DataWorks搬站方案Airflow作业迁移至DataWorks

简介：DataWorks提供工作搬站性能，反对将开源调度引擎Oozie、Azkaban、Airflow的工作疾速迁徙至DataWorks。本文次要介绍如何将开源Airflow工作流调度引擎中的作业迁徙至DataWorks上DataWorks提供工作搬站性能，反对将开源调度引擎Oozie、Azkaban、Airflow的工作疾速迁徙至DataWorks。本文次要介绍如何将开源Airflow工作流调度引擎中的作业迁徙至DataWorks上。反对迁徙的Airflow版本Airflow反对迁徙的版本：python >= 3.6.x airfow >=1.10.x 整体迁徙流程迁徙助手反对开源工作流调度引擎到DataWorks体系的大数据开发工作迁徙的根本流程如下图示。针对不同的开源调度引擎，DataWorks迁徙助手会出一个相干的工作导出计划。整体迁徙流程为：通过迁徙助手调度引擎作业导出能力，将开源调度引擎中的作业导出；再将作业导出包上传至迁徙助手中，通过工作类型映射，将映射后的作业导入至DataWorks中。作业导入时可设置将工作转换为MaxCompute类型作业、EMR类型作业、CDH类型作业等。 Airflow作业导出导出原理介绍：在用户的Airflow的执行环境外面，利用Airflow的Python库加载用户在Ariflow上调度的dag folder（用户本人的dag python文件所在目录）。导出工具在内存中通过Airflow的Python库去读取dag的外部工作信息及其依赖关系，将生成的dag信息通过写入json文件导出。具体的执行命令可进入迁徙助手->工作上云->调度引擎作业导出->Airflow页面中查看。 Airflow作业导入拿到了开源调度引擎的导出工作包后，用户能够拿这个zip包到迁徙助手的迁徙助手->工作上云->调度引擎作业导入页面上传导入包进行包剖析。导入包剖析胜利后点击确认，进入导入工作设置页面，页面中会展现剖析进去的调度工作信息。开源调度导入设置用户能够点击高级设置，设置Airflow工作与DataWorks工作的转换关系。不同的开源调度引擎，在高级设置外面的设置界面基本一致如下。高级设置项介绍： sparkt-submit转换为：导入过程会去剖析用户的工作是不是sparkt-submit工作，如果是的话，会将spark-submit工作转换为对应的DataWorks工作类型，比如说：ODPS\_SPARK/EMR\_SPARK/CDH\_SPARK等命令行 SQL工作转换为：开源引擎很多工作类型是命令行运行SQL，比如说hive -e, beeline -e, impala-shell等等，迁徙助手会依据用户抉择的指标类型做对应的转换。比方能够转换成ODPS\_SQL, EMR\_HIVE, EMR\_IMPALA, EMR\_PRESTO, CDH\_HIVE, CDH\_PRESTO, CDH\_IMPALA等等指标计算引擎类型：这个次要是影响的是Sqoop同步的目标端的数据写入配置。咱们会默认将sqoop命令转换为数据集成工作。计算引擎类型决定了数据集成工作的目标端数据源应用哪个计算引擎的project。Shell类型转换为：SHELL类型的节点在Dataworks依据不同计算引擎会有很多种，比方EMR\_SHELL，CDH\_SHELL，DataWorks本人的Shell节点等等。未知工作转换为：对目前迁徙助手无奈解决的工作，咱们默认用一个工作类型去对应，用户能够抉择SHELL或者虚节点VIRTUALSQL节点转换为：DataWorks上的SQL节点类型也因为绑定的计算引擎的不同也有很多种。比方 EMR\_HIVE，EMR\_IMPALA、EMR\_PRESTO，CDH\_HIVE，CDH\_IMPALA，CDH\_PRESTO，ODPS\_SQL，EMR\_SPARK\_SQL，CDH\_SPARK\_SQL等，用户能够抉择转换为哪种工作类型。留神：这些导入映射的转换值是动态变化的，和以后我的项目空间绑定的计算引擎无关，转换关系如下。导入至DataWorks + MaxCompute设置项可选值sparkt-submit转换为ODPS_SPARK命令行 SQL工作转换为ODPS_SQL、ODPS_SPARK_SQL指标计算引擎类型ODPSShell类型转换为DIDE_SHELL未知工作转换为DIDE_SHELL、VIRTUALSQL节点转换为ODPS_SQL、ODPS_SPARK_SQL### 导入至DataWorks + EMR设置项可选值sparkt-submit转换为EMR_SPARK命令行 SQL工作转换为EMR_HIVE, EMR_IMPALA, EMR_PRESTO, EMR_SPARK_SQL指标计算引擎类型EMRShell类型转换为DIDE_SHELL, EMR_SHELL未知工作转换为DIDE_SHELL、VIRTUALSQL节点转换为EMR_HIVE, EMR_IMPALA, EMR_PRESTO, EMR_SPARK_SQL### 导入至DataWorks + CDH设置项可选值sparkt-submit转换为CDH_SPARK命令行 SQL工作转换为CDH_HIVE, CDH_IMPALA, CDH_PRESTO, CDH_SPARK_SQL指标计算引擎类型CDHShell类型转换为DIDE_SHELL未知工作转换为DIDE_SHELL、VIRTUALSQL节点转换为CDH_HIVE, CDH_IMPALA, CDH_PRESTO, CDH_SPARK_SQL## 执行导入设置完映射关系后，点击开始导入即可。导入实现后，请进入数据开发中查看导入后果。 ## 数据迁徙大数据集群上的数据迁徙，可参考：DataWorks数据集成或MMA。工作上云具体文档：https://help.aliyun.com/document\_detail/181296.html > 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

关于sql:DataWorks搬站方案Azkaban作业迁移至DataWorks

简介：DataWorks迁徙助手提供工作搬站性能，反对将开源调度引擎Oozie、Azkaban、Airflow的工作疾速迁徙至DataWorks。本文次要介绍如何将开源Azkaban工作流调度引擎中的作业迁徙至DataWorks上。DataWorks迁徙助手提供工作搬站性能，反对将开源调度引擎Oozie、Azkaban、Airflow的工作疾速迁徙至DataWorks。本文次要介绍如何将开源Azkaban工作流调度引擎中的作业迁徙至DataWorks上。反对迁徙的Azkaban版本反对全副版本的Azkaban迁徙。整体迁徙流程迁徙助手反对开源工作流调度引擎到DataWorks体系的大数据开发工作迁徙的根本流程如下图所示。针对不同的开源调度引擎，DataWorks迁徙助手会出一个相干的工作导出计划。整体迁徙流程为：通过迁徙助手调度引擎作业导出能力，将开源调度引擎中的作业导出；再将作业导出包上传至迁徙助手中，通过工作类型映射，将映射后的作业导入至DataWorks中。作业导入时可设置将工作转换为MaxCompute类型作业、EMR类型作业、CDH类型作业等。 Azkaban作业导出Azkaban工具自身具备导出工作流的能力，有本人的Web控制台，如下图所示： Azkaban界面反对间接Download某个Flow。Flow的导出流程：操作步骤： 1.进入Project页面 2.点击Flows，会列出Project上面所有的工作流(Flow) 3.点击Download即可下载Project的导出文件 Azkaban导出包格局原生Azkaban即可，导出包Zip文件外部为Azakaban的某个Project的所有工作(Job)和关系信息。 Azkaban作业导入拿到了开源调度引擎的导出工作包后，用户能够拿这个zip包到迁徙助手的迁徙助手->工作上云->调度引擎作业导入页面上传导入包进行包剖析。导入包剖析胜利后点击确认，进入导入工作设置页面，页面中会展现剖析进去的调度工作信息。开源调度导入设置用户能够点击高级设置，设置Azkaban工作与DataWorks工作的转换关系。不同的开源调度引擎，在高级设置外面的设置界面基本一致，如下图：高级设置项介绍： sparkt-submit转换为：导入过程会去剖析用户的工作是不是sparkt-submit工作，如果是的话，会将spark-submit工作转换为对应的DataWorks工作类型，比如说：ODPS\_SPARK/EMR\_SPARK/CDH\_SPARK等命令行 SQL工作转换为：开源引擎很多工作类型是命令行运行SQL，比如说hive -e, beeline -e, impala-shell等等，迁徙助手会依据用户抉择的指标类型做对应的转换。比方能够转换成ODPS\_SQL, EMR\_HIVE, EMR\_IMPALA, EMR\_PRESTO, CDH\_HIVE, CDH\_PRESTO, CDH\_IMPALA等等指标计算引擎类型：这个次要是影响的是Sqoop同步的目标端的数据写入配置。咱们会默认将sqoop命令转换为数据集成工作。计算引擎类型决定了数据集成工作的目标端数据源应用哪个计算引擎的project。Shell类型转换为：SHELL类型的节点在Dataworks依据不同计算引擎会有很多种，比方EMR\_SHELL，CDH\_SHELL，DataWorks本人的Shell节点等等。未知工作转换为：对目前迁徙助手无奈解决的工作，咱们默认用一个工作类型去对应，用户能够抉择SHELL或者虚节点VIRTUALSQL节点转换为：DataWorks上的SQL节点类型也因为绑定的计算引擎的不同也有很多种。比方 EMR\_HIVE，EMR\_IMPALA、EMR\_PRESTO，CDH\_HIVE，CDH\_IMPALA，CDH\_PRESTO，ODPS\_SQL，EMR\_SPARK\_SQL，CDH\_SPARK\_SQL等，用户能够抉择转换为哪种工作类型。留神：这些导入映射的转换值是动态变化的，和以后我的项目空间绑定的计算引擎无关，转换关系如下。导入至DataWorks + MaxCompute设置项可选值sparkt-submit转换为ODPS_SPARK命令行 SQL工作转换为ODPS_SQL、ODPS_SPARK_SQL指标计算引擎类型ODPSShell类型转换为DIDE_SHELL未知工作转换为DIDE_SHELL、VIRTUALSQL节点转换为ODPS_SQL、ODPS_SPARK_SQL### 导入至DataWorks + EMR设置项可选值sparkt-submit转换为EMR_SPARK命令行 SQL工作转换为EMR_HIVE, EMR_IMPALA, EMR_PRESTO, EMR_SPARK_SQL指标计算引擎类型EMRShell类型转换为DIDE_SHELL, EMR_SHELL未知工作转换为DIDE_SHELL、VIRTUALSQL节点转换为EMR_HIVE, EMR_IMPALA, EMR_PRESTO, EMR_SPARK_SQL### 导入至DataWorks + CDH设置项可选值sparkt-submit转换为CDH_SPARK命令行 SQL工作转换为CDH_HIVE, CDH_IMPALA, CDH_PRESTO, CDH_SPARK_SQL指标计算引擎类型CDHShell类型转换为DIDE_SHELL未知工作转换为DIDE_SHELL、VIRTUALSQL节点转换为CDH_HIVE, CDH_IMPALA, CDH_PRESTO, CDH_SPARK_SQL## 执行导入设置完映射关系后，点击开始导入即可。导入实现后，请进入数据开发中查看导入后果。 ## 数据迁徙大数据集群上的数据迁徙，可参考：DataWorks数据集成或MMA。工作上云具体文档：https://help.aliyun.com/document\_detail/181296.html> 版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。

关于sql:汽车之家基于-Flink-的数据传输平台的设计与实践

简介：数据接入与传输作为买通数据系统与业务零碎的一道桥梁，是数据系统与架构中不可或缺的一个重要局部。数据传输零碎稳定性和准确性，间接影响整个数据系统服务的 SLA 和品质。此外如何晋升零碎的易用性，保障监控服务并升高系统维护老本，优雅应答劫难等问题也非常重要。数据接入与传输作为买通数据系统与业务零碎的一道桥梁，是数据系统与架构中不可或缺的一个重要局部。数据传输零碎稳定性和准确性，间接影响整个数据系统服务的 SLA 和品质。此外如何晋升零碎的易用性，保障监控服务并升高系统维护老本，优雅应答劫难等问题也非常重要。本文介绍了汽车之家实时计算团队利用 Flink 和 Flink 实时平台构建数据传输 SDK 和传输平台并不断完善的实践经验与总结。内容包含：背景与需要技术选型与设计 —— Why Flink?数据传输零碎的设计架构基于 Flink 的 Binlog 接入 SDK平台应用总结与瞻望一、背景与需要汽车之家（下称之家）作为一家数据智能驱动的公司，人造存在着对数据的各种简单需要，之家的数据系统负责撑持这些业务需要的发展。数据传输零碎，作为其中一环，承当了各类数据导入散发的需要，反对用户订阅数据变更。随着撑持的业务扩增与需要的减少。原来的接入零碎暴露出了肯定的问题和有余：不足无效的工作与信息管理机制，依赖人工进行工作的治理和运维，信息的统计接入程序资源应用节约，不足弹性针对 DDL 变更问题，不能很好的解决，必要时须要人工染指传输零碎依赖的组件比拟多，比方 Zookeeper，Redis 等代码的技术债累积，代码保护老本变高针对上述问题，咱们决定开发一套新的数据传输和散发零碎，一举解决上述问题。二、技术选型与设计 —— Why Flink?在发展新零碎的开发工作之前，咱们剖析的可选的计划思路大体分三种: 齐全自研（相似于 otter）复用市面上的开源组件(Maxwell/Canal/Debezium)进行二次开发和整合基于 Flink 进行组件的开发咱们规约出以下次要设计应用指标：架构设计上要运维治理是敌对的，提供高可用以及故障复原策略，反对异地多活架构设计上要提供强数据准确性，至多承诺 at-least-once 语义架构设计上要对扩缩容是敌对的，能够按需分配资源功能设计上要全面的监控笼罩和欠缺的报警机制，反对元数据信息管理功能设计上要对实时计算是敌对的(1)功能设计上要能齐全进攻 DDL 变更带来的问题此外，在性能指标上，接入零碎的延时和吞吐至多要满足所有业务惯例状态下的需要。 (1) 指与实时计算平台整合的能力方案设计与比照按照设计思路和指标，咱们整顿了计划次要性能的比照表格： (1)Flink 自带高可用和故障复原，实时计算平台在此基础上提供更强的高可用服务 (2)良好的编码 + flink 机制即可实现 Exactly-Once (3)实时计算平台自带工作部署治理能力 (4)实时计算平台自带齐备的监控和治理通过探讨，大家统一决定基于Flink进行新的传输平台的开发： Flink DataStream 的编程模型和 API 在应答数据传输场景上，十分的天然与间接Flink 在框架层面提供了一致性保障和 HA/稳定性/流量控制措施，让咱们能够不用去解决这些开发上比拟艰难和简单的问题，背靠框架即可较为轻松地实现相干工作Flink 人造具备横向纵向扩容的能力，按需应用计算资源即可齐全复用了之家 Flink 实时计算平台已有的组件和能力——齐备的监控报警/工作生命周期治理/异地多活/自助运维等性能咱们的 MVP 版本开发实现大概只破费了不到 3 周的工夫，POC 的后果完全符合预期的性能要求和性能要求。三、数据传输零碎的设计架构从逻辑层面来看，之家的实时数据传输平台分为 3 局部： ...

关于sql:刹车失灵数据是否也会刹车失灵

最近上海车展中，特斯拉车主维权事件闹得满城风雨。事件次要争议点在于：车主示意行车时无奈刹车要求维权，特斯拉回绝提供维权人的行车数据或用其余模式证实非产品质量问题，从而引发的争议。作为吃瓜大众的一员，试问如果产品质量没问题，数据不心虚，特斯拉为什么不提供相干数据证实本身清白？再者汽车用户本人的行车隐衷数据为什么不属于本人？特斯拉高管明确示意的“无奈斗争”，如此没有依据且漠视人命的“无奈斗争”到底是哪里来的底气？车企又当运动员又当裁判员，智能汽车的数据监管何时能力跟上？？由上述事件不禁联想到整个 IT 行业的“数据刹车失灵”，微盟事件、链家事件等造成的重大问题，仿佛更加不足为奇，那么作为古代企业，到底怎样才能刹住数据的车呢？？数据的刹车是什么？首先解释一下刹车。刹车：艰深来讲就是指把运行中的车强制进行或升高速度的一种安装。数据运行的刹车大抵也类似，试想你治理着一个宏大的数据库集群运行，当初有很多开发测试人员正在操作运行着这些数据，但做为数据库管理员的你意识到目前可能会呈现数据泄露问题，请问怎样才能让数据疾速刹车呢？答案：登录管制。禁掉所有用户与数据库之间的连贯，让用户无奈登录数据查问操作系统，那数据的运行就会停下来。请看对立数据管控工具 CloudQuery 的实际案例：可通过锁定用户的登录账号和明码暂停数据的运行，这样即便有数百位用户操作数据，管理员都能够一个点击把刹车踩到底，顷刻间进行任何人对数据的任何操作。数据刹车应该有 ABS 防抱死零碎！数据在刹车时紧急制动是必要的，然而尽量不要常常应用，因为一旦紧急制动，车轮被锁死，行车的方向就不好管制，会给企业运行带来重大影响。那么如果排查问题发现数据异样时，能不能尽快尽量放大排查范畴，粗略定位到较小的范畴中呢？答案：能够。例如当系统管理员给予了用户「增加连贯」「审计剖析」的零碎权限后，发现此用户增加连贯时不能高效治理或者正在大量导出审计剖析数据时，系统管理员就能够启动数据的「ABS 防抱死零碎」，暂停此类用户对系统的操作权限，让数据的行车方向虽略有摆动，但仍能放弃零碎整体方向稳固。实际案例请看下图：这样能够保障在零碎运行不受大范畴烦扰的状况下，采纳点刹的形式踩住数据运行的刹车。数据的刹车力度须要有精准的管制！咱们晓得，行车过程中如遇到冰雪路段，毫厘之差的刹车力度也会影响到行车平安，就算经验丰富的老司机，也很难精准管制刹车力度，百分之百保障行车平安。那么如果是对数据的精准刹车，则更是难上加难，略微多一点或少一点的刹车力度，就可能意味着企业的损失或业务的停滞。那么能不能做到最精准的刹车管制呢？怎样才能做到？答案：能够。如果用户对于数据的操作权限是在十分精准粗疏的范畴内，如准确到某一连贯的某一数据库的某一个具体的表，一旦发现某一用户的操作有潜在危险时，就能够立刻发出此用户对该数据的具体操作权限。以下是 CloudQuery 的实际案例：例如上图中，调配给某用户的 MySQL_001 连贯中 infromation_schema 数据库中查看和插入表的权限，如果想要发出，一键点击即可。如何查看数据的行车记录？正如再好的刹车零碎也挡不住碰瓷一样。当数据运行时可能会呈现一些过后没发现但却随着工夫而暴露出的重大问题。那么作为数据运行的管理者，咱们如果想定期审计用户在零碎内执行的所有 SQL 来确保数据稳固，是否能够实现？怎样才能实现呢？答案：能够。CloudQuery 将会审计在零碎内所有用户执行过的 SQL 并保留数据。（将来将会审计所有）所有的用户在 CloudQuery 零碎内所执行的所有 SQL 语句将会都被记录。管理员能够在审计剖析界面随时查看用户所执行的语句和操作。数据行车过程中被删，是否有备份、可立即复原？假如数据正在运行过程中遭逢极其状况，例如所有数据被黑客全副删除，那么咱们零碎中是否有备份？可能立即复原呢？答案：能够。如图所示，你能够在 opt/cloudquery/backup 目录中找到本人定期备份的数据；能够在雷同或不同 CloudQuery 部署节点复原正本。结语：无论是车辆的刹车零碎，还是数据的刹车零碎，作为关键时刻救命的货色，无论何时都是重中之重。不管做汽车还是做软件产品，弱小的性能和技术当然是咱们独特谋求的，但生命和平安必须要放在所有技术和性能之上，容不得半点马虎。对立数据库管控工具 CloudQuery 官网地址：https://cloudquery.club/

关于sql:利用RDS-MySQL数据库云开发ToDo-List

简介场景介绍基于云开发平台、Midway FaaS 和云数据库RDS MySQL 版疾速开发一个 Todo List。背景常识体验实验室开发者通过场景化试验把握云计算的what和how。收费云资源，实在云环境，丰盛实际场景地址：https://developer.aliyun.com/... 什么是云开发平台？云开发平台是阿里云所提供的一站式、全云端的开发平台，关上浏览器就能够开发、调试、上线。点击进入云开发平台。什么是Midway FaaS？一个用于构建 Node.js 云函数的 Serverless 框架，帮忙开发者专一于产品开发，升高保护老本。欢送 Star! https://github.com/midwayjs/m... RDS数据库阿里云关系型数据库RDS（Relational Database Service）是一种稳固牢靠、可弹性伸缩的在线数据库服务，提供容灾、备份、复原、迁徙等方面的全套解决方案，彻底解决数据库运维的懊恼。创立利用1.登录云开发平台。关上网址https://workbench.aliyun.com/... 2.创立利用。关上疾速开始 https://workbench.aliyun.com/... 3.云资源拜访受权。如果您之前没有应用过云开发平台，会呈现云资源受权治理的选项，往下拉呈现直至批准受权的字样，点击「批准受权」后呈现受权胜利，点击进入「下一步」批准受权并显示受权胜利后点击下一步。4.创立利用模板。别离抉择开发语言NodeJS，通过模版创立。点击官网模版，抉择Midway Serverless MySQL数据库示例利用模板，如图所示。5.填写利用根本信息。按图示填写利用的名称和利用介绍、计算服务。没有产品可选点击旁边的主动创立产品线就会呈现一个上海区域的产品了。信息填写实现后点击下一步。6.云服务治理。查看利用依赖的云服务的开明状况，未开明的服务右键点击立刻开明，在新标签关上所有服务开明页，依据提醒一一开明。开明后利用卡片环境治理前面的小图标全副变成绿色的已开明对勾形态，才算实现利用的创立。部署利用上一节曾经创立好了利用，本节介绍对利用进行开发部署流程。1.进入开发。利用创立好当前会跳转到利用详情页，点击利用详情页上的 [开发部署] 进入CloudIDE开发界面。2.装置依赖。点击 [终端]，而后在终端输入框中输出以下命令 npm i 装置依赖。依赖蕴含的包比拟多，全副下载须要一点工夫，急躁期待即可，加载结束后，能够看见以下图片中的提醒。 npm i 3.进行部署。点击CloudIDE中的 [部署tab栏]，而后点击 [部署] 开始部署。4.确认部署信息。在弹出框中弹出的是该利用默认配置的数据库信息，不须要进行配置。如果长期应用配置本人的数据库，能够依照后续 “数据库设置”一节进行操作。点击[持续部署] 进入部署阶段。5.日常环境部署胜利。日常环境部署胜利后如下图所示，能够应用附件中标注的长期域名进行拜访测试。6.长期域名拜访。复制生成的长期域名进行拜访，能够进入Todo list web利用界面。如果集体利用须要发到线上，绑定集体线上域名持续在「线上环境」部署即可Todolist web利用界面显示的待办事项都是存储在默认配置好的数据库的数据库表中，将在后续 “数据库设置”一节中进行阐明。下线利用函数计算弹性实例相干的云资源有肯定的收费额度，额度耗费实现后会按量付费。如果不须要保留利用，请及时操作下线，免得产生不必要的费用，在该利用治理页面点击下线即可。数据库设置后面的章节应用的是利用内提供的的收费默认数据库，数据库配置有两种形式，一种是在开发平台设置，另外一种是在CloudIDE中进行配置，上面将别离介绍。 1.在云开发平台中设置。 a) 在利用详情中，点击 [开发部署] ，而后再次点击[利用配置]关上配置页面。在利用开发中，通常要应用一些敏感的信息去进行数据相干的操作，比方数据库连贯信息、鉴权相干信息等等。如果将这些信息间接 hardcode 写在代码里，会带来潜在的因为代码透露而造成敏感信息跟着被透露的危险。为了升高这种危险，云开发平台举荐应用「环境变量」的形式来代替 hardcode 的做法。b）批改环境变量。因为本我的项目设置了默认的环境变量，所以能够看见曾经创立好了的数据库连贯信息，您能够在该界面将数据库连贯信息批改为您本人的RDS数据库，或者能够依据您本人的需要来创立其余的环境变量。默认环境变量阐明： MIDWAY_RDS_HOST RDS 数据库连贯地址MIDWAY_RDS_PORT RDS 数据库连贯端口MIDWAY_RDS_DBNAME RDS 数据库名称MIDWAY_RDS_USERNAME RDS 数据库账户名称MIDWAY_RDS_PASSWORD RDS 数据库账户明码 ...

关于sql:SP21-COMPSCI-Memory-Allocator

DashboardSP21 COMPSCI 354 003Available Apr 19 at 12am - May 7 at 11:59pm 19 daysProject 4: Memory AllocatorNotes from MikeDifficulty: This project focuses on one of the major themes of Machine Organization Programming classes taught for many years at Universities all over the world and has gained a reputation for being a challenging project. I found twoparts challenging when I first did this project:1) Understanding how memory allocators work in general. First, watch the lecture videos and read section 9.9 – 9.9.6 of the book. It would be best if you learned this material in preparation for the final anyway. This project is designedto reinforce that learning.We're doing something a little different with the headers, but the spirit of the implementation matches the implicit free list idea. Invest the time reading the provided code to see what data the header stores and how those data are accessed—the header struct stores additional information not stored by the implicit free list model. We would use this extra information to investigate memory utilization if we had more time.2) Getting the C code that extracts the information I needed from the headers was tricky. I highly recommend writing helper functions so you only need to get this right once and can reusue this code. I included a list of suggested helperfunctions in the template file. These helper functions are not long. When I wrote them, they each fit on one line (multiple statements per line). Use the code provided in Mem_Dump to learn to access each piece of data packed into theheader.3) The overall length of the code you need to write to complete this project is not long. My final solutions for both Mem_Alloc and Mem_Free were less than 25 lines long each - including comments. I will admit that those line countsinclude some lines with more than one statement but not unreasonable. For example, one line reads int padding = 0 while ((size + padding) % 4) padding++ And, during the writing process, I used about 25 printf statements that Iremoved when my code was working. *yes I'm aware you can compute padding with one statement using simple math, but I was feeling really lazy at that moment.Cheating: This project has been used in many Universities for this class for many years. There are lots of solutions available on the Internet. We all try to change some little thing to make sure you can't just turn in a solution you find onthe Internet. Over the summer session, I caught 9 students out of 80 submitting work from the Internet for this project. I'm told my course has a reputation as a "gpa killer". However, at least part of this is that I'm good at catchingcheaters. Getting a 0 on a project or exam will definitely hurt your gpa. Fair warning, your work will be compared with a collection of popular solutions from the Internet. It is very difficult to look at someone else's solution and not copythe structure. I would encourage you to avoid searching for other people's work and instead come to office hours if you would like to talk about strategies for completing this project.Eight day project: I think this is a very reasonable project for the remaining time left in the semester. Please let me know if after you complete it if I'm wrong – so I can provide adequate time for students in the future. I think every aspectincluded in this project supports the learning goals for this course without extra work (memory allocations, fitting policies, freeing, and coalescing). We're skipping memory utilization analysis, and we're only implementing the first-fit policy. It's important to me that I'm not overwhelming anyone during the last two weeks of the semester – I know you all are taking other classes with projects and have jobs that also require your attention. Please reach out to me if you have anyconcerns about finishing the project.concerns about finishing the project.Corrections and Additions ...

关于数据迁移:DataWorks搬站方案Airflow作业迁移至DataWorks

简介：DataWorks提供工作搬站性能，反对将开源调度引擎Oozie、Azkaban、Airflow的工作疾速迁徙至DataWorks。本文次要介绍如何将开源Airflow工作流调度引擎中的作业迁徙至DataWorks上 DataWorks提供工作搬站性能，反对将开源调度引擎Oozie、Azkaban、Airflow的工作疾速迁徙至DataWorks。本文次要介绍如何将开源Airflow工作流调度引擎中的作业迁徙至DataWorks上。反对迁徙的Airflow版本 Airflow反对迁徙的版本：python >= 3.6.x airfow >=1.10.x 整体迁徙流程迁徙助手反对开源工作流调度引擎到DataWorks体系的大数据开发工作迁徙的根本流程如下图示。针对不同的开源调度引擎，DataWorks迁徙助手会出一个相干的工作导出计划。整体迁徙流程为：通过迁徙助手调度引擎作业导出能力，将开源调度引擎中的作业导出；再将作业导出包上传至迁徙助手中，通过工作类型映射，将映射后的作业导入至DataWorks中。作业导入时可设置将工作转换为MaxCompute类型作业、EMR类型作业、CDH类型作业等。 Airflow作业导出导出原理介绍：在用户的Airflow的执行环境外面，利用Airflow的Python库加载用户在Ariflow上调度的dag folder（用户本人的dag python文件所在目录）。导出工具在内存中通过Airflow的Python库去读取dag的外部工作信息及其依赖关系，将生成的dag信息通过写入json文件导出。具体的执行命令可进入迁徙助手->工作上云->调度引擎作业导出->Airflow页面中查看。 Airflow作业导入拿到了开源调度引擎的导出工作包后，用户能够拿这个zip包到迁徙助手的迁徙助手->工作上云->调度引擎作业导入页面上传导入包进行包剖析。导入包剖析胜利后点击确认，进入导入工作设置页面，页面中会展现剖析进去的调度工作信息。开源调度导入设置用户能够点击高级设置，设置Airflow工作与DataWorks工作的转换关系。不同的开源调度引擎，在高级设置外面的设置界面基本一致如下。高级设置项介绍： • sparkt-submit转换为：导入过程会去剖析用户的工作是不是sparkt-submit工作，如果是的话，会将spark-submit工作转换为对应的DataWorks工作类型，比如说：ODPS_SPARK/EMR_SPARK/CDH_SPARK等 • 命令行 SQL工作转换为：开源引擎很多工作类型是命令行运行SQL，比如说hive -e, beeline -e, impala-shell等等，迁徙助手会依据用户抉择的指标类型做对应的转换。比方能够转换成ODPS_SQL, EMR_HIVE, EMR_IMPALA, EMR_PRESTO, CDH_HIVE, CDH_PRESTO, CDH_IMPALA等等 • 指标计算引擎类型：这个次要是影响的是Sqoop同步的目标端的数据写入配置。咱们会默认将sqoop命令转换为数据集成工作。计算引擎类型决定了数据集成工作的目标端数据源应用哪个计算引擎的project。 • Shell类型转换为：SHELL类型的节点在Dataworks依据不同计算引擎会有很多种，比方EMR_SHELL，CDH_SHELL，DataWorks本人的Shell节点等等。 • 未知工作转换为：对目前迁徙助手无奈解决的工作，咱们默认用一个工作类型去对应，用户能够抉择SHELL或者虚节点VIRTUAL • SQL节点转换为：DataWorks上的SQL节点类型也因为绑定的计算引擎的不同也有很多种。比方 EMR_HIVE，EMR_IMPALA、EMR_PRESTO，CDH_HIVE，CDH_IMPALA，CDH_PRESTO，ODPS_SQL，EMR_SPARK_SQL，CDH_SPARK_SQL等，用户能够抉择转换为哪种工作类型。留神：这些导入映射的转换值是动态变化的，和以后我的项目空间绑定的计算引擎无关，转换关系如下。导入至DataWorks + MaxCompute 导入至DataWorks + EMR 导入至DataWorks + CDH 执行导入设置完映射关系后，点击开始导入即可。导入实现后，请进入数据开发中查看导入后果。数据迁徙大数据集群上的数据迁徙，可参考：DataWorks数据集成或MMA。原文链接本文为阿里云原创内容，未经容许不得转载。

关于sql:复杂SQL查询和可视化报表构建

场景介绍AnalyticDB MySQL数据开发流程。更多AnalyticDB MySQL相干至阿里云体验实验室简介指标是让云上数据仓库用户及开发者通过简略的步骤体验基于AnalyticDB MySQL版和DMS构建云原生数据仓库的次要流程，流动将通过实例的开明、构造与数据的初始化、报表的开发、报表可视化等环节，用3个具体的利用场景来体验AnalyticDB MySQL版在新批发场景下的交互查问和ETL计算速度，以及通过DMS进行数据仓库数据报表开发的流程。场景中提供的数据集是一个批发场景的模仿数据，包含客户信息、订单记录、货物信息、国家地区信息等内容，数据总量10GB，最大数据表记录数为5999万条。产品简介云原生数据仓库AnalyticDB MySQL版是一种反对高并发低延时查问的新一代云原生数据仓库，高度兼容MySQL协定以及SQL:2003 语法规范，能够对海量数据进行即时的多维分析透视和业务摸索，疾速构建企业云上数据仓库。查看产品详情。数据管理DMS是基于阿里巴巴团体十余年的数据库服务平台的云版本，提供免装置、免运维、即开即用、多种数据库类型与多种环境对立的web数据库治理终端；能够为企业用户疾速复制搭建与阿里团体等同平安、高效、标准的数据库DevOps研发流程、数仓开发解决方案。查看产品详情。场景化数据查问剖析场景化数据查问剖析地址：https://dms.aliyun.com/门路：全副性能-SQLConsole-单库查问场景化SQL脚本如下： #### 1）统计半年内寰球各地区销售金额形成。0.5秒, 用饼状图图展现。select r_name //地区 ,sum(o_totalprice) totalprice //交易金额from ( select r_name, o_totalprice from customer ,orders ,nation ,region where c_custkey = o_custkey and c_nationkey=n_nationkey and n_regionkey=r_regionkey and o_orderdate < date '1993-09-23' // 谓词过滤：指定工夫 and o_orderdate > date '1993-03-23' ) a group by r_name order by r_name ; #### 2）统计某类目商品每天订单量以及订单金额，依照日期排序。 1秒。用折现图展现select o_orderdate, //下单日期 count(distinct o_orderkey), //订单数 sum(l_extendedprice*(1-l_discount)) as revenue //订单金额 from customer,orders,lineitem where c_mktsegment = 'MACHINERY' // 谓词过滤 and c_custkey = o_custkey and l_orderkey = o_orderkey and o_orderdate < date '1995-03-23' and o_orderdate > date '1995-02-23' // 谓词过滤指定工夫 and l_shipdate > date '1995-03-23' and l_shipdate < date '1996-03-23'group by //分组操作 o_orderdate //订单日期 order by o_orderdate; #### 3）统计某个地区整机供货商支出。1秒，用柱状图展现。select n_name, //地区 sum(l_extendedprice * (1 - l_discount)) as revenue //支出 from customer, orders, lineitem, supplier, nation, region //六表连贯 where c_custkey = o_custkey and l_orderkey = o_orderkey and l_suppkey = s_suppkey and c_nationkey = s_nationkey and s_nationkey = n_nationkey and n_regionkey = r_regionkey and r_name = 'EUROPE' // 谓词过滤：指定地区 and o_orderdate >= date '1996-01-01' //谓词过滤：指定工夫 and o_orderdate < date '1996-01-01' + interval '1' year and l_shipdate > date '1996-02-23' and l_shipdate < date '1996-03-23'group by n_nameorder by // TopN：按支出降序排序，留神分组和排序子句不同 revenue desclimit 10数据开发数据开发 ...

关于sql:SQL语句中-left-join-后用-on-还是-where区别大了

前天写SQL时本想通过 A left B join on and 前面的条件来使查出的两条记录变成一条，奈何发现还是有两条。起初发现 join on and 不会过滤后果记录条数，只会依据and后的条件是否显示 B表的记录，A表的记录肯定会显示。不论and 前面的是A.id=1还是B.id=1,都显示出A表中所有的记录，并关联显示B中对应A表中id为1的记录或者B表中id为1的记录。运行sql : select * from student s left join class c on s.classId=c.id order by s.id运行sql : select * from student s left join class c on s.classId=c.id and s.name="张三" order by s.id运行sql : select * from student s left join class c on s.classId=c.id and c.name="三年级三班" order by s.id数据库在通过连贯两张或多张表来返回记录时，都会生成一张两头的长期表，而后再将这张长期表返回给用户。在应用left jion时，on和where条件的区别如下： 1、 on条件是在生成长期表时应用的条件，它不论on中的条件是否为真，都会返回右边表中的记录。 2、where条件是在长期表生成好后，再对长期表进行过滤的条件。这时曾经没有left join的含意（必须返回右边表的记录）了，条件不为真的就全副过滤掉。 ...

关于sql:SQL-中英文标点查询问题

代码如下： SELECT * FROM 表名 WHERE 字段名 COLLATE Chinese_PRC_CS_AS_WS like '%?%'SELECT * FROM 表名 WHERE 字段名 COLLATE Chinese_PRC_CS_AS_WS like '%？%'这样子搜寻中英文问号进去的后果就会不一样。

关于sql:MSSQL-Server-脱机数据库失败

在 MSSQL Server 管理器中对数据库进行脱机操作时偶然会呈现脱机失败问题，先兆是在脱机界面时会等很长的工夫，如果遇到等很长时间的问题，那么个别思考为数据库被占用或正在应用的起因，参考以下 SQL： EXEC sp_who2 KILL [SPID]第一句是查询数据库的应用状况，第二句是 KILL 掉 SPID 关联的那一条记录，应用时记得替换 SPID 的值。

关于sql:SQL-Server-批量导入大数据

在以往的通常状况下，一次性向数据库中插入多条数据的办法多是用循环代码一条一条地插入，这种办法在面临百万、千万级别的数据时显得毫无效率，通常要期待几分钟，甚至几十分钟；好在 MS SQL Server 提供了一个叫做 bulk insert 的办法，有了它就可能更加高效地导入大数据；应用形式并不简单，用测试表举例： CREATE TABLE test( ID INT IDENTITY(1,1) PRIMARY KEY, name VARCHAR(50), tel VARCHAR(50))其中主键 ID 为自增标识列，另外两个一般数据字段，而后再筹备数据文件： ,henry,18011112222|,mark,13011112222|,join,14011112222|,mary,15011112222|,george,16011112222|,henry,18011112222|,mark,13011112222|,join,14011112222|,mary,15011112222|,george,16011112222|假如有一个叫做 d:\a.txt 的文件，文件内容如上，把那几行数据复制成更多行以进行大数据测试；而后编写 SQL 代码： BULK INSERT test FROM 'd:\a.txt' WITH(FIELDTERMINATOR=',',ROWTERMINATOR='|')其中 with 后的标识符 fieldterminator 指字段分隔符，rowterminator 指行分隔符，这里用的是 , 号和 | 号，联合筹备好的数据文件能够晓得自右边开始的列别离为 ID、name 和 tel，这个数据文件中每一行的第一个 , 号前没有数据，这是因为自增标识列能够在数据文件中被省略，如果前面也省略的话，插入到表中的内容就为 NULL，前提是列能够为 NULL；行分隔符的意思不必多解释，到此执行 SQL 命令就能够向 test 表中插入指定的数据，在我的电脑上插入 10 万条数据仅仅只须要 1 秒钟。

关于sql:SQL-Server-中不能直接插入标识列

在失常的状况下，如果向某张表的自增长标识列字段插入新的记录是会被 SQL Server 阻止的：然而通过批改某张表的 IDENTITY_INSERT 开关，可能向自增长的标识列手动增加新值，代码如下： SET IDENTITY_INSERT 表名 ON--接下来就能够插入自增长列的数据了，批改过后别忘了关掉这个开关--set identity_insert 表名 off

关于sql:SQL-while-循环的基本格式

DECLARE @i INTSET @i=0WHILE @i<100BEGIN PRINT @i SET @i+=1END意思为从 0 开始顺次输入到 99。

关于sql:NET-连接数据库时提示无法打开登录所请求的数据库

最近搬了一个古老的数据库，间接附加在了服务器的数据库资源管理器上，我的项目测试的时候怎么也拜访不了数据库，查看了日志外面的信息，在 SQL Helper 类中报出了“ 无奈关上登录所申请的数据库 ”这样一个谬误，再确认过账号密码和权限没有问题过后，又想起了数据库的所有者，果然问题出在这里，尝试更改数据库的所有者为正确的用户即解决：相干环境：Microsoft SQL Server 2012

关于sql:SQL-Server-用户-sa-登录失败

谬误的由来应该是在装置 SQL Server 的时候没有抉择 SQL Server 身份验证模式，我记得过后我只选了 Windows 身份验证模式，这种状况下用 sa 账号连贯数据库就会导致谬误，如下图所示：解决办法是在 SQL 服务器安全性设置中启用 SQL Server 和 Windows 身份验证模式：顺便再查看下 sa 账号的状态（在‘安全性’ - ‘登录名’外面找）：设置完后须要重新启动 SQL 服务，要不然可能会呈现下图所示的谬误：相干环境：Windows 10、Microsoft SQL Server 2012

关于visual-studio-code:使用-Visual-Studio-Code-SQLite-扩展来浏览-SAP-CAP-数据库

在 SAP Cloud Application Programming 编程模型里，咱们能够应用上面的命令行，应用长久化数据库( persistent database ) 来存储 entity 的数据。 cds deploy --to sqlite:my.db cds deploy --to sqlite:my.dbfilling sap.capire.bookshop.Authors from db\data\sap.capire.bookshop-Authors.csvfilling sap.capire.bookshop.Books from db\data\sap.capire.bookshop-Books.csv/> successfully deployed to ./my.db/> updated ./package.json 这条命令会在工程文件夹上面生成一个my.db文件。 .db 格局的文件，在 Visual Studio Code 里无奈间接关上：能够装置这个名为 sqlite 的 Visual Studio Code 扩大：装置结束后，能在 Visual Studio Code 右边看到一个新的 SQLITE EXPLORER面板，外面能够浏览 my.db 文件里蕴含的数据库表和视图：右键菜单里抉择 Show Table，即可查看指定数据库表里的内容：还能够本人编辑 SQLite Query，而后通过右键菜单 Run Selected Query 来执行： ...

关于数据仓库:深度-数据仓库分层存储技术揭秘

简介：作者：沄浩、士远一、背景据IDC公布的《数据时代2025》报告显示，寰球每年产生的数据将从2018年的33ZB增长到2025年的175ZB，均匀每天约产生491EB数据。随着数据量的一直增长，数据存储老本成为企业IT估算的重要组成部分。例如1PB数据存储一年，全副放在高性能存储介质和全副放在低成本存储介质两者老本差距在一个量级以上。因为要害业务需高性能拜访，因而不能简略的把所有数据寄存在低速设施，企业需依据数据的拜访频度，应用不同品种的存储介质取得最小化老本和最大化效率。因而，把数据存储在不同层级，并可能主动在层级间迁徙数据的分层存储技术成为企业海量数据存储的首选。本文介绍数据仓库产品作为企业中数据存储和治理的基础设施，在通过分层存储技术来升高企业存储老本时的关键问题和核心技术。 1. 什么是分层存储分层存储顾名思义，就是把数据分为高频拜访的热数据和低频拜访的冷数据，并别离存储在热数据层和冷数据层，达到性能与老本的均衡。热数据层采纳高性能存储介质，单位成本高，为管制估算个别容量较小，只存储要害业务数据，例如ERP，CRM数据，或者最新的订单数据等。冷数据层则存储非关键业务数据，例如审计日志，运行日志等，或历史积淀数据，例如一个月前的订单数据。此局部数据体量大，拜访频度低，性能要求不高，因而采纳单位成本低，容量大的存储介质来降低成本。同时，随着工夫流逝，局部热数据拜访频度会升高（个别称为数据降温），此时存储系统可能主动迁徙该局部数据到冷数据层来降低成本。 2. 数据仓库分层存储面临的挑战数据仓库产品在实现分层存储能力时，面临的几个外围挑战如下：抉择适合的存储介质。存储介质既要满足性能、老本需要，还要满足可靠性、可用性、容量可扩大、运维简略等需要。业务上的冷热数据，如何在分层存储中定义？即如何形容哪局部是热数据，哪局部是冷数据。冷热数据如何迁徙？随着工夫流逝，业务上的热数据降温为冷数据后，数据仓库如何感知温度的变动并执行数据迁徙来升高存储老本。如何减速冷数据的拜访？冷数据依然会被拜访，比方因法规政策要求，用户需对三个月前数据进行订正，或者须要对过来一年的数据进行统计分析来进行历史回顾和趋势剖析。因为冷数据体量大，查问波及的数据多，存储介质性能低，如果不进行优化，对冷数据的元信息，内容拜访可能呈现瓶颈影响业务应用。二、数据仓库分层存储关键技术解析本章将以阿里云数据仓库AnalyticDB MySQL版（下文简称ADB）为原型介绍如何在数据仓库产品中实现分层存储，并解决其外围挑战。ADB的整体架构分为三层：第一层是接入层：由多个前端节点形成，次要负责接入用户查问，进行SQL解析、优化、调度。第二层是计算引擎层：由多个计算节点组成，负责执行用户查问。第三层是存储引擎层：由多个存储节点组成，用户数据按Shard切片存储，每个Shard有多个正本保障高牢靠和高可用。 1. 冷热数据存储介质的抉择对于业务上的热数据，需采纳高性能存储介质满足其疾速查问需要。SSD绝对HDD来说，老本较高，但其具备高IOPS和高带宽的个性，因而ADB把热数据层建设在SSD上，并应用数据多正本机制，呈现存储节点异样时，通过切换服务节点来保障高牢靠和高可用。业务上的冷数据，个别是历史积淀的业务数据或日志数据，这些数据体量大，拜访频度低，因而容量大、成本低是存储介质的次要抉择因素。对于冷数据层，ADB抉择建设在阿里云OSS上。阿里云对象存储服务OSS作为阿里云提供的海量、低成本、高持久性的云存储服务，其数据设计持久性不低于99.9999999999%，服务可用性不低于99.995%。OSS提供的这些个性满足了冷数据层对老本和可靠性的需要，同时绝对于本人保护HDD磁盘，OSS本身具备容量有限扩大能力，满足海量数据存储需要。并且OSS能够近程拜访，因而存储节点的正本间能够共享数据来进一步降低成本。 2. 冷热数据定义问题业务本身对冷热数据的定义比拟明确。比方企业中一些须要高频拜访的CRM、ERP数据均为热数据。而对于审计日志，或数天前的订单数据，其拜访频度低，则可定义为冷数据。外围问题是，业务上的这些数据，如何在分层存储中形容其冷热属性并保障存储地位的准确性。例如企业促销流动，大量用户正在线上进行业务交互，此时如果分层存储谬误的把客户信息、商品信息等要害数据迁徙到冷区，则会引起相干查问性能受损，最终呈现客户登录碰壁，客户点击失败等业务异样，导致企业受损。ADB解决这个问题的办法是在用户建表时指定存储策略（storage_policy）来准确关联业务上的冷热数据和分层存储中的冷热存储，上面是示例。全热表所有数据存储在SSD并且不会降温，实用于全表数据被频繁拜访，且对拜访性能有较高要求的场景，比方CRM、ERP数据。 Create table t1( id int, dt datetime ) distribute by hash(id) storage_policy = 'HOT'; 全冷表所有数据存储在OSS，实用于体量大，拜访频度低，须要缩小存储老本的场景，比方审计日志数据。 Create table t2( id int, dt datetime ) distribute by hash(id) storage_policy = 'COLD'; 冷热混合表实用于数据冷热有显著工夫窗口的场景。例如最近7天的游戏日志数据，广告点击数据等需高频拜访，作为热数据存储，而7天前的数据可降温为冷数据，低成本存储。注：冷热混合表需配合表的分区应用。除storage_policy外，还需指定hot_partition_count属性。hot_partition_count指按分区值倒序，取最大N个分区为热分区，其余为冷分区。下例中，表按天分区，hot_partition_count = 7示意分区值最大的7个分区，也就是最近7天的数据为热数据。 Create table t3( id int, dt datetime ) distribute by hash(id) partition by value(date_format(dt, '%Y%m%d')) lifecycle 365 storage_policy = 'MIXED' hot_partition_count = 7; ...

关于spark:你的Parquet该升级了IOException-totalValueCount-0问题定位之旅

摘要：应用Spark SQL进行ETL工作，在读取某张表的时候报错：“IOException: totalValueCount == 0”，但该表在写入时，并没有什么异样。本文分享自华为云社区《你的Parquet该降级了：IOException: totalValueCount == 0问题定位之旅》，原文作者：wzhfy 。 1. 问题形容应用Spark SQL进行ETL工作，在读取某张表的时候报错：“IOException: totalValueCount == 0”，但该表在写入时，并没有什么异样。 2. 初步剖析该表的后果是由两表join后生成。经剖析，join的后果产生了数据歪斜，且歪斜key为null。Join后每个task写一个文件，所以partition key为null的那个task将大量的null值写入了一个文件，null值个数达到22亿。 22亿这个数字比拟敏感，正好超过int最大值2147483647（21亿多）。因而，初步狐疑parquet在写入超过int.max个value时有问题。【注】本文只关注大量null值写入同一个文件导致读取时报错的问题。至于该列数据产生如此大量的null是否正当，不在本文探讨范畴之内。 3. Deep dive into Parquet (version 1.8.3，局部内容可能须要联合Parquet源码进行了解)入口：Spark（Spark 2.3版本） -> Parquet Parquet调用入口在Spark，所以从Spark开始开掘调用栈。 InsertIntoHadoopFsRelationCommand.run()/SaveAsHiveFile.saveAsHiveFile() -> FileFormatWriter.write() 这里分几个步骤：启动作业前，创立outputWriterFactory: ParquetFileFormat.prepareWrite()。这里会设置一系列与parquet写文件无关的配置信息。其中次要的一个，是设置WriteSupport类：ParquetOutputFormat.setWriteSupportClass(job, classOf[ParquetWriteSupport])，ParquetWriteSupport是Spark本人定义的类。在executeTask() -> writeTask.execute()中，先通过outputWriterFactory创立OutputWriter (ParquetOutputWriter)：outputWriterFactory.newInstance()。对于每行记录，应用ParquetOutputWriter.write(InternalRow)办法顺次写入parquet文件。Task完结前，调用ParquetOutputWriter.close()敞开资源。3.1 Write过程在ParquetOutputWriter中，通过ParquetOutputFormat.getRecordWriter结构一个RecordWriter（ParquetRecordWriter），其中蕴含了： prepareWrite()时设置的WriteSupport：负责转换Spark record并写入parquet构造ParquetFileWriter：负责写入文件ParquetRecordWriter中，其实是把write操作委托给了一个internalWriter（InternalParquetRecordWriter，用WriteSupport和ParquetFileWriter结构）。当初让咱们梳理一下，目前为止的大抵流程为：SingleDirectoryWriteTask/DynamicPartitionWriteTask.execute-> ParquetOutputWriter.write -> ParquetRecordWriter.write -> InternalParquetRecordWriter.write 接下来，InternalParquetRecordWriter.write外面，就是三件事：（1）writeSupport.write，即ParquetWriteSupport.write，外面分三个步骤： MessageColumnIO.MessageColumnIORecordConsumer.startMessage；ParquetWriteSupport.writeFields：写入一行中各个列的值，null值除外；MessageColumnIO.MessageColumnIORecordConsumer.endMessage：针对第二步中的missing fields写入null值。ColumnWriterV1.writeNull -> accountForValueWritten：1）减少计数器valueCount （int类型）2）查看空间是否已满，须要writePage - 检查点1 （2）减少计数器recordCount（long类型）（3）查看block size，是否须要flushRowGroupToStore - 检查点2 因为写入的值全是null，在1、2两个检查点的memSize都为0，所以不会刷新page和row group。导致的后果就是，始终在往同一个page里减少null值。而ColumnWriterV1的计数器valueCount是int类型，当超过int.max时，溢出，变为了一个正数。 ...

关于sql:一次-SQL-查询优化原理分析900W-数据从-17s-到-300ms

有一张财务流水表，未分库分表，目前的数据量为9555695，分页查问应用到了limit，优化之前的查问耗时16 s 938 ms (execution: 16 s 831 ms, fetching: 107 ms)，依照下文的形式调整SQL后，耗时347 ms (execution: 163 ms, fetching: 184 ms)；操作：查问条件放到子查问中，子查问只查主键ID，而后应用子查问中确定的主键关联查问其余的属性字段；原理：缩小回表操作； -- 优化前SQLSELECT 各种字段FROM`table_name`WHERE 各种条件LIMIT0,10; -- 优化后SQLSELECT 各种字段FROM`table_name` main_taleRIGHTJOIN(SELECT 子查问只查主键FROM`table_name`WHERE 各种条件LIMIT0,10;) temp_table ON temp_table.主键 = main_table.主键找到的原理剖析：MySQL 用 limit 为什么会影响性能？一，前言首先阐明一下MySQL的版本： mysql> selectversion();+-----------+| version() |+-----------+| 5.7.17 |+-----------+1 row in set (0.00 sec) 表构造： mysql> desc test;+--------+---------------------+------+-----+---------+----------------+| Field | Type | Null | Key | Default | Extra |+--------+---------------------+------+-----+---------+----------------+| id | bigint(20) unsigned | NO | PRI | NULL | auto_increment || val | int(10) unsigned | NO | MUL | 0 | || source | int(10) unsigned | NO | | 0 | |+--------+---------------------+------+-----+---------+----------------+3 rows in set (0.00 sec) id为自增主键，val为非惟一索引。 ...

关于GaussDB:一文掌握GaussDBDWS-SQL进阶技能全文检索

摘要：本文简要介绍了GaussDB(DWS)全文检索的原理和应用办法。本文分享自华为云社区《GaussDB(DWS) SQL进阶之全文检索》，原文作者：Zhang Jingyao 。全文检索（Text search）顾名思义，就是在给定的文档中查找指定模式（pattern）的过程。GaussDB(DWS)反对对表格中文本类型的字段及字段的组合做全文检索，找出能匹配给定模式的文本，并以用户冀望的形式将匹配后果出现进去。本文联合笔者的教训和思考，对GaussDB(DWS)的全文检索性能作简要介绍，心愿能对读者有所帮忙。 1. 预处理在指定的文档中查找一个模式有很多种方法，例如能够用grep命令搜寻一个正则表达式。实践上，对数据库中的文本字段也能够用相似grep的形式来检索模式，GaussDB(DWS)中就能够通过关键字“LIKE”或操作符“~”来匹配字符串。但这样做有很多问题。首先对每段文本都要扫描，效率比拟低，难以掂量“匹配度”或“相关度”。而且只能机械地匹配字符串，短少对语法语义的剖析能力，例如对英语中的名词复数，动词的时态变换等难以主动地辨认和匹配，对于由自然语言形成的文本无奈取得令人满意的检索后果。 GaussDB(DWS)采纳相似搜索引擎的形式来进行全文检索。首先对给定的文本和模式做预处理，包含从一段文本中提取出单词或词组，去掉对检索无用的停用词（stop word），对变形后的单词做标准化等等，使之变为适宜检索的模式再作匹配。 GaussDB(DWS)中，原始的文档和搜寻条件都用文本（text）示意，或者说，用字符串示意。通过预处理后的文档变为tsvector类型，通过函数to_tsvector来实现这一转换。例如， postgres=# select to_tsvector('a fat cat ate fat rats'); to_tsvector ----------------------------------- 'ate':4 'cat':3 'fat':2,5 'rat':6(1 row)察看下面输入的tsvector类型，能够看到to_tsvector的成果：首先各个单词被摘取进去，其地位用整数标识进去，例如“fat”位于原始句子中的第2和第5个词的地位。此外，“a”这个词太常见了，简直每个文档里都会呈现，对于检索到有用的信息简直没有帮忙。套用香农实践，一个词呈现的概率越大，其蕴含的信息量越小。像“a”，“the”这种单词简直不携带任何信息，所以被当做停用词（stop word）去掉了。留神这并没有影响其余词的地位编号，“fat”的地位依然是2和5，而不是1和4。另外，复数模式的“rats”被换成了复数模式“rat”。这个操作被称为标准化（Normalize），次要是针对西文中单词在不同语境中会产生的变形，去掉后缀保留词根的一种操作。其意义在于简化自然语言的检索，例如检索“rat”时能够将蕴含“rat”和“rats”的文档都检索进去。被标准化后失去的单词称为词位（lexeme），比方“rat”。而原始的单词被称为语言符号（token）。将一个文档转换成tsvector模式有很多益处。例如，能够不便地创立索引，进步检索的速度和效率，当文档数量微小时，通过索引来检索关键字比grep这种全文扫描匹配要快得多。再比方，能够对不同关键字按重要水平调配不同的权重，不便对检索后果进行排序，找出相关度最高的文档等等。通过预处理后的检索条件被转换成tsquery类型，可通过to_tsquery函数实现。例如， postgres=# select to_tsquery('a & cats & rat'); to_tsquery --------------- 'cat' & 'rat'(1 row)从下面的例子能够看到：跟to_tsvector相似，to_tsquery也会对输出文本做去掉停用词、标准化等操作，例如去掉了“a”，把“cats”变成“cat”等。输出的检索条件自身必须用与（&）、或（|）、非（！）操作符连贯，例如上面的语句会报错postgres=# select to_tsquery('cats rat');ERROR: syntax error in tsquery: "cats rat"CONTEXT: referenced column: to_tsquery但plainto_tsquery没有这个限度。plainto_tsquery会把输出的单词变成“与”条件： postgres=# select plainto_tsquery('cats rat'); plainto_tsquery----------------- 'cat' & 'rat'(1 row)postgres=# select plainto_tsquery('cats,rat'); plainto_tsquery----------------- 'cat' & 'rat'(1 row)除了用函数之外，还能够用强制类型转换的形式将一个字符串转换成tsvector或tsquery类型，例如 ...

关于sql:一文详解SQL关联子查询

简介：本文次要介绍什么是关联子查问以及如何将关联子查问改写为一般语义的sql查问。本文次要介绍什么是关联子查问以及如何将关联子查问改写为一般语义的sql查问。在背景介绍中咱们将讲讲常见的关联子查问的语义，关联子查问语法的益处以及其执行时对数据库系统的挑战。第二章中咱们将次要介绍如何将关联子查问改写为一般的查问的模式，也就是解关联。第三章中咱们会介绍解关联中的优化办法。一背景介绍关联子查问是指和内部查问有关联的子查问，具体来说就是在这个子查问里应用了内部查问蕴含的列。因为这种能够应用关联列的灵活性，将sql查问写成子查问的模式往往能够极大的简化sql以及使得sql查问的语义更加不便了解。上面咱们通过应用tpch schema来举几个例子以阐明这一点。tpch schema是一个典型的订单零碎的database，蕴含customer表，orders表，lineitem表等，如下图：如果咱们心愿查问出“所有素来没有下过单的客户的信息”，那么咱们能够将关联子查问作为过滤条件。应用关联子查问写出的sql如下。能够看到这里的not exists子查问应用列内部的列c_custkey。 -- 所有素来没有下过单的客户的信息select c_custkeyfrom customer where not exists ( select * from orders where o_custkey = c_custkey )如果不写成下面的模式，咱们则须要思考将customer和orders两个表先进行left join，而后再过滤掉没有join上的行，同时咱们还须要markorder的每一行，使得原本就是null的那些。查问sql如下： -- 所有素来没有下过单的客户的信息select c_custkeyfrom customer left join ( select distinct o_custkey from orders ) on o_custkey = c_custkeywhere o_custkey is null从这个简略的例子中就能够看到应用关联子查问升高了sql编写的难度，同时进步了可读性。除了在exists/in子查问中应用关联列，关联子查问还能够呈现在where中作为过滤条件须要的值。比方tpch q17中应用子查问求出一个聚合值作为过滤条件。 -- tpch q17SELECT Sum(l1.extendedprice) / 7.0 AS avg_yearly FROM lineitem l1, part pWHERE p.partkey = l1.partkey AND p.brand = 'Brand#44' AND p.container = 'WRAP PKG' AND l1.quantity < (SELECT 0.2 * Avg(l2.quantity) FROM lineitem l2 WHERE l2.partkey = p.partkey);除了呈现在where外面，关联子查问能够呈现在任何容许呈现单行(scalar)的中央，比方select列表里。如果咱们须要做报表汇总一些customer的信息，心愿对每一个customer查问他们的订单总额，咱们能够应用上面蕴含关联子查问的sql。 ...

关于sql:一次非常有意思的-SQL-优化经历-从-30248271s-到-0001s

我的公众号：MarkerHub，Java网站：https://markerhub.com更多精选文章请点击：Java笔记大全.md 小Hub领读：数据量少的时候看不出区别，量大差异显著，文末的4点总结你应该去看一下，或者对你有帮忙！风过无痕https://www.cnblogs.com/tangy...场景用的数据库是 mysql5.6，上面简略的介绍下场景课程表：数据 100 条学生表：数据 70000 条学生成绩表 SC：数据 70w 条查问目标：查找语文考 100 分的考生查问语句：执行工夫：30248.271s 为什么这么慢？先来查看下查问打算：发现没有用到索引，type 全是 ALL，那么首先想到的就是建设一个索引，建设索引的字段当然是在 where 条件的字段。先给 sc 表的 c_id 和 score 建个索引再次执行上述查问语句，工夫为: 1.054s 快了 3w 多倍，大大缩短了查问工夫，看来索引能极大水平的进步查问效率，看来建索引很有必要，很多时候都遗记建索引了，数据量小的的时候压根没感觉，这优化感觉挺爽。然而 1s 的工夫还是太长了，还能进行优化吗，认真看执行打算：查看优化后的 sql: 补充：这里有网友问怎么查看优化后的语句办法如下：在命令窗口执行有 type=all 依照我之前的想法，该 sql 的执行的程序应该是先执行子查问耗时：0.001s 失去如下后果：而后再执行耗时：0.001s 这样就是相当快了啊，Mysql 居然不是先执行里层的查问，而是将 sql 优化成了 exists 子句，并呈现了 EPENDENT SUBQUERY， ...

关于Flink:Flink-SQL-在网易云音乐的产品化实践

摘要：本文由网易云音乐数据智能部资深数据平台开发工程师蒋文伟分享，次要介绍 Flink SQL 在云音乐的产品化实际。分享内容如下：简介产品性能性能优化运维欠缺将来布局一、背景简介1.Flink in Music先简略的介绍下云音乐的现状，目前音乐这边的客户端日志，服务端日志大略在每日大千亿条左右，维度表数据源像 Redis，MySQL 这些大略有上百个。而服务的实时计算工作开发的人员有上百名，其中不仅包扩数据开发工程师，分析师，也包含算法，后盾业务等同学。这些同学们也累积开发了上千个实时计算工作，这些工作不仅有统计工作，还有些一线业务，比方排行榜，实时热度等。 2.利用场景这里我略微列举了一些业务场景，比方咱们的内容散发、实时数仓、算法举荐，还有索引工作、实时监控，AB test 等，简直涵盖了整个数据链路中的大部分业务场景，能够说咱们当初的业务曾经离不开 Flink 的体系，那前面咱们会以其中几个场景为例，看看咱们在这些场景中应用原生的 Flink 会遇到那些问题。 ■ 内容散发第一个介绍的场景是散发，散发是个十分典型的场景。它会依据肯定条件对数据流进行划分，把输出数据流切分成多个子流。个别状况下散发会是整个数据链路的上游，所以相对来说这类工作十分重要，那么咱们在这个场景中会遇到什么问题呢? 问题1:开发效率低，业务规范流程难以复用首先是开发效率低下，这类业务逻辑非常简单，外围开发工作其实就是个 where 筛选，然而传统的开发方式须要用户理解很多额定的货色，比方 HDFS 的定时清理性能，如果这个组件交由用户开发，势必要凋谢权限，那么就可能会导致 HDFS 仓库文件被误删等安全事故，所以咱们须要建设一套对立框架，且能够提供一系列标准化的组件，用户仅须要关怀其外围业务逻辑即可。问题2:学习老本高第二个问题是学习老本较高，SQL 是一种十分优良的数据处理语言，很多同学也都会，然而 Flink SQL 的配置却没一般 SQL 那么简略。Flink SQL 要求用户对每个组件的配置都十分相熟，这是一个 HDFS 的 sink 操作，须要在 SQL 中配置输入目录，分区字段，文件大小，keytab，压缩格局等一系列的参数，而这些参数须要用户通过文档来学习。针对这个，咱们须要一种前端上的优化，通过给用户可视化的提醒，来简化配置，升高学习老本。问题3:外部环境凌乱第三，对一个稳定性，以及性能要求比拟高的工作来说，所有的这些监控、报警的配套体系建设也都是必不可少的。 ■ 特色快照第二个例子，特色快照，先简略的说下什么是特色快照，特色快照简略的能够了解成把特色的历史版本进行存储，为什么要这么做呢，因为特色是动态变化的，每个事件未必能保准程序达到，一个用户先点喜爱 DJ，在播放歌曲，再点击喜爱了动漫，咱们最终这次播放关联的应该是 DJ 而不是动漫，但依照工夫序可能就是错的，所以，对一每个版本的特色和 tag，都会有其惟一的 traceid 来进行治理，也就是一个 traceid 一个特色版本，这块在实时机器学习场景应用的十分宽泛。这边能够看到工作的流程图，包含数据荡涤，收集，抽样，去重，join 等流程，这些流程也有很多业务逻辑，像 join 这个流程如果 join 不上怎么办，是放在内存里等，还是再次回流到 kafka 期待下一轮匹配，亦或是应用降级计划。相对来说，对稳定性、兜底计划等都有较多要求。 ...

关于sql:MySQL个人学习笔记

MySQL数据库概述什么是数据库？所谓的数据库就是指存储和治理数据的仓库扩大内容1：数据库有哪些分类？(理解) 晚期: 档次式数据库、网络型数据库当初：关系型数据库、非关系型数据库什么是关系型数据库？底层以二维表的模式保留数据的库就是关系型数据库扩大内容2：常见的关系型数据库有哪些？(理解) Sql Server：微软提供，免费，实用于一些中型或大型的我的项目中，在java中的应用占比不高（.NET中应用的较多）Oracle：甲骨文公司提供，免费，实用于一些大型或者超大型的我的项目中，在java中的应用占比十分高mysql：瑞典MySQLAB公司提供，收费开源，实用于一些小型或者中型的我的项目中，在Java中的应用占比拟高（玲珑轻量）mariadb其实就是MySQL的一个分支，用法和MySQL齐全一样。DB2：IBM公司提供，免费，在一些银行、金融等行业中应用较多。在java中的应用占比也不高。Sqlite：迷你数据库，嵌入式设施中（安卓、苹果手机、pad）...数据库相干概念1、什么是数据库服务器数据库服务器就是一个软件（比方mysql软件）将数据库软件装置在电脑上，以后电脑就是一个数据库服务器。就能够对外提供存取数据的服务在一个数据库服务器中能够创立多个数据库（dataBases），每一个数据库都是一个独自的仓库。 2、什么是数据库数据库就是存储和治理数据的仓库，通常状况下，一个网站的中的所有数据会寄存在一个数据库中。例如： jd.com db_jd(数据库) taobao.com db_taobao(数据库) ... 3、什么是表一个数据库中能够创立多张表，每张表用于存储一类信息（数据库），例如： jd.com中的用户数据 tb_user(表) jd.com中的商品数据 tb_product(表) jd.com中的订单数据 tb_order(表) ... 4、什么表记录一张表中能够蕴含多行表记录，每一行表记录用于存储某一个具体的数据学生编号姓名年龄 1001 刘沛霞 35 1002 陈子枢 18 。。。。。。。。。什么是SQL语言？SQL是一门用于操作关系型数据库的通用的语言（应用SQL能够操作所有的关系型数据库）应用SQL能够操作数据库、表、表记录 (1)创立数据库、删除数据库、批改数据库、查询数据库 (2)创立表、删除表、批改表、查问表 (3)新增表记录、删除表记录、批改表记录、查问表记录应用SQL也能够操作存储过程/视图/索引等。提醒：SQL是一个规范通用的操作关系型数据库的语言（普通话），每个数据库厂商为了加强本人数据库的性能，都提供了反对本人数据库的语言，称之为数据库的方言。方言不通用！连贯mysql服务器通过命令行工具能够登录MySQL客户端，连贯MySQL服务器，从而拜访服务器中的数据。 1、连贯mysql服务器： mysql -uroot -p明码 -u：前面的root是用户名，这里应用的是超级管理员root； -p：(小写的p)前面的root是明码，这是在装置MySQL时就曾经指定的明码； 2、连贯mysql服务器并指定IP和端口: mysql -uroot -proot -h127.0.0.1 -P3306 -h：前面给出的127.0.0.1是服务器主机名或ip地址，能够省略的，默认连贯本机； -P：(大写的P)前面的3306是连贯端口，能够省略，默认连贯3306端口； 3、退出客户端命令：quit或exit或 q 4、FAQ：常见问题: %E7%AC%AC%E4%BA%8C%E9%98%B6%E6%AE%B5%E8%AE%B2%E4%B9%8903.assetse23a06d3921d5d68c48d6e51024aae8a.jpg?lastModify=1616081589) 解决办法：复制mysql装置目录下的bin目录的门路，将bin目录的门路增加到path环境变量中!! 能够在cmd中通过 echo %path% 查看path环境变量的值。 ...

关于sql:with-as关键字的使用

with..as相当于一张两头表，能够简略了解为sql片段--单个别名with aliasName as (select ....)select * from aliasName-- 多个别名with tmp as (select * from tb_name), tmp2 as (select * from tb_name2), tmp3 as (select * from tb_name3), …例字--相当于建了个e长期表with e as (select * from scott.emp e where e.empno=7499)select * from e;--相当于建了e、d长期表with e as (select * from scott.emp), d as (select * from scott.dept)select * from e, d where e.deptno = d.deptno;with as 的这种语法适宜和union all搭配应用with temp1 as (select 'female' sex, 'zhangsan' stu_name from dual),temp2 as (select 'male' sex, 'lisi' stu_name from dual),temp3 as (select 'female' sex, 'wangwu' stu_name from dual)select * from temp1union allselect * from temp2union allselect * from temp3

关于sql:高性能SQL高性能的索引策略

高性能索引的策略创立高性能索引的几种形式：1.独立的列2.前缀索引和索引选择性3.多列索引4.抉择适合的索引列程序5.主键索引自增和uuid的区别6.笼罩索引7.索引和锁 1.独立的列咱们要让mysql正当地应用索引，在查问中，这些索引的列要是“独立的列”。“独立的列”指的是索引列不能是表达式的一部分，也不能是函数的参数。例如，咱们不必用上面这个查问无奈应用 actor_id 列的索引： select actor_id from actor where actor_id + 1 = 5; mysql无奈主动解析actor_id + 1 = 5 ，咱们要养成始终将索引列独自放在比拟符号的一侧。 2.前缀索引和索引选择性有时候须要索引很长的字符列，这会让索引变得大且慢，对于blob,text或者很长的varchar类型的列，必须应用前缀索引，因为mysql不容许索引这些列的残缺长度。窍门在于抉择足够长的前缀以保障较高的选择性，同时又不能太长（节约空间）。为了决定前缀的适合长度，须要找到最常见的值的列表，而后和最常见的前缀列表进行比拟。假如咱们有一张City表每个值都呈现了45~65次，当初查找最频繁的城市前缀，先从3个前缀字母开始每个前缀都比原来的城市呈现的次数更多，因为唯一性降落了，而后咱们减少前缀长度，直到前缀的选择性靠近残缺列的选择性。计算适合的前缀长度另一个办法就是计算残缺列的选择性，并使前缀的选择性靠近于残缺列的选择性。假如残缺列的选择性是0.0312，此时咱们针对不同的列长度来别离计算列选择性。查问显示以后前缀达到7的时候，再减少前缀长度，可选择性的晋升幅度曾经很小了。只看均匀选择性还是不够的，也有例外的状况，须要思考最坏状况下的选择性。均匀选择性会让你认为前缀长度为4或者5的索引曾经足够了，单如果数据分布很不平均，就可能会有陷阱。如果察看前缀为4的最常呈现城市的次数，能够看到显著不平均：前缀索引是一种能使索引更小，更快的无效办法，但另外一方面也有毛病，mysql无奈对前缀索引做order by 和group by ,也无奈应用前缀索引做笼罩扫描。 3.多列索引很多人对多列索引的了解都不够，一个常见的谬误就是，为每个列创立独立的索引，或者一些专家说“把where条件里的列都建设索引”这样含糊的倡议导致的。 4.抉择适合的索引列程序咱们最容易遇到的困惑就是如何建设一个良好的索引列的程序。对于如何抉择索引程序有一个教训法令：将选择性高的列放到索引的最前列。依据B-tree的个性，这个时候索引的确可能最快过滤出须要的行。假如有以下查问：select * from payment where staff_id = 2 and customer_id = 584;此时，能够distinct以下staff_id和customer_id的数量，确定那个列的可选择性更高。 5.主键索引自增和uuid的区别咱们创立两个表，别离为userinfo_incrid 和 userinfo_uuid ，而后主键别离为自增id和uuid，别离往每张表中插入100W行数据，检测一下工夫：留神到UUID主键插入行不仅破费的工夫更长，而且索引占用的空间也更大。一方面是因为主键字段更长，另一方面毫无疑问是因为页决裂和碎片导致的。咱们看看往第一个表中插入数据时，索引产生了什么变动：如图所示，因为主键的值是程序的，所以把InnoDB的每一条记录都存储在上一条记录的前面，当达到页的最大填充因子的时候，下一条记录就会写入新的页中，一旦数据依照这种程序的形式加载，主键页就会近似于被程序的记录填满，这也正是所冀望的后果。比照一下uuid聚簇索引的表插入数据：因为新行的主键值是没有法则的，并不一定比之前的大，所以InnoDB无奈简略地把新行插入到索引的最初，二十须要为新的行寻找适合的地位——通常是两头地位——并且调配空间，这会减少许多的额定工作，并导致数据分布不够优化，下列是一些毛病：1.因为写入是乱序的，InnoDB不得不频繁地做页决裂操作，以便为新的行调配空间。页决裂会导致挪动大量的数据，一次插入起码须要批改三个页。2.因为频繁页决裂，页会变得稠密并被不规则地填充，所以最终数据会有碎片。把这些随机值载入到索引里后，还须要做一次optimize table 来重建表并优化页的填充。因为这个案例能够看出，应用InnoDB时应该尽可能地按住键程序插入数据，并且尽可能地应用枯燥减少的主键值来插入新行。 6.笼罩索引通常大家都会依据查问的where条件来创立适合的索引，然而mysql也能够应用索引来间接获取数据（并不过原表），如果索引的叶子节点中曾经蕴含要查问的数据，那么久没有必要再回表查问了。如果一个索引蕴含所有须要查问字段的值，咱们就称之为笼罩索引。笼罩索引的益处：1.索引条目通常远小于数据行大小，所以如果只须要读取索引，那mysql就会极大地缩小拜访数据量，对于I/O密集型的利用也十分有帮忙，因为索引比数据更小，更容易放入没存中。2.因为索引是依照列值顺序存储的，所以对于IO密集型的范畴查问会比随机从磁盘读取每一行数据的IO要少得多。不是说所有类型的索引都能够成为笼罩索引，索引笼罩必须要存储索引列的值，而哈希索引，全文索引等都不存储列的值，所以mysql只能用b-tree索引做笼罩索引。 7.索引和锁咱们都晓得InnoDB的行锁是由索引实现的，没有索引的话，InnoDB就会锁住所有的行，所以索引能够让查问锁定更少的行。 ...

关于sql:高性能SQL索引基础和优点

索引根底和长处1.索引根底2.索引的类型3.索引的长处注释：1.索引根底根底概念：索引是存储引擎用于疾速找到记录的一种数据结构。要了解mysql中索引是如何工作的，最简略的办法就是去看看一本书的目录（索引）局部，如果想找到一个特定的题目，个别先会看书的目录（索引），找到对应的页码。在mysql中，存储引擎用相似的办法应用索引，首先在索引中找到对应的地位，而后依据匹配的索引找到对应的数据行。（InnoDB索引保留的是主键值，Myisam保留的是行号。）假如咱们要进行如下查问：select first_name from actor where actor_id = 5; 假如actor_id字段上有索引，mysql就会应用该索引找到actor_id为5的行，也就是说，如果该列有索引，mysql会在索引上岸值进行查找，而后返回蕴含该值的数据行。 mysql的索引程序非常重要，因为mysql只能高效地应用索引的最左侧前缀，这点将在后续博客中指出。创立一个蕴含两个列的索引，和创立两个只蕴含一列的索引是大不相同的。 2.索引的类型(1).B-Tree索引个别人在探讨索引的时候，那99%说的都是B-Tree索引,他应用B-Tree数据来存储数据。B-Tree最重要的特点就是，节点的所有值按顺序存储，并且每一个叶子页到根的间隔雷同，咱们都晓得，树形构造的查找时间复杂度都为log(n),因为这种构造，Btree索引可能放慢数据拜访的速度，因为存储引擎不再须要进行全表扫描来获取须要的数据，取而代之的是从索引的根节点开始搜寻。根节点的槽中寄存了指向子节点的指针，存储引擎依据这些指针向上层查找。通过比拟节点的值和要查找的值能够找到适合的指针进入上层子节点，这些指针实际上定义了子节点页中值的上线和上限，最终存储引擎要么找到对应的值，要么记录不存在。B-Tree对索引列是程序组织存储的，所以很适宜范畴查找。例如：在一个基于varchar类型的索引树上，依照字母程序传递间断的值进行查找是十分适合的，“找出所有A结尾的名字”，这样的查找效率会十分高。假如有如下表CREATE TABLE db.People (last_name varchar(255) NOT NULL,first_name varchar(255) NOT NULL,birthday date NOT NULL,gender varchar(255) NOT NULL, INDEX index_first_name(first_name, last_name, birthday)); 对于表中的每一行数据，索引中蕴含了first_name,last_name,birthday的值，如下索引的程序是依据create table语句中定义索引时列的程序，看一下最初两个条目，因为两个人的名字一样，则依据他们的出生日期来进行排序。 (2).Hash索引哈希索引基于哈希表实现，只有准确匹配索引所有列的查问才无效，对于每一行数据，存储引擎都会对所有的索引列进行计算一个哈希码，而后再去索引中通过哈希码来查找数据的槽。因为是哈希构造，所以查问的咱们由此能够晓得查问的工夫复杂度为O(1),然而它也有以下的限度：哈希索引只反对等值比拟，不反对任何范畴搜寻哈希索引不是依照索引值程序进行存储的，因而无奈用于排序。哈希索引也不反对局部索引匹配查找，因为哈希索引始终是应用索引的全部内容来进行哈希值计算的。拜访哈希索引的数据十分快，除非有很多哈希抵触，当呈现哈希抵触的时候，存储引擎必须遍历链表中的所有行指针，逐行比拟，直到找到所有符合条件的行。如果哈希抵触很多的话，保护索引的代价会很高，例如，如果在某个选择性很低的列上建设哈希索引，那么当从表中删除一行的时候，存储引擎须要遍历对应哈希值的链表中的每一行，找到并删除对银行的利用，抵触越多，代价越大。 3.索引的长处索引能够让服务器疾速定位列表的指定地位，总结下来有三个长处： 1.打打缩小了服务器须要扫描的数据量。2.索引能够帮忙服务器防止排序和长期表。3.索引能够将随机IO转化为程序IO。

关于sql:文末彩蛋数据仓库服务-GaussDBDWS单点性能案例集锦

摘要：介绍了13种GaussDB(DWS)单点性能的案例。1.1 数据歪斜 1.1.1 问题形容某局点SQL执行慢，波及大表的SQL执行不进去后果。 1.1.2 剖析过程数据歪斜在很多方面都会有体现： gs_ssh –c “df -h”查看各个数据磁盘的利用率，会有不平衡的景象。失常状况下，利用率最高和利用率最高的磁盘空间相差不大，如果磁盘利用率相差超过了5%就要引起器重。通过期待视图查看作业的运行状况，发现作业总是期待局部DN，或者个别DN。Select wait_status, count(*) cnt from pgxc_thread_wait_status where wait_status not like ‘%cmd%’ and wait_status not like ‘%none%’ and wait_status not like ‘%quit%’ group by 1 order by 2 desc; 慢语句的explain performance显示，基表scan的工夫和行数各个DN之间不平衡。基表scan的工夫最快的dn耗时5ms，最慢的dn耗时1173ms 数据最多的dn有22831616行，其余dn都是0行，数据有重大歪斜。通过歪斜查看接口能够发现数据歪斜。select table_skewness('store_sales'); select table_distribution('public','store_sales'); 通过资源监控发现，个别节点的CPU/IO显著比其余节点高。1.1.3 问题根因 GaussDB以后反对Hash表和复制表两种散布形式。默认创立的表是Hash散布的，如果不指定散布键，则抉择表的第一列作为散布键。那么这种状况就可能存在歪斜的。歪斜造成的负面影响十分大。首先，SQL的性能会十分差，因为数据只散布在局部DN，那么SQL运行的时候就只有局部DN参加计算，没有施展分布式的劣势。其次，会导致资源歪斜，尤其是磁盘。可能局部磁盘的空间曾经靠近极限，然而其余磁盘利用率很低。可能呈现局部节点CPU过低等等问题。 1.1.4 解决详情如何找到歪斜的表： 1.在库中表个数少于1W的场景，间接应用歪斜视图查问以后库内所有表的数据歪斜状况。 1 SELECT * FROM pgxc_get_table_skewness ORDER BY totalsize DESC; ...

关于sql:帆软FineReport造成数字混乱的原因总结

问题解决办法（1）查看左父格是否正确（如果是将下面一行利落下来的话，那么你将新的一行数据从新抉择左父格的话，那么下面被利落的一行也会被批改左父格，如果你批改下面被利落的一行的左父格的话，那么新的一行的左父格也会被批改，它们两个如同变成了一个人一样，所以咱们能够抉择不通过利落的模式，间接通过 ctrl + c and ctrl + v 来间接操作，不会有下面的这种状况）；（2） ==查看单元格内的公式是否正确==（可能你复制的下面的一行数据，公式复制下来没有批改具体的数据）；（3） ==查看款式==看看是否原本应该是数字模式的，然而你却没有设置，还是惯例模式。总结遇到数据凌乱的状况，执行下面的三种计划，可能不是很全，如果有新的新的状况，缓缓积攒。

关于sql:oracle常用语法

coalescecoalesce(参数列表):返回参数列表中第一个非空参数,最初一个参数通常为常量distinct去重 nvl作用：判断某个值是否为空值，若不为空值则输入，若为空值，返回指定值。专具体解释如下： 1、nvl()函数的格属式如下：NVL(expr1,expr2);2、含意是：如果oracle第一个参数为空那么显示第二个参数的值，如果第一个参数的值不为空，则显示第一个参数原本的值。 3、例：select name,NVL(name,-1) from user；运行后，后果返回两列数值，若name为空，则返回-1，若name不为空值，则返回其本身。 roundround函数用于数据的四舍五入1、round(x,d) ，x指要解决的数，d是指保留几位小数这里有个值得注意的中央是，d能够是正数，这时是指定小数点右边的d位整数位为0,同时小数位均为0； 2、round(x) ,其实就是round(x,0),也就是默认d为0； union与union allunion:去反复,排序union all:不反复也不排序.(举荐) intersect 与 minusintersect 就是交加minus 就是差集交加就是两个后果集中都有的元素比方 select uid from tb1intersectselect uid from tb2那么既存在zhitb1 又存在tb2中雷同的UID 就会查dao进去差集：select uid from tb1minusselect uid from tb2存在于tb1 但不存在与tb2中的uid 会被查出表的复制如果须要对表中的数据进行删除和批改,倡议通过复制表中的数据来对数据进行操作create table 表名 as 查问语句; --将emp表中的数据复制到t_emp表中 create table t_emp as select * from emp; --只须要表的构造 --将emp表的构造复制到t_emp表中 create table t_emp as select * from emp where 1=0;/*提供一个否定条件*/ --只复制一部分数据 --将emp表中部门10的员工的数据复制到t_emp表中 create table t_emp as select * from emp where deptno=10; --将emp表中的员工姓名,工资,年薪保留到t_emp表中 create table t_emp as select ename,sal,sal*12 year_sal /*如果字段中呈现函数或者计算须要提供别名*/ from emp; --统计emp表中部门的人数,将部门编码和人数保留到t_emp表中 create table t_emp(did,ecount) as select deptno,count(ename) from emp group by deptno; 留神:表的复制只会复制表中的数据,不会复制表中的束缚伪列rowid,rownumselect rowid from dual;rowid:是一个伪列,Oracle独有的.每一条记录的rowid 的记录是惟一的 ...

关于sql:SQL-SEVER创建登录帐号

因为差不多2年没有用过sql sever,刚刚又开始接触感觉很生疏。用于温习sql sever,做了一下集体笔记。便于当前好温习。创立服务器登录帐号： (申明：用命令创立帐号不会，或者当前须要再增加到帖子外面。) 1、创立数据库用户前检测是否开启数据库混合登录。用管理员身份登录数据库，右键数据库根目录关上【服务器属性】【安全性】设置混合登录。设置完混合登录后要重启服务器。重启服务器，右键左侧的服务器【进行】，再右键服务器【开启】。这样就不用到【治理】中的【服务】重启数据库。 2、设置登录帐号，并且要设置是否可登录帐号和拜访服务器。应用管理员身份登录数据库，关上据库根目录并关上【安全性】【登录名】，右键【登录名】关上【新建登录名】。创立新的登录账户，在【登录名-新建】设置登录的身份是windows身份验证还是SQL Server身份验证之类的。备忘了设置帐号可用的数据库，不然你创立了帐号也用不了想要用的数据库。在【登录名-新建】【用户映射】里设置该用户的拜访数据库。为什么创立了帐号缺登录不了呢?这个还是要波及【登录名-新建】【状态】设置。把【是否容许连贯到数据库引擎】和【登录】流量交易这两项设置好。

关于sql:有了这-4-款工具老板再也不怕我写烂SQL了

你对于正在运行的mysql 性能如何？参数设置的是否正当？账号设置的是否存在安全隐患？是否了然于胸？俗话说工欲善其事，必先利其器，定期对你的MYSQL数据库进行一个体检，是保障数据库安全运行的重要伎俩。明天和大家分享几个mysql 优化的工具，你能够应用它们对你的mysql进行一个体检，生成awr报告，让你从整体上把握你的数据库的性能状况。 1、mysqltuner.pl 这是mysql一个罕用的数据库性能诊断工具，次要查看参数设置的合理性包含日志文件、存储引擎、平安倡议及性能剖析。针对潜在的问题，给出改良的倡议，是mysql优化的好帮手。在上一版本中，MySQLTuner反对MySQL / MariaDB / Percona Server的约300个指标。我的项目地址：https://github.com/major/MySQ... 1.1 下载 [root@localhost ~]#wget https://raw.githubusercontent.com/major/MySQLTuner-perl/master/mysqltuner.pl 1.2 应用 [root@localhost ~]# ./mysqltuner.pl --socket /var/lib/mysql/mysql.sock>> MySQLTuner1.7.4- MajorHayden<major@mhtx.net>>> Bug reports, feature requests, and downloads at http://mysqltuner.com/>> Runwith'--help'for additional options and output filtering[--] Skipped version check forMySQLTuner scriptPlease enter your MySQL administrative login: rootPlease enter your MySQL administrative password: [OK] Currently running supported MySQL version 5.7.[OK] Operating on 64-bit architecture 1.3、报告剖析 ...

关于sql:实时数仓以upsert的方式读写Kafka数据以Flink112为例

在某些场景中，比方GROUP BY聚合之后的后果，须要去更新之前的后果值。这个时候，须要将 Kafka 音讯记录的 key 当成主键解决，用来确定一条数据是应该作为插入、删除还是更新记录来解决。在Flink1.11中，能够通过 flink-cdc-connectors 我的项目提供的 changelog-json format 来实现该性能。对于该性能的应用，见之前的分享Flink1.11中的CDC Connectors操作实际。在Flink1.12版本中，新增了一个 upsert connector(upsert-kafka)，该 connector 扩大自现有的 Kafka connector，工作在 upsert 模式（FLIP-149）下。新的 upsert-kafka connector 既能够作为 source 应用，也能够作为 sink 应用，并且提供了与现有的 kafka connector 雷同的基本功能和持久性保障，因为两者之间复用了大部分代码。本文将以Flink1.12为例，介绍该性能的根本应用步骤，以下是全文，心愿对你有所帮忙。公众号『大数据技术与数仓』，回复『材料』支付大数据资料包Upsert Kafka connector简介Upsert Kafka Connector容许用户以upsert的形式从Kafka主题读取数据或将数据写入Kafka主题。当作为数据源时，upsert-kafka Connector会生产一个changelog流，其中每条数据记录都示意一个更新或删除事件。更精确地说，如果不存在对应的key，则视为INSERT操作。如果曾经存在了绝对应的key，则该key对应的value值为最初一次更新的值。用表来类比，changelog 流中的数据记录被解释为 UPSERT，也称为 INSERT/UPDATE，因为任何具备雷同 key 的现有行都被笼罩。另外，value 为空的音讯将会被视作为 DELETE 音讯。当作为数据汇时，upsert-kafka Connector会生产一个changelog流。它将INSERT / UPDATE_AFTER数据作为失常的Kafka音讯值写入(即INSERT和UPDATE操作，都会进行失常写入，如果是更新，则同一个key会存储多条数据，但在读取该表数据时，只保留最初一次更新的值)，并将 DELETE 数据以 value 为空的 Kafka 音讯写入（key被打上墓碑标记，示意对应 key 的音讯被删除）。Flink 将依据主键列的值对数据进行分区，从而保障主键上的音讯有序，因而同一主键上的更新/删除音讯将落在同一分区中依赖为了应用Upsert Kafka连接器，须要增加上面的依赖 <dependency> <groupId>org.apache.flink</groupId> <artifactId>flink-connector-kafka_2.12</artifactId> <version>1.12.0</version></dependency> 如果应用SQL Client，须要下载flink-sql-connector-kafka_2.11-1.12.0.jar，并将其搁置在Flink装置目录的lib文件夹下。 ...

关于sql:九个最容易出错的-Hive-sql-详解及使用注意事项

浏览本文小倡议：本文适宜细嚼慢咽，不要一目十行，不然会错过很多有价值的细节。文章首发于公众号：五分钟学大数据前言在进行数仓搭建和数据分析时最罕用的就是 sql，其语法简洁明了，易于了解，目前大数据畛域的几大支流框架全副都反对sql语法，包含 hive，spark，flink等，所以sql在大数据畛域有着不可代替的作用，须要咱们重点把握。在应用sql时如果不相熟或不认真，那么在进行查问剖析时极容易出错，接下来咱们就来看下几个容易出错的sql语句及应用注意事项。注释开始1. decimalhive 除了反对 int,double,string等罕用类型，也反对 decimal 类型，用于在数据库中存储准确的数值，罕用在示意金额的字段上注意事项：如：decimal(11,2) 代表最多有11位数字，其中后2位是小数，整数局部是9位；如果整数局部超过9位，则这个字段就会变成null，如果整数局部不超过9位，则原字段显示；如果小数局部有余2位，则前面用0补齐两位，如果小数局部超过两位，则超出局部四舍五入；也可间接写 decimal，前面不指定位数，默认是 decimal(10,0) 整数10位，没有小数 2. location表创立的时候能够用 location 指定一个文件或者文件夹create table stu(id int ,name string) location '/user/stu2';注意事项：创立表时应用location，当指定文件夹时，hive会加载文件夹下的所有文件，当表中无分区时，这个文件夹下不能再有文件夹，否则报错。当表是分区表时，比方 partitioned by (day string)，则这个文件夹下的每一个文件夹就是一个分区，且文件夹名为 day=20201123这种格局，而后应用：msck repair table score; 修复表构造，胜利之后即可看到数据曾经全副加载到表当中去了 3. load data 和 load data local从hdfs上加载文件load data inpath '/hivedatas/techer.csv' into table techer;从本地零碎加载文件load data local inpath '/user/test/techer.csv' into table techer;注意事项：应用 load data local 示意从本地文件系统加载，文件会拷贝到hdfs上应用 load data 示意从hdfs文件系统加载，文件会间接挪动到hive相干目录下，留神不是拷贝过来，因为hive认为hdfs文件曾经有3正本了，没必要再次拷贝了如果表是分区表，load 时不指定分区会报错如果加载雷同文件名的文件，会被主动重命名4. drop 和 truncate删除表操作drop table score1;清空表操作truncate table score2;注意事项： ...

关于sql:深度干货异构数据的SQL一站式解决方案

在近期的GDG开发者大会广州站上，个推高级技术总监董霖以“异构数据的SQL一站式解决方案”为主题，深刻分享了个推在SQL畛域多年的实战经验。本文将从三方面论述对立SQL：一、为什么要对立SQL 二、如何对立SQL 三、个推对立SQL实际（以下依据演讲内容整顿） 01为什么要对立SQL 数据作业是多兵种单干的战场公司外部围绕数据发展的工作，须要数据分析师、数据研发工程师、运维工程师、甚至产品经营人员共同完成，沟通和合作的效率成为关键性因素。数据存储引擎目迷五色随着大数据行业的倒退，数据存储引擎目前处于百花齐放的阶段，新兴技术层出不穷：如关系型数据库，包含MySQL、Oracle、SQL Server以及蚂蚁推出的OceanBase等；NoSQL计划，包含Redis、Aerospike、MongoDB等；基于Hadoop体系的计划，包含Hive、HBase等；以及目前比拟炽热的NewSQL方向，包含Greenplum、TiDB、Doris、ClickHouse等。各式各样的存储引擎让不少参加数据作业的人感到茫然，不晓得该抉择什么样的形式。开发者要花十分多的老本不停地尝试各种计划，以应答市场需求。开发者须要精确理解数据存在哪里、字段格局怎么、数据表间的关系怎么、数据如何操作等信息，技术人员和业务人员还须要花很多工夫把握各种存储引擎的性能和个性。多样的数据存储计划引擎抉择类型多、学习老本高除了存储引擎，计算引擎的抉择也给大家带来困扰。Spark和Flink各有千秋，也各自在疾速倒退和互相学习交融。另外机器学习引擎也有很多计划，比方Tensorflow、PyTorch以及计算引擎中携带的机器学习算法库，但这些计划的学习老本比拟高，经常令开发者感到纠结，难以抉择。工作语言不对立存储引擎和计算引擎具备繁多的计划，会给协同工作带来较大的语言障碍。对于分析师来说，日常大量应用的次要是SQL，然而有些时候也会应用Python、Shell脚本等形式实现数据处理。数据建模人员次要依赖Python，而数据研发人员则次要应用Java和Scala来开发实时工作。产品经营人员甚至会应用Excel来实现一些简略的剖析工作。当然，大多数时候他们还是将需要表白给数据分析师，由分析师来帮助实现。语言障碍也在肯定水平上限度了合作的效率，在资源调配上也不足灵活性。比方基于Spark或Flink的实时工作目前只能由数据研发同学实现，这很容易造成工作积压。 “对立SQL”天时地利人和如果咱们认真思考，其实会发现数据处理实质上是数仓的加工解决，而各类数据作业都可形象为数仓的ETL过程，即数据的提取（extract）、转换（transform）和加载（load）。目前来看，SQL是形容数据处理流程最优的DSL（Domain Specific Language），是事实标准。在目前大环境下推广对立SQL的解决方案是大势所趋，具备天时地利人和的根本条件： • 地利：数据体量增长，计算、人力、沟通成本增加，为企业不能接受之重； • 天时：支流关系型数据库、MPP数据库、计算引擎、ES、甚至NoSQL计划曾经或者打算反对SQL语法； • 人和：SQL语言易于上手，外围性能只有9个动词；分析师、建模师、数据研发甚至产品经营等非技术人员都能够疾速把握SQL这门语言。咱们认为能够通过对立SQL的形式去实现二八准则的转换，即从目前把80%的工夫花在20%的惯例数据作业上，转变成用20%的工夫就能够实现80%的惯例数据作业。这样咱们就能够有更多的工夫去解决更简单的工作，去思考数据的价值。 02如何对立SQL要想实现SQL的对立，咱们认为需满足四大外围需要：元数据买通、跨数据源、反对离线和实时计算、反对机器学习。先以一个典型的离线计算场景为例，咱们心愿通过简略的SQL即可达成指标，即用Hive数据与MySQL数据相交融，而后回写到HBase。 `update hbase.biz.user_balances as aset a.balance = ret.balancefrom (select b.uid, c.balance from hive.warehouse.users as b inner join mysql.biz.balances as c on b.uid = c.uid) as retwhere a.uid = ret.uid` 相似的，如果是一个典型的实时计算场景，咱们也心愿能通过一个简略的SQL来实现Kafka数据流与MySQL的交融再回写到Redis这样的需要，例如： `update redis.dashboard.brands as aset a.cnt = ret.cntfrom ...