从流批一体到湖仓一体架构演进的思考

大数据发展

大数据起源于 Google 在 2004 年前后发表的三篇论文，即：

• 分布式文件系统 GFS（HDFS）
• 大数据分布式计算框架 MapReduce（MapReduce）
• NoSQL 数据库系统 BigTable（HBase）。

Lucene 开源项目的创始人 DougCutting 正在开发开源搜索引擎 Nutch，阅读了 Google 的论文后，根据论文原理初步实现了类似 GFS 和 MapReduce 的功能。这也标志着大数据技术从理论走向实践，为后续的大数据生态圈发展奠定了基础。

大数据最初生态圈

早期大数据生态圈以 Hadoop 为核心，形成了以分布式存储与计算为基础的技术体系。

• HDFS 解决海量数据存储问题，它将大文件分割成多个数据块，分布存储在集群中的不同节点上，并且通过多副本机制保证数据的可靠性。
• MapReduce 实现分布式批处理，把计算任务分解为 Map 和 Reduce 两个阶段，在集群中的多个节点上并行执行，提高计算效率。
• YARN 统一资源调度，负责管理集群中的计算资源，为各个应用程序分配 CPU、内存等资源。

基于这些核心组件，还衍生出了以下核心组件：

• Hive，它提供了类似 SQL 的查询语言 HiveQL，让用户可以方便地对存储在 HDFS 上的数据进行分析和处理；
• HBase（分布式数据库），基于 HDFS 构建，适合存储和处理海量的结构化和半结构化数据，能够提供快速的随机读写访问。

在这个阶段，大数据技术主要以离线批处理为主，聚焦于结构化数据处理，为企业数据规模化存储与分析奠定了基础。但它也存在明显的局限性，对实时处理和非结构化数据的支持有限，难以满足一些对数据时效性要求高的业务场景。

在早期，能掌握这些组件，就有机会在大数据领域找到不错的工作，因为这些技术是当时大数据处理的核心技术。

大数据如今生态圈

随着数据类型的多样化，包括结构化、半结构化和非结构化数据的大量涌现，以及处理需求的不断升级，大数据生态圈逐渐扩展至流处理、实时分析等领域。

• Spark 基于内存计算，大大提升了批处理效率，它将中间计算结果存储在内存中，避免了频繁的磁盘 I/O 操作，使得数据处理速度大幅提高。
• Flink 实现了流批一体处理，它可以根据数据的特性和业务需求，灵活地进行流式计算和批处理计算，并且在处理过程中能够保持低延迟和高吞吐量。
• Kafka 解决了实时数据管道问题，作为一个高吞吐量的分布式发布订阅消息系统，它能够高效地收集、传输和存储实时数据流，为实时数据处理提供了可靠的数据来源。
• 云原生技术，如 AWS S3、k8s 等也在大数据领域得到广泛应用，推动了大数据系统的弹性扩展和高效管理。
  • AWS S3 提供了高可靠、低成本的对象存储服务，方便大数据的长期存储和管理；
  • k8s 则可以实现容器化应用的自动化部署、扩展和管理，提高了大数据集群的运维效率。

为什么现在需要掌握的组件越来越多，大数据从最初的几个组件会发展到如今这么多组件呢？

核心原因是每一个组件都有对应解决的业务痛点，虽然技术不断发展，但核心的还是 Hadoop 体系，新的组件都是在其基础上进行扩展和优化，以满足不同的业务需求。

如今，在企业落地时，需要根据具体的业务场景选择最合适的工具，但同时也面临着架构复杂度高、数据孤岛等挑战。

大数据架构演变

离线跑批：批量处理的早期实践

在早期，大数据处理主要集中在日志分析、报表生成等离线批处理场景，主要基于 Hadoop MapReduce。这种方式将数据按批次处理，具有稳定性强、成本低的优势。在处理大规模日志数据时，可以将一天或一周的日志数据作为一个批次进行处理，利用 MapReduce 的分布式计算能力，在集群中的多个节点上并行计算，最终生成分析报表。

但这种方式也存在诸多痛点：

• ETL 计算、存储、时间成本高，数据完整性难保障。在 ETL 过程中，需要对数据进行抽取、转换和加载，涉及到大量的数据传输和处理操作，不仅消耗大量的计算资源和存储资源，而且处理时间较长。在数据抽取过程中，如果源数据出现异常，可能导致部分数据丢失，从而影响数据的完整性。

• 数据处理链路过长，数据准确性、一致性保障难。从原始数据的采集到最终的数据分析结果，中间可能经过多个处理环节，每个环节都可能引入数据错误或不一致的问题。在数据转换过程中，如果转换规则定义不准确，可能导致数据失真。

