投稿者: datacompany.jp

投稿日:

Gemini Notebookでファイルを1つずつ参照するのが面倒

Gemini Notebookでソースを1つずつ登録するのが面倒

・Gemini Notebook（旧Google NotebookLM）は、自分だけの専用アシスタントとして使われている
・スプレッドシートやGoogleドキュメント、PDF、WEBページなどをソースとして登録すると、その資料をRAGとして、Geminiが要約したり、質問に答えてくれる
・しかし、Googleドライブ等のストレージを丸ごと登録できず、ソースを1つずつ登録するのが面倒
・Agent Platform（旧Vertex AI）のAgent Search（旧Vertex Ai Search）を使えば、丸ごと登録できる

Gemini Notebook（旧Google NotebookLM）は、自分だけの専用アシスタントとして、便利に使われています。

スプレッドシートやGoogleドキュメント、PDF、WEBページなどをソースとして登録すると、その資料をRAGとして、Geminiが要約したり、質問に答えてくれます。

例えば、社内マニュアルをソースと登録すれば、FAQチャットボットになります。

それまで、マニュアルを1ページずつ検索して、ユーザの質問に回答していた業務も、Geminiが集約して回答してくれるので、劇的に効率化できます。

ソースを１つずつ登録するのが面倒


このように、自分だけの専用アシスタントとして使えるGemini Notebookですが、Googleドライブ等のストレージを丸ごとソースとして登録できません。

PDFやスプレッドシートなど、ソースであるファイルを1つずつ登録しなければならず面倒です。

Googleドライブのフォルダリンクをコピー

Gemini Notebookのソースにペーストしても、フォルダは登録できない。Notebookはファイルをソース単位で登録が必要。

Agent Platformでストレージを丸ごと登録


こんな時、Agent Platform（旧Vertex AI）のAgent Search（旧Vertex Ai Search）を使えば、ストレージを丸ごと登録できて便利です。

Gemini Notebookは使いませんが、Notebook同様にGeminiを使って、指定するRAGだけ回答を生成できます。

Agent PlatformのAgent Searchのデータストア登録画面。Googleドライブを丸ごと登録できる。

Google Cloud開発お承ります

datacompanyでは、お客様のご予算・環境に応じたクラウド開発を承ります。

お困りごとがございましたら是非ご相談ください。　

お問い合わせフォーム

投稿日:

FTPサーバにあるデータをGoogle Cloudに連携する④

FTPサーバにあるデータをGoogle Cloudに連携する④

・FTPサーバは、社内基盤でCSVファイル等を授受する際に便利で使われている
・中継サーバとしてFTPサーバにファイルを置くことで、Google Cloudにもファイルを連携できる
・FTPサーバとGoogle Cloudを連携する方法は複数あるが、方法により課金方式が異なり、要件や予算に応じた連携方法を選ぶ必要がある
※本シリーズでは、SFTPサーバもFTPとして含みます

FTPサーバは、社内基盤でCSVファイル等を授受する際に便利で使われています。

PCのローカルフォルダと接続し、ファイルを管理されている方も多いでしょう。

中継サーバとしてFTPサーバを活用すれば、FTPサーバにファイルを置くことで、社内基盤とGoogle Cloudでファイルを連携できます。

そのような方法は複数ありますが、方法により課金方式は異なります。

要件や予算に応じた連携方法を選ぶことが望ましく、本シリーズでは代表的な方法や課金方式等をご紹介いたします。

シリーズ前回についてはこちらからご覧いただけます。

FTPサーバにあるデータをGoogle Cloudに連携する③

FTPサーバとGoogle Cloudを連携する方法は複数ある

FTPサーバとGoogle Cloudを連携する方法はいくつかありますが、課金方式等が異なります。

本シリーズでは、代表的な方法をご紹介いたします。

今回は、Integration Connectorsについて、ご紹介いたします。

Integration Connectorsは、SaaSなど外部サービスとGoogle Cloudをつなぐ接続アダプタです。

