我們在之前的文章中介紹了如何從Oracle遷移到Greenplum。與Oracle遷移類似，作為在世界范圍內有廣泛用戶的數據倉庫產品，在綜合評估了多種因素后，Teradata的很多用戶選擇遷移到Greenplum。我們將從為什么遷移和如何遷移兩個層面來討論如何從Teradata遷移到Greenplum。

01

Teradata產品和用戶面臨的問題

Teradata公司成立于1979年，主要為客戶提供三種服務：基于云和硬件的數據倉庫、業務分析和咨詢服務。Teradata在1983年推出其首個數據庫產品，并為數據倉庫市場輸送了大量的人才，之后很長一段時間內一直處于數據分析領域市場領導者的地位。國內很多大型商業銀行的數據倉庫系統都是基于Teradata進行構建的。到2005年前后，隨著Intel x86 64位處理器的發布，基于x86架構的服務器在企業里開始承擔越來越多的計算工作，而Teradata一直固守其一體機架構，造成越來越多的企業難以承受其高昂的硬件成本和擴容維護費用。另一方面，用戶的數據越來越多，業務對數據倉庫的響應時間要求越來越短，而Teradata中存在讀寫互相阻塞的問題，無法滿足業務的需求。面對這一矛盾，很多公司都在考慮如何更好地建設數據倉庫以滿足當前及未來一段時間的業務增長需求，甚至有用戶想借此機會搭建新一代數據平臺，在提供Teradata原有功能的同時，可以整合不同業務單元的數據，實現更加多元的業務能力。在選擇新的數據平臺和Teradata的替代方案時，用戶往往非常慎重，通常會從多個維度對市面上眾多常見的商業和開源產品進行全方位的評估，包括功能、性能、高可用、可擴展性、開放性、數據加載速度、跨云跨平臺能力、與第三方工具的集成能力、監控管理特性和總體成本等。用戶期望尋找成本更低、更開放、功能和性能同樣強大的替代方案。大量用戶最終選擇了Greenplum，并認同Greenplum是替代Teradata的最佳產品。

02

從Teradata遷移到Greenplum的可行性

熟悉數據產品的讀者大多了解，Teradata和Greenplum都屬于MPP數據庫，這一架構上的相似性意味著從Teradata遷移到Greenplum是個非常自然的過程。熟悉Teradata的用戶可以快速掌握Greenplum。同時，兩者的語法非常接近、生態系統高度重合，這也極大地降低了遷移的難度和過程，使得Greenplum成為Teradata理想的替代產品。另外一方面，Greenplum相比Teradata更加開放，產品基于PostgreSQL完全開源，不需要專有硬件，大大降低了數據倉庫構建的軟硬件成本。

Teradata架構

上圖給出了Teradata的架構，可以看出，Teradata同樣采用無共享(Shared Nothing)大規模并行處理( MPP)架構。主要包括解析引擎(Parsing Engine，PE)、計算引擎 (Access Module Processor，AMP)、消息通信層 (Bynet)三個模塊。其中PE模塊相當于Greenplum的 master節點，負責處理用戶連接、SQL的解析、分發和最終查詢結果的輸出；AMP模塊 相當于Greenplum 的segment節點，負責具體數據的計算工作；Bynet模塊相當于Greenplum的interconnect部分，負責整個網絡的通信和數據在不同節點的傳輸。此外，VDisk相當于Greenplum segment節點的本地存儲。可見，Teradata在架構上和Greenplum基本一致，主要區別是在其對應的硬件部分，如Bynet是專門的硬件網絡設備，VDisk部分對應的底層存儲一般是通過共享存儲劃分邏輯單元號(LUN)的方式實現。

因為Greenplum和Teradata在架構上相似，且都支持ANSI SQL標準，因此兩個產品中大量語句的語法都一致或者高度相似，即使有不一樣的語法或者概念，也能在另一個產品中找到對應的語法或者概念。例如，對于create table命令，兩者的語法基本一樣；如果創建表時劃分分區，兩者都使用partition by。但對于數據分布的控制，Teradata使用primary index, 而Greenplum使用distributed by。對于大多數Teradata特有的概念和語法，遷移到Greenplum時可以忽略，極個別的情形下需要加以改寫。

