開発者のためのデータツール地図ガイド

• データ分野に初めて参加したソフトウェア開発者が、ツールの名前を覚えるだけでなく、データの収集／保存／処理／活用の各段階で各ツールが担う役割とつながりを把握できるよう、全体像を整理する
• データ職種はおおまかに分析／サイエンス／エンジニアリング／機械学習のタイプに分かれ、SQLとBIから統計モデルとノートブック、パイプライン基盤、運用中のモデル配備まで、異なる問題とツールを扱う
• ストレージは、高速な分析と利便性を提供するデータウェアハウス、低コストで柔軟なデータレイク、テーブル形式でACIDとスキーマ管理を加えたレイクハウスに分類される
• データ処理は、dbtのようなSQL変換、pandasとDuckDBによるローカル処理、Sparkの分散バッチ処理、KafkaとFlinkのストリーム処理へと広がり、Airflowのようなオーケストレーターが独立したタスクの実行順序と失敗時の復旧を管理する
• 処理済みデータはダッシュボードだけでなく、営業／サポート業務、アドホック分析、機械学習、プロダクト内分析機能、データ販売に活用され、規模が大きくなるほどカタログ／セマンティックレイヤー／リネージ／ガバナンスがデータの意味と責任を維持する中核基盤となる

---

開発者が知っておくべき範囲

• データ企業に加わったものの関連するバックグラウンドがなかったソフトウェアエンジニアが、ツールの用途とノートブックとの相互作用を理解するためにまとめた開発者向け概説書である
• ダッシュボードの作り方、統計の基礎、Sparkクラスタの運用方法や、同じカテゴリの製品ごとの詳細比較は扱わない
• データがどこで生まれ、どのように処理・保存・表示されるのかをたどりながら、各ツールが担うライフサイクル段階を区別する

データ職種の4つのタイプ

• 実際の役割の境界は、特に小さな会社やチームでは曖昧だが、全体像を理解するために4タイプに分けられる
• 分析型はSQLとスプレッドシートでデータを解釈し、インサイトを可視化する
  • Data analystとBI analystが代表的で、Tableau、Excelなどを使う
  • 顧客データを参照して地域別の解約率を計算し、Tableauダッシュボードとリテンション施策の提案を作る作業が例である
• サイエンス型は統計・モデル・実験を通じて、表面的なレポートより深い問いや予測を扱う
  • Data scientistが代表的で、Python、pandas、scikit-learn、ノートブックを主に使う
  • 解約要因を探索し、顧客ごとの解約可能性モデルを作ったうえで、リテンション施策のA/Bテストを設計・分析できる
• エンジニアリング型はソースデータを収集・整形・標準化してウェアハウスやレイクにロードし、データツールとデータベースを運用する
  • Data engineerが代表的で、Python、Apache Spark、データベース、ウェアハウス、クラウドを使う
  • 分析結果を反復実行可能なリバースETLパイプラインへ拡張したり、複数ソースの取引データを統合してスキーマ・クエリ・品質チェックを管理したりする
• 機械学習型は分類モデルからLLMまで、AIモデルを作成して運用する
  • ML scientistとML engineerをひとつにまとめたカテゴリであり、別個のツールエコシステムが大きいため本文では詳しく扱わない
  • レコメンドモデル用の学習データを組み立て、モデルを学習・調整してAPIとして配備した後、予測を監視し、行動変化に合わせて再学習する

ETLとELT

• **ETL（Extract-Transform-Load）**はソースデータを抽出し、整形したり他のデータと結合したりした後、結果を目的地にロードする一般的な流れである
• ステップの順序は固定ではなく、反復されたり互いに重なったりすることがある
• ELTはソースデータを先にウェアハウスへロードし、その中で変換して結果を別テーブルに保存する
  • 追加のストレージ容量と計算のため、コストが増える場合がある
  • 元データが残っているため、後から別の方法で再処理できる

ファイル形式とメモリ形式

• CSVは小さなデータを渡しやすく、ほとんどのオフィスソフトで開けるため、非技術ユーザーに適している
• Apache Parquetは列指向ファイル形式で、圧縮率が高く、大規模データを効率よく保存・転送できる
  • ほとんどのデータツールが対応しており、ツール間の共通形式として機能する
  • Apache ORCも似た問題を解決する
