从底层到应用 那些数据人的必备技能

  根据数据应用的不同阶段,笔者将从数据底层到最后应用,来谈谈那些数据人的必备技能。

  大数据平台

  大数据平台目前很火,是数据源头,涌现出各种炫酷新技术,包括搭建Hadoop、Hive、Spark、Kylin、Druid等。不过做这些的前提是你要懂Java,因为很多平台都是用Java开发的。目前很多企业都把数据采集下来了,对于传统的业务数据,用传统的数据是完全够用的,可是对于用户行为和点击行为这些数据或者很多非结构化的数据,包括图像和文本类的,由于数据量太大,很多公司都不知道怎么进行存储。

  这其实要解决的是实时、近实时和离线的大数据框架如何搭建,各数据流之间如何耦合和解耦,如何进行容灾的问题,平台稳定、可用是需要重点考虑的。

  笔者的感觉是:最近两三年中,这方面的人才还是很稀缺的,因为大数据概念炒作得非常厉害,很多企业被忽悠着开始进入大数据行业。而进入的前提之一就是需要把数据存储下来。很多用户行为方面的数据,对于业务的提升比较明显的,如果你能很好地刻画用户,那么对你的产品设计、市场营销、开发市场都是有帮助的。现阶段,很多公司都要做第一步:存储更多的数据。

  和传统的SQL不同的是,针对大数据量的非结构式数据,我们所想的就是:用最廉价的成本存储数据同时能够达到容灾、扩展性高、高性能、跨域,从目前来看,分布式已经被证明是很好的一个方式。

  另外,云端会是个很好的方向,因为不是每个公司都养得起这么多、这么贵的大数据平台开发人员和运维人员。这也提醒从事这个行业的我们,要有很好的危机意识,及时贡献出自己的价值,积极主动地学习新技术,否则就可能被淘汰了。

  此外,花点钱把数据托管给云服务提供商是对于创业公司或者一些传统的企业来说是个很好的思路,这样能够最快速地确定数据对你的价值是什么,并不用采购这么多的服务器、雇佣这么多的运维人员和网站开发人员。

  接下来,给未来会从事这方面的人或者想存储数据的公司一点建议。目前这块工作最被吐槽的一点就是:Hive速度好慢,SQL查询好慢,集群怎么又挂掉了,Hadoop版本升级后,怎么数据跑出来不对了等等。

  因此,在这个领域内工作,需要有强大的攻坚能力,并且还需要有快速定位和解决bug的能力,因为有很多工具都是开源的。因为是开源的,所以会出现各种“坑”,甚至出现无法向下兼容的情况,所以需要强大的Java开发能力。

  如果想在这块做得很好,还需要有整个系统架构的设计能力、较强的抗压能力和解决问题的能力、资源收集的能力,可以打入开源社区,这样就可以随时跟进最新的潮流和技术。

  数据仓库-ETL

  确实做仓库的人很辛苦,单单Oncall就会让人望而却步。有很多数据库工程师,晚上睡觉的时候经常被Oncall电话吵醒。因为数据流程出问题,需要第一时间去排查,是哪个数据源出问题,并且要立即解决,否则整个数据流程都会受到影响。

  如果数据流程受到了影响,你就可能会被大领导随时叫到办公室说:“我要的数据怎么还没有准备好,我的业务报表今天怎么没有发出来?”

  这是个很重要的岗位,因为数据流程很重要,决定了数据从源头杂乱无章的状况,通过ETL之后变成了整齐的数据,这些整齐一致性的数据可以让你很方便地把各业务的统计结果计算出来,并且能够统一口径。要不然就会变成有几个部门,就有几种统计结果的情况。至少在以下几点上,笔者觉得数据仓库人员应该要做好:

  数据字典的完整性。用的人都希望能够清晰地知道这个字段的逻辑是什么。字段要保持很好的一致性,不要同样一个字段在不同表里有不同的定义。

  核心流程的稳定性。不要让每天订单主表能够使用的时间很不稳定,有的时候很早,有的时候要中午才出来,如果不稳定就会导致使用数据的人对你很没有信心。

  仓库版本迭代不要过于频繁,要保持不同版本之间的兼容性。不要做好了仓库1.0,很快就把原来的推倒重来,变成了2.0。在数据仓库中需要考虑到延续性,主表的变动不要太频繁,否则使用的人会非常痛苦,好不容易才用习惯了1.0的表结构,没办法这么快进行切换。简单地说,要能向下兼容。

  保持各业务逻辑的统一性。不要出现同样的业务逻辑,同一个组别的人统计出来的结果不同。原因在于共同的逻辑没有落地成通用的东西,所以导致每个人写法不同。这点其实需要特别注意。

  这个岗位的技能要求是,不要成为仅仅会写SQL的人。现在工具都很发达,如果你的技能很单一的话,那么可替代指数是非常高的,并且你自身也没有什么成就感。这里并不是说会写SQL的人水平很低,只是说应该多学一些技能,否则会很危险。

  仓库人员应该常常思考如何进行架构设计是最合理的,你要考虑是否需要字段冗余、行存储还是列存储、字段如何扩展最有效、热数据和冷数据如何拆分等,所以需要有架构思维。

  技能上,除了SQL熟练之外,还需要知道如何写Transform、MapReduce。因为有很多业务逻辑用SQL实现起来非常复杂,但是如果你会其他脚本语言,那么就能给你提供便利,让你的效率提升很多。另外,好的数据仓库人员需要写Java或者Scala,通过写UDTF或者UDAF来提升你的效率是很有必要的。

  数据仓库人员也应该常常考虑自动化和工具化方面的事情,需要很好的工具或者模块的抽象能力,动手实现自动化的工具来提高整个组织效能。针对经常碰到的数据倾斜问题,需要很快定位问题并进行优化。

  说完了数据存储,接下来是数据应用的几个关键职位。数据应用最关键的前提是数据质量。因为在每次阐述观点、分析结论或者用算法的时候,都需要先检查源头数据正确性,否则任何结论都是伪命题。

  数据可视化

  这是个很炫的工作,从业者最好是能懂点前端,比如js。数据可视化人员需要有很好的分析思维,不能为了炫技而忽视对业务的帮助程度。笔者觉得这个岗位需要有分析的能力,才能把可视化做好。

  从另外一方面来说,做数据应用的人都应该懂点数据可视化,要知道观点表达的素材顺序是:图片>表格>文字。一个能够用图片来阐述的机会千万别用文字来描述,因为这样更易于让别人理解。要知道,给大领导讲解事情的时候,需要把大领导设想成是个“数据门外汉”,这样才能把一件事情说得比较生动。

  数据分析师

  现在对数据分析的需求是很大的,因为大家都想说:数据有了,但是能做些什么呢?这就需要有数据分析师,对数据进行分析和挖掘,然后做数据应用。

  对数据分析师吐槽最多的是:分析出来的不就是正常的业务逻辑吗,还需要分析什么?或者是分析的结论不对,跟业务逻辑不符合,等等。特别是当ABTest的结果与最初设定的预期不相符合的时候,分析师会常常被拉过去说:分析一下,为什么AB实验结果不显著,里面肯定有原因的。

  很多时候,分析师的心里独白是:心里苦啊,这个转化率下降了,从数据上可以看出哪个细分渠道下降了,至于为什么客户不下单,得去问用户去,很多时候,数据上也体现不出来为什么,只能告诉你现状是什么。

  如果一个数据分析师一直在写分析报告、给结论中持续,周而复始,而没有直接在业务中体现成绩,那么,这位数据分析师该醒醒了,想想这个是你要的岗位吗?

  对于数据分析师的定位,笔者认为,成为优秀的数据分析师是非常难的。现在行业也没有多少优秀的分析师。数据分析师的技能要求,除了会数据分析、提炼结论、洞察数据背后的原因之外,还需要了解业务,懂算法。只有这样,当面对一个业务问题时,数据分析师们才可以针对问题抽丝剥茧,层层递进去解决问题,再根据定位的问题进行策略的应对。比如是先做上策略进行测试还是应用算法进行优化,用算法用在哪个场景上,能不能用算法来解决问题。

  一个优秀的数据分析师,是个精通业务和算法的全能数据科学家,不是那个只会听从业务的需求而进行拉数据、做报表、做分析的闲杂人等。我们都说分析要给出结论,优秀分析师的结论就是一个能解决问题的一揽子策略和应对措施,而且很多需求是分析师去主动发现,并通过数据挖掘出来的。

  从上述描述中,可以看到对数据分析师的要求是:会写sql拉数据,精通业务、会数据洞察、精通算法,主动性强。要求还是很高的。

  大部分不落地的分析都是伪分析。有一些探索性的可行性研究可以不考虑落地,但是其他的特定业务需求的分析都需要考虑落地,然后通过实践来反推作用,如此反复,才能慢慢地肯定价值,同时提升你的分析技能,也只有这样才能证明你作为分析师、数据落地者的价值。

  数据挖掘/算法

  笔者在这方面经过这三年的摸爬滚打,感触很多,体会比较深的吐槽主要有以下几点:一个规则搞定了,还用什么算法?你的准确率怎么这么低?你的准确率可以到99%吗?你的推荐有价值吗?你不推荐客人也会下那个产品的订单的。帮我做个大数据预测,看他想要什么?

  很多时候,不同的场景对准确率的要求是不同的,所以在一定合理的场景下和业务进行据理力争是必要的,不要害怕让业务吐槽,更多的时候要管理好他们的预期。

  有些场景下,推荐的价值在于“长期复购率”,所以不要每次都盯着ABTest的转化率来说事,让客人的费力度降低也是很有前景的。一个智能的产品会让客人用起来爱不释手,虽然在这一次的转化中没有明显的差别,但是观察长期复购率才能体现价值。特别是要区分高频和低频产品,频次比较低的产品就特别难体现出短期价值。

  对于这个岗位的技能要求来说,没有要求你一定要从零开始实现所有的算法,现在有很多现成的算法包进行调用。最基本的要求是,你要知道每个场景会用到哪个算法,比如分类场景,常用的分类算法就有LR/RF/Xgboost/ET等等。此外,你还要知道每个算法的有效优化参数是什么、模型效果不好的时候怎么优化。还需要有算法的实现能力,语言方面可以用Scala/python/R/Java等。我们常说,工具不重要,重要的是你玩工具,不是工具玩你。

  另外,针对有监督式学习算法,算法工程师最好有很好的业务敏感度,这样在功能设计的时候才能更有针对性,设计的功能才有可能有很好的先验性。

  深度学习(NLP,CNN,语音识别)

  在这方面笔者没有具体商用过,只是曾经动手实践过。个人感觉商业化是重点。大家都在观望,都说聊天机器很有用,可是siri做了这么久反响也一般。

  现在客服机器人又很火,大家又在吐槽说:这个上下文理解的太差了,机器人的语义识别做得怎么这么差。谁做谁知道,对于中文的语义识别,难度比外语产品大,因为中文的一种否定说法有太多种变体,你不知道我们会说哪种。

  另外,常常有人吐槽说,CNN这么复杂,线上需要满足100ms内返回,搞得这么复杂,实时调用怎么整,肯定来不及了,最后只能考虑线下预测了。常常说这话的人是不会自己写底层代码的。很多时候笔者觉得,不是你没有解决问题的办法,而是你没有去思考怎么解决问题,心智决定了你的产出。

  笔者认为,在这方面需要有比较强的算法改造和优化能力,尽量提高算法预测的速度,同时不断提高算法的外延性,提高精度。目前整个行业也都是朝着好的方向在发展。在应聘时要记得和招聘上的要求核对一下,看自己哪块技能需要补充,这样你才能成为人中之龙凤。

  相关链接

  如何用数据创造价值,如果你没有用数据创造价值的能力,那么就只能等着被数据淹没,被数据拍死在职场上,早早到达职业的天花板。

  体现数据价值的层面上,越往数据应用层靠拢,对数据产生价值的要求就越高,从事这块领域的人要常常自省是否有好的商业敏感度,毕竟在工业界,没人关心你是否比传统的基线提高了一个百分点,他们关心的是你提高了一个百分点之后,对公司的价值是什么。

  而越往底层越没有强制要求和业绩绑定在一起,更多的是从流程上进行约定。对于这块的价值体现,主要从技术层面上的创新为主,你如果解决了现存架构的问题,那么你就可以成为一个专家。所以多学学编程吧,别太约束自己,故步自封。

  携程技术中心 潘鹏举

关注读览天下微信, 100万篇深度好文, 等你来看……