bowang0911/databricks-qa-ja huggingface dataset:
DWH層内のデータと結合するDWH層外のデータセットにセマンティック一貫性を適用することで、いくつかのメリットがあります：

DWHレイヤーの外にあるデータのセマンティック一貫性を実現することは、そのデータをDWHに統合するよりもはるかに簡単です。
その結果、コアとなるDWHが安定したまま、DWHの開発をより速く、より探索的に行うことができます。また、ある結果が永続的な価値を持つことが証明された場合、そのデータセットを後日DWHに統合することができます。
データサイエンティストは、ビジネスKPIなど組織のビジネス情報モデルに由来するデータに簡単にアクセスでき、意味的に一貫性のあるデータと組み合わせることができます。
最後に、すべてのデータが意味的に一貫している必要はないので、データレイクアプローチの高速で探索的な性質は、現代のユースケースでも利用可能です。
ディープラーニングは、機械学習のサブセットで、人間の脳の構造と機能から着想を得たアルゴリズムを使用します。ディープラーニングは、従来のタスクに特化したアルゴリズムではなく、データ表現の学習に基づく、より広範な機械学習手法の一群に属します。
データレイク上でのモダンなユースケースと、データウェアハウス上での従来のBIユースケースを区別して説明します：

モダンなユースケースのためのデータレイク 現代のユースケースは、通常、データレイクに保存されたデータに対して機械学習やAIを使用します。どちらのアプローチも、行動や起こりうる結果を予測するモデルを作成し、ビジネスユーザーが事前に適切な行動を取れるようにすることを目的としています。

機械学習モデルは、データセットに対して学習（教師ありまたは教師なし）され、以前に見たことのないデータセットからパターンを見つけたり予測を行ったりするように最適化されます。ディープラーニングは、機械学習のサブセットで、人間の脳の構造と機能から着想を得たアルゴリズムを使用します。ディープラーニングは、従来のタスクに特化したアルゴリズムではなく、データ表現の学習に基づく、より広範な機械学習手法の一群に属します。機械学習では、ユースケースのためにデータレイクに明示的に取り込まれた大規模なデータセットを使用することがよくあります。

データウェアハウスは、複数のコアビジネスソリューションから現在および過去のデータを保存するデータ管理システムです。データウェアハウスは、組織がどのようにビジネスを行っているかをモデル化したもので、洞察やレポーティングを容易に行うことができます。データウェアハウスは、BI、レポーティング、データ分析のために、運用データベースからデータを抽出・集約します。データウェアハウスの利点は、多くのソースからのデータを統合し、履歴情報を提供し、分析処理をトランザクションデータベースから切り離すことです。データウェアハウスは、データの品質と正確性を確保し、例えば、異なる製品タイプ、言語、通貨に対する命名規則やコードによって一貫性を持たせることでデータを標準化します。
Databricks Lakehouse Platformは、Unity Catalogを通じて、統一されたガバナンスモデルを実現する手段を提供します。Unity Catalogでは、データアーティファクトにきめ細かい権限を付与し、ユーザーをグループ化して一元的に管理することが可能です。どのようなデータやリソースにアクセスできるのか、チームやユーザーを簡単に管理できることは、持続可能な運営モデルやコスト管理のために重要なことなのです。
追跡と実行というテーマでは、AIの運用モデルの成功の重要な部分は、データとAIの利用を測定可能なビジネス成果に効果的に結びつけることができることであり、DatabricksはそうしたKPIを収集、管理、維持できる基盤を提供する。ビジネスにおけるデータの価値を表すKPIの1つが、RODA（Return on Data Assets）です。
製品カタログの検索にLLMを使えば、商品説明や文章、音声の記録などに目を通し、ユーザーの検索に応えて、その内容に関連するものを提案するよう、モデルに課すことができます。ユーザーは、探しているものを見つけるために正確な用語を必要とせず、LLMがニーズに合わせて方向付けることができる一般的な説明だけでよいのです。その結果、ユーザーがサイトを利用する際に、まるでパーソナライズされた専門家のガイダンスを受けたかのような感覚に陥る、パワフルな新しい体験が得られました。
ファインチューニングを行うことで、モデルの方向性を、それが意図する特定のコンテンツに対して調整することができます。事前にトレーニングしたモデルを、特定分野の情報などで追加トレーニングすることで、このコンテンツとより一致した方法でユーザーのプロンプトに応答するモデルの能力が向上し、多くの組織にとって実行する価値のあるステップとなります。
Dolly 2.0はそのようなモデルの1つで、ダウンロードサイトに提示されているライセンス条項に従って自由にダウンロードし、広く使用することができます。Hugging Face は、AIコミュニティがセマンティック検索と呼ぶものに最適な言語モデル（大規模なもの、そうでないものも）を発見できる人気の場所です。
エンベッディングとは、文章、段落、文書を数値で表したものです。どのように生成されるかの仕組みは、モデルの中に埋もれていますが、理解すべき重要なことは、モデルが2つの文書をエンベッディングに変換したとき、数値の間の数学的距離（差）が、それらの間の類似性の程度について何かを教えてくれることです。
オープンソースのlangchainのようなツールは、このためのビルディングブロックを提供しています。重要なのは、例えば検索したい商品カタログの詳細を形成する埋め込みデータは、従来のリレーショナルデータベースやNoSQLデータストアの中からは検索できないことです。その代わりに、特殊なベクトルストアを使用する必要があります。
マイクロサービスとは、検索フレーズなどのリクエストを受け取り、レスポンスを返す軽量なアプリケーションのことです。モデルと検索する埋め込みをマイクロサービス内にパッケージ化することで、マイクロサービスが提供する検索機能にアプリケーションから広くアクセスできるようになるだけでなく、ほとんどのマイクロサービス基盤ソリューションは弾力的なスケーラビリティをサポートしているので、需要の増減に対応できるようにサービスにリソースを割り当てることができる。これは、コストを抑えながらアップタイムを管理するために不可欠です。
選択的クエリやポイント・ルックアップは、BIやアナリティクスのユースケースでよく見られる、大きなデータセットから少量または単一の結果を返そうとするものです。BIやアナリティクスのユースケースでよく見られるもので、「針の穴を通すような」クエリーと呼ばれることもありますが、こうしたクエリーをコストを抑えながら高速化することは困難です。なぜなら、クラウドデータウェアハウス（CDW）でポイント検索を高速化するためには、インデックスを作成するか、追加の最適化サービスを使用しなければならないからです。さらに、これらのオプションはノブであり、各アプローチを有効にする前に、いつ、どのように使用するかを理解する必要があることを意味します。
一つの例をみてみましょう。例えCDWにデータセットをロードした後、クエリに8.7秒かかっています。もしこれが十分な速度でない場合は、高価な最適化サービスを利用すれば、3.6秒まで短縮することが可能です。しかし、忘れてはならないのは、このためにお金を払っていることです。テーブルが変わるたびに、最適化サービスはメンテナンス作業を行わなければならないのです。もっと簡単で安価な方法として、Predictive I/Oを使えば、Lakehouseのデータを3.7秒でロードしてクエリすることができます！次に、Predictive I/Oの初期の顧客による実世界のワークロードを見てみましょう。データをDatabricksにロードし、選択的なクエリを実行するというシンプルなプロセスでした。Predictive I/Oは、このお客様のユースケースにおいて、CDWよりも35倍高速でした。ここでも、優れたパフォーマンスを発揮するために必要なノブはありません。
Delta LakeとParquetテーブルに対して、Predictive I/Oは、ヒューリスティック、モデリング、ファイルプロパティに基づくスキャンパフォーマンスの予測など、さまざまな形態の機械学習と機械知能を使用して、さまざまな最適化をインテリジェントに有効または無効化します。
ワークスペース・ファイルを使用する利点は以下の通りです：

