一、关于Dataphin（智能数据建设与治理）Dataphin是阿里巴巴集团数据治理方法论基于内部实践的产品化输出，致力于帮助各企业用中台方法论治理企业级好数据，构建起质量可靠、消费便捷、生产安全经济的企业级数据中台。Dataphin支持在多种大数据架构之上构建数据中台，具备一站式数据采、建、管、用全生命周期管理能力，显著提升数据治理水平，在计算引擎利旧降本基础上满足企业多元化数智应用需求，为企业上云用数赋智夯实数字化能力底座。二、DataphinV3.6版本概览01-拓展多引擎、多类型数据源、多消息渠道，满足企业多元化数智应用需求 ADB引擎适配：新增适配以AnalyticDB for PostgreSQL作为计算引擎，可支持数据集成、离线&实时数据研发、数据质量、资产安全、数据服务等功能，助力企业构建统一的数据仓库平台。数据源拓展：新增支持达梦数据源可用于离线集成、提升对国产数据库的支持度；Hive及HDFS的数据源增加EMR版本选择，实时集成输出组件新增支持Hive，增强对Hive数据源的适配度。自定义消息渠道：支持自定义消息发送渠道，通过配置化的方式实现与阿里云电话&短信、企业自有消息渠道的对接，以接收任务监控、质量监控、数据服务监控等告警信息。02-贯穿事前规划、事中监控、事后稽核的全链路数据治理能力概念建模：可视化定义基于实际业务场景抽象出的业务实体及关系，以更好地反映业务之间的联系，并为逻辑模型建设提供依据。智能基线监控：支持配置天基线，添加需要保障的关键任务或字段后，系统可基于依赖关系自动圈选需要纳入监控范围的任务，同时支持配置灵活的告警规则及接收方式，以降低人工运维成本。全域数据质量：拓展支持针对多种数据源表的质量监控，内置丰富的质量规则模板，同时支持基于业务场景自定义监控规则，以提升配置灵活性和业务监控覆盖面。数据标准落标：新增支持批量导入数据标准，提升配置效率；支持基于标准属性和字段元数据进行关联映射配置，实现标准和资产的关联，作为后续落标稽核的基础。03-研发体验优化，加速企业数字能力建设编辑器优化：优化报错提示，可快速定位到错误代码行并提示错误原因及修复建议；新增set参数提示，可查看参数的默认值、类型及说明，提升数据开发效率。集成组件优化：Orcale组件适配特殊字符的处理以减少运行报错，hologres组件支持填写SQL准备及完成语句，hana组件支持小写表名等，降低集成任务配置成本补数据优化：支持一键过滤下游暂停调度的任务极其全部下游，以保障补数据整体链路可正常执行，减少人工筛选成本脱敏方式拓展：支持配置底层查询直接过敏或仅展示脱敏，以支持简单的where/join等子查询场景，对业务使用更友好三、新版本重点特性详解及应用场景示例特性1：基础研发版支持AnalyticDB PostgreSQL计算引擎应用场景：构筑可线性扩展的企业数据仓库服务，加速企业数据分析和运营体系搭建AnalyticDB PostgreSQL强兼容PG/Greenplum开源生态，兼容Oracle/TD语法生态，具备秒级弹性和数据共享等国内领先的产品能力；支持复杂SQL优化、海量数据关联聚合、资源负载管理，可提供PB级企业数据分析服务。Dataphin基础研发版支持以AnalyticDB PostgreSQL作为计算引擎，用户现有的OLTP数据库实例，如RDS MySQL，PostgreSQL，或传统数据库实例 Oracle，SQL Server等，均可以通过Dataphin的数据集成和调度能力同步到AnalyticDB PostgreSQL；结合数据质量监控、安全分类分级及脱敏配置等功能，打通入库、清洗、分析和洞察的全链路，助力企业构建统一的数据仓库平台，加速面向业务场景的数据分析和运营体系搭建。特性2：概念建模应用场景： 可视化定义基于实际业务场景抽象出的业务实体及关系，为逻辑模型建设提供依据主题域层级从1级拓展到最多5级，企业可基于主题域更好的构建资产类目体系，实现数据分层管理。新增概念建模能力，在数仓规划及数据架构设计阶段，支持可视化配置基于实际业务场景抽象出的业务实体及其之间的关系，并以实体关系流程图的形式直观展示，有利于数据消费者更好理解数据和数据对应的业务。如制造业中的“原材料采购”场景，可以抽象出“客户、订单、原材料商品、地址”等业务对象，以及“供应商询价、下采购单、财务预付款、供应商发货、到货签收、财务付尾款”等业务活动。此外，业务实体间的关系类型，在原有关联, 继承, 层级的基础之上, 新增前后序、流转、包含关系, 以便更精确的反映真实业务联系。如：“采购”流程包含“供应商发货”和“到货签收”两个事件，两个事件之间是流转关系，而“采购”是“供应商评审”的后续流程。概念模型创建完成后，可基于定义的业务实体快速创建对应的逻辑表，默认继承实体之间的关系并自动翻译为数据表之间的关联逻辑，实现概念模型和逻辑模型的映射，为模型开发提供业务输入和指导。特性3：基线运维应用场景：保障核心业务数据的产出任务，及时发现异常并预警，降低对业务用数的影响1、添加需要保障的任务或字段后，系统将基于依赖关系自动推算需要纳入监控范围的上游节点，降低人工配置成本。配置时只需要关注需要保障产出及时性的核心业务数据对应的任务或字段即可，而无需关心整体依赖链路的上游节点，系统将基于任务之间的依赖关系自动推导计算需要纳入监控范围的节点。这样一来，即使更新了任务依赖关系，也无需更新基线配置，大大降低了人工操作成本；同时也提升了监控准确性，避免因为配置不同步而导致的监控缺失。2、可自定义配置基线整体的预警及破线告警、基线监控范围内单个节点的运行出错或变慢告警，便于及时发现异常并处理。可以将需要保障数据的预计产出时间配置为基线的“保障时间”；同时可以根据任务复杂度和业务重要程度，预估任务运行出现异常可能需要的处理时间，将其配置为基线的“余量”，承诺时间-余量即为基线的预警时间。周期运行过程中，系统将根据基线链路上每个节点最近7天的历史运行概况，推算保障节点的预计运行完成时间。如果推算出的时间晚于配置的预警及承诺时间，则会发送基线告警，给开发人员和业务人员对应的通知。此外，还可以给基线链路上的单个任务或字段配置运行变慢或运行出错的告警，便于尽早发现可能出现的异常并处理，保障业务数据能正常产出。3、支持查看每条基线的运行详情，如果存在预警或破线的风险，可自动识别定位到关键路径上的关键实例，便于开发运维人员直接处理，减少人工分析定位。特性4：数据标准应用场景：支持标准和资产的映射关联，以作为质量稽核的参考，提升企业资产治理水平。1、标准属性配置优化，支持批量导入数据标准，提升配置效率。支持配置属性字段的取值类型（自定义输入、枚举单选、枚举多选）及取值约束，同时也可引用码表作为枚举取值来源，以增强标准定义的规范性。如，指标的“业务分类”属性需要来源于企业的“业务系统”码表、“字段长度”属性的取值范围需要限制在0~128字符等。支持下载标准定义模板，并通过上传Excel文件方式批量导入数据标准，实现历史标准的批量迁移入库。支持查看导入执行日志；支持配置导入冲突处理策略；支持一键下载异常记录及异常提示，以提升配置效率。2、支持基于标准属性和元数据字段进行关联映射配置，实现标准和资产的关联，作为后续落标稽核的基础。支持将标准属性和资产元数据进行关联映射配置，实现标准和资产的关联。可以在资产目录查看字段及指标的落标映射结果，以便参考映射到的标准定义进行开发，将数据治理前置到研发链路。针对不满足关联标准的资产，可以尽早进行整改，提升企业整体数字能力建设的标准化成熟和资产的健康度。3、支持码表、词根的定义及管理。码表可用于约束标准属性字段的取值范围，提升标准定义的准确性；词根可作为数据表、字段等研发对象命名的参考依据，提升研发规范性。特性5：全域数据质量应用场景：通过对全域数据表及数据源的监控，将数据质量风险前置，进一步提升资产健康度。1、支持计算引擎内及多种数据源表的质量监控，支持数据源连通性及表结构异动性监控。数据质量模块分为域内版和全域版。其中，域内版可以针对计算引擎内的物理表及字段，以及Dataphin特有的逻辑表、指标和实时元表进行质量监控；同时还支持对已创建数据源的连通性以及监控范围内的表结构异动性进行监控。全域版在支持计算引擎内物理表的基础上，还支持10余种数据源的表监控，如MySQL、Oracle、Hana等。结合使用全域版和域内版的功能，能够拓展可监控的资产对象类型，将数据质量风险前置，降低对后续研发链路的影响。2、基于DAMA体系内置丰富的质量规则模板，开箱即用；可自定义监控规则并支持配置规则触发方式，以灵活适配多样化的业务需求。基于DAMA（国际数据资产管理协会）体系，Dataphin质量模块内置完整性、唯一性、及时性、一致性、有效性、稳定性6类场景的系统模版及规则，大大降低使用门槛；支持自定义SQL的方式创建规则模版，以灵活适配多样性的业务需求。此外，支持配置灵活多样的规则触发条件，如定时触发、代码运行触发、任务调度触发等，可满足不同的开发场景。3、自动生成质量监控报告，支持查看下载异常数据，可作为质量整改的参考。特性6：编辑器优化应用场景：优化报错及参数自动提示，提升开发效率和使用体验。1、报错提示优化：支持快速定位到错误代码行并标识错误语句，提示错误原因及修复建议；可自动识别不规范的代码语句，支持一键修复或忽略提醒。2、支持set参数提示：提示可选的参数，并支持查看参数的默认值、类型及说明；指定参数后，如有默认值或枚举值，自动提示可选值。特性7：实时集成支持增量同步到Hive应用场景：实时增量从MySQL或Oracle抽取数据同步到Hive支持批量在Hive目标库自动建表，可自动为目标表添加系统附加字段；支持处理DDL，如新增表、删除表、表结构变更等8种场景；提供预览字段功能，可查看源表与目标表字段的差异对比，减少手动建表操作。支持智能检查目标表规范性及可用性，针对异常结果给出告警、错误等不同等级的提示，将问题前置以降低任务运行错误的可能性。此外，新增实时集成任务的提交详情，异常及风险提示一目了然，校验流程透明化。特性8：离线集成组件优化应用场景：适配多种数据源的特殊逻辑及异常处理，提升集成任务配置流畅度。输入组件，对PostgreSQL、AnalyticDB for PostgreSQL类型的数据源，在使用QuerySQL方式时，支持添加常量字段Hana组件支持小写表名由于AnalyticDB for PostgreSQL仅支持在建表时指定分区字段，不支持后续添加，因此在整库迁移目标数据源为AnalyticDB for PostgreSQL时，自动添加分区字段，以适配需要创建分区的场景Hologres输出组件支持填写SQL准备语句和完成语句优化Oracle来源表带有特殊字符（如/）时的处理策略，使离线管道任务能正常运行而无需使用自定义组件，降低配置成本特性9：补数据支持过滤暂停节点应用场景：批量选中多层节点进行补数据，可一键过滤暂停节点，避免阻断补数据任务执行。调度方式为“暂停调度”的任务，生成的补数据实例默认为暂停运行。暂停运行的节点会阻断下游其他实例的运行，此外如果选择了多个补数据业务日期且设置为周期间串行（即并发分租数为1），还会影响后续业务日期实例的执行，阻断整个补数据进程。基于该背景，Dataphin新增支持在配置补数据任务时，可一键过滤暂停调度的任务极其下游节点。此外某些场景下，暂停调度的任务在补数据对应的业务日期下需要正常参与调度，如每月第一天运行的财务月结算任务，需要在指定的临时结算日期运行。针对这种场景，新增支持配置选中的暂停任务在选中的补数据业务日期的运行方式，可选空跑、正常运行、暂停运行，以灵活适配多样性的业务求。特性10：脱敏规则支持配置脱敏方式应用场景：通过配置查询时不脱敏仅展示脱敏，以支持简单的where/join等条件，对业务使用更友好数据开发中，常常对一些敏感字段需要配置脱敏规则，以保障数据安全。默认情况下，在整个研发链路中，配置了脱敏规则的数据均使用脱敏后的结果参与计算，会导致where/join等条件不生效的问题，影响业务使用。基于此背景，Dataphin支持针对脱敏规则配置不同的脱敏方式：底层脱敏：在数据被查询时就进行脱敏。SQL的处理过程中，均使用脱敏后的结果处理，能对数据起到更好的保护效果仅展示脱敏：在数据被查询时不进行脱敏，仅在最后对外展示的时候进行脱敏。SQL处理过程中，均使用原文进行处理，因此可以支持简单的where/join等条件，对业务使用更友好。需要注意的是，如果对敏感字段使用UDF处理（如字符串截取），会触发脱敏降级，该字段生成的衍生字段会统一降级为***。通过该能力，开发人员可以根据不同的使用场景配置不同的脱敏策略，以更好地适配业务需求，平衡好数据安全性和使用灵活性。特性11：自定义消息渠道应用场景：快读对接阿里云电话/短信以及企业自有消息渠道，以获取告警及消息通知支持实例级别和租户级别的自由配置，不同租户可开启不同的消息渠道。支持快速对接阿里云的电话及短信渠道，或经过简单的参数配置对接企业自由的消息渠道。配置完成后，支持发送测试消息，以快速验证渠道可用性，保证消息可正常发送。特性12：跨租户发布配置优化应用场景：导入导出配置优化，支持对接外部存储系统，发布流程更顺畅1、导出文件配置优化：新增可设置“是否导出建表语句”；如设置了导出，可在待发布对象列表下载建表文件新增支持设置“是否运行下载发布文件”新增支持发布文件外部存储设置（本期支持启用OSS存储），可设置导出完成后“是否自动转存外部存储”，并支持设置同名文件冲突处理策略；若开启外部存储，待发布对象列表可一键转存并查看转存记录2、导入数据源校验优化：按照“数据源名称”进行匹配，如有名称相同的数据源则校验数据源类型，类型一致则认为在目标环境匹配成功如果未匹配到同名数据源，仅提示风险，不阻断发布（可能导致依赖对应数据源的任务发布失败）四、总结与展望本次发布的V3.6版本中，Dataphin围绕数据资产建设、数据资产治理、基础平台等三大功能板块进行了完备性、安全性、研发效率、开放性、稳定性、易用性、可交付性等方面进行了优化和升级。在下一个版本中，我们将持续提升资产建设平台的易用性及可交付性、资产治理平台的完备性以及基本户平台的稳定性和开放性进行迭代，敬请期待！

