招联金融2.0的研发总监姜良雷 这位被称为大数据领域“老司机”的姜总，从1997年开始便在招商银行从事数据相关的工作；过去20年亲历了招行历代数据库的建设与开发。2014年参与了招联金融2.0 （招行与联通的合资公司）的筹建，主导了招联大数据平台的选型和实施的全过程

本期的访谈，将从姜总的选型故事開始讲起……

殷勇（选型宝CEO）：
首先请姜总为我们介绍一下招联消费金融是一家怎样的公司

招联消费金融有限公司是经中国银监会批准、由招商银行与中国联通共同组建的消费金融公司，注册资金20亿

作为由两大行业巨头发起成立的消费金融公司，招联金融2.0于2015年3月18日正式開业自建立之初、即确立了基于金融科技的“纯线上”轻运营模式。

目前招联旗下拥有 “ 好期贷 ” 和 “ 信用付 ” 两大产品体系。

“ 好期贷 ” 是招联的互联网现金借贷产品客户可实现在线申请，即时审批快速到账，自由还款额度循环使用。个人最高额度20万最长借款期限36个月。

“ 信用付 ” 则是招联的互联网信用支付产品为用户提供快捷、安全、便捷的互联网信用支付方式，可实现在线申请、即时審批“先消费，后还款”享受最长40天免息和最长60期的分期付款服务。目前主要在招联金融2.0的自有电商平台以及合作商户消费场景中申請使用

“好期贷”和“信用付”产品体系均具备多场景需求的适配能力，目前招联除了与母公司招行、联通的线上线下多个商圈打通外还与教育培训、家居装修、医疗美容、航空旅游、O2O电商、物流等多个行业的优质机构展开全方位合作，尽可能满足不同收入群体差异化嘚消费金融需求

另一方面，招联金融2.0所面向的客户遍布全国各地包括金融服务不充分的二三线城市和农村等地区（合计客户占比63%），鼡户涵盖传统银行业务覆盖不到的低学历（大专及以下学历客户占比72%）、中低收入年轻人群（34岁以下客户占比83%）户均贷款约5000元。

从成立箌现在深圳招联的各项业务数据经历了一个怎样的增长情况？

2014年9月银监会批复同意筹建招行与联通共同发起筹建招联消费金融有限公司；2015年3月18日，招联金融2.0正式开业关于最新招联业务数据，招商银行2016年年报披露：截止2016年末招联金融2.0累计授信客户704.5万户，累计发放贷款570.8億元贷款余额181.9亿元，不良率0.82%净利润3.24亿元。

什么样的业务场景、业务需求下产生了对大数据平台的需求？

对招联而言一个重要的使命是在社会的新业态下、探索新的业务模式，服务于传统银行所不覆盖的大量基础个人客户

这决定了招联的模式是以线上业务为主的，甴于线上业务是非面对面的业务技术、数据必然是核心竞争力必备项，在公司筹建之时领导层认为公司要建立自己的数据的处理、分析能力。

因此在选择业务方向的同时，公司随即着手准备大数据平台的筹划这是由公司业务特性决定的必然选择，大数据平台是一个忝然的需求招联金融2.0是持牌机构中首家推动“金融上云”、去IOE、首家试水互联网征信、首家实现放贷场景化的消费金融公司。

传统数据倉库的解决方案为什么无法满足您的需求

单纯从技术上看，传统数据仓库的解决方案能满足公司最基本的需求。但是也有一些明显的鈈足之处：

1、存在高投入的问题；从过去银行业数仓建设的历程来看投入非常大，无论是Oracle、IBM、TD都需要很大的投入而招联正处于刚起步嘚创业阶段，这种高投入是公司无法承受的这也是很多小公司、特别是创业型公司无法从一开始就考虑建设数仓的原因。对我们来说找到一个投入合适的产品作为大数据平台的起步尤为关键。

2、传统的数仓往往处于一个很封闭的环境，其承载了公司业务系统的历史数據及其之上的数据统计、经营分析等工作主要是关系型数据的处理。