モジュール化されたコードと再利用： ファイルのサポートにより、大規模で多くのセルがあるノートブックをより小さく、より理解しやすいモジュールにリファクタリングすることができます。ノートブックでは、「import」ステートメントを使用して、これらのモジュールを参照することができます。
テスト： ノートブックやモジュールのコードに対してユニットテストを作成し、ソースコードと一緒にファイルとしてパッケージすることができます。
初期化スクリプト： クラスタに対応した初期化スクリプトをワークスペース・ファイルに格納することができます。これらのスクリプトはアクセス制御され、許可されたユーザーだけが変更できるようになります。
ライブラリとアーティファクトの再利用： Wheel、Jar、および共有Pythonライブラリのソースファイルをノートブックに保存できるため、ノートブック内の作業の共有、配布、および複製が容易になります。
ソフトウェアの依存関係管理の改善： requirements.txtファイルにより、ワークスペース内のノートブックやその他のPythonコード資産のソフトウェア依存関係をファイルにカプセル化し、そのソフトウェア環境の将来の複製を単純な`%pip -r`呼び出しを減らすことができるようになりました。
オブジェクトのアクセス制御リスト（ACL）を使用して、個々のファイルまたはフォルダへのアクセスを保護します。個々のファイルまたはフォルダへのアクセスを、持つべきユーザーまたはユーザーのグループのみにアクセス権を制限することができます。ACL は、Workspace ブラウザまたはオブジェクト内部から直接制御することができます。
Spark NLPは、Apache Spark™の上に構築された最先端の自然言語処理ライブラリです。分散環境で容易にスケールする機械学習パイプラインのために、シンプルでパフォーマンスと精度の高いNLPアノテーションを提供します。Spark NLPには、200以上の言語に対応した7000以上の事前学習済みパイプラインとモデルが付属しています。また、トークン化、単語分割、品詞タグ付け、単語と文の埋め込み、名前付き固有表現認識、依存関係解析、スペルチェック、テキスト分類、感情分析、トークン分類、機械翻訳（+180言語）、要約と質問応答、テキスト生成、画像分類（ViT）、その他多くのNLPタスクが提供されています。
Spark Connectは、クライアントとサーバーを分離したアーキテクチャで、あらゆるアプリケーションからSparkクラスタへのリモート接続を可能にし、どこでも実行できるようにします。このクライアントとサーバーの分離により、最新のデータアプリケーション、IDE、ノートブック、およびプログラミング言語がSparkにインタラクティブにアクセスできるようになります。
Spark 3.4では、Spark ConnectはDataFrame, Functions, Columnを含むほとんどのPySpark APIをサポートしています。サポートされているPySpark APIは、API referenceドキュメントで「Supports Spark Connect」と表示されるので、既存のコードをSpark Connectに移行する前に、使用しているAPIが利用可能かどうかを確認できます。
データウェアハウス（DWH）とは、膨大な量のデータを利用者の目的に応用しやすくするため、整理・格納する管理システムのことを指します。意思決定支援や BI（ビジネスインテリジェンス）アプリケーションにおいて広く利用されてきており、これには長い歴史があります。データウェアハウスの技術は、1980 年代後半の登場以来進化を続け、MPP アーキテクチャなどの並列処理技術の進歩によって、より大規模なデータ処理が可能なシステムがもたらされました。しかし、データウェアハウスには、エクセルで作成されたような構造化データ（あらかじめ決められた管理構造に従って格納されたデータ）の処理には適しているが、非構造化・半構造化データといったそのままでは利用できない複雑なデータ（文章や音声、画像など）の処理には適していないという問題があり、近代ビジネスが必要とする高速で多様なデータの大規模処理においては課題がありました。データウェアハウスは、そういった最新のデータ処理を前提としたユースケースには適しておらず、コスト効率的にも最適なソリューションではありません。
データレイクは、規模に関係なく、画像・動画・メールのログなどの非構造化データを、生データのまま格納できる場所のことを指します。

データウェアハウスの利用が進み、多くの企業で複数のソースからの膨大なデータ収集が可能になるにつれて、アーキテクトによる単一システムの構想が生まれました。さまざまな分析プロダクトやワークロードのデータを単一のシステムに集約するという構想です。そしておよそ 10 年前に多様な形式の生データ用レポジトリ（保管場所）である「データレイク（Data Lake）」の構築が始まりました。データレイクはデータの格納には適していました。しかし、重要な機能が欠けており、トランザクションのサポートやデータ品質の保証がありません。一貫性と分離性の欠如により、アペンド（データをファイルなどに追加する操作）と読み取り、バッチとストリーミングジョブ（データをリアルタイムで処理）を混在させることはほぼ不可能です。データレイクは、これらの理由から本来の目的の達成には至っておらず、データスワンプ（活用ができないデータが大量に溜まっている）状態となっているのが実情です。

