前言:
之前的帖子中对自己的学科背景和学习动力等原因做了描述和铺垫,也对数据分析方法体系作了自己理解的归纳,现在看起来显得重要但也不重要,重要是指这些知识作为基础的不可或缺,不重要是指这些知识作为框架禁锢了思维。
(本文来自成都CDA就业班学员2018.9投稿)
1 职业发展篇
先聊聊2015年的事吧,参加培训之后我对自己的知识体系进行了重建和巩固,也在过程当中发现了很多有意思的事,这也成了之后选择工作时考虑的一个因素——数据量较大之后,处理的速度异常缓慢;因此,培训之后的第一站我进入了一家大数据公司,这里的大数据并不是伪命题的“大数据”,而是真正的大数据,百亿级存量数据,千万级增量,完善的Hadoop体系,在这里我接触到了轨迹数据、空间数据、个人隐私数据等等,也接触到了图数据库,Spark GraphX、Streaming、MLlib,Kettle...,在这样的环境中,充分运用到了各种大数据组件,也加强了自己Python+Mysql和Spark+Hive+Kafka技术栈的模型经验,既操作过百亿级数据的分析建模,也完成过六度人脉的图数据库检索和图引擎分析;言归正传,在公司呆了1年多之后,我选择了往技术管理岗转型,在经过了仔细斟酌之后,我选择了当时的风口,互联网金融行业,在2017年7月加入互联网金融公司,做起了风控团队的高级数据挖掘工程师、部门主管、部门经理助理,同时也兼任过数据产品经理、架构师,主要负责风控体系的完善和优化,在此期间,开始接触渠道分析、反欺诈模型、信用模型、授信模型、贷后监控和续贷营销,也是在这里完成了风控系统的多次迭代、营销系统CRM标签体系的建立、电销语音系统的完善...
2016-2017年:大数据分析师——大数据研发工程师——数据分析团队负责人
2017-2018年:高级数据挖掘工程师——AI研发中心主管——经理助理
2018-至今:风控副总裁
02 技术发展篇
职业发展中提到了一些所用到的工具,但仍然不够完善,这里我们就详细的聊聊这些东西;在我看来大数据公司一般分为几类:
数据存储和处理类:主要做底层数据的汇聚、存储和清洗,将非标和脏数据做标准化是这一类公司的主要工作,其中大部分的工作量会在运维、清洗和数仓模型,这一类公司也有的人称呼为计算平台或者运维平台或者基础平台类公司,当然云平台只是其中的一部分。
报告和可视化解决方案类:主要做数据可视化呈现和解决方案输出,用前端可配置的标准产品和报表作为公司的盈利手段。
产品与运营分析类:主要通过各类模型(数据模型和产品模型)分析和优化产品功能和运营成本,经常接触到的有场景建模产品(语音、图像识别、风控放款、精准营销)的公司就在这个范畴内。
精细化运营类:主要通过控制产品和用户的生命周期来实现最终盈利,这一类公司一般都有完善的用户生命周期体系,相比2、3类公司,这一类公司离客户更近,主要是2C端公司,他们的核心是用户运营体系而不是模型和分析的手段,比如游戏公司、社交平台等;当然,就如同一个公司的不同部门,一个人的不同涉猎范畴,各个类型的公司在技术上也会出现重叠,这也是公司综合实力的一种体现。
数据产品类:主要通过整合以上公司的技术和资源进行盈利,这一类公司所具有的核心竞争力是快速的定制化和业务梳理能力,通过咨询方案和软件外包切入,整合多家公司标准化产品后提供产品。
其他类:以上几类是经常接触到的大数据公司类型,除此之外还有一些创新商业模式形成的大数据公司。
在简单的将大数据公司进行分类之后,可以很明确的看到,我之前所工作过的公司是第一类和第三类,每一类公司的界定在于公司的业务基础和优势是在哪一个领域,比如,我所在的第一家公司的优势是基础平台的数据处理能力和运维能力,而数据可视化及模型和分析是在此基础上衍生的盈利点,也是公司发展的方向;我暂且将第一家公司和第二家公司称为A、B公司,在A公司这样的以数据基础平台作为优势的公司,能够快速上手的无非是数据基础平台所使用的各类组件的安装、调优和使用,Hadoop生态圈,如下图:
通常情况下,进入公司之后的第一件事都是具体着手某一个模块的工作,也就是说你是运维工程师的话,那么首先让你了解的肯定是我们有多少服务器,每一台服务器部署的组件和对应的IP,然后才是在此基础上如何管理和优化,如果你是数据分析师的话,首先需要了解的就是我们的数据都放在哪,是HBase、Hive还是Elasticsearch,然后如何进入如何操作,因此,作为大数据分析师的我,首先接触到的就是数据仓库,不同的数据仓库使用的操作语言在逻辑上大同小异,在语法上风格各异,在这里我主要使用的是SQL(这里不具体区分Mysql、Oracle和Hive)。
我需要做的就是按照需求取数并进行分析,每天的工作是从Xshell登陆到服务器,在shell界面输入Hive进入数仓进行查询和取数,根据业务需要分析数据,导出结果到HDFS…,在了解业务逻辑和数据字段的同时,我也在思考:这个HDFS是什么?我提交脚本的Yarn到底是什么?为什么偶尔会出现内存溢出的报错?为什么数据量大和数据量小的时候分析消耗的时间差不多?带着这些疑问,我在熟练中思考,在思考中进步;在逐渐熟悉业务的同时,我们接到了新的需求,需要对数据进行及时的检索反馈,同时也要进行预测功能的增加,那么,及时检索怎么实现呢?我们把数据从底层数据库通过kettle定时脚本将数据抽取到ES,这样,数据按照业务类型实现了少量数据的及时检索,但是不久之后问题又来了,随着数据量的增大,哪怕是ES集群进行索引分片之后仍然不能够进行稳定的及时检索,因此有了之后HBase+ES的二级索引,在此过程中,我也熟悉了ELK的使用;解决了及时查询的问题,那么接下来该解决预测问题了,当时能想到的办法是使用Mahout对文件系统的数据进行建模,依靠Mahout库提供的各类算法能够比较简单的实现预测建模,常见的分类、聚类、关联需求都能通过他来完成,但是随着预测需求的不断增加,逐渐发现每天的工作时间几乎都消耗在等着计算结果出来,这又有些尴尬了;在此期间,基于我们能够较好的完成离线数据的检索和建模,需求又进一步升级到了需要实时数据进行预警监控,有了之前的经验,我们很容易的就想到了flume+kafka+streaming这一套框架,因此,我们开始向spark去转换;在用上了spark之后,我们将Mahout上运行的算法用Spark MLlib进行替换,意外的发现,只要有大的内存,那么计算速度可以缩短到之前的十分之一,所以,我们义无反顾的改用了Spark,我也在私下恶补了Spark基于内存的DAG和MapReduce的区别。
之后,我成功的从大数据分析师转型到了大数据研发工程师,开始着手各类功能需求研发问题的对接和开发,当然,我也兼任了售前工程师;在一次聊天的过程中,业务方说到了有没有办法通过图数据结构将人与人、人与物、人与事件进行连接,替换目前繁杂的嵌套检索实现快速检索和简单修改,带着这个疑问,我了解了Spark GraphX和Neo4j,作为一个图引擎,GraphX的强项就是处理这种开放性的图算法问题,你可以通过自定义节点和边关系来实现复杂关系的连接,进而实现快速的图检索,但整个计算过程耗时很长,退而求其次,我开始思考使用Neo4j或者Titan来实现我简单的检索要求,最终,将清洗之后的节点和边按照主体要求和表头要求入库到Neo4j就简单实现了检索功能,也可以通过Neo4j提供的接口实现对图数据结果的交互,应用到其他需要的地方。
在结束了以上项目之后,我加入了互联网金融公司B,在B公司中,我的主要工作是迭代和优化风控相关模型,之后也近一步着手反欺诈、信用、授信、催收、客户评级、意愿预测、响应模型、图关系挖掘(标签传播)、推荐系统、智能语音项目等系统和算法的研发,以上的项目我就不一一举例了;B公司相较于A公司是一家典型的产品与运营分析类公司,所以,他的整个底层的效率可以说是很原始,多套系统产生的多个数据库,经常会有跨库取数的情况,在这里,最难的一件事不是建立一个好的模型并迭代优化它,而是如何缩短ETL的时间,当然这一切在建立了数据中心之后得到了解决;那么作为一个模型团队的负责人,我们还是回到模型上来,如何做一个好的模型,这个问题从流程上来说千篇一律,无非也是数据清洗、特征工程、模型选择、参数优化、模型部署和迭代,但我要说的是,作为一个数据挖掘工程师或者算法工程师,应该会的不仅仅只是如何对各个格式数据进行清洗、如何调用一个算法,重点应该落在业务需求的本身,应该落在对特征变量的理解,应该落在模型的落地上,其次还有如何快速的进行模型在不同场景的迁移;建模只是一种手段,不是最终的产品,对大部分需求来说,能进行简单分析达到业务目的的,绝对不会让你试了逻辑回归又试随机森林,试完随机森林再用用深度神经网络,对产品或者管理而言,需要看到的是结论,而不是过程,所以这也是需要数据挖掘工程师要有深厚沉淀的原因,换言之,你要具备用最快的速度得出最好解决方案的能力, 是的,这里我用的是解决方案,业务加上流程加上基于分析或者模型的解决方案,而不是一个干巴巴的模型,一个参数矩阵,因此,在我看来,数据挖掘工程师(算法工程师)相较于开发工程师来说,最大的区别是,能钻得进去,能跳得出来,一个优秀的数据工程师,能独立完成模型和算法,也能独立和开发对接各类接口;一个强悍的数据工程师,还能玩得了Xgboost和TensorFlow, 也写得了Axure和Xmind,当得了项目管理,也编得来架构文档;这也是为什么数据工程师比开发工程师贵的原因。所以,如果你从业时间已经不短,但是还在满足于目前场景里的模型效果不错,有那么一些IV很高的变量,有那么一个KS很高的pkl,那么,你可能已经落后了。
在B公司,我通过优化和迭代反欺诈、信用、授信、催收模型加强了Python、Mysql、Redis的了解和使用,尝试过用逻辑回归、随机森林、GBDT、Xgboost、lightGBM等算法优化模型,争执过target的选择,也使用过各类加减乘除指幂导数来构造特征,在构造的两千多个特征中,也使用过L1、L2正则化、随机森林和神经网络算法去筛选特征,在清洗数据的时候也遇到过到底应该保留补全还是drop掉这个维度,到底需不需要将类别变量进行编码的问题;通过客户评级、意愿预测、响应模型、推荐系统加强了Spark ML、MLlib、Hive、HBase、Kafka的使用,很多意愿和响应模型所用的特征都是基于用户访问轨迹的数据,我们通过页面埋点的方式实施收集用户访问数据,将监听的数据推到Kafka中,Kafka再将数据推给Streaming,通过设置offset来消费Kafka的数据,在这个过程中,我们完成数据清洗,通过Dstream对应的RDD来调用MLlib 进行模型预测,将ETL结果写入HBase,将模型结果写入Hive;通过图关系挖掘(标签传播)练习了Spark GraphX和Neo4j的使用。在各个项目过程中,从一开始只关注模型的效果,逐步开始了解业务的场景,比如:欺诈模型是为了预测可能逾期的样本cut段,而信用模型是为了挽回更多的优质客户增加用户的通过量;从业务场景中催生了规则加模型的风控模式,从续贷营销催生了召回业务模式,从图挖掘催生了信修和潜在客户挖掘模式,这些模式都建立在对业务流程熟悉的基础上;因为当时公司没有专职的数据产品经理,所以作为团队的负责人,义不容辞的根据业务的需要和技术的发展设计和落地产品也成了我们份内的工作,作为一个兼职的数据产品经理,我的心得是必须懂开发、懂业务、懂项目管理才能做一个不挨怼的数据产品经理,至少需要做到每一个功能的输入和输出你要明明白白,每一个流程是否切合业务逻辑你要清清楚楚,天马行空的想法,需要但是适可而止。在之后的智能语音机器人项目中又陆续接触了ASR、NLU、DMS、TTS等模块的开发和算法工作,快速学习和落地了NLP相关的各类分词、纠错和检索,当然,能快速的落地产品还是得归功于团队小伙伴们的给力。在整个智能语音项目中,团队从一开始的一无所知到最终达到95%以上的召回率,这一过程让我相信,模型和算法是相通的,重要的是算法的思维和逻辑,还有一颗你对算法热爱的心。
03 案例分享篇
有人说,没有一个成功的落地案例的数据工程师不是一个好的数据科学家,那么,案例分享必不可少,下面会简单分享一个落地案例。
这是一个基于数据中心做精准营销的项目,整个逻辑并不复杂,业务部门需要对存量和增量客户打上标签并进行规则过滤和用户意愿及响应度预测,并通过外呼系统进行触客,实时返回用户意愿,并对标签库进行迭代。
整个数据的采集通过数据库binlog和flume实现采集(埋点、外呼日志、业务数据),将日志数据推到Kafka,另外一部分三方数据和基本数据会在清洗后存入Hive或HBase,其中,进入Hive的数据是按照业务报表需求清洗之后的报表基础表,之后通过Kylin实现逻辑交叉,并在Superset呈现结果。HBase中的结果是核心的标签数据,通过HBase的rowkey唯一标识用户ID&标签ID字段,通过对增量数据进行计算后进行合并,存储在HBase中,在Spark中使用SQL和MLlib对标签的DF结构进行计算和预测,结果存储在Redis中通过API接口向应用层输出。其中,ELK对日志数据进行及时检索,Ganglia监控整个集群的运行状况。通过以上的步骤可以实现对用户日志和标签结果的检索,对用户意愿和响应度进行预测,以及通过api传参控制规则过滤筛选。
整个过程并不复杂,但细节的工作是巨大的,比如:底层数据的采集协调、数据的存储方式和结构、Topic的定义、Rowkey的定义、增量数据的合并算法、报表Cube的配置、模型使用的字段和offset的合理设置、后端调用传参的实时性和准确性以及并发等等。
除了对数据流的架构和应用的架构,如何合理的安排人员,提高工作的效率也是一个大的问题,最后,项目的管理和计划就应该提上日程了。在整个流程跑通之后,功能测试、模块测试、系统测试也会需要随时对算法对接口进行优化。
注:整个过程中并没有涉及到具体算法的实现和开发架构,但不代表算法实现和开发架构不重要。
04 总结
以上是我对三年工作的一些心得和体会,希望像3年前为入门者解惑的帖子一样,今天也能为众多在数据领域拼搏而又迷茫的人举一个亲身经历的例子供大家参考。
附上自己2015年9月发的第一张帖:https://bbs.pinggu.org/thread-3918504-1-1.html
=====================分割线=====================
顺
附带宣传:如何零基础入门数据分析岗位?| CDA数据分析就业班60期火热报名中