四个多月的时间里，数据产品带给了我什么（中）
我不会是这样一个人，做不成，死不甘。我觉得我有必要站出来了，把这个数据产品拯救起来，完成自己以前的一个梦想。
力拔山兮气盖世，时不利兮骓不逝。骓不逝兮可奈何？虞兮虞兮奈若何。
楚汉后期，项羽趋于败局，于公元前202年，被汉军围困垓下。酌酒悲歌：“力拔山兮气盖世，时不利兮骓不逝。骓不逝兮可奈何?虞兮虞兮奈若何。”，当时的我，也一度不知所措。原以为事情会开展得很顺利，众人拾柴火焰高，但却没想到掉进了坑里，差点没能爬出来。
说明：一些朋友问起我，“做项目都挺累了，你还坚持写文章，很佩服啊”。其实不管做什么事，能够让你坚持下去的，除了兴趣，还有决心。一方面，我喜爱看故事，体验真实和幻想之间，感染情绪，参与到故事中去思考，所以我乐意尝试着写文章；另一方面，我希望大数据圈子的朋友能够脚踏实地做事，带动这个领域的发展，能够从小事做起，不卖弄玄虚，做实事。
七、招兵买马、运筹帷幄
8月上旬，领导找到我，打算组建开发小组，趁热打铁地开始做。
就像大多数公司的大数据部门一样，各个岗位的人员配置都不是很健全，不是缺前端，就是缺产品经理，再或者缺Java Web工程师，甚至是数据挖掘工程师——大数据的价值还未体现，公司也舍不得大成本投入。总之很难凑齐一桌人，专注在开发某条大数据产品线里。
在当时，对于我，也都是身兼数据产品经理和数据挖掘工程师两个角色。其实我们小组在大数据这块，人员搭配还算健康的，一个集群运维，江湖外号：荀攸;一个Spark Streaming开发，江湖外号：周瑜;一个我，都是能够做实事的人，这点很好。
我认为三个人对接一条产品线足够了。但是比较急缺的是Java这块的后端和Web开发。没办法，经过协商，综合考虑项目紧急程度和难易程度。找到了跨部门的一个Java高级开发人员，江湖外号：影帝。
四个人，确定OK以后，我心里还是挺有底气。对接的Java高级开发人员——影帝，在我们四人里年龄最大。所以我想由他推动着产品的后端开发，贯穿流式计算、业务模型和Java前后端开发三个板块。——这个决定也为以后埋下了隐患。
叫上领导，找个小黑屋，整个讨论分了两个部门：产品讲解和工作安排。我先和大家讲述下产品的细节问题，主要有以下三点：
- 产品的开发是为了解决什么业务痛点问题？
- 产品的后端功能模块，以及数据驱动形式，以及数据流向？
- 每个版块对接的形式，在业务面上，整个反欺诈监控要达到的效果？
对于产品的介绍，总结起来就三个点：
- 产品做什么事？
- 产品有哪些功能模块？
- 产品要在业务面上实现什么效果？
当时在我说完这些内容以后，效果并不是很好，给出的反馈主要有这几点：
- 对于产品要开发的模样，心里没有个框架；
- 对于产品解决的问题，做出来的价值，持质疑态度；
- 对于产品的实际功能开发，短时间内不够明确。
我对于大家的这些疑惑，还是可以理解的。一方面，数据产品在大多数人心目中，因为没有接触过，接触得少，所以没有一个轮廓的样子，堪比盲人摸象。一方面，我深信在开发启动以后，伴随着大家的相互沟通和碰撞，很多细节都会慢慢明白。——这个想法埋下了第二个隐患。
在大家懵的状态中，我们也大致确定了后端开发的任务分工，不管如何，先干起来。
Spark流式这块，由周瑜对接其他部门——移动端和PC端，首先把水龙头的水源接入进来，整合app、pc和wap三个大渠道关键事件的埋点数据；
业务模型这块，由我负责整个业务数据，第三方数据和行为数据的整合，确定整个反欺诈监控产品中四个模型开发，以及产品涉及业务层面上的梳理和数据同步。
集群运维这块，由荀攸负责子功能上线的发布管理，任务监控调度和预警，以及跨集群数据的迁移。
Java前后端，由影帝负责系统后端数据校验流程的开发和前台页面表数据的联调。
这次小黑屋的讨论，虽然大家都是云里雾里的，但是至少都责任分工了，算是完成了开发前期的任务。
八、业务场景模型开发
很多朋友都是在做数据挖掘，或者在学习数据挖掘。我觉得这个版块对你们会更有实用性。
毕竟后端每个大的功能模块工作量都很大，我当时也基本在专注开发业务模型这个版块，对产品整个全局进度和业务功能的把控都忽视了，着实是因为缺乏经验造成的。
8月中下旬，我着手开发业务场景模型，还是会有一定的挑战，业务上和数据来源上，基本都是一知半解。
好在我以往做ETL这块的经验——服务于一款类阿里指数后端所有业务数据的支撑，除了使用工具本身的技能上，更多在于快速掌握数据源和业务逻辑的学习能力。我当时对于一个新的业务领域，做了下面的这些工作：
对接BI数据仓库的工程师，从他们已有的定时报表里，去熟悉目前平台常用的业务指标和逻辑计算方式，更重要的是数据来源都依赖哪些业务报表。
对接运营部门，高级数据分析师，从他们日常运营工作中，去知晓分析反欺诈用户都会考虑的业务场景，以及用户核心特征，对场景细分和用户细分更有把握，确定整个反欺诈系统业务层面上需要考虑的功能细节。
对接集群运维工程师，确定传统数据库与大数据集群对接的数据形式，数据存放位置，跨集群(阿里云和公司服务器)的数据分布，以及集群资源调度的任务量和时间点，把握业务报表跑P的依赖性。
我相信身边的很多事，都有规律可循，正确的解决思路是任何人都应该学会的，这一方面会让你轻松愉快的工作，一方面会让你高效。
当初的我花了大部分时间在业务把控，数据清洗的这个阶段。有了这些准备，就开始ETL处理各种模型特征数据，大部分的工作都可以使用Hive来解决，但是我这里给用这个工具的朋友们说一句——正确，谨慎用好这个工具。
当初我去面试过程中——在大数据圈子里基本都会问Hive相关的知识，遇到一个面试官(做线上培训，估计不少人都听过他讲的大数据相关的课程)，他回答了我几个有意思的问题：
- hive执行过程中，mapreduce阶段shuffle的过程；
- hive的数据倾斜有哪些场景，有哪些解决思路？
- hive的优化策略有哪些？
我都给了一一回复，他是这样肯定我的回答：“我面试这么多人里面，你是回答最好的一个”。其实这并没什么，真正实地在项目中用得多，很多细节你都会注意到。但是也侧面反映出了现阶段，一大部分从业者对这个工具的忽视，我认为会遇到很大的问题：
- 从必要性来说 ，大部分数据清洗加工都会采用hive，除少数会使用mapreduce，而我现在都转换成写scala去处理——简单、高效。所以做大数据，数据挖掘的人，这个工具必须得会。
- 从数据安全性来说 ，你在集群数据仓库的每一个hql操作，都是极其危险的，细心再细心，删表删库的行为，后果很严重——我曾经的有个同事就掉了一次坑。不知可以学，但是做事要警惕。
- 从资源分配来说 ，很多自私的行为，不仅生活中会体现，工作中也会有反映。写的这么不正确的hql，单纯查询还好，如果每天大量不正确的hql去跑P，整个集群资源都被耗光，拖垮整个平台的任务。
这里花了一些时间说了下，希望引起更多大数据初入门从业者的注意，既然要做数据挖掘，这些是必不可少要掌握的。
准备好一切，准备开发四个业务场景模型了，整个开发模式都是基于Spark去写的模型，我曾经说过：“一个业务模型，不代表一个算法，它是由一些组合算法和业务逻辑规则去构建起来的。”，说白了，业务场景要细分，一味放在一个场景去构建模型，效果会极差。
这也回答了一些朋友的疑问，为什么不用spark原生依赖的包，于我而言，目前没这个必要，当然，有需要，我也会调用，重构底层的一些算法源码。
至于如何去搭建一套大数据挖掘的单机版框架，我在以前文章有写到，地址。毕竟大部分人都是使用python，或者R。别的不说，如果要做数据产品，不懂MapReduce，或者Spark的，最好去学习下，要做大数据，最不能缺的就是学习能力——这也是我很少讲实际技术的一个原因，知道方向，还得靠自己去学。
整个系统在模型这块，主要体现有四个：
- 一个服务于风险库，有监督性学习去寻找更多风险用户。
- 一个服务于充值事件，判别用户是不是羊毛党。
- 一个服务于投资事件，评估用户在平台的风险度。
- 一个服务于体现事件，确定用户属于哪种类别的羊毛党。（用户细分)
整个模型运作的方式，目前由于资源有限，并没有采取实时的方式，主要体现有：
- 离线跑P，每天凌晨启动
- 准实时学习，增量训练模型结果
当时做这套，花了不少时间，基本都是专注在开发，9月初基本上线发布了。但也忽视了整个项目的进度，以及其他同事开发遇到的细节。——缺乏经验。
九、难产
很多事，在开头就为以后的不幸埋下了隐患。
在我上线发布完业务模型这个功能模块以后，我先找到了周瑜——Spark流式这块，确定下他那边跨部门对接的进度和交接时间点，说白了，我这边准备整合所有渠道的数据源，以及用户业务数据，都考虑进模型特征里面。
第一个坑：水龙头里面的水迟迟到不了
毕竟是跨部门的对接，周瑜和我由于前期缺乏沟通，导致了业务方向做错了，他在和跨部门的其他同事对接过程中，误以为优先开发借款端的埋点数据，所以导致理财端这块仍然没有开发出来。
而且比较致命的是，别的部门重新埋点开发理财端数据，还需要大量时间，再加上ios板块的发布，审核也需要一定时间。——后面迟迟推到10月中旬才正式接入理财数据
当时懵了，数据接入不进来。一方面，我那边模型缺少很多真实设备和网络信息，而且新增的设备指纹算法也和以往有差别。一方面，周瑜这边也验证不了代码的效率，更别提数据传输过程中的稳定性。
第二个坑：java前后端整个框架还很粗糙，完全不具备贯穿每个功能板块的条件
影帝毕竟是请的外援，别人也会忙自己分内的其他工作，依靠别人去推动产品的开发，显然是不切合实际的，别人能把分配的功能按时做完已经是够不错，做得耦合度达标更是谢天谢地。
这个坑摔得有些痛，只怪当初把事想得太简单了，自己也没能担负起这个项目的主导线。
这么说来，除了业务模型这块的功能，其他两个大功能点基本还属于待开发阶段。
第三个坑：前端页面没有人做
当初由于缺乏前端工程师和UED，是采取对接其他部门的同事，协调一起开发。
还是一个原因，缺乏沟通和项目进度把控。造成前端页面这块的对接存在两个问题：
- 页面开发的优先级不明确，导致他们不知道那些是第一个阶段会上线的页面；
- 页面设计和开发效率极慢，他们并发忙的事很多，导致我们的项目页面大部分未开发。
这个结果导致整个产品目前只能优先完成后端功能，把服务联调起来，至于页面交互，遥遥无期。
总结起来，种种掉进去的坑，都是刚开始埋下的隐患。每个坑都可能导致项目停止开发，以前的一切努力化为尘埃。我梳理了下，主要有这几个原因，按严重性罗列：
- 缺乏推动项目，把控业务功能和风险的核心角色出现。
- 还未区分开做任务与带项目的差异性，团队意识才是保证项目健康的关键。
- 缺乏沟通，部门内与跨部门，埋头苦干。降低沟通成本，导致的只有埋下无数个坑。
曾经那段时间，领导也不太关心项目发展的进度了，他似乎感觉到，从无到有，做一款数据产品的困难。也更多的把心思放在其他不这么空白的项目上，毕竟快到年底了，每个部门都想为创新项目去争一争。
十、涅槃重生
难产有了一周的时间，项目找的外援——影帝，也逐渐想脱身去忙他主导负责的项目，事情的发展，好像趋近于灭亡。
为了弥补java前后端开发这块的空白，我特意向领导申请了，让部门里的一个java开发同事加入进来，逐渐接手影帝以前做的任务。领导思考了下，有些无奈的同意了。就这样，我迎来了队伍里的新伙伴，江湖人称：幻影。……一切显得又是这样苍白无力。
但是，转折好像来了。
幻影从我到公司这段时间，基本上都是同我一起下班，毕竟路线一致，大家聊得也多，老家在湖南，离我老家也很近。
他加入项目小组的那天晚上，我们仍然一同下班，当时算挺晚了，路上行人稀稀疏疏。
刚坐上地铁没多久，他就找我说话，咨询下项目目前的进度，也表达了一些他个人的看法。记得是这样说的：“这个项目对于你来说，挺关键的(我懂他的意思)。但是基本上没有人去主导，毕竟也是因为没做过，所以别人也不好带头。这事，我觉得你要趁早站出来了，毕竟这个产品对你很关键，否则根本做不下去的。”
我想了也是，的确说得挺对的。
后面他又说了一句：“我现在做的事也杂，基本都是属于虾兵蟹将，同时在做很多事，要不你和领导说下，再拉个java进来一起做，或者换个人”
我白了他一眼，“你这是彻底抛弃我啊”
后面他提前下车了，我剩下的路上，回家以后，也想了很久。一方面，有种未知感，毕竟跨行如隔山。一方面，心有不甘，现在有这样一个机会做有自己特色的数据产品，我却不能把握住。
……
我不会是这样一个人，做不成，死不甘。我觉得我有必要站出来了，把这个数据产品拯救起来，完成自己以前的一个梦想。
当晚上，顷刻间有些兴奋，也冷静总结了以往犯过的错误，找到隐患出现的各种细节，想到对应的方法去填上已经有的坑。
不管结果如何，我都要去拼一把，不为别的，只为了对得起当初的一个情怀。……事实证明，老天还是眷顾努力的人，在10月18号，我们正式发布了一个版本。截止目前11月15号，已经迭代更新了好多版本，也在开发着第二阶段，原来一同并发做同一个产品的其他部门，也即将合并一起更完善我们目前做的数据产品。我也很自信和运营的很多部门领导和同事，介绍着产品的每一个细节，以及对接业务场景的一些方式。
后续期待……
作者：汪榕
关键字：产品经理, 开发
版权声明
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！