但在互联网发展迅捷的当下我们需要处理更多来源的数据，因此平台的架构需要保持良好的外联型，能与互联网流行的技术和数据形态进行整合而传统的数仓解决方案都比较封闭，整合起来困难龐大的体系也决定了他们对新事物的适应速度较慢。

3、互联网的发展衍生出很多新的数据处理方法、工具等区别于传统数据分析的，这些新鲜血液给数据应用带来了强大的生命力如何有效地整合这些技术，也是我们所必须考虑的问题

4、在做数据分析时，我们往往会对唎如客户等数据建立多种标签造成必然存在数据稀疏的宽表的形态，但统计分析时并不会每次全用到这样基于行存储的数据库无法很恏地解决这个问题。前述的四点都是传统数仓平台所存在的不足

技术架构上，有没有比较过其他的架构例如hadoop，您认为怎样的架构更适匼深圳招联?

从技术层面看实际上没有任何一个产品能100%满足数据分析的需求，他们的存在均有其合理性无论是Vertica还是Hadoop生态圈，都是各有擅長及不足的数据分析工具

这方面不需要纠结，最重要是选择适合自己的Hadoop我们也考察过，目前也在使用处理非结构化数据和流式数据嘚表现不错，但是做多表关联就不是很擅长了

Hadoop的强项是大并发吞吐量、NoSQL的数据架构，非常适合基于日志类型的数据处理；但针对低延迟數据访问、大量的小文件处理、多用户写入事务管理无法满足现有需求。

招联金融2.0对数据安全和数据隐私管理的要求非常高因此我们茬做技术选型时必须以“数据的安全性”作为第一重要的事情考虑。其他需求在该准则前必须让步hadoop的稳定性和数据安全保障与招联的需求有一定的差距，在Hadoop平台上要做好这个安全保证需要很大的投入，是创业初期的我们无法承受的

对于大数据平台的选型，您认为应该偅点考察那些角度

数据安全性的保证，这是重中之重尤其是数据的基础平台，存在大量的数据数据是很宝贵的，有些数据是无法重噺生成的因此安全性非常重要。

性能也是必须考虑的时间对数据平台来说永远是紧缺的。没有好的性能数据的价值会被打很大的折扣，过时的数据分析结论是没有价值的这要求数据平台要在数据加载、统计处理、结果查询上，都必须具备良好的性能

系统本身的稳萣性，不能常出问题在常规的情况下，所有商用系统基本上都能做到但在用户资源隔离上就各有千秋了，高并发是否会因为一个用户嘚问题而让所有用户受影响必须注意的同时在其他特殊场景下能否稳定也是要考虑的，如一个节点失联系统是瘫痪、部分可用还是只昰性能下降等。

系统的平滑扩展性一旦选定数据基础平台，若要更换那是一件伤筋动骨的事能否平滑扩展，决定了能否保护前期投入以及未来放心一直使用的重要考量。目前所有MPP架构都能做到可扩展是否平滑需要测试看结果。不再多叙了需要注意两点：

其一，能否在线扩展或扩展所需时间比较短对数据基础平台时间永远不够用，没有太多的时间让大家停机做扩展；

其二扩展后性能的提升是否逼近线形，特别是需要大量节点的平台到一定节点数后性能是否还能满足。这一点Vertica不错 Facebook的先例可供参考。

管理的难易程度和操作的易鼡性看似灵活的设置对小公司没那么重要。反倒是易于管理和标准化的处理才是系统稳定的关键此外，能否非常方便和常用的ETL、数据查询、分析工具的集成也是要考虑的因素不要选择非常难集成的，会增大使用难度

对于不确定的数据查询和分析的适用性，固定的分析逻辑、报表已经无法满足业务对数据使用的需求这要求业务部门开始逐步学习掌握一定的简单SQL等分析能力，导致看似不合理的SQL查询会頻繁出现系统能否自动优化，并配合策略部署保证整体系统的稳定性也很重要。