Greenplum和Teradata在工具鏈和生態系統上也存在著許多相似性。如下表所示，Teradata中常用的庫和工具在Greenplum都有對應的使用方式和工具。所有常見的BI工具都同時內置支持Teradata和Greenplum。所以，使用商業智能(BI)工具的用戶在遷移后依然可以使用自己熟悉的工具。

類型	Teradata	Greenplum	遷移說明
ODBC/JDBC	支持	支持	_
BI前端展現 工具	支持所有BI前端工具	支持所有BI前端工具	通過ODBC或JDBC標準訪問DW，改動量很小或沒有；
LOAD工具	fastload/ multiload/ tpump等	外部表導入、COPY等工具	采用工具對ETL腳本使用到的部分 批量自動修改
UNLOAD工具	fastexport等	外部表導出、COPY等工具	采用工具對ETL腳本使用到的部分 批量自動修改
命令執行 客戶端	BTEQ	PSQL	采用工具對ETL腳本使用到的部分 批量自動修改
SQL－ DML語法	支持ANSI SQL	支持ANSI SQL	Greenplum和Teradata的語法基本相同。Teradata有少量特殊語法或函數(如事務BT/ET、OLAP的csum，rank、qualify等、函數如char)，Greenplum都有相對應的甚至更強大的函數，只是需要修改SQL中的語法。工作量不大
SQL－ 語法DDL	使用PRIMARY INDEX、PPI等	使用Distribution分布數據，使用partition做表分區	DDL語法基本相同。需要將Teradata的PRIMARY INDEX改成Distribution key，PPI改成表分區
備份與恢復	采用NETVULT＋archive工具	CRONTAB調度器＋ gpbackup/ gprestore	實現數據庫的自動備份
系統監控等管理工具	Teradata MANAGE	Greenplum Command Center	_

Teradata與Greenplum的數據庫特征比較

雖然異構數據庫遷移的工作量不小，但由于有上述大量相同點，從Teradata遷移到Greenplum往往是一個可以接受的工作。許多用戶也在實踐中發現這項工作比想象中容易。在國外，著名的投資銀行摩根斯丹利成功將其部分Teradata集群遷移到Greenplum，并逐步擴大Greenplum的集群數量和使用場景。到2018年，摩根斯坦利在600多臺機器上運行著24個生產集群，管理著多達25PB的原始數據。在國內，某大型商業銀行在2013年就啟動了部分Teradata集群向Greenplum的遷移，遷移完成后批量作業的處理時間減少了6個小時，報表查詢響應時間減少為原來的?。

03

如何從Teradata遷移到Greenplum

由于Grennplum和Teradata基于同樣的MPP架構，所以在Teradata上的物理模型設計原則同樣適用于Greenplum，遷移工作主要是對應語法的翻譯。

01

遷移流程概述

Teradata遷移至Greenplum的總體流程如下圖所示，主要分為歷史數據遷移、日常加工流程遷移、應用接口遷移及管理工具遷移幾個階段。

遷移總體流程圖

1. 歷史數據遷移該階段包括如下步驟：

在Teradata數據庫中，按規定分隔符及字符編碼將歷史數據導成文本文件，存放于Greenplum數據庫網絡相通的ETL服務器本地磁盤或所連NAS上，確保Greenplum數據庫通過gpfidst協議的外部表能讀取數據文件。

從Teradata導出DDL腳本，按照Greenplum語法批量修改腳本，確保在Greenplum中能成功創建所有用戶表。

2. 日常加工流程遷移

該階段將ETL查詢加工語句按Greenplum的DML語法進行轉換，并根據Teradata與Greenplum函數對照表替換相關函數，轉換ETL連接數據庫方式。重新配置加工作業，歷史數據遷移成功后，啟動日常ETL作業。

