一文带你了解大数据管道

 介绍

如果您从大数据开始，通常会被众多工具，框架和选项所困扰。 在本文中，我将尝试总结其成分和基本配方，以帮助您开始大数据之旅。 我的目标是对不同的工具进行分类，并试图解释每个工具的目的以及它如何适应生态系统。

首先，让我们回顾一些注意事项，并检查您是否确实遇到大数据问题。 我将重点介绍可以在本地部署的开源解决方案。 云提供商为您的数据需求提供了几种解决方案，我将略微提及它们。 如果您在云中运行，则应真正检查可用的选项，并与开源解决方案进行比较，以了解成本，可操作性，可管理性，监控和上市时间。 

> 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中一些最常见的查询引擎。 但是最大的影响是云提供商发布的无服务器分析解决方案数量增加，您可以在其中执行任何大数据任务而无需管理任何基础架构。 

> Simplified Hadoop Ecosystem

考虑到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还使用外部注册表支持架构演变，这将使您可以相对轻松地更改所摄取数据的架构。

元数据

存储数据后，下一步是保存其元数据(有关数据本身的信息)。 最常见的元数据是架构。 通过使用外部元数据存储库，数据湖或数据管道中的不同工具可以查询它以推断数据模式。

如果将Avro用作原始数据，则外部注册表是一个不错的选择。 这样，您就可以轻松地将处理过程中的提取分离。

数据一旦被摄取，为了由OLAP引擎查询，通常会使用SQL DDL。 Hadoop生态系统中最常用的数据湖/数据仓库工具是Apache Hive，它提供了元数据存储，因此您可以像定义了架构的数据仓库一样使用数据湖。 您可以在Hive上运行SQL查询，并连接许多其他工具(例如Spark)以使用Spark SQL运行SQL查询。 Hive是Hadoop生态系统内部的重要工具，可为您的分析查询提供集中的元数据库。 其他工具如Apache Tajo都建立在Hive之上，以在您的数据湖中提供数据仓库功能。 

Apache Impala是Hadoop的本地分析数据库，它提供元数据存储，您仍然可以使用Hcatalog连接到Hive以获取元数据。

Apache Phoenix还有一个metastore，可以与Hive一起使用。 Phoenix致力于OLTP，从而启用对事务具有ACID属性的查询。 它具有灵活性，并通过利用HBase作为其后备存储来提供NoSQL世界中的读取模式架构功能。 Apache Druid或Pinot还提供元数据存储。

数据处理

此阶段的目标是使用单个架构清理，规范化，处理和保存数据。 最终结果是具有良好定义的架构的可信数据集。

通常，您需要执行某种处理，例如：

• 验证：通过将数据存储在单独的存储中来验证数据并隔离不良数据。 根据数据质量要求，在达到特定阈值时发送警报。
• 整理和清理：清理数据并将其存储为另一种格式，以便进一步处理，例如，用Avro替换低效的JSON。
• 值的标准化和标准化
• 重命名字段
• …

请记住，目标是创建一个可信的数据集，以后可用于下游系统。 这是数据工程师的关键角色。 这可以以流或批处理的方式完成。

在批处理的情况下，流水线处理可以分为三个阶段：

