Databricksは、ドイツのベルリンで開催されるSIGMOD 2025のプラチナスポンサーであることを誇りに思っています。私たちの受け入れられた論文とエンジニアリングの機会についてもっと学びましょう。
によって サム・プレック 、 ティム・ヤヌショフスキ による投稿
Archived. This article has not been updated since the publish date above. The dynamic nature of information means that previously accurate content can become outdated or even obsolete over time. Readers are advised to exercise due diligence and cross-check any information found in this blog post before making decisions or adopting any practices based on said information.
DatabricksはSIGMOD 2025のプラチナスポンサーであることを誇りに思っています。この会議は6月22日から27日までドイツのベルリンで開催されます。
SIGMOD 2025の開催都市は、オーフス、アムステルダム、ベオグラードと並ぶ、Databricksのヨーロッパにある4つのR＆Dハブの1つがある場所でもあります。
ベルリンオフィスは、Databricksの研究において中心的な役割を果たしており、その一部はSIGMODで展示され、私たちの3つの受け入れられた論文に貢献しています。主任エンジニアMartin Grundは、2つの論文の主著者 であり、ベルリンのサイトリーダーTim Januschowskiは、ベルリンに拠点を置くいくつかのエンジニアと共にUnity Catalogに関する論文を共著しました。これらの貢献は、私たちが積極的に採用を行っているベルリンでのコアシステムと戦略的な作業の一端を垣間見せています。
6月22日から27日までの間にブース＃3に立ち寄って、チームのメンバーに会い、最新の作業とユニークな協力的なDatabricksの文化について学び、データシステムの未来について話し合いましょう！
企業は、ますます複雑なデータガバナンス要件を管理するために、細かいアクセス制御ポリシーを適用したいと考えています。これらの豊かなポリシーは、すべてのワークロードに対して一様に適用されるべきです。本論文では、企業のデータとAIワークロード全体にわたる細かいデータアクセスポリシー、行レベルのフィルター、および列マスクを強制する統一ガバナンスシステムの実装であるDatabricks Lakeguardを紹介します。Lakeguardは2つの主要なコンポーネントに基づいて構築されています：まず、JDBCのような実行プロトコルであるSpark Connectを使用して、クライアントアプリケーションとサーバーを分離し、バージョンの互換性を確保します。二つ目に、Databricksのクラスタマネージャーでコンテナの隔離を利用して、ユーザーコードをコアのSparkエンジンから安全に隔離します。Lakeguardを使用すると、ユーザーの権限は、SQL、Python、Scala、およびRのマルチユーザーコンピューティングでサポートされる言語であれば、任意のワークロードに対して強制されます。この作業は、細かいアクセス制御がSQLワークロードに対してのみ強制され、Apache Sparkのようなフレームワークを使用したビッグデータ処理は、クラスターに束縛されたデータアクセスで粗いガバナンスに依存していた、断片化したガバナンスソリューションを克服します。
企業は、その柔軟性、低コスト、高性能のため、データ資産を管理するためにLakehouseアーキテクチャをますます採用しています。カタログはこのアーキテクチャで中心的な役割を果たしているにもかかわらず、まだ十分に探求されておらず、現在のLakehouseカタログは一貫性のないガバナンス、狭い相互運用性、データ発見のサポートの欠如など、主要な制限を示しています。さらに、表形式のデータを超えたより広範な資産を管理する需要が増えており、これには非構造化データやAIモデルが含まれ、既存のカタログでは対応できません。これらの課題に対処するため に、私たちはUnity Catalog（UC）を導入します。これは、Databricksで開発されたオープンでユニバーサルなLakehouseカタログで、さまざまな資産とワークロードをサポートし、一貫したガバナンスを提供し、外部システムと効率的に統合し、強力なパフォーマンス保証を提供します。我々は、主要な設計課題とUCのアーキテクチャがそれらにどのように対応しているかを説明し、その設計選択が有効であることを証明する何千もの顧客デプロイメントからの洞察を共有します。UCのコアAPIとサーバーおよびクライアントの実装は、2024年6月以降、オープンソースとして利用可能になっています。
Apache Sparkの多くのユーザーにとって、Sparkバージョンのアップグレード管理は、通常、時間がかかるコード移行を伴う大きな中断です。これは主に、Sparkではアプリケーションコードとエンジンコードの間に明確な分離がなく、それらを独立して管理することが難しいためです（依存性の衝突、内部APIの使用）。DatabricksのServerless Sparkオファリングでは、Spark Connectを利用してクライアントアプリケーションとSparkエンジンを完全に分離し、SparkエンジンのバージョンをシームレスにアップグレードできるVersionless Sparkを導入しました。この論文では、Spark Connectを中心に構築したインフラが、自動化されたSparkワークロードの中断なく自動的にアップグレードし、障害を修復する方法を示します。Versionless Sparkを使用すると、DatabricksユーザーのSparkワークロードは無期限に実行され、常に完全に管理された経験に基づいて最新バージョンで実行され、Apache Sparkのプログラム可能性のほぼすべてを保持します。
私たちは採用しています！私たちの求人をチェックして、世界中で成長しているエンジニアリングチームに参加してください。
ブログを購読して、最新の投稿を受信トレイにお届けします。