Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

1. 医療データ

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

3. アーキテクチャ

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

4. 課題と対策

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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/

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

No content