点击上方蓝字“Linux宝库”共同关注！
今天是初六，初六送穷，送穷的最好方法莫过于“撸起袖子加油干”，据说很多小伙伴已经开始工作了。今天就给大家上一篇技术干货，祝大家来年都能勤劳致富！
——编者按
应用系统如何实现与对象存储的无缝对接？
最近几年，对象存储的优势正在被越来越多的认识，已经有很多文献阐述为什么要使用对象存储，这里不再赘述。但是仍然有许多用户在考虑从传统文件系统转向对象存储时心存疑虑，主要是担心应用对接问题。但事实上在我们过去两年的实践中发现，很多用户的应用对接对象存储比想象中容易得多，许多时候用户仅仅要做一些配置，不需要对应用做任何修改或者二次开发，即可成功对接对象存储。而且往往可以同时使用对象存储和传统文件系统，在应用了新的对象存储的同时，仍然不丢弃已购买的传统存储。
本文将举两个例子说明对象存储是如何无缝对接应用系统的，分别是非结构化和结构化数据。
非结构化数据，影像存储
影像存储的需求在许多行业里都存在，例如：遥感影像（请参考致敬SpaceX，奥思数据对象存储航天品质服务航天项目），银行的柜台、后督等业务中用到的票据影像和人脸图像，法院、检察院的证物照片和电子卷宗等。
这里我们以医疗影像为例说明对象存储是如何接入的。随着医疗行业的发展，CT、MR、X光、超声等数字医疗影像的精度和数量不断提高，远程调阅场景越来越普遍，医疗影像也是精准医疗、智能医疗的重要输入。
PACS组件示意图
支持医疗影像存储、管理和调阅的系统被称之为PACS（Picture Archiving and Communication Systems）。PACS中用到存储的主要有两个部分
1.符合DICOM标准的元数据（Metadata），记录了影像采集的时间、采集设备、图像格式、病人相关信息等，这部分是结构化数据，条目很多，对搜索效率要求高，但是数据量不大，适用于使用传统阵列。
2.医疗影像数据本身，这部分是非结构化数据，数据量较大，随着诊断设备的升级和增多，数据量增长也较快，适合使用对象存储。
以前医疗影像数据主要放在文件系统，比如NAS设备中。随着数据量的增长，使用传统文件系统存储医疗影像数据，访问效率下降的挑战和存储扩容、数据迁移带来的停机时间的挑战越来越大。对于患者来说，时间就是生命。采用对象存储能够有效提高系统可用性，降低数据不可访问的风险。
医院等用户对于用对象存储替代NAS等传统文件系统的主要担心在于：PACS系统调用存储的接口，可以很好地兼容符合POSIX标准的文件系统，是否能兼容对象存储未知。
但实际上目前很多PACS系统，已经能够支持对象存储。以开源PACS系统Dicoogle为例，其架构如下图所示：
图中“Storage”就是对接存储的组件，可见Dicoogle是可以支持S3对象存储的，我们经过测试，验证了Dicoogle可以很好地对接兼容S3接口的对象存储系统。这里是以开源PACS举例，其他商用PACS和ECM（Enterprise Content Management，企业级内容管理）系统也类似。
结构化数据，大数据分析
这类应用场景在许多行业都会遇到，百TB、PB级的结构化数据存储与分析。是的，你没看错，是结构化数据。许多人认为对象存储适用于非结构化数据如影像、视频的存储，但实际上结构化数据的规模增长到一定程度，传统的存储系统也会遇到可扩展性、访问效率和可用性问题，而对象存储目前已经有了很好地支持结构化数据（俗称“数据库”）的方案。
开源领域用得比较多的两种结构化大数据方案：Hadoop Hive和Spark SQL目前都已经可以很好地支持对象存储。
Hadoop对象存储连接组件发展历史
（图片来源：hortonworks.com）
以Hive为例，Hive使用对象存储依赖于Hadoop底层调用对象存储接口的组件。得益于Hadoop社区十年来的不断努力，Hadoop对接S3的组件经历了从S3到S3n（S3 Native）再到S3a（S3 Advanced）三个阶段的发展，2016年以后该组件对Hadoop及其生态中各种方案的支持已经能够媲美Hadoop本身的HDFS。同时，Hadoop还于2013年发展出了对OpenStack Swift对象存储的支持，2014年发展出了对Google Cloud Storage的支持，2016年开始兼容阿里云OSS和Azure Data Lake。
有必要提醒的是，接口协议是一方面，另一方面对协议的实现同样重要，不同对象存储产品和方案对结构化数据的支持优劣差别很大。例如Hive使用ORC（Optimized Record Columnar）格式存储数据时，很多SQL操作只需要读取其中一小部分数据就能够完成。这对于百TB级以上，甚至PB级、10PB级结构化数据处理、分析的意义很大，因为在这种量级下读取全量数据进行分析是不现实的，即使能够实现，开销也非常巨大。ORC格式的应用能够大幅提升数据分析性能。
但这种格式给对象存储提出了挑战，因为Hive不会读取完整对象，而是取其中一段数据，并且随时可能中断一个HTTP请求，因为它已经获得了足够的数据完成操作。
Hive在执行SQL操作时对象存储后台日志截图
这就要求：1. 对象存储系统对Range Request要支持得非常好；2. 对象存储系统能够支持Request ID，并且在客户端断开HTTP请求时，对象存储系统能够根据Request ID优雅地终止系统内所有关于该Request的操作，避免额外开销。如果做不到这两点，使用ORC格式时，不仅仅不能提高性能，反而有可能降低性能。
为何对象存储平滑对接应用比人们以前想象的要容易？
在其他行业和场景中，我们也都看到了很多无痛应用对象存储的方案，例如与媒资领域HLS（HTTP Live Streaming）方案的无缝对接，对金融领域常用的企业内容管理系统的支持等等。在我们的实际案例中，应用对接往往在一天之内就完成了。
为何对象存储对接应用比人们以前想象中的要容易很多？
究其原因，第一是生态。任何一个用户的IT系统并不是简单的 应用（计算） + 存储 ，而是由多个组件构成的，每个组件都是在庞大的生态中，优秀的软件和系统都在积极与生态中其他玩家对接、集成与被集成。对象存储由于其优秀的海量存储平滑扩展能力和多业务隔离集中存储方面的优势，被生态中的很多玩家青睐，这些玩家包括很多服务于各行业的应用系统和中间层软件。
第二个原因是对象存储接口标准逐渐统一。起初各大厂的对象存储都有自己的私有协议，但是目前逐步统一为两种事实标准：AWS S3接口协议和OpenStack Swift接口协议。其中S3接口应用最为广泛，最近两年，很多人在谈论“支持对象存储”的时候，言下之意都是“支持S3接口协议”；Swift接口在有OpenStack产品的厂商中支持较多，例如IBM的Filenet对Swift接口的支持就较为完善，另外在Hortonworks的加持下，Swift还可以支持Hadoop的Data Locality。
有意思的是，AWS S3接口的广泛支持并不意味着AWS S3公有云存储本身在对象存储领域就广受欢迎，根据IDC 2017年全球对象存储用户调研报告，只有不到20%的对象存储用户选择使用公有云存储。
最后顺便说一句，奥思数据OStorage对象存储系统是一款兼容S3和Swift接口的企业级和运营级对象存储产品，已在银行、航天等多个行业的生产系统中得到验证，长时间无故障持续稳定运行，对海量非结构化和结构化数据存储均有很好的支持。
关于作者：
本文作者李明宇，奥思数据（OStorage）创始人 & CTO，沉迷于搞机和编程20年不能自拔，目前主要兴趣在于对象存储和云计算。
关于“Linux宝库”微信公众号：
欢迎关注"Linux宝库"微信公众号，这里每天发布最新的开源人物和开源事件。谨以此号记录Linux和开源业界的点点滴滴，为开源爱好者和从业者点亮人生。
- 责任编辑：李明宇 -- END -
Linux宝库
长按扫码，关注我们
为开源爱好者和从业者点亮人生！