接続に特化したサービスで、Application Integrationと組み合わせて使います。

アダプタとしてFTPサーバの認証情報を保有し、Application Integrationでバッチ実行やワークフローを構築します。

プログラミング不要で手軽にGUIで構築できます。

その反面、デメリットもあります。

アダプタとして接続ノードを維持するため、常に稼働費用が発生します。

GUIで手軽に構築したり、POCで一時的に使いたい場合に向いています。

このようにFTPと連携する方法は、様々です。

開発リソースやコスト等の要件にあわせて選択すると良いです。

FTPと連携する方法工数課金方式
Cloud Data Fusion小常時課金
Google Compute Engine大常時課金
Google Cloud Run大稼働時のみ
Integration Connectors小常時課金

Google Cloud開発お承ります

datacompanyでは、お客様のご予算・環境に応じたクラウド開発を承ります。

お困りごとがございましたら是非ご相談ください。

お問い合わせフォーム

投稿日:

FTPサーバにあるデータをGoogle Cloudに連携する③

FTPサーバにあるデータをGoogle Cloudに連携する③

・FTPサーバは、社内基盤でCSVファイル等を授受する際に便利で使われている
・中継サーバとしてFTPサーバにファイルを置くことで、Google Cloudにもファイルを連携できる
・FTPサーバとGoogle Cloudを連携する方法は複数あるが、方法により課金方式が異なり、要件や予算に応じた連携方法を選ぶ必要がある
※本シリーズでは、SFTPサーバもFTPとして含みます

FTPサーバは、社内基盤でCSVファイル等を授受する際に便利で使われています。

PCのローカルフォルダと接続し、ファイルを管理されている方も多いでしょう。

中継サーバとしてFTPサーバを活用すれば、FTPサーバにファイルを置くことで、社内基盤とGoogle Cloudでファイルを連携できます。

そのような方法は複数ありますが、方法により課金方式は異なります。

要件や予算に応じた連携方法を選ぶことが望ましく、本シリーズでは代表的な方法や課金方式等をご紹介いたします。

シリーズ前回についてはこちらからご覧いただけます。

FTPサーバにあるデータをGoogle Cloudに連携する②

FTPサーバとGoogle Cloudを連携する方法は複数ある

FTPサーバとGoogle Cloudを連携する方法はいくつかありますが、課金方式等が異なります。

本シリーズでは、代表的な方法をご紹介いたします。

今回は、Google Cloud Runについて、ご紹介いたします。

Cloud Runは、Google Cloudでコンテナ（Docker）をサーバレスに実行できる環境です。

前回のGoogle Compute Engine（GCE）は、サーバを立てる必要がありました。

Cloud Runは、サーバレスな実行環境で、コードを置くだけで動きます。

サーバレスでOS管理も不要です。

Cloud Schedulerと連携させることで、指定した時間だけ定期実行できます。

とても使い勝手が良いです。

また、コスト面でも優秀です。

Cloud Data FusionやGCEのように常時課金ではありません。

実際に稼働した時間だけ課金となり、定期実行においても、運用費を抑制できます。

その反面、デメリットもあります。

前回とりあげたGCEのように、初期構築に相応の知識や経験が必要です。

Cloud Runはプログラムやコンテナの実装が必要です。

また、タイムアウトが短く、大容量データや長時間のデータ連携には向いていません。

プログラミング等に抵抗がなく、FTPのデータ容量が比較的小さい場合に向いています。

FTPと連携する方法工数課金方式
Cloud Data Fusion小常時課金
Google Compute Engine大常時課金
Google Cloud Run大稼働時のみ

Google Cloud開発お承ります

datacompanyでは、お客様のご予算・環境に応じたクラウド開発を承ります。

お困りごとがございましたら是非ご相談ください。

お問い合わせフォーム

投稿日:

FTPサーバにあるデータをGoogle Cloudに連携する②