2. 采集数据本步骤将指导您如何通过DataWorks采集日志数据至MaxCompute。说明 ：本场景已为您提供OSS数据源和RDS数据源。新建OSS数据源。1.1 双击打开虚拟桌面的Chromium网页浏览器。1.2 在RAM用户登录框中单击下一步，并复制粘贴页面左上角的子用户密码到用户密码输入框，单击登录。1.3 复制下方地址，在Chromium网页浏览器打开新页签，粘贴并访问DataWorks控制台。说明：如果您访问DataWorks控制台时，出现了大数据基础服务使用说明网页，请您刷新网页即可。https://workbench.data.aliyun.com/1.4 在左侧导航栏中，单击工作空间列表。1.5 在工作空间列表页面顶部，选择资源所在地域为上海。1.6 在工作空间列表页面，找到您的资源，单击右侧操作列下的数据集成。说明：您可在云产品资源列表中查看资源的项目名称。1.7 在数据集成首页，单击右上角的 图标。1.8 在左侧导航栏中，单击数据源管理。1.9 在数据源管理页面，单击右上方的新增数据源。1.10 在新增数据源对话框中，选择数据源类型为OSS。1.11 在新增OSS数据源对话框中，配置各项参数，单击更多选项。参数说明：数据源名称：输入oss_workshop_log。Endpoint：输入http://oss-cn-shanghai-internal.aliyuncs.com。Bucket：输入new-dataworks-workshop。AccessKey ID：输入LTAI4FvGT3iU4xjKotpUMAjS。AccessKey Secret：输入9RSUoRmNxpRC9EhC4m9PjuG7Jzy7px。1.12 在警告对话框中，单击确定。1.13 在资源组列表，单击公共资源组右侧的测试连通性。返回如下结果，连通状态为可连通，表示数据集成资源组能够与数据源连通。1.14在新增OSS数据源对话框中，单击完成。新建RDS数据源。2.1 在数据源管理页面，单击右上方的新增数据源。2.2 在新增数据源对话框中，选择数据源类型为MySQL。2.3 在新增MySQL数据源对话框中，配置各项参数，单击更多选项。参数说明：数据源类型：选择连接串模式。数据源名称：输入rds_workshop_log。JDBC URL：输入jdbc:mysql://rm-bp1z69dodhh85z9qa.mysql.rds.aliyuncs.com:3306/workshop。用户名：输入workshop。密码：输入workshop#2017。认证选项：选择无认证。2.4 在资源组列表，单击公共资源组后的测试连通性。返回如下结果，连通状态为可联通，表示数据集成资源组能够与数据源连通。2.5 在新增MySQL数据源对话框中，单击完成。创建业务流程。3.1 在数据源管理页面，单击左上方的 菜单图标，选择全部产品>数据开发与运维>DataStudio（数据开发）。3.2 在数据开发页面，右键单击业务流程，选择新建业务流程。3.3 在新建业务流程对话框中，输入业务名称，例如test，单击新建。3.4 在业务流程开发面板，单击虚拟节点并拖拽至右侧的编辑页面。3.5 在新建节点对话框中，节点名称输入为workshop_start，单击提交。3.6 在业务流程开发面板，单击离线同步并拖拽至右侧的编辑页面。3.7 在新建节点对话框中，节点名称输入为OSS_数据同步，单击提交。3.8 在业务流程开发面板，单击离线同步并拖拽至右侧的编辑页面。3.9 在新建节点对话框中，节点名称输入为rds_数据同步，单击提交。3.10 在右侧的编辑页面，通过拖拽连线，将workshop_start节点设置为两个离线同步节点的上游节点。配置workshop_start节点。4.1 在数据开发页面左侧，选择业务流程>您的业务流程>通用，双击虚拟节点workshop_start。4.2 在该节点的编辑页面，单击右侧的调度配置。4.3 在调度配置面板的时间属性区域，重跑属性选择为运行成功或失败后皆可重跑。在调度配置面板的调度依赖区域，单击使用工作空间根节点，设置workshop_start节点的上游节点为工作空间根节点。说明 ：由于新版本给每个节点都设置了输入输出节点，所以需要给workshop_start节点设置一个输入。此处设置其上游节点为工作空间根节点，通常命名为工作空间名称_root。由于当前实验环境的虚拟桌面浏览器显示问题，如果当前调度配置页面的参数出现了错位，您可以将浏览器的显示百分比设置小一些。4.4 在该节点的编辑页面左上方，单击 图标保存配置。新建表。5.1 在数据开发页面，选择业务流程>MaxCompute，右键单击表，单击新建表。5.2 在新建表对话框中，表名输入ods_raw_log_d，单击新建。5.3 在表ods_raw_log_d的编辑页面上方，单击DDL。5.4 在DDL模式对话框中，输入如下创建OSS日志对应目标表的建表语句，单击生成表结构。CREATE TABLE IF NOT EXISTS ods_raw_log_d ( col STRING ) PARTITIONED BY ( dt STRING );5.5 在确认操作对话框中，单击确认。5.6 在表ods_raw_log_d的编辑页面的基本属性区域，中文名输入为OSS日志对应目标表，单击提交到生产环境。5.7 在提交到生产环境对话框中，单击确认。5.8 在数据开发页面，选择业务流程>MaxCompute，右键单击表，单击新建表。5.9 在新建表对话框中，表名输入ods_user_info_d，单击提交。5.10 在表ods_user_info_d的编辑页面上方，单击DDL。5.11 在DDL模式对话框中，输入如下创建RDS对应目标表的建表语句，单击生成表结构。CREATE TABLE IF NOT EXISTS ods_user_info_d ( uid STRING COMMENT 'uid', gender STRING COMMENT 'gender', age_range STRING COMMENT 'age_range', zodiac STRING COMMENT 'zodiac' ) PARTITIONED BY ( dt STRING );5.12 在确认操作对话框中，单击确认。5.13 在表ods_user_info_d的编辑页面的基本属性区域，中文名输入为RDS对应目标表，单击提交到生产环境。5.14 在提交到生产环境对话框中，单击确认。配置离线同步节点。6.1 在数据开发页面左侧，选择业务流程>您的业务流程>数据集成，双击oss_数据同步。6.2 在oss_数据同步页面的数据来源中，配置如下参数，其他配置保持默认。参数说明：数据源：选择OSS>oss_workshop_log数据源。文件名（含路径）：输入user_log.txt。文件类型：选择text类型。列分隔符：输入列分隔符为|。6.3 在oss_数据同步页面的数据去向中，配置如下参数，其他配置保存默认。参数说明：数据源：选择ODPS>odps_first数据源。表：选择数据源中的ods_raw_log_d表。说明： odps_first数据源是工作空间绑定MaxCompute实例时，系统自动生成的默认数据源。odps_first数据源写入至当前工作空间下的MaxCompute项目中。6.4 在页面右侧，单击调度配置。6.5 在调度配置面板的时间属性区域，重跑属性选择为运行成功或失败后皆可重跑。在调度配置面板的调度依赖区域的本节点的输出中，输入本节点的输出名称为工作空间名称.ods_raw_log_d，单击添加。说明 ：您可在云产品资源列表中查看工作空间名称。6.6 在页面右侧，单击数据集成资源组配置。6.7 在数据集成资源组配置面板，单击更多选项。6.8 在警告对话框中，单击确认。6.9 在数据集成资源组配置面板，方案选择调试资源组。6.10 在上方工具栏中，单击 图标保存配置。6.11 在数据开发页面左侧，选择业务流程>数据集成，双击rds_数据同步。6.12 在rds_数据同步页面的数据来源中，配置如下参数，其他配置保持默认。参数说明：数据源：选择MySQL>rds_workshop_log数据源。表：选择数据源中的ods_user_info_d表。6.13 在rds_数据同步页面的数据去向中，配置如下参数，其他配置保存默认。参数说明：数据源：选择ODPS>odps_first数据源。表：选择数据源中的ods_user_info_d表。6.14 在页面右侧，单击调度配置。6.15 在调度配置面板的时间属性区域，重跑属性选择为运行成功或失败后皆可重跑。在调度配置面板的调度依赖区域的本节点的输出中，输入本节点的输出名称为工作空间名称.ods_user_info_d，单击添加。说明 ：您可在云产品资源列表中查看工作空间名称。6.16 在页面右侧，单击数据集成资源组配置。6.17 在数据集成资源组配置面板，单击更多选项。6.18 在数据集成资源组配置面板，方案选择调试资源组。6.19 在上方工具栏中，单击 图标保存配置。提交业务流程。7.1 在数据开发页面左侧，双击您的业务流程。7.2 在业务流程的编辑页面上方的菜单栏中，单击 提交图标。7.3 在提交对话框中，选择所有的节点，输入备注，选择忽略输入输出不一致的告警，单击提交。返回如下页面， 等待所有节点提交成功，单击 图标关闭即可。运行业务流程8.1 在上方菜单栏中，单击 图标运行。8.2 在业务流程的编辑页面，右键单击rds_数据同步。8.3 在功能列表，单击查看日志。返回结果如下，表示rds_数据同步节点运行成功，并成功同步数据。8.4 在日志页面右上角，单击 图标关闭日志。8.5 在业务流程的编辑页面，右键单击oss_di（即下图中的oss_数据同步）。8.6 在功能列表，单击查看日志。返回结果如下，表示oss_数据同步节点运行成功，并成功同步数据。确认数据是否成功导入MaxCompute。9.1 在数据开发页面的左侧导航栏，单击临时查询。9.2 在临时查询页面左侧，右键单击临时查询，选择新建节点>ODPS SQL。9.3 在新建节点对话框，单击提交。9.4 在SQL查询页签，输入如下SQL语句，单击 图标运行，查看导入ods_raw_log_d和ods_user_info_d的记录数。说明 ：SQL语句中字段dt的参数${bdp.system.bizdate}表示业务日期，例如，任务运行的日期为20220916，则业务日期为20220915，即任务运行日期的前一天。select count(*) from ods_raw_log_d where dt=${bdp.system.bizdate}; select count(*) from ods_user_info_d where dt=${bdp.system.bizdate};9.5 在参数对话框中， 单击确定。9.6 在MaxCompute计算成本估计对话框中， 单击运行。返回如下结果，您可以查看到导入ods_raw_log_d表和ods_user_info_d表的记录数，表示OSS和RDS中的数据成功导入到MaxCompute。

