批流一体架构面临的挑战传统架构数据仓库的架构

（炫酷实时监控大屏）

对于企业来说，不仅需要及时观察核心指标的变化，更重要的是了解变化背后的原因。 通过对数据的探索性分析，可以更全面地洞察业务，从而为后续的运营决策、营销决策、风控决策等提供信息支持。在电商节促销活动期间，电商平台活动期间，商家密切关注实时交易数据流向。 通过实时分析这些活动流量数据，如用户活跃率、转化率等关键指标信息，可以帮助平台和商家及时调整相关活动策划策略，从而提高商家的营销收入和效益。整个活动。

从以上业务场景可以明显看出，业务查看数据报表不再局限于实时数据，也希望结合历史数据进行更全面的探索和分析。 在某些场景下，甚至需要对两个数据进行比较。 融合分析。 为了实现这些对时间更加敏感的业务需求，其背后存在着非常复杂的一系列技术问题，这促使人们开始探索批流一体化分析的道路。

批流一体化架构面临的挑战

传统架构数据仓库的架构随着实时业务分析的需求而不断演变。 然而，在数据分析平台的初期，为了满足实时分析的需求，传统的做法一般将实时分析和历史批量数据分析分开。 它分为2个不同的独立架构，形成如下图所示的异构环境：

在这样一个完全不同的独立异构环境下，可以说无论是从部署架构层面还是数据存储介质层面都完全不一致，这使得技术实现面临着比较大的挑战。

上述限制使得开发和运维工作变得非常困难，无法灵活应对业务敏捷多变的数据访问需求。

该架构基于这种传统解决方案的进一步演进，诞生于大数据生态系统的架构开始出现。 架构中，数据处理分为三个部分：Speed Layer、Batch Layer和Layer。

但在实际应用过程中，发现该架构也存在一些缺陷。 虽然它使用相同的建筑环境，但它也有与传统建筑类似的更复杂的维护工作。 企业需要维护两个复杂的分布式系统，即Batch Layer和Speed Layer，并确保它们逻辑上产生相同的结果并输出到服务层。

Kappa架构因此，为了统一Batch Layer和Speed Layer，业界由Kafka团队提出了新的Kappa架构。 基于新型DB（数据库）的设计思想，所有的数据消费都必须基于Kafka形成统一的数据导出，后续的数据处理都是基于流式（Kafka）数据源。

这种架构随着Kafka上数据处理能力的提升（特别是Flink框架的加持，流式数据处理能力显着提升）而引起了大家的关注。 Kappa试图解决多个计算引擎带来的开发、运维问题，只保留一组实时的代码和数据。 但在实践中，我们发现单向流处理并不能完全支持数据处理的复杂性。 比如数据模型的演化、历史数据的修补和更新、缓慢变化维度的处理等等，都需要更加复杂。 灵活的数据建模能力。

基于以上对传统方案、Kappa、Kappa等数据架构的讨论，以及企业应用的实际需求，我们认为从数据架构灵活性、处理逻辑的便捷性、数据的便捷性等角度，都有更好的解决方案。模型治理。 接下来我们将讨论批流一体化架构的关键部分：数据模型、数据生命周期和查询服务，为企业选择批流一体化模型提供一些参考。

基于云计算的批流一体化大数据分析架构探索

基于统一数据模型、生命周期管理、查询服务等批流一体化分析中的关键需求，以及对上述各种解决方案的探索，我们最终选择基于架构进行产品升级，打造批量与流水一体化的企业级产品应用。

数据模型 我们知道，数据分析离不开模型设计作为基础。 模型是数据处理的目标和方法，是数据计算逻辑，是数据分析的对象。 这里我们将模型分为实时模型和历史模型。 实时模型旨在追求数据处理的及时性，因此必须避免复杂的计算逻辑。 历史模型是为了分析的完整性而设计的，因此需要更丰富的指标含义和数据治理能力。 。 从业务分析的角度来看，两者还是有共同特征的。 两者之间的关系可以概括如下。

