メインコンテンツへジャンプ
<
ページ 2
>

DataFrameの等式関数を使ったPySparkテストのシンプル化

DataFrameの等式テスト関数 は、PySparkのユニットテストを簡素化するためにApache Spark™ 3.5とDatabricks Runtime 14.2で導入されました。 このブログ記事で説明した機能一式は、次期Apache Spark 4.0とDatabricks Runtime 14.3から利用可能になります。 DataFrameの等式テスト関数を使用して、より信頼性の高いDataFrame変換を記述 PySparkでデータを扱うには、DataFrameに変換、集約、操作を適用します。 変換が蓄積されるにつれて、コードが期待通りに動作することをどうやって確信できるでしょうか? PySparkの等式テストユーティリティ関数は、データを期待される結果と照らし合わせてチェックする効率的で効果的な方法を提供し、予期しない差異を特定して分析プロセスの初期段階でエラーを検出するのに役立ちます。 さらに、デバッグに多くの時間を費やすことなく、即座に対策を講じることができるように、違いを正確に特定する直感的

Apache Spark 構造化ストリーミングにおけるステートフルパイプラインの最新パフォーマンス改善へのディープダイブ

この投稿は、ステートフル・パイプラインの最新のパフォーマンス改善に関する2部構成のシリーズの第2部です。 このシリーズの最初の部分は、 Apache Spark 構造化ストリーミングにおけるステートフルパイプラインのパフォーマンス改善 でカバーされています。 Project Lightspeedの更新ブログ では、ステートフルパイプラインに追加したさまざまなパフォーマンス改善の概要を紹介しました。 このセクションでは、パフォーマンス分析中に観察されたさまざまな問題を掘り下げ、それらの問題に対処するために実施した具体的な機能強化の概要を説明します。 RocksDBステートストア・プロバイダの改善 メモリ管理 RocksDBは主に メモリ を memtables 、ブロックキャッシュ、その他のピン留めブロックに使用します。以前は、マイクロバッチ内のすべての更新は、 WriteBatchWithIndex を 使用してメモリにバッファリングされていました。 さらに、ユーザーは書き込みバッファとブロックキャッシュの使用に

Apache Spark 構造化ストリーミングにおけるステートフルパイプラインのパフォーマンス改善

イントロダクション Apache Spark™ の 構造化ストリーミング は、Spark SQLエンジン上に構築された、スケーラビリティと耐障害性を提供する人気のオープンソースストリーム処理プラットフォームです。 Databricksレイクハウスプラットフォーム上のほとんどの増分的および ストリーミングワークロード は、 Delta Live Tables および Auto Loader を含む構造化ストリーミングを利用しています。 ここ数年、あらゆる業界における多様なユースケースにおいて、構造化ストリーミングの使用と採用が 飛躍的に伸びて います。 Databricksでは、1週間に1,400万以上の構造化ストリーミングジョブが実行されており、その数は年間2倍以上のペースで増加しています。 ほとんどの構造化ストリーミングのワークロードは、 分析ワークロードと運用ワークロード...

レイクハウス・モニタリング: データとAIの品質監視のための統合ソリューション

はじめに Databricks Lakehouse Monitoring (レイクハウス・モニタリング)を使用すると、データからフィーチャー、MLモデルまで、すべてのデータパイプラインを追加のツールや複雑な操作なしに監視できます。 Unity Catalog に組み込まれているため、ガバナンスと並行して品質を追跡し、データとAI資産のパフォーマンスについて深い洞察を得ることができます。Lakehouse Monitoringは完全にサーバーレスなので、インフラストラクチャやコンピュート構成のチューニングを心配する必要はありません。 Lakehouseのモニタリングに対する統一されたアプローチにより、 Databricks Data Intelligence Platform で直接、品質の追跡、エラーの診断、ソリューションの検索が簡単に行えます。Lakehouse Monitoringを最大限に活用する方法を本記事ではご紹介します。 なぜレイクハウス・モニタリングなのか? データパイプラインは順調に動いているよう

Spark ConnectにおけるPythonの依存関係の管理方法

November 14, 2023 Hyukjin Kwon鄭瑞鳳 による投稿 in エンジニアリングのブログ
分散コンピューティング環境におけるアプリケーションの環境管理は難しい。 すべてのノードがコードを実行するのに必要な環境を持っていることを保証し、ユーザーのコードの実際の場所を決定することは、複雑なタスクである。 Apache Spark™は、Conda、venv、PEXなど様々な方法を提供している。 --jars、--packagesの ようなスクリプトオプションや、 spark.jars.*の ようなSparkコンフィギュレーションをサブミットする方法と 同様に、 PySparkでPythonの依存関係を管理する方法も併せて参照してみてください。これらのオプションにより、ユーザーはクラスタ内の依存関係をシームレスに処理できる。 しかし、Apache Sparkの依存関係を管理するための現在のサポートには限界がある。 依存関係は静的にしか追加できず、実行中に変更することはできない。 つまり、Driverを起動する前に必ず依存関係を設定する必要がある。 この問題に対処するため、Apache Spark 3.5.0か