升级概述为什么选择升级到PolarDB MySQL 8.0？PolarDB MySQL 8.0.1 (基于官方MySQL 8.0.13内核版本)发布于2019-12-03和PolarDB MySQL 8.0.2（基于官方MySQL 8.0.18内核版本）发布于2020-07-22*，增强了诸多卓越的架构增强和内核能力，为业务提供更灵活的技术解决方案和强大收益的性能提升，主要包括：Serverless：Serverless数据库能够使得数据库集群资源随客户业务负载动态弹降，将客户从复杂的业务资源评估和运维工作中解放出来。多主集群（库表）：在一个集群中通过多个主节点来实现从一写多读架构到多写多读架构的升级，主要面向SaaS多租户、游戏、电商等高并发读写的应用场景。弹性并行查询（Elastic Parallel Query）：弹性并行查询（Elastic Parallel Query，ePQ）目前支持单机并行和多机并行*两种并行引擎，单机并行引擎等效于原有的并行查询，多机并行引擎支持集群内跨节点的自适应弹性调度*。列存索引（IMCI）：面向OLAP场景大数据量复杂查询。通过列存索引，PolarDB MySQL实现了一体化的实时事务处理和实时数据分析的能力，成为一站式HTAP数据库产品解决方案。通过一套数据库系统，即可满足业务的OLTP及OLAP需求。高压缩引擎（X-Engine）：阿里巴巴自研的基于LSM-tree架构的存储引擎X-Engine提供了强大的数据压缩能力，满足了归档数据库低存储成本的要求。通过LSM-Tree（Log-Structured Merge-Tree）层次化架构和Zstandard（ZSTD）压缩算法实现了更高的数据压缩率，对比使用InnoDB作为存储引擎，最高可节省70%的存储空间。分区表增强：支持更多分区功能增强（全二级分区类型支持、Interval Range分区、List Default Hash分区、异构分区、部分分区索引、全局二级索引等），性能改进（分区MDL锁、动态剪枝、Partition-Wise连接等）帮助客户解决大表性能、运维和管理。冷数据归档：为了降低数据存储成本，PolarDB for MySQL支持将低频使用的冷数据归档到OSS对象存储中，支持冷热数据管理语法和存储过程方式。DDL增强优化：支持并行DDL、秒级加字段、DDL预读、DDL多路归并排序、DDL异步IO、非阻塞DDL等增强了DDL的性能、稳定性和易用性。事务系统增强：全新的事务系统PolarTrans, 它利用提交时间戳技术CTS对高并发在线交易场景进行了优化，可以有效提升数据库的读写性能；同时PolarTrans利用现有的网络基础设施资源，与RDMA技术深度结合，推出高性能集群强一致性读SCC功能。SCC可以确保集群任何RW和RO节点都可以提供写后读的强一致性，通过对强一致性读请求进行RO分流，有效降低了RW节点的负载。在OLTP场景下，极大的提升了集群的整体吞吐能力。SQL优化：包括利用Window Function和Group By Aggregation对子查询解关联；通过CBQT组件（Cost Based Query Transformation）实现基于代价的查询变换，从而大幅提升复杂查询的执行效率；Limit Offset下推、谓词完全下推、扫描完全下推（FastTraverse）和针对HashJoin的Bloom Filter下推能力；Partial Result Cache（简称PTRC）功能来缓存查询语句中算子的中间结果集，来减少这些复杂算子的重复计算，以此来提升查询性能。性能监控增强：Performance Agent是PolarDB提供的一种更加便捷的性能数据统计方案。通过PolarDB MySQL引擎插件的方式，实现PolarDB MySQL引擎集群中的节点内部各项性能数据的采集与统计。SQL Trace功能，用于跟踪SQL语句的执行信息，如：执行计划和执行统计信息（包括扫描行数、执行时间等）。可以帮助您快速地发现因执行计划变更而引发的性能变化，并统计当前集群中占用内存最多的查询语句。另外，PolarDB MySQL 8.0.x版本还受益于官方从各个方面带来的令人兴奋的能力，详细参考《What’s New in MySQL 8.0》：SQL全面增强：支持窗口函数（Window functions）, 公共表表达式（Common Table Expressions）, 优化并发SELECT ... FOR UPDATE的NOWAIT和SKIP LOCKED, 降序索引（Descending Indexes）, Grouping函数, 正则表达式函数（Regular Expressions）, 字符集增强（Character Sets）, 代价模型增强（Cost Model）, 直方图（Histograms），哈希连接（Hash Join）*，横向派生表（LATERAL），[NOT] IN/EXISTS子查询转换增强*，EXPLAIN ANALYZE*，索引级别的优化器HINT，派生表条件下推*TempTable临时表内存引擎：代替MEMORY引擎，更高效的支持VARCHAR和VARBINARY类型。 支持JSON数据*：JSON数据存储、JSON函数、改进排序和部分更新支持GIS数据：空间数据存储、空间类型、空间函数和空间索引 可靠性（Reliability）：基于InnoDB存储的元数据管理和事务性的数据字典改进，使得DDL成为操作和灾难恢复保证安全。 可观测性（Observability）： 显著增强了Performance Schema，Information Schema，配置变量和错误日志。易于运维（Manageability）：支持Undo tablespace管理，支持instant DDL，极大缩短了一些常见DDL的操作。安全（Security） 改进了OpenSSL，增加了新的默认认证方式，SQL角色等等。性能（Performance） InnoDB显著的增进了Read/Write负载、IO bound负载, 和高竞争的热点（hot spot）负载。预检验PolarDB MySQL 5.6/MySQL 5.6 向 8.0 升级过程中，经常遇到的问题主要是性能问题、语法兼容性问题，以及周边组件是否的支持，查询的性能问题一般是由于优化器升级导致执行计划有变，此类问题需要对性能低下的语句进行针对性的性能优化，但性能问题基本不会引发业务报错以及代码的改写问题，此类问题不在本文讨论范围之内。本文主要讨论真实的兼容性问题，此类问题需要在数据库升级过程中，对代码做出对应的更新或环境配置的更改，引发原因主要是版本升级后一些语法的变化以及特性的更新、移除。预检验主要提供一个简要清单来帮助用户在升级前能够更好的了解升级过程中可能注意的问题，如果遇到下列问题，可以到版本升级详细说明章节进行操作和检查。确保没有使用废弃的数据类型、函数和功能，更多信息参考 Features removed in MySQL 8.0 官方文档。确保触发器Triggers没有丢失或者空的definer或无效的内容。确保只有InnoDB引擎的分区表。确保关键字和保留关键字没有冲突，详细参考官方文档 Keywords and reserved words。确保没有和MySQL 5.6的系统数据库没有和MySQL 8.0的新增INNODB_开头的词典表名冲突。确保不依赖于INFORMATION_SCHEMA下的GLOBAL|LOCAL]_[VARIABLES|STATUS]表确保sql_mode中不使用废弃的变量设置。确保表或存储过程单个ENUM或者SET 列元素的长度不得超过 255 个字符或 1020 个字节。确保表分区不在共享InnoDB tablespaces表空间。确保查询SQL中的GROUP BY不带有 ASC or DESC 。确保外键约束名字不超过64字符。为了增强Unicode的支持，考虑将使用utf8mb3字符集（已废弃）的对象改为utf8mb4字符集。另外，同样也需要考虑使用utf8mb4代替utf8，因为utf8是utf8mb3字符集的别名。更多信息参考 The utf8mb3 character set (3-byte UTF-8 unicode encoding) 。如果上述内容确保没有存在，可以跳过下面章节进行升级，请参考《PolarDB for MySQL引擎大版本一键升级》。注意：升级前一定要进行备份，以避免升级过程可能遇到的其他问题。另外，达摩院的DAS团队还推出了智能压测能力，方便客户对新升级实例进行流量回放的压力测试，详细可以了解《智能数据库DAS之智能压测技术》。版本升级详细说明配置兼容性引擎和分区表兼容有关将MyISAM 表转换为 的信息InnoDB，请参阅 第“将表从 MyISAM 转换为 InnoDB”。在PolarDB MySQL 8.0中，将导致使用没有此类型支持的存储引擎分区表创建语句失败并出现错误 ( ER_CHECK_NOT_IMPLEMENTED )。PolarDB MySQL 存储引擎现在负责提供自己的分区处理程序，并且PolarDB MySQL 服务器不再提供通用引擎分区支持。 InnoDB是唯一提供 PolarDB MySQL 8.0 支持的本机分区处理程序的存储引擎。必须在升级服务器之前InnoDB更改使用任何其他存储引擎的分区表将其转换为InnoDB，或删除其分区 - 否则之后无法使用。如有类似分区，需要提前转换引擎后再进行升级，检查语法:SELECT TABLE_SCHEMA, TABLE_NAME FROM INFORMATION_SCHEMA.TABLES  WHERE ENGINE NOT IN ('innodb', 'ndbcluster') AND CREATE_OPTIONS LIKE '%partitioned%'; 或者 SELECT DISTINCT NAME, SPACE, SPACE_TYPE FROM INFORMATION_SCHEMA.INNODB_SYS_TABLES   WHERE NAME LIKE '%#P#%' AND SPACE_TYPE NOT LIKE 'Single';应该更改为InnoDB引擎或删除分区:<mysql> ALTER TABLE part ENGINE = INNODB; Query OK, 0 rows affected (0.09 sec)   OR   <mysql> ALTER TABLE part REMOVE PARTITIONING; Query OK, 0 rows affected (0.06 sec)如果使用 mysqldump从在 MySQL 5.6（或更早版本）中创建的转储文件将数据库导入PolarDB MySQL 8.0 服务器，则必须确保创建分区表的任何语句都不会同时指定不受支持的存储引擎，方法是删除对分区的任何引用，或通过将存储引擎指定为 InnoDB或允许将其设置为 InnoDB默认值。“为升级准备安装”中给出的过程描述了如何识别在升级到 MySQL 8.0 之前必须更改的分区表。有关详细信息，请参阅“与存储引擎相关的分区限制”。字符集&排序规则兼容官方版本 8.0 默认字段集改为 utf8mb4，MySQL/PolarDB MySQL 8.0 默认字符集为了兼容性目前默认 character_set_server 均为 utf8，可以按业务需求调整，为了改进 Unicode 支持，请考虑将使用该字符集的对象转换utf8mb3为使用该utf8mb4字符集。不推荐使用utf8mb3字符集。另外，考虑使用utf8mb4字符集引用而不是 utf8，因为当前 utf8是utf8mb3字符集的别名。有关详细信息，请参阅 utf8mb3 字符集（3 字节 UTF-8 unicode 编码）在 MySQL 文档中。官方MySQL版本 8.0 新增了 default_collation_for_utf8mb4 参数，此参数的作用是在字符集为 utf8mb4 时，默认排序规则，默认值为 utf8mb4_0900_ai_ci，官方文档注明只是为MySQL Replication使用的内部参数，所以建议如果没有从低版本同步过程中遇到Illegal mix of collations错误前不建议修改该默认值为utf8mb4_general_ci/utf8_general_ci。utf8mb4_unicode_ci 是基于官方Unicode的规则来做通用的排序和比较，准确度高，但比对速度稍慢。utf8mb4_general_ci 是精简集合的排序规则，目的是提供简化的一个设计来加快速度，虽然没有去遵循Unicode的规则，但是结果在相同情况下是符合预期的。排序规则和字符集不同，它之和排序和比较有关系，其中ai指的是口音不敏感。也就是说，排序时e，è，é，ê和ë之间没有区别， ci表示不区分大小写。也就是说，排序时p和P之间没有区别。注意事项比如在 8.0向低版本反向同步或者 dump 同步时，有可能导致脚本不支持，比较容易在 DTS 低版本与高版本双向同步场景下出现，需要使用5.6默认的排序字符集，否则DTS反向同步的时候会有异常。创建视图可能会报错Illegal mix of collations 原因也是由于排序规则问题，如使用 convert(a.c1 using utf8mb4) = b.c1原因是使用 convert(exp using utf8mb4)，不指定 collation，MySQL 按照 utf8mb4 查询，返回的 charset number 总是 255，255 对应的 collation 就是 MySQL 8.0 默认的 utf8mb4_0900_ai_ci。修改 default_collation_for_utf8mb4，或者是 ddl 里面指定 column，table， db 的 collation 都不会起作用。 如果一定要用 convert，可以明确带上 collation，类似这样写 (convert(a.c1 using utf8mb4) collate utf8mb4_general_ci) = b.c1修改 default_collation_for_utf8mb4 默认值如utf8mb4_unicode_ci，会导致SYS库无法读取及其相关函数无法读取，报错“Illegal mix of collations (utf8mb4_unicode_ci,IMPLICIT) and (utf8mb4_0900_ai_ci,IMPLICIT) for operation '='”，也会导致会导致从PolarDB 8.0.1升级到PolarDB 8.0.2失败，因为该参数是8.0的新参数，所以建议不要修改该参数，如果必须使用其他值，请升级前提工单重置为默认utf8mb4_0900_ai_ci升级后修改回来。参数兼容lower_case_table_names从 MySQL 8.0.11 开始，禁止 lower_case_table_names 使用与服务器初始化时使用的设置不同的设置来启动服务器。该限制是必要的，因为各种数据字典表字段使用的排序规则基于 lower_case_table_names 服务器初始化时定义的设置，并且使用不同的设置重新启动服务器会在标识符的排序和比较方式方面引入不一致。实例区分大小写在 8.0 版本中，无法在初始化完成后再次更改，需要在购买PolarDB MySQL 8.0实例时选定。sql_mode为避免PolarDB MySQL 8.0 上的启动失败，请NO_AUTO_CREATE_USER从 sql_modeMySQL 选项文件中的系统变量设置中删除任何实例。sql_mode您的系统变量设置中不得定义过时的 SQL 模式，sql_mode 会引起许多行为的不同，在版本升级时需要确认对齐。取消如下配置项:DB2, MAXDB, MSSQL, MYSQL323, MYSQL40, ORACLE, POSTGRESQL, NO_FIELD_OPTIONS , NO_KEY_OPTIONS, NO_TABLE_OPTIONS以上配置项大多为组合配置，需要注意是否有不一致的 mode 选项，如: sql_mode=TRADITIONAL等于配置如下项: STRICT_TRANS_TABLES, STRICT_ALL_TABLES, NO_ZERO_IN_DATE, NO_ZERO_DATE, ERROR_FOR_DIVISION_BY_ZERO, NO_ENGINE_SUBSTITUTION. 在 5.6 默认配置时，sql_mode=TRADITIONAL等于配置如下项: STRICT_TRANS_TABLES, STRICT_ALL_TABLES, NO_ZERO_IN_DATE, NO_ZERO_DATE, ERROR_FOR_DIVISION_BY_ZERO, NO_AUTO_CREATE_USER, and NO_ENGINE_SUBSTITUTION.可以看到 5.6 多了 NO_AUTO_CREATE_USER 项，但其实 8.0 已经禁止使用 GRANT 语句隐式创建账号，5.6 虽然添加了NO_AUTO_CREATE_USER 选项，但在指定 identified by 时，同样可以使用 GRANT 创建账号。如果您发现 ONLY_FULL_GROUP_BY启用导致对现有应用程序的查询被拒绝，则这些操作中的任何一个都应该恢复操作：如果可以修改有问题的查询，请这样做，以便非确定性非聚合列在功能上依赖于GROUP BY列，或者通过使用 ANY_VALUE().如果无法修改有问题的查询（例如，如果它是由第三方应用程序生成的），请将sql_mode服务器启动时的系统变量设置为 not enable ONLY_FULL_GROUP_BY。例如，当描述不是的一部分GROUP BY，并且没有应用聚合函数（例如MIN或MAX）时，就会发生这种情况。以前的行为：SELECT id, invoice_id, description FROM invoice_line_items GROUP BY invoice_id;   +----+------------+-------------+   | id | invoice_id | description |   +----+------------+-------------+   | 1 | 1 | New socks             |   | 3 | 2 | Shoes                 |   | 5 | 3 | Tie                   |   +----+------------+-------------+   3 rows in set (0.00 sec)PolarDB MySQL 8.0：SELECT id, invoice_id, description FROM invoice_line_items GROUP BY invoice_id;   ERROR 1055 (42000): Expression #3 of SELECT list is not in GROUP BY clause and contains nonaggregated column 'invoice_line_items.description' which is not functionally dependent on columns in GROUP BY clause; this is incompatible with sql_mode=only_full_group_byINFORMATION_SCHEMA系统和状态变量信息的表5.6中INFORMATION_SCHEMA具有包含系统和状态变量信息的表在8.0中被废弃，INFORMATION_SCHEMA.GLOBAL_VARIABLES INFORMATION_SCHEMA.SESSION_VARIABLES INFORMATION_SCHEMA.GLOBAL_STATUS INFORMATION_SCHEMA.SESSION_STATUS在8.0中迁移至PERFORMANCE_SCHEMA中，performance_schema.global_variables performance_schema.session_variables performance_schema.variables_by_thread performance_schema.global_status performance_schema.session_status performance_schema.status_by_thread performance_schema.status_by_account performance_schema.status_by_host performance_schema.status_by_user直接使用该视图的应该尽量使用SHOW命令进行代替，而非直接使用相应的视图SHOW VARIABLES SHOW STATUS视图/表以及关键词InnoDB相关视图INFORMATION_SCHEMA基于InnoDB系统表的视图被数据字典表的内部系统视图取代。受影响 InnoDB INFORMATION_SCHEMA的视图已重命名：，如果系统应用中有直接访问 InnoDB 相关视图，需要确认应用中是否已经修改。重命名的 InnoDB 信息模式视图旧名称新名字INNODB_SYS_COLUMNSINNODB_COLUMNSINNODB_SYS_DATAFILESINNODB_DATAFILESINNODB_SYS_FIELDSINNODB_FIELDSINNODB_SYS_FOREIGNINNODB_FOREIGNINNODB_SYS_FOREIGN_COLSINNODB_FOREIGN_COLSINNODB_SYS_INDEXESINNODB_INDEXESINNODB_SYS_TABLESINNODB_TABLESINNODB_SYS_TABLESPACESINNODB_TABLESPACESINNODB_SYS_TABLESTATSINNODB_TABLESTATSINNODB_SYS_VIRTUALINNODB_VIRTUAL在 5.6 版本中不能存在 8.0 中新增的同名视图，在 5.6 实例中执行如下语句，如果有返回则需要确认如何对此类表进行处理，此项检查建议在自建实例上云升级时执行 SELECT TABLE_SCHEMA, TABLE_NAME FROM INFORMATION_SCHEMA.TABLES WHERE LOWER(TABLE_SCHEMA) = 'mysql' and LOWER(TABLE_NAME) IN ( 'catalogs', 'character_sets', 'check_constraints', 'collations', 'column_statistics', 'column_type_elements', 'columns', 'dd_properties', 'events', 'foreign_key_column_usage', 'foreign_keys', 'index_column_usage', 'index_partitions', 'index_stats', 'indexes', 'parameter_type_elements', 'parameters', 'resource_groups', 'routines', 'schemata', 'st_spatial_reference_systems', 'table_partition_values', 'table_partitions', 'table_stats', 'tables', 'tablespace_files', 'tablespaces', 'triggers', 'view_routine_usage', 'view_table_usage' ); Suppose +--------------+------------+ | TABLE_SCHEMA | TABLE_NAME | +--------------+------------+ | mysql        | catalogs   | +--------------+------------+ 1 row in set (0.00 sec)因此，此类用户表应在升级前重命名或删除：mysql>ALTER TABLE catalogs RENAME user_catalogs; Query OK, 0 rows affected (0.05 sec)   OR   mysql> DROP TABLE catalogs; Query OK, 0 rows affected (0.06 sec)视图兼容在 MySQL 8.0 之前，用户可以创建具有最多 255 个字符的显式列名的视图。为遵守列名的最大长度，MySQL 8.0 不支持显式列名超过 64 个字符的视图。目前这些视图只能通过  在 MySQL 5.6 中执行SHOW CREATE VIEW来识别。mysql> SHOW CREATE VIEW v1; +------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+----------------------+----------------------+ | View | Create View                                                                                                                                                                  | character_set_client | collation_connection | +------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+----------------------+----------------------+ | v1   | CREATE ALGORITHM=UNDEFINED DEFINER=`root`@`localhost` SQL SECURITY DEFINER VIEW `v1` AS select 1 AS `a123456789012345678901234567890123456789012345678901234567890123456789` | utf8                 | utf8_general_ci      | +------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+----------------------+----------------------+ 1 row in set (0.00 sec应在升级PolarDB MySQL 8.0前修改视图名字mysql> ALTER VIEW v1(a12345678901234567890) AS SELECT 1;系统表兼容mysql.user系统表的 Password列 mysql.user在 MySQL 5.7.6 之后及8.0中被删除。所有凭据都存储在该 authentication_string列中，包括以前存储在该Password 列中的那些。INNODB表兼容DYNAMIC替换 COMPACT为InnoDB表的隐式默认行格式。一个新的配置选项，innodb_default_row_format指定默认的InnoDB行格式。允许DYNAMIC的值包括（默认值）COMPACT、 和 REDUNDANT。升级到PolarDB MySQL 8.0 后，您创建的任何新表都使用定义的行格式，innodb_default_row_format 除非您明确定义行格式 ( ROW_FORMAT)。对于未显式定义 ROW_FORMAT选项或使用 的现有表ROW_FORMAT=DEFAULT，任何重建表的操作也会默默地将表的行格式更改为定义的格式 innodb_default_row_format。否则，现有表将保留其当前行格式设置。有关详细信息，请参阅定义表的行格式。类型兼容枚举和集合类型兼容表或存储过程的单个ENUM或SET列元素的长度不得超过 255 个字符或 1020 个字节。YEAR类型YEAR(2) 类型废弃，需要用YEAR(4) 替换。类型数据插入兼容将负值插入无符号列会报错创建一个包含无符号列的表：CREATE TABLE test (id int unsigned);插入一个负值，以前的行为：INSERT INTO test VALUES (-1); Query OK, 1 row affected, 1 warning (0.01 sec)PolarDB MySQL 8.0的行为：INSERT INTO test VALUES (-1);   ERROR 1264 (22003): Out of range value for column 'a' at row 1除以零会报错创建测试表：CREATE TABLE test2 (id int unsigned);尝试除以零，以前的行为：INSERT INTO test2 VALUES (0/0);   Query OK, 1 row affected (0.01 sec) PolarDB MySQL 8.0的行为：INSERT INTO test2 VALUES (0/0);   ERROR 1365 (22012): Division by 0字符超长插入报错将 20 个字符的字符串插入 10 个字符的列会报错，创建一个包含 10 个字符的列的表：CREATE TABLE test3 (a varchar(10));尝试插入更长的字符串，以前的行为：INSERT INTO test3 VALUES ('abcdefghijklmnopqrstuvwxyz');  Query OK, 1 row affected, 1 warning (0.00 sec)PolarDB MySQL 8.0的行为：INSERT INTO test3 VALUES ('abcdefghijklmnopqrstuvwxyz');   ERROR 1406 (22001): Data too long for column 'a' at row 1非标准零日期插入日期时间列会报错创建一个包含日期时间列的表：CREATE TABLE test3 (a datetime);插入0000-00-00 00:00:00，以前的行为：INSERT INTO test3 VALUES ('0000-00-00 00:00:00');   Query OK, 1 row affected, 1 warning (0.00 sec)PolarDB MySQL 8.0的行为：INSERT INTO test3 VALUES ('0000-00-00 00:00:00');   ERROR 1292 (22007): Incorrect datetime value: '0000-00-00 00:00:00' for column 'a' at row 15.x 旧式类型兼容旧式decimal、旧式varchar、旧式TIME/DATETIME 和 TIMESTAMP类型等数据类型分别在 MySQL 5.1 、 MySQL 5.0 和 MySQL 5.6 中已过时，由于二进制升级而一直持续到 MySQL 5.6 将不被支持在 MySQL 8.0 中。这些表可以通过在升级前在 MySQL 5.6 中运行CHECK TABLE…FOR UPGRADE 或带有check-upgrade选项的 mysqlcheck 来识别。此外，使用旧式T IME/DATETIME 和 TIMESTAMP的表可以通过启用会话变量来识别，参考"How to Easily Identify Tables With Temporal Types in Old Format!"。mysql> check table 41_decimal for upgrade; +-----------------+-------+----------+-------------------------------------------------------------------------------------+ | Table           | Op    | Msg_type | Msg_text                                                                            | +-----------------+-------+----------+-------------------------------------------------------------------------------------+ | test.41_decimal | check | error    | Table upgrade required for `test`.`41_decimal`. Please dump/reload table to fix it! | +-----------------+-------+----------+-------------------------------------------------------------------------------------+ 1 row in set (0.00 sec)   mysql> check table 55_temporal for upgrade; +------------------+-------+----------+------------------------------------------------------------------------------------------+ | Table            | Op    | Msg_type | Msg_text                                                                                 | +------------------+-------+----------+------------------------------------------------------------------------------------------+ | test.55_temporal | check | error    | Table upgrade required. Please do "REPAIR TABLE `55_temporal`" or dump/reload to fix it! | +------------------+-------+----------+------------------------------------------------------------------------------------------+ 1 row in set (0.00 sec)   nisha@nisha-PORTEGE-Z30-A:~/workspace1/mysql-5.6/dbg-5.6/client/mysqlcheck --user=root --socket=/home/nisha/workspace1/mysql-5.6/dbg-5.6/data/mysql.sock --databases test --check-upgrade error    : Table upgrade required for `test`.`41_decimal`. Please dump/reload table to fix it! test.55_temporal error    : Table upgrade required. Please do "REPAIR TABLE `55_temporal`" or dump/reload to fix it! test.child                                         OK test.geom                                          OK test.jemp                                          OK test.jemp_myisam                                   OK test.opening_lines                                 OK test.parent                                        OK test.t_blackhole                                   OK test.t_blob                                        OK test.t_blob_myisam                                 OK test.t_compressed                                  OK test.t_compressed2                                 OK test.t_compressed3                                 OK test.t_dynamic                                     OK test.t_gen_stored                                  OK test.t_gen_stored_myisam                           OK test.t_gen_stored_myisam2                          OK test.t_index                                       OK test.t_json                                        OK test.t_myisam_compressed                           OK test.t_myisam_compressed2                          OK test.t_myisam_compressed3                          OK test.t_sc~!@#$%^&*(                                OK test.vt2                                           OK使用此类数据类型的表无法升级，应通过REPAIR TABLE 修复，并为旧式 varchar/旧式 decimal 转储/重新加载：mysql> REPAIR TABLE 55_temporal;   +------------------+--------+----------+-------------------------------------------------------------------------------------+ | Table            | Op     | Msg_type | Msg_text                                                                            | +------------------+--------+----------+-------------------------------------------------------------------------------------+ | test.55_temporal | repair | Note     | TIME/TIMESTAMP/DATETIME columns of old format have been upgraded to the new format. | | test.55_temporal | repair | status   | OK                                                                                  | +------------------+--------+----------+-------------------------------------------------------------------------------------+ 2 rows in set (0.01 sec)   mysql>    Dump:  $./client/mysqldump --databases test --socket=5.6/data/mysql.sock --user=root>test.sql   Restore: mysql> .\ test.sql 关键词与保留字PolarDB MySQL 8.0 可以通过 information_schema.KEYWORDS 表查看当前版本的关键词与保留字，不得有关键字或保留字违规。PolarDB MySQL 8.0 中可能保留了一些以前未保留的关键字，有关详细信息，请参阅关键字和保留字在 MySQL 文档中。建议所有自定义内容(表名、字段名、函数 名)等等全部要规避使用。除此之外， KICKOUT 是 PolarDB MySQL 8.0 的保留关键字。因此，若您已经在 MySQL 5.6 或开源 MySQL 8.0 上使用该关键字作为对象名称(如表名、字段名、存储过程名等)，在迁移到 PolarDB MySQL 8.0 前，请您先修改对象名称避免使用该关键字。否则迁移时，将会出现错误码为1064 的语法报错。补充关键词（RDS）有业务会使用自建序列号生成器函数 nextval、currval，这两个关键词在 RDS MySQL 8.0 中为保留字，需要改写函数名称或者直接使用 RDS 提供的 seq 功能CREATE sequence s START WITH 1 minvalue 1 MAXVALUE 9999999 increment BY 1 CACHE 20 cycle; SELECT nextval(s),currval(s);SQL兼容性GRANT授权在 MySQL 8.0.11 中，删除了与帐户管理相关的几个已弃用的功能，例如使用 GRANT语句修改用户帐户的非特权特性。例如GRANT REPLICATION CLIENT ON *.* TO 'odps'@'%'; You are not allowed to create a user with GRANT 需要改为两步建 create user; grant privielges;不支持 GROUP BY ASC/DESC 写法从 MySQL 8.0.13 开始，已删除不推荐使用的子句ASC或 DESC限定符GROUP BY以前依赖GROUP BY排序的查询可能会产生与以前的 MySQL 版本不同的结果。要生成给定的排序顺序，请提供一个ORDER BY子句。select id,count(*) from sbtest.sbtest1 where id < 10 group by id desc需要改写为select id,count(*) from sbtest.sbtest1 where id < 10 group by id order by id外键约束定义在 MySQL 5.6 中，定义FOREIGN KEY定义的InnoDB 不带CONSTRAINT 的关键字或者指定外键约束名称不得超过 64 个字符。在 MySQL 8.0 之前的版本中，当用户未明确指定时，InnoDB 通过在表名后附加 '_ibfk_X' 来自动生成外键约束名称，其中 X 是一个数字。如果表名是多字节 64 个字符，例如下面示例中使用的西里尔表名 'имя_базы_в_кодировке_утф8_длиной_больше_чем_45имя_азы_в_кодировк'，则自动生成的外键约束名称超过 64 个字符。应通过删除约束并通过确保外键约束名称不超过 64 个字符来添加具有显式约束名称的约束来更改这些表。mysql> ALTER TABLE `имя_базы_в_кодировке_утф8_длиной_больше_чем_45имя_азы_в_кодировк` DROP FOREIGN KEY `имя_базы_в_кодировке_утф8_длиной_больше_чем_45имя_азы_в_кодировк_ibfk_1`; Query OK, 0 rows affected (0.01 sec) Records: 0  Duplicates: 0  Warnings: 0   mysql> ALTER TABLE `имя_базы_в_кодировке_утф8_длиной_больше_чем_45имя_азы_в_кодировк` ADD CONSTRAINT FOREIGN KEY FK1 (fld2) REFERENCES t1(fld1); Query OK, 0 rows affected (0.13 sec) Records: 0  Duplicates: 0  Warnings: 0触发器兼容MySQL 5.0.17 之前的 CREATE TRIGGER 不支持 definer 属性。此类具有缺失/空定义器属性或无效创建上下文（即 character_set_client、collat​​ion_collection、数据库排序规则属性）的触发器定义 一直存在到 MySQL 5.6 无法升级。这些触发器可以通过在 MySQL 5.6 中运行带有检查升级选项的mysqlcheck或CHECK TABLE来识别。$./client/mysqlcheck --user=root --socket=5.6/data/mysql.sock --databases triggers --check-upgrade  triggers.t1 Warning  : No definer attribute for trigger 'triggers'.'trg_t1_before_insert'. The trigger will be activated under the authorization of the invoker, which may have insufficient privileges. Please recreate the trigger. Warning  : No definer attribute for trigger 'triggers'.'t1_bi'. The trigger will be activated under the authorization of the invoker, which may have insufficient privileges. Please recreate the trigger. Warning  : No definer attribute for trigger 'triggers'.'trg_t1_after_insert_1'. The trigger will be activated under the authorization of the invoker, which may have insufficient privileges. Please recreate the trigger. Warning  : No definer attribute for trigger 'triggers'.'trg_t1_after_insert'. The trigger will be activated under the authorization of the invoker, which may have insufficient privileges. Please recreate the trigger. Warning  : No definer attribute for trigger 'triggers'.'trg_t1_after_insert_3'. The trigger will be activated under the authorization of the invoker, which may have insufficient privileges. Please recreate the trigger. Warning  : No definer attribute for trigger 'triggers'.'trg_t1_before_update_3'. The trigger will be activated under the authorization of the invoker, which may have insufficient privileges. Please recreate the trigger. Warning  : No definer attribute for trigger 'triggers'.'trg_t1_before_update'. The trigger will be activated under the authorization of the invoker, which may have insufficient privileges. Please recreate the trigger. Warning  : No definer attribute for trigger 'triggers'.'trg_t1_after_update'. The trigger will be activated under the authorization of the invoker, which may have insufficient privileges. Please recreate the trigger. Warning  : No definer attribute for trigger 'triggers'.'trg1'. The trigger will be activated under the authorization of the invoker, which may have insufficient privileges. Please recreate the trigger. status   : OK triggers.t2                                        OK   mysql> check table t1; +-------------+-------+----------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Table       | Op    | Msg_type | Msg_text                                                                                                                                                                                                         | +-------------+-------+----------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | triggers.t1 | check | Warning  | No definer attribute for trigger 'triggers'.'trg_t1_before_insert'. The trigger will be activated under the authorization of the invoker, which may have insufficient privileges. Please recreate the trigger.   | | triggers.t1 | check | Warning  | No definer attribute for trigger 'triggers'.'t1_bi'. The trigger will be activated under the authorization of the invoker, which may have insufficient privileges. Please recreate the trigger.                  | | triggers.t1 | check | Warning  | No definer attribute for trigger 'triggers'.'trg_t1_after_insert_1'. The trigger will be activated under the authorization of the invoker, which may have insufficient privileges. Please recreate the trigger.  | | triggers.t1 | check | Warning  | No definer attribute for trigger 'triggers'.'trg_t1_after_insert'. The trigger will be activated under the authorization of the invoker, which may have insufficient privileges. Please recreate the trigger.    | | triggers.t1 | check | Warning  | No definer attribute for trigger 'triggers'.'trg_t1_after_insert_3'. The trigger will be activated under the authorization of the invoker, which may have insufficient privileges. Please recreate the trigger.  | | triggers.t1 | check | Warning  | No definer attribute for trigger 'triggers'.'trg_t1_before_update_3'. The trigger will be activated under the authorization of the invoker, which may have insufficient privileges. Please recreate the trigger. | | triggers.t1 | check | Warning  | No definer attribute for trigger 'triggers'.'trg_t1_before_update'. The trigger will be activated under the authorization of the invoker, which may have insufficient privileges. Please recreate the trigger.   | | triggers.t1 | check | Warning  | No definer attribute for trigger 'triggers'.'trg_t1_after_update'. The trigger will be activated under the authorization of the invoker, which may have insufficient privileges. Please recreate the trigger.    | | triggers.t1 | check | Warning  | No definer attribute for trigger 'triggers'.'trg1'. The trigger will be activated under the authorization of the invoker, which may have insufficient privileges. Please recreate the trigger.                   | | triggers.t1 | check | status   | OK                                                                                                                                                                                                               | +-------------+-------+----------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ 10 rows in set (0.01 sec)     mysql> select definer, trigger_name from INFORMATION_SCHEMA.TRIGGERS where definer=''; +---------+------------------------+ | definer | trigger_name           | +---------+------------------------+ |         | trg_t1_before_insert   | |         | t1_bi                  | |         | trg_t1_after_insert_1  | |         | trg_t1_after_insert    | |         | trg_t1_after_insert_3  | |         | trg_t1_before_update_3 | |         | trg_t1_before_update   | |         | trg_t1_after_update    | |         | trg1                   |  +---------+------------------------+  9 rows in set (0.02 sec) mysql>应转储/重新加载此类触发器以解决问题：Dump: $./client/mysqldump --databases triggers --socket=5.6/data/mysql.sock --user=root>triggers.sql   Restore: mysql> .\ triggers.sql并行查询导致的排序问题PolarDB MySQL 8.0开始支持并行查询能力，并行扫描由于随机访问数据导致MySQL默认串行扫描的顺序每次会随机变化，尤其涉及到分页的SQL，需要要生成给定的排序顺序，请提供一个ORDER BY子句保证顺序。子查询问题子查询中的order by 不再起作用，例：SELECT * FROM  (   SELECT * FROM `information_schema`. TABLES   ORDER BY table_name DESC  ) AS sg GROUP BY table_name内层的order by 会被5.7、8.0的优化器忽略，需要修改语句，最简单是添加 limit 使排序生效，例如：SELECT * FROM  (   SELECT * FROM `information_schema`. TABLES   ORDER BY table_name DESC limit 10000 # 需要足够大的行数  ) AS sg GROUP BY table_name派生表问题优化器现在以一致的方式处理子句中的派生表和视图， FROM以更好地避免不必要的物化，并允许使用产生更有效执行计划的下推条件。但是，在 PolarDB MySQL 8.0 中，以及对于修改表之类的语句，DELETE对 UPDATE先前实现的派生表使用合并策略可能会导致 ER_UPDATE_TABLE_USED错误：mysql> DELETE FROM t1     -> WHERE id IN (SELECT id     ->              FROM (SELECT t1.id     ->                    FROM t1 INNER JOIN t2 USING (id)     ->                    WHERE t2.status = 0) AS t); ERROR 1093 (HY000): You can't specify target table 't1' for update in FROM clause当将派生表合并到外部查询块中会导致从表中选择和修改表的语句时发生错误。（物化不会导致问题，因为它实际上将派生表转换为单独的表。）避免此错误的解决方法是在执行语句之前禁用系统变量的derived_merge 标志 ：optimizer_switchSET optimizer_switch = 'derived_merge=off';该derived_merge标志控制优化器是否尝试将FROM子句中的子查询和视图合并到外部查询块中，假设没有其他规则阻止合并。默认情况下，该标志是on启用合并。设置标志以off 防止合并并避免刚刚描述的错误。有关更多信息，请参阅 第 8.2.2.4 节，“使用合并或实现优化派生表和查看引用”。在UNION语句中，要应用 ORDER BY或LIMIT应用于个人SELECT，请将子句放在括起来的括号内 SELECT：(SELECT a FROM t1 WHERE a=10 AND B=1 ORDER BY a LIMIT 10) UNION (SELECT a FROM t2 WHERE a=11 AND B=2 ORDER BY a LIMIT 10);以前版本的 MySQL 可能允许这样的语句不带括号。在 PolarDB MySQL 8.0 中，强制要求使用括号。GET_LOCK函数兼容该 GET_LOCK()功能在 MySQL 5.7.5 中使用元数据锁定 (MDL) 子系统重新实现，并且其功能已得到扩展：以前，GET_LOCK() 一次只允许获取一个命名锁，第二次GET_LOCK() 调用释放任何现有锁。现在GET_LOCK()允许同时获取多个命名锁，并且不会释放现有锁。依赖于GET_LOCK()释放任何先前锁的行为的应用程序必须针对新行为进行修改。获取多个锁的能力会在客户端之间引入死锁的可能性。MDL 子系统检测死锁并ER_USER_LOCK_DEADLOCK 在发生这种情况时返回错误。MDL 子系统对锁名称施加了 64 个字符的限制，因此该限制现在也适用于命名锁。以前，没有强制执行长度限制。获取的锁 GET_LOCK()现在出现在 Performance Schema metadata_locks表中。列 OBJECT_TYPE说USER LEVEL LOCK， OBJECT_NAME列表示锁名。一个新功能， RELEASE_ALL_LOCKS() 允许一次释放所有获得的命名锁。有关更多信息，请参阅 第 12.15 节，“锁定功能”。其他客户端兼容对于 java 应用来说，MySQL Connector/J 升级到 5.1.46 以上版本 到 8.0.8 能够连接到 MySQL 8.0 服务器，但使用 caching_sha2_password. （连接帐户需要连接器/J 8.0.9 或更高版本 caching_sha2_password。）。dataworks由于未在数据源中设置utf8可能出错，建议修改数据库名，并和RDS的设置一致。在PolarDB MySQL的连接串增加：characterEncoding=utf8&com.mysql.jdbc.faultInjection.serverCharsetIndex=Unknown system variable 'tx_read_only'8.0 中已经删除 tx_read_only 环境变更，需要使用 transaction_read_only 代替select @@tx_read_only需要改为select @@transaction_read_only升级检查器官方目前提供了8.0升级检查器，目前PolarDB MySQL未支持，自建库升级前请参考检查器。参考文档What Is New in MySQL 8.0Changes in MySQL 8.0准备安装以进行升级升级到 MySQL 8.0？这是你需要知道的...官方56/57/80差异mysqld Options and VariablesBuilt-In Functions and OperatorsLoadable FunctionsINFORMATION_SCHEMA TablesPerformance Schema Tablessys Schema ObjectsKeywords and Reserved Words

