データ分析サービスの各論

1. Amazon OpenSearch Service

ログ分析、リアルタイムのアプリケーションモニタリング、クリックストリーム分析などのユースケース向けの、完全なオープンソースの検索および分析エンジン
Apache Lucene検索ライブラリを搭載

1.1. アーキテクチャ

データ階層として、インデックス(RDBのテーブルの概念)とその中にシャード(RDBでのパーティションの概念)が存在する。
インデックス単位でシャード数、レプリカ数を設定。

参考

1.2. AWSサービス間の連携

1.2.1. データロードにおける連携

※ 図中のアスタは参考リンクのナンバリングと対応。

考察

公式のベストプラクティスを参照すると、1ドキュメントのリクエストを複数回投げるよりも複数回まとめてBulk APIで投げる方がいい旨の記載がある。
リファレンスアーキテクチャ(2022/11時点)でも以下のようにBulk APIを叩く構成が示されている。
一方で、リアルタイム性を求める場合、Bulk APIを大量に叩くとスロットリングが発生してしまう(*8)。
参照先の記事ではLambdaで頑張り、エラー時はFirehoseに流している。
Firehoseに1分などデータを蓄積して反映させるニアリアルタイム性で問題ないのであれば初めかFirehoseに流すことが管理面でも良さそう。

▲ AWSリファレンスアーキテクチャより転載

■ リファアーキの読み解き
CloudTrailやVPCフローログ、CloudWatchのログをOpenSeaechで検索できるようにするアーキテクチャ。

CloudTrailやVPCフローログは5min毎[^1]にS3バケットにログを転送する。
S3のイベントをトリガしてSQSにメッセージを送る。
SQSエンキューをトリガにLambda関数を実行する。
Lambda関数でBulk APIでOpenSearchへデータ一括投入する。
ダッシュボード上でデータを閲覧/検索する。

参考

https://tech.connehito.com/entry/2021/12/07/174254
https://docs.aws.amazon.com/ja_jp/dms/latest/userguide/CHAP_Introduction.Sources.html
https://docs.aws.amazon.com/ja_jp/dms/latest/userguide/CHAP_Task.CDC.html
https://aws.amazon.com/jp/blogs/news/amazon-dynamodb-zero-etl-integration-with-amazon-opensearch-service-is-now-generally-available/
https://pages.awscloud.com/rs/112-TZM-766/images/AWS-Black-Belt_2023_Amazon-OpenSearch-Service-Advanced-Search_0131_v1.pdf
https://medium.com/levi-niners-crafts/syncing-data-from-documentdb-to-opensearch-using-change-streams-61753fe77d6e
https://dev.classmethod.jp/articles/reinvent2020-emb019-deep-dive-on-aws-glue-elastic-views/
https://www.wantedly.com/companies/company_7005547/post_articles/870209
https://aws.amazon.com/jp/about-aws/whats-new/2022/09/amazon-vpc-flow-logs-delivered-amazon-kinesis-firehose/
https://buildersbox.corp-sansan.com/entry/2022/06/14/110000
https://www.estie.jp/blog/entry/2023/03/03/114001
https://d1.awsstatic.com/architecture-diagrams/ArchitectureDiagrams/centralized-log-analytics-ra.pdf?did=wp_card&trk=wp_card
https://aws.amazon.com/jp/about-aws/whats-new/2020/12/announcing-aws-glue-elastic-view-preview/?nc1=h_ls
https://docs.aws.amazon.com/ja_jp/dms/latest/userguide/CHAP_Source.DocumentDB.html#CHAP_Source.DocumentDB.ConfigureCDC
https://aws.amazon.com/jp/about-aws/whats-new/2023/11/amazon-opensearch-zero-etl-integration-s3-preview/
https://aws.amazon.com/jp/blogs/news/cloudfront-realtime-dashboard/
https://dev.classmethod.jp/articles/amazon-opensearch-ingestion-announce/
https://docs.aws.amazon.com/ja_jp/opensearch-service/latest/developerguide/configure-client-s3.html
https://docs.aws.amazon.com/ja_jp/opensearch-service/latest/developerguide/bp.html
https://aws.amazon.com/jp/blogs/aws/new-logstash-plugin-search-dynamodb-content-using-elasticsearch/

