某大佬耗费三年时间整理的:大数据平台基础架构指南,成功靠它了

大数据平台整体建设思想

别人的大数据平台是怎样的呢?如果参加过一些大大小小的技术分享论坛或会议,你应该不难发现,在各种各样新的诸如“XXX公司大数据平台实践无敌干货分享”之类的PPT中,谈到大数据平台的技术组件时,多半都。会给出一个大同小异的系统架构图。

在这个架构图中,各种日志和DB数据采集组件,存储和计算引擎,监控和调度系统,不管在实践中真实的应用情况如何,反正在图上所有组件一个都不缺,除了个别组件的增减替换,每家公司的大数据平台看起来都没有太大的区别。

所以,如果你要问大数据平台的基础架构图长什么样,不用自己画,直接用HortonWorks公司的黄芪丹参滴丸发行版套件图来展示,估计也没啥大的不妥,如下图所示。

某大佬耗费三年时间整理的:大数据平台基础架构指南,成功靠它了”> </p> <p class=

服务意识和产品思想的培养

要谈大数据平台的服务化,要评估大数据平台的服务水平,首先就得讨论什么是大数据平台的职能定位和服务对象范围。很不幸的是,这也不是一一个有标准答案的问题。

●在有些公司,大数据团队只负责基础组件的开发和运维,为业务方提供SDK,组件套装或集群形式的服务。

●在有些公司,基础组件之上的工具,平台等,都由专门的工具团队负责,层层分工、团队之间交叉服务。

●在有些公司,不同的事业部团队会自行在基础平台组件之上,各自垂直地构建独立的业务系统,平台基础组件开发者服务于上层业务系统开发人员。

●在有些公司,大数据团队从下到上全链路通吃,从集群运维一直负贵到最终具体终端业务数据的产出,对终端使用数据的用户负责。

某大佬耗费三年时间整理的:大数据平台基础架构指南,成功靠它了”> </p> <p class=

工作流(作业)调度系统

在大数据平台的所有组件中,工作流调度系统(工作流调度程序)无疑是最重要的核心组件之一,一是任何一个稍微有点规模且不是简单做做的大数据开发平台都必不可少的重要组成部分。

根据具体语境,称呼习惯和功能指代范围的细微不同,工作流调度系统也常常被叫作作业调度系统(作业调度器),任务调度系统,工作流作业调度系统,或者在约定场景下干脆被简称为调度系统。下文中我们也可能在不造成歧义的情况下,根据需要混用这几种称呼。

作为一个业务环境相对复杂的系统,工作流调度系统涉及的内容繁杂,针对的场景多种多样,实现的方案千差万别,是一个需要理论和实践并重的系统。

某大佬耗费三年时间整理的:大数据平台基础架构指南,成功靠它了”> </p> <p class=

安全与权限管控

大数据平台的权限管理工作,听起来不就是用户和密码管理这点事吗?先找一个数据库存储两者的映射关系,再找——一个地方记录每个人可以做什么事,最后在需要的时候验证一下就好了。如果不讨论各种加解密原理和算法,这个话题有什么值得一谈的吗?

实际上,如果真正接触过这方面的工作内容,你很快就会发现,不论是在技术层面还是在产品层面,大数据平台环境下的权限管理工作都是一一个让人伤脑筋的烫手山芋。它不仅是一个技术问题,还是一一个业务问题,甚至还可能是一个人际沟通和权衡利益得失的哲学问题。

某大佬耗费三年时间整理的:大数据平台基础架构指南,成功靠它了”> </p> <p class=

如何成为一名糟糕的大数据平台工程师

幸福的家庭都是一样的,不幸的家庭各有各的不幸。

本来想从如何成为一一名优秀的大数据平台开发工程师的角度入手,但仔细想了一下,从这个角度入手的话,这个话题就太简单了!虽然我没有被诸如杰夫院长之类的大神附体,也不好意思自认为有资格指点江山。但是,讲道理这件事,谁不会呢?

好比,炒股票,不就是低买高抛吗?玩互联网,不就是拉流量变现吗?而要想成为一名优秀的大数据平台开发工程师,只要做到深度与广度并重,钻研技术,理解产品,能搭架构,能解错误,那就妥妥的了。

某大佬耗费三年时间整理的:大数据平台基础架构指南,成功靠它了