• 无法支持实时、近实时的数据分析。由于是批量处理，数据处理的时效性较差，无法满足一些对实时性要求高的业务场景，如实时监控、实时推荐等。

• 对业务库造成影响，容易把业务库采挂。在采集业务库数据时，如果采集频率过高或采集方式不当，可能会对业务库的性能产生较大影响，甚至导致业务库无法正常工作。

Lambda 架构：实时与离线的融合探索

为了兼顾实时与离线处理，Lambda 架构应运而生。它通过引入双链路，离线层（Hadoop）处理全量数据，实时层（Storm/Flink）处理增量数据，最终在服务层合并结果。在电商数据分析场景中，离线层可以每天凌晨对前一天的全量交易数据进行处理，生成各种统计报表；实时层则对实时产生的交易数据进行处理，如实时计算当前的销售额、订单量等指标。

但 Lambda 架构也存在以下痛点：

• 组件多，难管理。由于涉及到离线和实时两条处理链路，需要使用多种不同的组件，如 Hadoop、Storm/Flink、Kafka 等，这些组件的配置、运维和管理都比较复杂，增加了系统的运维成本。

• Kafka 数据一致性、准确性难保障，问题难排查。Kafka 作为实时数据传输的关键组件，在数据传输过程中可能会出现数据丢失、重复或乱序的问题，而且这些问题的排查和解决比较困难，会影响到实时数据处理的准确性和可靠性。

• 实时链路成本高。实时链路需要处理大量的实时数据流，对计算资源和存储资源的要求较高，因此成本也相对较高。

• 离线实时链路数据难对齐。由于离线和实时链路的数据处理方式和时间不同，可能会导致数据不一致的问题，如在统计用户活跃度时，离线数据和实时数据可能会得出不同的结果，这给数据分析带来了困扰。

思考

大数据生态圈为什么从最开始的简单几个组件发展到如今几十上百组件？

核心原因是围绕我们业务需求和痛点，产生了相应的解决方案，也就是目前大数据生态圈越来越多组件的原因。随着业务的发展，数据量不断增大，数据类型越来越复杂，对数据处理的时效性、准确性和多样性要求也越来越高。为了满足这些需求，就需要不断引入新的技术和组件，如为了实现实时处理，引入了 Flink、Kafka 等组件；为了处理非结构化数据，引入了 Elasticsearch 等组件。

离线跑批、Lambda、kappa 存在那些问题？

• 业务规则的复杂：随着业务的发展，业务规则变得越来越复杂，传统的离线跑批和 Lambda 架构难以满足复杂业务规则的处理需求。在电商促销活动中，涉及到多种优惠策略的组合计算，离线跑批和 Lambda 架构可能无法实时、准确地处理这些复杂的业务逻辑。

• 时效性的要求：现代业务对数据的时效性要求越来越高，需要能够实时获取数据并进行分析，以便及时做出决策。离线跑批和 Lambda 架构在时效性方面存在明显的不足，无法满足实时监控、实时推荐等业务场景的需求。

• 数据质量的提高：数据质量对于数据分析的准确性和可靠性至关重要，而传统架构在数据质量保障方面存在一定的缺陷。在数据采集和传输过程中，容易出现数据丢失、错误或不一致的问题，影响数据的质量。

基于上面的场景数据湖组件、血缘关系组件、流批一体组件、审计安全组件等诞生。数据湖组件可以存储各种类型的数据，包括结构化、半结构化和非结构化数据，为数据分析提供了更全面的数据基础；血缘关系组件可以记录数据的来源和处理过程，便于数据质量的追溯和管理；流批一体组件能够实现实时和离线数据的统一处理，提高数据处理的效率和灵活性；审计安全组件可以对数据的访问和使用进行监控和审计，保障数据的安全性和合规性。

从流批一体到湖仓一体

数据湖简介

数据湖是一种新型的数据管理架构，旨在存储和管理企业的各种原始数据，无论是结构化数据（如关系数据库中的表格数据）、半结构化数据（如 JSON、XML 文件），还是非结构化数据（如文本、图像、视频等） 。

与传统数据仓库不同，数据湖不要求数据在存储前进行复杂的预处理和转换，数据以其原始格式直接存入，保留了数据的原始性和完整性。这使得企业能够在后续根据不同的业务需求，灵活地选择合适的处理方式和分析工具，挖掘数据的潜在价值。数据湖的出现，为企业解决了数据多样性和处理灵活性的问题，能够适应大数据时代数据量快速增长、数据类型复杂多变的特点。

数据湖架构

数据湖架构主要包含以下几个关键部分：

