四 工具比较：批处理和实时 ETL 工具
在此类别中，可以选择开源工具、托管服务或完全托管的自助服务引擎。
阿帕奇Spark
Spark是一种分布式通用集群计算框架。Spark 引擎在摄取数据时计算并优化有向无环图 (DAG)。（DAG 是一种单向前进的数据流，没有循环）。Spark 的内存数据处理引擎对动态或静止数据执行分析、ETL、机器学习和图形处理。它为某些编程语言提供高级 API：Python、Java、Scala、R 和 SQL。
优点：
- 具有大型企业应用的成熟产品，已在许多用例的生产中得到验证
- 随时支持SQL查询。
缺点：
- 实施和维护复杂且劳动密集
- 几秒钟的延迟，消除了一些实时分析用例
亚马逊Glue
Amazon Glue 是一种完全托管的 ETL 和数据发现服务，构建于 Apache Spark 之上。Glue 提供了一个无服务器环境，可以使用它自动配置的虚拟资源来运行 Spark ETL 作业。使用 Glue，可以针对 S3 执行 ETL 作业以转换流数据，包括各种转换和转换为 Apache Parquet。
优点
- 可以减少正在进行的集群管理的麻烦
缺点
- 仍在作为服务发展
- 限于 Spark 的批处理性质，这会带来一定的延迟和限制
- 必须在存储层做很多优化（例如在 S3 上压缩小文件）以提高查询性能
阿帕奇Flink
还处理批任务的流处理框架。Flink 也是一个声明式引擎。它将批处理视为具有有限边界的数据流。数据通过源进入并通过汇离开。它基于流和转换的概念。
优点：
- 流优先方法提供低延迟、高吞吐量
- 真正的逐条处理
- 不需要对其处理的数据进行手动优化和调整
- 动态分析和优化任务
缺点：
- 一些缩放限制
- 比较新；与其他框架相比，生产中的部署更少
阿帕 Flume
用于聚合、收集和移动大量日志数据的可靠分布式服务。它具有灵活的基本架构。从 Web 服务器捕获流数据到 Hadoop 分布式文件系统 (HDFS)。
优点：
- 中央主服务器控制所有节点
- 容错、故障转移以及高级恢复和可靠性功能
缺点：
- 难以理解和配置复杂的逻辑/物理映射
- 占用空间大——>50,000 行 Java 代码
阿帕奇Storm
Apache Storm 处理大量数据并以比许多其他解决方案更低的延迟提供结果。适用于近乎实时的处理工作负载。Storm 是一个组合引擎，开发者预先定义 DAG，然后处理数据。这可能会简化代码。但这也意味着开发人员必须仔细规划他们的架构以避免低效的处理。
Apache Storm 架构建立在 spouts 和 bolts 之上。Spouts 是信息的来源。它们将信息传输到一个或多个螺栓。整个拓扑形成一个DAG。
优点：
- 非常适合实时处理
- 使用微批次可以灵活地调整工具以适应不同的用例
- 广泛的语言支持
缺点：
- 可能会降低可靠性，因为它不能保证消息的顺序
- 实施起来非常复杂
阿帕奇Samza
Samza 使用发布-订阅模型来摄取数据流、处理消息并将结果输出到另一个流。这是一个合成引擎。Samza 依赖于 Apache Kafka 消息系统、架构，并保证提供缓冲、容错和状态存储。
优点：
- 提供复制存储，以低延迟提供可靠的持久性
- 简单且具有成本效益的多用户模型
- 可以消除背压，持久化数据供以后处理
缺点：
- 不支持非常低的延迟
- 仅支持 JVM 语言
- 不支持恰好一次语义
亚马逊Kinesis Streams
由 AWS 作为托管服务提供的专有事件流工具。每秒从数十万个来源收集千兆字节的数据。以毫秒为单位捕获实时分析用例的数据。与 Kafka 的 pub-sub 模型非常相似，包括弹性缩放、持久性和低延迟消息传输（根据亚马逊的说法，在 70 毫秒内收集数据）。
优点：
- 易于设置和维护的托管服务
- 与亚马逊广泛的大数据工具集集成
缺点：
- 商业云服务，每个分片按小时收费；处理大量数据时可能会很昂贵
- 需要牺牲一定程度的控制和定制，以换取易用性和减少对基础设施的关注
五 工具比较——分析引擎
数据从业者使用越来越多的工具从存储和流式数据中获取洞察力和价值。这些工具反过来与商业智能应用程序一起工作，以可视化和探索数据、数据建模和其他用于机器学习和人工智能的预测分析应用程序。
今天使用的常见分析工具包括：
- 大数据查询引擎：
- Amazon Athena
- Presto
- Trino / Starburst
- Redshift Spectrum
- Hive
- 其他
- 专用文本搜索引擎
- ElasticSearch
- Amazon OpenSearch
- Apache Solr (open source, based on the same library as ES, but much less prevalent)
- Kusto – managed MS offering
- 存储层
- 数据仓库
大数据查询引擎
顾名思义，这些技术旨在或已经发展为针对从 GB 到 PB 的各种规模的数据源运行交互式分析查询。它们可以搜索任何形式的数据——结构化、半结构化、非结构化——并且可以运行许多同时查询，如果可能的话实时。他们可以查询存储在任何地方的数据，而无需将数据移动到单独的结构化系统中，例如关系数据库或数据仓库。
亚马逊Athena
Athena 是一个分布式查询引擎，使用 S3 作为其底层存储层。它的性能很大程度上取决于数据在 S3 中的组织方式，因为没有数据库可以代替 ETL 工具进行转换。ETL 到 Athena 必须优化 S3 存储以实现快速查询和处理有状态操作。
Athena 执行全表扫描而不是使用索引。这意味着某些操作（例如大表之间的连接）可能会非常慢。
Presto
Presto（或 PrestoDB）是一个依赖于 Hive 元存储的开源分布式 SQL 查询引擎。它专为对任何数量的数据进行快速分析查询而设计。它是亚马逊基于 Athena 的基础服务。与 Athena 一样，您可以使用 Presto 查询云对象存储中的数据；您不必先将数据移动到单独的分析系统中。查询执行在可扩展的纯内存架构上并行运行。
Presto 具有通过其连接器直接连接 S3 之外的各种数据源的功能，包括 HDFS 数据块和关系数据库。
Trino / Starburst
Trino 是一种分布式 SQL 查询引擎，旨在查询分布在一个或多个异构数据源上的大型数据集。Trino 最初名为 PrestoSQL，是原始 prestoDB 开源项目的一个分支。它由 Trino Software Foundation 的大型贡献者和用户社区维护。
Starburst 是 Presto 基金会管理委员会的成员，维护着一个名为 Starburst Enterprise 的企业级 Trino 商业发行版。Starburst Enterprise 包括额外的安全功能、更多连接器、基于成本的查询优化器、对运行额外部署平台的支持等。它旨在帮助大公司安全地从他们的 Trino 部署中提取更多价值。
Redshift Spectrum
Redshift 是一个关系数据库；Redshift Spectrum 是一个查询引擎，驻留在专用的 Redshift 服务器上并访问 S3 中的数据。
与 Athena 相比，Redshift 是：
- 快点
- 更健壮（具有额外的计算能力）
- 更贵
- 管理起来更复杂，需要大量的集群管理专业知识
亚马逊向 Redshift 引入了 RA3 节点类型，以提高性能并增加存储容量。Amazon 的 Redshift 高级查询加速器 (AQUA) 位于 Amazon Redshift RA3 集群的计算和存储之间，并与 Amazon Redshift RA3 实例一起运行。它不适用于数据湖。
Hive
Apache Hive 是一个开源数据仓库应用程序，用于读取、写入和管理大型数据集。它与 Apache Hadoop 分布式文件系统 (HDFS) 或其他数据存储系统（如 Apache HBase）配合使用。您通过命令行工具和 JDBC 驱动程序连接到 Hive。使用 Hive 的 SQL-like 接口查询存储在与 Hadoop 集成的各种数据库和文件系统中的数据。
专用文本搜索引擎
顾名思义，专用文本（或全文）搜索引擎检查文档和数据库记录中的所有单词。（元数据搜索方法仅分析文档的描述。）它们承诺通过高级索引和基于相关性的更直观的搜索结果快速检索数据。
Elasticsearch
Elasticsearch 是一个基于 Lucene 的开源可伸缩搜索引擎。它通常用于日志搜索、日志分析以及 BI 和报告。您可以在任何地方运行它。
将 Elasticsearch 包含在流式架构中以明确查询日志文件的情况并不少见。为此，将所有原始数据存储在数据湖中以供重放和临时分析。然后对其进行去重，过滤掉不相关的事件，并将该子集发送到 Elasticsearch。
可以使用 Kafka Connect 将主题直接流式传输到 Elasticsearch。
将所有日志存储在 Elasticsearch 中不需要自定义编码。但由于 Elasticsearch 日志通常包含大量文本，因此相对较大，存储成本高昂
亚马逊OpenSearch
OpenSearch 项目由亚马逊创建，是一个基于 Elasticsearch 和 Kibana 的分叉搜索项目。（亚马逊没有计划 Elasticsearch 和 Kibana 的当前或未来版本。）它与 Elasticsearch 相同，但随着时间的推移会有所不同。
阿帕奇Solr
Apache Solr 是一个基于 Apache Lucene™ 构建的开源企业搜索平台。它提供分布式索引、复制和负载平衡查询、自动故障转移和恢复以及集中配置。它被设计为可靠的、可扩展的和容错的。
Microsoft Azure 数据资源管理器
Azure 数据资源管理器是一项用于存储和运行大量数据的交互式分析的服务。它基于 RDMS，支持数据库、表和列等实体。您可以通过 Kusto 查询语言创建复杂的分析查询。
Kusto 补充但不替代传统 RDBMS 系统，用于 OLTP 和数据仓库等场景。它对所有形式的数据（结构化、半结构化和非结构化）表现同样出色。Kusto 不执行单个行和跨表约束或事务的就地更新。
存储层
与其他类型的流架构组件一样，存储层也在不断发展，充分利用它们的策略也在不断发展通常，可以选择文件存储、对象存储（数据湖，主要是mostly0 和数据仓库）。
文件存储——Hadoop 旨在处理大量数据。相对而言,对于中小型文件，它仍然足够简单和有效。但是元数据是有限的，并且只能通过整个文件进行搜索，因此随着容量的增加，使用 HDFS 作为主要存储层的成本、复杂性和延迟变得不合适。
对象存储——通常是指数据湖，其中最突出的是 Amazon S3；微软 Azure 数据湖和谷歌云存储。文件位置被标记，元数据是可靠的。因此缩放是无限的，搜索比文件存储快得多。但数据必须经过转换和优化才能使其可查询。
数据仓库——这些最适合结构化和半结构化数据，数据必须在存储在仓库中之前进行预处理（读取模式）。仓库可以提供简单的数据访问和快速查询，但不能以经济高效的方式扩展，也不能很好地处理非结构化数据。它们通常还需要一个封闭的架构——也就是说，它们实际上只适用于各自供应商的工具集。有许多可用的数据仓库；最著名的是 Snowflake 和 Amazon Redshift。
六 流数据常见用例
流式数据处理使实时或近实时获得可操作的洞察成为可能。特别适合流式传输的用例包括：
- 欺诈检测——将复杂的机器学习算法与实时交易分析相结合，以识别模式并实时检测表明欺诈的异常情况。
- 网络安全——数据流中的异常有助于数据安全从业者隔离或消除威胁，例如来自单个 IP 地址的可疑流量。
- 物联网传感器数据——实时计算数据流，例如监控机械或环境条件或库存水平并几乎立即做出响应。
- 在线广告和营销情报——跟踪用户行为、点击次数和兴趣，然后为每个用户推广个性化的赞助广告。实时衡量观众对内容的反应，以快速、有针对性地决定为访客和客户提供哪些服务并吸引潜在客户。
- 产品分析——跟踪数字产品中的行为以了解功能使用、评估用户体验变化、增加使用并减少放弃。
- 日志分析——IT 部门可以将日志文件转化为集中的易于使用的消息流，以从日志文件中提取意义；通常与可视化工具和开箱即用的过滤器结合使用。
- 云数据库复制——使用变更数据捕获 (CDC) 在云中维护事务数据库的同步副本，以支持数据科学家使用高级分析。
七 流处理常见陷阱
流处理是从海量数据流中获取商业价值的最佳方法。但路径不一定是直截了当的。在设计流式传输架构时，请牢记这些陷阱：
- Apache Spark 的复杂性
- 过度依赖数据库
- 小文件的激增
Apache Spark 的复杂性
Spark 是一个强大的开源流处理器，并且被广泛使用。但是，与 Hadoop 一样，它是一个复杂的框架，需要大量的专业知识。 它功能强大且用途广泛 – 但它不易使用、部署简单或运行成本低廉。那是因为：
- 专为大数据和 Scala 工程师打造，而非分析团队。在 Spark 中构建数据转换需要在 Scala 中进行冗长的编码，并具备在对象存储、分区和合并小文件方面实施数十种 Hadoop 最佳实践的专业知识。
- 不是一个独立的解决方案。Spark 只是更大的大数据框架的一部分。对于流处理、工作流编排和状态管理，需要组装相当多的额外工具，每个工具都有自己的专业技能集，从而增加了更多的复杂性和成本。
- 需要很长时间才能实现价值。Spark 的大规模实施是一个复杂的编码项目。随着雇用或培训专家、定制开发和手动调整以优化和扩展 Spark 所需的时间，从开始到生产需要几个月或更长时间。
- 造成技术债务并扼杀敏捷性。对数据或分析要求的任何更改都需要一个编码周期，包括回归测试/QA。
- 造成数据工程瓶颈。数据团队必须实施任何需要新 ETL 流程或管道更改的新仪表板或报告。因此，每个变更请求都必须符合工程团队的 Sprint 计划。这可能会很痛苦，并最终会减少整个组织对数据的访问。
- 是昂贵的。 的确，没有直接的许可费用（尽管通过托管 Spark 服务可能会产生高昂的订阅费用）。但是，将额外硬件的成本添加到专业知识的成本中，Apache 部署很容易超过大多数软件许可的价格。当使用高端开发人员进行普通的数据管道构建和维护时，也会产生机会成本。
过度依赖数据库
如果已经在管理大量数据流，这可能是显而易见的——但将流数据保存在关系数据库中是站不住脚的：
- 事务数据库必须保留用于操作。任何额外报告或处理都会妨碍表现。
- 基于事件的数据存储为对象而不是表。但是关系数据库是建立在表格存储之上的；使用它们来存储非结构化数据需要冗长的清理和转换过程，并在摄取时造成工程瓶颈。
- 存储成本很容易使所有其他项目成本相形见绌，尤其是当将大数据存储在存储和计算紧密耦合的数据库中时。
- 操作型数据库只包含相对较新的数据，而且通常只包含数据点的最新状态。挖掘模式和趋势或跟踪数据沿袭以从错误中恢复是非常具有挑战性的。
- 流数据的价值通过探索技术、预测建模和机器学习得到释放。与传统数据库相比，这些分析需要更广泛、更灵活的数据访问。
小文件的激增
将小文件写入对象存储非常简单。但无论是在云端还是本地使用 Hadoop 或 Spark，小文件都会破坏性能。打开每个文件、读取元数据和关闭文件都需要几毫秒的时间，这在处理数百万个文件时变得有意义。此外，许多文件会导致许多不连续的磁盘寻道，而对象存储并未为此进行优化。
为了缓解这种情况，请在数据架构中使用压缩——定期将较小的事件文件合并到较大的档案中——以提高查询性能。最好的方法是：
- 地定义压缩窗口。过于频繁地压缩是一种浪费，因为文件仍然非常小，任何性能改进都是微不足道的。当系统等待压缩作业完成时，压缩太少会导致处理时间过长和查询速度变慢。
- 删除未压缩的字段以节省空间和存储成本。当然，始终保留原始状态的数据副本以用于重放和事件溯源。
- 压缩完成后重新配置 Athena 表分区，这样 Athena 将读取压缩后的分区而不是原始文件。
- 保持文件大小尽可能大，但仍然足够小以适应未压缩的内存。
同时，遵循一些最佳实践可以确保在构建流式架构时更快地获得更多价值。
八 综述
随着流数据的规模持续增长，组织可以通过构建或升级数据架构来保持竞争力，使他们能够实时或接近实时地处理和分析数据。该过程的每个步骤都有多种方法、技术和工具。通过采用有限数量的最佳实践并坚持开放数据架构以最大限度地增加选择，数据堆栈不仅具有成本效益，而且在可预见的未来具有足够的灵活性和可扩展性。
