Technical Challenges for Big Health Care Data. Donald Kossmann Systems Group Department of Computer Science ETH Zurich

Transcription

1 Technical Challenges for Big Health Care Data Donald Kossmann Systems Group Department of Computer Science ETH Zurich

2 What is Big Data? technologies to automate experience Purpose answer difficult questions help make difficult decisions

3 Big Data Examples What is French translation of this presentation? How long does it take from Zurich to Vitznau? Where should Migros build next supermarket? Should my bank give Donald a mortgage? Often the answer is not precise more data (experience) improves results more data (experience) good for corner cases

4 Big Data in Health Care Understanding vs. Experience Doctor: Please, take this drug. Patient: Why? Doctor: Because it works. Precision Medicine Question: find right therapy for individual patient too complex to understand the answer patients cannot wait for science more data -> more coverage of multi-morbid helps socialize health care: we are all equally rich

5 Bilder: istockphoto, Fotolia Cloud Era ERP 5

6 Challenges and Concerns Cost Where to store the data? Which technologies to use? How to get answers in most efficient way? Value Which data worth keeping? How to clense my data? Which questions make sense? Which answers? Security How to protect my data (internal and external attackers)? How do I collaborate with others who have data? Goal: Get all three aspects right! 6

7 What is special about Health Big Data? Cost data is in silos; needs to be (logically) centralized first data integration difficult due to lack of standards Value data is incomplete and imprecise (subjective statements) fatal consequences of mis-predictions Security give control to patients yet allow global analysis

8 Agenda A Sharing Architecture Processing Encrypted DAta

9 Data Silos Today clients clients clients clients clients HTTP(S) App Server App Server App Server App Server App Server SQL USZ USZ Dr. X Dr. X

10 Pros and Cons of Silos Pros Cost: proven technology Value: isolation of resources Security: well understood (as we will see) Cons Cost: expensive because no sharing of resources Value: cross-silo analytics difficult / impossible Security: on-premise security less rigorous

11 Shared Data Architecture (Cloud) clients clients clients clients clients HTTP(S) App Server App Server App Server App Server App Server SQL QP QP QP QP Storage Storage Storage

12 Metaphor Compare these two architectures with Shopping Mall vs. Amazon

13 Optimizing Shared Data Architecture In Shared Memory, access pattern is diffuse everybody wildly accesses all data nodes If indexes do not work, then optimize scans optimize for the worst case Looking at many queries, much data is relevant batch queries and kill many birds with one stone tradeoff between latency and throughput control latency (SLAs) by partitioning the data

14 Agenda A Sharing Architecture Processing Encrypted Data

15 Data in the Cloud Donald Dirk Joachim Köln Leipzig Bonn Data are not encrypted Great to process the data in the cloud Little protection against attackers 15

16 Encryption in the Cloud Joachim Donald Dirk ax$!2 A!(1T %&!ez Xz6!! Data is encrypted in the cloud. Confidentiality: Data protected against attackers. Cost: all processing on-premise with data shipping. Utility: analysis involves loss of sovereignity of data.

17 Cipherbase: Secure Co-processor Joachim %&!e% Xz6!! All computation done on secure hardware in the cloud Confidentiality: (visible) data encrypted at all times. Cost: special algorithms for tight integration. Utility: support all operations. (across silos next slide.)

18 Analytics Across Silos Joachim Donald Dirk ax$!2 %&!e% Xz6!! Donald & Joachim authorize Dirk to run specific query. Dirk only sees aggregated results. No raw data. Donald and Joachim only see their own data.

19 Why trust trusted Hardware? Three options Dedicated co-processors: e.g., IBM 4970 Extensions to commodity processors: Intel SGX Custom hardware: FPGAs We chose FPGAs no operating system (less software to trust) open source the layout available and cheap

20 Summary General ICT Trends cloud computing: industrialization of computing digitallly-born data data and infrastructure sharing Huge opportunities Big Data: answer questions we cannot answer today Role of Technology help navigate cost vs. value vs. security triangle Big Data in Health Care leverages general trends (some specifics) important to manage expectations

21 Crescando Storage Manager (idisk) A distributed (relational) table: MM on NUMA horizontally partitioned distributed within and across machines Query / update interface SELECT * FROM table WHERE <any predicate> UPDATE table SET <anything> WHERE <any predicate> Some nice properties constant / predictable latency & data freshness solves the Amadeus use case support for Snapshot Isolation, monotonic writes

22 Design Operate MM like disk in shared-nothing architect. Core ~ Spindle (many cores per machine & data center) all data kept in main memory (log to disk for recovery) each core scans one partition of data all the time Batch queries and updates: shared scans do trivial MQO (at scan level on system with single table) control read/update pattern -> no data contention Index queries / not data just as in the stream processing world predictable+optimizable: rebuild indexes every second Updates are processed before reads

23 Crescando on 1 Machine (N Cores) Scan Thread Scan Thread Input Queue (Operations) Split Scan Thread Scan Thread Merge Output Queue (Result Tuples)... Input Queue (Operations) Scan Thread Output Queue (Result Tuples)

24 {record, {query-ids} } results is Predicate Indexes Queries + Upd. qs Unindexed Queries Active Queries Record 0 records Crescando on 1 Core Snapshot n Snapshot n+1 data partition Read Cursor Write Cursor

25 Scanning a Partition Record 0 Snapshot n+1 Snapshot n Read Cursor Write Cursor

26 Scanning a Partition Record 0 Snapshot n+1 Snapshot n Read Cursor Write Cursor Merge cursors

27 Scanning a Partition Record 0 Build indexes for next batch of queries and updates Snapshot n+1 Snapshot n Read Cursor Write Cursor Merge cursors

28 Implementation Details Optimization decide for batch of queries which indexes to build runs once every second (must be fast) Query + update indexes different indexes for different kinds of predicates e.g., hash tables, R-trees, tries,... must fit in L2 cache (better L1 cache) Probe indexes Updates in right order, queries in any order Persistence & Recovery Log updates / inserts to disk (not a bottleneck)

29 Crescando vs. MySQL - Throughput Amadeus workload, vary updates Synthetic read-only workload, vary skew

30 Cipherbase: Secure Co-processor Idea: Farm out computation on encrypted data to co-processor Most database work on commodity hardware (cheap & fast) Logging, Locking / Synchronization, Buffer Management, Scheduling etc. Expressions on encrypted or (partially) homomorphically encrypted data Secure co-processor evaluates expressions on encrypted data Arithmetic, Comparisons and Intrinsics (MIN, MAX etc.) Trusted Code Base easy to verify Cloud DBMS Query Parsing Buffer Pool Resource Scheduling Logging/ Recovery Transaction Manager Locking Query Execution Access Methods SQL OS TM Encryption Key Expression Evaluation

31 TPC-C Results Normalized Throughput Plaintext Customer Strong/Weak Strong/Strong Opt NoOpt