作为互联网金融领域的先行者，成立于2009年底的阿里小贷发展初衷即是为淘宝和天猫上的卖家提供小额贷款业务，实现“让天下没有难做的生意”的目标。伴随产品形态的丰富，服务对象的扩展，小贷业务增长迅速，平均每年增长速度在四到五倍左右。经历了近5年的发展，已有超过36万人从阿里小贷借款，最小贷款额为1元。

与传统银行不同的是，阿里小贷重塑了一套信用评价体系和信用概念，其小额贷款模式不需要抵押物，是纯信用贷款。信用从何而来？来源于贷款者线上经营信用数据、财务数据等等，阿里小贷对贷款者在互联网上积累的海量数据进行分析予以授信。数据成为阿里小贷业务模式的基础，也是核心所在。究其根本，这是一笔数据生意。这笔数据生意，从第一天起，就根植于阿里云计算飞天平台之上。

数据驱动增长，掘金阿里数据

“3分钟申请、1秒放款、0人工干预”，这是阿里小贷独有的一套高效工作模式，这样的高效有赖于其背后独特的业务模式，它将是否放贷、贷款额度和风险评估等传统银行最为看重的业务环节完全交给了大数据处理平台。阿里小贷数据仓库的总共数据量十多PB。每天处理上PB的数据量，包括店铺等级、收藏、评价等几百亿个信息项，运算上百个数据模型，甚至需要测评用户对假设情景的掩饰和撒谎程度。最终用户能否申请贷款、能贷到多少钱，完全依靠的是大数据平台为其计算出来的信用值。这些无疑对大数据处理平台的可靠性、安全性以及计算的准确性提出了极高要求，算错一笔可能就会造成比较大的资金损失。

为了确保数据计算的准确性，阿里小贷要从各个层面去挖掘申请贷款的卖家或者消费者的信息，这个过程几乎会用到整个阿里集团包括淘宝、天猫、B2B和1688等多个业务部门的数据，以及集团外部的社会征信数据。这也使得阿里小贷聚集了多个项目的技术骨干。其中，负责阿里小贷数据仓库的基础模型和基础平台建设的架构师陈鹏宇和负责早期运维工作的资深经理张国保就是项目中重要的技术负责人。近日，他们深入分享了阿里小贷技术演进历程。

据他们介绍，小贷业务目前每天从外部同步过来的数据量上百TB。数据同步过来之后要经过小贷数据仓库的三层加工，加工结果以指标（输出模型要用到的离线变量）的形式传递到阿里集团的通用决策系统AGDS。通用决策系统能够支持上万种数据仓库提供的离线变量，包括买家、卖家及店铺交易等所反映出的众多数据。此外，它还会从其他系统获取一些实时信息，如卖家当前的交易情况、具体的处罚情况等，并结合这些实时数据和数据仓库的离线变量动态计算卖家的风险程度和授信模型。因此，通用决策模型是小贷真正的业务引擎，其上大约有几千条规则，可以理解成一条有几千变量的公式，能算出卖家的最终授信模型。在放贷系统申请时，这个引擎就能告知它是否可以放贷、大约可以放多少钱等。这便是小贷依据数据计算做业务决策的整个过程，如图1所示。

此外，阿里小贷的业务特点决定它对安全性和实时性也有很高要求。阿里小贷使用了多方数据，包括集团内部的数据以及其他合作伙伴提供的数据。这些数据都高度敏感，阿里小贷作为使用方有义务确保数据安全，因此对平台的安全性有较高要求。而且发放贷款之后，要做好贷后监控。小贷通常会根据贷款人的网上行为数据，对其信用风险进行评估。这种评估做得越及时，就越有可能在出现异常时提前发出预警、挽回损失。而准确性、安全性和实时性等阿里小贷的核心业务特性都得到飞天平台的有力支持。

根植飞天平台，业务迅猛增长

由于阿里小贷的业务与数据相生相依，伴随数据来源的广泛增长，数据库会越来越庞大，任何传统数据平台都没有能力支撑这种业务模式，同时，前文提到的阿里小贷对准确性和安全性的严苛要求，当时业界并没有成熟的解决方案，结合云平台在存储和计算方面可以提供的强扩展能力，阿里小贷成为“飞天”平台的第一批用户，并见证了飞天平台的每一步成长（如图2所示）。反过来看，也正是“飞天”这样强大的云平台，才能支持小贷平均每年四到五倍这样近乎野蛮的业务增长速度。

2010年4月10日小贷业务第一款基于“飞天”的贷款产品――淘宝订单贷款发布，只面向杭州地区提供服务。那时的飞天集群只有30台服务器，小贷业务用了两个集群，数据处理引擎是SQL Engine 0.2。两个集群同时运行相同的业务，计算出结果后，需要人工将计算结果备份到另一个集群。同年9月，阿里小贷决定将业务开放到全国，然而在一切准备就绪时，发现当时的集群规模无法支撑那么大的计算量。这时，飞天团队做了一件当时看起来很了不起的事，将集群规模从30台扩展到100台，SQL Engine 0.2升级成0.8版本，保障了阿里小贷在2010年11月顺利将业务扩展到全国。