• Apache Avroは行指向のバイナリ形式で、レコードの受け渡し、特にストリーム処理に使われる
• Apache Arrowは処理とゼロコピー転送に最適化された、事実上の標準インメモリ形式である
  • Parquetは小さなファイルと必要な項目のスキャンに、ArrowはCPU・GPU命令とキャッシュを活用した実際の計算に焦点を当てる
  • Arrowはより多くのメモリを使うが、pandasやRustのDataFusionのようなツール間でデータを効率的に受け渡しする
  • pandasのオプションバックエンドとして使うことができ、PolarsとDataFusionは最初からArrowベースで作られている

データウェアハウス

• データウェアハウスはPostgreSQL・MySQLのようなデータベースに似ているが、分析負荷に最適化されている
• MySQLのようなOLTPデータベースはIDでユーザー行を1件探す作業に適しており、OLAPウェアハウスは年間の地域別売上合計のような列単位の集計に適している
• 伝統的には整形済みの構造化データの最終保存先だったが、ELTでは生データの最初のロード先としても使われる
• 保存形式とクエリエンジンが密接に結合しているため高速なBI・レポート用クエリを提供する一方、3種類のストレージの中でコストが最も高い
• 製品にはSnowflake、BigQuery、Redshiftがある
• オープンソース・セルフホストの選択肢にはClickHouse、Apache Doris、StarRocksがある
• 小さなプロジェクトなら従来型のデータベースでも十分な場合がある

データレイク

• データレイクはCSV、Parquet、JSON、メール、画像など、構造化・半構造化・非構造化データを最小限の処理で保管する、大規模なクラウドフォルダに近い
• Amazon S3、Google Cloud Storage、Azure Blob Storageに命名・パーティション規則とアクセスポリシーを定め、ファイルを保存することで構築できる
• 適切に管理しないと、見つけたり活用したりしにくい**データスワンプ（data swamp）**になり得る
• マネージドな選択肢にはAzure Data LakeとSnowflakeのデータレイク機能がある
• データを直接検索・ダウンロード・パースせずに問い合わせるには、メタデータカタログとクエリエンジンが必要である
  • カタログはテーブル名、スキーマ、ファイルマッピングを記録する
  • クエリエンジンはそのメタデータを使って関連ファイルを読み込み、SQLなどのクエリを実行する
• カタログにはHive Metastore、AWS Glue Data Catalog、Unity Catalogがある
• クエリエンジンにはApache Spark、Trino、Amazon Athenaがある

データレイクハウス

• データレイクハウスは、低コストで柔軟なレイクの上に、ウェアハウスに近い機能を追加するもの
• 中核となる構成要素であるテーブル形式が、クエリエンジンと生データの間で保存方式を管理する
  • ACIDにより、同時書き込み、書き込み中のエラー、データ破損に対処する
  • 半構造化データでもスキーマを定義する必要があり、完全な非構造化データはテーブル形式の利点を得られない
  • スキーマ進化とバージョン管理をサポートする
  • インデックスとパーティション最適化によりクエリを高速化できる
  • 一部の実装は、特定時点のスナップショットを参照するタイムトラベルをサポートする
• レイクが基盤なのでウェアハウスより低コストになり得て、特定のクエリエンジンに縛られないが、別途計算コストまで含める必要があるため、単純な価格比較は難しい
• 主なテーブル形式は Apache Iceberg、Delta Lake、Apache Hudi
• マネージドサービスには Google の Lakehouse for Apache Iceberg、Databricks、IBM watsonx.data がある

データソースと取り込み

• データは PostgreSQL・Mongo のようなアプリケーションデータベース、Stripe のような外部 API、ブラウザ分析イベント、IoT デバイスなどから入ってくる
• 抽出後すぐに処理することもでき、ELT では形式・サイズ・インフラに応じて、レイク・レイクハウス・ウェアハウスにまず原本を保存できる
• 専用スクリプトは柔軟だが、認証、ページネーション、エラー処理のような反復的な接続コードを再実装する必要がある
• データ取り込みツールは、ソースと宛先のコネクタを設定してこの反復作業を処理する
  • 抽出データをまずどこかにロードする必要があるため、ELT の流れに傾きやすい
  • 代表的な製品は Fivetran、Airbyte、dlt
