医療データレイクで分析基盤の構築 / JAWS DAYS 2021 JMDC DATALAKE

JAWS DAYS 2021-03-20の登壇資料。
株式会社JMDCのデータレイクの取扱いについて紹介します。

https://jawsdays2021.jaws-ug.jp/timetable/track-d-1100/

Transcript

1. 医療データレイクで分析基盤の構築 小森谷 一生
2. 自己紹介 • 名前： 小森谷 一生 • 所属: 株式会社JMDC データプラットフォーム開発本部 本部長 • 開発: バックエンドエンジニア (Ruby, AWS) データ基盤、アドテク、ゲームAPIなど • 好きなAWSサービス: Athena • JAWS DAYS: ２年ぶり2回目
3. アジェンダ 1. 医療データ 2. データレイクを採用した背景 3. アーキテクチャ 4. 課題と対応
4. 1. 医療データ
5. • 「健康で豊かな人生をすべての人に」 • 医療費の増大などの社会課題に取り組む • 2019年12月東証マザーズ上場 • ロゴサポーターとしても参加！ JMDCについて
6. JMDCデータサービス • 保険者や医療機関への解析支援 • 医療の発展に繋がるデータサービスの提供
7. プロダクト① • 薬剤処方の継続や併薬、処方パターンの分析 • 医療機関内のデータ分析を行い、臨床にあったQI(診療の質指標)レポート
8. プロダクト② • 健康に関わる様々な情報を集約できるPHRサービス、PepUP • スマホで患者さんが問診を入力でき、電子カルテと連動するメルプ
9. 取り扱うデータ • レセプト、DPCなど様々な医療データ • 累積母集団数は約730万人（2020年4月時点）
10. データの提供 • AWS Data Exchangeにて COVID-19のレセプトデータの無償公開 • JMDCのデータに基づく論文やレポートの公開
11. 2. データレイクを採用した背景
12. データレイク アーキテクチャを採用した背景 1.大量の非構造化データ 2.事業ごとの分析環境の違い 3.オンプレ基幹システムのクラウド化
13. 背景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病院 基幹システム
14. • 4IJGU+*4 • ;*1ѹॖ • ϔομʔແ͠ • μϒϧΫΥʔτ͞Εͯͳ͍ΧϯϚ • ͦ΋ͦ΋ϑΝΠϧ͕͓͔͍͠ 背景1: 大量の非構造化データ
15. 背景1: 大量の非構造化データ id date code result 1 2021-03-19 1 12.6 2 2021-03-20 2 80 構造化！ エンジニア フィールドエンジニア 医療知識者
16. • 病院内の電子カルテや基幹システムに精通したフィールドエンジニアチーム • 薬剤師、看護師、検査技師などの医療系知識者チーム • 自動化を進めるエンジニアチーム 背景1: 大量の非構造化データ これらのチームで使いやすい分析データの構造化に取り組む
17. 背景2: 事業ごとの分析環境の違い a データソース b c 利用者 アウトプット 医療機関 製薬 生保 自社 自社SaaS BI CSV DWH イメージ図)
18. • レセプトやDPCデータなどデータソースにより構造性は異なってきます。それ により自社分析用や医療機関提出ようなど用途が変わってきます。 • さらにそれらを組み合わせたデータマートの構築が事業ごとのり発生する場合 もあり。 • 分析環境も利用者合わせて変わって来るのでストレージ(S3上のCSVや Paruqet)が分離されているデータレイクが利便性が高い。 背景2: 事業ごとの分析環境の違い
19. 背景3: オンプレ基幹システムのクラウド化 • データマートのスナップショットを保存する必要があり、長期的な低頻度のアク セスのデータがあり、オンプレ上でその環境を実現する負担が上がっている。 • オンプレで加工処理したデータをクラウドのDWHへ転送を行う場合の転送時 間がかなり掛かっている。 • 大幅なコストダウン
20. 3. アーキテクチャ
21. JMDCで主流の構成 Lambda S3 Athena Catalog Redshift QuickSight ETL DWH BI • ETLの前段としてLambda を利用 • ETLメイン処理としては Athena • 加工処理後、用途に合わせ コピーなどを行う
22. Lambdaでの前段ETL • CSVのファイル名に規則があり、S3のLocationを分類 • Zipの解凍、文字コード変換 • ヘッダーの状況を確認しCatalogの作成。 GlueのCrawlerは仕様していない。 • Pandasでデータの訂正
23. メインETL処理をAthenaでやる理由 • フィールエンジニアやデータサイエンティストなどの非エンジニアのSQL資産を 活かすことを考え、Sparkよりも取り扱いやすいと判断 • 比較的規模の小さなデータソースにおいてはスモールスタートが始めやすい。 Sparkの経験が無いエンジニアにも学習コストが低く開発に入りやすい。 • Athena engine version2:平均性能10〜15%UPした！
24. メインETL処理をAthenaでやるときの苦労 • getPartition Error: Partitionの多いテーブルで複数のPartitionにまたがる Queryを実行する時に内部でGlueのAPIをコールしているようで、そこの上限 でErrorが発生する。ここの上限緩和申請は無い。Queryを調整し発生頻度は 下がるが時々発生しRetryすることで乗り切る。 • AthenaでのADD PARTITIONのQueryが遅かったのだがGlueのAPIで Partion作ったら速く行えた。
25. メイン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で半角英数記号の全角化とかをやりたいであり ます。
26. 4. 課題と対策
27. 現在の課題 Data lake Data lake Data lake Data lake Data lake • 利用者の分析環境によってデータとカタログのコピーが発生し、 領域の管理が負担に。
28. 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のクラスメソッド石川さんの発表が非常に参考になりまし た。
29. 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/
30. ご清聴ありがとうございました。 JMDCでは医療プロダクトに 挑戦したいメンバーを絶賛募集中です！！ お気軽にお声がけください。