Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

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

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

241b40d1d5f3ce3d78d576143daa0f71?s=128

小森谷 一生

March 20, 2021
Tweet

Transcript

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

  2. 自己紹介 • 名前: 小森谷 一生 • 所属: 株式会社JMDC データプラットフォーム開発本部 本部長

    • 開発: バックエンドエンジニア (Ruby, AWS) データ基盤、アドテク、ゲームAPIなど • 好きなAWSサービス: Athena • JAWS DAYS: 2年ぶり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では医療プロダクトに 挑戦したいメンバーを絶賛募集中です!! お気軽にお声がけください。

  31. None