流批一体化架构方案

一、当前数据处理待痛点分析

• 当前生产环境因source端数据更改，导致后续计算重新运行情况时有发生，这样不仅牵扯开发精力而且十分消耗资源。
• 现有的数据处理方式不能更好的面向未来日益增多的需求
• 业务线数据模型混乱，数据使用成本特别高。
• 需求驱动的烟囱式开发，完全没有复用的可能性，计算成本居高不下。
• 分析计算后的数据下沉到Mysql中，查询和保障方面不灵活。
  
  

二、流批一体化架构方案

   1、流批一体化架构方案分析   目前流批一体化架构比较完美的实现方式是采用流计算+交互式分析双引擎架构，在这个架构中，流计算负责的是基础数据，而交互式分析引擎是中心，流计算引擎对数据进行实时ETL工作，与离线相比，降低了ETL过程的latency，交互式分析引擎自带存储，通过计算存储的协同化，实现高写入TPS、高查询QPS和低查询latency，从而做到全链路的实时化和SQL化，这样就可以用批的方式实现实时分析和按需分析，并能快速的响应业务的变化，两者配合，实现1+1>2的效果，该架构对交互式分析引擎的要求非常高，可考虑的方案：ClickHouse、Presto+Kudu、ES、Hbase，也可以考虑目前比较热的数据湖技术，如Deltalake、Hudi等支持在HDFS上进行upsert更新，随着其流式写入、SQL引擎支持的成熟，在未来使用一套存储引擎解决实时、离线数据需求，从而减少多引擎运维开发成本，具体的技术实现讨论根据业务场景决定。传统的Lambda架构很明显的缺陷是需要维护两套分别跑在批处理和实时计算系统上面的代码，而且这两套代码得产出一模一样的结果。对于Lambda架构设计需要面对的问题是：     1、我们是否可以使用流计算系统来处理这些问题？

2、全量数据处理如何用流计算处理？

3、相较批处理流计算天然的分布式特性注定具备良好的扩展性，其能否加大并发量来处理海量的历史数据，在现阶段我们公司的业务场景下显然海量历史数据的处理是必须要考虑的问题？基于以上问题的考虑，使用Kappa架构方案替代原来的Lambda架构方案是具有可行性的。

   

     Flink流计算系统对全量数据进行计算的逻辑

      1)用Kafka保存数据，需要几天数据量就保存几天。（在实际应用场景有待验证，容错机制、一致性保证）

      2)当需要全量计算时，重新起一个流计算实例，从头开始读取数据进行处理，并输出到一个结果存储中。

      3)当新的实例完成后，停止老的流计算实例，并把老的一引起结果删除。

2、流批一体化数据处理体系整体架构

整个流批一体化体系架构共分为5层，暂时不考虑平台层，仅考虑接入层、存储层、计算层和应用层，下图是整体架构的概要图。

         

  1、接入层：该层利用数据接入工具（DataX、Canal）收集数据到Kafka中，这些数据在未来不仅参与实时分析计算也参与离线分析计算，保证实时和离线计算的原数据是统一的（ODS层），进而构建流批一体化的大数据处理架构。

2、存储层：该层对原始数据、ETL后的明细数据进行存储，基于统一的数据模型分层，将数据分别存储在HDFS、ClickHouse、Hbase、Redis、Mysql等存储引擎中（上述存储引擎仅作为参考，具体的存储引擎讨论后决定）。

3、计算层：计算层主要使用flink，也可考虑存储引擎自带的计算能力。Flink计算引擎主要用于实时数据同步、流式ETL、复杂多维业务场景下的指标实现。基于Flink时间语义、状态保存、端到端的精确一次性保障、容错机制等实现业务需求。

4、应用层：以统一的查询服务对各个业务线数据场景进行支持，目前只针对财务系统。

5、平台层：在平台层主要需要做三个方面的工作，分别对外提供统一的查询服务、元数据及指标管理、数据质量及血缘关系。【作为架构后期实现内容，现阶段暂时不考虑】

3、数据模型分层流批一体化实时数仓

考虑到实时性问题和中间流程出错的可能性，尽可能减少分层，因此将其分为四层

  ODS 层

原始数据层，保存原始数据，对非结构化的数据进行结构化处理，轻度清洗，几乎不删除原始数据。该层的数据主要来数据库的binlog日志，对于binlog日志通过canal监听，写到消息队列Kafka中。除了存储在Kafka中，同时也需要考虑从是否将业务数据库的binlog日志通过Flink写入HDFS、Kudu等存储引擎，（需考虑是否使用Hive，落地到Hive表中）供查询明细数据，这样就可以支持离线分析处理。

DWD层

实时明细数据层，以业务过程作为建模驱动，基于每个具体的业务过程特点，构建最细粒度的明细层事实表；可以结合企业的数据使用特点，将明细事实表的某些重要维度属性字段做适当冗余，也即宽表化处理；该层的数据来源于ODS层，通过简单的Flink流式ETL后得到，对于binlog日志的处理主要进行简单的数据清洗、处理数据漂移，以及可能对多个ODS层的表进行Join，该层的数据存储在消息队列Kafka中，同时也需考虑使用Flink实时写入Hive表，供查询明细数据。

DIM层

公共维度层，基于维度建模理念思想，建立整个业务过程的一致性维度，降低数据计算口径和算法不统一风险；

DIM层数据来源于Flink程序实时处理ODS层数据得到；

DIM层维度数据主要使用选择MySQL、Hbase、Redis三种存储引擎，对于维表数据比较少的情况可以使用MySQL。对于单条数据大小比较小，查询QPS比较高的情况，可以使用Redis存储，降低机器内存资源占用，对于数据量比较大，对维表数据变化不是特别敏感的场景，可以使用HBase存储。（根据具体的业务场景考虑是否需要）

DM层：

公共维度层，基于维度建模理念思想，建立整个业务过程的一致性维度，降低数据计算口径和算法不统一风险；

(1)数据集市层

以数据域+业务域的理念建设公共汇总层，对于DM层比较复杂，需要综合考虑对于数据落地的要求以及具体的查询引擎来选择不同的存储方式（现有业务场景主要考虑落地到Mysql中），分为轻度汇总层和高度汇总层，高度汇总层数据用于比较简单的KV查询，提升查询性能数据的时效性要求为秒级，轻度汇总层Kafka中宽表实时写入OLAP存储引擎，用于复杂的OLAP查询场景，可以满足分析和产出复杂报表的需求，对数据的时效性到分钟级；

(2)轻度汇总层

轻度汇总层由明细层通过Flink流式ETL得到，主要以宽表的形式存在，业务明细汇总是由业务事实明细表和维度表join得到；轻度汇总层数据存储比较多样化，首先利用Flink实时消费DWD层Kafka中明细数据join业务过程需要的维表，实时打宽后写入该层的Kafka中，以Json或PB格式存储；对于多维业务明细汇总数据通过Flink实时写入Kudu、HDFS和ClickHouse用于复杂的多维数据分析，实时特征数据则通过Flink join维表后实时写入HDFS；

(3)高度汇总层

高度汇总层由明细数据层或轻度汇总层通过聚合计算后写入到存储引擎中，产出一部分实时数据指标需求，灵活性比较差；

计算引擎使用Flink Datastream API和Flink SQL，指标存储引擎根据不同的需求，对于常见的简单指标汇总模型可直接放在MySQL里面，维度比较多的、写入更新比较大的模型考虑放在HBase里面，还有一种是需要做排序、对查询QPS、响应时间要求非常高、且不需要持久化存储的可以考虑直接存储在Redis里面。

作者：Asuro(陈)