FTPサーバにあるデータをGoogle Cloudに連携する②

・FTPサーバは、社内基盤でCSVファイル等を授受する際に便利で使われている
・中継サーバとしてFTPサーバにファイルを置くことで、Google Cloudにもファイルを連携できる
・FTPサーバとGoogle Cloudを連携する方法は複数あるが、方法により課金方式が異なり、要件や予算に応じた連携方法を選ぶ必要がある
※本シリーズでは、SFTPサーバもFTPとして含みます

FTPサーバは、社内基盤でCSVファイル等を授受する際に便利で使われています。

PCのローカルフォルダと接続し、ファイルを管理されている方も多いでしょう。

中継サーバとしてFTPサーバを活用すれば、FTPサーバにファイルを置くことで、社内基盤とGoogle Cloudでファイルを連携できます。

そのような方法は複数ありますが、方法により課金方式は異なります。

要件や予算に応じた連携方法を選ぶことが望ましく、本シリーズでは代表的な方法や課金方式等をご紹介いたします。

シリーズ前回についてはこちらからご覧いただけます。

FTPサーバにあるデータをGoogle Cloudに連携する①

FTPサーバとGoogle Cloudを連携する方法は複数ある

FTPサーバとGoogle Cloudを連携する方法はいくつかありますが、課金方式等が異なります。

本シリーズでは、代表的な方法をご紹介いたします。

今回は、Google Compute Engine (GCE)について、ご紹介いたします。

GCEは、Google Cloud上で使える「仮想サーバ」です。

アプリを常時稼働させるWebサーバや、バッチ処理の実行、ETL処理など、柔軟に環境を構築できます。

例えば、FTPから出力のみ許されているような場合（FTPへのアクセス参照が許されない場合）でも、FTPサーバの受け皿として機能します。

とても柔軟に構築できる反面、デメリットもあります。

前回とりあげたCloud Data Fusionのように、容易に構築できるとは言えず、初期構築に相応の知識や経験が必要です。

OSの運用保守やセキュリティ管理、プロセス監視など、運用の内製や工数も必要です。

Cloud Data Fusionと同様に待機中のコストもかかります。

Cloud Data Fusionも、裏側ではGCEが稼働しており、データ量が0ゼロでも費用は発生します。

GCEのインスタンスを立てている間、ずっと課金されてしまいます。

FTPサーバへのアクセスが許されず、FTPからをGoogle Cloudに連携させたい等に向いています。

FTPと連携する方法工数課金方式
Cloud Data Fusion小常時課金
Google Compute Engine大常時課金

Google Cloud開発お承ります

datacompanyでは、お客様のご予算・環境に応じたクラウド開発を承ります。

お困りごとがございましたら是非ご相談ください。

お問い合わせフォーム

投稿日:

FTPサーバにあるデータをGoogle Cloudに連携する①

FTPサーバにあるデータをGoogle Cloudに連携する①

・FTPサーバは、社内基盤でCSVファイル等を授受する際に便利で使われている
・中継サーバとしてFTPサーバにファイルを置くことで、Google Cloudにもファイルを連携できる
・FTPサーバとGoogle Cloudを連携する方法は複数あるが、方法により課金方式が異なり、要件や予算に応じた連携方法を選ぶ必要がある
※本シリーズでは、SFTPサーバもFTPとして含みます

FTPサーバは、社内基盤でCSVファイル等を授受する際に便利で使われています。

PCのローカルフォルダと接続し、ファイルを管理されている方も多いでしょう。

中継サーバとしてFTPサーバを活用すれば、FTPサーバにファイルを置くことで、社内基盤とGoogle Cloudでファイルを連携できます。

そのような方法は複数ありますが、方法により課金方式は異なります。

要件や予算に応じた連携方法を選ぶことが望ましく、本シリーズでは代表的な方法や課金方式等をご紹介いたします。

FTPサーバは使い勝手が良い

まず、FTPサーバについてです。

