※ 本記事は、Umair Siddiquiによる”Migrating Teradata and Netezza to Oracle Autonomous Database“を翻訳したものです。

2023年8月4日

このブログはKiran Tailorと共同執筆されています。

データ・ウェアハウス・アプライアンスの履歴と課題

データ・ウェアハウスは1980年代からずっと存在しています。データ・ウェアハウスは、複数のソースからデータを収集して格納できます。格納されているデータには、様々な分析ツールを使用してアクセスおよび分析し、意思決定に役立てることができます。データ・ウェアハウスには、サーバー、ストレージ、オペレーティング・システムおよびデータベースが必要です。統合されると、データ・ウェアハウス・アプライアンスと呼ばれます。これらのアプライアンスは2000年代初頭に市場に参入し、オンプレミス・データ・センターで設置および保守されています。TeradataとNetezzaは、こうしたシステムの代表的な例です。

現在、データ・ウェアハウス市場は爆発的な成長を遂げています。この成長は、企業が支出していることのみでなく、保存、分析、収益化されているデータ量にも影響します。データ・インサイトは、収益を高め、コストを削減するためにこれまで以上に重要になっています。データ・ウェアハウジング・ソリューションでは、物理アプライアンスの保守に重点を置くのではなく、開発者およびシステム管理者が結果に注力することを推奨します。しかし、多くの顧客は依然としてオンプレミス・データ・ウェアハウス・アプライアンスに依存しているため、次の課題があります。:

  • 運用時間: このようなシステムの運用化は、システムがオンプレミスに到着するずっと前から始まっています。システムには、オンプレミス・データ・センターの電力、冷却、スペース、冗長性、バックアップおよび安全性に関する広範なコンプライアンスが必要です。データ・センターの準備ができたら、次に、システムのインストール、オンおよび微調整の課題が生じます。この継続的なタスクには、OpexおよびCapexのコストに加えて、時間、コスト、専門知識が必要です。

  • ハードウェアおよびソフトウェアのリフレッシュ・サイクル、パッチ適用およびベンダー・ロックイン: 数年ごとに、顧客はサーバー、ストレージおよびその他のハードウェア・コンポーネントをアップグレードする必要があります。パッチが適用され、通常はメンテナンス期間、エキスパート、停止時間が必要です。ソフトウェアを更新する必要があるため、すべて直接費と間接費が発生します。また、顧客は元のベンダーにとどまる必要があります。

  • システム・スケーリング: これらのリジッド・システムのスケーリングには、パフォーマンス、ストレージ、またはその両方を含めることができます。また、合計データ・ストレージの観点からも上限がある場合があります。到達したら、顧客は新しいシステムを取得し、運用化の課題を再度解決する必要があります。次世代のアプリケーションおよびアプリケーションが幅広く使用されるようになったため、これらのアプライアンスが設計したデータの量が複数倍になるため、このデータ・ウェアハウス・モデルは課題に対応できません。

  • 新機能およびツールの互換性および統合: これらのシステムは特定のベンダーによって提供されるため、新しいツールの統合や新機能の取得は複雑で時間がかかるため、顧客は後れをとる可能性があります。

  • セキュリティ状態を維持: 新しいセキュリティ脅威、高度なハッカー、悪意のあるソフトウェアが急速に増加しています。このような脅威によって、データをオンプレミス・アプライアンスに安全かつセキュアに格納することは困難になります。言っているように、データは新しい金です。そこで、企業がどのように自社とその顧客データのターゲットになっているかを確認できます。

Oracle Cloud Infrastructure(OCI)とオラクルのデータ・ウェアハウジング・ソリューションであるOracle Autonomous Data Warehouseを見てみましょう。

パブリック・クラウドとその利点

パブリック・クラウドは、企業がこれらの課題に取り組む方法になりつつあります。インフラストラクチャを迅速にセットアップして運用できるだけでなく、個々のサービスと完全なエンドツーエンドのソリューションも、わずかな時間で導入できます。

Oracleは、2018年にAutonomous Data Warehouseを発表しました。Autonomous Data Warehouseは、数分以内にデプロイできます。また、バックアップやパッチ適用などの時間のかかる管理タスクを自動化し、ハードウェアの調達時間も不要です。これは、共有または専用インフラストラクチャにデプロイしたり、CPUとストレージの自動スケーリングを構成したり、パフォーマンスの監視やプライベート・エンドポイントを介したアクセスを行ったり、秒単位の課金で必要のない場合は停止または開始できます。これらの機能により、アプライアンスの導入よりもコスト管理と柔軟性が向上します。詳細は、Autonomous Databasesの概要を参照してください。

