在数据管道中，数据通常经历两个阶段：数据处理和数据访问。 对于任何类型的数据，当它进入组织时（大多数情况下有多个数据源），很可能是不干净的，或者是其格式可能不被最终的内部或外部业务用户直接报告或分析的格式。 组织。 因此，首先需要进行数据处理，通常包括数据清理，标准化，转换和聚合。 然后，最终数据将显示在数据访问层中-随时可以报告并用于所有方面的分析。 数据处理有时也称为数据准备，数据集成或ETL。 其中，ETL可能是最受欢迎的名称。

数据处理和数据访问具有不同的目标，因此已通过不同的技术实现。 大数据的数据处理从一开始就强调"扩展"，这意味着每当数据量增加时，给定可用硬件，处理时间仍应在预期范围内。 整个数据处理时间范围从几分钟到几小时到几天不等，具体取决于数据量和处理逻辑的复杂性。 另一方面，数据访问强调的是"快速"响应时间，以秒为单位。 在较高的水平上，数据处理的可扩展性主要是通过并行处理来实现的，而快速的数据访问则是基于访问模式以及服务器上可用内存的增加，通过优化数据结构来实现的。

数据处理

为了清理，标准化和转换来自不同来源的数据，数据处理需要触摸即将到来的数据中的每条记录。 记录清洁并定稿后，就可以完成工作。 这从根本上不同于数据访问-数据访问导致不同用户和/或应用程序重复检索和访问相同信息。 当数据量较小时，与数据访问相比，数据处理的速度面临的挑战要小，因此通常发生在最终数据所在的同一数据库内。 随着数据量的增长，人们发现必须在数据库之外进行数据处理，以绕开数据库系统造成的所有开销和限制，而数据库系统显然并不是最初设计用于大数据处理的。 那时是ETL，然后Hadoop开始分别在数据仓库和大数据时代发挥关键作用。

大数据处理的挑战在于，要处理的数据量始终处于硬盘可以容纳的水平，但远远超过给定时间可用的计算内存量。 高效数据处理的基本方式是将数据分解成较小的部分并并行处理。 换句话说，可伸缩性是通过首先在编程中启用并行处理来实现的，这样，当数据量增加时，并行进程的数量将增加，而每个进程继续处理与以前相似的数据量； 第二，随着并行进程数量的增加，添加更多具有更多处理器，内存和磁盘的服务器。

大数据的并行处理首先是通过数据库系统和ETL工具中的数据分区技术实现的。 将数据集进行逻辑分区后，可以并行处理每个分区。 Hadoop HDFS（高度分布式文件系统）以最可扩展的方式适应了相同的原理。 HDFS的作用是将数据划分为具有恒定大小的每个数据块的数据块。 然后将这些块分配到不同的服务器节点，并由元数据存储将其记录在所谓的"名称"节点中。 当数据进程开始时，进程数由每个服务器节点上的数据块数和可用资源（例如，处理器和内存）确定。 这意味着只要您有来自多个服务器的足够的处理器和内存，HDFS就可以进行大规模并行处理。

目前，Spark已成为内存中进行大规模数据处理的最受欢迎的快速引擎之一。是否有意义？尽管内存确实变得更便宜了，但它仍然比硬盘驱动器贵。在大数据空间中，要处理的大数据量始终远远大于可用的内存量。那么Spark如何解决呢？首先，Spark利用具有多个数据节点的分布式环境中的内存总量。但是，如果有任何组织尝试将大数据放入Spark群集中，则内存量仍然不够，而且可能会非常昂贵。让我们考虑一下Spark适用于哪种类型的处理。数据处理总是从将数据从磁盘读取到内存开始，最后将结果写入磁盘。如果每个记录在写入磁盘之前只需要处理一次（典型的批处理就是这种情况），那么与Hadoop相比，Spark将不会产生优势。另一方面，Spark可以将数据保存在内存中以进行数据转换的多个步骤，而Hadoop无法。这意味着当多次重复处理同一数据时，Spark提供了优势，这正是分析和机器学习所需要的。现在考虑以下问题：由于可能同时运行数十个或数百个此类分析流程，如何以具有成本效益的方式扩展处理规模？显然，仅仅依靠内存中的处理是无法完全解决的，大数据的分布式存储（例如Hadoop）仍然是补充Spark计算的大数据解决方案中必不可少的部分。