• 预处理阶段：如果原始数据不干净或格式不正确，则需要对其进行预处理。 此阶段包括一些基本验证，但目标是准备要在下一步进行有效处理的数据。 在此阶段，您应该尝试展平数据并将其保存为二进制格式(例如Avro)。 这将加快进一步处理的速度。 这个想法是，下一阶段将执行行级操作，并且嵌套查询非常昂贵，因此现在对数据进行平整将提高下一阶段的性能。
• 可信阶段：数据经过验证，清理，规范化并转换为Hive中存储的通用模式。 目标是创建数据所有者理解的受信任的通用数据集。 通常，将创建一个数据规范，数据工程师的职责是应用转换以匹配该规范。 最终结果是以Parquet格式设置的数据集，可以轻松查询该数据集。 选择正确的分区并优化数据以执行内部查询至关重要。 您可能希望在此阶段部分地预先计算一些聚合，以提高查询性能。
• 报告阶段：此步骤是可选的，但通常是必需的。不幸的是，当使用数据湖时，单个模式不能满足所有用例。这是数据仓库和数据湖之间的区别。查询HDFS的效率不如数据库或数据仓库，因此需要进一步的优化。在此阶段，您可能需要对数据进行规范化处理，以使用不同的分区存储数据，以便不同的涉众可以更有效地查询数据。这个想法是创建针对不同下游系统(数据集市)优化的不同视图。在此阶段，如果您不使用OLAP引擎，则还可以计算聚合(请参阅下一节)。受信任的阶段对谁将查询数据一无所知，该阶段为使用者优化了数据。如果客户端是高度交互的，则您可能希望在此阶段引入快速存储层，例如用于快速查询的关系数据库。或者，您可以使用OLAP引擎，我们将在后面讨论。

对于流来说，逻辑是相同的，但是它将以流的方式在定义的DAG中运行。 Spark允许您将流与历史数据一起加入，但存在一些限制。 稍后我们将讨论OLAP引擎，该引擎更适合于将实时数据与历史数据合并。

处理框架

可用于处理的一些工具是：

· Apache Spark：这是最著名的批处理框架。 它是Hadoop生态系统的一部分，是一个托管集群，可提供令人难以置信的并行性，监控和出色的UI。 它还支持流处理(结构流)。 基本上，Spark在内存中运行MapReduce作业，其性能是常规MapReduce性能的100倍。 它与Hive集成在一起以支持SQL，并可用于创建Hive表，视图或查询数据。 它具有很多集成，支持多种格式，并且拥有庞大的社区。 所有云提供商都支持它。 它可以作为Hadoop集群的一部分在YARN上运行，也可以在Kubernetes和其他平台上运行。 它具有许多针对特定用例(例如SQL或机器学习)的库。 

• Apache Flink：第一个统一批处理和流传输的引擎，但主要关注流传输。 它可以用作像Kafka这样的微服务的主干。 它可以作为Hadoop集群的一部分在YARN上运行，但自成立以来，它还针对其他平台(如Kubernetes或Mesos)进行了优化。 它非常快，并提供实时流传输，使其成为比Spark在低延迟流处理(尤其是有状态流)方面更好的选择。 它还具有用于SQL，机器学习等的库。 

 

• Apache Storm：Apache Storm是一个免费的开源分布式实时计算系统，它专注于流传输，是Hadoop生态系统的托管解决方案部分。 它具有可扩展性，容错性，可确保您的数据将得到处理，并且易于设置和操作。
• Apache Samza：另一个出色的有状态流处理引擎。 Samza允许您构建有状态的应用程序，以从多个来源(包括Apache Kafka)实时处理数据。 在YARN之上运行的Hadoop生态系统的托管解决方案部分。 

• Apache Beam：Apache Beam本身不是引擎，而是将所有其他引擎结合在一起的统一编程模型的规范。 它提供了可以与不同语言一起使用的编程模型，因此开发人员在处理大数据管道时不必学习新的语言。 然后，它为可在云或本地运行的处理步骤插入了不同的后端。 Beam支持前面提到的所有引擎，您可以在它们之间轻松切换并在任何平台上运行它们：云，YARN，Mesos，Kubernetes。 如果您要开始一个新项目，我真的建议您从Beam开始，以确保您的数据管道可以用于将来。 

在此处理阶段结束时，您已经烹饪了数据，现在可以使用了!但是，为了烹饪，厨师必须与团队合作…

编排

数据管道编排是一个交叉过程，它管理所有其他任务之间的依赖关系。 如果使用流处理，则需要编排每个流应用程序的依赖关系，而对于批处理，则需要安排和编排作业。

