带你了解，什么是大数据！（上）
介绍
如果您从大数据开始，通常会被众多工具，框架和选项所困扰。在本文中，我将尝试总结其成分和基本配方，以帮助您开始大数据之旅。我的目标是对不同的工具进行分类，并试图解释每个工具的目的以及它如何适应生态系统。
首先，让我们回顾一些注意事项，并检查您是否确实遇到大数据问题。我将重点介绍可以在本地部署的开源解决方案。云提供商为您的数据需求提供了几种解决方案，我将略微提及它们。如果您在云中运行，则应真正检查可用的选项，并与开源解决方案进行比较，以了解成本，可操作性，可管理性，监控和上市时间。
> Big Data Ecosystem
数据注意事项
（如果您有使用大数据的经验，请跳至下一部分……）
大数据非常复杂，除非绝对必要，否则请不要参与其中。要获得见解，请从小处着手，也许使用Elastic Search和Prometheus / Grafana来开始收集信息并创建仪表板以获取有关您的业务的信息。随着数据的扩展，这些工具可能不够好或维护成本太高。这是您应该开始考虑数据湖或数据仓库的时候。并改变主意，开始大胆思考。
检查数据量，有多少以及需要存储多长时间。检查温度！数据，它会随着时间的流逝而失去价值，那么您需要存储多长时间？您需要多少个存储层（热/热/冷）？您可以存档或删除数据吗？
您需要问自己的其他问题是：您存储的数据类型是什么？您使用哪种格式？您有任何法律义务吗？您需要多快提取数据？您需要多长时间可用于查询的数据？您期望什么类型的查询？OLTP还是OLAP？您的基础架构有哪些限制？您的数据是什么类型？有关系吗 图形？文件？您有要实施的架构吗？
我可能会写几篇有关此的文章，理解此数据，设置边界，要求，义务等非常重要，这样才能使此配方生效。
> 4Vs of Big Data
数据量是关键，如果每天要处理数十亿个事件或海量数据集，则需要将大数据原理应用于管道。但是，没有一个单一的边界可以将"小"数据与"大"数据以及其他方面（例如速度，团队组织，公司规模，所需分析类型，基础架构或业务目标）区分开来 您的大数据之旅。让我们回顾其中的一些……
OLTP与OLAP
几年前，企业曾经使用关系数据库支持在线应用程序，该关系数据库用于存储用户和其他结构化数据（OLTP）。一夜之间，这些数据使用复杂的作业存档到数据仓库中，该仓库针对数据分析和商业智能（OLAP）进行了优化。历史数据已复制到数据仓库中，并用于生成用于制定业务决策的报告。
数据仓库与数据湖
随着数据的增长，数据仓库变得昂贵且难以管理。此外，公司开始存储和处理非结构化数据，例如图像或日志。借助大数据，公司开始创建数据湖以集中其结构化和非结构化数据，从而创建一个包含所有数据的存储库。
简而言之，数据湖只是一组将数据存储在HA文件系统中的计算机节点，以及一组用于处理数据并从中获取见解的工具。 基于Map Reduce，创建了庞大的工具生态系统，例如Spark，可以使用更具成本效益的商品硬件处理任何类型的数据。其想法是，您可以在廉价的硬件中处理和存储数据，然后直接查询存储的文件而无需 使用数据库，但依赖于文件格式和外部架构，我们将在后面讨论。 Hadoop使用HDFS文件系统以经济高效的方式存储数据。
对于OLTP来说，近年来，已经转向NoSQL，它使用的数据库可能会扩展到SQL数据库的局限性之外，例如MongoDB或Cassandra。但是，最近的数据库可以处理大量数据，并且可以用于OLTP和OLAP，并且以低成本进行流处理和批处理。甚至YugaByteDB之类的事务数据库也可以处理大量数据。具有许多系统，应用程序，数据源和数据类型的大型组织将需要一个数据仓库和/或数据湖来满足其分析需求，但是如果您的公司没有太多的信息渠道和/或您在云中运行， 一个单一的大型数据库足以简化您的架构并大大降低成本。
Hadoop或非Hadoop
自2006年发布以来，Hadoop一直是大数据世界中的主要参考。基于MapReduce编程模型，它允许使用简单的编程模型来处理大量数据。多年来，该生态系统呈指数增长，从而创建了一个可以处理任何用例的丰富生态系统。
最近，人们对Hadoop生态系统提出了一些批评，并且很明显，在最近几年中，使用率一直在下降。能够使用自己的数据格式以超低延迟进行接收和查询的新OLAP引擎已取代了Hadoop中一些最常见的查询引擎。但是最大的影响是云提供商发布的无服务器分析解决方案数量增加，您可以在其中执行任何大数据任务而无需管理任何基础架构。
考虑到Hadoop生态系统的规模和庞大的用户群，这似乎还没有死，而且许多新的解决方案除了创建兼容的API和与Hadoop生态系统的集成外别无选择。尽管HDFS是生态系统的核心，但由于云提供商已构建了更便宜，更好的深度存储系统（例如S3或GCS），因此现在仅在本地使用。云提供商还提供开箱即用的托管Hadoop集群。看起来Hadoop仍然活跃并且活跃，但是您应该记住，在开始构建Hadoop生态系统之前，还有其他更新的选择。在本文中，我将尝试提及哪些工具是Hadoop生态系统的一部分，哪些与之兼容，哪些不是Hadoop生态系统的一部分。
批处理与流处理
根据对数据温度的分析，您需要确定是否需要实时流传输，批处理或在许多情况下都需要。
在理想环境中，您将实时地从实时数据中获取所有见解，并执行基于窗口的聚合。但是，对于某些用例来说，这是不可能的，而对于另一些用例，则没有成本效益。这就是为什么许多公司同时使用批处理和流处理的原因。您应该检查您的业务需求，并确定哪种方法更适合您。例如，如果只需要创建一些报告，则批处理就足够了。批处理更简单，更便宜。
最新的处理引擎，例如Apache Flink或Apache Beam，也称为第四代大数据引擎，为批处理和流数据提供统一的编程模型，其中批处理只是每24小时进行一次流处理。 这简化了编程模型。
一种常见的模式是具有流数据以获取时间紧迫的见解，例如信用卡欺诈，以及用于报告和分析的批处理。较新的OLAP引擎允许以统一的方式进行查询。
ETL与ELT
根据您的用例，您可能需要在加载或读取时转换数据。ELT意味着您可以执行将数据转换和聚合为查询一部分的查询，这可以使用SQL进行，您可以在其中应用函数，过滤数据，重命名列，创建视图等。BigData OLAP引擎可以实现 它提供了一种以ELT方式实时查询和批量查询的方法。另一种选择是在负载（ETL）上转换数据，但请注意，在处理过程中进行联接和聚合并不是一件容易的事。通常，数据仓库使用ETL，因为它们倾向于要求使用固定的模式（星型或雪花型），而数据湖更灵活，并且可以在读取时执行ELT和模式。
每种方法都有其自身的优点和缺点。简而言之，读取时的转换和聚合速度较慢，但提供了更大的灵活性。如果查询速度慢，则可能需要在处理阶段进行预加入或聚合。稍后讨论的OLAP引擎可以在摄取期间执行预聚合。
团队结构和方法
最后，您的公司政策，组织，方法论，基础架构，团队结构和技能在您的大数据决策中起着重要作用。例如，您可能有一个数据问题，需要您创建管道，但不必处理大量数据，在这种情况下，您可以编写一个流应用程序，在该应用程序中以 单一管道更容易；但是如果您的公司已经有一个数据湖，则您可能希望使用现有的平台，而这并不是您从头开始构建的。
另一个例子是ETL与ELT。开发人员倾向于构建ETL系统，在该系统中，数据可以以简单的格式进行查询，因此非技术人员可以构建仪表板并获得见解。但是，如果您有强大的数据分析人员团队和小型开发人员团队，则您可能更喜欢ELT方法，使开发人员只专注于提取；数据分析师编写复杂的查询来转换和聚合数据。这表明在大数据旅程中考虑团队结构和技能的重要性。
建议将一支具有不同技能和背景的多元化团队一起工作，因为数据是整个组织的跨职能部门。数据湖非常擅长在保持数据治理和安全性的同时实现轻松协作。
配料
在回顾了大数据世界的多个方面之后，我们来看看基本要素是什么。
数据存储
您需要的第一件事是一个存储所有数据的地方。不幸的是，没有一种产品可以满足您的需求，这就是为什么您需要根据用例选择合适的存储。
对于实时数据摄取，通常使用附加日志来存储实时事件，最著名的引擎是Kafka。另一种选择是Apache Pulsar。两者都提供流功能，还可以存储事件。这通常是热数据的短期存储（请记住数据温度！），因为它不经济高效。还有其他一些工具，例如用于存储数据的Apache NiFi，它们都有自己的存储空间。最终，数据将从附加日志传输到另一个存储，该存储可以是数据库或文件系统。
海量数据库
Hadoop HDFS是数据湖最常用的格式。大型数据库可以用作数据管道的后端，而不是文件系统。有关更多信息，请查看我先前在Massive Scale Databases上的文章。总之，诸如Cassandra，YugaByteDB或BigTable之类的数据库可以保存和处理大量数据，其速度比数据湖快得多，但价格却不便宜。但是，数据湖文件系统与数据库之间的价格差距逐年缩小。在Hadoop / NoHadoop决策中，您需要考虑这一点。现在，越来越多的公司选择大数据数据库而不是数据湖来满足其数据需求，而仅将深存储文件系统用于归档。
总结要考虑的Hadoop生态系统之外的数据库和存储选项是：
· Cassandra：NoSQL数据库，可以存储大量数据，提供最终的一致性和许多配置选项。非常适合OLTP，但可用于带有预先计算的聚合的OLAP（不灵活）。一个替代方案是ScyllaDB，对于OLAP（高级调度程序）而言，它更快，更好。
· YugaByteDB：大规模关系数据库，可以处理全球事务。关系数据的最佳选择。
· MongoDB：强大的基于文档的NoSQL数据库，可用于提取（临时存储）或用作仪表板的快速数据层
· InfluxDB用于时间序列数据。
· Prometheus用于监视数据。
· ElasticSearch：分布式倒排索引，可以存储大量数据。有时，ElasticSearch被许多人忽略或仅用于日志存储，它可用于各种用例，包括OLAP分析，机器学习，日志存储，非结构化数据存储等等。绝对是您在大数据生态系统中拥有的工具。
记住SQL和NoSQL之间的区别，在NoSQL世界中，您不对数据建模，而是对查询建模。
Hadoop数据库
HBase是Hadoop生态系统中最受欢迎的数据库。它可以以列格式保存大量数据。它基于BigTable。
文件系统（深度存储）
对于数据湖，在Hadoop生态系统中，使用HDFS文件系统。但是，大多数云提供商已将其替换为他们自己的深度存储系统，例如S3或GCS。
这些文件系统或深度存储系统比数据库便宜，但仅提供基本存储，不提供强大的ACID保证。
您将需要根据您的需求和预算为您的用例选择合适的存储。例如，如果您的预算允许，则可以使用数据库进行摄取，然后转换数据后，将其存储在数据湖中以进行OLAP分析。或者，您可以将所有内容存储在深度存储中，但将一小部分热数据存储在关系数据库等快速存储系统中。
文件格式
如果使用HDFS，另一个重要的决定是将使用哪种格式存储文件。请注意，深度存储系统将数据存储为文件，并且不同的文件格式和压缩算法为某些用例提供了好处。如何在数据湖中存储数据至关重要，您需要考虑格式，压缩方式，尤其是如何对数据进行分区。
最常见的格式是CSV，JSON，AVRO，协议缓冲区，Parquet和ORC。
> Comparison between file formats
选择格式时应考虑以下几点：
· 数据的结构：某些格式接受JSON，Avro或Parquet等嵌套数据，而其他格式则不接受。即使这样做，也可能不会对其进行高度优化。Avro是嵌套数据的最有效格式，我建议不要使用Parquet嵌套类型，因为它们效率很低。进程嵌套JSON也非常占用CPU。通常，建议在摄取数据时将其放平。
· 性能：Avro和Parquet等某些格式的性能优于其他JSON。即使在Avro和Parquet的不同用例之间，一个也会比其他更好。例如，由于Parquet是基于列的格式，因此使用SQL查询数据湖非常有用，而Avro更适合ETL行级转换。
· 易于阅读：考虑是否需要人们阅读数据。JSON或CSV是文本格式，并且易于阅读，而功能更强的格式例如镶木地板或Avro是二进制。
· 压缩：某些格式比其他格式提供更高的压缩率。
· 模式演变：在数据湖中添加或删除字段要比在数据库中复杂得多。诸如Avro或Parquet之类的某些格式提供了某种程度的架构演变，使您可以更改数据架构并仍然查询数据。诸如Delta Lake格式的工具甚至提供了更好的工具来处理模式中的更改。
· 兼容性：JSON或CSV被广泛采用并与几乎所有工具兼容，而性能更高的选项具有较少的集成点。
如我们所见，CSV和JSON易于使用，易于阅读和通用格式，但是缺乏其他格式的许多功能，因此它太慢而无法用于查询数据湖。ORC和Parquet在Hadoop生态系统中被广泛用于查询数据，而Avro还在Hadoop之外使用，尤其是与Kafka一起用于提取时，对于行级ETL处理非常有用。面向行的格式比面向列的格式具有更好的模式演变功能，这使它们成为数据提取的理想选择。
最后，您还需要考虑文件大小和CPU成本之间的权衡，如何压缩文件中的数据。某些压缩算法速度更快，但文件大小更大；另一些压缩算法速度较慢，但压缩率更高。有关更多详细信息，请查看本文。
> Compression options
我建议使用快照来流式传输数据，因为它不需要太多的CPU能力。对于批处理，bzip2是一个不错的选择。
同样，您需要查看我们之前提到的注意事项，并根据我们查看的所有方面进行决策。让我们以一些用例为例：
用例
· 您需要在某处提取实时数据和存储，以作为ETL管道的一部分进行进一步处理。如果性能很重要并且预算不是问题，则可以使用Cassandra。标准方法是使用优化格式（如AVRO）将其存储在HDFS中。
· 您需要在某个地方处理数据和存储，以供高度交互的面向用户的应用程序使用，其中延迟很重要（OLTP），您需要提前知道查询。在这种情况下，请根据数据量使用Cassandra或其他数据库。
· 您需要将处理后的数据提供给您的用户群，一致性很重要，并且由于UI提供了高级查询，因此您不预先知道查询。在这种情况下，您需要一个关系SQL数据库，根据您的情况，像MySQL这样的经典SQL数据库就足够了，或者您可能需要使用YugaByteDB或其他关系大规模数据库。
· 您需要为内部团队存储处理后的数据以进行OLAP分析，以便他们可以运行临时查询并创建报告。在这种情况下，您可以将数据以Parquet或ORC格式存储在深度存储文件系统中。
· 您需要使用SQL来运行历史数据的临时查询，但是您还需要仪表板，这些仪表板需要在不到一秒钟的时间内做出响应。在这种情况下，您需要一种混合方法，在该方法中，将数据的子集存储在快速存储中（例如MySQL数据库），并将历史数据以Parquet格式存储在数据湖中。然后，使用查询引擎使用SQL跨不同的数据源进行查询。
· 您需要执行非常复杂的查询，而这些查询只需几毫秒即可响应，还可能需要在读取时执行聚合。在这种情况下，请使用ElasticSearch存储数据或某些较新的OLAP系统（如Apache Pinot），稍后我们将对其进行讨论。
· 您需要搜索非结构化文本。在这种情况下，请使用ElasticSearch。
基础设施
当前的基础架构会在决定使用哪些工具时限制您的选择。要问的第一个问题是：云计算与本地部署。云提供商提供了许多选择和灵活性。此外，它们为您的大数据需求提供了无服务器解决方案，更易于管理和监控。无疑，云是存放大数据的地方。即使对于Hadoop生态系统，云提供商也提供托管群集和比本地存储便宜的存储。查看我有关云解决方案的其他文章。
如果您在场所中运行，则应考虑以下事项：
· 我在哪里运行工作负载？毫无疑问，Kubernetes或Apache Mesos提供了一个统一的编排框架，以统一的方式运行您的应用程序。无论使用哪种框架，部署，监视和警报方面都是相同的。相反，如果您使用裸机运行，则需要考虑和管理部署的所有交叉方面。在这种情况下，托管集群和工具将比库和框架更适合。
· 我拥有哪种类型的硬件？如果您具有带有快速SSD和高端服务器的专用硬件，则可以部署Cassandra等大型数据库并获得出色的性能。如果您仅拥有商品硬件，那么Hadoop生态系统将是一个更好的选择。理想情况下，您希望针对不同的工作负载使用多种类型的服务器。Cassandra的要求与HDFS有很大不同。
监控和警报
下一个要素对于数据管道的成功至关重要。在大数据世界中，您需要有关流程和数据的不断反馈。您需要收集指标，收集日志，监视系统，创建警报，仪表板等等。
使用Prometheus和Grafana等开源工具进行监视和警报。使用日志聚合技术来收集日志并将其存储在诸如ElasticSearch之类的地方。
> Grafana Monitoring
利用云提供商的功能进行监视和警报（如果可能）。根据您的平台，您将使用不同的工具集。对于无云服务器平台，您将依靠您的云提供商工具和最佳实践。对于Kubernetes，您将使用开源监控器解决方案或企业集成。我真的推荐这个网站，在这里您可以浏览和检查不同的解决方案，并构建自己的APM解决方案。
大数据世界中要考虑的另一件事是可审计性和问责制。由于法规不同，您可能需要跟踪数据，捕获和记录数据流经管道时的所有更改。这称为数据来源或血统。诸如Apache Atlas之类的工具用于控制，记录和管理您的数据。其他工具如Apache NiFi也支持开箱即用的数据沿袭。有关实时跟踪，请检查"打开遥测"或" Jaeger"。还有很多云服务，例如Datadog。
对于Hadoop，使用Ganglia。
安全
Apache Ranger为您的Hadoop平台提供了统一的安全监控框架。提供集中的安全性管理，以在中央UI中管理所有与安全性相关的任务。它使用不同的方法提供授权，并在整个Hadoop平台上提供全面的可审核性。
人
您的团队是成功的关键。大数据工程师可能很难找到。投资于培训，技能提升，研讨会。删除孤岛和繁文tape节，简化迭代过程，并使用域驱动设计来设置团队边界和职责。
对于大数据，您将分为两大类：
· 数据工程师进行摄取，丰富和转换。这些工程师具有强大的开发和运营背景，并负责创建数据管道。开发人员，管理员，DevOps专家等将属于此类别。
· 数据科学家：他们可以是BI专家，数据分析师等，负责生成报告，仪表板和收集见解。这些人专注于OLAP并具有深刻的业务理解，收集了将用于制定关键业务决策的数据。SQL和可视化方面很强，但是软件开发方面很弱。机器学习专家也可能属于此类。
预算
这是一个重要的考虑因素，您需要金钱来购买所有其他成分，并且这是有限的资源。如果您有无限的资金，则可以部署海量的数据库并将其用于大数据需求而不会带来很多麻烦，但这会花费您很多钱。因此，本文中提到的每种技术都需要具备使用，部署和维护技术的人员。有些技术比其他技术更复杂，因此您需要考虑到这一点。
食谱
现在我们已经掌握了食材，让我们来烹饪我们的大数据食谱。简而言之，该过程很简单；您需要从不同来源获取数据，对其进行充实，将其存储在某个位置，存储元数据（模式），对其进行清理，对其进行规范化，对其进行处理，隔离不良数据，以最佳方式聚合数据并将其最终存储在某个位置以供下游系统使用 。
让我们更详细地了解每个步骤…
数据摄取
第一步是获取数据，此阶段的目标是获取所需的所有数据并将其以原始格式存储在单个存储库中。它通常由将其数据推送到Kafka或数据存储中的其他团队拥有。
对于没有大量数据的简单管道，您可以构建一个简单的微服务工作流，该工作流可以在单个管道中摄取，丰富和转换数据（注入+转换），您可以使用Apache Airflow之类的工具来编排依赖性。但是，对于大数据，建议您将摄取与处理分开，可以并行运行的海量处理引擎对于处理阻塞调用，重试，背压等效果不佳。因此，建议在保存所有数据之前 您开始处理它。作为调用的一部分，您应该通过调用其他系统来确保您的数据丰富，以确保所有数据（包括参考数据）在处理之前都已落入湖泊中。
有两种摄取方式：
· 拉取：从数据库，文件系统，队列或API等地方提取数据
· 推送：应用程序也可以将数据推送到您的湖泊中，但始终建议在两者之间使用一个消息传递平台，例如Kafka。常见的模式是变更数据捕获（CDC），它使我们能够将数据从数据库和其他系统实时移入湖泊。
正如我们已经提到的，使用Kafka或Pulsar作为数据摄取的中介是极为常见的，以实现持久性，背压，并行化和摄取的监控。然后，使用Kafka Connect将数据保存到您的数据湖中。这个想法是您的OLTP系统将事件发布到Kafka，然后将其吸收到您的湖泊中。避免直接通过API批量提取数据；您可能会调用HTTP端点进行数据充实，但请记住，从API提取数据在大数据世界中并不是一个好主意，因为它速度慢，容易出错（网络问题，延迟等），并且可能导致源系统崩溃。尽管API非常适合在OLTP世界中设置域边界，但这些边界是由大数据世界中Kafka中的数据存储（批次）或主题（实时）来设置的。当然，它总是取决于数据的大小，但是如果可能，如果没有其他选择，请尝试使用Kafka或Pulsar。以流式方式从API中提取少量数据，而不是批量提取。对于数据库，请使用Debezium等工具将数据流式传输到Kafka（CDC）。
为了最大程度地减少依赖性，如果源系统将数据推送到Kafka而不是您的团队提取数据，则总是比较容易，因为您将与其他源系统紧密耦合。如果无法做到这一点，并且您仍然需要掌握摄取过程，那么我们可以考虑两种主要的摄取类别：
· Un Managed Solutions：这些是您开发的应用程序，用于将数据提取到数据湖中；您可以在任何地方运行它们。从没有现成解决方案的API或其他I / O阻止系统中提取数据时，或者在不使用Hadoop生态系统时，这非常常见。这个想法是使用流媒体库从不同的主题，端点，队列或文件系统中摄取数据。因为您正在开发应用程序，所以您具有完全的灵活性。大多数库提供重试，背压，监视，批处理等等。这是您自己的代码方法，因此您将需要其他工具来进行编排和部署。您可以获得更多的控制权和更好的性能，但需要付出更多的努力。您可以使用服务总线使单个整体或微服务进行通信，或者使用外部工具进行协调。一些可用的库是Apache Camel或Akka生态系统（Akka HTTP + Akka流+ Akka集群+ Akka Persistence + Alpakka）。您可以将其部署为整体或微服务，具体取决于接收管道的复杂程度。如果您使用Kafka或Pulsar，则可以将它们用作获取编排工具来获取数据并丰富数据。每个阶段都将数据移动到一个新主题，通过使用主题进行依赖性管理在基础架构中创建DAG。如果您没有Kafka，并且想要一个更直观的工作流程，则可以使用Apache Airflow来协调依赖关系并运行DAG。这个想法是要提供一系列服务来摄取和丰富日期，然后将其存储在某个地方。完成每个步骤后，将执行下一个步骤并由Airflow进行协调。最后，数据存储在某种存储中。
· 托管解决方案：在这种情况下，您可以使用部署在群集中并用于提取的工具。这在Hadoop生态系统中很常见，在该生态系统中，您拥有诸如Sqoop之类的工具来从OLTP数据库中获取数据，而Flume则具有从流媒体中获取数据的能力。这些工具提供监视，重试，增量负载，压缩等功能。
Apache NiFi
NiFi是其中很难分类的工具之一。它本身就是野兽。它可以用于摄取，编排甚至简单的转换。因此，从理论上讲，它可以解决简单的大数据问题。这是一个托管解决方案。它具有可视界面，您可以在其中拖放组件并使用它们来摄取和丰富数据。它具有300多个内置处理器，可以执行许多任务，您可以通过实现自己的处理器来扩展它。
> NiFi workflow
它具有自己的体系结构，因此它不使用任何数据库HDFS，但已与Hadoop生态系统中的许多工具集成。您可以调用API，并与Kafka，FTP，许多文件系统和云存储集成。您可以管理执行路由，过滤和基本ETL的数据流。对于某些用例，您可能只需要NiFi。
但是，由于节点间的通信，群集中的10个以上节点效率低下，因此NiFi无法扩展到某个特定点。它倾向于在垂直方向更好地扩展，但是您可以达到其极限，尤其是对于复杂的ETL。但是，您可以将其与Spark等工具集成以处理数据。NiFi是吸收和丰富数据的绝佳工具。
诸如Druid或Pinot之类的现代OLAP引擎还提供了自动提取批处理和流数据的功能，我们将在另一部分中讨论它们。
您也可以在提取过程中进行一些初始验证和数据清理，只要它们不是昂贵的计算或不跨越有限的上下文，请记住，空字段可能与您无关，但对另一个团队很重要。
最后一步是确定数据的放置位置，我们已经讨论过了。您可以使用数据库或深度存储系统。对于数据湖，通常将其存储在HDFS中，其格式取决于下一步；请参见下一步。如果您打算执行行级操作，Avro是一个不错的选择。Avro还使用外部注册表支持架构演变，这将使您可以相对轻松地更改所摄取数据的架构。
下集见
猜你喜欢：
