1. ユーザーズ・ガイド
  2. Oracle Big Data SQLの概要

1 Oracle Big Data SQLの概要

Oracle Big Data SQLへようこそ。

1.1 Oracle Big Data SQLとは

Oracle Big Data SQLでは、Apache Hive、HDFS、Object Store、Oracle NoSQL Database、Apache Kafka、Apache HBaseおよびその他のNoSQLデータベースなど、複数のビッグ・データ・ソースに格納された非リレーショナル・データに対する問合せがサポートされています。これにより、分散データに対して統一した問合せが可能になり、異なる製品のデータ・ストアのデータがすべてOracleデータベースに格納されているかのようにシームレスに表示および分析できるようになります。

Oracle Big Data SQLを使用すると、手動または既存のアプリケーションによって、Hadoopエコシステム内のデータに対する非常に複雑なSQL SELECT文を実行できます。たとえば、Oracle Advanced Analyticsのユーザーである場合は、Oracle Big Data SQLを使用してOracle Databaseデータ・マイニング・モデルをHadoopのビッグ・データに拡張できます。

Oracle Big Data SQLインストールのコンポーネント

Oracle Big Data SQLのアーキテクチャは、Hadoop (またはNoSQL)クラスタ上の並列インストールと連動するOracle Databaseシステム(単一ノードまたはRAC)上のインストールで構成されます。この2つのシステムは、EthernetまたはInfiniBandのどちらかを通じてネットワーク接続できます。Oracle Databaseシステムのコンピュート・ノード上のHadoopおよびHiveクライアントにより、データベースとOracle Big Data SQLプロセス(Oracle Big Data SQLセルと呼ばれる)の間の通信が可能になります。このプロセスは、Hadoopクラスタの各DataNodesで実行されます。このメカニズムによって、Oracle DatabaseはHadoopクラスタ上のデータの問合せが可能になります。また、Oracle Big Data SQL Query Serverは、クラスタ上のエッジ・ノード上にデプロイでき、Oracle Big Data SQLセルに接続することもできます。詳細は、問合せサーバーの操作を参照してください。

Hadoop HDFSファイル・システム内およびObject Storage内のデータは不明な形式で保存されているため、SQL問合せには、行内と列内の処理対象データの解析と解釈のための、なんらかの構造が必要になります。Oracle Big Data SQLでは、HDFSでこれを実現するために、利用可能なHadoop構造(特にInputFormatおよびSerDe Javaクラス)が活用されます。必要に応じて、Hiveメタデータ定義も使用されます。オブジェクト・ストレージの場合、Big Data SQLでは、テキスト、Parquet、ORCおよびAvroファイル形式のデータへのアクセスに、高度に最適化されたCドライバが使用されます。DataNodes上のOracle Big Data SQL処理セルは、YARNによって管理され、Hadoopインフラストラクチャに統合されます。これらのセルは、Smart Scan、ストレージ索引、集計オフロードという3つの重要な機能を提供しています。ビッグ・データ・ソース用のスマート・スキャンについて、ストレージ索引についておよび集約オフロードについてを参照してください。

1.1.1 Oracle外部表について

Oracle Big Data SQLによって、外部表のパフォーマンスが大幅に向上します。外部表は、データベース外のデータの場所を識別および記述するOracle Databaseオブジェクトです。他のデータベース表に使用するのと同じSQL SELECT構文を使用して、外部表を問い合せることができます。

Big Data SQLでは、ファンアウトの並列性が使用されることで、外部表での処理の拡張性が非常に高まります。たとえば、Big Data SQLの外部表に対するシリアル問合せでは、Hadoopクラスタの並列処理能力が利用されます。

外部表はアクセス・ドライバを使用して、データベース外のデータを解析します。様々なソースからのデータを処理する複数の外部データ・ドライバが存在します。1つ目はORACLE_HIVEであり、これは、Apache Hiveで定義されているメタデータを利用します。2つ目はORACLE_HDFSであり、これは、HDFS内のデータに直接アクセスします(外部表定義の一部としてメタデータを指定)。3つ目はORACLE_BIGDATAであり、これは、Object Storage内のデータにアクセスします。HDFSと同様に、メタデータは表定義の一部です。

1.1.2 Oracle Big Data SQLのアクセス・ドライバについて

外部表への問合せによって、データがOracleデータベースの表に格納されている場合と同様に、外部ソースに格納されているデータにアクセスできます。Oracle Databaseは、外部表が提供するメタデータを介してデータにアクセスします。

