Comments
Transcript
NEC ブレードシステムSIGMABLADE-MとiStorage D8環境でのOracle
NEC ブレードシステム SIGMABLADE-M と iStorage D8 環境での Oracle Database 11g を 用いた E-LT アーキテクチャの有効性 1 目次 1. はじめに ............................................................................................................................................3 2. E-LTアーキテクチャの有効性........................................................................................................4 2.1 ETL処理とDWHクエリの高速化が求められる背景 ..............................................................4 2.2 E-LTアーキテクチャによる解決策 ..........................................................................................4 3. ストレージとサーバーのハードウェア........................................................................................9 3.1 iStorage D8 ....................................................................................................................................9 3.2 NECブレードシステム SIGMABLADE-M ............................................................................10 3.3 WebSAM iStorage Manager........................................................................................................10 3.4 Storage Path Savior .....................................................................................................................10 4. 検証環境 ..........................................................................................................................................11 4.1 システム全体構成 ....................................................................................................................11 4.2 システム仕様 ............................................................................................................................14 5. 検証モデル ......................................................................................................................................15 5.1 検証モデルの概要 ....................................................................................................................15 5.2 スキーマ構成 ............................................................................................................................15 5.3 検証で使用したETL処理とDWHクエリの処理内容 ...........................................................17 6. ハードウェアリソース増強によるETL処理の性能向上..........................................................23 6.1 アンバランスなリソース増強 ................................................................................................23 6.2 バランスを保ったリソース増強 ............................................................................................26 6.3 容量を基準にしたディスクドライブ数での性能 ................................................................29 7. データベース統合によるETL処理とDWHクエリの性能向上................................................33 7.1 ETL処理と同様のリソース追加によるDWHクエリの性能向上 ........................................33 7.2 データベース統合によるデータ移動時間の短縮 ................................................................37 7.3 E-LTアーキテクチャのメリット ............................................................................................39 8. まとめ ..............................................................................................................................................41 9. 付録 ..................................................................................................................................................42 2 1. はじめに 2006 年 7 月、日本電気株式会社（以降、NEC）は、次世代 IT 基盤を実現するため、IT プラットフォーム製品の開発指針およびロードマップを策定し、IT プラットフォームビジ ョン「REAL IT PLATFORM」を発表しました。この「REAL IT PLATFORM」では、NEC の仮想化技術、高信頼技術、統合化技術とシンプルな運用技術を利用し、「柔軟」「安心」 「快適」なシステムをお客様に提供することを目指しています。 一方、日本オラクル株式会社（以降、日本オラクル）は、Oracle Database 10g を発表した 数年前よりグリッドコンピューティングを実現する「Oracle GRID」技術を提供しています。 さらに、2006 年 11 月にはグリッドをベースとした次世代のビジネス・ソリューション構築 を目的として各協賛ベンダーとの共同の検証施設「Oracle GRID Center」を設立しました。 NEC と日本オラクルは 20 年に渡る協業関係を基盤とし、次世代 IT インフラ基盤の実現 に向けた開発レベルでの戦略協業（STA：Strategic Technology Alliance）を推進しており、 NEC は「REAL IT PLATFORM」の具現化を強化するために「Oracle GRID Center」に参画 しました。 このたび、NEC ブレードシステム SIGMABLADE-M とストレージ iStorage D8 環境で Oracle Database 11g を使用した E-LT アーキテクチャの有効性を示す検証を実施しました。 本文書ではその検証結果を報告します。 2. E-LT アーキテクチャの有効性 2.1 ETL 処理と DWH クエリの高速化が求められる背景 近年、企業を取り巻く環境は非常に早いスピードで移り変わっており、その変 化への対応は厳しさを増しています。この状況下、企業の意志決定者は迅速かつ 適切な判断をするためにタイムリーで正確な情報を必要としています。このニー ズに答えるのがデータ・ウェアハウス(以降、DWH)です。通常、DWH ではそれぞ れの業務システムのデータをそのまま蓄積するのではなく、スター・スキーマな どの分析しやすいデータモデルに変換して格納します。この一連の処理を ETL (Extract/Transform/Load) 処理と呼びます。意思決定の高度化に伴い、DWH が扱う べきデータ量も増えています。そのため ETL に必要な時間も増加傾向にあります。 高度な意思決定を迅速に行うためには DWH クエリのレスポンスの速さだけでは なく、ETL 処理にも大量データを高速に処理することが求められます。 2.2 E-LT アーキテクチャによる解決策 Oracle Database は単なるデータの入れ物ではなく、それ自体が強力なデータ加 工エンジンです。そのため Oracle Database では、ETL 処理の加工エンジンとして データベースを使用する E-LT アーキテクチャが実装可能です。 本検証では NEC ブレードシステム SIGMABLADE-M（以降、SIGMABLADE） と iStorage D8 環境での Oracle Database 11g を用いた E-LT アーキテクチャの有効性 を示します。 データベースを加工エンジンとして使用しないETL処理ではDWHに格納するデ ータをETL処理サーバーで加工します。この場合のETL処理の流れを図 2-1に示し ます。基幹システムからETL処理サーバーにフラットファイルを抜き出し （Extract：赤線）、JavaやCOBOLで書かれたETL処理プログラムやソートツールな どでDWHのデータに変換(Transform：図 2-1青線)します。ETL処理の中にはDWH のデータを更新することがあります。この場合、DWHのデータのアンロードを行 いTransformに使用します（図 2-1青い点線部分）。最後にTransformが完了したデー タをDWHへロード（Load：図 2-1緑線）します。 4 図 2-1 DWH とは別の ETL 処理サーバーを使用する ETL 処理フロー E-LTアーキテクチャではDWHのデータへの変換をETL処理サーバーではなく、 格納先のDWHのデータベースエンジンで行います。そのため、ETL処理サーバー がありません（図 2-2）。 E-LTアーキテクチャでの処理は次のように実施されます。まず、基幹システム からデータを抽出（Extract）します。そのデータのロード先はDWHであるため Extractの直後がロード（Load）になります。そして、DWHのデータベースエンジ ンで変換（Transform）を行います。変換後のデータはすでにDWHに格納されてい るため、図 2-1のLoadでのシステム間の移動は必要ありません。DWHのデータは 大規模になることが通常であるため、システム間のデータ移動が減少することも ETL処理時間の短縮になります。 図 2-2 E-LT アーキテクチャの ETL フロー 5 E-LTアーキテクチャではデータベースを処理エンジンとするため、ETL処理フ ローはSQLで記述されます。Oracleでは、GUIによってETL処理フローを設計する ことでOracle Databaseに最適化されたSQLとPL/SQLを生成するETLツールを提供 しています。ETLツールとしてはOracle Warehouse BuilderとOracle Data Integratorが あります。設計の際にはETL処理を念頭においた設計でE-LTアーキテクチャのコ ードを作成できます（図 2-3）。本検証ではOracle Warehouse Builderを使用しまし た。 図 2-3 ETL ツールによる ETL 処理設計 E-LT アーキテクチャでは ETL の Transform をデータベースで行います。そのた め、ETL 処理の時間を短縮させるにはデータベースエンジンの処理速度をあげる ことが効果的です。Oracle Database では SQL の実行を自動並列化する機能があり ます。これを利用すれば、CPU リソースの増強により並列度をあげることができ るため ETL 処理を高速化できます。 6 また、ETL 処理は大規模データを扱うので、CPU 性能のみならずそれにデータ を供給するストレージにも高い性能が求められます。並列度を増加させるために CPU リソースばかりを増強しても、ストレージのデータ供給性能がボトルネック になるため ETL 処理性能が向上しなくなります。ETL 処理の性能向上には CPU 性能とストレージ性能のバランスを保ったリソース追加が必要です。 本検証では、Oracle Database の機能を使用した CPU リソースおよびストレージ リソースの増強を実施します。 CPU性能の増強はOracle Real Application Clusters（以降、RAC）のサーバーノー ド追加で実施します。RACのサーバーノード追加ではSIGMABLADEを使用してい ます。この方法はシステムのサーバー台数を増やすことでCPU増加を図るスケー ルアウトに該当します。Oracle Databaseでは大量のデータを扱うSQL処理を複数プ ロセスで並列処理することができます。並列処理する複数のプロセスをパラレ ル・スレーブ・プロセスと呼び、これらのプロセスを制御するプロセスをクエリ ー・コーディネーター・プロセス（以降、QC）と呼びます。RACでは、QCがす べてのノードのスレーブ・プロセスを制御します。新しく追加されたノード上の スレーブ・プロセスについてもQCによって制御されるのでノードを追加するごと にパラレル度を増加させることができます（図 2-4）。 図 2-4 Oracle Database の自動並列化のメカニズム ストレージ性能の増強は Automatic Storage Management（以降、ASM）のリバラ ンス機能で実施します。ストレージリソースの追加には iStorage D8 を使用してい ます。iStorage D8 ではディスクアレイコントローラーとディスクエンクロージャ ーをセットで追加できる特長があります。ディスクエンクロージャーのみを追加 した場合、ディスクアレイコントローラーの最大帯域に達してしまうとそれ以上 の I/O 性能は得られません。iStorageD8 ではディスクアレイコントローラーもディ スクエンクロージャーと同時に増強できるためこの問題を解決できます。一方、 7 ASM のリバランス機能には追加されたディスクドライブを含めてストライピン グし、既存データを再配置する機能があります。 iStorageD8 によるリソース追加を実施したあとASMのリバランスを使用するこ とで、データ供給性能の向上ができます（図 2-5）。 図 2-5 iStorage D8 と ASM のリバランスを用いたストレージ性能の向上 本文書では E-LT アーキテクチャのメリットを以下の２つの検証で確認します。 6 章の「ハードウェアリソース増強によるETL処理の性能向上」ではETL処理の 性能向上にはCPU性能とストレージ性能のバランスを保ったリソース追加が必要 なことを確認しています。 7 章の「データベース統合によるETL処理とDWHクエリの性能向上」では、E-LT アーキテクチャにおいてETL処理エンジンとしてDWH環境を選ぶメリットについ て確認しています。 8 3. ストレージとサーバーのハードウェア 3.1 iStorage D8 iStorage D8 は SAN (Storage Area Network)対応のストレージ製品であり、「スケ ーラビリティ」、「マネージャビリティ」、「アベイラビリティ」の特長を持ってい ます。 1. スケーラビリティ ノードと呼ばれるストレージ装置の単位を最小 1 ノードから最大 4 ノードま で拡張することができます。これにより、容量拡大だけでなく、従来頭打ち となっていたストレージ性能を、リニアに向上させることが可能です。 2. マネージャビリティ ストレージ内の物理リソースをプール化し、プールから業務のタイプに応じ て必要なリソースを割り当てた仮想ストレージを構成する機能を持っていま す。仮想ストレージへのリソース追加や変更は、サーバーやアプリケーショ ンへの影響なく動的に実施できます。また、仮想ストレージ単位に管理者を 設定でき、管理権限のない仮想ストレージへのアクセスを制限し、誤操作や 不正アクセスを防止して、業務の機密性を確保できます。 3. アベイラビリティ ハイアベイラビリティシステムに要求される可用性向上に向けて、SPOF （Single Point of Failure）を徹底排除しています。多重化、モジュール構造化 により、万一の障害発生によるシステム停止の極小化を実現しています。 また、HDD の二重障害でも業務の継続を可能とする RAID-6（Redundant Array of Independent Disks）に加えて、RAID-1 の性能、RAID-6 の冗長性を共に兼ね 備えた RAID-TM（Triple Mirror）を備えています。これら複雑な RAID 演算 処理を行う際に、専用 LSI「高速 RAID エンジン」によって高速な処理を実現 しています。 9 3.2 NEC ブレードシステム SIGMABLADE-M NEC ブレードシステム「SIGMABLADE」は、エンタープライズから中堅市場 向けまで様々な IT 環境の一元化に幅広く対応した「真のサーバー統合」を実現し ます。 1. 基幹システム統合化に対応 サーバー、ネットワークから SAN ストレージまで幅広い IT 環境統合を実 現可能であり、大規模な基幹システムの統合にも対応可能です。 2. 一つ上の効率管理を支える先進テクノロジー 自律運用を実現する統合プラットフォーム管理基盤 「SigmaSystemCenter」、 最新のサーバーマネジメント「EXPRESSSCOPER エンジン」、 「SIGMABLADE モニター」などの優れた運用管理機能により柔軟な統合 化を実現する技術の採用。 3. 利用環境に配慮した工夫 データセンタやサーバールームだけでなく、快適なオフィス内設置も可能 な 100V 電源対応や静音技術、用途に応じて選べる多彩なスイッチなど、 様々な利用環境に配慮した機能性を備えています。 4. 投資の保護 高速バックプレーン採用による長期利用ニーズへ対応し、今後の各種ブレ ードエンハンスへ対応が可能です。従来のブレード 「Express5800/BladeServer」の資産も継承しています。 3.3 WebSAM iStorage Manager WebSAM iStorageManager は、iStorage ディスクアレイ装置のストレージリソー スを効率的に一元管理し、構成や運転状況を運用管理者が簡単に把握するために 必要な、構成表示、状態監視、障害通知などの機能を提供します。 3.4 Storage Path Savior Storage Path Savior（SPS）は、サーバー装置から iStorage ディスクアレイ装置へ のアクセスパスを複数使用して、I/O トラフィックを各アクセスパスに分散する機 能や、アクセスパス上に問題が発生した場合に、自動的なアクセスパスの代替を する機能を提供します。 10 4. 検証環境 4.1 システム全体構成 本検証で使用したシステム全体の構成を図 4-1に示します。 図 4-1 システム全体構成 RAC ではクラスタ・データベースのメンバーであるサーバーを指すときにノード という言葉を用います。また、iStorage D8 においてもエンクロージャーとコントロ ーラーの 1 セットをノードと呼びます。本文書では両者の呼び方を区別するため、 RAC についてはサーバーノード、iStorage D8 についてはストレージノードという言 葉を用います。 11 システム間の接続の様子を図 4-2に示します。 Host Director（HD）は iStorage D8 の着脱可能な接続モジュールです。このモジュ ール数を調整することでコントローラーの最大 I/O 帯域を調整することことができ ます。サーバーとストレージの間は 4Gbps Fibre Channel で接続しています。 図 4-2 システム間の接続の様子 12 ディスク構成およびディスク用途の関係は以下の通りです。 表 4-1 ディスクの用途 データファイル用の ASM ディスクグループは１つのみで、各ストレージノード に ASM ディスクが 11LU(44 ディスクドライブ)割り当てられています。ストレー ジノード 2 のディスクは ASM ディスクグループに追加用のディスクであり、追加 後にはディスクドライブ数が 2 倍の 22LU(88 ディスクドライブ)となるように設計 しています。ASM ディスクグループは、ASM によるミラーリングを行わない外 部冗長性で設定しています。 13 4.2 システム仕様 ・サーバー ブレードシステム SIGMABLADE-M CPU ブレード Express5800 120Bb-6 × 8 CPU デュアルコア インテル(R)Xeon(R)プロセッサー 5160 3GHz 2 ソケット(4 コア)/CPU ブレード メモリ 8GB/CPU ブレード ・ストレージ モデル名 iStorage D8 ホストインタフェース Fibre Channel 4Gbps× 4 /ストレージノード キャッシュメモリ 2GB/ストレージノード ディスクドライブ ストレージノード 1： SAS 73GB(15,000rpm) × 16 + SAS 147GB(15,000rpm) × 44 ストレージノード 2： SAS 147GB(15,000rpm) × 44 ・ソフトウェア OS データベース・ソフトウェア 運用管理ソフトウェア Red Hat Enterprise Linux AS release 4 (Nahant Update 5) Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 WebSAM SigmaSystemCenter 1.1 WebSAM iStorage manager 5.3.005 14 5. 検証モデル 5.1 検証モデルの概要 E-LTアーキテクチャに基づいた構成を想定しETL処理の変換処理(Transform) をOracle Databaseで実施しました。図 5-1がモデルの全体図となります。基幹シ ステムである売上管理システムのデータを使用して、ETL処理によりDWHの２ つのファクト表（顧客ファクト表、売上ファクト表）を作成します。 図 5-1 検証で使用したシステム 5.2 スキーマ構成 売上管理システムのデータを格納する表と DWH のデータを格納する表を示し ます。実際に運用している表をイメージできるように検証では使用しなかった表 についても示しています。 z 売上管理システムのデータを格納するスキーマ 次の表は、基幹システムのデータの Oracle Database へのロード先です。本検 証で使用した SALES 表と CUSTOMER 表は青枠で囲み、レコード件数と表サイ ズを示しています。 15 図 5-2売上分析システムのデータを格納する表 z DWH のスキーマ ・顧客分析用のファクト表とディメンション表 顧客分析用のファクト表である CUST_FACT 表を中心に、各種ディメンシ ョン表が設計されています。検証で使用した CUST_FACT 表と AREA_DIM 表 は青枠で囲み、レコード件数と表サイズを示しています。 図 5-3 顧客分析用のファクト表とディメンション表 16 ・売上分析用のファクト表とディメンション表 売上分析用のファクト表である SALES_FACT 表を中心に各種ディメンショ ン表が設計されています。検証で使用した SALES_FACT 表、AREA_DIM 表 および PRODUCTS_DIM 表は青枠で囲み、レコード件数とサイズを示してい ます。 図 5-4 売上分析用のファクト表とディメンション表 5.3 検証で使用した ETL 処理と DWH クエリの処理内容 本検証では、ETL 処理と DWH クエリをそれぞれ 2 種類用意しました。性質の 異なる処理を 2 種類実施することで測定結果の違いを確認します。 ETL 処理としては顧客ファクト表作成のための ETL 処理と売上ファクト表作成 のための ETL 処理を実行しました。DWH クエリとしては製品毎の売上金額合計 TOP10 を求めるクエリと平均売上数量上位地域 TOP5 を求めるクエリを実行しま した。次では、各処理内容について記します。 z DWH クエリ 製品毎の売上金額合計 TOP10 を検索するクエリ SALES_FACT 表と PRODUCTS_DIM 表を全表読み込み、結合します。次に、 売上金額から製品ごとに売上金額合計を求める集計演算を行いソートして上 位 10 件を取り出します。 17 図 5-5 売上金額合計 TOP10 を検索するクエリ 平均売上数量上位地域 TOP5 を検索するクエリ SALES_FACT 表と AREA_DIM 表を読み込み結合します。次に、地域毎に 売上数量から平均売上数量を求める集計演算をおこないソートして上位 5 件 を取り出します。 図 5-6 平均売上数量上位地域 TOP5 を検索するクエリ z ETL 処理 顧客ファクト作成の ETL 処理と売上ファクト作成の ETL 処理はどちらも、 sales 表と customer 表を全件結合した結果をもとにファクト表を作成します。 これら 2 つの ETL 処理の違いは集計処理の有無です。顧客ファクト作成の ETL 処理は集計処理が入るため結果表は小さくなりますが、集計演算処理の時間 が必要になります。これに対し、売上ファクト作成の ETL 処理は集計処理が 入りませんが、結果表は大きくなるという特徴があります。これら 2 つの ETL 処理フローは、OWB によってどちらも 1 つの INSERT … SELECT の SQL 文 として生成されました。 18 顧客ファクト作成の ETL 処理 SALES 表と CUSTOMER 表の全表読み込みを行い結合します。その後、注 文コードをキーとした集計処理（GROUP BY と COUNT 関数）を実施するこ とで顧客ごとの累計購入回数を求めます。そのほかには顧客の生年月日を年 齢コードに変換するようなコード化処理を実施します。この処理が完了する と結果を CUST_FACT 表へロードします。CUST_FACT 表は顧客一人一人のデ ータを分析するため CUSTOMER 表と同じ件数のレコード数を持っています。 図 5-7 顧客ファクト作成の ETL 処理 売上ファクト作成の ETL 処理 SALES 表と CUSTOMER 表の全表読み込みを行い、結合します。その後、 生年月日から年齢コードを求めるようなコード化処理を実施します。 図 5-8 売上ファクト作成の ETL 処理 19 本検証で使用するETL処理コードはOWBによって 1 つのSQL文として自動生成 されましたが、SQL文中では複数のJOINやGROUP BYなどさまざまな処理要素が 含まれています（図 5-9）。 図 5-9 顧客ファクト作成の ETL 処理の SQL 文（抜粋） Oracle DatabaseはSQLを実行するとき、さまざまな行オペレーションの組み合わ せで処理します。JOINやGROUP BYは行オペレーションのひとつとして処理され ます。行オペレーションはOracle Databaseのオプティマイザによって組み合わされ、 最適と判断されたものが実行計画として採用されます。図 5-10に顧客ファクト作 成のETL処理での実行計画と行オペレーションが処理された時間帯を示しました （この情報の取得方法については「9. 付録」参照）。 20 図 5-10 ETL 処理の SQL で実行される行オペレーションの処理の実行開始時刻と継続時間（構成 4） 21 行オペレーションはそれぞれ異なるリソース消費傾向を持っています。例えば、 HASH JOINはCPUリソースの消費が多く、TABLE ACCESS FULLはストレージリ ソースの消費が多いといった具合です。さらに、各行オペレーションは実行開始 時刻と継続時間が異なるため、ETL処理実行中のリソース消費は時間軸に沿って 一様にはなりません（図 5-11）。 図 5-11 ETL 処理実行中のリソース消費 このようにリソース消費が一様にならないときには、OS 統計の取得間隔に注意 が必要です。OS 統計の取得間隔は ETL 処理全体の時間に比較して充分に短い時 間でないとリソース使用のピークが分析できません。 図 5-12に、ストレージリソースの消費速度を 3 秒平均で表した場合と 3 分平均で 表した場合とで比較した図を示します。この図で示したETL処理は約 500 秒程度 で完了しています。この処理時間に対して 3 秒平均は充分リソース使用のピーク が分析可能な時間分解能です。一方、3 分平均ではリソース使用のピークとそうで ないところが平均化されてしまい、本当のピーク時間帯が分析できなくなってい ます。 図 5-12 3 秒平均と 3 分平均での相対読み込み速度比較 22 6. ハードウェアリソース増強による ETL 処理の性能向上 ETL 処理は１つの処理が大量データを扱うため、CPU 性能のみならずその CPU にデータ を供給するストレージ性能も重要です。RAC はノード追加が簡単にできるので、CPU リソ ースを容易に追加することができます。しかし、ETL 処理性能向上のために CPU リソース のみを追加していくと、ストレージは CPU のデータ処理性能に見合った性能でデータを供 給できなくなっていきます。本検証では、CPU のデータ処理性能の向上にはサーバーノー ド追加を行い、ストレージのデータ供給性能の向上にはストレージノード追加を行います。 この検証を通して、ボトルネックであるハードウェアリソースを特定しそのハードウェ アリソースを増強することで、ETL 処理の性能が向上することを確認します。 6.1 アンバランスなリソース増強 本節では ETL 処理を高速化するために、RAC のノード追加によりデータ処理速 度を向上させます。 一般に処理速度を向上させるには処理を実行するプロセスの並列度を上げること が有効です。しかし、少ない CPU 数で並列度をあげると CPU のリソースが不足し てしまいます。そのため、CPU リソースの追加をしつつ並列度をあげることが処理 速度の向上には必要です。RAC のサーバーノード追加では CPU リソースを追加する ことが容易にでき、さらに並列度を自動で増加させることができます。そこで、ETL 処理速度の向上のために RAC のサーバーノード追加により CPU リソースの追加を 行います。 本検証では、集計演算処理を含む顧客ファクト作成のETL処理を使用して、RAC のサーバーノード追加によるETL処理時間の短縮を試みます（図 6-1）。本検証の最 小構成であるRACのサーバーノード 2 台とストレージノード 1 台の性能を基本にし て、サーバーノードを追加したときの性能を測定します。このときETL処理のパラ レル度はサーバーノード 1 台につき 8 パラレルで実行しています。 図 6-1 ETL 処理の性能向上のためのサーバーノード追加 23 サーバーノードを追加することによるETL処理実行時間の変化を図 6-2に示しま す。構成 1 から構成 2 へサーバーノードを 2 台追加したとき処理時間は約 17%しか 短縮されず、さらに構成 2 から構成 3 へサーバーノードを 4 台追加したときは約 2％ 程度しか短縮されませんでした。顧客ファクト作成のETL処理をストレージノード 1 台（ディスクドライブ 44 台）のこれらの構成で行った場合、サーバーノードの追加 （CPUリソースの追加）の効果が小さいという結果になりました。 図 6-2 サーバーノード追加による ETL 処理実行時間の変化 では、なぜサーバーノードを追加したにも関わらずETL処理時間があまり短縮さ れなかったのでしょうか。それを確認するためにETL処理実行中のハードウェアリ ソース消費傾向を確認します。図 6-3はiostat とmpstatのデータをもとにして作成さ れた相対読み込み速度の時間推移グラフ、及びCPU使用率の時間推移グラフです。 相対読み込み速度は、構成 1 での読み込み速度の最大値を 1.0 としています。この ETL処理では、ストレージノード 1 台の相対読み込み速度の上限は 1.1 であることが 事前にわかっています。CPU使用率については、CPUコア数×100%が上限です。そ れぞれの構成でのリソースの上限はグラフ上に赤線で示しています。 24 図 6-3 構成 1 から 3 における相対読み込み量及び CPU 使用率の推移 サーバーノード 2 台（構成 1）のときを確認すると、ETL 処理の前半部分に相対 読み込み速度が 1.0 付近を維持している時間帯があり、すでに上限値 1.1 に近い値で す。次に、サーバーノードを追加して 4 台（構成 2）にすると、先ほど上限値に近か った部分が上限値 1.1 で頭打ちになっていることが確認できます。ここからさらにサ ーバーノードを追加して 8 台（構成 3）にしても、すでにストレージノード 1 台での データ供給能力の上限に達しているため、ETL 処理時間の短縮効果は非常に小さく なります。 本 ETL 処理をストレージノード 1 台で実行したとき、構成 1 ですでにストレージ 性能の上限に近い値に達していました。そのため、サーバーノードを追加しても性 能向上が小さいものに留まりました。 次節ではボトルネックとなっているストレージリソースの増強を行います。 25 6.2 バランスを保ったリソース増強 「6.1アンバランスなリソース増強」では構成 2（サーバーノード 4 台、ストレー ジノード 1 台）の段階でストレージのボトルネックにより性能向上が停滞しました。 そこで、今度はデータ処理能力と供給能力のバランスを保つことを目的として、構 成 2 にストレージノードの追加を実施します (図 6-4)。ここで、構成 2 にストレー ジノードを追加した構成を構成 4（サーバーノード 4 台、ストレージノード 2 台） とします。 図 6-4 構成 2 にストレージノードを追加 26 構成 2 と構成 4 におけるETL処理の実行時間を図 6-5に示します。 図 6-5 構成 2 および構成 4 の ETL 処理実行時間 構成 2 から構成 4 へ変更したことで ETL 処理実行時間が約 16%短縮されています。 構成 2 から構成 3 へ変更したときは約 2％の実行時間の短縮であったことと比較す るとストレージノード追加の効果が顕著に確認できます。 27 次に、構成 2 および構成 4 の相対読み込み速度とCPU使用率の時間推移を比較し ます（図 6-6）。 構成 2 では処理時間の前半部分で相対読み込み速度が上限に達していました。構 成 4 では、ストレージノードの追加で上限が引きあがり、全体の処理時間が短縮さ れたことが確認できます。 図 6-6 構成 2、構成 4 における相読み込み量及び CPU 使用率の時間推移 本検証を通して、ボトルネックであるハードウェアリソースを特定し増強するこ とで ETL 処理の性能が向上することを確認できました。 28 6.3 容量を基準にしたディスクドライブ数での性能 本章では、まずストレージノードの台数は増強せずにサーバーノードのみを追加 したため、ストレージ側がボトルネックとなりました。そこで、次にストレージノ ードを追加してディスクドライブを 44 台から 88 台に増強しました。このように CPU 能力のみの増強を行うと、ディスク I/O がボトルネックになりやすくなっています。 近年のストレージ技術の進歩によってディスクドライブの大容量化が進み、大規 模データベースの構築に必要なディスクドライブ本数が減少しています。ディスク ドライブに関する技術の向上は、主に容量を増やす方向で大きく改善されましたが、 それと比較するとデータ供給性能はそれほど改善されていません。一方、半導体技 術の進歩により CPU のデータ処理性能は劇的に増加しました。この結果、データベ ースサイズを基準にしてディスクドライブの台数を決めると、CPU のデータ処理性 能に対してストレージのデータ供給性能が不足する傾向があります。システム全体 の性能を向上させるためには、CPU とストレージの性能バランスを考慮した構成を とることが必要です。 そのことを確認するために、新たにデータベースサイズで見積もったディスクド ライブ数(12 台)で ETL 処理を実行し、すでに実施した構成 2、構成 4 の ETL 処理実 行時間と比較しました。このときのサーバーノードはすべて 4 台です。 3 つの構成でのETL処理実行時間の比較を図 6-7に示します。 図 6-7 サーバーノード 4 台でディスクドライブ数を増加させたときの ETL 処理実行時間 29 図 6-7の通り、少ないディスクドライブ数で構成するとETL処理性能が悪化します。 大量データを扱うETL処理では、ディスクドライブ台数をデータベースのサイズを 基準に見積もると、CPUのデータ処理能力に対してストレージのデータ供給能力が 不足する傾向があります。 本章で示した検証結果によると、サーバーノード 4 台ではディスクドライブ 44 台 でもディスクI/Oがボトルネックになりました。しかし、同一のデータサイズをより 多くのディスクドライブ数で分散させると空き容量が大きくなります（図 6-8）。デ ータベースのサイズを基準にディスクドライブの数を見積もると 12 台で収まるため、 44 台、88 台といった台数は多いと感じるかもしれません。 図 6-8 同一のデータ量をより多くのディスクドライブ数で分散 データの処理と供給の性能バランスを保つにはこのように多くのディスクドライ ブ数が必要になる傾向がありますが、必ずしもデータ容量が少ないうちからたくさ んのディスクドライブ台数を用意する必要はありません。パーティション表と ASM のリバランス機能を活用することで、データ量増大に伴うディスクドライブの追加 によってデータ供給性能の向上が可能です。 30 図 6-9 データ増大に伴うディスクドライブ追加でデータ供給性能の向上 ETL 処理で扱うデータは日々蓄積されていく傾向を持つデータです。日々蓄積さ れるデータで表の全体サイズは増加していきますがパーティション表を使用するこ とで、表の増加に関わらず走査範囲を該当パーティションに絞ることができます。 例えば 1 年分のデータが入った表の中からある特定の月だけ検索したい場合、非パ ーティション表では走査範囲が表全体の 1 年分ですが、月ごとにパーティションを 作成した場合は指定した月のパーティション範囲のみです。 一方、ASM ディスクグループにディスクドライブを追加すると、既存データが追 加したディスクドライブにリバランスされます。これにより、既存データに対する ストレージのデータ供給速度を向上することができます。 最初から性能バランスを考慮して多くのディスクドライブを用意すると、システ ムの稼動開始時には大きな空き容量ができてしまいます。パーティション表と ASM のリバランスを使用することで、データベースサイズの増大に伴うディスクドライ ブの追加によってデータ供給性能を向上させていく運用ができます。 また、データ供給速度の向上のためにディスクドライブ数を増やす方法として、 DWH 環境と ETL 環境を統合する E-LT アーキテクチャを採用する方法があります。 この構成のメリットについては次章で詳しく取り扱いますが、ここではディスクド ライブ数の面から取り上げます。 31 ETL環境のリソースとDWH環境のリソースは通常別々に用意されています。この 状況でディスクドライブの様子を示したのが図 6-10です。 図 6-10 ETL 環境と DWH 環境で別々に用意されたディスクドライブ E-LTアーキテクチャでは、ETL環境とDWH環境は同一の環境で構築することがで きます。この状況をディスクドライブの様子を示したのが図 6-11です。 図 6-11 E-LT アーキテクチャでのディスクドライブ 図 6-10ではETLおよびDWHに使用されているディスクドライブは 2 本、図 6-11で は 4 本です。このようにETL環境とDWH環境を同一環境にすることによってディス クドライブ数が増加するため、別環境であったときよりもデータ供給速度を向上さ せることができます。 この構成は ETL 処理と DWH クエリの実行時間帯が分離している場合特に有効で す。次章ではこの構成のメリットを検討します。 32 7. データベース統合による ETL 処理と DWH クエリの性能向上 ETL 処理は DWH 構築に必要な前処理です。DWH クエリの処理内容は、大量データの読 み込み、結合、ソートなど ETL 処理と同様の処理で構成され、ハードウェアリソースの消 費傾向も類似しています。このことから DWH に適したハードウェアリソースのバランス を持つデータベースサーバーは ETL 処理にも適した環境であると考えられます。 そこで本章では、E-LT アーキテクチャによってもたらされる以下の２つのメリットを検 証します。 1. DWH 環境と ETL 環境を同一環境にした場合、ETL 専用環境のリソースを節約できる のみではなく、データベース環境へのハードウェアリソース追加が ETL 処理と DWH クエ リの両処理に対して有効に働きます。 2. ETL 処理を通して作成したデータは DWH 環境へ格納されます。このとき、DWH 環境 のデータベースエンジンで ETL 処理を行えば、同じ環境であるためデータ移動時間を短縮 できます。 7.1 ETL 処理と同様のリソース追加による DWH クエリの性能向上 本節では、DWH クエリと ETL 処理を同一環境で行う場合、ETL 性能を向上させ るための環境へのハードウェアリソース追加が ETL 処理だけでなく DWH クエリの 性能向上につながることを確認します。そのために、6 章と同じ構成である構成 1（8 コア、44 ディスクドライブ）、構成 2（16 コア、44 ディスクドライブ）および構成 ４（16 コア、88 ディスクドライブ）を使用して DWH クエリを実行した性能および リソース消費傾向の変化を確認します。 DWH クエリには「売上金額合計 TOP10」を使用し構成 1 では 16 パラレル、構成 2 および構成 4 では 32 パラレルで実行しました。 各構成におけるDWHクエリの実行時間を図 7-1に示します。 33 図 7-1 各構成における DWH クエリの実行時間 図 7-1より、構成 1、構成 2 および構成 4 へとリソースの追加によって性能向上して いることが確認できます。 34 次に、DWH クエリ実行中のストレージリソースの消費傾向を確認するために読み 込み性能の時間推移のグラフを示します。相対読み込み速度の基準となる値 1.0 は、 構成 1 での顧客ファクト作成のための ETL 処理の読み込み速度の最大値です。本検 証の DWH クエリのストレージノード 1 台での相対読み込み速度の上限値は 1.25 付 近であることは事前にわかっています。 図 7-2 各構成における読み込み性能の時間推移 35 構成 1 から構成 2 へサーバーノード数を 2 倍にした構成変更では DWH クエリの 実行時間が約 20％しか短縮していませんでした。構成 2 の相対読み込み速度を確認 すると 1.25 付近で上限値に達しています。このことから実行時間が約 20％しか短縮 しなかった原因はディスク I/O がボトルネックとなったためだと考えられます。そ こで構成 2 から構成 4 へストレージノード数を 2 倍にすると実行時間が大きく短縮 されました。 DWHクエリは大量のデータを扱うので、CPUリソースだけでなくストレージ性能 も考慮しないと適切な性能が得られません。この傾向はETL処理に見られるハード ウェアリソース消費傾向と同様のものです。そこで、ETL処理とDWHクエリの環境 を同一にし、この環境にハードウェアリソースの追加をすれば両処理の性能向上が 期待できます。(図 7-3) 図 7-3DWH と ETL 統合環境へのリソース追加 次に、DWH 環境で ETL 処理を行うことによるデータ移動時間の短縮を検討しま す。 36 7.2 データベース統合によるデータ移動時間の短縮 ETLとDWH環境を別々に構成した場合、TransformしたデータをETL環境から取り 出しDWH環境に転送する必要があります。一方、E-LTアーキテクチャではこの転送 処理が減少します（図 7-4）。本節ではETL、DWHのシステム間のデータ移動時間が ETL処理全体にどの程度の影響を与えるのかを検証します。 図 7-4 DWH を ETL 処理エンジンとすることで省略されるシステム間データ移動 システム間データ移動時間の有無がETL全体の処理時間に及ぼす影響を確認す るためにETL、DWH環境別構成でTransform 後にDWH環境へ格納するデータのシ ステム間移動の測定を行いました。ETL、DWH環境別構成のそれぞれの構成は図 7-5の通りです。 37 図 7-5 検証で使用した ETL、DWH 環境別構成 システム間のデータ移動はデータ・ポンプ・エクスポートによるデータの取り 出し(expdp)、scp コマンドによる転送、そしてデータ・ポンプ・インポートによる データの格納(impdp)で実施しました。Transform は顧客ファクト作成のための ETL 処理と売上ファクト作成のための ETL 処理の 2 種類をパラレル度 16 で実行しま した。2 種類実行した理由は、DWH に格納するファクト表のデータのサイズによ るシステム間データ移動時間の違いを確認するためです。それぞれのファクト表 のデータサイズは顧客ファクト表が 6GB、売上ファクト表が 60GB になります。 検証結果を図 7-6に示します。 図 7-6 各ファクト表を DWH 環境へ格納するまでの Transform とシステム間データ移動の時間 38 ETL 処理においてシステム間データ移動のために多くの時間が割かれているこ とが確認できます。特に、売上ファクト表(60GB) 作成のための ETL 処理ではシ ステム間データ移動時間が大きくなっています。これは、顧客ファクト表(6GB) 作 成のための ETL 処理に比べてデータサイズが大きいためです。本検証では、顧客 ファクト作成の場合のシステム間データ移動は Transform の実行時間の 35％、売 上ファクト作成の場合 420％もの時間が必要になりました。 一方、DWH環境上でETL処理を実行する場合、図 7-6のシステム間データ移動 の時間が必要ないためそれだけ速くETL処理が完了します。 本節の検証より、Transform した結果大きなデータが作成されると、システム間 データ移動に多くの時間を割かれることが確認できました。DWH 環境上で ETL 処理を行うとこの時間が不要になります。DWH のデータは大規模になる傾向があ るので、システム間の移動時間がなくなることで ETL 処理時間が大きく短縮され ると考えられます。 7.3 E-LT アーキテクチャのメリット 図 7-7はETLのハードウェアリソース増強検証（6 章）と、ETLとDWHのハードウ ェアリソース共有検証（7 章）の結果を合わせたものです。 DWHクエリとETL処理の実行時間帯が異なる場合、それぞれの処理は干渉しあ わないため図 7-7で示した結果が適用できます。 39 図 7-7 E-LT アーキテクチャでのメリット 以上、DWH 環境上での ETL 処理を可能にする E-LT アーキテクチャについて次 の 2 点を確認しました。 1. ETL 専用環境のリソースを節約できるのみではなく、環境へのハードウェ アリソース追加を ETL 処理と DWH クエリの両処理に対して有効に使えます。 2. ETL 処理を通して作成したデータを抜き出し DWH 環境へ転送する時間を 不要にできることで、ETL 処理全体の実行時間を大きく短縮できます。 Oracle Database での E-LT アーキテクチャでは上記 2 点のメリットが同時に享受 できます。 40 8. まとめ 本文書では、NEC ブレードシステム SIGMABLADE と iStorage D8 上での E-LT アーキテ クチャの有効性に関する検証結果を報告しました。 Oracle Database は単なるデータの入れ物ではなく、それ自体が強力なデータ加工エンジ ンです。そのため Oracle Database では E-LT アーキテクチャが実装可能です。データベース をエンジンとした ETL 処理のコードは SQL や PL/SQL で記述されます。Oracle では、GUI によって ETL フローを構成し SQL コードを生成する ETL ツールを提供しています。 ETL 処理は大量データを扱う処理であるので、CPU だけでなくストレージにも高い性能 を求められます。そこで、SIGMABLADE と Oracle Real Applications Clusters、そして iStoradeD8 と Oracle Automatic Storage Management を組み合わせることで CPU リソースおよ びストレージリソースを簡単に増強できます。 検証では、ETL 処理性能向上のために CPU リソースのみならずストレージリソースの追 加も実施し、データの処理性能と供給性能のバランスを保つことで ETL 処理の性能が向上 することを確認しました。 また、E-LT アーキテクチャは DWH クエリと同様に SQL で大量データを処理するもので あり、リソース消費傾向が似たものになっています。このため、ETL 処理と DWH クエリ の実行環境を同一にし、この環境にハードウェアリソースの追加をすれば両処理に対する 有効なハードウェアリソース追加となります。また、DWH のデータベース上で ETL 処理 を行うため、DWH に格納する Transform 後のデータのシステム間移動が必要なくなります。 意思決定の迅速化とデータ量の増大に対応するために、SIGMABLADE と iStorage D8 上 での Oracle Database を ETL 処理エンジンとする E-LT アーキテクチャが有効であることが 確かめられました。 41 9. 付録 5.3節ではETL処理のSQL文実行中に実施された複数の処理の実行時間帯を示しました。本 章ではその取得方法について説明します。 ETL 処理の SQL 文実行後に DBMS_SQLTUNE.REPORT_SQL_MONITOR を実行した結果 から得られるレポートにより上記の情報を得ることができます。 DBMS_SQLTUNE.REPORT_SQL_MONITOR は Oracle Database 11g より使用できる機能です。 DBMS_SQLTUNE.REPORT_SQL_MONITORを用いて顧客ファクト作成のためのETL処理 を監視したレポートを図 9-1に示します。このレポートには多くの列がありますが、実行 時間帯を得るには以下の 2 列に注目します。 Time Active(s) … Start Active … Operation のアクティブ時間（秒） SQL 文開始から Operation の操作が開始されるまでの経過時間(秒) 図 9-1のレポートは、上記の 2 列の情報を抜粋したものになっております。 この情報をもとに行オペレーションごとに実行時間帯を図示すると図 5-10が得られま す。 42 図 9-1 顧客ファクト作成のための ETL 処理の監視レポート結果（抜粋） 43 日本オラクル株式会社 日本電機株式会社 〒107-0061 〒108-8001 東京都港区北青山 2-5-8 東京都港区芝 5-7-1 オラクル青山センター NEC 本社ビル Copyright© 2009, Oracle. All rights reserved. Copyright© 2009 NEC Corporation. All Rights Reserved 無断転載を禁ず このドキュメントは単に情報として提供され、内容は予告なしに変更される場合があり ます。このドキュメントに誤りが無いことの保証や、商品性又は特定目的への適合性の黙 示的な保証や条件を含め明示的又は黙示的な保証や条件は一切無いものとします。日本オ ラクル株式会社は、このドキュメントについていかなる責任も負いません。また、このド キュメントによって直接又は間接にいかなる契約上の義務も負うものではありません。こ のドキュメントを形式、手段（電子的又は機 械的）、目的に関係なく、日本オラクル株式 会社の書面による事前の承諾なく、複製又は転載することはできません。 Oracle、JD Edwards、PeopleSoft、及び Siebel は、米国オラクル・コーポレーション及び その子会社、関連会社の登録商標です。 その他の名称は、各社の商標または登録商標です。 本書は、Oracle GRID Center の取組みにて実施された検証結果に関する技術情報を提供す るものであり、本書に記載されている内容は改善のため、予告無く変更することがありま す。富士通株式会社は、本書の内容に関して、いかなる保証もいたしません。また、本書 の内容に関連した、いかなる損害についてもその責任は負いません。 Red Hat は米国およびその他の国で Red Hat,Inc の登録商標または商標です。 Linux は Linus Torvals の商標です。 その他の各種製品名は、各社の製品名称、商標または登録商標です。 本資料に記載されているシステム名、製品名等には、必ずしも商品表示((R)、TM)を付記 していません。 44