哔哩哔哩张杨：由Kafka+Flink向湖仓一体的转型之旅

从最早的Flume+Flink，到后来的Kafka+Flink，再到今天的湖仓一体。哔哩哔哩实时数仓演进历程，是大型互联网企业大数据发展的一个“缩影”，为更多企业部署实时数仓技术路线，带来了极大的参考价值。

那么，在一线技术开发人眼中，实时数仓是怎样一个存在形态？真正的实时数仓应该具备哪些典型特征？和离线数仓相比，实时数仓在整体架构或者内核技术上，有什么不同？湖仓一体在满足业务实时性方面有哪些表现……在ITPUB《实时数仓选型指南》系列采访中，我们有幸邀请到哔哩哔哩基础架构部资深开发工程师 张扬，通过张老师的实践经验分享，我们可以系统、全面地了解实时数仓的过去和现在，为企业找到适合自己的部署方案打开新的思路！

答：实时数仓是一整套技术方案，本质上是对标的是离线数仓。为什么会出现实时数仓？主要是因为传统离线数仓在数据处理上有比较高的延迟，一般数据实效性是T+1或者小时级别。随着企业业务的发展，很难满足实时性需求，而实时数仓可以更好地解决这一问题。包括消息中间件或者说是一些计算引擎，其实都是为了解决传统离线数仓的缺陷以及不足，演进而来。如果用一句话总结，实时数仓是一个完整的解决方案，主要是为解决数据端到端的时效性问题。无论是数据的生产，还是数据最终的业务端，都会通过一个具体的解决方案满足时效性要求。

2、问：实时数仓的典型特征是什么？有小时级、分钟级、秒级甚至亚秒级这样一个标准吗？

答：业界对时效性要求有不同标准，大多数是分钟级或者是秒级这样一个标准，当然也有亚秒级的响应，具备这种能力的实时数仓比较少。比较明显的特征是，端到端的延迟实际上在大幅降低。因为在数据领域，数据价值与实效性是一个统一体，随着数据时效性降低，价值也在降低。说白了，数据处理的时间越久，价值也会大打折扣。

3、问：和离线数仓相比，实时数仓在整体架构或者内核技术上，有什么不同？发生了哪些重要变化？主流趋势是什么？

答：主流架构主要有两种：一个是Lambda架构；一个是Kappa架构。Lambda架构，由离线数仓和实时数仓两部分组成，是为了满足实时计算目标，在原来离线数仓基础上增加了一个实时计算的链路，并对数据源做了改造。对实时数仓而言，Lambda架构有明显的不足，同时维护两套系统，资源占用率高。而Kappa架构的优势在于，只通过一套系统就可以同时完成流处理、批处理任务，但Kappa架构无法解决流处理和批处理在部分处理逻辑不一致的情况。

所以，任何架构都不是十全十美，企业要根据自己的业务场景选择适合自己的架构。一般来说，在数据采集上，一些小公司会使用类似Flume这种开源、高可靠、高扩展、容易管理的数据采集系统。那么，数据如何从生产端落到存储？很多企业会以消息中间件Kafka为主。计算引擎主流的是Flink，一些企业也在用 Spark streaming，存储主要是以Kafka为主。

个人认为，Flume+Flink是早期实时数仓的完美解决方案。之前，离线用Hadoop，但存在单点瓶颈，编程框架不够灵活，所以有了之后的Spark。现在，大家基本上都用Kafka+Flink这样一套技术架构。不管是离线数仓，还是实时数仓，都会在底层做一个从上到下的分层。具体包括：ODS（原始数据层）、DWD(数据细节层)、DWS(数据服务层)等。

这几年，随着数据技术的发展，人们的认知也在发生着迭代。比如：在存储层，Kafka最早只是一个消息中心，如果用它来承担整个数据仓库的数据存储，性能不足以支撑。另外，成本比较高，用Kafka存储数据，对存的要求比较高。同时，数据规模也不会太大。因为，在消息中间件里，不可能存太多数据，一般只存最近的一两天，不会存过去几十天的数据，这说明Kafka不具备查询、分析能力，最多支撑的是数据消费能力。

那么，如果企业依然用Kafka+Flink来支撑实时数仓，会导致一个什么结果呢？假如Kafka里的数据出了问题，想通过一个引擎把数据批量拉出来看，这是一件非常困难的事儿。因为Kafka更偏向于线上服务，接口比较简单，没办法进行查询分析。所以，用户在实时数仓应用过程中，会很不爽，特别难受，维护成本也高。

还有一个问题是，Kafka和离线数仓一样，都不支持数据更新。只不过，离线数仓是ROI导向，数据有边界，直接覆盖到某一端就可以了。而实时数仓没有边界，需要一些点对点的数据更新能力。比如：从DWD到DWS，需要有轻度聚合的操作。如果你用Kafka来存储数据，数据规模会比较大，通过追加log的形式支持数据更新，会引发数据膨胀，导致下游使用数据不方便，这也是湖仓一体架构逐渐替代Kafka+Flink的根本原因。

