这是我参与「第四届青训营 」笔记创作活动的第6天。
1、电商流批一体实践
字节之前的电商业务数据分为离线数仓和实时数仓建设，离线和实时数据源，计算引擎和业务代码没有统一，在开发相同需求的时候经常需要离线和实时对齐口径，同时，由于需要维护两套计算路径，对运维也带来压力。
因此需要将数据源、业务逻辑、计算引擎统一，提高开发运维效率。
数据源：将Kafka的数据利用Flink进行预处理，并同步到Hive中，用于批处理。由于流批的数据都是从Kafka到Flink，保证了数据源的一致性。
业务逻辑：不同的调度背景使用同样的SQL代码，UDF相关的代码逻辑都是复用的，只不过批是按小时/天调度，流一直在跑。
计算引擎：都使用Flink引擎，提高开发运维成本。
2、字节Flink OLAP实践
Flink的OLAP在字节内部的场景主要是HTAP场景。TP是事务计算，AP是查询计算，HTAP可以理解为能处理TP、AP混合场景的引擎。
在没有HTAP引擎之前，“在线”和“离线”是完全隔离开的，因此可能出现小时/天的延迟。线上数据通过OLAP引擎更新并存储支持事务的存储系统中（比如MySQL），线上数据库再通过离线流程，将数据同步到离线数据源（比如Hive）中，下游再基于Hive的数据进行处理。
有了HTAP之后，AP和TP都可以通过HTAP引擎输送到下游，Flink直接提供数据查询和分析的能力，“在线”和“离线”不再隔离开，延迟可以降到秒级。
个人总结
本文介绍了字节跳动在电商流批一体的实践，将数据源、业务逻辑、计算引擎进行统一。然后介绍了字节跳动在Flink OLAP所做的实践，有了HTAP之后，优化了OLAP的并发性和延迟性。
