Flink在实时处理领域，通过扩展分析功能，能够和HTAP架构融合。 一般是实时数仓：https://pingcap.com/zh/blog/when-tidb-and-flink-are-combined

关于这点，具有代表性的例子是 PingCAP的TiSpark.

日志架构分为几个部分： 采集日志–》传输日志–》存储日志–》查询/展示日志 下面是一些日志架构。 文件日志存储 在小规模（个位数机器）、低并发的应用下，直接使用log4j/logback将日志输出到本地文件即可。 ELK三剑客 稍微常见的日志接收、存储和查询架构就是ELK（ElasticSearch、Logstash/Filebeat、Kibana）。 对于现成的开源框架，用得也挺广泛。 不过，当日志量很大时，硬件开销不容小觑。 基于MQ 比如使用Kafka，单台几十万的并发可以达到，压力在传输和存储上。 传输需要经过3次序列化和反序列化（采集时写入本地硬盘，进出MQ，入库）；存储一般用ES或HBase。 对于每秒上百G的日志，需要的机器至少上千台（根据硬盘写入速度200MB来算，几百G/s的日志量），这个开销也是很大的。 更精简的架构 减少传输量：压缩日志，一般能高达80%以上的压缩率 减少序列化次数：需要减少中转流程，采集完不用落盘，直接发送给日志处理服务 更强的存储数据库：列式存储的ClickHouse 下面可以实现一个简单的客户端和日志处理端： 日志发送客户端：基于UDP传输（节省传输量），需要考虑UDP最大传输量64KB，换HTTP传输。 日志处理服务：接收日志，写入ClickHouse 这是某东的日志处理架构，也算是与时俱进了。