一、对于流批一体数据仓库
流批一体是一种架构思维，这种思维说的是同一个业务，应用同一个sql逻辑，在既能够满足流解决计算同时也能够满足批处理工作的计算。
从效率层面来说，批处理只能以t+1的模式出现业务数据，流解决只能以t+0的模式出现业务数据，当二者独立时企业须要运行两套代码，开发、运维、人力老本高，出现周期长。而流批一体则应用一套代码出现两套业务数据，开发、运维老本升高一半，实效性显著晋升。
那么，什么又是流批一体数据仓库呢？简略点说，它是将异构源的数据应用同一套计算引擎并联合数据仓库实践所特有的材料存储架构实现实时、离线剖析业务的数据汇合。
该数据汇合具以下特点：
面向主题：数据仓库依照肯定主题域组织数据；
易于集成：打消源数据中的不一致性，保障企业全局信息的一致性；
绝对稳固：汇合中数据长期保留，只需定期加载、刷新；
预测趋势：数据中寄存历史信息，可对企业倒退历程和将来趋势做出定量分析和预测。
二、数栈在流批一体数仓上的演进
随着客户体量增大，客户需要逐渐减少，面对PB级别的批数据和流数据的解决需要，数栈技术团队面临越来越多的挑战，在这个过程中逐步完善了数栈数仓架构体系。从2017年的基于传统架构的批处理通过4年迭代到基于混合架构的流批一体数仓，如图：
数栈流批一体架构混合数仓演进过程示意图
- 基于传统架构的批处理
互联网诞生之初尽管数据量暴增，单日事实表条数达千万级别，但客户需要场景更多是“t+1”模式，只需对当日、当周、当月数据进行剖析，这些诉求仅离线剖析就可满足。
恰逢hadoop生态刚刚衰亡之时，数栈技术团队基于数据暴增存储缓和的窘境搭载Hadoop生态链，将数据周期性导入HDFS，利用Hadoop平台Hive做数据仓库就可实现对HDFS上的海量数据集进行离线剖析。
这一阶段其实与互联网实质架构没有过多变动，仍是将数据周期性装载而后剖析，只是应用的技术由经典的数仓工具转型到了大数据工具。
- 基于Lambda架构的流批独立
随着网络、通信技术倒退，“隔日达”的数据已不能满足客户的需要场景，他们更期待实时数据出现，这样无论是在金融、证券交易还是批发、港口的实时监控预警等场景下，决策者都能够第一工夫做出无利判断，晋升效率缩小损失。
为应答这种变动，数栈技术团队联合过后支流大数据处理技术，在原有的HIVE数仓上，减少了过后最先进的流批一体计算引擎Spark来放慢离线计算性能。同时在原有的离线大数据架构上，减少了一条基于Kafka存储以及Flink计算引擎的流解决链路用于实现实时性要求较高的指标计算。
尽管应用Spark和Flink计算引擎满足了客户对于实时数据的场景出现，但因为Spark尽管理念上是流批一体但实质上还是基于批来实现流，在实效上仍存在肯定的硬伤。而同期的Flink计算引擎并不欠缺，数栈技术团队于是对Flink性能进行了肯定的扩大。
在此过程中同步孵化出了能够实现更多数据源同步的FlinkX和能够通过Sql对更多的数据源进行实时计算并写入的FlinkStreamSql。（取之开源，馈之开源。数栈技术团队已将它们分享到了Github上，有须要的同学能够点原读原文查看。）
这一阶段数栈技术团队通过自研的FlinkX和FlinkStreamSql，在原有的离线链路上新增了流计算链路用于实时数据分析，实现了从传统大数据架构到Lambda架构的转变。
Lambda架构的核心思想是将业务进行拆分，实时性要求高的业务走实时计算计划，实时性要求低的业务走离线计算计划，最初由数据服务层对全副数据进行剖析汇总供上游应用。
Lambda架构流批独立解决流程图
- 基于Kappa架构的实时处理
Lambda架构的搭载根本满足了客户对于实时数据的诉求，大量客户通过数栈DTinsight实现数据赋能生产工作的需要，在每日数以万计的数据量下，数栈DTinsight也能保持稳定的运行，为客户在数据驱动业务上提供了强有力的后盾。
尽管Lambda架构满足了客户在业务上对于实时性的需要，但随着企业倒退业务量也在逐渐减少，导致开发与运维老本逐渐减少。此时Flink流解决技术也逐渐成熟，Flink Exactly-Once和状态计算已齐全能够保障计算最终后果的准确性，因而数栈技术团队开始关注在Lambda架构的根底上如何做出调整。
LinkedIn的前首席工程师杰伊·克雷普斯（Jay Kreps）曾针对Lambda架构提出过一个改良观点：改良Lambda架构中的Speed Layer，使它既可能进行实时数据处理，同时也有能力在业务逻辑更新的状况下重新处理以前解决过的历史数据。
受到Kreps的启发，数栈团队举荐实时业务较多的客户将Kafka的数据日志保留日期，当流工作产生了代码变动或者须要对上游进行回溯计算时，只须要放弃原来的Job N不动，而后再启动一个作业Job N+1，指定历史数据的offset进行计算并写入到一张新的N+1表中，当Job N+1的计算进度赶上Job的进度后，能够将原来的Job N工作替换成Job N+1，上游的业务程序只须要依据Job N+1生成的表进行剖析或者展现。这样就能够将离线链路层去掉，缩小客户额定开发及保护代码的工作量，同时对立了业务的计算口径。
Lambda架构的的毛病在于须要保护两个简单的分布式系统中产生雷同后果的代码，而通过减少并行度以及重播历史数据的形式去重新处理实时数据能够无效的代替离线数据处理系统。这样架构既简略也防止了保护两套零碎代码还须要放弃后果统一的问题。
Kappa架构实时数仓流程图
- 基于Kappa+Lambda混合架构的流批一体数仓
通过Lambda架构和Kappa架构，数栈能够解决大部分企业面临的实时场景和开发运维需要，但也有些企业对于实时业务需要较高就会产生因极其数据乱序导致实时计算数据不精确，那么这个时候流工作就面临着数据品质上的问题。
针对于这种状况数栈技术团队联合Kappa架构和Lambda架构的劣势，通过Labmda架构中离线链路对实时链路产出数据周期性校订，同时联合FlinkX内核反对流批一体的个性，在计算层基于FlinkX计算引擎来对立实现整个链路中计算工作，以此来保证数据的最终一致性。
三、数栈流批一体外围引擎FlinkX技术解读
FlinkX是一款基于Flink的流批对立的数据同步以及SQL计算工具。既能够采集动态的数据，比方MySQL，HDFS中的业务数据，也能够采集实时变动的数据，比方MySQL、 Binlog、Kafka等。在FlinkX1.12中，也会将FlinkStreamSql交融其中，使得FlinkX1.12既能通过同步工作采集动态、动静的数据，又能通过SQL工作对采集后的数据依据业务时效性进行流批处理。
在数栈中，FlinkX的流批一体的实现是体现在数据采集层以及数据计算层。
- 数据采集层
从数据的时态来讲，能够将数据分为实时数据和离线数据。比方像Kafka、EMQ这类高吞吐量的消息中间件它们通常持有的是源源不断的数据，所以能够通过FlinkX的实时采集工作对数据进行实时的落库，以便后续的工作进行近实时、准实时的业务计算。像Mysql、Oracle这类OLTP数据库通常是持有的历史的事务数据，这类数据都是以天、月为工夫单位进行存储与计算，因而能够通过FlinkX的离线同步工作将这类数据间隔性增量或者全量同步到咱们的OLAP数仓或者数据湖中，而后依据各类业务指标对数据进行分层以及跑批剖析。
另外，除了将数据采集到存储层，还会依据数据治理中定义的数据标准并联合数仓标准，通过FlinkX的同步工作实现对数据的荡涤、转换以及维度补全，以此进步数据的有效性以及业务计算的准确性。
- 数据计算层
当数据被采集到指定的存储层后，会联合存储类型以及业务时效性对数据进行惯例的业务计算。FlinkX Sql能反对流批计算的能力来源于Flink内核在1.12版本中对元数据的对立治理以及在DataStream API上反对批执行模式，这样加强了作业的可复用性和可维护性，使得FlinkX 作业能够在流和批两种执行模式之间自在进行切换并只须要保护一套代码，无需从新写任何代码。而且，相比于开源的Flink，FlinkX 1.12 不仅提供了更多的Source以及Sink来反对对各类数据源的实时以及离线计算还实现了脏数据管理插件，让客户在ETL阶段针对谬误不合规的数据可能由感知以及容错解决能力。
FlinkX在数栈中实现流批一体流程图
- 数栈流批一体在数仓上的实际
上面联合架构图场景讲述下数栈流批一体的做法。
场景：股票交易中K线有分时图、日线图、周线图等之分，用户股票交易实现后须要在K线上显示交易点和成交金额。
数栈未实现流批一体解决形式：
对于下面这个场景数栈未实现流批一体前的做法是分时图的交易点会采纳Flink计算，日K、周K等的交易点通过配置周期Spark工作进行计算，即经典的Lambda架构，这种架构的痛点是比拟显著的，保护两套代码开发效率低、两套计算引擎老本高、数据口径不统一。
数栈实现流批一体后处理形式：
在数栈平台先抉择创立实时采集和数据同步工作将业务库数据采集到Kafka和Iceberg，即数仓的ODS层。实时数仓和离线数仓从ODS到DWD层数据荡涤和数据打宽的解决逻辑是一样的，表定义构造也是保持一致的，所以这一步只须要实现一套Flink SQL数栈平台会主动翻译成Flink Stream和Flink Batch工作即可用于实时数仓又能够用于离线数仓。实时数仓和离线数仓DWS层别离寄存分时图交易点信息和日K、周K等数据，两边解决逻辑不同所以在这一层须要依据业务开发两套SQL, Stream Flink SQL对接实时数仓DWD层数据实时计算分时图交易点，Batch Flink SQL对接离线数仓DWD层数据周期调度计算日K、周K等交易点数据。应用层服务间接从DWS层获取交易点数据进行展现。
通过实例咱们能够看到数栈抉择了Iceberg作为流批一体的存储层，起因如下：
- Iceberg存储的是原始数据，数据结构能够多样化；
- Iceberg反对多种计算模型，是一个通用化设计的Table Format，完满地解耦了计算引擎和底下的存储系统；
- Iceberg底层存储反对灵便，个别用 S3、OSS、HDFS 这种便宜的分布式文件系统，采纳特定的文件格式和缓存就能够对应场景的数据分析需要；
- Iceberg我的项目背地的社区资源十分丰盛，在国内外曾经有不少大公司将海量的数据跑在Iceberg上；
- Iceberg保留全量数据，当流计算工作有重跑历史数据的需要时可从Iceberg读取数据而后无缝切换到Kafka即可。
四、流批一体为企业赋能
随着大数据畛域一直倒退，企业对于业务场景的诉求从离线的满足到高实时性的要求，数栈产品也在这一过程中进行着一直的迭代降级，为企业在晋升数据计算结果品质，晋升企业业务研发效率，升高企业保护老本上提供了无力帮忙。
- 晋升数据计算结果品质
高质量、高准确度的数据有利于企业做优良的决策，数栈基于混合架构的流批一体数仓将计算引擎进行了对立，解决了不同引擎两套代码之间的SQL逻辑不能复用问题，让数据在一致性和品质上失去了保障。
- 晋升企业业务研发效率
从业务开发到上线，业务开发人员只须要针对业务开发一套SQL工作，随后依据业务延时规范在流批计算之间进行灵便切换即可。利用端开发人员也只须要针对业务拼接一套SQL封装逻辑。
- 晋升企业资源利用率，升高保护老本
企业用户的实时、离线业务只须要运行在同一套计算引擎上即可。无需为运行实时、离线业务的不同计算引擎别离购买高配的硬件资源。而针对业务变更，开发人员也只须要批改对应的SQL工作，无需思考实时、离线工作别离批改。
五、将来布局
尽管FlinkX SQL在肯定水平晋升了流批计算的能力，但批处理在实效上还有待进步，下一步数栈技术团队将从Flink源码层面去对算子以及Task进行一些优化，进步批处理层面计算效率升高企业工夫老本。同时进一步对立数据源中元数据规范，让企业在数据治理过程中所波及的数据字典、数据血统、数据品质、权限治理等模块在后续应用层面可疾速被响应，缩小企业治理老本。
数栈流批一体架构，通过迭代已实现实时数仓+OLAP场景联合，只需一套代码就可进行多个计算解决模式，不仅满足了企业低提早、高时效的业务驱动需要，同时也升高了企业开发、运维、人工成本。当然这只是流批一体摸索的第一步，数栈技术团队将持续在数据存储层面进行深挖，将数据仓库的便捷治理、高质量数据个性与数据湖的可摸索、高灵活性相交融，实现数栈在数据仓库到湖仓一体的转变，实现对未知数据先对立存储再灵便摸索的能力，在数据架构层面更进一步。