从无到有,我司CRM的演变史

来到现在这公司已经近5年,能拿得出手项目仅有CRM和消息网关。本篇文章主要讲CRM的演变史。

一、孽缘。

        15年12月21日来到公司,团队新组建,算我仅4人,最长到仅半年而已,当时公司购买了sugarcrm系统,创建模块确实很方便,但开发起来很困难,举个例子,当时的实施方做统计报表功能耗费了一个月的时间,丢过来的功能还无法使用。这让我们一时之间也无从下手,大家熟悉的框架也各不相同,有人熟悉tp、ci,有人laravel、yii,最大的问题是sugarcrm自动生成很多无用的表或者字段,让这帮以性能最优为天职的人无法忍受。

二、萌芽

         大概到了2016年1月的中下旬,产品经理(也是新人)要给sugarcrm加很复杂的功能,要求系统能筛选用户、创建活动、审批活动、消息发送。短短的16字需求包涵了很多的细节,比如说筛选用户。因为有很多的条件,需要把用户有关的属性打标签,累计和进行计算等。创建活动需要能任意组合短信、站内信、礼品卡发送,支持定时发送功能。发送需要支持多种消息同时发送,如果用户选择了礼品,必须先发送礼品,再发送短信,发送的结果必须要落盘,用以分析。这么多的功能,以目前对sugarcrm掌控程度,根本无法实现,大家商量决定写一套系统嵌入到sugarcrm,完成业务需求。从1月底到2月中旬(中间过年,找财务另了88元红包)主要就是两个任务,了解需求,对接需要的业务方和选择开发使用的框架。最终采纳龙龙(微博老司机、和鸟哥一起吃饭的人)提出的yaf作为开发框架。用户数据从大数据(新团队)获取。短信、站内信发送使用架构组接口,礼品发送使用用户组接口,其他功能自己开发。可笑的是,当时都尚未评定开发周期,运营直接一封邮件给了大boss,信中说到,4.1号上线。

三、破土

      知道运营报备上线时已经2.25号,测试团队评估近3周,留给开发提测的时间是3.11号。这里要介绍下组内人员了,Andy(组长,出身搜狐)帅帅(出身头条)龙龙(出身微博)。Andy负责服务器的安装及业务协调,龙龙负责yaf方面的环境搭建,我和帅帅负责业务梳理及表结构设计。这里也的提一个坑,其他组的人大部分是从某东过来的。用的是innodb引擎,用户主键是36位的串,这其实为以后的业务还是留了点坑,此处不细表。 

      需要的环境搭建完毕后,大家过了下整理的业务诉求,明白需求后,帅帅领了筛选、龙龙领了活动创建和审批活动、我领了消息发送。

      主要讲下筛选这块的实现方案吧。大数据团队新组建,所有的数据都灌到es中,让活动这块直接从es中取数据。初衷是好的。可以减少两方的交互,解耦。在测试环境数据量少,测试时功能可以实现,但并未覆盖海量数据的场景。不管怎样,从开始开发到正式上线这段期间内,我们几个人每天都是9点到单位晚上10点或者晚上12点之后才回去,周六日只歇一上午或者一下午在家洗洗衣服。那年3月我媳妇来北京开会,等到她住的地方已经快1点了。就这样每天喝着单位买的牛奶花生乳、晨光烧饼、大王家的酸辣汤艰难的熬着,这段痛苦的往事每每回忆起都是甜蜜的,记得帅帅在那段时间发了一个截图,上面写着“每天过需求进度,那个程序员都说进度正常,离上线还有3天时间,联系不上程序员了,在线求解决办法”。我们三个人总会调侃这个段子总会说“咱们还有大招,是时候放大招了”,直到现在这大招都未用过。就这样到了3.31号晚上准备上线,当把所有的功能运行了后,产品经理说大家可以回去了。大家并没有想象中的那种轻松,只是吃了几个串,收拾收拾打车回家。

      ps: 3月中旬谭总(出身腾讯)、然然总(出身360)相继加入了团队。

四、修剪

      上线之后,并没人使用,大概在4.15左右运营开始使用,发现了上面说的拉取数据的问题,由于都是通过http方式拉取数据,导致一个用户筛选大概要3-5个小时,有的甚至要一天才能完成一个筛选任务,这不是任何人想要的效果。因此大家决定改进数据拉取方式。谭总的出现解决了sugarcrm的js问题。然然总的出现解决了数据筛选的效率问题。具体方案如下:

      1、继续沿用原来的筛选条件表。把原来的交互做的更为流畅。

      2、与大数据同事沟通,数据改为推文件的方式从hive推到指定的某台服务器上。

      3、对当前的业务梳理,把数据拆分为66张表,同时增加了一张userId和int的类型转换表。

      4、66张表的设计全都做了优化,字段90%都是int类型。减少磁盘空间,提高了查询效率。

      5、对推过来的数据做解析,生成表需要的文件,采用load data infile 入库,这种方式极大提高了入库效率。

      6、把原来一条极为复杂的sql,拆分为几条简单的sql(谭总在前端用js已经处理好切割的标签),然后通过交、并、补的方式算出符合的人数。

      当这几个步骤完成之后,线上的运行已经飞一般的感觉。

五、施肥

      这种方式持续到了2016年12月份。运营提出来需要支持周期性活动。所谓周期,是把一段时间内的活动按照天的方式,每天动态生成活动、每天动态生成用户组。这个时段解决了消息发送效率不高的问题,从原来边发边入库到先发后入库。极大提高了效率。运营使用量的增加,我们也开始了筛选及结果的分表。2017.1.2日还拉着测试童姨加班测试,2017年1月5日上线用了一整夜,虽然中间有出问题,总算到天亮的时候上线完成。此后CRM已经成为了运营以及整个公司不可或缺的系统了。

六、风吹雨打

      经历了这些后,CRM也接入了push消息等。随着飞琦的加入,组内人员越来越壮大。系统承接的业务越来越多。筛目前已经有500多个纬度的指标了。随之而来的问题是,大数据推送的文件越来越大目前已经到了150G,系统可用的时间越来越晚,终于爆发了运营投诉技术的事。运营要求尽快推送,大数据表示现在业务越来越多,需要更多的机器,运维回复手中无多余机器使用。公司处于濒临倒闭的边缘。无采购打算。有点屋漏偏逢连夜雨的意思。

七、再度起航

      经过多方调节,同意采购5台机器给大数据,此外CRM决定把数据从mysql 迁移到clickhouse。这个方案也是然然总提出来的,不得不佩服然然总。之所以选clickhouse基于以下这几点考虑:

      1、列式存储

      2、多核cpu并行运行

      3、写入速度特别快,特别适合大批量数据写入。

      因此2019年10月。开始调研clickhouse的可行性,梳理这几年来筛选的任务及处理逻辑。到此时,随着业务的重新划分,人员的变动,CRM维护的人就我一个人了。为了对CRM的未来负责,决定采用java实现筛选。因此,从10月份调研,11月、12月程序开发,让大数据向mysql和clickhouse同时推送数据的同时,利用canal收集mysql的binlog同步运营的筛选条件,也开发了筛选对比的小工具。对相同条件的筛选结果比对,找出差异,经过3个月的对比,发现没有异常,4月份完成了线上切换。切到clickhouse后,筛选性能比原来提升了4-7倍。感谢期间付出努力的各位同事。

      至此,CRM的开发和优化已经完毕,虽然目前公司不是很景气,但不会因为这些原因停止演变。希望能有后续演变过程与您分享。        

  • 2
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值