大数据金融(大数据在金融领域有什么用处)

举一个证券的例子，举一个银行的例子。

证券行业的案例

以上是一个神策标签画像产品的实施流程示意，如上图，可以发现，我们整体的项目管理做的非常精细，包括项目准备、系统部署、标签需求梳理、产品持续交付、标签系统实施、交付与培训、交付后支持七个步骤。

1.需求调研：梳理业务场景、运营策略和需求

具体到其中的需求调研阶段，上图是我们根据了解到客户的业务场景、运营策略和需求初步建立的一个需求梳理框架。因为该企业设计标签体系的目的是做用户运营，所以会从新客培育、活跃留存、交易提升、资金留存、沉没唤醒、流失预防、丧失召回、用户体验、大客户运营等维度来梳理企业的业务体系，但是如果企业的标签体系设计目的是做个性化推荐，设计思路将完全不同。

所以，我们为每一个企业梳理标签体系前都要明确目标，根据目标来梳理一个基本的业务需求框架，再通过前期调研，如访谈、查资料等来补充框架上的信息。

2.由业务需求抽离出标签需求

明确企业的业务需求后，我们再根据企业的业务需求梳理标签需求，并梳理出相应的标签策略，最后制定对应的标签，这些标签是企业最终的场景应用会使用到的标签。

如上图，我们最终帮该证券客户的标签梳理成几大类。

第一类是用户的基本信息。基本信息包括如用户识别、激活信息（引流或者拉新时的重要信息，如用户什么时候来、什么渠道来等）、风险特征（金融行业用的比较多）等信息。

第二类是用户的账户特征。因为证券企业的用户有多套资金帐户，但是不管用户操作的是哪个资金帐户，企业最终营销的都是用户本身，关于用户本身的特征和偏好才是最重要的信息，所以我们会对用户的帐户做一层设计。

第三类是业务特征。之所以我们会划分交易、理财、资讯、服务四类，与企业的运营体系相关，他们是按照板块划分具体的运营的。所以要建立真正代表用户在特定业务场景下的标签，我们会拆分业务层，业务层对应的标签就是表征业务本身的特点，如理财的标签与交易标签完全不一样，股票标签会涉及到个股偏好，但是理财产品实际上对特定产品偏好较弱，更看重产品类型。还有活跃特征和价值标签很好理解，我就不赘述了。

下图是某证券客户标签画像系统实施的 demo 示例。

第二个银行的案例，是中原银行大数据架构师刘远东的一次分享。

平台建设目标与思路

中原银行已将大数据治理与应用建设上升到全行战略层面，并制定了以技术创新为导向，秉承自主可控、开放共享的理念，构建统一完整、便捷高效、智能安全的大数据技术体系，提供全流程、一站式、智能化的数据服务的目标。

值得强调的是，中原银行一直以来的目标不是做一个系统，而是为了提供一种服务。比如，当业务人员想知道流失了多少客户，就目前来说，很难提供给他 BI ，即使提供了数据，他也很难算出来，但通过场景化分析，制定出该场景下所需要的维度和指标，通过调取相关数据，很容易进行分析。因此，我们计划把一个场景做成服务，未来提供给业务团队使用。

数据平台建设进展与规划

这是中原银行大体的平台建设进展情况：

2016 年已完成基础平台搭建和数据架构的设计；

2017 年建立了一个数据整合平台，构建了数据服务引擎、OLAP 自助分析引擎和挖掘分析平台的基础搭建；

2018 年计划做数据治理、实时计算服务、图计算服务、数据交换平台、机器学习平台等；

2019 年，我们可能会从技术角度出发，做一些更加整合类的、更加完善类的、提升类的项目。

在很多情况下，虽然科技部门领头建立了技术体系，但并没有真正的业务落地，现在我们在尝试往实现业务跨越发展的方向转移。

在 2018 年 6 月，中原银行特别成立了一个一级部——数据银行部，这是从信息技术部分离出来的一个部门。

以前我们更多地专注于技术，但现在意识到用技术驱动业务，在营销和风控方面的成本和难度都非常高，且技术并不一定能驱动业务带来收益，从这一点上，我们决定尝试神策数据提供的这一套场景化的方法论和逻辑。

中原银行在过去几年做了一些技术驱动的改进。比如，面向全行的集中交付能力优化，包括固定报表和移动报表，自助查询模型等，特别是在过去几年银行业的自助查询比较流行，没有做的银行未来也一定要做，这是一个必经的阶段。

数据分析需求理解：五种模式支持全行应用

我认为银行业的数据分析需求可能有五种场景的数据交互模式（如上图）。中原银行目前做了一个数据实验室，其实是一套数据湖的系统，就是把以前的仓库、集市这些平台迁到了一个新的计算架构上面，它的主要作用是为了做数据建模和探索性的分析，该平台完全独立于原来的 P2P 平台，且不像以前那样只做报表，也能做一些自助分析、数据建模，以便将来能支持更多建模师的使用。

我们希望这种项目出来成果之后，能做成不同类的业务场景应用。不过，有些旧有模式，比如即席查询在中国视角下会一直存在，因为很难从别的应用场景完全替代它。

数据分析平台体系建设