2010年底，阿里小贷的贷款模型由原来的两个（授信和贷后预警）发展成十个。大家逐渐发现，要想支持这么多模型不能再采用烟囱式的方法，因为拿到数据后要走很长的加工链路，才能得出要用的指标。这时，需要有一个底层的公用数据库，于是大家开始动手建数据集市。此时，又遇到了跟当初扩展全国业务一样的问题，集群处理能力再次受到挑战。飞天平台再一次做版本升级，将数据处理引擎从SQL Engine 0.8升级成Data Engine 0.2，Data Engine 0.2有两项重大突破：1.存储压缩，压缩比可达到2~5倍；2.计算性能大幅提升。最终，集群规模瓶颈被成功突破，飞天为阿里小贷性能提升提供了足够的存储和计算能力。

随着业务的发展，数据挖掘项目对阿里历史数据的需求越来越大，有些项目甚至需要从2003年淘宝成立以来卖家的所有数据中去挖掘信息，这便对数据跨度和质量提出了很高的要求。于是，阿里小贷开始构建大型数据仓库，但这无疑给飞天提出了更大挑战，尤其是在稳定性方面一定要有所保证。ODPS的研发开始，将Data Engine与运行于云梯1上能支持1500台服务器的莫邪合并，将莫邪作为ODPS的数据处理引擎。同期，飞天将集群服务器规模扩展到千级别。这时对阿里小贷来说，等于ODPS将飞天平台包在了底层，主要由ODPS来对阿里小贷的业务提供支持。

2012年初，集团开始将数据魔方、淘宝指数、Tcif等重要业务从Hadoop集群迁移到ODPS集群上，从一定程度上解决了一直困扰阿里小贷的数据共享问题。此前，阿里小贷共享集团数据时大部分要到Hadoop集群去取，数据同步、上游数据复制、下游时间衔接等都有可能出问题，很难保障数据产出的质量和稳定性。

业务迁移完成之后，开始在ODPS集群上建一个集团的数据中心，也就是ODS层，专门汇总阿里各个业务部门的数据，然后在其上提供一个基础的统一数据服务。总的来看，对比Hadoop，ODPS优势很明显：

5K出现，平台和技术走在业务前面

集团的ODPS数据中心和阿里小贷的业务系统放在同一个集群中，必然造成随着业务增长争抢资源的现实。但如果将数据分开存储在两个集群的话，又与之前将数据从Hadoop集群拷到ODPS集群来计算并无二致。这时，扩展飞天集群规模成为必然之选。也是在这个时间，“飞天”已经迈向5K时代，平台和技术的发展走在了业务需求的前面。

提到飞天5K，除单集群规模由1000多台升级到5000台之外，其实还有另一个更重要层次的意义不能忽视，这5000台并不是一个天花板，ODPS集群之间有很强的跨集群复制能力，确保了集群之间很好的连通性、数据有更好的共享性。现在，ODPS数据中心已搬到另一个飞天5K集群上，但得益于5K的跨集群复制能力，使得ODS层可以为多方提供数据而无需显式拷贝，用户感觉不到集群的变化或数据传输延迟。

2014年7月8日，ODPS正式开放对外提供服务。此前，ODPS一直是阿里巴巴内部的秘密武器，第一个用户就是阿里小贷。传统的数据仓库一般都搭建在Oracle等关系型数据库上，而阿里小贷搭建在飞天平台上，所以必然会要求ODPS能提供很多关系型数据库的功能，例如，存储过程编程能力，以及很多数据分布的开放函数和数据分析函数等。这在技术上非常有挑战性，因为在ODPS这样的分布式框架里解决这些问题要比在关系型数据库中难很多。ODPS比较逼真地模拟了传统RDBMS的物理表和视图概念，包括存储分区都很像Oracle，能支持很多传统数据的功能。

然而，在ODPS上构建一个大型数据仓库的过程中，仍然有一些地方需要注意，这里分享一个最为关键的点――数据管理粒度的划分，即ODPS和Project的划分。基本上可将ODPS理解成一个数据管理的基本单元，常见划分粒度的方法有几种：按照层次分成几层，每层一个Project；或者整个数据仓库为一个Project；或者每一个主题数据为一个Project等。这个粒度划分对于后期的管理成本有非常大的影响。但针对不同团队的不同阶段会有不同的划分方案，并没有什么绝对的划分方案，一般会从几个维度来思考：数据仓库所面向的用户范围及数据业务要面向的人群，不仅是开发者，用户也会在数据仓库上直接使用数据；团队内部的协同方式，如何决策和分工；数据安全方面的一些策略，例如数据仓库的基础层可能不开放，那么它是如何对其他系

统做输出的，不同的输出策略也会影响数据管理粒度的划分等。一定要在构建数据仓库之初，将数据管理粒度划分好，因为除非来一次比较大的重构，基本上很难有回头路。

借力云，小企业与大企业同步起跑

从阿里小贷这门数据生意的发展历程不难看出，小贷业务与阿里云之间既有相互磨合，又有相互促进，从而成就了彼此业务的迅速发展。而云计算为小贷业务带来的则不仅仅是平台的支撑、成本的降低，从某种意义上讲，云计算是这种以数据为核心的新型互联网金融业务可以依托的天然平台。

伴随着底层技术的不断完善与持续发展，更多中小企业可以在云计算平台上获得数据存储、数据处理服务，并从而构建丰富的数据应用，云计算使得每一个中小企业具备和大企业同步起跑的底气，支撑更多创新服务的涌现，这是云计算承载的重要意义所在。