一方で、柔軟で高性能なシステムに対するニーズは高まり続け、多くの企業が、SQL 分析、リアルタイムの監視、データサイエンス、機械学習など、多様なデータアプリケーションに対応するシステムを必要としています。AI を最大限に活用するには、非構造化データ（テキスト、画像、動画、音声など）の処理能力を高めることが不可欠ですが、非構造化データはまさに、データウェアハウスが得意としないデータ形式です。非構造化データの処理には、一般的に複数のシステムが使用されます。データレイクと複数のデータウェアハウスに加えて、ストリーミング、時系列、グラフ、画像データベースのような特殊システムなどが導入されます。複数のシステムの使用は複雑さを招き、さらに大きな問題となる遅延を引き起こします。異なるシステム間のデータの移動やコピーが必要になるためです。
データレイクの限界に挑む新しいシステムとして登場したデータレイクハウスは、データレイクとデータウェアハウスの優れた要素を取り入れた新しいオープンアーキテクチャです。新たなシステムデザインによって構築されており、データウェアハウスと類似のデータ構造とデータ管理機能を、オープンフォーマットで低コストのクラウドストレージに直接実装しています。データレイクハウスは、安価で信頼性の高いストレージ（オブジェクトストア形式）が利用可能になった今、最新のニーズに対応するデータウェアハウス構築のための最善策と言えるでしょう。
データレイクハウスの主な特徴は次のとおりです。

トランザクションのサポート：エンタープライズにおけるデータレイクハウスでは、多くのデータパイプラインがデータの読み取り・書き込みを同時に行います。ACID トランザクションのサポートにより、SQL などを利用したデータの読み取り・書き込みを複数のユーザーが同時に実行する場合でも一貫性が保たれます。
スキーマの適用とガバナンス：データレイクハウスは、スタースキーマ、スノーフレークスキーマなどの DW スキーマのアーキテクチャをサポートし、スキーマの適用と進化をサポートすることを期待されています。システムはデータの整合性を判断する能力および、堅牢なデータガバナンスと監査メカニズムを備えていなければなりません。
BI ツールをサポート：データレイクハウスでは、ソースデータに対して直接 BI （ビジネスインテリジェンス）ツールを使用できます。これにより、データの陳腐化の低減、最新性の向上、レイテンシー（データ転送における通信の遅延時間）の低減が可能になり、データレイクとデータウェアハウスの両方でデータコピーを重複して保持することによるコストを削減します。
コンピューティングとストレージを分離：これは、ストレージとコンピューティングが別々のクラスタを使用することを意味します。したがって、同時に利用するユーザー数やデータサイズの増大にあわせた拡張が容易になります。最新のデータウェアハウスの中には、このような特徴を持つものもあります。
オープン性：データレイクハウスでは、Parquet のようなオープンで標準化されたストレージ形式が使用されています。API を提供し、機械学習や Python/R ライブラリなど、さまざまなツールやエンジンからデータへの効率的な直接アクセスを可能にしています。
構造化・非構造化データのサポート：データレイクハウスは、構造化、非構造化、半構造化データをサポートし、画像、動画、音声、テキストなど、最近のデータアプリケーションに必要なデータ形式の保存、調整、分析、アクセスを可能にします。
多様なワークロードのサポート：データレイクハウスは、データサイエンス、機械学習、SQL、分析など、さまざまなワークロードをサポートします。ワークロードの種類によっては専用のツールが必要な場合もありますが、その場合でも、同じデータリポジトリが使用されます。
エンドツーエンドのストリーミング：企業の多くがリアルタイムのレポート作成を当然のこととしています。データレイクハウスでは、ストリーミングがサポートされるため、リアルタイムのデータアプリケーション専用のシステムを別途用意する必要がありません。
データレイクハウスの上記のような特徴の他に、エンタープライズグレードのシステムでは追加機能が必要となります。例えば、セキュリティやアクセス制御の機能です。昨今のプライバシー規制に対応するための監査、保持、リネージなどのデータガバナンス機能は不可欠になっており、データカタログやデータ使用量指標などのデータを抽出するためのツールも必要です。データレイクハウスでは、このようなエンタープライズ機能を単一のシステムに対して実装、テスト、管理するだけですみます。
ビジネスでは、全てのデータに金塊が含まれていることが分かっています。チームの仕事はそれを見つけ出すことです。しかし、扱いにくいツールや設定の難しいインフラに囲まれている状態では、その仕事をうまくこなすことはできません。本当はビジネスで現在何が起こっているのかを解明してヒーローになりたいのに、時間はツールとの格闘にばかり費やされています。
 Databricks はビッグデータを簡素化するために構築されました。Apache Spark™ は、データパイプラインを構築するための統合フレームワークを提供することで、この使命を達成するための大きな一歩を踏み出しました。Databricksは、Spark を中心に構築されたゼロ管理クラウドプラットフォームを提供することで、これをさらに推進します。Spark では、1) 完全マネージド型の Spark クラスタ、2) 調査および視覚化のための対話型ワークスペース、3) 運用パイプラインスケジューラー、4) お使いの Spark ベースのアプリケーションをk強化するプラットフォームを提供しています。もうデータの追跡に頭を悩ませる必要はありません。これからはビジネスに直結する知見を得るために注力できるようになります。
