挖财资深架构师：如何建立基于大数据的信贷审批系统

信贷的未来在线上，线上信贷和传统信贷有很大区别，难度更大。如何充分地利用大数据进行反欺诈和信用评分，如何使用大数据建立高效的审批核系统，如何在有限的人力下实现业务的指数增长。

本视频时长51分，建议在Wifi环境下观看。

大家好，今天给大家带来的分享是基于大数据的信贷审批系统。首先先自我介绍，我真名是曹静静，花名是叫曹宝，早期在淘宝的数据平台做海量数据的中间件，然后在Morgan Stanley的全球清算中心任职，之后去Ebay搭建了一个亿万级的广告的大数据处理平台，联合翻译了Scala函数编程，本人也是Scala和Spark的爱好者和推广者，现在就职于挖财信贷部门作为研发负责人和资深架构师，负责整个挖财信贷的基础架构和挖财大数据风控平台。

我首先会先解释线上信贷和传统信贷有什么区别，接下来的分享内容会分四点：

1. 我们做线上信贷会面临怎样的挑战，面对这个挑战如何设计信贷的系统架构；

2. 整个信贷分为贷前、贷中和贷后，我今天的分享主要会侧重于贷中和贷后的系统设计，最后会聚焦在贷中的审批系统设计；

3. 其次如何做好线上信贷，我们会用到大量的数据，这些数据如何加工处理使之服务于我们信贷的整体系统；

4. 既然有了系统和平台，我们怎么样把他们结合起来让它们发挥更大的作用。

这张图介绍了现在线上信贷业务和传统银行业务（或者最早的小贷公司业务）之间的区别。

线上信贷业务有一个比较非官方的定义：进件、电销、电照、审批核、放款、回款、催收等行为均发生在线上，意味着我们都是用我们的系统来去处理这些事情；传统银行大家可能知道大部分行为都是人工操作，比如去进件然后地推，接着审批核有专门的人去收集资料，大家贷过房贷就知道这件事情了；目前一些小的P2P公司处于混合的状态，即部分流程会放到线上。

各维度的特点：

1. 用户特点：线上贷款的用户特点是什么？我们有海量的用户也有非常丰富的接入场景，例如现在的线上贷款可能有2C或2B，甚至有对小贷公司的贷款。我们会有H5即简单的web的页面这种获客方式，也会有SDK、nativeApp和API的接入方式，对于整个系统设计而言接入方式是非常多的。

2. 数据特点：线上信贷业务的数据特点比较复杂。我们有多样的数据获取方式，比如我们有数据爬取、第三方的合作、自己的抓取收集等等；数据格式有结构化的、非结构化的、文本类的都有；数据种类比如电商类、网银类和市政类的数据都有。

3. 贷中贷后的特点：我会分为三大块进行描述：多样的贷款种类、高强度的审批核和高度的自动化和智能化。

4. 决策特点：整个线上信贷业务要做到实时的反欺诈，快速迭代信用评级和高效的专家系统。

信贷业务如果要把它互联网化，那下图应该能够更好地反映它，即我们要往哪边走，往这边走我们会遇到的困难是什么？如果是阶段1，我每个月要放款1亿，我的核心人员如果是100个人，这100个人包括研发、催收和审批核人员等，这样也许很容易做到，只要借助于一些系统的开发应该就能完成。

但如果你要做到阶段2一个月放款10亿，如何保证核心人员也能维持在100人？阶段3的100亿呢？在这前提下做出来的东西我才认为是互联网带给我们的红利，在核心人员不变的情况下我们的业务可以实现线性的增长。

怎么样做到这一点，我总结下来有两条：

1. 进行深度的数据挖据，这里会涉及到方方面面，我们会怎样借助搭建一个数据平台来做深度的数据挖掘；

2. 在深度挖掘的基础上怎样build一套高效的信贷系统，这里会侧重一个高效的审批系统，当然智能催收、精准营销也同样重要。

首先线上信贷的系统架构，这里总结了非常关键的三个阶段：

1. 一开始如果我们要开展一个业务，我们可能选择最快的方式——外包，我们会把一些审批系统、核心系统外包给别的公司或者去买一个能够迅速上手的系统，这样带来的问题其实也是我们血淋淋的教训，虽然能够快速上线业务但其背后会带来复杂的维护成本，而且我们数据服务的集成基本上是不可持续的；