FTPサーバは、ファイルをネットワーク経由でやりとりするための仕組みです。

FTP（File Transfer Protocol）という通信ルールを使い、ファイルをアップロードしたりダウンロードできます。

企業様においては、社内基盤のサーバ間でCSVファイル等をやり取りする際によく使われます。

FTPと聞くと、少し古いイメージがありますが、私の印象では、まだまだ現役のイメージがあります。

FTPサーバとGoogle Cloudを連携する方法は複数ある

FTPサーバとGoogle Cloudを連携する方法はいくつかありますが、課金方式等が異なります。

本シリーズでは、代表的な方法をご紹介いたします。

今回は、方法の1つである「Cloud Data Fusion」について、ご紹介いたします。

Cloud Data Fusionは、外部ソースとGoogle Cloudを連携できるノーコードツールで、ETL / ELT パイプラインを簡単に構築できます。

ノーコードで簡単にできますが、本番運用を想定したBasic以上の利用料は月間約$1,100～です。

$1=150円として月16.5万円、年約200万円もかかり高額です。

この費用は、データ量が0ゼロでも発生します。

Cloud Data Fusionは、裏側でGoogle Compute Engine (GCE)に仮想サーバを立てています。

そのため、インスタンスを立てている間、ずっと課金されてしまいます。

FTPサーバにあるデータを、短期間でGoogle Cloudに連携させたい時や、一度限りの連携等に向いていると思います。

FTPと連携する方法工数課金方式
Cloud Data Fusion小常時課金

Google Cloud開発お承ります

datacompanyでは、お客様のご予算・環境に応じたクラウド開発を承ります。

お困りごとがございましたら是非ご相談ください。

お問い合わせフォーム

投稿日:

会計ソフトfreeeのデータをBigQueryに連携する

会計ソフトfreeeのデータをBigQueryに連携する

・会計ソフトは、売上や経費の計上、入金と請求の消込みなど、経理業務を効率化できる
・ただ、会計データを横断的に分析したり、次の施策検討に活用するには機能が十分とは言えない
・freeeはAPIを公開しており、取引データをGoogle Cloud Run Functionsで取得し、BigQueryに同期できる
・OAuth認証で取得したトークンはSecret Managerで安全に管理する

会計ソフトは売上や経費の計上だけでなく、消込み（取引先からの入金と請求を名寄せする処理）もできる便利なSaaSです。

経理業務が劇的に効率化します。

ただ、会計データを分析したり、そこからネクストアクションを検討することは、まだまだ十分ではありません。

会計データをダウンロードして、BIに取り込めば分析できますが、そもそもデータを分析に適した形式でダウンロードできない場合もあります。

そこで、会計ソフトfreeeを例に、データをBigQueryに連携してみました。

会計ソフトfreeeのAPIは公開されている

freeeのホームページを検索すると、APIリファレンスが公開されていました。

アカウントや申請情報、銀行口座連携など、たくさんありそうです。

リファレンスを下にスクロールすると、Deals　取引（収入・支出）というものを見つけました。

内容を見ると、おそらくこれをBigQueryに連携すれば、ある程度のデータが見れそうです。

Deals　取引（収入・支出）のAPIリファレンス

発生日や金額、収入・支出フラグなど、取引の詳細なデータを取得できます。

Google Cloud Run Functionsでfreeeに接続する

freeeの取引データは、Google Cloud Run Functionsで接続できます。

freeeのOAuth連携を行い、freeeの取引（deals）を取得して、BigQueryにテーブルとして同期します。

freeeの認可画面へリダイレクトしてOAuthを開始し、freeeから返ってきたcodeを使ってtoken交換し、refresh_tokenをSecret Managerに保存します。

初めて接続した時は、Secret Managerを使わなかったのですが、最終的に使うことになった理由は後述します。

そして、freee APIを叩いてデータを取得し、freeeの取引一覧（deals）を期間指定で全件取得して、BigQueryに同期します。

