简介：加和科技 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) 云原生大数据平台对加和的价值总结
最初，做了架构调整之后带来的一些变动，从几个角度来说：
一是响应业务需要能力晋升。业务需要服务能力大幅晋升，单次服务老本升高。业务老本可预估，晋升业务服务效率；
二是服务稳定性和韧性晋升。大幅升高资源调整耗时和难度、特定计算场景的耗时大幅降落；
三是数据团队能力转型。一方面从业务运维转化为业务推动，另一方面从数据分析转向机器学习；
四是扩大新利用场景。流程自动化和工作治理自动化、技术栈和业务的服务的继续优化。
总体来说，技术决策者，咱们并没有用到很多简单的开源技术，优化服务架构的时候，更多的考量是咱们的业务弹性，和人员组成。作为技术决策者和技术从业者，更多关注技术供应链，依赖阿里云提供成熟的技术，咱们的团队得以专一于解决业务问题，更多去灵便的组合市场上现有的技术，而后疾速地撑持我业务的倒退。这样专业化分工，业余的人做业余的事，让咱们的团队能够更好地为客户服务。
原文链接
本文为阿里云原创内容，未经容许不得转载。