データサイエンティストやエンジニアから、開発者やデータアナリストに至るまで、ビッグデータから迅速かつ効率的に価値を引き出したいユーザーに最適です。対話型のワークスペースの提供により、Spark のネイティブな R、Scala、Python、SQL、インターフェースや、リモートプログラムアクセス用 REST API、オフラインで開発された任意の Spark ジョブを実行する機能、BI やドメイン固有のツールといったサードパーティ製アプリケーションに対するシームレスなサポートが可能になりました。このように Databricks により、ユーザーは、最も使いやすいインターフェースを通じてデータおよび情報を活用できます。
Databricks は、金融サービス、医療、小売、メディア＆エンターテインメント、公益事業など、さまざまな分野の企業で使用されています。コア ETL、データの発見と深掘り、データウェアハウス、データ製品のデプロイ、ダッシュボードを使用した社内外向けの情報の公開など、幅広いユースケースで、当社のプラットフォームをご利用いただいています。
そのとおりです。企業は大量のデータを蓄積していますが、ビッグデータの分析プロセスには、インフラ管理、プロビジョニング上のボトルネック、取得や管理にかかる高額のコストなど、多くの障壁が存在します。Databricks は、これら全ての障害を取り除くように設計されています。私たちはビッグデータを企業にとって扱いやすいものにし、ビジネスアプリケーションの Excel のように、一般的な存在にしたいと考えています。
Databricks は、バークレー大学で Spark の研究プロジェクトを開始したチームによって開発され、後に Apache Spark™ になりました。Databricks は、オープンソースコミュニティと連携してプロジェクトの拡大を続けています。当社は、他のどの企業よりも多くのコードを Spark に提供してきました。また、Spark の開発者、システムインテグレーター、アプリケーション、ディストリビューター、トレーナー向けに、Databricks 認定プログラムも提供しています。さらに当社では、データサイエンス、エンジニアリング、ビジネスを統合してイノベーションを加速する、統合分析プラットフォームの Databricks も開発しました。
Databricks は現在、ブラウザベースのファイルアップロード、Azure Blob Storage、AWS S3、Azure SQL Data Warehouse、Azure Data Lake Store、Cosmos DB などの NoSQL データストア、Cassandra、Elasticsearch 、JDBC データソース、HDFS、Sqoop、および Apache Spark によってネイティブにサポートされている他のさまざまなデータソースをサポートしています。
Databricks は、既に業界のベストプラクティスに基づいて独自のセキュリティアーキテクチャを実装しています。さらに SANS のインターネットセキュリティ対策トップ 20、コンセンサス監査ガイドライン、NIST ガイドライン、そしてインターネット標準といった、より高い基準を達成するよう継続的に取り組んでいます。また Databricks では、Databricks の完全性に影響を及ぼす可能性があるアプリケーションまたはネットワークレベルのセキュリティ問題を特定する、セキュリティ機能を標準で保持しています。
分析に関する遺伝学の一分野です。その主な役割は、DNA のシーケンス全体、または DNA を構成する原子の組成、および DNA 原子間の化学結合を決定することです。ゲノミクスの分野は、全体構造としてのゲノムに重点を置いており、生物の完全な遺伝物質の研究として定義することができます。DNA は 1869 年に初めて単離されましたが、ゲノミクスは、科学者が単純な生物の DNA シーケンスを決定した 1970 年代に始まったばかりです。ゲノミクスの分野で最大のブレークスルーは、自由生活性有機体であるインフルエンザ菌の全ゲノムシーケンスが完成した 1995 年に起こりました。ヒトゲノム計画は、ヒトゲノムの 30 億文字全てをシーケンシングすることを目的として 1990 年に開始されました。染色体 22 は、1999 年にこの計画の一環としてシーケンシングされた最初の染色体です。国際ヒトゲノム配列コンソーシアムは、2001 年 2 月にヒトゲノムの最初の草稿を学術誌ネイチャーに発表し、ゲノム全体の 30億塩基対のシーケンスの約 90% を完了しました。全てのシーケンシングは 2003 年 4 月に完了し、公開されました。進化するゲノミクスの分野には、一般的に次に挙げるいくつかの重要な研究分野が含まれています。
IBM によると、デジタルツインの従来の定義は、「物理オブジェクトを正確に反映するように設計された仮想モデル」です。デジタルツインは、離散的または連続的な製造プロセスにおいて、さまざまな IoT センサー（OT：運用技術データ）やエンタープライズデータ（IT：情報技術）を用いてシステムやプロセスの状態データを収集し、仮想モデルを形成します。このモデルは、シミュレーションの実行、性能の問題の調査、知見の抽出に使用できます。
 デジタルツインの概念は、特に新しいものではありません。実際、最初の申請は、25 年以上前に行われました。ロンドンにあるヒースローエクスプレスの鉄道施設における基礎工事とコファダム工事の初期段階で、基礎のボアホールグラウティングを監視・予測するためのものであったと報告されています。この最初の申請から数年後、エッジコンピューティングや AI、データ接続性、5G 通信、モノのインターネット（IoT）の改善や機能向上により、デジタルツインは費用対効果が高い手段となり、現在のデータドリブンなビジネス環境において必須となっています。
Datasetとは、Java および Scala 用のタイプセーフなSparkの構造化APIです。Python および R は動的型付け言語であるため、この API の使用はできませんが、Scala や Java で大規模なアプリケーションを作成するためには強力なツールです。DataFrame は、Row 型のオブジェクトの分散型コレクションであり、さまざまなタイプの表形式データを保持できます。Dataset API を使用すると、データフレーム内のレコードに Java クラスを割り当て、Java の ArrayList や Scala の Seq と同様に、型付きオブジェクトのコレクションとして処理できます。Dataset で使用できるAPIはタイプセーフで、Dataset 内のオブジェクトを、最初に配置したクラスとは別のクラスのものとして誤って表示することはありません。このため、明確に定義されたインターフェースを介してやりとりする必要のある大規模なアプリケーションを作成する場合、Dataset はソフトウェアエンジニアにとって魅力的です。Dataset クラスは、内部に含まれるオブジェクトの型でパラメータ化されます。Java では Dataset、Scala では Dataset[T]です。Spark 2.0では、サポートされるT型は Java の JavaBean パターンに従う全てのクラスと、Scala のケースクラスで、Spark が自動的にT型を分析し、Dataset内の表形式データに適切なスキーマを作成する必要があるため、これらの型は制限されます。
Data Vault（データボルト）とは、データモデリングのデザインパターンで、エンタープライズ規模の分析向けのデータウェアハウスを構築する際に使用されます。データボルトには、ハブ、リンク、サテライトの 3 種類のエンティティがあります。ハブは、ビジネスの中核となるコンセプトを、リンクは、ハブ間のリレーションシップを表します。サテライトは、ハブに属する情報やハブ間のリレーションシップに関するデータを格納します。データボルトは、レイクハウスのパラダイムを採用する組織に適したデータモデルです。
データボルトに様々なメリットがあります。1. アジャイル, 2. 構造化され、リファクタリングに柔軟に対応, 3. ペタバイト規模にも対応する優れたスケーラビリティ, 4. ETL コード生成をサポートするパターンを使用, 5. データレイヤー、ETL、スタースキーマなど、現行のアーキテクチャを使用可能。
 データボルトは、アジャイルな方法と技術に基づいているため、急速に変化するビジネス要件に適応できます。データボルトの手法を利用する大きなメリットは、モデルが変更された場合に、ETL ジョブのリファクタリングが少なくて済むことです。