BigQueryに同期したfreeeの取引データ

トークンのエラー沼にご注意

連携は成功しましたが、翌日にデータを更新すると、エラーになりました。

{'error': 'invalid_grant', 'error_description': '指定された認可グラントは不正か、有効期限切れか、無効か、リダイレクトURIが異なるか、もしくは別のクライアントに適用されています。'}

どうやら認証エラーが発生しているようです。

いろいろ検証したところ、トークンが原因でした。

refresh_tokenでaccess_tokenを取得し、access_tokenでfreee APIを呼ぶ流れになっていますが、refresh_tokenを使ってaccess_tokenを取得すると、レスポンスに新しいrefresh_tokenが返ってくることがあります。

その場合、古いrefresh_tokenを使うとエラーになります。

refresh_tokenを使い回すことはできず、最新のrefresh_tokenを常に保持しなければなりません。

refresh_tokenは、APIを実行する度に変わるとは限りません。

そのため、APIを実行し、レスポンスに新しいrefresh_tokenが含まれていたら、そのtokenを保存して更新することでエラーを回避します。

Cloud Runの環境変数にrefresh_tokenを固定せず、Secret Managerをrefresh_tokenの台帳として使うように設計することでエラーを回避できました。

Google Cloud開発お承ります

datacompanyでは、お客様のご予算・環境に応じたクラウド開発を承ります。

お困りごとがございましたら是非ご相談ください。

お問い合わせフォーム

投稿日:

e-TaxでエラーHUBH139Eが発生した時に試すこと

e-TaxでエラーHUBH139Eが発生した時に試すこと

・マイナンバーカードやスマートフォンで国税を電子申告できる納税システム「e-Tax」
・個人の確定申告から法人税まで、スマートフォンの電子証明書で簡単に申告できる
・ただし、マイナンバーカードを更新すると、e-Taxに登録済みの電子証明書と異なりエラーが発生する場合がある
・e-Taxの電子証明書を更新する時に、スマートフォンのマイナンバーカードで署名せず、実物のマイナンバーカードで署名を試す

今回は、クラウドや生成AIではなく、e-Taxのお話です。

e-Taxは、マイナンバーカードやiPhone等のスマートフォンで国税を電子申告できる納税システムです。

個人の確定申告から法人税まで、スマートフォンの電子証明書で簡単に申告できることから、使ってらっしゃる方も多いと思います。

今回は、マイナンバーカードを更新したことで申告エラーが発生したものの、いつもと違うリンクをタップすることで解決したお話になります。

同じようにお困りの方もいらっしゃると思いますので、ご参考になれば幸いです。

見慣れないエラーHUBH139Eが発生

e-Taxは、個人の時から使っており、スマートフォンで確定申告していました。

スマートフォンにマイナンバーカードを取り込み、電子証明書として使えるようになってから利便性もさらに高まり、使い勝手の良いサービスだと思います。

このたび、法人税を申告したところ、エラーになりました。

見慣れないエラー「HUBH139E」が発生

※画像は会計ソフトの画面。e-Taxも同じエラーを確認。

エラー情報によると、e-Taxに登録済みの電子証明書と、今回の申告に使った電子証明書が異なることが原因のようです。

個人の確定申告もe-Taxを使いましたが、最近になって、マイナンバーカードを更新したことを思い出しました。

おそらく、電子証明書も更新されており、そのことが原因だと思いました。

そこで、ヘルプページを確認し、e-Taxのマイページから電子証明書を再登録しました。

e-Taxのお知らせで、「電子証明書の登録」→「送信されたデータを受け付けました」の通知が届いたことを確認し、再度、法人税を申告しました。

しかし、同じエラーが発生し、ここで沼にはまってしまいました。

e-Taxの受信通知で、電子証明書が受け付けされたことを確認していたが、エラーになった。この通知が届くと、原則として、e-Tax側は即時反映されると聞いていたこともあり沼にはまった。