背景在使用RDS的过程中，总是发现，我的数据库并没有使用那么多的空间啊，怎么空间就满/不够用了呢？接下来，我们就看看我们的磁盘究竟使用在了哪儿了？分析1、RDS控制台查看空间详情可以在RDS管理控制台-监控和报警，资源监控中查看存储空间详细的使用情况。看了上面监控中的信息，好像信息统计也不是很准，我们还是不清楚数据差在哪儿啦，只是清楚磁盘被data/log/other/tmp占用了，具体是我哪些业务库表呢？我们接着往下看。在RDS管理控制台-自治服务（DAS）-一键诊断-空间分析 中具体看下磁盘使用情况。首先需要【重新分析】一下，确保数据的时效性。在【空间分析】的【表空间】中，可以查看每个表的物理文件占用磁盘大小，以及是否存在较多的磁盘碎片，可以通过这里进行碎片整理。2、SQL查看空间详情如果可以登录实例后使用SQL查看具体的库表空间占用。select table_schema as '数据库名称',sum(table_rows) as '记录数', \ sum(truncate(data_length/1024/1024, 2)) as '数据容量(MB)', \ sum(truncate(index_length/1024/1024, 2)) as '索引容量(MB)', \ sum(truncate(data_free/1024/1024, 2)) as '碎片空间(MB)' \ from information_schema.tables where table_schema='DB_NAME'; -- 注：DB_NAME 需要使用真实的数据库名替换。select table_schema as '数据库名称',table_name as '表名', \ table_rows as '记录数', \ truncate(data_length/1024/1024, 2) as '数据容量(MB)', \ truncate(index_length/1024/1024, 2) as '索引容量(MB)', \ truncate(data_free/1024/1024, 2) as '碎片空间(MB)' \ from information_schema.tables where table_schema='DB_NAME'; -- 注：DB_NAME 需要使用真实的数据库名替换；如果碎片空间过大，请执行optimize table 进行清理。SELECT file_name, concat(TOTAL_EXTENTS,'M') as 'FIle_size' FROM INFORMATION_SCHEMA.FILES order by TOTAL_EXTENTS DESC;具体的磁盘文件占用的信息中，处理基础的表空间（ibd）文件占用，还存在临时表和undo log文件占用，熟悉MySQL的朋友们都知道，这都是占用磁盘空间比较大的文件，确实也容易被我们忽略。通过以下文件磁盘占用的命令输出，可以大概了解到实例磁盘空间占用的所有文件记录。这里还是多加关注可能占用磁盘的数据，才能更加了解我们的数据库，enjoy RDS MySQL！

