RSS VentureBeat
フォロー
Databricksは、AIエージェントの速度を低下させてきた数十年来のデータパイプライン問題を解決したと述べている
数十年にわたり、データ専門家はパフォーマンスの問題なく、運用データベースと分析データベースを統合するという課題に直面してきました。ライブデータに対する継続的な推論を必要とするエージェントは、従来のデータパイプラインの非効率性を浮き彫りにします。Databricks は、インフラストラクチャを統合することでこれらの問題に対処するために Lakehouse//RT と LTAP を導入しました。Lakehouse//RT は、ガバナンスされた Delta および Iceberg テーブル上で直接ミリ秒単位のクエリレイテンシを提供し、個別のリアルタイムサービング層の必要性を排除します。LTAP、または Lake Transactional/Analytical Processing は、書き込み時点から Postgres ネイティブのトランザクションデータを Delta および Iceberg フォーマットで保存し、ETL パイプラインを削除します。このアプローチは、エンジンの収束に焦点を当てた以前の HTAP ソリューションとは異なり、ストレージレイヤーでデータを統合します。中核となるエンジニアリングの課題はレイテンシであり、Lakehouse//RT は Reyden コンピュートエンジンと、行から列への変換を処理するキャッシングレイヤーでこれを克服します。Lakehouse//RT は 100 ミリ秒未満のレイテンシを提供し、データコピーなしで Unity Catalog のガバナンスフレームワーク内で動作します。問題は認識されていますが、Databricks のエージェンティック AI のフレーミングとオープンフォーマットのアプローチは、主要な差別化要因と見なされています。アナリストは、Lakehouse のアーキテクチャは強力ですが、そのレイテンシと信頼性は証明される必要があると指摘しています。トランザクション書き込みと直接的なレイククエリのためのオープンフォーマットへの移行は、重要視されています。特にエージェントを活用している企業にとって、問題はベストオブブリードツールの選択から、防御可能な個別のシステムへと移行します。専門化されたシステム間のギャップは、エージェントにとって運用上のリスクとなり、個別のサービングレイヤーからの統合を推進しています。エージェントワークロードは、人間速度の分析のために構築された従来のデータアーキテクチャに固有のレイテンシを許容できません。
