谈谈如何构建优化的流数据架构

一 为什么要使用流数据架构

流处理最初是一种“特定群体”技术。但随着 SaaS、物联网和机器学习的快速发展，各行各业的组织现在都在试行或全面实施流分析。很难找到一家没有应用程序、在线广告、电子商务网站或物联网产品的现代公司。这些数字资产中的每一个都会创建实时事件数据流。人们越来越渴望整合流式数据基础架构，从而使复杂、强大和实时的分析成为可能。 

传统的批处理架构可以满足较小规模的需求。但流媒体资源——传感器、服务器和安全日志、实时广告、来自应用程序和网站的点击流数据等等——每秒可以生成多达 1 Gb 的事件。流式数据架构在生成数据时使用这些数据，并准备好进行分析。考虑到数据流的独特特征，后者尤其重要——通常是非结构化或半结构化数据，在进行任何认真的分析之前必须对其进行处理、解析和结构化。 

流式架构提供了批处理管道无法提供的多项优势： 

以原生形式处理永无止境的事件流，避免批处理事件的开销和延迟。 

实时或近实时处理最新的数据分析和洞察力——例如，显示机器性能的仪表板，或微目标广告或即时服务，或检测欺诈或网络安全漏洞。

检测时间序列数据中的模式， 例如突出显示网站流量数据的趋势。这很难用传统的批处理来完成，因为连续的时间相邻事件可以跨多个批次中断。

构建流媒体架构是一项复杂的挑战，最好根据用例使用额外的软件组件来解决——因此需要“构建”一个通用解决方案，以处理大多数（如果不是全部）设想的用例。 

二 流式架构的组件

流数据架构是一个软件组件框架，用于从多个来源摄取和处理大量原始数据流。 

从广义上讲，它由四个部分组成：

流处理器或消息代理，用于收集数据并重新分发它

数据转换工具（ETL、ELT 等），为查询准备好数据

查询引擎，提取商业价值

大量流数据的经济高效存储——文件存储和对象存储

下面我们回顾一下每种组件类型在流式架构中的位置和方式。

流处理器/消息代理

流处理器从其来源收集数据，将其转换为标准消息格式，然后连续流式传输以供其他组件使用。（此类组件可以是存储组件，例如数据湖、ETL 工具或其他类型的组件。）流处理器具有高容量（>1 Gb/秒），但不执行其他数据转换或任务调度。

作为数据管道的流处理器（来源：Wikimedia Commons）

例子：

Apache Kafka

 Amazon Kinesis Data Streams

Azure Event Hub

Google Cloud PubSub

流处理工具

在消息代理存储数据后，您必须聚合、转换和构建数据以使其可以查询。您可以通过 ETL 执行此操作，在其中您在暂存区域或流工具中准备数据，然后再将其移动到查询位置，或者通过 ELT，在同一位置转换和查询数据。此类转换包括规范化；将相关字段映射到列；加入来自多个来源的数据；文件压缩；分区；基于时间的聚合；等等。

例子：

Apache Spark Streaming (SQL querying possible, mostly via complex Java or Scala)

Amazon Web Services – Kinesis

Google Cloud – Dataflow

Microsoft Azure – Stream Analytics

Apache Flink

Upsolver

请注意，根据您的需求和您创建的架构，数据转换可能会直接发生在数据流入和存储在数据湖或其他存储库之前，或者在数据被摄取和存储之后。

查询引擎

数据现在已准备好进行分析。工具和技术差异很大，具体取决于用例。 

示例（并非详尽无遗）：

查询引擎——Athena、Presto、Hive、Redshift Spectrum 

文本搜索引擎——Elasticsearch、OpenSearch、Solr、Kusto

云数据仓库——AWS Redshift、Snowflake、Google BigQuery、Synapse Analytics (Azure)

NOSQL 存储 – Cassandra、Amazon DynamoDB、CosmosDB、Google BigTable

图形分析——Neo4j、Amazon Neptune

关系数据库——RDS、SingleStore、CockroachDB

实时数据库——Imply、Clickhouse

TSDB——InfluxDB，AWS TimeSeries

流式数据存储

由于事件流的庞大数量和多结构性质，组织通常将其流事件数据存储在云对象存储中以用作数据湖。它们提供了一种经济高效且持久的方法来存储大量事件数据。它们是一个灵活的集成点，因此流媒体生态系统之外的工具可以访问流媒体数据。

例子：

亚马逊 S3