开发者学堂课程【AnalyticDB PostgreSQL 产品调优及最佳实践：核心能力介绍】学习笔记，与课程紧密联系，让用户快速学习知识。课程地址：https://developer.aliyun.com/learning/course/1232/detail/18393核心能力介绍 内容介绍：一、ADBPG 产品介绍二、ADB PG 权限管理 一、ADBPG 产品介绍线上 ADBPG 是兼容性仓库阿里云自研云原生MPP数据仓库，强兼容PG/Greenplum开源生态，兼容Oracle/TD语法生态：自研云原生存算分离架构，具备秒级弹性和数据共享等国内领先的产品能力：拥有完整的企业级分析能力，融合阿里云产品生态，可打造全场景覆盖的一站式数据平台；优点如下：（1）云原生架构存算分离全新自研云原生架构，解耦计算和存储，支持秒级扩缩容，按需存储付费：默认支持行列混存，使用分层存储架构，设置缓存加速：面向多实例，开放数据共享，实现云原生实例间数据一写多读架构。（2）TB～PB级数据实时响应MPP水平扩展架构，TB-PB级数据查询秒级响应：向量化计算，及列存储智能索引，领先传统数据库引擎性能3x；新一代SQL优化器，实现复杂分析语句免调优（3）稳定可靠、简化运维飞天平台基于阿里多年大规模集群系统构筑经验打造，智能硬件管理，故障监控诊断自恢复，支持MPP数据库实现复杂集群系统高可靠，自运维。（4）企业级分析能力支持SQL 2003，强兼容PG/Greenplum开源生态，部分兼容Oracle语法，支持PL/SQL存储过程，OLAP窗口函数，触发器，视图等，完备功能和生态，实现应用快速适配，支持主流数仓迁移上云（5）数据多模分析通过PostGIS插件支持地理信息数据分析；内置100+机器学习算法库，实现数据智能探索；高性能向量检索算法，支持视频/图像检索以搜图。ADP PG发展历程整个发展历程从17年正式上线，到版本的引进，再到云原生架构、存算分离都做了大量的工作，整个过程是技术的引进也是产品的发展历程 ADB PG生态集成因为ADB PG也兼容PG/Greenplum，所以无论是外围生态，PG/Greenplum对接云上有QACS和RDS产品。OACS移线Maccompute、OACS、Flink。同步服务有DTS，通过联邦分析可以对接叶梦，主要是对接hadupe的生态系统，所以整个外围生态，包括PG的生态，大数据的生态，还是比较丰富的。ADBPG产品架构MPP水平扩展，海量数据实时分析，兼容Oracle语法生态，高可用HA架构，支持分布式事务。MPP数据库，支持一写多读，底层存储目前只有行存列存，执行层为自己重新写的现代化执行引擎。连接外部可以直接访问ODCS和ODPS。特点如下：多活协调节点：·Cascade 架构 SQL 优化器·全局分布式事务管理计算节点水平扩展：·计算任务全并行执行·新一代向量化计算引擎·非结构化数据检索高可靠存储引擎：·本地数据双副本·支持行存储/列存储·高吞吐导入/导出分布式事务支持：·支持分布式事务，保证强一致性·支持SI/RC隔离级别丰富的字段类型如今公测已经是ADB PG7,内核已经升级到了PG12.ADB PG6内核是9.4。可以理解为9.4的生态类型都支持。目前ADB PG 12前的所有生态数据类型都支持。数字类型，日期，字符串，几何类型，向量范围称为数组类型。ADB PG支持丰富的数据类型，您还可以使用CREATE TYPE命令定义新的数据类型数值类型：smalint,bigint,bigserial,bit[{n}],bit varying[(n)],Boolean,bytea,decimal[(p,s)],double precision,real,serial,money字符串类型：character[(n)],character varying[(n)]text,xml,json范围类型：int4range int8range numrangetsrange tstzrange daterange日期/时间类型：timestamp[(p)] [without time zone]timestamp[(p)] with time zonetime[(p)] without time zone]time[(p)] with time zoneinterval [fields][(p)]date几何类型：path,point,polyg​on向量类型：float[]完整&标准的SQL语法函数、存储过程、过程化语言ADB PG 支持丰富的函数及运算符，如 JSON 函数和操作符、窗口函数、高级聚合函数、文本搜索函数和操作符、范围函数和运算符等等。目前来说语音上，不管是 PO JAVA 还是 POpython的沙箱机制都没有很健全，一般都是客户申请工单不会默认开放给客户，一般推荐用户用POP circle。在写circle写存储过程的时候会用UDF来写。开工单可以用C或Java或Python，但由于安全隐患，默认没有打开。ADB PG实例逻辑架构整个逻辑架构为一个实例可以建很多个数据库，并且为相对传统的数据库，如MY SQL、PG都是可以建库，库里面有Schema，Schema下面有表。一般建表要指定分布键，也可以使用分布键Hash值，随机Random，或复制Replication三种方式，但一般线上客户使用的最多的是MPP分布键的分布方式。也支持压缩和分区表。一般来说客户用的是一个MPP，因为购买的时候会买ADB PG几个节点，数据肯定分布在节点上，所以需要选择分布键，若不选 数据库实例：云平台上的一个MPP数据库集群，创建时分配固定资源，包含一组模式、表对象和数据以及用户模式（SCHEMA）：逻辑概念，数据库中的一组逻辑空间，包含一系列表，视图等对象。表定义选项：数据分布定义：按分布键Hash值，随机Random，或复制Replication三种方式，进行节点间数据分布。存储格式定义：支持指定按行存储，或者按列存储。压缩算法定义（可选）：支持多种高性能数据压缩算法，包括LIZ4，ZSTD,RLE等。分区表支持（可选）：对于大表，支持按区间Range，或值LIST进行分区，且支持多级分区。ADB PG 表结构定义分布键一般会默认第一列，容易造成数据倾斜。比如按照分布键 OrderID ，选择组件或unique会比较好，若没有组件可以拿符合的分布键就行。 如今ADB PG6在建表时客户需要选择表的类型。传统是行存表和列存表。行存表：高吞吐更新写入，点查询数据按行存储，操作某列必须读入整行适合较多数据更新操作场景通过索引，支持高并发的点查询列存表：批量加载，全表聚合，压缩率高数据按列存储一每一列单独存放，数据即是索引只访问查询涉及的列-大量降低系统IO数据类型一致，数据特征相似-实现高压缩率适合更新少，全表聚合操作向量化计算引擎新一代计算引整Laser，消除火山模型碎片化内存分配采用LLVM进行动态代码生成（CodeGen），提升表达式计算性能利用CPU的SIMD技术，指令级并行，进一步提升性能Cascade 框架 SQL 优化器，复杂查询免调优新一代 cascade 框架的 SQL 优化器，面向全并行执行架构，代价优化 CBO 和规则优化RBO相结合，实现复杂 SQL 免调优。优化系统还增加了实时物化视图的功能。感兴趣的可以去官网查看详细文档。特点：（1）Top-Down 路径搜索框架，搜索和路径选择更全面精准，避免出现局部查询路径最优解（2）子查询自动改写为分布式 JOIN 实现并行计算，规避手工改写调优（3） SQL 优化阶段定义动态分区裁剪，即支持确定性过滤条件，也支持参数化的过滤条件，减少 I/O外部数据源—OSSADB PG 对接的云上的QSS可以作外表的导入导出，还可以联邦分析查询。1、适用场景（1） OSS 数据导入到本地表（行存表/列存表）（2）直接查询分析 OSS 海量数据（3）OSS外表与本地表关联分析2、OSS外表分类（1） OSS 普通外表（2） OSS 分区外表，例如，适用于 SLS 归档日志OSS外表数据来源(1)酒业务应用APP写入到 OSS(2)阿里云 SLS 的日志日档(3)阿里云 DLA 的ETL输出具体操作请参考官网文件：http//help.aliyun.com/document detail/445437.html外部数据源-ODPS（现在交MaxComputer）适用场景（1）ODPS 数据同步至 ADB PG（2）直接查询分析 ODPS 表（3）ODPS 表与 ADBPG 表关联直询ODPS外表分类（1）普通外表，对应ODPS非分区表（2）末级分区外表，对应ODPS未级分区表（3）分区外表，对应ODPS分区表异构数据源导入与联邦分析联邦分析即不光能访问ODPS，还能访问OSS，还有Haddoop生态系统通过部署PXF服务进行外表访问：Hadoop HDFS（Text|Avro|JSONIORCIParquet）SQL Databases（Oracle|MySQL|PostgresQL）查询性能加速：列过滤谓词下推通过外表加载的方式，可实现高性能数据导入，加载性能随节点数线性扩展：INSERT INTO<目标表>SELECT*FROM<外部表>二、ADB PG权限管理1、ADB PG 权限体系ADB PG权限体系继承了 PG社区的权限体系，它包括以下权限：（1）实例权限实例权限可以理解为能否连接的问题，当我们买了一个产品后，上面云数据有一个安全性白名单控制，能够允许某一个IP访问，允许某个客户能够访问或不能访问，都是在PG的hba文件控制。即能修改pg_hba.conf（2）数据库权限grant赋予是否允许连接成创建schema的权限revoke回放数据库级别的权限包括：是否允许连接数据库是否允许在数据库中创建schema默认情况下，数据库在创建后：允许public角色连接，即允许任何人连接。不允许除了超级用户和owner之外的任何人在数据库中创建schema会自动创建名为public的schema.这个schema的alI权限已经腻子给public角色，即允许任何人在里面创建对象。（3）schema权限grant赋予允许查询schema中的对象或在schema中创建对象revoke回收schema级别的权限包括：是否允许查看schema中的对象是否允许在schemm中创建对象默认情况下新建的schema的权限不会赋予给public角色，因此除了超级用户和owner，任何人都没有权限查看schema中的对象或者在schema中新建对象。（4）object权限grant赋予revoke回收数据库里object一般指表、视图和列等。（5）表空间grant赋予允许在对应表空间创建表，物化视图，索引，临时表revoka回收表空间意味着每个数据库都可以建在不同的数据目录下面，但如今云上安全把控比较重，还未开放。对象级别的权限每种型的对象权限都一样，相对来说PG的社区语法是很完备的，想要的功能几乎都可以在文档中找到权限控制体系。具体请参考文档 https//www.postqresql ora/docs/9.4/sql-grant_html赋予权限语句GRANT权限ON对象类型对象名TO用户名如:GRANT SELECT ON TABLE table TO userl; --.允许user1 select table GRANT SELECT ON TABLE table TO publlc;--允许所有人select table撤销权限REVOKE权限ON对象类型对象名FROM用户名如:REVOKE SELECT ON TABLE table FROM userl：--不再允许user1 select table查看权限可以用 select查也可用快捷命令查默认权限如果你是用户建的表不把权限给其他人，则其他人是无法查看的，默认权限，控制着以后在sehema下创建的对象所具有的默认权限相当于schema下创建的新对象都会首先执行一组gant/revoke语句对 schema中已有对象无效。默认权限遵循的原则是最小原则，创建后不给其他人看其他人是无法查看的，除非在public下面，public schema其他人都可以访问，但其他人也只能进入public schema，如果不允许访问，其他人也是不能查看表。2、资源管理ADB PG 弹性存储形态弹性存储实例在购买的时候会每个节点附带共享盘，一个默认规则，如果并发很高的话建议节点计算规格的时候靠数相对选择多一点，如今节点规格支持升降配。计算节点用MBP，数据选的越多，单条查询就越短，可以增缩选择4-8或8-4都可以。云盘可以无感知扩容，但目前云盘并不支持缩。 Segment ：数量越多，单条查询性能越好；CPU核数越多，并发能力越好，目前Segment计算节点数支持扩容、缩容ECS：CPU内存资源规格支持垂直升降配云盘：云盘目前支持ESSD/高效云盘，支持ESSD云盘扩容（用户无感知）在单个 ECS 上资源是如何划分ADBPG计算节点资源管理ADBPG是一个重计算和重资源的MPP数据库，可谓有多少资源就能消耗多少资源，带来的好处是处理速度变快了，坏处就是容易超过系统总量。系统资源包括：CPU、内存、网络、磁盘IO、文件句柄，其中最重要的是内存、一旦内存分配超限，容易导致各种系统问题：如果不进行管理变化变高不限流会占用很多内存，运行会比较慢。带来危害ADBPG资源管理的两个方案：Resource Queue和Resource Group目前公有云Resource Group由于安全问题，暂不支持ADBPG 资源管理-Resource Queue支持自定义执行队列，根据用户角色，其执行任务进入对应资源管控队列。任务队列支持设定：并行执行任务数CPU优先级内存资源上限示例：定义三个队列ETL队列：赋予资源获取最低优先级BI报表队列：赋予资源获取最高优先级数据探索队列：赋予资源获取中间优先级建三个Q，一个是ETL角色人物，一个是BI报表角色人物，一个是数据探索角色人物。可以设定每个Q的朝位如一个5个，一个10个，一个2个，ETL角色发动查询的时候最多只有5个朝位，只有它的朝位出来了，其他的角色才能进入查询。 Resourc Queue 简介Resource Queue是ADBPG最早的资源管理方式，支持通过SQL配置Resource Queue支持进行四种类型的资源限制:并发限制、CPU限制、内存限制和查询计划限制。超级用户可以通过SOL在数据库内定义多个资源队列，并设置每个资源队列的资源限制。在一个数据库中，每个资源队列可以关联一个或多个数据库用户，而每个数据库用户只能归属于单个资源队列。资源队列支持的资源限制配置如下:CREATE FESOURCE QUEUE name WITH (queue_attribute=value [ ... ])where queue_attribute is:ACTIVE_STATEMENTS=integer[ MAX_COST=float[COST_OVERCOMMIT=(TRUEIFALSE)]][ MIN_COST=float ][ PRIORITY=(MINLOWMEDIUMHIGHIMAX)][ MEMORY_LMIT='memory_units’]说明：MEMORY_LIMIT（内存限制）队列中所有查询所使用的的内存的量。例如，对ETL查询设置2GB的MEMORY LIMIT，这样每个Segment里的ETL查淘最多使用2GB的内存。ACTIVE STATEMENTS（一般用这个设置并发比较多）队列中槽位的数量;一个队列中最大可并行数，当所有槽位都占用时，新的查询必须等待，默认每个查询使用等量的内存。PRIORITY查询使用的相对CPU使用量，可以设置为以下级别:BOW、MEDIUM、HIGH 和MAX，默认级别是MEDUM，查询优先权的机制会监控系统中所有正在运行的查询的CPU使用量，并根据其优先权别来调整其CPU使用量，例如，你可以为执行各源队列设置MAX优先权，为其他 查询设置MEDIUM优先权，确保执行查询可以获得比较多的CPU资源。MAX COST（估算）查询计划消耗限制。数据库优化器会为每个查询计算消耗，如果该消耗超过了资源队列所设定的的MAX COST的值，该查询就会被拒绝 Resource Queue使用:创建资源队列创建资源队列一般如下三个并发，优化级一般估的不是很准。创建一个队列将队列给某一个角色即可，因为创建队列以后肯定需要绑定到一个客户上去，然后客户用这个队列。创建带有并发限制的队列带有ACTIVE_STATEMENTS设置的资源队列会限制指派给该队列的角色所执行的并发查询数量例如，要创建一个名为adhoc且并发限制为3的资源队列:=# CREATE RESOURCE QUEUE adhoc WITH (ACTIVE _STATEMENTS=3);创建带有内存限制的队列，带有MEMORY_LIMIT设置的资源队列控制所有通过该队列提交的查询的总内存。总内存不应超过每个Segment可用的物理内存。以每个Segment为基础，设置MEMORY_LIMIT为90%的可用内存.例如，如果一台主机有48GB物理内存和6个Segment实例，那么每个Segment实例可用的内存是8GB，可以为单个队列按照0.90*8=72GB来计算推荐的MEMORY_LIMIT。如果在系统上创建有多个队列，它们的总内存限制加起来也必须为7.2GB=#CREATE RESOURCE QUEUE myqueue WITH (ACTIVE_STATEMENTS-20,MEHORY LIMIT-"2000HB”):设置优先级为了控制一个资源队列对可用CPU资源的消耗，管理员可以指派一个合适的优先级。当高并发导致对CPU资源的竞争时，与较高优先权资源队列相关的查询和语句将会比较低优先权的查询和语句得到更大份额的可用CPU。优先级有几种设置: LOW、MEDIUM、HIGH、MAX在创建队列后，可以通过ALTER语句重新设置优先级=#P CREATE RESOURCE QUEUE executive WITH (ACTIVE STATEMENTS=)，PRIORITY=MAX);=#ALTER RESOURCE QUEUE adhoc WITH (PRIORITY=LOW):=#ALTER RESOURCE QUEUE reporting WUTB(PRIORITY=BIGB)Resource Queue 使用:状态监控ADB PG 资源队列监控指标队列如今支持在控制台上进行云监控rsqHolders代表当前运行的SQL并发数rsqWaiters代表正在排队的SQL，若rsqWaiters不等于0则代表在排队。资源队列并发超过当前设置因此需要排队。

开发者学堂课程【企业运维训练营之大数据 EMR 原理与实践：视频-《E-MapReduce》】学习笔记，与课程紧密联系，让用户快速学习知识。课程地址：https://developer.aliyun.com/learning/course/1242/detail/18440视频-《E-MapReduce》​5.EMR 与开源 Hadoop 对比（1）成本阿里云EMR：资源是按量付费的，它支持资源灵活调整。数据这个分层存储资源使用率高，没有额外的软件的License费用自建的Hadoop集群：需要提前预估资源，并且资源是相对固定的，如果采用了Hadoop发行版，还需要额外的支付License费用。所以从成本来看，EMR购买比较灵活，整体的成本是更低的。（2）性能阿里云的EMR：较开源版本的性能有很大的提升自建的Hadoop集群：采用了开源社区的版本，性能需要自己去优化。所以性能方面阿里云的EMR集群比自建的Hadoop集群要好。（3）易用性阿里云的EMR：分钟级别能创建和启动Hadoop集群。自建的Hadoop集群：需要采购服务器，部署Hadoop生态组件，可能周期长达数周。（4）弹性阿里云EMR：能根据作业临时的启动和销毁集群，并且能根据业务的周期，还有集群动态负载，动态的调整。自建的Hadoop集群：它的计算和存储是耦合的，它的资源相对固定，没有办法弹性的调整资源所以EMR支持弹性扩展，弹性的扩展计算和存储资源。而自建的Hadoop客集群是不支持的。（5）安全阿里云EMR：支持企业级的多租户的资源的管理能力，对表列行级别的权限控制和日志审计，并且它支持加密，对数据进行加密自建的Hadoop集群：它的多租户管理能力需要自行去配置，它的能力是不完善的，没有办法满足企业级的要求所以安全性方面阿里云的EMR是更好的。（6）可靠阿里云的EMR：经过大规模的企业级的环境的检验的，并且随着开源版本升级，也是经过了专业的兼容性验证，它提供了优于社区版本的使用体验。自建的Hadoop集群：需要自行的去更新，还有升级开源版本的组件，还要验证各个组件各个版本的兼容性，需要自行修复社区的bug。（7）服务阿里云的EMR：有专业和资深的大数据专家技术服务团队提供售后支持自建的Hadoop集群：没有这个服务支持的，Hadoop的发行版也要支持，也要支付额外的费用。6.EMR 的基本概念系统性了解这些基本概念后看上图架构图，最下层是节点所在的物理位置以及节点网络相关的概念，分别是地域、可用区、专用网络和交换机。（1）物理位置以及节点网络相关的概念拓扑图这几个概念的关系①最外层是地域也叫region，地域是指数据中心所在的地理位置，即通常这个按照数据中心所在的城市划分，例如北华北一地域表示这个数据中心所在的城市是青岛，华北二是北京，华东一是杭州，华东二是上海，需要注意的是创建的资源，创建成功后就不能再变成区域②第二层专业网络专业网络又叫VPC，是基于阿里云构建的一个隔离的网络环境，专业网络之间在逻辑上是彻底隔离的，在创建集群要提前创建VPC。③第三层可用区可用区是指在同一个地域内，电力和网络相互独立的物理区域，可以理解为机房，比如在北京建立了三个机房，分别在朝阳、海淀、昌平。这个北京区域就有三个横区，叫横区A，横B，横区C。④第四层交换机交换机是用于集群节点的这个ECS实际通信的，所以交换机它是归属于某个可用区，并且归属到某个ABC网络。最底层是ECS节点，也就是组成EMR集群的服务器节点，ECS节点是部署到交换机下。（2）架构图介绍在架构图中第456层都是ECS节点相关的概念。①第六层CPU、内存、内网带宽磁盘分为系统盘和数据盘，磁盘它有两种类型云盘：云盘它是指一款块存储产品本地盘：它是指ECS所在的物理机的本地硬盘设备本地盘的存储性能和性价比都相对高一点，但是它的数据可靠性是取决于物理机的可靠性的，它存在这个单点故障，所以线上环境还是建议选择云盘。②第五层实例类型根据业务的场景和使用场景，ECS实例可以分为多种实例类型，比如通用型、计算型、CPU型、内存型。根据CPU和内存的配置，一种实例类型又能分为多个实例规格。比如EC2G的实例规格的ECS，EC就是一核CPU，2G就是2G内存③第四层付费的类型付费类型可能分为按量付费和包年包月包年包月：按月购买和续费，它是预付费模式，包年包月的集群到期后才能释放按量付费：是按照实际开通的时长进行收费的，它是后付费模式。上上图右侧的四个，挂载公网、安全组、标签组和资源组挂载公网：指集群上是否挂载公网IP，如果挂载公网IP之后，集群可以访问公网，也可以通过公网登录安全组：它是一个虚拟的防火墙，它是基于安全组，它可以对某个安全组下的所有的ECS的出方向和入方向进行网络控制，比如要限制192168.0.1这个IP访问的这个节点的八零端口，就可以通过安全组件设置。标签：它是由区分大小写的键值对组成，可以基于标签方便的管理和检索资源，比如有两个EMR集群，一个是测试集群，另外一个是生产的集群，可以使用标签来区分。资源组：资源组是从业务的角度管理跨地域，跨产品的资源的，就是可以将资源组映射为项目或者是应用或者是组织，比如公司一个阿里云账号下有多个部门在使用，每个部门的资源就能配置到不同的资源组下，这样更方便管理和使用④第三层是节点类型EMR的核心是集群，集群是由一个或者多个阿里云的ECS组成的，以Hadoop集群为例，每个ECS上都运行了一些进程，比如namenode、datanode resource和node，每个服务也都是由不同的进程组成的。例如STMS服务，有namenode、datanode，还有三个进程组成。这些所有服务的进程共同组成整个子Hadoop集群，而运行着不同类型进程的节点，它就分为不同的节点类型，节点类型有三类，一个是master，Core节点，还有task节点。master节点：它是集群服务、部署、管控等组件的节点，就例如HDMS的namenode，Core节点：是被主实例节点管理的节点，Core节点上可能会运行Hadoop、HDFS等datanode服务。同时Core节点可能也会部署计算服务来执行计算任务。task节点：task节点是专门负责计算的实例节点，它不会保存HDMS的数据，也不会运行Hadoop HDFS的datanode服务，task节点会部署YARN的nodemanager，主要就是用于YARN的计算。⑤EMR集群类型目前分为六种不同的集训类型是安装的核心组件不一样第一种集群类型是新版的数据糊Data Lake：是一个灵活的、可靠的、高效的、数据的计算集群，核心组件就是Hive、Spark，适用于数据糊场景、离线数据分析等场景。第二个集群类型是数据分析OLAP：OLAP核心组件是clickhouse和starRocks，clickhouse是一个开源的面向列式存储的一个OLAP的分析引擎，starRocks是开源的一个MPP架构的OLAP分析引擎，两者都提供了这个极致性能的数据分析功能，适用于数据分析的场景。第三种集群类型是实时的数据流dataFlow：适合实时数据流的场景，它的核心组件就是flink，flink企业版的引擎的性能是开源的flink的两到三倍，其中它的Kafka的组件提供了一套完整的服务监控体系，还有元数据的管理体系，这种集群类型可以广泛的应用于日志的收集还有监控数据的聚合这些场景。并且它支持流式数据处理，还有实时数据分析。第四种集群类型是数据服务dataServing：是阿里云EMR提供基于Apache Hbase的数据服务机器类型，它的核心组件是Hbase。Hbase是一个高可靠的、高性能，面向列的一个可伸缩的分布式数据系统第五种集群类型是机器学习：提供hive和Spark离线的大数据ETL和TensorFlow的模型训练，它提供了分布式的深度学习框架支持，提供了200多经典的机器学习算法包，还有十多种深度学习算法。覆盖了推荐还有广告等场景，这种集群类型主要是面向大数据+AI的场景第六种集群类型是数据湖类型：目前支持Hadoop、Zookeeper、Presto类型，Hadoop集群提供最丰富的这个开源的组件列表，完全兼容Hadoop生态，可应用到数据的离线处理，实时处理，还有交互式的交互式查询等多种使用场景，Zookeeper集群是提供适用于大规模的Hadoop集群，Hbase集群，Kafka集群，适用于独立的分布式一次性锁服务，Presto集群是基于内存的一个分布式的SQL的交互式查询引擎，它支持多种数据源，适合PB级级别的海量数据的复杂的分析，以及跨数据源的产生场景。自定义集群：除了这六种还有一种是自定义集群，自定义集群提供了丰富的服务搭配，可以按照自己的需要，自行的安装服务组件。⑥第一层是服务组件可能之前提到的HDFS、Hive、Spark这些都是服务组件。在创建集群的时候会选，有一些必选的组件，还有一些可选的组件，在第二节课会对一些重点的服务组件进行详细的介绍。（3）元数据①元数据概念元数据是指hive等服务的元数据。在安装hive服务时，是需要在hive的配置文件中配置原数据相关的信息，与传统的关系型数据库不同的是，hive表中的数据其实是存储保存在HDFS上，即hive的数据库表分区都可以在HDFS上找到对应的文件，所以需要记录hive的数据库表分区和HDFS文件的一个对应关系，可以理解为这个对应关系都是元数据。②元数据类型目前元数据支持三种存储方式，分别是内置MYSQL，自建的RDS，还有DLF统一元数据。第一种是内置MYSQL：MYSQL的service实例是部署在EMR集群中的，通常是在master节点，hive、Spark等去访问元数据的时候，其实也不是直接访问MYSQL，而是先访问HiveMetastore服务，服务再通过JDBC访问集群的MYSQL。这种方式的优点是部署简单，但是也有风险，因为这个MYSQL数据库是部署在集群的一个节点中，不能保证服务的高可用，所以这种方式只建议在测试场景使用。第二种是自建的RDS：元数据就存储在RDS中。自建的RDS的这种元数据类型和内置的MYSQL类型在架构上是一致的，区别就是由本地放到了云的RDS MYSQL中。第三种是DLF统一元数据：这种方式是将元数据存储到数据湖DLF中，数据湖DLF是阿里云数据湖构建产品，它是一款云服务，这种元数据的存储方式，比自建的RDS，还有内置的MYSQL最大的区别是HiveMetastore服务，不用再部署在EMR集群上了，而是将这个元数据的查询服务，还有存储服务都托管到了这个DLF上，hive、SparkS、这些引擎去通过HTDP协议访问DLF就可以了。

