为什么很多大数据项目搞着搞着就黄了？为什么很多大数据项目搞着搞着就黄了？夏天的淘金热百家号大数据正在改变世界。但是，大多数大数据项目搞着搞着就黄了，很难成功。这是为什么呢？企业正努力在产品中部署大数据，这一点是毋庸置疑的。但是，根据Gartner在2016年下半年发布的新闻稿：只有15％的企业将其大数据项目部署到生产中。”Gartner在选词时非常谨慎，这并不意味着剩下的企业没有实践，或者数据科学家没有发现使用大数据技术的优势，只是剩下的85%的项目并没有真正投入生产。问题不在于缺少大数据分析或者是大量的数据科学实验。真正的挑战是缺乏大数据自动化能力，以便将实验版本从沙箱推入功能齐全的生产环境中。大多数人认为分析生产就是调整集群。当然，可以编写一个sqoop脚本并将表格放入一次。但是，在不影响源系统的情况下多次实现则是一个挑战。然后，必须确保构建的数据管道在由服务级别协议（SLA）设置的时间范围内提供数据。此外，数据模型需要针对用户当前正在使用的工具（如Tableau，Qlik等）进行优化，以达到用户所期望的响应能力。在Hadoop和Spark之上使用工具进行大量的努力和改进以对大型数据集进行快速原型设计。但原型是一回事，创建每天运行而不发生故障的数据工作流程，或者在数据流作业失败时自动启用恢复，又是另外一回事。本文作者分析了五大大数据项目夭折最常见的技术原因：1、无法快速加载数据以满足SLA虽然像sqoop这样的工具支持数据读取的并行化以从传统数据源获取数据到数据湖，但需要专家来使其正常工作。如何划分数据？要运行多少个容器等问题都需要专家给出合适的解决方案。如果无法正确处理并行数据的读取，则一个小时就可完成的任务甚至需要10到20倍的时间，因为大多数人不知道如何正确调整。2、不能逐步加载数据以满足SLA大多数企业并未将整个操作转移到大数据环境中。他们从现有的操作系统移动数据以执行新的分析或机器学习，这意味着需要在新数据到达时继续加载。问题是这些环境不支持添加，删除或插入的概念，这意味着必须重新加载整个数据集（请参阅上面的第1点），否则必须围绕一次更改捕获问题编写代码。3、不能以交互方式提供对数据报告的访问权限想象一下，如果有1000位商业智能分析师，他们都不想使用您的数据模型，因为他们需要很长时间才能查询。这是Hadoop的一个经典问题，也是许多公司仅使用Hadoop进行预处理和应用特定机器学习算法，但随后将最终数据集移回传统数据仓库以供BI工具使用的原因。无论如何，这个过程又为成功完成大数据项目增加了难度。4、不能从测试迁移到生产许多企业能够确定沙箱环境中数据科学家的新见解的潜力。一旦他们确定采纳新的分析方法，就需要从沙盒转移到生产环境。从开发转移到生产是一个完整的升降和换挡操作，通常是手动完成的。虽然它在开发集群上运行良好，但现在相同的数据管道必须在生产集群上重新优化。这种调整往往需要大量的返工才能有效执行。如果开发环境与生产环境有任何不同，则情况尤其复杂。5、不能管理端到端的生产工作量大多数企业都将注意力集中在工具上，因此他们的数据分析师和科学家可以更轻松地识别新的方法。但是，他们没有投资类似的工具来运行生产环境中的数据工作流程，因此不得不担心启动、暂停和重新启动过程，还必须担心确保作业的容错性，处理通知以及协调多个工作流以避免“冲突”。因为上述五大技术原因，导致很多大数据项目并没有如期与我们见面。当然，如果你有更棒的见解，欢迎在评论区留言。本文由百家号作者上传并发布，百家号仅提供信息发布平台。文章仅代表作者个人观点，不代表百度立场。未经作者许可，不得转载。夏天的淘金热百家号最近更新：简介:江河皆海，容大。悬崖上可以没有自私的欲望是严峻的。作者最新文章相关文章恒丰银行：基于大数据技术的数据仓库应用建设
恒丰银行探索采用大数据技术构建统一的企业级数据管理平台，重构数据仓库应用，减少数据重复加工与存储，促进信息管理应用的数据融合共享，提高数据处理总体效率，提升数据分析和应用创新能力，正逐步取得预期的成效。
伴随着商业银行业务的快速发展，传统数据仓库技术架构面临越来越大的挑战。与此同时，以Hadoop/Spark为代表的大数据技术发展迅猛，为解决传统架构的瓶颈带来了新思维。以大数据技术为基础的数据管理平台与传统数据库软件相比，具备如下优势：
(1)更低的成本投入
能够基于X86服务器弹性水平扩展，通过节点冗余增加容错能力，多核计算资源能充分利用，相比小型机方案成本低廉;利用本地磁盘做存储，节省昂贵的集中存储设备投入;软件产品和服务的价格更低。
(2)更强的整体处理能力
消除集中存储的带宽瓶颈，可采用SSD介质加速随机读写速度,获得极高的IO处理能力;针对并行计算需求设计，采用异步无锁的高并发服务框架，提供可线性增长的数据并行处理能力，可提供高并发低延迟数据处理服务。
(3)更优的资源管理和调度机制
可提供弹性的租户资源管理体系，防止不同应用之间的资源过度竞争，在不同时间段为各应用按需调配资源，利于在一个统一的数据平台上构建多个应用系统。
处于业务发展的新阶段恒丰银行，更需要一个低成本可线性扩展的数据处理平台，解决企业多个数据应用形成数据孤岛，数据资源难以共享、数据标准不一、存在大量冗余数据的问题。恒丰银行在进行充分的可行性分析后，基于大数据平台重构优化了数据仓库及关联应用。同时基于统一的企业公共数据模型上构建发展各应用集市和分析集市，减少数据的重复加工和各数据应用的开发成本。
最后，构建了包容实时数据应用和数据分析型应用的统一软硬件技术架构，同时满足联机数据查询和海量数据分析需求，提高数据应用的开发效率和增强了服务器资源有效利用率，减少了应用总体开发和部署成本。
二、恒丰银行大数据技术服务
(一)任务、目标
利用大数据技术可有效构建以数据仓库应用为核心、弹性扩容、资源相对隔离、多应用共存的分布式集群数据管理平台，有效解决长期积累的问题：
(1)解决平台处理能力不足，应用分散问题
分布式并行数据处理解决超大数据集的可计算难题，加速统计分析应用的响应速度;提供可统一调度的超大硬件资源池，多个上层应用和数据仓库可共存于一套集群环境，极低成本快速实现企业应用之间数据的共享与融合，减少数据跨系统复制导致的数据批处理时延，减少多个应用数据库独立部署带来冗余的数据存储成本。
(2)强化数据仓库核心应用地位，实现企业数据治理目标
数据仓库应用承担更多的基础与共性数据加工职能，有利于聚合应用共性需求，有效管控和实施数据标准，统一关键指标计算口径，易于实现数据治理目标。
同时，建立统一的数据处理任务调度平台，多个数据应用可以和数据仓库应用整合，统一配置数据批处理任务和调度依赖关系，复用数据仓库建立的企业数据模型资源，更清晰划分数据处理职责边界，减少数据重复加工和开发成本，缩短各应用数据批处理时间，实现各系统每日尽早开放服务。
大数据技术是一种新型的技术，从接触概念、了解技术到大数据平台落地，会遇到了多方面的挑战，主要体现在大数据产品的选择、平台架构与应用的规划，人员培养三个方面。
1、大数据产品选型
选择的大数据产品应满足以下特点：
(1)兼顾大数据批量处理和小样本数据精确查询统计的性能需求
系统应该在全量数据并行处理和小样本数据快速过滤两种场景都有高性能表现，同时能并发处理尽量多的小样本数据计算需求。
(2)优化的数据存储与访问管理模型
支持表索引、数据分片(sharding)/分区(partition)、行列混合存储、数据块分布统计、复制表等概念，减少数据插入、更新和访问的总体IO时间成本。
(3)有效合理利用资源
减少JVM Inbox/OutBox与多层数据复制引发的内存膨胀，尽量避免出现JVM GC引发的性能抖动，减少跨网络节点的大量数据广播，避免不必要的重复计算。
(4)易于开发和原有应用尽量平滑迁移
支持SQL2003标准，在TPC-H、TPC-DS基准测试上有良好表现，对主流传统数据库的专用特性(如Oracle存储过程)提供了必要的兼容性支持，在API设计和开发工具软件支持等方面减少系统迁移和新项目开发成本。
(5)高度容错能力
同时支持Erasure Code1.5副本和3副本以上的数据容错和快速修复;消除全系统软硬件单点故障，任何单点失效都有容错部件接管服务职能。
(6)友好的运维监控界面，提供外部集成接口
集成化的运维监控管理页面，同时可为行内集中监控系统提供软件部件实时状态信息与故障告警服务接口;可以跟踪当前作业任务进度和资源使用情况。可详细持续记录SQL执行计划和实际成本消耗，统计分析资源消耗较多的热点SQL。
(7)支持在线扩容
系统能够动态不停机扩容，可自动实现数据自动重分布，扩容时现有系统可以不间断正常运行。
2、平台架构与应用规划
大数据产品源自广泛的开源技术，是多种分布式存储、计算引擎与资源调度的有机组合。架构与规划的难点在于需要架构设计人员清楚地了解各类存储引擎的适用场景，对应用并发、时效性、资源消耗等需求有明确的认识，合理地组合各类存储，设计数据流转，才能发挥大数据技术的优势。
同时，需要对上层应用进行分类，针对不同的分类要分配不同的计算、存储资源，细化资源隔离与管控的粒度，充分合理地利用硬件资源。
3、人才培养
大数据平台技术平台比传统数据库技术复杂得多，对开发实施团队的技术理解能力要求很高，参与人员的技术培训和辅导是个长期的过程。按人员专长成立了技术架构设计、基础环境支持、应用项目开发、性能测试与系统优化、数据模型设计、数据分析与建模、数据标准治理等多个专业小组，各施其职、通力协作。
由于项目使用的大数据技术较新，基础软件产品也处于迭代开发中。恒丰银行致力于打造一个学习型组织，加强包括行内员工和合作开发公司员工的技术培训，对大数据应用开发的难点编写培训教程和制定开发规范，建立微信学习群，不定期的分享开发经验和剖析不良的实现案例，做好了分层知识传导，帮助大家在实施开发过程少走弯路。
4、实施过程/解决方案
技术平台能力要求
企业应用数据能力按数据处理时效性可分为：
(1)离线批处理。T+1日时效性的数据应用，在企业内部目前占大多数，包括传统的数据仓库应用和CRM等系统应用等。
(2)准实时应用。能够在生产数据产生后1分钟处理完的应用，一般形成生产系统是松耦合的旁路数据流关系。主要基于大数据的流处理技术实现，一般设置一定的数据采样时间间隔，通过系统在线日志数据采集或网络报文旁路方式提取业务发生数据，为交易监控、风险预警、客户服务提供接近实时的处理能力。
(3)实时应用。能够在生产数据产生后的1秒内甚至几毫秒内完成的应用，主要与生产系统形成协同服务支持关系，通过企业内部服务同步调用或异步消息事件处理方式实现与客户交互或交易过程中基于大数据的深度加工处理能力。
典型实现方式是构建实时流处理与实时事件总线相结合的实时处理架构，构建渠道端的异步事件处理能力。典型的应用场景有实时交易反欺诈、个性化场景营销服务等。
从技术支撑能力按从易到难顺序可以分为如下阶段：
(1)支撑海量数据存储和低延迟联机查询。将企业主要数据汇聚到一个平台上，支持大并发的低延迟联机查询，这也是一般企业应用大数据能力的初步目标。
(2)支持统计分析应用。包括即席业务统计报表、多维业务数据分析、客户群体细分等应用，一般可替代传统数据仓库的主体功能。
(3)数据探索与业务预测。支持业务分析团队的数据探索和业务建模实验，实现诸如业务趋势预测、客户行为预测等高阶应用。
(4)决策支持能力。通过应用决策树、规则推理引擎、运筹优化技术，实现客户定价、风险预警等领域特定业务问题的机器自动化流程管理和简单人机交互方式的辅助业务决策支持应用。
(5)自主学习能力。通过引入深度学习网络、知识图谱、遗传演化等智能技术构建相对复杂的机器智能学习体系，能从海量数据中提炼高价值信息，构建自主训练与反馈、可不断从最新数据中调整演化的智能业务模型体系。
5、企业数据管理平台功能层次
数据管理平台按企业数据能力需求的功能实现，可分为如下层次：
(1)数据存储层。对应不同应用需求场景和业务数据特点(更新频度、生命期、数据价值密度)，可整合不同的底层存储技术和不同的数据库引擎，实现多样化的数据存储服务。
(2)资源管理层。构建在最新的大数据技术基础上，具备灵活的资源管理和并行计算调度能力，实现多种数据管理组件协同服务的分布式协作软件框架。
(3)数据汇聚层。满足生产系统日志准实时采集、异构数据源并行抽取和大容量数据发送转储需求的数据移动技术架构，T+1、T+0数据适配多种技术场景实现从源端流转并集中存储到大数据管理平台的数据存储层。
(4)流式处理层。构建实时流处理计算层，包括实时流处理引擎、高效的流数据缓存层和计算组件(包括分类、汇总、过滤、路由等多种功能)。
(5)图计算层。通过图计算引擎，实现关系网络数据的抽象、存储和快速统计计算需求。
(6)数据挖掘功能层。贴近数据存储的数据挖掘算法功能层，由并行计算能力强、集成度较高的分布式机器学习和数据挖掘软件框架实现，为应用程序提供简单API调用接口，也支持在其上构建业务数据探索软件层。
(7)数据管理应用组件层。需要自主开发完善的数据管理组件，包括元数据管理、数据标准化管理、数据生命期管理、数据开放权限管理和审批流程、跨数据集群的准实时数据复制、完善的系统运行监测与告警等。
6、技术平台与产品选型
Apache Hadoop是针对大规模分布式数据而开发的软件框架，已经成为企业管理大数据的基础支撑技术。然而开源Hadoop仍然面临一些挑战：
首先，开源Hadoop技术在对GB到TB级数据的处理效率较低。
其次，只有对海量的数据进行高效的分析及利用才能将大数据中存在的巨大潜在价值转换为实际的商业价值，这就需要完备的决策分析工具集运行在大数据平台架构之上，企业亟需完备的解决方案来加速大数据应用的业务创新。
恒丰银行从企业应用角度出发，通过对国内外众多主流大数据平台产品的技术能力和实现细节详细了解、对比、筛选，并对候选产品进行严格的POC测试，最终选择了更符合恒丰银行需求的国产TDH大数据平台产品。
针对上层应用的需求，恒丰银行利用HBase对二进制数据的高并发存储服务能力实现非结构化数据的高效存储，采用ElasticSearch发挥文本数据的快速全文检索能力。
基于商业数据可视化套件或开源的D3.js或Echart.js等Web图形组件开发业务可视化分析应用，结合大数据内存分析技术，实现业务团队自主数据探索和可视化即席分析。应用Discover,Mahout、MLlib等支持分布式并行计算的机器学习软件框架构建更高效的数据挖掘人机交互环境，提升业务建模效率。
利用Storm、Spark-Streaming等实时流处理技术，结合专家推理引擎、运筹优化与机器学习算法等数据智能技术，构建支持渠道自动化交互场景的实时营销和实时风控应用。
7、按应用场景分离的数据处理集群架构
按照应用场景需求的差异，基于大数据技术的数据管理平台可分为四大数据应用集群，并可在其上构建不同的应用系统和公共应用数据服务：
(1)在线应用集群。主要面向在线数据应用系统，有高并发低延迟应用服务响应要求。
(2)历史数据分析集群。主要面向数据历史数据分析应用、分支机构数据开放、业务团队数据自主探索和数据挖掘建模。
(3)非结构化应用集群。主要针对非结构化数据的存储、全文检索和处理(包括文本分析、图像识别等)需求。
(4)实时流处理和日志分析集群。主要针对实时流处理应用，特点是大规模快速写入需求，原始流数据的生命期较短，快进快出，一般可采用批处理模式进一步压缩提炼形成历史统计数据，用于实时流数据的机器学习与模式识别。
三、数据仓库应用体系建设
(一)结构化数据分层技术架构
基于大数据平台构建数据仓库结构化数据应用的整体架构包括如下层级结构：
1)源系统结构化数据：源系统按大数据平台的供数规范要求提供表数据文本和标志文件。
2)文件交换区FSA：文件的交换中枢，含源系统结构化数据和半结构化、非结构化数据(主要是外部数据)。
3)源数据缓存区ODM：结构化数据接入，在线数据平台的源数据历史层HDM、基础数据模型层的数据来源。
4)源数据历史层HDM：源数据缓存区数据接入。
5)基础数据模型层FDM：源数据按数据仓库模型加工后存储，源数据缓存区数据接入，公共数据模型层CDM的主要数据来源。仅大数据平台各数据层数据存储和内部流转用。
6)公共数据模型层CDM：聚焦客户营销和风险管理等业务领域公共需求的银行信息资产加工和存储，源数据缓存区、基础数据模型层数据接入，数据服务接口的主要数据来源。
7)数据服务接口DSI：在线数据平台的对外数据服务接口，源数据历史层、公共数据模型层数据接入，BI应用集市的数据来源。
8)历史数据服务接口：历史数据平台的对外数据服务接口，源数据历史层、公共数据模型层数据接入，各类查询应用的数据来源。
9)综合监管集市：包括银监标准化EAST应用在内的综合监管集市，数据服务接口的数据接入，综合监管应用的数据来源。
10)数据分析集市：BI统计分析类应用所在的数据集市，公共数据汇总层ADM的加工和存储，数据服务接口的数据接入。
11)统一调度平台：大数据平台ETL过程的统一作业调度监控，包括：调度、监控、日志、处理四部份内容。
(二)应用迁移
数据仓库应用迁移主要包括在线数据平台与历史数据平台两部分(不包含非结构化数据应用)。应用迁移的主要目标是建设在线数据平台、历史数据平台，设计公共数据模型，并实现包括银监标准化EAST等内建监管报送应用的数据切换。
整体设计思路分为数据移植、在线数据平台、历史数据平台、银监标准化EAST应用迁移四个部分。
1、数据移植流程
利用Sqoop技术连接原数据仓库抽取数据到hdfs文件系统;
将原数据仓库的数据抽取到hdfs文件系统后，在大数据平台中构建映射在这些数据文件上的外表，其表结构与原数据仓库表结构一致;
在构建外表后，数据平台已可以查询到原数据仓库的数据，为构建数据平台的HDM层源数据备份，还需将这部分的数据进行还原操作。
2、在线数据平台
在线数据平台集中了源数据缓冲层、源数据历史层、基础数据模型层和公共数据模型层。源数据缓冲层作为外部业务系统数据接入层，单日缓存业务系统每日数据，供历史明细层程序处理已存入基础数据平台。基础数据模型层保留了留原数据仓库部分基础数据模型，以支持公共数据模型及其他应用数据需求，保存模型历史数据。公共数据模型层，为数据仓库的主体数据体，是支撑数据汇总、数据分析的多纬度数据集市。
3、历史数据平台
历史数据平台是在线数据平台的数据备份，每日数据同步。历史数据平台源数据备份结构与在线数据平台一致，保存永久数据。历史数据平台公共数据模型备份结构与在线数据平台一致，保存永久数据。并依托公共数据模型的历史，构建历史数据查询服务模型接口。
4、银监标准化EAST等应用迁移
EAST等系统改造内容主要是数据连接改造(JDBC-hadoop)和参数配置调整，不包括系统功能和流程。由于EAST等系统数据结构为Oracle表，存储过程为Oracle存储过程，需根据大数据平台的特性对表结构进行重构，支持大数据平台的存储过程格式，并进行数据移植。
(三)公共数据集市建设
恒丰银行当前数据仓库存在应用离散、冗余数据加工、资源紧张等问题。所以，公共数据模型的建设需要统一需求管控，建立更大的项目资源池，减少重复开发，规划应用方向;统一计算口径，减少数据冗余和数据复制，减少重复数据加工;同时，能够满足不同应用场景的共性需求，稳妥推进新技术应用。
在主题模型领域，根据主题+业务方式进行数据存储，以具体业务为依据提练主题要素，涵盖客户、事件、产品、作业、财务绩效、资产管理、市场与公共元信息(如费率、利率与汇率)。依据可重用性、安全性、高可用性、可管理性、可扩展性、高性能的设计原则，采取总体规划、分层实现的方式。
构建公共模型层，数据来源主要包括行内数据、同业数据和外部数据三大部分：
行内数据：行内的业务系统、管理系统数据：核心、企贷、个贷、囯结等数十个源系统。九大类数据整合为公共数据模型七大主题，根据相应主题+业务划分对源数据进行重新整合分类归总。
同业数据：同业数据包括监管当局和其他银行披露的各项业务指标：规模数据、盈利数据、风险数据。
外部数据：从外部采购或抓取的数据，如公司、司法、舆情、宏观数据。
(四)数据治理目标实现
利用大数据平台提供的数据处理能力，针对数据质量管理、数据标准管理、元数据管理三个方面建立了一套完善的数据生命周期管理体系，建立统一的数据口径和数据规范。
数据质量管理：通过组件化的脚本对多数据源数据进行数据质量检查，将存在数据结构、字段分隔符、记录换行符、数据编码格式等问题的脏数据在入库前过滤出来，并通过数据入库稽核的方式，将不符合表结构定义的脏数据单独输出到脏数据记录表，支持表的字段阈值以及质量检测条件(如统计值，约束条件)等的定义，结合工作流调度引擎将数据质量检测贯穿在整个ETL过程中，并提供告警信息，通知运维人员进行处理。
数据标准管理：结合数据治理成果，将数据标准定义纳入系统管理，并以此为基础，提供数据质量自动化检测的依据。
元数据管理：提供行内数据资产概览，开放元数据查询管理应用，提供数据血缘分析和追溯能力。
(五)数据探索与业务建模
通过Rstudio和其他面向业务用户的图形化工具，可进行可视化交互式数据挖掘与统计分析，深度挖掘数据价值并建立业务数据模型，实现分析和预测功能，增强企业的决策判断力，提高商业智能化水平，提升客户体验，快速响应市场变化。
在可视化交互式数据挖掘工具基础上，恒丰银行构建了业务模型实验室应用，通过实现了一个集模型开发、模型验证、策略分析等业务功能于一体的环境，使得业务模型和策略的开发、维护、优化以及升级等工作更加标准化，实现一定程度的自动化，提高了业务建模的整体效率。
(六)开发专业数据集市与创新应用
恒丰银行详细规划了各管理分析领域的业务应用场景，形成了营销主题、风险主题、客户主题、资讯主题等专业共享数据集市，为具体管理分析域的业务应用提供了基础明细层、共享加工层、结果数据存储和对外服务接口。
同时针对各业务条线和经营单位关注点，进一步加工面向业务分析用途的主题汇总宽表，以此为基础结合公共数据集市明细表开放，构建业务部门分析集市和各分行数据集市。
在基于大数据技术的创新应用开发方面，大数据平台上已经陆续构建了业务可视化分析平台、精准营销、全面风险预警、客户关系管理、移动销售作业系统、财富管理系统、大数据资讯平台、交易反欺诈、信用卡交易监测、用户行为分析、客户生命周期管理、运营风险监测等30多个上层应用，充分发挥大数据平台在海量数据计算、非结构化数据处理、实时流数据处理、内存计算与列式存储等领域的能力与优势。
(七)全方位提升金融服务能力
为提升对实体经济的金融服务支撑能力，恒丰银行积极整合包括行业、市场相关的外部数据，构建业务发展规划平台，聚焦新兴产业、三农和小微企业，配备合理的信贷资源和人力资源，主动提供一站式的综合金融解决方案。
基于恒丰银行专业的产业经济研究能力，我们也规划通过移动互联应用，向企业提供专业的行业研究和市场分析情报，通过自建产业链交易撮合平台、O2O服务平台，降低企业交易成本与产品库存，加速资金周转。
通过与核心企业、电商平台合作，整合实体经济交易数据，共建服务于特定区域和产业链的大数据应用。运用集团授信、平台项目授信等多种授信管理创新模式，实现对三农与小微企业的定向信贷资金扶持，并在信贷评审、贷后监控、企业现金管理等业务场景充分应用大数据建模技术，加快授信评审速度，提升风险管理效率，提升企业资金运用效能和产品售后服务水平。
恒丰银行通过大数据平台构建数据仓库的项目实践，逐渐打造起全行数据综合服务体系，即报表和查询体系、基于专业引擎的数据计算访问体系、数据分析服务体系、数据挖掘建模体系，最终形成了数据应用价值到最终用户的合理传导机制。
（文章略有删减）
（来源： 数据猿）
责任编辑：
声明：该文观点仅代表作者本人，搜狐号系信息发布平台，搜狐仅提供信息存储空间服务。
今日搜狐热点O2O中客户主数据、数据仓库和大数据
在O2O项目中强调电子化和数字化，因此数据是个很关键的基础工作。而围绕数据，那么经常提到的客户主数据和数据仓库、大数据是什么关系呢？今天我们简单来聊聊，帮助大家理顺一下思路。
O2O强调的是客户体验，所有的流程和场景都离不开人，都是以人为本。所以，O2O项目中，对人的数据非常关注，尤其是用户的主数据模型的设计，以及对应主数据模型的数据采集、用户ID的统一等等，而基于主进行ID统一和主的，可以称之为“统一客户数据管理”，我们一般简称为UCM（Universal
Customer Master）。
在对人进行统一后，基本上是形成大会员系统，通过会员ID进行统一和唯一识别，这样形成了对客户的主数据（基础数据）的统一。但是企业一定是需要对整体业务数据的分析，这就意味着要建立DW（DataWarehouse）数据仓库，在DW里面进行数据的抽取清洗完善，并进行建模和分析，形成不同主题的数据集市，再通过BI工具进行统计分析展现和数据可视化。
但由于当前企业的数据量越来越大，而且非结构化数据越来越多，对非结构化数据的处理需求也越来越紧迫；同时海量的结构化数据当数据量增长到10TB以上，可能就会遇到性能瓶颈，这时候就需要构建大数据平台如Hadoop或者类似Spark等平台进行重构。
实际上，大数据平台不是万能的，它的优势在于海量数据的存储和运算，但不善于对结构化数据的业务和事务处理。所以，类似Hadoop大数据平台适合做大数据量的存储、ETL和运算，但不适合做企业的业务系统和。
如果企业既要做业务系统，又需要海量数据和高并发，那么这种情况不要采取大数据平台，而是可以采用内存数据库+内存计算的技术，可以实现大数据量的业务系统。比如12306的系统平台，以前经常死机卡顿，但现在明显感觉快多了不死机了吧？就是因为用了内存数据库和内存缓存计算技术。而内存数据库技术，类似SAP的HANA和Oracle的内存数据库，都是可以考虑的。
同样，大数据在查询统计上也不如关系型数据库。大数据平台因为结构不同，所以对一条数据的查询和对数万条数据的查询可能都是一个效率，而关系型数据库当对处理后的小数据量的查询特别快。因此，统计分析时会选择一个方式：大数据平台将数据清洗整理运算之后，加载到一个关系型数据库，再通过SQL或者BI工具进行统计分析展现，这样效率最高。
是不是太专业了？说到底，一个合理的大数据平台的架构可能是：
针对关系型数据库，建立企业统一的ETL机制和接口规范，按照统一规则或者基于企业数据总线对接全部业务系统，抽取清洗数据源后到数据源历史库，再分别根据UCM的需要加载或者平抽到UCM的临时库、根据DW的需要抽取到数据仓库的ODS。
针对非结构化数据，通过大数据平台进行海量数据收集、归档和索引。并提供专用的大数据查询工具满足常规数据查询和动态的数据分析。尤其要确保既能满足实时的数据细节获取也能满足批量的与关系型DW的。
UCM在大数据平台上清洗整理合并后形成UCM基表库，根据需要加载到关系型数据接口准备主数据分发服务，服务的对象包括业务系统、企业数据仓库和数据集市、以及大数据平台。分发的渠道则仍是统一的ETL平台。
根据抽取过来的ODS数据进行整理格式化和迁移转换，在DW进行建模和形成数据集市，比如有关联分析、有画像分析、有购物篮分析等等不同主题，最后根据分析的需要将所需数据加载到关系型，通过BI工具进行统计分析和可视化展现，或者实现移动端报表展现
主数据管理（MDM）与元数据管理
大数据管理平台-数据处理与数据集市
数据仓库的架构与设计
企业大数据平台下数仓建设思路
大数据之数仓平台设计思路01
大数据数据仓库－场景
大数据经典学习路线（及供参考）
没有更多推荐了，