データマートは、テーブルのセットを含むキュレートされたデータベースです。単一のデータチームやコミュニティ、マーケティングやエンジニアリング部門といった基幹業務の特定のニーズに対応できるよう設計されています。データマートは通常、データウェアハウスよりも小規模で、特定の目的に特化しています。一般的には、大規模なエンタープライズのデータウェアハウスのサブセットとして扱われ、分析や BI（ビジネスインテリジェンス）、レポーティングに使用されます。データマートは、中央データウェアハウスとデータレイクの物理的現実における最初の進化的ステップでした。エーシーニールセンは、1970 年代初頭に、情報をデジタル保存し販促活動を促進するための最初のデータマートを顧客に提供しました。
データマートの特徴は以下６点あります。1. 通常、データマートの構築や管理は企業のデータチームが行いますが、各事業部署の専門家が組織的に行うことも可能です。2. 企業のデータスチュワードがデータマートを管理し、エンドユーザーは読み取り専用の権限が設定されます。これは、技術に精通していないユーザーによる重要なビジネスデータの誤った削除、変更を防ぐためです。3. 一般的には、ディメンションモデルとスタースキーマが使用されます。4. データマートは、大規模なデータウェアハウスからキュレートされたデータのサブセットを含んでいます。データは高度に構造化され、データチームによってデータクレンジングと適合化が施されて容易に理解、参照できるようになっています。5. データマートは、特定の基幹業務やユースケースに特有のニーズにあわせて設計されています。6. 基本的に、ユーザーは、SQL コマンドを使用してデータを参照します。
データマートには、基本的に 3 つの種類があります。1. 独立型データマート：データウェアハウスの一部ではなく、エーシーニールセンが提供した最初のデータマートと非常によく似ています。通常、1 つの領域または対象領域に特化しています。データソースには、外部ソースと内部ソースの両方を含めることができます。データは変換、処理、データマートにロードされ、必要になるまで保存されます。
 2. 従属型データマート：既存のデータウェアハウスに従属する形で存在するデータマートです。トップダウンのアプローチを採用し、あらゆるデータを一元的に保存できます。何かしらの目的でデータを使用する際は、明確に定義されたデータのセクションを選択できます。
 3. ハイブリッド型データマート：データウェアハウスだけではなく、それ以外の独自のデータソースから取得したデータを組み合わせて使用します。これは、組織に追加された新たなグループや製品をアドホックに統合する場合など、さまざまな状況で役立ちます。ハイブリッド型データマートは、複数のデータベースが存在する環境に適しており、短期間で導入できます。このようなシステムはデータクレンジングを容易にし、小規模なデータセントリックのアプリケーションと相性が良いとされています。
データマートのメリットは、基本的に２つあります。1. 信頼できる唯一の情報源（SSOT）：データマートは、特定の基幹業務の単一のデータソースとして機能します。業務に関わる全ての人が同一の事実とデータに基づいて作業することを可能にします。2. 業務効率化をサポートするシンプルさ：ユーザーは、必要なデータを見つけるためにデータウェアハウス全体を調べたりテーブルを結合したりする必要はなく、あらかじめ精選されたデータマートで、必要なデータに容易にアクセスできます。
エンタープライズデータウェアハウスは、その企業における全てのデータ管理ニーズに対応するために善意で作成されています。しかし、各事業部署によってデータのニーズや目的が異なるため、あらゆるユーザーのニーズを満たすことはできません。そのため、各部門ではセルフサービスでの分析や、部門のレポーティングのニーズを満たすべく、時には IT 部門のサポートを受けながら、特定のデータウェアハウスの対象領域を拡張し、データをコピーして、独自のデータマートを作成しています。その結果、各部門のニーズを満たしたとしても、時間が経つにつれて、データのサイロ化やシャドーコピーの原因になります。また、多くの部署でこのようなことが行われている場合、組織内で信頼できる単一のデータソースが存在しなくなってしまいます。
レイクハウスは、企業内に存在するデータウェアハウスとデータマートを単一のプラットフォーム上に設置し、セキュリティとガバナンスを統一することで、データマートの課題を解決しています。同時に、各チームが独自システムを持つことができる柔軟な環境を提供します。また、データマートや「拡張コピー」は、他の全てのデータと同じレイクハウスプラットフォーム上で作成されるため、類似したコピーの複製を防止できます。レイクハウスのデータカタログにより、重複コピーを発見し、タグ付けやデータ辞書の使用などのデータガバナンスルールを使用して、誰もが拡張コピーを発見できるようになります。
データ共有とは、同じデータを複数のユーザーで利用できるようにすることです。増加し続けるデータは、あらゆる企業にとって重要な戦略的資産です。組織内外におけるデータ共有は、新たなビジネスチャンスを生み出すカギとなる技術です。外部データを利用するだけでなく、データを共有することで、パートナーとのコラボレーション、新たなパートナーシップの確立、データのマネタイズによる新たな収益源の確保が可能になります。
Delta Sharing は、セキュアなデータ共有のための世界初のオープンプロトコルです。使用しているコンピューティングプラットフォームを問わず、組織内外でのデータ共有を容易にします。
・ライブデータを直接共有：Delta Lake にある既存のライブデータを、他のシステムにコピーすることなく容易に共有できます。
・さまざまなクライアントに対応：データ受信者は、特定のコンピューティングプラットフォームを事前導入しなくても、Pandas、Apache Spark™、Rust、その他のシステムから Delta Sharing に直接アクセスできるため、データ送信における摩擦が軽減されます。
 ・セキュリティとガバナンス： Delta Sharing では、共有データセットへのアクセスの管理、追跡、監査を容易に行うことができます。
 ・スケーラビリティ：S3、ADLS、GCS などのクラウドストレージシステムを活用することで、大規模なデータセットを確実かつ効率的に共有できます。
