はじめに
本記事はDB Tech Showcase 2023の二日目(12/7)において AWS Japan の下佐粉さんが講演された「オンプレミスRDBのデータを AWSクラウド上の分析基盤に取り込む 手法の整理」のレポートです。
公式セッション紹介
オンプレミスRDBのデータをAWSクラウド上の分析基盤に取り込む手法の整理 - データの抽出、保存形態、必要となる前処理 -
企業の中にある各種システムからクラウド上の分析基盤(データレイク)にデータを取り込み、クラウドのパフォーマンスを活かして分析する手法は一般的になりつつあります。企業はオンプレミス上でRDBを多数活用しており、そのデータをクラウド上に効率よく取り込み、活用しやすい形で保存することが、データ活用促進の鍵です。本セッションでは、主にRDB上のデータを取得する際の手法と、取得したデータをどのような形にしてデータレイク上に保存するかという「データ取り込み」部分にフォーカスした説明を行います。環境はAWSを前提にしていますが、他クラウドのオブジェクトストレージへのデータ取り込み方法の一般論としても応用可能です。
発表資料
注：本記事の画像は注釈がなければ発表資料からの抜粋です
概要/オススメポイント
このセッションでは、オンプレミスRDBのデータを～とあるように、どちらかというと最初に（クラウド上に）データレイクを作る際に課題となる点にフォーカスしている点が特徴です。そのため、クラウド活用が進み始めて、偉い人から「そろそろうちもデータ活用できないの？」とか「クラウドにシステムあるんだからそこで分析してよ！」とか言われて、さてどうしよう、と思った方におススメです。
また、下佐粉さんはAWS JapanのSAであり、私も持っている AWSではじめるデータレイク の著者で、データ分析基盤のスペシャリストです。クラウド上で実際に動かしている中でのTIPSやノウハウも紹介されていますので、既にデータ活用を始めているけど課題がある、とか、いったんデータレイクを作ってみたけどこれでよいのかな？という方にも参考になると思います。
一方で、AWSの機能や仕組みを利用して説明されていますが別の機能等でも代替できますので、データレイク作りたいけどAWSじゃないんだよなあ、という方にも参考にできる点があると思います。
セッション内容
データレイクを作るうえで最初の課題となる『「データレイク」への「データ取り込み」』について、以下の観点から説明されています。
- なぜデータレイクを作るのか？
- データが無いと活用が進まないが、どのようにすればデータソース（ RDBMS 等）からデータを取り出せるか？
- RDBMS から取り出したデータはデータレイク上でどのように配置、更新するべきか？どのようにして性能を担保するか？
それぞれのポイントについて、お話を聞いて私が感じたポイントを紹介します。
1. なぜデータレイクを作るのか？
従来の構成のように、処理系と蓄積が分離されていない場合、何かを行い場合には処理系も変更が必要となり、蓄積されたデータの移動等含めたコストが大きくのしかかってきます。
ここで、似たような話を思い出しました。こちらはAmazon Auroraの解説資料ですが、全く同じ様な表現がされています。
つまり、レイヤは違えど、替えが効くものとそうでないものをきちんと分けましょう、という思想と理解しています。最初に利用できるデータを持つことで、後でどんな処理にも対応できます。そのため、まずはきちんと蓄積しましょう！
2. データが無いと活用が進まないが、どのようにすればデータソース（ RDBMS 等）からデータを取り出せるか？
データレイクとしては、データがないと活用されないため、データ量をまずは確保する必要があります。また、そのデータは業務側から提供してもらう必要があります。ここで、セッション内でも強調されていましたが、基本的にデータオーナ側は余分な負荷や仕事を増やしたくないので、ありものを受けつつ受け側（データレイク側）で技術で対応する必要があります。
これは実務でも あるある で、現業ではない部分に追加コストを投入してデータ連携を行う、というのはまず無理です。そのため、例えば現在HULFTでファイル連携しているならそれをもらう、とか、バックアップファイルをそのままもらう、とか、なるべく**「あるがまま」でデータ取得をしていくことでデータレイクのデータを充実**させることができるようになります。
逆に、これは私の経験上ですが、いったんデータレイクができてデータ活用の効果が見えてくると、このデータも使いたい！みたいな声に対してポジティブな対応（コスト面／心理面）が期待できます。
3. RDBMS から取り出したデータはデータレイク上でどのように配置、更新するべきか？どのようにして性能を担保するか？
配置・更新の最初のポイントとしては、履歴を全て記録する、という点になります。基本的には過去データを上書きせず、過去のデータは過去のデータとして保持することでデータの価値が出てきます。
ここで強調されていた点は、データが小さければなんとでもなる、巨大データの差分抽出の検討が肝になってくる、ということでした。
差分抽出については、なるべく機械的に抽出できるとよいが、前項の「あるがままに」を優先した場合には大体機械的な抽出が難しくなるため、CDC(Change Data Capture)での転送が多くなってきます。CDCの場合、転送自体に転送元・転送中のパフォーマンス懸念やトラブル時の対応が出てくるため、考慮が必要となります。
私自身もCDCをインプリした際に転送元への負荷が大きくなってしまいチューニングが必要になったことや、データ転送時の障害タイミングによっては二重取り込みが発生してしまい、その時の対応を検討しなければならなくなったことがあります。
更新の反映においては、InsertのみかUpdate/Deleteも許容するかで大きく難易度が変わってくるため、Update/Deleteもシステム上はInsertで表現できないか、という検討が必要になります。
例えば、紹介されてますがETLでの取り込み時に更新日時を付加して、断面をVIEWで抽出する形になります。ただ、こちらは私も経験がありますがずっと溜まっていくと断面を抽出すること自体が負荷になってくるため、ある程度のタイミングで洗い替えをおこなうと良いと考えてます。
データ整備の基本戦略と性能の最適化
最後に、まとめとしてデータレイクに取り込んだ後、分析するためのTIPSについてデータレイクの構成とともに触れられていました。
ビジネス的な前処理
まず、データレイクに生データを取り込んだだけだと利用できないため、適切な前処理が必要になるとのお話でした。必須の前処理として具体的に以下三点が挙げられていました。
- 文字コードの変換： UTF 8 等に統合を検討
- ID の統一：システムで異なる ID を発行している場合等の対応
- 日付、表現の統一：日付の表現方式、タイムゾーン、大文字小文字 等
具体的な目的としては、他のテーブルとJOIN可能な構成にする、という点を挙げられていました。分析するためには他のデータと連携する必要があるため、こちらは当然ですね。そういえば先日 Google Cloud のイベントでAI(Duet AI)を利用してあるテーブルへの変更を他の変更にも適切に適用する、みたいな話がありました。この辺りはAIを活用するとより簡易にできるようになるかもしれませんね。
性能向上のための前処理
基本的にはAthenaでS3にアクセスするときのチューニングと同様になります。
また、S3のアクセスについては、今回のRe:inventで発表された Amazon S3 Express One Zone の機能もあります。
検証記事 （Amazon S3 Express One Zoneの性能測定をしてみた）によると、従来アンチパターン（小さい大量ファイル）の性能も向上しているため、この辺の前処理はまた別の Best Practise が出てくるかもしれません。
まとめ
再掲になりますが、既にセッションの資料は こちら にアップロードされています。本紹介Blogではいくつかのトピックを割愛してますため、内容についてはセッション資料を参照ください。
私自身、DWHを簡易データレイクとする、というような構成自体は経験がありますが、本当のクラウドネイティブなS3等のオブジェクトストレージをメインとしたデータレイクは経験がありません。今回のセッションを聞いて、ビジネス的な内容については うんうん となるところも多く、また、具体的な前処理についても触れられていたので、今後そういったプロジェクトにかかわる際には参考にしていきたいと思います。
皆さんのセッション理解の一助になれば幸いです。