SQL関数の名前付き引数

本日は、SQL関数で名前付き引数を利用できるようになったことを紹介します。 この機能を使えば、より柔軟な方法で関数を呼び出すことが可能になります。 このブログでは、まずこの機能がどのようなものかを紹介し、次にSQLユーザー定義関数(UDF)のコンテキストで何ができるかを示し、最後に組み込み関数でどのように機能するかを探ります。 まとめると、名前付き引数はSQLのヘビーユーザーにとってもライトユーザーにとっても、作業を容易にする新しい便利な方法です。 名前付き引数とは何か? 多くのプログラミング言語では、関数定義に1つ以上の引数のデフォルト値を含めることができます。 例えば、Pythonでは次のようなメソッドを定義できます: def botw(x, y = 6, z = 7): return x * y + z ユーザーがこの機能を呼び出したい場合、次のように選択できます: botw(5...

Python ユーザー定義テーブル関数(UDTFs)の紹介

Apache Spark™ 3.5とDatabricks Runtime 14.0は、エキサイティングな機能をもたらした:Pythonのユーザー定義テーブル関数(UDTFs)です。 このブログでは、UDTFとは何か、なぜUDTFは強力なのか、そしてどのようにUDTFを使うことができるのかについて説明する。 Pythonのユーザー定義テーブル関数(UDTF)とは? Pythonのユーザー定義テーブル関数(UDTF)は、出力として単一のスカラー結果値の代わりにテーブルを返す新しい種類の関数です。 一度登録されると、SQLクエリの FROM 句に登場させることができる。 各Python UDTFは0個以上の引数を受け入れ、各引数は整数や文字列のような定数スカラー値である。 関数本体は、これらの引数の値を調べて、どのデータを返すべきかを決定することができる。 PythonのUDTFを使うべき理由 要するに、複数の行や列を生成する関数が必要で、Pythonの豊富なエコシステムを活用したいのであれば、Python UDTFが

Apache Spark™ 3.5におけるArrowに最適化されたPython UDF

Apache Spark™では、Pythonのユーザー定義関数(UDF)は最も人気のある機能の1つです。 ユーザーは、独自のデータ処理ニーズに合わせてカスタムコードを作成することができる。 しかし、シリアライズとデシリアライズのためにcloudpickleに依存している現在のPython UDFは、特に大きなデータの入出力を扱うときに、パフォーマンスのボトルネックに遭遇する。 Apache Spark 3.5と Databricks Runtime 14.0では 、Arrowに最適化されたPython UDFを導入し、パフォーマンスを大幅に改善しました。 この最適化の核となるのが、標準化された言語横断的なカラム型インメモリデータ表現である Apache Arrow である。 Arrowを利用することで、これらのUDFは、従来の遅いデータ(デ)シリアライゼーションの方法をバイパスし、JVMとPythonプロセス間の迅速なデータ交換をもたらします。 Apache Arrowの豊富な型システムにより、これらの最適化され

集まれ!Legendary Heroes of DATA + AI !! Vol 6

October 31, 2023 Hisae Inoue による投稿 in Databricks ブログ
日本のDatabricks Championの皆様に、目指したその理由や、これからの思いについて伺う「集まれ!Legendary Heroes of DATA + AI !!」。Legendary Heroes of Data+AI の皆さんの輪もドンドン広がっています!できる限りこちらでご紹介を続けていきたいと思いますので、是非引き続きご覧ください! さて、今回はVol.6として満を持して登場、 アマゾン ウェブ サービス ジャパン合同会社 本橋 和貴 様 をご紹介します。 —- 以前にご紹介したLegendary...

大手金融機関がデータブリックスを採用したワケは

October 12, 2023 Hisae Inoue による投稿 in Databricks ブログ
去る6月28日、サンフランシスコで開催されたDATA+AI SUMMITにて、「APJ Partner Champion of the Year」を受賞したDatabricks Champion、NTTデータの齋藤が登壇いたしました。 NTTデータのData+AI Summit参加のレポートはこちら Data and AI Summit 2023 - Databricks 現地レポート(6/27 Partner Summit) - Qiita 今回のセッションでは、大手金融機関であるNTTデータのお客様が、データとAIを活用したデータ分析へと進化していく際、数あるサービスの中から、プラットフォームとして、データブリックスを採用された経緯や、基盤構築の際に苦労したポイントなどを紹介しています。お客様の既存のプラットフォームがどのような課題を抱え、データブリックスにどのような期待を持って導入されたのか。同じような課題をお持ちの企業様に参考にしていただければと思います。...