微软 Azure 存储

谷歌云存储

三 流式架构最佳实践

在构建流架构时，请牢记这些技术：

部署读取模式模型

分离实时和历史数据

维护所有传入事件的不可变日志

分层数据湖

保持架构开放

优化查询性能

部署读取模式模型

应该了解正在摄取的数据——每个数据源的架构、稀疏填充的字段、数据基数等。在读取时获得这种可见性而不是在写入时尝试推断它可以省去很多麻烦，因为随着架构变化的发生（意外的新的、删除的和更改的字段），可以基于最准确和可用的数据构建 ETL 管道。

将用于实时分析的数据与历史数据分开

优化用于实时或近实时分析的数据以确保快速读取。以原始形式保留历史数据以供临时查询使用，用于：

“回放”过去的事态

错误恢复

追踪数据沿袭

探索性分析

维护所有传入事件的不可变日志

在这里，实质上是在存储整个事件转换链，而不仅仅是转换的最终（或最近）结果。通过这种方式，可以将任何事件恢复到某个时间点的状态。这种“事件溯源”方法有很多好处： 

使数据团队能够追溯验证他们的假设

使运营团队能够跟踪已处理数据的问题并快速修复它们

在发生故障或数据损坏的情况下提高容错能力；可以通过将整个事件序列应用于损坏的实体来恢复数据的当前状态。

为了降低成本，将日志存储在对象存储中。当收到分析师或研究人员的请求时，创建一个 ETL 作业以将数据从不可变日志流式传输到分析平台，并从那里回放。 

根据用户的技能对数据湖进行分层

在数据湖中存储多个数据副本，以服务于范围广泛的消费者。理想的数据管道让这些消费者中的每一个都能使用他们已知的工具访问他们想要的数据——例如，完整（或接近完整）的数据科学家或机器学习算法的原始数据，或者聚合的、更薄的和结构化的版本BI 分析师可以使用它来快速创建报告。可以自动化提取原始数据的 ETL 管道，并根据用例执行相关转换。然后，可以避免依赖数据提供者（DevOps、数据工程）手动工作的瓶颈，例如为每个新请求编写 Apache Spark 等 ETL 框架。

针对不同用户组配置的云数据湖

保持架构开放

鉴于分析行业的快速变化，保持对“面向未来”的架构的开放性至关重要。避免供应商锁定或过度依赖单一工具或数据库。当可以通过广泛的服务使用各种工具提供无处不在的数据访问时，将获得最大的价值。

要创建一个开放式架构：

以开放的列式文件格式（例如 Avro 和 Parquet）存储数据，这些格式是标准的、众所周知的并得到广泛支持（与为特定数据库构建的专有文件格式（例如Databricks Delta Lake ）相反），这也提高了查询性能。

将原始历史数据保留在廉价的对象存储中，例如 Amazon S3。无论使用什么平台来管理数据湖和运行 ETL，保障数据始终可用。

使用支持良好的中央元数据存储库，例如 AWS Glue 或 Hive 元存储。可以在一个位置集中管理所有元数据，在此过程中降低基础架构、IT 资源和工程时间方面的运营成本。

优化查询性能

以下最佳实践可提高大多数业务案例的查询性能：

适当地分区数据以供您使用

转换为高效的列式文件格式

经常压缩（合并）小文件

分区数据

如何对数据进行分区对查询成本和速度有重大影响。查询运行更高效、成本更低，因为适当的分区限制了Amazon Athena 等查询引擎为回答特定分析问题而必须扫描的数据量。

数据通常按时间戳进行分区。但是，根据查询，数据可能会被其他字段分区，例如地理或与记录时间戳不同的基于时间的字段。如果可能，根据可能运行的查询类型和分析系统的建议来配置分区的大小。例如，如果大部分查询都需要过去 12 小时的数据，考虑按小时而不是按天进行分区，以减少要扫描的数据量。

转换为高效的列式文件格式

另一种减少扫描数据量的方法。将计划用于分析的数据存储在列式文件格式中，例如 Apache Parquet 或 ORC。使用列式格式，可以仅查询所需的列，从而减少所需的计算量，从而加快查询速度并降低成本。

经常压缩以解决“小文件问题”

数据流每天定期产生数百万个小事件文件。小文件提供更新鲜的数据，但如果直接查询这些小文件，随着时间的推移会降低性能。将小文件合并为大小合适的文件的过程称为压缩。

