存储与计算分离:OSS构建表 + 计算引擎对接

本文涉及的产品
对象存储 OSS,20GB 3个月
阿里云盘企业版 CDE,企业版用户数5人 500GB空间
文件存储 NAS,50GB 3个月
简介: 看到标题,可能有用户要问:OSS不是用来存图片、视频、及文件的吗,还可以在上面建表、数仓?计算效率和经济性表现怎么样? 本文先给出基本结论: OSS是什么? 对象存储(Object Storage Service,简称OSS)是基于阿里云飞天分布式系统的海量、安全和高可靠的云存储服务,是一种面向互联网的大规模、通用存储,提供RESTful API,具备容量和处理的弹性扩展能力。

看到标题,可能有用户要问:OSS不是用来存图片、视频、及文件的吗,还可以在上面建表、数仓?计算效率和经济性表现怎么样?

本文先给出基本结论:

  • OSS是什么?

对象存储(Object Storage Service,简称OSS)是基于阿里云飞天分布式系统的海量、安全和高可靠的云存储服务,是一种面向互联网的大规模、通用存储,提供RESTful API,具备容量和处理的弹性扩展能力。

  • 基于OSS是否可以创建数据表?

既然可以把摄像头推流接到OSS,建表属于小Case了。并且2016年在亦龙大神的帮助下,Hadoop社区在官方版本中支持OSS,开启了阿里云存储与开源融合的新里程碑。

  • OSS上建表是否易用?

今天为了降低OSS上建表的门槛,日志服务(原SLS)LogHub可以支持OSS上表的实时写入(表类型包括TextFile,列存储Parquet),支持压缩及数据Partition配置。在计算引擎端,我们已经和阿里云(MaxCompute、E-MapReduce)和主流开源计算引擎(Presto等)打通,无缝使用多种计算引擎热插拔对接。

既然可以把数据表直接建在HDFS、MaxCompute(原ODPS)上,选择OSS来存储表数据又是为什么呢?

存储与计算分离的趋势

在2009年做大规模计算的核心词是“Locality”:让计算尽量靠近数据以提升效率。当时一个公认的模型是:构建一个足够大的资源池,把数据和计算融合在里面发挥规模效应。

但最近几年以来,生态和环境都悄然发生了一些变化:

  • 计算模式:全量数据计算模式,逐步被Impala、Presto等更高效计算模式赶上
  • 存储格式:ORC/Parquet/Kudu等列存、索引技术诞生,使得计算不需要Scan大块数据
  • 网络架构:25G网络开始上线,FPGA等技术也加快了网络体验
  • 存储介质:SSD、AliFlash、3D X-Point 大量混合技术使得存储可以“既快又猛”
  • 计算平台:GPU、FGPA、甚至是未来的TPU等改变计算形态

从这些变化使得我们发现:

通过一款机型通吃存储+计算方案,已经演变成存储+计算各自服务化,通过高速网络进行连接的趋势

1
这种方式可以使得存储、计算不用再被”机型“,”机柜“,”电力“等方案束缚,在各自最擅长的领域进行创新。从业界对于”分层“的工作中,我们也看到了这类的尝试:

案例1:Netflix 基于S3解决方案

Netflix是AWS创新代表,特别是他们的大数据业务。根据2016 Re:Invent上Slides描述,Netflix每天新增500 Billion条日志(数据量500 TB)、存量数仓规模 60PB、每天会对其中3PB数据做计算。

在Slides中Netflix谈到:从2014年开始就决定开始摒弃各种系统隔阂,底层使用了统一存储S3,之上构建各种计算引擎系统。事实证明Netflix这一步走得正确,海量的存储与计算能力使得商业的创新得到了充分释放,成为AWS上令人引以为傲的学习榜样。

2

受Netflix启发,AWS 在2016 Re:Invent 上推出了一款新的计算产品Athena:该产品将Presto服务化提供基于各种存储类服务的 Ad-Hoc Query能力。

AWS Athena利用多个可用区(Availability Zones)中的计算资源执行查询,并将S3用作底层数据存储系统,由于数据冗余地存储在多个地点和每个地点的多个设备中,服务具备很高的可用性和可靠性。

案例2:Facebook RocksDB项目

Google开源了Level DB,而Facebook通过改造成RocksDB使它上升到新高度。RocksDB除了对LSM模型的多个优化外,另一个非常吸引人的地方在对存储介质、计算层适配得非常友好,可以充分发挥计算和存储的性能。底层的介质与存储对上层API透明热插拔,是在软件设计层面存储+计算分离的一个优美案例。

3

OSS上建立数仓的优势

优势1:不受限制的存储空间

对于数据仓库来说最重要一点是海量存储,能为计算分析提供大数据吞吐支持。在这个点上OSS是非常合适的。