2. Amazon CloudSearch

全文検索用のマネージドサービス。
内部ではSolrが稼働するインスタンスを立てている。
LuceneはJavaで書かれた検索エンジン・ライブラリであり、SolrはLuceneを使って作成された検索エンジン・サーバ。
RDSのLike検索で対応できない理由は以下。
- Like検索ではインデックスが効かないため負荷が大きい。
- データ量の増加と共にクエリが重くなる。
- 語彙が考慮されないため表記揺れをまとめて検索できない。
形態素解析(京都vs東京都)やサジェスト(半分くらいまで入力すると補完した候補が出るアレ)機能を利用できる。

2.1. アーキテクチャ

ドメイン作成時にインデックスフィールドを定義する(※ コンソールではサンプルをアップロードすると自動で解析してくれるので手直しするだけでOK)。
検索対象のデータを直接CloudSearchに格納しクエリを投げるのではない。データ本体はRDSやDynamoDB、S3などに置かれており検索のためのインデックスフィールドにキーワードをマッピングした情報をJSONやXMLでCloudSearchに渡す。

クエリパーサの種類は以下。

パーサ	説明
Simple	ベーシックなマッチング
Structured	複雑なboolean検索や重み付けなど対応
Lucene	CloudSearchではパフォーマンスは保証されていない。曖昧検索、正規表現など対応。
Dismax	Luceneを補うためにSolrで開発。単語の出現位置の考慮など対応。

■ 用語整理

全文検索

複数の文書（ファイル）から特定の文字列を検索すること。「ファイル名検索」や「単一ファイル内の文字列検索」と異なり、「複数文書にまたがって、文書に含まれる全文を対象とした検索」という意味で使用される。

パーサ

コンピュータプログラムのソースコードやXML文書など、何らかの言語で記述された構造的な文字データを解析し、プログラムで扱えるようなデータ構造の集合体に変換するプログラムのこと。そのような処理のことを「構文解析」「パース」（parse）という。

参考

2.2. AWSサービス間の連携

2.2.1. データロード/検索における連携

※ 図中のアスタは参考リンクのナンバリングと対応。

考察

CloudSearchを利用したアーキテクチャは検索してもあまり出てこない印象。
OpenSearchほどカスタマイズ性が高くなく、データ連携の手法も限られている(DBと直接連携する機能は提供されていない)ため何かしらのコンピュートリソースからAPI経由でインデクシングする構成しかないものと思われる。
なお、CloudSearchのインデクシングは時間を要することからDBの更新とCloudSearchのインデクシングを同期的に実行するのは微妙。キューやS3に差分を放り込み非同期で処理する方法が望ましい。

参考

3. AWS Glue Elastic Views (提供終了)

コードを書かずに複数のデータストア間でデータを結合して複製するためのマテリアライズド・ビューを簡単に構築できる。

Update 7/26/2023: Glue Elastic Views is no longer available as of April 2022.

3.1. アーキテクチャ

PartiQLによりビューの定義を行う。

■ 用語整理

PartiQL

ドキュメント指向のデータモデルへのSQL準拠のアクセスをサポートする新しいオープン標準のクエリ言語

ドキュメント指向データベースに対してクエリを投げる際にSQLと同様のインターフェースを提供してくれているものと理解。

3.2. AWSサービス間の連携

3.2.1. データ連携

従来(?)Glue Elastic Viewsでできたデータ連携部分について連携方法を考察する。

※ 図中のアスタは参考リンクのナンバリングと対応。

考察

