S3データレイクをAWSの分析サービスを使って有効活用する #AWS-06 #AWSSummit | DevelopersIO
本記事は、AWS Summit Japan 2021のセッション動画、「AWS-06: 貯めるだけじゃもったいない！AWS 分析サービスを使ったデータレイクの有効活用」のレポート記事です。 「データはとりあえずS3に溜めておけ！」とデータレイクっぽいものは作れたけど上手く使いこなせていない方、それなりにいらっしゃるのではないでしょうか？本セッションでぜひAWSの分析サービスの活用術をおさらいしてみてください。 概要 データの持つ力を活かす方法としてデータレイクがありますが、データレイク上にデータは貯まってきたものの、どう有効活用すればいいか悩んだ経験はないでしょうか？データレイクに存在するデータと分析ツールと組合せ、活用する方法として、“レイクハウスアプローチ”があります。本セッションでは"レイクハウスアプローチ"の考え方を紹介すると共に、どのようなAWSサービスを用いて"レイクハウスアプ
AmazonAthenaで日時バッチ処理を作成 – TECH4ALL
Amazon Athenaで日時バッチ処理を作成 はじめに EMR on Sparkで実行していた日時処理(の一部)を、AthenaのCTASで実装し直した記事です。 何故このような対応をしたかというと、単にコスト削減＆高速化のためです。 ただ、実行するクエリや処理するデータ量によっては、この対応により逆に高コスト＆低速になる場合もあるので、事前に評価を行う必要があります。 この対応でどのようになったか この処理が毎日READ/WRITEするデータのサイズは下記のとおりです。 READデータ：約 80 GB/日 WRITEデータ：約 6 GB/日 この対応により、速度とコストは下記のようになりました。 EMR Athena 計算式については、後述します。 Athenaの速度は、Sparkと同様のクエリでは約24分でしたが、クエリ内の「ORDER BY」を外すと約6分で終了しました。 そのた
Athenaを使ったデータ処理基盤の設計 - Speee DEVELOPER BLOG
こんにちは。UZOUのプロダクト開発をしているエンジニアの@kanga333です。 UZOUでは広告データの集計の一部にAmazon Athenaを採用しています。 この記事ではUZOUにおけるAthenaを使ったデータ処理基盤の設計について紹介したいと思います。 全体構成 データ処理基盤の全体構成は次のようになっています。 以後はそれぞれのコンポーネントについて順次紹介していきます。 FleuntdによるS3への集約 UZOUでは特にFluentdアグリゲータのような中継サーバは設けていません。広告配信サーバに常駐するFluentdがログを直接S3にプットしています。 以下はFluentdのS3 output部分の設定の一部抜粋です。 <buffer time> @type file timekey 60m </buffer> path example_table/dt=%Y%m%d/h
大規模データについて第2回～EMR(Hadoop)について、なぜEMRなのか～ - Qiita
初めに、前回から大規模データ処理について連載させていただきましたが、 思ったより多くの方にストックいただき、この分野の関心の高さを改めて実感しております。 われわれも、この分野の事業に力を入れており、 積極的に取り組んで行く所存でございます！ それでは 大規模データについて第2回 ～EMR(Hadoop)について、なぜEMRなのか～ ご存じない方は、EMRって何？ということになると思うので 軽く説明させていただきます。 EMRとは、Amazon Web Service社（AWS）が提供している クラウドでのHadoopの実行環境です。 正式名称は「Amazon Elastic MapReduce」になります。 処理対象データをAWSのS3(クラウドストレージ)に配置し、 必要なコンピューティングリソースをを指定して実行すると、 必要な時に必要なだけ、文字通り「Elastic」にHadoop
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - dacort/demo-code: Bits of code I use during live demos
GitHub - commoncrawl/cc-pyspark: Process Common Crawl data with Python and Spark