• 数据采集：目前通用的是 CDC 采集（数据准确性高）。CDC（Change Data Capture）即变更数据捕获，它能够实时捕获数据源中数据的变化，将这些变化的数据及时传输到数据湖中。与传统的数据采集方式（如 Sqoop、Flume 等）相比，CDC 采集的数据准确性更高，能够更精确地反映数据源中的数据变更情况，减少数据丢失和错误。在电商业务中，订单数据、用户数据等的实时变化都可以通过 CDC 技术准确地采集到数据湖中，为后续的实时数据分析提供可靠的数据支持。

• 真正的流批一体：通过数据湖实现离线和实时共用同一份数据去处理，利用 Flink、Spark 去实现离线和实时共用同一套代码去计算。在传统的大数据处理架构中，离线处理和实时处理往往使用不同的数据存储和计算方式，导致数据不一致和处理流程复杂。而在数据湖架构下，无论是离线分析还是实时处理，都基于数据湖中的同一份原始数据进行操作。Flink 和 Spark 等计算引擎具备强大的流批一体处理能力，它们可以根据业务需求，灵活地切换计算模式，使用同一套代码对数据进行离线批处理和实时流处理。在分析用户行为数据时，可以使用 Flink 实时处理用户的实时行为数据，如实时监控用户的登录、浏览、购买等行为；同时，也可以使用 Spark 对历史用户行为数据进行离线分析，挖掘用户的行为模式和潜在需求。这种流批一体的处理方式，不仅提高了数据处理的效率，还保证了数据的一致性。

数据湖平台优势与价值

数据湖的产生本质也是为了解决业务和技术架构演进中产生的一些痛点，不能迷信新就是好，得结合企业业务实际情况去选择合理的架构。在大数据分析应用场景中，了解时长趋势和需求、优化企业决策、提高运行效率、指导产品优化和运营等，都依赖于数据的安全、准确、有价值、质量高以及计算快等特性。数据湖在这些方面具有显著的优势：

• 数据采集层：之前是 Sqoop、Flume、Seatunnel 等各种组件采集，引入组件多，链路复杂，现在的 CDC 千表入湖。CDC 技术的应用，极大地简化了数据采集的流程。它可以实现对大量数据源（千表）的数据采集，并且能够保证数据的准确性和实时性。与传统的多种采集组件组合使用相比，CDC 减少了组件之间的协作复杂度，降低了数据采集链路中的出错概率，提高了数据采集的效率和稳定性。

• 计算引擎：之前使用 Spark、Impala、Presto、Flink 等多种计算引擎，现在 Flink 流批一体。Flink 的流批一体特性使其成为数据湖架构中理想的计算引擎。它可以在同一个平台上处理批量数据和实时流数据，避免了不同计算引擎之间的切换和数据迁移，提高了计算资源的利用率和数据处理的效率。Flink 还具备强大的容错能力和低延迟处理能力，能够满足企业对实时数据分析和处理的严格要求。

• 即席查询：之前使用 Impala、Presto、HBase、Kudo 等工具进行即席查询，如今 Doris、Starrocks 在即席查询方面表现出色。Doris 和 Starrocks 等新一代的分析型数据库，针对数据湖场景进行了优化，在即席查询方面具有更高的性能和更好的扩展性。它们能够快速响应复杂的查询请求，支持大规模数据的实时查询和分析，为企业的业务决策提供及时的数据支持。在企业进行市场分析、销售数据分析等场景中，Doris 和 Starrocks 可以快速地从数据湖中查询出所需的数据，并生成分析报表，帮助企业及时了解市场动态和业务运营情况 。

数据湖作为大数据技术发展的重要成果，为企业提供了更强大的数据管理和分析能力。通过优化数据采集、计算引擎和即席查询等关键环节，数据湖能够更好地满足企业在数字化转型过程中对数据处理和分析的需求，帮助企业挖掘数据价值，提升竞争力。

结语

从流批一体到湖仓一体的架构演进，是大数据技术发展的必然趋势，也是企业应对日益复杂的数据处理需求的关键举措。流批一体解决了计算层的流批割裂问题，实现了流批统一计算，提高了数据处理的时效性和灵活性。而湖仓一体则在此基础上，进一步打通了存储与计算的协同，构建了统一的存储平台，兼容各类数据，避免了数据孤岛，提升了数据处理的适配性与效率，降低了综合成本，支撑了多元化业务场景的落地。

在这个快速发展的时代，技术的演进永不止步。未来，随着大数据、人工智能、云计算等技术的深度融合，一定还会有更加高效、智能、灵活的数据处理架构的出现，为企业的数字化转型和创新发展提供更强大的支持。作为大数据领域的从业者，我们应紧跟技术发展的步伐，不断学习和探索，将这些先进的技术应用到实际工作中，提升自己能力的同时，也为企业创造更大的价值。