OpenSearch、RedShiftへのデータ連携はゼロETL統合が広くサポートされていることを踏まえるとGlue EVはゼロETL統合に取って代わったように伺える。

参考

4. AWS Glue

Apache SparkというOSSの並列分散処理フレームワークのフルマネージドサービスであり、分析用データのETL(Extract/Transform/Load)処理を行う。
EMRではインスタンスの管理などは利用者側で実施する必要がある一方、Glueはそれらが不要で必要なタイミングでのみ実行できる。
ETLの処理単位をジョブと言い、Apache Spark(PySpark/Scala)かPython Shellを利用可能。
Glueの自動生成するコードや自身のスクリプトをジョブとして実行可能。
種々のデータソースのスキーマを推論・作成し、メタデータをカタログとして管理し、ジョブ実行時に参照する。
ETL処理の歴史的背景
- 昔はデータはRDBやCSVファイルに保存され、いずれも構造化されており、それらを処理して分析していた。
- 現在では大量のデータかつ非構造化データも含めた分析が必要とされるようになったことで従来に分析では対応できなくなった。
- 収集した生データを保存する先としてデータレイクという概念が生まれ、データレイクの生データを分析する前処理としてETL処理を行う手法が取られた。
Glue StudioではETLジョブを定義するビジュアルエディタを提供する他、パフォーマンスチェックも可能。

■ 用語整理

ETL(Extract/Transform/Load)処理
- Extract : ERPやDB、CSVファイルなどに散在するデータを集約し、分析に必要なデータのみに抽出する処理。
- Transform : DWHにて分析しやすいデータ形式に変換する処理。
- Load : 加工したデータをDWHに取り込む処理。
スキーマ
- 概念スキーマ、外部スキーマ、内部スキーマの3層で構成され、DBの操作方法やデータの物理的な格納方法などを定義したDBの設計図。

■ ETL処理の使い分け

▲ BlackBeltより転載

■ EMRとの使い分け

AWS Glue は Apache Spark 環境で動作させることができ、データ変換ジョブのスケールアウト実行環境が提供されます。AWS Glue では ETL ジョブの推測、展開、モニタリングが行われ、ジョブの作成とメンテナンスのプロセスが大幅に簡略化されます。Amazon EMR では Hadoop 環境に直接アクセスでき、下位レベルへのアクセスや、Spark 以外のツールを使用できる柔軟性が向上します。

参考

4.1 アーキテクチャ

内部ではEMRが動きSparkクラスタを構築せずジョブが実行できる。

クローラ

cronやイベントトリガでデータソースにアクセスしデータ抽出を行う。
分類子(Classifier)を参照してデータソースのスキーマを推論・作成する。
データソースを全てクロールするか差分のみをクロールするかを選択可能。

分類子

「データソースに投げ込まれるファイルはこういうファイルだよ」を定義しておくものと理解した。
分類子にはあらかじめ用意された組み込み分類子(JSONやCSVなど)と独自に定義するカスタム分類子が存在する。

データカタログ

クローラの抽出したデータのメタデータ(DBやテーブル、パーティションの情報)の出力先。
データカタログのメタデータはS3に保存される。なお、データの実体をカタログが持つわけではなく「データの実体がどこにあるか」などのメタデータのみが保持される。
Apache Hiveメタストア互換であり、EMRから参照可能。
クローラを利用せずAPIを介して直接テーブル定義を登録することも可能。

参考

4.2. AWSサービス間の連携

4.2.1. ネットワーク

▲BlackBeltより転載

参考

4.2.2. 分析実行における連携

※ 図中のアスタは参考リンクのナンバリングと対応。

考察

基本的にログ分析の場合はS3にデータを流してGlueにかけると理解。
IoT系のストリーミングデータはストリームETLジョブによりGlueに投げらる。以前は間にFirehoseもしくはLambda+FirehoseやKinesis Data Analytics (Amazon Managed Service for Apache Flink)で処理して投げる必要があった。