任务和应用程序可能会失败，因此您需要一种以统一的方式计划，重新计划，重放，监视，重试和调试整个数据管道的方法。

诸如Dagster或Prefect之类的较新框架添加了更多功能，并允许您跟踪向管道添加语义的数据资产。

一些选项是：

• Apache Oozie：Oozie是Hadoop的调度程序，作业创建为DAG，并且可以由时间或数据可用性触发。 它与Sqoop等提取工具和Spark等处理框架集成在一起。
• Apache Airflow：Airflow是一个平台，可用于计划，运行和监视工作流程。 使用DAG创建复杂的工作流程。 图中的每个节点都是一个任务，边定义了任务之间的依存关系。 Airflow Scheduler在遵循您描述的指定依赖项的同时，在一组工作线程上执行您的任务。 它为您生成DAG，以最大程度地提高并行度。 DAG是用Python编写的，因此您可以在本地运行它们，对其进行单元测试并将其与开发工作流程集成。 它还支持SLA和警报。 Luigi是具有类似功能的Airflow的替代产品，但Airflow具有更多功能，并且比Luigi具有更好的扩展性。
• Dagster‘s 机器学习，分析和ETL的新型协调器。 主要区别在于您可以跟踪数据的输入和输出，类似于Apache NiFi创建数据流解决方案。 您还可以在任务中实现其他值。 它还可以并行运行多个作业，易于添加参数，易于测试，提供简单的版本控制等等。 它仍然有些不成熟，由于需要跟踪数据，因此可能难以扩展，这是NiFi面临的一个问题。
• Prefect与Dagster相似，提供本地测试，版本控制，参数管理等等。 Prefect之所以与众不同，是为了克服Airflow执行引擎的局限性，例如改进的计划程序，参数化的工作流，动态工作流，版本控制和改进的测试。 它具有一个核心的开源工作流管理系统以及一个完全不需要设置的云产品。
• Apache NiFi：NiFi还可以安排作业，监视，路由数据，警报等等。 它专注于数据流，但您也可以处理批处理。 它在Hadoop外部运行，但可以触发Spark作业并连接到HDFS / S3。

简而言之，如果您的需求只是编排不需要共享数据的独立任务，请使用Airflow或Ozzie。 对于需要数据沿袭和跟踪的数据流应用程序，对于非开发人员请使用NiFi，对于开发人员请使用Dagster或Prefect。

数据质量

大数据中经常忽略的一个重要方面是数据质量和保证。 由于数据质量问题，公司每年都会损失大量资金。 问题在于，这仍然是数据科学领域中一个不成熟的领域，开发人员已经在这一领域工作了数十年，他们拥有出色的测试框架和方法，例如BDD或TDD，但是您如何测试管道?

该领域存在两个常见问题：

• 误解的要求：转换和编排逻辑经常会变得非常复杂。 业务分析师可以使用他们的领域语言来编写需求，开发人员通常会犯错，并计划，开发，测试和部署技术上正确但有错误需求的解决方案。 这些类型的错误非常昂贵。
• 数据验证：管道测试与代码完全不同。 开发软件时，您要测试功能，这是确定性的黑盒测试。 对于给定的输入，您始终会获得相同的输出。 对于数据资产，测试更加复杂：您需要声明数据类型，值，约束等等。 此外，您需要应用聚合来验证数据集，以确保行数或列数正确。 例如，很难检测是否有一天您的数据量下降了10%，或者某些值是否正确填充。

公司在数据质量和测试方面仍处于起步阶段，这造成了巨大的技术负担。 我真的建议查看这篇文章以获取更多信息。

为了缓解这些问题，请尝试遵循DDD原则，并确保设置了边界并使用了通用语言。 使用支持数据谱系的框架，例如NiFi或Dagster。

一些关注数据质量的工具是：

