X

Big Data、Data Integration、Data Lakeに関するテクノロジー、製品・サービス情報、セミナー情報などをお届けします

Recent Posts

Big Data and Data Integration - Japan

Apache KafkaのメッセージをOracle Cloud オブジェクト・ストレージへ永続化する

はじめに 今日のデータ分析基盤では大規模なデータを安価に保持できるデータストアが必要です。ビッグデータ時代黎明期においてはHDFSがその一翼を担い、データストアの定石アーキテクチャとして定着しました。 しかし、Amazon S3に代表される、いわゆるクラウド・ストレージの台頭により、HDFSは唯一の選択肢ではなくなりつつあることもまた事実です。 かつて、データマネージメント市場において、HDFSを中心にあらゆるエコシステムが急速に形成されたように、今やクラウド・ストレージとのインターフェースを持たないデータ処理エンジンは皆無と言える状況です。 一昔前まで、この技術分野ではリレーショナル・データベースを中心にシステムを構成するアーキテクチャが一般的でした。オンライントランザクション処理のオペレーショナルデータベースからオンライン分析処理のデータウェアハウスへ、バッチによるETL処理を経由しデータを渡しつつ、他システムとはメッセージキューやEAIで連携、という具合です。 残念ながらこの旧式の仕組みでは、あらゆるタイプの大容量データをリアルタイムに処理できるスケーラブルでフォルトトレラントなシステムを安価に実現することはできません。 これらの課題を背景に、Apache Kafka(※)は開発され、そのメリットに一早く着目した先進的なエンジニアにより、特にクラウド上の現代的なアーキテクチャとして定着しつつあります。 とりわけ、「Apache Kafkaでストリームデータを受け、Amazon S3に永続化」というデータの貯め方が定石手法として見られわけですが、これは当然Oracle Cloud Infrastructureのオブジェクトストレージでも可能です。本記事では、その具体的な設定例と実際にストリームを永続化するところまでを取り上げてみたいと思います。 本記事で永続化したデータをApache Sparkから利用する方法を、続編「Apache Sparkからオブジェクトストレージのデータを使う」に纏めましたので併せてご参照ください。 ※「Apache Kafkaは、Apache Software Foundationの登録商標または商標です。」     Step 1 : バケットを作成し、S3互換APIキーで接続できるようにします Kafkaで受けたメッセージをオブジェクトストレージに保存するためのバケットを作成します。 Cloud Consoleの左上メニューから「オブジェクト・ストレージ」>「オブジェクト・ストレージ」と辿り、「スコープ」から任意のコンパートメントを選択し、「バケットの作成」ボタンをクリックします。バケットの名前を入力し、「バケットの作成」ボタンをクリックすれば完了です。詳細手順は「バケットの管理」の「バケットを作成するには」を参照。 バケットを配置するコンパートメントには、S3互換APIキーを使用して接続するための設定を実施しておく必要があります。 Cloud Console右上の「プロファイル」から「テナンシ」を選択、「オブジェクト・ストレージ設定の編集」ボタンをクリック、「AMAZON S3互換APIで指定されたコンパートメント」のプルダウンメニューからバケットを作成したコンパートメントを選択し、保存すれば完了です。詳細手順は「Amazon S3互換性およびSwift API用のコンパートメントの指定」の「指定されたコンパートメントの表示と指定」をご参照ください。 次に、オブジェクトストレージに接続するためのS3互換APIキーを作成します。S3同様、ここで作成する秘密キーとアクセスキーを使った認証によってKafkaがオブジェクトストレージにアクセスできるようになります。 OCIコンソールにログイン後、「左上メニュー>」「アイデンティティ」>「ユーザー」と辿り、任意のユーザーをクリックし「ユーザーの詳細」画面へ移動、「リソース」の「顧客秘密キー」をクリック、「秘密キーの生成」ボタンをクリックし、この設定に名前をつけます。詳細手順は「顧客秘密キーを作成するには」をご参照。 「秘密キーの生成」ボタンを押すと秘密キーが表示されます。秘密キーは一度しか表示されませんので、作成した段階で、確実にコピーして一旦保存することをお勧めします。 これで秘密キーとアクセスキーのペアが作成されました。 ここで作成したアクセスキーと秘密キーをコピーし、環境変数としてexportします。もちろん.bash_profileなどを使われてもOKです。 $ export AWS_ACCESS_KEY_ID=xxxxxxxxxxxxxxxxxxxxxxxxx $ export AWS_SECRET_ACCESS_KEY=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx     Step 2 : Confluentのインストールと起動 今回はApache Kafkaの商用パッケージを開発されているConfluent社のバイナリを使ってみたいと思います。 Confluent社のサイトからバイナリをダウンロードし解凍するとディレクトリが作成され、同ディレクトリ配下のbinディレクトリにコマンド群があります。 $ ls -F bin/ etc/ ksql_logs/ lib/ README share/ src/ $ cd bin 今回はテストなのでfirewalldを止めておきます。 $ sudo systemctl stop firewalld Zookeeper/Kafka/Kafka Connectを起動します。 $ bin/confluent start connect This CLI is intended for development only, not for production https://docs.confluent.io/current/cli/index.html Using CONFLUENT_CURRENT: /tmp/confluent.Wq84QztF Starting zookeeper zookeeper is [UP] Starting kafka kafka is [UP] Starting schema-registry schema-registry is [UP] Starting connect connect is [UP] これで必要なサービスが起動しました。     Step 3 : トピックを作成し、テストデータを取り込みます まずはトピックを作成します。 $ bin/kafka-topics --zookeeper localhost:2181 --create --topic test-topic --replication-factor 1 --partitions 5 Created topic test-topic. 作成したトピックを確認します。 $ bin/kafka-topics --zookeeper localhost:2181 --list 作成したトピックtest-topicにサンプルのメッセージを取り込みます。 $ curl -s http://stream.meetup.com/2/rsvps | bin/confluent produce test-topic This CLI is intended for development only, not for production https://docs.confluent.io/current/cli/index.html Kafkaで受けているメッセージの内容を確認してみます。 $ bin/confluent consume test-topic -- --from-beginning This CLI is intended for development only, not for production https://docs.confluent.io/current/cli/index.html {"venue":{"venue_name":"Sainsburys","lon":-0.108527,"lat":51.517307,"venue_id":24421151},"visibility":"public","response":"yes","guests":0,"member":{"member_id":14619028,"photo":"……………(略)     Step 4 : オブジェクトストレージにメッセージを永続化します まず、設定ファイルを作成し任意の場所に保存します。この例ではinjest-to-oci.jsonというファイル名で作成しましています。この設定ファイルの内容によって、オブジェクトストレージにストリームデータが永続化される際の挙動が決まります。 { "name": "injest-to-oci", "config": { "_comment": "The S3 sink connector class", "connector.class":"io.confluent.connect.s3.S3SinkConnector", "_comment": "The total number of Connect tasks to spawn (with implicit upper limit the number of topic-partitions)", "tasks.max":"1", "_comment": "Which topics to export to S3", "topics":"test-topic", "_comment": "The S3 bucket that will be used by this connector instance", "s3.bucket.name":"kafka-bucket", "_comment": "The AWS region where the S3 bucket is located", "s3.region":"us-ashburn-1", "_comment": "The REST endpoint of the OCI Object Storage Service", "store.url": "https://ksonoda.compat.objectstorage.us-ashburn-1.oraclecloud.com", "_comment": "The size in bytes of a single part in a multipart upload. The last part is of s3.part.size bytes or less. This property does not affect the total size of an S3 object uploaded by the S3 connector", "s3.part.size":"5242880", "_comment": "The maximum number of Kafka records contained in a single S3 object. Here a high value to allow for time-based partition to take precedence", "flush.size":"100000", "_comment": "Kafka Connect converter used to deserialize keys (unused in this example)", "key.converter":"org.apache.kafka.connect.json.JsonConverter", "key.converter.schemas.enable":"false", "_comment": "Kafka Connect converter used to deserialize values", "value.converter":"org.apache.kafka.connect.json.JsonConverter", "value.converter.schemas.enable":"false", "_comment": "The type of storage for this storage cloud connector", "storage.class":"io.confluent.connect.s3.storage.S3Storage", "_comment": "The storage format of the objects uploaded to S3", "format.class":"io.confluent.connect.s3.format.json.JsonFormat", "_comment": "Schema compatibility mode between records with schemas (Useful when used with schema-based converters. Unused in this example, listed for completeness)", "schema.compatibility":"NONE", "_comment": "The class used to partition records in objects to S3. Here, partitioning based on time is used.", "partitioner.class":"io.confluent.connect.storage.partitioner.TimeBasedPartitioner", "_comment": "The locale used by the time-based partitioner to encode the date string", "locale":"en", "_comment": "Setting the timezone of the timestamps is also required by the time-based partitioner", "timezone":"UTC", "_comment": "The date-based part of the S3 object key", "path.format":"'date'=YYYY-MM-dd/'hour'=HH", "_comment": "The duration that aligns with the path format defined above", "partition.duration.ms":"3600000", "_comment": "The interval between timestamps that is sufficient to upload a new object to S3. Here a small interval of 1min for better visualization during the demo", "rotate.interval.ms":"60000", "_comment": "The class to use to derive the timestamp for each record. Here Kafka record timestamps are used", "timestamp.extractor":"Record" } } 各項目が何を意味するのかはコメント欄を見ていただくとだいたいわかると思いますが、下記4つの重要項目だけ補足で説明します。 作成済みのバケット名を記載します。ここでは先のステップで作成したkafka-bucketという名前を入力しています。 "_comment": "The S3 bucket that will be used by this connector instance", "s3.bucket.name":"kafka-bucket", バケットを作成したリージョン名を記載します。当たり前ですがS3とは表記が異なります。リージョン表記一覧はこちら。 "_comment": "The AWS region where the S3 bucket is located", "s3.region":"us-ashburn-1", OCIオブジェクトストレージのエンドポイントを記載します。[]の部分をご自分の環境に合わせて編集する必要があります。 "_comment": "The REST endpoint of the OCI Object Storage Service", "store.url": "https://[tenant_name].compat.objectstorage.[region].oraclecloud.com", 例えば、契約したテナント名が「ksonoda」、利用するリージョンがAshburnであれば下記のようになります。 このパラメータはS3互換のオブジェクトストレージサービスを利用する場合に必要な設定です。 "store.url": "https://ksonoda.compat.objectstorage.us-ashburn-1.oraclecloud.com", 以上が設定ファイルの説明です。 この設定ファイルを使って、下記コマンドでKafkaに取り込まれたメッセージを、オブジェクトストレージに永続化します。 $ bin/confluent load injest-to-oci -d ./injest-to-oci.json This CLI is intended for development only, not for production https://docs.confluent.io/current/cli/index.html これで、メッセージがオブジェクト・ストレージに永続化されました。オブジェクトストレージのバケットの中をのぞいてみるとメッセージがオブジェクトとして永続化されていることがわかりす。   以上、本記事では、データ分析基盤システムにおいてエッジで生成されるデータをKafkaで受け取り、オブジェクトストレージに永続化する部分の設定例を取り上げてみました。 この設定例は単一のインスタンス上に構築した非常に簡単なものです。もっと本格的な構成で検証してみたいけどOracle Cloudは使ったことがないなぁという方は Oracle が githubで提供している下記terraformスクリプトを使ってみてください。非常に簡単に構築できますよ。 Confluent構築のterraformスクリプト Confluent構築のterraformスクリプト(kubernetes版)   ※本記事の続編「Apache Sparkからオブジェクトストレージのデータを使う」も併せてご参照ください。 続編では、本記事でオブジェクトストレージに永続化したjsonファイルをSparkから読み込み、簡単なデータ操作実行後、オブジェクトストレージへ書き戻す処理について概説しています。   参考資料 From Apache Kafka to Amazon S3: Exactly Once Kafka Connect Amazon S3 Sink Connector Using Non-AWS Storage Providers

はじめに 今日のデータ分析基盤では大規模なデータを安価に保持できるデータストアが必要です。ビッグデータ時代黎明期においてはHDFSがその一翼を担い、データストアの定石アーキテクチャとして定着しました。 しかし、Amazon S3に代表される、いわゆるクラウド・ストレージの台頭により、HDFSは唯一の選択肢ではなくなりつつあることもまた事実です。 かつて、データマネージメント市場において、HDFSを中心に...

GraphPipeとは

GraphPipeとは、Oracleがオープンソースとして公開する、機械学習およびディープラーニングのモデルのデプロイを単純化し標準化するツールです。 https://oracle.github.io/graphpipe/#/ 2019/5/17 に、Oracle Code Tokyo 2019 にて、GraphPipeについてご紹介しました。 「GraphPipe and TensorFlow, Serverless and Neural Networks with Fn Project」 関連情報は、こちらより参照いただけます。 ABeam Consulting Ltd. 澤田 哲史 様 と共同登壇させていただきました。 ABeam Consulting Ltd. 澤田 哲史 様  Blog  https://www.scpepper.tokyo/ github https://github.com/scpepper69 日本オラクル 河内 美樹 github (デモ内容) https://github.com/miiki/graphpipe_classy-func 当日資料 https://speakerdeck.com/miiki/graphpipe-and-tensorflow-serverless-and-neural-networks-with-fn-project   澤田様の当日のスライドは公式サイトからダウンロードいただけます。 https://www.oracle.co.jp/campaign/code/2019/ ページ内を「B-4-4」で検索し、「資料ダウンロード」リンクからどうぞ。(念の為、資料への直リンク) ぜひ触ってみてください~!

GraphPipeとは、Oracleがオープンソースとして公開する、機械学習およびディープラーニングのモデルのデプロイを単純化し標準化するツールです。 https://oracle.github.io/graphpipe/#/ 2019/5/17 に、Oracle Code Tokyo 2019 にて、GraphPipeについてご紹介しました。「GraphPipe and TensorFlow,...

Oracle GoldenGateが、Microsoft社 SQL Server 2017対応機能強化と Microsoft Azure SQL Database への接続(ターゲット)をサポートしました

※本投稿は、Oracle GoldenGate for SQL Server supports SQL Server 2017 and Delivery to Microsoft Azure SQL Database を元に翻訳した投稿です。 Oracle GoldenGateのProduct Managementチームは、Oracle GoldenGate 12.3 for SQL Server が SQL Server 2017 Enterprise Edition からのキャプチャおよび配信をサポートする新しい機能を追加しました。またMicrosoftのAzure SQL Databaseへの配信に関するCertifyを完了したことを発表しました。 SQL Server 2017 御客様は、support.oracle.comのPatches&Updates から、SQL Server用Oracle GoldenGate(CDC Extract)のパッチリリース12.3.0.1.181228を入手・導入することで、SQL Server 2017 Enterprise Edition への接続が可能となります。   Azure SQL Database また、上記SQL Server 2017のサポートと同じパッチリリースを使用して、Azure SQL Databaseへのリモート配信もサポートされるようになりました。サポートされているWindows server(Certification Matrixを参照)に Oracle GoldenGate パッチをインストールし、Azure SQL DatabaseへのRemote Replicatを構成できます。 Documentation 詳細は、Oracle GoldenGateのドキュメントおよびクイックスタートチュートリアルを参照してください。: https://apexapps.oracle.com/pls/apex/f?p=44785:24:578025582835::NO:24:P24_CONTENT_ID,P24_PREV_PAGE:21869,1  

※本投稿は、Oracle GoldenGate for SQL Server supports SQL Server 2017 and Delivery to Microsoft Azure SQL Database を元に翻訳した投稿です。 Oracle GoldenGateのProduct Managementチームは、Oracle GoldenGate 12.3 for SQL Server...

Big Data and Data Integration - Japan

クラウドでリアルタイムデータをキャプチャして分析

※本投稿は、Capture and Analyze Real-Time Data in the Cloud を元に翻訳した投稿です。 ビジネスイベントが発生したときにそれを理解して対応することは、これまで以上に重要です。 顧客行動、詐欺行為、およびマーケティング機会の変化は、数時間、数日、数週間後ではなく、発生した瞬間に対処する必要があります。 多くの企業がこの必要性を認識し、企業内の異なるグループによる消費のためにリアルタイムのビジネスイベントを提供するためのストリーミングバックボーンを開発しました。 主に2つの課題があります。どのようにしてビジネスアプリケーションからストリーミングデータを取得するかと、その結果得られるストリーミングデータをビジネス上の洞察と決定にどのように変換するかです。多くの組織ではストリーミングイベントを作成するためにトランザクションデータベースからのレプリケーションと変更データキャプチャを使用しています。このアプローチは、ストリームパブリッシングコードを使用してアプリケーションを直接手動で組み込むよりも明らかな利点があります。非侵襲的で労力がかからず、アプリケーションオーナーにとってリスクが低く、すべての障害シナリオでデータベースとストリームのデータが一致する信頼性があります。Oracle GoldenGateはトランザクションレプリケーションのマーケットリーダーであり、さまざまなデータベースベンダーからのデータを他のデータベース、またはApache Kafkaなどのビッグデータおよびストリーミング環境にレプリケートするための広範な接続オプションを提供します。Oracle Data Integration Platform Cloud(DIPC)は、この機能をOracle Cloud Infrastructureのサービスとして提供します。ストリーミングデータの処理と分析、および自動化された意思決定の推進のために、オラクルはOracle Stream Analytics(OSA)に豊富な対話型ユーザー・インタフェースとApache Sparkに基づくスケーラブルなランタイムを提供します。 Oracle OpenWorld 2018では、ハンズオンラボ「Oracle Data Integration Platformクラウドを使用したOracle GoldenGateストリームの分析」の一環として、リアルタイムデータの取得と分析を行うエンドツーエンドのユースケースを紹介しました。 ユースケースは、顧客の動向や購買履歴に基づいてリアルタイムのマーケティング機会に対応することです。 ラボでは、プログラミングや低レベルの設定を行わずに、これを簡単なユーザーインターフェイスで設定する方法を示します。 ラボでは、Spark用のOracle Big Data Cloud環境とKafkaストリーミング用のOracle Event Hubも使用しています。 最初のステップは、DIPCコンソールを開いてレプリケーションランタイムを管理するDIPCエージェントを起動することです。 エージェントはクラウドまたはオンプレミスにデプロイできるため、任意の場所でレプリケーションを実行できます。 次のステップで、ユーザーはソースデータベースとターゲットKafka環境との接続を設定できます。 DIPCは、ソースデータベースからメタデータとプロファイリング情報を自動的に収集して、ユーザーに詳細なスキーマ情報を提供します。 ユーザーはグラフィカルデザイナーを使用してレプリケーションを設計し、どのスキーマとテーブルがプロセスに参加するべきかの詳細を選択し、Kafkaにイベントを提供することができます。 レプリケーションの進行状況は、タスク監視ページで監視および制御できます。 ユーザーは、イベント数、エラー、データの遅れ、およびその他の重要な要因に関する統計を確認できます。 データがKafkaに複製されると、ユーザーはStream Analyticsユーザーインターフェースにアクセスしてイベントの分析を開始できます。 ユーザーは、データベースの変更内容を含むKafkaトピックに基づいてパイプラインを作成します。 パイプラインは着信イベントからのデータを表示し、ユーザーがデータストリームを対話的に処理し分析することを可能にします。 ユーザーは、イベントを段階的に強化および変換する処理ステップを追加し続けます。 2番目のステップは、データベースからの追加の顧客データでイベントデータを充実させることです。 3番目のステップでは、ジオフェンスに基づいてイベントをフィルタリングするためのパターンを追加します。 ジオフェンスは事前定義済みの領域です。この場合、顧客へのオファーをトリガーする小売場所です。 ユーザーは、ユーザーインターフェイスでジオフェンスに関連して個々の顧客の場所を確認できます。 フィルタリングの後、ユーザーは製品のスコアリングステップを通じて機械学習モデルを適用するなど、さらに処理を追加することができます。 最後に、オファーを受け取る必要がある顧客との処理済みイベントをターゲット・ストリームに格納して、顧客との通信を開始することができます。 要約すると、ハンズオンラボでは、データベースの変更から複雑なリアルタイム分析ソリューションに移行して、ビジネスがリスクと機会に即座に対応できるようになることを60分以内で実現できることがわかりました。 詳細は、Oracle Stream Analytics、Oracle Data Integration Platform Cloud、およびOracle GoldenGateを参照してください。

※本投稿は、Capture and Analyze Real-Time Data in the Cloud を元に翻訳した投稿です。 ビジネスイベントが発生したときにそれを理解して対応することは、これまで以上に重要です。 顧客行動、詐欺行為、およびマーケティング機会の変化は、数時間、数日、数週間後ではなく、発生した瞬間に対処する必要があります。 多くの企業がこの必要性を認識し、企業内の異なるグループに...

Big Data and Data Integration - Japan

Data Integration Platform Cloud (DIPC) 18.4.3 リリース

※本投稿は、Data Integration Platform Cloud (DIPC) 18.4.3 is Now Available を元に翻訳した投稿です。 Data Integration Platform Cloud (DIPC) 18.4.3 がリリースされました。 DIPCを御存知無い方はこちらの「紹介ビデオ(2分)」をご覧下さい! Data Integration Platform Cloud(DIPC)は、さまざまなベストオブブリードなデータ統合ソリューションがどのように連携してシームレスに機能し、機能の相乗効果を見つけ、より小さな断片的なタスクやプロジェクトをソリューションベースのアプローチへ高めるかをあらためて想像したものです。 たとえば、DIPCでは「Elevated Tasks」と「Atomic Tasks」の概念が導入されています。 後者のAtomic Tasksは、より小さなデータ要件とロジックを達成するために使用されるポイントタスクと同等です。一方、前者のElevated Tasksは、頻繁にまとまる最終目標指向(データレイクの構築、データの準備など)からなります。 技術的な要件を単純で論理的なタスクグループにまとめました。 DIPC 18.4.3の新機能をいくつかみていきましょう。 今回のリリースで大幅に強化されたのは、高速パフォーマンスを提供するOracleの使いやすい完全自律型データベースであるAutonomous Data Warehouse(ADW)のサポートの追加です。 これで、ADWへの接続を作成し、Elevated Tasksで使用できるメタデータを取得できます。 最近のブログ記事で、Data Lake Builder Task について説明しました。 このタスクは、データレイクの自動化を支援し、直観的なインスタンス化とデータレイクへのデータのコピーを可能にします。これにより、既存のデータエンジニアとデータサイエンティストの間の摩擦が軽減されます。 データレイクへの包括的なエンドツーエンドの反復可能なデータパイプラインを迅速に作成できます。 Data Lakeへのデータの追加タスクは、ターゲットとしてAutonomous Data Warehouseをサポートするようになり、Amazon S3からも取り込むことができます。 さらに、タスク実行はリモートエージェントを通じてサポートされています。 Replicate Data Task には、AvroおよびSubタイプの高度なKafkaサポートが含まれています。 ユーザーエクスペリエンスは、将来的にさまざまなレプリケーションパターンをサポートするように強化されました。 タスク内のデータを暗号化することもできます。 ODI Execution Task では、Autonomous Data Warehouse(ADW)およびOracle Object Storageのサポートが追加され、ユーザーはADWに一括ロードし、ETL / ELTワークロードを実行してデータを変換できます。 また、DIPC Scheduling が提供されたことにより、ジョブを実行するためのスケジューリングポリシーを作成できます。加えて、異種サポートが拡張され、GoldenGate for SQL Serverが DIPC Agent を通じて利用できるようになりました。 タスクを作成して実行する方法については、このドキュメントページを参照してください。

※本投稿は、Data Integration Platform Cloud (DIPC) 18.4.3 is Now Available を元に翻訳した投稿です。 Data Integration Platform Cloud (DIPC) 18.4.3 がリリースされました。 DIPCを御存知無い方はこちらの「紹介ビデオ(2分)」をご覧下さい! Data Integration...

Oracle Data Minerハンズオン:GLMでの分析

このハンズオンでは、顧客の性別を予測する上で最も重要な顧客属性を分類の学習アルゴリズムで分析します。 分類モデルではGLM(一般化線形モデル)を利用します。またGLMの拡張機能(機能選択および機能生成)を使用する方法についても説明します。 機能選択は、最も意味のある属性を選択するプロセスです。機能の選択により、より小さいモデルとより速いスコアリングに導く、より少ない予測子でGLMモデルを作成することができます。 機能生成は、属性を新しい機能に結合するプロセスです。機能生成では、GLMは非線形項(最大3次項)を使用し、透明性を向上し、より強力なモデルを作成できます。 Oracle Data Minerハンズオン「GLMの機能選択と機能生成」 ハンズオン概要 顧客情報と販売情報データが、データベース上のテーブルに格納されている 上記テーブルのデータに対して、教師あり学習(分類モデルによるモデル構築)を行う 分類モデルでは、GLM(リッジ回帰、機能選択、機能の生成)アルゴリズムを使用 完成したモデルの結果確認と比較 インストールや接続設定は、前回の内容をご参照ください。  

このハンズオンでは、顧客の性別を予測する上で最も重要な顧客属性を分類の学習アルゴリズムで分析します。 分類モデルではGLM(一般化線形モデル)を利用します。またGLMの拡張機能(機能選択および機能生成)を使用する方法についても説明します。 機能選択は、最も意味のある属性を選択するプロセスです。機能の選択により、より小さいモデルとより速いスコアリングに導く、より少ない予測子でGLMモデルを作成することが...

Big Data and Data Integration - Japan

