文章详情

短信预约-IT技能 免费直播动态提醒

请输入下面的图形验证码

提交验证

短信预约提醒成功

一文带你了解大数据管道

2024-12-10 16:00

关注

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


> 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生态系统之外的数据库和存储选项是:

记住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。 通常,建议在摄取数据时将其放平。

如我们所见,CSV和JSON易于使用,易于阅读和通用格式,但是缺乏其他格式的许多功能,因此它太慢而无法用于查询数据湖。 ORC和Parquet在Hadoop生态系统中被广泛用于查询数据,而Avro还在Hadoop之外使用,尤其是与Kafka一起用于提取时,对于行级ETL处理非常有用。 面向行的格式比面向列的格式具有更好的模式演变功能,这使它们成为数据提取的理想选择。

最后,您还需要考虑文件大小和CPU成本之间的权衡,如何压缩文件中的数据。 某些压缩算法速度更快,但文件大小更大;另一些压缩算法速度较慢,但压缩率更高。 有关更多详细信息,请查看本文。 


> Compression options

我建议使用快照来流式传输数据,因为它不需要太多的CPU能力。 对于批处理,bzip2是一个不错的选择。

同样,您需要查看我们之前提到的注意事项,并根据我们查看的所有方面进行决策。 让我们以一些用例为例:

用例

基础设施

当前的基础架构会在决定使用哪些工具时限制您的选择。 要问的第一个问题是:云计算与本地部署。 云提供商提供了许多选择和灵活性。 此外,它们为您的大数据需求提供了无服务器解决方案,更易于管理和监控。 无疑,云是存放大数据的地方。 即使对于Hadoop生态系统,云提供商也提供托管群集和比本地存储便宜的存储。 查看我有关云解决方案的其他文章。

如果您在场所中运行,则应考虑以下事项:

监控和警报

下一个要素对于数据管道的成功至关重要。 在大数据世界中,您需要有关流程和数据的不断反馈。 您需要收集指标,收集日志,监视系统,创建警报,仪表板等等。

使用Prometheus和Grafana等开源工具进行监视和警报。 使用日志聚合技术来收集日志并将其存储在诸如ElasticSearch之类的地方。 


> Grafana Monitoring

利用云提供商的功能进行监视和警报(如果可能)。 根据您的平台,您将使用不同的工具集。 对于无云服务器平台,您将依靠您的云提供商工具和最佳实践。 对于Kubernetes,您将使用开源监控器解决方案或企业集成。 我真的推荐这个网站,在这里您可以浏览和检查不同的解决方案,并构建自己的APM解决方案。

大数据世界中要考虑的另一件事是可审计性和问责制。 由于法规不同,您可能需要跟踪数据,捕获和记录数据流经管道时的所有更改。 这称为数据来源或血统。 诸如Apache Atlas之类的工具用于控制,记录和管理您的数据。 其他工具如Apache NiFi也支持开箱即用的数据沿袭。 有关实时跟踪,请检查"打开遥测"或" Jaeger"。 还有很多云服务,例如Datadog。

对于Hadoop,使用Ganglia。

安全

Apache Ranger为您的Hadoop平台提供了统一的安全监控框架。 提供集中的安全性管理,以在中央UI中管理所有与安全性相关的任务。 它使用不同的方法提供授权,并在整个Hadoop平台上提供全面的可审核性。

您的团队是成功的关键。 大数据工程师可能很难找到。 投资于培训,技能提升,研讨会。 删除孤岛和繁文tape节,简化迭代过程,并使用域驱动设计来设置团队边界和职责。

对于大数据,您将分为两大类:

预算

这是一个重要的考虑因素,您需要金钱来购买所有其他成分,并且这是有限的资源。 如果您有无限的资金,则可以部署海量的数据库并将其用于大数据需求而不会带来很多麻烦,但这会花费您很多钱。 因此,本文中提到的每种技术都需要具备使用,部署和维护技术的人员。 有些技术比其他技术更复杂,因此您需要考虑到这一点。

食谱

现在我们已经掌握了食材,让我们来烹饪我们的大数据食谱。 简而言之,该过程很简单; 您需要从不同来源获取数据,对其进行充实,将其存储在某个位置,存储元数据(模式),对其进行清理,对其进行规范化,对其进行处理,隔离不良数据,以最佳方式聚合数据并将其最终存储在某个位置以供下游系统使用 。