• Apache Griffin：此工具是Hadoop生态系统的一部分，它提供了一个统一的过程，可以从不同角度衡量数据质量，从而帮助您构建可信任的数据资产。 它提供了一个DSL，可用于为数据创建断言并将其验证为管道的一部分。 它与Spark集成在一起。 您可以为数据集添加规则和断言，然后将验证作为Spark作业运行。 Griffin的问题在于DSL可能变得难以管理(JSON)，并且非技术人员难以解释，这意味着它无法解决被误解的需求问题。 

> Apache Griffin Processes

• Great Expectations ：这是一个用Python编写的更新工具，专注于数据质量，管道测试和质量保证。它可以轻松地与Airflow或其他编排工具集成，并提供自动数据验证。使该工具与众不同的是事实，它是人类可读的，并且可由数据分析师，BA和开发人员使用。它提供了直观的UI，还提供了完全自动化的功能，因此您可以将验证作为生产管道的一部分运行，并在漂亮的UI中查看结果。非技术人员可以使用笔记本编写断言，这些笔记本提供开发人员可以轻松理解，转换为代码并用于测试的文档和正式要求。 BA或测试人员编写数据断言(期望)，然后将其转换为UI中的人类可读测试，以便每个人都可以看到并验证它们。它还可以进行数据分析以为您生成一些断言。它可以直接连接到本地或云中的数据库或文件系统。它非常易于使用和管理。可以将期望值提交到源代码存储库，然后将其集成到管道中。伟大的期望为涉及数据质量的所有各方创建了一种通用的语言和框架，从而非常容易地以最小的努力来自动化和测试管道。 

 

> Great expectations UI

数据查询

现在，您已经掌握了烹调方法，现在该从该方法中获得最大价值了。 至此，您已经使用一些深层存储(如HDFS)以可查询的格式(例如Parquet或OLAP数据库)将数据存储在数据湖中。

有多种工具可用于查询数据，每种工具都有其优点和缺点。 它们中的大多数都集中在OLAP上，但是也很少针对OLTP进行过优化。 有些使用标准格式，仅专注于运行查询，而另一些使用自己的格式/存储将处理推送到源，以提高性能。 有些使用星型或雪花模式针对数据仓库进行了优化，而另一些则更为灵活。 总结这些是不同的注意事项：

• 数据仓库与数据湖
• Hadoop与独立
• OLAP与OLTP
• 查询引擎与OLAP引擎

我们还应该考虑具有查询功能的处理引擎。

处理引擎

我们在上一节中描述的大多数引擎都可以连接到元数据服务器，例如Hive并运行查询，创建视图等。这是创建精细报表层的常见用例。

Spark SQL提供了一种将SQL查询与Spark程序无缝混合的方法，因此您可以将DataFrame API与SQL混合。 它具有Hive集成和通过JDBC或ODBC的标准连接; 因此您可以通过Spark将Tableau，Looker或任何BI工具连接到数据。 

Apache Flink还提供SQL API。 Flink的SQL支持基于实现SQL标准的Apache Calcite。 它还通过HiveCatalog与Hive集成。 例如，用户可以使用HiveCatalog将其Kafka或ElasticSearch表存储在Hive Metastore中，并稍后在SQL查询中重新使用它们。

查询引擎

这类工具专注于以统一的方式查询不同的数据源和格式。 这个想法是使用SQL查询来查询您的数据湖，就像它是一个关系数据库一样，尽管它有一些限制。 其中一些工具还可以查询NoSQL数据库等等。 这些工具为外部工具(如Tableau或Looker)提供JDBC接口，以安全方式连接到您的数据湖。 查询引擎是最慢的选择，但提供最大的灵活性。