e-Taxの電子証明書を更新する時に、スマートフォンのマイナンバーカードで署名せず、実物のマイナンバーカードで署名を試す

e-Taxの電子証明書の更新は、マイページ→その他の登録情報→電子証明書の登録・更新からできます。

ここが沼にはまった原因でした。

電子証明書の各項目はスマホ用を指定

下にスクロールすると、このような画面が出てきます。

「スマートフォンを利用」をクリックすると、QRコードが表示されます。

QRコードをスマートフォンのマイナポータルアプリで読み取ると、スマートフォンに次のような画面が表示されます。

この画面が表示されたら、一番下の「実物のマイナンバーカードで署名」をタップして、電子証明書を更新します。

この方法でe-Taxの電子証明書を更新したところ、エラーHUBH139Eは解消しました。

スマートフォンにマイナンバーカードを取り込み、電子証明書として使えるようになってから、「iPhoneのマイナンバーカードで署名」を常にタップしていました。

おそらく、「iPhoneのマイナンバーカードで署名」をタップして電子証明書を登録し、e-Taxのお知らせで、「電子証明書の登録」→「送信されたデータを受け付けました」の通知が届いたとしても、古い電子証明書で上書きしたことになると思われます。

Google Cloud開発お承ります

datacompanyでは、お客様のご予算・環境に応じたクラウド開発を承ります。

お困りごとがございましたら是非ご相談ください。

お問い合わせフォーム

投稿日:

Google Cloud Storage Transfer（ST）の限界

Google Cloud Storage Transfer（ST）の限界

・誰でも簡単にノーコードでStorage間でデータ転送できることが魅力的
・例えば、Google Cloud StorageのバケットAからバケットBに定期的に自動転送
・ただし、任意の日時で繰り返し転送できない　繰り返し設定は時間・日・週のみで、月次も不可
・工数はかかるが利便性や長期的な運用を考慮すると、Cloud Runでフルスクラッチ開発がベター
・Cloud Runなら、任意のスケジュールで転送できる

Google Cloud Storage（GCS）のようなStorage間でデータを転送したい時に役立つのがGoogle Cloud Storage Transfer（ST）です。

便利で簡単に設定できるため、バケット間でデータを転送する時など、知らないうちに利用していたという方も多いと思います。

STは、たびたびアップデートされており、AWS（S3）からGCSも転送できます。

STのユースケース　GCSのバケット間の転送

STで、よく使われているケースとして、GCSのバケット間の転送があります。

特に、KPIをトラッキングする企業様において、社内外のデータをGCSで管理されており、それらを運用して統合分析する場合に役立ちます。

実装もとても簡単です。

転送ジョブを作成します

次のステップへ進みます

ソース（転送元）を指定し次へ進みます

転送先を指定し次へ進みます

ジョブの実行タイミングを指定し次へ進みます（本日のテーマです）

お好みの設定で作成し設定完了です

STには限界もある

このように設定すると、任意のタイミングでStorage間のデータを自動で転送します。

ノーコードで簡単な操作だけで、このようなデータ転送を構築できます。

しかし、STには限界もあります。

例えば、毎月1日AM9時に1回だけ転送を設定します。

カスタム頻度で実行を選びます

頻度に「月」がないため設定できません

1時間毎や2週間毎等は設定できますが、毎月は設定できません。

そのため、任意の日時で繰り返し転送できません。

Google Cloud Run Functionsのフルスクラッチでカスタマイズ対応


このようなケースの場合、初期工数はかかりますが、Google Cloud Run Functionsのフルスクラッチ開発がベターになります。

Cloud Run Functionsなら、毎月1日AM9時に1回だけ転送といったように、任意の日時でピンポイントに転送できます。

STはデータ容量やファイル数で課金されるため、それらが多い場合の費用も抑制できます。

Cloud Run FunctionsはPythonに対応。イベント駆動で様々なケースに応じた処理がサーバレスにできる。