2. 随后我们自然而然进入第二阶段——自主研发。大家可能会问研发一套系统的周期要多长，我们最早采购的那些系统其实都是专业做了很多年的系统外包，是有相应的一个银行同业经验开发出来的系统。

   但是以我们的经验来看，只要满足你的最小需求，其实一开始设计这个系统可以尽量地按照你的需求定制化，这样的开发周期不会太长，自行研发的系统的高扩展以及和你的数据服务的集成也是最好的；

3. 第三阶段其实也是最核心的阶段，刚才我说到如果每个月放款100亿，你怎样能保持你的核心人员能保证在100人左右，这时候你们就要进入输出阶段。

   所谓的输出阶段就是将你的能力和你的系统外包到外面去做，即选择更低廉的人力成本去完成你的业绩（例如每个月放款100亿），这就要求你在自行研发阶段时对整个系统架构以及对它的权限体系在自己心里都有统一规划，有这样的规划到输出阶段你才不会显得那么突兀和忽然对整体架构有那么大的冲击。

我们设计的贷中贷后系统可能日处理量在上万笔或者上十万笔，这里大部分都由机器来做决策，少部分还会涉及到人工处理，怎么样能够更好地做到分单，其实在催收、审批只要涉及到有人工处理的地方都会用到分单，审计也是必不可少的。

在下图第二层（即蓝色的部分）有权限管理、审核和深蓝等等，深蓝会重点说，因为它是提高我们审批核人员人工审批的一个关键要点，它是怎么样做到让人工能够更好地利用数据做审批。

在这一层大部分都是web服务，它们大部分都是作为一个单独的web IP暴露出来的；最上面这一层我们把所有的服务集成一个工作台，在这个工作台所有的业务人员（涉及到贷款方方面面的人员）都可以在上面做操作；中间有一个非常关键的一层称为Desicison Node，主要负责一个贷款在贷前、贷中、贷后所有流程的管理。

接下来下图谈到如何让机器来代替人去做决策，我们做的线上贷款怎么样能够提高我们的审批、审核人的效率，怎么样提高我们催收的效率。审批审核如果一天一个人能审100单其实蛮不错了，这效率已经很高了，但如果让一个人一天审500单那基本不可能，我们就提出了这样系统的构建过程：

1. 深蓝系统大家可以认为它是一个Data Hub，是审核人员所需要的所有数据的集市，在这边以非常友好和高效的方式呈现给审核人员；

2. 规则和模型是我们包装的自动化审批过程的process或者service，当人和机器他们混合做决定以后他们的结果会到我们的审批决策这个Desicison Node里；

3. 电照和审核是一些辅助系统，一般情况我们是需要和对方沟通验证一些资料的；

4. 审批决策的规则相对比较简单，这里选用了Groovy和QLExpression规则表达式，它们不能作为规则引擎，跟Drools比Drools比较重而且比较商业化。

   我们用Groovy和QLExpression主要考虑的因素第一个是性能，大概有10倍到50倍的提升。第二个因素是Groovy和QLExpression对程序员和稍微会excel的editor这些人非常友好，其实我们也不需要Drools那么多比如说rule dependency或者是一些复杂rule等东西。

5. 重点要突出的是：不是人最后去做决定而是机器规则去做，为什么要这样设计？其实考虑到人的比重会越来越小，大部分的decision都会慢慢的transfer到规则和模型这一块，在业务架构上就需要预先体现这点。

接下来讲深蓝系统，下图是我们深蓝系统的截图，可以看出这其实是相当简单的一个界面，为了提高效率我们做了一些设计，这个系统目的是让审批核人员用这个系统能够快速地做出决定。

比如有人过来申请贷款，那我依据什么来给他批这个贷款？其实就是数据，数据通过这个系统呈现给审批核人员，系统会将不同的数据进行分类，同时我们还会有汇总的信息，比如我们有两份风控报表和反欺诈报表，我们还有灰名单、黑名单，一些敏感词等数据。

这个web page上的detail部分会有很多的信息，我们会将关键的信息高亮来提示审批核人员。这个系统上之前我们的审批核大概一人是50单，上了之后有double的效率。