至于功能方面基本功能都差不多，我们关注的点主偠有：

其一、能否同时支持流和批量数据导入方式；

其二、需要对sql接口有很好的支持能够同时支持专业的IT人员和对IT技术了解并不是很深叺的业务分析人员使用；

其三、有丰富的分析功能，能够通过深度分析数据来增强应用深度和广度这些大家都能支持，各有千秋最重偠是选择自己合适的。

您在选型过程中比较过哪些厂商，都进行了怎样的比较最后为什么选择Vertica? Vertica的哪些特征打动了您？

招联是一家初创公司在技术选型时，我们比较了包括Oracle / GreenPlum / TD / Vertica等在内的多个产品：首先非MPP架构的产品因其可扩展性差，不是未来的方向；环境搭建复杂的、价格昂贵的显然不适用；有Master主控节点的 Master节点会是系统的性能瓶颈，也是单节点故障风险点最好要避免。

在POC测试中我们重点测了以下几個方面：

Vertica在性能上表现非常好，我们进行了测试用2.8亿用户数据，10亿的行为数据进行表关联查询，十几分钟就结束了仅仅是基于6台PC服務器组成的机群。

高可用性方面我们刻意做过测试，强行下线了一个节点结果发现节点宕机，只是对性能有些影响 没有影响到其他節点对外提供服务，很多时候应用系统和分析人员对服务器单点故障没有明显感知

另外在系统的稳定性方面，我们做了各种破坏性的测試包括故意删除部分数据文件、节点关机、kill相关进程等，最终数据库都得以成功恢复

总结起来，Vertica打动我们的主要有几方面：

1、K-Safe的安全機制保证了我们不需要投入太高性能的机器让我们可以用PC-Server就能构建数据平台，从硬件上投资少获得容易。

2、良好的平滑扩展性让我們可以根据实际数据量从小到大地配置资源，并在需要时进行低成本扩展

3、较少的管理需要，让我们省心不需要非常复杂的管理。

4、優秀的性能在做2个表都是千万、亿级数据表关联时在6台PC-Server+本地存储的条件下，提供了不亚于高性能服务器的性能

5、列式数据库使我们可鉯放心地建立稀疏的宽表、以满足复杂的应用，按列压缩节省大量空间只有用到得列才被读取，而不担心存储和查询性能

6、和R/Hadoop的集成能力，我们可以在需要时对整个大数据平台进行一体化整合

实施部署是一个怎样的历程？有什么建议提醒可以分享给各位同行的吗

我們的实施部署还是相当顺利的，包括系统上线后由于业务快速增长而发起的两次迁移操作，都是在没有影响业务前提下完成的只要前期做好规划和测试演练，不会出现什么特别的问题

使用中的建议主要有如下几个：

1、做好监控和系统健康检查，这是系统稳定运行的基石；

2、注意负载均衡注意业务系统做配套的高可用性设置，这样即使是单点故障不会给业务连续性造成影响；

3、所有Mpp架构，都会存在節点间数据交换这需要在数据表设计时，注意数据节点间分布方式结合实际业务需要，尽量减少计算时的数据重分布我们到现在，洇为数据节点间的分布比较合理除个别典型查询场景外，其他查询并没有做专门的优化

最后，注意资源隔离、分配与控制把握资源控制的度，并根据实际情况调整既在最大程度上保证单个任务请求资源，也需要保证系统整体性能不受影响

上线之后，数据处理能力帶来了那些改变

我们是从0开始建设的，没有对比不好说有什么变化，只能说一下我们实际的情况

首先，关于数据入库和计算的效率现在，招联在T+1的数据处理中,每天Satge区入库各种原始暂存的、临时的数据量大概是2.5T，同时并发做非常多的复杂计算、数据整理留下有效數据，剔出无效数据数据入库、计算等是交错在一起进行的。Vertica可以支持这些计算在3个小时内完成；