结合OSS的目录设置,对大规模(百万级别以上)文件做合理划分,并与计算引擎配合拿到更高的计算效率。LogHub投递OSS存储支持Hive-style分区目录,将数据按照日期存储,可以设置多维分区。

举个例子,我们有一个应用叫my-app,为应用创建一个dw项目 my-dw,在项目中创建了一组表,以其中一个表my-table作为例子:表中的数据以时间(天)作为partition(例如date='20170330' 代表当天的数据目录)。

整个数仓的层级结构可以映射为OSS的一个访问路径:

  • my-app 为 OSS 上bucket名称
  • my-dw 之后则为数仓的项目名(namespace)
  • my-table是表名
  • date=20170330是一维分区

4

优势2:极低的存储成本

OSS 是提供实时数据读写“最便宜”存储产品之一,对于100GB日志数据:

  1. 使用列存储编码(以Parquet格式为例),通过snappy压缩后,存储数据量在8 GB左右
  2. 以OSS当前官网价格计算,使用OSS存储一个月费用为 8 * 0.148 = 1.184 元
  3. 除此之外,OSS有两种根据访问频率可任意转换形态:IA(低频)、Archive(冷备),最低可以降低60%成本。OSS 与 IA,Archive之间数据模型是一致的,数据形态可以非常便捷的转换。

5

优势3:一份数据,对接多种计算引擎

我们可以将数据以一种通用的协议存储(例如textfile,sequence file或parquet等),目前OSS上数据支持如下计算引擎:

  • 开源:Spark、Presto、Druid,Pig,Hive等
  • 阿里云:MaxCompute,E-MapReduce、RDS-PG、Batch Compute等

以上计算引擎和存储之间都是热插拔,可以方便地在不同大小的测试、生产数据集上进行切换组合。

对比与传统数仓方案,数据存储于OSS,计算实现了Schema on Read,使得数据分析的自由度得到了很大提升。

6

除了支持多种计算引擎外,OSS 本身还有Geo-Replication功能,可以在不同Region间准实时进行同步,不把鸡蛋放在一个篮子里,以进一步提升重要数据的安全性。

优势4:在计算效率上比肩HDFS类存储

OSS从API上看起来不像HDFS类存储这么细,性能并不一定好?

这里以一个Map-Reduce作业举例,在作业的执行过程中,OSS会在3个地方被用到:

  • 调度:当查询提交时,需要根据计算数据范围 List OSS目录制定plan,确定多少文件目录参与计算
  • 运行:每个Worker根据plan扫描指定目录下文件,读取并进行自定义计算
  • 结果:当计算完成时,写入OSS(计算中间结果产生的Shuffle文件可以写在本机以优化性能,部分场景下也可以选择使用OSS)

7

可见,对于Ad-Hoc Query类场景,OSS在使用模式上都可以完全胜任。

开始在OSS分析数据

数据写入

  • LogHub(推荐)

直接将日志以准实时方式写入OSS,支持JSONParquetCSV格式,投递规则配置如下:

8

数据在OSS存储如下:

2017-04-18 11:50:39 513.75KB oss://oss-shipper-shenzhen-test/tfs_access_log/updatetime=2017_04_18_11_00/log_1492487434507106535_1670221.snappy.parquet
2017-04-18 11:56:01 517.36KB oss://oss-shipper-shenzhen-test/tfs_access_log/updatetime=2017_04_18_11_00/log_1492487754196771821_1670280.snappy.parquet
2017-04-18 12:01:31 537.03KB oss://oss-shipper-shenzhen-test/tfs_access_log/updatetime=2017_04_18_12_00/log_1492488089710991745_1670335.snappy.parquet
2017-04-18 12:06:54 512.95KB oss://oss-shipper-shenzhen-test/tfs_access_log/updatetime=2017_04_18_12_00/log_1492488410774368293_1670389.snappy.parquet
2017-04-18 12:22:55 512.95KB oss://oss-shipper-shenzhen-test/tfs_access_log/updatetime=2017_04_18_12_00/log_1492489370787863606_1670558.snappy.parquet
2017-04-18 12:34:21 261.69KB oss://oss-shipper-shenzhen-test/tfs_access_log/updatetime=2017_04_18_12_00/log_1492490057002827204_1670672.snappy.parquet
object list number is: 5451
totalsize is: real:195677878828, format:182.24GB

通过LogHub写入优势:数据接入LogHub多种选择,全托管归档服务,准实时投递,支持异常重试,STS授权。了解OSS投递请参考文档

  • OSS API/SDK

使用OSS 各种SDK或API写入,完全自主的写入方式,参考文档

计算引擎