3. 應用接口遷移在該階段，由于Greenplum數據庫支持ODBC/JDBC，商業智能前端展現等工具可通過ODBC或JDBC標準訪問數據倉庫，改動網絡連接IP等即可。4. 管理工具部署

該階段包括以下步驟：

部署Greenplum備份及恢復工具，定期備份數據及定期進行恢復演練。

部署相關管理工具，如Greenplum Command Center。

在上述各個階段中，涉及到的主要遷移任務如下表所示。接下來我們將分別介紹各階段的主要工作。

遷移任務	任務簡述
數據卸載	從Teradata卸載抽取歷史數據
DDL導出	從Teradata導出表DDL腳本
DDL腳本轉換遷移	按Greenplum語法對Teradata版DDL(包括表，索引，視圖)腳本進行轉換
數據加載	選擇Greenplum數據加載方式，如外部表或者copy工具，準備加載腳本，進而進行數據加載
ETL工具腳本轉換遷移	建立Greenplum到ETL服務器的網絡連接，對數據加工模塊腳本按Greenplum語法進行局部修改，查詢語句轉換及存儲過程轉換等
查詢語句轉換遷移	按Greenplum語法規則及特性修改轉換及優化查詢語句
存儲過程轉換遷移	按Greenplum語法規則及特性修改轉換及優化Teradata及用戶自定義函數，存儲過程等
資源負載管理遷移	根據Teradata資源負載管理確定Greenplum用戶及資源組或者資源隊列
安全及權限管理遷移	遷移用戶及組等角色的訪問權限及數據庫對象權限
BI工具接口遷移	建立Greenplum到BI前端應用連接

主要遷移任務

接下來，我們將詳細介紹主要的遷移工作。

02

Teradata數據卸載及DDL導出規范

首先，我們需要了解Teradata的數據卸載及DDL導出規范。

(1)數據卸載規范

• 在卸數前，需要按遷移前協商好的字符編碼從Teradata中卸出數據，推薦使用UTF8或者GBK，在確定字符編碼規則后，通知準備加載腳本的相關人員。

• 在數據卸載前，需要按遷移前協商好的分隔符從Teradata中卸出數據，推薦使用單分隔符(如“|”等)，如果有特殊規定需要雙分隔符(如“|@|”)，Greenplum也允許使用。在確定分隔符規則后，通知準備加載腳本的相關人員。

(2)DDL導出規范

• 在Teradata中通過show schemaname.tablename來導出用戶表DDL語句，將定義語句傳至約定的ETL中轉服務器等，需確保該中轉服務器與Greenplum數據庫網絡相通，以便修改后的DDL能傳輸至Greenplum數據庫服務器進行用戶表的創建。

• 數據定義語句(DDL)轉換。

下面詳細介紹如何進行 DDL 轉換。

1. Create table

將Teradata表定義轉換為Greenplum表定義，有以下考慮要點：???? 在Teradata數據庫中大小寫不敏感，而Greenplum數據庫則大小寫敏感。例如，如下代碼說明了Greenplum數據庫對大小寫是敏感的。pivotal=# create table t1(id int,name varchar(32)) distributed by (id);CREATE TABLEpivotal=# insert into t1 values (1,'ABC');INSERT 0 1pivotal=# select * from t1 where name='ABC'; id | name----+------ 1 | ABC(1?row)pivotal=# select * from t1 where name='abc'; id | name----+------(0?rows)

Teradata默認大小寫不敏感，若要區分大小寫，則應在查詢語句中指定CASESPECIFIC關鍵字，強制不忽略大小寫。