• Apache Pig：它是与Hive一起使用的最早的查询语言之一。 它有自己的语言，不同于SQL。 Pig程序的显着特性是它们的结构适合于实质性的并行化，从而使它们能够处理非常大的数据集。 现在，它越来越倾向于使用基于SQL的新引擎。
• Presto：由Facebook发布为开源，它是一个开源的分布式SQL查询引擎，用于对各种规模的数据源运行交互式分析查询。 Presto允许查询数据所在的位置，包括Hive，Cassandra，关系数据库和文件系统。 它可以在几秒钟内对大型数据集执行查询。 它独立于Hadoop，但与大多数工具集成在一起，尤其是Hive以运行SQL查询。
• Apache Drill：为Hadoop，NoSQL甚至云存储提供无模式的SQL查询引擎。 它独立于Hadoop，但与Hive等生态系统工具集成了许多功能。 单个查询可以联接来自多个数据存储的数据，从而执行特定于每个数据存储的优化。 即使分析人员在后台读取文件，它也非常擅长让分析人员将任何数据视为表。 Drill支持完全标准的SQL。 商业用户，分析师和数据科学家可以使用标准的BI /分析工具(例如Tableau，Qlik和Excel)来利用Drill的JDBC和ODBC驱动程序与非关系数据存储进行交互。 此外，开发人员可以在其自定义应用程序中利用Drill的简单REST API来创建精美的可视化效果。 

> Drill model

OLTP数据库

尽管Hadoop已针对OLAP进行了优化，但是如果您要为交互式应用程序执行OLTP查询，仍然有一些选择。

HBase在设计上具有非常有限的ACID属性，因为它是按比例扩展的，并且不提供现成的ACID功能，但是可以用于某些OLTP场景。

Apache Phoenix建立在HBase之上，并提供了一种在Hadoop生态系统中执行OTLP查询的方法。 Apache Phoenix与其他Hadoop产品(例如Spark，Hive，Pig，Flume和Map Reduce)完全集成。 它还可以存储元数据，并支持通过DDL命令创建表和版本化的增量更改。 它非常快，比使用Drill或其他查询引擎要快。

您可以使用Hadoop生态系统以外的任何大规模数据库，例如Cassandra，YugaByteDB，SyllaDB for OTLP。

最后，在任何类型的快速数据库(例如MongoDB或MySQL)中拥有数据的子集(通常是最新数据)是很常见的。 上面提到的查询引擎可以在单个查询中在慢速和快速数据存储之间加入数据。

分布式搜索索引

这些工具提供了一种存储和搜索非结构化文本数据的方法，并且由于它们需要特殊的结构来存储数据，因此它们位于Hadoop生态系统之外。 这个想法是使用倒排索引来执行快速查找。 除了文本搜索外，该技术还可以用于各种用例，例如存储日志，事件等。有两个主要选项：

• Solr：这是一个基于Apache Lucene的流行，快速，开放源代码的企业搜索平台。 Solr是可靠的，可伸缩的和容错的，提供分布式索引，复制和负载平衡查询，自动故障转移和恢复，集中式配置等。 它非常适合文本搜索，但与ElasticSearch相比，它的用例有限。
• ElasticSearch：它也是一种非常流行的分布式索引，但是已经发展成为自己的生态系统，涵盖了许多用例，例如APM，搜索，文本存储，分析，仪表板，机器学习等。 它绝对是一种非常有用的工具，可用于DevOps或数据管道，因为它用途广泛。 它还可以存储和搜索视频和图像。

ElasticSearch可用作数据湖的快速存储层，以提供高级搜索功能。 如果将数据存储在键值型海量数据库中，例如HBase或Cassandra，由于缺少联接，它们提供的搜索功能非常有限; 您可以将ElasticSearch放在前面以执行查询，返回ID，然后对数据库进行快速查找。

它也可以用于分析。 您可以导出数据，对其进行索引，然后使用Kibana对其进行查询，创建仪表板，报告等等，还可以添加直方图，复杂的聚合甚至在数据之上运行机器学习算法。 弹性生态系统非常庞大，值得探索。 

OLAP数据库

