医療データレイクで分析基盤の構築 小森谷 一生

自己紹介 • 名前： 小森谷 一生 • 所属: 株式会社JMDC データプラットフォーム開発本部 本部長 • 開発: バックエンドエンジニア (Ruby, AWS) データ基盤、アドテク、ゲームAPIなど • 好きなAWSサービス: Athena • JAWS DAYS: ２年ぶり2回目

アジェンダ 1. 医療データ 2. データレイクを採用した背景 3. アーキテクチャ 4. 課題と対応

1. 医療データ

• 「健康で豊かな人生をすべての人に」 • 医療費の増大などの社会課題に取り組む • 2019年12月東証マザーズ上場 • ロゴサポーターとしても参加！ JMDCについて

JMDCデータサービス • 保険者や医療機関への解析支援 • 医療の発展に繋がるデータサービスの提供

プロダクト① • 薬剤処方の継続や併薬、処方パターンの分析 • 医療機関内のデータ分析を行い、臨床にあったQI(診療の質指標)レポート

プロダクト② • 健康に関わる様々な情報を集約できるPHRサービス、PepUP • スマホで患者さんが問診を入力でき、電子カルテと連動するメルプ

取り扱うデータ • レセプト、DPCなど様々な医療データ • 累積母集団数は約730万人（2020年4月時点）

データの提供 • AWS Data Exchangeにて COVID-19のレセプトデータの無償公開 • JMDCのデータに基づく論文やレポートの公開

2. データレイクを採用した背景

データレイク アーキテクチャを採用した背景 1.大量の非構造化データ 2.事業ごとの分析環境の違い 3.オンプレ基幹システムのクラウド化

背景1: 大量の非構造化データ 患者ID 検査日 検査名 結果 1 21/03/19 尿酸 12.6 2 21/03/20 血糖 80 ID DATE CODE RESULT 1 2021-03-19 AA ++ 2 2021-03-20 BB (-) A病院 基幹システム B病院 基幹システム

• 4IJGU+*4 • ;*1ѹॖ • ϔομʔແ͠ • μϒϧΫΥʔτ͞Εͯͳ͍ΧϯϚ • ͦ΋ͦ΋ϑΝΠϧ͕͓͔͍͠ 背景1: 大量の非構造化データ

背景1: 大量の非構造化データ id date code result 1 2021-03-19 1 12.6 2 2021-03-20 2 80 構造化！ エンジニア フィールドエンジニア 医療知識者

• 病院内の電子カルテや基幹システムに精通したフィールドエンジニアチーム • 薬剤師、看護師、検査技師などの医療系知識者チーム • 自動化を進めるエンジニアチーム 背景1: 大量の非構造化データ これらのチームで使いやすい分析データの構造化に取り組む

背景2: 事業ごとの分析環境の違い a データソース b c 利用者 アウトプット 医療機関 製薬 生保 自社 自社SaaS BI CSV DWH イメージ図)

• レセプトやDPCデータなどデータソースにより構造性は異なってきます。それ により自社分析用や医療機関提出ようなど用途が変わってきます。 • さらにそれらを組み合わせたデータマートの構築が事業ごとのり発生する場合 もあり。 • 分析環境も利用者合わせて変わって来るのでストレージ(S3上のCSVや Paruqet)が分離されているデータレイクが利便性が高い。 背景2: 事業ごとの分析環境の違い

背景3: オンプレ基幹システムのクラウド化 • データマートのスナップショットを保存する必要があり、長期的な低頻度のアク セスのデータがあり、オンプレ上でその環境を実現する負担が上がっている。 • オンプレで加工処理したデータをクラウドのDWHへ転送を行う場合の転送時 間がかなり掛かっている。 • 大幅なコストダウン

3. アーキテクチャ

JMDCで主流の構成 Lambda S3 Athena Catalog Redshift QuickSight ETL DWH BI • ETLの前段としてLambda を利用 • ETLメイン処理としては Athena • 加工処理後、用途に合わせ コピーなどを行う

Lambdaでの前段ETL • CSVのファイル名に規則があり、S3のLocationを分類 • Zipの解凍、文字コード変換 • ヘッダーの状況を確認しCatalogの作成。 GlueのCrawlerは仕様していない。 • Pandasでデータの訂正

メインETL処理をAthenaでやる理由 • フィールエンジニアやデータサイエンティストなどの非エンジニアのSQL資産を 活かすことを考え、Sparkよりも取り扱いやすいと判断 • 比較的規模の小さなデータソースにおいてはスモールスタートが始めやすい。 Sparkの経験が無いエンジニアにも学習コストが低く開発に入りやすい。 • Athena engine version2:平均性能10〜15%UPした！

メインETL処理をAthenaでやるときの苦労 • getPartition Error: Partitionの多いテーブルで複数のPartitionにまたがる Queryを実行する時に内部でGlueのAPIをコールしているようで、そこの上限 でErrorが発生する。ここの上限緩和申請は無い。Queryを調整し発生頻度は 下がるが時々発生しRetryすることで乗り切る。 • AthenaでのADD PARTITIONのQueryが遅かったのだがGlueのAPIで Partion作ったら速く行えた。

メインETL処理をAthenaでやるときの苦労 • より高速化させたいためにEMR Prestoを試してみる。 • Athena: 8秒くらいのクエリ • EMR Presto: m5.2xlarge x 30TASK 24秒くらい • getPartitionのAPI問題はEMR Prestoでも発生 • Athenaコスパいいー！となり戻ってくる。 • UDFが2019/11にPreview版で一部のRegionにサポートされたが、それ以来 音沙汰がない。Tokyo Regionで半角英数記号の全角化とかをやりたいであり ます。

4. 課題と対策

現在の課題 Data lake Data lake Data lake Data lake Data lake • 利用者の分析環境によってデータとカタログのコピーが発生し、 領域の管理が負担に。

Redshift lake house architecture BigData – JAWS #16 Lake House Architecture Pattern クラスメソッド 石川さん https://dev.classmethod.jp/articles/20210301-bigdata-jaws-16-lake-house- architecture-pattern/ • こういった課題の対応へRedshift lake house architectureとして、Redshift Spectrumを中心とする構成に向けてAWSより新機能がGAされている。 • BigData – JAWS#16のクラスメソッド石川さんの発表が非常に参考になりまし た。

Amazon Redshift を使用したレイクハウスアーキテクチャの ETL および ELT 設計パターン: パート 1 https://aws.amazon.com/jp/blogs/news/etl-and-elt-design-patterns-for-lake-house-architecture- using-amazon-redshift-part-1/

ご清聴ありがとうございました。 JMDCでは医療プロダクトに 挑戦したいメンバーを絶賛募集中です！！ お気軽にお声がけください。

No content