“大数据(Big Data)”的概念在过去几年里引起了各个行业的充分关注。以信息处理能力作为核心竞争力之一的商业银行，如能引入大数据的理念和相关技术，将有效提升自身的信息化水平，促进信息化银行的建设和发展。
因此，有必要基于商业银行经营特点和现有IT架构，对“大数据”的概念加以分析和探讨。
本文以商业银行的视角，从大数据的核心思想、数据特点、技术要领、实施要点四个方面切入，以六组问答的形式对商业银行大数据相关的思想、概念、方法、对策等进行辨析和讨论。
大数据的核心在于“大”吗?
体量大、维度高、形态多、价值高但密度低是公认的大数据四大特点(即大数据的“4V”定义)。需要指出的是，这四大特点的概括，是出于理论研究的需要，对“数据”本身特点进行的概括。
而对于商业银行的业务应用而言，则应从具体效用的角度来理解大数据思想及技术。
大数据之于商业银行，在于对既有数据分析系统的升级，显著提升数据分析和商业决策的效率。
大数据的思想追求数据在商业决策中的“无处不在”，讲求数据分析与具体业务的紧密衔接。
从商业智能(BusinessIntelligence， BI)的角度来看，大数据技术是原有BI的升级，将传统的“具体业务—商业数据—BI分析—报表—决策—具体业务”的BI流程进行了再造，压缩了整个流程的信息链条，同时提升了链条各个环节及整体的运转效率。
大数据之于商业银行，在于提供了一种有效的手段，提高商业银行对客户的理解与认知能力。
大数据技术支持商业银行对大量日志数据进行统计和建模，从而了解客户的行为习惯、风险偏好、健康情况、消费能力、渠道喜好、信用状况及人口统计学等多方面的信息，进而为客户“贴标签”、“画像”;亦可整合多种信息反馈渠道的数据，帮助商业银行实时关注、理解客户的真正业务需求。
大数据之于商业银行，在于能够低成本、批量地实现较高水准的个性化客户服务，增加客户粘性。
如能有效地将大数据分析系统与移动互联网技术、线上线下一体化服务体系进行紧密融合，就可为商业银行的客户提供“千人千面”的个性化服务。
例如，对于低净值长尾客户，可用较低的成本，批量化地通过电子渠道提供随身的知心服务，提高产品和服务的覆盖率;对于高净值客户，提供“客户经理+电子渠道”的随身贴心服务，提升客户的业务贡献。
可见，从具体效用的角度来看，衡量一个商业银行是否真正应用了大数据、发挥了大数据的价值，就是要看其大数据系统是否能够显著提升数据分析和商业决策的效率，是否能够提高对客户的理解与认知能力，是否能够低成本、批量地实现较高水准的个性化客户服务。
如果商业银行的大数据系统未能实现上述效用，那就需要认真审视自身的大数据战略并加以调整。
大数据就是外部数据吗?
在国内，以阿里、腾讯、百度为代表的互联网企业，以各自的核心业务(例如，阿里的电子商务、腾讯的社交娱乐、百度的网络搜索)为切入点，通过并购、自主开发等方式，不断推出种类繁多的网络服务，在网络空间中搭建了“全业务”的数据平台，收集了海量的客户数据，并以此为基础开发出了一系列客户征信、消费贷款、网络保险等大数据产品，向商业银行的相关产品提出挑战。
与上述互联网企业相比，商业银行在网络空间中缺少类似的“全业务”平台，因此短期内难以依靠自身的电子渠道获取类似的客户信息。对此，商业银行是否应该将大数据的战略重点放在从自身体系之外获取客户数据呢?应从以下三个角度进行分析。
数据价值的角度。京东白条、天猫分期、阿里小贷、支付宝运费险、百分点个人征信、金电联行“企业客观信用”等业务的成功实践已经验证了互联网客户大数据在维度、粒度、活性方面的优势和价值，如果这些数据能与商业银行的既有数据进行融合分析，将有望获得更加精准的数据分析结果。
自身大数据体系的建设。一方面，应以内部数据为重点，做好自身既有数据的价值深钻和分析架构的大数据改造，而不应以引入外部数据作为大数据发展的战略重点;另一方面，要放开眼界，积极引入外部数据，增强商业银行与互联网企业IT架构方面的交流，以期加快自身大数据体系的建设进度，提升其兼容性与可用性。
数据交换的合规性。客户在使用互联网服务期的行为信息、购物记录、健康信息等数据理应属于隐私数据，客户在注册期间签署的网络服务协议是否能够有效支持互联网企业采集、商用并交换，尚属法律空白。因此，商业银行在引进外部数据之前，应首先做好合规工作。
可见，对于商业银行而言，合规合理地引入外部数据，有助于提升自身数据的多样性、细化数据粒度，并可通过数据交换提升自身大数据体系的兼容性与可用性。
但是也应充分认识到，商业银行多年积累的业务数据的价值还远未完全发挥，尚待深钻、分析和应用，应将基于内部数据的分析应用作为当前自建大数据能力的核心;与此同时，也要及时开展预研预估，做好外部数据交换的合规准备工作，为“内外兼修”的大数据平台建设做好准备。
大数据是否等同于非结构化数据?
“非结构化数据”是在大数据的“4V”定义中作为数据多样性的一个典型例子而被提出的，因此受到了普遍关注，在众多关于大数据的文献中，“非结构化数据”也占据着比较重要的地位。
那么，商业银行是否也应将“非结构化数据”的处理作为现阶段自建大数据体系的重点?
对于这一问题，要结合“非结构化数据”的特性进行分析。非结构化数据的本质特性是所包含信息的丰富、复杂程度远远高于结构化数据。典型的“非结构化数据”包括文本、音乐、语音、图像、视频等类型的数据，这些数据所包含的信息极其丰富，不能使用数据表进行无损耗转化。
因此，非结构化数据无法使用数据表或者类似的结构化的方式进行无损转化，所以只能以数据包、文件集的方式进行存储，也无法使用与结构化数据相同的数据分析方法进行统计、分析、建模，往往需要通过专门设计的预处理算法将其转化为结构化数据。
这就增加了数据管理和分析的难度，也提高了对数据存储、计算资源的需求。对于非结构化数据的分析，至今仍是学术界的研究热点，在学术领域尚属“进行时”，在商用领域的应用则更是凤毛麟角。
可见，现阶段自建大数据体系，对于非结构化数据应按照“量体裁衣”的原则，根据自身IT架构的存储、计算资源和技术人员投入分步实施。
对于资源紧张的商业银行，可采取“存储—外购预处理模块—自行研发”三步走的路径积累非结构化数据的分析能力。
对于资源较丰富的商业银行，则可按照“预研一批、实用一批、储备一批”的策略，采用“外购预处理模块+产学研合作+自行研发”的方式进行尝试，紧跟技术前沿，适时引入成熟的非结构化处理技术，但也应注意资源配比，不应将非结构化数据作为现阶段自建大数据体系的重点。
大数据等同于数据仓库吗?
如前所述，商业银行是否具备大数据能力，应依据数据及数据分析系统所发挥的具体效用来判断。
以“显著提升数据分析和商业决策的效率”，“显著提高对客户的理解与认知能力”，“低成本、批量地实现较高水准的个性化客户服务”三条标准来衡量，目前商业银行数据仓库建设还需在以下几个方面加以强化。
建设异构的数据仓库平台。
多年来，商业银行的数据仓库以存储业务、交易数据为主，因此采购了存储成本较高的专业数据仓库服务，数据在进入仓库之前的ETL规则相对比较严格，并采用了“时间换空间”的策略进行主题拆分以节约存储空间。
这就导致在执行诸如交易链恢复、交易场景还原等分析任务时消耗较高的计算资源，降低整体的分析效率。
与用户行为数据紧密相关的日志数据，具有典型的“数据量大、频度高但价值密度低”的特点，可针对这一需求，搭建低成本的PC集群、内存数据库等，与既有的数据仓库融合起来，构成对数据源和分析端透明的异构数据仓库，提高其响应速度和处理能力。
搭建业务指标提取逻辑的共享平台。
目前商业银行基础数据的标准化工作已经取得了长足的进展，但在实际应用中，尚存在“业务逻辑信息孤岛”现象(即由于缺乏一个共享平台，而造成不同的分析师之间无法互通业务指标的提取逻辑，每个分析师、每个数据分析部门就形成了一座座孤岛)。
这一现象不仅造成业务指标“多态”问题，也诱发了数据仓库访问请求的重复提交，影响数据分析的效率和准确性，因此需尽快搭建权限控制合理的业务指标提取逻辑分享平台，解决“业务逻辑信息孤岛”问题。
建立由信息治理部门主导、以业务部门为中心的大数据创新立项机制。大数据应用要求尽量压缩数据分析业务链条，进一步提高具体业务与数据分析环节结合的紧密程度。
对此，可以探索建立由信息治理部门主导、以业务部门为中心的大数据创新立项机制。
简言之，就是将数据分析师融入具体业务部门，由数据分析师和具体业务部门共同发起大数据应用的创新项目立项，经信息治理部门审批后，给予相应的计算资源，并依据数据应用项目在具体业务中产生的效果进行评估和激励。
大数据只需要Hadoop平台吗?
Apache 软件基金会(ASF)旗下的海杜普(Hadoop)开源项目对于大数据应用无疑有着巨大的推动作用，基于Hadoop的HDFS系统也是目前主流大数据平台的重要基础设施，那么是不是有了Hadoop平台，商业银行就拥有了大数据处理能力了呢?
首先，从软硬件平台的完备性来看，还需持续投入，配置更多的软件模块，以提升大数据分析平台的能力。
Hadoop只是大数据分析平台的基础设施，除了基于Hadoop及Yarn的Hive、HBase、Pig、Storm之外，mahout、Hadoop-R、Hadoop-weka等数据分析、数据挖掘套件对于大数据分析也是必不可少的，另外速度更快、性能更高的Spark体系也在互联网企业获得了成功的应用，值得商业银行关注和借鉴。
其次，从数据的来源来看，还需改造前端，以获取更多维度、更高频次、更细粒度的数据。
商业银行的数据分析系统长期以来重视业务数据的存储，而对于系统运行状态的日志、客户个人信息的收集并不重视，而这些信息恰恰是大数据分析得以理解客户、排查业务问题的关键所在。
因此，商业银行需要系统性地进行应用前端改造，借鉴互联网企业、电商企业的做法，设法获取更多维度、更高频次、更细粒度的数据，更好地满足大数据分析对数据源的需求。
最后，从项目的执行过程来看，还须形成“数据分析+业务应用”的数据分析模式，以迭代方式优化分析结果和具体业务。
传统的BI模式下，数据分析的业务流程可以概括为：接受业务部门提出的分析需求=>数据分析=>形成报告。
而大数据分析的很多项目需要数据分析师与业务人员一起进行持续迭代，有的项目甚至很难确立一个明确的终止时间点(例如电商的推荐系统一般由一个团队持续优化)，这就需要商业银行能够允许在特定的大数据分析项目上，采取“数据分析+业务应用”的数据分析模式，以迭代方式优化分析结果和具体业务。
可见，Hadoop平台并不是商业银行具备大数据能力的充要条件，商业银行不仅需要在软硬件平台上持续投入，还需要在前端设计、数据分析模式等方面加以改造，才能更加适应大数据分析的要求。
大数据只是数据分析部门的事?
如前所述，大数据能力是以数据分析为基础的，融合商业决策、客户感知、个性化服务为一体的综合竞争力，因此，大数据能力建设就不应仅由数据分析部门来承担。
要从战略层面将大数据能力建设纳入发展规划。
应做好顶层设计，把大数据能力建设与信息化银行建设结合起来，与线上线下一体化建设结合起来，与互联网金融发展战略结合起来，协同业务、渠道、科技、数据分析等多个部门，做好顶层设计和统筹规划，形成“全员大数据”的氛围，从数据源梳理、数据分析平台搭建、分析模式确立、外部数据交换规则等多个层次制定明确的方针与操作标准，加快大数据能力建设的进度。
要重视数据分析流程的效率提升。
大数据分析的效用大小，很大程度上取决于数据的活性以及分析结果投入具体业务的速度，因此，要尽可能压缩传统BI的业务链条。
可在电子渠道和自助渠道尽可能地实现数据采集与分析结果应用的一体化(例如，基于客户个性的产品关联推荐、基于场景的实时定价、自助设备界面个性化自适应等)，也可在传统的BI领域中，应用大数据的处理模式，以高实时性的中间数据层为媒介，建立效率更高、实时性更强、管理者自定义程度更深的商业智能系统，实现商业报表的实时化、移动化、定制化。
要重视人才储备和技术积累。
大数据技术的发展日新月异，数据的人才储备和技术积累却不能一蹴而就，需要相当力度的持续投入。
人才储备方面，应本着“引进一批，培养一批，储备一批”的原则，引进一小批高层次技术人才，通过具体的项目实施，培养大量的存量技术人员，并通过面向高校和社会的大数据技术竞赛、资助开源社区等方式，形成广泛而有效的人才储备。
技术积累方面，应按照“开放并包，为我所用”的思路，组成大数据预研团队，积极开展开源项目的筛选、验证、吸收工作，沿着“引入并消化大数据开源项目—资助大数据开源项目—提出并主导大数据开源项目”的路径，不断强化自身在大数据技术方面的优势，形成自身的核心竞争力。
本文作者：谢尔曼 黄旭
来源：51CTO