Glueジョブの各実行元の使い分けとしては以下(*2)。

ジョブ実行の契機が数個程度。 → トリガ (ただし基本的には拡張性を考慮するとワークフローの方がいい?)
複数のジョブ実行がある。 → ワークフロー
Glue以外のリソースへのアクセス/処理実行が挟まる → SFn
なお、現在ではSFnとGlueが統合しているためLambda関数を挟まずに直接実行も可能。

なおS3→Glueのような表現がたまにあったが実際公式ドキュメントのS3イベントの送信先を確認するとGlueはなかった。おそらく何かしら(上の絵だとSQSやEventBridge)を経由していると思われる。実際以下のリファレンスアーキテクチャ(2022/11時点)を見るとS3トリガでEventBridgeを介してGlueジョブを実行している。ここのSQSとの使い分けはイベントを複数の処理に繋げたいかどうかなのだろうか？

▲ AWSリファレンスアーキテクチャより転載

■ リファアーキの読み解き

工場内に設置したMonitronセンサーとゲートウェイからKinesis Data Streamsへデータを転送。
Firehoseを介してデータレイクであるS3へ転送。
S3イベントをEventBridgeへ通知。
Lambdaを起動してIoT EventsへS3イベントを渡し、警告をERPへ。
同じくIoT EventsからSNSトピックを介してスタッフに通知。
EventBridgeからGlueジョブを実行し、S3のデータを処理。その後AthenaがS3データへクエリする。
Grafanaで可視化する。

参考

5. AWS Clean Rooms

複数のAWSアカウント間でデータの実体をコピーすることなくセキュアに共有する。
現状、プライバシーの観点やセキュリティの観点から、個人情報のマスキングやデータ移動に制限があるなどデータコラボレーションが進みにくい。
Clean Roomsでは生データをコピーやDB自体の共有を行わずにパートナーとデータ共有を行う方法を提供する。

5.1. アーキテクチャ

参考

5.2. AWSサービス間の連携

※ 図中のアスタは参考リンクのナンバリングと対応。

考察

メンバーアカウントのうち1つしかクエリ実行できないとするとそんな一方的なデータ提供をしてくれるものなの？と思っていたがBlackBeltで実際のユースケースとしてグループ企業間でのデータ連携や業務提携として相互に共有する使い方が示されていた。
なお、2023/6時点のリファアーキとして以下が示されている。個人的にはNeptuneに投げ込むところがCleanRoomsの用途として一番示唆を与えてくれてる感じがした。クロスデバイスユーザデータや世帯データなど本来関連するデータがアカウントや企業に跨って点在し、制約上データを移動できないケースは実際ありそうで、かつそれらを紐づけることで導ける予測がある気がする。

▲ AWSリファレンスアーキテクチャより転載

■ リファアーキの読み解き

Pinpointで収集したユーザの行動データをFirehose経由でS3に流す。
Glueでデータカタログを構成し、CleanRoomsにて外部の共有データと連携する。
3-party側でCleanRoomsのメンバーシップの招待を承諾する。
CleanRoomsでクエリを実行する。
クエリの結果をS3に出力する。
クロスデバイスユーザデータや世帯データをNeptuneにロードする。
QuickSightで可視化する。
SageMakerでMLモデルを生成する。
SageMakerの予測結果をPinpointにフィードバックする。

参考

6. AWS Glue DataBrew

従来、データ分析や機械学習を行う場合、データのクリーニングや正規化を行う必要がある。データアナリスト/サイエンティストが細かなETL処理のコードを書くことなくそれらの前処理を行えるようにするためのビジュアルデータ準備ツールとしての位置付け。
入力ファイルはcsvやjson、xslxなどのファイルをサポートし、ファイルフォーマットを拡張子で自動判別。

■ Glue Studioとの使い分け

