ECI与K8S在医疗行业及人工智能中的应用

1、ECI与K8S在医疗行业及人工智能中的应用技术创新，变革未来医疗行业的数据特点基于阿里云ECS+OSS+MNS的部署基于K8S的部署基于K8S+ECI的部署目录医疗行业的数据特点AI其他领域数据：UCR：100KB/SampleImageNet：2MB/Sample医疗行业常见数据：常规心电图：1MB/SampleCT影像：2MB/Sample越光长程面临的挑战我们采集的数据采样率256Hz采样时间：30天总采样点：256*86400*30=663552000采样点每个采样点16Bits（2bytes）总大小：1265MB/每次检查需要最短时间内（持续提升）完成海量数据 的精准分析阿里云监控数

2、据每15秒采样一次每个月4*60*24*30=1728000100200300400500600700一个病人/月100台ECS*10个监控指标/月百万长时间监测的意义心律失常的“一过性”特点：阵发、偶发。最短可以5秒定义一个心脏危险心律失常的“隐匿性”特点：没有伴随症状，或睡梦中发生。无从知晓危害性与发作频率不一定相关：比如猝死、晕厥，或心梗，可能一个月，甚至半年发生 一次，造成死亡或心脏永久性损伤国外大量临床研究证实，且写入国际临床指南：监测时长是诊断产出率的决定性因素：7天比24小时高3-4倍而可穿戴性和续航能力是影响监测时长的决定性因素越光普氏贴心越光贴心满足国家和国际最新行业标准的I

3、I类医疗器械心电诊断类产品 动态心电图机市场独有性能：民用纽扣电池支持最长30天连续记录配套专业软件分析算法准确性（FDA和国家药监局要求的标准数据库）：心跳判定 99.8%，房颤判定 100%临床诊断结果对照结论：一致性达到97.9% - 100%传统心电图机传统动态心电图机VS.基于阿里云ECS+OSS+MNS的部署采用OSS接收医院数据多地域尽可能靠近客户（杭州、北京、成都、印度等）医院网络情况复杂/不佳，使用OSS可以获得尽可能快的速度流量不均衡，OSS按流量计费性价比更高123456789101112131415161718192021222324基于阿里云ECS+OSS+MNS的部

4、署数据上传（数百M非结构化数据）：通过ECS转发优点：实现简单，经典应 用直接迁移缺点：受限于ECS网络条件，OSS仅充云盘角色OSS直传优点：效率高、稳定性 好，最大化OSS能力缺点：无法复用API的身份验证，需要为直传做独立 的身份与权限验证基于阿里云ECS+OSS+MNS的部署客户端直传OSS的权限控制常见方法：优点缺点客户端内嵌Access Key开发方便非常不安全，即使使用了RAM子用户，如 果AK被窃取，仍然有仿冒用户、重新下 发AK的问题STS TokenOSS文档最佳实践-移动应用端直传中的 推荐方案每次创建专用STS Token，通常使用目录 或通配符构建JSON进行设置，对

5、具体文 件进行授权的话则较繁琐请求签名（Header/URL）可以精准控制权限（例如，服务器端指 定文件名的PUT方法），不指定文件名则 存在客户端恶意指定文件名覆盖现有文 件的风险。无需调用STS等服务，减少依 赖官方文档相对简单，相比较以上两种方 法，隐藏较深且缺少示例早期SDK支持不佳，需要自行签名基于阿里云ECS+OSS+MNS的部署数据自动处理：数据上传至 OSS进入MNS队 列ECS监听MNS进行数据处 理ESS弹性伸 缩ECS原生ESS无法根 据MNS消息堆积 数量进行伸缩ECS连续处 理数据，数 据间不隔离MNS只保证每条消息至 少被消费一次，一条 数据可能被多次消费基于K8S

6、的部署数据自动处理：数据上传至 OSS创建Job分析数据K8S集群服务ECS创建并加入节约约需10分钟依赖于负载检测的伸缩，存在延 时（例如5分钟）依赖于平均CPU使用率的缩容可能缩减扔在运行任务的节点依赖于ECS规格，不够灵活MNS只保证每条消息至少 被消费一次，一条数 据可能被多次消费ECS连续处 理数据，数据 间不隔离基于K8S+ECI的部署数据自动处理：数据上传至 OSS创建Job分析数据ECI(ASK)集群ECI与Job一一对应极速启动（配合ECI 2.0的CRD，1分 钟内就绪）任务结束立刻销毁灵活的CPU/Memory比例Spot（便宜）、GPU（快速）的支持基于K8S+ECI的

7、部署ESS vs ECI 实战分析情况1：当前集群满载，新数据待分析（2CPU分析时间15分钟）基于K8S+ECI的部署ESS vs ECI 实战分析情况2：当前集群满载，两个新数据相隔一分钟传至OSS1.2.ESS：第一个任务到达，创建1个ECS并加入集群，总耗时 10+15+5=30分钟第二个任务到达，因为数据1在1分钟前已经触发了伸 缩，导致ESS在沉默期（必须设置沉默期，否则在节点 就绪前会不断创建新ECS直至抵达伸缩组上限），第二 个任务最终在第一个ECS沉默期结束后（假设15分钟）， 开始创建。总耗时15+10+15+5=45分钟ECI：任务到达即立刻创建ECI实例并运行。两个任务

8、各 耗时1+15=16分钟基于K8S+ECI的部署ESS vs ECI 实战分析情况3：当前集群满载，两个新数据相隔一分钟传至OSS，两个数据相差较大，一个需2CPU，15分钟，另 外一个需要2CPU，30分钟，ESS伸缩规格配置为4CPUESS：总计费时间： 10+30+5=45分钟*4CPU=180 CPU分钟ECI：任务到达即立刻创建ECI实例并运行。第一个任务耗时1+15=16分钟*2CPU=32 CPU分钟第二个任务耗时1+30=31分钟*2CPU=64 CPU分钟总计费时间：32+64=96 CPU分钟基于K8S+ECI的部署ESS vs ECI 实战分析情况4：使用GPU进行推理（CPU需时30分钟的数据，GPU约需时2分钟）基于K8S+ECI的部署ESS vs ECI 总结ECI不适用的场景：ECI每个实例均需要单独拉取镜像、挂载磁盘等。ECI2.0的CRD可以大幅提高该速度，但如果所需镜像特别特别大，并且 节点持续运行的情况下，同一ECS实例执行多个任务的响应时间较ECI更低ESSEC