【Oracle Cloud Advent Calendar 2018連動企画】Oracle Analytics Cloudで機械学習コンペしてみた

早いもので今年も12月になってしまいました。 今回は、いつものブログと少し趣を変えまして、Oracle Cloud Advent Calendar 2018との連動企画として少し砕けた感じで執筆します。 さて、テーマですが、前回紹介したOracle Analytics Cloud(OAC)を使った機械学習にしようと思い、オラクルお馴染みのInsuranceデモを準備していたのですが、Cloudii様のブログでOACによるタイタニック生存予測の記事を見つけまして、勝手にコンペしてみよう企画にします。 題材は、同じkaggleのTitanic。目標精度は73%以上を目指します。 【Cloudii様の記事一部抜粋】   1.データの理解 さて、何はともあれまずは「データの理解」から始めたいと思います。 今回のデータセットは、タイタニック号に搭乗された方がどのような属性であったかを表しているデータになります。 PassengerId – 乗客識別ユニークID Survived – 生存フラグ(0=死亡、1=生存) Pclass – チケットクラス Name – 乗客の名前 Sex – 性別(male=男性、female=女性) Age – 年齢 SibSp – タイタニックに同乗している兄弟/配偶者の数 parch – タイタニックに同乗している親/子供の数 ticket – チケット番号 fare – 料金 cabin – 客室番号 Embarked – 出港地(タイタニックへ乗った港) TrainデータとtestデータをデータセットとしてOACにアップロードした後、目的変数である「Survived」がどのような項目であるか確認します。 Survivedを右クリックして「Suvrivedの説明」をクリックすると、OACが基礎情報を教えてくれます。 Trainデータには、891件あり約4割が生存(1)していることがわかります。 キードライバを確認すると、Survivedに相関が強い項目は性別やチケットクラス、出港地、同乗者数などのようです。 何も考えずに、これらの項目を説明変数としてRandomForrestでモデルを作成したところ74%の精度がでました。(目標達成!) と、ここでこのブログを終わらせるのも忍びないので、精度向上のために少し工夫をしていきたいと思います。 2.データの準備 データを眺めていると、AgeやCabinなどは使えそうではあるものの欠損値があるためにNull埋めしてあげる必要がありそうです。 また、性別が強い相関を示していたため、特徴量を増やすために名前から敬称(Mr. Mrs. Missなど)を抽出すれば使えそうな気がします。 さらに、同乗者数がSibSPとparchに別れているため、これらを合算した項目なども良いのではと推察します。 このような、分析前の前処理部分をデータフローで作成していきます。 ・敬称(Honorific)の抽出 グループ化機能を利用して、Nameに含まれる敬称別に分類します。 ・Ageのnull埋め 列の追加でCase文を利用し敬称毎の平均年齢で補完しました。 ・家族人数の算出 これも同様に列の追加で、単純に足し算しています。 ・Fareのビン化 料金はそのまま使うと計算量が多くなりそうなので、ビン化機能で4つの区分に分けます。グラフ見ながらビン数変えたり、手動で位置を変えれたりするのでかなり便利な機能ですね。 ・チケット番号やキャビン番号からのグループ抽出 チケット番号を眺めていると349905とか347742とか、左2桁で共通項がありそうだったので、そこを抽出します。 キャビンも同じようにしました。(nullが多いのであまり意味はなさそう) ALONEは、家族人数が0であればばフラグを立てるようにしています。(一人だけで乗船している方が助かっている確率が高い) ・データセットの保存と実行 別の名前でデータセットを保存し「データフロー」の実行をクリックすると、データの準備が完了です。 忘れないようにtestデータにも同じ処理を行ってあげます。 3.モデルの作成 いよいよモデルを作成していきます。ここでもデータフロー機能を利用します。 まずは、学習に使う項目だけ「列の選択」で選びます。 ・アルゴリズムを選択  Random Forrestを選択しTargetに「Survived」Positive Case に「1」を入力します。 ・モデルの保存と実行 モデル名を入力しデータフローを実行することで、モデルが作成されます。 4.スコアリング ・モデルの適用 同じくデータフローで、testデータを呼び出し「モデルの適用」を選択します。 「モデル」欄で先ほど作成したモデル名を選択し、出力項目PredictedValue(予測値)を「Survived」という項目で出力するように設定します。 ・提出用フォーマットに整形 Kaggleで答え合わせ出来るようにPassengerIdとSurvivedだけにします。     ・データセットに保存&実行 保存する名前を入力しデータフローを実行することでテストデータにモデルが適用され予測値が付加されたデータセットが完成します。     5.答え合わせ OACからデータをダウンロードし、Kaggleに提出します。 ちなみに落としたデータの雰囲気。     気になる結果は。。。。 78.4% よかった。。。一応目標達成です。   ・感想 もう少し粘って80%を目指したかったのですが、今回は時間切れなのでここまで。 さらなる工夫の余地としては、年齢やキャビンのnull埋めを予測モデル作って行ったり、アルゴリズムのパラメータチューニングなどが考えられます。 Python書ける人から見るとOACを使った機械学習は少しまどろっこしく見えるかもしれません。しかし、セルフサービスBIツールであるDVだからこそ、データの会話という意味ではスクリプトより効率が良いと思いました。今回の作業もExcel操作できる方であれば、2時間程度で行えるものです。データ分析の民主化という意味では、非常に有効なツールと言えるのではないでしょうか。 それでは、良いクリスマスをっ!

早いもので今年も12月になってしまいました。 今回は、いつものブログと少し趣を変えまして、Oracle Cloud Advent Calendar 2018との連動企画として少し砕けた感じで執筆します。 さて、テーマですが、前回紹介したOracle Analytics Cloud(OAC)を使った機械学習にしようと思い、オラクルお馴染みのInsuranceデモを準備していたのですが、Cloudii様...

Big Data Management

Oracle Data Minerを使って機械学習をはじめよう

Oracle Data MinerはOracle Databaseに内包されたIn-Database Analyticsのためのエンジンで、GUI操作でデータの分析・機械学習を行うことができます。 今日は、Oracle Data Minerの一連の操作を実行できる、ハンズオン資料をご紹介します。   Oracle Data Minerが利用できる環境 Oracle Data Minerは、Oracle Cloud環境のPaaSデータベース(DBaaSインスタンス)では、High PerformanceまたはExtreme Performanceに含まれています。 オンプレミス環境のデータベースではEnterprise EditionのAdvanced Analytics Optionに含まれています。 Oracle Data Minerをはじめよう データベースの準備 ここでは、Oracle Cloud環境のPaaSデータベース(DBaaSインスタンス)を例として挙げています。 サンプルスキーマのインストール データベースを準備し、サンプル・スキーマをインストールします。サンプル・スキーマのインストール方法が不明な場合は、こちらもご参照ください。 Data Minerを実行するユーザを作成 create user <username> ...; で、Data Miner用のDBユーザを作成します。 SQL Developerのダウンロードと接続 OTNからOracle SQL Developerをダウンロードします。 以下の資料に従い、先程作成したDBユーザで接続します。 Oracle Data Miner ハンズオン 準備:SQL Developerから接続 Oracle Data Minerで機械学習 顧客の様々な属性情報から保険商品を購入してくれそうかどうかを予測するモデルを、機械学習によって作成します。以下の資料に従って実施します。 Oracle Data Miner ハンズオン 「分類モデルによる予測」 ハンズオン概要 顧客情報データ(年齢、職業、車を持っているかどうか等の様々な属性情報を持つ、かつ、保険を購入したかどうかのフラグ列を持つ)が、データベース上のテーブルに格納されている 上記テーブルのデータに対して、教師あり学習(分類モデルによるモデル構築)を行う 分類モデルでは、決定木、GLM、SVM、ナイーブ・ベイズアルゴリズムを使用する 完成したモデルを、新規データに対して適用する これらの操作が全てGUI操作にて実施 ハンズオンでは、接続したユーザがもつ実テーブルに対して機械学習を行いました。対象データはそのユーザから参照できればOKなので、他のユーザが持つテーブルのデータも、SELECT権限があればもちろん利用できます。 更に言えば、Oracle Databaseには、外部表(External Table)という便利な機能があります。参照できればOK(大事なことなので2回言いました?!)ということは、「外部表を利用してOS上のファイル」や、今まで本BLOGでもご紹介してきた「外部表+Big Data SQL によってHadoop上のデータ」に対しても、Oracle Data Minerを使って機械学習を実行することができます。 Oracle Cloudでは、無料ではじめられるトライアル環境がありますので、ぜひご利用ください。 ※本資料の動作確認は、Oracle Database 18.2 (18.0.0) High Performance と、SQL Developer 18.3 で行いました。 追記: ハンズオン資料の第2弾を公開しています。続けて、ぜひお試しいただけると嬉しいです。 Oracle Data Minerハンズオン:GLMでの分析  

Oracle Data MinerはOracle Databaseに内包されたIn-Database Analyticsのためのエンジンで、GUI操作でデータの分析・機械学習を行うことができます。 今日は、Oracle Data Minerの一連の操作を実行できる、ハンズオン資料をご紹介します。   Oracle Data Minerが利用できる環境 Oracle Data Minerは、Oracle...

Big Data Management

データレイクにおける対話式クエリ