湖仓一体的设计原理是，用Hudi、iceberg这样的内核技术，解决Kafka+Flink之前的存储问题。大体来看，湖仓一体架构为企业带来的直接好处是，实现了流批一体的支持。比如：在文件系统中，支持了类似Kafka的一个流式增量效果的能力，能达到基本比较实时的效果，比如分钟级。但是没有办法像消息中间件那样，具备特别实时的能力，很难达到秒级。其实，在实时数仓的大部分场景中，做到分钟级就够用了。

湖仓一体还有另外一个优势，就是支持update，解决了Kafka的弊端。湖存储不受时间限制，底层依托于HDFS，可以存大量的历史数据。与此同时，湖仓一体可以增量消费，可以做到数据写入后立刻就能读，做到类似消息中间件的效果。

当然，有了湖仓一体，并不意味着Kafka+Flink就会被“一刀切”。在一段时间里，Kafka和湖存储会有一个并行期。而从长远发展看，企业慢慢都会从Kafka往湖仓上面转。而在特别实时的场景，像风控这种业务线，具有秒级或者亚秒级的延迟需求，Kafka依然具备优势。

而在计算层，Flink是主流计算引擎，尤其当湖仓一体与Flink结合后，上层的计算层也会朝着统一方向去发展，真正达到流批一体的效果。

4、问：有些企业用Kafka来做实时数仓，有些企业则基于HTAP满足业务实时性需求，包括云数仓、湖仓一体。具体而言，有没有一个清晰的界限，对整个技术栈做一个分类？

答：其实，中间使用什么技术未必特别重要，实时数仓最大的特点是，整个数据从产出到最终价值实现，是一个端到端的比较低的延迟。从这个角度看，数据的使用，或者从业务视角去划分，可能会更准确。目前，业界会分为三类：实时、近线、问：可否从内核的角度做一个区分？

答：以B站为代表的公司，基本采用开源产品搭建起来的，相对来说，存储和计算分得比较清楚。但是，以Doris、TiDB 、Hologres为代表的企业，是把计算和存储统一到一套引擎里，是存算一体架构。个人认为，在一些比较小的业务场景下，存算一体架构非常方便。但是，对于数据规模比较大的业务场景，存算一体架构在业务能力支撑上会比较难，包括Clickhouse，会对需求有依附，在功能和成本上比较难以支撑业务诉求。

简单理解，数据规模比较小，比如是千万级别的时候，所有的数据可以从生产端直接到Clickhouse、TiDB等，终端在使用的时候，直接查就可以了。不管是做实时的指标，还是偏OLAP 的分析，可以直接从存储里取数据，中间用一套比较强的存储引擎，没有任何性能问题。但是，如果数据规模比较大，比如：达到万亿级或者千亿级规模，这种存算一体架构暴露出来的缺点，就会比较逆向。

答：以Hudi为存储，以Flink为引擎，构建一整套湖仓架构，离线架构也依托于这个架构往流批一体的方向在演进。

答：早期选型的时候也纠结，到底选择Hudi，还是iceberg。当时感觉Hudi功能更全，而iceberg更专注于append 场景，标准非常清晰，更多是format 表格式的一些定义。而B站的业务场景，更需要一些更新等能力，所以最终决定选择Hudi。

答：场景主要是几个方向：一、机器学习方向，通过一些特征进行个性化推荐；二、广告场景；三、内部的一些报表需求。

答：是的，在线业务实时需求较多。一般来说，类似后台的模型沉淀这种服务，是离线业务；推荐业务就是在线业务；训练也是离线业务。对业务方来说，不管离线和在线业务都直接面向用户，实时数仓团队都要提供服务支持。

采访嘉宾简介张杨，哔哩哔哩 基础架构部-资深开发工程师。2015年本科毕业于北航。2015～2017年就职于阿里巴巴集团安全部，参与业务风控系统开发。2017年至今就职于哔哩哔哩，主要从事大数据调度，传输和计算的研发，目前主要在做实时计算平台相关工作，推动flink在b站多个业务的应用和落地。在flink实时计算，实时数据采集传输，任务调度都有一定的经验。

充电10分钟跑1200公里，丰田官宣重大突破，还要将电池体积重量成本减半！中科大刚刚也有大消息

科技前沿｜马斯克：未来机器人数量将超过人类 中国会有很强的人工智能能力

一研究生10年前论文存在剽窃，学校决定：撤销其硕士学位！校规：若已在职，还将通报其单位

LOL：EDG队内语音曝光，Uzi让杰杰开团，杰杰反怼Uzi爱咋玩咋玩

Threads用户突破3000万，推特威胁起诉Meta窃取商业机密，马斯克回应

哔哩哔哩大会员2.68元/月，6.88元/3个月，请点本站上边链接购买

2023年07月07日 14:08:04

随机账号机器密码：
20AJ3 YP7
54G JC78
37XK425kzZ62 YH92zx071Ejeb3
18DH307wnE0 VZ83bj791Rfzw
70KO891cx VS85
00YL947roN59h RP66pz329O
69RP466s KT22rz678Rxkh8
86XH757 YC23tl088Hjtj7
30XC643 FU49oj33
74KV048p TD76cl