Oracle Databaseでは、次に示すOracle Big Data SQL用のアクセス・ドライバをサポートしています。

  • ORACLE_HIVE: Apache Hiveデータ・ソースに対するOracle外部表を作成できます。HDFSデータ・ソースに対してHive表がすでに定義されている場合、このアクセス・ドライバを使用します。ORACLE_HIVEは、Hive表が定義されているHBaseやKafkaなど他の場所に格納されているデータにもアクセスできます。

  • ORACLE_HDFS: HDFSに格納されているファイルに対するOracle外部表を直接作成できます。このアクセス・ドライバはHive構文を使用してデータ・ソースを記述し、COL_1、COL_2などのデフォルトの列名を割り当てます。個別のステップとしてHive表を手動で作成する必要はありません。

    ORACLE_HIVEと同じ方法でHiveメタデータ・ストアからメタデータを取得するのではなく、ORACLE_HDFSアクセス・ドライバは必要な情報をすべてアクセス・パラメータから取得します。メタデータを指定するにはORACLE_HDFSアクセス・パラメータが必要です。このパラメータは、Oracle Database内の外部表定義の一部として格納されます。

  • ORACLE_BIGDATA: オブジェクト・ストアのファイルを介して外部表を作成できます。このアクセス・ドライバを使用して、オブジェクト・ストアに取得されたデータを問い合せます。ORACLE_BIGDATAでは、テキスト(つまり、デリミタ付き、JSONおよびXML)、ORC、ParquetおよびAvroファイル・タイプがサポートされています。ORACLE_HDFSドライバと同様に、アクセス・パラメータを使用してファイルの構造を説明します。

1.1.3 ビッグ・データ・ソースのSmart Scanについて

Oracle外部表には従来の索引がありません。このような外部表に対する問合せは、通常、全表スキャンを必要とします。HadoopクラスタのDataNode上のOracle Big Data SQL処理エージェントにより、Smart Scan機能(フィルタ述語のオフロードなど)がOracle外部表にまで拡張されます。Smart Scanは、問合せ結果がデータベース・レイヤーに返信される前に、ストレージ・レイヤーで列および述語のフィルタリングを実行するために、Oracle Exadata Database Machineでしばらくの間使用されてきました。Oracle Big Data SQLでは、Smart Scanは、リクエストされた要素のみがOracle Databaseに送信されるようにHadoopサーバーでローカルに実行される最終フィルタリング・パスです。HadoopのDataNodeで稼働しているOracleストレージ・サーバーは、HDFSの様々なデータ形式(CSVテキスト、Avro、Parquetなど)に対してSmart Scansを実行できます。

このSmart Scanの実装では、Hadoopクラスタの超並列処理能力を利用してソースでデータをフィルタリングします。無関係なデータの大部分(全体の最大99パーセントまで)を先んじて破棄できます。これには、次のような利点があります。

  • クラスタとデータベース間のデータの移動およびネットワーク・トラフィックを大幅に削減します。

  • 非常に小さい結果セットをOracle Databaseサーバーに返します。

  • 可能な場合、スケーラビリティおよびクラスタ処理を利用してデータを集約します。

問合せ結果の返送速度が大幅に速くなります。これは、ネットワーク上のトラフィックおよびOracle Databaseでのロードが削減されたことによる直接の結果です。

関連項目:

スマート・スキャン対象のデータ・ファイルを設定する方法の詳細は、「HDFSへのOracle表領域の格納」を参照してください。

外部表の概要、およびOracle Databaseドキュメント・ライブラリ内の詳細情報への手引きについては、『Oracle Database概要』を参照してください。

1.1.4 ストレージ索引について

HDFSに格納されているデータの場合、Oracle Big Data SQLでは、Oracle Databaseに対して透過的なストレージ索引が自動的に管理されます。ストレージ索引には、HDFSに格納されているデータに関するハード・ディスク上のデータ分散のサマリーが含まれています。ストレージ索引により、I/O操作とフラット・ファイルからOracle Databaseブロックにデータを変換するCPUコストを減らすことができます。ストレージ索引を"否定の索引"と考えることができます。Smart Scanは、ストレージ索引からデータがデータのブロック内にないことがわかるため、そのブロックを読み飛ばすことができます。これにより、I/Oを大幅に回避できます。

