在大数据和人工智能时代，数据作为资源的一种存在形式，已经成为了非常重要的生产要素，通过对其分析挖掘可以创造出巨大的经济价值。
数据从产生到应用，需经过接入、清洗、整合和加工，这些工作通常在数据仓库中完成，关于数仓通常有两类说法，1类是大数据仓库与传统数仓，所谓大数据仓库通常是指采用大数据技术构建的数据仓库，随着hadoop的兴起逐渐流行;另1类是离线数仓与实时数仓，离线数仓主要是T+1同步和处理数据，具有1天的数据延迟，而实时数仓则可以做到实时或者近似实时，具有不同的应用场景。
实时数仓的发展已经具有较长的历史，应用到了各行各业，但是作为最近几年刚兴起的消费金融领域，实时数仓的建设又将面临哪些新的挑战?
（一）实时性，消费金融，根据中国银监会的定义，需以小额、分散为原则开展业务，以马上消费金融公司为例，人均借贷3000元，业务遍及全国，该小额分散的业务特性决定了必须完全依靠数据在线上完成整个授信放贷过程，如果按照传统银行的方式线下签单、人工审批，则会产生巨额的人工成本，以3000元的人均客单价带来的利润根本无法承受该成本。
依靠数据实时授信要求实时数仓从数据接入、清洗、整合、加工到查询整个过程需控制在毫秒级完成，因为在整个授信决策过程中除了实时数仓的数据服务外，还有诸多环节，比如：与前端app对接的api系统，留存申请单的申请单系统，机器学习的模型评分，控制决策步骤的工作流系统，做欺诈、信用评估等决策的规则引擎系统等，所以每个环节都需做到极致，时间尽量压缩，只有这样才可能做到一次授信在亚秒级完成，为客户带来较好的用户体验。
（二）数据质量，离线数仓支持的大多是BI报表等统计类业务，统计类业务对数据质量要求不高，出现少量数据错误并不会引起统计数据的较大波动，从而不影响数据决策，对于数据质量要求高的业务，由于离线数仓中均是离线任务，任务时效性要求不高，当发现数据质量问题后，通常会有一定的时间可以修复解决，最终实现较高的数据质量。对于实时数仓，很多行业或者绝大部分公司对它的定位主要还是OLAP业务，支撑数据的准实时分析，对数据错误不特别敏感，但是在消费金融行业，在第一个
实时性挑战处有提到，依靠数据做实时授信，授信是消费金融公司赖以生存的最关键因素，授信做的好，表现为通过率提升，增加放款额，逾期率降低，减少坏账成本，一增一减，大幅提升盈利水平，反之，则大幅压缩盈利空间或者出现放款额越多亏损越大的问题，可见，授信对于实时数仓的定位将不再是OLAP的分析场景，而是OLTP的联机交易业务，对数据质量要求极高，尽可能避免或者减少因数据问题影响授信业务。
（三）数据获得/应用成本，同样围绕消费金融的授信放贷业务，如何降低数据获得与应用成本，快速把数据价值体现到授信过程中，对于消费金融公司非常重要，在用户的授信过程，需要用到外部购买数据，自建数据，各业务系统产生的历史数据和当前数据，这些数据具有数据量大且散落于各系统库表中的特点，需有比较好的查询机制，支持大数据量的多维查询和跨库甚至是跨异构数据库的统一查询能力，避免当有新的授信规则需要数据时还需到各研发条线排期开发数据接口或者传统技术无法满足大数据量的查询时效性问题。
授信主要分反欺诈与风险定价两个大的阶段，其中尤其是反欺诈阶段，快速迭代反欺诈的规则和模型，将大幅降低违约成本，能否快速迭代，其中最关键的因素之一就是在线下分析/挖掘数据发现新的规则或者训练出更好的模型时，能否在最短的时间内对接上依赖的数据从而完成生产环境部署，这需要有非常好的的数据架构作为基础，这对传统的实时数仓提出了非常大的挑战，实时数仓架构将不再局限在先汇聚数据再查询，是否可以不汇聚任何数据或者部分汇聚部分还存于源库表，在多源异构存储中实现实时数仓业务。
综上所述，在消费金融行业，对数仓提出了更加高标准的要求，主要体现在实时数仓的时效性、数据质量、数据查得/应用成本三个方面。
马上消费金融公司作为消费金融持牌机构，其打造的符合消费金融业务特点的实时数仓项目，基于大数据技术实现，比较好的解决了以上挑战，目前已经完成对全公司核心系统的所有数据实时接入，日接入数据超过10亿行，自研分布式统一查询模块，实现亿级数据多表关联查询毫秒级返回且支持异构数据库联查，为实时风控业务提供了非常好的数据架构和数据支撑。
下面，我们以马上消费金融的实时数仓系统为例，向大家展示消费金融公司基于大数据平台的实时数仓解决方案。
（一）针对消费金融行业数据处理的实时性要求，马上消费金融从以下几方面提出了解决方案：
1、元数据的自动管理。在元数据当中维护MySql的schema、Kafka的topic、HBase的tableName、rowkey字段，ElasticSearch的索引列字段等信息。
2、性能和规模扩展性。借助于分布式消息系统Kafka和列式存储系统HBase以及ElasticSearch集群可动态扩展系统的高可用性。
3、高指标的SLA。实时数仓系统提供的服务响应在毫秒级别，7×24小时不宕机提供服务。
4、接口、标准兼容性。提供标准的SQL语句查询，满足NoSql解析为标准SQL的查询。
5、数据的一致性。实现数据精准实时同步，做到了Exactly Once的语义。
6、配置化、定制化管理。通过配置化管理实现对多个业务系统数据的接入，避免硬编码，通过定制化SQL对外提供实时的数据查询服务。
（二）马上消费金融实时数仓系统的演进过程：
第一阶段的实时数仓系统落地系统架构，如下图：
在系统的第一阶段，马上消费金融使用阿里开源的canal对mysql的binlog进行实时同步，将数据同步到下游的Kafka。Kafka作为数据的缓冲层，可以为系统本身提供数据拉取源，同时也可满足其他业务部门在Kafka当中的数据订阅需求。
另外，其通过自主开发的plugin插件进行对Kafka数据的消费，将数据转存到HBase和ElasticSearch当中;自研的统一查询平台，使newSql解析器将标准的SQL查询解析为对ES查询的DSL，同时支持ES作为一级查询引擎，HBase作为二级查询引擎实现查询的多层高可靠查询服务，服务响应平均在几百毫秒以内。
在第一阶段的系统落地并实践一段时间之后，马上消费金融实时数仓系统的设计团队有了新发现，即Dremio可以更好地解决异构存储的数据源之间的 join 查询，如：Elasticsearch、MySQL、MongoDB、Hbase之间进行 join 等多种业务查询的场景。经过全方位测试，他们进行了该系统第二阶段方案的落地。
第二阶段的实时数仓系统落地系统架构，如下图：
升级版的实时数仓系统引入了dremio，这使得系统的响应能力提升了一个数量级，平均查询耗时在几十毫秒以内，多表join查询(2000W~1.3亿数据量)响应时间在几百毫秒以内。进而更好地实现了实时数据仓库对业务系统数据决策的支持，满足了即席查询和包含连接、聚合等操作的复杂查询需求。
结语：
随着监管趋严，2018年金融行业将更加回归理性，合规、普惠、服务实体经济将是消费金融公司发展的主旋律。基于小额、大量、短期、高频的业务特点，消费金融公司若想兼顾效率与风控，必须在技术方面寻求解决方案，通过实时数仓系统创建一站式数据中心，自助式对金融数据进行多维度分析和联机查询，为用户的数据安全和业务的快速决策提供重要支撑。马上消费金融是消费金融领域科技应用的探索者与实践者，希望本文分享的该公司实时数据仓库系统落地案例对于同业机构解决同类问题有一定的参考意义。
免责声明：本网站内容主要来自原创、合作伙伴供稿和第三方自媒体作者投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。任何单位或个人认为本网站中的网页或链接内容可能涉嫌侵犯其知识产权或存在不实内容时，应及时向本网站提出书面权利通知或不实情况说明，并提供身份证明、权属证明及详细侵权或不实情况证明。本网站在收到上述法律文件后，将会依法尽快联系相关文章源头核实，沟通删除相关内容或断开相关链接。
