所以，你要问，做为大数据务虚系列文章的第一篇，就想搞个大新闻，放一个有中国特色的四个现代化的社会主义大数据平台的卫星么？
是的，凡事不谈理想和主义，就显得不够高端呗～～ 何况对于我们这些干底层苦力活的大数据码农来说，没有理想，那和只知道埋头赚钱的互联网资本家们又有什么不同 ；）
好，废话少说，开始正题。
别人家的大数据平台，长什么样？
说到大数据平台长的什么样，如果参加过一些大大小小的XX Conference和XX Summit，你应该不难发现，在各种各样新的，老的，大的，小的 XXX高科技公司的诸如：“我司数据平台实践之无敌干货分享” 之类的PPT中，谈到数据平台的技术组件，多半都会画出大同小异的系统架构图来，各种日志DB链路，存储计算引擎，监控调度组件，管它是真是假，反正大家都不缺 ；）除了个别组件的增减替换，哪家的数据平台看起来都没啥太大区别。（没错，我也做过类似的分享。。。）
所以，如果直接拿比如：H公司的发行版套件图来show，估计也没啥大的不妥 ；）
除去公开会议，过去的两年里我和北上杭的不少业内同行也做过私下交流，这过程中，也有同学很直白的跟我说，别折腾了，平台建设的整体思路，其实都差不多，随便找一家靠谱的公司交流一下就好了。貌似真的可以交流和PK的，只是一些具体链路／组件上的深度技术细节，平台的稳定性，以及大家各自平台与自己公司业务的功能适配等方面的差异了。
和别人家的大数据平台，差距在哪里？
那么，如此看来，稍微靠谱一点的公司，大家的大数据平台，整体水平应该都在差不多的水平线上？差距，只是踩坑多少和经验的积累？（什么，你说主要差距是待遇的差别？别那么直接嘛！我会哭出来的。。。）
所以，现实果真如此么？
以我司自己为例吧，向上，我们和一些优秀的一线大公司，比如阿里妈妈，企鹅爸爸的数据平台建设水平相比，整体有不小差距肯定是不用怀疑的，这些差距真的仅仅是具体组件的技术深度这些层面的因素造成的么？我自问没有那么简单。
向下，我也接触过不少过来面试的同学，在这样那样的公司（有些其实也不是小公司了）从事数据平台的建设工作。简历上写的各种主流技术一样不拉，五脏俱全。但往往平台的整体应用情况，是极度原始和简陋的。可是如果画系统架构图，没准因为这样那样的原因，组件比起我们来，时不时的还会多出两三个来 : )
那么，这里面的差距到底在哪里？
纯粹论底层组件，抛开财大气粗，自打飞天开始，啥组件都要自己搞一套的阿里不说，多数公司主要依托的还是开源组件，从技术层面来说，填坑的水平固然有差异，但真的是各自平台整体水平差距的最重要的因素么？
对多数公司来说，你的业务负载并没有达到BAT的规模，架构的先进性，极端情况下平台的稳定性，各种弹性和可拓展性，对你真的有很大影响么？你和别人的差距真的是类似深度学习，流式SQL，即席OLAP之类新技术应用速度上的差距么？别人不用这些技术的时候，支持业务的能力，不是一样甩你几条街？
拿手机厂商来举例，造手机，外观上不就是个触屏加摄像头么？剩下的组件配置不外乎：蓝牙／wifi／NFC，GPS，内存，CPU。所以，你觉得山寨机和IPhone的差距在哪里？
再比如旋翼类无人机，主体结构不就是电池，马达加几个螺旋桨么？ 那大疆的无人机和淘宝上几十块钱一个的玩具四轴又有什么区别？（哦，有的，“晓”的英文名起得帅气，大数据玩家值得拥有！）
在我看来，多数公司，大数据具体组件的应用水平方面，固然有差距，但不是平台整体成熟度差距的根本所在。
回过头来说，一些具体组件技术深度上和一线大公司的差距，因为公司体量和人才储备方面的差距，一时半活你多半也是学不来的，很可能，在很长的一段时间内，你也没有必要学，等到技术成熟，或者你的业务火烧眉头需要了，再拿过来用就好了。
事实上，产品形态和服务水平的差距，才是最核心的差距，幸运的是，产品和服务的思想，也是有可能快速学习，借鉴和改进的（前提是你认识并理解这个差距）
大数据平台的建设目标是什么？
所以，大数据平台建设的目标是什么？比拼谁的组件更丰富？谁跟进社区技术跟进得最快？谁的团队拥有最多的Comitter？No，No，No！这些，最多也就是手段，而非目标。甚至都不一定是实现目标的最有效的手段。
评估数据平台的能力和成熟度，重点不在于你提供了多少种存储计算引擎，Cover了大数据生态圈多少的技术组件，或者你自认为的团队技术能力有多么的无敌，甚至都不是你的平台有多么的稳定，组件性能调优得多么彻底。
事实上，你为用户解决了哪些问题，扫除了哪些障碍，提升了多少效率，带来了了哪些增值收益，进一步的，包括平台内部组件的横向联通和业务纵向贯穿打通上下游链路的能力，这才是数据平台建设的根本目标和成熟度评估标准。
这不是我假装用户至上所喊出的无关痛痒的漂亮话，这是我们做为一个专业的背锅团队，在过去几年的实践中，实际的经验教训总结，不太谦虚的说，我们数据平台的技术水平在类似规模的公司中，还算过的去，从我们团队出去的同学多数也都能在新的环境里承担重任。但是在领导眼中，我们团队的产出价值，未必是令人满意的。所以，痛定思痛，亡羊补牢中 ：）
不过，所谓知易行难。每隔一段时间，回头再看，都会发现自己之前所做的工作，还是和这个目标有不小差距。
大数据平台的建设指导方针？
至于如何建设数据平台，一定是根据各个公司的实际情况，因地制宜的，不过，可以谈谈几个基本方针思想，我姑且归纳为四个现代化把，标题党，你懂的 ：）
工具化
所有自建的数据平台，大概都是从集群搭建之类的工作开始，对集群进行运维管理，提交给用户（可能就是自己）使用。
这件事情做得多了，你就会想要提高效率，最简单的，就是把一些常用的操作用脚本维护起来，沉淀经验，避免误操作呗，比如集群部署，配置更新等等。
但工具化，难道就是写写集群日常维护脚本这点事么？工具化的本质目标，是降低学习成本，提高工作效率，减少犯错概率。所以工具化的背后，是对组件细节的封装和简化，不仅仅从平台组件维护的角度，更是从用户应用开发的角度来说。
比如说用户不熟悉HBase的使用方式，（虽然已经很简单了），你写一个SDK包去封装一些常用操作提供给用户（然后，SDK里面，你可能就可以做一些权限，流量控制，监控，顺带屏蔽一些高风险操作之类）
再比如说用户消费Kafka的Topic，难免要做一些消费Offset查询，重置，即时的消息查阅之类的工作。扔给用户Broker和ZK的地址，自己去研究Kafka／ZK客户端命令行搞定，固然也是一种方式，但无论从用户的效率还是从集群的安全角度考虑，都是不恰当的。提供一些工具把这些操作封装起来，对用户屏蔽集群的拓扑细节，屏蔽操作的命令细节显然有助于提高效率和安全性。
平台化
工具化无论程度如何，绝大多数公司或多或少都会做一些相关的工作。但平台化，有些公司就未必会去做。所谓平台化，就是将各种组件，工具，开发流程整合到一起，统一管理，提供成体系的开发运维管理途径。规范流程，提升平台整体的稳定性和可控性，进而提升运维和业务开发的效率。
平台化的障碍，往往是 “非不愿也，实不能尔”。看过不少公司（有些还不是小公司）的数据平台团队，提供给用户的就是若干集群和它们的日常运维优化，甚至还有一些连集群都是各个用户自建的大小集群，没有统一的管理。所有具体业务的开发，调试，问题排查工作都交给业务方来负责。至于权限控制，流量隔离，流程优化，最佳实践，方案建议？大家自求多福吧。
出现这种情况，可能的原因很多：
可能有技术原因，比如别人使用你的集群压根就没有多少收益，稳定性缺乏保证，业务间无法隔离，出现故障相互影响，缺乏工具来帮助简化开发等等，说到底就是不信任你，那么自己玩就是了。
再有，可能是团队定位问题，自己定位为集群运维者，而非方案提供者。这有时候可能是团队分工，部门利益冲突之类的原因导致，而也有些时候可能只是你自己的目标取舍导致的后果，觉得具体业务与我无关，业务方怎么用好集群，构建业务，那是他们的问题，多一事不如少一事，我专心解决好集群故障，提升集群性能就行，我是顾问，不是管家或保姆，我没有义务和时间去帮助别人解决问题。有这时间多写两个Patch，走好我的Committer之路 :-）
所以，无论是分工和部门墙原因，还是自我定位导致对系统全貌的不了解，缺乏整体规划的能力，总之最后的结果就是系统整合平台化这件事，即使你想做，也没有能力做。
这些问题，也许未必完全是团队自身的问题，公司的风格环境，人才短缺的客观因素，业务方诉求的轻重缓急，现阶段业务的核心矛盾，周边相关系统的成熟度等等，也许并不在你的可控范围之内。
但不管怎么说，这些只是问题，而非理由，平台化的工作可以逐步进行，重要的是对目标的追求，无论有多少困难，你总能找到当前阶段可以做，应该做，必须做的事情 ；）
服务化
平台化和服务化有什么区别？？？ 好吧，说实话，没有本质的区别。你说工业，农业，国防现代化和科学技术现代化有什么区别？ 做到后面都是一致的，都要依托技术的进步。
但分开来说，我想重点强调的，是理念上的问题。
服务是个被用烂的词语了，早在计划经济时代，你应该就体验过（好吧，暴露年纪了）国营商店的优秀服务了把？
所以，什么是服务？我们辛辛苦苦提供了稳定的Hadoop集群给业务方用，是服务么？我们开发了高性能的ETL工具，是服务么？我们把元数据血缘关系都收集，分析，展现出来了，是服务么？我们提供了任务调度的方式手段，是服务么？
其实，这个问题，没有标准答案，是不是服务，取决于你所服务的对象。你所提供的内容，是不是对方最终想要的东西？好比我想享受一顿美食，你给我一条活蹦乱跳的澳洲龙虾，一个设备齐全的厨房，甚至还有一本澳龙制作指南。不是不可以，但可能并不是大多数人所期望的服务。但如果我是想学习海鲜烹饪，那这种服务就再理想不过了。
鉴于这个问题有太多的内容好谈，所以，这里就不详细展开，只是先强调一下：服务，是围绕着客户体验为中心展开的，所以它的重点不在平台自身，它的重点是用户。用户满意才是衡量服务水平的唯一标准。
P.S. 顺便广告一下，下一篇务虚文章，应该会重点展开谈谈服务化，谈谈这两年在服务化的路上我们的一点点感受和教训。
产品化
说实话，前面讲这么多最后都没用，产品化才是平台最后能够健康发展的根本。
做为背锅多年的团队管理者，我可以负责任的告诉你：提供工具，是你做为码农的自我修养和追求，提供平台是你领取卑微薪水的义务所在，提供服务是你博取业务方大爷偶尔的怜悯的方式，但最后，这些领导都不关心，领导只关心你的价值产出 :-）
做得越多，错得越多，服务越好，负担越重，这种困境，只有依托良好的产品形态来换取可衡量的价值产出才能打破。
不以产品化为目标的平台建设，自High不难，残喘存活，问题也不大，但要实现人类大同，按需分配，精神极度丰富的社会主义高级阶段目标，就会比较困难了。
而产品化同样也不是一个一厢情愿，埋头努力就能解决的问题，更多的时候，是对现实中各种问题的评估，妥协和取舍。这取舍，在短时间范围内，甚至可能包括：你个人的工作效率，你的技术情怀，追求和节操。
这方面，我们处理得也并不太好，但多少也有一些体会，后面另写文章详细展开把～～～
罗马不是一日建成的
然后，你要说，这些都很好，然而并没用把，你以为你是那两个大厂么？你就纸上谈兵瞎BB吧，这种假大空的套话，那么多Conference上，我听多啦～～
好吧，你是对的。 不过，有时假装一下自己有追求，也不是坏事 ；）
另外，话说回来，虽然前面的顺序貌似是按照工具化，平台化，服务化，产品化的节奏逐步演进的，但是其实这四者没有必然的先后高低之分。也未必见得只有大厂才能玩好服务化和产品化的概念。小平台有小平台的优势和玩法，大厂有大厂的定位和烦恼。
举个例子，比如腾讯云／阿里云也算人多势众，高端大气了吧，大厂的技术储备应该也不差。但是看看他们的EMR相关产品，功能是及其简单的，各种限制和约束，几乎完全无法定制，稍微有点规模，有点经验的数据平台团队对这样的产品应该都不会满意，总结一下就是，简陋！完全没法用。如果你用这个来对标自己的平台建设目标，我只能说，眼界太低了。
但，这是因为他们能力不够，或者是经验不足么？ 显然不是，这是公有云的产品形态所服务的对象的问题，当你的主体用户是数以千万计没有足够开发能力和经验的小客户时，你所追求的就不是全能而又高端的服务了，而是提供最普通，最简单，最傻瓜的功能，做到完全不可能出错。想要更好更灵活更强大的功能服务？抱歉，不在优先考虑范围内。很好理解不是，如果不这样做，就等着海量“无知”用户的投诉和任务工单吧 :-）
所以，尽管你的公司很可能就活不到罗马建成的那天，又或者我们压根建设的不是罗马而是社会主义新农村，那也不要紧，小有小的态度，乡村别墅未必就不能盖得漂亮而有态度 ；）
总结
好吧，这篇谈主义的不知道怎样才能写得不水，争取下一篇不要写得这么水。。。
链接：
常按扫描下面的二维码，关注“大数据务虚杂谈”，务虚，我们是认真的 ；）
