基于对象存储的离线大数据处理架构和应用实践

熵简科技大数据处理系统目前已经累计完成 3.7 PB 规模的大数据处理和分析，覆盖了超 2000+ 数据源，涉及丰富的数据类型，如宏观经济数据、电商招聘等另类数据、研报新闻等文本类数据。这背后，是一个处理PB级数据的离线大数据处理架构。

本文从离线大数据处理的数据存储选型要点入手，详细介绍如何构建一套基于对象存储的离线大数据处理框架。同时，作为彩蛋，我们在文章最后一部分，介绍了基于该大数据处理框架的电商大数据实践案例，该数据集已被广泛应用于金融投资分析中。

作者信息

本文出自熵简科技大数据团队，团队致力于构建高效率、低成本和低运维的大数据处理系统，为熵简科技应用层及中台层各项服务提供海量的算力支持，涉及数据清洗、数据融合、数据核验、数据建模等多种处理能力。

01

背景

随着大数据时代的到来，当前互联网上的各类数据急剧膨胀。庞杂的信息需要经过采集、清洗、分析才能形成真正有价值的信息，从而为各类机构和企业提供决策依据。作为一家提供全域数据智能服务的科技公司，熵简科技的数据服务是所有业务的核心基础。

目前，熵简科技大数据处理系统已经累计完成 3.7 PB 规模的大数据处理和分析，覆盖了超 2000+ 数据源，涉及丰富的数据类型，如宏观经济数据、电商招聘等另类数据、研报新闻等文本类数据。

这背后，是一个处理PB级数据的离线大数据处理架构。在这个PB级离线数据处理的架构中，最重要的两个部分便是数据存储和计算引擎，各自的核心需求如下：

1.1 数据存储

原始数据是来自于互联网的海量数据，其特点是数据量大，并且随着时间的推移不断的膨胀。

很多原始数据是只有在特定的时间内才能采集到的，如果丢失将不能进行恢复，是一个不可挽回的损失。

因此，数据存储的要求要保证：

1、大量数据的存储（月增幅TB级）

2、强大的IO能力

3、支持增量数据的追加写入和读取

4、稳定可靠

1.2 计算引擎

数据处理需要应对的事情是面对不断膨胀的数据不仅仅需要进行新增数据的处理，还要面临可能因为算法调整需要重新计算所有历史数据的情况。

因此，数据处理要求保证：

1、大量数据处理的能力（PB级别）

2、高效的数据处理能力（月度或者日度的数据更新需要在小时级别处理完毕）

3、稳定、鲁棒性高，在出错的情况下可以迅速进行调整和步骤级别恢复

4、开发和学习成本低

02

数据存储技术选型

2.1 对象存储介绍

对象存储是一种可以水平扩展的分布式数据存储，其中每个数据单元存储称为一个对象，实际上可以是任何类型和任何大小的数据。对象存储中的所有对象都存储在单个平面地址空间中，而没有文件夹层次结构。

当前市面上最有名的对象存储非 AWS S3 莫属，阿里云也提供了类似的存储服务 Aliyun OSS。其特点就是高扩展性（几乎无限的存储空间），可用性和持久性（11个9的持久性保证），高性能，低成本，丰富的支持（Hadoop s3a等）。基于云服务商提供的对象存储服务，使用 RESTful API 可以在互联网任何位置存储和访问数据，同时也能选择多种存储类型以全面优化存储成本。

除了云服务商提供的对象存储服务之外，开源社区也提供了对象存储服务，MinIO 是其中的佼佼者。MinIO 是一个基于 Apache License v2.0 开源协议的对象存储服务。它兼容 AWS S3 云存储服务接口，非常适合于存储大容量非结构化的数据，例如图片、视频、日志文件、备份数据和容器/虚拟机镜像等，一个对象文件可以是任意大小，从数 KB 到最大 5TB 不等。

丰富的云厂商支持和开源社区支持，保证了使用对象存储作为存储介质具有了私有化部署的可能，也为 ToB 的大数据服务提供了更多的技术方案。

2.2 存储成本对比

与文件类型和块类型存储不同，对象存储没有归档层次结构，并且元数据完全可自定义，因此与文件或块存储相比，硬件限制要少得多；加上对象存储的横向扩展性，其存储成本远远低于其他类型的存储。

我们以阿里云上的 OSS、Table Storage、文件存储NAS、普通云盘四类存储服务为例，对比一下各自的价格：

注：以上数据均来自阿里云的各项存储服务的公开标价。

从上表中可以看出来，对象存储无疑是性价比之王，其标准存储的价格仅为普通云盘的一半。而云服务商提供的低频存储和归档存储类型，价格更低（一般为三分之一的价格）。存储类型可以方便的切换和灵活的配置，大大降低了成本。

2.3 数据管道

在对大数据清洗的过程中，数据管道通常指数据来源到计算引擎之前的数据传递渠道，主要负责给计算引擎提供数据以及保存计算结果。由于采集系统或上游系统每时每刻都在产生大量的数据，计算引擎读取数据的速度一定要高于上游系统的写入速度。以 Apache Spark 为例，Spark应用的耗时有很大一部分花在读取数据上，因此一个高效的数据处理流程，对数据管道的要求也是极高，数据管道需要极佳的 IO 性能。在做大数据离线清洗中，常见的数据源包括关系型数据库、Kafka 和对象存储。

关系型数据库

关系型数据库无法应付大量的非结构化数据，大规模的存储和高并发访问会导致数据库负载过高最终产生性能瓶颈。

实践中我们尝试过 2TB 的 RDS 数据库作为数据管道，一旦超过千万级的数据量，读取整张表将要花费近小时级的时间，而同样的读取在对象存储中只需要数分钟。这样的差距放在 10 亿级别的数据量上更是无法接受的。