下图是我们审批系统的prototype，审批系统现在正在开发过程中，它的主要目的是把各个信息汇总，不光是审批人员的信息，还有我们规则模型跑出来的结果，还有这个人审批的历史记录，在这系统都会以一个非常详尽的报表形式展现给我们的审批核人员，让他们因此做出一个decision。

先大致介绍我们信贷审批系统，后面的重头戏是大数据，我们是怎么基于大数据去玩这件事情，我们是怎么样去基于大数据做数据挖掘来让我们的审批系统变得更智能。

说到数据平台架构，其实信贷领域数据平台的架构和电商数据平台的架构不太一样，但技术上可能有共通，这里不一样的点是从一个数据平台要解决的需求和我们要用的场景是什么。对一个成熟线上信贷业务而言，它的数据种类有很多种，大概总结为以下：

1. 社交类：比如你的通讯人，通话记录，QQ好友、微信好友等；

2. 网银类：比如今天消费的银行流水，credit card欠款情况等；

3. 电商类：比如在淘宝、京东、一号店上的买卖信息；

4. 市政类：比如公积金缴纳、社保情况等。

数据格式千奇百怪，刚才我已经提到的文本类的数据，结构类的还有半结构化的数据等等。服务场景重点说一下，对一个信贷的大数据平台他的服务场景有四类：

1. 申请，这个数据平台在申请阶段时就要起作用，所谓申请就是当你在一个App或者界面进行申请的时候我们的实时反欺诈就先起到作用，然后挡住一部分人；

2. 审批，基于规则和模型的自动化审批。之前也提到部分审批系统是一个人机混合的过程，虽然是人审批，但是人也是基于大数据平台给他计算出来的数据去进行快速抉择；

3. 催收，大家可能知道整体的经济形势，投资会慢慢地向保守的状况走去，其实从这个角度来看催收可能是后面大家非常看重的点，也就是说怎么样能够让用我们的数据让催收变得更高效，其实也是这个数据平台的需求；

4. 分析建模：最后一点要highlight一下，当大家都在说Machine Learning或者基于规则的去建模，这些东西都要我们数据科学家或我们的数据分析人员去分析建模，这也是数据平台的需求，如果你没有好的平台怎么完成你的模型训练和最后的上线迭代。

基于这几个需求其实已经对整套系统的设计提出了相应的技术要求：

1.数据管理，

1. 多源导入导出：因为数据种类和数据格式多，所以我们需要多源的导入导出，稍后会举例说明如何导入导出；

2. 统一的Schema和类型系统，这点很重要，因为你的数据存在于MySQL、MongoDB、HBase和HDFS等以各种形式存在。大家都希望一份data可以满足所有需求，比如说Ad-Hoc Query 、real-time compute、batch compute。

   但按照现在的技术这是不现实的，所以同一份data有可能有不同的存储形式存在，这要求我们统一Schema和类型mapping的系统，这点很关键，这样可以解决每个人在开发对同一张表的不同存储和开发自己的data mapping的问题，而且这种data mapping是日常中最容易出错的地方；

3. 数据质量实时监控：这点也很关键，不管你的模型和你的规则有多好，但如果你基于一个比较糟糕的数据，用最经典的一句话解释就是Garbage in Garbage out（垃圾进，垃圾出）。

   比如大家成功爬取一个人的网银流水，你怎么知道这个人的网银流水成功了而没有在中途丢掉一条网银流水？或者在中途没有爬到网银流水是因为System Failure获取出错了还有因为这个人真的没有消费记录？想这些东西的话你必须要有一个数据质量的完整监控，而且要做到实时；

4. 按需的存储结构，申请服务场景大家需要一个实时服务，而对审批和催收可能需要准实时，基于内存和多索引的存储可以满足实时服务，但成本也较高。同样，准实时可以采用内存和磁盘 share的存储系统，而成本最低的就是 HDFS文件存储系统了，这时你面对的是离线计算任务。

2.服务分级，大家可以看到我们对不同的服务场景分了三种服务等级，这个是根据计算服务的最少可用时间（SLA）定义的：

1. 实时：我们规定是小于1秒，基本上是200毫秒到500毫秒之内完成；

2. 准实时：小于5分钟；

3. 离线：大于5分钟

3.计算框架