中原银行目前规划了一套数据平台体系，但目前这个体系还在演进。

在过去几年，中原银行大概做了将近 1000 张报表、20 多个主题的自助分析以及数据实验室的平台。

这些平台面向的人员有所不同，报表主要面向数据使用人员；自助分析主要面向条线，比如给领导编制报表和往下发布数据的人；数据实验室主要面向一些有科技背景的人员，比如建模师。

除了上述三大平台，中原银行还建立了一个社区平台，我们把这些统称为一站式分析平台。

数据驱动创新社区的建立是为了引领行业数据驱动的发展，目前，科技部正在主导这个社区的建设。

我们会在该社区大量地发布一些数据驱动的内容，比如，数据分析报告，文章等。

个人认为，像数据驱动这种工作的推动，将来一定是业务牵头的，因为即使技术人员有思路也很难达到盈利，所以需要站到业务角度上去实践，现在，我们会把自己的技术人派遣到业务部门，学习在业务场景下进行分析。

前面提到的这几种数据分析平台还是比较偏技术方向，不过我始终认为，未来一定是场景化的方向才有发展。因为场景化的成本更低，比如，更低的使用成本，场景化让业务人员使用更方便；更低的人才成本，场景化的应用不需要招很多技术人员。

面向大数据的综合分析平台架构

这是中原银行目前面向大数据的综合分析平台架构，在这方面各行差异不大。

不过，中原银行集市做的很薄，只有一个贴源的 ODS，以及 4-5 块集市，比如管会、内部运营、营销等，与其他银行相比，中原银行是一个非常轻的架构，从贴源可以直接到集市，有的集市甚至没有指标加工，就直接整合明细，再到自助分析、报表，有的也往实验室里面供。

个人认为，像自助分析和场景化分析、数据湖这样的思路早晚会替代我们之前做的大量报表，T+0 会替代 T+1，这只是时间问题，所以，我们整个架构现在也在往这边迁移。

分析平台建设实践—性能优化

在前几年中原银行对分析平台做了一些性能调优。一般刚开始从报表转到 BI，肯定会面临性能问题，因为 BI 本身是一种以空间换取灵活性的方式。

我们采用大数据技术支撑计算，用了 30 个物理计算节点，大概有二三十个面向大数据反范式设计的主题模型，也就是宽表模型，因为宽表模型牺牲了很多空间的代价，在这个大数据的平台上一般会跑得比较顺，冗余度高一点，性能会提高。

不过，大数据平台的一个主要特点是成本较低，扩容方面也可以接受，所以我们现在更多选用这种方式。

分析平台建设实践—质量提升

数据质量提升，是中原银行今年的重点，我们准备启动一个新的数据治理项目。下面简单介绍下：

我们建设了一个在线口径管理的渠道。举个例子，现在业务在看报表发现数据问题的时候，会有一个线上的渠道直接在上面反馈问题，之后会有专门的技术人员跟进，除此之外，我们还有一个类似知识库的渠道，该渠道有利于口径的沉淀，但是，对数据的治理，比如主数据、标准管理，我们还需要进一步完善。

分析平台建设实践-灵活性提升

这个是中原银行的 BI 平台，总体来说使用还不错。我认为银行到一个阶段必须做 BI，如果没有 BI 很难把数据驱动的思路真正地让业务落地，因为业务人员无法直接接触数据，很难了解数据在未来的作用。只有他们把 BI 用熟了之后，你才能告诉他以后可以做场景化分析和预测类分析，现在中原银行就是沿着这样的轨迹发展。

分析平台建设实践—数据安全管控

金融业会涉及很多敏感数据，特别要注意数据安全问题，为了保证数据安全，我们做了一些技术上的加工，比如：

下载管理，我们建立了完善的数据使用审核流程和设定了数据最小访问授权，按需分配报表访问权限；

实时脱敏，Smartbi 支持不同形式的数据脱敏展现，可以实现前台敏感信息的脱敏展示，对像身份证号这样的敏感数据在实时展现时会隐去；

使用痕迹的管理，我们会统计发布报表访问数据，促进报表使用过程中的自我监督和相互监督，便于及时发现因岗位调整，多余授权带来的数据泄漏风险；

行为监控，我们利用大数据与机器学习技术，建设数据安全智能分析预警平台，对数据操作行为进行智能化监控，防范内部数据安全事件。

未来建设规划—数据深度探查服务体系

我们的未来建设规划大体如上图，目前来说，我们还处于数据探索和多维分析阶段，在今年我们启动了几个数据建模项目，下面列举一二。

我们启动了一个叫做网点的现金流预测项目，要做到精准预测，需要考虑到很多维度，比如网点的维度、人员的维度、客流的维度、天气的维度。因此，这个项目通过分析研究所有网点的历史数据来预测各支行每天需要多少存款，这里的存款指的是现金。因为对支行来说现金的存量是个非常大的成本，比如运输成本，而且现金沉淀到支行没有利息，相当于现金放那儿了。

我们希望预测类的项目在明年会有一些阶段性的成果出现，也希望通过我们在数据驱动变革创新方面的努力，能为推进金融业数字化转型建设发展进一份力。

以上是我的回答，希望对你能有帮助，欢迎关注我的主页。