从图中实时模型和历史模型的共同特点分析，两种模型是融合统一的。 例如，两个模型中的事实表通常是相同的，可以使用共同的分析维度和指标语义进行数据分析。 这就需要一个批流一体化平台来支持两种模型的统一定义、设计和管理，避免模型混乱。 重复开发和模型不一致。 历史模型是实时模型的超集。 历史模型覆盖了实时模型的能力，并增强了分析能力（更多维度、更细粒度、全局去重指标等）。

由于处理实时数据和历史数据的计算引擎不同，利用各自的优势，实时模型继续使用流式计算引擎连接流式数据源，而历史模型则进行大规模融合基于大数据平台的并行能力进行多数据源的计算。 同时，历史模型利用数据仓库理论中成熟的多维度分析方法，提供缓变维度管理、历史数据刷新等能力，增强数据治理。 通过模型定义的统一管理，避免数据处理逻辑的重复开发，保证指标定义的一致性。

数据生命周期模型是统一的，但数据仍然由不同的计算引擎处理。 不能让两个数据一起提供查询服务，这会导致服务能力的不一致，通常是数据结果的重复。 因此，还需要解决如何管理数据生命周期。 实时数据流和历史数据集可以说是两个完全并行且不同的数据流，如下图所示：

两种存储需要统一进行数据管理，针对不同的分析场景，处理方法也不同。 为了保证时效性，实时数据会牺牲一定的数据“质量”（原始数据采集质量不可控、数据到达较晚、缺乏数据质量实时校正流程等）。 这对于一些监控场景来说已经足够了，“不那么真实”的数据质量是可以接受的；这对于分析场景来说是无法容忍的。需要保证数据的准确性，需要对实时数据进行“修正” ” 相应地才能与历史数据统一。

因此，当实时流数据“沉淀”成历史数据时，需要有一定的流程来组织和修正实时数据。 这可以通过实时处理和校正（数据回放）来完成，也可以通过离线处理和校正（一般称为关联更多数据源）来完成，这需要批流集成平台具有数据治理能力不同的场景。 它不能简单地将实时数据沉淀为历史数据，而必须提供多重数据修正的处理能力。

查询服务SQL语言是数据分析师最熟悉的查询方式。 它提供标准的SQL语法支持，成为数据应用层面尤为关键的一环。 过去我们使用HBase、Redis等各种技术来实现查询服务层，甚至要求实时层和历史层使用不同的API。 应用程序可以自行确定合适的查询引擎，这给应用程序开发带来了较高的门槛。

因此，为了简化服务层接口，需要根据实时分析和历史分析的不同业务场景，自动将查询请求路由到相应的数据集进行检索和返回。 同时，还需要具备融合两种数据查询的能力，而不是分别从异构系统中提取数据，然后在数据层使用笨拙的编码或手动方法进行合并。 这也需要一个批流集成平台，支持实时分析和历史分析的独立查询，以及两种数据查询集成的能力。

解决方案优势作为大数据领域OLAP解决方案的先行者，产品本身支持实时数据和历史数据的多维度数据分析能力，基于此的统一产品架构设计为后续提供了良好的基础支撑创建批流集成分析架构。 。 下图是该产品基于完整Spark计算引擎提供的批流一体化架构设计：

从上面的架构图我们可以清楚地看到，其中心位置就是元数据模型的统一管理。 这是批流集成实现的关键部分。 然后再结合架构的优点，就可以更好的解决我们的问题。 上述挑战：

在整个“实时”的业务支撑和实施过程中，相比于其他架构企业需要运维底层复杂的基础设施，以及实施过程中繁琐的代码开发工作，企业现在只需要执行模型设计和管理在此之上。 ，以及数据生命周期定义的操作，大大提高了工作效率，减轻了运维工作负担和成本投入。

概括

基于升级改造的批流一体化分析融合架构，不仅为批流一体化关键部分提供支持，还结合其他优势，使整个解决方案更方便在企业实施。 例如，图形界面友好，支持Hive和Kafka数据源，与主流BI平台无缝集成。

目前，我们正在将这个解决方案应用到一家大型金融机构的数据平台上。 对于批流集成的最优方案，我们在实践中不断探索和迭代。