权衡数据流通的价值与高性能的价值，并根据需要尽可能频繁地压缩文件，以使数据保持最佳文件大小。 

三 工具比较：流处理/事件流工具

到目前为止，最常见的事件流工具是 Amazon Kinesis 和 Apache Kafka。

亚马逊Kinesis

Amazon Kinesis 是一种发布-订阅 (pub-sub) 消息传递解决方案。它是 AWS 云中的一项托管服务；配置有限，无法在本地运行 Kinesis。

设置/配置：AWS 代表管理流式传输数据所需的基础设施、存储、网络和配置。AWS 还处理硬件、软件和其他数据流服务的配置、部署和持续维护。

成本：没有前期设置成本。收费取决于：

所需吞吐量所需的分片（分区）数量 每个分片本质上是一个包含数据子集的单独流；Kinesis 每个流有多个分片）。

生产者传输到数据流的数据量，因此对于大量数据，成本可能很高。

用于：鉴于 Amazon 的高可用性承诺，如果没有用于 24/7 监控、警报和 DevOps 团队从故障中恢复的资源，Kinesis 可能是一个不错的选择。

阿帕奇Kafka

Apache Kafka 是一个开源的 pub-sub 系统，已经发展成为一个成熟的水平可扩展和容错系统，用于高吞吐量数据重放和流。

设置/配置：优化 Apache Kafka 的吞吐量和延迟需要同时调整生产者和消费者。服务器端配置——例如，复制因子和分区数——对于通过并行性实现最佳性能也至关重要。为了获得高可用性，必须将 Kafka 配置为尽快从故障中恢复。

在 Kafka 中构建 ETL 管道存在挑战；除了数据转换的基本任务外，还必须考虑事件流数据的独特特征。

成本：Kafka 需要自己的集群。设置 Kafka 集群需要学习和分布式系统工程实践以及集群管理、供应、自动缩放、负载平衡、配置管理和重要的 DevOps 参与的能力。还需要大量节点（代理）、复制和分区以实现系统的容错和高可用性。 

用于：实时数据处理；应用程序活动跟踪；日志记录和/或监控系统。

托管Kafka服务

Confluent KSQL和Amazon MSK（Kafka 托管流）都提供部署在云中的离散托管 Kafka 服务。 他们的目标是利用 Kafka 的灵活性和近乎无处不在的特性，同时管理其内在的大部分复杂性。   

Confluent Cloud是 Kafka 的完全托管云服务，可加速事件驱动服务和实时应用程序的开发，而无需您管理 Kafka 集群。 

设置/配置：需要 Java 运行时环境和访问 Kafka 集群以实时读取和写入数据。集群可以在本地或云端。需要为 ksqlDB 服务器和查询设置配置参数，以及底层 Kafka 流和 Kafka 客户端（生产者和消费者）。

成本：多种定价模型：每 Gb（数据输入、数据输出、数据存储）；每小时计算；每小时分区。

用于：用于在云中托管 Kafka。也可用作消息代理，促进企业级系统之间的通信，并将每个系统生成的数据集成到中央位置，例如 Amazon S3。

Amazon MSK是一项完全托管的服务，可简化使用 Apache Kafka 管理消息队列和处理流数据的生产应用程序的构建和运行。  

设置/配置：MSK 简化了设置和维护。设置和配置基于 Apache Kafka 的部署最佳实践。自动配置并运行您的 Apache Kafka 集群。 

成本：基于使用情况。需要为代理实例的运行时间、每月使用的存储空间以及集群内外数据的标准数据传输费用付费。

用于：维护和扩展 Kafka 集群，启用由完全托管服务支持的端到端摄取管道。还用作不同微服务之间的实时消息代理。

四 工具比较：批处理和实时 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 将读取压缩后的分区而不是原始文件。

保持文件大小尽可能大，但仍然足够小以适应未压缩的内存。

同时，遵循一些最佳实践可以确保在构建流式架构时更快地获得更多价值。

八 综述

随着流数据的规模持续增长，组织可以通过构建或升级数据架构来保持竞争力，使他们能够实时或接近实时地处理和分析数据。该过程的每个步骤都有多种方法、技术和工具。通过采用有限数量的最佳实践并坚持开放数据架构以最大限度地增加选择，数据堆栈不仅具有成本效益，而且在可预见的未来具有足够的灵活性和可扩展性。

本文来自微信公众号 “数据驱动智能”（ID：Data_0101），作者：晓晓，36氪经授权发布。