BTEQ -- Enter your SQL request or BTEQ command:create table test.t1 (id int,name varchar(32)) primary index ( id ); *** Table has been created. *** Total elapsed time was 1 second. BTEQ -- Enter your SQL request or BTEQ command:insert into test.t1 values(1,'ABC'); *** Insert completed. One row added. *** Total elapsed time was 1 second. BTEQ -- Enter your SQL request or BTEQ command:select * from test.t1 where name='ABC'; *** Query completed. One row found. 2 columns returned. *** Total elapsed time was 1 second. id name----------- -------------------------------- 1 ABC BTEQ -- Enter your SQL request or BTEQ command:select * from test.t1 where name='abc'; *** Query completed. One row found. 2 columns returned. *** Total elapsed time was 1 second. id name----------- -------------------------------- 1 ABC BTEQ -- Enter your SQL request or BTEQ command:select * from test.t1 where name='abc' (CASESPECIFIC) ; *** Query completed. No rows found.?***?Total?elapsed?time?was?1?second.

???? 數據類型及約束條件。

???? 在Greenplum數據庫，主鍵(PK)可以考慮作為分布鍵。

???? 非標準化的Teradata SQL命令，即Teradata特有的SQL命令。

在DDL轉換中，應根據上述考慮要點進行轉換。下表根據Teradata與Greenplum建表(CREATE TABLE)語句的語法詳細說明如何轉換。

Teradata		Greenplum
CREATE TABLE ;		CREATE TABLE ;? ????;
定義	說明	定義	說明
SET/MULTISET	定義記錄是否可重復	無	無，轉換時直接刪除
Create Table Options? 表選項	定義表的物理屬性? Fallback? Journaling? Freespace?	無	無，轉換時直接刪除
Column Definitions字段定義	定義表的各個字段，可以通過format函數定義數據格式	Column Definitions (字段定義)	根據數據類型對照表替換，Greenplum不支持通過to_char/to_date函數定義數據格式，Greenplum默認日期格式為YYYY-MM-DD，即如果字段默認格式為YYYY-MM-DD，那么轉換時直接刪除即可
Table-level Constraints? 表級約束	定義約束? Primary key? Unique? CHECK條件 Foreign key	Table-level Constraints (表級約束)	Greenplum支持定義主鍵，但是不推薦；不支持CHECK條件及創建外鍵
Index Definitions索引定義	定義表索引	Index Definitions (索引定義)	Greenplum支持，但是和Teradata類似，需要根據業務要求再次評估是否創建索引
PI Definitions索引定義	主索引	DK Definitions (分布鍵定義)	根據Teradata主索引直接修改為分布鍵即可
partition Definitions分區	表分區	partition Definitions (分區)	Teradata與Greenplum分區表語法不同，根據Greenplum的語法轉換

建表語句詳細對比

2. 數據類型轉換對照

Teradata與Greenplum中數據類型的轉換對照如下表所示。

Teradata字符類型	Greenplum字符類型
Char(n)	character (n),?char(n)
Varchar(n)	character varying(n),?varchar(n)
Long Varchar	text
SmallInt	smallint,?int2
Integer	integer,?int,?int4
Dec(m,n)	real,?float4
Float	float8,?float
Date	date
Time	time
Timestamp	time with time zone

3. 物理模型轉換規則

針對上述轉換規則，對于每一個CREATE TABLE 語句，執行如下轉換邏輯：(1)全局替換規則s/(CREATE[\s]+MULTISET[\s]+TABLE[\s]+[\w]+\.[\w]+).*$/$1/imgs/ MULTISET / /g;s/,NO FALLBACK ,//g;s/NO BEFORE JOURNAL,//g;s/NO AFTER JOURNAL,//g;s/FREESPACE = 30, //g;s/DATABLOCKSIZE = 10000 BYTES,//g;s/CHECKSUM = DEFAULT//g;s/CHARACTER SET LATIN NOT CASESPECIFIC/ /g;s/FORMAT 'YYYY-MM-DD'/ /g;s/PRIMARY INDEX /DISTRIBUTED BY /g;s/( COMPRESS \([\d\D]+?\))/ /g;s/( COMPRESS '[\d\D]+?')/ /g;s/( COMPRESS [\d\.]+ )//g;s/TITLE _UNICODE '[\d\w]+'XC//g;s/NO RANGE OR UNKNOWN//g;s/?CASESPECIFIC/?/g;

