Compartir a través de

都市伝説 (Urban Legends) を読み解く - 必要なデータをフィルタリングする方法は!?

  • Artículo

マイクロソフトの北川です。

都市伝説には「ニュース性」「真実味」「オチ」という特徴があり、起源や根拠が全く不明なものが多いとされています。また、何かしらの根拠があるものに関しても、なんでもない事実に尾ひれがついて伝説化したとされています。この都市伝説の問題はそれが「真実」であるかのように語られる点にあります。特定の都市伝説が広く普及した原因は、広く信頼されているソースにより紹介されたことにあるとされています。

閑話休題

日本オラクル社のウェブサイトにおける「オラクル都市伝説」で揶揄されている「あのデータベース」ですが、今回は「PowerPivot と相性がいい」とされているようです。この PowerPivot は、提示されている UI を見るとマイクロソフトが5月1日より提供開始した SQL Server 2008 R2 PowerPivot for Excel (以降 PowerPivot) のようです。

「データの活用」という観点でエンジンでは競合する両社がともに「セルフサービス BI」の重要性を訴求するといういいお話では残念ながらないようです。では、今回はこの「都市伝説」を読み解いてみましょう。

 

以下オラクル都市伝説サイトより。

  1. テーブルに格納されているデータすべてを取得しようとしている
  2. 3時間かけてもデータの取得が終わらない

実際にディスクの転送量からそのデータ量を検討してみましょう。今回のシステムは一般的なタワー型サーバーを使用していると仮定します。こういったサーバーにはデータ領域用途で通常4本程度のディスクを内蔵することができるようになっています。近年主流となっている SATA 7,200rpm のディスクのシーケンシャル Read の性能がおおむね 30MB/sec (Disk to CPU) とします。一般的なタワー型サーバーでは、4本のディスクを内蔵することができますので、このディスクで RAID0+1 (Stripe & Mirror) 構成をとった場合、60MB/sec となります。

都市伝説サイト本文では「バッチが終了した6時から9時までかけてもデータ取得が完了できなかった」と書かれていますので、3時間かけてもデータ取得を完了できなかったことになります。では、いったいどれくらいのデータサイズだったのでしょうか。計算してみましょう。60MB/sec * 3,600sec * 3 = 648,000MB となりますので、データは最低でも約650GB あるようです。

Oracle Database で稼働する X 事業部のシステムおよび「あのデータベース (SQL Server)」で稼働する Y 事業部のシステムは同じサイズのデータを持っており、同スペックのタワー型サーバーで稼働していると仮定します (比較対象ですので、同じデータ量および同じハードウェア構成を持つと仮定することが出来ますよね)。

3時間かけてもすべてのデータの取得が終わらなかった「あのデータベース (SQL Server)」で稼働する Y 事業部のシステムに対して、Oracle Database で稼働する X 事業部のシステムは、VPD (Virtual Private Database) により「ユーザーごとに必要なデータにのみアクセスを許可」する一種のフィルタリングが行われているため「データ取得もサクサクと短時間で終わっている」とされています。

では、X 事業部のシステムはどのような属性でフィルタリングされているのでしょうか。データの取得のため、J くんは自身のアカウントで X 事業部のシステムにログインしたと推測されます (セキュリティに配慮した、とされている X 事業部が共有アカウントを利用していることは想定外)。アクセス制御で利用されている VPD は、ユーザー名を含む「セッション コンテキスト」という属性を利用してアクセス制御をおこないます。どのようなポリシーが施行されていたかは都市伝説本文中には記載されていませんが、同スペックの機材で純粋な読取りに3時間以上かかるデータを「サクサクと短時間で終わっている」といえる時間で読み取っていることから、かなりの量のデータがフィルタリングされていると推測されます。とすると、ユーザーもしくはユーザーが所属するグループの発注情報のみ参照できるようにアクセス制御ポリシーが設定されているのかもしれません。

ここで当初の目的を振り返ってみましょう。M 部長から K さんが依頼されたのは「会議で使うための X 事業部と Y 事業部の売り上げ分析レポートの作成」です。そして依頼された K さんは「X 事業部は新人の J くん、Y 事業部は K さん」と担当を決め、のちに「J くんと担当を変えようかと思ったが、先輩として新人に重荷を負わせることはできない」と逡巡していますので、二人が固定的に特定の事業部に所属している、もしくは特定の事業部のシステムをメンテナンスしている、ということはないと想定することが出来ます。

