附白皮书下载 | 国产化数仓升级最佳实践：从Teradata迁移至AnalyticDB

阿里云数据库 2023-03-02

1584

欢迎点击文末「阅读原文」

下载《数据仓库升级交付标准化白皮书》

前言

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数仓”的最佳实践。

数据仓库的发展趋势及困境

经过近30多年的发展，企业级数仓都有了不同程度的发展，积淀了大量的业务数据。同时随着多维度的业务发展转变，数仓应用将面临如下的发展趋势。

● 数据层面：数据规模不断突破，非结构化信息持续增长；

● 业务层面：离在线快速响应，实时交互成为常态；

● 架构层面：数据库与大数据加速融合，云原生将成为必然；

● 产品层面：目前产品面临硬件老化，升级维护成本过高，需要下一代产品进行升级。

数仓架构升级挑战

▶︎ 技术方面

功能兼容性：众多的OLAP产品，不确定那款可以替代当前的数仓环境。

改造方案全面性：改造数仓环境，涉及的环节非常多，需要通盘考虑。

迁移实施复杂度：历史沉淀数据太过庞大，当前数仓老旧，涉及多个团队合作，整个迁移过程非常复杂。

▶︎ 成本方面

评估改造成本：采用新型的分布式数据库技术，改造评估成本无法准确估算。

评估应用改造周期：30多年的数据沉淀，数据迁移速度、应用改造难度等无法有效评估改造周期

▶︎ 运维方面

数据安全监管：数据监管会变得空前严格，多场景的运维需求也会日益突出。

开发人员技能：企业人员能力是否能够胜任，也决定着数仓改造的成败。

DB管理技能：分布式数仓环境的DB运维能力的提升，则是对当前运维人员的又一技能挑战。

云资源管理能力：分布式数仓需要日常的运维工作具备相关技能。

数仓迁移规划

我们将Teradata迁移至ADB PG的数仓迁移方法总结归纳为“五阶十步”法，迁移项目为保证平滑过渡、风险可控等目标，总体会倾向平迁策略，即不改架构，不动流程，尽力兼容。“五阶十步”内容如下图示：

图1 - Teradata数仓迁移“五阶十步”

业务调研

业务调研阶段需对原系统上下游做详实调研，调研内容包括但不限于：

● 原数仓系统架构

● 原数仓数据交互流程

● 原系统资源盘点

● 原数仓库表统计

最后迭代输出调研分析报告，并与业务方做深入讨论与修正。

原数仓系统架构

图2 - 原数仓系统架构示意图

比较典型的证券企业数仓架构：上游数据依赖采集程序生成数据文件，通过Teradata的FSLoad加载入库；下游系统不直接访问Teradata数仓，通过前置环境来过渡；数仓内部分层建模，ETL任务通过Automation调度工具集成。这种架构主要好处是管控能力强，体现在安全可控、性能可控、并发可控。

原数仓数据交互流程

图3 - 原数仓数据交互流程图

原系统资源盘点

针对现有系统资源使用情况进行多维度盘点，确认初步迁移计划。

以数仓表统计为例，根据表的数据量和类型等关键指标，有针对性的制定下一步的迁移计划。

方案设计

该阶段需多方参与共创，设计并编制可落地的执行方案，提请业务方审议。内容包括但不限于：

图4 - 方案设计

以下就几项核心内容进行描述：

系统架构

如下图所示

图5 - 新系统架构示意图

图6 - ADB PG组件部署逻辑示意图

图7 - DBStack部署架构图

DBStack是阿里云企业级交易、分析、传输、治理于一体的数据库管理平台；能够帮助企业构建稳定、安全、经济的全场景数据库解决方案，快速替换Oracle、Db2、Teradata等传统数据库。

规划设计

迁移方案

组织保障

实施计划

项目里程碑计划如图：

图8 - 里程碑计划示意图

Teradata系列产品替换

核心数仓替换：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 + DTS

ADAM

在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调度任务，实时性高，业务拓展性好，异常恢复成本低。同时，通过跨任务流依赖检查以及事件调度等功能，也实现了复杂依赖关系的调度场景。

总结

过去几十年，国外数据仓库平台厂商包括Teradata、Exadata、Netezza 等一直是金融、运营商等重点行业的优先选择。但是，近年来传统数仓掣肘明显，存在软硬绑定、难以升级与维护、成本高昂，以及架构老化，难以赋能业务创新；体系封闭，受制于人，难以突破等问题，企业急需架构升级。

阿里云自研的新一代云原生数据仓库AnalyticDB PostgreSQL体系化解决以上难题，在关键行业的核心应用中成果显著。帮助金融、电信行业客户将传统数仓全面升级至云原生数仓，构建数据平台全新架构，有效满足客户对于数据平台实时化、弹性扩展、高性价比及安全可控的诉求，突破传统数仓技术瓶颈，最终赋能企业数智化创新。