接上文：《大数据团队从0到1》
1.0阶段的核心是数据分析，把大数据离线计算的整套流程和框架搭建起来，后续就是不断在框架中加入新的业务、新的需求了。但是1.0阶段的数据是T+1的，即每天、每周、每月定时计算的，快一点儿的有每小时、甚至每5分钟的，都是离线数据，实时性不足。2.0阶段重点加强的，就是实时计算领域。
实时 VS 离线
实时计算与离线计算，表面上的区别，在于数据的时效性。实际在这背后，还有更多的区别。上一篇文章中说，从0到1的阶段需要的是数据分析，但没有解释为什么一开始是使用“离线的”数据分析而不是实时的，下面来解释一下：
大数据离线与实时计算的相同点
1、输入
大数据一定是与线上数据解耦的。
离线计算时，我们把数据从线上数据库中同步一份儿到离线数仓中，在离线数仓中进行复杂的计算；
实时计算时，我们也是采用异步的办法，从线上数据中接一条分支的数据流过来，进行实时计算；
两种方案都是，不直接操作线上数据，而是想办法同步一份儿数据过来，再使用我们同步过来的这份儿数据进行计算。
2、输出
输出的方式，都是把结果数据直接输出，更新到一个数据存储里。用户的感知上没有太大区别，有的时候甚至不在乎这份儿数据是多久更新一次。
大数据离线与实时计算的不同点
1、人员技能
离线计算的核心技能就是SQL，虽然HiveSql与传统RDBMS的SQL写法稍有不同，但绝大多数情况下都是一样的。首先理解SQL的本质是MapReduce任务，再顺着这一思路去写SQL即可。
而实时计算就麻烦了，这一领域的技术链条长、同类产品多，需要的都是全域的“通才”。而这类“通才”往往很难找，不敢奢求找到技术链条完全匹配的，匹配度超过50%的都不容易。一般有两种办法解决这一问题：
- 凑齐整个技术链条的“专家”。技术链条虽长，但每个节点都有每个节点的“专家”，凑齐所有节点的专家即可；
- 寻找学习能力强的“潜力股”。大部分公司会选择这种方式。“潜力股”的薪资水平通常会比有多年经验的专家低得多，但学习能力强、上手速度快。而且很多程序员都对大数据这一领域垂涎三尺，巴不得有个机会可以转到大数据领域；
现在在招聘网站上看求职者简历，很多人都会用+拼成好几条技术线，凸显自己的技术面广。例如：
Flume+Kafka+HDFS+Spark+HBase+Redis+Impala+ElasticSearch+Hive
求职者这一思路是没有错的，毕竟如果只专于某一种技术或者框架，可能换一家公司就发现技术选型不一样，又要从头再来了。
但是这里也要提醒公司的招聘负责人注意，根据多年面试经验，求职者的技术链条一般写的都是整个大数据团队的技术链条、而不是他自己一个人的，需要仔细识别他自己负责的到底是哪一块，避免招聘入职后发现被骗。
2、成本
如果是开源使用者，这一阶段的服务器费用成本不会增加太多，但是人力成本、学习成本、时间成本上会多出许多，甚至还需要专门的大数据运维工程师。
如果是云产品使用者，这一阶段会又多出大量的云产品费用支出。毕竟实时计算所需的技术组件远比离线要多、要贵。
3、投入产出比
即使以上1、2两条都不是问题，那最终算下来的投入产出比，也远远低于离线计算。同样是计算“每日订单量”并写到一张结果表中，离线计算从开发到完成不会超过半个小时，实时计算大约得要一天的工作量。
4、“坑”
实时计算是有“坑”的，更麻烦的是，万一真掉进坑里了，修复会很难。
离线计算如果出错了，直接重跑一次即可，会直接把之前错误的数据覆盖掉；
实时计算如果出错了，如果按正常流程修复，需要先找到出错的时间点，把消费进度恢复到那一时间点，再重新消费。这里边还要注意“幂等”、注意“顺序”等等问题，非常麻烦。所以一般都采取直接用“离线计算”来修正实时计算的数据（甚至不管实时数据是否出错，都定期用离线数据修正）。这就需要实时和离线两边的代码逻辑完全一致。那么问题又来了：完全不同的编程语言，如何保证两边的逻辑完全一致呢？“坑”挖到这里，一般人可能就坚持不下去了。
个人十分看好Flink“流批一体化”的产品方向，期待Flink能更快地成熟起来，把这一问题从根本上解决掉。
综上，第一阶段使用离线计算才是比较明智的做法。毕竟想稳住自己的地位，必须要先尽快的做出成绩。
面临的选择
这里列举在实时计算团队的工作过程中，会面临的几个比较重要的选择。
1、数据接入方式
大数据团队想接一条数据流过来的方式有很多。比较常见的有：
-
规定一个消息队列，作为大数据接入的标准数据源。其他业务方如果有需求，就按照事先规定好的接入标准把数据主动写到这条消息队列中，大数据再进行消费。
- 适用于大数据团队比较强势、团队规模不大的公司；
- 优点：大数据团队完全不用担心有遗漏的业务、或者消息的格式不匹配导致的报错；
- 缺点：其他所有的业务团队都需要了解并严格执行大数据团队制定的规则；
-
大数据团队自己想办法去拿数据。例如监听业务数据库的binlog、或作为一个新的消费者订阅业务方的所有消息队列。
- 适用于大数据团队相对弱势、团队规模较大的公司；
- 优点：各个业务团队几乎可以完全不用顾忌大数据团队的需求，做好他们自己就可以；
- 缺点：业务方有变更时，大数据很难及时了解；需要耗费大量精力在沟通上；人工维护成本太高；
我当然更偏向选择第1种。但事实往往不尽如人意。
2、技术选型
技术选型中必不可少的几类组件：
- 流计算引擎（Storm/Spark/Flink/KafkaConsumer/...）
- 消息队列（Kafka/RocketMQ/阿里云DataHub/阿里云日志服务LogHub/...）
- 日志采集工具（Logstash/Flume/阿里云日志服务LogTail/...）
- 缓存（Redis/Memcache/...）
- 数据存储（RDBMS/NOSQL数据库/搜索引擎/分布式文件系统/...）
- ……
还有一些可能会用到的，比如：
- 数据查询引擎（Kylin/Impala/Presto/...）
- ……
在做选型之前，最好先要把同类的产品都研究一遍，列举出优缺点，最终选择一款最适合自己场景的产品。
见过很多的团队，选型属于“随大流”类型，别人用什么、我们就用什么。
选型是需要有自己的原则的（一个没有原则的团队，想想就觉得很可怕）。比如：
- 偏向于选择大型云服务商的云产品；
- 偏向于选择社区活跃度高的开源产品；
- 偏向于选择依赖环境少的产品；
- 偏向于选择生态完善、不会需要太多二次开发的开源产品；
……
小公司由于人力有限，一般在选型上的注意事项会比较多。大公司则恨不得自己从0开始重新写代码，之后作为开源软件捐赠出去、或者作为商业化产品卖。
大数据团队组织架构V2.0
如图，在1.0基础上，增加了两个新的职位：
Spark/Storm/Flink开发工程师
- 任职要求关键词：Java/Scala、Spark/Storm/Flink、Flume/Logstash、HBase、Redis/Memcache、ElasticSearch、……
- 岗位职责：负责基于大数据实时计算体系的需求开发
大数据运维工程师
这是一个神奇的岗位，在招聘网站上几乎看不到，但是却是一个实实在在存在、甚至必须存在的岗位。原因之一，也是由于大部分公司都把大数据的“开发”和“运维”岗位合成了一个，要求：大数据实时计算体系的搭建、开发、运维。
但是其实，大数据的运维和开发还是建议分开，因为大数据运维这一领域有好多该做的事儿。
另一个原因则是，近几年大型的云服务提供商的崛起，使得云产品的使用率越来越高，这类云产品都是免运维、开箱即用的。
另外还有一个神奇的岗位，叫“大数据测试工程师”，也是在招聘网站上几乎看不到。大数据领域的测试，我虽从业多年，也一直没找到一个非常合适的测试方法和测试流程，一直坚持的办法就是开发的自测和互测，因为需要能看懂代码的人。
大数据团队工作成果V2.0
- 实时计算平台：提供实时（准实时）的大数据计算平台，使数据更加实时。
总结
2.0阶段，相对1.0阶段来说，走得更慢，而且缺少特别有突破性的成果。但是从团队建设的角度，这一阶段走完之后，大数据团队就基本已经成型了。
这一阶段可以走得很长，甚至永远在这一阶段走下去。毕竟光是依靠大数据的“离线+实时”的计算能力，就可以做很多很多事儿。重点注意这一阶段的团队流程建设，包括实时计算团队的领域划分、技术方案设计、文档与注释要求、压力测试等等，也包括之前提到过的离线计算团队的数仓设计原则、编码规范等等，还包括如何让整个团队提升工作效率、避免重复造轮子、避免陷入舒适区等等。
总结一下，2.0阶段走向成熟的标识就是：一切基本的数据分析都不再是问题，数据中心建设完成。
下一个阶段，就是如何让数据发挥价值。