メダリオンアーキテクチャとは、レイクハウスのデータを論理的に整理するために用いられるデータ設計を意味します。データがアーキテクチャの 3 つのレイヤー（ブロンズ → シルバー → ゴールドのテーブル）を流れる際に、データの構造と品質を増分的かつ漸次的に向上させることを目的としています。メダリオンアーキテクチャは、「マルチホップ」アーキテクチャとも呼ばれます。
レイクハウスは、データレイクとデータウェアハウスの優れた要素を取り入れた新しいデータプラットフォームアーキテクチャです。モダンレイクハウスは、拡張性と性能に優れたデータプラットフォームです。未加工データと準備済みデータの両方をホストし、ビジネスにおける迅速な消費、高度な知見や意思決定を促進します。データサイロを解消し、企業全体の認証済ユーザーによる、単一プラットフォームでのシームレスかつセキュアなデータアクセスを可能にします。
レイクハウスアーキテクチャのメリットはたくさんあります。1. シンプルなデータモデル, 2. わかりやすく、導入が容易, 3. 増分 ETL が可能, 4. 未加工データからのテーブル再作成がいつでも可能, 5. ACID トランザクション、タイムトラベル
ブロンズレイヤーでは、外部ソースシステムからのあらゆるデータを格納します。ブロンズレイヤーのテーブル構造は、ロード日時、プロセス ID などの付加的な行のメタデータに加えて、ソースシステムの「そのまま」のテーブル構造に対応します。このレイヤーは、変更データの迅速な取得、ソースの履歴アーカイブ（コールドストレージ）、データリネージ、監査性の機能を備えており、ソースシステムからデータの再読み込みなしで、必要に応じた再処理を行います。
レイクハウスのシルバーレイヤーでは、ブロンズレイヤーのデータをマッチング、マージ、フィルタリング、クレンジング（適度なレベル）し、あらゆる主要なビジネスエンティティ、コンセプト、トランザクションの「エンタープライズビュー」を提供します。（顧客マスターテーブル、店舗マスターテーブル、重複を排除したトランザクションテーブル、相互参照テーブルなど）
 シルバーレイヤーでは、異なるソースからのデータをエンタープライズビューに取り込み、アドホックレポート、高度な分析、機械学習などのセルフサービス分析を可能にします。シルバーレイヤーのデータは、アナリスト、データエンジニア、データサイエンティストによるプロジェクトや分析のソースとなり、ゴールドレイヤーの企業や部門のデータプロジェクトにおいて、ビジネス上の課題の解決を支援します。
 レイクハウスのデータエンジニアリングでは、一般的に、ETL ではなく ELT 処理が行われます。これは、シルバーレイヤーにデータがロードされる際に、最小限、あるいは「適度な」変換およびデータクレンジングルールのみが適用されることを意味します。データレイクでのデータの取り込みや供給における迅速性と俊敏性が優先され、シルバーレイヤーからゴールドレイヤーにデータがロードされる際には、プロジェクト特有の複雑な変換やビジネスルールが多く適用されます。データモデリングに関しては、シルバーレイヤーは第 3 正規形に近いデータモデルを備えています。このレイヤーでは、Data Vault のような書き込み可能なデータモデルを使用できます。
レイクハウスのゴールドレイヤーにあるデータは、通常、消費可能な「プロジェクト専用」データベースに整理されています。ゴールドレイヤーはレポート作成に適しています。結合が少なく、より非正規化され、読み取りが最適化されたデータモデルを使用しています。データ変換とデータ品質ルールの最終レイヤーです。顧客分析、製品品質分析、インベントリ分析、顧客セグメンテーション、商品推薦、マーキング／販売分析などのプロジェクトにおける最終プレゼンテーションレイヤーです。多くのキンボール式スタースキーマベースのデータモデル、またはインモン式データマートは、レイクハウスのこのゴールドレイヤーに適合します。
 このように、データはレイクハウスの異なるレイヤーを移動する際に、キュレートされます。従来の RDBMS テクノロジースタックのデータマートや EDW をレイクハウスに取り込み、企業における初の「汎 EDW」の高度な分析や機械学習を可能にするケースもあります。従来のスタックでは不可能、あるいはコストがかかりすぎるため、実現されていなかったことです。（IoT／製造業データと営業・マーケティングデータを連携させ、欠陥分析やヘルスケアゲノミクス解析を行う、EMR/HL7 臨床データ市場と金融債権データの連携によりヘルスケアデータレイクを構築してタイムリーな患者ケアの分析や改善を行うなど）。
はい、メダリオンアーキテクチャは、データメッシュのコンセプトと互換性があります。ブロンズとシルバーのテーブルは「1 対多」方式で結合できるため、1 つのアップストリームテーブルのデータを使用して、複数のダウンストリームテーブルを生成できます。
金融商品やサービスのコモディティ化が進み、メディアや小売業界がパーソナライズされた体験を好むようになったことで、消費者の目は肥えてきています。消費者から求められるものが日々変化していく中で、銀行がこれからも必要とされ続けるためには、パーソナライズされた知見やレコメンド、財務目標の設定、レポート機能といった従来の銀行業務を超えた魅力的な銀行体験を提供する必要があり、これらは全て地理空間や自然言語処理（NLP）などの高度な分析機能によって実現されます。金融サービスのパーソナライズは、オープンファイナンスとも呼ばれ、データ共有の原則に基づき、銀行が顧客のニーズに特化した幅広い可能性を提供できるようにするものです。金融サービスのパーソナライズは、オープンバンキング（次節参照）の標準採用と、世界中で変わり続ける規制によって実現されます。
データベースやデータストレージシステムにおけるトランザクションとは、1 つの作業単位として扱われるあらゆる操作のことです。トランザクションは、完全に実行される、もしくは全く実行されないかのいずれかで、ストレージシステムを一貫した状態に保ちます。トランザクションの典型的な例として、銀行の預金口座から現金を引き出す処理が挙げられます。この場合、預金口座から現金を引き出したか、もしくは全く引き出さなかったか、どちらかの処理が発生し、中間の状態はありません。
ACID とは、トランザクションを定義する4つの重要な特性、Atomicity（原子性）、Consistency（一貫性）、Isolation（独立性）、Durability（永続性）の頭文字をとった略語です。データベース操作にこれらの ACID 特性がある場合は、ACID トランザクションと呼ぶことができます。また、これらの操作を適用したデータストレージシステムは、トランザクションシステムと呼ばれます。ACID トランザクションにより、テーブルの読み取り、書き込み、変更の各処理で次の特性が保証されます。
 ・原子性（A）：トランザクションの各ステートメント（データの読み取り、書き込み、更新、削除）は、1 つの単位として扱われます。ステートメントは、実行されるか、あるいは全く実行されないかのいずれかです。この特性は、ストリーミングデータソースがストリーミングの途中で障害が発生した場合などに、データの損失や破損が発生するのを防ぎます。
 ・一貫性（C）：トランザクションがテーブルに、事前定義された予測可能な方法でのみ変更を加えることを保証します。トランザクションの一貫性により、データの破損やエラーが起きた場合でもテーブルの整合性を保ち、意図しない実行結果を防ぎます。
 ・独立性（I）：複数のユーザーが同じテーブルで読み書きを同時に実行しても、トランザクションが分離され、同時進行のトランザクションが相互に干渉したり、影響を受けたりしないようにします。実際は、同時に発生していも、各要求は単独で発生しているように扱われます。
 ・永続性（D）：システム障害が発生した場合でも、正常に実行されたトランザクションによるデータの変更が保存されることを保証します。
