小売店データ統合基盤における受信機能開発
## 技術スタック Python, PySpark, EC2, RDS, S3, Lambda, AWS_SNS ## システム概要 小売店パネルデータ集計基盤のリプレース開発 その基幹系のうち、小売店様より受領するローデータの受信機能開発を行った。 当該システムは各小売チェーンから日次、週次、月次、隔月様々な粒度のサマリーデータ、あるいはレシート単位のジャーナルデータを24時間365日受領している。常にファイルを待ち受ける部分と、その受け取ったファイルにフラグ付やバリデーション、フォーマット変換等を行い一つのデータレイクへ集約させていく処理部分を「受信機能」と称した。私はこの受信機能開発を担当した。 ## システム開発の背景 * 既存の小売店パネルデータの精度低下を改善したい * より細かいデータ粒度を扱えるようにして新しい分析を可能にしたい * リアル店の売上に加え、ECの売上情報も加算した結果が見たい 以上の目的を達成するため、既存システムのリプレースおよび機能追加が行われた。 その中でデータの粒度や総量、および処理速度を大幅にあげるため、既存のRDBを基軸とした設計では運用に耐えうるプロダクト開発が困難であることが判明。より早く、より正確な情報をお客様へご提供するため、分散処理フレームワークやDWHを基軸とした設計に変更し技術基盤の検証からプロダクト開発まで実施することが求められた。 そのようなシステムの基幹系を開発するチームにいた私は、通常のCSVファイルとして受領する様々な種類の売上データを検証・フォーマット変換してデータレイクへ蓄積する受信機構の開発を担当した。 ## 取り組んだこと ### 技術基盤検証 圧縮効率や転送スピードの面でどの技術が適切かを比較・実証・検証する。ファイル圧縮方法の選定、S3とEC2その他各種マネージドサービス間の転送速度等、一番システムに適合するものは何かを実証していった。 後続の処理でEMRを利用すること、および圧縮してS3のコストを抑えることを目的に、snappy圧縮のpaquet形式でファイルをアウトプットする方針を採用。 また受信処理機構ではコア数の利用可能上限等を比較検討し、PySparkを採用。 以上の結論に至るため、私は候補となる技術基盤をピックアップし、検証のための実装、検証結果のまとめと説明を行った。 ### 実装 上記までの要件と基盤選定結果から、小さな１ファイルを短時間で処理するという本来の設計思想から外れた方法でPySparkを実装する必要があった。 HDFSの代わりにEBSを使い、PySpark専用S3転送ライブラリではなくAWSCLIを採用するなど、トリッキーではあるものの実証を重ねて最適な実装を探しながら組み上げた。 また、バリデーション項目も多く各種マスタとの照合も必要とされていたため、目標の三倍以上の処理時間が当初かかっていたが、全体設計を眺めつつ設計や仕様そのものに余分がないかを確認し組み替えていくことで、不要な機能を削除したり後続の処理に組み入れ目的の処理速度を達成した。 ## 得られたもの * 技術検証、実装、テストを小さなサイクルとして回していくことで、新技術を適用するときのものの考え方を身に付けることができた。 * 実装は設計や基盤選定と密接に関わっており、大局的な視点から目の前の作業の地を見定めて、最適解を得ること、必要であれば与件を変更することも重要であることを学んだ。 * 大規模データ基盤の実装方法や構成の手つきを学ぶことができた