实战云端CRM变革，挖掘零售电商潜能

自从电商开始真实运作的那天，人们便开始关注电商平台上的标准化数据所带来的潜在价值。但要采集和分析这些数据并不是一件容易的事。不同平台上的海量实时数据给数据采集带来了很大挑战，同时数据分析需求的多样性和时效性也急需通用而快速的分析平台支持。阿里云有得天独厚的电商基因，通过阿里内部各类业务需求的历练，其积累了大量的实践经验，特别是在电商平台数据处理方面的沉淀。这使得当我们基于阿里云的云计算服务来处理这些电商平台数据时有一种“回娘家”的感觉。

基于阿里云的数据采集

数据采集并不仅是获取数据并保存好，更重要的是要保证数据采集的商业价值。数据采集的商业价值基于海量和实时两大点。这也就意味着我们不仅要应对几乎无限增长的数据规模，还要保证很高的时效性。具有电商基因的阿里云的各个产品帮助我们紧紧抓住了商业价值的这两点基础。

基于阿里云来解决采集的数据规模不断增长的问题

我们在考虑设计一个可以对应无限增长的数据规模的采集服务时会考虑四个方面。

先看一下我们实际的数据采集的局部架构图，如图1所示。

我们首先会把所有不同平台的卖家进行统一编号。然后根据不同的模来分配给不同的采集程序。采集程序会根据卖家的编号找到对应的库并进行保存。我们考虑到未来的可能性，目前分了64个库，每16个库放在一台RDS（阿里云的关系型数据库服务，可以认为是数据库所在的虚拟服务器）上。

现在就来说一下这个设计如何满足以上四点需求。对于可扩展性，从图1中可以看到，整个采集过程都是按照横向扩展方式设计的。由于数据采集需要数据计算和数据存储能力，所以可以看到，对于数据计算能力可以通过增加模数和ECS来最大扩展到一个卖家一台ECS的比例。对于数据的存储能力可以通过增加RDS来最大扩展到一个库一台RDS的比例。也就是说，在单个电商卖家的数据量没有达到计算和存储能力的极限的情况下，可以几乎无限扩展。

但实际使用过程中，情况会比预先考虑的更复杂，最常见的情况就是卖家数据不均衡，如图2所示。当一个卖家的数据量超过一般卖家几百倍时，该怎么办呢？我们仍然可以用同样的思路来解决这个问题，如图3所示。

对于数据采集的计算能力，我们可以通过增加维度来获得。对于大卖家，不仅可以根据卖家编号取模，还可以根据买家编号取模，这样就把大卖家切成多个小卖家，让不同的采集程序来处理。对于数据采集的存储能力，可以调整RDS与数据库的映射关系让数据库得到更多的RDS支持，最多当然是一个RDS对应一个数据库这样的映射关系。说到这里，还要考虑一台RDS撑不住怎么办？根据实际的使用情况，一台中型RDS一秒钟可以处理200笔订单。如果不存在性能问题，那么这个卖家一小时就要成交72万笔。我们现在接入的卖家订单数远远小于这个数值。

如果考虑的是活动瞬发值，那么就要参考第二个设计思路：快速伸缩的实现。阿里云的RDS和ECS是可以按时间计费升级的，这给我们带来两个好处。一个好处是能够应对波峰波谷的波动。在临时性的数据量增长的情况下，只需要临时升级ECS和RDS即可。横向扩展是一种相对静态的增长方式，面对临时瞬发的活动类波峰变化，只需要付少量费用临时动态升级就可以很好地对应。另一个好处是这给我们留了很大的余地。在横向扩展时，我们默认会使用中型的ECS和RDS，为设备在纵向升级时留出足够的余量，在临时需要更多处理能力时可以一键达成目的。

基于阿里云来解决数据时效性的问题

很多情况下，我们认为数据是静态的，采集过来就好了。而实际上数据时刻在变。如果采集不及时数据就消失了，或如果采集到了但没及时处理那么时效性背后的商业价值也会丢失。下面以淘宝交易数据为例说明及时采集带时效性数据的必要性。

淘宝的原始交易数据从【等待买家付款】到【买家已付款】的变化是在同一条记录上进行的。可能当前是【等待买家付款】的状态，下一秒就变成【买家已付款】，再下一秒就变成【卖家已发货】。如果我们采集【等待买家付款】花了2秒钟，那么【买家已付款】的状态就会漏采集，系统无法做该状态下的操作。例如，CRM提供的营销工具会在【买家已付款】状态下发“亲，我们已收到你的付款，我们会赶快给你发货。”这样的通知。如果漏了这个状态，这条通知就不会发出。那么CRM的商业价值就丢失了一部分，这是难以接受的。

