大数据是当前最炙手可热的技术方向了，但是对于大多数的传统企业和组织而言，虽然对大数据有了一定的了解，但是具体应该如何应用大数据的技术来帮助企业和组织提高效率、降低成本、优化业务等，仍然不够清晰明朗。
本文试解释大数据应用的整体过程并对初始应用大数据的切入点进行展开阐述。
1前言
严格意义上说，大数据可以算是一个伪命题：大数据概念的产生只是折射了组织机构中数据极速增长的情况。但是这种增长不是一夜产生的，过去也存在，并且至今也没有一个被广泛认同的大数据的定义标准（例如容量多少算大？价值密度的考量标准？数据增长速度多少算大数据？实时性的具体要求？）。所以，现在所谓的大数据与原来的数据需求并没有本质的不同，只是有一些新的技术出现能够更好地支持对较大规模数据的处理，并且维持一个相对合理的成本（硬件使用成本和时间开销成本）。
但是，有一些声音把Hadoop与大数据等同起来也是不恰当的。Hadoop所带来的分布式计算的思想无疑是解决大规模数据处理的基础，但并不意味着Hadoop是放之四海而皆准的技术框架。
企业和组织中的数据已经成为良好竞争力的基石，能够帮助到生产效率的提高、企业增长和创新。但是快速增长的数据也带来了新的挑战：如何理解数据并从中寻找价值、达成生产效率的调高、企业的增长和创新？
大数据技术开始普及之初，差不多所有对数据量的讨论都聚焦在基于互联网产生的海量数据和多媒体类型的数据，而几乎没有人对企业已有的数据进行深入分析和应用。但同时稍具经验的人也同意互联网数据的质量与企业内部数据的质量相比是天差和地别。
2大数据应用过程概述
所有的数据应用，无论数据是大还是小，是基于传统的数据仓库还是新兴起的大数据技术，都需要两个大的阶段：数据准备阶段和数据应用阶段。其中数据准备阶段又可以分为数据采集、数据存储和数据管理三个部分（注意，不是三个环节，因为未必是三个割裂的步骤），数据应用阶段大体上包括数据分析与挖掘、数据展现与应用。
传统的数据平台（并非大数据独有的）通常会包括ODS（OperationalDataStore）、数据仓库（DW–DataWarehouse）、数据集市（DM–DataMart）这三个数据存储与计算的节点，中间基本上依靠ETL工具或定制化的开发来实现数据的流转。这种体系架构的定义是因为局限于传统IT体系架构的处理能力和企业对数据管理/治理的重视程度：
一、传统的IOE架构（垂直体系架构、RDBMS数据库的方式）由于成本高及处理能力上限较低的问题，所以无法以一个统一的数据平台支持全企业范围的数据管理及后续应用的需求。这样的体系架构带来的问题也很多：
1、没有一个企业范围的统一数据平台将导致每个数据应用项目单独从数据采集、数据预处理到数据存储等环节都需要单独建设——重复建设、效率低下；
2、因为数据并非全企业范围的，往往导致数据维度有欠缺；
3、由于多个入口，后期维护的成本和人员开销也大，还容易导致数据冗余和一致性问题。
二、认知问题导致仅仅重视最终的数据应用的建设，但是忽视前期的数据准备环节的建设——无论从成本投入上还是项目周期上及组织协调上都没有做到全企业范围一盘棋，导致每个项目没有对数据准备做充分的工作。
为了改变上述存在的问题，企业（政府）应该构造一个全组织范围统一的数据管理平台，这个平台需要采用先进的分布式的体系架构来规避大规模数据存储与访问的成本、水平扩展及效率上的问题。只有先解决了这个问题，才能真正面向全组织范围进行数据的汇集（采集后存储）。
在这个过程中，为了形成小步骤迭代的实际效果，应先尽可能多的汇集数据。对汇集的数据先按照原生状态进行存储与基本管理，在后续的时间中进行小步骤、短循环的数据预处理的迭代——即进行一些数据的梳理、不断提升数据质量、数据标准化与主数据的制订等，并形成主题数据。部署结构可以参考下图。
图1-数据汇聚管理平台
上图给出了部署的示意，但是每个环节做些什么事情、需要什么能力呢？如下图所示，每个部分往往需要不同的技术、人员的参与。数据源代表了当前组织内已经有的数据，在真正实施之前需要对基础的数据集状态做基本调研，调研内容要包括数据的形态、数据的访问方式等内容。（这时尚不需要进行业务数据方面的梳理和调研）
第一个步骤是数据接入。接入的部分并不需要一次性把所有数据源都接入。对于任何的企业或政府而言，基本上也不具备在这一环一蹴而就的能力——数据源也是不断涌现的。所以这一部分建议先构建主要业务系统的接入，需要从数据的形态和数据的访问方式上都予以支持。
第二个部分就是数据存储了。数据存储是在接入的环节就需要考虑的，最主要考虑的内容就是应该对全数据形态都兼容——支持结构化与非结构化的数据存储，也支持一些文档等形式的数据的存储；由于考虑到全组织内的数据是较大规模（TB到数十TB级别）甚至极大规模（百TB甚至PB级别），并且组织还在不停的发展，需要该存储部分能够支持分布式的体系架构和较好的水平扩展能力，不依赖专有的存储设备（这类设备通常造假高昂）。但也值得提出的是，虽然Hadoop技术栈提供了HDFS的分布式文件系统和基于Hive的数据库访问接口，但是由于HDFS的初始设计是为了Map-Reduce的计算，所以不适合进行中小文件的存放与管理。Hive由于是构建在HDFS上的数据库接口，其效率依赖于HDFS的效率，也并不适合进行大规模结构化数据的存放与访问。
第三部分是数据管理。这里提出的管理是面向数据的后续梳理、治理和数据供给等内容。基于这个数据管理可以构造数据资源体系、数据从原生形态到主题形态的处理、数据的供给等。
上述的三个部分并没有把一般意义上的ETL（数据的部分预处理）单独列出，主要原因是我们在考虑一个完整的企业级的大数据平台，那么这个平台面对后续不同应用的时候可能存在数据的不同处理；同时ETL的能力也应该在数据管理的部分予以考虑，而不是一个独立的部分。
图2-数据准备的三个部分（数据源是已存在的）
另外，现代的数据治理理念通常都会讲几个概念：
1、治理需要组织的重视与参与，组织是人的构成，还包括执行一些例如数据标准化的智能等内容；
2、治理还需要定义流程并与业务集成，一定的流程是需要的，但是不能仅仅从管理方法论上考虑，应该有一个系统来指导；
3、治理还应该考虑数据标准化、主数据等内容；
以上内容或多或少地都已经包含在上图中，后面会相应展开。但是这里先强调一点：不能够先搞一个标准化组织，协调大量人力做完整的数据调研和梳理，然后才进行集成和后续ETL转换、清洗等工作。因为如果这样做势必导致项目周期漫长，但是这个治理阶段仅仅是数据的准备而非最终的应用，而准备阶段是为数据应用进行服务的。同时由于企业和IT技术的变化很快，等到一些数据与业务梳理好了开始进行后续数据应用开发的时候，可能业务发生了变化导致不得不对治理的过程进行迭代，导致额外的工作和成本。
3、大数据建设中的需求
3.1数据采集
说到数据采集，不得不说说两类不同的应用和数据时代的特点。
OLTP和OLAP是两个技术型的术语，同时也代表了两种截然不同类型的应用：OLTP通常是自己产生数据并提供一定业务逻辑，大多时候仅仅是人的延伸，帮助快速处理或者自动流转业务过程；OLAP则不同，这类应用是需要消费OLTP所产生的数据，而不能自己基于业务创造数据。
因此就需要有数据采集的过程帮助OLAP的应用从OLTP的应用中完成数据的收集过程。当今的大数据应用无疑就是典型的OLAP的应用，而过去我们听过的或者即使未听说过的各种应用基本都是OLTP的应用，是采集数据这个动作的源头。（简单举例能够提供数据的传统应用：各类企业的ERP和CRM、银行的账务系统、运营商的计费系统、制造业的MES和SCM、医院的HIS和EMR、城市交通监控系统、税务、社保、人口户籍、工商的企业注册系统等等，数不胜数。）
数据采集–数据采集又称数据获取。传统上是电气系统里采用的术语，这里借用来指代在基于TCP/IP的IT环境中，从已存在的第三方系统采集数据并输入到后续汇集数据存储的过程。
在互联网企业的角度看，数据采集基本上是基于互联网的爬虫技术，因为互联网的数据绝大多数是基于HTTP协议可以访问的各类HTML或其他文档数据等。但是企业和政府则不同，他们的数据主要以RDBMS的结构化数据为主，少数企业可能以特有的非结构化数据为主（例如新闻媒体机构、基因检测机构等），但95%以上的企业或政府的主要数据都是结构化的并保存在传统的RDBMS数据库中。这样的数据相比互联网数据而言质量好、价值密度大，但结构复杂，访问困难。下面我们就看看企业数据采集中的要求与挑战。
由于企业的IT建设形成的周期长（国内有一些企业或政府现存的IT系统最早有20年前甚至更早的），在这个过程中IT技术几经发展，每个阶段都采用了一些不同的建设方式；相应的，应用开发商也不断的引入新的力量。这样的情况导致对当前企业数据的现状没有全局的了解，对于每个数据源的技术和业务状态缺乏足够的了解。但实际的需求不会因这样的局限而降低：
原系统在业务期间可能已经无法承受额外的压力，要在不产生新的压力的情况下来完成数据采集；
很多核心业务系统长时间运行日常业务处理，真正能够给到进行单独数据采集的时间有限（例如：财务系统往往在下班后还要出报表、做账务结转等工作，在之后还要进行数据的例行备份工作，能够给到数据采集的时间不超过4~5小时），如果采用每日一次的采集方式，则必须在有限的时间里完成；
传统企业IT架构可能存量数据很大，但是并不会进行变化数据标记，也就意味着每天一次的采集需要面对全量数据，后续的处理过程中要有识别这种变化数据的能力；
虽然企业或政府的核心数据与主要数据是基于RDBMS的，但是仍然有可能有些外围数据是基于文件、接口等其他形式，所以仍然需要数据采集能够兼容多种数据形态与多种数据访问方式。
现在企业的运营在加速，对数据的捕获、采集及后续处理都需要加速，从原来的T+1到准实时（分钟级延迟甚至秒级延迟）；在一些引入机器的业务过程中，要充分考虑流式数据处理的架构。
从数据采集效率和处理能力上，要至少能够满足当前数据量最大的系统及最大变化数据的业务高峰的处理需要；要能够满足未来至少3~5年的业务增长（至少采用水平扩展的方式来支持）。
3.2数据存储
这里用了数据存储的提法，但并不是传统意义上的硬件存储的概念。数据被采集后需要保存在一个统一的数据存放的平台，这个平台就需要满足这里要讨论的数据存储的需求。
之所以采用数据存储的提法，是因为要综合考虑全面的数据存放需求，不仅仅是数据库的结构化数据，还需要考虑文件型数据、文档型数据及机器产生的数据等。这就意味着需要对结构化的数据提供良好的保存、访问的能力，还要对文件数据（非结构化）数据提供良好的保存和访问的能力。这些数据的保存与管理应该采用统一的或称为融合的技术，而不是不同的、割裂的系统。下面对每种数据的存储需求稍作展开。
3.2.1基本数据存储需求
数据库的数据存储需要考虑统一平台、相对隔离，相对隔离就是虽然可以统一进行存放，但是能够独立控制访问，从安全性上有着良好和充分的考虑；由于来源于众多系统，数据总量将会巨大（目前国内一个4线城市的政务融合数据库的结构化数据已经达到上百TB），所以需要采用分布式的数据库技术，而不是传统的IOE架构。对于未来的数据增长具有水平扩展的适应能力，同时数据的吞吐能力也随着数据量的增加，分布式节点增加带来存储空间的同时，也线性提升了数据的吞吐能力。
文件数据的保存需要综合考虑大文件和小文件的需求——例如视频数据往往以特殊的流式数据保存，或者通过一些大文件的组合方式来保存（单一文件可能从MB到GB，总体容量需求达PB甚至数百PB），但是一些日志数据、交易传输数据等往往以中小文件的方式存放（小到KB甚至数十个字节）。需要这里的数据存储能够通过可接受的成本提供海量小文件的高效率存储于吞吐和大文件的存储能力及良好的吞吐能力。
除了上述这些最基本的需求外，由于数据的重要性已经无需讨论，所以这里的数据存储必然还需要满足RASP的企业特性，及可靠性、可用性、可扩展性和良好的性能。可靠性要求数据能够根据一些具体情况提供不同等级的保护能力——本地冗余存放、异地冗余存放、冗余度设置等。可扩展性及良好的性能都可以通过可水平扩展的分布式架构来实现。可用性的具体需求后面再讨论。
以上仅仅提到了最基本的数据存放与吞吐需求，并未探讨数据可访问性、可用性、可见性及安全性的需求，这些需求将在“3.3”节“数据管理”中详细分析。
3.2.2融合平台数据管理需求
数据存储除了上述的容量、类型、吞吐和水平扩展等方面的需求，还有一个内容这里也做一个展开。
在图1中我们列出的融合数据有两个，一个是“原生”、一个是“主题”。为什么涉及两个融合数据的存放于管理点？它们各自的建设目的与需求是什么？
首先，数据汇集在一起并最终提供给后续的其他基于数据的应用来使用，是需要对数据进行关联、映射、匹配、清洗、完善、丰富，然后通过后续的数据服务提供数据的实时推送、自动更新、批量下载、即席查询等多种数据供给方式。但是数据的关联、映射、匹配、清洗、完善与丰富的过程并不简单，往往周期长、是个不断迭代的过程。同时，作为数据源的应用系统往往也不是一成不变，随着业务的不断发展，这些应用也不断地发展着，在发展的时候大多还会改变原有的数据形态，而这又给数据的一些基本处理过程带来了极大地挑战。
为了解决上述问题，一个比较好的处理方法是先不对原有的数据做任何处理，仅仅汇聚在一个统一的数据存放点——即上文中提到的原生融合数据，除了在不同的存放技术之间做一些最基本的兼容性上的调整，所有数据保留了最原始的形态，基于这些原始形态可以更容易地开展数据的梳理，只有经过梳理才能进行后续的关联、映射、匹配、清洗、完善与丰富等操作。经过这些操作之后的数据往往并不是按照原有的数据源来进行管理，而是基于业务上的意义进行管理，这就是上文的主题融合数据。例如：从政务的角度有人口数据和法人数据等，人口数据包括了所有面向自然人应有的数据内容——姓名、性别、学历、履历、职业、健康、消费、信用等等内容；而企业角度可能有产品数据、客户数据等，产品数据应该涵盖产品方面的所有数据内容——产品型号、定价、销量、生产成本、组成的零部件数据、相关零部件的供应商数据、产品的物流数据、订单数据、售后服务数据等等。
如果只是从数据价值挖掘分析的角度，那么基本上需要以主题数据为基础对外提供数据供给；但如果从数据的业务交互上，有时也需要从原生数据为基础提供数据供给。在主题数据侧的数据供给可以以批量、定时的方式来，但是也应该支持流式、准实时的方式。在原生数据侧的数据供给，则大多应采用流式、准实时的方式。
3.3数据管理
数据是非常具有价值，同时也是传统IT与大数据时代计算机系统的基础资产。但是数据是电子方式存在的，不像实体的资产一样直观可见，不通过特殊的软件体系数据内容对于管理者是不可见的。即使采用一些基础的数据访问能力，对于业务人员也无法理解数据的含义。所以数据的管理首先是要进行数据资源的记录与展现，这个过程的第一环就是“数据盘点”的过程。在本文的最后会对“数据盘点”做展开的阐述。
为了实现数据的盘点和资源的记录与展现，首先要兼容各类的数据格式——结构化、非结构化、数据库、文件等等。也就是我们需要一个通用的数据资源“记录本”，这个“记录本”能够以一个通用的形式对不同形态的数据都做记录，还要能够把具体的数据内容都在一个平台上存放。所以这里有两个部分的内容需要考虑：
1.数据的标准化，对于不同的数据类型以及一些基本的IT维度的内容要制定一个最基本的标准。例如：日期的记录必须采用统一的格式，如“YYYY年MM月DD日”。不能够每个系统各自一套。（文件不在此列，因为对于文件而言，往往保留的是无法被结构化的数据内容，如果原来是文件，但里面采用了结构化的格式记录的内容也是实际上是结构化的内容，则应通过数据库的形式来记录在融合库中，而不是继续采用文件的方式）
2.统一的账本，无论数据的原生形态如何，都需要在这个管理平台上以一个账本格式进行记录和展现。数据是有安全和权属属性的，在做数据融合的时候，仍然需要尊重和保留数据的这些能力——即应该对数据的来源进行记录、对后续的访问进行控制、对数据的安全或等级进行保护。所以需要对数据的来源、安全控制进行细粒度的管理，如果需要还应该有一个基于数据归属的数据授权流程机制，由真正具有权限者对使用申请进行审核并决定是否可以被申请者访问。
由于数据是有价值的，尤其是面向客户和一些财务相关的数据承载了巨大的价值，但同时也是对所描述对象的一些基本属性和行为的详细档案，这些档案在访问上应该受到限制，但应该最大限度减少这个限制对价值挖掘的影响。可以采用的做法可以有敏感数据屏蔽，即仅开放不敏感部分；还可以采用统计结果开放的方式，即不会有个体数据提供给数据申请方，系统仅仅是根据申请人的统计性需求在平台内经过计算后提供最后统计结果。由于结果数据不会指向任何一个具体的对象——无论是人还是设备等其他对象。
值得一提的还有一点：虽然企业的核心数据相比互联网数据而言，质量有着极大的差异，企业数据有着互联网无法比拟的数据质量，但是多数时候在数据进行汇聚中会发现，数据仍然存在很多缺失、不同来源之间相互矛盾等情形。为了能够让后续的业务过程能直接使用这个大数据平台上的数据，就需要先期对数据的质量进行一些提升，这也是数据管理方面的需求。数据质量的提升最开始应该先解决易于处理并带来较大直接收货的内容。
3.4数据统计
数据的后续使用有很多形式：数据的交互、数据统计和数据挖掘。其中数据的交互通常是OLTP系统在业务过程中对小量数据、以较好时效性（例如数据延迟5秒）进行流转以支持跨系统的模块和做和业务流程优化、自动化能力提升等。数据统计则是基于现有数据进行简单的统计计算，对数据分布或表示的实际业务意义进行汇总和展示。这种数据统计完全不是新鲜内容，但是其处理过程也相对简单，但仍能揭示很多有价值的信息。数据挖掘则不同，数据挖掘是对数据深层次所蕴含的规律和价值进行深入研究并基于一些计算机自动处理的方式来实现的数据利用过程。
数据统计在数据分门别类进行管理之后，这一环是易于实现的。本文主要讨论大数据的数据准备环节，不对数据统计展开。
3.5数据挖掘
数据挖掘就是通过大量数据和一些特殊算法来揭示业务上一些外在表象不尽一致的一些事件之间的关联与趋势。这能够帮助企业经营者发现出现问题的原因、外部条件等。所以能够更加深入地发现数据的价值。
数据挖掘也是一个专门的领域，本文不做展开讨论。（翱旗有数据挖掘方面的出色解决方案，如有兴趣，可以另外获得相关信息）
3.6数据应用
数据应用则在有了良好数据准备之后呈现一个百花齐放、百家争鸣的景象，非常类似苹果手机及上层软件的关系——在一个统一的基础操作平台（iOS）之上有着数量巨大的各个类别的应用软件。具体的数据应用可能与所属的行业有关，也可能与不同的角度有关（客户画像、故障预警、制造流程优化等）。所以数据应用势必需要广泛的IT企业参与其中。那么对于一个要进行数据应用建设的组织而言，更恰当的应该是完成数据的准备，提供数据的使用接口来帮助后续的应用开发人员快速实现数据应用的构建。
为了能够适应市场飞速的变化，不断保持乃至提高竞争力，则需要这个数据平台能够有效支持应用的快速迭代开发。这需要应用开发甚至前期的数据准备都采用“小步快跑”的思路，而不是瀑布式的每个环节都完全完成后才开始后续工作。这样的思路基本也是不可行的：
如果一个企业把所有当前数据都梳理清楚才开始进行数据采集与集成、汇聚，这个数据准备的周期将非常长，而且也会有很大可能刚刚梳理完成准备进行集成的时候发现，远端数据结构已经变化了。可是怎么解决呢？在第5章的数据准备的建设步骤中将做详细阐述。