• **変更データキャプチャ（CDC）**は、テーブルを繰り返し照会せず、データベースのレプリケーションログから挿入・更新・削除を捕捉する
  • 取り込みツールがデータベースソースに対して内部的に使用する
  • 独立したオープンソースコンポーネントとして Debezium が広く使われている

データ処理言語

• Pythonは、大きなコミュニティとネイティブライブラリのエコシステムを備えた、データ作業における事実上の標準言語
  • 他の言語で作られたツールでも Python バインディングを提供することが多く、Rust ベースの Apache DataFusion がその一例
• numpy は高性能な多次元配列を提供し、多くのライブラリの基盤になる
• pandas は、1次元の Series と2次元の DataFrame を提供する事実上の標準
  • seaborn・Plotly で可視化し、streamlit でインタラクティブアプリを作れる
  • DuckDB で SQL クエリを実行したり、scikit-learn の機械学習手法を適用したりできる
• R は学術分野で、Java・Scala は Spark のようなビッグデータフレームワークで使われ、Julia と Rust もデータ作業に使われるが、Python ほど普及していない
• SQLはウェアハウスのクエリと変換に広く使われるが、実行環境ごとに構文が少しずつ異なる

バッチ処理とリアルタイム処理

• バッチ処理は、先月の売上集計のように大きなデータのまとまりを定期的に処理し、結果を数時間または数日待てる作業に適している
• リアルタイム処理は、到着後すぐに処理するストリーム方式や、20秒単位のようなマイクロバッチを使う
• ボット検知のように結果の速さが重要なパイプラインは、ユーザーをできるだけ早く識別・ブロックするためにリアルタイム処理を使う

SQL ベースの変換

• dbt と SQLMesh は、SQL の select 文で変換を定義し、実際のクエリエンジンで実行されるようにコンパイルする
• 両ツールはデータを直接処理せず、変換オーケストレーションを担う
• ユーザー定義の Python スクリプトよりも変換方法を標準化し、複雑な作業を依存関係のある小さなモデルに分離できる
• dbt の ref は、ハードコードしたテーブル名の代わりにモデルを参照し、依存関係グラフに従って正しい順序で実行する
• 結果は通常、原本と同じウェアハウス・レイクハウス・レイクに保存されるが、クエリエンジンの設定によっては別の宛先へ送ることもできる

ローカル DataFrame と DuckDB

• DataFrameは表形式データを扱う2次元配列の抽象化であり、Python では pandas が最も広く使われている
• 他の実装には Python・Rust の Polars、Rust の DataFusion、Julia の DataFrames.jl、R の data.frame、Java の tablesaw がある
• pandas、data.frame、tablesaw は、呼び出しと同時に演算する**即時実行（eager）**方式
• DataFusion と Polars の LazyFrame は、演算を論理プランとして積み上げた後、.collect() で実行する
  • 実行前にプランを最適化できるため、より速くなる可能性がある
• ローカルライブラリはメモリと CPU に制限される
  • pandas はすべてのデータをメモリ上で処理するため、RAM 容量に縛られる
  • Polars のストリーミングは RAM より大きいデータも扱えるが、一部の演算ではワーキングセットをメモリに載せる必要がある
• DuckDBは「分析用 SQLite」と呼ばれるインプロセス OLAP データベース
  • 別途インフラなしで、ローカルの CSV、Parquet、pandas DataFrame を SQL で照会する

大規模分散処理

• 単一マシンの限界を超えると、データを複数の断片に分けてクラスタで並列処理し、作業量に合わせて水平スケールする
• Apache Hadoop は初期の代表的なツールだが、現在はレガシーと見なされ、古い環境で見かけることがある
• Apache Spark は現在の事実上の標準で、データの読み込み・変換・並列化・最適化を担う
  • PySpark は DataFrame API と pandas 互換レイヤーを提供する
  • SparkR は最近廃止され、Java・Scala バインディングも提供されている
  • さまざまなストレージを読み書きできるため、データレイクのクエリエンジンと大規模変換作業の両方に使われる
• Daskは、使い慣れた pandas・numpy API に近い形で Python コードをクラスタへ拡張する
• Ray は汎用分散計算フレームワークで、特に ML 学習によく使われる
• Apache Flink はバッチも処理するが、ストリーム処理が主力

イベントストリーミングと Kafka

