Mindful Machines 原创系列之大数据：批量存储
2018.4.10 Marcin Mejran 《数据工程》
这是《Mindful Machines 系列之大数据》的第一部分。主要聚焦于批量存储（又名：《大数据备忘录：数据存储》）。在后续文章中，我们将涉及批处理、流处理、 NoSQL 和基础架构。
你有很多数据并且打算把它们存储起来以备将来分析吗？你准备如何存储这些数据？在这篇文章中，我们将讨论各种数据存储方案，以及他们之间的联系。下文并非为了提供一个所有可行技术的完整清单，而是讨论一些技术亮点。尽管涉及 PaaS，但本文会特别避免讨论企业级解决方案。
RDBM
关系数据库管理系统
传统的 SQL 数据库看上去可能不是个常规的选择。但是，除了简单的纵向扩展，它还可以通过 分片)（sharding）和只读副本（read-replicas）进行跨节点扩展。在后文中，我会更多的将这些数据库作为分析型数据库（相对少量的大型查询），而不是传统数据库（大量的小型查询）来分析。
总体：
- 强有力的 ACID 保证（译者注：Atomicity 原子性、Consistency 一致性、Isolation 隔离性、Durability 耐久性）
- 行级更新和插入
- 需要结构化数据。一些数据库也支持自由格式的 JSON 字段
- 可扩展至大数据规模
- 纵向上：现代机器的存储空间可以相当大，所以即使一台机器也能存储显著的数据
- 横向上：能支持分片（Sharding）。虽然需要额外的手动设置和潜在的客户端逻辑更改
- 进行扩展时，你需要进行权衡（例如：跨分区查询还是复杂查询）
- 就扩展而言，计算与存储系统密切相关
- 复杂的多主集群或自动故障转移设置可能会导致系统中存在单点故障
- 被 Uber 和 Facebook 采用，进行大数据处理
- 如果你真的需要扩展规模，还有更好的专用技术可以选择
- 开源；存在 PaaS 和企业版
- 支持 JSON 格式
- 拥有多个公司的商业支持
- 比 MySQL 更好的并行单一查询优化
- 第三方对列式存储引擎的支持，大大加快了分析速度
- 支持通过 PL 或者代理进行分片（sharding）
Amazon Aurora: 兼容 MySQL 和 PostageSQL 的 AWS 全托管数据库
- 专有的 PaaS
- 存储空间自动切无缝分配
- 数据在所有可使用区域复制
- 声称对比于开源版，通过与 SSD 存储层的紧密耦合提高了性能。
- 比PostgreSQL更好的性能
- 在开源版本的支持方面存在落后。Auro 对 MySQL 5.7 的支持在 MySQL 5.7 之后 2 年出现
- 不支持除只读副本外的集群
Object/File Storage:
对象/文件存储：
这些分布式、可扩展的数据存储多用于存储大量的类似历史日志或图像文件等大块数据。这些数据存储可以有效地进行批量数据读取以便进一步处理（通过 Spark、Presto 等）。因此能够充当数据仓库（Data Warehouse）的后端。
总体：
- 结构化、半结构化和非结构化数据的高效存储
- 不是为单行的读写而设计的
- 不适用存储小文件或对象
- 可以连接数据处理系统（Spark、MapReduce 等）
- 计算可以不依赖于存储而独立扩展
Apache HDFS：Hadoop 分布式文件系统（HDFS）提供了一种存储数百 PB 字节的分布式数据存储。
- 开源；存在 PaaS 和企业版
- 用 Java 编写
- 2006 年首次发行
- 分布式，容错的，可扩展
- 数据在集群中以完整副本或纠删编码的形式存储多份
- 多个主节点支持无缝故障转移
- 以目录形式存储文件，但未设计成可挂载的文件系统
- 其他多个项目强有力的支持 HDFS，包括 HBASE、SCAK、HIVE、Hadoop MapReduce、Presto 和 Flink
- 即使使用现代工具（Hortonworks，Cloudera），运行自己的集群仍然需要大量的操作知识
- 存在 PaaS 版（Amazon EMR， Azure HDInsight， Google Dataproc），并且 PaaS 版可以减少所需的操作知识。
- 没有针对存储大量较小的文件（<64 MB）例如图像，进行优化
- 你可以把它们组合在一起形成，例如，SequenceFiles
- 基于谷歌文件系统相关论文
- 如果您正在运行自己的硬件或对性能有要求，那么这是一个可靠的选择.。否则，像 S3 这样的云存储是更好的选择
- Hortonworks 及 Cloudera 提供的商业支持
Amazon S3：一个由 Amazon 提供的全托管对象/文件存储平台
- 专有的 PaaS
- 分布式，高可用性（99.99%）和容错性（99.999999999%）
- 完全托管，无需自行配置或人工扩展
- 可以模拟一个文件系统，包括在“目录”中列出对象/文件（技术上，仅使用键的前缀）
- 可以认为是 HDFS 的替代方案，因为许多项目能够查询存储在 S3 中的数据（包括 MapReduce、Spark、Fl.、Presto 等）
- 如果使用Amazon EMR，HBase 可以使用 S3 作为存储后端
- 列表操作比较缓慢，并且仅在最终结果才能保持一致。（例如：可能返回过期数据）
- Hadoop 的最新发布版本中包括了实验性的元数据缓存支持来解决这个问题
- 相对低的成本和较少的操作开销
- 如果你是 Amazon 生态系统的用户，那么这是一个存储批量数据的可靠选择
Azure Blob Storage：由 Azure 提供的类似于 S3 的对象/文件存储平台
- 专有的 PaaS
- 分布式的、高度可用的（99.99%）以及容错的（根据复制配置的不同，可达到 99.999999999% 或者更高）
- 完全托管，无需配置或人工扩展
- 不同于 S3，可在列表操作时保持强一致性
- 可以认为是 HDFS 的替代方案，因为许多项目能够查询存储在 S3 中的数据（包括 MapReduce、Spark、Fl.、Presto 等）
- HBase 可以用 Azure Blob Storage 作为原生后端
- 相对低的成本和较少的操作开销
- 如果你是 Azure 生态系统的用户，那么这是一个存储批量数据的可靠选择
Google Cloud Storage: 由 Google 提供的类似于 S3 的对象/文件存储平台
- 专有的 PaaS
- 分布式的、高度可用的（99.9% 到 99.95%）以及容错的（99.999999999%）
- 完全托管，无需配置或人工扩展
- 不同于S3，可在列表操作时保持强一致性
- 可以认为是 HDFS 的替代方案，因为许多项目能够查询存储在 S3 中的数据（包括 MapReduce、Spark、Fl.、Presto 等）
- 不支持 HBase，Google 更希望你使用 BigTable 的 HBase 接口
- 相对低的成本和较少的操作开销
- 如果你是 Google 生态系统的用户，那么这是一个存储批量数据的可靠选择
Columnar NoSQL
列式 NoSQL
与以行的形式存储数据相反，列式 NoSQL 数据库以列或者一组列的形式存储数据。在仅需读取某些列的子集的查询中，这样的存储方式能极大的提高性能。
总体：
- 高效存储结构化数据
- 除了批量读取和写入外，还允许进行关键字级别的写入和读取
- 可以了解数据处理系统（Spark，MapReduce 等）从而使计算能力的扩展独立于存储能力
- 可以用作常规的 NoSQL 数据库
Apache Cassandra：通过无主从区别的数据库模式避免单点故障，提高可用性
- 开源；存在 PaaS 和企业版
- 用 Java 编写
- 最初由 Facebook 开发并于 2008 年公开发布
- 大体上，可用性高于一致性（AP）
- 通过严格测试，支持每个查询一致性的可调，从而避免错误
- 通过有限的 SQL 语法进行查询（不支持 Join）
- 需要模式（Schema）已预先定义的结构化数据
- 无需外部依赖（如 ZooKeeper），这使得部署相对容易
- 总体性能良好，尤其注重批量写入的性能
- 支持二级索引
- 被 Uber 和 Netflix 使用
- 基于亚马逊的 Dynamo 论文
- 对 Spark 的一级支持和无其它依赖关系，使其非常适合作为 Spark 的数据存储后端
- DataStax 提供的商业支持
Apache HBase:一个强一致的（CP）数据库。构建在 HDFS 和 Zookeeper 之上。
- 开源；存在企业版
- 用 Java 编写
- 2007 年首次发行
- 一致性高于可用性（CP）
- 提供对 MapReduce 的原生支持。通过第三方支持 Spark。很快，又提供了内置的 HBase 3.0.0 支持（用 2.0.0 发行版评判，可能过了一段时间）
- 支持协处理器，使自定义代码能在 HBase 服务器上轻松运行
- 读取性能与 Cassandra 平分秋色甚至更胜。但写入速度较慢
- 实际结果取决于测试者是 Hortonworks 还是 DataStax
- 依赖 HDFS 和 Zookeeper。如果你并不是 Hadoop 生态系统的用户，那么部署起来比较复杂
- 支持二级索引
- 被 Facebook 等使用
- 受到 Google BigTable 的影响
- 对于 HDFS 的依赖，使得很难说清着究竟是批量数据存储仓库，还是普通的 HDFS
- Hortonworks 和 Cloudera 的商业支持
Google BigTable：面向高一致性的全托管数据库
- 专有的 PaaS
- 一致性高于可用性（CP）
- 完全托管
- HBase 就是受到了 BigTable 影响。 同时， BigTable 提供了 开源的 HBase 兼容层
- 支持 HBase 的第三方库（Spark， MapReduce 等）一般也同样支持 BigTable
- 不支持自定义协处理器
- 不支持二级索引
Amazon DynamoDB: 面向高可用性的全托管数据库
- 专有的 PaaS
- 可用性高于一致性（AP），但支持每个查询一致性的可调
- 完全托管
- 支持读写能力的自动扩展
- 无需预先为每个表格定义模式（Schema），只需定义索引键
- 与 Cassandra 一样继承自Dynamo，因此拥有许多相似之处
- 支持 MapReduce 和 Spark 对 DynamoDB 表进行操作
- 支持二级索引
数据仓库集数据存储与数据处理于一体。在本系列的后续《数据处理》一文中，我们将深入研究这些解决方案的计算性能，这正是使用它们存储数据的关键原因。
总体：
- 低延迟和高吞吐量的查询性能，但不一定比其他现代批处理解决方案更快
- 优化的列式数据存储
- 灵活度有一定局限（数据类型，UDFs，数据处理方法等）
- 如果用作主数据仓库，会被套牢
Druid: ：为提供低延迟分析性查询设计的列式数据仓库
- 开源
- 用 Java 编写
- 2012 年开始开源
- 提供亚秒级分析性查询/联机查询
- 支持实时摄取数据，而不单只是批量摄取
- 提供 SQL 查询的有限子集（仅限于大到小表连接）
- 集群可独立于存储无缝缩放
- 利用 S3 或 HDFS 等“深度”存储，避免节点失效时的数据丢失
- 基础构架设置复杂，涉及多种类型的节点和分布式存储（S3、HDFS 等）
- 增加操作开销的数个外部依赖关系（S3/HDFS，ZooKeor，RDBM）
- 适用于处理时间序列数据
- 被 Airbnb、eBay、Netflix、沃尔玛等使用
- 对于专门的分析/OLAP系统，这是一个可靠的选择。否则，可以选择其他更为灵活，开销更小的解决方案（以较慢的查询为代价）
ClickHouse：为提供低延迟分析性查询和简单性而设计的列式数据仓库
- 开源
- 用 C++ 编写
- 2016 年由 Yandex 开放源码
- 对某些工作的性能明显高于 Druid
- 可扩展性不如 Druid 或其他解决方案
- 使用 Zookeeper， 同时也可以在不用 Zookeeper 的情况下运行单节点集群
Amazon Redshift: 全托管的数据仓库解决方案，可以使用 SQL语法高效地存储和查询数据。
- 专有的 PaaS
- 支持所有 SQL 语法，可进行一般的分析存储
- 加载/卸载数据需要时间（有可能数小时）
- 没有实时摄取，只有批处理，虽然可用微型批次模拟实时
- 需要明确地调整集群的上行/下限（调整期间，不支持数据写入）
- 存储和计算是紧密联系在一起的
- 缺少复杂的数据类型，如数组、结构、映射或本地JSON
Google BigQuery: 全托管的数据仓库解决方案，可以使用 SQL 语法高效地存储和查询数据。
- 专有的 PaaS
- 支持所有 SQL 语法，可进行一般的分析存储
- 支持数据实时摄取
- 与 Redshift 不同的是，它采取无服务器的方式。你不需要自己管理、缩放集群以及支付集群费用
- 支持复杂数据类型（数组、结构）但不支持原生JSON
- 专有的 PaaS
- 支持所有 SQL 语法，可进行一般的分析存储
- 没有实时摄取，只有批处理，虽然微批次可以模拟实时
- 计算节点可不依赖于存储节点独立扩展
- 计算资源在不使用的情况下可以暂停从而节省费用
- 利用 Azure Blob Storage 存储数据
- 缺少复杂的数据类型，如数组、结构、映射或本地JSON
若有收获，就点个赞吧
0 人点赞
