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のチームで何らかの変更を行ったのか」 といった相談や問い合わせは依然としてそれなりの工数を占めていた。 組織全体でのデータ活用や複数ドメインでのデータ連携ができているという
TrinoとIcebergでログ基盤の構築 | さくらのナレッジ
はじめに 2023年10月5日(木)にTrino / Presto Conference Tokyo 2023 (Online)が開催されました。本記事はイベントにて発表した内容をご紹介します。 社内の監視サーバについて さくらインターネットでは現在社内の各チームでPrometheus, Elastic Stack, Lokiなどの監視基盤を個別に運用しています。この状態では運用負荷が大きいためSRE室でログ基盤を提供することにより、運用の手間を減らすことや運用レベルを底上げしてコスト削減ができるのではないかと検討しています。既存のOSSでの運用も行ってみたものの、マルチテナント提供・ライセンス体系の問題など課題があったことからTrinoとIcebergでの開発を始めました。 Icebergとは Icebergはビッグデータ・データレイクを構築するためのストレージフォーマットです。データの
CDC + Apache Iceberg で Amazon Athena にデータを取り込む
このポストについて#このポストは Distributed computing Advent Calendar 2023 の3日目の記事になります。 1日目、2日目に続いて Apache Iceberg について書きますが、このポストでは Iceberg の実用例を書きます。 AWS DMS による CDC の結果を Apache Iceberg 形式にして Amazon Athena でクエリできるようにするという内容になります。 やっていることとしては Perform upserts in a data lake using Amazon Athena and Apache Iceberg | AWS Big Data Blog で紹介されている内容と近いですが、実務としての背景や工夫したところなどを書いていきます。 背景#私の所属する事業会社では日々プロダクトから様々なデータが発生して
BigQuery のデータ品質やデータ活用を高める Dataplex 等の活用
Google Cloud Next Tokyo '23で発表した資料です。
OpenMetadataでRedshiftのクエリログからリネージュを作成する | DevelopersIO
OpenMetadataではデータリネージュ（データの流れ）を可視化できます。 Redshiftではクエリのログを読み込むことでそこから自動的にリネージュ情報を作ることができます。 その流れをやっていこうと思います。 Redshiftのユーザについて OpenMetadataを利用する際はスーパーユーザではないユーザを利用するべきです。 OpenMetadataはデータカタログなので原則Redshift内の実データ書き換えは発生しません。 発生してしまったらかなり怖いです。 よってスーパーユーザの権限はそもそも必要なく、 また、もしも想定外に書き換えがあった時にはきちんと禁止されるように一般のリードオンリーユーザを作成して行います。 また別の理由として、スーパーユーザでは全てのデータにアクセスができてしまい、 Redshift Spectrumを利用するテーブルに対してもクエリをかけること
データ基盤 Knile のプロダクトマネジメントの取り組み
こんにちは、データエンジニアの多田です。 私は現在、データ利活用基盤「Knile（発音は “ナイル"）」の開発をしています。 今回は、私が Knile チームでスクラムマスターからプロダクトマネージャーへと役割が推移していく中で取り組んできた、チーム開発の課題とその対策について紹介いたします。 Knile とは Knile とは、以前 CET と呼ばれていたチームが開発するデータ利活用基盤です。 Knile のビジョンや設計思想については、最近行われた社外への登壇資料があるので、ご覧ください。 第14回MLOps勉強会 CloudNative Days Tokyo 2021 時間軸で取り組むチーム運営 この記事では以下の 4 つのサイクルに分けて取り組みを紹介します。 長期計画 半期 四半期 スプリント(2 週間) チーム運営のサイクル これは実際に業務の中で考える思考の順番でもあります。
データレイクの新しいカタチ：Open Table Formatの紹介 - 流沙河鎮
はじめに Open Table Formatは次世代のデータレイクの基盤となり得る技術で、徐々に導入事例(末尾に列挙)が増えてきているものの、日本での認知度は発展途上な印象がある。本記事ではOpen Table Format登場の背景を紹介する。執筆にあたって、Apache Iceberg: An Architectural Look Under the CoversとAWSにおける Hudi/Iceberg/Delta Lake の 使いどころと違いについてを特に参考にした。 Open Table Formatとは？ Open Table Formatとは、従来のデータレイクの技術的な課題&ユースケースの要請に応える形で登場した、データレイクに最適化されたテーブルフォーマットを指す概念で、上手く活用することでクエリプランニング、実行性能の最適化、効率的なUpdateやDelete、タイム
データウェアハウスの設計原理 - 極北データモデリング
非正規形のデータ構造では更新時異状が発生する。更新時異状があると実装できない機能が(ふつうは)出てくるので、OLTPシステムでは正規化が必要になる。 一方データウェアハウスには日中のデータ更新がないので、OLTPの設計原理に従う必要がない。では何を指針として設計すればよいか。 古典的なデータウェアハウスの設計原理にディメンジョナル・モデルがある。 ディメンジョナル・モデルに従ったDBは、いわゆるスタースキーマ 多数の外部キーと小数の数値データからなるファクトテーブルと それを取り巻く次元テーブル この2段でおしまい、という形になる。 このモデルでは、リレーションシップは全てファクトと次元の間に張るのであって、 売上ファクト = { 年月日, 事業部コード(FK), ブランドコード(FK), 製品コード(FK), 数量 } 事業部次元 = { 事業部コード, 事業部名 } ブランド次元 =
2018年から2,3年かけて立ち上げたい新規事業：データ処理ツールの開発 - 2018-07-11 - ククログ
クリアコードの新規事業の立ち上げに取り組むことが多い須藤です。 どういう事業を立ち上げたいかは社内だけで共有することもできますが、クリアコードのポリシーは「デフォルトで公開して共有」なので、ここにまとめています。私が取り組むときは1人で少しずつ進めていたのですが、今回はだれかと一緒に取り組めるといいなぁと思っています。興味があるクリアコードのメンバーは今月中に一度取り組み方を相談しましょう。興味があるクリアコードメンバー以外の人には選択肢が2つあります。1つはクリアコードに入社して一緒に取り組む方法です。もう1つはビジネスパートーナーとして一緒に取り組む方法です。 クリアコードの新規事業立ち上げのパターン クリアコードは今月から第13期目に入っています。創業時からフリーソフトウェアの推進と稼ぐことの両立を大事にしていますが、それの実現方法はずっと同じだったわけではありません。創業時から変わ
Great ExpectationsでBigQueryのデータ品質を監視する | フューチャー技術ブログ
1. はじめにこんにちは、フューチャーでアルバイトをしている板野です。 Great Expectationsというツールを使って、表形式データの品質をバリデーションする流れをご紹介します。 MLOpsを推進するにあたりMLモデルの監視が必要となってきています。その中でも、MLモデルに入出力されるデータ品質をバリデーションすることは重要な監視事項の一つです。 ML監視についての概要や意義については、こちらの記事で詳しく述べられているのでぜひご覧ください。 2. Great Expectationsの概要 ※公式サイトロゴ Great Expectations（GX）はデータ品質監視ツールの1つで、表形式データの品質監視ができます。GXはOSSであり、Pythonライブラリとして提供されています。 予めデータに対し、Expectationと呼ばれる「データのあるべき姿」を定義しておき、監視対象
Apache Iceberg の table を near real time で更新する
Apache Iceberg の table を near real time に、つまり高頻度で更新するということをやってみた。 Apache Iceberg とは#Apache Iceberg (以下 Iceberg) は分散ファイルシステムやクラウドストレージ上の table format であり、Apache Hudi や Delta Lake と並んで data lake や lakehouse architecture で用いられる。 特徴的なのは table とデータ実体 (Parquet, Avro など) の間に metadata file, manifest list, manifest file の抽象的なレイヤーがあり、ファイル単位で table の状態を track できること。 これにより強い isolation level、パフォーマンス、schema evo
Redshiftの利用状況を可視化して不要なテーブルをお掃除した話 - LIVESENSE ENGINEER BLOG
これは Livesense Advent Calendar 2022 DAY 10 の記事です。 年末のお掃除捗っていますか？我が家では窓掃除にWV1が大活躍しています。 データエンジニアの毛利です。サービス横断のデータ分析基盤であるLivesense Analytics（以降LA）の開発、運用を行っています。 背景 データ利用状況の可視化 テーブルの利用状況 Redshiftユーザーの利用状況 運用してみてわかったこと 最後に 背景 データを提供したものの、気がつくとほとんど使われていない、というのはよくある話だと思います。 LAでも様々なデータを提供できるように機能追加してきた結果、日々データは増え続け、システムの保守コストも徐々に膨れ上がってきました。システムは拡張する一方で、人が運用できる範囲には限度があります。いくつか解決方法があるかと思いますが、今回はデータの整理にフォーカスし
データ品質を重視したデータ基盤プロダクト開発
データ基盤アーキテクチャトレンド 2023 LTとパネルで学ぶ (https://findy.connpass.com/event/278140/) の登壇資料になります。
【AWS】Datazoneのプレビュー版が出たので概要を纏めてみました - Qiita
はじめに こんにちは。 つい先日AWSでDatazoneのプレビュー版が開始されました。AWSが展開するデータカタログということで期待値も高いのではないでしょうか。 簡単なチュートリアルの実施とドキュメントをざっくり読んだだけですが、自分用に概要を纏めます。 チュートリアルを実施したのみで各種検証は実施しておりません。内容が間違っている可能性もございますのでご注意下さい。 全体イメージ 各種詳細 ①Datazone ビジネスデータカタログをコアサービスとしたデータ利用サービス ユーザーはDataportalという専用のIFから利用する。AWS管理コンソールとは別のIF ネイティブで対応しているデータアセットは以下2つ Redshiftテーブル（ビュー） Lakeformationで管理されているGlueテーブル プロジェクトという単位でデータカタログへデータアセットの登録•購読やデータ利用
分析基盤BIツールにQuickSightを選んだ理由 - エス・エム・エス エンジニア テックブログ
医療・介護・ヘルスケア・シニアライフの4つの領域で高齢社会に適した情報インフラを構築している株式会社エス・エム・エスのAnalytics&Innovation推進部（ 以下、A&I推進部）でデータ分析基盤開発を担当している長谷川です。 A&I推進部はエス・エム・エス社内のデータを横断的に収集し、データの分析や加工から、データに基づく施策までを行う部門で、現在は介護事業者向け経営支援サービスである「カイポケ」や、介護職向け求人情報サービスである「カイゴジョブ」のデータ分析やレコメンドシステムの開発を行っています。 エス・エム・エスは多くのサービスでAWSを採用しており、A&I推進部においてもAWSのマネージドな機能を活用してデータ分析やサービス開発を行っています。 A&I推進部とは エス・エム・エスは主に医療・介護領域を事業のドメインとしていますが、それらのうち特に介護領域は労働集約型の事業
AWS Glueでデータレイクフレームワーク（Hudi）を試してみた - Qiita
Copy On Write Table Copy On Write Tableのファイル スライスにはベース ファイルとカラムナ ファイルのみが含まれ、各コミットはベース ファイルの新しいバージョンを生成する。 列方向のデータのみが存在するように、すべてのコミットで暗黙的に圧縮する。 その結果、書き込み増幅 (受信データの 1 バイトに対して書き込まれるバイト数) ははるかに大きくなり、読み取り増幅はゼロになる。 主に読み取り負荷が高い分析ワークロードにとって望ましい特性。 下記は、Copy On Write Tableのテーブルに書き込まれて、２つのクエリが実行されている場合に概念的にどのように機能するか示したもの。 ※ 出典：Apache Hudiの Table & Query Types Merge On Read Table Merge On Read Tableは、Copy On
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Kafka Connect：Iceberg Sink Connectorを使ってみる
Apache Iceberg Catalog選択のポイント