Data lakes(データレイク)は、今まで長年にわたり、ビッグデータ領域の重要な一員でした。 それは、あらゆる種類の新しいデータを取得・管理し、そのデータで新しいエキサイティングな潜在的なユースケースを提供します。詳細情報についてabout what a data lake is(データレイクは何か)とwebcast about building a data lake in the cloud(クラウドでデータレイクを構築するウェブキャスト)をご覧ください。 しかし、その最初の段落の重要なキーワードはおそらく「潜在的」かもしれません。 なぜならデータの価値を実現するために、あなたがまず新しいデータを理解し、対話的に探索する必要があります。その上に仮説を形成し、検証することも必要です。 データレイクに対する対話式クエリとは 大規模の対話式のデータレイククエリは簡単ではありません。 この記事では、すべてのデータを完全に活用するために克服する必要があるいくつかの問題を見ていきます。そのため、Oracle acquired SparklineData(オラクルはSparklineDataを買収し)、対話式のデータレイククエリに大規模で対応できるようになりました。 この記事の後半にもっと詳しく説明します。 Hadoopはデータレイクの標準的なプラットフォームでしたが、もともとは 対話式の作業ではなく、バッチ用に設計されました。 Apache Sparkは、最新の分散コンピューティングプラットフォームとして、対話式のクエリに対する新しいアプローチを提供し、MapReduceを使用するHadoopより10倍あるいは100倍の高速処理を持ちます。HDFSをOracle’s object storage(オラクルのオブジェクトストレージ)(AmazonはS3、MicrosoftはBlob Storage)に置き換えると、大規模の対話式のクエリを潜在的にサポートするmodern data lake(現代的データレイク)の基盤が得られます。 完全に機能するデータレイクを無料で構築しましょう 大規模データの対話式クエリの困難さ 例え現代的なデータレイクを持っていたとしても、データレイクの対話式クエリは非常に難しい問題が伴います。下記に、その課題となるポイントをあげます。 •パフォーマンス •事前集約 •スケールアウト •柔軟性 •ツールの選択 これらを順番に見てみましょう。 (パフォーマンス) 対話式のクエリには、高速なレスポンスが必要です。 ユーザーはワークシートやダッシュボードをナビゲートする際に快適に分析を行える必要があります。 しかし、多くのユーザーがデータレイクのデータセットに同時アクセスしようとすると、パフォーマンスが低下します。さらに、ファクトテーブルとディメンションテーブルを結合すると、追加のパフォーマンスボトルネックが発生する可能性があります。 多くのツールはインメモリ層の構築で問題の解決を図りますが、このアプローチだけでは十分でありません。 (事前集約) パフォーマンス問題に対処するもう1つの方法は、データレイクからデータを抽出して事前に集計することです。 多次元データの分析を容易にするため、OLAPキューブや分析データの絞り込み、およびマテリアライズド事前集計テーブルなどが実績ある手法として用いられてきました。 しかし、ここでは制限があります。この事前集計は、ダッシュボードやレポートをサポートしますが、アドホックのクエリの場合は対応が難しくなります。カギとなる情報はサマリされたデータの中には現れません。これは、デジタル写真を拡大し、不明瞭なピクセルを取得するようなものです。 あなたが望むのは、すべての生データにアクセスでき、必要なものを自由に拡大して見渡すことができることです。 Pre-aggregating data for deep analysis(ディープ・アナリシスのためのデータ事前集計)で詳細説明をご覧ください。 (スケールアウト) データはかなり大きくなる可能性があります。 そして、遅かれ早かれ、一度に1ギガバイトのデータではなく、テラバイトの分析を行う必要があるはずです。 このような規模への対応として、Sparkは分散コンピューティングエンジンを持ち、ネイティブに大規模処理で動作するように設計されているため、スケールアウト可能ですが、他の多くのツールはストレステストで失敗してきました。 (柔軟性) 正常にスケールアウトすることは課題の一部です。処理が完了した後にスケールバックする必要もあります。一言でいうと、柔軟な処理環境が必要です。例えば、最近実施したキャンペーンの分析または毎月のダッシュボードの更新の場合、新しいデータセットが突然使用される可能性があります。その作業負荷が時間とともに変化する特徴に対応するため、柔軟な環境は必要です。柔軟性は、modern data lake where compute and storage can scale independently(計算とストレージが独立で拡張できる現代データレイク)の機能の一部です。ただ、柔軟性はデータレイクを使用するツールたちが分散型のアーキテクチャを持つことも要求します。 (ツールの選択) 最後に、データを最大限に活用することは、個人や特定の組織だけの仕事ではありません。データサイエンティストやビジネスアナリストらの協力も必要であり、彼らはそれぞれ異なるツールを使用する要件もあります。ツールごとにデータを独自に準備することを避け、すべてのツールを同じデータに対応できることが必要です。 データレイクのクエリ問題を解決 2018年4月にオラクルはSparklineData社を買収しました。その代表的なツールであるSparkline SNAPはいくつの革新的なソリューションで上記の問題を解決できます。 パフォーマンス、スケーラビリティの課題に対し、Apache Sparkを使用してインメモリでスケールアウトを処理します。 テラバイトのデータセットでも1秒未満でクエリを実行完了できます。 完全に分散した計算エンジンアーキテクチャでインメモリインデックスを使用するため、データの事前集計や抽出は不要です。 オブジェクトストレージとSparkクラスタに基づいて動作するため、データレイクでの分析を柔軟に伸縮・縮小し処理します。 さまざまなユーザーが、自分のツールでデータにアクセスできます。例えばPythonやRを実行するノートブックZeppelinやJupiterなど、BIツールのTableau、Oracle Analytics Cloudなどです。言い換えると、自分のツールでSparkline SNAPインメモリ層に接続することができます。 オラクルは現在Sparkline SNAPをOracle’s own data lake and analytics solutions (Oracle独自のデータレイクと分析ソリューション)への統合を進めており、すみやかな市場への提供を計画しています。 対話型クエリの使用例 このようにデータレイクによる真の対話型クエリが実現された環境において、どのようなケースで、この技術を使うべきでしょうか? 多くのユースケースがありますが、ここでは3つについて考えてみましょう: 1.データ量予測が難しいIoTなどのケース マシンおよびクリックログなどのイベント/時系列のデータは、サイズと複雑さが急速に変化します。現代的なデータレイク基盤であっても、そのテラバイト以上のデータに対するアドホッククエリのパフォーマンスをBIツールで保証することは不可能です。Sparkline SNAPは、パフォーマンス向上のためにデータの移動や事前集計が不要で、直接データレイク上でその大規模なデータセットをストレスなく操作および分析することができます。 2.分析対象のデータソース数が多いケース 分析用データは、全てデータレイクに揃っていない可能性があります。 ERPだけではなく、様々なデータストアを横断的に分析することは非常に困難が伴います。個々のスキーマに最適化されているため、横断的なクエリには全体最適なスループットが得られないためです。もし、全てのデータをオブジェクトストレージに移動してSparkline SNAPでアクセス可能にした場合は、十分なアドホッククエリ性能を提供できます。データソースは単一でも、60種類のソースからでも分析できます。 3.BI分析用のデータマート作成が煩雑なケース 最後に、おそらく、あなたは今どうやって新しいインメモリBIツールで既存のクエリと事前集計結果にアクセスできるかを悩んでいるかもしれません。 Sparkline SNAPを使用することにより、データマート作成作業を省略して、あらゆるレベルの細かいライブデータを分析できます。したがって、データを準備する時間と労力を節約できるだけでなく、より良い分析を行うことができます。pre-aggregating data for deep analysis(ディープ・アナリシスのためのデータ事前集計)で詳細説明をご覧ください。 データレイクを使い始めたい場合、このguided trial(ガイド付きトライアル)を参照してください。ほんの数時間で、データを蓄積し、それを視覚化と機械学習できる環境が手に入ります。 本資料は、Oracle Big Data blog(https://blogs.oracle.com/bigdata/interactive-data-lake-queries-at-scale)を抄訳したものです。

Data lakes(データレイク)は、今まで長年にわたり、ビッグデータ領域の重要な一員でした。 それは、あらゆる種類の新しいデータを取得・管理し、そのデータで新しいエキサイティングな潜在的なユースケースを提供します。詳細情報についてabout what a data lake is(データレイクは何か)とwebcast about building a data lake in...

Big Data Management

最近、オラクルアナリティクスが話題らしいけど、今更聞けない人のための説明書き

エンタープライズBIとセルフサービスBI Business Intelligenceの概念が誕生してから、早いもので20年の月日が経とうとしています。 当初は、Business ObjectsやBrio、Cognosなどのツールが台頭し、デスクトップ版から始まり利用者の増加に対応するためWeb版へと進化してきました。 同時に性能やセキュリティなど様々な機能が拡充され、エンタープライズな領域でも利用できるツールとして発展してきました。 オラクルでもOracle Business Intelligence Enterprise Edition(BIEE)を提供し続けており、世界中で多くのお客様にご利用いただいています。 IT部門が、しっかりと管理をする「エンタープライズBI」の世界は、一定の成果を上げているものの、予め作成されたダッシュボードを確認し、ドリルダウンするといった 比較的、硬直的な利用が定着しました。それ以上の細かい作業を行う場合は、ダッシュボードからExcelにダウンロードして加工することがほとんどです。 しかしながら、データ分析の民主化が叫ばれる昨今、Excelでは生産性が悪いことから「セルフサービスBI」と呼ばれるツールが登場してきました。 代表的なツールとしてTableauやQlick、PowerBIなどがあげられます。オラクルでは、Oracle Data Visualization(DV)を提供しています。 分析者である業務ユーザー自身が、手持ちのデータやオープンデータを簡単にヴィジュアライゼーションできる機能がうけ、爆発的に部門単位で導入されています。 ところが昨今、自由を求める「セルフサービスBI」とガバナンスを求める「エンタープライズBI」のギャップが生じているお客様を多く見受けられます。 自由とガバナンスを両立させるOracle Analytics Cloud (OAC) IT部門と業務部門の力関係の都合もあり、業務部門が使いやすいセルフサービスBIを全社導入したが、結局うまくいかないケースがあります。 セルフサービスBIは、チャートの表現力や操作性などの機能要件には長けているものの、非機能要件ではセキュリティや性能などの問題があげられます。 例えばセキュリティでは、認証・認可機能の社内システムとの連携や、ロール別のアクセス制御、監査のためのロギングなど、性能面では、レポート上でデータ処理するのではなくDB側に処理をうまくオフロードする仕組みやクエリ最適化、同時接続のためのキャッシュ機構などが求められます。 逆にエンタープライズBIでは、中間層としてセマンティックレイヤと呼ばれる領域を持つことで、上記の非機能要件に対応できますが、それゆえに新しいデータソースを追加したい時はIT部門の作業が不可欠であり俊敏性に劣る事は事実です。機能要件的には、基本的な部分はセルフサービスBIが優位なものの、ドット単位で調整が必要な帳票機能や、フィルタリング条件の詳細なカスタマイズなど、ITリテラシが低い業務ユーザー向けの機能がエンタープライズBIでは強化されていたります。 そこで、この両者は共存関係にあることがベストプラクティスですが、管理面、とくにユーザの追加削除や、効率的なデータマネジメントという観点では2重管理となり、安易な導入はIT/業務双方に重荷となってしまいます。 オラクルでは、後発ながらもDVに継続的な投資を行っており他のセルフサービスBIとは一線を画すツールとなっています。 単純な操作性だけではなく、データ加工や機械学習が行えるデータフロー機能などを盛り込みつつ、エンタープライズBIであるBIEEと同一基盤で稼働させることもできるため、 両者の良いとこどりをしつつ、シンプルな管理面を実現しています。 それがOracle Analytics Cloud(OAC)です。   Data Visualizationの3つの特徴 (DV) 誰でも簡単に操作可能  セルフBIの必須項目といって良い操作性。誰でもお手軽に手元のExcelでもDBでも好きなところからデータを取得し、簡単に視覚化することができます。  操作性は好みと慣れによる部分が大きいですが、様々なBIツールを操作した経験がありますが、DVはかなり分かりやすいUIであると自負できます。  単純なドラッグ&ドロップ操作だけはなく、内蔵AIが値の意味解釈を教えてくれるため「データの理解」が圧倒的に早く進みます。 豊富な機能  チャートの種類やドリルダウン、Pythonの組み込みなど、機能を比較する上で様々な要素がありますが、DVがもつ最も便利な機能として「データフロー」があります。  集計や結合など、分析の8割は前処理だと言われていますが、その前処理部分までGUIで簡単に行えます。単純なレイアウト変換だけではなく、簡単な機械学習機能(分類や回帰等) も備わっているため、ビジネスユーザとデータサイエンティスト、データエンジニアとデータで会話する基盤として最適です。   全社規模で使える  本ブログの前半でも触れている通り、セルフサービスBI成功のポイントは、エンタープライズBIとの共存にあります。DVはエンタープライズBIであるBIEEのリポジトリ(エンタープライズ情報モデル)と共通化することにより、性能やセキュリティ要件など全社展開時に求められる要件に対応できます。  また、我々はオラクルであるが故に、クエリ性能には拘りをもっています。通常セルフサービスBIは、レポート内部に独自ファイル形式でデータを保持し操作を行います。これによってExcelデータの活用が可能になる反面、スケールアップもスケールアウトも望めないというデメリットがあります。そこで、DVでは「ライブモード」という機能を有しており、レポート内部にデータを保持せずに常にDB側にクエリが発行され負荷をDB側にオフロードする機能があります。例えば、弊社のAutonomous Data Warehouse Cloud(ADWC)と組み合わせることによりDBの知識のないお客様においても簡単に性能問題を改善することできます。 Oracle Cloudでは、フリーでOACをお試しできる環境を用意しております。 もし、ご興味ある方はこちらからトライアル環境を申し込みいただき、チュートリアルを実践してみてください。   ※参考情報 https://www.slideshare.net/oracle4engineer/201803201oracle-analytics  

エンタープライズBIとセルフサービスBI Business Intelligenceの概念が誕生してから、早いもので20年の月日が経とうとしています。 当初は、Business ObjectsやBrio、Cognosなどのツールが台頭し、デスクトップ版から始まり利用者の増加に対応するためWeb版へと進化してきました。同時に性能やセキュリティなど様々な機能が拡充され、エンタープライズな領域でも利用できる...

Big Data Management

Big Data SQL - Semi-structured data

以前の投稿で、Schema on ReadとSchema on Writeの長所短所について触れました。結論として、HDFSはデータをオリジナルフォーマットで置いておくのに適していることが分かりました。時折、ユーザはXMLやJSONのような半構造化データ(semi-structured data)を持ちます。今回は、それをどのように扱うかを紹介します。 半構造化データのユースケース HDFS上に半構造化データを格納する一般的なユースケースのひとつは、全てのオリジナルデータを格納し、そのうち部分的にリレーショナルデータベースに移動することです。これは日常的にはデータの一部が必要だが、その他の部分は極めて稀にアクセスされる(深い分析に必要になるかも知れない)ということかもしれません。例えば、以下のようなXMLフォーマットがあります。 ... ... ... ... ... 日常的には、リレーショナルデータベースで名前と年齢のみ必要: Name Age ---- ---- .... .... 他の列はごくまれにアクセスされます。この例では、HDFSはオリジナルデータを格納するのによいソリューションで、Big Data SQLはそれをデータベースからアクセスするのに良いツールのように見えます。そのことを例を使って説明しましょう。 Big Data SQLとXML Big Data SQLを使ってXMLデータにクエリを実行するために、HiveメタデータをOracle XQuery for Hadoopを使ってHiveメタデータを定義する必要があります。それから、Oracle Databaseで外部表を定義します。 ではデータとDDLの例を見ていきましょう。 例として、何らかのマシンデータを挙げます(スマートメーターのようなものを想定)。 81708374/04/2013 12:290.197000 81708374/04/2013 12:590.296000 81708374/04/2013 13:290.24000 81708374/04/2013 13:590.253000 81708374/04/2013 14:290.24000 これをHDFS上に置きます。 [Linux] $ hadoop fs -put source.xml hdfs://cluster-ns/user/hive/warehouse/xmldata/ 次にHiveメタデータの定義をします。 hive> CREATE EXTERNAL TABLE meter_counts( customer_key string, end_datetime string, general_supply_kwh float, off_peak_kwh int, gross_generation_kwh int, net_generation_kwh int) ROW FORMAT SERDE 'oracle.hadoop.xquery.hive.OXMLSerDe' STORED AS INPUTFORMAT 'oracle.hadoop.xquery.hive.OXMLInputFormat' OUTPUTFORMAT 'oracle.hadoop.xquery.hive.OXMLOutputFormat' LOCATION 'hdfs://cluster-ns/user/hive/warehouse/xmldata/' TBLPROPERTIES ( 'oxh-column.CUSTOMER_KEY'='./CUSTOMER_KEY', 'oxh-column.End_Datetime'='./End_Datetime', 'oxh-column.General_Supply_KWH'='./General_Supply_KWH', 'oxh-column.Gross_Generation_KWH'='./Gross_Generation_KWH', 'oxh-column.Net_Generation_KWH'='./Net_Generation_KWH', 'oxh-column.Off_Peak_KWH'='./Off_Peak_KWH', 'oxh-elements'='row'); XML表を作成するための情報は、Oracle XQuery for Hadoop (こちら)から参照できます。 次に、Oracle Databaseで、外部表としてHive表にリンクするよう定義します。 SQL> CREATE TABLE OXH_EXAMPLE ( CUSTOMER_KEY VARCHAR2(4000), END_DATETIME VARCHAR2(4000), GENERAL_SUPPLY_KWH BINARY_FLOAT, OFF_PEAK_KWH NUMBER, GROSS_GENERATION_KWH NUMBER, NET_GENERATION_KWH NUMBER ) ORGANIZATION EXTERNAL ( TYPE ORACLE_HIVE DEFAULT DIRECTORY DEFAULT_DIR ACCESS PARAMETERS (com.oracle.bigdata.tablename=default.meter_counts) ) REJECT LIMIT UNLIMITED PARALLEL; 完成です。XMLデータに対しクエリを実行する準備ができました。Oracle Database上で以下を実行します。 SQL> SELECT * FROM oxh_example WHERE ROWNUM <= 3; ...... 8170837 4/04/2013 12:29 0.196999997 0 0 0 8170837 4/04/2013 12:59 0.296000004 0 0 0 8170837 4/04/2013 13:29 0.239999995 0 0 0 素晴らしい。XMLデータをデータベースの中で構造化して見えるようになりました。 Big Data SQLでもう1点素晴らしいのは、パースと処理の一部がHadoop側にプッシュダウンされることです。 例えば次のクエリを実行します。 SQL> SELECT COUNT(1) FROM oxh_example WHERE customer_key='8170837'; このクエリはHadoopにプッシュされ、データベースリソースを使用しません。Enterprise Managerからは”cell external table smart scan” イベントだけが確認できます。 Cloudera Managerからは3つのHadoopノードが使用されていることが分かります。同時刻にデータベースノードはIdle状態です。 以下の統計は、100GBのうち8KBだけがデータベース側に送られてきたことを示します(残りはCell側(=Hadoop側)でフィルターされています)。 SQL> SELECT n.name, VALUE FROM v$mystat s, v$statname n WHERE s.statistic# = n.statistic# AND n.name LIKE '%XT%'; ... cell interconnect bytes returned by XT smart scan 8192 Bytes cell XT granule bytes requested for predicate offload 115035953517 Bytes Big Data SQLとJSON 半構造化データでもう一つ有名なものはJSON形式です。Oracle Databaseはここにも良い意味で驚きがあります。Oracle Database の バージョン12cから、JSONデータに対しとても便利でフレキシブルなAPIが利用できます(データベース内の表でもデータベースの外(=外部表)であっても)。紹介しましょう。 例として、以下の入力データを使用します。 {wr_returned_date_sk:37890,wr_returned_time_sk:8001,wr_item_sk:107856,wr_refunded_customer_sk:5528377,wr_refunded_cdemo_sk:172813,wr_refunded_hdemo_sk:3391,wr_refunded_addr_sk:2919542,wr_returning_customer_sk:5528377,wr_returning_cdemo_sk:172813,wr_returning_hdemo_sk:3391,wr_returning_addr_sk:2919542,wr_web_page_sk:1165,wr_reason_sk:489,wr_order_number:338223251,wr_return_quantity:4,wr_return_amt:157.88,wr_return_tax:11.05,wr_return_amt_inc_tax:168.93,wr_fee:11.67,wr_return_ship_cost:335.88,wr_refunded_cash:63.15,wr_reversed_charge:87.15,wr_account_credit:7.58,wr_net_loss:357.98} {wr_returned_date_sk:37650,wr_returned_time_sk:63404,wr_item_sk:1229906,wr_refunded_customer_sk:5528377,wr_refunded_cdemo_sk:172813,wr_refunded_hdemo_sk:3391,wr_refunded_addr_sk:2919542,wr_returning_customer_sk:5528377,wr_returning_cdemo_sk:172813,wr_returning_hdemo_sk:3391,wr_returning_addr_sk:2919542,wr_web_page_sk:1052,wr_reason_sk:118,wr_order_number:338223251,wr_return_quantity:19,wr_return_amt:3804.37,wr_return_tax:266.31,wr_return_amt_inc_tax:4070.68,wr_fee:47.27,wr_return_ship_cost:3921.98,wr_refunded_cash:1521.75,wr_reversed_charge:2100.01,wr_account_credit:182.61,wr_net_loss:4454.6}   このデータをLinuxのファイルシステム上からHDFS上に置き、1列のみのHive表として作成します。その後、Oracle Databaseから1列のみの外部表を作成します。 [Linux] $ hadoop fs -put source.json hdfs://cluster-ns/user/hive/warehouse/jsondata/ hive> CREATE TABLE json_string( json_str string) ROW FORMAT SERDE 'org.apache.hadoop.hive.serde2.lazy.LazySimpleSerDe' STORED AS INPUTFORMAT 'org.apache.hadoop.mapred.TextInputFormat' OUTPUTFORMAT 'org.apache.hadoop.hive.ql.io.HiveIgnoreKeyTextOutputFormat' LOCATION 'hdfs://cluster-ns/user/hive/warehouse/jsondata/' SQL> CREATE TABLE WEB_RETURNS_JSON_STRING ( JSON_STR VARCHAR2(4000) ) ORGANIZATION EXTERNAL ( TYPE ORACLE_HIVE DEFAULT DIRECTORY "DEFAULT_DIR" ACCESS PARAMETERS (com.oracle.bigdata.tablename=json.json_string) ) REJECT LIMIT UNLIMITED PARALLEL; OK、ここまでは無選別に見えます。なぜ1列だけのテーブルが必要なのでしょうか? Oracle Database 12cでは、JSONデータの扱いが大きく拡張しており、それはBig Data SQLでも自動的に利用できるものです(Big Data SQLはOracle SQLであることは皆さん覚えてますよね)。 JSONをOracle SQLでパースすることは極めて簡単です。列名の後に. (ドット)をつけてフィールド名を書くだけです。 SQL> SELECT j.json_str.wr_returned_date_sk, j.json_str.wr_returned_time_sk FROM web_returns_json_string j WHERE j.json_str.wr_returned_time_sk = 8645 AND ROWNUM <= 5; ... 38195 8645 38301 8645 37820 8645 38985 8645 37976 8645 System Statをチェックすると、Hadoop側で多くのデータがフィルターされていることが分かります。 SQL> SELECT n.name, VALUE FROM v$mystat s, v$statname n WHERE s.statistic# = n.statistic# AND n.name LIKE '%XT%'; ... cell interconnect bytes returned by XT smart scan 507904 Bytes cell XT granule bytes requested for predicate offload 16922334453 Bytes 注:パースとフィルターがHadoop側で行われています! Big Data SQL と JSONにおける制限と回避策 JSON 文字列が4000文字になるまでは、テーブルにVARCHAR2(4000)の列を定義することで、全てはうまくいきます。しかし、4000文字以上のJSON文字列を扱う場合はどうなるでしょうか?それをCLOBで定義すると、このケースでは全てのパースとフィルターがデータベース側で行われます。 テストケース 先の例のテーブル定義(列定義がVARCHAR2)を使用し、クエリを実行します。 SQL> SELECT COUNT(1) FROM web_returns_json_string j WHERE j.json_str.wr_returned_time_sk = 8645; クエリは75秒で完了しました。Enterprise Managerは、待機イベントの殆どが、スキャンをオフロードしストレージ側で行われたことを意味する”cell external table smart scan”であることを示しています。 次に、同じHive表に対し、Oracleの外部表を定義しますが、今回は列をCLOBで定義します。 SQL> CREATE TABLE WEB_RETURNS_JSON_STRING ( JSON_STR CLOB ) ORGANIZATION EXTERNAL ( TYPE ORACLE_HIVE DEFAULT DIRECTORY "DEFAULT_DIR" ACCESS PARAMETERS (com.oracle.bigdata.tablename=json.json_string) ) REJECT LIMIT UNLIMITED PARALLEL ; 同じクエリを実行します。 SQL> SELECT COUNT(1) FROM web_returns_json_string j WHERE j.json_str.wr_returned_time_sk = 8645; 実行時間はなんと90分!3600倍も遅いです。Enterprise Managerは待機イベントの殆どがDatabase CPUであることを示しています。これはCLOB列であるために、オフロードができなかったことを意味します。 Cloudera Managerはこれら2つのクエリの違いを示します。最初のクエリはCell側(3つのHadoopノード)のリソースを使用し、2つ目のクエリはデータベース側のみ使用しています。 4000文字を超えるJSONの場合、性能が劣化するという問題があることが分かりました。ではどうやって回避すればよいでしょうか? 簡単です!XMLの例のようにHiveメタストア内の構造を定義してHive表とOracle表のマッピングをするとよいです。 hive> CREATE EXTERNAL TABLE j1_openx( wr_returned_date_sk bigint, wr_returned_time_sk bigint, wr_item_sk bigint, wr_refunded_customer_sk bigint, wr_refunded_cdemo_sk bigint, wr_refunded_hdemo_sk bigint, wr_refunded_addr_sk bigint, wr_returning_customer_sk bigint, wr_returning_cdemo_sk bigint, wr_returning_hdemo_sk bigint, wr_returning_addr_sk bigint, wr_web_page_sk bigint, wr_reason_sk bigint, wr_order_number bigint, wr_return_quantity int, wr_return_amt double, wr_return_tax double, wr_return_amt_inc_tax double, wr_fee double, wr_return_ship_cost double, wr_refunded_cash double, wr_reversed_charge double, wr_account_credit double, wr_net_loss double) ROW FORMAT SERDE 'org.openx.data.jsonserde.JsonSerDe' STORED AS INPUTFORMAT 'org.apache.hadoop.mapred.TextInputFormat' OUTPUTFORMAT 'org.apache.hadoop.hive.ql.io.HiveIgnoreKeyTextOutputFormat' LOCATION 'hdfs://cluster-ns/user/hive/warehouse/jsondata/' JSON用のSarDeは何種類かあるが、性能の観点で個人的にorg.openx.data.jsonserde.JsonSerDeをお勧めします。 この後はOracleの外部表を定義すればOKです。 SQL> CREATE TABLE WEB_RETURNS_JSON_SD_OPENX ( WR_RETURNED_DATE_SK NUMBER(10,0), WR_RETURNED_TIME_SK NUMBER(10,0), WR_ITEM_SK NUMBER(10,0), WR_REFUNDED_CUSTOMER_SK NUMBER(10,0), WR_REFUNDED_CDEMO_SK NUMBER(10,0), WR_REFUNDED_HDEMO_SK NUMBER(10,0), WR_REFUNDED_ADDR_SK NUMBER(10,0), WR_RETURNING_CUSTOMER_SK NUMBER(10,0), WR_RETURNING_CDEMO_SK NUMBER(10,0), WR_RETURNING_HDEMO_SK NUMBER(10,0), WR_RETURNING_ADDR_SK NUMBER(10,0), WR_WEB_PAGE_SK NUMBER(10,0), WR_REASON_SK NUMBER(10,0), WR_ORDER_NUMBER NUMBER(10,0), WR_RETURN_QUANTITY NUMBER(10,0), WR_RETURN_AMT NUMBER, WR_RETURN_TAX NUMBER, WR_RETURN_AMT_INC_TAX NUMBER, WR_FEE NUMBER, WR_RETURN_SHIP_COST NUMBER, WR_REFUNDED_CASH NUMBER, WR_REVERSED_CHARGE NUMBER, WR_ACCOUNT_CREDIT NUMBER, WR_NET_LOSS NUMBER ) ORGANIZATION EXTERNAL ( TYPE ORACLE_HIVE DEFAULT DIRECTORY DEFAULT_DIR ACCESS PARAMETERS ( com.oracle.bigdata.cluster:bds30 com.oracle.bigdata.tablename:json.j1_openx)) REJECT LIMIT UNLIMITED PARALLEL ; クエリを実行します。 SQL> SELECT COUNT(1) FROM WEB_RETURNS_JSON_SD_OPENX j WHERE j.wr_returned_time_sk = 8645; 実行時間は141秒でした。Hadoop側へオフロードしていました。VARCHAR2のネイティブ処理と比較して2倍遅いですが、CLOBとしてネイティブ処理するよりも1800倍速いです。 まとめ HDFSはオリジナルフォーマットでのデータ格納に向いています Big Data SQLは半構造化データへの Wide Capabilityを提供します JSONファイルフォーマットにとって、out of the boxで扱うのに便利なAPIを持ちます   本投稿は Big Data SQL Quick Start. Semi-structured data. - Part12.   を元に投稿しています。

以前の投稿で、Schema on ReadとSchema on Writeの長所短所について触れました。結論として、HDFSはデータをオリジナルフォーマットで置いておくのに適していることが分かりました。時折、ユーザはXMLやJSONのような半構造化データ(semi-structured data)を持ちます。今回は、それをどのように扱うかを紹介します。 半構造化データのユースケース HDFS上に半構造化...

Big Data Management

Big Data SQL - Schema on Read と Schema on Write

Schema on Read か Schema on Writeか データロードについて。データロード先となるシステムは、通常2種類のうちどちらかです。2つのうち片方はSchema on Writeです。Schema on Writeでは、データロード時に列やデータフォーマットなどを定義する必要があります。ETL(データを幾つかの特定のシステム向けに使いやすいように変換する)が終わると、とても高速にREADでき、システムのパフォーマンスも良好です。しかし、留意すべき点は、データローディング時に既にペナルティを払っているということです。Schema on Writeのシステムとしては、Oracle DatabaseやMySQLのようなリレーショナル・データベースが挙げられます。 もう一つのアプローチはSchema on Readです。この場合、データに変更や変換を何も加えずにロードします。ETL処理をスキップするので(データを変換しない)、データフォーマットや構造に頭をかかえることもありません。ファイルを、ただ、ファイルシステム上にロードするだけです(写真をFlashカードや外部ストレージからノートPCにコピーするかのように)。データの意味付けはデータのREAD時に決定します。興味深いことに、ひとつのデータ(ファイル)は異なった作法で読まれます。例えばバイナリデータがあったとき、Serialization/Deserializationフレームワークを定義し、SELECT時に使って構造化データを得る、あるいは、バイトのセットを得る。他の例では、シンプルなCSVファイルであっても同じ列を数値とするか文字列とするか、その違いによって、ソートや比較演算で異なる結果になります。 HDFS(Hadoop Distributed File System)はSchema on Readの古典的な例です。Schema on ReadとSchema on Writeのさらに詳細はこちらで参照できます。 Schema on Writeは万能か? ParquetやORCというHadoop内のファイルフォーマットについて聞いた方も多いでしょう。これはSchema on Writeアプローチの例です。ソースフォーマットを処理エンジン(hive, impala, Big Data SQLなど)にとって扱いやすいように変換します。Big Data SQLはPredicate Push Downや列のプルーニングなどのとても強力な機能を持ち、性能を大きく向上します。Parquetファイルを使ってBig Data SQLのドラマティックな性能改善することを、過去のBlogから、伝わってるといいのですが。しかし、データ変換の後、即座にソースファイルを削除しますか?いいえ、理由を説明しましょう。 ソースデータの変換 データソースとして、AVROフォーマットを使用します。   { "type" : "record", "name" : "twitter_schema", "namespace" : "com.miguno.avro", "fields" : [ { "name" : "username", "type" : "string", "doc" : "Name of the user account on Twitter.com" }, { "name" : "tweet", "type" : "string", "doc" : "The content of the user's Twitter message" }, { "name" : "timestamp", "type" : "long", "doc" : "Unix epoch time in seconds" } ] } このスキーマを使用してAVROファイルを作成します(3行持ちます)。 $ java -jar /usr/lib/avro/avro-tools.jar random --schema-file /tmp/twitter.avsc --count 3 example.avro 次に、このファイルをHDFSディレクトリ上に配置します。 $ hadoop fs -mkdir /tmp/avro_test/ $ hadoop fs -mkdir /tmp/avro_test/flex_format $ hadoop fs -put example.avro /tmp/avro_test/flex_format メタデータを使って説明する準備ができましたね。CREATE HIVE TABLEでHive External Tableを作成します。 hive> CREATE EXTERNAL TABLE tweets_flex ROW FORMAT SERDE 'org.apache.hadoop.hive.serde2.avro.AvroSerDe' STORED AS INPUTFORMAT 'org.apache.hadoop.hive.ql.io.avro.AvroContainerInputFormat' OUTPUTFORMAT 'org.apache.hadoop.hive.ql.io.avro.AvroContainerOutputFormat' LOCATION '/tmp/avro_test/flex_format' TBLPROPERTIES ('avro.schema.literal'='{ "namespace": "testing.hive.avro.serde", "name": "tweets", "type": "record", "fields": [ {"name" : "username", "type" : "string", "default" : "NULL"}, {"name" : "tweet","type" : "string", "default" : "NULL"}, {"name" : "timestamp", "type" : "long", "default" : "NULL"} ] }' ); Oracle Databaseからこのデータにアクセスできるように、上のHive表にリンクするようなOracleの外部表を作成します。 SQL> CREATE TABLE tweets_avro_ext ( username VARCHAR2(4000), tweet VARCHAR2(4000), TIMESTAMP NUMBER ) ORGANIZATION EXTERNAL ( TYPE ORACLE_HIVE DEFAULT DIRECTORY "DEFAULT_DIR" ACCESS PARAMETERS ( com.oracle.bigdata.tablename=DEFAULT.tweets_flex) ) REJECT LIMIT UNLIMITED PARALLEL; ここで、Big Data SQL用に最適化のために、Parquetフォーマットに変換しようと思います。 hive> create table tweets_parq ( username string, tweet string, TIMESTAMP smallint ) STORED AS PARQUET; hive> INSERT OVERWRITE TABLE tweets_parq select * from tweets_flex; このParquetファイルにリンクするような、Oracleの外部表を作成します。 SQL> CREATE TABLE tweets_parq_ext ( username VARCHAR2(4000), tweet VARCHAR2(4000), TIMESTAMP NUMBER ) ORGANIZATION EXTERNAL ( TYPE ORACLE_HIVE DEFAULT DIRECTORY "DEFAULT_DIR" ACCESS PARAMETERS ( com.oracle.bigdata.cluster=bds30 com.oracle.bigdata.tablename=DEFAULT.tweets_parq) ) REJECT LIMIT UNLIMITED PARALLEL; OK、準備できたようです。では、作成した表(CREATE TABLE AS SELECTでAVROのデータから作成したので同一のデータを持つ表)にクエリを実行してみましょう。 SQL> select TIMESTAMP from tweets_avro_ext WHERE username='vic' AND tweet='hello' UNION ALL select TIMESTAMP from tweets_parq_ext WHERE username='vic' AND tweet='hello' ------------ 1472648470 -6744 うーん、思ってたのと違う。データは同じであるべきなのに、何かがおかしい。これは、SMALLINTデータ型はTIMESTAMP(という名前の)列に対して十分ではないことが原因です。Hive内のParquet表を再作成し、再実行してみましょう。 hive> drop table tweets_parq; hive> create table tweets_parq ( username string, tweet string, TIMESTAMP bigint ) STORED AS PARQUET; hive> INSERT OVERWRITE TABLE tweets_parq select * from tweets_flex; Hive表再作成後は、Oracle Database側では何もする必要はありません。(Hive表の名前は変更していないので) SQL> select TIMESTAMP from tweets_avro_ext WHERE username='vic' AND tweet='hello' UNION ALL select TIMESTAMP from tweets_parq_ext WHERE username='vic' AND tweet='hello' ------------ 1472648470 1472648470 当たり!結果が等しくなりました。 結論 Schema on Read と Schema on Write どちらがよいか?それは哲学的問題です。Schema on Readは柔軟性と人的エラーからの保護をもたらします。Schema on Writeはよりよい性能をもたらします。一般的に、ソースフォーマットのデータを(念の為)保持しておくこと、そしてスキャンするエンジンにとって便利な別のフォーマットに最適化することは、良い考えです。ETLは誤った変換をするかもしれません。ソースデータがあれば、データを正しいやり方でソースから再パースすることができます。 本投稿は   Big Data SQL Quick Start. Schema on Read and Schema on Write - Part11. を元に投稿しています。

Schema on Read か Schema on Writeか データロードについて。データロード先となるシステムは、通常2種類のうちどちらかです。2つのうち片方はSchema on Writeです。Schema...

Big Data Management

Big Data SQL - Kerberos

Hadoopの世界では、Kerberosがクラスタを保護するデファクトスタンダードであり、Big Data SQLもKerberosをサポートします。 オラクル社では、Big Data SQLをKerberizedクラスタにインストールする方法をドキュメントで提示しています。今日はKerberosインストールのテストとデバッグの代表的な手順を示します。 まず、テスト環境について説明します。4つのノードがあります。中には、3つがHadoopクラスタのノード(vm0 [1-3])で、1つがデータベースのノード(vm04)です。 Kerberosチケットはkeytabファイルから起動されます。KeytabはHadoopの各ノートとデータベースのノード(RACの場合、各データベースノード)に存在する必要があります。 データベースノードに有効なKerberosチケットがあることを確認します。   [oracle@vm04 ~]$ id uid=500(oracle) gid=500(oinstall) groups=500(oinstall),501(dba) [oracle@scaj0602bda09vm04 ~]$ klist Ticket cache: FILE:/tmp/krb5cc_500 Default principal: oracle/martybda@MARTYBDA.ORACLE.COM Valid starting Expires Service principal 07/23/18 01:15:58 07/24/18 01:15:58 krbtgt/MARTYBDA.ORACLE.COM@MARTYBDA.ORACLE.COM renew until 07/30/18 01:15:01   データベースホストからHDFSにアクセスできることを確認します。 [oracle@vm04 ~]$ cd $ORACLE_HOME/bigdatasql [oracle@vm04 bigdatasql]$ ls -l|grep hadoop*env -rw-r--r-- 1 oracle oinstall 2249 Jul 12 15:41 hadoop_martybda.env [oracle@vm04 bigdatasql]$ source hadoop_martybda.env [oracle@vm04 bigdatasql]$ hadoop fs -ls ... Found 4 items drwx------ - oracle hadoop 0 2018-07-13 06:00 .Trash drwxr-xr-x - oracle hadoop 0 2018-07-12 05:10 .sparkStaging drwx------ - oracle hadoop 0 2018-07-12 05:17 .staging drwxr-xr-x - oracle hadoop 0 2018-07-12 05:14 oozie-oozi [oracle@vm04 bigdatasql]$   確認を完了した後、 Hadoopノードでも同様に確認します。   [root@vm01 ~]# su - oracle [oracle@scaj0602bda09vm01 ~]$ id uid=1000(oracle) gid=1001(oinstall) groups=1001(oinstall),127(hive),1002(dba) [oracle@vm01 ~]$ klist Ticket cache: FILE:/tmp/krb5cc_1000 Default principal: oracle/martybda@MARTYBDA.ORACLE.COM Valid starting Expires Service principal 07/23/18 01:15:02 07/24/18 01:15:02 krbtgt/MARTYBDA.ORACLE.COM@MARTYBDA.ORACLE.COM renew until 07/30/18 01:15:02 Hadoop環境にアクセスできることを確認します。環境にアクセスして、HDFS上でテストファイルを作成します。   [oracle@vm01 ~]$ echo "line1" >> test.txt [oracle@vm01 ~]$ echo "line2" >> test.txt [oracle@vm01 ~]$ hadoop fs -mkdir /tmp/test_bds [oracle@vm01 ~]$ hadoop fs -put test.txt /tmp/test_bds   データベースノードにアクセスして、HDFS上のテストファイルへの外部表を作成します。   [root@vm04 bin]# su - oracle [oracle@vm04 ~]$ . oraenv <<< orcl ORACLE_SID = [oracle] ? The Oracle base has been set to /u03/app/oracle [oracle@vm04 ~]$ sqlplus / as sysdba SQL*Plus: Release 12.1.0.2.0 Production on Mon Jul 23 06:39:06 2018 Copyright (c) 1982, 2014, Oracle. All rights reserved. Connected to: Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options SQL> alter session set container=PDBORCL; Session altered. SQL> CREATE TABLE bds_test (line VARCHAR2(4000)) ORGANIZATION EXTERNAL ( TYPE ORACLE_HDFS DEFAULT DIRECTORY DEFAULT_DIR LOCATION ('/tmp/test_bds') ) REJECT LIMIT UNLIMITED; Table created. SQL>   前の手順で作成したHDFS上の2行のテストファイルを確認できます。   SQL> select * from bds_test; LINE ------------------------------------ line1 line2 Kerberosを使ったよくあるケースを紹介し、解決方法について説明します。 シナリオ1:データベース側でKerberosチケットをミスした場合 データベース側でKerberosチケットをミスしたことをシミュレートします。 これはかなり簡単で、kdestroyコマンドを使用します。   [oracle@vm04 ~]$ kdestroy [oracle@vm04 ~]$ klist klist: No credentials cache found (ticket cache FILE:/tmp/krb5cc_500) extprocはKerberosチケットをキャッシュするので、変更を適用するには、extprocを再起動する必要があります。まず、extprocのプロセスの名前を確認します。   [oracle@vm04 admin]$ cd $ORACLE_HOME/hs/admin [oracle@vm04 admin]$ ls -l total 24 -rw-r--r-- 1 oracle oinstall 1170 Mar 27 01:04 extproc.ora -rw-r----- 1 oracle oinstall 3112 Jul 12 15:56 initagt.dat -rw-r--r-- 1 oracle oinstall 190 Jul 12 15:41 initbds_orcl_martybda.ora -rw-r--r-- 1 oracle oinstall 489 Mar 27 01:04 initdg4odbc.ora -rw-r--r-- 1 oracle oinstall 406 Jul 12 15:11 listener.ora.sample -rw-r--r-- 1 oracle oinstall 244 Jul 12 15:11 tnsnames.ora.sample   名前は、データベースSIDとHadoopクラスタ名で構成されるので、extproc名はbds_orcl_martybdaだと思われます。extprocを停止し、起動します。   oracle@vm04 admin]$ mtactl stop bds_orcl_martybda ORACLE_HOME = "/u03/app/oracle/12.1.0/dbhome_orcl" MTA init file = "/u03/app/oracle/12.1.0/dbhome_orcl/hs/admin/initbds_orcl_martybda.ora" oracle 16776 1 0 Jul12 ? 00:49:25 extprocbds_orcl_martybda -mt Stopping MTA process "extprocbds_orcl_martybda -mt"... MTA process "extprocbds_orcl_martybda -mt" stopped! [oracle@vm04 admin]$ mtactl start bds_orcl_martybda ORACLE_HOME = "/u03/app/oracle/12.1.0/dbhome_orcl" MTA init file = "/u03/app/oracle/12.1.0/dbhome_orcl/hs/admin/initbds_orcl_martybda.ora" MTA process "extprocbds_orcl_martybda -mt" is not running! Checking MTA init parameters... [O] INIT_LIBRARY=$ORACLE_HOME/lib/libkubsagt12.so [O] INIT_FUNCTION=kubsagtMTAInit [O] BDSQL_CLUSTER=martybda [O] BDSQL_CONFIGDIR=/u03/app/oracle/12.1.0/dbhome_orcl/bigdatasql/databases/orcl/bigdata_config MTA process "extprocbds_orcl_martybda -mt" started! oracle 19498 1 4 06:58 ? 00:00:00 extprocbds_orcl_martybda -mt Kerberosチケットのキャッシュをリセットしました。 HDFSデータに対しクエリを実行します。   [oracle@vm04 admin]$ sqlplus / as sysdba SQL*Plus: Release 12.1.0.2.0 Production on Mon Jul 23 07:00:26 2018 Copyright (c) 1982, 2014, Oracle. All rights reserved. Connected to: Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options SQL> alter session set container=PDBORCL; Session altered. SQL> select * from bds_test; select * from bds_test * ERROR at line 1: ORA-29913: error in executing ODCIEXTTABLEOPEN callout ORA-29400: data cartridge error KUP-11504: error from external driver: java.lang.Exception: Error initializing JXADProvider: Failed on local exception: java.io.IOException: javax.security.sasl.SaslException: GSS initiate failed [Caused by GSSException: No valid credentials provided (Mechanism level: Failed to find any Kerberos tgt)]; Host Details : local host is: "m04.vm.oracle.com/192.168.254.5"; destination host is: "vm02.vm.oracle.com":8020; エラーを確認します。このエラーが表示された場合は、データベース側に有効なKerberosチケットがないことを意味します。 すべてを元に戻し、環境が正しく動作するようにします。 [oracle@vm04 admin]$ crontab -l 15 1,7,13,19 * * * /bin/su - oracle -c "/usr/bin/kinit oracle/martybda@MARTYBDA.ORACLE.COM -k -t /u03/app/oracle/12.1.0/dbhome_orcl/bigdatasql/clusters/martybda/oracle.keytab" [oracle@vm04 admin]$ /usr/bin/kinit oracle/martybda@MARTYBDA.ORACLE.COM -k -t /u03/app/oracle/12.1.0/dbhome_orcl/bigdatasql/clusters/martybda/oracle.keytab [oracle@vm04 admin]$ klist Ticket cache: FILE:/tmp/krb5cc_500 Default principal: oracle/martybda@MARTYBDA.ORACLE.COM Valid starting Expires Service principal 07/23/18 07:03:46 07/24/18 07:03:46 krbtgt/MARTYBDA.ORACLE.COM@MARTYBDA.ORACLE.COM renew until 07/30/18 07:03:46 [oracle@vm04 admin]$ mtactl stop bds_orcl_martybda ... [oracle@vm04 admin]$ mtactl start bds_orcl_martybda ... [oracle@scaj0602bda09vm04 admin]$ sqlplus / as sysdba ... SQL> alter session set container=PDBORCL; Session altered. SQL> select * from bds_test; LINE ---------------------------------------- line1 line2 SQL> シナリオ2:Hadoop側でKerberosチケットをミスした場合 Hadoop側でKerberosチケットをミスしたケース(Oracleユーザーの場合)を紹介します。各Hadoopノードでkdestroyコマンドツールを使用し、チケットを削除します。   [oracle@vm01 ~]$ id uid=1000(oracle) gid=1001(oinstall) groups=1001(oinstall),127(hive),1002(dba) [oracle@vm01 ~]$ kdestroy すべての手順を完了した後、データベース側でクエリを再実行します。   [oracle@vm04 bigdata_config]$ sqlplus / as sysdba ... SQL> alter session set container=PDBORCL; Session altered. SQL> select * from bds_test; LINE ---------------------------------------- line1 line2 SQL> すべてがうまく見えますが、実行統計情報を確認しましょう。   SQL> select n.name, s.value /* , s.inst_id, s.sid */ from v$statname n, gv$mystat s where n.name like '%XT%' and s.statistic# = n.statistic#; NAME VALUE ---------------------------------------------------------------- ---------- cell XT granules requested for predicate offload 1 cell XT granule bytes requested for predicate offload 12 cell interconnect bytes returned by XT smart scan 8192 cell XT granule predicate offload retries 3 cell XT granule IO bytes saved by storage index 0 cell XT granule IO bytes saved by HDFS tbs extent map scan 0 「cell XT granule predicate offload retries」が0ではないことを確認できます。つまり、実際の処理はすべてデータベース側で行われます。 HDFS上で10TBのテーブルにクエリを実行すると、10TBをデータベース側に移動し、処理します。つまり、Hadoop側でKerberosチケットをミスした場合、クエリは正常に終了しますが、SmartScanは機能しません。   Kerberosチケットの更新 Kerberosの特徴の1つは、チケットに有効期限があり、更新する必要があることです。 Big Data SQLのインストール時に、データベース側とHadoop側でcrontabジョブを作成します。何らかの理由でこれに失敗した場合、以下を例として使うことができます。   [oracle@vm04 ~]$ crontab -l 15 1,7,13,19 * * * /bin/su - oracle -c "/usr/bin/kinit oracle/martybda@MARTYBDA.ORACLE.COM -k -t /u03/app/oracle/12.1.0/dbhome_orcl/bigdatasql/clusters/martybda/oracle.keytab" Big Data SQLは常にOracleプリンシパルを使用しますが、HDFSへのアクセスを細かく制御したい場合、マルチユーザー認証機能を使用する必要があります。   結論 Big Data SQLはKerberizedクラスタで動作する KerberosチケットはDatabase側とHadoop側に存在する必要がある データベース側でKerberosチケットをミスした場合、クエリは失敗する Hadoop側でKerberosチケットをミスした場合、クエリは失敗しない。ただし、フェールバックモードで動作する(すべてのブロックをデータベースノードに移動し、そこで処理する。これは望んだことではない。)   本投稿は Big Data SQL Quick Start. Kerberos - Part 26. を元に投稿しています。

Hadoopの世界では、Kerberosがクラスタを保護するデファクトスタンダードであり、Big Data SQLもKerberosをサポートします。 オラクル社では、Big Data SQLをKerberizedクラスタにインストールする方法をドキュメントで提示しています。今日はKerberosインストールのテストとデバッグの代表的な手順を示します。 まず、テスト環境について説明します。4つのノード...

Big Data Management

データエクスチェンジのビジネス価値

“様々な種類のデータが活用可能な状態になると、その効果は想像を超える" Tim Berners-Lee in 2007.   10年前には、企業はこれほどまで多くのデータとそこから生まれる力を持っていませんでした。今後、さらに産業間におけるデータエクスチェンジ(共有)により、この流れは加速していくと考えられています。このインテリジェンスの共有は、一部の企業が顧客の理解を深め、顧客体験を改善し、新しい収益源の確保する機会をもたらします。 データエクスチェンジの事例 Telefonica(テレフォニカ) テレビの視聴者の属性とその行動を理解するためにビッグデータを活用しています。これにより、状況・時間帯・またはデバイス単位に最適化されたリコメンドを作成できます。テレフォニカの顧客に対する深い理解は、コンテンツ制作者にとって視聴者の好みを知る価値あるデータです。 これはテレフォニカが匿名化されたテレビ視聴に関するインテリジェンスを持ち、広告代理店やメディアプロデューサーとデータ共有できることを意味します。それは、よりよいコンテンツを提供することで、市場および視聴者に対し価値を還元できます。 テレフォニカはデータ収益化に積極的に取り組むことでスペインのデジタル広告とメディア市場の30%を獲得することができました。 位置情報のマネタイゼーション 小売業者は、通信事業者と提携することにより、匿名化、集計されたインテリジェンスを出店計画に活用しています。 ヨーロッパで3番目のモバイルオペレーターであるTurkcell(タークセル)はSMSをベースとしたロケーション情報サービスを提供しており、コンテンツに対して最も効果の高い”位置”とタイミングでプロモーションできます。データエクスチェンジにより、広告主は各エリアに存在する人口統計に基づいて広告の内容を最適化することも可能です。 保険業界においても、このようなアプローチが行われています。例えば、Generali(ジェネラリ) は、顧客の車からGPSなどの一連のデータを収集し分析することでテレマティクスや事故データを追跡して事故の原因となった運転行動やパターンを特定し顧客プロファイリングの改善に役立てています。 データエクスチェンジの市場は、成功を収めているテレコム・メディア産業においては収益の10%を占めるほどに成長していますが、産業全体で見てみると、わずか0.2%しか収益を生み出していません。これは、非常に大きなビジネスのオポチュニティがあることを示唆しています。 データエクスチェンジのさらなる利点 産業間のデータエクスチェンジはより大きな可能性を秘めています。ある都市では telecom networksから位置情報を収集し分析することで新しい都市開発や輸送リンク、最適な駐車場配置や渋滞の解消に役立てていこうとしています。また、電力会社ではスマートメーターの位置情報と電気自動車の車載機の情報を活用し、グリッド単位の高度な電力需要予測に取り組んでいます。 救急活動においても、データエクスチェンジされたテレマティクスが活用されおり、事故の際により迅速に最適なチームを派遣することができます。車載器の情報から搭乗人数やクラッシュ時の衝撃の大きさ、事故現場の性格な位置情報を把握することができるためです。 車載器からの情報取得は、以下のモデルレースデモをご参照ください。 データドリブンによる成功は、企業がデータを使用した新しい方法を模索する意欲にかかっています。事例を通してデータの流通は収益を伸ばしたり、新しい消費者に対する洞察を得るための、ビジネスにとって有用なツールであることが裏付けられています。しかし、所詮ツールであり、大事なのは、そのデータを活かすためのアイデアなのです。 毎日、企業のデータと緊密に接しているデータサイエンティストやアナリストから、ビジネス・リーダーが業務改善するための新しい方法を模索する中、オラクルは組織内のすべての人に豊富な統合ソリューションを提供しています。 本資料は、Oracle Big Data blog(https://blogs.oracle.com/bigdata/data-exchange-and-monetization)を抄訳したものです。

“様々な種類のデータが活用可能な状態になると、その効果は想像を超える" Tim Berners-Lee in 2007.   10年前には、企業はこれほどまで多くのデータとそこから生まれる力を持っていませんでした。今後、さらに産業間におけるデータエクスチェンジ(共有)により、この流れは加速していくと考えられています。このインテリジェンスの共有は、一部の企業が顧客の理解を深め、顧客体験を改善し、新しい収...

Big Data Management

Big Data SQL - マルチユーザー認証

Big Data SQLのメリットの1つは、セキュリティです。Oracle Databaseを利用して、HDFSやその他のソースに格納されたデータを処理します。そのため、Data Redaction、VPD、Database Vaultなどの多くのデータベース機能を適用できます。これらの機能は、データベース・スキーマと権限を組み合わせて、侵入者がデータベース側からデータにアクセスしようとする場合、データを保護します。 しかし、HDFSに格納されたデータは、他の目的(Spark、Solr、Impala…)で使用される場合もあり、他のメカニズムで保護する必要もあります。Hadoopの世界では、Kerberosがデータ保護の最も一般的な認証方法です。KerberosとHDFS ACLを組み合わせて、ファイルシステムレベルでデータを保護できます。ファイルシステムとしてのHDFSは、ユーザーとグループの概念を持ち、所有者、グループ、その他のユーザーにそれぞれの権限を付与できます。   結論:Kerberizedクラスタを使用する場合、Big Data SQLはHDFSファイルを扱うために有効なKerberosチケットを持っている必要があります。このすべての設定は、標準のOracle Big Data SQLインストーラで自動化され、使用可能です。詳細はこちらをご確認ください。 Big Data SQLとKerberos 顧客がKerberizedクラスタを使用している場合、我々も有効なKerberosチケットが必要です。Big Data SQLはどのプリンシパルを持つ必要がありますか。 答えはoracleです。以前のBig Data SQLリリースでは、すべてのBig Data SQLが同じユーザーoracleとして実行されており、次のような状況でした。 クエリを実行しているユーザーに基づいて、データへのアクセスを承認することができない Big Data SQLを介して問い合わせを実行するユーザーは、すべてoracleとしてHadoopクラスタ監査に記録される 他のアプリケーションでも使用され異なる権限を持つ(別のユーザーやグループに属している)データが既にある場合、どのようにすればよいでしょうか。Big Data SQL 3.2では、新しい機能としてマルチユーザー認証を導入しました。 Hadoop Impersonalization マルチユーザー認証の基礎は、ImpersonalizationというHadoopの機能です。Impersonalizationの説明は以下になります。(出典はこちら) "A superuser with username ‘super’ wants to submit job and access hdfs on behalf of a user joe. The superuser has Kerberos credentials but user joe doesn’t have any. The tasks are required to run as user joe and any file accesses on namenode are required to be done as user joe. It is required that user joe can connect to the namenode or job tracker on a connection authenticated with super’s Kerberos credentials. In other words super is impersonating the user joe." スーパーユーザーsuperは、ユーザーjoeに代わってジョブを送信し、HDFSにアクセスします。SuperにはKerberos認証情報がありますが、joeにはKerberos認証情報がありません。タスクやname node上のファイルへのアクセスはjoeとして実行する必要があります。Joeは、superのKerberos認証情報で認証された接続上でname nodeまたはjob trackerに接続する必要があります。言い換えれば、superはjoeをImpersonalizationしています。 同じように、oracleはスーパーユーザーであり、他のユーザーがImpersonalizationされています。 マルチユーザー認証の主な概念 Big Data SQLは、クラスタ上のデータにアクセスしている信頼できるユーザーを識別します。信頼できるユーザーがクエリを実行する時 Hadoopで指定された承認ルールは遵守される Hadoopで指定された承認ルールをデータベースに複製する必要はない Hadoopクラスタ監査は、Big Data SQLクエリを実行する実際のユーザーを識別する Oracle Databaseは、Hadoopに信頼できるユーザーを提供するエンティティとして考えられる Oracle Databaseの問い合わせを実行しているデータベース・ユーザーをHadoopユーザーにマッピングする必要がある Oracle表を問い合わせている実際のユーザーを識別し、ユーザーIDをHadoopに渡す必要がある これはOracle Databaseのユーザー(スキーマ)である可能性がある セッション・ベースのコンテキストから発生された軽量ユーザーである場合もある(SYS_CONTEXT参照) ユーザー/グループのマッピングは、HadoopのOSルックアップで確認できる必要がある   デモンストレーション シナリオ1 このシナリオではシンクライアントまたはCLIENT_IDENTIFIERによって認証を行います。多層アーキテクチャの場合(アプリケーション層とデータベース層がある場合)、同一のスキーマを使用する複数のユーザーを同じアプリケーション内で区別することは難しいです。 この機能に関するドキュメントはこちらで確認できます。ここでは、よくあるケースをサンプル・コードで紹介します。 オブジェクトを操作するには、マッピングテーブルを管理する権限をユーザーに与える必要があります。 ここでは、ユーザーbikesを使います。 SQL> grant select on BDSQL_USER_MAP to bikes; SQL> grant execute on DBMS_BDSQL to bikes; SQL> grant BDSQL_ADMIN to bikes; 念のためユーザーbikesのパーミッションを削除します。 SQL> begin DBMS_BDSQL.REMOVE_USER_MAP (current_database_user =>'BIKES'); end; / マッピングテーブルが空であることを確認します。 SQL> select * from SYS.BDSQL_USER_MAP; そして以下のクエリを実行します。これはマッピングなしのデフォルト・モードなので、ユーザーoracleとしてHDFSに接続するでしょう。 SQL> select /*+ MONITOR */ * from bikes.weather_ext; 監査ファイルを確認します。ユーザーoracleがファイルを読み取ったことを確認できます(ugi = oracle)。 $ cd /var/log/hadoop-hdfs $ tail -f hdfs-audit.log |grep central_park 2018-03-01 17:42:10,938 INFO ... ugi=oracle ... ip=/10.0.0.10 cmd=open ... src=/data/weather/central_park_weather.csv.. ファイルの権限を確認します。このファイルはデータベースの外部表として表します。誰でもこのファイルをREAD可能です。 $ hadoop fs -ls /data/weather/central_park_weather.csv -rw-r--r-- 3 oracle oinstall 26103 2017-10-24 13:03 /data/weather/central_park_weather.csv では、最初のマッピングを作成します。ユーザーbikesをOSのユーザーuser1にマッピングします。 SQL> begin DBMS_BDSQL.ADD_USER_MAP( current_database_user =>'BIKES', syscontext_namespace => null, syscontext_parm_hadoop_user => 'user1' ); end; / パーミッションテーブルを確認します。   クエリを実行します。 SQL> select /*+ MONITOR */ * from bikes.weather_ext; 監査ファイルではユーザーuser1がファイルを読んだことを確認できます。(ugi=user1) $ cd /var/log/hadoop-hdfs $ tail -f hdfs-audit.log |grep central_park 2018-03-01 17:42:10,938 INFO ... ugi=user1... ip=/10.0.0.10 cmd=open ... src=/data/weather/central_park_weather.csv.. 監査ファイルではユーザーuser1がファイルを読んだことを確認できます。(ugi=user1) (user1はHadoop OS上には存在しませんが、このように監査されます。) # id user1 id: user1: No such user ユーザーが存在しない場合(user1の場合)、777権限を持つファイルしか読み取れません。全員の読み取り許可を取り消して、もう一度問い合わせを実行してみます。 $ sudo -u hdfs hadoop fs -chmod 640 /data/weather/central_park_weather.csv $ hadoop fs -ls /data/weather/central_park_weather.csv -rw-r----- 3 oracle oinstall 26103 2017-10-24 13:03 /data/weather/central_park_weather.csv   クエリは失敗しました。これを動作させるために、各Hadoopノードにuser1アカウントを作成し、oinstallグループに追加します。 $ useradd user1 $ usermod -a -G oinstall user1 クエリを再度実行し(成功します)、ファイルを読み取ったユーザーを確認します。 SQL> select /*+ MONITOR */ * from bikes.weather_ext; $ cd /var/log/hadoop-hdfs $ tail -f hdfs-audit.log |grep central_park 2018-03-01 17:42:10,938 INFO ... ugi=user1... ip=/10.0.0.10 cmd=open ... src=/data/weather/central_park_weather.csv.. user1でファイルを成功に読み取りました。user1がグループoinstallに所属するため、読み取ることができます。 このスキーマをhdfsや他のユーザーにマッピングしたい場合、以下を実施します。 SQL> begin DBMS_BDSQL.REMOVE_USER_MAP (current_database_user =>'BIKES'); DBMS_BDSQL.ADD_USER_MAP( current_database_user =>'BIKES', syscontext_namespace => null, syscontext_parm_hadoop_user => 'hdfs' ); end; /   例外が発生した原因は、ユーザーhdfsがimpersonationのブラックリストに載っていることです。 $ cat $ORACLE_HOME/bigdatasql/databases/orcl/bigdata_config/bigdata.properties| grep impersonation .... # Impersonation properties impersonation.enabled=true impersonation.blacklist='hue','yarn','oozie','smon','mapred','hdfs','hive','httpfs','flume','HTTP','bigdatamgr','oracle' ...   シナリオ2 次のシナリオはシンクライアントまたはCLIENT_IDENTIFIERによって認証を行います。多層アーキテクチャの場合(アプリケーション層とデータベース層がある場合)、同一のスキーマを使用する複数のユーザーを、同じアプリケーション内で区別することは難しいです。 ユーザーHR_APPとして、データベースに接続するアプリケーションがあります。多くのユーザがこのアプリケーションを使用して、データベースにログインします。これらのユーザを区別するために、dbms_session.set_IDENTIFIERプロシージャを使います。(詳細はこちらで確認できます) 従って、Big Data SQLのマルチユーザー認証機能は、ユーザーSYS_CONTEXTを使用して、Hadoopで認証できます。以下にテストケースを示します。 -- Remove previous rule, related with BIKES user -- SQL> begin DBMS_BDSQL.REMOVE_USER_MAP (current_database_user =>'BIKES'); end; / -- Add a new rule, which tells that if database user is BIKES, Hadoop user have to be taken from USERENV as CLIENT_IDENTIFIER -- SQL> begin DBMS_BDSQL.ADD_USER_MAP( current_database_user =>'BIKES', syscontext_namespace => 'USERENV', syscontext_parm_hadoop_user => 'CLIENT_IDENTIFIER' ); end; --Check current database user (schema) -- SQL> select user from dual; BIKES -- Check CLIENT_IDENTIFIER from USERENV -- SQL> select SYS_CONTEXT('USERENV', 'CLIENT_IDENTIFIER') from dual; NULL -- Run any query aginst Hadoop -- SQL> select /*+ MONITOR */ * from bikes.weather_ext; -- check in the Hadoop audit logs -- -bash-4.1$ tail -f hdfs-audit.log |grep central_park 2018-03-01 18:14:40 ... ugi=oracle ... src=/data/weather/central_park_weather.csv -- Set CLIENT_IDENTIFIER -- SQL> begin dbms_session.set_IDENTIFIER('Alexey'); end; / -- Check CLIENT_IDENTIFIER for current session -- SQL> select SYS_CONTEXT('USERENV', 'CLIENT_IDENTIFIER') from dual; Alexey -- Run query agin over HDFS data -- SQL> select /*+ MONITOR */ * from bikes.weather_ext; -- check in the Hadoop audit logs: -- -bash-4.1$ tail -f hdfs-audit.log |grep central_park 2018-03-01 18:17:43 ... ugi=Alexey ... src=/data/weather/central_park_weather.csv   シナリオ3 このシナリオは、ユーザー認証IDを使います。データベースに接続するユーザーは、認証されたIDをHadoopに渡します。 これを動作するために、以下のコマンドを実行します。   SQL> begin DBMS_BDSQL.ADD_USER_MAP( current_database_user => '*' , syscontext_namespace => 'USERENV', syscontext_parm_hadoop_user => 'AUTHENTICATED_IDENTITY'); end; / その後、HDFS上のユーザーは以下のように返されます。 SQL> select SYS_CONTEXT('USERENV', 'AUTHENTICATED_IDENTITY') from dual; BIKES 例えば、bikes(データベースユーザー)としてデータベースにログオンした場合、HDFS上ではbikesユーザーとして認証されます。 $ tail -f hdfs-audit.log |grep central_park 2018-03-01 18:23:23 ... ugi=bikes... src=/data/weather/central_park_weather.csv 以下のクエリを実行して、マルチユーザー認証に使用するルールを確認できます。 SQL> select * from SYS.BDSQL_USER_MAP; このマルチユーザー認証の機能により、HDFS上のデータに強固なセキュリティを構成できるようになります。 本投稿は Big Data SQL Quick Start. Multi-user Authorization - Part 25. を元に投稿しています。

Big Data SQLのメリットの1つは、セキュリティです。Oracle Databaseを利用して、HDFSやその他のソースに格納されたデータを処理します。そのため、Data Redaction、VPD、Database Vaultなどの多くのデータベース機能を適用できます。これらの機能は、データベース・スキーマと権限を組み合わせて、侵入者がデータベース側からデータにアクセスしようとする場合、デ...

Big Data Management

Big Data SQL - Storage Index

Big Data SQLの強力な機能である、Storage Indexについて説明しましょう。はじめに、Storage Indexという名前は誤解を招くかもしれませんが、それは動的であり、データスキャン後に自動的に作成されます。特別なコマンドや特別な何かを実行する必要はありません。(B-Tree Indexのように)再構成のようなメンテナンスの必要もありません。ワークロードを実行するとそのうちにより良い性能を得ることができます。 Storage IndexはBig Data SQLのための完全に新しいもの、というわけではありません。Oracle Exadataもこの機能を持っており、Big Data SQLではそれを再利用しています。 どのように動くか 主要な点は、スキャンの単位にメタデータを作成することです。例えば、あるクエリ(いくつかの述語をWHERE句に持つ、例えばwhere id =123のような)でHDFSブロックをスキャンするとします。もしこのブロックが行を返さないなら、このブロックに対し、この列に対する統計値(最大値や最小値)を作成します。 次回スキャンでは、この統計値を使用して、スキャンをスキップすることができます。 これはユニークな列値に対して非常に強力な機能です。Hadoopの場合、Storage IndexのためのFine-Granuleユニットは、HDFSブロックです(HDFSブロック単位に最大値・最小値を持ちます)。ご存知のように、HDFSブロックはとても大きく(Big Data Appliance ではデフォルト 256MB)もしスキップすることが出来れば、大幅な性能向上が得られるでしょう。 クエリはグラニュル単位でスキャンされ、もし行を返さなければ、Storage Indexが作成されます(もしブロック内で1行でもHitする場合は、Storage Indexはこのブロックに対しては作成されません)。 HDFSデータは通常3つのコピーを持ちます。性能を最大化するにはStorage Indexからの便益をできるだけ速く得ることであり、Big Data SQL(3.1以降)ではホスト(Hadoopのノード)の順番によって決定されます。 一度テーブルをスキャンしStorage Indexを最初のレプリカに作成すると、2回目のスキャンではコピーに対してもStorage Indexが適切に使用されます。 では、Storage Indexの悪い例・良い例を紹介しましょう。ユニークな列を持つテーブルがあります。 SQL> SELECT num_distinct FROM user_tab_col_statistics WHERE table_name = 'STORE_SALES_CSV' AND COLUMN_NAME = 'SS_TICKET_NUMBER'; num_distinct ------------ 849805312 これはとても大きなテーブルです。(多くの行を持ちます) SQL> select count(1) from STORE_SALES_CSV ------------------- 6 385 178 703 これらが意味するのは、それぞれの値は7~8回登場すような、極めてSelectiveな列(選択性が高い列)であるということです。(テーブル全体では900.1GBのデータセット)。Storage Indexがどのように動くかを見るのに、以下のようなクエリを実行します。(2行を返す)。 SQL> select count(1) from STORE_SALES_CSV where SS_TICKET_NUMBER=187378862; 1度目の実行は、大量のIOとCPUを消費し10.6分かかりました。2回目以降の実行は極めて高速で、3秒で終わりました(なぜなら、Storage Indexにより、実行したクエリのWhere句条件に確実にマッチしないブロックを知ることができるから)。Storage Indexの効果を知るために、以下のSQLを実行してセッション統計を確認します。 SQL> SELECT n.name, CASE NAME WHEN 'cell XT granule predicate offload retries' THEN VALUE WHEN 'cell XT granules requested for predicate offload' THEN VALUE ELSE round(VALUE / 1024 / 1024 / 1024,2) END Val, CASE NAME WHEN 'cell XT granule predicate offload retries' THEN 'Granules' WHEN 'cell XT granules requested for predicate offload' THEN 'Granules' ELSE 'GBytes' END Metric FROM v$mystat s, v$statname n WHERE s.statistic# = n.statistic# AND n.name IN ('cell XT granule IO bytes saved by storage index', 'cell XT granule bytes requested for predicate offload') ORDER BY Metric; ------------------------------------------------------------------------------------- cell XT granule IO bytes saved by storage index 899.86 GBytes cell XT granule bytes requested for predicate offload 900.11 GBytes   この統計によると、READしたのは256MB(=cell XT granule bytes requested for predicate offload - cell XT granule IO bytes saved by storage index)だけであり、これはHDFSブロック1つということです。 最初のスキャン 実環境においてStorage Indexを無効化することは推奨しませんが、1つだけ副次効果があります。Storage Indexを有効化している場合は、無効化している場合と比較し、最初の1回目のスキャンが遅くなる可能性がある点です。先の例では、最初のスキャンは10.6分でしたが、2回目以降の実行はすべて数秒でした。 ストレージインデックスを無効化すると、1回目も2回目もそれ以降も変わらず同じ時間がかかります。(約5.1分) これらの実行時間について纏めると以下です。 実行時間(ストレージインデックスが有効) 1回目のスキャン: 10.3分 2回目のスキャン:  3秒 実行時間(ストレージインデックスを無効化したとき) 1回目のスキャン: 5.1分 2回目のスキャン: 5.1分 セレクティブではない述語を持つクエリ(WHERE句であまり絞り込めないクエリ) 先の例を考慮すると、Storage Indexは1回目の実行で性能劣化をもたらしていますが、セレクティブではない述語をもつクエリに対してはどうなるか、を、確認してみると興味深いです。このテーブルはSS_QUANTITY列を持ち、それは1~100の、100種類の値しかありません。   SQL> SELECT num_distinct FROM user_tab_col_statistics WHERE table_name = 'STORE_SALES_CSV' AND COLUMN_NAME = 'SS_QUANTITY'; ------------ 100 SQL> SELECT min(SS_QUANTITY, max(SS_QUANTITY) FROM STORE_SALES_CSV ---- ------ 0 100 ストレージインデックスが有効な状態で次のクエリを3回実行しました。 SQL> select count(1) from STORE_SALES_CSV where SS_QUANTITY=82; すると3回とも実行時間は5.3分でした。これはたくさんの行がHitします。(ただしSELECT結果としてはCOUNTしているので1行ですが) しかし、0行Hitするような検索、つまり、WHERE SS_QUANTITY=-1のように存在しない述語を指定すると、 SQL> select count(1) from STORE_SALES_CSV where SS_QUANTITY=-1; 実行時間は冒頭の例のように、1回目の実行は10.5分、2回目以降は3秒で完了します。 最後にStorage Indexを無効化してテストを繰り返すと、いずれも5.3分でした。 この内容を纏めると以下のとおりです。 実行時間(Storage Indexが有効) 1回目(多くの行がHitする場合): 5.3分 2回目(多くの行がHitする場合): 5.3分 1回目(0行がHitする場合): 10.5分 2回目(0行がHitする場合): 3秒 実行時間(Storage Indexが無効化している場合) 1回目(多くの行がHitする場合): 5.3分 2回目(多くの行がHitする場合): 5.3分 1回目(0行がHitする場合): 5.3分 2回目(0行がHitする場合): 5.3分 これらをもとに以下のことが推測できます。 Storage Indexはブロックが行を返さない場合のみ作成される ブロックが1行でも行を返すなら、SI(Storage Index)は作成されない つまり、1回目の実行で性能劣化がなければ、2回目以降の実行でSIによる性能向上は得られないことを意味する Order By 先程の例で、セレクティブではない述語を持つクエリ(ソートしない限りはStorage Indexにとってよくないクエリ)を見てきました。 データがソートされている場合は、どうでしょうか?新しいデータセット(テーブル)を、オリジナルの表をベースに、ソートしながらHiveQLで作成します。 hive> create table csv.store_sales_quantity_sort stored as textfile as select * from csv.store_sales order by SS_QUANTITY; その後、多くの行がHitする先のクエリを2回実行します。(FROM STORE_SALES_CSV を、今作成したHive表:store_sales_quantity_sortを元にした表に置き換えて実行しています) 多くの行がHitするクエリであるにもかかわらず、2回目の実行が高速化していることがわかります。Storage Indexが使われました。このことを統計値から証明します。 cell XT granule IO bytes saved by storage index 601.72 GBytes cell XT granule bytes requested for predicate offload 876.47 GBytes 列がどのようにソートされているかを分析したりするには、このツールも使えます。 Bucketing 性能を大幅に向上させるもうひとつのトリックはBucketingです。それは値の種類の数を知っている場合や、distinct valueの最大値を知っている場合にのみ有効です。もし事前にQuery述語を知っていれば(上の例ではSS_QUANTITY=<値>)以下のように最適化された形でデータを準備するかもしれませんね。 次の文では100個のファイルを作成し、それぞれのファイルはそれぞれに対応する値を持ちます(理想的な場合はそうなるが、そうではない場合はHASH分散のようになる)。 hive> CREATE TABLE csv.store_sales_quantity_bucketed( ss_sold_date_sk bigint, ss_sold_time_sk bigint, ss_item_sk bigint, ss_customer_sk bigint, ss_cdemo_sk bigint, ss_hdemo_sk bigint, ss_addr_sk bigint, ss_store_sk bigint, ss_promo_sk bigint, ss_ticket_number bigint, ss_quantity int, ss_wholesale_cost double, ss_list_price double, ss_sales_price double, ss_ext_discount_amt double, ss_ext_sales_price double, ss_ext_wholesale_cost double, ss_ext_list_price double, ss_ext_tax double, ss_coupon_amt double, ss_net_paid double, ss_net_paid_inc_tax double, ss_net_profit double) CLUSTERED BY (SS_QUANTITY) INTO 100 BUCKETS ROW FORMAT DELIMITED FIELDS TERMINATED BY '|' stored as textfile; hive> set hive.enforce.bucketing = true; hive> insert overwrite table csv.store_sales_quantity_bucketed select * from csv.store_sales; Oracle外部表を作成し、クエリを2回実行すると、Storage Indexのもたらす効果を確認できます。 外部表を作成し、以下のクエリを実行します。 SQL> select count(1) from STORE_SALES_CSV_QUANTITY_BUCK where SS_QUANTITY= 82; .... elapsed time: 822 sec SQL> select count(1) from STORE_SALES_CSV_QUANTITY_BUCK where SS_QUANTITY= 82; .... elapsed time: 8 sec SQL> SELECT * FROM xt_stat; cell XT granule IO bytes saved by storage index 867.53 GBytes cell XT granule bytes requested for predicate offload 876.47 GBytes 2回目の実行では、実行時間が大幅に削減できている理由として、8.94GBのデータしかREADしていません。もしWHERE句の述語に現れる列でバケットすれば、BucketingとStorage Indexによって、大幅な性能改善をもたらします。 JOINとStorage Index ブルームフィルターを使ったJOINにおいて、Storage Indexはとても強力で便利な機能になります。このことを先の例を使って示しましょう。STORE_SALES_CSV_QUANTITY_BUCKと、小さい表(2行のみを持つ)をJOINします。 SQL> CREATE TABLE test_couple_rows AS SELECT 3 q FROM dual UNION ALL SELECT 4 q FROM dual; では大きなファクト表(SS_QUANTITY列でバケットされている)と、SS_QUANTITY列をJOIN述語としてJOINします。 (Bloom Filterを使うかどうかはOptimizer判断ですが、それが選択されたとします。) SQL> SELECT /*+ use_hash(tt ss)*/ COUNT(1) FROM test_couple_rows tt, STORE_SALES_CSV_QUANTITY_BUCK SS WHERE ss.Ss_Quantity = tt.q AND tt.q>0; 実行計画を確認します。Bloom Filterが使われていることがわかります。 クエリの実行時間は12秒でした。多くのIOを除去できたことが、以下の統計値からわかります。Storage Indexよ、ありがとう! cell XT granule IO bytes saved by storage index 859.91 GBytes cell XT granule bytes requested for predicate offload 876.47 GBytes 本投稿は Big Data SQL Quick Start. Storage Indexes - Part10. を元に投稿しています。  

Big Data SQLの強力な機能である、Storage...

Big Data Management

Big Data SQL - データ型と型変換

Big Data SQLの性能を向上する簡単な方法を共有しましょう。Big Data SQLは2つの主要なピース(DatabaseとHadoop)を持つ、複雑なシステムです。それぞれのシステムはそれぞれのデータ型 - Oracle RDBMSとJava – を持ちます。Oracle Databaseからクエリを実行する度にデータ型変換が発生します。データ変換はCPU負荷の高い処理です。 AVRO, RCFile, ORC and Parquet files. Hadoopサーバに着目すると、内部的には複数のコンポーネント、Hadoop Part(Data Node)とOracle Part(Smart Scan)があります。さらに”External Table Service”(Big Data SQLソフトウェアの一部)があり、ここでデータ型の変換を行います(ここでCPUをたくさん消費) ここで良いニュースがあります。既にETLを実行済みでソースデータからParquetまたはORCに変換されているなら、適切なマッピング(Hiveデータ型からOracle Databaseのデータ型へ)によって、データ変換をすることなく、パススルーすることができます。変換表はこちら。百聞は一見に如かず、ということで例を見てみましょう。ここにHive表(ORCファイル)があります。 hive> show create table store_sales; OK CREATE TABLE store_sales( ss_sold_date_sk bigint, ss_sold_time_sk bigint, ss_item_sk bigint, ss_customer_sk bigint, ss_cdemo_sk bigint, ss_hdemo_sk bigint, ss_addr_sk bigint, ss_store_sk bigint, ss_promo_sk bigint, ss_ticket_number bigint, ss_quantity int, ss_wholesale_cost double, ss_list_price double, ss_sales_price double, ss_ext_discount_amt double, ss_ext_sales_price double, ss_ext_wholesale_cost double, ss_ext_list_price double, ss_ext_tax double, ss_coupon_amt double, ss_net_paid double, ss_net_paid_inc_tax double, ss_net_profit double) ROW FORMAT SERDE 'org.apache.hadoop.hive.ql.io.orc.OrcSerde' STORED AS INPUTFORMAT 'org.apache.hadoop.hive.ql.io.orc.OrcInputFormat' OUTPUTFORMAT 'org.apache.hadoop.hive.ql.io.orc.OrcOutputFormat' LOCATION 'hdfs://bds30-ns/user/hive/warehouse/orc.db/store_sales' そしてOracle RDBMSに外部表を2つ作成します。 1つ目のテーブルはHIVEのDOUBLE型をOracleのNUMBER(7,2)と定義します。 SQL> CREATE TABLE STORE_SALES_ORC_NUM ( SS_SOLD_DATE_SK NUMBER(10,0), SS_SOLD_TIME_SK NUMBER(10,0), SS_ITEM_SK NUMBER(10,0), SS_CUSTOMER_SK NUMBER(10,0), SS_CDEMO_SK NUMBER(10,0), SS_HDEMO_SK NUMBER(10,0), SS_ADDR_SK NUMBER(10,0), SS_STORE_SK NUMBER(10,0), SS_PROMO_SK NUMBER(10,0), SS_TICKET_NUMBER NUMBER(10,0), SS_QUANTITY NUMBER(10,0), SS_WHOLESALE_COST NUMBER(7,2), SS_LIST_PRICE NUMBER(7,2), SS_SALES_PRICE NUMBER(7,2), SS_EXT_DISCOUNT_AMT NUMBER(7,2), SS_EXT_SALES_PRICE NUMBER(7,2), SS_EXT_WHOLESALE_COST NUMBER(7,2), SS_EXT_LIST_PRICE NUMBER(7,2), SS_EXT_TAX NUMBER(7,2), SS_COUPON_AMT NUMBER(7,2), SS_NET_PAID NUMBER(7,2), SS_NET_PAID_INC_TAX NUMBER(7,2), SS_NET_PROFIT NUMBER(7,2) ) ORGANIZATION EXTERNAL ( TYPE ORACLE_HIVE DEFAULT DIRECTORY DEFAULT_DIR ACCESS PARAMETERS ( com.oracle.bigdata.cluster=bds30 com.oracle.bigdata.tablename=orc.store_sales) ) REJECT LIMIT UNLIMITED PARALLEL ; 2つ目のテーブルはマッピングマトリックスの定義に従って、HiveのDOUBLE型を、OracleのNUMBER(7,2)ではなく、BINARY_DOUBLEで定義します。 パフォーマンステストでは10同時実行で行い、それぞれのクエリは列でフィルタリング(列の値でWHERE句による絞込が発生)する。1つ目のテーブルではDOUBLE→NUMBERのデータ型変換が発生し、2つ目のテーブルではDOUBLE→BINARY_DOUBLEのデータ型変換が発生します。 SQL> SELECT COUNT(1) FROM STORE_SALES_ORC WHERE ss_net_paid_inc_tax=:bind 全10クエリは、ほぼ同時に終了しました。データ型の変換と実行時間は以下の通りです。 double (hive) → number (oracle) : 16.1分 ※マッピングは適切か?NO double (hive) → binary_double (oracle): 10.8分 ※マッピングは適切か?YES 適切なデータ型のマッピングを行うことで、より良いパフォーマンスが得られました。背後で何が起きているか見てみましょう。 CPU使用率はどちらの場合も、とても高いです。 CPU上限に達しており、次はIOスループットが興味深いメトリックとなります。 1つ目のテーブルでは複雑なデータ変換であるため、Cell側で多くのCPU時間を使用しCPUバウンドになりそれ以上速くREADできません。2つ目のテーブルではデータ変換がないので、データを単にSmart Scanステップにパスするだけです。 TextFiles と Sequence Files. AVRO, RCFile, ORC, Parquetであればいいのだが、テキストファイルやSequenceFileの場合は、全く違った動きをします。HadoopのCSVファイルのInputFormatはバイトストリームをREADします。テキスト行(通常は改行コードで終端とされている)を読み、列のパースを行います。どのように動くか順を追って説明します。 Javaパートの”External Table Service”がHDFSブロックをREADし、Cのbyte bufferに送る Cパートの”External Table Service”が、バッファを改行コードでパースし行を見つける Cパートの”External Table Service”が、行を “|”でパースし列の値を見つける。ここでは常にString(文字列)として扱う。例えば”-11.52” のように。(数字ではなく常に文字列として) Cパートの”External Table Service”が、見つかった文字列 -11.52をOracleのNUMBER型に変換する ここでの違いは、最初の例のString型→IEEE バイナリ浮動小数点(OracleのBINARY_DOUBLE)への変換よりも、String型→OracleのNUMBERへの変換のほうが、はるかに効率が良いことが挙げられます。 このことを確かめるために、先に作成したような例でテストを行います。今回はCSVファイルで格納したHive表に対し、外部表を作成しテストします。1つはNUMBERで、もう一つはBINALY_DOUBLEを使用します。   SQL> CREATE TABLE STORE_SALES_CSV_NUM ( SS_SOLD_DATE_SK NUMBER(10,0), SS_SOLD_TIME_SK NUMBER(10,0), SS_ITEM_SK NUMBER(10,0), SS_CUSTOMER_SK NUMBER(10,0), SS_CDEMO_SK NUMBER(10,0), SS_HDEMO_SK NUMBER(10,0), SS_ADDR_SK NUMBER(10,0), SS_STORE_SK NUMBER(10,0), SS_PROMO_SK NUMBER(10,0), SS_TICKET_NUMBER NUMBER(10,0), SS_QUANTITY NUMBER(10,0), SS_WHOLESALE_COST NUMBER(7,2), SS_LIST_PRICE NUMBER(7,2), SS_SALES_PRICE NUMBER(7,2), SS_EXT_DISCOUNT_AMT NUMBER(7,2), SS_EXT_SALES_PRICE NUMBER(7,2), SS_EXT_WHOLESALE_COST NUMBER(7,2), SS_EXT_LIST_PRICE NUMBER(7,2), SS_EXT_TAX NUMBER(7,2), SS_COUPON_AMT NUMBER(7,2), SS_NET_PAID NUMBER(7,2), SS_NET_PAID_INC_TAX NUMBER(7,2), SS_NET_PROFIT NUMBER(7,2) ) ORGANIZATION EXTERNAL ( TYPE ORACLE_HIVE DEFAULT DIRECTORY DEFAULT_DIR ACCESS PARAMETERS ( com.oracle.bigdata.cluster=bds30 com.oracle.bigdata.tablename=csv.store_sales) ) REJECT LIMIT UNLIMITED PARALLEL ; 2つ目の表ではNUMBER(7,2)の代わりに、BINARY_DOUBLEで定義します。 SQL> CREATE TABLE STORE_SALES_CSV ( SS_SOLD_DATE_SK NUMBER(10,0), SS_SOLD_TIME_SK NUMBER(10,0), SS_ITEM_SK NUMBER(10,0), SS_CUSTOMER_SK NUMBER(10,0), SS_CDEMO_SK NUMBER(10,0), SS_HDEMO_SK NUMBER(10,0), SS_ADDR_SK NUMBER(10,0), SS_STORE_SK NUMBER(10,0), SS_PROMO_SK NUMBER(10,0), SS_TICKET_NUMBER NUMBER(10,0), SS_QUANTITY NUMBER(10,0), SS_WHOLESALE_COST BINARY_DOUBLE, SS_LIST_PRICE BINARY_DOUBLE, SS_SALES_PRICE BINARY_DOUBLE, SS_EXT_DISCOUNT_AMT BINARY_DOUBLE, SS_EXT_SALES_PRICE BINARY_DOUBLE, SS_EXT_WHOLESALE_COST BINARY_DOUBLE, SS_EXT_LIST_PRICE BINARY_DOUBLE, SS_EXT_TAX BINARY_DOUBLE, SS_COUPON_AMT BINARY_DOUBLE, SS_NET_PAID BINARY_DOUBLE, SS_NET_PAID_INC_TAX BINARY_DOUBLE, SS_NET_PROFIT BINARY_DOUBLE) ORGANIZATION EXTERNAL ( TYPE ORACLE_HIVE DEFAULT DIRECTORY DEFAULT_DIR ACCESS PARAMETERS ( com.oracle.bigdata.cluster=bds30 com.oracle.bigdata.tablename=csv.store_sales ) REJECT LIMIT UNLIMITED PARALLEL; 性能テストのために、フルテーブルスキャンするクエリを使います。(実はこのクエリは統計情報を収集する際に実行するクエリです) SQL> SELECT to_char(COUNT(SS_SOLD_DATE_SK)), substrb(dump(MIN(SS_SOLD_DATE_SK),16,0,64),1,240), substrb(dump(MAX(SS_SOLD_DATE_SK),16,0,64),1,240), ... to_char(COUNT(SS_NET_PROFIT)), substrb(dump(MIN(SS_NET_PROFIT),16,0,64),1,240), substrb(dump(MAX(SS_NET_PROFIT),16,0,64),1,240) FROM STORE_SALES_CSV 2つ目の表にも同様に実行: SQL> SELECT to_char(COUNT(SS_SOLD_DATE_SK)), substrb(dump(MIN(SS_SOLD_DATE_SK),16,0,64),1,240), substrb(dump(MAX(SS_SOLD_DATE_SK),16,0,64),1,240), ... to_char(COUNT(SS_NET_PROFIT)), substrb(dump(MIN(SS_NET_PROFIT),16,0,64),1,240), substrb(dump(MAX(SS_NET_PROFIT),16,0,64),1,240) FROM STORE_SALES_CSV_NUM 結果は以下のように異なりました。 string (hive) → number (oracle): 18分 String→OracleのNUMBER型への変換を実施 string (hive) → binary_double (oracle): 64分 String→Oracleの binary_double 型への変換を実施、これは非常に高負荷な処理 以下のグラフからも、BINARY_DOUBLE型への変換はCPUを多く消費することが明白です。 重要: HadoopでParque, ORC, RC, AVROフォーマットでDOUBLE型を使用している場合にOracle RDBMSでBINARY_DOUBLE型を定義すると、この場合はデータ型変換は行われません。データをOracle SmartScanのために直接パスするだけです。 テキストファイルやSequencefileの場合は、常にデータ変換が行われます(なぜならText Inputformatは常に文字列とみなされるから)。その場合は、最も軽い方法を選択するべきです(BINARY_DOUBLEではなく、NUMBER(7,2)を選択します)。 本投稿は Big Data SQL Quick Start. Data types - Part8. を元に投稿しています。

Big Data SQLの性能を向上する簡単な方法を共有しましょう。Big Data SQLは2つの主要なピース(DatabaseとHadoop)を持つ、複雑なシステムです。それぞれのシステムはそれぞれのデータ型 - Oracle RDBMSとJava – を持ちます。Oracle Databaseからクエリを実行する度にデータ型変換が発生します。データ変換はCPU負荷の高い処理です。 AVRO,...

Big Data Management

Big Data SQL - Partition Pruning

パーティションはデータウェアハウスやあらゆる種類のデータベースで共通のテクニックです。読者の皆さんはパーティションとは何か?ということはよくご存知だと思うので割愛します。必要に応じてOracle RDBMSの例を参照下さい。 Hiveパーティション Hiveは元々HDFS上にMapReduceでWriteするための簡単な方法として開発されました。HDFSはファイルシステムで、Linuxライクな構造を持ちます。従って、パーティションと見なすのはとても簡単で、サブディレクトリにするだけです。ここで2つの表を挙げます。大きなファクト表:STORE_SALESと、小さなディメンジョン表:DATE_DIMです。それらは以下の関係を持ちます。   ファクト表(STORE_SALES)は明確な時刻識別子は持たないが、ディメンジョン(dictionary)との関係性がありDATA_DIM表で明確にデータ定義されています (d_domは日、d_moyは月、d_yearは年)。ではパーティション化されたSTORE_SALES表を作成しましょう。 SQL> CREATE TABLE store_sales_part( ss_sold_date_sk bigint, ... ss_net_profit double) partitioned by ( yearINT, month INT, day INT) stored as ORC; 上の文は3つの仮想列(YEAR, MONTH, DAY)を持つパーティション表を作成しています。データをこのHive表に入れる前に、ダイナミックパーティショニングに必要な、いくつかのパラメータを追加します。   hive> SET hive.exec.dynamic.partition=true; hive> SET hive.exec.dynamic.partition.mode=nonstrict; hive> SET hive.exec.max.dynamic.partitions =10000; hive> INSERT INTO TABLE store_sales_part PARTITION (year, month, day) hive> SELECT store_sales.*, dt.d_year, dt.d_moy, dt.d_dom FROM store_sales, date_dim dt WHERE dt.d_date_sk = store_sales.ss_sold_date_sk;   INSERT後、HDFS上でどのように分散されているかを確認します。 $ hadoop fs -du -h /user/hive/warehouse/orc.db/store_sales_part/*/*/|tail -2 168.5 M 505.5 M /user/hive/warehouse/orc.db/store_sales_part/year=2005/month=9/day=8 168.7 M 506.0 M /user/hive/warehouse/orc.db/store_sales_part/year=2005/month=9/day=9   新しいパーティション表:STORE_SALES_PARTは3つの仮想列を持ち、仮想列は実際Disk上には格納されないが(=Disk上のスペースを取らないが)、不必要なIOを避けるのに使うことができます。さらに、これらの列はHIVEコンソールから問い合わせることができます。   hive> select ss_sold_date_sk, year, month, day from store_sales_part limit 2; OK 36890 2001 1 1 36890 2001 1 1   Great! ではOracle RDBMSの番、このHive表にリンクされたテーブルを作成します。 SQL> CREATE TABLE STORE_SALES_ORC_PART (SS_SOLD_DATE_SK NUMBER(10,0), .... SS_NET_PROFIT BINARY_DOUBLE, YEAR NUMBER, MONTH NUMBER, DAY NUMBER) ORGANIZATION EXTERNAL (TYPE ORACLE_HIVE DEFAULT DIRECTORY DEFAULT_DIR ACCESS PARAMETERS ( com.oracle.bigdata.cluster=bds30 com.oracle.bigdata.tablename=orc.store_sales_part) ) REJECT LIMIT UNLIMITED PARALLEL; Oracleの外部表として、パーティションプルーニングできる表が作成できました。このことを確かめてみましょう。パーティションキーでのPredicateが無いクエリを実行します。 SQL> SELECT COUNT(1) FROM STORE_SALES_ORC_PART; 実行後、統計値を確認します。 SQL> SELECT n.name, round(s.value / 1024 / 1024 / 1024) FROM v$mystat s, v$statname n WHERE s.statistic# = 462 AND s.statistic# = n.statistic#; -------------------------------------------- cell XT granule bytes requested for predicate offload 298 ディレクトリのサイズを確認してみます。 $ hadoop fs -du -h -s /user/hive/warehouse/orc.db/store_sales_part/ 297.8 G 893.5 G /user/hive/warehouse/orc.db/store_sales_part ディレクトリサイズは298GBで、上の統計値に合致します。全ては正しく動いていますね。 では、特定の年に絞ったクエリを実行します。 SQL> SELECT COUNT(1) FROM STORE_SALES_ORC_PART WHERE YEAR=2004; データベースの統計値を確認します。 SQL> SELECT n.name, round(s.value / 1024 / 1024 / 1024) FROM v$mystat s, v$statname n WHERE s.statistic# = 462 AND s.statistic# = n.statistic#; -------------------------------------------- cell XT granule bytes requested for predicate offload 60 HDFS上のファイルサイズを確認し比較します。 $ hadoop fs -du -h -s /user/hive/warehouse/orc.db/store_sales_part/year=2004 60.3 G 893.5 G /user/hive/warehouse/orc.db/store_sales_part 60GB分だけREADしていることが分かります。 しかし最も興味深いのは、サブパーティションでもフィルタできることです。例えば、全ての年の12月のデータだけ欲しいとします。次のように、12月パーティションだけREADします: SQL> SELECT COUNT(1) FROM STORE_SALES_ORC_PART WHERE MONTH=12; データベースの統計値を確認します。 SQL> SELECT n.name, round(s.value / 1024 / 1024 / 1024) FROM v$mystat s, v$statname n WHERE s.statistic# = 462 AND s.statistic# = n.statistic#; -------------------- cell XT granule bytes requested for predicate offload 23 素晴らしいことに、HDFS上のデータサイズの合計値とぴったり一致します。 $ hadoop fs -du -h -s /user/hive/warehouse/orc.db/store_sales_part/*/month=12 5.1 G 15.3 G /user/hive/warehouse/orc.db/store_sales_part/year=2001/month=12 5.1 G 15.3 G/user/hive/warehouse/orc.db/store_sales_part/year=2002/month=12 5.1 G 15.3 G /user/hive/warehouse/orc.db/store_sales_part/year=2003/month=12 5.1 G 15.3 G /user/hive/warehouse/orc.db/store_sales_part/year=2004/month=12 2.1 G 6.3 G /user/hive/warehouse/orc.db/store_sales_part/year=2005/month=12 シンプルだがパワフルな機能です!   本投稿は Big Data SQL Quick Start. Partition Pruning - Part7. を元に投稿しています。  

パーティションはデータウェアハウスやあらゆる種類のデータベースで共通のテクニックです。読者の皆さんはパーティションとは何か?ということはよくご存知だと思うので割愛します。必要に応じてOracle RDBMSの例を参照下さい。 Hiveパーティション Hiveは元々HDFS上にMapReduceでWriteするための簡単な方法として開発されました。HDFSはファイルシステムで、Linuxライクな構造を持ち...

Big Data Management

Big Data SQL 3.2.1 が公開されました

お知らせです。Oracle Big Data SQL 3.2.1が公開されました。このリリースでは、Oracle Database 12.2.0.1をサポートしています。主要な点は: 現在Big Data SQL 3.2 をご利用中のお客様はこのUpdateを適用する必要はありません。このUpdateはOracle Database 12.2.0.1をサポートするためのものです。 Big Data SQL 3.2.1はOracle Database 12.1.0.2とOracle Database 12.2.0.1の両方で使用可能です。 Oracle Database 12.2.0.1での使用には、April Release Update と、BDS3.2.1のためのone-off patchが必要です。 ソフトウェアはARUから入手できます。Big Data SQL 3.2.1のインストーラーはまもなくOracle Software Delivery Cloud(旧称 eDelivery)から入手できます。 Big Data SQL 3.2.1 インストーラー(Patch 29071671) 注:これは完全なインストーラーです。パッチではありません。 Oracle Database 12.2.0.1 April Release Update (Patch 27674384). Grid Infrastructureを利用の場合は、GIも同様に12.2.0.1 April Release Updateを適用してください Big Data SQL 3.2.1用の(April RU上に適用する)one-off (Patch 26170659)。ダウンロードページから適切なリリースを選択してください。このone-offも、Database ServerとGrid Infrastructureの両方に適用します。 なお、Big Data SQL チュートリアルシリーズもぜひご覧ください。このシリーズではBig Data SQLの機能の理解に役立つ、多くのビデオがあります。 Oracle Big Data Lite Virtual MachineとHadoopの紹介 Big Data SQLの紹介 HadoopとBig Data SQLのアーキテクチャ Big Data SQLのパフォーマンス関連機能 Information Life Management 本投稿は Big Data SQL 3.2.1 is Now Available の抄訳です。必要なパッチに関する最新情報はMy Oracle Supportもあわせてご参照ください。

お知らせです。Oracle Big Data SQL 3.2.1が公開されました。このリリースでは、Oracle Database 12.2.0.1をサポートしています。主要な点は: 現在Big Data SQL 3.2 をご利用中のお客様はこのUpdateを適用する必要はありません。このUpdateはOracle Database 12.2.0.1をサポートするためのものです。 Big Data...

Big Data and Data Integration - Japan

データから価値を創出する鍵:それはData Preparation(データの前処理)

アナリティクスプロジェクトの成功は、分析データの品質に依存します。一方で、データの価値が認められた現在のビジネス環境において、企業は膨大で多様なデータを収集しているが、種類も量も指数関数的に増加しており、それらを分析のために使いやすい形式に変換するコストは大きな課題のひとつです。 Data Preparation(前処理)の難しさ たとえば、分析の前には異なるデータセットを結合したり、粒度を整えるために集計したり、null値を補填したり、データの重複を排除したり、データの型を合わせたりと分析の8割は前処理と言われるようにプログラミング工数と処理のリソース両面で負荷がかかります。 これらのタスクは、通常IT部門のナレッジで対応できますが、昨今、分析プロジェクトのオーナーシップが業務部門にシフトしているため、より問題が顕著になっています。業務部門の中にもPythonやRなどを用いてデータの前処理を行える人材がいるケースがあるが、それをビッグデータに対してスケールさせる術に長けているとは限りません。その結果、処理依頼がIT部門へのバックログとして、時として数週間を要します。 これらの課題を認識している企業は data preparation technologiesにより解決を図ることができます。フォレスター社の調査(research from Forrester)によると、増大するデータの課題に対して2/3の企業がdata preparationツールの導入を検討しており、すでに56%が導入していると言われています。 昨今のData preparationツールは、IT専門知識を持つ人に限らず、企業が”前処理”を含む全ての分析プロセスを個々のビジネスラインに広げることを可能にします。これによりデータ分析のボトルネックが解消されるだけでなく、業務部門が率先して分析を行うことにより洞察精度の向上が期待できます。 ビッグデータを有効活用する仕組み 様々なデータソースからの溢れかえる膨大なデータを正しく制御し、ビジネス全体で一貫性を保ちながらアクセス可能であることも重要です。例えば、CaixaBank(CaixaBank is storing vast pools of data )は、データレイクとして1つの統合プラットフォームにビッグデータを格納しており、各事業部門は必要に応じて単一のデータソースとして関連データにアクセスし、分析することが可能です。 データレイクが構築されることにより、企業は新しいアイデアを探索するためにデータを使った試行錯誤(データドリブン)が可能になります。例えば、テレフォニカ(Telefonica worked with a single view of its data )は、TV配信コンテンツを顧客別にパーソナライズし、最適な価格を算出するアルゴリズムをテストするためにデータレイクを使用しました。PoCの後、テレフォニカはこのアルゴリズムを実装し、コンバージョンレートが向上し、顧客の解約率20%低下しました。 ビジネスにおけるデータの価値が高まりつつある中、企業がデータの管理と監督を強化するために強力な規制の推進力があります。EUのGDPR(EU’s GDPR )が発行され、顧客情報の収集・使用・共有の仕方に対して透明性が求められ、違反が認められる場合には厳しい罰則が課せられます。 まとめ データドリブンによる新しいビジネスを手掛けていくためには、Data preparationは、企業の最重要課題であり、ビッグデータを扱う上での最優先事項です。 毎日データに向き合うデータサイエンティストやアナリストからビジネスリーダーまで、オラクルは組織内のすべての人に豊富な統合ソリューションを提供しています。 本資料は、Oracle Big Data blog(https://blogs.oracle.com/bigdata/big-data-preparation-value)を抄訳したものです。

アナリティクスプロジェクトの成功は、分析データの品質に依存します。一方で、データの価値が認められた現在のビジネス環境において、企業は膨大で多様なデータを収集しているが、種類も量も指数関数的に増加しており、それらを分析のために使いやすい形式に変換するコストは大きな課題のひとつです。 Data Preparation(前処理)の難しさ たとえば、分析の前には異なるデータセットを結合したり、粒度を整えるた...

Big Data Management

Big Data SQL - Predicate Push Down機能

Big Data SQLは、version 3.0からPredicate Push Down(PPD)という素晴らしい機能があります。PPDはORCファイル、Parquetファイル、いくつかのNoSQL Database(HBaseのような)に対し有効です。ここではORCとParquetファイルのケースを説明しましょう。ORCとParquetはどちらのファイルも同じアプローチなので、ORCで説明します。もしこれらのファイルタイプについて詳しくなければ、ParquetやORCに関する文章を読むことを推奨します。 ORCファイルはメタデータを内部に持ちます。値の最小値・最大値を10,000行ごとに持ちます。(10,000はデフォルト値で、orc.row.index.strideパラメータで定義されます) このことは、スキャンすべきストライプとそうではないストライプを高速に見極められることを意味します。例えば、PK列のように、極めて一意性の高い列をスキャンするなら、これは多くのIO処理をスキップすることができます。 例を見てみましょう。2つにストライプ化されたテーブルを検索したいとします。それぞれのストライプに含まれる、B列の値の最大値・最小値は以下の図のとおりとします。 もしWHERE B=6 なら、最初のストライプはスキップ可能です。もしWHERE B=15なら、両方のストライプをスキップ可能です。 Big Data SQL ワークフロー Big Data SQLがどのように動くか説明しましょう。STOCK_PRICES表がORC(またはParquet)形式でHDFS上にあるとします。以下のクエリを実行します。 SQL> SELECT ticker, AVG(price) OVER (PARTITION BY ticker ORDER BY mnth) as avg_price FROM stock_prices WHERE mnth < :x AND mnth > :y AND stx_xchange = :z ORDER BY mnth; ワークフローは以下です。 1). DiskからデータをREADし、External Table Service 層に送る 最初のステップでは、DiskからデータをREADします。ここでは少しだがとても効果的な最適化を施すことができます。 Column Pruning:仮にstock_price表が100列あるとすれば、クエリで4列しかリストしていないので(ticker, price, mnth, stx_xchange)、他の96列はDiskから読まずに済む Predicate Push Down:例では、WHERE句にある列と2つの文をプッシュする必要があります。ORC索引を使うとREADの一部分を除去することができます。WHERE句の指定に確実にマッチしないデータはREADしません。 mnth < :x AND mnth > :y AND stx_xchange = :z Column PruningとPredicate Push Downをどうやって実現するかを指し示す図を1枚お借りします。(引用元) 2). Oracle RDBMSフォーマットに変換し、SmartScanに送る 2番目のステップでは、HDFSフォーマット(Binary, Avro, ORC, Parquet)からOracle RDBMSフォーマットに変換します。これはとてもCPU intensiveなステップで、SarDeの適用とOracle RDBMSのデータ型への変換を行います。行や列を事前にプルーニング(除去)できていれば、CPU枯渇を防ぐことができますね。ひとつ前のステップの、Predicate Push Down機能よ、ありがとう! 3). Smart Scan 次のステップは、WHERE句に対しSmart Scanを適用します。 mnth < :x AND mnth > :y AND stx_xchange = :z Predicate Push Downがデータの一部を除去するものであれば、Smart Scanはきっちりと厳密にフィルターします。更に、ただPredicate(述語処理)だけではなく、関数処理を行います。スマートスキャンが可能な関数は以下のSQLで得られます。 SQL> SELECT * FROM v$sqlfn_metadata WHERE offloadable = 'YES'; 4). Oracle RDBMS パート このステップは私の絵の範囲外ですが、少しご紹介します。全ての関数がスマートスキャンで適用されるわけではありません(例えばPL/SQLやウィンドウ関数)。この部分はDatabaseにパスされます。今回のクエリの例では、AVG(price) OVER (PARTITION BY ticker ORDER BY mnth) as avg_price や、ORDER BYは、データベース層で実行されます。   Predicate Push Downの良い/悪いユースケース Predicate Push Down機能の良い/悪いユースケースをテストするために、Intel Big Benchから巨大なテーブルを使用します。 SQL> SELECT COUNT(1) FROM BDS.store_sales_orc; 6 385 178 703 rows データはZLIB コーデックで圧縮されています。(ORCのデフォルト) $ hadoop fs -du -s -h /user/hive/warehouse/orc.db/store_sales/ 297.8 G 893.5 G /user/hive/warehouse/orc.db/store_sales 以下のSQLで、テーブルの統計情報より、「最もSELECTIVEな列」、「最もSELECTIVEではない列」を確認します。user_tab_col_statistics(列の統計情報を格納)より、列の値の種類が最も多い列(最もSELECTIVEな列)と、最も少ない列(最もSELECTIVEではない列)を検索しています。 SQL> SELECT * FROM (SELECT num_distinct, Column_name FROM user_tab_col_statistics WHERE table_name = UPPER('STORE_SALES_ORC') ORDER BY num_distinct FETCH FIRST 1 ROW ONLY) UNION ALL SELECT * FROM (SELECT num_distinct, Column_name FROM user_tab_col_statistics WHERE table_name = UPPER('STORE_SALES_ORC') ORDER BY num_distinct DESC FETCH FIRST 1 ROW ONLY); ------------------------------------------- 100 SS_QUANTITY 849805312 SS_TICKET_NUMBER 最もSELECTIVEな列: SS_TICKET_NUMBER 最もSELECTIVEではない列: SS_QUANTITY ここから2つの外部表を作成します。STORE_SALES_ORC表は、Predicate Push Downが可能な表、もう片方STORE_SALES_ORC_NOPPD表は、その機能を無効にします。Predicate Push Downはデフォルトで有効ですが、無効にするには以下のようにCREATE TABLE時にcom.oracle.bigdata.ppd=FALSEパラメータを追加することで設定できます: CREATE TABLE STORE_SALES_ORC_NOPPD ( ... ) ORGANIZATION EXTERNAL ( TYPE ORACLE_HIVE DEFAULT DIRECTORY "DEFAULT_DIR" ACCESS PARAMETERS ACCESS PARAMETERS ( ... com.oracle.bigdata.ppd=FALSE ) ではテストをはじめましょう。 1). 「最もSELECTIVEではない列」でフィルタリング SQL> SELECT COUNT(1) FROM store_sales_orc WHERE SS_QUANTITY=6; 63849869 →実行時間: 89秒 SQL> SELECT COUNT(1) FROM store_sales_orc_noppd WHERE SS_QUANTITY=6; 63849869 →実行時間: 84秒 2). 「最もSELECTIVEな列」でフィルタリング SQL> SELECT COUNT(1) FROM store_sales_orc WHERE SS_TICKET_NUMBER=187378860; 2 →実行時間: 9秒 SQL> SELECT COUNT(1) FROM store_sales_orc_noppd WHERE SS_TICKET_NUMBER=187378860; 2 →実行時間: 87秒   3). Join Predicate Push Down機能はJOIN処理をも加速化することができるかもしれません。全てのJOINではないが、WHERE句に述語処理があり、かつ暗黙的にNested Loopで実行されるような場合です。 大きなファクト表(store_sales_orc 表またはstore_sales_orc_noppd 表、それぞれ6,385,178,703 行)を、小さなディメンジョン表date_dim_orc 表(109,573行)とJOINしてみましょう。 デモ用途で、Nested Loopを強制させるようヒントを追加します。(本番システムではやらないように!Optimizerに任せましょう) PPD(Predicate Push Down)が利用可能な表に対するクエリ: SQL> SELECT /*+ use_nl(store_sales_orc)*/ dt.d_year, SUM(ss_ext_sales_price) sum_agg FROM date_dim_orc dt, store_sales_orc WHERE dt.d_date_sk = store_sales_orc.ss_sold_date_sk AND dt.d_moy = 12 AND dt.d_dom = 24 AND dt.d_year = 2004 GROUP BY dt.d_year ORDER BY dt.d_year,sum_agg DESC FETCH FIRST 100 ROWS ONLY; PPD不可の表に対しても、上のクエリのテーブル名store_sales_orcを、store_sales_orc_noppdに変えて実行します。 どちらも同じ実行計画を持ちます: STORE_SALES表にPredicateを持ちます   PPD有効な表(STORE_SALES_ORC)で実行:実行時間  11秒 PPD無効な表(STORE_SALES_ORC_NOPPD)で実行:実行時間 128秒 STORE_SALES表(ファクト表)から小さなデータセットしか必要ではない場合にのみ、この機能の効果が得られます。データのほとんど全てが必要な場合は、それほど効果的ではありません。 注:この違いはJOINがNested Loopの場合のみ発生します 4). 累積のPredicate Predicateは累積です、すなわち、「SELECTIVEではない列」(BDSにとっては嬉しくない)であっても、複数指定することで、Predicateが積み重なりデータセットはSELECTIVEになり(=とても絞り込まれた状態)性能も向上します。先の例で、5つの「SELECTIVEではない列」でPredicateを指定します。 SQL> SELECT /*+ MONITOR*/ COUNT(1) FROM store_sales_orc SS WHERE ss.Ss_Quantity = 84 AND ss.Ss_Store_Sk = 21 AND ss.Ss_Sold_Date_Sk = 38046 AND ss.Ss_Promo_Sk = 90 AND ss.ss_hdemo_sk = 3702;   Predicate Pushdownをどうやって確認するか Predicate Pushdownが動作したかを確認するには、実行計画を確認する必要があります。その方法は一般的に2つあり、Enterprise ManagerまたはExplain Planです。       両方のケースでHDFS上の大きな表にPredicateが存在することを確認するべきです。 Findings Predicate Push DownはSelective Query(少ない行を返す)に効果的です。完璧に動作します。 Predicate Push DownはUnselectiveな場合は少し遅くなります(全てのストライプのスキャン時に、インデックス検索分の余分なオーバヘッドがかかるため)。しかしその差は小さく、無視できます。 Column Projectionは常に適用されます。データ型変換ではたくさんのCPUを必要とするがこれがセーブできるので、とてもよいことです。 大きなファクト表から少数のデータを必要とするようなJOINも、高速化されることがあります。(それがNested Loopで動く場合)     本投稿は Big Data SQL Quick Start. Predicate Push Down - Part6. を元に投稿しています。  