开发者学堂课程【AnalyticDB PostgreSQL 产品调优及最佳实践：调优建议】学习笔记，与课程紧密联系，让用户快速学习知识。课程地址：https://developer.aliyun.com/learning/course/1232/detail/18395调优建议 内容介绍一、ADB PG日常使用二、执行计划三、常用调优方式 一、ADB PG日常使用表在MPP节点间的三种分布方式ADB PG用的是MPP数据库，数据一般分布在各个节点上的，默认一般用 Hash分布方式，分布建很重要，默认在用户选择的时候挑一个合适的分布键，因为有的时候ADB PG会有一些从RDS TB有关的,因为RDS TB 为单机没有分布键的概念，没有加上DISTRIBUTED BY，默认是Hash分布，如果不带上DISTRIBUTED BY，就默认为第一列CREATE TABLE products(第一列有的时候不是主键，如果是性变的话则说明倾斜的非常厉害，查询即发现性能不行，就需要各种诊断。因此数据分布一定要均匀是非常关键的。（1）默认根据分布键的hash值分布​​​​CREATE TABLB prouducts(​​name varchar(40),​​prod_id integer,​​supplier_id integer)​​DISTRIBUTED BY (prod_id0；​（2）若没有适合的列做hash分布，可以采用随机分布​CREATE TABLB random_stuff(​​things text,​​dooddads text,​​etc text)​​DISTRIBUTED RANDOMLY;​（3）小表、维度表在各个节点有一份全量复制​CREATE TABLB replicated_stuff(​​things text,​​doodads text,​​etc text)​​DISTRIBUTED RANDOMLY;​​​​表的分布键选择原则有主键就选择主键，如果多表需要JOIN，则看JOIN键是否可以作为主键，若JOIN键又为主键又是做JOIN最好，JOIN键如果是分布键能够减少网络sharp,不需要sharp到一个节点上再去算。1、选择数据分布均匀的列:若选择的分布列数值分布不均匀，则可能导致数据倾斜。某些Segment分区节点存储数据多(查询负载高)。根据木桶原理，时间消耗会卡在数据多的节点上。故不应选择 bool 类型，时间日期类型数据作为分布键。（2、选择经常需要JOIN 的列作为分布键，可以实现图一所示本地关联( Collocated JOIN)计算，即当JOIN键和分布键一致时，可以在 Segment分区节点内部完成JOIN，否则需要将一个表进行重分布( Redistribute motion)来实现图二所示重分布关联(Redistributed Join)或者广播其中小表(Broadcast motion)来实现图三所示广播关联( Broadcast Join)，后两种方式都会有较大的网络开销3、尽量选择高频率出现的查询条件列作为分布键，从而可能实现按分布键做节点 segment 的裁剪4、按主指定分布键，默认表的主键为分布键，若表没有主键，则默认将第一列当做分布键5、分布键可以被定义为一个或多列；6、谨慎选择随机分布DISTRIBUTED RANDOMLY,这将使得上述本地关联，或者节点裁剪不可能实现。支持表按区间或者值进行分区，自动分区裁剪，提升查询效率但目前来说也不太建议，因为现在用的CPU的优化器，如果多表交易的时候每张表分区表都很多的情况下，优化器生成的计划也慢一点，也不建议多表场景下分区太多，一般来说200-300就足够，不要将几年的分区都建了，以前出现这种情况后，我们建议用户如果查询量不高的，可以建一个月或一年的分区来减少分区的个数。分区也支持如下：范围(RANGE)分区:基于一个数值型范围划分数据，例如按着日期区间定义。值( LIST)分区:基于一个值列表划分数据，例如按着 城市属性定义多级分区表:上述两种类型的多级组合，最多支持三级分区分区表支持多种分区管理操作，包括新增分区，删除分区，重命名分区，清空截断分区，交换分区，分裂分区等注意:分区个数建议小于200，否则会影响查询的SQL优化性能https://help.alivun.com/document detail/118173.html 多级分区表设计实例，一级分区采用按月的区间（Range）分区，二级分区采用按地区的值（List）分区设计。​CREATE TABLE sales​​(id int, yoax int,month int, day int, region text)​​DISTRIBUTED BY (id)​​PARTITION BY RANGE(month)​​SUBPARTITION BY LIST (region)​​SUBPARTITION TEMPLATE(​​SUBPARTITION usa VALUES ('usa”)，​​SUBPARTITION europe VALUES ('europe") ,​​SUBPARTITION asia VALUES ('asia).​​DEFAULT SUBPARTITION other regions)​​(START (1) END (13) EVERY (1)，DEPAULT PARTITION other months );​支持数据按行存储或者按列存储列存根本上降低数据仓库大规模IO行存表:高吞吐写入更新，点查询数据按行存储，操作某列必须读入整行适合较多数据更新操作场景通过索引，支持高并发的点查询​CREATE TABLE foo (a INT，b TEXT) DISTRIBUTED BY (a);​列存表:批量加载，全表聚合，压缩率高、数据按列存储 -每一列单独存放只访问查询涉及的列-大量降低系统IO数据类型一致，数据特征相似 - 实现高压缩率适合更新少，全表聚合操作​CREATE TABLE foo (a INT，b TEXT)​​WITH (APPENDONLY = TRUE ， ORIENTATION​​=​​COLUMN)​​DISTRIBUTED BY (a);​多种压缩算法，成本和性能取得平衡数据压缩可用于列存表或者行存追加表，平均3倍以上数据压缩率 算法名特点压缩级别版本支持ZLIB标准、通用1-94.3,6.0ZSTD解压性能高1-196.0RLE主要针对数值类型 4.3,6.0​ ​CREATE TABLE foo (a int,b text)​​WIT日 (appendonly=true， orientation=column， compresstype=zstd, compresslevel=9)​​DISTRIBUTED BY (a);​列存也可以带上压缩，现在一般默认推荐LC4。相对来说LC4比zstd解压效果更好，但压缩效率差不多。统计信息：目前自动收集方式CPU的优化要根据统计信息来计算代价，所以统计信息的收集非常关键，现在是默认会收集统计信息。用下表中工具开发控制。如果关gp_autostats_mode参数值含义NONE关闭自动收集统计信息ON_CHANGE有数据更新超过一定行数时，收集统计信息(IUD、CTAS)ON_NO STATS默认值，无统计信息时，数据更新时，收集统计信息闭则默认不收集，下面的参数不用更改。之前有一个客户反映在insert时感觉比想象中的慢，然后发现后台在insert的时候，若这张表没有数据单场插入的时候会花一点时间收集统计信息。即这些统计信息在后台是默认的，用户不用太感知。·truncate语句会删除统计信息，再次插入数据时，数据表会处于无统计信息状态，再次插入数据时，会根据gp_autostats_mode参数按无统计信息处理ON_CHANGE更新行数阈值由gp_autostats_on_change_threshold控制 二、执行计划执行计划：两种收集模式收集模式说明explain 显示执行计划，不真正执行语句，在计划中显示估算信息explain analyze 显示执行计划，并且真正执行语句，在计划中显示真实执行信息收集模式在控制台的诊断模块有一个分析诊断功能，里面有图形化的展现，但目前来说只做到了运行后的图形化展现，还不能做到动态实时的展现图。 执行计划：explain计划项目含义说明算子名称 计划中算子节点的名字，以“->”开头进行缩进如例子中的Seq Scan、Sort、Gather Motion等算子属性 算子在本计划中的操作属性如例子中的Sort Key: b表示Sort算子的排序键是b列cost 估算的代价，包含启动代价和总代价，中间用“..” 间隔rows估算的行数width估算的每行的宽度，单位字节Optimizer 生成该计划的优化器名字，ADB PG具有优化器自适应功能，可能和用户设置的不一致如果explain估算出来的cost，估算大概有多少行，每一行的宽度，用的是postgres还是optimizer。执行计划：explain analyze 计划项目Planning time含义说明actual time实际执行时间，单位毫秒actual rows实际输出行数Planning time实际生成执行计划的时间Slice memory每个slice使用的内存情况Memory used整个查询使用的内存情况Execution time实际执行时间​(cost=2851.68..2934.18 rows=11000 width=16)(actual time=13.748..15.897 rows=11121 loops=1)​ ​前面为估算后面为真正执行时的行数。还可看出内存使用情况，判断内存是否足够或是否落盘。执行计划：如何发现问题（1）自上而下，梳理痛点·从上向下梳理计划，查看时间到底花在了什么算子上面，然后针对具体算子深入分析（2）查看代价，对比行数·查看比较代价估算的异常( 特别小或特别大)，对比估算行数和实际执行行数，找到代价估算和行数估算的问题（3）·耗时算子，尽量避免·AP场景很少需要NestLoop、Sort+GroupByAgg，遇到它们需要谨慎·(4)具体算子，是否合理·Motion:是否有不必要的Motion?是否可以优化分布键?是否可以使用复制表?·Join:内外表顺序是否合理?·Scan:是否可以使用索引?是否可以使用分区表?(5)内存信息，调整参数·查看下盘情况，分析后适当调整statement_mem参数通过索引提升查询性能 索引类型语句示例/适用场景B-treecreate index il on tl using btree (c1)适用大多数场景，尤其对于点查询和更新等操作Bitmap create index i2 on t2 using bitmap (c2)唯一值低于10w且任于总行数1/10，常与其他列有联合过滤条件GIN/GiST全文检索，数组，JSON 因为APE是兼容内核为9.4的PG的，有可能scanland可以加索引，如果用bitmap索引或许可以用class聚集一下等方面都存在优化手段，但各个业务场景不一样因此优化手段也不一样。优化建议where条件的过滤效果较好时，可以尝试添加索引。TP场景尤其需要梳理业务，创建合适索引创建索引后，建议进行统计信息收集不建议在更新较多的表上建索引，更新较为频繁的表上创建索引，会降低数据更新效率避免在一个表上建过多索引，一个表的索引数最好不超过6个避免创建包含列数过多的组合索引，建议组合索引中包含的列数少于3列组合索引是从前向后匹配where条件的，不能命中前导列的where条件，不会使用该索引批量导入大量数据前可删除索引，导入数据后重建索引避免创建重复的索引或具有相同前导列的索引三、常用调优方式SQL诊断通过pg_stat_activity视图查看当前耗时较长的SQL可看到当前正在运行中的一些circle，包括下表所示等内容 属性含义说明runtime语句执行的时长datname执行语句的数据库名usename执行语句的用户名waiting是否在等待waiting_reason等待的原因Query 执行的语句，有长度截断，可通过track_activity_query_size调整​select current timestamp - query_start as runtime, datname, usename, waiting, waiting_reason, query​​from pg_stat_activity​​where current_query != '<IDLE>' order by 1 desc;​常用调优方式：消除Redistribute Motion一种方法为分布键调整交易列，如果估算不太准，则可以把一张表建成一个分布表，每个节点一份，但这只针对小表，因为这很占用存储空间。 t1表的分布键为t1.a，t2表的分布列是t2.b会出现t2表的重分布 t1表的分布键为t1.a，t2表的分布列是t2.a无需重分布直接Join 常用调优方式:消除Broadcast Motion代价估算行数估算问题如果计划中，一个分支中出现多次Broadcast，则需要观察行数估算信息，是否行数估小了，是否收集了统计信息使用复制表如果计划中，在基表扫描后，出现一次Broadcast，可以考虑将基表改为复制表、 常见调优方法：避免下盘当分配给查询节点的内存不足以用来执行操作时，部分数据会下盘，影响查询性能优化建议:调整statement_mem(默认2GB)节点内存是有限的，每一条circle的内存使用也是有限的，因为如果每一条circle内存任务太多，会把系统打到MEM的，因此默认2GB，超了就会写磁盘，所以有的计算节点用的是临时磁盘大小，如果写落盘最多的一个节点不能超过60G。 其他调优方式：SQL优化策略（1）（1）优化能力相关优化的时候如果硬条件过多则优化circle的时间可能会较长。索引一般挑索引力度比较好的，因为有些索引可能建了也没什么效果，前面在讲膨胀的地方有一个诊断建了以后用了多少次，索引的扫描和表的全局扫描，在数据里面一个叫index scan,一个叫cicon scan，cicon scan顺序扫描全表，index scan用索引怎么做，诊断里面有一个index scan和cicon scan次数对比，如果建了一个索引发现cicon scan少了10次，而index scan只少了一次，则意味着带where 条件的那个索引优化性可能估算代价走cicon scan比走index scan好。也意味着索引建了可能没有什么效果，所以不是所有场景下都要建索引。·控制in条件或or条件的条目数量，过多的条目会导致ORCA优化时间加长尽量避免在where条件中使用复杂表达式或函数操作，可能导致优化器行数估算不准确.索引相关为避免全表扫描，可考虑在where条件上加索引where条件避免使用!=或<>操作符号，只有在=、<、<=、>>=、between时才可用到索引where条件中避免使用or条件，or条件会导致索引失效，若索引可提升性能，可使用union替代or条件like条件可考虑使用全文检索替代e（2）数据类型相关尽量使用数值类型，避免使用字符串类型，字符串类型会降低查询和连接性能尽量使用varchar(n)替代char(n)，节省存储空间，减小计算内存，加速字符串比较效率很多地方是follow PE思想的，PE思想在做字符串比较的时候，是有编解码相对数字比较耗时会更多一点，所以说通常情况下能用数值的用数值，有时候会发现有的客户有的字段DS叫日期，我们建议他建成timespace。但客户可能是从大数据那边过来的，就将它建成了DS字符串显示模式。但最好数比较多时间最好就建时间类型。其他调优方式:SQL优化策略(2)（1）输出列尽量避免使用select*，从业务角度优化需要的输出列。如果是纯列纯表就不要用select*，但有些地方临时表比较方便。（2）临时表复杂查询可使用临时表暂存中间结果，一方面方便业务调试，另一方面避免不必要的重复计算（3）where条件如果有in子句，尽量将出现频率高的值放在in子句的前面，减少比较次数（4）Join相关一个查询中参与Join的表数量控制在12个以内，多余12个表join，可以考虑使用临时表拆分语句（5）存储过程/函数能使用SQL语句实现的，不要用循环去实现