1. SQL Based，选型也很重要，这么多年大家也知道各种编程语言例如Python、Scala、Java、C++的数据处理，以我看下来效率最高的其实是SQL Based，它的受众不光是研发人员还有我们的数据分析人员他们都会很容易地去提高效率；

2. Lambda架构，Lambda这个结构来源于函数式编程思想，类似函数式编程里闭包的概念，当然在大数据里应用的话最早提出来的是Twitter的一个project叫Summingbird，用简单的话去描述就是把你的计算逻辑看成一个function，而你计算逻辑可以apply不同的场景，它可以是实时的也可以是离线的，你不需要去修改代码就完成同一套计算逻辑在不同场景下的计算。

3. ML Pipeline，在进行机器学习训练过程中，调用指定的算法比如Decision Tree、Random Forest（随机森林）、SVM，这只是完成了全部工作的10%，其它大部分时间是在做数据准备、特征工程等这些操作。

   Pipeline的概念就是要把这些操作全部打在一个管道里，然后训练完模型后将这些操作和参数都序列化到磁盘上，当需要进行 prediction时，这个pipeline是可以直接被使用的（反序列化），我会解释为什么要去考虑这个问题；

4. Storm：我们采用这个Storm（有JStorm，然后最近的Twitter的Heron），Storm这个东西在实时场景还是非常推崇的，因为在过去的一年多中大概有6-7次的机房故障，Storm这个集群基本不用太多人干预，它相当的稳定。

接下来给大家一个引子——黑名单，大家做信贷的话都会知道黑名单这个概念，提到黑名单大家背后都有很多的事情：

1.黑名单的来源，大概有三类：

1. 人工的录入，打标，比如你们的催收专员、审批核专员他们今天打来电话说有一个人实在催不回来了，那么就把他mark成黑名单；

2. 聚类或图计算生成，这类用到的算法有K-Means、Graph Shortest Path（最短路径），还有Graph  Centrality ；

3. 第三方的合作，批量导入，大家如果从事信贷这个领域就知道很多征信公司和提供征信服务的公司以及小贷公司大家对黑名单这一块会做到一个market市场，大家会互相交易一些黑名单。

2.黑名单的使用场景，其实上述来源三点也正好也贴切了这三个场景：

1. 贷前申贷过滤，我们对于欺诈类行为的人就直接在前面就挡掉了，其实就跟支付安全是一样的道理；

2. 贷中审批关联性标记，这里用了一个关联性标记，其背后隐含了很多东西，用黑名单举例，我有个key-value store ，你过来一个人我命中了他的身份证，或者命中了电话号码，但这往往对团伙欺诈或者是比如在图里面有二度了（过来一度又过了一度）这种Case，其实这种的match不是很容易被发现，那这时候就需要做一个关联线索。

   拿最简单的例子：你是一个黑中介，你的手机通讯录里存了很多人，然后我又是通过你来去申贷的，我的电话薄里面也存了很多人，这时候咱俩用电话号码去match肯定是不一样的，但如果我用我的电话薄和你的电话薄去做match，这个match可以以一个比重进行衡量，比如两个set的交集比上并集大于60%就可以作为一个指标来标记你们是关联的，这个关联性相当有用；

3. 离线的模型训练，这里需要大量的黑名单或者是白名单去作为我们的规则（比如决策树）的输入。

3.对应上面三种使用场景，我们也提出了三种计算要求：贷前必须做到实时计算，贷中我们要做到近实时计算，离线黑名单生产其实做到daily就可以了；

4.算法涉及到K-Means、word2vec、Graph  Centrality等这些都是图计算和聚类算法，他们主要用来生成我们的黑名单，这里值得一提的是K-Means和图的最短路径现在已经有online版本了，可以不用做24小时的等待时间去训练去找到这个黑名单，你可以online用一些算法，这个Spark也有个很好的支持；

5.规模，我们现在规模是1000万的用户，1000万其实只是一个起步，1000万大家可以算算，单机已经不能满足我们的要求了；

6.扩展，例如从黑名单你得出的灰名单是什么，我的敏感词是什么等等，其实都是一样的Case。

