从Redshift看弹性分析演进
弹性能力，是云产品的核心能力之一，也是各大云厂商的竞争热点。AWS作为全球云厂商的领军企业，其发展方向具备一定的代表意义。下面就从其数据仓库产品-Redshift入手，分析其在弹性能力方面的演进过程，同时也谈谈自己对弹性问题的一些理解。
1. 弹性发展阶段
产品弹性能力的发展，是有其一定的规律。一方面是企业在根据需求不断打磨，更好地满足客户方需求；一方面也是需要一个技术积累沉淀的过程。下面是我将弹性发展划分的几个阶段，需要说明的是，为了满足不同客户场景，不同阶段的产品是会长期共存的。
1). 第一阶段：无弹性
第一个阶段，就是无弹性节点。这一时期，云厂商更多是提供标准品。但为了满足来自客户侧的不同需求，往往通过定义多个规格来完成。从数据分析场景来看，比较显著的需求差异就是对核心两类资源：计算、存储的需求差异。一类是提供快速的计算访问，一类是提供海量的数据存储。因此在产品定义阶段，就分拆成不同的规格。例如Redshift的售卖规格（来自官网资料）
通过不同的硬件提供了差异化的服务，满足客户的不同需求。当然这种方式的弊端也很明显，标品不能很好地满足客户个性化需求。
2). 第二阶段：资源弹性
走到第二阶段，看到标品规格无法满足用户需求的情况下。可提供资源扩展能力。这里的资源扩展能力，可包含很多的维度。
- 维度-Scale UP Scale UP，就是提升集群节点单体的能力。可以通过增加资源的方式，提升其性能。例如增加CPU、内存等。通常对于云端产品来说，就是升级了一个规格。
- 维度-Scale OUT Scale OUT，就是通过增加集群节点来提高整体能力。云端典型的分布式产品，都具有平滑扩容的能力。通常对于云端产品来说，就是增加集群节点数。
以Redshift的DS规格为例，其是支持在一定范围内的节点扩缩容及不同规格间的升降配能力。这一阶段的弊端主要表现在粒度比较粗，无法精细化管理；无法扩展独立资源，例如只增加计算或存储部分及对扩规格系列的升降配有限度上。
3). 第三阶段：细粒度弹性
在这个阶段，产品会提供独立资源的弹性能力，进而解决上一阶段独立资源的问题。例如单独扩展计算能力、存储能力等。这种方式，可以更好满足不同的不同工作负载，提高整体的利用率。常见的场景是，有些用户某项资源不足，但受之前技术架构的影响，又不得不购买一大块资源；而独立弹性的方式则更加精准，有的放矢。这个阶段的问题，在于对独立资源的拆分及分配的精细化粒度。
4). 第四阶段：功能弹性
在此阶段，侧重点不在是资源而是某项功能。产品通过支持特殊功能来实现一定的弹性。例如在数据分析中比较常见的数据冷热分层的问题。在AWS中的RA3规格，就提供了基于S3的冷存储和SSD热存储。用户不需要关心数据分布，就可实现以接近冷存储的价格、热存储的性能的使用体验。这里的功能点，可以依据数据生命周期进行梳理，看在哪些环节可能存在瓶颈或需求，通过扩展功能的形式体现。
从起点的数据接入，是否可满足海量数据抽取；到数据存储的冷热分离、数据加密、数据压缩；再到数据计算的异构计算等等。很多都可以去灵活扩展，可通过特定规格或功能项来丰富产品的能力。
5). 第五阶段：使用弹性
到了这一阶段，则更加贴近用户的实际使用需求提供弹性能力。比较典型的如AWS提供的“并发扩展”能力，如下段描述。
在实际使用中，可以帮助用户起到“削峰填谷”的作用。用户不在因偶尔的业务峰值，而需额外购买大量的资源，起到了很好的经济性。这一点很具有优势。
当然还有一种更为极致的情况，即ServerLess方式，用户只为服务付费。例如AWS提供的Spectrum。
当然，这种方式的前提是数据已经存储且所需的服务是低频数据服务。综合上述两种情况，其实已经可以为用户提供很好的使用弹性。
- 对于高频用户，使用前者，购买预留资源，满足峰值压力。
- 对于低频用户，使用后者，无需预购资源，随用随付费。
2. 弹性对客户是个“银弹”？
弹性能力，是未来大的发展趋势，对客户来说也很具吸引力。当用户上云前，面对各大云厂商的产品，该如何选择？面对同一产品，纷繁复杂的规格、特性、功能，该如何去选择呢？这些都是是摆在用户面前的问题，不用简单用弹性方案单一应对。下面是我提供的几点建议，方便客户去评估。
1). 评估业务特征
要想做好选择，首先第一步是做到了解自身。用户当前的数据总体规模、数据增长趋势、数据存储特征、数据访问特征、业务负载模式、技术储备能力等等。这些数据的收集整理，可为后面的评估选型打下良好的基础。特别是数据增长、数据访问和业务负载，这些可直接关联到对弹性能力的要求。
2). 风险承担能力
弹性能力，可能是一把双刃剑。用好了，能帮助企业节省大量成本；用不好，可能故障频发进而影响业务。这里需要企业对相应的风险，有一定的评估判断。简单来做，可做个业务分级，根据不同的业务等级提供不同的保障能力。特别是针对“使用弹性”的方式，要避免将核心业务跑在全弹性的模式上，规避可能的风险。
3). 规划协调能力
弹性能力，对于企业的规划协调能力也提出了一定的要求。在数据使用上，企业应该是有一个中长期的规划，根据自身发展及对数据使用的要求，有计划有步骤地实施企业战略。这对于资源使用上，会有很好的前瞻性，合适扩容？如何扩？扩哪方面的能力？扩容风险？等等，都能做到心中有数。此具体的实施上，还需要协调组织能力，数据在企业内部流转中往往涉及很多部门，如果是有损的弹性方案，是需要提前做好预案。
4). 成本收益评估
使用弹性，更多看中是弹性所带来的收益。针对这个，需要有详尽的估算。算算可能的收益与承担的风险是否对等，是否值得采用。此外，针对使用弹性部分，还需考虑额外的弹性花费，并设置阈值；达到一定程度后，采用预留资源方式更加合理。
5). 使用体验评估
在选择弹性，最为关键的一步评估，是使用体验。各大厂商推出的天花乱坠的弹性能力，是否真的那么美好？弹性是平滑在线的吗？对业务是否有影响？弹性扩展的时长怎样，是否满足企业窗口？弹性受数据规模、业务压力等因素的影响程度如何？弹性失败，是否有必要的预案？等等。这些都是企业在选择之前应该考虑并实际评测过的。只要这样才能做到心中有数，做出合理、最优的选择。
3. 厂商该如何用好弹性
弹性能力，是各大厂商都在追求的核心能力之一。那么，当厂商已经具备了弹性能力，如何更好地为客户服务？如何更好将自己的技术输出到云端？下面是一些建议：
1). 功能评测
弹性能力，对于云下客户来说，还是比较陌生的，需要主动引导客户。把一个比较好的方式就是相关功能的介绍，特别是此功能能为客户带来的附加价值。可以通过一些user guide的方式，输出这些最佳实践内容，帮助客户了解、熟悉弹性能力。充分享受到云端带来的便利。
2). 性能评测
客户考虑弹性，重点会考虑在两个方向：性能和成本。因此，需要厂商在这两个方面给用户足够多的信息。在性能方面，厂商可提供不同规格的性能评测指标，方便用户了解。如果有可能，可针对客户的实际场景，有针对性地进行必要的测试。这里重点是对弹性所带来的负载能力的提升，有指导性的建议。这点对客户很重要，客户可据此制定roadmap，逐步上云。
3). 成本估算
承接上面，在做好性能评测的同时，对成本也要加以估算。方便用户了解弹性能力，为他带来的实际收益。厂商可根据自身经验，为客户制定“质优价廉”的方案，而不是让用户自己来选择。
4). 风险评估
没有方案是银弹，弹性也不例外。用户选择弹性，必然要有其一定的风险。信息的不对等，是对于客户来说最大的障碍。这就需要厂商根据自身产品的实际情况、优劣势分析，给客户客观的评估，而不是一味夸大自己的功能。对于SLA、RTO等指标，要有专门的说明。
5). 业务评估
厂商可主动收集客户的使用特征，包括规模、增长、热点等。根据这些信息，有针对性地为客户提供解决方案。为客户做出选择，做好铺垫工作。同时，必要的前期业务评估，也有利于后期的实施及可能的问题解决。
6). 效果评估
客户在使用之前，是很难评估到使用效果的。最理想的方式是“引导+试算+试用”的三部曲。即引导客户选择，评估用户诉求、试算可能的方案，加给出试用效果。通过这样的方式，给客户明确的信心，也有利于客户充分了解产品。
