首先，什么不是大数据？技术参考《曲阜市智程网络科技有限公司-智能营销笔记本》

基本上，可以装入一台计算机/机器的所有东西。在大数据出现之前，我们是如何处理数据的？关系数据库（RDB）非常流行（并且仍在大量使用）。

什么是关系数据库？

关系数据库，是建立在关系数据库模型基础上的数据库，借助于集合代数等概念和方法来处理数据库中的数据，同时也是一个被组织成一组拥有正式描述性的表格，该形式的表格作用的实质是装载着数据项的特殊收集体，这些表格中的数据能以许多不同的方式被存取或重新召集而不需要重新组织数据库表格。关系数据库的定义造成元数据的一张表格或造成表格、列、范围和约束的正式描述。每个表格（有时被称为一个关系）包含用列表示的一个或更多的数据种类。 每行包含一个唯一的数据实体，这些数据是被列定义的种类。当创造一个关系数据库的时候，你能定义数据列的可能值的范围和可能应用于那个数据值的进一步约束。而SQL语言是标准用户和应用程序到关系数据库的接口。其优势是容易扩充，且在最初的数据库创造之后，一个新的数据种类能被添加而不需要修改所有的现有应用软件。主流的关系数据库有oracle、db2、sqlserver、sybase、mysql等。-百度百科

RDB 的示例是 MySql 和 SqlServer。

在 RDB 中，数据是使用关系建模的。目标是以创建许多表和参考链接为代价，尽可能少或没有数据重复。这就是数据规范化。数据规范化有很多规则，我们需要做什么才能规范化数据。
规则是第一范式 (1NF)、2NF、3NF、4NF 和 BCNF - Boyce 和 Codd 范式。

尽管 SQL 是一种结构良好的查询语言，但它并不是当今处理数据的唯一工具。我们将讨论原因，但首先，让我们记住一个例子：

我们正在建立一个社交媒体网站。像 WEIBO。我们的网站保存了转化为许多关系（表格）的数据。我们的一些主要屏幕是根据以下问题构建的：

-> 特定人喜欢多少条推文？
-> 我怎样才能看到我的个人WEIBO提要？

这些问题是我们业务需求的主要部分：我们的用户希望能够访问来自他们的朋友或他们关注的人的推文。他们想查看喜欢的数量、分享和评论的数量。*我们如何设计一个 SQL 查询来获取这些数据？*我们可以查看每个用户的以下信息，对最近的推文进行加入操作，对喜欢进行加入操作，对转推进行另一次加入操作，对评论进行加入操作等等。

• join - 这是一个 SQL 连接运算符，我们根据特定的键将 RDB 中一个或多个表中的列组合在一起。这只是我们如何查询数据以回答主要业务问题的一种选择。

现在，有一个更集中的业务问题：

-> 有多少人喜欢一个特定的用户？

我们如何回答这个问题？我们也可以利用 SQL 并为此创建查询。综上所述，我们可以使用 SQL 开发一个完整的社交媒体平台。但是，等等，我们没有讨论 Scale 和查询数据的大小。据分析师称，我们每天面临着 100 亿条微文。这意味着它不适合一台机器。最重要的是，我们现在面临新的要求：超快速地提供结果。超快是什么意思？在几毫秒内。哎呀。现在，需要超过 1、2 或 5 秒才能完成的具有 5-10 个连接的查询还不够好（根据当今的业务需求）。

现在我们明白了 RDB 并不总是答案，让我们看看什么是大数据。

那么，什么是大数据？

这是一组无法放入一台机器的大量数据。

两个主要挑战：

1.     更多数据要处理（然后可以装在一台机器上）

2.     更快的回答/查询响应要求

处理大量数据的一种技术是 NoSQL。在大多数情况下根本没有关系。这种方法可以帮助我们更快地获得结果，以及存储更多的数据。

NoSQL 是我们解决当今数据驱动系统挑战的一种方法。
我们如何处理具有大数据约束的数据？我们首先考虑我们将如何使用这些数据。我们想回答哪些商业案例？我们将如何存储和稍后查询数据？使用大数据和快速是有代价的。其中之一可能只是放弃查询灵活性。

我们应该提前知道我们需要服务哪些查询来回答业务问题。我们将为查询提前做好准备——通过以各种方式复制数据，以较慢的写入为代价获得更快的读取。这个过程称为非规范化数据。