基于这个引子我们来看我们的数据平台设计，下图是我们数据平台的架构，大家会看到我们做了服务的分级，基于redis上面有codis，它是redis分布式管理的框架，最早由豌豆荚提供的，现在已经开源了，这个框架用起来也是相当简单，对ops很友好，在它上面我们做了一个Storm的集群，主要用来服务于贷前的需要在500毫秒之内有响应的计算框架。

第二类的计算框架就是我们的近实时，这里主要是模型prediction——也就是我们贷中的审批核，然后一些模型规则在这里面跑，主要是小于5分钟，我们主要采用Spark Streaming加上Spark SQL，这里涉及到的计算有规则的预测、模型的预测还有准实时的报表。

这里我们使用了HBase和Phoenix作为storage，HBase这边给大家的建议是如果用HBase作为solution，最好有一到两个人对HBase相对比较了解和有比较深的建树，日常 HBase的运维还是有很多的，例如region compact、split等。

Phoenix是什么样的东西呢？他在HBase的key-value storage提供了SQL wrapper，即你在上面就可以像写SQL一样去操作HBase,然后performance大概有1%到5%的下降。Phoenix上可以使用buildin的方法去建二级索引，你可以建更多的索引（性能下降较多），里面用的是HBase的Coprocessor概念去实现的。

但是大家使用Phoenix的时候也要特别谨慎，因为它的类型系统和HBase的类型系统其实不是统一的，也就是有一个mapping在里面，一旦你用到它了你的所有数据需要尽量从Phoenix入Phoenix出，而不是一边使用HBase。

当然Phoenix也是支持HBase的物理表，Phoenix有view的概念，但这样操作并不是很友好的，所以大家使用Phoenix还是需要谨慎，它的侵入性比较强，一旦用上了他对你的整个ecosystem就必须要用Phoenix去做，可以替代的方案大家可以考虑用ElasticSearch来做相应的事，如果你的索引特别多的话。

第三层是我们的离线计算，它主要服务于我们数据的清洗、聚合、feature提取、预计算、模型训练和报表，这里我们用HDFS+Hive，着重提一下我们并没有用原生的MapReduce+Hive，它的计算框架已经替成了Spark，因为在一张大表（大概是5t到10t的规模），我们跑过benchmark，大概Spark SQL离线要比Hive SQL要快十倍，如果你再用上Parquet列存储storage的话你的性能会更好。

大家可以看到我们大部分用的是开源的东西，对创业公司或2000人以内的公司来说这些开源的项目是最容易上手，但是用这些开源的东西我们自己也要开发相应的东西，有哪些东西呢？

1. Schema管理（mapping），刚才提到我们已经有太多的system，例如Spark DataFrame、HBase的storage、HDFS的storage、redis的storage，如果一张表从Storm或者HBase都有，那我必须要有一个consistent view ，前期如果有Schema管理，然后到不同的storage system来做mapping，会对你后面的开发以及对整体容错率会大大提升；

2. Exporter，这个很重要，大家可以看到我们的数据源有MySQL、API Gateway、FTP Gateway、HTTP Gateway，如果有统一的exporter那么可以从这些源分别导入到这几个地方；

3. Scheduler，即任务的管理，包括定时的日任务和 Streaming的服务。

4. Monitor，监控包括系统错误和数据质量。

以上东西都要自己去开发。甚至有些需要你做plug-in的东西。

再说一下两个应用场景数据平台：

1. 我们使用Apache开源的Zeppelin，大家如果不做一些数据分析可能不是很熟悉，打个比方更像数据库的DMS系统，不过它更powerful可以做到数据的分析、报表的展示，然后还有个交互式的一个input output；

2. 我们有EP的实验平台，主要面向我们的数据科学家。

下图是Zeppelin的官方介绍，它服务于四块：数据消费；数据发现；数据分析；数据展示，还有collaboration，这块很有意思，因为他是一个sandbox，你有一个想法或idea想要尝试，你可以配不同的interepter，你可以配Java、Scala，或者配SQL、Phoenix等等。

也就是说你可以尝试不同的计算方式，然后生成Markdown文件，这个Markdown你可以在中间添加详细的描述：你这一步要做什么事情，代码是什么，输出的结果是什么，然后下一步又要做什么事情。

做到了以后你和你的team member可以用它去做交互：我这边有个idea或者我这边做了个东西，你看我的Markdown然后就可以直接play。如果大家去上Spark Campus的训练营，那边会有Spark NoteBook，图上只是开源版本。这个东西还是非常好用的。

