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

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

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

Transcript

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

   View Slide

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

   View Slide

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

   View Slide

4. 1. 医療データ
   

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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病院 基幹システム
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

20. 3. アーキテクチャ
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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で半角英数記号の全角化とかをやりたいであり
    ます。
    

    View Slide

26. 4. 課題と対策
    

    View Slide

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

    View Slide

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のクラスメソッド石川さんの発表が非常に参考になりまし
    た。
    

    View Slide

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/
    

    View Slide

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

    View Slide

31. View Slide