开发者学堂课程【数据仓库 ACP 认证课程：【视频】云原生数据仓库 Analyticdb MYSQL 版-解析与实践-3】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/928/detail/14625
【视频】云原生数据仓库 Analyticdb MYSQL 版-解析与实践-3
5. DML 外表式数据导入导出-oss
步骤与刚才讲解的类似：
（1）确定目标和源表：
OSS：文件
AnalyticDB：数据表
首先确定目标和源表，oss上均是以文件的形式存储，以文件形式进行导入，加载到analyticDB MYSQL 当中，同样可以将analyticDB MYSQL 数据导出到文件当中。
（2）创建映射表：
AnalyticDB中创建该数据表的映射表
（3）DML命令导出
通过INSERT INTO或者INSERT overwrite来实现数据的导入
在adb中创建表数据表，此时即可通过INSERT INTO命令实现数据的导入导出
（4）外部表对应的参数
ENGINE=”oss“对应的引擎为oss对象存储
如果需要访问oss当中对应的文件需要知道“end point” “url’’”acessid””acesskey”以及在oss当中列分隔符”delimiter”
注意oss与analyticDB MySQL所属的区域相同，如都是华东，即在该地区创建产品，若是不在同一地区则无法实现该数据的导入导出。
ENGINE=”OSS”---存储引擎为odps
TABLE_PROPERTIES=’{
“endpoint" :"oss-cn-xxxxxx-internal.aliyuncs.com",
---OSS的EndPoint （域名节点）
“url”:”oss://bucket-name/xxx/”
---OSS中文件夹的地址，以/结尾。
“accessid”: "LTAIF*****5FsE・，
“AccessKey”：“Ccw****iWjv*“，
---访问OSS文件的Access key和 Secret
“delimiter”：“；”
---定义OSS中数据文件的列分隔符
2. 数据同步：RDS到Analytic DB MYsql 同步链路整体介绍
数据的导入导出为一次性的实时的，无法进行数据的改变，通过数据同步，阿里云的同步输入来搭建同步数据链路，来实现对数据源实时数据的传输。
DTS：数据传输服务，支持关系型数据库、NOSQL及大数据（qlap）等数据源之间的数据传输与交换。在阿里云的多款产品之间通过数据传输进行数据的导入导出实现同步链路的搭建。
通过DTS同步到多种数据源数据到analyticDB MySQL中，analyticDB MySQL为数仓产品，本身并不生产数据，数据均来源于外部数据源，通过多个数据源传输数据来实现交互式BI分析和数仓迁移
数据源支持ORACLE、POLARDB mysql、 POLARDB-X等等，这些数据源通过DTS来实现数据加载到ADB mysql当中，同时mysql为后面的商业大表、大屏，来提供数据的支撑。
同样DTS也可以实现数据的迁移，下面重点介绍RDS MYSQL 到analyticDB MySQL的同步流程，其他数据源同步流程类似。
7. 数据同步：整体介绍
同步由结构初始化，全量同步，增量同步三个步骤组成
很好理解，原始数据存在于RDS MySQL，数据存在自己的数据结构，需要在adb当中实现结构初始化，把表中数据结构在analyticDB MySQL建立结构，再进行全量同步，将RDS MySQL存量历史数据全量同步到在analyticDB MySQL，随着后续RDS MySQL为业务数据库面向生产日常业务，数据进行增删改查，通过增量同步保证RDS MySQL同步到analyticDB MySQL当中，这就是数据同步的三个过程。
（1）结构初始化：
是同步的第一个环节，即在analyticDB MySQL端创建于源MySQL对应表的结构。
①确认analyticDB MySQL和MySQL间表的结构关系。
②根据配置的表结构信息，DTS会自动的在analyticDB MySQL端创建表。例如下图中，指定了表和主键列和分布列，DTS会根据这些信息，加上其他列的信息，在AnalyticDB MySQL端建表。
分布列是AnalyticDB MySQL的表结构属性，AnalyticDB MySQL会根据该列把数据在多个节点上进行分布式储存。注意，源端必须存在主键列，否则无法正确同步数据。
（2）全量同步
在结构初始化后，DTS会进行全量同步，然后在此基础上，在基于binlog进行增量同步，全量同步的方法，基于主键划分区间，然后并行同步到analyticDB MySQL中，全量数据一般规模大，为了提高效率对原表进行划分，进行并行处理。
可以简单的理解为按主键范围把数据从MySQL中查询出来，并写入analyticDB MySQL，可以实现高效并行写，加快全量同步性能。
在此注意，为什么需要全量同步？
MySQL中存在大量历史数据，这些数据对应的binlog或许已经被删除，无法通过重放binlog来同步这部分数据。同时，并行、批量拉取数据并写入analyticDB MySQL，效率也比逐行解析binlog要高。
也就是说在全量同步阶段，DTS是通过将源表按照主键进行划分，然后将每一部分数据，单独、并行写入analyticDB MySQL当中。
（3）增量同步阶段
MySQL端的修改会产生binlog，dts通过捕获并解析mysql端的binlog日志，转换为insert/update/delete等语句，并在analyticDB MySQL端回放这些操作，实现mysql到analyticDB MySQL的增量同步
结构初始化和全量同步都是一次性的，增量同步则是持续的，只要mysql端有变化，DTS就会捕获并同步到analyticDB MySQL端。
日常业务流程通过DML/DDL进行修改rdsMySQL产生binlog日志，DTS在进行捕获、解析进行转换，在analyticDB MySQL中重新执行操作从而实现两个数据源的同步。
二、SQL优化和慢查询解决方案
analyticDB MySQL定义为针对于千万条数据的毫秒级查询引擎，是一个实时数仓产品，所以对于sql的优化及慢查询具有丰富的方案。
1. 慢查询诊断与优化：查询流程和执行计划
对于 MySQL而言 SQL语言是完成用户和系统内部存储数据之间的交互最基本的工具，在执行阶段，analyticDB MySQL执行结构切分为多个Stage来执行对，一个stage就是执行计划中某一部分的物理实体。一个查询可分为多个步骤，每一个步骤被称为stage。
如：map对原始数据作map运算过程中，后续可做reduce，一个map或一个reduce即可理解为一个stage
举例：分组聚合查询
分组聚合查询的处理流程，Controller节点会把查询的逻辑执行计划（plan）分片下发到执行计划任务的各个节点上。
对于analyticDB MySQL而言一个可分为多个stage，一个stage内部又由多个task组成，task由算子aggrerate具体执行，总体查询划分为三个阶段：先执行stage2再然后stage1之后的stage0
Stage2由4个task组成，分布在4个节点上并行地进行执行
在每一个test里包括三个基本的算子，首先是tablescan表示扫描，然后是filter表示过滤，aggregate表示区部地聚集。
Stage1与stage2存在数据呈分布与传输的过程称之为remote exchange远程数据交换，将stage2的结果传入stage1
传输方式有多种，在stage1中存在2个task ，remote exchange是将上一个stage的结果传入，并完成两个结果的聚合
Stage2由4个task组成，并执行数据的扫描，过滤以及局部聚合等操作
Stage1由2个task组成，并执行最终的聚合操作
Stage0由1个task组成，负责汇总
2. 算子
一个算子对应数据处理的基本逻辑，一个算子负责完成一个基本的数据处理逻辑，一组算子按照执行计划完成数据的一组处理规则。具体算子介绍如下：
Aggregation：通过sum（） count（） avg（）等函数对数据进行聚合或分组聚合操作。
Distinctlimit：对SQL语句中的DISTINCT LIMIT操作。
Filter：使用存储层数据的索引进行过滤，如果存储层没有索引，需要在计算层使用算子进行过滤。
Remote exchange ：用来表示上游向下游stage传输数据时所用的方法，包括：broadcast、repartition、gather。
Jion ：对应SQL语句中的jion操作。
Project：对应SQL语句中对待定字段的投影操作，如：case when then控制流，conccat（）函数等。
Stageoutput ：用于将当前stage处理后的数据通过网络传输到下游stage的节点。
Sort ：应SQL语句中对ORDER BY子句的操作，执行ORDER BY 字段的排序，
Tablescan ：用于从数据源读取数据，如果需要过滤数据，那麽数据由底层数据源使用索引高效完成。
Topn ：对应SQL语句中ORDER BY LIMIT,M,N查询。
3. 影响查询性能的因素
（1）集群规则
·不同集群规格的cpu核数、内存大小和数据存储介质等属性不同，处理子任务的能力也就不同，需要结合业务查询特征来选择集群规格。
·以Join或分组聚合为主的业务查询会消耗较多的CPU和内存资源。
·扫描数据和简单分组聚合操作的查询会消耗较多的磁盘I/O资源。
（2）节点数量
analyticDB MySQL版本使用了分布式数据处理架构，一条查询会被分解成多个Stage在不同的节点上并行执行。所以如果集群中的节点数量越多，analyticDB MySQL版处理查询的能力也会越强。您可以根据实际的业务需求来决定集群节点的购买数量，更多详情，可以参考创建集群。
（3）数据分布特征
·由于使用了分布式数据处理架构，具备将一条查询分解到多个节点上并行执行的能力。
·充分利用多节点来并行处理查询，还取决于数据在储存节点上的分布特征。
·如果数据能够均匀分布在储存节点上，多个子任务在处理数据时，就能几乎同时结束任务。
·数据分布不均匀，子任务在处理数据是会存在时间上的长尾，从而影响最终的查询效果。
（4）数据量大小
·在处理查询时，通常不会讲处理过程中的临时结果暂时写到磁盘里，而是尽量在内存中将所有数据处理掉。
·如果查询需要处理的数据量较大，就可能会长时间占用大量的资源，导致整理查询效率降低，进而影响最终的查询效果。
·表储存的数据量较大，在执行索引过滤、明细数据读取等操作时会出现争抢磁盘I/O资源，导致查询变慢。
（5）查询并发度
·能同时处理的查询数量也会存在上限。如果查询的并发度过高，集群节点资源已达到瓶颈，那么后台的查询会出现较长时间的排队，影响整体查询效果。
（6）查询复杂度
·查询的负责度不同造成的压力也不同。
·如果查询中过滤条件过于复杂，会在数据过滤时对储存节点造成一定压力；如果查询中Join算子过多，数据可能需要在不同节点间进行多次的网络传输，造成网络阻塞；如果查询中分组字段过多，也会占用较多的内存资源。