(2)獲取TITLE 語句信息，轉換生成COMMENTON 語句

COMMENT語法如下：

COMMENT ON TABLE schemaname.tablename.columnname IS ‘column specification’;

其中：

• schemaname：模式名

• tablename：表名

• columnname：字段名

• column specification：字段描述

(3)轉換PARTITION BY 語句語法

Greenplum PARTITION BY語法如下：

PARTITION BY partition_type (column) ?(?partition_spec?)?

(4)轉換CREATE INDEX索引語句

下圖給出了一個例子。

4.根據已存在表的結構創建空表

在Teradata中，使用CREATE TABLE AS語法，可以基于已經存在的表創建新表。如果只創建表定義，不復制數據，則使用WITH NO DATA選項。而在Greenplum中，該功能是通過LIKE關鍵字實現的，轉換模式如下

CREATE TABLE schemaname.new_tablename AS schemaname.old_tablename WITH [NO] DATA

轉換為：

CREATE?TABLE?schemaname.new_tablename?(LIKE?schemaname.old_tablename)

注意：該轉換需要手動搜索腳本進行手工轉換。

5. Drop table

Teradata與Greenplum刪除表的語法一致，但是如果聲明在刪除表前先判斷表是否存在時，那么Teradata與Greenplum語法有區別，轉換過程如下圖所示。

注意：該轉換需要手動搜索腳本進行轉換。

6.臨時表轉換

臨時表作為一種輔助工具，能夠提高SQL操作的性能。特別是針對下列情況的 SQL操作，臨時表能發揮非常重要的作用：???? 不能使用規范化的表。???? 要求多條 SQL 語句完成。???? 臨時表對于頻繁產生的中間結果或作為后續工作基礎的中間結果也非常有用。

因此，在各類數據庫中，都支持創建臨時表功能，Teradata支持全局臨時表(Global Temporay Table)、可變臨時表(Volatile Temporay Table)兩種類型，而Greenplum只支持可變臨時表(temp/TEMPORARY)。語法轉換規則如下：

???? 直接將VOLATILE替換為temp/TEMPORARY，或者將GLOBAL TEMPORARY替換為temp/TEMPORARY。

???? 在Greenplum中不支持維護交易日志LOG或者不維護交易日志NO LOG關鍵字，直接刪除即可。在Greenplum 6.0中支持unlogged table，用戶可以根據業務場景靈活進行選擇。

???? 控制事務提交后是否保留記錄，可使用ON COMMIT PRESERVE ROWS/ON COMMIT DELETE ROWS，這在Greenplum中同樣適用。

???? 其他的DDL定義修改可參考永久物理表轉換規則。

???? 如果臨時表無delete及update操作，那么建議進行壓縮，壓縮語句在分布鍵前進行聲明，語法如下：

CREATE TEMP TABLE schemaname.temp_tablename(like?schemaname.tablename|select?……?from?schemaname.tablename)WITH?(APPENDONLY=TRUE,ORIENTATION=ROW,COMPRESSTYPE=ZLIB,COMPRESSLEVEL=5)DISTRIBUTED?BY?RANDOMLY;

注意：臨時表在ETL腳本自動轉換工具中可進行80%的自動轉換，再針對無法自動轉換的語句進行手動轉換。

下圖給出了一個臨時表轉換的示例。

臨時表轉換示例下篇我們將接著向大家介紹如何從Teradata遷移到Greenplum。

(未完待續)

---

Greenplum近期社區活動

6月13日 14：00-15：00

聽個推資深大數據研發專家 栗子 為你講述《個推如何采用Greenplum提高PB級別數據處理能力》

6月19日 16：00-17：00

聽Greenplum原廠研發郭峰講解《Greenplum內核揭秘之查詢優化》

我知道你

在看

哦

總結

以上是生活随笔為你收集整理的greenplum客户端工具_如何从Teradata迁移到Greenplum（上篇）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。