BigQueryを題材にし、大規模なデータベースでの分散処理の仕組みについて紹介します。
BigQueryの分散処理の仕組みを深掘りする_プレイドエンジニアブログ
BigQueryを題材にし、大規模なデータベースでの分散処理の仕組みについて紹介します。
BigQueryのテーブルでパーティション数の上限が増えました | DevelopersIO
Google Cloudデータエンジニアのはんざわです。 2024年5月29日のアップデートにより、パーティション分割されたテーブルにおけるパーティション数の上限が増加しました。 これにより、これまで以上に長期間のデータをBigQueryに保存できるようになりました。 BigQuery release notes： 5月29日 2024 個人的には大きなアップデートだと思うので早速ブログを執筆しています！ どれくらい増えるのか 今回のアップデートでパーティション数の上限が4000から10000に増加しました。 これにより、アップデート前後のパーティション数の上限と日次パーティションの対応年数を表で示すと次のようになります。 項目 アップデート前 アップデート後
dbtを導入した話、そしてClassiのデータ基盤「ソクラテス」の現在地 - Classi開発者ブログ
こんにちは、データプラットフォームチームの鳥山（@to_lz1）です。 Classiでは、2019年ごろからデータ基盤に「ソクラテス」の愛称をつけて運用を続けています。初期の構成は2021年に書かれたエントリ*1にも詳しいですが、数年の間に進化したことも増えてきました。 大きな変化の一例として、最近、私たちのチームではdbt*2を導入してジョブ間の依存管理やメタデータの管理を改善しました。 本記事ではこの取り組みをピックアップして紹介します。また、進化したソクラテスの構成図をアップデートするとともに、Classiデータプラットフォームチームの最新版の雰囲気もお伝えできればと思います。 dbt移行前の構成 ジョブ間の依存管理がつらい メタデータの管理がつらい 過去との差分と、移行への機運 周辺ツールのエコシステムが整った エンジニア以外のメンバーがPull Requestを出すことが減った
BigQuery の 履歴ベースの最適化 (History-based Optimizations) を試したかった
はじめに こんにちは、クラウドエース データソリューション部所属の濱です。 データソリューション部では、Google Cloud が提供しているデータ領域のプロダクトについて、新規リリースをキャッチアップするための調査報告会を毎週実施しています。 新規リリースの中でも、特に重要と考えるリリースを記事としてまとめ、本ページのように公開しています。 クラウドエース データソリューション部 について クラウドエースの IT エンジニアリングを担う システム開発統括部 の中で、特にデータ基盤構築・分析基盤構築からデータ分析までを含む一貫したデータ課題の解決を専門とするのが データソリューション部 です。 弊社では、新たに仲間に加わってくださる方を募集しています。もし、ご興味があれば エントリー をお待ちしております！ 今回紹介するリリースは、2024年4月1日にリリースされた「クエリの履歴ベースの
Soda SQLとStreamlitでポータブルなデータ品質チェックツールを実装する
以前、Great Expectationsを使ったデータバリデーションの仕組みについての記事を書きました。 Great Expectationsはデータに対するテスト実行とプロファイリングを実行し、結果をHTMLで出力してくれる、高機能で便利なツールでした。しかし、環境の構築や設定の準備に手間が掛かり、スモールスタートでテストだけ始めたいというような場合は導入のコストがネックになると思います。 一方で、Great Expectationと同様に有名なツールとして、Soda SQLというものがあります。こちらは、コマンドラインツールで、pipでインストールしてYAMLでテストやプロファイリングの設定を記述すればすぐに実行することができます。 ただし、テストやプロファイリングの実行結果はJSONになるので、Webブラウザでレポートを見たいといった場合には、自前でその仕組みを実装する必要がありま
dbt exposureによるデータ基盤アウトプットの登録を自動化しました - Timee Product Team Blog
はじめに 課題感・背景 使用しているBIツールについて BIツールの使用ボリューム感について やったこと：概要 やったこと：詳細 referenced tableにテーブル名ではなくdbtモデル名が入るようにしたことについて 各種アウトプットの公開設定をmeta情報として付与する方針としたことについて tagを追加してexposureの検索性を向上させたこと exposureのnameにシートとダッシュボードのタイトルを反映する方針にしたこと 今後の発展 保守運用の設計 カラムレベルリネージュ ✖️ exposure おわりに We're Hiring!! はじめに こんにちは。okodooonです！！ データ基盤を参照したアウトプットが社内に溢れかえっていませんか？ 弊社は追いきれていないLookerStudioやConnectedSheetがめちゃくちゃ溢れかえっていました。 そんな折
trocco+JIRAで完成の定義を記入していない課題一覧をBigQueryに同期してデータポータルで可視化する
モチベーション スクラムでは完成の定義とはプロダクトバックログアイテムが品質基準を満たしたインクリメントであることを示す記述です。 リファインメント時にプロダクトオーナーと開発者が合意を取った上で記入してから、スプリントで着手するのが理想ですが、記入が完了していないまま着手に取り掛かってしまっている課題が無いかを確認したいことがありました。 今回はそのためにやったことを残します。 対象読者 既にtroccoを導入している方 最終イメージ こんな感じでアクティブスプリント内で完成の定義の記入が終わっていない課題の内容を可視化することができます。 カスタムフィールドのIDを確認 カスタムフィールドが用意できたら、タイトルから詳細を編集をクリックします。 https://xxxxx.atlassian.net/secure/admin/EditCustomField!default.jspa?i
Great Expectationsを使ったBigQueryでのデータバリデーション
データウェアハウスとしてBigQueryを使う環境でデータバリデーションを実行し、その結果をGoogle Cloud Storage(GCS)バケットに保存することで、データ品質に関するレポートを組織内で共有できるようにしてみます。バリデーションの実装はSQLとして用意するのではなく、JSONで仕様を記述できるGreat Expectationsというフレームワークを使います。バリデーションの実行はデータパイプラインの実装でよく使われるApache Airflowを使います。 データパイプラインでのデータバリデーションの必要性 データパイプラインでデータの自動連携やETLを運用していると、いつの間にか連携されてくるデータの性質や仕様が変わっていることがあります。その変化に気づかず、データパイプラインでデータを処理してユーザに提供してしまうと、そのデータを利用した業務での事故に繋がります。ま
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
エンジニア向けのBIツール、QuaryをBigQueryに接続して使ってみた | DevelopersIO
こんちには。 データアナリティクス事業本部 機械学習チームの中村(nokomoro3)です。 Quaryというエンジニア向けのBIツールが気になったので使ってみました。 GitHub - quarylabs/quary: Open-source BI for engineers VSCodeの拡張機能やCLIが準備されており、以下のことができます。 データベースへの接続 dbtに類似した機能 sqlファイルとしてmodelを記述可能、schemaもyamlファイルで記述可能 schemaはGUIで操作もでき、リネージも表示可能 また簡単なグラフなどもyamlファイルで管理可能 対応ソースはBigQueryやSnowflakeなどとなっていますので、今回はBigQueryで試してみようと思います。 BigQuery側の準備 前準備として、以下のページにある ml-latest-small.z
Redshiftのデータ共有で元DBに作成したテーブルを即時反映させる - Qiita
はじめに Redshiftのデータ共有、皆さん使われているでしょうか。 物理的なコピーをせず、Redshift間でデータの共有ができて便利ですよね。 さて、このデータ共有ですが、既に共有されているテーブルに対してデータの追加や更新（INSERTやUPDATE）をすると即時反映されますが、テーブルの作成（CREATE TABLE）はデフォルトでは即時反映されません。 テーブルの作成も即時反映させたい場合は、ALTER文で SET INCLUDENEW = TRUE SCHEMA schema を実施する必要があります。デフォルトではこれがFALSEになっており、かつGUI上ではこれをTRUEに設定できるところが見つかりませんでした。 今回はこれをクエリエディタv2で実施してみます。 前提条件 以下のRedshiftを、それぞれ別のアカウントで作成済み。 プロデューサーはRedshift Pr
BigQueryのBigLakeテーブルと従来の外部テーブルを比較してみた | DevelopersIO
Google Cloudデータエンジニアのはんざわです。 前回に引き続き、BigLakeテーブルを紹介したいと思います。 今回の記事では、従来の外部テーブルとBigLakeテーブルを比較し、BigLakeテーブルが従来の外部テーブルより優れている点を簡単に紹介したいと思います。 前提条件 Cloud StorageをデータストアとしたBigLakeテーブルと外部テーブルを比較します BigQuery Omniを使用した他クラウドのBigLakeテーブルやCloud Bigtableなどをデータストアとする外部テーブルは検証の対象外です そもそもBigLakeテーブルとは？ BigLakeテーブルは、従来の外部テーブルと同様に外部のデータストアのデータにアクセス可能なテーブルです。 従来の外部テーブルと比較するとアクセス権の委任により、「ユーザーがBigLakeテーブルにアクセスする権限」と
LLMの事前評価のシステムアーキテクチャを紹介します
この記事の概要 こんにちは。PharmaX でエンジニアをしている諸岡（@hakoten）です。 この記事では、「YOJO事業部のプロダクト内で使用されているLLM（Large Language Models）の機能の性能を事前評価するための仕組み」について、システムのアーキテクチャをご紹介しています。 LLMを用いて実現している具体的な機能については詳しく触れていませんので、その点ご理解ください。 LLMにおける事前評価とは何か まず、プロダクトにおけるLLM（Large Language Models）機能の評価がどのようなものかについて簡単に説明します。 LLMの特徴の一つとして、「出力が確率的である（毎回異なる）」という点があります。そのため、LLMで生成された文章や出力に対しては、出力結果の良し悪しを定量的に計測する方法が必要になります。 弊社における定量的な計測は、大きく次の2
Snowflake ArcticにRAGを実装してみる - Qiita
最初に この記事は以下の2つの記事 Snowflake Arcticを試してみる 続・Chromaで埋め込みを体感してみる～日本語対応編～ を組み合わせてみたメモとなります。 昨日(2024/5/6)にSnowflakeのVector EmbeddingsがPublic Preview(PuPr)になったので、RAGの実装をSnowflakeで完結させることもできるのですが、この記事ではプリミティブな方法を理解するという目的でベクトルデータベースを別途導入して接続しています。 RAGの仕組み RAGの仕組みについては、Snowflake社のBLOG Snowflake Cortexを使用した簡単かつ安全なRAGからLLMへの推論に記載されている以下の図が分かりやすいです。 大まかには以下のような流れになります。 Embedしたドキュメントをあらかじめベクトルデータベースに保存しておく ユー
分析基盤を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を導入
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
データカタログの最初の一歩 〜データ組織向けに dbt docs を整備している話〜 / Maintaining dbt docs for data organizations
BigQuery データ キャンバスでデータモデリングしてみた / I tried data modeling with BigQuery Data Canvas