ストレージ索引は、HDFSに基づいた外部表、またはORACLE_HDFSドライバとORACLE_HIVEドライバのどちらかを使用して作成された外部表に対してのみ使用できます。ストレージ索引は、オブジェクト・ストアに基づく外部表や、Apache HBaseやOracle NoSQLなどのStorageHandlerを使用する外部表には使用できません。

ストレージ索引はインメモリー領域索引を収集したもので、各領域索引には最大32列のサマリーが格納されています。各分割に領域索引が1つあります。1つの領域索引に格納されているコンテンツは、その他の領域索引とは無関係です。これにより拡張性が高まり、ラッチ競合を回避できます。

各領域索引では、ストレージ索引が領域の列の最小値と最大値を管理します。最小値および最大値は、不要なI/Oの回避に使用されます。これは、I/Oフィルタリングとも呼ばれます。V$SYSSTATビューにあるストレージ索引統計別に保存されたセルのXTグラニュルI/Oバイト数は、ストレージ索引を使用して保存されたI/Oのバイト数を示したものです。

次の比較を使用する問合せはストレージ索引によって改善されます。

  • 等価(=)

  • 不等価(<、!=または>)

  • 以下(<=)

  • 以上(>=)

  • IS NULL

  • IS NOT NULL

Oracle Big Data SQLサービスが受け取った問合せに含まれる比較述語が領域の列の最大値よりも大きい場合や最小値よりも小さい場合に、ストレージ索引が自動的に構築されます。

ノート:

  • WHERE問合せ句に頻繁に出現する列に基づいて表内の行を順序付けると、ストレージ索引の効果が上がります。

  • ストレージ索引は、すべての非言語データ型で動作し、非言語索引に似た言語データ型でも動作します。

例1-1 ストレージ索引を使用したディスクI/Oの回避

次の図に、表および領域索引を示します。この表の列Bには、1から8までの範囲の値があります。一方の領域索引には最小値として1、最大値として5が格納されています。もう一方の領域索引には、最小値として3、最大値として8が格納されています。

storage_index_io.pngの説明が続きます
図storage_index_io.pngの説明
次のような問合せの場合、最初の行セットのみが一致します。2番目の行セットの最小値と最大値は問合せのWHERE句と一致しないため、ディスクI/Oが回避されます。
SELECT * 
FROM TABLE 
WHERE B < 2;

例1-2 ストレージ索引とブルーム・フィルタの使用

ストレージ索引を使用すると、表の結合で不要なI/O操作をスキップできます。たとえば、次の問合せでは、I/O操作を実行し、ファクト表の最初のブロックにのみブルーム・フィルタを適用しています。ブルーム・フィルタは、結合パフォーマンスの向上のために重要です。この例では、ファクト表ではなくディメンション表に述語があります。ブルーム・フィルタは"dim.name=Hard drive"に基づいて作成されて、このフィルタがファクト表に適用されます。そのため、ディメンション表にフィルタがある場合でも、ディメンション問合せの結果に基づいて、そのソース(つまりHadoop)でデータにフィルタを適用できます。これにより、関係するストレージ索引などの最適化も可能になります。 

SELECT count(*) 
FROM fact, dimension dim  
WHERE fact.m=dim.m and dim.product="Hard drive";
storage_index_join.pngの説明が続きます
図storage_index_join.pngの説明

ファクト表の2番目のブロックに対するI/Oは、最小値/最大値の範囲(5,8)がブルーム・フィルタに存在しないため、ストレージ索引によって完全に回避されます。

1.1.5 述語のプッシュダウンについて

多くのビッグ・データ・システムでは、ファイルタイプそのもの(Apache Parquetなど)またはHiveのパーティション化やStorageHandler APIを使用して、述語のオフロード機能が一部のレベルでサポートされています。Oracle Big Data SQLでは、述語をOracle Databaseからサポート・システムにプッシュすることで、このようなオフロード機能を利用しています。たとえば、述語のプッシュダウンによって次の動作が自動的に行われるようになります。

  • パーティション化されたHive表に対する問合せは、パーティション列に対するフィルタ述語に基づいてプルーニングされます。

  • Apache ParquetおよびApache ORCファイルに対する問合せでは、内部索引(これらのファイル形式内に含まれる構造など)に照らして述語を検証することで、I/O回数を削減します。

    ノート:

    次の項で説明する回避策を使用してHiveを介してファイルが生成されないかぎり、Parquetファイルに対する問合せの述語のプッシュダウンは非効率です。

  • Oracle NoSQL DatabaseまたはApache HBaseに対する問合せでは、述語を使用してリモート・データ・ストア内のデータのサブスキャンが行われます。

