BigQueryのBigLakeテーブルと従来の外部テーブルを比較してみた | DevelopersIO
Google Cloudデータエンジニアのはんざわです。 前回に引き続き、BigLakeテーブルを紹介したいと思います。 今回の記事では、従来の外部テーブルとBigLakeテーブルを比較し、BigLakeテーブルが従来の外部テーブルより優れている点を簡単に紹介したいと思います。 前提条件 Cloud StorageをデータストアとしたBigLakeテーブルと外部テーブルを比較します BigQuery Omniを使用した他クラウドのBigLakeテーブルやCloud Bigtableなどをデータストアとする外部テーブルは検証の対象外です そもそもBigLakeテーブルとは？ BigLakeテーブルは、従来の外部テーブルと同様に外部のデータストアのデータにアクセス可能なテーブルです。 従来の外部テーブルと比較するとアクセス権の委任により、「ユーザーがBigLakeテーブルにアクセスする権限」と
【AWS】Amazon Security Lakeの概要とアクセス管理の検証 - Qiita
はじめに 2023年5月に一般提供を開始したAmazon Security Lake(以後Security Lakeと記載)についてサービスの概要と特徴であるアクセス管理(データアクセス,クエリアクセス)に焦点をあてて記載します。 今回解説を行わない内容 Security Lake 環境構築の諸設定解説 Security Lake に蓄積したデータの可視化 目次 ・Security Lakeとは ・メリット ・システム構成図とアクセス管理の検証箇所 ・導入ステップ ・アクセス管理動作検証 ・どのような活用が期待されるか ・注意点 Security Lakeとは Security Lakeは、フルマネージド型のセキュリティデータレイクサービスです。 AWS環境・SaaSプロバイダー・オンプレミス・クラウドソースからのセキュリティデータ（ログ・イベントデータ）を、アカウントに保存されている専用
【新機能】BigQuery data canvasを早速触ってみた #GoogleCloudNext | DevelopersIO
Google Cloudデータエンジニアのはんざわです。 現在開催中のGoogle Cloud Next'24でBigQuery data canvasという新機能が追加されました。 本記事では早速この新機能を触ってみたいと思います！ BigQuery data canvas とは？ BigQuery data canvasは、データソースの選択、クエリの実行、可視化をDAGで操作できる分析用のインターフェイスです。 また、Geminiのサポートにより、自然言語を使用したデータの検索やSQLの作成、グラフの生成も行うことが可能です。 BigQuery data canvasの公式ドキュメント それでは早速触ってみたいと思います！ 注意 2024年4月10日時点でBigQuery data canvasはprivate プレビューで、使用するためにはRequest BigQuery data
Repro における Presto Cassandra Connector 改造秘話 / Presto Conference Tokyo 2020
https://techplay.jp/event/795265 の発表資料です
Amazon DataZone 初期導入から Amazon Redshift 統合の新機能まで解説する！ | DevelopersIO
Amazon DataZone 初期導入から Amazon Redshift 統合の新機能まで解説する！ はじめに クラスメソッドの石川です。Amazon DataZoneは、クラウドサービス間の連携を活かし、Amazon Redshift統合の機能強化により、従来よりも簡単な操作で環境設定ができるようになりました。データガバナンス系のツールは設定が多くなりがちなので、この利便性は多くのユーザーにとって気になるところでしょう。 今回は、Amazon Redshiftのサンプルデータの作成からAmazon DataZoneの初期導入とAmazon Redshift 統合まで解説します。 すでに、Amazon Redshift 導入済みの方は、「Amazon DataZoneの準備」から、Amazon Redshift 統合の機能強化のみご覧いただきたい方は「環境プロファイルを作成」から読み進
AWS Glue × Apache Iceberg で構築する更新可能なデータレイクテーブル
こんにちは。シンプルフォーム株式会社 にてインフラエンジニアをしています、山岸です。 社内向けに運用しているデータ分析基盤について現状抱えているいくつかの課題を克服すべく、最近は更改に向けた検証に取り組んでいます。今回は取り組みの一つである「AWS Glue と Apache Iceberg によるデータレイクテーブル構築」についてご紹介したいと思います。 概要 当社ではデータ分析基盤の ETL 処理に AWS Glue を使用しています。社内のデータ分析業務等のため、RDS データベース等のデータソースから日次で S3 上に構築された DWH に連携しています。 現行のデータ分析基盤では、DB テーブル上のデータを毎日全件洗い替えています。このような処理方法は ETL 実装や問題発生時の復旧が簡単である一方、ETL 処理のコスト効率が悪く、データ量の増加に伴って処理時間も長くなっていきま
分析基盤へのデータ連携処理をEmbulkからAmazon Aurora S3 Export機能に切り替えた話 - BASEプロダクトチームブログ
はじめに こんにちは！Data Platformチームでデータエンジニアとして働いている @shota.imazeki です。 分析基盤の構築・運用などの側面から社内のデータ活用の促進を行っています。 BASEではAurora MySQLにあるデータをEmbulkを用いてBigQueryに連携しています。BigQueryへ連携されたデータは分析基盤としてLookerなどを通して社内利用されています。 このデータ連携処理にはいくつかの課題があり、それを解決するためにEmbulkからAurora S3 Export機能を用いた連携処理に切り替えることにしましたので、それについて紹介していきたいと思います。 ※この切り替えについては現状、試験的に一部のDBのみの切り替えとなっていますが、運用上の大きな課題が出てこなければ徐々に切り替えていく予定です。 切替前のデータ連携処理 先述した通り、BAS
Strata NY 2019 参加記 - Session Day 2 | リクルート
リクルートデータ組織のブログをはじめました。※最新情報はRecruit Data Blogをご覧ください。 Recruit Data Blogはこちら そろそろ時差ボケにも慣れてきました、データ分析基盤チームのエンジニアの鳥井です。 こちらの記事に詳しいですが、 この記事を執筆している今、O’Reillyが主催している Strata Data Conference 2019 @ NY というカンファレンスに参加しています。 Strataについてと、Session Day 1の印象に残ったセッションについて、上記記事で紹介させていただきました。 この記事では、1本目の記事に引き続き、Session Day 2で聞いた中で印象に残った発表を1つ簡単に紹介したいと思います。 Session Day 2 Creating an extensible 100+ PB real-time big da
データエンジニアリングの要諦の後ろ髪を掴む - Fundamentals of Data Engineeringを読んで - じゃあ、おうちで学べる
最強なデータ分析基盤は何か⁉︎多種多様なデータ分析基盤が、制約のない環境で競合した時… ビジネス用途に限らず、あらゆるシナリオで使用可能な「データ分析」で比較した時、最強なデータ分析基盤は何か⁉︎ 今現在最強のデータ分析基盤は決まっていない データ分析基盤まとめ（随時更新） などもあり大変参考にさせていただきました。ありがとうございます。 はじめに データエンジニアリングは、データの収集、処理、保存、そして提供を行う技術やプロセスを扱う複雑な分野です。この分野の全容を系統的に把握することは決して容易なことではありません。このような状況の中で、『Fundamentals of Data Engineering』という書籍に出会いました。この本は、著者たちの豊富な実務経験に基づいて書かれており、データエンジニアリングの基本概念とそのライフサイクルに焦点を当てています。さらに、これらの概念を現実
pg2arrowを並列化する - KaiGaiの俺メモ
今回は皆さんが大好きな便利ツール「pg2arrow」のお話です。 PostgreSQLでポータブルな列指向データ形式 Apache Arrow を読み出すには、Arrow_Fdwを利用する事ができます。 PG-StromではGPU-Direct SQLにも対応していますし、列指向データという事もあって、被参照列しかI/Oが発生しない、同じ列のデータが近傍に固まっているという大量データ処理に適した特性を持ってもいます。 また、Apache Arrow形式のファイルを作成するにはPyArrowやPandasなど様々なツールがありますが、我々DB屋としてはPostgreSQLに格納されたトランザクショナルなデータを、分析用にApache Arrow形式として吐き出せるととても嬉しい。そんな時に使えるツールがpg2arrowなのです。 pg2arrowは、PostgreSQLにクエリを投げ、その問
【Iceberg 1.5新機能】viewの紹介 - 共通メタデータ形式とバージョン管理が実現する新たな可能性 - 流沙河鎮
はじめに Iceberg view概要 一般的なクエリエンジンにおけるviewの役割 Iceberg viewを使ってみる Iceberg viewのコンセプト メタデータ形式の共有 viewのバージョン管理 Iceberg viewの構成要素と仕組み View Metadata versionsフィールド representationsフィールド 「create_changelog_view」プロシージャによるIcebergのCDC create_changelog_view create_changelog_viewの使い方 引数 アウトプット create_changelog_viewの実行例 Tips Carry-over Rows Pre/Post Update Images ユースケースのアイデア おわりに Appendix: Viewサポートに関連するPR はじめに 2024
データカタログのコメントをLLMに考えさせてみる - Qiita
要約 LLMを使って これを こうします はじめに 今回はBedrockの利用ユースケース案の簡単な検証です。 冒頭示したように、Glue Data CatalogにはGlueでETLジョブを走らせるためのデータスキーマが登録されています。各カラムには名前とデータタイプのほかにコメントを格納できます。コメント自体は機能に何ら影響は与えません。メモ書きです。 あまり意識することはないかもしれませんが、AthenaなどS3をソースにテーブル作成する際には、バックグラウンドで自動的にData Catalog テーブルが作成されます。今回対象としているテーブルもその一つで、先日以下の記事でAthenaを利用する際に作られたテーブルです。このほかにもELBのログ分析のためAthenaを使ったことがある人もそのテーブルが作られているはずです。 このテーブル自体は何てことないテーブルですし、この前作られ
UNION 型: データ型が混在するカラムのサポート - nagix
この記事は Apache Drill Advent Calendar 2015 の3日目の記事です。 少し前の記事で、一つのカラムにデータ型が混在したデータを読むときの注意点を説明しました。 その後リリースされた Drill 1.3 で、[DRILL-3229] Create a new EmbeddedVector にて改良が進行中のコードが取り込まれたことにより、データ型が混在するカラムの取り扱いができるようになりました。具体的には、UNION 型というデータ型が新たに追加され、個々のフィールドごとに異なるデータ型を内部で保持できるようになっています。 以前の記事同様、次のようなデータを用意します（以前の記事の時のデータとはほんの少し異なりますが、その理由は後述）。 $ cat /tmp/sensor.json [ {"sensor_id":15, "timestamp":"2015-
分析者から見た使いにくいデータ基盤の話 | リクルートテクノロジーズ メンバーズブログ
リクルートテクノロジーズのアドベントカレンダーの 12/25 の分です。 要するにデータが潤沢なデータレイクと、秩序だったデータウェアハウスがほしいという話をします。データマートは分析者も必要に応じて作ればいいので、なくても問題ないです。データレイク、データウェアハウス、データマートについては本記事で解説します。 とはいえ、「データあるから分析してくれ」を最初に取りかかる場合は、秩序だったデータウェアハウスが無いはずなので、データレイクに大量のデータがあれば贅沢は言いません。実はデータがない状態は本記事では想定していません。 本アドベントカレンダーでは似た内容を先に書かれましたが、本ブログでは使う側の視点なのでちょっと違います。とはいえ、目指す姿はだいたい似るはずです。 http://yuzutas0.hatenablog.com/entry/2018/12/08/235900 なんのため
RAG用ドキュメントとしてのデータカタログ
データカタログの悩み dataplexやdbt docs、その他無数のSaaS製品に代表されるデータカタログは、データリネージを自動的に生成できるなど便利な機能を数多くそろえている一方で、物足りない点もまだ多く、特にマネージャー陣など非データ分析職や他チームからの問い合わせを削減することは過去の経験から考えてもまだ難しいと感じている。 自チームがデータ分析を行う際には、とりあえずデータカタログで調べてみるという形を実現できたことはあるのだが、 マネージャー「AのディメンションごとにBのメトリクスを自分で集計したいが、どのテーブルを使えばいいか」 別チームのメンバー「プロダクトXに関する指標Yが数日前から変動しているが、Xのチームで何らかの変更を行ったのか」 といった相談や問い合わせは依然としてそれなりの工数を占めていた。 組織全体でのデータ活用や複数ドメインでのデータ連携ができているという
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
並列分散処理基盤のいま ～45分で学ぶHadoop/Spark/Kafka/ストレージレイヤSW入門～（Open Source Conference 2021 Online/Hokkaido 発表資料）
Hive on Spark の設計指針を読んでみた
Streamlitを使ってデータカタログを作ってみた
SparkをRESTfulに利用できるApache Livyを導入した話 #hcj2019 #ApacheSpark #ApacheLivy
〜小さく始めて大きく育てる〜データ分析基盤の開発から活用まで