|
|
51CTO旗下网站
|
|
移动端

1.3.2 工具平台化

《大数据平台基础架构指南》第1章大数据平台整体建设思想,在本章中,为了避免分歧,我们首先会对本书上下文语境中所讨论的“大数据平台”这个概念做一个简单的阐述和背景铺垫。本节为大家介绍工具平台化。

作者:刘旭晖来源:电子工业出版社|2018-11-11 10:46

1.3.2  工具平台化

组件工具化这件事无论深入程度如何,绝大多数公司或多或少都会做一些将日常事务进行封装相关的工作。但将工具进行平台化这件事,有些公司就未必会去做了。

所谓平台化,就是将各种组件、工具和2018送彩金的娱乐网站流程整合到一起,统一管理,提供成体系的2018送彩金的娱乐网站运维管理途径。同时通过规范流程,提升平台整体的稳定性和可控性,进而提升运维和业务2018送彩金的娱乐网站的效率。

平台化的障碍,往往是“非不愿也,实不能尔”。有不少公司(其中有些还是有一定规模的公司)的数据平台团队,提供给用户的就是若干集群和它们的日常运维优化,甚至有时候连集群都是由各个业务团队的用户自建的,没有统一的管理。所有具体业务的2018送彩金的娱乐网站、调试、问题排查工作都交给业务方来负责。至于权限控制、流量隔离、流程优化、最佳实践、方案建议等各类增值服务,就更不用想了,用户须完全依靠自己,只能自求多福。

出现上述现象的原因很多。

可能是技术原因,比如别人使用大数据团队所提供的集群时,压根就没有多少收益,反而有稳定性缺乏保证、业务间无法隔离、出现故障相互影响、缺乏工具来帮助简化2018送彩金的娱乐网站等负面影响。说到底就是大数据基础架构团队提供的附加价值不够,还要受平台的约束和依赖,不如自己建设来得放心。

也可能是团队定位问题,大数据基础架构团队,将自己定位为集群的运维者,而非方案的提供者。这种情况可能是团队分工、部门利益冲突之类的原因导致的,也可能只是基础架构团队自己的目标定位取舍导致的。

比如,觉得上层的具体业务应用与基础架构工作无关,业务方怎么用好集群去构建业务是其他部门团队的职责,多一事不如少一事,作为基础架构团队,专心解决好集群的故障,提升集群的性能就行了。简单来说,就是认为大数据基础架构团队是顾问,不是管家或保姆,团队没有义务和时间去帮助上层团队解决业务问题,有这时间多写两个补丁、修复一下集群故障、提升技术、走好开源之路多好。

所以,无论是团队分工和部门间原因,还是自我定位的原因,结果就是大数据基础架构团队对大数据整体的实际应用全貌并不了解,不知道用户的痛点在哪里。因为缺乏了解,也就不具备整体规划平台、整合流程的能力。最后的结局就是,将各种系统和工具进行整合并完成平台化这件事,即便团队想做,也没有能力实施。

当然,上述这些问题,有时候也许未必完全是团队自身的原因,公司的风格、环境、人才短缺的客观因素,业务方诉求的轻重缓急,现阶段业务的核心矛盾,周边相关系统的成熟度等,都可能对平台化的工作和意愿造成影响。而这些因素有时候真的并不在团队的可控范围内。

但不管怎么说,这些只是问题,而非理由。平台化的工作不求一步到位,也可以逐步进行,最重要的是对这个目标本身的追求。无论有多少困难,你总能找到在当前阶段从平台化的角度可以做、应该做也值得做的事情。如果真的完全没有,那还是赶紧换个工作吧。


喜欢的朋友可以添加我们的微信账号:

51CTO读书频道二维码


51CTO读书会第9群:808517103

【责任编辑:book TEL:(010)68476606】

回书目   上一节   下一节
点赞 0
分享:
大家都在看
猜你喜欢

读 书 +更多

XML案例解析教程

本书对2018送彩金的娱乐网站XML应用程序给予了详细指导,其中一些应用程序甚至对于您来说是完全陌生的。这些应用程序包括XML 1.0,以及与XSLT、XQuery和XPat...

订阅51CTO邮刊

点击这里查看样刊

订阅51CTO邮刊
博聚网