AWS Glue DataBrewもAWS Glue Studioもビジュアルでデータ処理のジョブを作成しますが、AWS Glue DataBrewはデータのプレビュー機能やサマリーが表示されたりとデータの中身がわかりやすいです。一方でAWS Glue StudioはETLジョブ作成ツールというだけあってデータソースやターゲットがビジュアルでわかりやすい作りになっています。対象ユーザーを考えるとAWS Glue DataBrewは非エンジニアでも使いやすいツールだと言えます。

6.1. アーキテクチャ

参考

6.2. AWSサービス間の連携

※ 図中のアスタは参考リンクのナンバリングと対応。

考察

分析対象のデータのパターンによって以下に集約されると考える。

AWS内にあるデータ → S3/Glueデータカタログでつなぐ
オンプレ環境にあるデータ → 閉域網を通りてJDBC接続/Glueデータカタログでつなぐ
外部のSaaSにあるデータ → AppFlowを通してS3に連携してつなぐ
外部のCSP(クラウドサービスプロバイダ)にあるデータ → S3に連携してつなぐ

結局、下のリファアーキでも示されるように少し込み入った処理をしたり他サービスとの連携、通知あたりを考えるようになるとSFnでフロー化することになるが、 責務分担の観点 では良いなと思った。
以前SFn+Lambda/ECSでデータ分析のフローを書くサービスを作っていたころ、データチームが書いたコードをzipでもらってLambdaに乗せる開発体制をとっており、結合テストでつらい思いをしたことがある。データチームはDataBrewの中を責務に、そこを呼び出し周辺環境を支えるのは開発チームとして責務を切ることでエラーのデバッグに両チームが呼び出される自体は避けられそう。

▲AWSソリューションライブラリより転載

参考

7. Amazon EMR

HadoopなどのOSSの分析フレームワークを用いてビッグデータの分析を行うネージドな環境を提供する。

近年、大量で多種多様のデータを用いてマーケティングなどに利用するビッグデータを利用するデータ分析のニーズが高まってきた。従来一般的だった、データを単一のサーバに蓄積し、クエリを投げて取得する方法では処理時間に限界が来た。そこで複数のサーバをクラスタ構成を取り、並列計算させる方法が考えられた。
単に並列に増やしてもサーバの障害に弱くスケーラビリティに欠ける。それらを考慮したものがHadoopなどの分散処理のフレームワークである。

■ Hadoopとは
Hadoopは分散ファイルシステムHDFSと計算処理を担う分散処理フレームワークHadoop MapReduceによって支えられる。

HDFS
HDFSはマスターノードであるNameNodeとスレーブノードであるDataNodeで構成され、NameNodeはメタ情報を保持し、データの実体はDataNodeに保持される。全てのファイルは最低3ノードにレプリケートされ、冗長構成を持ったファイルシステムとなっている。

Hadoop MapReduce
HadoopではマスターノードであるJobTrackerとスレーブノードであるTaskTrackerで構成される。JobTrackerは司令塔として各ノードのTAskTrackerにタスクを割り当てる。
なお、この処理はHadoop2系では分散リソース制御機構Hadoop YARNとMapReduce ApplicationMasterの2つに分離され、より多くのクラスタを構成可能となった。

Mapタスク : HDFSの生データをの処理に基づきキーバリュー形式にデータを抽出する。
Reduceタスク : 各ノードでMapタスクによってキーバリュー形式に意味付けされたデータを統合し集計する。

■ MapReduceとSpark

MapReduceでは多段階のジョブ実行の際に処理間のデータの受け渡しに何度もHDFSとの間にIOが発生し非効率なケースがあったり、同一のデータを複数ジョブを並列で回す際に何度も同じデータの読み出しが発生する。こうした繰り返し処理の効率化を行うために、HDFSに特殊なキャッシュを設け、インメモリで高速な分散処理を行うことを考えたのがSpark。