• ストリーム処理は、クレジットカード不正検知のように結果が即座に必要な場合や、Web 分析イベントを到着時に検証し、IP 地理情報でエンリッチして ClickHouse に入れる処理に適している
• 到着直後に処理すれば、次のバッチ実行まで生のペイロードを別途保管しなくてもよい場合がある
• Apache Kafka は、プロデューサーのイベントを受け取って保存し、コンシューマーが読み取れるようにする分散型・耐障害性のあるイベントストリーミングプラットフォームである
  • メッセージキューと異なり、コンシューマーが確認してもイベントは削除されず、保持ルールが期限切れになるまで複数のコンシューマーが繰り返し読み取れる
  • Kafka 自体はデータを処理せず、別のワーカーがコンシューマーとして処理する
• Kafka Connect は Kafka をデータベースなどの外部システムに接続する
• Kafka Streams は Kafka 上でステートフルな変換、ウィンドウ集計、結合を行う Java・Scala ライブラリである
  • アプリケーションに組み込まれて実行され、Kafka 上でのみ動作する
• ほかのイベントストリーミングプラットフォームには Apache Pulsar、Redpanda、AWS Kinesis Data Streams がある

ストリーム処理エンジン

• Apache Flink はイベントソースと処理手順の定義を受け取り、クラスタへのデプロイ、スケーリング、障害復旧を担う
• パイプラインには、フィルタリング、フィールドマッピング、ウィンドウ集計、重複排除、別の Kafka トピックやデータベースへの出力を含められる
• デプロイされたジョブは終了するバッチではなく、新しいイベントを継続的に処理する
• ほかの選択肢には Spark Structured Streaming、Google Cloud Dataflow、Azure Stream Analytics がある

ジョブオーケストレーション

• dbt 変換、Spark ジョブ、カスタムスクリプトが増えると、オーケストレーターが個々のステップを 1 つのパイプラインに組み合わせる
• 各ジョブと依存関係をコード（主に Python）で定義すると、有向非巡回グラフである DAG が作られる
• オーケストレーターはデータを直接処理せず、Spark スクリプトの実行、dbt 変換の呼び出し、HTTP リクエストなどを調整する
• スケジュール、Kafka イベント、UI からの手動実行、HTTP リクエスト、プラグインで作成したトリガーを利用できる
• 独立したジョブを並列実行し、失敗したステップだけを再試行して、その地点から再開できる
• 開始から終了まで実行されるバッチ処理向けなので、稼働し続けるストリームパイプラインにはあまり合わず、この場合は Flink のような処理エンジン自体に依存する
• 代表的な製品は Apache Airflow、Dagster、Prefect、Luigi である
  • Luigi はより古く、現在の人気は低い

オブザーバビリティと品質モニタリング

• データのオブザーバビリティは、パイプラインの状態とデータ自体の品質に分けられる
  • パイプライン監視は、実行有無、失敗、所要時間を確認する
  • データ監視は、鮮度、データ量の異常、予告なしのスキーマ変更などを確認する
• パイプラインには Prometheus、Grafana、ELK のような一般的なアプリケーション観測ツールと、オーケストレーター自体の機能を利用できる
• データ品質チェックは、期待される形式を直接定義する Great Expectations と dbt tests で実装できる
• 自動化製品は正常なデータパターンを学習したうえで異常を検知し、Monte Carlo、Bigeye、Metaplane が例である

パイプラインで繰り返されるロード

• ETL の最後のロード先はウェアハウス・レイク・レイクハウスだが、データはパイプラインの最後に一度だけ保存されるのではなく、異なる形で何度も保存される
• メダリオンアーキテクチャは、同じストレージ内の精製レベルを 3 つの階層に分ける
  • Bronze はソースからそのまま入ってきた生データである
  • Silver は型の修正、重複排除、ソースの結合などを経た精製・標準化データである
  • Gold はダッシュボードやレポートなど、特定の目的に合わせて集計・モデリングしたデータである
• アナリストは主に Gold テーブルを参照し、エンジニアはパイプラインのデバッグのために Bronze までさかのぼることができる

ディメンショナルモデリング

• メダリオン構造がデータの精製レベルを表すなら、ディメンショナルモデリングはウェアハウステーブルの形を構成する
• Ralph Kimball の『The Data Warehouse Toolkit』が普及させた方式で、ファクトテーブルとディメンションテーブルを区別する
• ファクトテーブルは、注文・決済・ページビューのように、1 行につき 1 つの出来事や測定値を保存する
  • 縦に長く幅は狭く、数値とディメンションテーブルの外部キーが多く、増え続ける