“非规范化是试图提高数据库读取性能的过程，代价是损失一些写入性能，通过添加数据的冗余副本或提前对数据进行分组。” - 维基百科。

这给我们带来了一个新的挑战——数据设计挑战：

如何组织数据以便于快速查询？

让我们回到我们的例子。特定用户喜欢多少条推文？为了解决这个问题，我们将保留一个计数器并在每个“喜欢”时更新它，作为写入操作的一部分。这将节省我们在阅读时计算计数的成本。
但是，一旦我们采用这种方法，我们就需要为每个特定问题/业务案例构建一个数据版本。我们变得很快，但失去了灵活性。另一种方法是为每个“喜欢”操作写一行并每 5 分钟计算一次，以保持结果“5 分钟新鲜”。这为我们带来了新的存储解决方案：NoSql、DocumentDB、GraphDB 等。上述所有解决方案都需要支持大量查询的负载，同时不会卡在具有读/写锁的事务中。

读/写锁 是解决读写器问题的同步方法，通常意味着多个线程可以并行读取数据，但只有具有排他锁的线程才能更新数据。

这就是为什么读/写锁有可能通过将部分数据锁定未知时间或 TTL（生存时间 - 也用作资源将被锁定多长时间的最大阈值）而使我们陷入困境的原因。

这总结了大数据挑战的本质，这将我们带到了大数据框架。今天，许多公司将尝试以较少处理的方式存储数据，即原始数据，而不会丢失任何数据，也不会对其进行过滤。当然，根据要求解决信息隐私法，例如 GDPR、HIPAA 等。

这就是为什么我们要利用各种框架来大规模、快速地处理数据。让我们看看下一个方法，它建立在我们可以捕获数据的快照并在必要时读取它们的想法的基础上。

用于设计软件架构以支持大规模数据的构建块：

1.     数据湖

2.     数据仓库

3.     处理层

4.     用户界面/API

数据湖

数据湖是我们以原始方式保存所有数据而不进行处理的地方。我们以这种方式保存它，以便以后在出现业务案例或新产品时，我们将相对可用并以原始格式提供它。这种存储应该很便宜，因为我们希望存储我们可以存储的所有内容（考虑到数据合规性）。云让我们可以存储一切。在Azure 上，我们可以将所有内容存储在 blob 存储中。在 AWS 上，我们可以使用 s3。我们将 blob 用作无休止的文件系统。我们存储在 Data Lake 中的数据在开始时可能没有意义/目的，只是存储，因此我们以后不会丢失数据或商业机会。

数据仓库 (DW)

数据仓库将保存更多处理过的数据，可能具有用于快速查询或快速处理的特定结构。DW 将被数据科学家、业务分析师和开发人员高度使用。DW 将具有用于快速访问的索引，并且数据将以独特/优化的方式保存。把它想象成一个有索引的图书馆，你不需要翻遍所有的书来找到你想要的书。

到目前为止，我们讨论了数据湖和数据仓库。到达 DW 的数据已经有目的，用于回答业务问题。这意味着，该数据将至少有两个副本，一个是原始格式，另一个是保存在 DW 中的已处理格式的副本。

处理层

在处理数据时，我们需要工具来帮助我们分析、系统地从中提取信息、创建机器学习模型等等。这是处理层的职责。我们将以分布式的方式进行。
分布式处理有一个完整的生态系统，其中一个已知的框架是 Apache Spark：

Apache Spark 是分布式处理生态系统的一部分。它具有用于批处理、流式处理、SQL、机器学习和图形处理的内置模块。

用户界面/API

很多时候，我们会希望构建一个界面来为业务服务，它可以是为我们的客户服务的 UI（用户界面）或 API（应用程序编程接口）。我们的客户通常希望了解数据。它可以是推特提要的形式。这是我们基本通用架构的最后一层，它将为我们的客户提供结果。

总结
曲阜市智程网络科技有限公司程序员总结一下。这些构建块开启了工作负载管理、各种类型的文件（Json、Binary、Parquet、TDMS、MDF4 等）、日志系统、专为处理规模而设计的新架构等的全新世界。
今天有很多方法来描述大数据。但是，最终，我们需要了解并理解这些工具，以便优化我们的工作并设计和实施最佳解决方案来满足我们的业务需求。

智程网络科技致力于大数据智能营销笔记本界面系统开发-网站建设-软件定制开发，欢迎咨询