问题原因您在更新时遇到错误代码1：8024400A ，错误代码2：80072EE2 ，这两个报错导致不能更新。第一个报错是由于更新服务器请求数过多，服务器访问繁忙导致。第二个报错是Windows更新服务器可能遇到异常多的更新请求。解决方案阿里云提醒您：如果您对实例或数据有修改、变更等风险操作，务必注意实例的容灾、容错能力，确保数据安全。如果您对实例（包括但不限于ECS、RDS）等进行配置与数据修改，建议提前创建快照或开启RDS日志备份等功能。如果您在阿里云平台授权或者提交过登录账号、密码等安全信息，建议您及时修改。请您参考以下场景进行操作。针对错误代码1的方法您可以尝试稍后再进行更新。针对错误代码2的方法您可以参考以下步骤操作。关闭Windows更新服务。删除临时更新文件。打开更新服务，再次尝试更新。

RedisShake基本介绍RedisShake是基于redis-port基础上进行改进的是一款开源的Redis迁移工具，支持Cluster集群的在线迁移与离线迁移（备份文件导入）。数据可平滑迁移，当部署在其他云厂商Redis服务上的Cluster集群数据，由于SYNC、PSYNC命令被云厂商禁用，无法在线迁移时，可以选择离线迁移。RedisShake使用背景RedisShake是一个用于在两个Redis实例之间同步数据的工具，满足非常灵活的同步与迁移需求。Redis实例之间的关系其中可能存在（standalone->standalone），（standalone->Cluster），（Cluster->Cluster）等。目前，比较常用的一个数据迁移工具是Redis-Shake ，这是阿里云Redis和MongoDB团队开发的一个用于 Redis 数据同步的工具。RedisShake功能说明RedisShake主要是支持Redis的RDB文件的解析、恢复、备份、同步四个功能：恢复（restore）：将 RDB 文件恢复到目标Redis数据库。备份（dump）：将源 Redis 的全量数据通过RDB文件备份起来。解析（decode）：读取 RDB 文件，并以 JSON 格式解析存储。同步（sync）：支持源redis和目的redis的数据同步，支持全量和增量数据的迁移，支持从云下到阿里云云上的同步，也支持云下到云下不同环境的同步，支持单节点、主从版、集群版之间的互相同步。同步（rump）：支持源 Redis 和目的 Redis 的数据同步，仅支持全量迁移。采用scan和restore命令进行迁移，支持不同云厂商不同redis版本的迁移。注意：如果源端是集群版，可以启动一个RedisShake，从不同的db结点进行拉取，同时源端不能开启move slot功能；对于目的端，如果是集群版，写入可以是1个或者多个db结点。Redis-Shake特性概览高性能：全量同步阶段并发执行，增量同步阶段异步执行，能够达到毫秒级别延迟（取决于网络延迟）。同时，我们还对大key同步进行分批拉取，优化同步性能。在 Redis 5.0、Redis 6.0 和 Redis 7.0 上测试支持使用lua自定义过滤规则支持大实例迁移支持restore模式和sync模式支持阿里云 Redis 和 ElastiCache监控体系：用户可以通过我们提供的restful拉取metric来对redis-shake进行实时监控：curl 127.0.0.1:9320/metric。数据校验：如何校验同步的正确性？可以采用我们开源的redis-full-check。支持版本：支持2.8-5.0版本的同步，此外还支持codis，支持云下到云上，云上到云上，云上到云下（阿里云目前支持主从版），其他云到阿里云等链路，帮助用户灵活构建混合云场景。断点续传。支持断开后按offset恢复，降低因主备切换、网络抖动造成链路断开重新同步拉取全量的性能影响。RedisShake执行过程启动Redis-shake进程，这个进程模拟了一个 Redis 实例，Redis-shake的基本原理就是模拟一个Slave从节点加入源Redis集群，然后进行增量的拉取（通过psync命令）。Redis-shake进程和数据迁出的源实例进行数据的全量拉取同步，并回放，这个过程和 Redis 主从实例的全量同步是类似的。如下图所示。详细分析上述同步原理源Redis服务实例相当于主库，Redis-shake相当于从库，它会发送psync指令给源Redis服务实例。源Redis实例先把RDB文件传输给 Redis-shake ，Redis-shake 会把RDB文件发送给目的实例。源实例会再把增量命令发送给 Redis-shake ，Redis-shake负责把这些增量命令再同步给目的实例。如果源端是集群模式，只需要启动一个redis-shake进行拉取，同时不能开启源端的move slot操作。如果目的端是集群模式，可以写入到一个结点，然后再进行slot的迁移，当然也可以多对多写入。目前，redis-shake到目的端采用单链路实现，对于正常情况下，这不会成为瓶颈，但对于极端情况，qps比较大的时候，此部分性能可能成为瓶颈，后续我们可能会计划对此进行优化。另外，redis-shake到目的端的数据同步采用异步的方式，读写分离在2个线程操作，降低因为网络时延带来的同步性能下降。Redis-Shake安装使用主要有两种方式：下载Release版本的可执行二进制包、下载源码文件进行编译操作这两种方式。下载Release版本的可执行二进制包Download from Release点击下载就可以进行直接使用Redis-Shake服务。下载源码文件进行编译操作除了直接下载可执行包之外，还可以下载源码之后，可以进行运行build.sh文件执行进行编译源码，生成可执行包。可以根据上面的下载中source code进行下载。或者可以针对于Git进行clone源码仓库，如下所示。git clone https://github.com/alibaba/RedisShake cd RedisShake sh build.sh 复制代码运行Redis-Shake服务首先如果需要进行同步和重放，则需要进行编辑sync.toml文件以及编辑restore.toml.redis-shake 支持三种数据迁移模式：sync、restore 和 scan：快速开始：数据迁移（使用 sync 模式）快速开始：从dump.rdb恢复数据（使用 restore 模式）快速开始：数据迁移（使用 scan 模式）使用 filters 做数据清洗运行日志运行监控启动同步sync运行机制我们打开或者编辑sync.tomlsync.toml文件内容当我们编辑sync.toml文件之后，可以进行配置我们实际情况下的source源redis实例以及target目标redis实例。之后可以配置对应的cpu和相关性能的配置。下面针对于配置进行相关的配置介绍type = "sync" # 同步机制实现 [source] # 源Redis服务实例 version = 5.0 # 填写Redis源服务版本, 例如：2.8, 4.0, 5.0, 6.0, 6.2, 7.0, ...。 address = "127.0.0.1:6379" # 源Redis服务实例 地址+端口 username = "" # 如果Redis没有配置ACL，则可以不填写，否则需要填写用户名 password = "" # 如果Redis没有配置ACL，则可以不填写，否则需要填写密码 tls = false # 是否开启tls安全机制 elasticache_psync = "" # 是否支持AWS的elasticache [target] type = "standalone" # 选择Redis的类型："standalone：单机模式" or "cluster：集群模式" version = 5.0 # 填写Redis源服务版本, 例如：2.8, 4.0, 5.0, 6.0, 6.2, 7.0, ...。 # 如果目标Redis服务实例属于cluster集群模式, 那么可以写入其中一个节点的地址和端口. # redis-shake 会通过`cluster nodes` 命令获取其他的节点地址和端口 address = "127.0.0.1:6380" # 填写的对应的ip加端口 username = "" # 如果Redis没有配置ACL，则可以不填写，否则需要填写用户名 password = "" # 如果Redis没有配置ACL，则可以不填写，否则需要填写密码 tls = false # 是否开启tls安全机制 [advanced] dir = "data" # 数据同步的存储目录 # 设置使用的最大CPU核心数, 如果设置了0 代表着 使用 runtime.NumCPU() 实际的cpu cores数量 ncpu = 4 # 开启pprof性能检测的port, 0代表着禁用 pprof_port = 0 # 开启metric port端口, 0代表着禁用 metrics_port = 0 # log的相关设置 log_file = "redis-shake.log" # 设置对应的日志文件名称 log_level = "info" # debug, info or warn # 设置对应的日志级别 log_interval = 5 # in seconds # 日志打印频次 # redis-shake gets key and value from rdb file, and uses RESTORE command to # create the key in target redis. Redis RESTORE will return a "Target key name # is busy" error when key already exists. You can use this configuration item # to change the default behavior of restore: # panic: redis-shake will stop when meet "Target key name is busy" error. # rewrite: redis-shake will replace the key with new value. # ignore: redis-shake will skip restore the key when meet "Target key name is busy" error. rdb_restore_command_behavior = "rewrite" # restore的操作类型：panic, rewrite or skip # pipeline的大小数量阈值 pipeline_count_limit = 1024 # Client query buffers accumulate new commands. They are limited to a fixed # amount by default. This amount is normally 1gb. target_redis_client_max_querybuf_len = 1024_000_000 # In the Redis protocol, bulk requests, that are, elements representing single # strings, are normally limited to 512 mb. target_redis_proto_max_bulk_len = 512_000_000 复制代码Redis单机实例同步到Redis单机实例修改sync.toml，改为如下配置。[source] address = "ip:6379" password = "" [target] type = "standalone" address = "ip:6379" password = "r-bbbbb:xxxxx" 复制代码启动 redis-shake：./redis-shake sync.toml 复制代码Redis单机实例同步到Redis集群实例修改 sync.toml，改为如下配置：[source] address = "r-aaaaa.redis.zhangbei.rds.aliyuncs.com:6379" password = "r-aaaaa:xxxxx" [target] type = "cluster" address = "192.168.0.1:6379" # 这里写集群中的任意一个节点的地址即可 password = "r-ccccc:xxxxx" 复制代码启动 redis-shake：./redis-shake sync.toml 复制代码Redis集群实例同步到Redis集群实例方法1：手动起多个 redis-shake集群C有四个节点：192.168.0.1:6379192.168.0.2:6379192.168.0.3:6379192.168.0.4:6379把4个节点当成4个单机实例，参照单机到集群 部署 4 个 redis-shake 进行数据同步。不要在同一个目录启动多个 redis-shake，因为 redis-shake 会在本地存储临时文件，多个 redis-shake 之间的临时文件会干扰，正确做法是建立多个目录。方法2：借助 cluster_helper.py 启动脚本cluster_helper.py可以方便启动多个redis-shake从集群迁移数据，效果等同于方法1。注意源端有多少个分片，cluster_helper.py 就会起多少个 redis-shake 进程，所以如果源端分片数较多的时候，需要评估当前机器是否可以承担这么多进程。cluster_helper.py 异常退出的时候，可能没有正常退出 redis-shake 进程，需要 ps aux | grep redis-shake 检查。每个 redis-shake 进程的执行日志记录在 RedisShake/cluster_helper/data/xxxxx 中，反馈问题请提供相关日志。依赖Python 需要 python3.6 及以上版本，安装 Python依赖：cd RedisShake/cluster_helper pip3 install -r requirements.txt 复制代码配置修改 sync.toml:type = "sync" [source] address = "192.168.0.1:6379" # 集群 C 中任意一个节点地址 password = "r-ccccc:xxxxx" [target] type = "cluster" address = "192.168.1.1:6380" # 集群 D 中任意一个节点地址 password = "r-ddddd:xxxxx" 复制代码运行cd RedisShake/cluster_helper python3 cluster_helper.py ../redis-shake ../sync.toml 复制代码参数 1 是 redis-shake 可执行程序的路径参数 2 是配置文件路径查看redis-shake的日志信息[root@redis ~]# redis-shake ./redis-shake.toml 2022-08-26 11:20:28 INF GOOS: linux, GOARCH: amd64 2022-08-26 11:20:28 INF Ncpu: 3, GOMAXPROCS: 3 2022-08-26 11:20:28 INF pid: 21504 2022-08-26 11:20:28 INF pprof_port: 0 2022-08-26 11:20:28 INF No lua file specified, will not filter any cmd. 2022-08-26 11:20:28 INF no password. address=[127.0.0.1:6380] 2022-08-26 11:20:28 INF redisWriter connected to redis successful. address=[127.0.0.1:6380] 2022-08-26 11:20:28 INF no password. address=[127.0.0.1:6379] 2022-08-26 11:20:28 INF psyncReader connected to redis successful. address=[127.0.0.1:6379] 2022-08-26 11:20:28 WRN remove file. filename=[4200.aof] 2022-08-26 11:20:28 WRN remove file. filename=[dump.rdb] 2022-08-26 11:20:28 INF start save RDB. address=[127.0.0.1:6379] 2022-08-26 11:20:28 INF send [replconf listening-port 10007] 2022-08-26 11:20:28 INF send [PSYNC ? -1] 2022-08-26 11:20:28 INF receive [FULLRESYNC 1db7c7618b6d0af25ffafb1645d4fba573624d02 0] 2022-08-26 11:20:28 INF source db is doing bgsave. address=[127.0.0.1:6379] 2022-08-26 11:20:28 INF source db bgsave finished. timeUsed=[0.09]s, address=[127.0.0.1:6379] 2022-08-26 11:20:28 INF received rdb length. length=[194] 2022-08-26 11:20:28 INF create dump.rdb file. filename_path=[dump.rdb] 2022-08-26 11:20:28 INF save RDB finished. address=[127.0.0.1:6379], total_bytes=[194] 2022-08-26 11:20:28 INF start send RDB. address=[127.0.0.1:6379] 2022-08-26 11:20:28 INF RDB version: 8 2022-08-26 11:20:28 INF RDB AUX fields. key=[redis-ver], value=[4.0.14] 2022-08-26 11:20:28 INF RDB AUX fields. key=[redis-bits], value=[64] 2022-08-26 11:20:28 INF RDB AUX fields. key=[ctime], value=[1661484028] 2022-08-26 11:20:28 INF RDB AUX fields. key=[used-mem], value=[1897096] 2022-08-26 11:20:28 INF RDB repl-stream-db: 0 2022-08-26 11:20:28 INF RDB AUX fields. key=[repl-id], value=[1db7c7618b6d0af25ffafb1645d4fba573624d02] 2022-08-26 11:20:28 INF RDB AUX fields. key=[repl-offset], value=[0] 2022-08-26 11:20:28 INF RDB AUX fields. key=[aof-preamble], value=[0] 2022-08-26 11:20:28 INF RDB resize db. db_size=[1], expire_size=[0] 2022-08-26 11:20:28 INF send RDB finished. address=[127.0.0.1:6379], repl-stream-db=[0] 2022-08-26 11:20:28 INF start save AOF. address=[127.0.0.1:6379] 2022-08-26 11:20:28 INF AOFWriter open file. filename=[0.aof] 2022-08-26 11:20:29 INF AOFReader open file. aof_filename=[0.aof] 2022-08-26 11:20:33 INF syncing aof. allowOps=[0.20], disallowOps=[0.00], entryId=[0], unansweredBytesCount=[0]bytes, diff=[0], aofReceivedOffset=[0], aofAppliedOffset=[0] 2022-08-26 11:20:38 INF syncing aof. allowOps=[0.20], disallowOps=[0.00], entryId=[1], unansweredBytesCount=[0]bytes, diff=[0], aofReceivedOffset=[14], aofAppliedOffset=[14] 2022-08-26 11:20:43 INF syncing aof. allowOps=[0.00], disallowOps=[0.00], entryId=[1], unansweredBytesCount=[0]bytes, diff=[0], aofReceivedOffset=[14], aofAppliedOffset=[14] 2022-08-26 11:20:48 INF syncing aof. allowOps=[0.20], disallowOps=[0.00], entryId=[2], unansweredBytesCount=[0]bytes, diff=[0], aofReceivedOffset=[28], aofAppliedOffset=[28]