• ディメンションテーブルは、顧客・製品・日付のように、出来事が発生した文脈を保存する
  • より幅が広く、相対的にゆっくり変化する
• 中央のファクトテーブルをディメンションテーブルが囲むと スター・スキーマ になる
  • より正規化された スノーフレーク・スキーマ もあり、Snowflake 製品とは無関係である
• グレイン（grain） は、1 行が 1 件の注文、1 つの注文明細、顧客別の日次注文のどれを表すのかを定義する
• データマートは、マーケティング・財務のように特定のチームやテーマに合わせたウェアハウスの一部であり、通常は Gold 階層に位置する
• すべてのチームが厳密に従うわけではなく、高速な現代のウェアハウスと低廉なストレージコストを活用し、目的別に広く非正規化した1 つの大きなテーブルを作ることもある

アプリケーション向けリアルタイム OLAP

• 社内ダッシュボードにはウェアハウスの Gold テーブルで十分だが、多数のユーザーにミリ秒単位で提供する場合は、クエリ遅延と 1 件あたりのコストが不適切になり得る
• ユーザー向け分析、リアルタイムの社内モニタリング、リーダーボード、人気項目、使用量測定のように、高い同時実行性と高速な応答が必要なデータはリアルタイム OLAP データベースへ移す
• Apache Druid、Apache Pinot、ClickHouse、Apache Doris が該当し、ClickHouse が広く使われている

リバース ETL

• リバース ETLは、ウェアハウスで処理したデータを CRM のような運用ツールへ戻す
• Stripe データで顧客生涯価値を計算して HubSpot に入れれば、営業チームが高価値顧客をすぐに確認できる
• 専用ツールはテーブル・列と宛先フィールドを紐づけ、失敗、再試行、レート制限、アラート、増分同期を処理する
• 選択肢には Airbyte Data Activation、Fivetran Activations、Hightouch、RudderStack がある
  • Fivetran Activations は買収前には Census という名前だった

データカタログとセマンティックレイヤー

• 人のためのデータカタログは、データの出所、所有者、アクセス方針、検索情報を保持し、テーブルと列にビジネス上の文脈を与える
  • クエリエンジン向けのメタストアとは目的が異なる
  • Unity Catalog、DataHub、OpenMetadataが代表的
• セマンティックレイヤーは、ビジネスエンティティ、関係、指標の標準定義を保管する
  • 顧客モデルがどのテーブルと列に由来するのか、EMEAにどの市場が含まれるのか、売上から返金を除外するのかなどを統一する
  • BIツールやAIエージェントで正しいエンティティと指標を選ぶと、必要なクエリに変換したり、クエリ生成に必要な情報を提供したりする
• LookerのLookML、Cube、dbt Semantic Layer、Unity Catalogのセマンティック機能が例である

データリネージ

• **データリネージ（data lineage）**は、パイプラインを通過する中でデータがどのように変換されたかを追跡する
• オーケストレーターのDAG、変換SQLのパース、処理ジョブが出力するイベント・メタデータから自動収集できる
• テーブルレベルでは、gold.ordersがsilver.ordersとsilver.customersから作られたという関係を記録する
• 列レベルでは、customers.life_time_valueがorders.totalとsubscription_payments.amountから計算されたという関係まで追跡する
• 列削除の下流への影響評価、誤った指標の根本原因分析、個人識別情報の利用に関するコンプライアンスに活用する
• Unity Catalog、DataHub、OpenMetadataはリネージの可視化をサポートするが、パイプライン全体がコネクターや手動イベントで追跡データを提供する必要がある
• プロバイダー別の形式ではなく、複数のカタログや処理ツールがサポートするOpenLineage標準を使用できる

BIダッシュボードとレポート

• ダッシュボードとレポートはデータパイプラインの最も一般的な消費先であり、小さな会社では実質的に唯一の活用例である場合もある
• BIツールはウェアハウス、レイクハウス、アプリケーションデータベースに接続し、コードを書かずにチャートやダッシュボードを作れるようにする
• 核心は、非技術ユーザーが毎回アナリストに依頼せず、UI上で直接チャートを作成したり探索したりするセルフサービスである
• 定期レポートをメールやSlackで送ったり、指標がしきい値を超えたらアラートを出したりできる
• TableauとPower BIは大企業で広く使われており、強力で柔軟な可視化に重点を置いている
• LookerはLookMLのセマンティックレイヤーを中心に、技術組織向けに設計されている
• Metabaseはセルフホスティングを含めて素早く設定でき、非技術ユーザーにも使いやすい
• Looker StudioはLookMLを使用せず、Lookerより機能が少ない別製品で、最近再びData Studioに名称が変更された