这套系统对权限的隔离现在做得相当不好，而且有些小的 bug，所以我们后面也是做了一个CMS的单点登录的认证并 fix了些 bug。此外开发了下载，上传并建表的一些功能。

下图是一个例子，MySQL的Importer in Zeppelin，我们做了一件事：我把我的最主要数据源MySQL里面一张表或者多张表导入到HDFS，形成我的parquet文件，parquet文件大概描述一下就是列存储，大家可以认为它是把schema和data存储在一起。

这里的代码基本上是所有的代码，大概34行到40行就完成了一个非常通用的MySQL的表到HDFS的导入过程。

大家看到下面会有些输入框，这也是我刚才说的它的交互非常好的地方，你在这边只要申明几个变量然后用这个函数（嵌入函数z.input()），下面这些交互框就会有给到你，你要run它的时候只要在下面填入你的参数，比如表名是什么，然后并发度是多少，然后基于哪个key去做partition在这边都可以填，其中的性能我们测过是相当快的，很快地就可以把这张表load到你的HDFS上面。

下图展示了我们二次开发的系统，主要是统一schema，统一schema其实有两种方式：我有MySQL的schema，也有HBase的schema等等，那我们采用 jdbc sql type来作为一个central来让它们之间mapping。

我们多次编程后总结下来这些系统其实都是SQL-Based，意味着我们可以用JDBC里面的type system来定义。上图的表有很多列，它的schema type我们叫做Spec，即central的类型系统，这个类型系统里定义的都是我们的JDBC的type system。

然后你会看到我们有Phoenix的JSON、MySQL的JSON等等，比如这张表定义完了以后你想match成Phoenix的，只要点相应的schema，那么这段schema就是可用的。当然这也有API的接口，可以直接编程拿到它的schema。

下图是我们系统里的实时的数据监控，MySQL的数据都会通过Kafka被我们消费到HBase system，这个消费是实时的，在这个实时的过程中任何一批数据里面出现失败都会在这个界面显示，而且会和我们的报检系统去联动，我们想看到的在这个消费流的过程中，我们的一条数据都不能出问题，我们不能因为数据的质量导致我们后面的规则和模型不可用。

上图中的row key 、raw JSON就是Kafka的message，我们存到HBase里面大家会看到有很多条，然后fail了15条。大家可能会问为什么要这么详细，因为整个系统build的过程中一定要有工程化的思想，即我们要第一时间上来发现问题，要知道哪些key出了问题，然后我们才能够绕过整条流程，从我的sources直接拿到我的数据去做订正。

仔细想想这个过程：我从MySQL到我的HBase的过程中，中间其实是复杂流的处理过程，如果出错了，你的订正其实是要拿着这个出错的最关键的信息找到你的源数据，然后绕过这套复杂计算逻辑直接订正到你的目标的一个HBase的存储里面。

下图是Job配置，这是online的Spark的streaming process，大家可以看到我用了Mesos Job配置。重点说一下，Spark是可以跑到YARN或Mesos上面，为什么我们把它的实时的计算放在Mesos上？

因为Mesos对于异构的Job兼容更好，即我可以不跑Spark，我在这个Mesos的集群上可以跑我自己的微服务比如Spring Boot的实时服务，我也可以跑Storm服务，我甚至可以跑其他的一些实时计算。如果你用YARN的话对整个开发的友好程度可能就会大打折扣了。

下面重点说下整个信贷中贷后最大的一块数据挖掘，它是由有一定的银行背景的数据科学家或是有一定数据挖掘经验的人来从事的，下图展示的是他们现在的工作方式，这工作方式也是typical的现状，也不一定只是挖财的一个现状，即数据科学家在对一个规则的产生和一个模型的训练往往会经过多少步。

可以看到当一个需求提出来时我们会定一个指标，然后数据科学家首先要去了解数据，即需要哪些数据和变量，了解了这些数据以后他会有excel给到我们的数据工程师，由他们去开发这些变量。

这个过程大家可以理解为开发feature然后导出feature，然后给到数据科学家，他会load feature，然后做本地的训练，这里面本地的训练可能用到Weka、Scikit-Learrn或者是SAS，然后在本地速度调优，最后这一步数据科学家的产出会是什么？

