Redshift Serverless RPUスケールの挙動 - Qiita
Redshift Serverlessを使用して気づいたポイントについて記す 思ったよりスケールしない Serverlessであり、負荷に応じて自動的にスケールするなら、Base RPUは8(最小値)で良いと考えて設定した。 しかし、実際にQueryを実行すると、非常に実行が遅く、実際に実行時のCloudwatchを見ると全くRPUがスケールしていないことがわかった。 この挙動が疑問に思えたため、以下の試行を行い、挙動を確認した。 (ちなみに試したのは2023年の3月なのでまた挙動は変わっている可能性もある) まず、十分な負荷のかかるようなデータとSQLを準備するのはそれ自体が工数がかかるので、AWSのブログで紹介されているTPC-DSベースのRedshift用のDWHベンチマークを使用することとした https://github.com/awslabs/amazon-redshift-u
分析基盤をAthenaからBigQueryへノーコードで移行した話 - mikan Developers' Blog
この記事はmikan Advent Calendar 2023の24日目の記事です。 こんにちは。株式会社mikanでPlatform Engineeringチームのリーダーをしております。@hoshitocat です。Platform Engineeringチームは最近できたチームですが、その取り組み内容についてはまた後ほどご紹介できればと思っています。 昨日はQAチームのchiakiさんによる、 「テスト自動化で試行錯誤した話」でした。QAの自動化に取り組みたいと思っている方や、QAコスト削減方法に悩んでいる方はぜひ読んでみてください！ note.com なお、mikan Advent Calendar 2023の他の記事は下記のリンクからご覧ください。 adventar.org はじめに これまでの分析基盤の課題 BigQuery利用への意思決定 Glueを使ってみるが断念 Athe
Google Cloudの監査ログを理解する&長期間保存方法 - NRIネットコムBlog
こんにちは、上野です。 前回に引き続き、Google Cloudのセキュリティ設定第２弾です。今回は監査ログ（Cloud Audit Logs）です。 監査ログは「誰が、いつ、どこで、何をしたか」を残すログで、AWSだとCloudTrailですね。目的はAWSと同じなのですが、設定方法や見え方がけっこう異なるので、概要を掴みつつ追加の保存設定を見ていきます。 Google Cloudの監査ログ 監査ログには、管理アクティビティ監査ログ、データアクセス監査ログ、システムイベント監査ログ、ポリシー拒否監査ログの4種類存在します。 管理アクティビティ監査ログ ユーザーが VM インスタンスを作成したときや IAM権限を変更したときに記録されるログで、いわゆる一般的な監査ログです。デフォルト有効で、無効にできません。 データアクセス監査ログ BigQueryやCloud Storageなど、データ
SnowflakeとMetabaseで作る格安データ分析基盤 - Qiita
導入の背景 Snowflakeを導入し、Talendと各種バッチ処理を作成してデータ分析基盤を構築しましたが、肝心のBIがコストの関係でストップとなりました。当初はPowerBIを導入する予定でしたが、BIをQuickSightに変更してコストを約半分にまで下げる案に変更しても予算がおりませんでした。コスト問題をクリアする為に仕方なくOSSであるMetabaseで構築した環境でしたが、思った以上に低価格で高性能な環境ができあがり、PowerBIに負けてないどころか、こちらの方が使い勝手が上だと思う環境ができましたので、紹介したいと思います。 ###おすすめしたいポイント ■Snowflake ・クエリが投げられた間だけの課金(停止中は課金されない) ・停止中でも瞬間に起動するので、遅延は感じない ・控えめに言っても超高速 ・スタンダード契約なら、最小サイズのXSサイズで1クレジット$2.8
Dataformを使ってデータ分析基盤を構築した話 - Leverages データ戦略ブログ
はじめに こんにちは。レバレジーズ データ戦略室の辰野です。 前回の投稿からいつの間にか1年以上経過していました。引き続きデータマネジメントやデータガバナンスに関連する仕事をしていたのですが、今回は私が昨年度末に取り組んだ、Dataformを利用したデータ分析基盤の構築についてお話させていただきます。 Dataformとは Dataformとは、現在Google Cloudで利用できるデータモデリングツールの一つです。ELT（抽出、読み込み、変換）処理における、T（変換）の部分を管理できます。主な機能として、下記があります。 SQLワークフローを開発、実行できる テーブル同士の依存関係を管理できる テーブルの品質テストができる これらの機能を利用することで、すべてのデータプロセスを管理することが可能です。 （参考：Google Cloud,Dataform の概要） Dataformを導入
Cloud Asset Inventory を使用してGoogle Cloud上のアセットを分析する - NRIネットコムBlog
こんにちは、最近はGoogle Cloudの記事を書いている上野です。（AWSももちろんやってます） 今回はCloud Asset Inventoryを見ていきます。 Cloud Asset Inventoryとは？ Google Cloud上の、アセットを管理できるサービスです。アセットとは、大きく以下の2種類を指します。 リソース Compute Engine 仮想マシン（VM）やCloud Storage バケットなどのGoogle Cloud上で作成されたリソースのメタデータ ポリシー IAMポリシー、Organizationsポリシーなど、誰が何にアクセスできるかという情報（ポリシーのメタデータ） Google Cloud上に5 週間分の履歴情報が保管されています。 AWSで言うとAWS Configに近いサービスになります。 Cloud Asset Inventoryの開始方法
SnowflakeでFunctional Role+Access Roleのロール設計を実現するTerraformのModule構成を考えてみた | DevelopersIO
SnowflakeでFunctional Role+Access Roleのロール設計を実現するTerraformのModule構成を考えてみた さがらです。 2024年1月にSnowflakeのTerraform Providerに関する2024年のロードマップが公開されています。 このロードマップについてわかりやすくまとめて頂いているのが下記の記事です。内容としては、GRANTの再設計、GAしている全機能のサポート、既存Issueの解決、などに取り組んでいくとのことで、破壊的な変更を含む一方で良い方向に進んでいることが感じ取れます。 そしてこのロードマップのうちの「GRANTの再設計」ですが、「v0.88.0でGRANTの再設計は完了」「以前の形式のGRANT関係のリソースは2024年6月26日に削除」というDiscussionが投稿されていました。着実に開発が進んでいますね。 そこで
AWS Cost and Usage Report(CUR)をTerraformで作成する
AWS Cost and Usage Report（AWSのコストと使用状況レポート、以下CUR）は、AWSのコストやリソースの使用状況をS3やRedshiftにアップロードしてくれる機能です。EC2インスタンスIDなどのリソース単位を含めることができるため、コストの追跡が容易になります。 Cost Explorerと異なり、EC2以外のAWSサービスのリソースも含まれます。1日1回以上、S3にアップロードされるので、自分たちの使い慣れたBIツールなどで分析・可視化することができます。 AWSマネジメントコンソールからCURを設定することが多いのですが、今回はTerraform（一部CloudFormation）で作成する方法を紹介します。 プロバイダの設定 今回は、CURのデータを保存するS3バケットを東京リージョン（ap-northeast-1）に作成します。 後述しますが、CURを作
拒否ポリシーでBigQueryのテーブル削除を無効にする
はじめに こんにちは、クラウドエース データ ML ディビジョン所属の疋田（ひきた）です。 珍しい苗字でなかなか覚えづらいと思いますので、是非「ヒッキー」と呼んでいただければ嬉しいです。 クラウドエースの IT エンジニアリングを担うシステム開発部の中で、特にデータ基盤構築・分析基盤構築からデータ分析までを含む一貫したデータ課題の解決を専門とするのがデータ ML ディビジョンです。 データML ディビジョンでは活動の一環として、毎週 Google Cloud (旧 Google Cloud Platform、以下「GCP」) の新規リリースを調査・発表し、データ領域のプロダクトのキャッチアップをしています。その中でも重要と考えるリリースを本ページ含め記事として公開しています。 今回ご紹介するリリースは、2023年8月7日にサポートするようになった、拒否ポリシーを介してのアクセス拒否機能です
Snowflake 向けの DevOps の取り組みと現状の課題についてまとめてみた
本記事の背景 本記事は、某所で密かに行われていた Snowflake DevOps 情報交換会 Season 1 最終回の議論用に共有した内容です。 本会は、 DevOps を中心に、また DevOps とは直接は関係ないテーマも含め、その時々において関心のあるテーマを取り扱っていましたが、今回は最終会ということで、本来のテーマである DevOps において、私個人が中心的テーマであると考える構成管理やデプロイの自動化について議論したいと思い、整理しました。 中心的テーマを再び取り上げようと考えたきっかけの 1 つが Snowflake Data Superhero の Tomas が LinkedIn で EXECUTE IMMEDIATE FROM という新しい構文について紹介しているのを発見したことです。これはステージ上の SQL ファイルを直接実行できるという機能です。 Tomas
Snowflakeにて大規模なテーブルのクエリ実行時間を高速化するためのマイクロパーティションという選択肢について
テーブルに対して設定する場合は、複数の日付列を指定するのが良いと記載があります。この場合は日付列はTIMESTAMP型の場合はTO_DATEでキャストすることを推奨されています。 例えば、ファクトテーブルに、多くの離散値（テーブル内のマイクロパーティションの数よりも多く）を含む TIMESTAMP 列 c_timestamp がある場合、タイムスタンプではなく日付に値をキャストすることで、列にクラスタリングキーを定義できます（例： to_date(c_timestamp)）。これにより、カーディナリティが合計日数に削減され、より優れたプルーニング結果が通常生成されます。 引用元：クラスタリングキーを選択するための戦略 費用 今回の例では、DATE列に指定した場合は約5クレジット、DATE列を含む4列に指定した場合は22クレジットの消費でした。 自動クラスタリング クラスタリングキーを設定し
EventarcでBigQueryのテーブル挿入をトリガーにworkflowsを動作させる
今回はEventarcでBigQueryのテーブルにデータが挿入されたときにworkflowsをキックするということをやってみたいと思います。 従来はEvetarcでGCSのデータ更新をトリガーにCloud Functionsを実行する。のような構成はとれていたのですが、BigQueryのデータ挿入をトリガーに実行できるようになっていますので、少し試してみたいと思います。 Workflowsの設定 以下のようにWorkflowsを設定していきます。 ここで躓きやすいのはService Accountの指定です。ここでのSAはWorkflows実行用のSAを用意しておくといいでしょう。 ここでのSAにはworkflowsで実際に呼び出すAPIへのアクセス権を付与しておく必要があります。例えば、BigQueryをworkflowsで実行する場合はBigQueryへのアクセス権を付与しておく必要
【コスト最適化】BigQuery Editions などの解説と見積もり方法
2023 年度の Google Data Cloud & AI Summit にて BigQuery に対する超有益なアップデートが発表されました！ 価格体系の変更について、有効的に活用すればコストの最適化ができるものになります。 ヘビーユーザーは当然のこと、ライトユーザーやこれから検証のために少し触ってみたいような方々に向け、おさらいも交えながら説明をさせていただきたいと思います。また、弊社内で実際に利用している BigQuery のデータセットに対し、この変更でコストがどのように最適化できるのかも紹介させていただきます。 価格体系の変更 まずは、おさらいとして BigQuery の価格体系を解説します。 BigQuery のアーキテクチャはストレージとコンピューティングに分離されています。伴って、BigQuery の料金は、Storage pricing (ストレージ料金)と呼ばれるス
Pub/SubのBigQueryサブスクリプションの書き込みレイテンシを計測する
概要 Pub/SubからBigQueryに直接ストリーミングインサート可能なBigQueryサブスクリプションの書き込みレイテンシを計測したので、計測方法と結果を残します。 BigQueryサブスクリプションとは メッセージキューであるPub/SubからBigQueryに直接データをストリーミングインサートできるサービスです。 このサービスを使うことで、DataflowやCloud Runなどのサブスクライバーを挟まないシンプルな構成のストリーミングデータパイプラインを構築可能です。 間にサブスクライバーを挟まないので、生データをそのままBigQueryに書き込むことしかできません。 計測対象 今回の計測対象は、Pub/SubのBigQueryサブスクリプションからBigQueryへ書き込まれるまでです。 データソースで、データが発生してからBigQueryへ書き込まれるまでの時間ではあり
ついにGAした Redshift と Aurora の Zero-ETL でニアリアルタイム連携 - Qiita
[1] はじめに Zero-ETL統合とは？ OLTP系DBとOLAP系DWHはそもそも役割が違うので、従来はOLTP DBに蓄積されてたデータをDWHにデータ連携するETLが必要だった この連携は結構大変で、要件に応じて例えばGlue、DMS、Kinesys、MWAA、StepFunctionsなどなどいろいろなサービスを組み合わせて実現する必要があった この煩雑な工程をなくして、ニアリアルタイムでデータ自動連携しようというAWSの構想がZero-ETL Zero-ETLの範囲や実現方法はいろいろある https://aws.amazon.com/jp/what-is/zero-etl/ OLTP系DB〜DWH(Redshift)に着目すると、2023年12月時点で以下のDB間のZero-ETL統合ができる。 Aurora MySQL → Redshift（GA) Aurora Post
BigQuery の Execution Plan を体感&可視化で理解してパフォーマンスチューニングする - Qiita
この記事では、BigQuery に搭載されている Query execution graphs を用いて、なんとなくクエリのパフォーマンスを最適化する方法を説明します。 ほとんどの項目が経験と憶測で書かれているので、あくまで参考程度にお願いします。 Query execution graphs とは Query execution graphs とは、BigQuery が SQL クエリを解釈して実行計画を作成する際に生成される内部表現です。Execution graphs は、クエリの各ステップをノードとして表し、ノード間のデータフローをエッジとして表します。また、グラフを見ることで、クエリの実行順序や依存関係、並列度やリソース消費などを把握することができます。 主に以下のようなノード(ステージ)があります。 Input: データセットからデータを読み込むノード。テーブルデータの統計情報
バクラク事業部による AWS コスト管理の課題に対して行った3つの取り組み - LayerX エンジニアブログ
こんにちは！バクラク事業部 Platform Engineering 部 DevOps チームの多田(@tada_infra)です。7月はLayerX エンジニアブログを活発にする期間でして、ぜひ左記のリンクを辿って気になる記事を見ていただけるとありがたいです！先週の金曜日は Natsuo さんのLayerX のエンジニアインターンって実際どうなん？に答えていくでした。この記事では DevOps チームで行った AWS コスト管理の課題にまつわるお話になります。 AWS コストに関して持っていた課題感 1. サービスのコスト高騰の検知が遅いこと 2. コストの可視化ができていなかったこと 課題に対して取ったアクションの紹介 1. コストが高騰している特定サービスのコスト削減・最適化 2. コストの上昇を検知するために AWS Budget Alert と Cost Anomaly Dete
Datastream for BigQuery を本番導入しようとしている話
オープンロジという物流テック企業でエンジニアをやっている阿部です。オープンロジではデータ基盤の整備を進めており、その第一弾として Datastream for BigQuery を本番導入しようとしています。導入の経緯や、これまでに調査して分かったコトなどを書いていきたいと思います。 トリッキーな挙動になることもありますが、総じて非常に優れたマネージドサービスです。RDB と BigQuery を同期する仕組みとしては、かなり優秀です。まだ、本格的な稼働はしていませんが、いずれオープンロジのデータ基盤の中核を担うシステムになると思っています。 Datastream for BigQuery とは？ MySQL, PostgreSQL などのリレーショナルデータベース (RDB) から BigQuery に準リアルタイムでデータを同期する Google Cloud のサービスです。RDB が
Cloud Run (Grafana) + BigQuery + IAPでデータの見える化を実現した - 株式会社ヘンリー エンジニアブログ
こんにちは、ヘンリーでSREをしているTODA（＠Kengo_TODA）です。 弊社ではデータの共有は主にNotionを用いています。ただ各システムからデータをかき集めて動的に共有するには、Notionはちょっと向いていないなと思うところがあります。データを通じてシステムや顧客、チームの課題を掴むことはスタートアップの生命線とも言え、SLOやKPIを動的に図示してスタンドアップミーティングなどで共有できる仕組みが必要だと感じていました。 このため、Grafanaを用いた仕組みをGCP上に構築しました。ウェブページを自動生成できるツールからの情報は以前Noteでご紹介したサーバーレス社内サイトで展開していますが、Grafanaであれば動的にコンテンツを構築して提供できると期待しています。 この記事ではGCPないしGrafanaの設定をどのようにしたか、その背景とともに説明していきます。 どの
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
BigQuery Remote Functionsによる形態素解析 - DMM inside