述語のプッシュダウンを有効にするために必要なデータ型

述語のプッシュダウンでは、Hiveデータ型とOracleデータ型の間に特定のマッピングが存在することが必要です。これらのマッピングを次の表に示します。

Hiveデータ型 Oracleデータ型にマッピング

CHAR(m)

CHAR(n)、VARCHAR2(n) (n >= m)

VARCHAR(m)

CHAR(n)、VARCHAR2(n) (n >= m)

string

CHAR(n)、VARCHAR2(n)

DATE

DATE

TIMESTAMP

TIMESTAMP(9) Hive TIMESTAMPにはナノ秒、9桁の小数秒が入ります。

TINYINT

NUMBER(3)が望ましいが、NUMBERまたはNUMBER(n) (任意の値n)も有効。

SMALLINT 

NUMBER(5)が望ましいが、NUMBERまたはNUMBER(n) (任意の値n)も有効。

INT  

NUMBER(10)が望ましいが、NUMBERまたはNUMBER(n) (任意の値n)も有効。

BIGINT                    

NUMBER(19)が望ましいが、NUMBERまたはNUMBER(n) (任意の値n)も可

DECIMAL(m)

m = nのNUMBER(n)が望ましいが、NUMBERまたはNUMBER(n) (任意の値n)も有効。

FLOAT                      

BINARY_FLOAT

DOUBLE                     

BINARY_DOUBLE

BINARY

RAW(n)

BOOLEAN

CHAR(n)、VARCHAR2(n) (n >= 5)、値TRUE、FALSE

BOOLEAN

NUMBER(1)が望ましいが、NUMBERまたはNUMBER(n) (任意の値n)も有効。値0 (false)、1 (true)。

1.1.6 キャラクタ・ラージ・オブジェクト(CLOB)処理のプッシュダウンについて

Hadoopデータに対する問合せには、レコード数が数百万になる可能性があるラージ・オブジェクトの処理を伴うことがあります。こうしたオブジェクトをフィルタ処理や解析のためにOracle Databaseに戻すことは非効率です。Oracle Big Data SQLでは、Hadoopクラスタ上の専用処理セルにCLOBの処理をプッシュ・ダウンすることで大幅なパフォーマンス向上を実現できます。Hadoopでフィルタ処理すると、Oracle Databaseに戻す行の数が少なくなります。解析することで、フィルタ処理した各行内の列から返されるデータの量が少なくなります。

CLOB処理はユーザーのニーズに適合するように無効化または再有効化できます。

現在のリリースでは、この機能は現時点でCLOBデータを返すJSON式にのみ適用されます。ストレージ・レイヤーの評価に適格なJSONフィルタ式には、単純化された構文のJSON_VALUEおよびJSON_QUERYが含まれます。

将来のリリースでは、その他のCLOB型(substrやinstrなど)に加えてBLOBデータにも同じサポートが提供されます。

Oracle Big Data SQLは、次に示すサイズ制約の範囲内で、HadoopにCLOBの処理をプッシュ・ダウンできます。

  • CLOB列のフィルタリングは最大サイズが1 MB。

    ストレージ・サーバーでの評価に利用できる実際のデータ量は、使用される文字セットに応じて異なることがあります。

  • 列の解析は最大32 KB。

    この制限は、CLOBデータ型のストレージからの選択リストの投影を表します。

列のサイズがこれらの2つの値を超える場合にのみ、処理がOracle Databaseに戻されます。

例1-3 JSONドキュメントの処理

