在维护客户基于MaxCompute搭建的数据仓库时，我们遇到过一些问题，踩过一些坑，同时积累了一些经验，也初步形成了一套操作流程规范，在这里与大家以Tip的形式与大家分享一下。
Tip1.避免同步视图
同步的源数据要避免使用视图，在客户的生产环境上曾经出现过这样的情况：由于生成视图的存储过程优化不好，同步视图在同步任务发起请求后很久没有生成出来，导致同步任务及后续的ETL挂起达数小时之久，所以后续和数据提供方接洽，将数据源从视图换为表，保证在同步之前同步表里的内容已经更新。
在测试环境下，通过修改数据集成中的同步任务实现数据源从视图切换成表。再确认不同的数据源的表数据结构完全一致之后，修改如下同步脚本中的table值为新的表名。
由于在同步脚本里truncate字段为true，所以再次同步数据时该分区内的旧数据会被擦除，在修改之后可以直接通过补数据节点得到新数据源里的数据，同时该节点之后的节点也需要重跑，确保所有任务数据的正确性、一致性。
核对数据也是保证修改前后数据正确性、一致性的办法之一。核对主要是与数据提供方核对数据。这里以验证销量数据为例，双方核对的标准如下
|
客户编码Code |
客户姓名Name |
年月 BILL_DATE |
数据行数 |
销售数量PROD_QUANTITY |
销售金额 PROD_AMOUNT |
|
|
|
|
|
||
如果连续一周与数据提供方的数据一致，那么可以认为数据源修改成功
Tip2.Maxcompute数据同步到AnalyticDB
AnalyticDB常常作为MaxCompute与QuickBI之前的数据加速层，那么MaxCompute到AnalyticDB的数据同步就是必须的。按照通常的数据集成操作来配置，我们可以建立一个数据同步任务，但是当我们尝试运行这个同步任务时就会发现任务运行失败。
起初在授权策略、网络方面查错，但是依旧没有解决问题。最终了解到MaxCompute到AnalyticDB的数据同步必须进行下面的操作：
由于使用的公有云，要将 garuda_build@aliyun.com
和 garuda_data@aliyun.com两个公用云账号添加到MaxCompute的工程中：
ADD USER ALIYUN$garuda_build@aliyun.com;
ADD USER ALIYUN$ garuda_data@aliyun.com在添加账号之后需要将Describe,Select权限赋给这两个账号：
GRANT Describe,Select ON TABLE rpt_outlet_report_daily_april TO USER ALIYUN$garuda_build@aliyun.com;
GRANT Describe,Select ON TABLE rpt_outlet_report_daily_april TO USER ALIYUN$garuda_data@aliyun.com;之后再运行这个同步任务，发现同步成功！
Tip3.数据删除
数据提供方对上个月的历史数据进行了修改，删除了部分不符合业务逻辑的数据，为保证数据一致性，我们也需要将这部分历史数据删除。由于数据同步是增量的，每天只同步变更日期大于{bdp.system.bizdate}的数据，并用这部分数据替换掉全量数据里的旧数据。数据更新的示例代码如下，其中dwd_dummy_data为全量基础表，存放全量数据；ods_dummy_data为增量同步表，存放今天的增量数据，ds为分区列
由于数据提供方已经没有不符合业务逻辑的数据，那么每日的同步数据一定是符合业务逻辑的，所以并不用做数据删除。那么需要删除的数据就在全量数据中，即示例中的dwd_dummy_data表中。从示例代码可以看出数据更新只使用到分区为两天前的全量数据，所以更新所有分区的的全量数据是没有必要的，但是同时也说明了数据删除操作必须在数据更新任务触发时间前完成，否则完成删除操作的数据全量数据并不会用于新一轮的数据更新。
在明确了这些注意点之后，我们在测试环境中对要进行操作的分区的数据进行备份，方便回滚。由于MaxCompute没有update操作，我们通过insert overwrite来实现数据的删除，下面以删除dwd_dummy_data表中col3小于1000的数据为例，实现的逻辑如下
注意在where中限定分区列ds，否则将会插入所有分区中符合条件的数据，产生重复数据。
同样的，数据删除之后也需要和数据提供方核对数据。一旦数据差异较大时，且问题无法短时定位时要及时回滚数据，即将备份的数据重新插入到操作的分区，同时保留操作时的脚本，用于和数据提供方核查数据删除逻辑。当确定没有修改ETL脚本时，重跑对应业务日期的任务也可以实现数据回滚。
在确定删除逻辑正确，数据可以核对上之后，就可以对生产环境上的数据进行操作。操作时需要通知客户操作的开始时间、预计的操作时长、操作的表、操作的逻辑，如果可能造成影响比较大，也要将可能的影响告知客户。在客户邮件同意之后方可进行操作。同样的，在测试环境操作时的一切准则在生产环境同样要遵守，在连续数据核对一周之后，如果数据没有差异那么操作完成，相关的操作、操作日期、操作人员需要记录下来。
Tip4.ETL脚本修改
ETL脚本修改的准则与数据删除进本类似，但要记得将修改前的脚本备份。另外，对脚本尽量小的改动。举例来说，比如要A字段的值由其他字段依据某些逻辑生成，后面改动时需要将A字段为特定值的数据过滤掉，我们可以选择在生成逻辑里面进行修改，但是这样可能对原来的逻辑产生影响，于是可以在不显著影响执行效率的情况下，考虑再加一层select查询，同时用where限定条件过滤掉数据。
修改完成之后，在脚本的头部注释上添加Modify信息，例如下图：
文章来源-五叶草
---阿里大数据博文，问答，社群，实践，有朋自远方来，不亦说乎……