Spark は、同じデータを何度も繰り返す反復計算では優位に立ちますが、データ変換やデータ統合など、１回で終わる ETL のようなジョブに関しては、まさに MapReduce が得意とするところです。
結論：Sparkは、特に専用クラスタ上で、データが全てメモリに収まる場合に優れた性能を発揮し、Hadoop MapReduce は、メモリに収まらないデータに適しており、他のサービスと並行した実行が可能。

■ YARN

計算リソースを一元管理する。クライアントからの計算リソース要求に応じて、どのスレーブでリソースを確保するかをスケジューリングする。

■ Hive
Hadoop上に構築されたDWHで非構造化データの大規模なプールに対してクエリ実行可能(HiveQL)。

■ HBase
HDFS上に構築された列指向分散データベース。NoSQLキー/バリューストア。

7.1. アーキテクチャ

参考

7.2. AWSサービス間の連携

※ 図中のアスタは参考リンクのナンバリングと対応。

参考

8. Amazon Kineis

ストリーミング処理向けのスケーラブルなキュー。
内部的にキューのようなものを持ち、メッセージをバッファしてデーアコンシューマ側に送る/取りに来てもらう構成を取る一連のサービス群。

■ Kinesis Data StreamsとFirehoseの使い分け

Firehoseは中でバッファリングしてからある程度のまとまりを配信するpush型配信。そのため一定の遅延が生じるニアリアルタイムな構成になる。
Streamsはpull型で内部でデータを溜めないのでリアルタイム要件にはこちら。

なお、先日Firehoseでバッファせず配信することが可能となり、Firehoseでもリアルタイムで流すこと自体は可能になった。

8.1. アーキテクチャ

参考

8.2. AWSサービス間の連携

※ 図中のアスタは参考リンクのナンバリングと対応。

参考

9. Amazon Managed Streaming for Apache Kafka

Apache Kafkaのマネージドサービス。
kafkaについては以下。Kinesis Data Streamsと基本的には同じ。
現行kafkaを使用していてクラウドにリフト&シフトを想定するのであればMSKでいいが、これから開発するような場合ではKinesisを選択するべき。

▲DevAx connect資料より転載

参考

https://pages.awscloud.com/rs/112-TZM-766/images/20191120_AWS-BlackBelt_AmazonMSK.pdf

10. Amazon Managed Service for Apache Flink

Kinesis Data Analyticsの後継。
Kinesis Data AnalyticsにはSQLアプリケーション向けとFlink向けアプリケーションとがあったが、後者に統一されたのだろうか？まだ記事が少なすぎてこの辺不明確。

当初FirehoseにLambda関数噛ませるとかじゃだめなの？と思ってたが、以下の記事で納得した。
Lambdaはステートレス故に直前のデータに依存した結果を返すような処理苦手である。そのため直前のデータをどこか外部のストレージで保持しようにも遅延の観点でストリミーング処理と相性が悪い(それが許容できるならもちろんOK)。Data Analytics (現MSF)はWINDOWクエリのように特定の期間のストリーミングデータを参照するクエリをもち、区間のデータに対する分析が可能となる。

10.1. アーキテクチャ

参考

10.2. AWSサービス間の連携

※ 図中のアスタは参考リンクのナンバリングと対応。

参考

11. Lake Formation

従来、データ分析環境を作ろうとするとデータレイクとしてのS３とGlueのカタログやジョブ、ワークフローの作成、分析のためのAthena、権限管理のためのIAMを全て自前で用意する必要があった。これらの環境のセットアップをいい感じにやってくれるのがLake Formation。そのほかアカウントを跨いで存在するS3データへのアクセスを1つに集約するため内部でGlueデータカタログを連携する機構を持っている。(LF-tag以外にもRAMを利用して共有する方法もある。)

11.1. アーキテクチャ

実体としてはS3とGlue。
データレイクは実質S3。
ブループリントとして予め用意された数パターン(接続先がDBかログか)のワークフローを作成可能。編集は不可。
IAMよりもきめ細やかなデータレイクに対するアクセス制御を提供。