训练完的一个模型你可以认为是具有规则的比如decision tree、if-else这些东西，然后给到算法工程师，算法工程师拿到的这些模型以后再去开发相应的算法，再去开发一套实时的feature，注意这和刚才的离线feature是不同的，这是两套逻辑，最后这个模型才上线。

整个过程中大家会看到有涉及到三类人，当然这三类人不光有分工的问题而且还有数据的copy问题，最让人可能会容易出错的或让人会觉得比较摸不到头脑的地方可能是开发feature的这个计算逻辑，为什么到你算法上线的时候你还要去开发一套实时的feature计算逻辑？

这套东西非常容易出错也就导致数据科学家在train一个model，train完result然后提交上线时，他往往不会很trust，他会觉得你们的input是不是我当时训练的那部分数据集。这里引入了别人的一句话：数据科学家80%的时间在准备数据，20%的时间其实在埋怨这个数据其实不是我想要的。

我们在想怎么样能够让我们的模型迭代更快，因为整个征贷市场的风险变化非常快，我们怎么样让我们的模型规则能够最快的上线，因此我们提出了假如我们只有数据科学家没有数据工程师和算法工程师，我们应该怎么玩转这件事情？

下图是我们开发的一套系统，大体架构是这样的：我们基于Spark的ecosystem搭建了一个上层的系统。

之前提到的Zeppelin主要承载了数据科学家前期的数据调研，即data discovery、data exploring、data analysis，另一边是data experimental platform（实验平台），承载的是feature engineering，包括feature的变换、一些简单的feature的处理即feature的工程化，还有model training、model selection和model testing，最后数据科学家把这件事情完成一个model串完了以后要做的是发布，发布时他会做一个A/B testing setup做一定的灰度，然后会在线上的结果result收回来后不断地去调优反馈这个系统。

发布是在我们的Rule Service里面去做，我们的Rule Service会有model deploy online prediction，我们在实验平台上不会做模型的预测，只会做离线训练和我们的实时prediction的result的返回。

能做到这个一定是基于下面这几个关键的点：

1. Lamada的架构，一个feature开发在离线训练阶段可能由数据工程师基于一套逻辑开发，实时的prediction由我们的算法工程师去开发，怎么样能够用一套代码把这两个东西做完，其实就是用的是Spark Batch Streaming即Lamada的架构；

2. 模型训练，有ML Pipeline，其实它在模型的上线也会用到，你可以认为你训练出来的结果就是pipeline，整个pipeline都可以save到磁盘上面，在另外的Rule Service做prediction时，你可以把整一个pipeline从磁盘上解序列化出来，然后load到你的内存然后就可以预测了。

基于这套系统的帮助我们是想让我们的数据科学家或者是数据分析人员变得全栈化，所谓全栈化大家都知道带来的好处就是我们可能减少更多的错误，减少我们的数据copy，节省更多资源，提高我们的迭代速度。

下面简单介绍一下Spark Pipeline，举一个最简单的一个例子比如一个text文档过来，你要去做成一个Logistic Regression Model，那么第一步做分词，然后做TF，然后做Logistic Regression，这部分是train，train完了以后这套东西的东西可以save到硬盘上，当你需要使用时，只要从硬盘里把这个load出来叫做pipeline model result，然后feed它raw text时你就能得你的prediction，即你的result。整套过程其实Spark已经做得相当好了。

下图是Zeppelin做的一个小的example，这是Spark上面的一个代码，Spark ML是2.0以后才来的，那2.0之前1.6这个版本相对比较稳定，用的MLlib这个package，最大的变化是把一些接口做了调整，把一些pipeline更加加强。

这边主要想展示的是用Spark去做一个model的train以后，如果大家有ML background的话，可以看到Scikit即python最经典的单机版的分析ML library，它代码行数层次是在同一个层次上，这里面使用Scala去写，也可以Python去写，这其实已经非常精简了。

最后说下有了我们的数据平台，有了我们信贷的一个中后台系统后，我们还缺少哪环可以让这两个事情能够更好地结合在一起？

我们有很多系统融合的地方，其中我选了四点：

