Más contenido relacionado La actualidad más candente (20) Similar a AWSで作る分析基盤 (20) AWSで作る分析基盤11. データレイクを基軸とした分析基盤の論理
アーキテクチャ
Raw Data Pond
Middle Layer Pond
Active Data Pond Data
Warehouse
Data
Mart
Data
Mart
Machine
Learning
収集元
蓄積(データレイク)
分析 可視化
ETL
Message
Queue
Pub/sub
Message
Realtime
SQL
Batch
(FTP..)
Data
Mart
BI
Report
Files
MapReduce
D
a
t
a
C
a
t
a
l
o
g
s
Data
Mart
33. データレイクを基軸とした分析基盤の論理
アーキテクチャ
Raw Data Pond
Middle Layer Pond
Active Data Pond Data
Warehouse
Data
Mart
Data
Mart
Machine
Learning
収集元
蓄積(データレイク)
分析 可視化
ETL
Message
Queue
Pub/sub
Message
Realtime
SQL
Batch
(FTP..)
Data
Mart
BI
Report
Files
MapReduce
D
a
t
a
C
a
t
a
l
o
g
s
Data
Mart
40. S3 Select
S3 Select を使えばCSV, JSON, Parquetファイルの中身に対して直接データを抽出できます。
扱いやすいデータ構造までETLが済んだファイルであればS3 Selectを使ってデータレイクが
作りきれます。
48. 組み込みされている分類子
分類子タイプ 分類文字列
Apache Avro avro
Apache ORC orc
Apache Parquet parquet
JSON json
バイナリ JSON bson
XML xml
Amazon Ion ion
Combined Apache ログ combined_apache
Apache ログ apache
Linux カーネルログ linux_kernel
Microsoft ログ microsoft_log
Ruby ログ ruby_logger
Squid 3.x ログ squid
Redis 監視ログ redismonlog
Redis ログ redislog
CSV csv
Amazon Redshift redshift
MySQL mysql
PostgreSQL postgresql
Oracle データベース oracle
Microsoft SQL Server sqlserver
Amazon DynamoDB dynamodb
カスタム分類子を使えば
Grokフィルタパターンが
使える
53. データレイクを基軸とした分析基盤の論理
アーキテクチャ
Raw Data Pond
Middle Layer Pond
Active Data Pond Data
Warehouse
Data
Mart
Data
Mart
Machine
Learning
収集元
蓄積(データレイク)
分析 可視化
ETL
Message
Queue
Pub/sub
Message
Realtime
SQL
Batch
(FTP..)
Data
Mart
BI
Report
Files
MapReduce
D
a
t
a
C
a
t
a
l
o
g
s
Data
Mart
58. Athenaとは?
Amazon Athena は、標準 SQL を使用して Amazon Simple Storage Service (Amazon S3) での
データの直接分析を簡易化するインタラクティブなクエリサービスです。
AWS マネジメントコンソールでいくつかアクションを実行するだけで、Athena にデータの保存先
の Amazon S3 を設定し、標準 SQL を使用してアドホッククエリの実行を開始できます。結果は
数秒で返ります。
Athena はサーバーレスであるため、インフラストラクチャの設定や管理は不要です。
また、実行したクエリにのみ課金されます。
Athena は自動的にスケールして—クエリを並列実行する—ため大規模なデータセットや複雑
なクエリでも結果がすぐに返ります。
(公式Docより)
59. S3のデータに対してテーブル定義
CREATE EXTERNAL TABLE IF NOT EXISTS cloudfront_logs (
`Date` Date,
Time STRING,
Location STRING,
Bytes INT,
RequestIP STRING,
Method STRING,
Host STRING,
Uri STRING,
Status INT,
Referrer STRING,
OS String,
Browser String,
BrowserVersion String
) ROW FORMAT SERDE 'org.apache.hadoop.hive.serde2.RegexSerDe'
WITH SERDEPROPERTIES (
"input.regex" =
"^(?!#)([^ ]+)s+([^ ]+)s+([^ ]+)s+([^ ]+)s+([^ ]+)s+([^ ]+)s+([^ ]+)s+([^ ]+)s+
([^ ]+)s+([^ ]+)s+[^(]+[(]([^;]+).*%20([^/]+)[/](.*)$"
) LOCATION 's3://athena-examples/cloudfront/plaintext/';
S3に入っているデータに対してSQLを投げるには、まずテーブル定義が必要です。
Hive DDLに基づいて、外部テーブルを作成します。(CREATE EXTERNAL TABLE文)
上記のようにカラム名と型を宣言し、LOCATION 節で S3の場所を指定します。
また、SerDe (シリアライザー/デシリアライザー) を指定することで様々な形式のファイルに
対応することができます。
78. Amazon Kinesis Data Analytics
Amazon Kinesis Data Analytics は、新しいプログラミング言語や処理フレームワークを習得する
ことなく、標準 SQL でストリーミングデータをリアルタイムで処理できる最も簡単な方法です。
Amazon Kinesis Data Analytics を使用すると、SQL を使用してストリーミングデータのクエリやス
トリーミングアプリケーション全体の構築を行うことができます。これにより、実用的なインサイト
を得て、ビジネスやお客様のニーズにすばやく対応することができます。
(公式Docより)
79. 特徴
Amazon Kinesis Data Analytics は、Kinesisの中を流れるデータに対してSQLを実行し、
結果をストリーミングデスティネーションに出力します。(Kinesis Stream or Kinesis Firehose)
フィルタや文字列操作など前処理に利用されることが多いですが、工夫すると指定したウィンド
ウ内で異常値をプロットする異常値検出にも利用できます
82. EMRとは?
Amazon EMR では、管理された Hadoop フレームワークが提供され、動的にスケーリング可能
な Amazon EC2 インスタンスで、大量のデータを、簡単、高速、高コスト効率な方法で処理でき
ます。また、Apache Spark や HBase、Presto、Flink といった他の一般的なフレームワークを
Amazon EMR で実行することや、Amazon S3 や Amazon DynamoDB といった他の AWS データ
ストア内でデータを操作することもできます。
(公式 Doc)
91. AWS Batchとは?
AWS Batch は、従来のバッチコンピューティングソフトウェアと同様に、必要なインフラストラク
チャの設定および管理に伴う、差別化につながらない力仕事を排除します。このサービスでは、
送信されたジョブに応じてリソースを効率的にプロビジョニングし、キャパシティー制限の排除、
コンピューティングコストの削減、および結果の迅速な提供を行うことができます。
(公式 Doc)
96. データレイクを基軸とした分析基盤の論理
アーキテクチャ
Raw Data Pond
Middle Layer Pond
Active Data Pond Data
Warehouse
Data
Mart
Data
Mart
Machine
Learning
収集元
蓄積(データレイク)
分析 可視化
ETL
Message
Queue
Pub/sub
Message
Realtime
SQL
Batch
(FTP..)
Data
Mart
BI
Report
Files
MapReduce
D
a
t
a
C
a
t
a
l
o
g
s
Data
Mart
108. Elasticsearch Serviceとは?
Amazon Elasticsearch Service はダウンタイムなしで、Elasticsearch を大規模かつ簡単にデプロ
イ、保護、運用する完全マネージド型サービスです。
このサービスは、オープンソースの Elasticsearch API、マネージド Kibana を提供するほか、
Logstash およびその他の AWS のサービスとの統合で、いかなるソースからもデータを安全に
取り込み、リアルタイムに検索、分析、可視化できます。
Amazon Elasticsearch Service は従量課金制です。前払い費用や最低料金はありません。
Amazon Elasticsearch Service では、必要なだけの ELK スタックをランニングコストなしで入手で
きます。 (公式 Doc)
116. Elastic Beanstalkとは?
Elastic Beanstalk では、アプリケーションを実行しているインフラストラクチャについて学習する
ことなく、AWS クラウドでアプリケーションをすばやくデプロイし、管理できます。Elastic
Beanstalk は、選択肢を狭めたり制御を制限したりすることなく、管理の複雑さを軽減します。ア
プリケーションをアップロードするだけで、Elastic Beanstalk が自動的に容量のプロビジョニング、
負荷分散、拡張、およびアプリケーションの状態のモニタリングといった詳細を処理します。
(公式 Doc)
Notas del editor データレイクの特徴
2010年代になると、データレイクが台頭してきました。データウェアハウスでも非構造化データを蓄積・処理できますが、最も効率的な方法ではありません。ビッグデータと呼ばれる、非常に多くの種類・量のデータがあると、すべてをデータウェアハウスに格納した場合、多大な費用が発生する可能性があるからです。さらに、時間と労力の制約があります。データウェアハウスに格納されるデータは、格納前にテーブルレイアウトに合うようにクレンジングする必要があります。(注1)多種多様なデータをETLするコストは膨大になってしまいます。それが、データレイクが人気を博した最大の理由です。データレイクは、主に非構造化データを最も費用対効果の高い方法で処理できます。非構造化データとは、単に構造化されていない業務データではなく、テキストやソーシャルメディア、IoTデバイスのログファイルやセンサー、マシンデータまで、あらゆるデータを対象とします。
ここでデータレイクの例を見てみましょう。先ほどのDWHで使用した小売チェーンの例に戻って、考えてみます。DWHでは、顧客がどのような商品を買ったのかという事実に基づいた分析が可能ですが、入店したが買わなかったことや将来どのようなものを購入するかの予測を行うことは難しいです。そこで、データレイクに様々なデータを蓄積することが有効になります。例えば、Webチャネルと実来店を紐づけたり、顧客のSNSデータを取り込むことでより精度の高いオファーをすることが可能かもしれません。さらに、天気や気温などの外部情報を取り込むことで、仕入れの最適化も考えられます。データレイクはデータウェアハウスのデータをより価値のあるものに高めてくれます。
注1:データレイクを持っていても、クレンジングが不要になるわけではありません。あくまでも格納時にスキーマレスであり、活用に向けたクレンジングは必要になります。しかしながら、Sparkを代表とする分散処理技術との相性の良さから、クレンジング処理を行う基盤としてもデータレイクは有効です。
データウェアハウスの特徴
1950年代に最初のデータベースが登場し、1980年代に現在のスタンダードであるリレーショナルデータベースが普及しました。データベースはリアルタイムの構造化データを更新する、つまりOLTP用途で利用されます。ビジネスが成長するにつれ、複数の場所や業態からデータが発生するようになり、すべてを分析するためには、それらを集約した場所が必要でした。それがデータウェアハウスです。
例えば、あなたは小売チェーン店の会員カードに入会しているかもしれませんが、データウェアハウスは、現在の買い物客の傾向を分析する目的において、あなたの購入記録を保持しているかもしれません。データウェアハウスは、購入したすべてのアイテムの記録を保持し、最適化されるためデータ分析者はより簡単に分析することができます。
スキーマオンリード(Schema on Read) vs スキーマオンライト(Schema on Write) — データウェアハウスのスキーマは、格納の前に定義され、構造化されています(スキーマはデータの書き込み中に適用されます)。対照的に、データレイクは事前定義されたスキーマを持たないため、ネイティブの形式でデータを格納できます。したがって、データウェアハウスでは通常、データプレパレーションの大半が処理前に行われます。データレイクの場合は、データが後で実際に使用されるときに実行されます。 Sparkの仕組みはHadoopのMapReduceと似ていますが、Hadoopが毎回のステップ終了時にHDFSにデータを書き出すのに対し、Sparkではデータをメモリ上に展開したまま複数のステップを連続して実行できるのが特徴です。この仕組みにより、ステップ数の多い処理では一般的にHadoopよりSparkのほうがパフォーマンスが高いとされています。
https://yubessy.hatenablog.com/entry/2016/12/11/095915 はじめに - カラムナフォーマットとは
カラムナフォーマットとは、データベースの分析用途に利用されるファイルフォーマットの種類の一つです。大量のデータを扱う際に効率的に圧縮してストレージコストを下げたり、計算時に必要なデータだけを取り出して計算コストを小さくできる設計がされています。本稿では、分析基盤で利用されるファイルフォーマットの概要を紹介し、 そのあとに、カラムナフォーマットにおける符号化方式、データモデル、ファイルフォーマットについて説明しようと思います。
分析基盤で利用されるフォーマット
最近は分析基盤用途として、Hive、Presto、Sparkといった並列分散処理プロダクトやそれらのマネージドシステムであるAmazonのEMRやAthena、GCPのDataProc、そしてフルマネージドなBigQueryやRedShiftが利用されるようになりました。
これらのプロダクトで取り扱えるフォーマットは、大きく以下3つに分けることができます。
テキストフォーマット(例:CSV、JSON)
行指向フォーマット(例:AVRO)
列指向(カラムナ)フォーマット(例:Parquet、ORC)1
CSVやJSONといったテキストフォーマットは、人間からの可視性が高い、アプリケーション連携がやりやすいというメリットがあります。しかしながら、データベース用途のフォーマットとしては、人間からの可視性よりも、保存時の圧縮効率や機械による処理のしやすさを追求する必要があります。データベース用途に向いているフォーマットの種類としては、行指向フォーマットと列指向フォーマットがあります。行指向フォーマットと列指向フォーマットの違いは、データの格納方式です。行指向フォーマットは、行方向に連続してデータを格納するため、一つの行をまとめて操作することの多いOLTP処理に向いています。従来のデータベースはもともとこの行指向フォーマットが利用されてきました。ストレージ技術などの発展により、DWH用途での利用を行うようになって、注目されるようになったのが列指向フォーマットです。列指向フォーマットは、列方向に連続してデータを格納する方式で、列単位でデータを取り出す分析用途に向いています。
主要なOSSのカラムナフォーマットのライブラリとしては、ParquetとORCがあります。ParquetはTwitter社とCloudera社が、2010年のGoogleの論文Dremel: Interactive Analysis of Web-Scale Datasets(以下Dremel Paper)におけるデータレイアウトに関する内容をOSS実装したもので、ORCはもとはApache Hiveのためのフォーマットとして実装されたという背景の違いがあります。
カラムナフォーマットにおける符号化方式の基礎
カラムナフォーマットでは、データ型やカーディナリティ等の特性に応じて、様々な符号化方式から決定木等によって各列に最適なエンコード方式を選択します。これらの符号化技術自体は、行指向フォーマットでも利用されるものですが、カラムナフォーマットでは、型が同じデータが並んだり、規則的にインクリメントするデータが並ぶなど、符号化によるデータ圧縮が効きやすいというメリットがあります。
ここで符号化方式の一部を紹介します。