文章发表于2023-11-29 09:42:17，归属【科技前沿】分类，已有399人阅读
在2016年对大数据部门负责人进行的一些调查中，数据种类被强调为最重要的因素，其次是数据量(25%)，最后是速度(6%)。2017年的趋势强调，巨大的机会在于整合更多的数据源，而不是更大的数据量，而是不同的数据源。换句话说，它突出了多样性的特征作为最重要的特征，将体积的特征退居其次。这就是为什么公司专注于识别新数据源和集成传统上用于其他目的(例如支持其应用程序)的数据源的原因：更多地利用数据源已成为企业界的新挑战。
在设计大数据架构时，我们发现自己有一个非常广泛且不断增长的工具箱，当面对这种挑战时，我们常常会感到不知所措，因为我相信这种感觉已经在某些时候出现了，所以我决定写这篇文章，以便在设计大数据架构时帮助您。
在你开始阅读这篇文章之前，我不希望你认为读完这篇文章你就有了体系结构的解决方案，你不会有应该使用的体系结构的“图片”，因为没有一个单一的体系结构涵盖了所有的用例，但是我希望通过这篇文章我们知道：在设计一个解决方案时我们要问自己什么，以及我们必须考虑什么。
通常情况下，我们发现，当我们实施一个新的大数据架构时，我们是为了一个“小目标”而做的，也就是说，它源于为一个具体的用例提供解决方案的需要。一方面，这是积极的，也是我们在其他场合强烈推荐的：“专注于你的目标”。如果没有明确的目标，您的解决方案可能会失败，但另一方面，您必须考虑到体系结构将会增长，并且必须能够支持未来的用例。
最重要的事情之一是，您定义了体系结构将具有的高级“层”，并且您的层中没有一个是基于特定工具，因为很多时候，体系结构将需要不同类型的工具来覆盖它必须响应的不同问题。让我们看一个小例子：
我们的大数据架构必须有一个数据入口点，或者通常被称为“数据摄取层”，如果我们的用例需要从关系数据库中获取数据，您可能会决定使用“Sqoop”作为工具。当你将来需要读取文件、日志、电子邮件时怎么办?你将不得不整合新的工具，如Flume, Nifi等。
这种情况不仅会发生在“数据摄取层”中，还会发生在体系结构的不同层中，因此我的建议是不要使用工具进行设计，而是尝试让您的体系结构基于作为体系结构每一层的一部分的模块化节点。这将使您的设计成为可扩展的模块化架构。
使用不同的工具将允许您为更多的用例提供解决方案，但这并不意味着您使用了所有的工具。尝试在合并工具之前对其进行评估，并提前考虑，因为具有各种工具的系统将增加其管理方面的复杂性。
在您的架构应该具备的特征中，我们发现：
1. 可伸缩性：它必须能够增加系统每一层的硬件容量，在某些情况下增加其处理能力，在其他情况下增加其存储能力。
2. 容错：当任何服务器或节点出现故障时，系统必须保证其可用性，避免数据丢失。这适用于体系结构的每一层。
3. 数据分布：请记住，由于信息量很大，这些系统会分布数据，为此，您需要为您的体系结构配备容纳信息的不同节点。这种类型的解决方案与基于数据中心性的传统解决方案相去甚远。
4. 分布式处理：当处理大量信息并应用或多或少复杂的算法时，这些解决方案基于分布式处理来优化执行时间。这意味着您的设计必须准备好使用不同的节点来分布数据处理，并具有扩展的能力。
5. 数据位置：这个术语在大数据系统中被广泛使用，指的是分析过程和被处理数据之间的接近程度。这些体系结构必须有利于数据的位置，以避免网络传输，这在传统系统中不被认为是关键点，但在这些系统中可能会影响执行时间。
在选择技术时，不要不知所措。以下是一些可以帮助你进行设计的技巧：
1. 在信息获取中：评估您的来源类型，并不是所有的工具都适合每个来源，在某些情况下，您会发现最好结合几个工具来覆盖所有的情况。
2. 在处理过程中：评估你的系统是流处理还是批处理。一些不被定义为纯流的系统使用他们所谓的微批处理，它通常给出在日常语言使用中称为流的问题的答案。
3. 在监控方面：请记住，我们谈论的是大量的工具，它们的监控、控制和管理可能非常繁琐，所以无论您决定安装完整的堆栈还是安装独立的工具并生成自己的体系结构，我还建议您使用工具来控制、监控和管理您的体系结构，这将促进和集中所有这些任务。
不要偏离你的道路，有些事情我们必须牢记在心：
当然，随着您在设计大数据架构方面积累了经验，您可以在这个主题上给我一些想法，但就目前而言，从我的角度来看，这些是您在开始设计解决方案之前应该知道的一些主要答案。
1. 专注于您的用例，当您的目标明确时，您将知道如何授权您的体系结构。体积、种类、速度……你真的都需要吗?
2. 定义架构：批处理还是流处理?你真的需要你的架构来支持流吗?
3. 评估数据源：数据源的异构程度如何?所选择的工具是否支持所有类型的数据源?