更难以接受的是造成负向的商业损害。如果有一个营销工具会在【等待买家付款】的时候，发送短信告诉买家：“亲，你要的商品我们已经帮你保留了，请尽快付款。”如果处理这类时效性花了10秒钟才处理完成，但在10秒内订单状态早就变成【买家已付款】了。那就会发生给已经付款的买家发送催付的短信，这会让买家难以接受和造成很大的困惑，增加了卖家服务的压力和维持客户关系的压力，造成商业价值的损害。

正因为时效性数据和商业价值的关系非常紧密，所以我们需要花大力气来处理它。这个例子中的营销工具需要根据十几个维度进行筛选后才能决定需要对什么客户发送什么短信。这些筛选维度有原始数据的维度也有统计数据的维度，例如向收货在江浙地区的买家发送短信，这来自原始的交易数据，也有向买过n次的买家发送短信这样的统计数据，这十几个维度的组合按照传统的从数据库查询的方式对数据库的压力极大。如果直接根据数据库性能预判来扩容的话，每个卖家的成本会很高。所以我们通过ECS和RDS之外的阿里云工具来解决。所以基于云计算技术来及时地采集时效性数据和处理时效性数据，我们有三个手段：

最短路径就是将对时效性数据的处理和数据源之间的距离缩到最短。不等数据进入数据库再开始查询和处理，直接在采集程序处开始使用数据。这样能节省其他路径的时间。看起来似乎很完美，但实际上忽略了一个问题，数据库有它的价值，它可以提供数据存储、查找、统计等功能。但不进入数据库怎么查找和统计数据呢？对于涉及到时效性处理的一部分数据，我们用快速I/O的方法来代替部分数据库的功能。

当采集数据还在内存中时，我们通过让OTS（阿里云开放结构化数据服务，可以看做高速的键值存储）或OCS的持久化版本（阿里云开放缓存服务，当使用持久化缓存时，与OTS效果类似）作为中间存储来进行实时的数据统计和计算。第一次的时候将采集数据存入中间存储，随后每一次都根据本次和之前的值进行统计和计算。OTS可以达到10w级别的QPS，与RDS整整差了一个级别的性能。OCS与之类似。因此，可以将OTS和OCS看做性能弱化容量无限的持久化内存存储。在实践中，我们在中间存储数据的计算上，每一条数据只有不到0.1毫秒的性能损失，这样可以避免时效性数据处理时的n次聚合查询和普通查询的负担。不过这里还少说一部分。OTS和OCS持久化存储都可以理解为键值存储，它可以用来存储特定维度的数据，但不能进行多维度查询。例如可以将某一卖家和某一买家的组合作为键，这个卖家和这个买家的统计信息作为值来使用。但不能进行之前说的1x维度组合查询。所以我们更进一步地使用图7中的方法得到自由维度查询功能。

我们将需要的原始数据和它的统计信息变成一条数据库记录，这样不但可以自由组合查询维度，而且避免了n次普通查询和聚合查询的消耗。例如，我们将一次交易的原始数据和交易双方的统计数据一起保存成一条宽表记录，这条记录会有如买家A在卖家B这里买了什么，付了多少钱，这样的原始数据，还会有这个买家在这个卖家那里一共买过多少次，至今付过多少钱这样的统计数据。通过这样的手段把可以n次的查询缩减为一个查询。

不过问题还没完，我们所做的一切都是为了快速处理时效性数据。只是按照刚才那样做的话，随着宽表的数据量的增加，查询速度会越来越慢，并且由于维度是自由组合的，数据库索引并不能解决问题。另外，宽表中的信息来自多个表，这些表可能存在多对多关系，例如刚才的一条记录中会有像是买家A在卖家B买了什么，可能是多个商品。在一般的关系中，一个交易的ID和商品的ID是一对多关系，那么把它们合并到一条记录中就只能把多个表的相关信息并列成一个值放入宽表中。例如用逗号分隔商品1、商品2、商品3，对于这样的多值维度，用数据库的like效率很低，因此我们引入了搜索引擎来处理这个问题，如图8所示。

根据分词符号和分词词典将一域多值切分后，与其他查询维度一起，通过倒排文件把需要查找的维度进行交并处理。这样就可以解决数据库索引不支持多维组合和一域多值查询的麻烦。当然，搜索引擎从RDS中抓取数据后建立索引需要额外的时间，为了既得到搜索引擎多维组合和一域多值的分词好处，又尽量减少搜索引擎从RDS中取数据建索引的时间消耗，我们可以让本来要存入RDS的记录先进入搜索引擎，再写入RDS，而不是让搜索引擎在写入RDS后，再读取一次。这样可以节省一些时间。我们会尽量满足两边的要求。到现在，就算对于时效性数据的处理非常复杂，也可以在数据失效前完成处理。

