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

Azure Databricksによるデータ漏洩対策

前回のブログ では、 仮想ネットワークサービスエンドポイント または Private Link を使用して、Azure DatabricksからAzureデータサービスに安全にアクセスする方法について説明しました。 この記事では、これらのベストプラクティスのベースラインを前提として、データの流出を防止するために、ネットワークセキュリティの観点からAzure Databricksのデプロイを強化する方法について、詳細な手順をウォークスルーします。 Wikipedia によると データ漏洩は、マルウェアや悪意のある行為者がコンピュータから不正なデータ転送を行うことで発生します。一般に、データ漏洩またはデータエクスポートとも呼ばれます。データ漏洩は、データ窃盗の一形態とも考えられています。2000年以降、多くのデータ漏洩が発生し、世界中の企業の消費者信頼、企業評価、知的財産、政府の国家安全保障に深刻な損害を 与えました。 この問題は、企業が機密データ(PII、PHI、戦略的機密情報)をパブリッククラウドサービスで保管・

Databricksでの安全かつ責任ある生成AIデプロイのためのLLMガードレールの実装

イントロダクション よくあるシナリオを考えてみましょう。あなたのチームは、オープンソースのLLMを活用して、カスタマーサポート用のチャットボットを構築したいと考えています。 このモデルは、本番環境で顧客からの問い合わせを処理するため、いくつかの入力や出力が不適切または安全でない可能性があることに気づかない可能性があります。 そして、内部監査の最中になって初めて(運良く このデータを追跡 していた場合)、ユーザーが不適切なリクエストを送信し、チャットボットがそのユーザーとやりとりしていることに気づくのです! さらに深く掘り下げると、チャットボットが顧客を不快にさせている可能性があり、事態の深刻さはあなたが準備できる範囲を超えていることがわかります。 チームが本番環境でAIイニシアチブを保護するために、DatabricksはLLMをラップして適切な動作を強制するガードレールをサポートしています。 ガードレールに加えて、Databricksはモデルのリクエストとレスポンスをログに記録する推論テーブル( AWS | Az

Databricks Feature Serving(特徴量サービング)の一般提供開始のお知らせ

本日、Databricks Feature Serving(特徴量サービング)の一般提供を開始いたします。 特徴量はAIアプリケーションにおいて極めて重要な役割を果たし、通常、正確に計算し、低レイテンシーでアクセスできるようにするためにはかなりの労力を必要とします。 この複雑さによって、本番のアプリケーションの品質を向上させるための新機能の導入が難しくなります。 特徴量サービングを利用すれば、AIアプリケーションに対して、単一のREST APIを使用してリアルタイムで、事前に計算された特徴量やオンデマンドの特徴量を簡単に提供することができます! 特徴量サービングは、高速で安全、かつ簡単に使用できるように設計されており、次のような利点があります: 高速かつ低TCO - 特徴量サービングは、低TCOで高いパフォーマンスを提供するように設計されており、ミリ秒単位の待ち時間で特徴量を提供できます。 フィーチャーチェーン - 事前に計算された特徴量とオンデマンド計算のチェーンを指定することで、複雑なリアルタイム特徴量の計算

Databricks、Brickbuilderプログラムを拡張してUnity Catalog Acceleratorsを追加

本日、Brickbuilder Unity Catalog Acceleratorsを発表いたします。 この プログラム は、システムインテグレーターやコンサルティングパートナーの専門知識と、実績のあるフレームワークや構築済みのコードを組み合わせて、企業が特定の方法論や Databricksデータインテリジェンスプラットフォーム の機能を迅速に実装できるように支援するものです。 パートナーソリューションとアクセラレータで構成されるBrickbuilderプログラムは、 業界と 移行ソリューションに 焦点を当てて始まり、あらゆる規模の顧客が数ヶ月ではなく数週間でDatabricksデータインテリジェンスプラットフォームを使用してレイクハウスアーキテクチャーをセットアップし、充実させることを支援するアクセラレーターを含むように急速に拡大しました。 今日、Databricksは、生産性を向上させ、価値を最適化するために、顧客のあらゆる段階に適合するアクセラレーターを開発するために、トップパートナーとの協力と投資を続けて

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

February 15, 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パラメータ付きクエリの使い方を見て、組み込みの機能が他の選択肢よりも優れている理由を探ってみましょう。 パラメータ化されたクエリ