2024.12.19
システムの穴を運用でカバーしようとしてミス多発… バグが大量発生、決算が合わない状態から業務効率化を実現するまで
AWSを用いたデータレイクの基礎(全1記事)
リンクをコピー
記事をブックマーク
野口真吾氏(以下、野口):みなさんこんばんは。本日は「検索インフラ Tech Talk!」ということで、検索インフラから少し広げた話題にはなるんですが、「AWSを用いたデータレイクの基礎」というお話をします。よろしくお願いします。
最初に簡単に自己紹介します。アマゾンウェブサービスジャパンでスタートアップ担当のソリューションアーキテクトをしている野口真吾と申します。Twitterでは@nogというIDを使って活動をしています。2020年の7月より現職で活動をしていて、これまではスタートアップやメガベンチャーと言われる会社で、サーバーサイド開発や技術責任者、SREといった役割を主に担っていました。
前職は男女のマッチングアプリの会社だったので、マッチングアプリについてはちょっと詳しいです。この発表ではデータレイクとは何か、データレイクの作り方、それを収集、保存、加工、活用にそれぞれ分けて、あとは作り方のポイントについてお話しします。
データレイクとは何かですが、これまで企業でデータを扱うときにはデータのサイロ化というものがよく発生していました。これはどういうことかと言うと、例えば事業部ごとに自分たちの使いたいデータをデータウェアハウスでそれぞれ構築することで、データが分断してしまうことを指します。
大企業特有の話に聞こえるんですが、ゼロからデータ基盤を構築するスタートアップ企業でも起こり得ることです。例えば、長期的な視点をもたずにマーケティングチームのためにElasticsearchとKibanaのダッシュボードでデータを見られるようにして、そのあとにデータサイエンティストのためにデータウェアハウスを別途用意するみたいなことを場当たり的に行ってしまうと、スタートアップであっても、あっという間にデータのサイロ化が発生します。
これを回避して、すべてのデータを1ヶ所に集めるというのがデータレイクの考え方です。すべてのデータを1ヶ所に集めて、集めたデータを必要に応じて変換・加工して、さまざまな目的に使い分けます。
データレイクアーキテクチャに移行するための重要なポイントを考えます。データレイクでは、すべてのデータを一元的に保管することが大切です。このデータは耐障害性、可用性が高く、スケーラブルで低コストな必要があります。今日のデータは非常に多様化しているので、標準的なデータフォーマットをそのまま活用できるようにする必要があります。
またセキュリティの重要性は日々高まっているので、データをセキュアに扱うことが非常に重要です。さらにデータの力を引き出すために、ストレージと活用する層を分離して、いろいろなユースケース、分析などに対応する必要があります。
このような性質をもつデータレイクを、どのように作るかに焦点を当てていきます。データレイクを作るには収集、保存、変換、活用の4つのステップが必要です。まずデータの収集元のデータベースやファイル、センサーなどからデータを集める収集のステップ。次に収集したデータを、データレイクのストレージに格納する保存のステップ。そして保存したデータを、扱いやすく加工する変換のステップ。最後に変換したデータを活用、分析するステップです。
まずは収集について、AWSでどのように実現するかを見ていきます。左から見ていくと、ログのデータがあります。AWSのサービスやリソースのログはCloudWatch Logsに集まるので、これらをAmazon KinesisでデータレイクのストレージのAmazon S3に集めていきます。IoTデバイスなどのセンサーデータもAWS IoT Coreを使っている場合、これもAmazon Kinesisを使ってAmazon S3に集めることが可能です。
アプリケーションが出力するデータは、fluentdのようなエージェントのプログラムでS3に送ることもできますし、AWSのAPIやAWSのSDKを使って送信もできます。もちろんAmazon Kinesisを使って送ることも可能です。また、データベースのデータは、AWS Glueを使って定期的にS3に送ることもできるし、AWS DMSというマイグレーションのサービスを使って、データを継続的にS3に移すことも可能です。
最後にGoogleアナリティクスなどのSaaSのデータですが、こういったデータはAmazon AppFlowというサービスを使うことで、簡単にAmazon S3にデータ連携ができます。このように、データソースごとに簡単なやり方があるので、適宜チョイスして使ってもらえればと思います。
次に保存についての部分です。AWSでこの部分を考えるときは、データの保存先にAmazon S3を、メタデータカタログの保存先にAWS Glue DataCatalogを使うことをおすすめしています。S3は高い耐障害性と可用性を持っていて、容量に制限がなく、スケーラブルです。また、ライフサイクルという機能で、データを保存する期間を簡単に管理できて、時間が経ったデータをより安いストレージに移すことも簡単です。
これを活用していない会社が意外と多いです。技術力の高いスタートアップの会社でも、ライフサイクルやストレージクラスを見直すことでストレージコストが大幅に削減できる例がけっこうあります。S3で大規模なデータ活用をしている方は、一度見直してみることをおすすめします。
Glue DataCatalogは、データのメタデータカタログを管理するサービスです。実際のデータに対応するテーブル定義を自動的に生成する仕組みがあるので、例えばデータにカラムを追加した場合、自動的に追従してくれます。後ほど加工のところでも紹介します。
3つ目はデータ加工のステップです。パフォーマンスの観点と、ビジネス観点の2つの観点からお話しします。パフォーマンスの観点では、csvやjsonからparquetのカラムナフォーマットに変換すること、分散し過ぎたファイル群を集約しておくこと、データの配置を上手に行って、パーティショニングが可能なように配置すること、不要なデータを削除して、データ量を小さくして維持すること。この4つが重要です。
ビジネス観点では、分析するときにデータのキャストをしなくていいようにあらかじめデータの型をちゃんと変換しておくこと、日付の形式やタイムゾーンがバラバラにならないようにすべてのデータを同じ形式で、同じタイムゾーンになるように統一しておくこと、不要な個人情報などをきちんとマスクしてデータレイクに入れること、不要なカラムは削除していくこと。こういったことが重要です。
実際の加工の例を示します。ここではLTE処理でAWS Glue、Amazon Athena、Amazon EMRの3つのサービスを利用しています。この3つのサービスについて簡単に紹介します。
AWS GlueはフルマネージドのデータカタログとETLのサービスです。GUI上でETLの処理フローを作成するとコードが生成されて、そのコードをカスタマイズすることができます。S3に集めたローデータを、Glueでフォーマットを変換して保存し直すことも可能です。
Amazon Athenaは、サーバーレスなインタラクティブクエリのサービスです。運用コストがかからず、スキャンしたデータごとでコストがかかります。S3に保存したcsvやjson、parquetなどのデータに対して、Prestoベースの標準SQLの実行が可能です。
Amazon Elastic MapReduceは、フルマネージドなHadoop環境を提供します。運用面を気にせずにHadoopアプリケーションの開発や利用が可能です。KinesisやS3、DynamoDBとのデータ入出力に対応しています。
先ほどの図に戻ります。どういう加工処理を行っていくかです。ELBからこのS3にログデータを出力します。このデータをGlueを利用してこれをcsvからparquetに変換します。変換したデータをAthenaを使って日次集計して、別のデータとして保存します。次に、Kinesis Data Firehoseで送られてきた構造化されていないデータをS3に保存します。
そして、Glueを使って、正規化や破損レコードの削除の処理を行います。EMRを活用して、先ほどのELBのデータのparquetとこのデータを合わせて別のデータを生成することも可能です。また、RDS上のマスタデータからGlueを使って、日次での情報の抽出や個人情報のマスキングを行うことも可能です。
Glueを使えば、先ほど作った日次集計データとマスタデータをジョインしてリッチなデータの作成も可能です。このように生データから、求められるデータを生成できます。
続いて活用です。検索インフラという観点だとAmazon Athena、Amazon Redshift、Amazon Elasticsearch Serviceなどでデータレイクアーキテクチャを活用した検索基盤の作成が可能です。検索以外のデータの活用でも、目的に合ったデータレイクの活用方法を適宜選択できるようにするのが大切です。
主な活用シーンとして、BIや可視化、アドホッククエリ、機械学習、バッチの4つと、今回は触れませんが、リアルタイム処理を行うストリームを挙げています。これらをデータレイクアーキテクチャ上で行うことで、使いやすいデータ基盤の構築が可能です。最初の利用用途がBIや可視化だけでも、そこから少ない手間でアドホッククエリでの分析や機械学習など、別のユースケースにデータ活用の幅を広げることが可能です。
データレイクを作るときのポイントは、小さく始めること、そして段階的に作ることです。データレイクは性質上、最初からすべてを予見するのが困難です。良いところは最初にすべてを決めなくても、使い方をあとから決められるという点です。スモールプロジェクトで、S3にデータを保存することから始めて、徐々にデータソースやユースケースを拡張していくことがデータ活用の近道です。
まとめです。データレイクとは何かという話と、AWSを用いたデータレイクの作り方で、収集にはAmazon Kinesis、AWS Glue。保存にはAmazon S3、AWS Glue DataCatalog。加工にはAWS Glue、Amazon Athena、Amazon EMR。
検索インフラとしてAmazon Athena、Amazon Elasticsearch Service、Amazon Redshiftが使えるという話と、作る際のポイントで小さく始めるということをお話ししました。
AWSを用いたデータレイク構築に興味をもった方におすすめする参考情報を紹介します。2020年のAWS Summit Onlineの講演「データレイクのつくりかた、つかいかた、そだてかた」。今回の私の話は作り方でしたが、実際の運用方法や育てていく方法についても言及しています。
ほかにもAWS re:Invent Recapには、2020年末のre:Inventで発表されたAWSのアナリティクスの新サービスの紹介やクイックデモがあります。最後に、『AWSではじめるデータレイク』という書籍も体系的にまとまっていて、非常に参考になります。これらも興味があれば見てみてください。以上です。ご清聴ありがとうございました。
2024.12.12
会議で発言しやすくなる「心理的安全性」を高めるには ファシリテーションがうまい人の3つの条件
2024.12.19
12万通りの「資格の組み合わせ」の中で厳選された60の項目 532の資格を持つ林雄次氏の新刊『資格のかけ算』の見所
2024.12.16
32歳で成績最下位から1年でトップ営業になれた理由 売るテクニックよりも大事な「あり方」
2023.03.21
民間宇宙開発で高まる「飛行機とロケットの衝突」の危機...どうやって回避する?
2024.12.10
メールのラリー回数でわかる「評価されない人」の特徴 職場での評価を下げる行動5選
2024.12.13
ファシリテーターは「しゃべらないほうがいい」理由 入山章栄氏が語る、心理的安全性の高い場を作るポイント
PR | 2024.12.20
モンスター化したExcelが、ある日突然崩壊 昭和のガス工事会社を生まれ変わらせた、起死回生のノーコード活用術
2024.12.18
「社長以外みんな儲かる給与設計」にした理由 経営者たちが語る、優秀な人材集め・会社を発展させるためのヒント
2024.12.12
今までとこれからで、エンジニアに求められる「スキル」の違い AI時代のエンジニアの未来と生存戦略のカギとは
PR | 2024.11.26
なぜ電話営業はなくならない?その要因は「属人化」 通話内容をデータ化するZoomのクラウドサービス活用術
Climbers Startup JAPAN EXPO 2024 - 秋 -
2024.11.20 - 2024.11.21
『主体的なキャリア形成』を考える~資格のかけ算について〜
2024.12.07 - 2024.12.07
Startup CTO of the year 2024
2024.11.19 - 2024.11.19
社員の力を引き出す経営戦略〜ひとり一人が自ら成長する組織づくり〜
2024.11.20 - 2024.11.20
「確率思考」で未来を見通す 事業を成功に導く意思決定 ~エビデンス・ベースド・マーケティング思考の調査分析で事業に有効な予測手法とは~
2024.11.05 - 2024.11.05