至此，数据采集的两大问题终于被基本解决了。现在来看CRM提供的另一项重要服务----数据分析。

基于阿里云的数据分析

由于数据分析往往基于特定的场景，很难找到通用的模型，所以在此并不打算介绍具体的数据分析。而是将我们遇到数据分析的类型和阿里云产品的解决方案放在一起进行介绍。

我们在数据分析时会遇到四种场景，如图9所示。越往下需要的代价越大。简单指的是需要得到的分析结果依赖的过程较短，例如对热门商品的排序，只涉及一个排序查询；或者分析男女购买的比例，只涉及两次聚合查询。如果像刚才那个数据采集中处理时效性数据的场景，需要1x次查询包括聚合查询，那就属于复杂分析。实时指的是，数据分析的结果依赖于到目前为止的数据，同理非实时就是数据分析的结果依赖于某个固定区段的历史数据。例如前一天的，或前一年的。对于这四种等级我们有相应的处理办法：

1.简单非实时的情况（图10）分两类，因为是非实时的，可以理论上预先计算。但预先计算需要满足一个条件，就是数据查询的维度组合是有限的，或者说是不能过多的。例如查询维度是前一天的男性购买次数，这是可以的，但如果需要分析的维度不仅有时间和性别，还有年龄、名称、收货地址、电话号码和邮箱之类的组合，就会预先计算过多的报表，以至于还不如实时统计查询。

2.对于第2等级，简单实时的情况（图11），我们考虑两个点：一个是这个简单实时的分析调用频率如何，另一个是客户对这个简单实时分析的敏感度如何。对于调用频率高的分析，我们需要对结果进行缓存处理，以免无谓的高频多次调用。另外，对于客户实际敏感度不高的分析，我们可以人为将实时变成半实时或非实时的。例如对于热门商品的分析，客户并不会像看股票一样一直盯着，虽然理论上热门商品的列表需要的是实时结果，然而实际上在1小时内无论客户分析多少次，热门商品在一小时内都不会重新分析。这其实和对高频率查询的解决方式是一样的，只是切入点不同，高频是为了避免无谓的查询，例如某些数据变化的最小时间间隔是10秒钟，10秒钟内查询无论多少次，结果都是不会变的。而根据敏感性来降低实际的分析次数是基于客户对数据实时性的实际需求来做的。只是两者的目的不同。无论怎样，缓存（OCS）是分析的好帮手。

3. 当组合维度有限时，复杂非实时查询（图12）和简单非实时查询是一样的，例如可在半夜计算当天的分析需求，在第二天来使用。但如果分析的复杂度很高在一个晚上算不完的话，那么简单的半夜分析结果的方式就行不通了。ODPS给了我们很好的解决方案。我们每天定点将数据上传至ODPS，整合后通过ODPS分析，可以大大缩短计算时间，再复杂的查询计算，几乎都能在20分钟内拿到结果。这让我们感觉到复杂非实时分析不再是一个根本性的问题。

4.复杂实时的查询是非常苛刻的，真正的场景并不多，但还是有。例如，之前在数据采集中说的那个基于1x次包含聚合查询的时效性数据处理，就可以算是复杂的实时的数据分析。解决方法前面讲过了，依靠OTS、OCS、TIS（索引查询服务）和ECS的计算能力是可以进行不限维度的复杂的实时数据分析的。其实对于这种场景，单纯的某些方法和服务已经无法解决了，需要依赖具体的业务场景，从快速存取、快速计算、快速查询等方面去组合，将计算、存储和查询都保持在一个非常高速的通道上，达到一个非常实时的效果。

对云计算的一点感想

云计算带来的影响

我认为，云计算的产生和普及为解决软件业中永恒的难题――“复杂度”找到了一条可能可行的路，并且由于对此致命难题的撼动而产生深远的影响。

云计算带来的新机会

随着云计算的发展，软件的业务部分和基础技术部分会越来越分离，加上竞争的平等，使得问题变成了“怎样做业务创新，怎样用好云”，而不是“技术能否撑得住业务，要不要用云”。在这个背景下，能理解业务同时有基于云产品快速架构系统能力的架构师会变得更加重要。同时创新企业会越来越多，越来越多的人不用再专注于技术本身，而是有更多的时间站在技术和业务之间，思考怎么快速用云产品提高业务能力。