Google Cloud開発お承ります

datacompanyでは、お客様のご予算・環境に応じたクラウド開発を承ります。

お困りごとがございましたら是非ご相談ください。

お問い合わせフォーム

投稿日:

VertexAIとBQMLの効率的な使い分け

VertexAIとBQMLの効率的な使い分け

・様々なデータでAIモデルを作れるVertexAI
・人気の売上予測モデルも、AutoMLにデータを読ませればノーコードで自動作成
・ただし、モデル作成は1時間あたり約$21と高額
・非公式だが、Googleが推奨する方法で、費用と精度を両立したモデル作成が可能

生成AIが全盛期ですが、従来のAIもいまだ現役です。

特に、売上予測など、日次バッチでロジックを安定して稼働させたい時に重宝します。

Google Cloudには、たくさんのAIがあります。

SQLやPythonはフルスクラッチでモデルを作れますが、ノーコードでモデルを作るVertexAIのAutoMLは人気があります。

VertexAI　AutoML　※公式ページにリンクします

VertexAIは利用料金がとても高い

VertexAIは、ノーコードでAIモデルを作れるため、誰でも簡単に扱えます。

AutoMLは、目的などを選択するだけで、データにあわせたロジックが自動で反映され、予測モデルを簡単に作れます。

しかし、一部のモデルは利用料金がとても高いです。

例えば、売上予測に必要な表形式データを読み込ませると、モデル作成は1時間あたり約$21課金されます。　

VertexAIの料金　※公式ページにリンクします

モデルを完成させるまでに、様々なパターンを試すのが一般的です。

一度で完璧なモデルができることは稀で、それはほとんど空想のレベルです。

経験則ではありますが、1つのモデルを作るまでに、100回程度は試行錯誤しています。

VertexAIは、モデル作成を実行開始してから完了するまで、とても時間がかかります。

レコード数とカラム数がまったく同じデータで試してみてください。

SQLやPythonでフルスクラッチでモデルを作成するより、明らかに時間がかかります。

仮に、モデル作成1回に1時間かかった場合、100回試行すると、100時間です。

モデル作成は1時間あたり約$21です。

$21×100=$2,100≒32.3万円課金されてしまいます。※執筆当時の為替レートで試算

これでは課金が気になり、モデルを安心して作れません。

VertexAIとBQMLの効率的な使い分け

Google Cloudには、VertexAI以外にもBQMLというAIがあります。

BQMLは、Google CloudのDWH「BigQuery」に実装されているAI機能です。

BQMLはVertexAIとも連携していますが、モデル次第では、安価にモデルを作れます。

BQMLは、時間課金ではなく、クエリ実行でスキャンしたデータ量に応じて課金されます。

つまり、「どれだけのデータを読み取ったか」に応じた課金です。

一般的に、売上予測のデータは軽量で、Byte数が大きくなることは、そうありません。

非公式　Googleが推奨する費用と精度を両立したモデル作成

仕事の関係上、Google Cloudの皆様とお話することがあります。

売上予測のデータが軽量にも関わらず、VertexAIの処理が遅くて課金に悩まされていた頃、原因調査と改善を依頼したことがありました。

調査しても原因は不明で、VertexAIを使うと、処理に時間がかかってしまします。

そこで、以下のような処理を試したところ、費用と精度を両立してモデルを作成できました。

BQMLも、以前より、精度や機能が格段にレベルアップしています。

以前のBQMLに満足できなかった方も、お試しされてはいかがでしょうか。

フルスクラッチにはなりますが、皆様のご参考になれば幸いです。

・まず、VertexAIで最初のモデルを作ります。
・モデルができたら、特徴量をチェックします。
・VertexAIが選んだ特徴量を参考に、BQMLでモデルを再現します。
・モデルを再現したら、お好みの精度になるまで、BQMLでモデルを更新します。

Google Cloud開発お承ります

datacompanyでは、お客様のご予算・環境に応じたクラウド開発を承ります。