とすれば、J くんのアカウントで X 事業部のシステムにログインしたとしても、J くんの受注データや J くんが所属するグループのデータが抽出できるわけではなさそうです。そのため、アクセス制御ポリシーは、ログインしたユーザーの職責に基づいていると新たに想定することが出来ます。

では、当初の目的に「J くんの職責で抽出したデータ」は合致しているでしょうか。残念ながら M 部長が求めている売り上げ分析レポート、すなわち X 事業部としての売り上げ分析レポートとしては不十分な情報から作成されたレポートになってしまっているのではないでしょうか。

 

PowerPivot で必要なデータをフィルタリングする方法は!?

PowerPivot では、圧縮された多次元データベースとしてデータを保持することにより、Excel の限界を超えるデータを高速に処理することが可能です。しかし、今回のケースのように、650GB を超えるデータを取り込もうとした場合、データの読み取りに相応の時間が必要となります。

そこで、PowerPivot では、データベースから直接データを読み取るのではなく、SQL Server Reporting Service (SSRS) からデータを読み取ることが出来るようになっています。Y 事業部のシステムは「あのデータベース (SQL Server)」で稼働していますので、おそらく定型レポートは SSRS により実装されていると思われます。この SSRS からのデータ読み取りを利用することで、あらかじめ PowerPivot に取り込むデータを柔軟にフィルタリングすることが可能となります。

 

[結論] 仮に J くんが「特権ユーザー」でログインしている場合には約650GBのデータにアクセスすることが出来るかもしれません。両システムが稼働しているサーバーのハードウェア構成が共通の場合、やはり全データの取り込みには3時間以上かかることになります。

もし「サクサクと短時間で終わっている」という時間でデータ取得を終了させたい場合には、同レベルのハードウェアではなく、15,000rpm SAS ディスクを10本搭載した MSA2300 ストレージアレイを複数台利用した大規模システムである必要があります (MSA2300 ストレージアレイを3筐体 8G FC で接続したとしても、約650GB のデータをすべて取得するには14分ほどかかる計算になります)。

つまり、VPD によるアクセス制御が施行されたおかげでデータ取得が高速化されることは今回の目的には全く合致しておらず、高速なデータ取得のためには、いずれのシステムにおいてもストレージの増強が必要であると言えます。

もしくは、PowerPivot でデータを取り込む前にデータを簡単にフィルタリングする仕組みが必要です。SQL Server では SSRS からのデータ取得を利用することで、SQL 文を入力したりせず、簡単にフィルタリングを行うことが出来ますので、PowerPivot にはやっぱり SQL Server ということが出来ます。

 

[本項目における突っ込みどころ]

  1. SQL Server 2008 Enterprise, SQL Server 2008 R2 Enterprise / Datacenter では、データ圧縮の機能を標準で利用することが出来ます。マイクロソフトがパートナー様と実施した共同検証では、TPC-C の LineItem テーブルを 1:10 で圧縮することが出来ました。今回のシステムで使用されている発注テーブルおよび発注明細テーブルなども同じ圧縮率で圧縮することが出来たと仮定すると、ハードウェアを増強せずとも、約650GB の生データを約18分 (650,000MB / 10 / 60MB/sec) で読み込むことが出来ることになります。
  2. そもそも「売り上げ分析レポート」という基本的なレポートであれば、定型レポートとして準備されていてもよさそうですが。SQL Server のコンポーネントである SSRS を利用すれば、こうした定型レポートも簡単に作成することが出来ます。
  3. アドホックレポートの作成であり、ユーザー側でのデータのマージなどの処理が不要なのであれば、そもそも PowerPivot ではなく、Report Builder 3.0 の方が適しているかもしれません。Report Builder 3.0 を利用すれば、PowerPoint のようなユーザーインターフェースで、エンドユーザーが簡単にアドホックレポートを作成することが可能です。もちろん地図連携も可能です。また、SQL Server だけではなく、その他のデータベースにも直接接続してデータを取得することが可能です。こうした「追加の費用なく、データベースに格納されたデータをより簡単にエンドユーザーが活用することが出来る」という点が SQL Server の特徴であるということが出来ます。
  4. PowerPivot を活用したセルフサービス BI については「こんな悩みにさようなら! 明日から使えるシーン別データ活用法」でも紹介されています。