ACID トランザクションは、データの信頼性と整合性を最大限に高めます。部分的にしか操作を完了できなかった場合でも、データの一貫性を保つことができます。例えば、データベースのテーブルへの書き込み中に、予期せず電源が切れた場合、ACID トランザクションがなければ、データは一部のみ保存され、残りは保存されない可能性があります。その結果、データベースの一貫性は失われ、復旧は困難で時間のかかるものとなります。
ACID トランザクションは、これまでデータウェアハウスのみが持つ特性でしたが、Delta Lakeは、データレイクにACID トランザクションを提供します。これにより、新たなデータがテーブルに書き込まれても、ユーザーは、データの一貫性のあるリアルタイムなビューを見ることができます。各書き込みは、順序付けられたトランザクションログに記録される独立したトランザクションとなるためです。Delta Lake は、最高レベルの独立性（直列化可能な独立性）を採用し、1 つのテーブルでの読み取り／書き込みの一貫性と信頼性を確保しています。ACID トランザクションの実装により、Delta Lake は、ラムダアーキテクチャの問題である複雑さ、データの誤表示、ラムダパイプラインが壊れた後に必要となるリワークや再処理などを効果的に解決します。また、ユーザーは、データに対して複数の同時トランザクションを実行できます。データソースやストリームでエラーが発生した場合でも、Delta Lake は、トランザクションの実行を中止し、データをクリーンで元の状態に保つことを保証します。ACID トランザクションによる大きなメリットは、ユーザーが Delta Lake のデータを信頼できることです。データアナリストは、ダッシュボードの準備の ETL 実行に Delta Lake を使用することで、データアナリストが見ている KPI が、データの実際の状況を表していることを信用できます。機械学習のエンジニアは、特徴量エンジニアリングに Delta Lake のテーブルを利用することで、変換や集約が意図したとおりに実行できているか、または全く実行できなかったかを確信できます（その場合、通知を受けます）。データに対して持っているメンタルモデルが、実際のデータに反映していると信頼できる価値は計り知れません。
AdaGradはAdaptive Gradient Algorithmの略です。Adaptive Gradient Algorithm (Adagrad)は勾配に基づいて最適化するアルゴリズムです。過去の観測データに関する情報を取り入れることで、学習率がベクトルの要素ごとにパラメータに適用されます。低頻度の特徴に関連するパラメータには更新量を増やし（高い学習率など）、高頻度の場合は更新量を減らします（低い学習率）。Adagradの更新量は小さいため、スパースデータ（NLPや画像認識）の処理に適しています。各パラメータには固有の学習率があり、スパースな勾配に伴う問題解決能力が向上します。
AdaGrad を使用するメリットはいくつあります。1. 手動による学習率のチューニングが不要。2.重みのスケーリングが異なる場合、シンプルな確率的勾配降下法と比較して収束が高速で確実。3. マスターステップのサイズの影響をあまり受けない
Apache Hive は、Apache Hadoop 分散ファイルシステム (HDFS) から抽出された大規模なデータセットの読み取り、書き込み、および管理を行うために設計されたオープンソースのデータウェアハウスソフトウェアで、より規模の大きい Hadoop エコシステムの側面も持ち合わせています。
 Apache Hiveの豊富なドキュメントと継続的なアップデートにより、Apache Hiveはアクセスしやすい方法でデータ処理に革新を起こし続けます。
Apache Hive は、HDFS や Amazon S3、Azure Blob Storage、 Azure Data Lake Storage、Google Cloud Storage、Alluxio といった Hadoop 互換のファイルシステムに格納された大規模データの分析をサポートします。スキーマオンリードで HiveQL という SQL ライクなクエリ言語を提供し、クエリを Apache Spark、MapReduce、Apache Tez のジョブに透過的に変換します。
 その他の Hive の特徴は以下のとおりです。1. Hive データ関数により、大規模なデータセットの処理やクエリをサポートします。これらの関数が提供する機能には、文字列操作、日付操作、型変換、条件演算子、数学関数などがあります。2. リレーショナルデータベース管理システム（RDBMS）にメタデータを格納します。3. Parquet、プレーンテキスト、RCFile、HBase、ORC（Optimized Row Columnar）といったさまざまなストレージタイプに対応しています。4. Hadoop エコシステムに格納された圧縮データをアルゴリズムで操作します。5. ユーザー定義関数（UDF）が組み込まれており、日付、文字列、その他のデータマイニングツールを操作します。Hive では、組み込み関数が用意されていないユースケースを処理するために、UDF セットの拡張をサポートしています。6. SQL ライクなクエリ言語の HiveQL が、内部的に MapReduce や Tez、Spark のジョブに変換されます。
