テクテク日記

テクテク=テクノロジー&一歩ずつ(テクテク)

Power BIと物理メモリ①

BIを使っていくと、必ず理解しなければいけないのがRAMとCPUとなります。前回の記事ではこれらについて少し触れましたが、今回は主にPower BIとRAMの関係について見ていきたいと思います。

RAMとは

RAMはRandom Access Memoryの略で、いわゆるメインメモリであり、CPUが何らかの処理を行ったり、画面上に何かしらのデータを表示したりするときに使う作業用のメインメモリ(主記憶装置)となります。よく例えられるのが「机の広さ」であり、

メモリが多いほど、多くのアプリを同時に開ける

ことになります。RAMはその性質上、価格が高いことから価格重視でスペックの低いPCでは4~8GBで搭載されるようになっています。今では4GBのPCはほぼ見かけなくなりましたが、8GBのRAMを搭載しているPCはブランドによってはまだまだ普及しています。

RAMが重要な最大の理由の1つに、Power BIはインメモリデータベースのテクノロジーを使っていることが挙げられます。Power BI DesktopやExcel Power Pivotでデータモデルを作った場合、インポートされるデータはRAMに格納されることになります。その際、データは元データと同じサイズで格納されるわけではなく、圧縮アルゴリズムをベースに極限に圧縮された状態でRAMに格納されます。

データ量が少ない場合、8GBのRAMでも対応可能ですが、大量のデータを取り扱う必要がある場合、スペックの低いPCを使っていると、メモリ不足に陥りやすく、Power BI Desktopが非常に遅くなってしまう、あるいはフリーズしてしまうこともあります。

このことから、RAMを多く搭載したPCを使うべきである、というのが容易に理解できると思いますが、予算の問題、RAMが多い = (ノートPCの場合)バッテリーライフが短い、RAMを増強可能 or 増強不可、等のことも考慮する必要があります。

レポートが遅い理由

「Power BIでレポートが遅い」という不満はよく聞かれますが、その前にいくつかの定義を確認しておかないといけません。通常、Power BI Report(他のBIツールでは「ダッシュボード」)が遅いと表現した場合、Power BIを既に本格導入しているケースであればPower BI Serviceに発行されたレポートが遅いことを意味します。これに関しては様々な要因がありますが、Power BI DesktopとPower BI Serviceに限定せず見た場合、主に以下が原因であることが予想されます。

  1. レポートの構築を行っているPCのスペックが低い
  2. データのボリュームが大きい
  3. DirectQueryを使っている
  4. 非効率なメジャーがビジュアルで表現されている
  5. データ量が多いにも関わらず、非常に細かい粒度で結果を表示している
  6. 使用しているブラウザが遅い
  7. ページに沢山のビジュアルが配置されている
  8. Power BI Serviceを提供しているサーバーが海外にある
  9. VPNやファイアーウォールの影響
  10. その他

このうち、ハードウェアに関する1が今回のメイントピックとなりますが、分類した場合、

  • データ関連:2、5
  • クエリ関連:3、4
  • ツール関連:6
  • デザイン関連:7
  • その他:8、9、10

になります。また、6について世の中で最も普及している各社最新のブラウザを使っていればほぼ気にならなくなりましたが、以前は体感速度としてChromeの方がEdgeよりもレポートの表示がかなり速いものでした。

Power BI Desktopの構成

Power BIと物理メモリの関係を理解するためにはまず、Power BI Desktopを立ち上げた際、起動しているプロセスを理解する必要があります。ざっくりベースですが、Power BI Desktopを立ち上げた場合、Power BIは以下のオブジェクトによって構成されています。

全てのプロセスはRAMを使用しており、タスクマネジャーで見ると以下のようになります。

  1. Power BI実行ファイル
  2. Power Queryエンジン (Mashup Evaluation Container)
  3. WebView2(Webコンテンツの表示、UI・ビジュアルのレンダリング等)
  4. Analysis Services Instance (DAX / MDX)

このうち、③はMicrosoft Power BI Desktopという表記になっていますが、以前はChromiumベースのCefSharp (CefSharp.BrowserSubprocessというプロセス名)が使用されており、2022年1月以降はWebView2ベースとなったようです。

Power BI Desktop のコンポーネント変更について(Webview2) | Japan CSS Support Power BI Blog

なお、上記タスクマネジャーのPower BI Desktopで使用されたメモリは合計で1.36GBですが、実際のpbixファイルのサイズはたったの18MBであり、④のMicrosoft SQL Server Analysis Servicesインスタンス(以降「Analysis Services」)よりも若干小さいサイズになっています。

通常、pbixはサイズが最も圧縮された状態となっており、pbixを開くと分析エンジンのAnalysis Servicesは概して大きくなっていきます。インポートモードの場合、Analysis Servicesにはすでに圧縮された状態のデータ(スキーマ含む)がコピーとして入っている状態ですが、クエリによってテーブル・スキャンといった作業が発生するため、圧縮に対するトレードオフが生じ、pbixの圧縮率よりも悪くなってしまいます。

このことにより、

18MBのpbixファイルを使用するためには、最低限1.36GBのメモリが必要

となるわけです。

ページング

Power BIのデータ量が大きい場合、他の複数のアプリケーション、複数のPower BI Desktopを立ち上げていた場合、Windowsは簡単にメモリ不足になることが予想されます。しかし実際にWindowsはメモリの解放やページングといったテクニックでこれをスマートに対処していきます。Power BI Desktopを例にした場合、以下がイメージしやすいでしょう。

8GBのRAMのWindowsがあるとします。Power BI DesktopとAnalysis Services、そしてRAMをそれぞれ器として考えてみます。

この器にそれぞれ下記サイズのオブジェクトがあるとします。

これらはRAMに読み込まれるため、下図のようになります。他のアプリケーションに対するプロセスが一切ない前提で、8GBのうち4GBを使用したことになります。

ここで残りの6GBもRAMに読み込みます。が、8GBのメモリに対して合計10GBになってしまいますので、2GB分はみ出てしまいます。

ここでWindowsは2つのどちらかを実行します。

  1. メモリ不足と表示し、実行が失敗する
  2. ページングを行う

1はアプリケーションが非常に不安定となり、アプリケーションの強制終了等が起こりますが、基本的にWindowsは2のページングを行います。メモリ不足というのが問題ですので、Windowsは物理メモリではなく、バーチャルメモリの中に処理プロセスに必要なメモリの一部を退避させて実行を成功させます。

あくまで例となりますが、例えばPBID + Otherの2GBをバーチャルメモリ(この場合、SSD*1)に退避させることでアプリケーションの実行を継続していきます。

これであれば、メモリを無尽蔵に使用することができる!と思われるでしょうが、実際のところ、メモリにはアクセス速度というものがあり、RAMとSSDへのアクセス速度が異なるため、ページングによってデータの読み込みパフォーマンスが影響を受けてしまいます。RAMはSSDやHDに比べ、圧倒的に読み書き速度が速いため、インメモリ・テクノロジーを使ったBIツールが現在主流となっているわけです。

なお、ページングはどのプロセスでも多少発生しているようですが、ページングの量が多いと、それだけデータへのアクセスが遅くなることを意味しますので、次回その確認方法について紹介していきたいと思います。

marshal115.hatenablog.com

*1:Solid State Disk