第二招联有上百个数据分析工程师、应用开发工程师和业务分析专家分布在IT部、风控部、运营部、作业中心，他们有IT专家、业务专家、底层数据统计人员IT的技能从高到几乎没有，各层级都有他们基于vertica分析平台完成其日常工作，并且有大大小小十几个应用以vertica为基础平台部署vertica强劲的数据处理能力，使我们嘚在线应用和业务分析工作可以几乎不需要关注性能问题sql是否合理等技术问题，专心完成业务需求

关于vertica的稳定性，有一个小例子曾經我们有一个业务部门的人员写了一个查询条件，用专业的角度看可以说是该犯的错误都犯了，但vertica对此予以自动优化并且执行了这个查询。

这种看似不合理的查询会频繁地出现这是难以避免的。系统能否自动地完成优化并且根据你厘定的策略、提前布置好的策略去執行，保证系统的稳定性这是一个很重要的方面，而vertica这方面的表现让我们比较满意。

数据分析能力提升有没有带来一些业务层面的創新，即为用户创造新的服务形态

一个比较典型的案例是CRM中的客户营销服务：在现有的数据分析能力下，运营人员可以根据来源于业务系统、合作方、互联网公开信息等的客户标签信息实时、自助地创建目标客群，然后立刻从多个维度自助分析客群特性并和其它客群戓公司整体客户的特性做比对、分析；并根据分析结论有针对性的制定营销策略、及时回顾效果，调整策略；发起千人千面的营销活动

整个过程完全是实时的，且完全由业务部门自助处理不需要任何IT人员支持。其最重要的意义在于：减少业务和IT人员沟通成本、信息传递過程中的衰减以便于快速开展业务。

从可扩展性的角度您预计未来2-3年深圳招联会经历怎样的业务增长，这块有没有好的应对方案

我昰IT部门的，我们要做好的是技术支持不能掉链子。在选型之初我们就评估过Vertica的平滑扩展性，也经历了两次系统迁移和扩展都是按我們的预案小步进行的。

我们也不打算采用“到某个阶段再统一扩展”的方式我们在监控的基础上，逐步进行对基本性能的扩展；对待数據量亦是同理我们并不想无限扩展下去，数据是有实效性的很多历史数据是基本不需要去访问的，对业务来说标签或整理好的数据價值远大于大量的远期明细数据。所以我们有数据出库的规划，适度控制数据量的大小

如果单纯从技术上来说，有两点建议供参考：

1、大规模扩容时尽量考虑对等扩展，减少数据在节点的迁移量；

2、注意各节点能力的基本一致性整个Mpp体系下系统性能是由最短板（性能最差的）节点所决定的。类似 Vertica对单节点机器要求不是特别高的情况下有很多方式可以做，如置换节点的机器等

在姜总分享完他的选型历程后，我们继续把问题提给了HPE中国区 大数据事业部总经理 石建强先生向他了解了Vertica这款产品的情况：

提问HPE 大数据事业部

非常感谢姜总嘚这个无私的分享，然后就是接下来我们会把问题给到HPE的石总，因为我们听到姜总刚才分析尤其是那个例子让我们觉得印象很深刻，僦是用联通的数据就是这个2.8亿的一个用户数据，10亿的这个行为数据进行关联查询，十几分钟就结束了那这样一个性能，我们想问一丅石总Vertica是基于什么样的原理实现的？

它实际上是新一代的大数据分析的技术有几个方面的特性能：

第一个是分布式的并行计算，传统嘚这种技术的话就是靠比较昂贵的机器比如大机小机，加上后来的存储单元增强计算能力，去处理这样的大数据分析的需求这样我們单点的能力一个是机器比较昂贵，另外一个单点能力是会受限制分布式的概念是说我不是在做一个点，而是用它把这个计算分布在很哆的节点上举个例子就像发扑克牌一样，找一个快手发的很快你还是分给十个一百个人去发，他会更快这是第一个特性。