お困りごとがございましたら是非ご相談ください。

お問い合わせフォーム

投稿日:

Cloud Data Fusionがスケジュール実行エラーした時の対処法

Cloud Data Fusionがスケジュール実行エラーした時の対処法

・外部ソースとGoogle Cloudのパイプラインをノーコードで構築できるCloud Data Fusion
・設定済みのスケジュールタスクにおいて、エラーが発生することがある
・スケジュール設定を見直すだけで解決する場合がある

SalesforceやAWSのRedshift等の外部ソースをGoogle Cloudへ連携する方法はいくつかありますが、最も簡単でメジャーな方法はCloud Data Fusionです。

Cloud Data Fusionは、外部ソースとGoogle BigQueryなどGoogle Cloudを連携できるノーコードツールで、パイプラインを簡単に構築できます。

インスタンスを作成することで、毎日およそ数十ドルのコストが発生しますが、とても簡単にパイプラインを構築できるので、利用されている企業様も多いです。

Cloud Data Fusion公式

成功したはずのデプロイが、スケジュール実行するとエラーになる

簡単にパイプラインを構築できるCloud Data Fusionは、デプロイしたパイプラインをスケジュール設定することで、簡単にバッチ化できます。

しかし、デプロイに成功したはずのパイプラインを、スケジュール実行すると、エラーになる場合があります。

エラーになったログをダウンロードして確認すると、以下のようなキーワードが出力されます。

Spark Program　'phase-1' failed

Cloud Data Fusionは、複数のステップを踏んで、外部ソースをGoogle Cloudに連携します。

このエラーは、’pahse-1’で失敗しており、そのエラーメッセージの付近に、このような記述もあります。

Caused by ...省略... The connection attempt failed.

接続に失敗したというエラーが発生しています。

このエラーは、外部ソースへの接続情報やファイヤーウォールなど設定関連が誤っている時に発生します。

でも、おかしいですよね。

デプロイに成功しています。

設定は正しいので、エラーになるはずがありません。

高負荷の処理が集中すると、外部ソースもCloud Data Fusionもリソースがひっ迫してエラーになりやすい

Cloud Data Fusionは、同時に複数のデプロイを実行できます。

その上限は開示されていませんが、おそらくCloud Data Fusionのバージョンや、インスタンスのエディション等で異なります。

私の経験上ではありますが、現行のBasicエディションであれば、50個程度は実行できたと思います。

しかし、スケジュール設定においては、最大で10個しか同時に実行できません。

これは、同時実行数を減らすことで、高負荷の処理を分散する意図だと思われます。

おそらく、10個同時にスケジュール実行したことで、リソースがひっ迫し、エラーになったようです。

スケジュール設定を見直すだけで解決する場合がある

10個同時に実行してダメな場合、同時実行数を減らさなければなりません。

しかし、デプロイ数が多い場合、同時実行数を１つに設定してしまうと、全体の処理が終わらず、データ更新が終わりません。

もし、100個のデプロイをスケジュールしたい場合、100個を１つずつ実行するので、相当な時間がかかります。

このような場合、以下のように設定を見直すだけで、解決する場合があります。

10個同時に実行する点においては、外部ソースやCloud Data Fusionへの負荷がかかる点は変わらず、根本的な解決にはなりませんが、起動処理などのタイミングをずらすことはできます。

変更前

デプロイ番号スケジュール　開始時刻
#1~#100:00AM
#11~201:00AM
・・・省略・・・
#91~#1009:00AM

変更後

デプロイ番号スケジュール　開始時刻
#10:00AM
#20:06AM
・・・省略・・・
#919:00AM
・・・省略・・・
#1009:54AM

Google Cloud開発お承ります

datacompanyでは、お客様のご予算・環境に応じたクラウド開発を承ります。

お困りごとがございましたら是非ご相談ください。

お問い合わせフォーム

Proudly powered by WordPress