Big Data SQLは、version 3.0からPredicate...

Big Data Management

データレイクのソリューションパターン

 ビッグデータソリューション は、様々なレイヤーのテクノロジーで構成されており、今日ではより複雑な構成になってきています。 我々は、正しいアーキテクチャを選択するために、目的別にアーキテクチャを整理する必要があります。 ソリューションパターン (または、デザインパターンと呼ばれる) は、私たちがシステムの全体構成を理解する事に役立ちます。細かい木々には言及しませんが、システム全体を大きな森として俯瞰することができます。 この記事では、データレイクのいくつのかのソリューションパターンを紹介します。データレイクは、多くの用途を持ち、様々なビジネス上の課題に対するソリューションを提供する重要な役割を果たします。 ここで説明するソリューションパターンは、最も一般的なビッグデータのユースケースに対処するために、データレイクを他のテクノロジと組み合わせた例を示します。オラクルのPaaSクラウドサービスを使用して、クラウドベースのソリューションに焦点を当てます。 データレイク 4つのソリューションパターン: データサイエンスラボ データウェアハウスのETLオフロード ビッグデータ機械学習 ストリーミング分析 1.データサイエンスラボ ソリューションパターン  まず最初に、データサイエンスラボのユースケースから説明します。データサイエンスのためのツールを利用してディスカバリや実験を行うため我々は「ラボ」と表現しています。 データサイエンスラボは、新しいデータの理解や既存データに対する新しいモデルの検討、また、異なるデータセットの結合などを行うことで、ビジネス課題解決のための機械学習を試行するための環境です。  パターンの説明に入る前に、図の読み方を説明しておきます。青色の各ボックスはオラクルのクラウドサービスを表します。その枠内にあるグレーのボックスはその中で提供されている代表的なサービスを示しており、矢印は各サービス間のデータフローを意味します。 データサイエンスラボは、データレイクとデータビジュアライゼーションプラットホームが含まれます。データレイクはOracle Big Data Cloud に含まれる オブジェクトストレージとSparkおよび関連ツールで構成されます。 Oracle Analytics Cloud はデータの可視化およびデータの前処理のためのデータフローやRDBMSとデータレイクのマッシュアップ機能などを提供します。 また Oracle Database Cloud Service 上にメタデータを管理します。 データレイクのオブジェクトストアは、SwiftクライアントまたはOracle Software Applianceを利用して作成されます。 2.データウェアハウスのETLオフロード ソリューションパターン データウェアハウスは、企業が最も大事とするビジネスデータをビジネスインテリジェンスのために管理する重要なツールです。リレーショナルデータベース上に構築されるデータウェアハウス は、高度に構造化されています。しががって、データウェアハウスにロードされる前に、データを目的の構造に変換する必要があります。 この変換処理は、場合によってはデータウェアハウスに重大な負荷となり、オペレーションコストを上昇させる可能性があります。その変換処理を他のプラットホームにオフロードすることで、必要な変換のレベルに応じてオペレーションコストを削減し、データウェアハウスの真の目的である、データを提供する役割に集中することができます。 Oracle’s Data Integration Platform Cloud (DIPC) は、データウェアハウスのデータ抽出・ロードおよび変換のための主要ツールです。Oracle Database Cloud Serviceでメタデータ管理を行います。ELT処理を利用して、データが存在する場所でデータ変換が実行されます。 ロード前に追加の変換処理が必要な場合(ETL)、または新しい種類のデータを追加する場合は、データをオブジェクトストレージに一時的にステージングし、Sparkを使用して処理できます。またこれにより、Oracle Autonomous Data Warehouse Cloud.の機能である、データレイクに直接クエリ可能なテクノロジを利用し、データウェアハウスを拡張することが可能です。 3.ビッグデータ機械学習 ソリューションパターン Advanced analyticsは、機械学習、地理空間分析、グラフ分析技術を使用してデータ解析を行うデータレイクの最も一般的な事例です。ビッグデータに対する高度な分析機能は、データラボをエンタープライズ向けに拡張したものとも言えます。 また、ラボでは少数のプロセッサとストレージを使用する場合がありますが、高度な分析パターンでは、ワークロードの要求に合わせてシステムを拡張できます。 Oracle Data Integration Platform Cloudは、ソースでデータを取得し、オブジェクトストレージに格納するリモートエージェントを提供します。Oracle Big Data CloudのSparkに直接展開する事も可能です。一般的には、これは変換処理は実行されるジョブを定期的に自動実行する定型バッチとして利用されます。 処理結果のデータセットは、Oracle Analytics Cloudを使ってビジネスユーザーおよびアナリストがビジュアライゼーションや分析することができます。 4.ストリーミング分析 ソリューションパターン ストリーミングデータに焦点を当てたBig Data Advance Analyticsのひとつです。ストリーミングデータは、データ生成と同時に提供とされ、多くの場合、リアルタイムな処理を求められます。 ストリームアナリティクスは不正行為の検出(detecting fraud)や取引パターンを検知し購買に関する予測などに使用されます。また、ジオフェンスを併用して、対象が地理的境界への侵入を検知し、そこからアクションを行うことができます。 ビジネスデータは、Oracle Data Integration Platform Cloudのリモートエージェントがソースデータとして取得し、Oracle Event Hub Cloud Service. のApache KafkaのTopiCにパブリッシュされます。Spark StreamingでKafka Topicをサブスクライブし、特定イベントの検索や、時系列分析、またリアルタイムなアクションなどを行います。 オープンデータやモバイルアプリケーションのデータなど、kafkaに直接パブリッシュできるデータソースについても、Sparkのジョブで処理できます。検出されたイベントや機械学習の予測結果は、下流のアプリケーションやビジネスプロセスで利用するために、他のKafka Topicにパブリッシュされます。 まとめ ここで示した4つのソリューションパターンは、データレイクの使用開始にむけて参考になるかと思います。しかしながら、実際には複数のパターンを組み合わせることもあります。オラクルでは、共通のオブジェクトストアにアクセスできるOracle Big Data Cloudのインスタンスを簡単に作成し、どのような組み合わせのソリューションでも実現することが可能なのです。   本資料は、Oracle Big Data blog(https://blogs.oracle.com/bigdata/data-lake-solution-patterns-use-cases)を抄訳したものです。 The Documents contained within this site may include statements about Oracle’s product development plans. Many factors can materially affect Oracle’s product development plans and the nature and timing of future product releases. Accordingly, this Information is provided to you solely for information only, is not a commitment to deliver any material, code, or functionality, and SHOULD NOT BE RELIED UPON IN MAKING PURCHASING DECISIONS. The development, release, and timing of any features or functionality described remains at the sole discretion of Oracle. THIS INFORMATION MAY NOT BE INCORPORATED INTO ANY CONTRACTUAL AGREEMENT WITH ORACLE OR ITS SUBSIDIARIES OR AFFILIATES. ORACLE SPECIFICALLY DISCLAIMS ANY LIABILITY WITH RESPECT TO THIS INFORMATION. Refer to the LEGAL NOTICES AND TERMS OF USE (http://www.oracle.com/html/terms.html) for further information.

 ビッグデータソリューション は、様々なレイヤーのテクノロジーで構成されており、今日ではより複雑な構成になってきています。 我々は、正しいアーキテクチャを選択するために、目的別にアーキテクチャを整理する必要があります。 ソリューションパターン...

Big Data Management

Big Data SQL - JOIN性能を向上するBloom Filter(ブルーム・フィルター)

Big Data SQLはOracle Databaseから素晴らしい機能を継承しています。ひとつはBloom Filter(ブルーム・フィルター)の活用です。この機能はOracle10g以降で利用可能で、JOIN性能の向上に使われます。具体例を示す前に、Bloom Filterとは何かを説明しましょう。 Bloom Filter 概要 1). Input Bloom Filterは「要素Xは集合Yに存在するか?」というシンプルな問いに答える事ができるデータ構造です。答えは「絶対に違う」もしくは「存在するかもしれない」のどちらかになります。 Bloom Filterはビット配列であり、Bloom Filter の「配列の長さ」と、「複数のハッシュ関数(値に対し、配列の長さに準じた値を返す、例えば配列長が12なら1~12のどれかを返す)」が定義されています。 これから、集合Y("oracle",  "database", "filter"の3つの要素からなる)に、ある要素(例:"bytes")は、存在するか?について、調べていきます。 Input: データセット ※このデータセット(=集合Y)に対して、Bloom Filterを作成していきます。 集合Y ["oracle",  "database", "filter"] Bloom Filterの長さ。ここではBloom Filterの配列の長さを12とします。 ハッシュ関数のセット。ここでは次の3つのハッシュ関数:h1, h2, h3 があり、それぞれは1~12の数値を返します。(なぜなら配列の長さを12と決めたから) Bloom Filter 概要 2). Bloom Filter の作成 Bloom Filterを作成するには、 それぞれのハッシュ関数を、集合Yのそれぞれの要素に適用する 上で得られた結果でBloom Filterにマーキングする これらを以下に図示します。例えば、h1("oracle")=1、つまり、ハッシュ関数 h1 に "oracle"をかけた結果は1なので、ビット配列であるBloom Filterの1番目にマークをつけます。     実際には、Bloom Filter配列内の各要素に、いくつのチェックがついているかは気にしないので、このFilterをBooleanでマークし直します。(1つ以上のマークがついたかどうかをTRUE or FALSEで示します。)     集合Y("oracle", "database", "filter")に対するBloom Filterの作成が完了し、利用する準備ができました。 Bloom Filter 概要 3). Bloom Filter を使用 さあ、Bloom Filterを使いましょう。今ここに集合Y("oracle", "database", "filter")があり、この配列にある要素が存在するか否かをチェックしなければなりません。 まず、要素="oracle"の存在をチェックしたいとします。ここで必要なのは、全てのハッシュ関数を"oracle"に適用した結果を計算し、Bloom Filterとの適合をチェックすることです。   "oracle"は、Bloom Filterの全ての埋められた要素と一致するので、答えは「この要素は集合Yに含まれるかもしれない」。しかしなぜ「かもしれない」なのでしょうか?他の例を挙げて考えてみましょう。 次に、"Alex"という要素がこの集合Yに存在するかどうかをチェックしたいです。 Bloom Filterの1番目, 2番目, 7番目のマークを確認してみると、 Bloom Filterの要素1はTRUEとマークされている、なぜならh1("oracle")=1 Bloom Filterの要素2はTRUEとマークされている、なぜならh1("database")=2 Bloom Filterの要素7はTRUEとマークされている、なぜならh2("filter")=7 従って、要素"Alex"に対するハッシュ関数の結果は、Bloom Filterに合致します。つまり、要素"Alex"は、Bloom Filterのマーク済み要素と全て一致するので、答えは「"Alex"は集合Yに含まれるかもしれない」です。 では、Bloom Filterの利点は何でしょうか?それは「絶対違う」といえる場合です。次の例として、要素 "byte"の存在を確認してみましょう。 h2("byte")が6を返すがこれはFALSEです。つまり、要素"byte"は、集合Yの中に絶対に含まれません。 このように、「絶対違う」場合に、何かをしなくてよい(Oracle DatabaseのBloom Filter を使ったJOINでの例でいうと、データをJOIN対象としなくてよい)ことが、Bloom Filterを使うメリットになります。 実行計画でBloom Filterを確認しよう Oracle DatabaseでBloom Filterを使うのに、2つのステップが必要です。小さいテーブルに対しBloom Filterを作成し、それを大きなテーブルに適用することです。これらのステップは実行計画では"JOIN FILTER CREATE"と"JOIN FILTER USE"として現れます。   Bloom Filter と Big Data SQL: テーブルが全てHadoopにある場合 実際のケースに適用してみましょう。巨大なファクト表と、小さなディメンション表を用意します。どちらもHadoop上に格納されています。 SQL> SELECT COUNT(1) FROM store_sales_orc; 6385178703 SQL> SELECT COUNT(1) FROM date_dim_orc; 109573   テスト目的でクエリを準備します。TPCDSベンチマークテストから選びました。実行計画を読みやすくするために、NOPARALLELヒントを使用しました。 SQL> SELECT * FROM (SELECT /*+ NOPARALLEL*/ dt.d_year, SUM(ss_ext_sales_price) sum_agg FROM date_dim_orc dt, store_sales_orc WHERE dt.d_date_sk = store_sales_orc.ss_sold_date_sk AND dt.d_moy = 12 GROUP BY dt.d_year ORDER BY dt.d_year, sum_agg DESC) WHERE rownum <= 100; 実行計画は以下です。 実行計画などから、次のことが分かります。 小さい表(DATA_DIM_ORC)に対しBloom Filterが作成される(“JOIN FILTER CREATE” ステップ)。軽い処理。 大きい表(STORE_SALES_ORC)に対し Bloom Filterが適用される(“JOIN FILTER USE”ステップ)。重い処理。 Bloom Filterは91%のデータを除去した。(Actual Rows列より598M行と表示されているが、これはSTORES_SALES_ORC表の行数の9%である)。Bloom Filterの効果は、テーブルの実際行で割ることで計算できるだろう これらの全てのステップはHadoop側で行われている(Database側ではない) Databaseは最終的なJOINを行う ではどのくらいの量のデータがデータベースに転送されたか見てみましょう。2つの統計に注目します。 "cell XT granule bytes requested for predicate offload" スキャンすべきデータサイズ(ディスク上にどれくらいのデータがあるか) "cell interconnect bytes returned by XT smart scan" データベースに転送されたサイズ SQL> SELECT n.name, round(s.value/1024/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 229 cell interconnect bytes returned by XT smart scan 10 上記より、Databaseに転送されたのは10GBです。悪くないですね。 Bloom Filter と Big Data SQL: テーブルがDatabaseとHadoopにある場合 2つ目のテストケースを説明しましょう。巨大なファクト表はHadoopにあり、小さなディメンジョン表はDatabaseに格納されています。これは、極めて一般的な例です。なぜならディメンジョン表は頻繁に更新されるかもしれず(Database向き)、ファクト表は通常更新されない(Hadoop向き)からです。 同じテストを、テーブル名だけを変更して実行します。 SQL> SELECT * FROM (SELECT /*+ NOPARALLEL*/ dt.d_year, SUM(ss_ext_sales_price) sum_agg FROM date_dim_db dt, store_sales_orc WHERE dt.d_date_sk = store_sales_orc.ss_sold_date_sk AND dt.d_moy = 12 GROUP BY dt.d_year ORDER BY dt.d_year, sum_agg DESC) WHERE rownum <= 100; 実行計画は同じです。 同じアプローチが使われていますが、1点だけ異なります。Bloom FilterはDatabase側で作成され(軽い処理)、それをHadoop(Cell)側に転送し、大きな表に対し適用しています。統計もよく似ています。 SQL> SELECT n.name, round(s.value/1024/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 229 cell interconnect bytes returned by XT smart scan 8 性能の観点からはこれらのクエリはよく似ており、同じ実行時間を要します。(なぜならクエリの大部分の時間はBloom FilterをSTORE_SALES_ORC表に適用するところだからです) まとめ Bloom Filterは「要素Xは集合Yに存在するか?」というシンプルな問いに、「絶対に違う」もしくは「存在するかもしれない」で答えることができるもの Oracle Databaseの機能で、Bloom Filterを使ってJOINする機能がある これは、JOIN前にファクト表の行数をBloom Filterで削減することで、高速化が期待できる Big Data SQLでも、このOracle Databaseの機能を継承しており、Hadoop上にある大きなファクト表から「絶対に違う」データを除去するのに使用される 本投稿はBig Data SQL Quick Start. Joins. Bloom Filter and other features - Part5.を元に投稿しています。  

Big Data SQLはOracle Databaseから素晴らしい機能を継承しています。ひとつはBloom Filter(ブルーム・フィルター)の活用です。この機能はOracle10g以降で利用可能で、JOIN性能の向上に使われます。具体例を示す前に、Bloom Filterとは何かを説明しましょう。 Bloom Filter 概要 1). Input Bloom Filterは「要素Xは集合Yに存...

Big Data Management

Big Data SQL - Parallel Queryを実行

もちろん、全てのクエリがオフロードできるわけではないし、SQLの全てのパートがCell(Storage)側で実行できるわけではありません。極めて複雑なクエリや、PL/SQLを含むものもあります。そのようなクエリの性能向上には、Oracle Databaseのパラレルクエリを使うことができます。パラレルクエリは、Big Data SQLと一緒に使うこともできるし、ユーザやアプリケーション側からは全く違いがない(意識しなくて良い)のも利点です。 今回は2つのSQLを、それぞれシリアルクエリ・パラレルクエリとして実行した場合を見ていきます。 ①:ある複雑なクエリ ここで、ある複雑なクエリを見てみましょう。そのクエリは多くのフィルタリングリソースと、データベースリソース(ソート処理など)も必要です。オフロードできない関数である、RANKを見てみましょう。 SQL> select NAME, offloadable, AGGREGATE FROM v$sqlfn_metadata WHERE NAME = 'RANK'; NAME OFF AGG ------- --- --- RANK NO NO RANK NO YES RANK関数を使うクエリを準備します。 SQL> SELECT /*+ NOPARALLEL */ RANK() OVER(PARTITION BY ws.ws_bill_customer_sk ORDER BY ws.ws_ship_date_sk), ws.ws_item_sk FROM WEB_SALES ws WHERE ws.ws_sold_date_sk > 245 OFFSET 500000 ROWS FETCH NEXT 10 ROWS ONLY; まずは、シリアルモードで実行し(/*+ NOPARALLEL */ ヒントで指定)、結果を見てみましょう。Oracle Enterprise ManagerのSQL Monitorを使います。 データベース側で多くのCPUイベントの発生が確認できます。 次に、同じクエリをパラレル度を変えて実行してみます。/*+ PARALLEL(4) */ ヒントでパラレル度=4を指定。 SQL> SELECT /*+ PARALLEL(4) */ RANK() OVER(PARTITION BY ws.ws_bill_customer_sk ORDER BY ws.ws_ship_date_sk), ws.ws_item_sk FROM WEB_SALES ws WHERE ws.ws_sold_date_sk > 245 OFFSET 500000 ROWS FETCH NEXT 10 ROWS ONLY; 最初と同じクエリを実行していますが、データベース側のパラレル度が異なります。データベース側の処理が速く実行できればできるほど、より多くのIO待機(Storage Waits) を見ることになります。ストレージを待機するほど十分に速く、処理が進んでいるということです。 更に、Hadoop側で何が起きているか、Hadoop側のDisk使用率を見てみましょう。 グラフ左側:シリアルクエリは、低いIOワークロード これはDatabase側の処理の遅延に伴うもので、言い換えると、Database側は、Hadoopから届くデータを処理しきれるだけの十分なリソースを持っていないということです。 Cellのパラレル度は、データベースのパラレル度に直接は依存しないが、副作用として変わりうる(このクエリの例のように)。 グラフ右側:パラレルクエリは、高いIOワークロード(Disk使用率が100%近い) パラレル度を上げると、データベースがより多くのCPUリソースを投入でき、結果、HadoopのI/Oパワーをほぼ使い切っています。結果、実行時間は短縮しました。 実行時間: シリアル(DOP=1): 7.1分 パラレル(DOP=4): 3.2分 ※DOP=Degree of Parallelism, パラレル度 この結果は、Big Data SQLがこのケースで有益ではないことを示すものではありません。データ型変換と列のプルーニングはStorageサイドで行われます。このSQLでよりよい性能を得るには、データベース側のパラレル化が必要でした。 ②:仕事のほとんどをCell側で行うようなクエリ それゆえに、仕事のほとんどをCell側で行うようなクエリでは、シリアルクエリとパラレルクエリの実行時間の差は小さくなります。次の例で試してみましょう。 SQL> SELECT /*+ noparallel monitor*/ COUNT(1) FROM WEB_SALES ws WHERE ws.ws_sold_date_sk = 2451507 AND ws.ws_sold_time_sk=70565 AND ws.ws_bill_customer_sk=19628510 AND ws.ws_ext_discount_amt=4433.48;   待機イベントのほとんど(99%)が、”cell external table smart scan” であり、Cell側に関連するものです。そして、パラレル実行の場合に何が起きているか見てみると興味深いです。 上のクエリを /*+ parallel(4) */ ヒントに変えて実行します。 待機イベントは同じく、”cell external table smart scan” です。前の例のクエリとは異なり、実行時間とCell Disk Utilizationは、シリアル実行もパラレル実行もほぼ同じです。 実行時間: シリアル(DOP=1): 3.1分 パラレル(DOP=4): 2.9分 この理由は、すべての処理はCell側で行われ、データベース側のパラレル度は処理時間に影響しなかったからです。   Cell側(Hadoop側)のパラレル度 実際は、Cell側(Hadoopノード)も独自のパラレル度を持っています。ユーザがそれを制御することは出来ません。しかし実際は、それぞれのCell(Hadoopノード)が複数のブロックをパラレルに処理しています。シリアルクエリを実行した場合、Cell側の全てのパラレルスレッドと連動します。 上の図のように、それぞれのCell (Hadoopノード)は独自のパラレル度を持ちます(ここではNとする)。シリアルクエリはこれら全てのパラレルスレッドと協調して動きます。   パラレルクエリの例では、Query Coordinator(QC)が存在し、QCはパラレル実行プロセス(PX)を制御します。それぞれのパラレル実行プロセス(PX)は、自分に割り当てられたパートのCell(Hadoop)から届く入力データを扱うことと、その部分のパラレルスレッドと協調して動く責任があります。   上の図はデータベースのパラレル度がDOP=2で、そのときにそれぞれのPXがCell側のパラレルスレッドAおよびBをそれぞれ制御する様子を示します。 重要なのは、AとBの合計が、Nスレッドであることです。つまり、データベース側で異なるDOPを指定しても(例えば、/*+ noparallel */, /*+ parallel(4) */, /*+ parallel(32) */)、Cell側(Hadoop側)では、同じパラレル度になる、ということです。 本投稿はBig Data SQL Quick Start. Parallel Query - Part3.を元に投稿しています。

もちろん、全てのクエリがオフロードできるわけではないし、SQLの全てのパートがCell(Storage)側で実行できるわけではありません。極めて複雑なクエリや、PL/SQLを含むものもあります。そのようなクエリの性能向上には、Oracle Databaseのパラレルクエリを使うことができます。パラレルクエリは、Big...

Big Data Management

オブジェクトストレージを使用したAutonomous Data Warehouse Cloudとビッグデータの統合

Oracle Autonomous Data Warehouseに格納されているデータを使用してビジネスを実行することは可能ですが、そこには他にも価値のあるデータが多数あります。 Oracle Big Data Cloudを使用すると、そのデータを格納および処理し、 Autonomous Data Warehouse Cloudにロードする前準備ができます。 これら2つのサービスの統合ポイントは、 オブジェクト・ストレージです。   データレイクとDWHの使用例 ほとんどすべてのビッグデータの使用事例には、 データレイクとDWHの両方をうまく使い分けています。 たとえば、 予測メンテナンスでは、データレイクに格納されているセンサーデータとDWHに格納されている保守および購入記録を組み合わせることが必要です。 また、Customer360として特定の顧客のためにソリューションを決定しようとするときは、顧客の購入記録(データウェアハウス内)と顧客のWebブラウジングまたはソーシャルメディアの行動履歴を組み合わせることでより良い洞察を得られます。 予測メンテナンスのためのデータレイクとDWH 例として予測メンテナンスを行います。 正式なメンテナンス記録と購入または保証情報はすべてビジネスにとって重要です。 規制当局が適切なプロセスが遵守されているかどうかをチェックしたり、予算を管理したり新しいコンポーネントを注文するために購買部門に必要な場合があります。 一方、機械、気象観測所、温度計、地震計などのセンサ情報はすべて、一部の機器の動作を理解し予測するのに役立つ可能性のあるデータを生成します。 DWH管理者に、未処理の、多分あまり理解されていないマルチ構造の数テラバイトのデータを保存するよう依頼した場合、それほど最適ではありません。 この種のデータは、データレイクに適しており適切な前処理を施すことで、 機械学習アルゴリズムの入力データとして使用できます。 しかし最終的には、両方のデータセットを結合して、障害または許容範囲外に移動するコンポーネントを予測する必要があります。 例:オブジェクトストレージとDWHの連携 オブジェクトストレージはクラウド時代に最適なデータレイク基盤です。 オブジェクト・ストレージは、とりわけ、バックアップおよびアーカイブ、DWHのデータのステージング、またはそこに保管されていないデータのオフロードに使用されます。 さきほどの予測メンテナンスの使用例に戻りましょう。 オブジェクト・ストレージ内のデータ・レイクにロードされた後、センサデータは、 Oracle Big Data Cloudによって起動されたSparkクラスタで処理されます。 この「処理」は、単純なフィルタまたは結果の集約から、隠されたパターンを明らかにするための複雑な機械学習アルゴリズムの実行まで、さまざまなことが行われます。 その作業が完了すると、結果の表がオブジェクト記憶域に書き戻されます。 その時点で、それはAutonomous Data Warehouseにロードされるか、またはその場で参照されます。 どちらのアプローチが最適ですか? ユースケースによって異なります。 一般的に、そのデータに頻繁にアクセスするか、クエリのパフォーマンスが重要な場合は、 Autonomous Data Warehouseにロードすることが最適です。 ここでは、オブジェクト階層をストレージ階層の別の層と考えることができます(Autonomous Data Warehouseにはすでにストレージ階層としてRAM、フラッシュ、ディスクがあります)。 また、ETLオフロードユースケースでも同様のアプローチを見ることができます。 生データはオブジェクト記憶域にステージングされます。 変換プロセスは、1つ以上のBig Data Cloud Sparkクラスタで実行され、結果はオブジェクトストレージに書き戻されます。 この変換されたデータは、Autonomous Data Warehouseにロードすることができます。 Autonomous Data Warehouse Cloud とBig Data Cloudの連携 Oracle Autonomous Data WarehouseとOracle Big Data Cloudは、全く別個の2つのサービスとは考えないでください。 補完的な強みを持ち、オブジェクトストレージを介して相互運用することができます。 そうすることで、すべてのデータを活用して、ビジネス全体の利益を得ることが容易になります。 より多くのことを学ぶことに興味がある場合は、 オラクルの無料トライアルに登録して、独自のデータ・レイクを作成することができます。 本資料は、Oracle Big Data blog(https://blogs.oracle.com/bigdata/integrating-autonomous-data-warehouse-big-data-object-storage)を抄訳したものです。  

Oracle Autonomous Data Warehouseに格納されているデータを使用してビジネスを実行することは可能ですが、そこには他にも価値のあるデータが多数あります。 Oracle Big Data Cloudを使用すると、そのデータを格納および処理し、 Autonomous Data Warehouse Cloudにロードする前準備ができます。 これら2つのサービスの統合ポイントは、 オブ...

Big Data Management

オブジェクトストレージ それはデータレイクの新しい選択肢

オンプレミスが第一の選択肢であった時代においてデータレイクにとってHadoopが支配的なポジションを占めていました。しかし、今日の急速に変化する技術の世界では、新しいアプローチが普及しつつあります。それはApache Spark クラスタとオブジェクトストレージの組み合わせによるものです。 この記事では、このアプローチの背景を掘り下げ、なぜクラウド時代における最適な選択肢であるのか解説していきます。 クラウド時代に求められるデータレイク 2000年代初頭に誕生したApache Hadoopは、ビッグデータ用の基盤として着実な成果を上げてきました。 特に、ここ5年は、機械学習ブームも相まり確固たるデファクトの地位を築いてきました。 様々なエコシステムが特徴のHadoopですが、主たる機能としては2つあります。 データ蓄積層である分散ファイルシステムのHDFSとデータ処理層である分散処理フレームワークのMapReduceです。 データドリブンで成功を収める企業が増えてくるにつれ、一般企業でもデータ蓄積の機運が高まり、システムログ、クリックストリーム、センサおよびマシンデータなど 新しいデータソースを気軽に保存できる箱としてHDFSが人気を博しました。 ゲームチェンジャーとして認知されたHadoopは、汎用ハードウェアを集めて、オンプレミスにクラスタを構築するというスタイルで急速な広がりを見せました。 クラウドでも同じアーキテクチャが正しいのか? Sparkの出現 Hadoopの長所は、分散技術ですが、それは同時にボトルネックでもありました。 数千台規模に成長したクラスタは、ハードウェアの故障が頻発し、コスト削減のために導入したHadoopの運用が大変だという声があがりました。 そこで、ハードウェアの保守から解放されるクラウド上のIaaS環境にHadoopクラスタを構築するというスタイルが始まりました。 また、同時期にOSSの世界も進歩し、MapReduceより新しいフレームワークとしてApache Sparkが登場してきました。 Sparkは概念的にはMapReduceに似ています。しかし、主な違いはディスクではなくメモリ内のデータを処理するように最適化されていることです。 もちろん、これはSparkで実行されるアルゴリズムは圧倒的に高速であることを意味します。 今日においては、SparkはMapReduceにとってかわり、分散処理フレームワークの第一選択肢となっています。 Sparkは多くのHadoopディストリビューションにバンドルされているため、HDFSとセットで利用されるケースが多いです。 オンプレミスの環境では、Hadoopとの同居が最適解でしたが、はたしてクラウド時代においては、どうでしょうか。 クラウドの登場により、データを永続化させるためのより良いアプローチがあります。 それはオブジェクトストレージです。 改めてオブジェクトストレージおさらい オブジェクト内にファイルデータを保持し、オブジェクト内ではメタデータにより情報が管理されています。そのため、通常のファイルシステムで使用される階層構造が不要です。使用できるメタデータには制限がなく、すべてがフラットなアドレス空間に配置され、スケーラビリティの確保が容易です。比較的大きなコンテンツも取り扱うことが可能で、安定したスループットを提供します。データを複数リージョンにまたがって保存し、ペタバイト以上の無制限に拡張できます。 多くの企業において、コンプライアンスの都合上保管しなければならない、大量の構造化されていないデータの長期保管場所としてオブジェクトストレージが選択されます。 しかし、コンプライアンスの理由だけではなく、企業はオブジェクトストレージを利用して、様々な非構造データを格納しはじめました。それはなぜでしょうか? 答えは明確でコストです。一般的にオブジェクトストレージは、通常のブロックストレージに対して1/3~1/5程度のコストです。すなわち、HDFSにデータを保存する場合は、オブジェクトストレージに対して3~5倍のコストが発生することを意味します。 ここまでに、SparkはMapReduceより高速であり、オブジェクトストレージはHDFSより安価であるという話をしてきました。以後、その組み合わせイメージをご紹介します。 オブジェクトストレージにSparkに組み合わせる オブジェクトストレージとSparkの組み合わせは、Hadoopより弾力性のあるアーキテクチャです。Hadoopは、データローカリティのポリシーの元、ディスクとCPUをセットでクラスタ構成を行います。性能面については有利である一方、ノード追加やリバランス処理などクラスタ管理の苦労が絶えません。 一方でクラウド環境であれば、ディスク(オブジェクトストレージ)とCPU(Spark)を分離して動的に環境が用意であるため、データ保持するだけであればオブジェクトストレージを利用し、データ処理の必要があるタイミングだけ動的にSparkのクラスタを構成し、処理を行うというアーキテクチャが可能になります。. この新しいアーキテクチャがもたらすもの 1. オブジェクトストレージ + Spark = ビジネスのアジリティ CPUリソースを必要な時に必要な時だけ利用するといった、クラウドの最大のメリットを享受できる構成です。動的なリソース配置により、固定的なクラスタより、性能的/コスト的な優位性があります。Sparkクラスタを利用しない時は、クラスタをオフにしておくうことが出来、当然その間はコストが発生しないためです。その分、処理時のみに短期集中でCPUを割り当てることが性能優位性をもたらします。 オブジェクトストレージは、データレイクとして永続化する領域となり、データの量に応じて課金が発生します。これもあらかじめディスクを用意する構成に対し柔軟性が高いと言えます。 ここまでの説明で、ビッグデータをオブジェクトストレージに保存してSparkで分析のための前処理を行うバッチ的な運用をイメージされた方も多いでしょう。それは、このアーキテクチャの価値の一面でしかありません。 リソースの柔軟な割り当てによる最大の効果は、ビジネスの変化に機敏に追従することができる点です。新しいビジネス要件が必要になった場合は、独立した別のクラスタをすぐに起動することができます。1つのデータレイク(オブジェクトストレージ)に対して、複数の部門が別のクラスタを用意できるので、データは共有しつつ、新しい要件にすぐに対応できる環境になります。. 2. オブジェクトストレージ + Spark = 基盤業務からの解放 Hadoopは我々に多くのメリットをもたらしたものの、その運用の苦労は多くの場所で語られています。ディスク障害に始まりバージョンアップやリバランス、500を超えるパラメータ調整。 オラクルは、これらの課題に対しOracle Big Data Appliance.というエンジニアドシステムで道を切り開いてきました。 しかし、クラウドは別の選択肢を提供します。フルマネージドサービスとしてSparkとオブジェクトストレージサービスを提供します。バックアップ、レプリケーション、パッチ適用、アップグレード、チューニング、これらすべてをオラクルが請け負います。 クラウドでは、安定性と信頼性の責任がIT部門からクラウドベンダーに移ります。 3. オブジェクトストレージ + Spark = TCO削減 退屈で複雑な基盤の管理業務から解放されることで、担当者はより生産性の高い仕事に集中することができます。従来の基盤作業に追われていたエンジニアは、モデルの精度向上や業務部門との会話により多くの時間を活用できるようになり、結果データドリブンが加速していく体制がもたらされます。単純なコスト削減だけではなく、このようなプラスの効果を生み出すのです。 まとめ オブジェクトストレージとSparkで構築されたこの新しいデータレイクアーキテクチャの利点は、     1. ビジネスのアジリティ向上     2.基盤業務からの解放     3. TCOの削減 このすべては非常に有効です。 これらはOracle Big Data Cloudによってもたらされます。 無料お試し も可能ですので、ぜひお気軽にご利用ください。 本資料は、Oracle Big Data blog(https://blogs.oracle.com/bigdata/what-is-object-storage)を抄訳したものです。

オンプレミスが第一の選択肢であった時代においてデータレイクにとってHadoopが支配的なポジションを占めていました。しかし、今日の急速に変化する技術の世界では、新しいアプローチが普及しつつあります。それはApache Spark クラスタとオブジェクトストレージの組み合わせによるものです。 この記事では、このアプローチの背景を掘り下げ、なぜクラウド時代における最適な選択肢であるのか解説していきます。 ク...

Big Data Management

今注目のデータレイクとは何か?DWHと何が違うのか?

近年、データマネジメントに関して様々なキーワードが聞かれます。 データレイク, データウェアハウス(以下、DWH) – 本記事では、それらの位置づけを定義し、特徴や将来展望を整理します。 データレイクの定義 データレイクとは、構造化データや非構造化データを格納する場所であり、様々なデータソースから集められたデータを管理し、活用のための前処理を行える環境。 Hadoopやオブジェクトストレージ+Sparkで構成されることが多い。 詳しくはこちらの動画を参照 DWHの定義 データウェアハウスは、予め定義されたKPIなどの指標をモニタリング/分析するために、社内外の様々なデータソースからデータを収集し、検索のための最適化が行われた環境。 主にDWHのための機能を有したデータベースで構成される。   その他、関連キーワード エンタープライズデータウェアハウス (EDW): 企業全体向けサービスを提供するデータウェアハウス。 データマート: 個々の部門によって利用されユーザが現在必要としているデータをより最適化された形で利用。 データスワンプ: 失敗したデータレイクの揶揄。なんでも入るからと、計画性のないデータ蓄積を行うとレイク(湖)は、すぐに使いにくいスワンプ(沼)となる。 それぞれの違いは何か?どう使い分けるのか データレイクもDWHも様々なデータを格納するという点では共通しています。ここではデータを保存時に考慮すべきポイントは何かを考え、それぞれの役割について説明します。 データウェアハウスの特徴 1950年代に最初のデータベースが登場し、1980年代に現在のスタンダードであるリレーショナルデータベースが普及しました。データベースはリアルタイムの構造化データを更新する、つまりOLTP用途で利用されます。ビジネスが成長するにつれ、複数の場所や業態からデータが発生するようになり、すべてを分析するためには、それらを集約した場所が必要でした。それがデータウェアハウスです。 例えば、あなたは小売チェーン店の会員カードに入会しているかもしれませんが、データウェアハウスは、現在の買い物客の傾向を分析する目的において、あなたの購入記録を保持しているかもしれません。 データウェアハウスは、購入したすべてのアイテムの記録を保持し、最適化されるためデータ分析者はより簡単に分析することができます。 データレイクの特徴 2010年代になると、データレイクが台頭してきました。 データウェアハウスでも非構造化データを蓄積・処理できますが、最も効率的な方法ではありません。 ビッグデータと呼ばれる、非常に多くの種類・量のデータがあると、すべてをデータウェアハウスに格納した場合、多大な費用が発生する可能性があるからです。 さらに、時間と労力の制約があります。データウェアハウスに格納されるデータは、格納前にテーブルレイアウトに合うようにクレンジングする必要があります。(注1)多種多様なデータをETLするコストは膨大になってしまいます。それが、データレイクが人気を博した最大の理由です。データレイクは、主に非構造化データを最も費用対効果の高い方法で処理できます。非構造化データとは、単に構造化されていない業務データではなく、テキストやソーシャルメディア、IoTデバイスのログファイルやセンサー、マシンデータまで、あらゆるデータを対象とします。 ここでデータレイクの例を見てみましょう。 先ほどのDWHで使用した小売チェーンの例に戻って、考えてみます。 DWHでは、顧客がどのような商品を買ったのかという事実に基づいた分析が可能ですが、入店したが買わなかったことや将来どのようなものを購入するかの予測を行うことは難しいです。 そこで、データレイクに様々なデータを蓄積することが有効になります。例えば、Webチャネルと実来店を紐づけたり、顧客のSNSデータを取り込むことでより精度の高いオファーをすることが可能かもしれません。さらに、天気や気温などの外部情報を取り込むことで、仕入れの最適化も考えられます。 データレイクはデータウェアハウスのデータをより価値のあるものに高めてくれます。 注1: データレイクを持っていても、クレンジングが不要になるわけではありません。あくまでも格納時にスキーマレスであり、活用に向けたクレンジングは必要になります。 しかしながら、Sparkを代表とする分散処理技術との相性の良さから、クレンジング処理を行う基盤としてもデータレイクは有効です。 DWHとデータレイクの将来は? これらのテクノロジは、一方を淘汰するものではなく、共存共栄の関係にあります。 今後も、構造化されたデータをデータウェアハウスに保存し続けるでしょう。 しかし、企業は非構造化データについてはクラウド上のデータレイクに移動しています。 データの保存はコスト効率が最重要であるためです。 オラクルでは、DWHのディファクトスタンダードであるOracleDBをクラウド上で手軽に運用できる Autonomous Data Warehouse Cloudをリリースしています。 また、非構造化データを安価に保持するため、Storage Cloudを提供しており、それらの情報を加工するための 環境としてBig Data Cloudをリリースしています。 もし、データレイクに興味があり、自信で構築してみたい方は、以下のチュートリアルを是非おためしください。  free data lake trial with a step-by-step tutorial. Get started today.   本資料は、Oracle Big Data blog(https://blogs.oracle.com/bigdata/data-lake-database-data-warehouse-difference)を抄訳したものです。

近年、データマネジメントに関して様々なキーワードが聞かれます。 データレイク, データウェアハウス(以下、DWH) – 本記事では、それらの位置づけを定義し、特徴や将来展望を整理します。 データレイクの定義 データレイクとは、構造化データや非構造化データを格納する場所であり、様々なデータソースから集められたデータを管理し、活用のための前処理を行える環境。Hadoopやオブジェクトストレージ+Spark...

Big Data Management

Big Data SQL - 処理のオフロード(Smart Scan)

前回の投稿:Big Data SQLをはじめよう - Introduction や、 One Fast Query All your Dataを読んで、Big Data SQLがOracle Databaseを通してHadoop上のデータにクエリを実行することが出来る、ということが理解できたことでしょう。しかし、ただ単にデータをREADしているだけではありません。Big Data SQLは、HDFS上に格納されたデータを処理して、クエリに必要なデータだけをDatabaseに返すことができます。(Exadataに詳しい方にはよく知られた「Smart Scan」することができます) Oracle DatabaseとHadoopを含むデータマネージメントシステムを想像してみましょう。 Engineered Systemである、Big Data ApplianceとExadataで、Big Data SQLを実行すると、アーキテクチャーは次の図のようになります。 それぞれの優位性は: データベースの良いところ トランザクショナルなワークロード 同時実行性(read/write) クリティカルなデータの格納 複数テーブルの結合、複雑なクエリ Hadoopの良いところ バッチ処理。同時実行ではないワークロード 比較的シンプルなクエリ シンプルなクエリに対するスケーラビリティ 非構造化データ、半構造化データ(semi-structured data)の扱い 従って、RawデータをHadoop層に格納し、基本的なジョブを処理した後に、準備できたクリーンなデータをデータベース層に持つようなシステムが良さそうです。Big Data SQLは、これを実にシンプルに成し遂げることができます。 Hadoop層では以下のように動作します。 データのDeserialization (シリアライズ化されたものを元に戻す)。もしシリアライズ化されたフォーマット(AVRO, JSON, Parquetなど)で格納している場合、デシリアライズ化を行う 列のプルーニング。400列あるテーブルに、クエリでは1列をSELECTする場合、Big Data SQLは399列をプルーニング(除外)して1列だけを返す データ型の変換。データ型を型変換する処理はそれなりに負荷がかかる処理ですが、Big Data SQLは、Oracle Databaseフォーマットへの変換をHadoop層で行う 関数の適用。もしクエリにフィルタpredicate (like “id=…” のようなWhere句の条件指定)があれば、Hadoop層で動く。Hadoop層で動く全ての関数のリストは以下で確認できます(Oracle Database上で実行します) SQL> SELECT * FROM v$sqlfn_metadata WHERE offloadable = 'YES'; ここからは、”OFFLOADABLE”なクエリ(Hadoop層でワークロードの大半が行われるようなクエリ)を実行することにします。前回の投稿:Big Data SQLをはじめよう - Introduction のクエリを見てみましょう。 SQL> SELECT min(w.ws_sold_time_sk) FROM WEB_SALES w WHERE w.ws_sold_date_sk = 2451047; Big Data SQLの側面からは、フィルタリング(Where句での条件指定)がこのクエリの主要部分です。不要な行を取り除き、適切な行だけをRDBMS側に転送します。更に、Big Data SQLは列のプルーニングも行います。これはテーブルの全列から、これから計算しようとしている列のみを転送することを意味します。実行計画とクエリ統計をEnterprise Managerのから見てみましょう。(Enterprise Managerの「SQL監視」を使用します) Enterprise Managerからはオフロード効率も確認することができます。 Enterprise Managerの代わりに、実行時の統計を以下のクエリでも確認できます (SQL DeveloperやSQL*Plusなど任意のツールから、ユーザクエリを実行後に実行します) 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 これはBig Data SQLにとって良いクエリの典型的な例です。 オフロードが起きるかどうかは、どうやって決まる? この問いに答える前に、オフロードがどのように動作するかをもう少し詳しく説明します。 最初のステップで、Big Data SQLはストレージインデックスを適用してHDFSからデータをREADし、デシリアライズを行います。実際には、“External Table Service” はデータのREADにCとJavaの2つのモードがあり、テーブル定義にて、アクセスパラメータの設定で指定しています。 … ACCESS PARAMETERS ( com.oracle.bigdata.datamode=java ) or … ACCESS PARAMETERS ( com.oracle.bigdata.datamode=c ) Cモードはそれが利用可能な場合に使用します(全てのデータフォーマットに対応しているわけではありません)。どちらの場合も、Big Data SQLはHDFSブロックをREADし、それをOracleフォーマットに変換し(後のスマートスキャン・サブコンポーネントで必要)、スマートスキャンに送ります。スマートスキャンレベルでは、Big Data SQLは列のプルーニング、フィルタリング(行のプルーニング)、JSONやXMLのパースを行います。処理後のデータは、Oracle Databaseに、Oracle Databaseフォーマットで転送されます。 クエリがオフロードされているかどうか、どのように調べればよいでしょうか?これを確認する最初のステップは、Enterprise Managerから待機イベントを見ることです。 オフロード可能なProperクエリの例で見てみましょう(ここでは “Proper”と呼ぶことにします、なぜならワークロードの多くの部分をストレージ側(Hadoopサイド)で実行できるから)。 SQL> SELECT fnull(MIN(WS_SOLD_DATE_SK)), fnull(MIN(WS_NET_PROFIT)) FROM WEB_SALES; クエリで使用している fnull()は、何もしないPL/SQLファンクションです。(値を受けてそのまま返す) SQL> create or replace function fnull(input number) return number is Result number; begin Result:=input; return(Result); end fnull; WEB_SALES表は多くの列(34列)を持つが、上のクエリでは2列のみが含まれます。MINファンクションはOFFLOADABLEなので、これはHadoopサイドで実行できることを意味します。 SQL> SELECT NAME, offloadable, AGGREGATE FROM v$sqlfn_metadata WHERE NAME = 'MIN' AND AGGREGATE='YES'; NAME offloadable AGGREGATE ---- ----------- --------- MIN YES YES その結果、Big Data SQLによりフィルターされ、結果がDatabaseサイドに転送された後、Databaseサイドで作成したPL/SQLファンクションが適用されます。Enterprise Managerで見てみましょう。 待機イベントの87%が ”User IO” でこのIOの全てがCell側です(“cell external table smart scan”)。待機イベントの13%はCPU waitsです(おそらくPL/SQL実行の待機)。オフロード統計をチェックすることも有用です。Enterprise Managerで以下のように確認できます。 代わりに、以下のクエリを実行することでも確認できます。 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#; 上の例で、オフロード可能なクエリ、Big Data SQLにとって良いクエリを見てきました。一方で、アンチパターンとなるクエリとして、先の自作したPL/SQLファンクションの適用順を、以下のように逆にしてみます。 SQL> SELECT MIN(fnull(WS_SOLD_DATE_SK)), MIN(fnull(WS_NET_PROFIT)) FROM WEB_SALES; これは前のクエリと非常に似ており、結果も同じです。しかし、実行状況は全く異なります。列をPL/SQLでラップすると、とたんに、全てのデータをデータベース層に転送しなければならなくなります(PL/SQLはHadoop層では処理されないため)。Enterprise Managerは先の実行例とは異なる待機イベントを示します。 CPU Waitのみが待機イベントとして表示されることが観察できます。クエリの詳細をクリックすると、スマートスキャンの結果すべての行を返している(Eligible bytesの全てがFiltered bytesになってしまっている)ことが分かります。 このケースを可能な限り避け、クエリの大部分を可能な限りHadoop層で行われるように試みましょう。 とはいえ、このクエリでも、Hadoop層でいくつかの仕事は行っています。HDFSブロックをOracle Databaseフォーマットに変換することと、クエリに使用しない列のプルーニングです。 データベースサイドのデータ型変換 もしいくつかのノードでBig Data SQLエージェントが使用不可の場合、どのようになるでしょうか。Cloudera Managerから、Big Data SQLエージェントを停止してみます。 停止後、任意のクエリを実行します。 SQL> SELECT COUNT(1) FROM STORE_SALES ss WHERE ss.ss_sold_date_sk = 2452200; オフロードが行われていない、最初のサインは、クエリが遅くなることです。Enterprise Managerでは、待機イベント “Application: External Procedure Call” が多く見受けられます。 更に、データベース側の、ネットワーク使用状況からも、確認できます。 Big Data SQLの制約 Big Data SQLは、全てのOracle Database SQLです。詳細はここで確認できます。 全ての関数が、Hadoop層で処理されるわけではありません。オフロード可能な関数は以下のv$ビューで確認できます SQL> SELECT NAME FROM v$sqlfn_metadata WHERE offloadable ='YES'; オフロード不可の関数でも、Big Data SQLは列のプルーニングやデータ型変換を行います(それはデータベース層の多くのリソースを節約するのに役立ちます) 他の処理(オフロード不可の関数)は、データベースサイドで処理されます 本投稿はBig Data SQL Quick Start. Offloading - Part2.を元に投稿しています。  

前回の投稿:Big Data SQLをはじめよう - Introduction や、 One Fast Query All your Dataを読んで、Big Data SQLがOracle Databaseを通してHadoop上のデータにクエリを実行することが出来る、ということが理解できたことでしょう。しかし、ただ単にデータをREADしているだけではありません。Big Data SQLは、HDF...

Big Data Management

Big Data SQLをはじめよう - Introduction

これからBig Data SQLを動かすにあたり必要なステップを説明します。とても簡単!この記事を読んだ後、皆が私に賛同してくれることを願っています。まずはじめに、Big Data SQLが何か?を知りたければこちらのBlogをお勧めします。Oracle Big Data SQL: One Fast Query, Big Data SQL 2.0 - Now Available. (Big Data SQLのデザインゴールをカバーしています。) Big Data SQLのゴールの一つは透過性です。HDFSにあるディレクトリやHCatalogにあるテーブルをリンクするようなテーブルを外部表として定義するだけで、Oracle Database上のテーブルのように動作させることができます。製品ドキュメントも参考になるでしょう。 Big Data SQLをはじめよう Big Data SQLを使って、HDFS上に格納されたデータをOracle Database経由でクエリを実行する、もっともシンプルな例を紹介します。 まずはデータが実際にHadoop環境のHDFS上に格納されていることを確認します。これを実行するには、Hadoop環境で、HiveコンソールからHive表のDDLを確認します。 hive> show create table web_sales; OK CREATE EXTERNAL TABLE web_sales( ws_sold_date_sk int, ws_sold_time_sk int, .... ws_net_paid_inc_ship float, ws_net_paid_inc_ship_tax float, ws_net_profit float) ROW FORMAT DELIMITED FIELDS TERMINATED BY '|' STORED AS INPUTFORMAT 'org.apache.hadoop.mapred.TextInputFormat' OUTPUTFORMAT 'org.apache.hadoop.hive.ql.io.HiveIgnoreKeyTextOutputFormat' LOCATION 'hdfs://democluster-ns/user/hive/warehouse/tpc_ds_3T/web_sales' DDLより、データはテキストファイル(CSV形式)で、以下のHDFSディレクトリに格納されていることが分かります。 $ /user/hive/warehouse/tpc_ds_3T/web_sales DDLより、各フィールドの区切り文字は“|” です。念のため確認してみましょう。 $ hdfs dfs -ls /user/hive/warehouse/tpc_ds_3T/web_sales|tail -2 ... hive 33400655 2015-05-11 13:00 /user/hive/warehouse/tpc_ds_3T/web_sales/part-01923 ... hive 32787672 2015-05-11 13:00 /user/hive/warehouse/tpc_ds_3T/web_sales/part-01924 $ hdfs dfs -cat /user/hive/warehouse/tpc_ds_3T/web_sales/part-01923|tail -2 2451126|36400|2451202|302374|9455484|1765279|2274|6715269|2004559|472683|5807| 2451126|36400|2451195|289906|9455484|1765279|2274|6715269|2004559|472683|5807| 確かにHadoop環境のHDFS上にCSVファイルがありました。これをデータベースからフェッチしてみます。 新しい形式の外部表、新しい待機イベント、新しい行ソース Big Data SQLでは、 新しい形式の外部表(ORACLE_HIVEとORACLE_HDFSドライバ) 新しい待機イベント(cell external table smart scan) 実行計画における新しい行ソース(External Table Access Storage Full) が導入されています。 上のHDFSディレクトリに対し、以下のようにOracle外部表を定義します。 CREATE TABLE WEB_SALES_EXT ( SS_SOLD_DATE_SK NUMBER, … SS_NET_PROFIT NUMBER ) ORGANIZATION EXTERNAL ( TYPE ORACLE_HIVE DEFAULT DIRECTORY "DEFAULT_DIR" ACCESS PARAMETERS ( com.oracle.bigdata.cluster=democluster com.oracle.bigdata.tablename=web_sales) ) REJECT LIMIT UNLIMITED PARALLEL; このDDLでは、ORACLE_HDFSドライバを使った外部表であり、クラスタ名とHive環境のテーブル名(web_sales表)を指定しています。テーブル作成が終わったら、データベースに対しクエリを実行することができます。はじめに、とてもシンプルなクエリを実行してみましょう(Filter条件に合致する行から、ある列の最小値を求める)。その後、Oracle Enterprise Managerで、クエリがどのように処理されたかを確認します。 SQL> SELECT min(w.ws_sold_time_sk) FROM WEB_SALES_EXT w WHERE w.ws_sold_date_sk = 2451047; 新しい待機イベント“cell external table smart scan” や、実行計画における新しい行ソース“external table access storage full” が確認できます。 この表がOracleのデータ・ディクショナリに存在することは、以下のクエリで確認できます。 SQL> SELECT t.OBJECT_NAME,t.OBJECT_TYPE FROM user_objects t WHERE object_name='WEB_SALES_EXT'; OBJECT_NAME OBJECT_TYPE ----------- ------------- WEB_SALES_EXT TABLE Big Data SQLでは、新たにOracleのデータ・ディクショナリ、”ALL_HIVE_TABLES”が追加されました。 SQL> SELECT table_name,LOCATION,table_type FROM ALL_HIVE_TABLES WHERE object_name='WEB_SALES_EXT'; TABLE_NAME LOCATION TABLE_TYPE ----------- -------------------------------------- ----------- WEB_SALES_EXT hdfs://democluster-ns/.../web_sales EXTERNAL_TABLE Oracleを使って、Hadoopへのクエリがとても簡単に実行できたことがお分かりいただけたでしょうか。次のBlogで、もっと複雑なクエリについて紹介していきます。 本投稿はBig Data SQL Quick Start. Introduction - Part1.を元に投稿しています。

これからBig Data SQLを動かすにあたり必要なステップを説明します。とても簡単!この記事を読んだ後、皆が私に賛同してくれることを願っています。まずはじめに、Big Data SQLが何か?を知りたければこちらのBlogをお勧めします。Oracle Big Data SQL: One Fast Query, Big Data SQL 2.0 - Now Available. (Big...