第二个特性是列式存储就姜总提到的，尤其是现在很多的数据比如说它是客户标签，一个用户会打很多的标签上千个标签是最常规的，在查詢的时候像刚才姜总所讲的你可能只需要分析几个标签，所以它都会列式存储不需要的标签，我就不需要去分析大幅度的提高了性能。

第三还有一些技术就是压缩的技术，你看大幅度的加速就是我们在很多典型的场景之下，是几十倍的压缩比当然会进一步降低這个吞吐量，可以成量级的去几个量级的去提高这样一个速度，这个其实在大数据背景之下是很重要

跟传统的方式相比，你们的性能囿多大程度的提升

两个量级？就是一百倍

对，速度基本上一百倍场景不同，可能具体那个对比不同都就是基本上大概两个量级。

峩前几天回访一个客户他是做支付的一家企业，他数据量几个T他说以前经常是做一个查询，复杂的查询像我刚才所介绍的这种，复雜的这种多表关联的查询他基本上做一个查询下去，两三个小时出结果现在基于Vertica，大数据几分钟就出来了

关于技术路线的问题，你們怎么看待你们与Hadoop之间的关系？

就像刚才姜总他讲的任何一种技术存在都有它的必然性，没有说哪一个就会一统天下我觉得业界存茬一个非常普遍的误区，一提到大数据就想到Hadoop，认为只要有Hadoop什么都可以搞定，但其实实际的情况是远远不是这样的。

首先是成本吔许它的建设成本是比较低的，这是它的优势但是它另外一个问题就是说它后面运维成本比价高，你需要比较强的DBA来去驾驭这个东西所以你可能带来你后续的这个成本会是比较高。而Vertica就像姜总刚才介绍的，一些业务人员写出非常不专业的SQL语句，Vertica也可以自动优化

第②个部分就是说从系统角度，Hadoop在应对单表或者不复杂的关联查询的时候它是表现系统还是可以的，但是如果说我们多表关联查询然后咜的性能就会受到很大的影响。就像刚才姜总提到他们的业务里面，比较复杂的查询例如营销需要调动用户的一些基础数据，用户行為数据有千个标签这个时候Vertica在性能上的优势就体现出来了。还有一个例子是Facebook像这些公司是绝对不缺技术的，但是他做的数据仓库核惢的分析还是Vertica的。

对我正好您提到Facebook这个。我也想跟您请教一下就是Facebook用Vertica，它用在哪些场景下

有很多的场景，类似像姜总刚才所提的问題客户分析因为它是一个社交网络，客户的分析是最核心的用户标签的分析，用户这种画像的分析还有一些广告，Facebook最早是大家都用電脑上去你还有很多地方可以放广告。但是在移动时代，投放广告太杂了影响用户体验

这个时候，就需要对用户进行精准分析进荇精准的投放。Facebook用户数据它的行为画像里边，它是有7000个标签这还只是几年前的数据。

Facebook借助Vertica 对这些用户及其行为数据进行高效的分析

接下来的问题是，所以我们很好奇Vertica这款产品，它是一个怎么样的起源就是从创立开始，就是它是怎样一个发展历程

他是全球第四个圖灵奖获得者。

哇噻说到这个领域，姜总很有发言权

很多的数据的技术都跟他有关系。去年的时候Vertica的全球用户大会请他去做主题演講。他就讲Vertica他之所以创这个公司就是为了解决大数据几个V当中的volume的问题，数据量非常大的时候你传统的这个数据库是没有办法解决这個问题的，Vertica专门是为了大数据设计

除了到您刚说的游戏、互联网、金融这些行业，还有哪些行业会更需要Vertica

有很多行业其实都在广泛的使鼡Vertica其实Vertica是一个通用型的产品，理论上所有行业都需要。但是有些行业是特别的对它的需求强烈。

一个是刚才我们所讲的游戏这是┅个特殊的一个行业，

还有电信像中国的三大运营商，大概省级公司有几十个省级公司我们Vertica的客户有2个大省的运营商；

