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

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を用いた、マイグレーションのための新たなBrickbuilderソリューションを追加しました!

February 14, 2024 クリスティーヌ・ゴーティエ による投稿 in
過去2年間、Databricksは業界、マイグレーション、データおよびAIのユースケースのための革新的なソリューションを構築するために、主要なコンサルティングパートナーと協力してきました。 Databricks Brickbuilder ソリューションと アクセラレータは 、お客様の導入実績を基盤として、 Databricks データインテリジェンスプラットフォームの 可能性を最大限に引き出し、生産性を向上させ、データから価値を引き出すことができるように、パートナーの経験と知識をパッケージ化したものです。 Databricksは現在までに、レガシーシステムの移行、需要予測、顧客360、リスク管理、製品パフォーマンスなど、 60のパートナーソリューションを立ち上げて います。 最新のマイグレーションBrickbuilderソリューションと、Databricksパートナーがどのようにレイクハウスアーキテクチャへのエンドツーエンドのマイグレーションプロセスを段階的アプローチで支援しているかをご覧ください。 その結果、リ

DatabricksおよびApache Spark™上でのRayオートスケーリングのサポートを発表

Ray はオープンソースの統合コンピュートフレームワークで、分散環境におけるAIとPythonワークロードのスケーリングを簡素化します。 Databricks上でのRay の実行サポートを導入して以来、予測や深層強化学習からLLMの微調整に至るまで、数多くのお客様が機械学習のユースケースの導入に成功しています。 Rayバージョン2.8.0 のリリースに伴い、Ray on Databricksのオートスケーリングサポートが追加されました。 オートスケーリング は、変動する需要に対してリソースを動的に調整することができるため、不可欠です。 処理のニーズは時間と共に大きく変化する可能性があるため、オートスケーリングにより、最適なパフォーマンスとコスト効率を保証し、手動介入を必要とせずに計算能力と費用のバランスを維持するのに役立ちます。 Databricks上のRayオートスケーリングは、必要に応じてワーカーノードを追加または削除することができ、Sparkフレームワークを活用して分散コンピューティング環境におけるスケーラ

PySparkによるパラメータ化クエリ

PySparkは常にデータを問い合わせるための素晴らしいSQLとPython APIを提供してきました。 Databricks Runtime 12.1とApache Spark 3.4の時点で、パラメータ化されたクエリは、Pythonicプログラミングパラダイムを使用してSQLでデータをクエリする安全で表現力豊かな方法をサポートしています。 この投稿では、PySparkでパラメータ化されたクエリを作成する方法と、それがあなたのコードにとって良いデザインパターンである場合について説明します。 パラメータは、Sparkコードの再利用やテストを容易にするのに役立ちます。 また、良いコーディングの実践も奨励しています。 この記事では、PySparkのクエリをパラメータ化する2つの異なる方法を示します: PySpark カスタム文字列フォーマット パラメータマーカー 両方のタイプのPySparkパラメータ付きクエリの使い方を見て、組み込みの機能が他の選択肢よりも優れている理由を探ってみましょう。 パラメータ化されたクエリ

Mixtral 8x7B と Databricks モデルサーヴィングのご紹介

reviewed by saki.kitaoka 本日、Databricksは モデルサーヴィングで Mixtral 8x7Bをサポートすることを発表します。Mixtral 8x7BはスパースなMixture of Experts(MoE)オープン言語モデルで、多くの最先端モデルを凌駕するか、あるいはそれに匹敵します。最大32kトークン(約50ページのテキスト)の長いコンテキストを処理する能力を持ち、そのMoEアーキテクチャはより高速な推論を提供するため、RAG(Retrieval-Augmented Generation)やその他の企業ユースケースに理想的です。 Databricks Model Servingは、 プロダクショングレードのエンタープライズ対応プラットフォーム 上で、オンデマンド価格でMixtral 8x7Bへの即時アクセスを提供します。毎秒数千のクエリをサポートし、シームレスな ベクターストア 統合、自動化された品質 モニタリング 、統合 ガバナンス 、アップタイムのSLAを提供します。このエ

オフラインLLM評価:Databricks上での段階的なGenAIアプリケーション評価

背景 RAG(Retrieval-Augmented Generation)がAIを駆使したアプリケーションとの関わり方に革命をもたらす時代において、これらのシステムの効率性と有効性を確保することは、かつてないほど不可欠なことである。DatabricksとMLflowはこの革新の最前線にあり、GenAIアプリケーションの重要な評価のための合理化されたソリューションを提供している。 このブログポストでは、Databricks Data Intelligence Platformを活用いて、GenAIアプリケーションの3つのコアコンポーネント(プロンプト、検索システム、Foundation LLM)の品質を強化および評価し、GenAIアプリケーションの継続的な品質を確保するためのするためにシンプルで効果的なプロセスを紹介する。 ユースケース MLflowのドキュメントの質問に回答し、その結果を評価するQAチャットボットを作成する。 Databricksで外部モデルを設定する Databricksの モデルサービング

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

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

ファウンデーションモデル機能でGenAIアプリをより速く構築する方法

先週 発表した RAG( Retrieval Augmented Generation )に続き、Model Servingのメジャーアップデートを発表できることを嬉しく思います。Databricks Model Servingは 統一されたインターフェイス を提供するようになり、すべてのクラウドとプロバイダで基盤モデルの実験、カスタマイズ、プロダクション化が容易になりました。これは、組織固有のデータを安全に活用しながら、ユースケースに最適なモデルを使用して高品質のGenAIアプリを作成できることを意味します。 新しい統一インターフェースにより、Databricks上であろうと外部でホストされていようと、すべてのモデルを一箇所で管理し、単一のAPIでクエリすることができます。さらに、Llama2 や MPT モデルなどの一般的な大規模言語モデル (LLM) に Databricks 内から直接アクセスできる Foundation Model API...

リアルタイムの構造化データでRAGアプリケーションの応答品質を向上

Retrieval Augmented Generation(RAG )は、Gen AIアプリケーションのコンテキストとして関連データを提供する効率的なメカニズムです。 ほとんどのRAGアプリケーションは、通常、ドキュメントやWiki、サポートチケットなどの非構造化データから関連するコンテキストを検索するためにベクトルインデックスを使用します。 昨日、私たちはDatabricks Vector Search Public Previewを発表しました。 しかし、これらのテキストベースのコンテキストを、関連性のあるパーソナライズされた構造化データで補強することで、Gen AIの応答品質をさらに向上させることができます。 小売業のウェブサイトで、顧客が"最近の注文はどこですか?" と問い合わせる、Gen AIツールを想像してみてください。 このAIは、クエリが特定の購買に関するものであることを理解し、LLMを使用して応答を生成する前に、注文品目の最新の出荷情報を収集しなければなりません。 このようなスケーラブルなアプ