オペレーショナル分析

• オペレーショナル分析は経営陣向けレポートではなく、非分析職が日常的に使うアプリケーションの中にデータを提供する
• 活用例は次のとおり
  • 利用状況の集計をHubSpotに同期し、営業チームが適切な顧客にアップセルする
  • 最近の注文、サポートチケット、料金プランをZendeskに同期し、サポートチームが顧客の文脈を確認する
  • カスタマーサクセスチーム向けに、顧客別の製品導入状況を表示する社内アプリを作る
• リバースETLが代表的な配信方法だが、ウェアハウスを直接参照する社内Customer 360アプリもオペレーショナル分析に該当する

アドホック・探索的分析とノートブック

• **アドホック分析（ad-hoc analysis）**は、登録減少の原因や返金を引き起こしたコホートのような一度限りの問いを既存データで調査する
• 探索的分析は、あらかじめ決められた問いなしにデータを見ながらインサイトを探す
• 結果に応じて次の演算が変わり、単純なフィルターや集計より複雑なため、一般的なレポーティングツールだけでは不十分な場合がある
• Pythonとpandas・Polars、ウェアハウスのSQL UI、Spyder、RStudioなどを使用できる
• ノートブックはMarkdown、コード、SQLのようなセルを1つのファイルに結合し、画像、インタラクティブなチャート、テーブル出力をコードの横に配置する
  • 実行結果を見ながら段階的に探索し、結果を発表するのに適している
  • Jupyter、Google Colab、Deepnote、marimoが代表的
  • DatabricksやSnowflakeのようなプラットフォームも独自のノートブックを提供する

機械学習におけるデータ消費

• MLは特徴量ストア、学習、追跡、デプロイツールを備えた別領域だが、データの主要な消費先である
• LLM以外にも、解約予測、レコメンド、需要予測、顧客セグメンテーションのような専門モデルがあり、本番投入前に整備された学習データが必要である
• Data scientistやML engineerは、直近30日の注文数、最終ログインからの経過日数といった特徴量（feature）をウェアハウスから取得し、モデルを学習・デプロイする
• 予測結果は、CRMの解約スコアのようなオペレーショナル分析や、ユーザー向けの製品レコメンドへと再びつながる

組み込み分析

• 組み込み分析は、マーケットプレイスの販売者に人気商品、顧客地域、検索順位のような分析をアプリケーション内で提供する
• 事前定義されたチャート5つと限定的なフィルター程度であれば、クエリ、UI、チャートライブラリを自前で実装できる
• ユーザーが複雑な問い合わせを行う必要があるなら、Metabase、Looker、TableauのようなBIツールや、Sisense、Luzmoのような埋め込み中心の製品を使用できる
• ホストアプリケーションは認証・認可を担当し、組み込みツールは問い合わせUIとチャートレンダリングを処理する

データそのものを商品として販売する

• データは機能の材料を超えて、製品そのものになり得る
• 複数の暗号資産ブロックチェーンのデータを収集・変換・インデックス化してアナリストにアクセス権を販売したり、Google検索結果を収集してSEO専門家に販売したりできる
• データとクエリアクセス権を販売するには、適時に収集する堅牢なパイプラインと高性能なクエリ機能が必要である

データガバナンス

• データガバナンスは、個人識別情報、健康情報などの機微データに誰がアクセスできるかと、そのアクセス記録を管理する
• データ所有権、忘れられる権利のような個人情報の取り扱い、物理的な保存場所、保存期間も含む
• ウェアハウスのロール・アクセス制御、カタログの所有権情報、リネージによるPII利用追跡のような技術が支援できる
• 技術だけの問題ではなく、人とプロセスの比重が大きく、法務・コンプライアンス・セキュリティ組織と密接に結び付いている
• データ環境全体は、ソースから収集し、保存・処理して活用する流れとして捉えられ、各カテゴリの下にはさらに多くのツールと詳細な選択肢が生まれ続けている