在此类别中，我们有数据库，该数据库还可以提供用于模式和查询功能的元数据存储。 与查询引擎相比，这些工具还提供存储，并且在数据仓库的情况下可以强制执行某些架构(星型架构)。 这些工具使用SQL语法，Spark和其他框架可以与它们进行交互。

• Apache Hive：我们已经讨论过Hive作为Spark和其他工具的中央模式存储库，以便它们可以使用SQL，但是Hive也可以存储数据，因此您可以将其用作数据仓库。 它可以访问HDFS或HBase。 查询Hive时，它会利用Apache Tez，Apache Spark或MapReduce，而Tez或Spark的速度要快得多。 它还具有一种称为HPL-SQL的过程语言。
• Apache Impala：这是Hadoop的本地分析数据库，您可以使用它来存储数据并以有效的方式查询它。 它可以使用Hcatalog连接到Hive获取元数据。 Impala为Hadoop上的BI /分析查询提供了低延迟和高并发性(不是由批处理框架(如Apache Hive)提供的)。 即使在多租户环境中，Impala也会线性扩展，从而比Hive更好地替代查询。 Impala与本机Hadoop安全性和Kerberos集成在一起以进行身份验证，因此您可以安全地管理数据访问。 它使用HBase和HDFS进行数据存储。 

• Apache Tajo：这是Hadoop的另一个数据仓库。 Tajo专为针对HDFS和其他数据源上存储的大数据集的低延迟和可扩展的即席查询，在线聚合和ETL而设计。 它与Hive Metastore集成在一起以访问通用模式。 它具有许多查询优化功能，具有可伸缩性，容错能力，并提供JDBC接口。
• Apache Kylin：Apache Kylin是更新的分布式分析数据仓库。 Kylin的运行速度非常快，因此对于仪表盘或交互式报表等性能很重要的用例，它可以用于补充Hive等其他一些数据库，它可能是最好的OLAP数据仓库，但使用起来比较困难。 问题在于，由于维数高，您需要更多的存储空间。 这个想法是，如果查询引擎或Hive不够快，您可以在Kylin中创建一个"多维数据集"，这是针对OLAP优化的多维表，具有可从仪表板或交互式报表中查询的预先计算的值。 它可以直接从Spark生成多维数据集，甚至可以从Kafka实时生成多维数据集。 

OLAP引擎

在此类别中，我包括较新的引擎，这些引擎是对以前的OLAP数据库的改进，这些数据库提供了创建多合一分析平台的更多功能。 实际上，它们是前两种类别的混合，为您的OLAP数据库添加了索引。 它们位于Hadoop平台之外，但紧密集成。 在这种情况下，您通常会跳过处理阶段并直接使用这些工具进行提取。

他们试图解决以统一的方式查询实时和历史数据的问题，以便您可以在查询到实时数据以及低延迟的历史数据后立即立即查询实时数据，从而构建交互式应用程序和仪表板。 这些工具在许多情况下允许以ELT方式进行几乎没有任何转换的原始数据查询，但性能却优于常规OLAP数据库。

它们的共同点是它们提供了数据的统一视图，实时和批处理数据的接收，分布式索引，其自身的数据格式，SQL支持，JDBC接口，热冷数据支持，多种集成和元数据存储。

• Apache Druid：这是最著名的实时OLAP引擎。它专注于时间序列数据，但可用于任何类型的数据。它使用自己的列式格式，可以大量压缩数据，并且具有很多内置的优化功能，例如倒排索引，文本编码，自动数据汇总等等。使用具有极低延迟的Tranquility或Kafka实时摄取数据，数据以针对写入而优化的行格式保存在内存中，但是一旦到达，就可以像以前摄取的数据一样查询。后台任务，负责将数据异步移动到深度存储系统(例如HDFS)。当数据移至深层存储时，它将转换为较小的块，这些块按时间段进行了划分，这些段针对低延迟查询进行了高度优化。每个段都有一个时间戳和几个维，您可以使用它们过滤和执行聚合。和指标是预先计算的汇总。对于批量提取，它将数据直接保存到细分中。它支持推拉式摄取。它与Hive，Spark甚至NiFi集成在一起。它可以使用Hive Metastore，并且支持Hive SQL查询，然后将其转换为Druid使用的JSON查询。 Hive集成支持JDBC，因此您可以连接任何BI工具。它还有自己的元数据存储，通常是MySQL。它可以吸收大量数据并很好地扩展。主要问题是它具有许多组件，并且难以管理和部署。 

