前言
Teradata(TD)是美国前十大上市软件公司之一，经过逾30 年的发展，Teradata发展为全球领先的大数据分析和数据仓库解决方案厂商，赢得了超过2,000家客户的信任，在多个行业表现卓越，多年来一直居于领导者地位。随着Teradata近期宣布退出中国市场，越来越多的企业着眼于长期规划，将目光转移到国产数据库产品进行整体的技术架构升级，寻找高度契合国家战略、技术领先的国产化数据库产品。
AnalyticDB PostgreSQL（以下简称ADB PG）是阿里云自研的云原生数据仓库产品，提供基于阿里云生态的公共云和混合云服务，核心代码高度自主可控，提供PB级数据实时交互式分析，ETL/ELT，和BI报表展示功能，支持数据高吞吐实时写入与批量导入，提供ACID保证和标准事务隔离级别，采用MPP全并行架构。ADB PG已获得三方机构认证，包括：“分布式分析型数据库大规模性能认证”和 “分析型数据库Serverless分级能力”获增强级等能力认定。
申万宏源证券的数仓升级项目为阿里云第一个证券行业 “去Teradata数仓”项目，阿里云与申万宏源证券历时1年的紧密合作，最终成功实现ADB PG替换Teradata数据仓库。项目总计完成100多套上游业务源系统、约30套下游系统、25000多个任务、800多个服务接口、百TB数据、日新增500～700GB数据的平稳迁移，保障现有业务平稳有序运转同时，最终实现自主可控、数据快速赋能业务。
以下是我们从该项目中总结沉淀的关于“AnalyticDB PostgreSQL替换Teradata数仓”的最佳实践。
01数据仓库的发展趋势及困境
经过近30多年的发展，企业级数仓都有了不同程度的发展，积淀了大量的业务数据。同时随着多维度的业务发展转变，数仓应用将面临如下的发展趋势。
● 数据层面：数据规模不断突破，非结构化信息持续增长；
● 业务层面：离在线快速响应，实时交互成为常态；
●架构层面：数据库与大数据加速融合，云原生将成为必然；
●产品层面：目前产品面临硬件老化，升级维护成本过高，需要下一代产品进行升级。
02数仓架构升级挑战
▶︎ 技术方面
功能兼容性：众多的OLAP产品，不确定那款可以替代当前的数仓环境。
改造方案全面性：改造数仓环境，涉及的环节非常多，需要通盘考虑。
迁移实施复杂度：历史沉淀数据太过庞大，当前数仓老旧，涉及多个团队合作，整个迁移过程非常复杂。▶︎ 成本方面
评估改造成本：采用新型的分布式数据库技术，改造评估成本无法准确估算。
评估应用改造周期：30多年的数据沉淀，数据迁移速度、应用改造难度等无法有效评估改造周期▶︎ 运维方面
数据安全监管：数据监管会变得空前严格，多场景的运维需求也会日益突出。
开发人员技能：企业人员能力是否能够胜任，也决定着数仓改造的成败。
DB管理技能：分布式数仓环境的DB运维能力的提升，则是对当前运维人员的又一技能挑战。
云资源管理能力：分布式数仓需要日常的运维工作具备相关技能。
03数仓迁移规划
我们将Teradata迁移至ADB PG的数仓迁移方法总结归纳为“五阶十步”法，迁移项目为保证平滑过渡、风险可控等目标，总体会倾向平迁策略，即不改架构，不动流程，尽力兼容。“五阶十步”内容如下图示：
图1 - Teradata数仓迁移“五阶十步”
业务调研
业务调研阶段需对原系统上下游做详实调研，调研内容包括但不限于：
● 原数仓系统架构● 原数仓数据交互流程● 原系统资源盘点
● 原数仓库表统计
最后迭代输出调研分析报告，并与业务方做深入讨论与修正。
原数仓系统架构
图2 - 原数仓系统架构示意图
比较典型的证券企业数仓架构：上游数据依赖采集程序生成数据文件，通过Teradata的FSLoad加载入库；下游系统不直接访问Teradata数仓，通过前置环境来过渡；数仓内部分层建模，ETL任务通过Automation调度工具集成。这种架构主要好处是管控能力强，体现在安全可控、性能可控、并发可控。
原数仓数据交互流程
图3 - 原数仓数据交互流程图
原系统资源盘点
针对现有系统资源使用情况进行多维度盘点，确认初步迁移计划。
以数仓表统计为例，根据表的数据量和类型等关键指标，有针对性的制定下一步的迁移计划。
方案设计
该阶段需多方参与共创，设计并编制可落地的执行方案，提请业务方审议。内容包括但不限于：
图4 - 方案设计
以下就几项核心内容进行描述：
系统架构
如下图所示
图5 - 新系统架构示意图
图6 - ADB PG组件部署逻辑示意图
图7 - DBStack部署架构图
DBStack是阿里云企业级交易、分析、传输、治理于一体的数据库管理平台；能够帮助企业构建稳定、安全、经济的全场景数据库解决方案，快速替换Oracle、Db2、Teradata等传统数据库。
规划设计
迁移方案
组织保障
实施计划
项目里程碑计划如图：
图8 - 里程碑计划示意图
04Teradata系列产品替换
核心数仓替换：ADB PG适配
ADB PG与Teradata在数据类型、DDL/DML等语法、函数、特殊关键字等存在差异性，为此ADB PG系统性整理差异对照和语法兼容项。
以创建表为例，转换语法对照如下表：
举个例子，Teradata创建表DDL：
这个Teradata的DDL有三处特殊地方：-- 1）CHARACTER SET LATIN CASESPECIFIC-- 2）DATE FORMAT 'YYYYMMDD'-- 3）INTEGER FORMAT '99:99:99'CREATE TABLE ON_BOARD_MATCH_EVT( Evt_Id VARCHAR(200) CHARACTER SET LATIN CASESPECIFIC TITLE '编号' NOT NULL, Match_Dt DATE FORMAT 'YYYYMMDD' TITLE '成交日期' NOT NULL, Match_Tm INTEGER FORMAT '99:99:99' TITLE '成交时间' NOT NULL, Order_Dt TIMESTAMP(6) TITLE '委托日期' NOT NULL, Cust_Cd VARCHAR(80) CHARACTER SET LATIN CASESPECIFIC TITLE 'A代码' NOT NULL, Cust_No VARCHAR(80) CHARACTER SET LATIN CASESPECIFIC TITLE 'A编号' NOT NULL)PRIMARY INDEX ( Evt_Id )PARTITION BY ( RANGE_N(Match_Dt BETWEEN DATE '2000-01-01' AND DATE '2013-12-31' EACH INTERVAL '1' YEAR , DATE '2014-01-01' AND DATE '2015-12-31' EACH INTERVAL '1' MONTH , DATE '2016-01-01' AND DATE '2030-12-31' EACH INTERVAL '1' DAY , NO RANGE OR UNKNOWN) );
转换成ADB PG相关DDL（三处特殊地方无法兼容，需要评估对业务的影响）：
CREATE TABLE ON_BOARD_MATCH_EVT( Evt_Id VARCHAR(200) NOT NULL, Match_Dt DATE NOT NULL, Match_Tm INTEGER NOT NULL, Order_Dt TIMESTAMP(6) NOT NULL, Cust_Cd VARCHAR(80) NOT NULL, Cust_No VARCHAR(80) NOT NULL) DISTRIBUTED BY(Evt_Id)PARTITION BY RANGE(Match_Dt)( START(DATE '2000-01-01') END(DATE '2013-12-31') INCLUSIVE EVERY(INTERVAL '1' YEAR), START(DATE '2014-01-01') END(DATE '2015-12-31') INCLUSIVE EVERY(INTERVAL '1' MONTH), START(DATE '2016-01-01') END(DATE '2030-12-31') INCLUSIVE EVERY(INTERVAL '1' DAY), DEFAULT PARTITION def__par);COMMENT ON COLUMN ON_BOARD_MATCH_EVT.Evt_Id IS '编号';COMMENT ON COLUMN ON_BOARD_MATCH_EVT.Match_Dt IS '成交日期';COMMENT ON COLUMN ON_BOARD_MATCH_EVT.Match_Tm IS '成交时间';COMMENT ON COLUMN ON_BOARD_MATCH_EVT.Order_Dt IS '委托日期';COMMENT ON COLUMN ON_BOARD_MATCH_EVT.Cust_Cd IS 'A代码';COMMENT ON COLUMN ON_BOARD_MATCH_EVT.Cust_No IS 'A编号';
数据迁移工具：ADAM + DTSADAM
在Teradata 迁移中，通过ADAM(亚当)可以实现数据库自动采集、兼容性评估、自动结构迁移和智能订正，同时对应用Perl 脚本SQL 自动转换，大大降低Teradata 迁移的成本和难度，目前支持Teradata13-16 的版本。
ADAM核心功能● 采集TD 数据库的DDL、SQL、系统信息● TD => ADB For PG 兼容性分析● 自动对TD 进行结构迁移，并支持人工订正
● TD ETL Perl/DSQL 脚本里面SQL 自动转换
DTS
数据传输服务DTS（Data Transmission Service）支持将Teradata迁移至云原生数据仓库ADB PG版。
迁移类型支持● 库表结构迁移DTS将源库中迁移对象的结构定义迁移到目标库。● 全量迁移
DTS将源库中迁移对象的存量数据，全部迁移到目标库中。
数据库账号的权限要求：
统一开发与调度平台：DMS▶︎
背景介绍对于大型证券公司，其业务复杂度极高，据统计客户累计需要开发和调度的任务达到了2W+。阿里云DMS提供了强大的任务编排功能，能够完全对齐Automation相关功能。以下提供一个高效的迁移方案，可将生产调度系统从Automation迁移到DMS中。
▶︎ 任务迁移方案
方案目标：迁移工作量小，迁移后业务无损，提升运维效率。
1、确定业务场景
任务编排的业务场景，对齐automation的核心系统。以下几个业务场景为例：FLD_ODS_xxx、ITF_xxx、EXP_xxx
2、采集任务迁移
采集任务主要为脚本任务，根据上面的业务场景划分，将不同系统的采集任务放入不同的任务流，按照“一个表对于一个任务流”原则，迁移采集任务。
3、加载入库（FLD+ODS）的任务如何迁移
入库任务为脚本任务，需要把入库任务划分进不同的任务流
划分任务流● 一张表对应一个任务流：根任务是脚本任务，脚本任务的内容是对于数据的完备性检查，对于脚本任务配置失败重试。
● 一个任务流对应一张表：一个任务流只能有一个数据检查的脚本任务，从这个根任务起，添加所有依赖这个表的FLD与ODS任务，如下：
● 任务流不需要配置调度周期，调度由上游采集任务来通过openAPI触发。
4、对于采集加载之后的任务
这里包含了加载任务之后，所有的任务，如明细层、汇总层、集市层等等；任务流划分方式，还是按照“一张表由且仅由一个任务流产生”的基本原则，这里我们拿ITF/EXP层来举例。
划分任务流ITF / EXP示例
ITF与EXP类似，会交叉依赖上层的多个表，故这两个层的处理方式是类似的，所以放在一起说，但注意的是这两个层需要放到不同的业务场景里
调度方式
DMS任务支持基于时间调度和基于“事件”调度两种模式。
DMS任务编排完美适配Automation各项能力和用户开发调度需求，运行ETL调度任务，实时性高，业务拓展性好，异常恢复成本低。同时，通过跨任务流依赖检查以及事件调度等功能，也实现了复杂依赖关系的调度场景。
05
总结过去几十年，国外数据仓库平台厂商包括Teradata、Exadata、Netezza 等一直是金融、运营商等重点行业的优先选择。但是，近年来传统数仓掣肘明显，存在软硬绑定、难以升级与维护、成本高昂，以及架构老化，难以赋能业务创新；体系封闭，受制于人，难以突破等问题，企业急需架构升级。阿里云自研的新一代云原生数据仓库AnalyticDB PostgreSQL体系化解决以上难题，在关键行业的核心应用中成果显著。帮助金融、电信行业客户将传统数仓全面升级至云原生数仓，构建数据平台全新架构，有效满足客户对于数据平台实时化、弹性扩展、高性价比及安全可控的诉求，突破传统数仓技术瓶颈，最终赋能企业数智化创新。
