大数据运维规划.pdfVIP

大数据运维规划 1 一个企业的 IT 部门有业务和分析系统之分，这里就叫作 OLTP 和 OLAP 吧，IT 部门普通算是业务部 门的乙方，而 IT 部门的 OLAP 系统则是 OLTP 系统的乙方，因为 OLAP 系统处于 OLTP 的下游，一 般可用性要求也不高，在传统企业内，CRM 挂了是天大的事情，但同样的事情发生在 BI 等 OLAP 系 统上则可以容忍很长期。 传统企业的 OLAP 系统侧重对内支撑，除了必须的生产报表，不是必需品，更多像是奢靡品，有了可 能好一点，没有影响也不大，比如精确营销。 随着大数据时代到来，企业对内数据化、精益化运营的要求越来越高， OLTP 系统迫切需要 OLAP 的分析力，OLAP 则需要嵌入到 OLTP 流程中发挥价值，两者相互渗透，我中有你，你中有我，OLTP 与 OLAP 系统融合的趋势将越发明显。 同时，不少企业开始推进大数据价值变现， OLAP 系统的地位就发生了根本变化，即 OLAP 系统越 来越跟企业的直接价值创造相关，比如以前 OLAP 挂了，只要对内部客户做些解释也许就能消化影响， 现在则会造成外部客户投诉，在阿里等企业大数据平台挂了肯定是不可想象的事情。 相信每年阿里双 11 前大数据平台运维的人会很忙，即使如实时大屏数字显示这种都需要强大的运维 保障能力，而不少企业搞大型营销活动往往只关注 OLTP 系统的稳定，OLAP 系统的运维人员会悠闲 的多，这是数字化企业和非数字化企业的差距。 DT 的趋势不会改变，无论是对内还是对外，打造一个茁壮的大数据运维体系必不可少，由于 OLAP 与 OLTP 特点不一样，不是简单的照搬 OLTP 系统的运维方式就可以了，需要走出自己的路，这里分 享一下笔者最近关于大数据运维的一些思量。 1、数据运维的组织架构 2 笔者经历过不少种 BI 运维组织架构，一种是开辟和运维纵向一体化， BI 没有交维动作，开辟人员直 接为维护负责，在长达 6-7 年的时间，笔者所在的 BI 团队就是这种模式，每一个人按照业务条线进行 划分，为这个业务条线的所有数据负责。 这种运维的效率其实是很高的，对于个人的锻炼价值也很大，既做需求，也做开辟，更做维护，还要 会交流，但其最大的问题就是缺乏标准，处理过程不透明，无法进行运维承诺，规模很难扩大。 第二种就是开辟和运维彻底分离，即横向切割，不少企业发展到一定阶段，系统越来越庞大，IT 部门 为了保障系统稳定制定了大量的标准化规范和流程，为了确保运维管理的集中高效执行，运维团队必 须从开辟中剥离出来，传统的观点认为开辟和运维的职责存在天然的冲突，需要实现制衡。 从笔者的经历看，这种 BI 运维模式，从短期来看有效果，但长期看，存在着不少弊端，总体来 讲， 并非最好的运维模式。 开辟和运维要实现理想的交接，前提是交接的东西标准化程度要高，能够说得清晰，告诉你这个东西 不会变形成其他东西，因此，越稳定，越容易封装的东西越容易交接，也即越容易维护。 OLTP 不少时候是有这个特点的，但 OLAP 系统则彻底不同，OLTP 能清晰的说清晰提供了多少种服 务，这些服务之间的关系如何，也即组合是可以穷举的，但数据的指标和维度是如此之多，相互之间 的组合关系是无穷的，数据封装本身就是个伪命题，数据要交维需要的是对于业务和数据的深入理解， 而不是告诉维护这张表交给你管理，数据维护最大的一类工作数据质量稽核需要代码级别的溯源能力。 因此，BI 要实现理想交维往往惟独一种可能，维护人员跟开辟人员具备同样的技能，君不见核查数据 问题基本是要开辟参 的，只懂封装的数据运维人员除了能监控、告警、作业调度启停一下，可做的 事情很少，因此，这种浅层次的运维到底有多大的价值？ 3 随着数据交维的东西越来越多，运维人员会疲于奔命，不少沟通协调工作只是为了转述问题，一个问 题的解决流程会拉的很长，这种运维模式满意度其实很难提升，同时运维人员的专业技能也很难获得 增长。 第二种模式短期来看的确