これまでData Engineering Studyでは、第1回ではDWHとBIツールの選び方を、第5回、第6回ではそれぞれBigQueryとSnowflakeの特集回を実施してまいりました。
今回はDWH特集回の第3弾として、AWSのDWHである「Redshift」を題材に取り上げ、Federated QueryやRA3インスタンスなどの最新アップデート情報を盛り込みながら、AWSのソリューションアーキテクトの方をお呼びして深堀りをしていきます。
勉強会の第1部では、主に初心者〜中級者をターゲットに、Redshiftの生まれた背景や機能などの概要をご講演いただきます。
第2部では最新アップデートを中心としたデモを行います。近年のRedshiftはアップデートが多く、進化したRedshiftの機能を、画面を見ながらキャッチアップしていきます。
第3部では「10年戦えるデータ分析入門」の著者でもあるクックパッド株式会社の青木峰郎氏をお呼びし、「クックパッド」の分析基盤におけるRedshift活用事例をお話しいただきます。
当日の配信の内容は下のリンクからご覧になれます。
基調講演「Amazon Redshift の進化の歴史とこれから」
出典：大薗純平氏、「Amazon Redshift の 進化の歴史とこれから」、https://speakerdeck.com/jozono/redshift-evolution-2021 より
大薗 純平 氏
Amazon Redshift は AWS のサービスの中でも進化のスピードが速いマネージド型のデータウェアハウスサービスです。> AWS クラウド上のデータウェアハウス、オペレーショナルデータベース、およびデータレイクにある大規模の構造化データと半構造化データに対して標準的な SQL を使用して分析クエリを実行できます。これまで Redshift が登場以来どのように進化を遂げてきたか振り返りながら、最新のアップデート情報をお伝えします。
Amazon Web Services Japan K.K.
Senior Solutions Architect, Analytics
Twitterのアカウントはこちら
まず、Redshiftがどのように進化してきたかを年代に沿って紹介していただきました。
高速でスケーラブルで費用対効果の高いDWHマネージドサービスとして登場
大薗 純平氏：「2012年ごろのデータ分析のアーキテクチャは、主に構造化データが入っているリレーショナルデータベースからDWHを通して、BIツールを使って分析・可視化する流れが一般的でした。さらに、こういった仕組みを作るときはオンプレミスな仕組みが中心でした。
こういった状況下で、Amazon Redshift（以下Redshift）はDWHに位置付けられるものとして登場しました。Redshiftの特徴は「高速でスケーラブルで費用対効果の高いDWHマネージドサービス」な点です。Redshiftの登場以前はテラバイトのDWH基盤が多かったため、Redshiftのスケールアウトは革新的でインターフェイスがPostgreSQLになっています。さらに、ETLやBIといった周辺ツールとの接続が可能で、コスト面でも従来のDWHの1/10と破格でした。」
シェアードナッシングなアーキテクチャ
大薗 純平氏：「Redshiftの構造としてBIなどのクライアントからリーダーノードにクエリを投げると、リーダーノードがクエリを解釈し、実行計画を作成してくれます。そして、それを複数のコンピュートノードに投げて、SQLを実行していく流れになっています。実行するSQLの対象となるデータはコンピュートノードのローカルストレージに分散して格納されていて、コンピュートノードを追加していくことで、スケールすることができます。」
データの取り込みに関する仕組み
大薗 純平氏：「オブジェクトストレージにデータを格納したS3からデータをRedshiftに転送したり、逆に受け取ることもできます。また、バックアップ・リストアはRedshiftが管理する別のバゲットに自動的にスナップショットをとり、スナップショットからクラスターイメージを復元することができます。」
データの規模の変化により対応が困難に
大薗 純平氏：「その後も顧客のニーズに応えながら変化していく中で、2017年に転換期が訪れました。データの種類・量が激増し、より多くのユーザーやアプリケーションがDWHにアクセスするようになりました。また、SQLだけでなく、機械学習やリアルタイムストリーミングなどの分析手法が登場しました。
それに伴って、それまでのDWHの機能であった収集・蓄積・分析を、「収集・蓄積」と「分析」に分割する形になりました。収集・蓄積の所にはデータレイクを置いて、より多様で膨大なデータ量を取扱しやすいようなアプローチを取りました。また、多くのユーザーが様々な利用方法で扱えるように、DWHだけでなく他のデータストアを活用してすることで適時適所でデータを扱えるようになりました。」
DWHとデータレイクの連携
大薗 純平氏：「すべてのデータをRedshiftに格納することは難しくなったことを受けて、S3にデータを置いたまま、クエリを行ってコストを抑えながら利便性の向上を図れるRedshift Spectrumが発表されました。
Redshift Spectrumは並列クエリ実行エンジンで、データレイクにオープンフォーマットで置いたものをDWHにロードすることなくクエリをかけることできる機能です。アプリケーションから見ると、Redshiftにクエリを投げるとDWHにあるかデータレイクにあるかが関係なくデータにアクセスできるので、幅広い分析が可能になりました。」
ピーク時に備えたConcurrency Scaling
大薗 純平氏：「2019年にはDWHを利用するユーザーやアプリケーションが増加したことで、分析ワークロードにはピークが存在するようになりました。ピーク時にはクラスターのリソースを食い合ってしまい、スループットが低下する恐れがありました。
それに対して、Concurrency Scalingがリリースされました。これはクエリが集中してクエリを捌くためのリソースが足りなくなった場合に、裏で自動的に別のクラスターを瞬時に立ち上げて処理を待たずに実行してくれるソリューションです。追加のクラスターを立ち上げてクエリが実行されると、クエリが実行された分だけお金が発生しますが、1日1時間は無償で使える上に、無償枠を超えないように利用できるキャップをかけることもできます。」
スケールアウトに関する課題を解決
大薗 純平氏：「コンピュートを増やしてスケールする際に、コンピュートとストレージが密にくっついているので、どちらかだけを増やしたいというニーズに応えることが困難でした。
そこで、RA3インスタンスがリリースされ、アーキテクチャーが刷新されました。マネージドストレージにストレージ層を切り出して、コンピューターノードはクエリを捌くためのコンピュータリソースとして利用し、 マネージドストレージで頻繁にアクセスされるデータはコンピューターのノードにキャッシュするアーキテクチャーになっています。」
リアルタイムでの分析が可能に
大薗 純平氏：「2020年にはもう1つ大きな発表がありました。実際のビジネス活動ではどんどん新しいデータがデータソース上で反映されていく中で、本当にリアルタイムに新しいデータを分析できるのはデータレイクやDWHに連携された後になるので、バッチ連携するタイミングに依存していました。
そこでリリースされたのが「Federated Query」です。RedshiftからAmazon RDSもしくはAurora PostgreSQLのデータに直接クエリをすることができ、 データを移動することなく、ライブデータをDWHもしくはデータレイクのデータと繋げて分析することができます。また、MySQLのサポートも、プレビューではありますが始まっていて、多くのお客様に使っていただいております。」
複数クラスター間でのデータ共有
大薗 純平氏：「1つのクラスターではなく、複数のクラスターが必要になるケースが存在します。例えば、ワークロード間で目的が違ったり、そもそも管理する部分が違うとクラスターを分ける必要が出てきます。ただ、データを複数のクラスター間共有したい場合は、Redshiftから一度S3にデータをアンロードし、そのデータを別のクラスターにコピーする必要がありました。
これをシンプルにそして簡単にした、Data Sharingという機能が出てきました。データをシェアする側のクラスターであるプロデューサークラスターが、あるクラスターにこのスキーマもしくはこのテーブルだけ見せたいときは、GRANT・REVOKEの簡単な権限制御で引き渡してあげることによって、別のコンシューマクラスターからアクセスが可能になります。」
メンテナンスフリーな便利な機能
大薗 純平氏：「また、ノンチューニングでも高速なクエリパフォーマンスを提供する自動パフォーマンスチューニングも実装されています。裏側としてはテーブルの物理配置に必要なソートキーや分散キーを自動で選択し、データ増加に伴う履歴削除などの内部的なメンテナンスも自動化されているので、そのあたりを全く気にせずに運用することができます。」
「これからのRedshiftの進化」についてもお話ししていただきました。
RA3インスタンスの強化
大薗 純平氏：「RA3インスタンスのアーキテクチャーは非常に柔軟性が高く便利な面もありますが、コンピューターとストレージが離れることで、それらを行き来するデータの量が多くなると、ネットワークボトルネックになりかねません。
そこで今後は、AQUAという機能がコンピュートノードとマネージドストレージの間に入り、サーバレスのリソースで特殊なチップセットを使ってなるべくデータの近いところでフィルタリングや中継を行って、コンピューターノードに結果を返すアプローチが可能になり、より高速なクエリパフォーマンスを実現できます。」
SQLで機械学習のモデル作成・トレーニングが可能に
大薗 純平氏：「また、マシンラーニングとの連携であるRedshift MLはRedshiftのテーブルデータに対して、機械学習処理である、モデル作成・確認・推論といった一連の機械学習のパイプラインをすべてSQLで実行できるものです。」
AWSの他のサービスとのデータシェアが可能に
大薗 純平氏：「Data Sharing for Data Lakeは、Redshift間のデータシェアだけではなく、EMRやAthena、セージメーカーという別のデータストア基盤とデータをシェアすることができるようになる予定になっています。」
カスタムコーディングなしにデータの複製・結合が可能に
大薗 純平氏：「様々なデータソースのデータを結合してマテリアライズドビューの形で、RedshiftやElasticsearch Service、S3などのデータソースに対してデータを自由に繋げることできる機能になっています。これによって、DynamoDBのデータをRedshiftにSQLで連携することが容易になります。」
最後に、Redshiftの今までとこれからについてまとめていただきました。
大薗 純平氏：「今までは、リレーショナルデータベースからDWHに入れてBIで可視化するところから始まったRedhsiftでしたが、現在は様々な連携が許可され、RedshiftのDWH自体のパワーもアップしています。様々なところとの連携ができてきているので、今後どんな変化があるのかを期待していていただければと思います。」
基調講演2「実演 Amazon Redshift 最新機能」
出典：平間大輔氏、「実演 Amazon Redshift 最新機能」、https://speakerdeck.com/daisukehirama41/shi-yan-amazon-redshift-zui-xin-ji-neng より
平間 大輔 氏
Amazon Redshiftは、ここ1〜2年に限っても多くの機能が追加され、ますます使いやすいものになっています。ここではクエリの同時実行性能を飛躍的に向上させたconcurrency scaling、半構造化データを扱える新しいデータ型SUPER、業務システム上の最新データを直接クエリできるFederated Query、DWH間でデータを共有するData Sharingといった、Amazon Redshiftの最新機能を、デモを交えてご紹介します。
Amazon Web Services Japan K.K.
Solutions Architect, Analytics
今回は、よくあるシチュエーション別にどの機能を使っていくべきなのかを解説していただきました。
アクセス集中によるクエリ実行に待ちが生じるパターン
平間 大輔氏：「1つ目のシュチュエーションとして、朝イチでアクセスが集中してクエリの実行待ちが発生するケースです。RedshiftのようなDWH向けのRDBMSは、対応するクエリが複雑で大量のデータを一気に読み込むリソース大食いのクエリに合わせてチューニングされています。そのため単一のクエリに十分なCPUやメモリのリソースを割り当てられるようにするために、同時実行ができるクエリ数は少なめに抑えていることが多いです。これは、短時間に数千を捌かなければならない一般的なOLTP向けのデータベースとは真逆のチューニングだと思います。」
ピーク時に対してRedshiftが導入している機能
平間 大輔氏：「クエリが殺到して来た時にヘルプ用のクラスターを立ち上げるConcurrency Scalingという機能があります。処理を依頼して追加されるクラスターは設定によって最大10個まで起動させることができます。」
ここからは、Concurrency Scalingを使用したデモをやっていただきました。
※デモの様子はこちらからご覧になれます。
Concurrency Scalingによって実行時間を短縮化できる
平間 大輔氏：「2つのノードを用意して、片方にConcurrency Scalingを有効にして他の設定は同一にした状態にします。また、ベンチマークツールを使って分析系の重いクエリを20セッションから同時実行します。
最初は順調にどちらのクラスターもクエリを捌いていきます。 Redshiftの管理コンソールを見ていくと、同時実行スケーリングモードがAutoな場合は、要件に応じてConcurrency Scalingが必要だとRedshiftが判断すると、自動的にヘルプのクラスターを呼び出す仕組みになっています。Concurrency Scalingをオフにしている場合はAutoとは表示されません。
ワークロードの同時実行をすると、Concurrency Scalingが無効なものは、出始めはキュー待ちが発生してません。時間をおくとクエリの実行待ち（青色）が発生し、Concurrency Scalingが有効なものより全体の実行時間が長くなっていることが確認できます。」
様々な場所にある様々な形式のデータをRedshiftで分析したいパターン
平間 大輔氏：「Redshift内に蓄積されているデータ以外にも、データレイクのような巨大なストレージを用意してデータを貯めたり、常時更新されるデータを基幹のデータベースに有しているパターンがあると思います。そういったデータを一緒にジョインしてみたいという要望は昔からありました。
この問題を解決するための機能として、Federated Queryがあります。これは今のところ、Amazon RDSやAuroraのPostgreSQLのデータベースエンジンに対して直接クエリすることができます。また、プレビューではありますが、MySQLもサポートしてきたので期待していただければと思います。」
S3にデータをおいたままデータアクセスが可能に
平間 大輔氏：「また、S3上のデータをスキャンするためのRedshift Spectrumいう仕組みも用意されてます。これは外部にある特定のスキーマにあるテーブルとして認識されるので、SQL文では普通にジョインでき、裏側ではS3にアクセスするための専用のクエリ実行エンジンが用意されていて、高速にスキャンしてクエリすることができるという優れものなっています。」
半構造化データを直接テーブルに格納可能に
平間 大輔氏：「パブリックプレビュー中ですが、新しいデータ型としてSUPERというデータ型が登場しました。これはJSONデータを取り込むことができるネイティブに半構造化データをサポートするデータ型になっています。これはWeb系のシステムを中心にJSONを扱いたいという方におすすめです。」
複数のDWHのクラスターで同じデータをシェアしたいパターン
平間 大輔氏：「例えば、社内に部門ごとにクラスターが建てられているものの、社内共通データが入っているクラスターからのデータを持ってくるとなると、セキュリティ上の問題や処理の煩雑さがネックになります。データ移動せずにデータを共有する仕組みとして実現したのが、Data Sharingという仕組みになっています。」
ここからは、Data Sharingのデモを行なっていただきました。
※デモの様子はこちらからご覧になれます。
平間 大輔氏：「ETLクラスターのテーブルを2つのクラスターに共有していきます。アドホッククエリを実行するクラスターとダッシュボードを見せるクラスターになっています。ダッシュボードクラスターの方はすでに共有の設定しているので、アドホッククエリクラスターに共有設定をして、ETLクラスター中のテーブルのデータを書きかえて、反映されるかを見ていきます。」
平間 大輔氏：「今回はRA3プロデューサーというクラスターにデータを持たせていて、RA3プロデューサーという名前のクラスターからData Sharingを行なっていきます。今回は新しいデータシェアを作っていきます。シェアの対象としてテーブルとビューとユーザー定義関数が選べるようになっていて、必要なテーブルを選んで追加することで、シェア対象のテーブルが選ぶことができます。テーブルの選択などは管理コンソール上だけでなく、SQL文で実行することも可能です。
データシェアを行った後は、RA3コンシューマーについて見ていきます。データシェアに対して、コンシューマー側は外部データベースとしてのデータベースを作っていきます。外部データベースとして認識されることで、コンシューマクラスターでプロデューサークラスターに対してクエリが投げられることが可能になります。」
平間 大輔氏：「コンシューマクラスターで実行したときにはプロデューサークラスター側は全然深く関わらないが、プロデューサークラスターはシェアしたという情報は渡しています。しかし、プロデューサーからコンシューマーにデータが流れる形にはなってないでRedshiftのマネージとストレージをコンシューマークラスターも読みに行く形ですぐクエリが返ってきます。」
最後に、本日のお話をまとめていただきました。
平間 大輔氏：「これまで紹介した更新機能を使う場面がかなりあるかなと思います。こういう場面で使えるというのを今回の資料でまとめてご紹介させていただきました。Redshiftは現在も活発に新機能の追加が進められていて、数年前に検証してできなかったことが、実は今できるようになってるかもしれません。Redshiftの最新機能をぜひお試しいただければなと思います。」
事例講演「なぜクックパッドはRedshiftをデータ基盤に選び続けるのか」
出典：青木峰郎氏、「なぜクックパッドはRedshiftをデータ基盤に選び続けるのか」、https://koibu.me/events/18/talks/kLbXm5aUowi20pMyCtdp より
青木 峰郎 氏
クックパッドは2016年にデータ基盤を構築して以来、周辺技術はリファインしつつも、一貫してRedshiftを使い続けてきました。このセッションでは、そもそもデータ基盤とは何か、データ基盤を設計するときは何を考えるべきなのか、そしてその基準に照らして我々がなぜRedshiftを選ぶのかについてお話しします。
クックパッド株式会社 技術部
まずは、クックパッドのデータ基盤の概要についてお話ししていただきました。
内製サービスを多用したデータ基盤
青木 峰郎氏：「クックパッドは、検索分析サービスである「たべみる」でRedshiftを初めて導入しました。使用感がよかったため、2016年にはRedshiftを全社に展開しました。 その後は着々と新機能を次々に導入して今に至ります。最新のイベントとしては2021年3月にRA3クラスターを導入しました。
データ基盤は真ん中にRedshiftクラスターがあり、そこに入力しているデータが大きく分けて3系統あります。1つ目がマスターテーブルで、SQL・PostgreSQL・DynamoDB全部合わせて約500テーブルあります。 2つ目の系統がログで、アプリケーションから主にFluentd経由でS3にJSON形式のログが流れてきていて、それをSpectrumで見られるようにしています。 3つ目の系統がそれ以外のやつで、Workday ・SalesforceなどのSaaSから取り込んでいるデータです。
そして取り込んだデータは主にSQLを使い、分析に適した形式にバッチで変換してサマリーを作成します。SQLバッジについてはBricolageという自前のSQLバッチフレームワークを使って実行しています。
そして作ったサマリーテーブルや入力したテーブルの出力系統も大きく分けると3系統あります。まず1つ目がTableauなどの管理画面からの定型クエリがくるもので、2つ目の系統が毎回人間が考えて投げるような非定型クエリで、SQL clientを使うことが大体多いです。それから3系統目が他のシステムへのバルクエクスポートです。これはQueueryという時前のサービスを使用して、HTTP・APIでデータをアンロードできる仕組みを使っています。」
さらに、自前のソフトウェアであるPrismについても解説していただきました。
Prism Mergeによる大幅な速度向上
青木 峰郎氏：「特に作り込んでいるところの1つ目がログのロードです。 ログのロードはこれはPrismを使用して、S3に到着するJSONのログをParquetに変換して、Spectrumで参照できるようにしています。 Prismの特徴は、Parquetのマージを行うという点が挙げられます。到着したログのJSONファイルは最初Prism Streamプロセスによって、オブジェクト単位でParquetに変換されていきますが、これだとS3のオブジェクトの数が多くなってしまい、クエリが遅くなります。
そこで、別途Prism Mergeというプロセスが約6時間毎に行われ、巨大なS3オブジェクトに巨大なパーティーファイルにマージしています。これによって、平均して3倍から5倍の速度向上がみられています。
そしてもう1つの特徴として、LiveのParquetファイルとマージ済みのParquetファイルを等価的に変換して行くことができる点が挙げられます。つまりLiveとmergedでテーブルが分かれているわけではなくて、1つのSpetrumのテーブルとして見ています。 届いた直後は小さいParquetファイルができていきますが、時間が経つと順次古い方からマージされていき、高速化される仕組みになっています。」
DBごとのマスターテーブルの取り込み方
青木 峰郎氏：「マスターテーブルは取り込む対象のデータベースによって取り込み方を変えていて、一番多いのがMySQLになっています。これはPipelined Migratorという内製のシステムを使って取り込んでいます。専用のコンソールがあって、テーブルにチェックを付けていくだけで読み込めるようになってます。
また、PostgreSQLについてはAWS Database Migration Serviceを使っていることが多いです。ただ、クリティカルじゃないものから順番に、Redshift Federated Queryに移行していて、最終的にはMySQLも含めた中心のものはFederated Queryに移行したいと考えています。
DynamoDBは、DynamoDB Streamsを読んでS3にJSONを書き出し、それをPrismで取り込む仕組みになっています。 」
データ活用の事例にうつる前に、データ基盤をどのように作ったのかをお話ししていただきました。
データ基盤の使い道
青木 峰郎氏：「データ基盤の使い道は大きく3つにあり、1つ目が定型クエリで、毎日同じクエリを投げて定点観測する使い方になります。2つ目の使い道が非定型のアドホッククエリで、ユーザー理解に使われることが多かったり自社のシステムを理解するために、ユーザーがこういう機能をどう使ってるかユーザーはどういう特徴があるのかとかを調べたい時に用いる傾向があります。 そして3つ目の用途がバルクエクスポートで他のシステムへのデータ転送で、入ってきたものを加工してサマリーを作って、それを転送するのが主な使い道になります。」
青木氏は、バルクエクスポートがデータの活用方法として一番価値が高い方法だと語られ、その理由も説明していただきました。
バルクエクスポートの特徴
青木 峰郎氏：「そもそもデータ基盤は何のためにあるかというと、アプリケーションあるいはサービスのパフォーマンスを改善するためだと考えています。先ほどの3つの使い道のうちの1つ目と2つ目は定型クエリと非定型クエリは、人間がデータ分析をして人間がサービスを改善することが目的です。しかし、3番目はデータを直接サービスに戻して、直接サービスを改善するのが役割で、間に人間が挟まるかどうかの違いがあります。
人間が挟まらない方が効率が良く、24時間365日ずっと働き続けてずっと改善を行うので、バルクエクスポートが一番価値が高いとはいえ、システム的に一番制約が大きく複雑な仕組みになるので、データ基盤は他のサービスにデータを返すことを考えて設計すべきだと考えています。」
ここからは、クックパッドでのデータ活用事例について紹介していたいだきました。
事例1：たべみる
青木 峰郎氏：「1つ目はたべみるの事例で、クックパッドにおけるレシピ検索の分析ができるアプリケーション。主に食品のメーカーさんに利用されていて、特定のワードが検索されている時期が分かったり、特定のワードと一緒に検索されているワードがわかる特徴があります。
構造としてクックパッドレシピサービスから出てくるログとユーザーマスター・レシピマスターを合わせて、Redshiftに取り込みます。そしてBricolageを使ったSQLバッジを介して、日付と単語ID等をキーにした統計のサマリーを作り、それを別のRedshiftクラスターに転送して利用しています。
最初はRedshift1つで運用していましたが、障害が起きたことから2つに分かれました。Redshift間のデータは簡単なRubyスクリプトでアンロード・ロードを行って転送しています。 ただ今後はData Shatingで運用で運用していく可能性があります。」
事例2：人気順レシピ検索
青木 峰郎氏：「人気順レシピ検索という機能は、クックパッドでレシピを検索する時に人気のある順にレシピをソートとして見ることができると機能です。
構造としてはたべみるのアーキテクチャと類似している点が多く、クックパッドレシピサービスからPVログと レシピマスターをRedshiftに取り込み、それをSQLのバッチで処理して、ロジックは秘密ですが人気順ポイントをレシピごとに付与します。そして人気順ポイントをS3にアンロードし、その他の検索インデックスも同じようにS3ロードして、最終的にAthenaを使って全部ジョインし、1つのSolrドキュメントを作り、Solrに渡す仕組みになっています。Athenaを使用している理由は元々全てRubyで処理していたバッチを、後からRedshiftに置き換えたという歴史的な背景があるためです。」
事例3：ターゲティング広告
青木 峰郎氏：「先ほどまでのアーキテクチャと類似点が非常に多く、作成されたユーザーセグメント（例：健康志向を持つグループ）をオーディエンス拡張して、機械学習で作った外部の拡張情報をロードすることで、拡張ユーザーセグメントを作成します。最終的に作ったセグメントをRubyスクリプトでDynamoDBにロードするシステム構成になっています。」
最後に、何故クックパッドがRedshiftを使ってシステムを作ってきたのかをお話ししていただきました。
Redshiftを選ぶ3つの理由
青木 峰郎氏：「1つ目は、クックパッドのサービスがAWSにあるためです。 データ基盤は成長すればするほどアプリケーションとのデータのやり取りが増え、アプリケーションと連携しやすい近い場所にデータ基盤をおく必要性が生まれます。そのため、メインのアプリケーションがAWSなら、当然AWSにデータ基盤がある方がやりやすいです。
2つ目の理由はAWSの他のシステムとの連携が優れているからです。 他のシステムとの連携のための機能がさまざまある点が優秀で、 IAMで全ての連携機能を統一的に権限管理できる点も地味ですが非常に重要です。
そして3つ目は必要な機能ならRedshiftがいずれ追加してくれるだろうという信頼感があるからです。これまで後付けで実装されると思わなかったものが実際追加されてきたので、この先も機能がどうしても必要になったときは追加してくれると考えいて、追加されなければリクエストすればいいという気持ちでいます。」
過去のData Engineering Studyのアーカイブ動画
Data Engineering Studyは月に1回程度のペースで、データエンジニア・データアナリストを中心としたデータに関わるすべての人に向けた勉強会を実施しております。
当日ライブ配信では、リアルタイムでいただいた質疑応答をしながらワイワイ楽しんでデータについて学んでおります。
過去のアーカイブもYoutube上にございますので、ぜひご覧ください。
https://www.youtube.com/@dataengineeringstudy6866/featured
