Mindful Machines 原创系列之大数据：批处理
这是《Mindful Machines 系列之大数据》的第二部分（又名：《大数据备忘录》）。在上一篇文章中我们讨论了批量存储，在后续的文章中，我们将讨论流处理、NoSQL 和基础架构。
你准备如何处理泛滥成灾的历史数据？你选择用什么来处理它？Presto？Spark？Redshift？MapReduce？在这篇文章中，我们将讨论各种数据处理方案，以及他们之间的联系。下文并非为了提供一个所有可行技术的完整清单，而是讨论一些技术亮点。尽管涉及 PaaS ，但本文会特别避免讨论企业级解决方案。
Programmatic Batch Processing
程序化的批处理
这些系统为存储在批量存储系统（HDFS，S3，Cassandra，HBase 等）中的数据提供了程序化（Java，Scala，Python 等）的数据查询接口。
总体
- 提供灵活的数据查询接口
- 模式（Schema）需要人工管理或从文件中加载
- 现代系统提供了支持整体查询优化的高级 API
- Apache Hadoop MapReduce： 大数据生态系统的基石，它提供了一种高效处理拍字节(petabytes)级别数据的方法
- 开源；存在 PaaS 和企业版
- 用 Java 编写
- 发布于 2006 年
- 脱胎于 Google 的 MapReduce 论文
- 与传统的集群计算方法相比，为大批量数据的跨机器查询提供了高效且易于实现的方法
- 编写原始的 Java MapReduce 代码相对复杂
- 自 2014 年以来，Google 就不再使用 MapReduce 作为大数据处理的主要模型。开源世界中，新的技术正在取代 MapReduce（参见其他条目）。
- 需要使用 Hadoop（YARN） 集群。 这增加了操作开销
- 存在 PaaS 版（Amazon EMR， Azure HDInsight， Google Dataproc），并且 PaaS 版可以减少所需的操作知识
- Hortonworks 和 Cloudera 提供商业支持
- Apache Spark： 一种高度流行的将中间数据储存在内存中的集群计算框架
- 开源；存在 PaaS 和 SaaS 版本
- 用 Scala 编写
- 始于 2009 年，在 2010 年发表的论文中被介绍
- 一大亮点是为 Python、Scala、Java、R 和 SQL 提供了基本统一的 API，使得原生代码可以和优化的内置命令混合使用
- 在批处理引擎之上，提供对流式范式（streaming paradigm）的支持
- 内置机器学习库（MLLib 和 ML）
- 包含重要的，需要调谐的配置，以获得良好的性能
- Spark 最大的代码贡献者和商业支持者（Databricks）宣传他们的私有 PaaS 版比开源版要快得多。 这对它们产生了倾斜的激励机制。
- Amazon EMR， Azure HDInsight， Google Dataproc 提供 PaaS 解决方案
- Databricks Unified Analytics Platform 提供 SaaS 解决方案
- Hortonworks 和 Cloudera 提供商业支持
- Apache Flink： 集群计算框架，旨在提供比 Spark 更好的服务
- 开源；存在 PaaS 版本
- 用 Java 和 Scala 编写
- 发布于 2013 年
- 为 Python、Scala、Java 和 SQL 提供 API
- 在流处理引擎之上提供对批处理范式（batch paradigm）的支持
- 配置开销小于 Spark
- 提供内置的机器学习库—FlinkML， 但其广泛性和性能都不如 Spark 的机器学习库
- 是一个比较新的项目，并且看上去前景很好。但是 Spark 在新版本中的性能提升和功能改进不仅弥补了两者的差距，还有超越的趋势
- Amazon EMR 和 Google Dataproc 提供 PaaS 解决方案
SQL 批处理
这些框架提供了一个 SQL 接口，用于查询以分布式方式存储在 HDFS 或其他 blob（译者注：二进制大对象） 存储系统（S3 等）中的数据。
- 总体
- 提供集中式模式仓库
- 支持整体查询优化，但仅限于使用 SQL 和潜在的自定义 UDFs
- 大多数都需要传统的 SQL Server 来承载表元数据
- Apache Hive： 最初是 Hadoop MapReduce 之上的一个 SQL 层，如今在 YARN 之上
- 开源；存在 PaaS 版本
- 用 Java 编写
- Facebook 于 2009 年发布
- 使用 Java 编写自定义 UDFs 可能很难且非常耗时
- 更适用于复杂的分析性查询
- 最新版本部分程度上绕过了 MapReduce 并在单个节点（LLAP）上运行守护进程，以进一步优化性能。
- Amazon EMR、Azure HDInsight 和 Google Dataproc 提供 PaaS 解决方案
- Hortonworks 和 Cloudera 提供商业支持
- Apache Spark SQL： 建立在 Spark 之上的 SQL 计算层
- 开源
- 用 Scala 编写
- 最早以 Shark 为名，出现于 2010 年
- 需要使用 Spark 集群
- 更适用于复杂的分析性查询
- 使用 Scala、Python、Java 或 R 编写自定义 UDFs 非常简单
- 需要使用 Spark 集群，有时可能很难调谐
- Amazon EMR、Azure HDInsight 和 Google Dataproc 提供 PaaS 解决方案
- Hortonworks 和 Cloudera 提供商业支持
- Apache Flink SQL： 一个建立在 Flink 之上的 SQL 计算层
- 开源
- 用 Java 编写
- 发布于 2016 年
- 需要 Flink 集群
- 使用 Scala 或 Java 编写自定义 UDFs 非常简单
- 性能与 Spark 不相上下
- Amazon EMR 和 Google Dataproc 提供 PaaS 解决方案
- Presto: 针对海量数据集打造的 SQL 计算层
- 开源
- 用 Java 编写
- Facebook 于 2013 年发布
- 更适用于大量较小的 OLAP 查询
- 支持使用 Java 编写自定义 UDFs
- 需要调谐以获得良好的性能
- 性能与 Redshift 相当
- 性能比 Spark 有进一步优化。与 Databricks 公司的 SaaS 版 Spark 相比，结果可能不同。
- 被 Facebook 用于查询其 300 PB 的数据仓库
- Amazon Athena 提供 PaaS 版本
- Apache Impala: 由 Cloudera 发布的，基于 Google Dremel 技术的 SQL 计算层
- Amazon Redshift Spectrum: Redshift 的计算引擎版
- 专有的 PaaS
- 与 Redshift 不同的是，计算能力可以独立于存储能力而扩展。并支持读取存储于 S3 上任意格式的文件
- 为使用 Python 编写自定义 UDFs 提供有限的支持
- 可以利用 Redshift 管理表元数据
- 需要使用运行中的 Redshift 集群
数据仓库
数据仓库集数据存储与数据处理于一体
总体
- 低延迟和高吞吐量的查询性能，但不一定比其他现代批处理解决方案更快
- 列式数据存储
- 灵活度有一定局限（数据类型，UDFs，数据处理方法等）
- 如果用作主数据仓库，会被套牢
- 就扩展而言，计算与存储系统密切相关
Druid： 为提供低延迟分析性查询设计的列式数据仓库
- 开源
- 用 Java 编写
- 2012 年开始开源
- 提供亚秒级分析性查询、OLAP 查询
- 支持实时数据摄取，而不仅是批量摄取
- 提供有限的 SQL 查询子集（仅限于大到小表连接）
- 支持使用 Java 编写自定义 UDFs，但这很复杂
- 集群可独立于存储无缝缩放
- 利用 S3 或 HDFS 等“深度”存储，避免节点失效时的数据丢失
- 基础构架设置复杂，涉及多种类型的节点和分布式存储（S3、HDFS 等）
- 数个外部依赖关系（S3/HDFS，ZooKeor，RDBM）增加了操作开销
- 适用于处理时间序列数据
- 被 Airbnb、eBay、Netflix、沃尔玛等使用
- ClickHouse： 为低延迟分析性查询和简单性而设计的列式数据仓库
- Amazon Redshift: 全托管的数据仓库解决方案，可以使用 SQL
语法高效地存储和查询数据。
- 专有的 PaaS
- 支持所有 SQL 语法，可进行一般的分析存储
- 为使用 Python 编写自定义 UDFs 提供有限的支持
- 加载、卸载数据需要时间（有可能数小时）
- 没有实时摄取，只有批处理，虽然可用微型批次模拟实时
- 需要明确地调整集群的上行/下限（调整期间，不支持数据写入）
- 存储和计算是紧密联系在一起的
- 缺少复杂的数据类型，如数组、结构、映射或本地 JSON
- Google BigQuery: 全托管的数据仓库解决方案，可以使用 SQL
语法高效地存储和查询数据。
- 专有的 PaaS
- 支持所有 SQL 语法，可进行一般的分析存储
- 支持数据实时摄取
- 为使用 Javascript 编写自定义 UDFs 提供有限的支持
- 查询速度比 Redshift 快，但更贵
- 与 Redshift 不同的是，它采取无服务器的方式。你不需要自己管理、缩放集群以及支付集群费用。
- 支持复杂的数据类型（数组、结构）但不支持原生 JSON
- Azure SQL Data Warehouse:： 完全托管的数据仓库解决方案，计算能力可以不依赖于存储空间而独立扩展
- 专有的 PaaS
- 支持所有 SQL 语法，可进行一般的分析存储
- 没有实时摄取，只有批处理，虽然可用微型批次模拟实时
- 不支持自定义 UDFs（除非使用 SQL 编写）
- 与 Redshift 相比，性能可能不是最好的
- 计算节点可不依赖于存储节点独立扩展
- 缺少复杂的数据类型，如数组、结构、映射或本地 JSON
RDBM
关系数据库管理系统
传统的 SQL 数据库看上去可能不是个常规的选择。但是，除了简单的纵向扩展，它还可以通过分片)（sharding）和只读副本（read-replicas）进行跨节点扩展在。后文中，我会更多地将这些数据库作为分析型数据库（相对少量的大型查询），而不是传统数据库（大量的小型查询）来分析。
- 总体
- 强有力的 ACID 保证（译者注：Atomicity 原子性、Consistency 一致性、Isolation 隔离性、Durability 耐久性）
- 行级更新和插入
- 需要结构化数据。一些数据库也支持自由格式的 JSON 字段
- 可扩展至大数据规模
- 纵向上：现代机器的存储空间可以相当大，所以即使一台机器也能存储显著的数据
- 横向上：能支持分片（Sharding）。虽然需要额外的手动设置和潜在的客户端逻辑更改
- 进行扩展时，你需要进行权衡（例如：跨分区查询还是复杂查询）
- 就扩展而言，计算与存储系统密切相关
- 复杂的多主集群或自动故障转移设置可能会导致系统中存在单点故障
- 被 Uber 和 Facebook 采用，进行大数据处理
- 如果你真的需要扩展规模，还有更好的专用技术可以选择
- Amazon Aurora： 兼容 MySQL 和 PostageSQL 的 AWS 全托管数据库
若有收获，就点个赞吧
0 人点赞
