TeradataからSnowflakeにデータ移行の検証を行ったので記事にします。
オンプレのDWHというイメージが強いTeradata製品からクラウドネイティブのDWHとして有名なSnowflakeにデータ移行したが、データマイグレーションを行う上で色々な課題が発生したので課題と回避方法を説明します。
1.データの移行方法
既存システムおよび新システムともにAWSを利用しており、異なるAWSアカウントを利用している。
セキュリティの制約として現新をデータベース間を接続することはできない。
TeradataのQueryGridを利用したsnowflakeに対するシームレスで高性能なデータアクセスはできないため、ファイル出力することにした。
・ファイル出力はTeradata Parallel Transporter(以降、TPT)のexport機能を利用
[ダウンロードサイト]: https://downloads.teradata.com/
・SnowflakeのデータロードはSnowSQLのCopy intoを利用する
[ダウンロードサイト]: https://www.snowflake.com/en/developers/downloads/snowsql/
問題点1:
対象テーブルのレコードが非常に多いことからファイル出力すると非常にディスク容量が大きくなることでローカルディスクの容量を圧迫すること、また新システムにファイルの移送するのに時間がかかる。
対策1：
既存システム、新システムともにAWSであることからTeradataのデータエクスポート先をS3することでディスク容量の問題が解決できる。
またS3のクロスアカウント接続し、新システム側のSnowflakeの外部ステージ用のS3バケットに直接ファイル出力することでファイル移送が不要となる。
※S3に書き込む場合はTPTだけではなく、S3Accessmoduleをインストールが必要。
[ダウンロードサイト]: https://downloads.teradata.com/
データ移行の構成
2.テーブル定義の準備
移行先であるSnowflakeのテーブル定義を準備する。
※Teradataのテーブル定義と同じ構成にする。
問題点2:
TeradataのデータタイプとSnowflakeのデータタイプは異なっているため、Teradataのテーブル定義を使ってもSnowflakeのテーブルを作成することができない。
対策2:
TeradataのデータタイプとSnowflakeのデータタイプの対応表がSnowflake社のサイトにあるため、参考とした。
[ダウンロードサイト - Teradata to Snowflake Migration Open Manual]:
https://www.snowflake.com/thank-you-teradata-to-snowflake-migration-kit/
3.SQLクエリについて
| # | データ型 | 説明 |
|---|---|---|
| 1 | Char型 | 不要な空白が出力されるため、Oreplace,castなどを記述 |
| 2 | Varchar型 | 値の前に不要な空白が出力されるため、coalesceなどを記述 |
| 3 | Date型 / Timestamp型 | ファイル出力時はTO_CHARを利用し、文字列型として出力。snowflakeのDate型に合わせてフォーマットはYYYY-MM-DDとする |
| 4 | Clob型 | サイズは1Gに対してSnowflakeでは（VARIANT型）16Mのサイズ制限がある |
| 5 | BLOB型 | サイズは1Gに対してSnowflakeでは（VARIANT型）16Mのサイズ制限がある |
問題点3
Clob型、Blob型のデータをSnowflakeではどのように扱うのか
対策3:
| # | 対策 |
|---|---|
| 1 | CLOB型,BLOB型のデータをdatファイルなどに出力し、S3に保存しつつ、格納先のパスを文字列型に格納する |
| 2 | 16Mに収まるようにデータを分割する |
上記の２つの対策を検討する前にCLOB型、BLOB型の登録されているデータについて確認した方がよい。
１点目、登録されているデータは文字を扱っているのか
２点目、最大バイトがVARCHARの最大サイズである32,000文字以内であるか。もし、両方を満たしているようであればVARCHAR型に変換しファイル出力すればよい
※過去担当したシステムでは10,000文字も満たないデータしか登録されていなかった。
4.ファイル出力
TPTコマンドは接続情報、抽出クエリ分、保存先の設定などの記述する必要があるが、Teradataサイトを確認すると様々な記述ができる仕様となっている。汎用性を意識した設計になっているのかはわからないが、汎用的であるが故にどのように記述するべきかわからず、かなり混乱した。
※Teradata製品はよくあることだが、非常に柔軟性が高く色々な機能を実装しているが、柔軟であるがゆえに「どうすればよいいの」という結果になりやすいのでTeradata初心者には少し難しいという点がある。
問題点4
データ移行対象のテーブルは非常にレコード数が多いため、
ファイルサイズが大きくなり、テキストエディタで開くことはできない
対策4:
TPTのパラメータを確認すると1ファイルのサイズ制限を設定することが可能であり、抽出した結果がファイルサイズ制限に到達すると異なるファイルの分割出力が可能であるため、テキストエディタを開くことができる600Mとした。
また、ファイルを圧縮することができるため、gz圧縮も行った。
gz圧縮するためには出力時のパラメータ(ファイル名を指定するS3Object)の値をXXXX.gzという拡張子をgzにすることで圧縮されます。
※少し変わった仕様
Teradataのパラメータ
実行コマンド：
tbuild -f job_table.txt -v テーブル名.txt -j job_table -e UTF-8
[-f job_table.txt]
ファイル出力用のパラメータを設定するファイル
| # | パラメータ | 説明 |
|---|---|---|
| 1 | OpenQuoteMark | 値の最初に付与する記号 |
| 2 | CloseQuoteMark | 値の最後に付与する記号 |
| 3 | AccessModuleName | オブジェクトストレージ書き込み用のモジュール名 |
| 4 | S3ConfigDir | IAMクレデンシャルを利用したため、クレデンシャルファイルの格納先を指定する |
| 5 | S3Bucket | 保存先のS3バケット名 |
| 6 | S3Prefix | 保存先のS3バケット配下にあるプレフィックス名 |
| 7 | S3Object | 出力ファイル名(gz圧縮する場合に拡張子を.gzとする) |
| 8 | S3MaxObjectSize | ファイルの最大サイズ（本サイズ以上のデータを書き込む場合は複数ファイルとして出力される） |
| 9 | S3DontSplitRows | 必ずTrueするべき S3MaxObjectSizeの判断をレコード行にするか、バイトサイズにするかを決定する |
QuoteMarkには”（ダブルクォーテーション）を採用した。
理由は文字列カラムの値に改行コードが含まれている場合にQuoteMarkがないと終端を判断できないため
[-v テーブル名.txt]
Teradata接続アカウントやクエリを記載するファイル
| # | パラメータ | 説明 |
|---|---|---|
| 1 | ExportTdpid | Teradataへの接続文字列 |
| 2 | ExportUsername | Teradataのユーザ名 |
| 3 | ExportUserPassword | Teradataユーザ名のパスワード |
| 4 | FileWriterTextDelimiter | 値の区切り文字 |
| 5 | ExportSelectStmt | Teradataから抽出するためのSQLクエリ |
デリミタには｜（パイプライン）を採用した。
理由は文字列の値に,（カンマ）が含まれている場合にデリミタと区別ができないため、あまり利用されない記号を採用した。
[ -j job_table ]
job_table.txtファイル上に記載されているジョブ名
DEFINE JOB job_table
snowflakeへのデータロード
今後記載予定