相关实践学习
借助OSS搭建在线教育视频课程分享网站
本教程介绍如何基于云服务器ECS和对象存储OSS,搭建一个在线教育视频课程分享网站。
目录
相关文章
|
2天前
|
存储 弹性计算 监控
为什么要在云效平台创建发布流水线并将源代码编译环节替换为从OSS下载构建部署物
为什么要在云效平台创建发布流水线并将源代码编译环节替换为从OSS下载构建部署物
|
1月前
|
SQL 分布式计算 DataWorks
DataWorks产品使用合集之如何将CSV文件从阿里云OSS同步到ODPS表,并且使用列作为表分区
DataWorks作为一站式的数据开发与治理平台,提供了从数据采集、清洗、开发、调度、服务化、质量监控到安全管理的全套解决方案,帮助企业构建高效、规范、安全的大数据处理体系。以下是对DataWorks产品使用合集的概述,涵盖数据处理的各个环节。
DataWorks产品使用合集之如何将CSV文件从阿里云OSS同步到ODPS表,并且使用列作为表分区
|
28天前
|
监控 Serverless 持续交付
阿里云云效产品使用问题之如何让流水线支持构建 flutter web 应用到 OSS
云效作为一款全面覆盖研发全生命周期管理的云端效能平台,致力于帮助企业实现高效协同、敏捷研发和持续交付。本合集收集整理了用户在使用云效过程中遇到的常见问题,问题涉及项目创建与管理、需求规划与迭代、代码托管与版本控制、自动化测试、持续集成与发布等方面。
|
26天前
|
数据采集 DataWorks 安全
DataWorks产品使用合集之将按日分区的表同步数据到OSS数据源,该如何配置
DataWorks作为一站式的数据开发与治理平台,提供了从数据采集、清洗、开发、调度、服务化、质量监控到安全管理的全套解决方案,帮助企业构建高效、规范、安全的大数据处理体系。以下是对DataWorks产品使用合集的概述,涵盖数据处理的各个环节。
110 1
|
8天前
|
持续交付 开发工具 对象存储
阿里云云效产品使用合集之构建物如何上传到阿里云OSS
云效作为一款全面覆盖研发全生命周期管理的云端效能平台,致力于帮助企业实现高效协同、敏捷研发和持续交付。本合集收集整理了用户在使用云效过程中遇到的常见问题,问题涉及项目创建与管理、需求规划与迭代、代码托管与版本控制、自动化测试、持续集成与发布等方面。
|
1月前
|
Java 对象存储
java对接阿里云OSS上传
java对接阿里云OSS上传
140 2
|
1月前
|
Java 对象存储
java对接七牛云OSS上传
java对接七牛云OSS上传
23 2
|
1月前
|
存储 分布式计算 大数据
MaxCompute产品使用合集之是否支持创建OSS外部表为分区表,并访问OSS上以分区方式存储的数据
MaxCompute作为一款全面的大数据处理平台,广泛应用于各类大数据分析、数据挖掘、BI及机器学习场景。掌握其核心功能、熟练操作流程、遵循最佳实践,可以帮助用户高效、安全地管理和利用海量数据。以下是一个关于MaxCompute产品使用的合集,涵盖了其核心功能、应用场景、操作流程以及最佳实践等内容。
|
1月前
|
存储 DataWorks 关系型数据库
DataWorks产品使用合集之在使用数据集成中的同步任务从mysql同步表到oss,存储为csv时,最终生成的文件中没有表头,这个属性可以在哪里配置么
DataWorks作为一站式的数据开发与治理平台,提供了从数据采集、清洗、开发、调度、服务化、质量监控到安全管理的全套解决方案,帮助企业构建高效、规范、安全的大数据处理体系。以下是对DataWorks产品使用合集的概述,涵盖数据处理的各个环节。
|
2月前
|
存储 数据管理 Java
基于OSS、NFS构建高性能可扩展的遥感智能解译系统实践之路
该文探讨了构建高性能、可扩展的遥感智能解译系统的架构演进过程。作者强调架构应根据业务场景而定,而非追求单一的“最佳”架构。文章分为五个部分,介绍了从初步的业务场景分析到逐步优化的架构设计。 1. 业务场景描述了服务于地理信息行业的遥感数据管理平台,包括数据湖和遥感智能解译系统的功能和架构设计。 2. 初代系统解决了数据管理和智能解译的基本需求,但存在数据同步效率低下的问题。 3. 自动化阶段通过消息推送和数据接收模块减少了人工干预,将处理时间减半,但仍存在效率和稳定性问题。 4. 高性能阶段引入数据订阅/推送和数据接收Agent,实现了稳定、高速的数据传输,性能提升了6倍。
48775 2

相关产品

  • 对象存储