Oracle Cloud Guardは、強力なセキュリティ体制を監視、識別、達成、維持するための、すぐに使えるソリューションを提供します。この新しいサービスは、Oracleによって事前構成されたセキュリティのベスト・プラクティスを提供し、1回クリックするだけで有効化されます。プロビジョニング時に、個々のベスト・プラクティスのセキュリティ・ルールをカスタマイズできます。クラウド・ガードの詳細は、Cloud Guardのドキュメントを参照してください。

Teradataデータ・ウェアハウス・アプライアンスをOCIに移行する例を見てみましょう。他のタイプのデータ・ウェアハウスでも同様のアプローチを使用できますが、必要なオンプレミス・ツールは異なる場合があります。

OCIへのTeradataの移行

Teradataアプライアンスの移行には、次のコンポーネントが必要です。:

  • SQL Developer、SQL LoaderおよびOracle Data Sync (オンプレミス): これらのサービスは、オンプレミスに格納されているデータを抽出および変換し、OCI Object Storageに転送してAutonomous Data Warehouseにロードします。Oracle Data Integratorは、オンプレミスまたはOCIでマーケットプレイス・イメージを使用しても使用できます。進行中のデータ移行をサポートする場合は、このツールの使用を検討してください。

  • 仮想クラウド・ネットワーク(VCN)およびサービス・ゲートウェイ(OCI): サービス・ゲートウェイにより、オンプレミスから転送されたデータは、OCIのプライベート・バックボーンを使用して安全に行われます。

  • Object Storage (OCI): Object Storageは、転送されたデータを格納し、Autonomous Data Warehouseにロードします。

  • Autonomous Data Warehouse (OCI): オンプレミス・データ・ウェアハウスから転送されたデータをホストする新しいデータベース

A graphic depicting the architecture connecting an on-premises data center to the OCI tenancy.

Teradata移行戦略全体について、次の領域を考慮する必要があります。:

  • 表定義や索引などのデータベース・モデルの移行

  • データ移行

  • ダウンストリームおよびアップストリームに関する考慮事項のアプリケーション

データベース・モデルの移行

スキーマの移動は、すべての移行における主要なステップの1つです。SQL Developer (Teradataまたは他のデータ・ウェアハウス用のカスタム・ツール)は、これらのオブジェクトの一部に使用できます。SQL Developerでは、移行リポジトリを使用して、モデルを取得し、表および索引の構文を生成できます。SQL Developerでモデルが取得されると、Oracleに変更を適用する前にこのモデルを修正できます。

ストアド・プロシージャ、マクロおよびBTEQスクリプトがある場合があります。SQL Developerではこれらのオブジェクトを移動できません。Oracleと連携するには、手動で移行する必要があります。BTEQスクリプトの場合、Teradataネイティブ・ユーティリティを使用して、SQLのみをコピーして貼り付けることができます。

データ移行

データの移行には、次のオプションがあります。:

エクスポートおよびインポート(非増分データ):

  • FastExportを使用してTeradataからデータをエクスポートします。

  • ファイルを圧縮します。

  • ファイルをObject Storageに移動します。

  • DBMS_CLOUDパッケージを使用してデータをロードします。

増分データの場合は、次のステップで変更したレコードをエクスポートする必要があります。:

  • 増分データをObject Storageに移動します。

  • データをステージング表にロードします。

  • 変更データ取得(CDC)を実行するには、任意の方法を使用します。

ツール:

  • Teradataの場合、SQL Developerは、データベース・モデルの生成中に作成された移行リポジトリを使用してデータを移行できます。

  • Oracleのもう1つの無料ツールであるOracle Data Syncは、TeradataとAutonomous Databaseとの間で直接接続できます。このツールは、Oracle Autonomous Databaseに対してCDCを一括して実行できます。

アプリケーション・ダウンストリームおよびアップストリーム:

すべての移行では、すべてのダウンストリームおよびアップストリーム・アプリケーションを評価する必要があります。たとえば、Oracleと連動するようにETLアプリケーションを再構成する必要があります。このプロセスは、アプリケーション内で別のターゲットを選択するだけでよい場合があります。他のデータ・ウェアハウスの移行には、カスタム・ツールを使用して、SQL Developerによって実行されるタスクを実行できます。

データがAutonomous Data Warehouseインスタンスに転送された後、従来のツールを使用してアクセスおよび操作できるのみでなく、Oracle機械学習やデータ・カタログの作成などの組込みの分析ツールを利用できます。Oracle Analytics CloudやFusion Analytics Warehouseなどを使用して、分析サービスを有効にすることもできます。

まとめ

まとめると、オンプレミス・データ・ウェアハウス・デプロイメントをOracle Cloud Infrastructureに移行することで、柔軟性、スケーリング、コスト制御、データ収益化機能、操作のしやすさが実現します。このプロセスは、オンプレミス・デプロイメントで直面する主な課題のいくつかに対処します。詳細は、次のリファレンス・アーキテクチャを参照してください。: