字节跳动流式数仓和实时分析服务的思考和实践

　　导读：字节跳动旗下有许多产品，每天有大量的数据需要接收和计算。其中，以抖音、头条等为代表的产品以实时推荐和流计算为核心，这些都需要消耗大量的计算资源和存储资源。巨大的数据量和快速准确的计算需求，给技术架构带来了巨大的挑战。
　　本次分享的主题为字节跳动流式数仓和实时服务分析的思考和实践，将围绕以下3点展开：字节跳动产品架构的业务困境流式数仓和实时服务分析的实践火山引擎云原生计算
　　01hr业务困境
　　1。字节内部场景分析
　　字节跳动（下称字节）旗下拥有今日头条、抖音等多款产品，每天服务着数亿用户，由此产生的数据量和计算量也非常大：EB级别海量的存储空间每天平均70PB数据的增量每秒钟百万次数的实时推荐请求超过400万核的流式计算资源、500万核的批式计算资源
　　在进行大数据分析的时候，对数据通常有两种处理方式：
　　1。描述已经发生过的数据，比如，过去发生了什么，为什么发生，通常采用批计算来处理；
　　2。描述正在发生的数据，比如，此时正在发生什么，将要发生什么，这些通常采用流计算来处理，也是今日头条、抖音等产品实时推荐的核心。
　　2。遇到的典型问题
　　如上图所示，字节内部对于数据的处理也分为两条链路：流计算链路和批计算链路。两条链路有着不同的存储以及数据处理方式，给整个架构带来了挑战：
　　1。数据和系统冗余，流批两套系统采用了两套技术栈，两套存储系统，在使用过程中需要分别维护，这使工程师运维和学习的成本非常高；
　　2。数据一致性和正确性问题，数据来自多个源头，采用了流批两种处理方式，处理逻辑不一样，代码不可复用，在ETL的计算过程中数据被反复引用，这些都可能使最终的业务数据发生变化，导致数据不一致；
　　3。Serving性能问题，有些业务的主要场景比较简单，但也需要消耗大量的资源，比如简单的点查，往往要求高QPS。如果采用传统大数据的方案，把主键拼起来，那么中间的结合是松耦合的，如果要同时达到高QPS，这种拼接方案在计算上和资源上的投资都会很大，性能问题也很严重。
　　针对上述困境，字节团队选择了流式数仓和实时服务分析融合的解决方案。
　　02hr流式数仓和实时服务分析实践
　　1。流数仓和服务数仓融合
　　字节通过实践将StreamingWarehouse流式数仓和实时服务分析进行融合，StreamingWarehouse做数据处理，实时服务分析做数据服务，两者结合可以解决三个问题：FlinkTableStore解决数据和系统冗余问题基于Flink流批一体，解决数据冗余性和正确性问题实时服务分析引擎优化解决服务性能问题
　　2。对流批一体的思考
　　在做流式数仓以及实时数仓的产品以前，字节内部的架构师一直在思考一个问题：流批一体的核心到底是什么？
　　最终团队认为，存储就是流批一体的核心，存储就是所有数据分析的基础。
　　如上图所示，流数据随着时间的推移不停地变化，没有边界，从数据库的角度来看，每次Binlog之后会有一定的存储写入到硬盘中做持久化，每一个Snapshot对应Binlog实时位点，这样整个Snapshot就是一个有边界的批式数据，像上图一样一个桶一个桶地放着，两者结合就是完整的流批一体。
　　Binlog和Snapshot两个加起来，在数据库中既能处理流数据也可以处理批数据，所以字节团队将Flink的TableStore技术作为了最核心的基础支撑。
　　3。FlinkTableStore
　　（1）全新的Flink内置存储
　　FlinkTableStore有以下特性：SnapshotLog满足所有实时UserCase存储易用，直接查询DFS
　　从FlinkTableStore的定位来看，FlinkTableStore有Snapshot，支持批处理，加上Log流，同时还提供统一的存储，可满足所有面向实时分析服务的UserCase。
　　其次，FlinkTableStore存储易用，可直接像DFS分布式文件系统或对象存储一样使用，这对整个效率的提升、存储成本和性能的平衡都有很大作用。
　　（2）存储结构
　　FlinkTableStore的存储结构包括两部分：依赖于流式的其他消息队列组件的LogQueue基于列存的分布式文件系统
　　两部分结合可以支持流读（StreamingReading）、批读（BatchReading）以及LookupJoin。
　　（3）流批一体
　　Flink有支持流批一体的特性，在读取方面，可以支持流读，可以读取LogChanges，也可以支持批读，读Snapshot，还可以对批流进行融合读取，Hybridread读，还可以支持点查。在写入方面，既可以支持持续地流式数据插入，也可以支持分区，支持Overwrite的批写。
　　整个底层跟数据服务是类似的，可以基于分布式文件系统，底层是无服务的状态，能做到计算和存储分离。同时，FlinkTableStore本身是基于列存的，也具备列存所具有的高性能的分析特性，比如压缩比。
　　（4）全面支持SQL
　　目前业界没有外部存储可以支持FlinkSQL的所有能力，要么不支持定义，要么不支持Change，或者不支持批写，也有的不支持Online查询，这会造成流式存储、读取、查询的困难。
　　FlinkTableStore可以全面支持FlinkSQL。通过FlinkTableStore存储后的数据，只要有这个业务逻辑，有主键可选，就能够进行任意的DDL定义，还支持所有的类型，如消息类型或DML。在此基础上，我们就可以把查询或定义做得更好。
　　（5）MergeTree
　　MergeTree是用于实时计算核心的内部基础，FlinkState，ClickHouse及HBase，包括HSAP，都是基于MergeTree的。MergeTree本身支持大量快速更新的能力，包括更新写增量文件，以及基于SortedFile按需Merge。
　　MergeTree还可以支持高效分析和点查，它的全局有序性可以做到很好地DataSkiping，提升检索、查询的效率。
　　根据这些特点，字节团队用FlinkTableStore搭建实时数仓和实时服务分析的底层根基，并在上面进行进一步优化。
　　（6）字节FlinkOLAP优化
　　FlinkOLAP能力是流数仓的核心之一，字节团队基于Flink构建了全新的OLAP引擎，已支持UserGrowth、电商、幸福里、飞书等业务，共11个集群6000CoreAP资源，每天Query50w。同时为了支持业务在使用FlinkOLAP的过程中查询Latency和QPS的需求，对Flink引擎架构和功能实现进行了大量深入优化，使业务查询性能提升50以上，节省了计算资源；在小规模数据量下，Flink复杂作业执行的QPS从10提高到100以上，简单作业执行的QPS从30提高到1000以上。
　　我们在优化字节内部FlinkOLAP能力的同时，正在跟社区合作，积极将相关优化回馈社区，在〔FLINK25318〕ImprovementofschedulerandexecutionforFlinkOLAP下创建了20多个子任务，有部分已经合并入主分支，剩余的也在设计和开发中，后续计划跟社区一起共同推进FlinkOLAP能力建设和完善。
　　4。实现数据流端到端一致性
　　在ETL过程中，同一份数据源会进行多次计算，一些ETL的结果数据在对用户提供查询分析服务的同时也作为数据源执行下一轮，这时就会产生三个一致性问题：数据源到ETLExactOnceETL写入单表ExactOnce多个中间表的关联一致性
　　如上文所提到，在没有FlinkTableStore和实现流批一体之前，计算分为流计算链路和批计算链路，两条链路有各自独立的计算集群和调度，数据有不同的入口和不同的处理方式，这种模式下做数据的端到端一致性挑战很大，成本非常高。
　　实现流批一体后，通过自动调度资源，自动调度流式链路的数据处理流程，把链路中的数据流程通过中间表的事务写入，保证中间数据链路的一致性。同时Flink的本身的ExactOnce特性也能保证在ETL中间过程的链路上一致性。
　　字节团队通过流批一体化解决了数据跟系统的数据冗余以及一致性的问题，在此基础上，我们进一步对性能进行了优化。
　　5。采用云原生和实时服务分析提升性能
　　（1）云原生架构
　　字节的产品基本都是基于云原生架构进行改造，基于容器化，在公共云上全托管的Serverless模式。
　　在这个模式下，上层的用户只需要关注业务应用和规划，下面的资源运维管理和调度分配由技术团队处理，用户使用门槛低，同时也避免业务深度介入运维管理。
　　同时，云原生基于存算分离，弹性很高，能够满足高效的横向扩展。像头条和抖音等产品，在晚上到睡觉之前，用户的使用需求很高，这个时候对实时计算性能要求也非常高，用户睡觉后，使用需求下降，此时对性能的要求相对较低，弹性就可以往下放，云原生的弹性优势在这个场景下得到了非常好的体现。
　　此外，团队还通过高效的分布式引擎来解决服务性能问题：多方式加速查询，通过SSD、RDMA、PMEM、内存等手段，提升查询及Shuffle效率物化视图满足数据预计算用C重写向量化引擎，提升整体效率
　　几个改变下来，可以满足像头条、抖音等产品实时的写入、更新、高并发要求以及数据的可视化，用户在产品内进行点击动作后就可以立即推送其关心或感兴趣的视频和新闻。
　　（2）实时服务分析引擎
　　字节团队研发了新一代面向大数据场景的实时服务分析系统，既能够满足用户高QPS，低Latency的在线Serving需求，也能满足用户对于海量数据的实时分析需求。
　　传统的OLAP分析模式实际上是静态的，在分析的时候需要预设好的视图或模型，海量分析时，通过预设的分析模型，分析出来的结果给到Serving对应的数据库，如HBase，Redis，MySQL，在这个过程中Serving跟分析是分离的。
　　同时字节团队在业务的决策过程中发现，用OLAP的用户对分析的要求实际上是不固定的，且与OLAP本身的现状不相符，用户需要的是灵活、不固定、按需的分析。
　　因此，我们对实时分析的服务引擎做了两点优化：
　　1。服务与分析整合，使分析和服务一体化
　　2。支持海量数据实时写入、实时更新、实时分析，支持标准SQL（兼容MySQL语法）
　　（3）实时服务分析引擎典型场景
　　字节内部在使用实时服务的典型场景主要是推荐类的特征分析，如推荐中用的机器学习特征，这类场景带来了新的挑战：数据实时可见数据需要实时写入，实时查询，用户需要数据实时可见数据写入吞吐大查询并发高（QPS百万级别），对于查询时延要求（毫秒级别）；用户特征明细数据庞大，任意时间窗口的在线聚合难以满足时延的需求当前没有一个系统能够满足用户所有需求，用户通常需要KVOLAPBatch来满足业务需求
　　对于这些挑战，字节团队做了两个优化：一是使用MV对明细数据进行聚合，二是通过脏读来满足用户对时效性的要求。
　　以上，是字节云原生部门的两个重点的产品，流式数仓和实时服务分析引擎。
　　03hr火山引擎云原生计算
　　火山引擎产品的特点是，基于字节内部业务孵化，经过了大规模的实践检验后才进行商业化，技术比较成熟，相比开源最大的特点是云原生化。
　　上图是火山引擎云原生计算的大数据解决方案，共由5部分组成。最中间部分是核心引擎，分别是：用于流式计算的ServerlessFlink用于批式计算的ServerlessSpark和Ray动态引擎用于存储的火山引擎自研的大数据统一存储CloudFS和Iceberg
　　上述引擎基于开源，但根据字节的业务特性进行了增强和加固。
　　上层是数据的开发和管理，项目和权限管理可以对每个地方进行细化的权限管理；此外还有元数据管理、作业开发、任务调度，及API服务，总的来说能够做到端到端的维护。
　　右侧的数据服务，右侧的数据服务，包括能够提供标准的消息队列、100兼容Kafka的BMQ，还有开放搜索引擎OpenSearch，及实时计算Flink到实时服务分析的数据服务。
　　最下层的资源和调度，提供云原生Operator对资源调度进行优化，还支持多云管理和混合部署，提升计算链路使用过程中的资源利用效率。
　　在业务流程上，从数据集成到数据分析，再到数据服务，云原生计算产品体系可以端到端地服务客户的整个流程。
　　总的来说，火山引擎云原生计算产品体系在云原生的基础上，提供了一站式的大数据管理平台，能够实现实时和离线计算合一，通过资源调度和数据开发管理，进行了整体的端到端的优化。
　　04hrQA环节
　　Q1：数据源做ETL写入到单表时ExactOnce的度怎么保证？
　　A1：采用了Flink的ExactOnce特性。
　　Q2：Starrocks的性能对比测试
　　A2：据了解目前没有过性能的对比测试，另外，字节内部的站内场景比较多，碰到的问题也比较多，我们是基于云原生改造的，所以在QPS上做得比较深的，这是我们跟开源不太一样的地方。
　　Q3：怎么样看待FlinkTableStore？
　　A3：FlinkTableStore在流批一体的场景下是有非常好的能力，目前字节内部使用的FlinkTableStore跟开源并行同步的。
　　今天的分享就到这里，谢谢大家。
　　分享嘉宾：汪建锋火山引擎技术专家
　　编辑整理：张玮
　　出品平台：DataFunTalk
　　01分享嘉宾
　　汪建锋火山引擎云原生实时数仓技术专家
　　火山引擎云原生实时数仓产品经理，拥有十多年大数据和AI相关产品和方案架构等工作，当前主要负责火山引擎云原生实时数据库产品的产品设计和商业化工作。
　　02关于我们
　　DataFun：专注于大数据、人工智能技术应用的分享与交流。发起于2017年，在北京、上海、深圳、杭州等城市举办超过100线下和100线上沙龙、论坛及峰会，已邀请超过2000位专家和学者参与分享。其公众号DataFunTalk累计生产原创文章800，百万阅读，15万精准粉丝。