Apache Hive インフラストラクチャの中心的なリポジトリであるメタストアには、Hive のすべてのメタデータが保存されています。メタストアでは、メタデータを Hive テーブル とパーティションにフォーマットして、リレーショナルデータベース間でデータを比較することも可能です。メタデータには、テーブル名、カラム名、データ型、パーティション情報、HDFS 上のデータ位置などが含まれます。
Apache Hive のデータ型は、数値、日付/時間、文字列、複合データ、その他の5つのカテゴリで構成されています。
 1. 数値データ型: その名前が示すとおり、このデータ型は整数データがベースとなっています。データ型の例としては、「TINYINT」や「SMALLINT」、「INT」、「BIGINT」があります。
 2. 日付/時間データ型: このデータ型は、時刻と日付を入力するもので、「TIMESTAMP」や「DATE」、「INTERVAL」などのデータを入力できます。 
 3. 文字列データ型: このデータ型も非常にわかりやすく、入力されたテキストデータ、つまり「文字列」を処理するためのデータとして実装することができます。例えば、「STRING」や「VARCHAR」、「CHAR」などのデータを入力できます。
 4. 複合データ型: より高度なデータ型の一つである複合データ型は、より精巧なデータを記録し、「STRUCT」や「MAP」、「ARRAY」、「UNION」などのデータから構成されています。
 5. その他のデータ型: 他の4つのカテゴリーのどれにも当てはまらないデータ型をその他のデータ型と呼び、そこには「BOOLEAN」や「BINARY」などのデータを入力できます。
リレーショナルデータベース管理システム（RDBMS）は、行または列ベースのテーブルストラクチャにメタデータを格納することで動作するデータベースモデルであり、異なるデータセットを接続して比較することができます。
 RDBMS を利用することで、 Apache Hive はすべてのデータを安全、確実、かつ正確に保存、処理することができます。これは、役割ベースのセキュリティや暗号化通信などの統合機能により、抽出した情報へのアクセス権限が適切な人のみに付与できることにより実現します。
Apache Hive と RDBMS には、いくつかの重要な違いがあります。1. RDBMS の機能が何度も読み取り／書き込みを行うのに対し、Hive では一度だけ書き込み、何度も読み取りを行います。2. Hive は、スキーマオンリードのルールに従っており、データのチェックやパース、検証は行わず、ファイルのコピーや移動のみを行います。一方、従来のデータベースでは、スキーマオンライトのルールに従って、テーブルにスキーマが適用されます。3. Hive は Hadoop 上に構築されているため、Hadoop や MapReduce と同じ制限に準拠する必要があります。他の RDBMS は、その限りではありません。
Apache Spark は、様々なデータセットの大量データを処理するために設計された分析フレームワークで、 R から Python まで様々な言語をサポートできる強力なユーザーインターフェースを提供します。
 Hive は、データを行、列、データ型を持つテーブルとして表現し、HiveQL と呼ばれる SQL インターフェースを使ってクエリや分析を行うための抽象化レイヤーを提供します。また、Hive は、Hive LLAP による ACID トランザクションをサポートしています。トランザクションは、複数のユーザーやプロセスが同時にデータにアクセスし、CRUD（生成、読み取り、更新、削除）操作を行う環境において、データ表示の一貫性を保証します。
 Databricks が提供する Delta Lake は、ACID トランザクションを保証するという点では Hive LLAP に似ていますが、オープンソースの Delta Lake には、データアクセス時の性能と信頼性を高める利点があります。Spark SQL は、行、列、データ型を持つテーブルとして表現される構造化データを操作するための Apache Spark のモジュールです。
 Spark SQL は SQL 2003 に準拠しており、データ処理の分散エンジンとして Apache Spark を使用します。Spark SQL インターフェースに加えて、DataFrames API を使用して Java、Scala、Python、R を用いてデータを操作することが可能です。Spark SQL は、HiveQL に似ています。
 どちらも ANSI SQL 構文を使用しており、Hive 関数の大部分は Databricks 上で実行されます。これらの Hive 関数には、日付／時刻の変換やパース、コレクション、文字列操作、数学演算、条件付き関数が含まれます。
 ただし、Hive 特有の関数には、Spark SQL に相当するものに変換が必要な関数や、Databricks 上の Spark SQL には存在しない関数があります。ANSI SQL 構文を使用した全ての HiveQL は、Databricks 上の Spark SQL で動作すると考えてよいでしょう。
 ANSI SQL の集計と分析関数も含まれます。Hive は、ORC ファイル形式に最適化されており、Parquet もサポートしています。Databricks は、Parquet と Delta に最適化されており、ORC もサポートしています。Databricks では、オープンソースの Parquet をファイル形式として使用する Delta の使用を推奨しています。
PrestoDB 、通称 Presto は、もともとFacebookで立ち上げられたプロジェクトで、ペタバイト規模のデータを高速に処理・分析できる分散型 SQL クエリエンジンです。Presto のインフラストラクチャは、 MySQL や Teradata から MongoDB や Cassandra まで、リレーショナルデータベースと非リレーショナルデータベースの両方の統合をサポートしています。
Apache Kudu とは、Apache Hadoop 向けに開発された無料のオープンソースの列指向ストレージシステムです。構造化データ用エンジンで、各行への低遅延でランダムなミリ秒スケールのアクセスに加えて、優れたアクセスパターン分析もサポートします。広く普及している Hadoop 分散ファイルシステム（HDFS）と NoSQL データベースの HBase 間をつなぐために作成されたビッグデータエンジンです。
Apache Kylin とは、ビッグデータの対話型分析のための分散型オープンソースのオンライン分析処理（OLAP）エンジンです。Apache Kylin は Hadoop や Spark でSQL インターフェイスと多次元分析（OLAP）を提供するよう設計されています。さらに、ODBC ドライバ、JDBC ドライバ、REST API を介して BI ツールと容易に統合します。2014年に eBay が構築した Apache Kylin は、わずか 1 年後の 2015年に Apache ソフトウェア財団（ASF）のトップレベルプロジェクトに進出し、「Best open Source Big Data Tool （最も優れたオープンソースのビッグデータツール）」を 2015 年から 2 年連続で受賞しています。現在は、ビッグデータ向けの極めて重要な分析アプリケーションとして、世界中にある数千もの企業で使用されています。他の OLAP エンジンがデータ量に苦戦している中、Kylin のクエリ応答はミリ秒単位で、データセット全体を1秒以内のクエリレイテンシでペタバイト規模にスケーリングします。Kylin は、Hive クエリ経由でさまざまな次元の組み合わせと集計測定値を事前計算し、HBase に結果を入力することで、高速化を実現しています。