1.状态流，我们数据来源大部分是数据的爬取、第三方获取，这些数据最早都承接在MySQL的一个业务库，然后到我们后台是一个离线的大数据分析或者实时大数据分析，这是异步的数据同步过程。

这本身就是一个矛盾点：我要服务于线上，那需要一个同步调用的过程，我要知道所有的数据ready了才能去跑我的模型，才能去做prediction，但是我的数据又是不同的存储系统，数据传输又是异步的，所以这边状态流很重要。

也就是说你build的一套状态机制去管理你的数据告诉人家：这个数据是不是ready了，你期望这个数据值是不是已经在你要计算的这个平台已经OK了；

2.行为收集，之前给大家展示的那个深蓝系统里其实是有隐式和显式的行为收集，所谓隐式的行为收集就是当审批核人员在做任何操作的时候我们对他的行为做check，这个check有两个目的：

1. 我们要规范审批核的标准，也就是当你一套政策布置下去了以后其实每个人的手的宽紧度是不一样的，每个人对每个资料的感知也是不一样的。但这种情况下其实你通过一次次的培训，你可能会达到效果，但更多的我们是想通过一个隐式的feedback，然后再回过头来去看大家在某个点上是不是是有疑惑；

2. 隐式的行为的特征会被我们转换成自动化流程，也就是说我们可以绕掉一些人工的步骤。

3.机器到人，人再到机器，这点蛮有意思，这个过程中当我们需要去做数据，需要用数据去预测一个模型的时候。这个时候我们会计算出来不同的指标，但是这些指标和规则可能我们还没有验证过，可能就像Machine Learning里面一个冷启动，那这时候我们怎么办？

我们有一堆的审批核专家，这时候我们其实要利用到人给数据打标，根据这些专家的一些反馈然后这些打标最后反馈到机器，才会变成我们的规则和模型，这就是所谓的机器到人，人再到机器；

4.最后一点是规则可读，我们不需要非常复杂的Drools，我们只要最简单的Groovy和QLExpressin，第一个性能比较好，第二个就是说我相信大部分的业务人员现在对excel的表达式也很熟悉了，在这边已经可以满足大家edit。

下图是我们之前提到的状态管理，上面是我们数据的收集，我们有爬虫，有native data，有三方数据，然后这些数据都会异步的到HBase，HBase会承载了我们模型的prediction，图中蓝色的框我们会收集我们Data State from Kafka，最后模型的调用过程中会有个State Checker不断去pull这些data。

然后决定什么时候可以调模型，或者我们有个timeout，这个数据就没有ready你就不需要去调模型，因为你一旦调了模型这个prediction result是一个非常不靠谱的结果，而且大家不知道问题出在了哪。

下图是机器到人，人到机器的图，你会看到我们大部分的机器都是由Rule Service去提供机器审批，这里有feature有model prediction，深蓝是给人使用的一个data hub，就是审批人员在这边做的所有的操作都会通过我们的显式的专家意见收集和隐式的行为搜集不断地沉淀，最后到达Rule Service里。

下图展示的是我们的可视化规则，就是Groovy和QLExpressin，写这个语言非常大家很容易懂。

最后是我们的prototype，我们正在开发的专家打标系统，大家可以看到最下面这块比较多的是我们的raw data ，上面这块是我们给它计算出来的一些我们认为比较靠谱的值，当然这些值我们还是会让它再去confirm一次，我们要把计算出来的结果、它的raw data、它需要打标的结果统一地收集下来也就是完成一个显式的专家打标过程。

我的演讲结束了，谢谢大家！

怎么样？这样的分享看了是不是觉得干货满满、诚意十足？那小Q我告诉你，这样的良心分享， ArchSummit 大会一次就有十几个专题几十场！我就问你怕不怕！

ArchSummit 全球架构师峰会 2016 北京站7折火热报名中！二次传播的拾人牙慧，总是不及讲师现场的面授机宜。7折截至9月11日，现在报名立减2040

更多详情请戳阅读原文！

▽

延展阅读（点击标题）：

• 微信开源PhxSQL背后：强一致高可用分布式数据库的设计和实现哲学
  

• 左耳朵耗子：什么是工程师文化？
  

• 没有免费用户却飞速发展，Uber技术栈全解析！
  

喜欢我们的会点赞，爱我们的会分享！