大きなJSONドキュメントへの問合せでは、HadoopのOracle Big Data SQL処理セルにCLOB処理をプッシュダウンすることで効率が大幅に向上します。次の例では、購入オーダー情報がJSONで保存されています。このレコードの最大サイズは25Kで、数百万件のレコードの処理が必要になるとします。 
{"ponumber":9764,"reference":"LSMITH-20141017","requestor":"Lindsey Smith","email”: “Lindsey@myco.com”, “company”:”myco” …}
次に示すように、このデータにアクセスする外部表を作成できます。単一のCLOB列がある点に注目してください。
CREATE TABLE POS_DATA
  ( pos_info CLOB )
  ORGANIZATION EXTERNAL
  ( TYPE ORACLE_HDFS
    DEFAULT DIRECTORY DEFAULT_DIR
    LOCATION ('/data/pos/*')
  )
 REJECT LIMIT UNLIMITED;
このようにすると、次の単純な構文でデータを問い合せることができます。
SELECT p.pos_info.email, p.pos_info.requestor
FROM POS_DATA p
WHERE p.pos_info.company=’myco’

この問合せ例では、次の2つのデータ除外の最適化が実施されます。

  • データは、Hadoopクラスタ内のOracle Big Data SQLセルでフィルタ処理されます。「myco」という会社に関連するレコードのみが解析されます(解析後、該当するレコードから選択されたデータのみがデータベースに返されます)。

  • クラスタ内のOracle Big Data SQLセルは、フィルタ処理されたレコードのセットを解析して、各レコードから要求された2つの属性(p.pos_info.emailとp.pos_info.requestor)の値のみがデータベースに返されます。

次の表では、CLOB処理のプッシュダウンがサポートされる別の例を示します。前述したように、投影(CLOB列の選択側のリファレンス)は32 KBのCLOBデータに制限されていて、述語のプッシュダウンは1 MBのCLOBデータに制限されています。

問合せ コメント
SELECT count(*) FROM pos_data p WHERE pos_info is json; この場合、述語によりJSON形式に準拠する列のみが返されるようになります。
SELECT pos_info FROM pos_data p WHERE pos_info is json; 前の場合と同じ述語ですが、CLOB値が投影されるようになっています。
SELECT json_value(pos_info, '$.reference') FROM pos_data p WHERE json_value(pos_info, '$.ponumber') > 9000 ここでは、述語はJSONドキュメントのフィールドに対して発行されます。また、投影されたCLOB JSON値の上部にあるフィールド"reference"を取得するJSON値も実行しています。
SELECT p.pos_info.reference FROM pos_data p WHERE p.pos_info.ponumber > 9000; これは前の例と同様に機能しますが、簡略化された構文で表現されています。
SELECT p.pos_info.email FROM po_data p WHERE json_exists(pos_info, '$.requestor') and json_query(pos_info, '$.requestor') is not null; この例は、述語としてjson_existsとjson_queryも使用できるようにする方法を示しています。

1.1.7 集計オフロードについて

Oracle Big Data SQLでは、Oracle In-Memoryテクノロジを使用して、集計処理をOracle Big Data SQLセルにプッシュダウンします。これにより、Oracle Big Data SQLでは、Hadoopクラスタの処理能力を利用して、クラスタ・ノード全体に集計を分散させることができます。オフロードしない集計と比べて、パフォーマンスが急速に向上します。特に、適度の数の要約グループ化があると顕著です。単一表問合せの場合、集計操作は常にオフロードする必要があります。

Oracle Big Data SQLセルは、単一表と複数表の集計をサポートしています(ファクト表に結合するディメンション表など)。複数表集計の場合、Oracle Databaseは、キー・ベクターが集計プロセスのセルにプッシュされるキー・ベクター変換最適化を使用します。この変換タイプは、ビジネス問合せで一般的に使用される一般的な集計演算子(SUM、MIN、MAXおよびCOUNT)を使用するスター型結合SQL問合せに役立ちます。

ベクター変換問合せは、結合にブルーム・フィルタを使用する問合せの効率性を高めます。ベクター変換された問合せをOracle Big Data SQLセルと一緒に使用すると、集計に使用される行のフィルタ処理をオフロードする機能によって、問合せの結合のパフォーマンスが向上します。この最適化中、問合せ計画にKEY VECTOR USEという操作が表示されます。

Oracle Big Data SQLセルでは、グループ化列(キー・ベクター)がOracle Big Data SQL Storage Indexに適用されるため、ベクター変換された問合せの方が効率的です。

場合によっては、集計オフロードの利点が得られないこともあります。

  • 述語の欠落

    実行計画にSYS_OP_VECTOR_GROUP_BY述語が欠落している場合、集計オフロードが影響を受けます。次の理由により、述語が欠落する場合があります。

    • 表スキャンとグループ化行ソースの間に許可されていない中間行ソースがある場合。

    • 表スキャンでは行セットは生成されません。

    • オフロードできない式またはデータ型が問合せにある場合。

    • ベクター・グループ化は手動で無効化します。

    • 表スキャンまたは構成の表は、集計オフロードの利点が得られません。

  • スマート・スキャンの欠落

    「cell interconnect bytes returned by XT smart scan」と「cell XT granules requested for predicate offload」統計が使用可能である必要があります。

  • キー・ベクターの欠落

    セルに送信されるデータに対する制限は1MBです。このしきい値を超えた場合、キー・ベクターのインテリジェントなフィルタ処理の利点は得られますが、集計オフロードの利点は必ずしも得られません。この条件は、キー・ベクター・ライト・モードと呼ばれます。キー・ベクターの中には、サイズが大きいために、完全にはオフロードされないものがあります。ライト・モードでは、それらは集計オフロードをサポートしていないキー・ベクターとともにオフロードされます。ライト・モードでは、キー・ベクターは完全にはシリアル化されません。ライト・モードでキー・ベクターがオフロードされると、ベクター・グループ化オフロードは無効になります。

関連項目:

Oracle Databaseでの集計の動作の詳細は、Oracle Database In-Memoryガイドを参照してください

1.1.8 Oracle Big Data SQLの統計について

Oracle Big Data SQLでは、パフォーマンス分析のためのデータを提供できる統計が多数用意されています。

5つの主要なセルのXTおよびストレージ索引の統計

問合せがオフロード可能である場合、次のXT関連の統計は、どのようなIOの節約がオフロードおよびSmart Scanに期待できるかを判断するのに役立ちます。

  • cell XT granules requested for predicate offload

    リクエストされるグラニュルの数は、HDFSブロック・サイズ、Hadoopデータ・ソースの分割可能性、およびHiveパーティションの回避の有効性など、多数の要素によって異なります。

  • cell XT granule bytes requested for predicate offload

    スキャンのためにリクエストされるバイト数。これは、Hiveパーティションの回避後およびストレージ索引の評価前に調査されるHadoop上のデータのサイズです。

  • cell interconnect bytes returned by XT smart scan

    XTスマート・スキャンによってOracle Databaseに返されるI/Oのバイト数。

  • cell XT granule predicate offload retries

    DataNode上で実行されるBig Data SQLプロセスで、リクエストされた操作を完了できなかった回数。Oracle Big Data SQLは、失敗したリクエストをそのデータのレプリカを含んだ他のDataNodes上で自動的に再試行します。retries値はゼロになります。

  • cell XT granule IO bytes saved by storage index

    ストレージ・セル・レベルで、ストレージ索引によるフィルタリングで除去されたバイト数。これは、ストレージ索引によって提供された情報に基づいてスキャンされなかったデータです。

これらの統計は、問合せを実行する前後に、次のようにして確認できます。この例は、問合せの実行前で、null値を示しています。

SQL> SELECT sn.name,ms.value 
FROM V$MYSTAT ms, V$STATNAME sn 
WHERE ms.STATISTIC#=sn.STATISTIC# AND sn.name LIKE '%XT%'; 

NAME                                                      VALUE
-----------------------------------------------------     -----
cell XT granules requested for predicate offload          0 
cell XT granule bytes requested for predicate offload     0
cell interconnect bytes returned by XT smart scan         0 
cell XT granule predicate offload retries                 0
cell XT granule IO bytes saved by storage index           0

問合せの有効性を検証するには、問合せの実行後に、次のようにこれらの統計の一部または全部を確認できます。 

SQL> SELECT n.name, round(s.value/1024/1024) 
FROM v$mystat s, v$statname n
WHERE s.statistic# IN (462,463)
AND s.statistic# = n.statistic#;

cell XT granule bytes requested for predicate offload  32768
cell interconnect bytes returned by XT smart scan   32

5つの集計オフロード統計

次の統計は、集計オフロードのパフォーマンスを分析する際に役立ちます。

  • セルに送信されたベクター・グループ化操作

    集計をセルにオフロードできる回数。

  • カーディナリティのためセルに送信されなかったベクター・グループ化操作

    大きなワイヤフレームのためにオフロードされなかったスキャンの数。

  • セル上で処理されたベクター・グループ化行

    セルで集計された行の数。

  • セルによって返されたベクター・グループ化行

    セルによって返された集計行の数。

  • セル上で処理されたベクター・グループ化行セット

    セルで集計された行セットの数。

次のような問合せを実行することで、これらの統計を確認できます。

SQL> SELECT count(*) FROM bdsql_parq.web_sales;

  COUNT(*)
----------
 287301291

SQL> SELECT substr(n.name, 0,60) name, u.value
FROM v$statname n, v$mystat u
WHERE ((n.name LIKE 'key vector%') OR
       (n.name LIKE 'vector group by%') OR
       (n.name LIKE 'vector encoded%') OR
       (n.name LIKE '%XT%') OR
       (n.name LIKE 'IM %' AND n.name NOT LIKE '%spare%'))
      AND u.sid=userenv('SID')
      AND n.STATISTIC# = u.STATISTIC#
      AND u.value > 0;


NAME                                                      VALUE
-----------------------------------------------------     -----
cell XT granules requested for predicate offload          808 
cell XT granule bytes requested for predicate offload     2.5833E+10
cell interconnect bytes returned by XT smart scan         6903552 
vector group by operations sent to cell                   1
vector group by rows processed on cell                    287301291
vector group by rows returned by cell                     808

9つのキー・ベクター統計

次の統計は、セルに送信されたキー・ベクターの有効性の分析に役立ちます。

  • セルに送信されたキー・ベクター

    セルにオフロードされたキー・ベクターの数。

  • セルでフィルタ処理されたキー・ベクター

    セル上のキー・ベクターによるフィルタ処理で除外された行の数。

  • セルでプローブされたキー・ベクター

    セル上のキー・ベクターによってテストされた行の数。

  • 値で処理されたキー・ベクター行

    値を使用して処理された結合キーの数。

  • コードで処理されたキー・ベクター行

    ディクショナリ・コードを使用して処理された結合キーの数。

  • フィルタ処理されたキー・ベクター行

    スキップ・ビットによりスキップされた結合キーの数。

  • ライト・モードでのセルのキー・ベクター・シリアル化

    形式またはサイズのためにキー・ベクターがエンコードされなかった回数。

  • 割当て制限のためにライト・モードでセルに送信されたキー・ベクター

    1MBメタデータの割当て制限のために不正確フィルタ処理でセルにオフロードされたキー・ベクターの数。

  • 作成されたキー・ベクターeFilter

    キー・ベクターはセルに送信されませんでしたが、eFilter (ブルーム・フィルタに類似)は送信されました。

次のような問合せを実行することで、これらの統計を確認できます。

SELECT substr(n.name, 0,60) name, u.value
FROM v$statname n, v$mystat u
WHERE ((n.name LIKE 'key vector%') OR
       (n.name LIKE 'vector group by%') OR
       (n.name LIKE 'vector encoded%') OR
       (n.name LIKE '%XT%'))
      AND u.sid=userenv('SID')
      AND n.STATISTIC# = u.STATISTIC#


NAME                                                      VALUE
-----------------------------------------------------     -----
cell XT granules requested for predicate offload          250 
cell XT granule bytes requested for predicate offload     61,112,831,993
cell interconnect bytes returned by XT smart scan         193,282,128 
key vector rows processed by value                        14,156,958
key vector rows filtered                                  9,620,606
key vector filtered on cell                               273,144,333
key vector probed on cell                                 287,301,291
key vectors sent to cell                                  1
key vectors sent to cell in lite mode due to quota        1
key vector serializations in lite mode for cell           1
key vector efilters created                               1

ヒント:

The Data Warehouse Insiderで公開されているブログ「Big Data SQL Quick Start」には、これらの統計を使用してOracle Big Data SQLのパフォーマンスを分析する方法を示す一連のコードおよび機能のウォークスルーが掲載されています。第2回、第7回および第10回を参照してください。

1.2 インストール

Oracle Big Data SQLは、データが存在するHadoopシステムの他、データを問い合せるOracle Databaseサーバーにもコンポーネントをインストールする必要があります。

インストールの詳細は、次のリソースを参照してください。

  • 概要

    このガイドでは、サポートされているHadoopシステム/Oracle Databaseサーバーの組合せのためのインストールおよび構成の手順を説明します。

  • Oracle Big Data SQLマスター互換性マトリクス

    これは、My Oracle Supportにあるドキュメント2119369.1です。Big Data SQLと次の項目との互換性に関する最新情報は、このマトリクスを確認してください。

    • Oracle Engineered Systems。

    • その他のシステム。

    • Linux OSのディストリビューションとバージョン。

    • Hadoopディストリビューション。

    • 必要とされるパッチを含むOracle Databaseのリリース。