第92期 | 数据工程师是个有前途的职业么？
你好。这里是卖桃者说，今天和你聊聊数据工程师的话题。
国外很多知名互联网公司现在都有 Data Scientist 的职位，翻译过来非常吓人，叫做数据科学家，读着高端大气，看着能上天。这种职位如果你不是计算机博士，基本上不大可能有信心申请，比如你怯生生的问“我是本科能申请这个职位吗？”HR 大手一挥“对不起，我们只招博士后”，你立刻灰头涂脸败下阵来。而且，在国内如此残酷的就业环境下，别人都叫程序员、设计师、前端工程师、后端工程师、算法工程师，您自个儿叫科学家，想一想是不是就脑后生风呢？
考虑到这些因素，国内公司一般把这个职位叫做数据工程师，或大数据工程师，虽然这个称谓像“数据科学家”一样语焉不详，甚至同样会被过度解读，但总是比科学家低调一点，安全一些。无论是国外的数据科学家还是国内的数据工程师，都是需要和数据打交道的人。他们是一群能够处理和分析海量数据的汉子，或女汉子，每天从手里流过上亿条的数据是稀松平常的事情。
另外，需要说明的是，数据科学家偏研究领域，数据工程师偏工程领域。今天的话题主角是后者。
那么，数据工程师是个有前途的职业么？我觉得是，不过这个职业与前端工程师或移动工程师相比，人数的需求可能没有那么多，但要求更高一些，不仅是技术上的要求，而且要对产品和数据敏感，同时具备很好的协调性，因为数据工程师可能要与产品经理、决策者、商务等各种角色打交道。
为什么数据工程师在这个时代会变得炙手可热呢？在移动互联网和云计算的时代，数据正在以几何级数增加，我们每个人每天都在产生大量的数据。当你开车上班的时候，会产生导航和交通数据；我们生病看医生的时候，会产生医疗数据；我们购物的时候，处理邮件的时候，编写文档的时候，查看股价的时候，拿着手机打王者的时候……都在产生各种数据。未来是一个数据构筑的世界，和阿里的朋友们聊天，他们说，现在阿里是个数据公司。
数据改变未来。无论是实业创业还是移动互联网创业，这个趋势将不可逆转。
最近一直在看一些大数据相关的资料，结合我们自己构建数据平台的一些实践活动，谈一下我的几个想法。
1、要有数据，而且得大，没数据都是扯闲篇的
经常遇到一些读者问，想学习大数据相关的技术，怎么入手？或者想在公司引入 Hadoop、Spark、Presto 等一系列技术框架，怎么出手？我就问，你们数据是什么量级呢？答，几百万吧！几百万条记录您用得上这些技术吗？如果你真的想从事数据相关的工作，最好到一家“有数据”的公司，没有真实数据，你永远不会遇到真实环境和数据给你带来的挑战，甚至，你根本想象不到会有哪些挑战，技术就会变成无水之源。知和行隔着万丈鸿沟，看别人纵马狂奔总是容易的，你得自己骑上去试试。
什么是大数据？这个大是相对的，我们人为的去给大数据设定一个阈值，比如1PB，毫无意义，只有当前的数据规模大到对你现有的软硬件技术构成挑战时，才能称作大数据。比如公司内产生的数据已经无法通过关系数据库处理了，得想别的辙，可以算“大”。而且，大数据和时代息息相关，八十年代的大数据和今天的大数据是不可比拟的（为什么八十年代也有大数据呢？因为数据科学已经存在了几十年了呀）。
可以说，“大数据是一种文化现象，它描述了数据在人类生活中所占的比重，随着科技的发展，数据所占的比重会越来越大”。如何描述大数据的特征呢？有个 4V 原则，分别指容量（Volume）、种类（Variety）、速度（Velocity）和价值（Value），你的公司有没有大数据，大数据的形式和能对公司产生的价值，都可以从这些方面来描述。
无论如何，你得有数据。
2、进行数据分析是一件困难的事
以前有读者发来邮件和我说，后端有什么挑战呢，几乎所有的技术都有现成框架了啊！首先，这些框架也是工程师设计和研发出来的，我以前说过，“顶级工程师做工具和平台”，想要找挑战，你可以开发出更好的工具啊。其次，即使有了这些工具，我们去处理数据的时候，依然会困难重重。
如果你想成为一个优秀的数据工程师，你需要统计学和线性代数的相关知识，你必须有熟练的编程技巧和数据抽象的能力，还能做数据的可视化。完成了数据平台的构建，还有机器学习等着，还有人工智能等着，还有不可知的未来等着，有时候我一想到这些，就会产生特别绝望的想法：人类终究还是要输给数据吧。
即使是最基础的数据处理链路，比如数据清洗、存储、分析和计算，也会碰到各种问题。我以前做过一个用户行为分析的数据平台，链路是这样的：数据上报，通过 hash 名称存成 gz 文件，然后用 Python 进行数据清洗，存入 Hadoop 集群的 HDFS，再进行离线计算，通过 Spark SQL 把部分数据存入 MySQL，并提供 HTTP API，给前端做展示。
优化后的策略是：对 App 埋点数据格式进行重新整理和规划，引入 Presto，通过 ETL 程序把 HDFS 文件数据导入 Hive，并做 ORC 压缩处理，形成二进制格式（速度快，节省空间70%），并进行分区。然后通过 Presto jdbc 定时调度任务，将 Hive 数据做统计聚合至 MySQL。优化后的离线分析速度和灵活性都大大增加了。
这里面涉及的名词不少，如果你是数据工程这个领域的，应该都能理解。
推荐一下 Presto，这是一个非常优秀的分布式 SQL 查询引擎，可以实现全内存并行计算，动态编译执行计划，进行本地化计算。既适用交互式分析查询，也可以通过 API 实现数据聚合，数据量可以支持 GB 到 PB，非常惊人。
离线分析有了点眉目，还需要实时分析。有人说简单啊，Flume 进行数据采集，Kafka 做数据队列，Storm 作为 MQ 的消费者，对采集到的数据进行实时分析和流式计算，再存 MySql，就行了。嗯，清丽脱俗的技术方案一旦执行总会困难重重甚至灰头涂脸，知易行难啊。
即使是一套成熟的技术方案，当你去处理自己的实际业务时，也会遇到各种问题。你需要熟练掌握这些技术和引擎，并熟知你的业务数据，才能抽丝剥茧，层层推进，抵达彼岸。
好了，数据量足够大了，可以做机器学习了……
3、有价值的数据只能提供参考，并不能完全指导工作。
有了数据，有了数据分析结果，是不是就万事大吉了？非也，数据只能做参考，如果只看数据就可能出问题，因为数据会带来误导。
比如，新泽西沿海地区来了一场飓风，我们仅对飓风到来前后的部分推特采样数据进行分析，可能会得出这样的结论：人们在飓风来临前在购物，飓风过后在聚会。
仔细分析后你会发现，这些推特数据大部分来自纽约州。首先，这些人是推特的重度用户，其次，沿海的新泽西人正在担心他们的房子会不会被飓风吹倒，谁还有心思和时间去发推特呢？换句话说，如果你使用推特数据来分析飓风的影响，得出的结论可能会是这场飓风危害不大。事实上，真正受到飓风影响的人根本没时间发推。
还有推荐引擎，经常有人在朋友圈抱怨，京东为什么会给我推荐没品位的手机，微博为什么给我推荐不适宜的影片，如果碰巧是个老程序员，还会抱怨这些平台的算法真是烂啊。其实不是这样的。也许你根本就没有评价过人家的商品呢，也许你根本就不是目标用户呢，也许，就是推荐引擎出了问题啊……
总之，数据的相关性不能完全体现因果关系。数据并不会自己说话，它只能够以一种量化的、无力的方式去描述和再现我们身边的社会事件。在现阶段，人还占据绝对主导地位！
一个产品，如果没有数据的反馈和感知，是没有生命力的。一个企业没有数据，估计也很难走的更远。
关于数据工程师的话题，今天就聊到这里，你有什么数据处理的案例吗？可以在留言区说说。
卖桃者说，明天见。
（编辑：成敏）