别人的大数据平台是怎样的？
别人的大数据平台是怎样的呢?如果参加过一些大大小小的技术分享论坛或会议，你应该不难发现，在各种各样新的诸如“XXX公司大数据平台实践无敌干货分享”之类的PPT中，谈到大数据平台的技术组件时，多半都.会给出一个大同小异的系统架构图。
在这个架构图中，各种日志和DB数据采集组件、存储和计算引擎、监控和调度系统，不管在实践中真实的应用情况如何，反正在图上所有组件一个都不缺，除了个别组件的增减替换，每家公司的大数据平台看起来都没有太大的区别。
所以，如果你要问大数据平台的基础架构图长什么样，不用自己画，直接用HortonWorks公司的HDP发行版套件图来展示，估计也没啥大的不妥，如下图所示。
大 数据平台团队的职能定位
要谈大数据平台的服务化，要评估大数据平台的服务水平，首先就得讨论什么是大数据平台的职能定位和服务对象范围。很不幸的是，这也不是一一个有标准答案的问题。
●在有些公司，大数据团队只负责基础组件的开发和运维，为业务方提供SDK、组件套装或集群形式的服务。
●在有些公司,基础组件之上的工具、平台等,都由专门的工具团队负责, 层层分工，团队之间交叉服务。
●在有些公司，不同的事业部团队会自行在基础平台组件之上，各自垂直地构建独立的业务系统，平台基础组件开发者服务于上层业务系统开发人员。
●在有些公司，大数据团队从下到上全链路通吃，从集群运维一直负贵到最终具体终端业务数据的产出，对终端使用数据的用户负责。
在大数据平台的所有组件中，工作流调度系统(Workflow Scheduler)无疑是最重要的核心组件之一一，是任何一个稍微有点规模且不是简单做做的大数据开发平台都必不可少的重要组成部分。
根据具体语境、称呼习惯和功能指代范围的细微不同，工作流调度系统也常常被叫作作业调度系统(Job Scheduler)、任务调度系统、工作流作业调度系统，或者在约定场景下干脆被简称为调度系统。下文中我们也可能在不造成歧义的情况下，根据需要混用这几种称呼。
作为一个业务环境相对复杂的系统，工作流调度系统涉及的内容繁杂，针对的场景多种多样，实现的方案千差万别,是一个需要理论和实践并重的系统。
大数据平台的权限管理工作，听起来不就是用户和密码管理这点事吗?先找一个数据库存储两者的映射关系，再找- -一个地方记录每个人可以做什么事，最后在需要的时候验证一下就好了。如果不讨论各种加解密原理和算法，这个话题有什么值得一谈的吗?
实际上，如果真正接触过这方面的工作内容，你很快就会发现，不论是在技术层面还是在产品层面，大数据平台环境下的权限管理工作都是一一个让人伤脑筋的烫手山芋。它不仅是一个技术问题，还是一一个业务问题，甚至还可能是一个人际沟通和权衡利益得失的哲学问题。
幸福的家庭都是一样的，不幸的家庭各有各的不幸。
本来想从如何成为一一名优秀的大数据平台开发工程师的角度入手，但仔细想了一下，从这个角度入手的话，这个话题就太简单了!虽然我没有被诸如Jeff Dean之类的大神附体，也不好意思自认为有资格指点江山。但是，讲道理这件事，谁不会呢?
好比，炒股票，不就是低买高抛吗?玩互联网，不就是拉流量变现吗?而要想成为一名优秀的大数据平台开发工程师，只要做到深度与广度并重，钻研技术、理解产品、能搭架构、能解Bug，那就妥妥的了。
既然道理如此简单，还需要多解释吗?而我们，大概不是轻松地碾压了巴菲特，就是早已经顺利地在风口起飞了!
是的，优秀的人都是类似的，说起来就太过无聊了。
总之，人生就是一场解决问题的旅程，焦虑在所难免，但适度的危机感也未必是坏事。重要的是，不要让焦虑过度影响你的判断，尽量让自己具备主动选择未来的能力。
无论各位读者将来是否从事大数据平台开发工作，都真心祝愿各位在工作和生活中能直面问题，客观冷静地寻找解决方案，用正确的方法论和价值观为自己赢得一个充实且有价值的人生。
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
