大数据平台服务化思想及实践

大数据平台服务化思想及实践

1. 大数据平台 服务化思想及实践 刘旭晖(天火)@蘑菇街
6. 我的无敌水干货Agenda 大数据平台的建设目标是什么? 四个现代化的建设指导方针 论为人民服务的崇高理想 我们的一些背锅心得和实践经验
7. 别人家的数据平台长什么样? 来源:H公司Hadoop发行版套件图 • 是不是很眼熟:xxx公司数据平台实践之无敌干货分享 • 各种日志DB链路,存储计算引擎,监控调度组件 • 哪家的数据平台看起来都没啥太大区别?
8. 所以和大厂的差距,到底在哪里? • 组件都差不多,那整体应该都在差不多的水平? • 也就是火候差一点?填坑经验还不够? • 你说主要差距是待遇的差别?别那么直接嘛!
9. 认真思考一下差距 架构理论的 先进性 流式 SQL 差距在 哪? 深度学习 规模 弹性计算 • 这些差距对你来说重要么?你学得会么?你有必要学么? • 具体组件的应用水平方面,固然有差距,但不是平台整体成熟度差距的根本所在! • 产品形态和服务水平的差距,才是最核心的差距
10. 所以我们的目标是 No,No,No! • 谁的组件更丰富?谁跟进社区技术跟进得最快? • 谁的团队技术能力最无敌,谁拥有最多的Committers? • 只是手段,甚至都不一定是实现目标的最有效的手段。 Yes,Yes,Yes! • • • • 你为用户解决了哪些问题,扫除了哪些障碍 提升了多少效率,附加了哪些增值收益 平台内部组件的横向联通能力 业务纵向贯穿打通上下游链路的能力
12. 组件工具化 就是写写集群日常维护脚本这点事么 • 所有自建的数据平台,都是从集群的运维管理开始 • 这件事情做得多了,你就会想要提高效率,最简单的,就是 把一些常用的操作用脚本维护起来,沉淀经验,避免误操作 工具化的本质目标 • 降低学习成本,提高工作效率,减少犯错概率。 • 对组件细节的封装和简化,不仅仅从平台组件维护的角度, 更是从用户应用开发的角度来说。
13. 工具平台化 什么是平台化 • 将各种组件,工具,开发流程整合到一起,统一管理,提供成体 系的开发运维管理途径 实践起来有什么障碍? • 信任危机: 没有收益,没有保障,自己玩呗 • 团队定位:业务方怎么用好集群构建业务,那是他们的问题,我 是技术专家不是保姆 • 系统架构能力:对业务系统全貌不了解,缺乏整体规划的能力
14. 平台服务化 和平台化 的区别 重要的是理念,服务是围绕着客户体验为中心展开的,它的重点不在平 台自身,在与用户 用户满意才是衡量服务水平的唯一标准
15. 服务产品化 提供工具 提供平台 提供服务 • 码农的自我修养和追 求 • 领取微薄薪水的义务 • 博取业务方大爷怜悯 的方式 但是上面这些都没用!领导最终只关心你的价值产出 :-) 底层团队不好干啊。。。 • 做得越多,错得越多,服务越好,负担越重,这种困境,只有依 托良好的产品形态来换取可衡量的价值产出才能打破 • 产品化不是一个一厢情愿,埋头努力就能解决的问题,是对现实 中各种问题的评估,妥协和取舍
17. 数据平台的用户需要什么服务 用户会找你做些什么? • 要求提供各种的组件 • 请你传授各种优化的手段和Hack方法 • 认真钻研和学习各类计算框架 • 和你讨论数据存储在哪里,用什么工具查询 • 思考数据需要做什么预处理,是否需要缓存优化 用户实际想要的是什么 • 存储/计算/查询/展示服务 • 稳定可靠高效的存储数据 • 高效低成本的开发业务 • 快速便捷的查询到想要的数据 • 结果便于理解和沟通,能够支持业务决策
18. 构建数据平台服务的两条路径 针对具体的业务场景,一站到底式的支持 • 产品逻辑可以高度定制,最大程度匹配业务需求 • 流程复杂度相对可控,可以屏蔽与具体业务无关的内容, 容易保障易用性 • 系统架构成型快,演进负担小 • 系统专用性较强,可拓展性差,可能存在重复建设 针对通用的功能需求,构建独立的系统组件 • • • • • 模块化建设,可拓展性较好 减少各业务系统的重复建设 架构方案有机会做到更加深入,完善 系统架构成型较慢,迭代演进负担较大 场景定制程度较低,易用性较难保障
19. 不要问我是谁 • 所以,全心全意为人民服务? 用户就会跪下来感谢你了么?你的工作生活 从此就阳光快乐了么? • 事实上,自打你心里打定主意,走上这条又红又专的服务化之路的那天起, 你就走上了一条不归路。。。
20. 关于为人民服务,你需要知道 由俭入奢易,由奢入俭难 你的服务口碑,取决于你服务最差的那个环节 服务越多,支持的代价越高 老板:既要马儿驮得多,还要马儿不摔倒! 大家视角不同,各自的诉求经常是冲突的,哪怕你的出发点是: 你好,我好,大家好。 • 基于用户满意是唯一标准这条公理,错的都是你,不要做无意义 的抵抗,想想怎么解决问题 • • • • • • 所以,服务辣么苦,为什么我们还要做???
21. 大雪压青松,青松挺且直 要知松高洁,待到血化时
22. 我们的背锅心得 说好不打脸!
23. 前面服务的问题太多,只举两个例子 由俭入奢易,由奢入俭难,用户挑剔,难以伺候 • • • • QOS约定,用户预期管理 统一认知,明确你所提供的服务的范围定义和质量 产品定义,路线计划,已知问题列表,最佳避坑实践 产品使用过程中即时的反馈/提示/警告信息等等 意见有冲突,哪怕你的出发点是为了大家好 • 冲突的往往不是目标,而是在实现这个目标过程中的遇到的问题 • 解决核心矛盾,寻找妥协点 • 凡事可以坚持原则,但是没有必要苛求立场,没有必要追求大家对所有工作 真心赞同
24. 关于产品:君子喻于义 • 别让用户有挫败感! - 不要对用户做任何知识假定 • 提供差异化,阶梯式产品服务 - 面对现实,没有万能的产品 • 构建反馈式服务 - 比起响应迟钝的系统,更让人崩溃的,是压根没有响应的系统 • 确保你的产品,可持续改进 - 光有决心和能力,往往是不够的,你需要反馈和数据
25. 小人喻于利 • 一个有理想的技术同学工作时的思路:这个玩意看起来蛮有挑战 啊,让我来研究一下,搞定它! • 我们经常讨论的是, “是什么,怎么做,能不能做”,做得好 的时候,我们可能还会考虑“这么做是为什么” • 但是“为什么一定要做?这么做值得么?做点别的事是不是收益 更高?” • 不要忌讳谈论利益,它关系到你的团队能否存活发展下去,用它 来检验你的产品建设工作。
26. 祝大家从此过上幸福美满的生活 • 取义,还是取利,本无对错,要做好平台产品化建设工作, 两者缺一不可
27. • • 来人来函交流 刘旭晖(天火)@蘑菇街 wechat : colorant
28. 案例?(Backup) • 爬虫 • 公有云EMR • 调度系统