企业建网站群,领硕网站seo优化,wordpress 执行sql,电子商务网站的建设及规划简介#xff1a; 加和科技CTO 王可攀#xff1a;技术是为业务价值而服务 王可攀 加和科技CTO
本文将基于加和科技大数据平台升级过程中面临的问题和挑战、如何调整数据平台架构以及调整后的变化#xff0c;为大家介绍数字营销行业大数据平台云原生升级实战经验。主要分为以…简介 加和科技CTO 王可攀技术是为业务价值而服务 王可攀 加和科技CTO
本文将基于加和科技大数据平台升级过程中面临的问题和挑战、如何调整数据平台架构以及调整后的变化为大家介绍数字营销行业大数据平台云原生升级实战经验。主要分为以下三个部分。
加和简介加和的大数据服务挑战加和大数据平台升级
一、加和简介
加和科技于2014年创立2015年搭建自己的技术服务整个的服务模式为品牌广告客户现在也涉及到主要有营销需求的客户提供营销的技术解决方案。
(1) 加和服务模式
以下是加和科技对接的媒体方和数据方。 加和服务模式是把所有的媒体流量形成一个管道当客户需要在不同的媒体之间做联合的控频比如说同一个用户在优酷上看到一个广告在爱奇艺上又看到一次广告客户希望用户只看到三次广告。加和科技可以做一个跨平台的管控同时客户希望有第三方的挑选和监控就和其他的服务商协作为客户提供一个广告的服务。
(2) 加和数据规模
加和科技数据量级增长的非常迅速最开始的时候流量可能还不如一个中小型的媒体上个月峰值达到800亿的请求。数据的复杂度也比较高每一个请求都带着相应的广告的信息每一个请求里面有近百个相关的维度需要处理。每天日均触达的达到5亿次全年上线的活动5000服务100品牌的客户。 二、加和的大数据服务挑战
(1) 服务场景的挑战
随着体量的增大遇到一些问题和痛点
一是数据量级大服务运算复杂。服务的量级很大这个量级每天都要去实时需要分析或者是查找。客户在一定的时间范围内做活动信息的归纳或者是跨媒体的去重的处理。
二是客户需求多变需求复杂度大。客户的需求也是多变的服务的客户分析的数据的维度非常多每一个媒体用户不同标签属性上去做拆分去重并不是统一化的需求所以需要在大数据的范围内对这些需求进行处理。
三是计算量起伏大峰值难以预估。随着客户的需求而走整个计算的量级起伏也会比较大。客户有一波紧急的投放会导致很多的媒体的流量都包下来导致在短期的流量峰值会非常高。如果客户这段时间没有下单量级也会相应的有些下降服务成本和能力之间需要一个弹性支持的。
四是服务保障要求高。从媒体到请求把信息发给第三方或者是流量监控的平台再回来最终把决策好要给用户产生什么样的素材整个过程在100毫秒之内完成要考虑多次的网络延时和计算的延时。如果产生一些数据的错误会对客户的服务造成很大的影响。
(2) 自建大数据架构
加和科技选择自建的服务平台数量级没那么大的时候选择了一款商用数据库去做整体的数据的支持。加和科技的服务体系一直在阿里云上面但是数据库选择了一个商用数据库。当时也是平衡人员成本和服务的性能的要求在复杂的分析的体系之下商用数据库的性能还是比自己搭建的集群要好很多而且相应的服务器成本也会更低。 当时的数据来源主要是从ECS获得的一些日志对数据实时性要求不高更多的是离线分析。所以一开始用的是把日志做压缩然后定时汇总到的数据集群去做处理的方式。再利用Kafka收集合作方的相关数据的信息整合到业务报表后给客户呈现。
历史数据是存在OSS 上面另外一个自研的BI 是用于展示对应的复杂数据报表结果支持一些自主自拖拽的分析。从成本考虑简化了数据分析的部分利用小时级别的这种离线数据再加上Redis 的缓存数据去做了在线统计的模块。
(3) 历史架构服务痛点
历史结构有很多痛点随着业务增长、数据量增长出现了越来越多的问题。
首先是计算弹性差。数据量不大的情况下商用数据群还是可以比较快的做一些扩缩容。负载越大越难扩展、 应对突发故障困难、增减资源耗时不可控整就会对业务造成拖累。如果出现服务器发生故障整体的业务就会产生很大的影响。
其次是数据管理很复杂。历经多年后形成了很多中间表数据难以划分、调控复杂度高、业务之间依赖高、 任务资源争抢中间的逻辑关系很难梳理的。在计算中又产生一些资源消耗就进一步加剧了对弹性的需求。
再次是特定场景效率低。服务的场景经常用到大规模的数据交集涉及对大量数据交集的查询。单一的数据引擎在某些场景下很快的但在一些特定场景下效率不高因为把数据都放在同样的集群里面去所以它的效率会受比较大的影响。
最后是计算消耗难以预估。这个从业务角度考量成本不可控、 计算任务难以和业务打通很难为客户提供一个标准化、可视化服务。
三、 加和大数据平台升级
(1) 升级后架构
调整最重要的环节在整个计算引擎的部分把数据搬迁到了MaxCompute的平台上面用DataWorks去做数据的调度和管理。 MaxCompute的使用带来了大幅的灵活性提升。
使用云环境扩缩容是比较方便的计算的资源和存储的资源都获得了保障。也可以把原来的数据表做更好的分区分表的管理可以看清楚这些数据怎样用在中间的关系是怎样的可以做更好的业务流程的管理。 在搬迁的时候MaxCompute不支持这种开源的调度后来是联合阿里云的一块开发最终支持调用MaxCompute的任务的方式。变化比较大的是自研的BI2.0模块之前的服务模块是自拖拽的一个产品发现有的客户不会拖拽这种方式也是难以接受的现在改善成自动生成报表服务。这个服务目前看起来可以让客户大幅用起来数据查询的数量会大幅的提升。
(2) 架构调整效果-数据方面
架构调整的效果最显著的是数据方面。首先是日均用户数量有很大量的提升从原来的每年的几百个实时的请求上升到几千个一部分的耗时很高的任务通过MaxCompute也得到了解决。以前部分高耗时任务等待时间非常长现在时间缩减5倍。以前整个资源的调整时间平均大概72小时左右现在可能都不到半小时的时间这是云带来的能力。 (3) 云原生大数据平台对加和的价值总结
最后做了架构调整之后带来的一些变化从几个角度来说
一是响应业务需求能力提升。业务需求服务能力大幅提升单次服务成本降低。业务成本可预估提升业务服务效率
二是服务稳定性和韧性提升。大幅降低资源调整耗时和难度、特定计算场景的耗时大幅下降
三是数据团队能力转型。一方面从业务运维转化为业务推动另一方面从数据分析转向机器学习
四是扩展新应用场景。流程自动化和任务管理自动化、技术栈和业务的服务的持续优化。 总体来说技术决策者我们并没有用到很多复杂的开源技术优化服务架构的时候更多的考量是我们的业务弹性和人员组成。作为技术决策者和技术从业者更多关注技术供应链依赖阿里云提供成熟的技术我们的团队得以专注于解决业务问题更多去灵活的组合市场上现有的技术然后快速地支撑我业务的发展。这样专业化分工专业的人做专业的事让我们的团队可以更好地为客户服务。
原文链接 本文为阿里云原创内容未经允许不得转载。