让我们更详细地了解每个步骤…

数据摄取

第一步是获取数据,此阶段的目标是获取所需的所有数据并将其以原始格式存储在单个存储库中。 它通常由将其数据推送到Kafka或数据存储中的其他团队拥有。

对于没有大量数据的简单管道,您可以构建一个简单的微服务工作流,该工作流可以在单个管道中摄取,丰富和转换数据(注入+转换),您可以使用Apache Airflow之类的工具来编排依赖性。 但是,对于大数据,建议您将摄取与处理分开,可以并行运行的海量处理引擎对于处理阻塞调用,重试,背压等效果不佳。因此,建议在保存所有数据之前 您开始处理它。 作为调用的一部分,您应该通过调用其他系统来确保您的数据丰富,以确保所有数据(包括参考数据)在处理之前都已落入湖泊中。

有两种摄取方式:

正如我们已经提到的,使用Kafka或Pulsar作为数据摄取的中介是极为常见的,以实现持久性,背压,并行化和摄取的监控。然后,使用Kafka Connect将数据保存到您的数据湖中。这个想法是您的OLTP系统将事件发布到Kafka,然后将其吸收到您的湖泊中。避免直接通过API批量提取数据;您可能会调用HTTP端点进行数据充实,但请记住,从API提取数据在大数据世界中并不是一个好主意,因为它速度慢,容易出错(网络问题,延迟等),并且可能导致源系统崩溃。尽管API非常适合在OLTP世界中设置域边界,但这些边界是由大数据世界中Kafka中的数据存储(批次)或主题(实时)来设置的。当然,它总是取决于数据的大小,但是如果可能,如果没有其他选择,请尝试使用Kafka或Pulsar。以流式方式从API中提取少量数据,而不是批量提取。对于数据库,请使用Debezium等工具将数据流式传输到Kafka(CDC)。

为了最大程度地减少依赖性,如果源系统将数据推送到Kafka而不是您的团队提取数据,则总是比较容易,因为您将与其他源系统紧密耦合。 如果无法做到这一点,并且您仍然需要掌握摄取过程,那么我们可以考虑两种主要的摄取类别:

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还提供元数据存储。

数据处理

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

通常,您需要执行某种处理,例如:

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

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

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

处理框架

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

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


 



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

编排

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

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

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

一些选项是:

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

数据质量

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

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

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

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

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


> Apache Griffin Processes

 

> Great expectations UI

数据查询

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

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

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

处理引擎

我们在上一节中描述的大多数引擎都可以连接到元数据服务器,例如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接口,以安全方式连接到您的数据湖。 查询引擎是最慢的选择,但提供最大的灵活性。


> 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生态系统之外。 这个想法是使用倒排索引来执行快速查找。 除了文本搜索外,该技术还可以用于各种用例,例如存储日志,事件等。有两个主要选项:

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

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


OLAP数据库

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


OLAP引擎

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

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

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


> Druid architecture

 > Apache Pinot

 > 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。

 

来源:今日头条内容投诉

免责声明:

① 本站未注明“稿件来源”的信息均来自网络整理。其文字、图片和音视频稿件的所属权归原作者所有。本站收集整理出于非商业性的教育和科研之目的,并不意味着本站赞同其观点或证实其内容的真实性。仅作为临时的测试数据,供内部测试之用。本站并未授权任何人以任何方式主动获取本站任何信息。

② 本站未注明“稿件来源”的临时测试数据将在测试完成后最终做删除处理。有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341

软考中级精品资料免费领

  • 历年真题答案解析
  • 备考技巧名师总结
  • 高频考点精准押题
  • 2024年上半年信息系统项目管理师第二批次真题及答案解析(完整版)

    难度     813人已做
    查看
  • 【考后总结】2024年5月26日信息系统项目管理师第2批次考情分析

    难度     354人已做
    查看
  • 【考后总结】2024年5月25日信息系统项目管理师第1批次考情分析

    难度     318人已做
    查看
  • 2024年上半年软考高项第一、二批次真题考点汇总(完整版)

    难度     435人已做
    查看
  • 2024年上半年系统架构设计师考试综合知识真题

    难度     224人已做
    查看

相关文章

发现更多好内容

猜你喜欢

AI推送时光机
位置:首页-资讯-后端开发
咦!没有更多了?去看看其它编程学习网 内容吧
首页课程
资料下载
问答资讯