上篇请戳这里~~
说明：一些朋友问起我，“做项目都挺累了，你还坚持写文章，很佩服啊”。其实不管做什么事，能够让你坚持下去的，除了兴趣，还有决心。一方面，我喜爱看故事，体验真实和幻想之间，感染情绪，参与到故事中去思考，所以我乐意尝试着写文章。一方面，我希望大数据圈子的朋友能够脚踏实地做事，带动这个领域的发展，能够从小事做起，不卖弄玄虚，做实事。 七、招兵买马、运筹帷幄8月上旬，领导找到我，打算组建开发小组，趁热打铁的开始做。 就像大多数公司的大数据部门一样，各个岗位的人员配置都不是很健全，不是缺前端，就是缺产品经理，再或者缺Java Web工程师，甚至是数据挖掘工程师——大数据的价值还未体现，公司也舍不得大成本投入。总之很难凑齐一桌人，专注在开发某条大数据产品线里。 在当时，对于我，也都是身兼数据产品经理和数据挖掘工程师两个角色。其实我们小组在大数据这块，人员搭配还算健康的，一个集群运维，江湖外号：荀攸；一个Spark Streaming开发，江湖外号：周瑜；一个我，都是能够做实事的人，这点很好。 我认为三个人对接一条产品线足够了。但是比较急缺的是Java这块的后端和Web开发。没办法，经过协商，综合考虑项目紧急程度和难易程度。找到了跨部门的一个Java高级开发人员，江湖外号：影帝。 四个人，确定OK以后，我心里还是挺有底气。对接的Java高级开发人员——影帝，在我们四人里年龄最大。所以我想由他推动着产品的后端开发，贯穿流式计算、业务模型和Java前后端开发三个板块。——这个决定也为以后埋下了隐患。 叫上领导，找个小黑屋，整个讨论分了两个部门：产品讲解和工作安排。我先和大家讲述下产品的细节问题，主要有以下三点：
对于产品的介绍，总结起来就三个点，1.产品做什么事？2.产品有哪些功能模块？3.产品要在业务面上实现什么效果？ 当时在我说完这些内容以后，效果并不是很好，给出的反馈主要有这几点：
我对于大家的这些疑惑，还是可以理解的。一方面，数据产品在大多数人心目中，因为没有接触过，接触得少，所以没有一个轮廓的样子，堪比盲人摸象。一方面，我深信在开发启动以后，伴随着大家的相互沟通和碰撞，很多细节都会慢慢明白。——这个想法埋下了第二个隐患。 在大家懵的状态中，我们也大致确定了后端开发的任务分工，不管如何，先干起来。
这次小黑屋的讨论，虽然大家都是云里雾里的，但是至少都责任分工了，算是完成了开发前期的任务。 八、业务场景模型开发很多朋友都是在做数据挖掘，或者在学习数据挖掘。我觉得这个版块对你们会更有实用性。 毕竟后端每个大的功能模块工作量都很大，我当时也基本在专注开发业务模型这个版块，对产品整个全局进度和业务功能的把控都忽视了，着实是因为缺乏经验造成的。 8月中下旬，我着手开发业务场景模型，还是会有一定的挑战，业务上和数据来源上，基本都是一知半解。 好在我以往做ETL这块的经验——服务于一款类阿里指数后端所有业务数据的支撑，除了使用工具本身的技能上，更多在于快速掌握数据源和业务逻辑的学习能力。我当时对于一个新的业务领域，做了下面的这些工作：
我相信身边的很多事，都有规律可循，正确的解决思路是任何人都应该学会的，这一方面会让你轻松愉快的工作，一方面会让你高效。 当初的我花了大部分时间在业务把控，数据清洗的这个阶段。有了这些准备，就开始ETL处理各种模型特征数据，大部分的工作都可以使用Hive来解决，但是我这里给用这个工具的朋友们说一句——正确，谨慎用好这个工具。 当初我去面试过程中——在大数据圈子里基本都会问Hive相关的知识，遇到一个面试官（做线上培训，估计不少人都听过他讲的大数据相关的课程），他回答了我几个有意思的问题：
我都给了一一回复，他是这样肯定我的回答：“我面试这么多人里面，你是回答最好的一个”。其实这并没什么，真正实地在项目中用得多，很多细节你都会注意到。但是也侧面反映出了现阶段，一大部分从业者对这个工具的忽视，我认为会遇到很大的问题：
这里花了一些时间说了下，希望引起更多大数据初入门从业者的注意，既然要做数据挖掘，这些是必不可少要掌握的。 准备好一切，准备开发四个业务场景模型了，整个开发模式都是基于Spark去写的模型，我曾经说过：“一个业务模型，不代表一个算法，它是由一些组合算法和业务逻辑规则去构建起来的。”，说白了，业务场景要细分，一味放在一个场景去构建模型，效果会极差。 这也回答了一些朋友的疑问，为什么不用spark原生依赖的包，于我而言，目前没这个必要，当然，有需要，我也会调用，重构底层的一些算法源码。 至于如何去搭建一套大数据挖掘的单机版框架，我在以前文章有写到，地址。毕竟大部分人都是使用python，或者R。别的不说，如果要做数据产品，不懂MapReduce，或者Spark的，最好去学习下，要做大数据，最不能缺的就是学习能力——这也是我很少讲实际技术的一个原因，知道方向，还得靠自己去学。 整个系统在模型这块，主要体现有四个：
整个模型运作的方式，目前由于资源有限，并没有采取实时的方式，主要体现有：
当时做这套，花了不少时间，基本都是专注在开发，9月初基本上线发布了。但也忽视了整个项目的进度，以及其他同事开发遇到的细节。——缺乏经验。 九、难产很多事，在开头就为以后的不幸埋下了隐患。 在我上线发布完业务模型这个功能模块以后，我先找到了周瑜——Spark流式这块，确定下他那边跨部门对接的进度和交接时间点，说白了，我这边准备整合所有渠道的数据源，以及用户业务数据，都考虑进模型特征里面。
毕竟是跨部门的对接，周瑜和我由于前期缺乏沟通，导致了业务方向做错了，他在和跨部门的其他同事对接过程中，误以为优先开发借款端的埋点数据，所以导致理财端这块仍然没有开发出来。 而且比较致命的是，别的部门重新埋点开发理财端数据，还需要大量时间，再加上ios板块的发布，审核也需要一定时间。——后面迟迟推到10月中旬才正式接入理财数据 当时懵了，数据接入不进来。一方面，我那边模型缺少很多真实设备和网络信息，而且新增的设备指纹算法也和以往有差别。一方面，周瑜这边也验证不了代码的效率，更别提数据传输过程中的稳定性。
影帝毕竟是请的外援，别人也会忙自己分内的其他工作，依靠别人去推动产品的开发，显然是不切合实际的，别人能把分配的功能按时做完已经是够不错，做得耦合度达标更是谢天谢地。 这个坑摔得有些痛，只怪当初把事想得太简单了，自己也没能担负起这个项目的主导线。 这么说来，除了业务模型这块的功能，其他两个大功能点基本还属于待开发阶段。
当初由于缺乏前端工程师和UED，是采取对接其他部门的同事，协调一起开发。 还是一个原因，缺乏沟通和项目进度把控。造成前端页面这块的对接存在两个问题：
这个结果导致整个产品目前只能优先完成后端功能，把服务联调起来，至于页面交互，遥遥无期。 总结起来，种种掉进去的坑，都是刚开始埋下的隐患。每个坑都可能导致项目停止开发，以前的一切努力化为尘埃。我梳理了下，主要有这几个原因，按严重性罗列：
曾经那段时间，领导也不太关心项目发展的进度了，他似乎感觉到，从无到有，做一款数据产品的困难。也更多的把心思放在其他不这么空白的项目上，毕竟快到年底了，每个部门都想为创新项目去争一争。 十、涅槃重生难产有了一周的时间，项目找的外援——影帝，也逐渐想脱身去忙他主导负责的项目，事情的发展，好像趋近于灭亡。 为了弥补java前后端开发这块的空白，我特意向领导申请了，让部门里的一个java开发同事加入进来，逐渐接手影帝以前做的任务。领导思考了下，有些无奈的同意了。就这样，我迎来了队伍里的新伙伴，江湖人称：幻影。......一切显得又是这样苍白无力。 但是，转折好像来了。 幻影从我到公司这段时间，基本上都是同我一起下班，毕竟路线一致，大家聊得也多，老家在湖南，离我老家也很近。 他加入项目小组的那天晚上，我们仍然一同下班，当时算挺晚了，路上行人稀稀疏疏。 刚坐上地铁没多久，他就找我说话，咨询下项目目前的进度，也表达了一些他个人的看法。记得是这样说的：“这个项目对于你来说，挺关键的（我懂他的意思）。但是基本上没有人去主导，毕竟也是因为没做过，所以别人也不好带头。这事，我觉得你要趁早站出来了，毕竟这个产品对你很关键，否则根本做不下去的。” 我想了也是，的确说得挺对的。 后面他又说了一句：“我现在做的事也杂，基本都是属于虾兵蟹将，同时在做很多事，要不你和领导说下，再拉个java进来一起做，或者换个人” 我白了他一眼，“你这是彻底抛弃我啊” 后面他提前下车了，我剩下的路上，回家以后，也想了很久。一方面，有种未知感，毕竟跨行如隔山。一方面，心有不甘，现在有这样一个机会做有自己特色的数据产品，我却不能把握住。 ...... 我不会是这样一个人，做不成，死不甘。我觉得我有必要站出来了，把这个数据产品拯救起来，完成自己以前的一个梦想。 当晚上，顷刻间有些兴奋，也冷静总结了以往犯过的错误，找到隐患出现的各种细节，想到对应的方法去填上已经有的坑。 不管结果如何，我都要去拼一把，不为别的，只为了对得起当初的一个情怀。......事实证明，老天还是眷顾努力的人，在10月18号，我们正式发布了一个版本。截止目前11月15号，已经迭代更新了好多版本，也在开发着第二阶段，原来一同并发做同一个产品的其他部门，也即将合并一起更完善我们目前做的数据产品。我也很自信和运营的很多部门领导和同事，介绍着产品的每一个细节，以及对接业务场景的一些方式。 后续期待... 作者介绍 汪榕，3年场景建模经验，曾累计获得8次数学建模一等奖，包括全国大学生国家一等奖，在国内期刊发表过相关学术研究。两年电商数据挖掘实践，负责开发精准营销产品中的用户标签体系。发表过数据挖掘相关的多篇文章。目前在互联网金融行业从事数据挖掘工作，参与开发反欺诈实时监控系统。 |
|
|
来自： openlabzeng > 《待分类》
