明而决之

本文总结一个数据倾斜的问题，该问题由 SQL 函数对手机号分组时引发，做数仓开发的同学在在业务实战过程中，或许会遇到过。先简单介绍一下什么是数据倾斜和为什么会造成数据倾斜。数据倾斜是在分布式计算系统中经常遇到的一种现象，特别是在大数据处理和分析领域。它指的是数据在被分割并分配到多个计算节点上进行并行处理时，数据分布不均匀，导致某些节点处理的数据量远远大于其他节点的现象。在 MapReduce 中，数据倾斜也是比较常见的一个问题，稍不留意可能就会出现数据倾斜的问题。

本文介绍了怎么实现以引流的低价订单的为基本维度，按照业务 30天的间隔分别聚合低价订单退款、高价订单金额和高价订单退款金额。采用了两层表单的设计，一层事实表，一层根据业务不同的口径进行聚合。处理业务逻辑的时候，根据事实表的结构，采用分段聚合的逻辑先聚合【低价订单+高价订单】，然后再根据【低价订单】进行聚合，最终得到目标表。目标表开发好之后，在该表的基础上，根据各类业务指标进行聚合并可视化，最终提交给业务方使用。

本文主要介绍将神策数据入库的相关操作。目标：将神策数据入库到 MaxCompute 数仓。最终的解决方案的整个流程梳理下来其实就是：请求神策数据->Pandas 处理数据->转为 MaxCompute 数组并入库。

本文介绍了从 Dataworks 项目中获取所有表单字段的方法，基本步骤如下：查看官方文档，了解约束和接口；在线调试，并获取源码；配置本地环境，安装 alibabacloud_dataworks_public20200518；配置环境变量，新增两个环境变量ALIBABA_CLOUD_ACCESS_KEY_ID和 ALIBABA_CLOUD_ACCESS_KEY_SECRET，并将阿里云账号的 ACCESS_KEY_ID 和 ACCESS_KEY_SECRET 分别作为​对应变量的值；测试源码，打

解决 MaxCompute 不支持这个语法`DATE_FORMAT(string, string)`的方法本文提供了两种：方法1：开启 Hive 兼容模式方法2：显性修改传入`FROM_UNIXTIME(1672538400)`返回的数据类型另外，传递给`DATE_FORMAT()`的参数如果是 DATETIME 类型，会被隐性转换为 STRING 处理。

本次探索过程，发现了一个问题，阿里云产品，可能每一个都会有自己的控制台，有自己的一套权限管理，配置权限前，需要先思考，这个权限是在哪一个平台上使用，然后针对性去对应的文档和对应的控制台中寻找解决方案。就如本次，处理的内容其实是 MaxCompute 项目级别的问题，需要到项目中去寻找解决方案，一开始我配置了 RAM 用户相关权限，也在数据保护伞和 DataWorks 用户管理上面也尝试了解决方案，不过都是无用功，无法最终解决问题，只是更加清晰地了解了阿里云的权限管理逻辑。

本文分别通过 pgsql、ODPS SQL 和 MySQL 三种 SQL 语法进行 json 类型的处理。其中，使用 pgsql 处理方式最简单且简洁，而 ODPS SQL 最复杂，中间进行了多次数据类型的变更，甚至还需要使用一种更少见的数据类型 map 类型来辅助处理；而 MySQL 则处于二者之间。

在处理生产环境中的重复数据时，实际上就是要从表单中删除重复的数据，可以采用多种删除方式。比如：覆盖写入（`INSERT OVERWRITE`），该方式本质上是先清除数据，然后再进行插入操作，我们将新插入的数据进行去重即可。这个方式可以通过调度任务来实现，也可以通过查询窗口执行代码来实现。如果只是局部的几条数据出现问题，也可以手动进行处理，只需指定删除重复数据，然后再插入一次被删除的数据即可。

最终的方案更准确的说法是删表重建，以实现“修改字段数据类型”的目的，不过中间绕了些弯子。如果只是在开发环境中处理，还是会比较方便，对开发表进行删表重建（），使得数据表的数据类型和要插入的数据保持一致；或者修改插入数据的数据类型（cast），使得插入数据的数据类型和已创建数据表的数据一致；或直接修改数据表的数据类型（Alter），这个方案需要项目安全操作的权限。但是如果是发布到了生产环境，便会更加麻烦，除了以上可供选择的方法需要进行两次操作外，还涉及到表单的使用权限问题，所以一般建议非必要不删表！

1、开发环境和生产环境的表单的字段名要保持一致！这样才可以将开发环境的表提交到生产环境。如果要修改字段名，需要两端都进行修改，再提交。注意一个前提，必须要有开发环境和生产环境相关表单的alter权限。2、如果有外表也需要重建，修改的字段不会同步更改，会导致查询不到相关的数据。这个流程还是比较繁琐的，这还不涉及表单的调用，所以能不改尽量不改，前期的数仓表设计多花点功夫做好规范，这很重要！

生产环境添加列的方法：通过代码新增列、通过表管理新增、通过DMS新增列。

最近在做一些业务宽表的迁移，因为一个比较老的数仓示例已基本已弃用。该仓库为了快速响应数据需求，采用简单模式，没分开发环境和生产环境，使用的查询语言是MySQL。而迁移的目标仓库是标准模式（开发生产分环境跑），使用的ODPS SQL。在迁移的过程中，经常遇到的报错问题就是关于数据类型不一致，一段几百行的SQL，报错，调试，定位到问题，修改好，重跑，又报错……改了又改，最终跑通之后，粗算一下时间，足足得有三小时。这让我深刻感受到MySQL的灵活性和ODPS SQL的“不友好”。

在具体调整和部署整个工作流程时，我们务必了解源表的调度信息，充分理解源表的逻辑关系和运行机制，这样才能在最大程度上避免由于部分表单数据未被录入或丢失而导致的调度结果出现异常的现象，从而有力地保障数据信息的准确性、完整性和可靠性。

讲述标准模式和简单模式建表流程和maxcomputer同步到adb mysql的两类方法：数据集成同步和外部表同步……