> Druid architecture

• Apache Pinot：这是LinkedIn开源的Druid的更新替代品。 与Druid相比，由于Startree索引提供了部分预先计算，因此它提供了更低的延迟，因此它可用于面向用户的应用程序(用于获取LinkedIn提要)。 它使用排序索引而不是倒排索引，索引速度更快。 它具有可扩展的插件架构，并且具有许多集成，但不支持Hive。 它还统一了批处理和实时功能，提供快速接收，智能索引并将数据分段存储。 与Druid相比，它更容易部署且速度更快，但目前还不成熟。 

 > Apache Pinot

• ClickHouse：用C ++编写，此引擎为OLAP查询(尤其是聚合)提供了令人难以置信的性能。 它看起来像一个关系数据库，因此您可以非常轻松地对数据建模。 它非常容易设置，并且具有许多集成。 

 > ClickHouse

查看这篇文章，其中详细比较了3个引擎。 同样，从小处着手并在做出决定之前了解您的数据，这些新引擎功能强大，但难以使用。 如果您可以等待几个小时，则使用批处理和Hive或Tajo等数据库; 然后使用Kylin加快OLAP查询的速度，使其更具交互性。 如果这还不够，并且您需要更低的延迟和实时数据，请考虑使用OLAP引擎。 德鲁伊更适合实时分析。 麒麟更专注于OLAP案件。 Druid与Kafka的实时流媒体集成良好。 Kylin分批从Hive或Kafka获取数据; 尽管计划在不久的将来进行实时摄取。

最后，Greenplum是另一个更专注于AI的OLAP引擎。 

 > Presto/Drill provide more flexibility, Kylin great latency, Druid and Pinot, the best of both worl

最后，对于可视化，您可以使用多种商业工具，例如Qlik，Looker或Tableau。 对于开源，请检查SuperSet，这是一个了不起的工具，它支持我们提到的所有工具，具有出色的编辑器，而且速度非常快。 Metabase或Falcon是其他不错的选择。

结论

我们讨论了很多数据：不同的形状，格式，如何处理，存储以及更多内容。 切记：了解您的数据和业务模型。 使用迭代过程，慢慢开始构建您的大数据平台; 不是通过引入新框架而是通过提出正确的问题并寻找可以为您提供正确答案的最佳工具。

查看数据的不同注意事项，根据数据模型(SQL)，查询(NoSQL)，基础结构和预算选择合适的存储。 请记住与您的云提供商合作并评估云产品的大数据(购买与构建)。 从无服务器分析流水线开始，然后随着成本的增加而逐渐过渡到开源解决方案，这是很常见的。

由于对您控制范围之外的系统的依赖性，数据提取至关重要且复杂。 尝试管理那些依赖关系并创建可靠的数据流以正确提取数据。 如果可能，请其他团队负责数据提取。 请记住添加指标，日志和跟踪以跟踪数据。 启用架构演变，并确保已在平台中设置适当的安全性。

使用正确的工具完成工作，不要花费太多。 诸如Cassandra，Druid或ElasticSearch之类的工具是令人赞叹的技术，但需要大量知识才能正确使用和管理。 如果只需要对临时查询和报告进行OLAP批处理分析，请使用Hive或Tajo。 如果需要更好的性能，请添加Kylin。 如果还需要与其他数据源联接，请添加查询引擎，例如Drill或Presto。 此外，如果您需要实时查询批次，请使用ClickHouse，Druid或Pinot。