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