开发者学堂课程【E-MapReduce入门：走进开源大数据平台 EMR】学习笔记，与课程紧密联系，让用户快速学习知识。课程地址：https://developer.aliyun.com/learning/course/329/detail/3700走进开源大数据平台 EMR内容介绍：一、 EMR 产品的介绍和特点二、 EMR 的发展历程三、 现状四、 为什么选择 EMR五、 展望一、EMR 产品的介绍和特点在当前大数据技术是非常热门的技术趋势，其中开源大数据技术在解决互联网公司传统的企业大数据问题，包括大数据分析、 BI 报表、实时的数据处理、人工智能等问题方面发挥了非常大的作用。阿里云从2015年开始在云上构建大数据产品 EMR ，主要是将大数据的组件跟云相结合，来解决传统的 IDC 构建、自建大数据的系统向云上的牵引。EMR 产品主要包含以下几个方面的特点:1）整个系统的组建与开源大数据组件完全兼容，其中包括常用的大数据组件 HDS ，YARN ，Hive ，Spark 等等，能够暂时解决客户的各种大数据问题。2） EMR 产品是基于阿里云非常先进的 ISC 基础底座 ECS 来构建，具备极度的弹性性能，能够根据用户业务的需求以及业务的成长和缩减来进行弹性升缩3） EMR 支持计算存储分离的价格，计算存储两种资源能够分别截偶，这样可以极大地降低客户的这个成本。4） EMR 整体的组件性能包括 Hive 、 Spark 在全球处于领先地位，在常见的 TPC 的标准 benchmark 中，EMR 的性能长期处于前列，在最新的 EMR 版本中也支持了阿里云的数据湖解决方案，数据湖能够做到打破数据孤岛、原数据共享、计算容器化等最佳的用户实践。本次训练营包括理论和实践两个部分。二、EMR 的发展历程主要讲述产生 EMR的原因和 EMR 过去四年时间的变化1、早期大数据平台早期在阿里云使用大数据平台拥有三种选择：(1) 采用阿帕奇log社区开源版本去构建一个大数据平台，不仅包含Hadoop，还包括 Hive 、HBase、Kudu、 Impala 组件。采用此版本去构建开源大数据平台，对个人的要求比较高，一方面要考虑到组件之间的兼容性，第二方面社区并没有提供一个比较清晰的控制台界面，所以很多命令以及运维工作都需要在黑屏的方式下去操作，比较大的限制了Hadoop 这个平台的利用性，以及使用的门槛。(2) 采用基于 Hadoop 社区的很多发行版厂商提供的一些发行版软件，相对来说提供了比较完善的组件的兼容性测试，以及控台界面的功能，对用户来说是比较友好的。(3) 使用阿里云自研的一款开源大数据平台 MaxCompute ，以前简称叫做 ODPS ， MaxCompute 是名称修改之后的称呼，它是一个完全基于自研的超大规模的大数据分析平台，用法跟 Hive 非常类似。2、发展历程这个产品最早的时候是在2015年6月份在云上发布上线的，当时不叫 EMR ，只是 Spark 的一个镜像，在早期的时候只可以通过使用这个镜像把这个镜像下载到 ECS 上，快速搭建一个 Hadoop 和 Spark 集群，使用 Spark on Yarn 方式来运行，Spark命令，在2015年的11月份产品正式立项，作为一个正式的独立产品对外发布，2016年6月开始公测，产品正式商业化，达到 SAR 的要求，然后开始对外提供服务。目前EMR作为阿里云上非常重要的一款云上开源大数据生态级的产品，已经经历了一个商业化的历程。(1) 在最早期国外的厂商上有类似 EMR 的产品，但是发现这种产品的一个特点是云原生的面向于临时集群，一个任务其中一个集群用这种方式来做的一款产品，产品在最早期的时候拥有很多用，需求也比较简单，就仅仅是运行一个大数据的任务，通过这种临时集群能比较好的满足要求。任务运行完毕进行释放，对于比较简单的分析场景是完全能够满足的。(2) 随着国内市场的发展和一些更多客户的交流发现，更多的是需要一种长储集群，不仅是因为任务数比较多还比较难准确的预估出资源消耗的一个情况，所以在IDC里面建立一个集群，然后跑着大量的任务，当迁移上云的时候，这个 Gap 是比较大的，从一个能全量的一个集群转到云上完成任务，通过任务来集群，然后再评估需要多少资源，在这种情况下发现用户在上云的时候要求一个比较强的运维能力和相应的集群管理能力，同时也希望一个更好的工作流调度的一个工具来帮助他更好地管理集群、运维集群，降低开源大数据的一个使用门槛，在这种情况下产品有了一系列的转化，增加了很多组件管理的功能，增强了工作流管理1.0的开发，最早是在2017、2018年上线的。经过一段时间产品的打磨之后发现它大大降低了用户的一个试用门槛，不仅运行一个任务，在这种情况下能够承载更多的大客户，从IDC搬占上云任务工作流比较复杂，面临着一个多样化的组件选择的时候产品有满足这种需求。(3) 开源大数据的场景不断丰富，技术也不断的演进和向前迭代，在这种情况下对于集群的稳定性、安全性提出了更高的要求，所以在这个阶段把 Kubers 和 Runner 集成进来作为统一的集群权限管理和统一的健全管理的一个工具和组件。基本上主要的组件都已经实现了高可用的架构，包括像 HDFS 的 NameNode、 ER 的 Softmanager、 HBase 、Hmaster 服务都可以做到 HAR 降低了用户自己去配置 HU 的复杂度和管理成本。同时不断的去拓展开源大数据的使用场景，在不断的迭代过程中加入了很多像 Kafka 、 Impala 的开源大数据组件，同时机器学习、深度学习技术成长非常迅速，机器学习和深度学习与大数据分析是一个上下游的关系，机器学习、深度学习的数据要依赖于大数据分析的这个ETL或者舒畅的一个产出。这种情况下把机器学习的集群加入到独立的集群类型来进行统一的管理。(4) 随着产品的不断成熟到了第四个阶段，更好的去串联云上的大数据生态，这种情况下要求集群的组织更加的轻量级，智能化。在这个阶段寻找如何更好的去串联云上的各种生态，目前已经实现了 PAI - EMR 的产品结合。在创建集群使用 ESC 集群类型，使用 tendsor 组件、A link no组件，都是完全从 PAI 这个产品里导入过来的，它使用的不仅是开源，而是对开源技术的增强，同时很多用户希望在开源大数据生态里使用 DataWorks 这一比较成熟的工作流调度，权限管理、数据治理、数据地图的一块工具来构建自己的数据状态，帮助自己快速的上手，在这种背景下也跟 DataWorks 做深度的集成，目前向数据学、数据治理、数据质量已经陆陆续续的上线，后面会把 DataWorks 的权限管理跟 EMR 进一步打通，实现了 DataWorks 、EMR 能够有一个更好的更完整的用户体验，目前另外一个趋势就是很多用户在使用开源大数据的时候，不仅是 Unisys ，还有一些对于 k8s 的需求，所以目前也上线了 k8s 集群类型，也是能够更好的帮助用户去管理集 群，底层的资源。三、现状1、EMR 开源软件栈这是云上的开源大数据生态的软件站，这套软件站分为四个部分：(1)深蓝色的部分主要是开源大数据生态的组建，基本上没有太多的修改而且纯粹是基于社区开源的一个集成，在这种情况下使用开源是完全没有差别的.(2)另外针对用户一些使用的场景会对开源组件进行一系列的修改和增强，这就是浅绿色的一个组件啊比如说像 Spark 这块做了一系列的性能增强而且是比开源的性能有大幅的提升，但是这种增强完全不影响对于开源的一种使用体验。也就是说使用 Spark 组件完全可以和开源一样而且优化也是采用插件的机制，可以通过参数的方式打开或者关闭，对于浅绿色部分来说就是基于开源对开源有一系列的性能增强。(3)橙色部分是自研的组件比如说像 EMR Agent 是一套集群管理的组件，这套并不是开源大数据的组件但是属于对集群管理必备的一个组件，另外一方面比如说像 JinduFS 是从去年正式对外发布了一块数据湖构建的重要组件，今年性能有了大幅度的提升、功能有了快速的增强和完善目前有大量的用户是通过使用 JinduFS 快速构建云上的数据湖，实现了数据的分层存储，达到了社作业性能的提升。(4)浅蓝色的部分是利用开源大数据生态跟阿里云现有的产品，产品保护下，刚才提到了 DataWorks 、PAI、OSS、ECS、SLS这些产品。2、开源软件栈发展开源软件栈从一六年这个产品诞生以来不断的去丰富和增强，这几年的发展基本上还是按照开源大数据的组件和场景上的应用的拓展，软件站也不断的丰富，比如在一七年加入了 Presto、Impala ，在一八年加入 Flink 属于科学集群，在一九年对 Hadoop 版本做了比较大的版本升级，不只是支持好多二点几的版本，同时也支持很多三点几的版本，目前 EMR 软件站有两个分支，一个是 EMR 3.x 的版本，对应的就是 Hadoop 2.x 的版本，另一个分支对应的 EMR 4.x 的开源组件对应的是 Hadoop 3.x 的版本。Hadoop 3.x 的版本，同时支持Hadoop 3、Hive 3、HBS 2。 Hadoop 2.x 的版本，对应的就是 Hadoop 2.、2.8、2.5、 Hive 3.1.3，Hive 2.4.5以及HBase 1.4.9版本，同时根据不断的场景，数据仓库建设的场景，介绍一下 Presto、Impala ，用来做交互式分析和收藏数据查询，同时针对在一八年开始比较流行的Flink也加入到软件站来，用流失计算以及围绕大数据和AI的融合，上线了数据科学集群，里边就支持 TF on YARN 、Spark 这些计算框架，这些计算框架的引入能够帮助用户实现从大数据分析到机器学习一体化的架构。云上数据湖的不断的发展也加入了 Delta Lake、Kudo 组件，能够帮助用户快速的去构建影像数据库的一个平台，能够支持对数据的更新、查询、快速的一个实时数仓的构建。3、EMR 集群类型Data Science集群， Alink 是基于Flink 的继续学习组件， Data Science集群最大的一个优势在于它是一个半托管的架构，它跟 EMR 其他的集群类型一样，都是一个半托管的架构，在这种情况下可以更加方便简单的去安装，继续学习，深度学习常用的一些包更加灵活透明，用户可以自定义的去部署自己的软件环境，更加容易把继续学习、深度学习和大数据串联在一起。kafka 消息队列集群类型，目前采用两个版本，一个是 EMR 3.x的版本，主要用 kafka 1.x 的版本， EMR 4.x的版本，采用 kafka 2.x 的版本。除了提供 kafka 这个组件，做了一系列包括源数据管理的增强。Data Flow 集群类型，采用 Flink on YARN 这种架构，Flink 用的不是开源 Flink ，而是用的 wrkperform 组件。如果需要一个比较轻量级的一个机器学习的流失计算的引擎，可以采用Data Flow 集群类型，它相对于开源来说有更好的性能以及更加完善的用户体验，继承了 Alink 组件，可以实现流失的继续学习的功能和能力，浅层的算法是完全足够的。当集群规模非常大的时候可以考虑把主集本从主集群里面拿出来作为一个独立的分布式的一个能力，这种情况下你可以选择 Zookeeper 类型集群。实时 OLAP 集群类型，独立的 Druid 集群，数据平台： Hadoop、JinduFS、OSS、 depstor存储，最新版本0.18，非常新的版本。 四、为什么选择 EMR1、EMR 有四个比较重要的产品特性：(1)第一个是开源，所有的组件都是基于开源组件来做的，而且会跟着开源社区的发展不断的去迭代演进，同时因为这个不仅是对开源软件的集成，而且会对一些组件的版本进行适配确保这个组件的兼容性，相对来说有着更好的稳定性。(2)第二个因为基于开源社区做了一系列的性能优化，所以它的性能会比开源的版本有比较大的提升。EMR 会基于开源大数据的生态在阿里云上针对阿里云的环境去做一系列的弹性能力，按量付费的能力，不需要去预估基金规模到底有多大，到底需要多少的数据存储，只需要根据按量使用，按需去统括弹性扩展，能够迅速满足对资源的需求，也就是比如这块的业务爆发的非常迅速，在这种情况下，可能会需要快速的去部署一些云商的资源，用 EMR 就能实现分钟级别的创建集群，分钟级别的去扩展集群，同时面临大数据计算是一个典型的有波峰波谷的特性。就像，可能在晚上12点以后会有一个比较大的任务，把日报这种任务提交上来，在这种情况下，这个任务需要比较高的 SLA 保障，在白天这个任务跑完之后，可能会面临资源的低谷，这种情况下，通过 EMR 弹性伸缩的能力，可以很好的去配合弹性资源的计算，从而达到一个成节省成本的效果。(4)第四个主要是可以更好去对接云上的这个生态，相对于社区的组件，它更多的是一个通理上的考虑， EMR 产品会更好跟云上的一些产品的集成适配，云上更多的场景比如说像数据状态、数据、管理，在云上都有工具和一系列的这个产品， EMR 产品可以更加容易的去跟这些平台做集成和打通。2、计算弹性资源计算的弹性方面， EMR 的集群部署分为三种角色, Master 类型的集群、Core 类型的集群、Task 集群的类型。(1) Master集群主要是部署 Master 服务，包括 HDS 的 Namenode、Resource manager 、HBase 的 HMaster 服务。(2) Core 节点部署的除了存储还有计算的sleeve的服务，包括比如 HDFS 的DataNode 、ER 的Node Manager 。这些服务都部署在Core节点上。(3) Task 节点仅仅用来部署计算服务，包括 YAD、nodemanager ，这种服务是部署在 Task 节点上。因为Care节点不属于像 DataNode 、HBase 、Resource 服务，所以在集群模型里面是不允许弹性伸缩的，而 Task 节点因为它是一个纯计算节点，所以弹性伸缩起来是相对比较方便，而且对任务的影响、对业务的影响都是比较小的，在这种目前的这种集群架构下 Task 节点是可以灵活的去做弹性的。这个集群可以包年包月的去买，也可以用按量付费的方式去买，同时也可以在一个集群下面， Master 和 Core 采用的是包年包月的方式因为这种资源相对来说是固定的，同时用包年包月的方式去购买，也可以节省成本， Task 节点因为它是一个只需要做计算的一个节点，所以它可以用来做弹性伸缩，可以用按量付费的方式去购买，同时 Task 节点在用弹性伸缩的时候，也支持使用 spot ，就是抢占式实例去对资源进行成本的降低， spot 目前的成本仅仅是按量付费的一到两周，但是因为 spot 它的 SLA 是比较低的仅仅能保证每个小时是可以正常使用的，一个小时之后会重新竞价，由于库存或者竞价的原因无法进价的话，可能会对任务的运行产生一些影响，所以在任务运行选择范围的实力的时候，需要考虑到总体的政务的 SLA 的要求，弹性伸缩的方式支持包年包月，也是支持按时间弹性伸缩或者反复的进行弹性伸缩的两种方式，或者可以设置一个按时间伸缩的规则，比如在每天晚上12点开始做弹性伸缩的动作，然后这个任务比如能精确的预估出这个任务会在六点或者七点跑完，到了七点，再进行一个收容动作，确保这个任务能够实现一个成本的节省，也可以实现按负载伸缩，目前 YARN 的负载指标主要是采用了 YARN 的一些 mature 信息，包括 YARN 的一些比如 application running ，APPpending，Never usage，Cpuusage 这些指标来进行 YARN 的触发的一个trigger，这个指标达到一个需要设定的预警值或者弹性伸缩的门槛的时候，开始做一个弹性的动作，扩容或者缩容。3、多样化存储解决方案云上存储有多样化的解决方案，可以使用和线下 IDC 一样的 HDFS ，也可以使用Alibaba HDFS 服务或者使用 OSS (Standard) 类型，每种服务都有不同的特点和特显，重点介绍 HDFS 和 OSS. 当使用 HDFS 服务时，有两种选择一种是使用快存储 EBS ，另一种使用实例存储（本地盘实例/ I 系列/本地 SSD 实例） D1、D2 系列，本地盘实例特点为成本低，但是数据壳为应用层来保障，比如 HDFS 三副本策略来保证数据的应用。数据量比较小的情况下建议使用云盘，数据小于10tb以下，因为本地盘购买是一块物理盘，存储空间比较大。所以数据小于10tb或者20tb时建议使用块存储 EBS、HDFS。这种情况的优势为比较灵活、随着数据量增长不断的更加灵活扩单排容量，问题为成本相对来说较高。因为它的数据可靠性是通过产品上的冗余或者数据化来实现的，所以它在性能上比本地盘的实力会相对来说更低一些，但是它的可靠性会更高一些。总体来说，运维成本也会更低，因为它的数据可靠性是由 EBS 产品来保障的，当选择本地盘实例，也就是 D 系列或者 I 系列它的数据因为应用层是来保障数据可靠性，所以运维成本会相对来说更高，但是因为它本地是一块物理盘，所以它的购买成本是更低的，需要根据具体业务上的考量来选择合适的存储方式，来构建 HDFS 。 D 系列、I 系列使用 HDFS 的数据是三副本，因为应用层来保障数据可靠性，当采用 EBS 块存储的时候， EMR 副本数会默认设置为R，因为本身 EBS 就有数据可靠性的保障。当选择使用 OSS 的时候，优势是 OSS 的本身就是服务化的存储产品，所以使用成本和维护成本是更低的。但是，因为本身对象存储并不是针对大数据来设计开发，所以使用的性能会存在一个相较于 HDFS 在做 relief 操作、做 list 源数据操作的时候，性能会比HDFS要低一些。但是，总体来说能实现很好的按量使用，比如 10tb的存储使用 OSS 需要支付 10tb 存储空间的成本就可以。 JinduFS 可以更好的去帮助用户使用 OSS ，它是基于 OSS 之上做的一系列的分装，能够实现更好的性能，经过一系列的测试 JinduFS 的性能比 HDFS 性能更优，同时，有更好的数据可靠性和更低的成本管理，能很好地实现数据的分层存储，可以手动的指定通过调用 HDFS 、 JinduFS 的接口实现数据分层存储形式为标准型、低频型、归档型，根据数据的价值选择数据的存储的介质。但问题为 JinduFS 本身是采用了 cache 的模式， 把一系列的热数据 cache 到本地，所以成本需要付出一部分额外的本地 cache 的存储。4、灵活的集群架构通过计算和存储的结构可以采用 OSS 或者 JinduFS 的方式来实现计算和存储的金额，可以实现更灵活的经营架构，比如所有的原数据都存储在 RDS 或者类似于 RDS 的政府工程建设的时候，集群可以实现更灵活的创建、释放、弹性伸缩的动作，也可以综合集群共享一个GB 来实现源数据统一的管理和治理。顶上的集群比如有个 hadoop 集群啊，但是点到的 hadoop 集群上面可能有多种计算引擎，像 spark 引擎、Presto 引擎、Hive 引擎、Flink引擎，都去访问同一个 Matstore 的时候就可以实现源数据共享。同时因为数据都保存在一个 HDFS 或者 OSS 里，因为数据也可以实现跨集群共享的，计算引擎可以实现灵活的弹性的方式。有任务的时候可以实现弹性伸缩，没有任务时可以实现缩容把集群释放掉都是可以的，数据持久性的保存在 hadoop 集群里。五、展望第一， EMR 是一个有深入的产品，因为它的产品会随着开源社区的技术演进以及开源大数据的场景拓展不断的去丰富自己的场景和边界，同时也可以根据社区的版本来迭代连接测试版本。之后发布 Spark 3.0 版本，相对来说是包含了很多 Spark 3 的特性，希望用户体验最新的 EMR 版本的产品。同时产品也会根据阿里云做基础设施的升级，去不断的让客户利用。比如最近 ECS 即将发布的 AMD 的实力也会在今年完成对 AMD 实力的适配。AMD相对于英特尔的芯片的实力, 都是 X86 架构的,但是它的成本会更低，用在做 Task 节点、Master 节点的时候可以大幅有效的降低存储的计算成本，随着大数据容器化发展方向的不断成熟，比如 Spark 、on keep as技术实例的不断成熟，也会跟进技术方向去推进相应的集训类型，让更多的用户去探索新的大数据、技术发展，给用户带来产品上、功能上的体验和成本的节省。第三个方向会在基于阿里云平台去对接更加灵活的购买方式，目前 EMR 已经支持按量付费、包年包月、抢占式实例三种，去年阿里云发布了预留实例，在购买 EMR 的时候也可以预留实例，随着阿里云不断的推出新的购买形态也是可以随时更加灵活的去支持这种购买形态，实现用户红利，可以拿到这部分硬件的红利和一部分云生态的红利。第四部分会在数据湖场景，对于计算存储分离的场景在使用的时候去做一系列大量的优化，能够更好地实现在云上按量付费，按量使用的方式，不用再去做资源的预估，而是根据业务的发展方向，更好的去实现根据所需的容量去付费的方法方向。