来源：佳米谷大数据
说到“实时分析”，首先想到的是大屏幕上闪烁的数字和起伏的曲线，给人一种整体掌控的感觉。类似的场景经常出现在领导驾驶舱的资源监控或大屏幕显示中，这是“实时分析”中相对简单的应用场景，用于随时了解数据变化。
酷炫实时监控画面)
对于企业来说，不仅要及时观察核心指标的变化，还要了解变化背后的原因。通过对数据的探索性分析，可以全面洞察业务，从而为后续的运营决策、营销决策、风险控制决策等提供信息支持。在电商节的促销活动中，电商平台和商家密切关注活动期间的实时交易数据流。实时分析这些活动流量数据，如用户活跃度、转化率等关键指标，可以帮助平台和商家及时调整相关活动规划策略，从而提高整个活动的营销收益和效益。
从上面的业务场景可以清楚地看到，业务视图数据报表不再局限于实时数据，还希望结合历史数据进行更全面的探索和分析，甚至在某些场景下，需要将两种数据进行整合进行分析。为了实现这些对时间更加敏感的业务需求，背后有一系列非常复杂的技术问题，这促使人们探索批量和流量分析的集成。
00-1010传统架构数据仓库的架构也在随着实时业务分析的需求不断演进。但在数据分析平台初期，为了满足实时分析的需求，传统解决方案通常将实时分析和历史批量数据分析拆分为两种不同的独立架构，形成如下图所示的异构环境：
在这样一个完全不同的独立异构环境中，可以说无论从部署架构层面还是数据存储介质层面都是完全不一致的，这使得技术实现面临很大的挑战。
维护两套不同架构的服务，即实时分析和离线分析，对于系统运行的稳定性、后续的应用升级和故障处理来说，将是复杂而繁琐的。分别设计和管理实时分析和离线分析两种不同的数据模型。离线分析可以通过关联获取更丰富的数据，而实时分析只能以宽表的简单形式进行处理，以保证数据的时效性，开发过程相当繁琐。由于实时数据和离线数据存储介质的分离，两者的数据在存储时相互隔离，管理两者的数据周期更加困难。在数据服务层，需要根据应用层进行定制化开发，为不同的应用提供不同的数据服务，同时这种查询服务层的维护成本增加了很多。这些限制使得开发和运维工作非常困难，无法灵活响应业务敏捷多变的数据检索需求。
Lambda架构基于这种传统方案的进一步演进，诞生于大数据生态的Lambda架构开始崭露头角。在Lambda架构中，数据处理分为三个部分：速度层、批处理层和服务层。
Speed Layer负责实时数据处理，计算逻辑直接与流数据接口，将数据处理的延迟降到最低。然而，由于流数据的数据质量不可控，虽然缩短了数据处理时间，但可能会牺牲数据的正确性和完整性。批处理层负责批量处理数据，可以保证数据的正确性和处理规模。服务层负责集成Speed和batch的数据能力，并向外界提供简单一致的数据访问视图。但是在实际应用过程中，发现Lambda架构也存在一些不足。虽然它使用相同的架构环境，但它也有类似于传统架构的复杂维护工作。企业需要维护两个复杂的分布式系统，即Bat
Kappa架构因此，为了统一批处理层和速度层，卡夫卡团队在业界提出了全新的Kappa架构。基于streaming是一个新的DB数据库)的设计思想，所有的数据消费都要基于Kafka形成统一的数据导出，后续的数据处理也要基于Streaming数据源。
随着Kafka上数据处理能力的提升尤其是Flink框架的加持，显著提升了流媒体数据处理能力)，这种架构引起了人们的关注。Kappa试图解决多个计算引擎带来的开发和运行问题，只保留一组实时代码和数据。但在实践中我们发现，数据处理的复杂性并不完全由单向流处理来支撑，比如数据模型的演化、历史数据的修复和更新、慢变维度的处理等。所有这些都需要更灵活的数据建模能力。
pgc-image/ff627be28f6c4a4cbbdc995c0b450aa1?from=pc”>
基于上述对传统方案、Lambda、Kappa 这些数据架构的讨论，以及企业应用的实际需求，我们认为在数据架构的灵活性、加工逻辑的便捷性、数据模型治理等角度还有更优解。接下来，我们将从批流一体架构这关键部分：数据模型、数据生命周期以及查询服务，进行探讨，为正在进行批流一体选型企业提供一些参考。
基于 Kyligence 的批流一体大数据分析架构探索
基于统一数据模型、生命周期管理、查询服务等批流一体分析中的关键诉求，以及对上述各种方案的探索，最后我们选取基于 Lambda 架构对 Kyligence 产品进行升级，打造出批流一体的企业级产品应用。
数据模型我们知道数据的分析都离不开模型设计作为基础，模型是数据加工的目标和方法，是数据计算逻辑，也是数据分析的对象。这里我们把模型分为实时模型和历史模型，实时模型为追求数据处理的时效性设计，因此要避免计算逻辑复杂，历史模型为分析的完整性设计，因此需要更丰富的指标含义和数据治理能力。从业务分析的角度上出发，两者之间还是存在共同的特征，两者之间的关系可以用如下图示来总结。
从图上实时模型与历史模型的共同特点分析，两者模型是融合统一的。比如两个模型中的事实表通常都是相同的，可以使用公共的分析维度和指标语义进行数据分析，这就要求批流一体的平台可支持两个模型的统一定义，设计和管理，避免模型重复开发和模型不一致。历史模型是实时模型的超集，历史模型涵盖了实时模型的能力，增强了分析的能力（更多维度、更细的粒度、全局去重指标等）。
由于处理实时和历史数据的计算引擎不同，利用其各自优势，实时模型继续使用流式计算引擎对接流式数据源，历史模型基于大数据平台的并行能力，进行大规模多数据源的融合计算。同时历史模型利用数仓理论中成熟的多维分析方法论，提供缓慢变化维管理、历史数据刷新等能力，增强数据治理。通过对模型定义的统一管理，避免了数据处理逻辑的重复开发，更保证了指标定义的一致性。
数据生命周期模型统一了，数据还是不同计算引擎加工，不可以允许两份数据共同提供查询服务，会引起服务能力的不一致，典型是数据结果重复。因此还需要解决数据生命周期如何管理。实时数据流与历史数据集，可以说是两条完全平行不相同的数据流，如下图所示：
需要将两份存储进行统一的数据规整，面对不同的分析场景处理方式各有不同。实时数据为保证时效性，会牺牲一定的数据“质量”（原始数据采集质量不可控，数据晚到，缺少数据质量实时修正流程等），这对于一些监控场景是够用的，可以接受“不那么较真”的数据质量；对于分析型的场景来说这样是不可容忍的，需要保证数据的正确性，需要对实时数据进行相应的“修订”才可以和历史数据进行统一的整合。
所以当实时流数据“沉淀”为历史数据时，需要可以有一定的流程进行实时数据的规整和修正，可以通过实时处理修正（数据重放），也可以是通过离线处理修正（一般称为 Enrichment，比如关联更多数据源），这就要求批流一体的平台需要有不同的场景下的数据治理能力，不能简单把实时数据沉淀为历史数据，而要提供多种数据修正的处理能力。
查询服务SQL 语言是数据分析师最熟悉的查询方式，提供标准的 SQL 语法支持，成为对接数据应用层面尤为关键的一环。过去我们曾采用 HBase、Redis 等多种技术实现查询服务层，甚至要求实时层和历史层采用不同的 API，由应用自行判断合适的查询引擎，这给应用开发带来了更高的门槛。
因此，为了简化服务层接口，需要针对实时分析与历史分析的不同业务场景，自动将查询请求路由到相应的数据集进行检索并返回，同时还需要具备将两者数的查询融合能力，而不是分别从异构系统中取出数据，再在 Data Service 层用笨拙的编码或人工方式进行合并。这也就要求批流一体的平台既要支持实时分析与历史分析的独立查询，也要支持两者数据查询的融合能力。
方案优势Kyligence 作为大数据领域 OLAP 解决方案的yydst，产品本身支持实时数据与历史数据的多维数据分析能力，而基于此的统一产品架构设计，为后续打造批流一体融合分析架构提供了良好的基础支持。下图便是 Kyligence 产品提供基于全 Spark 计算引擎的批流一体架构设计：
从上面的架构图中可清晰的看到在中心位置上是元数据模型的统一管理，这是批流一体实现中比较关键的部分，然后再结合 Lambda 架构的优势，便能较好的解决我们在前文涉及的那些挑战：
模型统一管理方面：改进实时数据模型过去只能支持单一 Kafka Topic 数据的宽表主题，让其也能和历史模型一样，并共享相同的维度表数据，可实现标准星型和雪花模型设计，从而也实现了对模型的统一设计管理；数据生命周期方面：借助于 Lambda 架构优势，将实时与历史数据处理分开并行进行处理，这样的设计不仅很好的保护已有的历史数据资产不做变更或以较小的代价改动，而且能够使用历史数据对实时不满足的地方进行修正并覆盖，对于监控类或其他“低数据质量”要求的场景也可以直接将实时数据沉淀为“历史”数据。为不同的应用场景提供更加灵活的数据生命周期管理；统一查询服务方面：开发智能的查询路由作为查询服务统一查询入口，支持标准的 ANSI SQL 语法，通过对元数据模型的识别，可分别对实时数据集与历史数据集进行探测并解析，返回查询请求所预期的数据结果，同时以超快的响应速度支持。
在整个“实时”业务支持与实现过程中，对比其它架构中企业需要运维底层复杂的基础架构，以及在实现流程上繁琐的代码开发工作来说，企业现在只需要其上面进行模型设计与管理，以及数据生命周期定义的操作，极大地提升了工作效率，同时减轻了运维工作负担和成本投入。
小结
基于 Lambda 架构升级改造后的 Kyligence 批流一体分析融合架构，不仅解决批流一体中关键部分的支持，同时结合 Kyligence 的其它优势，整套方案可更便捷地在企业落地。例如图形界面化的友好操作、支持 Hive 和 Kafka 两种数据源、无缝集成主流的 BI 平台等。
目前，我们正将这套方案应用于一家大型金融机构的数据平台中。对于批流一体的最优解，我们在实践中不断探索和迭代。