数据处理领域的另一个热门话题是流处理。 它在降低处理速度方面具有巨大优势，因为在给定的时间点，只要数据到达，它只需要处理少量数据即可。 但是，它在两个方面不像批处理那样通用：第一是输入数据需要进入"流"模式，第二是仍然需要处理需要跨时间段聚合的某些处理逻辑 之后分批。

最后，云解决方案提供了机会，可以根据数据量（从而根据并行进程的数量）以更动态的方式扩展分布式处理系统。 在企业内部很难做到这一点，因为需要计划，预算和购买新服务器。 如果不能很好地规划容量，则大数据处理可能会受到硬件数量的限制，或者额外购买会导致资源浪费而无法使用。 云上的处理获得了基础架构弹性的巨大优势，它可以提供更多保证，从而以更具成本效益的方式实现最佳规模。

> A brief history of techologies for data processing

资料存取

与数据处理相比，数据访问具有非常不同的特征，包括：

• · 数据结构高度取决于应用程序或用户如何检索数据
• · 数据检索模式需要很好地理解，因为一些数据可以被大量的用户或应用程序重复检索。
• · 每次应检索的数据量应有针对性，因此应仅包含一部分可用数据。

根据上述原则，在过去的20年中，有几个里程碑反映了如何访问不断增长的数据量，同时仍在数秒内返回请求的数据：

• · 数据仓库：避免表联接，这在数据量很大时可能非常昂贵。 这里出现"事实表"的概念，其中所有列都放在一起，而没有关系数据库中的数据库规范化原则。
• · 列存储：每列都被存储和索引，因此分别访问。 当一行有很多列，而查询一次只检索很少的列时，这比常规关系数据库的基于行的访问提供了更快的响应时间。
• · NoSQL数据库：消除了联接和关系结构，并针对更快速的数据检索量身定制。
• · 内存数据库：通过将整个数据库或整个表保存在内存中来提供快速的性能。

下表列出了每种数据库类型的一些受欢迎的示例，但并非旨在提供完整列表。 请注意，一个数据库可能结合了不止一种技术。 例如，Redis以及内存中都是NoSQL数据库。 此外，从数据仓库和列存储的数据检索利用并行流程在适用时检索数据。 由于可以根据用户和/或应用程序的数据内容，数据结构和检索模式，选择不同类型的数据库，因此数据访问是组织需要快速且不断发展的领域。 同时出于不同目的同时拥有不同类型的数据库或工具也应该很常见。

摘要

如我们所见，数据处理和数据访问之间的一个很大区别是，数据访问最终来自客户和企业的需求，而选择正确的技术将推动未来新产品的开发并增强用户体验。另一方面，数据处理是公司的核心资产，规模处理和产生高质量数据是公司随数据增长的基本推动力。随着数据量的增长，许多公司会经历其数据处理系统的跟踪问题，并且从头开始重建数据处理平台的成本很高。并行数据处理和可伸缩性的原理需要从一开始就仔细考虑和设计。数据处理还与数据管理和数据集成紧密结合，这三个要素对于任何数据密集型组织的成功都是至关重要的。此外，每个组织现在都面临着来自开源社区和第三方供应商的众多大数据解决方案选择。清楚地了解数据处理和数据访问之间的差异，可以使IT和业务领导者不仅可以构建可靠的数据体系结构，还可以做出正确的决定，以稳定的速度对其进行扩展和现代化。

(本文翻译自Stephanie Shen的文章《Big Data Architecture in Data Processing and Data Access》，参考：https://towardsdatascience.com/big-data-architecture-in-data-processing-and-data-access-d03cff195e21)