ECI与K8S在医疗行业及人工智能中的应用
合集下载
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
赖
官方文档相对简单，相比较以上两种方 法，隐藏较深且缺少示例
早期SDK支持不佳，需要自行签名
基于阿里云ECS+OSS+MNS的部署
• 数据自动处理：
进入MNS队 列
数据上传至 OSS
ECS监听MNS 进行数据处
理
MNS只保证每条消息至 少被消费一次，一条 数据可能被多次消费
ECS连续处 理数据，数 据间不隔离
ECI与K8S在医疗行业及人工智能中的应用
技术创新，变革未来
目录
❖ 医疗行业的数据特点 ❖ 基于阿里云ECS+OSS+MNS的部署 ❖ 基于K8S的部署 ❖ 基于K8S+ECI的部署
医疗行业的数据特点
• AI其他领域数据： • UCR：~100KB/Sample
• 医疗行业常见数据： • 常规心电图：~1MB/Sample
基于K8S+ECI的部署
• ESS vs ECI 实战分析 ➢ 情况3：当前集群满载，两个新数据相隔一分钟传至OSS，两个数据相差较大，一个需2CPU，15分钟，另
外一个需要2CPU，30分钟，ESS伸缩规格配置为4CPU
ESS：总计费时间： 10+30+5=45分钟*4CPU =180 CPU分钟
ECI：任务到达即立刻创建ECI实例并运行。 1. 第一个任务耗时1+15=16分钟*2CPU=32 CPU分钟 2. 第二个任务耗时1+30=31分钟*2CPU=64 CPU分钟 3. 总计费时间：32+64=96 CPU分钟
基于K8S+ECI的部署
• ESS vs ECI 实战分析 ➢ 情况4：使用GPU进行推理（CPU需时30分钟的数据，GPU约需时2分钟）
ECI(ASK)集群
基于K8S+ECI的部署
• ESS vs ECI 实战分析 ➢ 情况1：当前集群满载，新数据待分析（2CPU分析时间15分钟）
基于K8S+ECI的部署
• ESS vs ECI 实战分析 ➢ 情况2：当前集群满载，两个新数据相隔一分钟传至OSS
ESS： 1. 第一个任务到达，创建1个ECS并加入集群，总耗时
发AK的问题
OSS文档最佳实践-移动应用端直传中的 推荐方案
每次创建专用STS Token，通常使用目录 或通配符构建JSON进行设置，对具体文
件进行授权的话则较繁琐
可以精准控制权限（例如，服务器端指 定文件名的PUT方法），不指定文件名则 存在客户端恶意指定文件名覆盖现有文 件的风险。无需调用STS等服务，减少依
• 依赖于ECS规格，不够灵活
K8S集群服务
ECS连续处 理数据， 数据间不隔 离
基于K8S+ECI的部署
• 数据自动处理：
创建Job分析数据
数据上传至 OSS
• ECI与Job一一对应 • 极速启动（配合ECI 2.0的CRD，1分
钟内就绪）
• 任务结束立刻销毁 • 灵活的CPU/Memory比例 • Spot（便宜）、GPU（快速）的支持
的精 每个月4*60*24*30=172800
百万
700
600
500
400
300
200
100
0
一个病人/月
100台ECS
*10个监控指标/月
长时间监测的意义
• 心律失常的“一过性”特点：阵发、偶发。最短可以5秒定义一个心脏危险 • 心律失常的“隐匿性”特点：没有伴随症状，或睡梦中发生。无从知晓 • 危害性与发作频率不一定相关：比如猝死、晕厥，或心梗，可能一个月，甚至半年发生
10+15+5=30分钟 2. 第二个任务到达，因为数据1在1分钟前已经触发了伸 缩
，导致ESS在沉默期（必须设置沉默期，否则在节点 就 绪前会不断创建新ECS直至抵达伸缩组上限），第二 个 任务最终在第一个ECS沉默期结束后（假设15分钟）， 开始创建。总耗时15+10+15+5=45分钟
ECI：任务到达即立刻创建ECI实例并运行。两个任务各 耗时1+15=16分钟
一次，造成死亡或心脏永久性损伤
• 国外大量临床研究证实，且写入国际临床指南： • 监测时长是诊断产出率的决定性因素：7天比24小时高3-4倍 • 而可穿戴性和续航能力是影响监测时长的决定性因素
越光普氏贴心®
• 满足国家和国际最新行业标准的II类医疗器械 • 心电诊断类产品 – 动态心电图机 • 市场独有性能：民用纽扣电池支持最长30天连续记录 • 配套专业软件分析算法准确性（FDA和国家药监局要求的标准数据库）：心跳判定
原生ESS无法根 据MNS消息堆积 数量进行伸缩
ESS弹性伸 缩ECS
基于K8S的部署
• 数据自动处理：
创建Job分析数据
数据上传至 OSS
MNS只保证每条消息 至少 被消费一次，一 条数 据可能被多次 消费
• ECS创建并加入节约约需10分钟 • 依赖于负载检测的伸缩，存在延
时（例如5分钟）
• 依赖于平均CPU使用率的缩容可能 缩减扔在运行任务的节点
基于K8S+ECI的部署
• ESS vs ECI 总结
启动并加入集群的时间 运行负载 清理时间
连续扩容间隔时间 缩容策略
ESS CPU：~10分钟 GPU：~15分钟 视同一实例运行Job数量而定
视ESS设定，通常>5分钟
视ESS沉默时间设置，集群场景下通常>10分钟（不低于节点创建并加入集群的时间）
需要精细设定
ECI CPU：<1分钟 GPU：<1分钟
>90%
0
无限制
不适用
• ECI不适用的场景：ECI每个实例均需要单独拉取镜像、挂载磁盘等。ECI2.0的CRD可以大幅提高该速度，但如果所需镜像特别特别大，并且 节点持续运行的情况下，同一ECS实例执行多个任务的响应时间较ECI更低
Thank you !
99.8%，房颤判定 100%
• 临床诊断结果对照结论：一致性达到97.9% - 100%
传统心电图机
传统动态心电图机
越光贴心
VS.
基于阿里云ECS+OSS+MNS的部署
• 采用OSS接收医院数据 • 多地域尽可能靠近客户（杭州、北京、成都、印度等）
• 医院网络情况复杂/不佳，使用OSS可以获得尽可能快的速度 • 流量不均衡，OSS按流量计费性价比更高
• ImageNet：~2MB/Sample
• CT影像：~2MB/Sample
越光长程面临的挑战
我们采集的数据 • 采样率256Hz • 采样时间：30天 • 总采样点： • 256*86400*30=663552000采样点 • 每个采样点16Bits（2bytes） • 总大小：1265MB/每次检查 • 需要最短时间内（持续提升）完成海量数据
好，最大化OSS能力
缺点：无法复用API的身份 验证，需要为直传做独立
的身份与权限验证
基于阿里云ECS+OSS+MNS的部署
• 客户端直传OSS的权限控制 • 常见方法：
优点
缺点
客户端内嵌Access Key STS Token
请求签名（Header/URL）
开发方便
非常不安全，即使使用了RAM子用户，如 果AK被窃取，仍然有仿冒用户、重新下
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
基于阿里云ECS+OSS+MNS的部署
• 数据上传（数百M非结构化数据）：
通过ECS转发 优点：实现简单，经典应
用直接迁移
缺点：受限于ECS网络条 件，OSS仅充云盘角色
OSS直传 优点：效率高、稳定性
官方文档相对简单，相比较以上两种方 法，隐藏较深且缺少示例
早期SDK支持不佳，需要自行签名
基于阿里云ECS+OSS+MNS的部署
• 数据自动处理：
进入MNS队 列
数据上传至 OSS
ECS监听MNS 进行数据处
理
MNS只保证每条消息至 少被消费一次，一条 数据可能被多次消费
ECS连续处 理数据，数 据间不隔离
ECI与K8S在医疗行业及人工智能中的应用
技术创新，变革未来
目录
❖ 医疗行业的数据特点 ❖ 基于阿里云ECS+OSS+MNS的部署 ❖ 基于K8S的部署 ❖ 基于K8S+ECI的部署
医疗行业的数据特点
• AI其他领域数据： • UCR：~100KB/Sample
• 医疗行业常见数据： • 常规心电图：~1MB/Sample
基于K8S+ECI的部署
• ESS vs ECI 实战分析 ➢ 情况3：当前集群满载，两个新数据相隔一分钟传至OSS，两个数据相差较大，一个需2CPU，15分钟，另
外一个需要2CPU，30分钟，ESS伸缩规格配置为4CPU
ESS：总计费时间： 10+30+5=45分钟*4CPU =180 CPU分钟
ECI：任务到达即立刻创建ECI实例并运行。 1. 第一个任务耗时1+15=16分钟*2CPU=32 CPU分钟 2. 第二个任务耗时1+30=31分钟*2CPU=64 CPU分钟 3. 总计费时间：32+64=96 CPU分钟
基于K8S+ECI的部署
• ESS vs ECI 实战分析 ➢ 情况4：使用GPU进行推理（CPU需时30分钟的数据，GPU约需时2分钟）
ECI(ASK)集群
基于K8S+ECI的部署
• ESS vs ECI 实战分析 ➢ 情况1：当前集群满载，新数据待分析（2CPU分析时间15分钟）
基于K8S+ECI的部署
• ESS vs ECI 实战分析 ➢ 情况2：当前集群满载，两个新数据相隔一分钟传至OSS
ESS： 1. 第一个任务到达，创建1个ECS并加入集群，总耗时
发AK的问题
OSS文档最佳实践-移动应用端直传中的 推荐方案
每次创建专用STS Token，通常使用目录 或通配符构建JSON进行设置，对具体文
件进行授权的话则较繁琐
可以精准控制权限（例如，服务器端指 定文件名的PUT方法），不指定文件名则 存在客户端恶意指定文件名覆盖现有文 件的风险。无需调用STS等服务，减少依
• 依赖于ECS规格，不够灵活
K8S集群服务
ECS连续处 理数据， 数据间不隔 离
基于K8S+ECI的部署
• 数据自动处理：
创建Job分析数据
数据上传至 OSS
• ECI与Job一一对应 • 极速启动（配合ECI 2.0的CRD，1分
钟内就绪）
• 任务结束立刻销毁 • 灵活的CPU/Memory比例 • Spot（便宜）、GPU（快速）的支持
的精 每个月4*60*24*30=172800
百万
700
600
500
400
300
200
100
0
一个病人/月
100台ECS
*10个监控指标/月
长时间监测的意义
• 心律失常的“一过性”特点：阵发、偶发。最短可以5秒定义一个心脏危险 • 心律失常的“隐匿性”特点：没有伴随症状，或睡梦中发生。无从知晓 • 危害性与发作频率不一定相关：比如猝死、晕厥，或心梗，可能一个月，甚至半年发生
10+15+5=30分钟 2. 第二个任务到达，因为数据1在1分钟前已经触发了伸 缩
，导致ESS在沉默期（必须设置沉默期，否则在节点 就 绪前会不断创建新ECS直至抵达伸缩组上限），第二 个 任务最终在第一个ECS沉默期结束后（假设15分钟）， 开始创建。总耗时15+10+15+5=45分钟
ECI：任务到达即立刻创建ECI实例并运行。两个任务各 耗时1+15=16分钟
一次，造成死亡或心脏永久性损伤
• 国外大量临床研究证实，且写入国际临床指南： • 监测时长是诊断产出率的决定性因素：7天比24小时高3-4倍 • 而可穿戴性和续航能力是影响监测时长的决定性因素
越光普氏贴心®
• 满足国家和国际最新行业标准的II类医疗器械 • 心电诊断类产品 – 动态心电图机 • 市场独有性能：民用纽扣电池支持最长30天连续记录 • 配套专业软件分析算法准确性（FDA和国家药监局要求的标准数据库）：心跳判定
原生ESS无法根 据MNS消息堆积 数量进行伸缩
ESS弹性伸 缩ECS
基于K8S的部署
• 数据自动处理：
创建Job分析数据
数据上传至 OSS
MNS只保证每条消息 至少 被消费一次，一 条数 据可能被多次 消费
• ECS创建并加入节约约需10分钟 • 依赖于负载检测的伸缩，存在延
时（例如5分钟）
• 依赖于平均CPU使用率的缩容可能 缩减扔在运行任务的节点
基于K8S+ECI的部署
• ESS vs ECI 总结
启动并加入集群的时间 运行负载 清理时间
连续扩容间隔时间 缩容策略
ESS CPU：~10分钟 GPU：~15分钟 视同一实例运行Job数量而定
视ESS设定，通常>5分钟
视ESS沉默时间设置，集群场景下通常>10分钟（不低于节点创建并加入集群的时间）
需要精细设定
ECI CPU：<1分钟 GPU：<1分钟
>90%
0
无限制
不适用
• ECI不适用的场景：ECI每个实例均需要单独拉取镜像、挂载磁盘等。ECI2.0的CRD可以大幅提高该速度，但如果所需镜像特别特别大，并且 节点持续运行的情况下，同一ECS实例执行多个任务的响应时间较ECI更低
Thank you !
99.8%，房颤判定 100%
• 临床诊断结果对照结论：一致性达到97.9% - 100%
传统心电图机
传统动态心电图机
越光贴心
VS.
基于阿里云ECS+OSS+MNS的部署
• 采用OSS接收医院数据 • 多地域尽可能靠近客户（杭州、北京、成都、印度等）
• 医院网络情况复杂/不佳，使用OSS可以获得尽可能快的速度 • 流量不均衡，OSS按流量计费性价比更高
• ImageNet：~2MB/Sample
• CT影像：~2MB/Sample
越光长程面临的挑战
我们采集的数据 • 采样率256Hz • 采样时间：30天 • 总采样点： • 256*86400*30=663552000采样点 • 每个采样点16Bits（2bytes） • 总大小：1265MB/每次检查 • 需要最短时间内（持续提升）完成海量数据
好，最大化OSS能力
缺点：无法复用API的身份 验证，需要为直传做独立
的身份与权限验证
基于阿里云ECS+OSS+MNS的部署
• 客户端直传OSS的权限控制 • 常见方法：
优点
缺点
客户端内嵌Access Key STS Token
请求签名（Header/URL）
开发方便
非常不安全，即使使用了RAM子用户，如 果AK被窃取，仍然有仿冒用户、重新下
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
基于阿里云ECS+OSS+MNS的部署
• 数据上传（数百M非结构化数据）：
通过ECS转发 优点：实现简单，经典应
用直接迁移
缺点：受限于ECS网络条 件，OSS仅充云盘角色
OSS直传 优点：效率高、稳定性