⚠️ Lưu ý: Các thông tin dưới đây chỉ nhằm mục đích tham khảo, vui lòng không sao chép nguyên văn cho bài báo cáo của bạn kể cả warning này.
Các data lake có thể giúp các bệnh viện và cơ sở y tế chuyển dữ liệu thành những thông tin chi tiết về doanh nghiệp và duy trì hoạt động kinh doanh liên tục, đồng thời bảo vệ quyền riêng tư của bệnh nhân. Data lake là một kho lưu trữ tập trung, được quản lý và bảo mật để lưu trữ tất cả dữ liệu của bạn, cả ở dạng ban đầu và đã xử lý để phân tích. data lake cho phép bạn chia nhỏ các kho chứa dữ liệu và kết hợp các loại phân tích khác nhau để có được thông tin chi tiết và đưa ra các quyết định kinh doanh tốt hơn.
Bài đăng trên blog này là một phần của loạt bài lớn hơn về việc bắt đầu cài đặt data lake dành cho lĩnh vực y tế. Trong bài đăng blog cuối cùng của tôi trong loạt bài, “Bắt đầu với data lake dành cho lĩnh vực y tế: Đào sâu vào Amazon Cognito”, tôi tập trung vào các chi tiết cụ thể của việc sử dụng Amazon Cognito và Attribute Based Access Control (ABAC) để xác thực và ủy quyền người dùng trong giải pháp data lake y tế. Trong blog này, tôi trình bày chi tiết cách giải pháp đã phát triển ở cấp độ cơ bản, bao gồm các quyết định thiết kế mà tôi đã đưa ra và các tính năng bổ sung được sử dụng. Bạn có thể truy cập các code samples cho giải pháp tại Git repo này để tham khảo.
Thay đổi chính kể từ lần trình bày cuối cùng của kiến trúc tổng thể là việc tách dịch vụ đơn lẻ thành một tập hợp các dịch vụ nhỏ để cải thiện khả năng bảo trì và tính linh hoạt. Việc tích hợp một lượng lớn dữ liệu y tế khác nhau thường yêu cầu các trình kết nối chuyên biệt cho từng định dạng; bằng cách giữ chúng được đóng gói riêng biệt với microservices, chúng ta có thể thêm, xóa và sửa đổi từng trình kết nối mà không ảnh hưởng đến những kết nối khác. Các microservices được kết nối rời thông qua tin nhắn publish/subscribe tập trung trong cái mà tôi gọi là “pub/sub hub”.
Giải pháp này đại diện cho những gì tôi sẽ coi là một lần lặp nước rút hợp lý khác từ last post của tôi. Phạm vi vẫn được giới hạn trong việc nhập và phân tích cú pháp đơn giản của các HL7v2 messages được định dạng theo Quy tắc mã hóa 7 (ER7) thông qua giao diện REST.
Kiến trúc giải pháp bây giờ như sau:
Hình 1. Kiến trúc tổng thể; những ô màu thể hiện những dịch vụ riêng biệt.
Mặc dù thuật ngữ microservices có một số sự mơ hồ cố hữu, một số đặc điểm là chung:
Khi xác định vị trí tạo ranh giới giữa các microservices, cần cân nhắc:
| Phạm vi giao tiếp | Các công nghệ / mô hình cần xem xét |
|---|---|
| Trong một microservice | Amazon Simple Queue Service (Amazon SQS), AWS Step Functions |
| Giữa các microservices trong một dịch vụ | AWS CloudFormation cross-stack references, Amazon Simple Notification Service (Amazon SNS) |
| Giữa các dịch vụ | Amazon EventBridge, AWS Cloud Map, Amazon API Gateway |
Việc sử dụng kiến trúc hub-and-spoke (hay message broker) hoạt động tốt với một số lượng nhỏ các microservices liên quan chặt chẽ.
Nhược điểm: cần phối hợp và giám sát để tránh microservice xử lý nhầm message.
Cung cấp dữ liệu nền tảng và lớp truyền thông, gồm:
Chỉ cho phép truy cập ghi gián tiếp vào data lake qua hàm Lambda → đảm bảo nhất quán.
Ví dụ outputs trong core microservice:
Outputs:
Bucket:
Value: !Ref Bucket
Export:
Name: !Sub ${AWS::StackName}-Bucket
ArtifactBucket:
Value: !Ref ArtifactBucket
Export:
Name: !Sub ${AWS::StackName}-ArtifactBucket
Topic:
Value: !Ref Topic
Export:
Name: !Sub ${AWS::StackName}-Topic
Catalog:
Value: !Ref Catalog
Export:
Name: !Sub ${AWS::StackName}-Catalog
CatalogArn:
Value: !GetAtt Catalog.Arn
Export:
Name: !Sub ${AWS::StackName}-CatalogArn