参考

12. Amazon FinSpace

金融業界向けに分析基盤を提供する。
動きを見るとおそらくFinSpaceの環境を1つ立ち上げると裏で認証認可のためのCognitoやら分析のためのGlueやSageMakerの環境が構成されるものと予想。
金融の知見がないので中身はよくわからんが株式(Equity)の利回り(Treasury Spread)等のデータ分析の実施に利用される(?)。

参考

13. AWS Data Exchange

データ版のMarketplace。
Data Exchangeで無償もしくは有償で公開される3partyのデータセットをサブスクライブすることでシームレスに分析データを入手できる。逆にAWSに認定を受けることでプロバイダとしてデータを提供/販売することも可能。
S3やRedShift、Lake Formation向けに統合されたデータセットがあり、データをエクスポート/コピーして自身のアカウントに移動することなく分析を開始できる。(Data Exchange For 〇〇)
AWS Marketplaceと統合している。
AWS Data Exchange for APIsにより、APIとしても提供/公開できるようになった。AWS SDKを介してRESTful/GraphQLを利用してデータセットにアクセス可能。データ全体を取得するのではなく特定のデータを取得したい/クエリしたい場合に有用。

参考

13.1. アーキテクチャ

参考

14. Amazon RedShift

スキーマオンライトモデルのDWH。予めスキーマを定義しておきSQLを介してデータを投入する。
列指向DBであり集計に強い。SQLベースなので非構造化データにはEMRを使う。

参考

14.1. アーキテクチャ

参考

https://pages.awscloud.com/rs/112-TZM-766/images/AWS-Black-Belt_2023_Amazon-Redshift-Overview_v1.pdf

14.2. AWSサービス間の連携

※ 図中のアスタは参考リンクのナンバリングと対応。

15. Amazon Athena

データレイクに対するスキーマオンリードモデルの分析サービス。
アドホックなデータ分析ツールであり、大規模データの分析や複雑なデータの分析には不向き。

参考

15.1. AWSサービス間の連携

※ 図中のアスタは参考リンクのナンバリングと対応。

参考

16. Amazon QuickSight

BIツール
独自の権限管理下でユーザやグループを管理する。
ある程度のカスタマイズは効くが限界はある。ユーザ単位での課金なので外部向けに出すには微妙。

16.1. アーキテクチャ

Viewだと分析にアクセスするたびに内部でクエリ実行してデータソースからデータ取得が発生する。テーブルとして持つことで予め計算済みの状態になる。

参考

https://docs.aws.amazon.com/ja_jp/quicksight/latest/user/supported-data-sources.html

17. Amazon DataZone

組織の複数のプロジェクト間で散在するデータを管理、活用するためのサービス。
AWSコンソールとは別でコンソール画面を持ち、データへのアクセス権の細かな設定やAthenaやRedShiftのクエリエディタでのシームレスなデータ分析を提供する。
ビジネスカタログとしてGlueデータカタログよりも自由度の高くデータをカタログ化。

参考

https://www.zead.co.jp/column/aws-amazondatazone/

18. AWS Entity Resolution

種々のデータストアに散在しサイロ化したデータから関連するレコードを検索しデータの関連性の示唆を与えるサービス。
Glueデータカタログを読み取りレコードの関連性はルールベースまたはMLベースのマッチングを用いて判断される。
データソースはS3

参考

https://www.sunnycloud.jp/column/20230728-01/amp/

19. AWS Data Pipeline

19.1. AWSサービス間の連携

現在はメンテナンスモードとなり、マネコンからアクセス不可。GlueやMWAAへの移行が推奨されている。FAQにアクセスしてもGlueに飛ばされるあたりメッセージを感じる。
マネージド型のコンテナオーケストレーションサービス。
DynamoDB、RDS、Redshift、S3をデータソースとして、自身の環境に構築するEC2やEMRでETL処理を実施できる。
スケジュール実行をサポート

参考