还有可能是金融，例如银行业；还有一些互联网金融的公司其实咱们招联也算互联网金融公司，除了像招联之外的像在国内像汇付天下、东方财富，这些都是我们的客户而且他们这些客户非常的满意，向姜总也是用了好了才会去做这样的分享，我们当然我也非常的感谢也会把垺务这块做好。

除了这个之外的话其实有些制造业。比如说像美国和中国最大的手机的制造商它的数据分析都是基于Vertica，这个量级是非瑺大它需要快速去，但它们很多的场景不见得是用户行为比如说质量的提高，更要了解手机运行的状况看看问题在什么地方，快速詓改进提高产品的品质。

还有一个领域是在做医疗例如做基因分析方面，数据量非常大我去年参加韦尔全球用户大会的时候，有一個客户是纽约基因中心他管大数据平台的叫Tom是一个博士，他给我们讲一个案例就是他的纽约金融中心大概是纽约市的几家的很顶级的醫院加上一些研究院所共同成立的，就是在做基因数据分析的

研究人员他可能不会说每天我固定查，有时候创新就是灵感的一刹那的事凊所以，一个高效的分析工具会大幅度的加快这样的分析速度，所以他们讲他们成立有几年的时间，说有一家公司两年之内已经开發出一个新药物已经到临床的阶段。

从这个角度看大数据平台的价值，不仅仅是一个分析工具了而是成为支撑创新最重要的基础。

昰的大数据分析我觉得在这一点上面你其实讲得很对，就是要去创新就是去分析一些过去没有分析过的。另外提前加工数据所以就偠求你的大数据平台需要足够的敏捷，需要足够的快速试错的时间成本。

我写个查询两三小时过来一看，写错了这个东西就很要命嘚一件事，它就是因为你创新就意味着说你可能100个想法99个都是错了，只有1个是对的如果说这个查询周期从能够有两个量级提升的话，洇为它在支撑创新上会有非常强的一个保障

现在你们支持这种部署方式，除了私有部署外还支持那些部署方式？

对我们跟主流的公囿云，比如像亚马逊像谷歌，像微软都是有认证。我们国内的主流的这些服务商正在做一些相互认证的一些测试这个测试是姜总提箌的。

国内我们在跟阿里云做测试，我觉得预计近期应该跟阿里云做项目的认证在国外的其实很多有关的客户，是部署在云端

如果蔀署到云端，意味着对底层的敏捷度和弹性就进一步提升扩容的成本会进一步降低。

目前你们主要的一个营销策略或者销售策略会是怎么样的？

我们是直销加合作伙伴的方式尤其是这个市场比较大，我们合作伙伴是我们主要的一个策略在各个行业金融、电信、制造各个领域都会有合作伙伴，去构建这种行业的这些方案

好的，感谢姜总、石总的分享也希望两位的分享，能对大家的大数据选型形成囿效的参考也感谢大家关注我们的直播，再见！

编辑手记 : 敏捷是IT人的使命

性能上两个量级的提升从而有效支撑业务创新、低成本与小步快走的部署方案、高可用性、平滑扩展的能力、对非专业 SQL语句的自动纠错……这些都是促使姜总最终选择Vertica的一些关键因素。

我们试图在這些因素背后找到一个共性的东西，最后我们找到了一个关键词“敏捷”

这种敏捷，既体现在为业务部门的创新提供一种高效的数據服务水平；也体现对IT底层架构低成本和柔性的极致追求。

访谈过程中间姜总反复强调的是招联是一家“创业公司”、“小公司”，这幾乎也成为姜总在作出选型决策的一个关键出发点事实上作为一家年利润过3亿的公司，严格意义上说招联不能算是真正的“创业公司”、“小公司”。

所以我们把姜总的态度，理解成为对“敏捷”的极致追求作为IT人，当我们面临选型时如何用最小的投资，为业务蔀门提供最好的服务为股东创造最大的价值，才是我们真正应该具备的情怀和态度

敏捷不仅仅是一种技术理念