Kafka 等消息队列

Kafka 在大数据量方面上则占据了优势，高吞吐量，高并发读写，无疑是流式数据处理中绝佳的选择，但是对于离线大数据处理，其最大的问题是存储成本高、运维成本高、且不适合保存历史冷数据。

对象存储

使用对象存储作为中间数据管道，可以带来很多好处。

从存储成本分析，对象存储在存储方式上可按照对象访问量、创建时间来区分存储类型，可以很方便地将历史数据做降级存储，有效降低存储成本。

从并发量分析，对象存储的并发性能极佳，特别是使用云服务商的对象存储服务时，例如阿里云的 OSS、AWS 的 S3 等，不需要考虑并发量的上限。

从运维上考虑，无论是开源的 MinIO，或者是云服务商提供的对象存储服务，运维都极其简单，人力成本几乎为零。

此外，使用对象存储可以将结构化数据和非结构化数据采用统一的方式存储，避免了在使用数据库类解决方案时，文本、音视频等文件需要单独存储的痛点。

但对象存储同时也带来了一些其他问题。例如对增量数据的读取方式，没有 Kafka 的指针、RDS 的自增 ID 作为原生支持。但是我们可以通过对象存储的key值的特殊设计来解决这一问题，下文的具体方案中会有详细阐述。

2.4 中间存储

在数据清洗过程中为了保证调试的鲁棒性和效率的提升，我们一般会在重要节点存储中间数据，例如非结构化数据第一次变成结构化的时候，一般会存储一份中间数据，保证后续的读取足够高效。

通常中间存储使用的是 HDFS。HDFS 具有的特性是高可用性和高扩展性，而这些特性对象存储全部都占有，甚至还有更强大的 IO 性能。此外由于 HDFS 用 NameNode 来存储文件元数据和文件寻址方式的原因，HDFS 对于大量小文件的读写存在性能瓶颈；而对象存储单独存储文件元数据，对于不同类型、不同大小的中间存储都提供了强大的支持。

基于对象存储的 Hadoop-AWS、Hadoop-OSS 等支持包解决了各计算引擎读取数据的方式，可以直接通过类 HDFS 的接口进行文件操作，与 HDFS 可以无缝切换，加上其几乎无需运维的特性，对象存储是离线数据处理中间存储的最佳选择之一。

03

整体架构

我们以 Apache Spark + 对象存储的流程为例，介绍基于对象存储的离线大数据处理架构。

整个处理过程分为以下几个主要流程：

1、Spider 通过网络采集，获取到数据后存储到对象存储中

2、通过 Airflow 的调度将数据清洗任务提交到 Spark cluster

3、清洗任务读取对象存储中的原始采集数据，并将中间数据输出到对象存储

4、再通过中间若干个数据清洗任务，最终将数据输出到 ElasticSearch

5、前后端通过对 ElasticSearch 的数据查询结果向客户展示分析后的有效数据

3.1 对象存储详细方案

3.1.1 原始数据存储

存储格式

采集端使用 JSON 格式存储、Snappy方式压缩数据，目的在于压缩存储所需的资源，Snappy 对 JSON 数据的压缩效果不错，可以大大节省存储空间，并且 Spark 读取 Snappy 数据不需要任何改造。

以下为压缩测试的一些结果：

存储路径管理

尽管对象存储没有天然的层次结构，但是我们可以将相同类型的数据对象赋予相同前缀的Key值，得到不同的存储路径（对象 Key 值前缀）。

存储路径按照不同的数据种类分目录进行存储，例如某网站的评论数据可以放在 web/comment/ 路径下，使用不同的路径区分不同的数据表，目的很简单，根据路径可以确定单表内容，保证 JSON 数据不进行混合。

分布式爬虫可以生成 UUID 作为文件名放入当前时间的文件夹，并发写入性能可以大大提升。

时间游标管理

在同一类型的数据存储路径下，采用数据入库时间来确定具体对象 Key 值， 例如：web/comment/2019/01/01/00/02/00/ ，利用路径的方式给数据增加了时间游标的功能，可以通过路径进行增量遍历。

文件大小

单文件大小控制在 64 MB 左右，避免过小的分片，数据进入对象存储之前进行合并处理是一个优秀的处理方式。

3.1.2 中间数据存储

存储格式

中间存储一律使用 Parquet 格式，Parquet 格式压缩率很高，节省空间，Spark 支持很好大数据架构，读取效率极高，丰富的数据格式可以支持绝大部分的数据结构。

存储路径管理

按照路径区分中间数据表例如：web/comment_analyzed，web 代表数据库名，而 comment_analyzed 代表被分析过的中间数据。

时间游标管理

离线数据的清洗有比较强的批次性，在采集数据的时候就会确定好相应的批次。

例如，如果需要 2019年12月 的数据，那么就会在原始数据中增加 "batch_date": "2019-12-01" 的批次标志。

中间数据清洗后，依照 web/comment_analyzed/batch_date=2019-12-01/ 的方式进行分区，Hadoop-AWS、Hadoop-OSS 等多数基于对象存储的依赖包都支持基于对象前缀的自动分区发现。

文件大小

控制中间输出文件的大小为 64 MB 左右，不宜过小也不宜过大。

其原因在于使用 Spark 进行数据处理的时候会按照文件的大小作为初始单个 partition 处理数据的大小。

过小的文件会造成读取的 overhead 过大，从而读取缓慢，而过大的文件大小会导致需要的 executor 内存大小暴涨。

3.2 Spark任务开发详细方案

时间游标管理

由于使用对象前缀标记存储类型和入库时间，数据清洗过程中需要开发读取对象存储时间格式路径的基础功能，我们接入了Mysql 作为元数据记录，记录每个任务当前处理到的时间节点信息。

（编辑：温州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!