石静猛 - 新一代通用增量计算等技术在降本增效上的实践.pdf

《石静猛 - 新一代通用增量计算等技术在降本增效上的实践.pdf》由会员分享，可在线阅读，更多相关《石静猛 - 新一代通用增量计算等技术在降本增效上的实践.pdf（29页珍藏版）》请在三个皮匠报告上搜索。

1、演讲嘉宾：石静猛新一代通用增量计算等技术在降本增效上的实践个人简介石静猛17年从业经验，大数据领域多年从业者2017年加入阿里巴巴的计算平台事业部工作，完整参与MaxCompute大数据产品的研发/生产/交付全流程工作，2022年加入云器科技，同样参与云器Lakehouse产品研发/生产/交付全流程，目前任云器科技有限公司的解决方案负责人01降本增效问题分析02降本增效最新技术实践（增量计算技术，Kappa架构，资源管理新模式，高性能引擎等）03大数据平台架构演进总结01降本增效问题分析“降本增效”依然是当前用户*最普遍*的关切之一 Total Cost of Ownership（TCO）=硬

2、件成本+软件成本+开发人员成本+维护人力成本+治理优化成本 Total Cost of Ownership（TCO）!=硬件成本 Total Cost of Ownership（TCO）硬件成本*3核心洞察：总拥有成本(TCO)远超硬件成本让我们分析一个客户案例！成本高企，效率低下的主要原因-平台落后1.Lambda1.Lambda架构是十年前创立的数据架构，目前已不先进架构是十年前创立的数据架构，目前已不先进存储层，数据湖和数据仓库尚未真正统一计算层，离线计算低实效性，实时计算高成本的矛盾组装式数据架构仍然复杂，异构存储及多套元数据，数据和计算资源冗余度高当下主流Lambda数据平台架构平台

3、能力发展落后于业务创新速度，成本问题愈发凸显。2.2.很多团队依然使用开源数据平台很多团队依然使用开源数据平台，碰到性能成本/优化天花板基于开源自建/二开不再先进，多组件间系统优化碰到瓶颈开源数据平台与主流商业平台差距巨大开源数据平台与主流商业平台差距巨大3.数据开发治理优化困难，造成数据使用低效，造成数据使用低效元数据分散，出问题难定位，运维效率低开发链路复杂，容易造成数据一致性问题，开发效率低组装式数据架构缺乏满足业务变化的灵活性，业务效率受影响“高成本、低效率”的典型场景场景场景场景解读场景解读场景一：场景一：实时加工成本高实时加工成本高（成本相关）（成本相关）数据量大、逻辑复杂，导致全

4、量实时加工成本过高（Flink）。通常只能实现部分指标实时只能实现部分指标实时，离线计算全量，维护两套逻辑需要手动天对齐。场景二：场景二：资源割裂，数据冗余资源割裂，数据冗余（成本相关）（成本相关）业务隔离导致“1+N”平台体系（1个离线+N个OLAP），查询层数据被分割在小的资源集群难以复用共享查询层数据被分割在小的资源集群难以复用共享，单个大作业仍能打满资源时查询稳定性差。场景三：场景三：多场景，多组件带来的开发效率低下多场景，多组件带来的开发效率低下（效率相关）（效率相关）新建业务时，数据需在多组件间导入导出，多种开发语言需要多个技术栈建设推高人力投入多种开发语言需要多个技术栈建设推高人

5、力投入场景四：场景四：引擎性能低，算不出来引擎性能低，算不出来（效率相关）（效率相关）数据规模巨大加工查询不能按时完成，分析数据需要预处理（如JSON提取、宽表构建），数据加工连贯数据加工连贯性造成割裂性造成割裂，平台人力资源投入人力资源投入成为业务瓶颈。Lambda 数据平台架构暴露“高成本、低效率”的四大典型场景02降本增效最新实践场景一：实时加工成本高-根源与解法1.资源常驻，缺乏弹性任务一旦启动，资源锁定，7x24小时不间断地运行，即使在业务低峰期也无法释放资源2.按峰配置，利用率低实时数据流的流量是波动的，为了确保在流量峰值时系统不出现堆积、不丢失数据，必须按照可能的最高峰值来配置资

6、源；这导致在大部分平常时段，资源利用率很低，造成了浪费。3.状态状态复杂复杂，内存消耗大，内存消耗大Flink是一个“状态化”的流处理器。维护状态（如窗口聚合、CEP模式、维表关联）需要大量内存4.运维复杂，成本转移运维复杂，成本转移庞大的状态数据不仅提升了内存与存储成本，更使得任务重启、扩缩容和数据恢复变得异常复杂，将直接的计算成本转化为高昂的运维管理成本短期解法：通过只处理关键指标、缩减窗口范围、引入外部KV存储等方式进行妥协。遗留问题：牺牲了业务精度，状态管理和运维依然复杂，资源浪费问题并未根本解决。核心追问：能否像管理离线任务一样来管理实时任务，并实现更低的成本？主流基于Flink 的