Testcontainersを利用したApache Kyuubiのユニットテスト環境構築
こんにちは。LINEヤフー株式会社ビジネスPF開発本部で LINE DMP の開発を担当している yamaguchi です。 この記事は、Testcontainers を活用して Apache Kyuubi を用いたユニットテスト環境をどのように構築したかを紹介します。 はじめに LINE DMP（Data Management Platform）は LINE 外部から同意を得てアップロードされた、あるいは LINE の内部で得られたデータをさまざまな形で ETL 処理をし、LINE広告やLINE公式アカウントのような B2B サービスで活用できるようにするためのプロダクトです。 膨大な累積データや非常に大きなトラフィックを扱うこともあり、リアルタイム処理から大規模バッチ処理までさまざまな LINE にまつわるデータ処理を行っています。 プロジェクトの背景 大規模データを取り扱うにあたり、
メタデータ管理をデータベースで担う新しいLakehouseフォーマット「DuckLake」が発表されました | DevelopersIO
さがらです。 DuckDBの公式ブログにおいて、メタデータ管理をデータベースで担う新しいLakehouseフォーマット「DuckLake」が発表されました。 本記事では、DuckLakeがどういったものか簡単に紹介し、ローカルで軽く触ってみたのでその内容をまとめてみます。 DuckLakeとは まずDuckLakeですが、DuckDBの開発元が開発したOSSのLakehouseフォーマットとなっております。 昨今のIcebergやDelta Lakeではファイルベースでメタデータを管理するという複雑性があったことを課題認識し、そのメタデータ管理を担うレイヤーをIcebergでいうカタログレイヤーも含めて全てSQLデータベースで担う方向性で実装したプロダクトが、DuckLakeとなっております。 DuckLakeのメリットとして、以下4つが上述のリンク先のブログで言及されています。 Simp
[調査報告] Amazon Athena 従来のS3ファイルレイアウトとIcebergテーブルフォーマットのデータ容量比較 | DevelopersIO
[調査報告] Amazon Athena 従来のS3ファイルレイアウトとIcebergテーブルフォーマットのデータ容量比較 AWS事業本部コンサルティング部の石川です。大規模データ管理では、S3上のデータ容量のサイズを事前に把握し、コスト試算をすることが欠かせません。今日は、Amazon Athenaのデータ管理に使用される2つの主要なフォーマット、従来のS3ファイルレイアウトと Apache Icebergのテーブルフォーマットの特長やデータ容量比較について解説します。 データレイクフォーマットの概要 データレイクフォーマットは、従来のS3ファイルレイアウトとApache Icebergのテーブルフォーマットの2種類があります。 補足: Amazon Athenaは、将来的に、Apache Icebergの他にApache HudiやLinux Foundation Delta Lake
![[調査報告] Amazon Athena 従来のS3ファイルレイアウトとIcebergテーブルフォーマットのデータ容量比較 | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/e090fe1737de1e050a92c8d61fad649de5438544/height=288;version=1;width=512/https%3A%2F%2Fimages.ctfassets.net%2Fct0aopd36mqt%2Fwp-thumbnail-764c44f07bcd41184fe62a432ae120ab%2F512a4cdcd05a0ed3ddea950fdf619fa0%2Famazon-athena)
AWS Glue データカタログの Apache Iceberg テーブルのストレージ最適化を試す！ | DevelopersIO
AWS事業本部コンサルティング部の石川です。AWS Glue データカタログは、Apache Iceberg テーブルのストレージ最適化をサポートするようになりました。ストレージ最適化とは何か、実際に動作を確認します。 Apache Iceberg テーブルのストレージ最適化とは Apache Iceberg テーブルのストレージ最適化とは、AWS Glue データカタログが提供するストレージ最適化と自動圧縮の機能です。メタデータのオーバーヘッドを削減し、ストレージコストを抑え、クエリパフォーマンスを向上させることができます。 Apache Iceberg テーブルに書き込むたびに、テーブルの新しいスナップショット、つまりバージョンが作成されます。さらに、Iceberg テーブルへの書き込み中に障害が発生すると、スナップショットで参照されない「孤立ファイル」と呼ばれるデータファイルが作成さ
Iceberg Summit 2024「Apache Iceberg におけるテーブル暗号化」セッションまとめ - 流沙河鎮
Iceberg Summit 2024 のセッション「Table Encryption in Apache Iceberg」を日本語でまとめます。 可能な限り正確に内容を拾えるようにリスニングに努めたつもりですが、もし誤りがあればご指摘ください。 Iceberg Summit とは？ イベント概要 イベントページ Table Encryption in Apache Iceberg スピーカー Iceberg におけるテーブルの暗号化とは？ Iceberg の built-in 暗号化エンジン Table Key デモ 開発状況 Deep Dive 暗号化によるパフォーマンスへの影響 今後の展望 QA(サマリ) Iceberg Summit とは？ イベント概要 公式ページより翻訳 本イベントでは、Apache Icebergを実務で活用していたり、Icebergの開発に携わる技術者による
Apache Atlasことはじめ(1) - Qiita
(株)日立製作所 研究開発グループ データマネジメント研究部の角井です。 オープンソースのデータカタログであるApache Atlasについて，2回に分けてご紹介させていただきます。第1回目となる本記事では，データカタログとしてのApache Atlasの背景と機能について，第2回目はビルドとインストールの手順についてご説明します。 1. Apache Atlasとは Apache Atlasはオープンソースの「データカタログ1」です。 データカタログは，DBMSやデータレイクなどに格納されているデータ資源を検索・参照できるようにするソフトウェアです。ただしデータそれ自体を格納しているわけではなく，代わりにデータ資源を活用したり管理したりするために有用な情報を抽出した，「データに関するデータ」すなわちメタデータを収集して格納しているのが特徴です2。データカタログは，データユーザやデータ管理
Apache Hive 4: 新しく追加されたUDFの紹介 - おくみん公式ブログ
Tuple Sketch UDFs 先日ついにApache Hive 4.0.0がリリースされました。おおよそ6年ぶりのメジャーアップデートということもあり、5000コミット以上もの変更をともなう大型リリースとなっています。 この記事ではHive 4にて追加されるUDFを紹介します。 Hive 4関連記事一覧 新UDF一覧 文字列操作系 HIVE-685: quote HIVE-18545: json_read 算術系 HIVE-26636: sinh, cosh, tanh 時刻系 HIVE-20768: tumbling_window HIVE-21576: cast + format 配列系 統計系 HIVE-16255: percentile_cont, percentile_disc HIVE-20490: approx_distinct HIVE-22939: データスケッチU
Amazon AthenaからIceberg形式のGlueテーブルの削除済みのスナップショットにタイムトラベルできないことを確認する | DevelopersIO
Amazon AthenaからIceberg形式のGlueテーブルの削除済みのスナップショットにタイムトラベルできないことを確認する データアナリティクス事業本部 インテグレーション部 機械学習チームの鈴木です。 今回は簡単な例ですが、Iceberg形式のGlueテーブルに対して、どのような場合にタイムトラベルができて、どうすればできなくなるのかをAmazon Athenaから確認してみました。 はじめに Amazon AthenaなどでサポートされているIcebergテーブルでは、スナップショットをもとに過去のデータの状態にタイムトラベルすることが可能です。 一方でスナップショットが残ってしまうことが課題となるケースもあります。例えば以下のSnowflakeの記事で紹介されているようなケースです。 GDPR：ベストプラクティス、一般的なリファレンスアーキテクチャパターン これはEU一般デ
{sparklyr}でS3バケット上のファイルをRで扱う - Qiita
概要 少し前に{sparklyr}というRからSparkを使うパッケージがRStudio社から公開されました。この{sparklyr}にはS3上のファイルも読み込めるspark_read_csvという関数が提供されており、Amazon Athenaが東京リージョンに来るまで代わりに使えないかと試してみました。 今回はAWS Public Datasetsにあるデータセットを読み込んでみましたが、入力対象のS3バケットに権限があれば同じように扱えると思います。 sparklyr: R interface for Apache Spark 事前準備 {sparklyr}の活用にあたって対象パッケージのインストールと、Spark環境の設定が必要になります。後者については{sparklyr}に関数が用意されているので、今回はそれを使用してローカルに環境構築します。 今回は試しませんが、ローカルでは
NumpyやPySparkで大量の確率モデルの確率密度関数を積分する - Qiita
はじめに 業務で行っていたとある分析で、大量の確率モデルの確率密度関数を積分して確率を求める機会があったので、この記事ではその際に調べたことを、架空の問題設定を通して紹介していこうと思います。 問題設定 今回はダミーのデータセットを用いて説明しようと思います。 ECサイトのユーザの毎月の決済回数を集計して、平均と標準偏差を算出したという体で、以下のようにしてNumpyとPandasでダミーデータを作成します。 rg = np.random.default_rng() models = [] for i in range(100000): id = str(i) usage = rg.uniform(0, 30, 12) # 各ユーザの12か月の利用回数を0~30の一様分布で生成 mean = float(np.mean(usage)) std = float(np.std(usage))
pytestでSparkアプリケーションのテストを書いてみる - Qiita
Sparkで動くアプリケーションをPythonで書いたので、pytestでテストしたい！ 大規模データでもテストしたいので、YARNクラスタにも投げたい！ ある意味 pytestに入門してみたメモ の続編です。 pytestプラグインとかあるみたいですが 今回は手の内が分かったうえで自分でいろいろやりたかったので、前回の復習も兼ねて自前で作ってみることにします。 spark-submitコマンドを使わずにSparkにアクセス Spark向けに書いたスクリプトを実行する時、普通はspark-submitコマンドを使うと思いますが、今回はpytest経由で実行したいので、spark-submitを使わずに普通のPythonからpysparkモジュールを呼びたいわけです。 そのためには、本来spark-submitがやっている諸々の設定を自分でやればいいはず。spark-submitの処理を追い
PySparkでspark-testing-baseを使ってみる - Qiita
概要 spark用のテストライブラリのspark-testing-baseをPySparkでどのように使うかを軽く調べてみた。 調べたこと unittest2のTestCaseを継承しており、unittest2.main()でテスト実行できる クラス内部でspark contextを立ち上げており、テストでわざわざ自力で立ち上げる必要がない 自分でspark contextを立ち上げていると、テスト実行時にエラーになる DataFrameの場合、スキーマと件数と各レコードの並びが一致するかを確認しているみたい from sparktestingbase.sqltestcase import SQLTestCase import unittest2 class DataFrameTest(SQLTestCase): def test_expected_equal(self): data =
Apache Spark 3.5で導入されたTesting APIを試す - Qiita
久しぶりのLLM以外の記事ですが、どちらかといえばこちらが本業です。 導入 Apache Spark 3.5がリリースされました。 下記のDatabricks公式blogでも取り上げられています。 これを読んでいていると、PysparkのTesting APIというものに目が引かれました。 類似のモジュールは既にあったと思うのですが、公式が出してくれると地味に捗ります。 というわけで、下のドキュメントを基に、ウォークスルーしてみました。 環境はいつものようにDatabricksを使います。DBRは14.0です。 Step1. ビルトイン関数を試す ドキュメントの内容ほぼそのままを実行してきます。 最初はデータフレーム同士の比較を行う関数assertDataFrameEqualでテストします。 import pyspark.testing from pyspark.testing.utils
What’s Next for the Upcoming Apache Spark 4.0? (今後のApache Spark 4.0には何が期待されるのか？) - APC 技術ブログ
セッションの要約 Apache Spark 4.0のリリースが近づいており、新機能やバグ修正によりユーザーエクスペリエンスが向上します。注目点はANSIモードとデータハンドリングの改善で、Sparknet GAの導入により多言語サポートが強化され、軽量なクライアントライブラリ「spark-connect」が登場します。文字列照合機能とストリーミングの強化により、データセットの操作が直感的になります。さらに、APIとUDFの改善、プロファイリングやログ記録機能の強化が開発者の効率を向上させます。 Apache Spark 4.0：ANSIモードとデータハンドリングの強化 Apache Spark 4.0のリリースが近づいており、開発者体験が大幅に改善することが予想されています。主な焦点は、ANSIモードとデータハンドリングの顕著な改善に基づいています。 Spark Connect がGAに
Glue + Athenaのローカル開発環境をOSSで構築（MinIO + Trino + HIVE） | moritalous blog
この環境をDocker Composeを使い構築します。 環境構築MinIOまずはS3を置き換えるMinIOからです。 ポイントは path-styleではなくvirtual-hosted styleを使用するため、MINIO_DOMAIN環境変数をセット他のコンテナから[バケット名].minioで名前解決できるようにhostnameを指定path-styleとvirtual-hosted styleの違いはこちらを参照ください。 version: '3' services: minio: image: quay.io/minio/minio hostname: bucket001.minio restart: always volumes: - ./minio/data:/data environment: - MINIO_DOMAIN=minio command: ["server
Apache SparkのTempViewに嵌った話 - Qiita
はじめに Databricks/Apache Sparkで開発を行っている際にTempViewを使用していたのですが、TempViewはメモリ上のデータを参照していると誤った認識をしていたため嵌りました。結論と対応方法を備忘録も兼ねてこの記事で共有させてください。 実際に嵌った話 処理の最初にDatabricks外部のDB から大量データをDatabricksに抽出し、TempViewに格納して、後続の処理ではTempViewを参照してデータを加工していく処理があります。 このTempViewを参照している箇所の処理が軒並み遅くメモリ上に格納されているのになぜ・・・？となったのがきっかけです。 誤った認識 Apache SparkのTempViewはメモリ上にデータが格納されていると思っていました。例えば下記SQLをDatabricks上で実行したときにTMP_COMMENTSはメモリ上か
Hive on TezのEXPLAINを読み解く | DevelopersIO
こんにちは、小澤です。 RDBではおなじみのEXPLAIN、実行計画を確認しクエリを最適化したり、インデックスの貼り方を考えたりするのによく使われるかと思います。 このEXPLAINですが、Hiveでも利用可能です。 HiveのEXPLAINはMapReduceやTez, Sparkのジョブに変換されるため、少々見方が特殊でこれらの知識も必要になります。 実行エンジンによって表示され方が異なるため、今回はHive on Tezに限定してこのEXPLAINの見方を解説していきます。 今回利用するクエリ 今回は、TPC-DSというOLAPなどの分析系クエリのベンチマークで利用されるデータを利用して見ていきたいと思います。 TPC-DSの詳細については解説しませんので、気になる方は公式の情報をご確認ください。 TPC-DS HiveでTPC-DSを利用できる環境を整えるために、以下のスクリプトを
Hadoop Streaming の Mapper と Reducer を初めて書いて感じたこと:お題目うぉっち
2010年02月02日 Hadoop Streaming の Mapper と Reducer を初めて書いて感じたこと O'reilly の Hadoop本を読んで、ますます Hadoop 熱が上昇中。ということで、社内でもともとDBで行っていて「重い、重い」と評判の分析処理を題材に、既存ロジックの Mapper、Reducerへの置き換えを体験してみた。 結局、6段階のMapReduceのチェーンに置き換えられたのだが、内容はさておくとして、既存の処理を mapper、reducer に置き換えていったときに感じたこと、印象深かったことを記しておくことにする（多分、思い違いや、もっといい方法があると思うが、初心者の過ちということで）。 ■ Streamingの場合、Mapper, Reducerへの入力は Key, Value ではない Javaのメソッドの説明を下手に読んで私がまず混
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Apache BigtopによるHadoopエコシステムのパッケージング（Open Source Conference 2021 Online/Osaka発表資料）
pyhive + jinjasqlで、prestoに対してprepared statementを実行 - Qiita
