很多集团做大数据平台,最后都变成了建了个Hadoop集群,数据倒是存进去了,但业务部门还是看不懂、用不上。表面上大数据平台建成了,实际上贴源数据、主题数据、集市数据混在一起,ETL跑批经常出错,元数据没人管,业务人员想看个客户360度视图还得靠人工拉数据拼表格。这种有平台没有用的困境,几乎是所有大数据平台建设项目绕不开的坎。这份《企业数字化底座与数字化转型解决方案》讲的是一家开展供应链金融、人人贷、保理等多种互联网金融业务的大型集团的大数据平台建设方案。这份方案的价值,不在于讲了多少个大数据概念,而在于它把从数据产生、数据交换、数据存储到数据应用、数据管控的整条链路,细化到了服务器数量、存储周期、数据库设计原则这种可以直接拿来执行的技术颗粒度,并且给出了完整的三阶段演进路线图。这是一份技术细节非常扎实的大数据平台建设范本,值得完整拆一遍。一、先看现状基础打好了但没有真正用起来方案对集团管理分析类应用建设现状的诊断很直接。基本的现状是——集团已建立面向整个业务的数据仓库,整合了前台业务运营数据和后台管理数据,建立了面向业务的管理分析应用;集团已开展供应链金融、人人贷和保理等多种业务,积累了一定量的业务数据,业务人员也从客户管理、风险评级和经营规模预测等方面提出了大量分析预测需求。但存在的问题也很明显——集团数据仓库累积数据没有充分利用;缺乏面向整个集团的统一、完整的数据视图;缺乏支撑集团日常业务运转的风险评估体系;缺乏集团客户360度视图,客户行为分析和预测无法实现;缺乏面向金融业务运营管理的关键绩效指标体系。方案给出的判断很直接——“基础数据平台和BI应用建设是未来一段时间的重点”。这句话点出了这类项目最容易踩的坑——很多企业以为数据仓库建好了就万事大吉,实际上数据仓库只是原材料仓库,真正把数据变成价值,还需要一整套数据平台、数据应用、数据管控的体系化建设。方案接下来明确了要重点关注的内容——数据平台整体架构、数据平台各层建设的标准、较成熟的金融业数据模型、数据质量治理、元数据管理、数据标准建设、数据整合、数据应用建设、数据平台的软硬环境。这份清单基本框定了整份方案后续要展开的所有内容。二、建设目标统一规划、统一分析、统一部署方案给出的数字化底座建设目标很清晰——“通过数据平台和BI应用建设,集团将搭建统一的大数据共享和分析平台,对各类业务进行前瞻性预测及分析,为集团各层次用户提供统一的决策分析支持,提升数据共享与流转能力”。这个目标背后有五个统一——统一规划分析方法、统一划分分析主题、统一设计数据模式、统一部署技术基础、统一定义BI应用。方案特别提到,云数据推送平台已经实现了主要业务及金融业务系统数据清洗、整合,为未来集团数据平台提供了丰富的数据源——这说明这个项目不是从零开始,而是在已有基础设施上继续深化建设。方案还给出了不同用户层级对BI应用的不同需求——集团决策层关注集团主要经营指标;集团职能管控层查看职能部门的业务经营情况;各级业务操作层通过BI应用实现业务协作和创新。数据来源覆盖供应链金融系统、POP系统、采购管理系统、其他业务系统,以及外部非结构化数据,并支持自定义报表工具行列的简单定义方式和多种格式报表。建设的五大预期收益方案给出的预期收益讲得很实在,值得逐条记住实现数据共享通过数据平台实现数据集中,确保集团各级部门均可在保证数据隐私和安全的前提下使用数据,充分发挥数据作为集团重要资产的业务价值。加强业务协作实现分散在供应链金融、人人贷、保理等各个业务系统中的数据在数据平台中的集中和整合,建立单一的产品、客户等数据的集团级视图,有效促进业务的集成和协作,并为集团级分析、交叉销售提供基础。促进业务创新集团业务人员可以基于明细、可信的数据,进行多维分析和数据挖掘,为金融业务创新客户服务创新、产品创新等创造了有利条件。提升建设效率通过数据平台对数据进行集中,为管理分析、挖掘预测类等系统提供一致的数据基础,改变现有系统数据来源多、数据处理复杂的现状,实现应用系统建设模式的转变,提升相关IT系统的建设和运行效率。改善数据质量从中长期看,数据仓库对集团分散在各个业务系统中的数据整合、清洗,有助于集团整体数据质量的改善,提高数据的实用性。这五条收益的排列很有逻辑——从数据能不能用共享,到业务能不能协同协作),到能不能创造新价值创新),再到建设效率能不能提升效率),最后到数据本身质量能不能变好质量,层层递进,覆盖了短期、中期、长期不同阶段的价值体现。三、总体架构七层架构撑起一整套数据平台方案给出的总体架构分为七层——数据产生层、数据交换层、数据计算层含数据存储层、流程调度层、数据应用层、数据管控层、用户访问层数据访问层。这套七层架构基本覆盖了从数据产生到数据消费的完整生命周期,是整份方案的骨架。数据产生层三类源数据方案把源数据内容分成三类——内部业务系统产生的结构化数据集团日常业务处理过程中产生的结构化数据,存储在关系型数据库中,如供应商信息、采购信息、商品信息、销售流水,或客户信息、账户信息、金融产品信息、交易流水)、集团内部非结构化数据日常业务处理过程中产生的非结构化数据,如用户访问日志、用户投诉、用户点评)、集团外部数据以非结构化为主,如国家政策法规、论坛等互联网信息、地理位置等移动信息、微博等社交媒体信息。数据增量获取策略也讲得很具体——本次项目实施采用以增量为主、全量为辅结合的方式。集团和集团业务系统的数据,增量数据识别和获取由云数据推送平台负责,采用分析对比源系统日志的方式实现;对于无法通过这种方式获取增量的源系统数据,则采用某一时间范围内的全部数据作为增量。初始数据加载均采用全量模式。数据交换层四大设计目标三大交换组件方案给出的数据交换层设计目标是——保证数据交换过程中不失真、保证数据在平台内高速流转、保证数据交换过程安全可靠、保证数据交换过程中不丢失。传输组件的设计逻辑是根据数据源存储的不同分类而设计,本质是通过分析数据存储结构和数据存储库的特点来针对性地设计工具,以追求卓越的性能。NAS存储承担三大功能——存储数据平台各Hadoop集群的元数据信息如HDFS文件系统元数据)、统一存储数据平台ETL加工处理程序数据压缩、数据加载等,各接口服务器通过文件系统Link建立映射)、暂存集团数据交换平台每日获取的业务系统变化数据以及金融数据平台加工计算结果。大数据交换组件处理集团内部和外部的非结构化、半结构化数据音频、视频、邮件、Office文档、抵押品扫描件、微博、贴吧、论坛、用户点击流、用户移动位置等),以实时和批量两种模式实现数据采集、传输到接口服务器NAS指定目录、存储到大数据区指定HDFS目录,实现技术上采用SFTP协议批量传输,或开发Java/C应用调用API/爬虫方式抓取。数据库数据交换组件处理集团内部业务系统产生的结构化数据业务数据存储在Oracle、SQLServer、MySQL和MongoDB四类数据库,互联网金融业务数据存储在MySQL数据库),以实时和批量模式实现数据采集轮询NAS集群指定目录,获取LZO压缩的数据文件)、数据核查质量校验)、数据加载到临时数据区),实现技术是Perl程序调用文件模块函数轮询目录、执行文件级数据质量检查、调用Hive Load命令加载到Hive Table。数据区数据交换组件处理数据平台计算层各数据区之间的数据流转——贴源数据区和主题数据区到集市数据区、大数据区到主题数据区和集市数据区、主题数据区/贴源数据区/集市数据区到沙盘数据区、各数据区数据归档,实现技术是Sqoop实现集市数据区与其他Hadoop数据区的交换)、Hadoop命令/Hive外部表/MR程序实现Hadoop数据区间交换。这套三组件分工的设计思路很清晰——大数据交换组件专管非结构化半结构化,数据库数据交换组件专管结构化业务数据,数据区数据交换组件专管平台内部各数据区之间的流转,三者各司其职,不会互相干扰。流程调度层批量、实时、归档三种处理流程批量数据处理由流程调度层部署的自定义WorkFlow组件调度运行,整个流程完成——获取业务系统结构化数据存入临时数据区、获取集团内外部非结构化数据并进行结构化处理存入主题或集市数据区、按照贴源数据模型整合数据标准化、更新/追加)、按照主题数据模型整合数据并生成汇总、数据加工计算后结果交付到数据集市支持分析类应用。实时数据处理流程强调实时或准实时获取并处理数据,通常采取消息队列等技术构建数据流,完成——通过数据库数据交换组件获取增量数据加载到实时数据区、通过大数据交换组件获取非结构化数据并利用Storm处理加载到实时数据区、针对实时数据区数据执行标准化处理和贴源整合。归档处理流程的对象包括业务系统数据文件、贴源数据区数据、主题数据区数据、大数据区数据和集市数据区数据,按照生命周期规划存储到归档区Hadoop集群,归档后原数据区删除此数据,具体实现——数据文件通过HDFS命令行copyfromlocal归档、贴源主题和大数据区通过distcp或自定义MR程序归档、集市数据区通过Sqoop或数据库Hadoop集成技术如外部表归档。数据存储层八大数据区各有各的规矩这是方案讲得最细的部分,给出了数据平台内部各数据区的详细设计规范。方案对每个数据区都给出了数据内容、主要用途、数据模型、保留周期、用户访问模式、工作负载、平台要求这七个维度的完整描述,非常具体。临时数据区业务系统前日增量数据,作为缓存数据支持后续ELT处理,采用贴源数据模型,保留最近7天数据,无最终用户访问,只有贴源/主题数据区批量作业访问,I/O敏感,少量数据用Hive的Load命令、大量数据用MR程序,与主题区/贴源区/集市区构成一个Hadoop集群。贴源数据区业务系统前日快照数据和一段时间的流水数据,进行数据标准化,为后续主题模型、集市和沙盘演练提供数据,采用贴源数据模型,不保存历史,以ELT形式通过Hive SQL执行日终批量ETL。大数据区集团内外部非结构化、半结构化数据,采集存储并进行结构化处理,数据按HDFS文件存储,建议保留1年,少量高级业务人员进行大数据分析,采用MapReduce分布式计算处理文本检索、语义分词、图像识别、音频识别等。历史归档数据区其他各数据区历史数据,按数据生命周期规划归档过期数据支撑历史查询,数据文件按数据区划分目录,建议保留7年,业务人员执行历史数据查询,采用独立的Hadoop集群。主题数据区—明细业务系统历史明细数据,打破业务条线整合数据,采用第三范式模型,保留长期历史,少量高级业务人员进行灵活查询、挖掘预测,I/O敏感,日终批量ETL合并、拉链、关联、汇总等。主题数据区—汇总对主题数据预加工后的结果数据,针对应用需求进行预连接预汇总,为集市提供数据,采用逆范式宽表,依赖于集市数据需求。沙盘演练数据区按沙盘演练需求准备的明细或汇总业务数据,为数据科学家的挖掘预测操作提供数据服务,模型依赖于沙盘演练需求,在整个沙盘演练周期内保留,采用独立的Hadoop集群。应用集市数据区面向集团内部管理分析类应用需求的汇总数据,为客户、运营等管理分析主题和数据增值产品提供数据服务,采用维度数据模型,决策人员、管理人员、业务人员访问,I/O敏感型,基于开放平台的完全无共享MPP数据库集群内存数据库。增值产品数据区根据外部用户的数据使用需求数据平台加工计算的结果数据,为部署在数据平台上的集团内外部增值产品提供数据支持,采用应用模型,依赖于用户业务需求,集团外部人员如客户通过自己部署在PaaS平台上的应用访问,独立的PaaS平台部署Hadoop集群。实时数据区面向应用的业务系统快照数据和一段时间的交易流水,为实时或准实时分析应用提供数据服务,采用贴源数据模型,依赖用户业务需求,集团业务人员使用,高时效高并发高可靠性的联机交易类查询,CPU敏感,独立的内存数据库集群,无单点故障365×24小时不停机。这套八大数据区的设计规范,展示了一个非常重要的数据架构原则——不同数据区承担不同职责,数据模型、保留周期、访问权限、平台要求都因职责不同而有明确差异。这不是一个一锅炖的大数据湖,而是分层分区、各有边界的精细化架构。数据应用层五大应用类型对应平台发展阶段方案给出了五种数据应用类型——历史查询类应用针对公检法查询需求、内外部审计需求和最终用户的历史交易查询需求,以贴源存储的归档数据为基础,通常使用BI工具或自主开发实现)、沙盘演练类应用业务人员根据业务需求设计计算模型,准备明细或汇总数据导入模型运算验证业务结果,通常使用R语言在Hadoop分布式体系下实现)、高时效类分析应用客户经理等最终业务人员针对当前业务发生进行实时查询分析,通常使用CEP、ESB等技术实现)、管理分析类应用实现集团客户管理、运营管理、财务管理、风险管理、监管信息披露五大分析体系功能,通常采用套装软件和BI工具如MicroStrategy实现)、数据增值类产品集团数据科学家根据业务需求或市场判断设计并运行模型,发掘数据价值并封装成商业产品,通常采用R语言和BI工具实现,面向集团内外部用户。方案还给出了一张很有意思的平台发展不同阶段对应应用的成长曲线,从工作负载复杂度、数据量、用户数、查询复杂度、ETL处理复杂度五个维度的增长曲线出发,划分了六个阶段——操作为主阶段什么正在发生? 批量、随机查询→报表为主阶段发生了什么历史查询类应用→分析为主阶段为什么会发生管理分析类应用、数据分析)→预测为主阶段将会发生什么沙盘演练类应用、数据增值类产品→实时分析类应用,持续更新加载/短查询,基于事件的动态触发)→动态数据仓库阶段让正确的事情发生。这条成长曲线揭示了一个规律——大数据平台的应用建设不是一步到位,而是随着数据量、用户数、查询复杂度的增长,从操作型的报表查询逐步演进到预测型的智能决策,每个阶段都有对应的合理应用类型,不能跳级冒进。管理分析类应用的四大分析体系方案对管理分析类应用给出了非常详细的功能清单,涵盖客户管理、风险管理、运营管理、财务管理四大体系监管披露体系目前没有明确要求。客户管理客户单一视图公司/个人/同业客户信息管理)、目标客户搜索重点/关怀/风险/异动客户)、客户细分个人/公司客户细分)、客户行为分析客户轮廓分析、产品交叉销售分析、百分比分析、渠道偏好分析)、营销活动管理规划、定义、执行、效果分析)、营销活动自动化渠道接口与集成、流程自动化。风险管理风险监控报表/信息披露流动性报表、利率敏感性报表、资本充足率报表)、市场风险市场风险暴露值、流动性管理、利率管理)、信用风险信用风险暴露值计算、信用风险控制,包括贷前控制、贷中监控、贷后分析)、操作风险异常交易预警、后督差错检查)、防欺诈/反洗钱定义欺诈交易模型、可能性欺诈交易预警、欺诈交易分布分析)、全面风险管理。运营管理领导管理驾驶舱、机构绩效考核、客户经理考核工作量评估、服务客户收益评估)、产品绩效考核、业务量考核供应链金融、人人贷、保理、基金、其他中间业务)、渠道成本与收益。财务管理总账分析资产负债表分析、损益表分析、现金流量表分析、财务指标分析)、盈利分析机构贡献度、产品贡献度、客户细分贡献度、渠道绩效)、资产负债分析净利息收入、净收入、净现值、市场价值等主要指标报告,头寸报告、现金流报告、风险价值VaR计算)、财务预算与计划预算编制、执行监控、过程分析、年末执行分析)、预测与场景分析业务规模预测、收益预测。这份功能清单密度很高,展示了一个金融类集团数据平台的管理分析应该覆盖的完整业务范畴,对于同类企业规划数据应用体系有很强的参考价值。数据访问层七种展现形式对应不同用户方案给出了七种数据展现形式——仪表盘通过仪表盘及其它展现方式对集团关键绩效指标进行展示,为领导层决策提供直观的数据支持)、静态报表按照预先定义格式的批处理报表、在线查询报表)、Office集成将分析应用嵌入到Office界面,利用Office的方便易用特性降低使用难度)、即席查询通过即席查询工具或手工书写SQL语句完成业务信息的即席查看)、多维分析从多个维度灵活组合分析目标值,常见功能包括上下钻取、透明钻取、旋转、分页、层钻、跨维钻取)、主动问题发现通过事件触发、规则匹配等方式发现集团运营中的问题,通过手机、邮件等方式报警)、挖掘预测使用专业软件工具通过数理统计等高级统计分析算法,分析结构化非结构化数据挖掘隐藏在数据中的价值)、Web服务将分析应用的功能发布为Web服务,注册在集团服务总线上,供其他业务系统或分析应用调用。这七种形式分别对应决策层、管理层、业务人员、数据科学家、业务系统五类用户——决策层多用仪表盘,管理层多用静态报表和多维分析,业务人员多用即席查询和主动问题发现,数据科学家用挖掘预测,业务系统通过Web服务调用分析结果。同一套数据,针对不同角色提供不同的消费形式,这个思路和很多现代数据平台的设计理念是一致的。四、数据管控层组织、评价考核、流程、平台四域联动数据管控层是方案里管理体系设计最完整的一块,方案明确指出金融数据管控体系涵盖组织架构、评价与考核、管控流程、管控平台四个域。数据管控的六大能力模块方案给出了数据管控覆盖的能力体系——数据认责数据所有人、数据生产人、数据使用人、IT支持团队各自承担明确职责)、数据标准数据类型、数据格式、业务分类、业务含义)、数据质量真实性定义、及时性定义、完整性定义、一致性定义)、元数据管理技术元数据、业务元数据、管理元数据)、数据安全安全等级、权限定义、审计定义、保留策略)、工作流管理组织建立/维护流程、标准建立/维护流程、考核指标建立/维护流程、评价与考核流程,这六大模块贯穿数据全生命周期——数据创建、数据存储、数据移动、数据共享、数据停用。四域相互作用的内部运转机制方案给出了一张非常清晰的运转机制图——管控组织明确了数据管控过程中的组织结构、角色、职责,除了负责制定数据标准质量安全等要求,还需要负责制定管控相关流程和评价考核指标。评价与考核通过建立定性或定量的数据管控评价考核指标,去评估及考核数据相关责任人职责履行情况、数据管控标准及数据政策的执行情况。管控流程规范了数据管控过程中各环节日常任务处理的运作模式,例如数据定义如何变更、数据冲突如何协调。管控平台采用专门的技术平台支撑管控流程的自动化,发布管控组织制定的相关标准和规范,及时反映管控过程中存在的问题。四者的联动逻辑是——管控组织制定标准数据标准、质量要求、安全要求,通过管控平台的工具支撑元数据管理、数据质量管理),经过管控流程数据接入流程、数据变更流程、数据授权流程、数据退役流程、标准/政策制定流程、评价考核流程)落地执行,最终由评价与考核环节完成考评闭环。数据管控组织的具体架构方案给出了一个非常具体的组织架构示例——信息管理委员会作为数据管控主导方;数据管控负责部门下设数据管控经理,配合数据标准管理员、数据质量管理员、数据安全管理员、元数据管理员四个专职岗位;数据管控参与方覆盖数据产生部门、数据使用部门、数据拥有部门,每个部门都设有数据主管、业务协调人、数据分析员;数据管理部门下设运维组织和实施项目组。方案强调数据管控组织是否有完整与合理的角色定义,是否有高层领导的参与,是整个数据管控成败的关键。这句话再次印证了一个道理——数据治理不是纯技术项目,组织和责任分工才是决定成败的关键因素。数据标准管理三部分工作方案把数据标准管理拆成三部分——数据标准建立和维护数据分类、数据结构、关键业务对象、关键代码、数据维度、代码映射,涵盖客户类数据标准、产品类数据标准等)、数据标准执行数据标准理念推广、ODS/归档系统落地执行)、数据标准管理的考评定性考评、定量考评、数据标准分析报告。目标是消除一数多义,提升数据的唯一性、一致性,将逐步形成的数据标准纳入一个规范的管理流程中,进行数据标准的更新、发布、使用监督等工作。数据质量管理三个环节的闭环数据质量管理框架蓝图分三部分——数据质量要求确认根据业务规则、数据一致性要求、数据完整性要求、数据唯一性要求、数据准确性要求、数据及时性要求,制定数据质量标准、验证规则、考核指标,同时要符合数据标准要求)、数据质量考评数据质量监控、不定期数据质量检查,对数据质量进行量化评价)、数据质量问题解决方案数据质量提升手段包括数据补录、手工修正、自动修正,并输出数据质量分析报告。方案强调数据质量提升是改进数据质量的手段和质量考评的目的。元数据管理三类元数据面向三类人群方案给出了元数据管理最核心的分类逻辑——业务元数据面向业务人员,从业务术语、业务描述、业务指标和业务规则等方面对数据进行描述;管理元数据面向数据管理人员,从运维管理角度描述数据处理、数据质量和数据安全的状态信息;技术元数据面向技术人员,从数据结构和数据处理细节方面对数据进行技术化描述。这三类元数据面向三类不同人群的设计思路,和前面数据质量管理产品里讲的业务人员用业务元数据定义规则、技术人员用技术元数据做检核的场景是一致的——同一份数据资产,要给不同角色提供不同抽象层次的理解方式。数据安全管理分级授权两条线数据安全管理分两部分——数据安全分级根据业务要求制定数据安全分级标准和政策,为数据应用及管理中实施数据安全保护和访问提供控制基础,涉及数据敏感度、数据重要性、安全等级定义、安全技术、数据访问授权根据数据安全分级标准,定义数据访问的授权方法及流程,建立基于数据安全分级的数据使用授权机制,实现数据访问和信息披露的安全,涉及数据访问授权规则、数据使用需求、数据使用者权责。数据管控平台的三层架构数据管控平台从总体上分为数据层、应用层、展现层三个主要层面,以数据层的数据库及相关基础系统为主要信息来源,通过应用层的运算处理,以不同形式不同功能在展现层提供用户接口。平台的功能模块涵盖工作管理待办事项、信息地图)、标准管理数据标准知识库、标准浏览、标准维护)、元数据管理元数据采集、元数据知识库)、质量管理质量稽核库、规则配置)、系统管理用户管理、权限管理、流程管理、绩效指标、规范管理。五、数据平台总体产品框架六大平台各司其职方案给出了整套数据平台的产品框架,由六个具体平台构成——数据交换平台自主开发交换组件NAS存储)、基础计算平台贴源数据区主题数据区大数据区,基于Hadoop集群Hive)、历史归档查询平台基于Hadoop集群Hive)、沙盘演练平台基于Hadoop集群)、增值产品平台基于Hadoop集群)、管理分析平台基于X86 MPP集群)、实时分析平台基于内存数据库),再加上数据管控平台贯穿始终,以及支撑数据获取的云数据推送平台。这些平台之间通过SFTP/HTTP/API、Distcp、HQLLoad、Copyfromlocal、Sqoop、FTP、MR、Queue等具体技术手段实现数据流转。这套框架把前面讲的架构和数据区设计,最终落到了具体的产品和平台上,形成了一套完整的、可以指导实际建设的技术蓝图。六、规划设计三阶段演进路线图方案的规划设计部分给出了从应—技—管三个维度展开的三阶段演进路线图,这是整份方案里最具操作指导价值的部分。第一阶段2013年以基础平台搭建为主应用方面开展客户信息管理、信用风险评级和业务统计分析三类应用建设。技术方面开展贴源数据整合,初步建立集团级数据视图,实现对管理分析类应用和实时分析类应用的支撑。管控方面规划数据管控蓝图,初步实施数据质量和技术元数据管理。方案对第一阶段的定位是以基础平台搭建为主,配合集团初期业务开展,应用建设从客户信息管理、风险管理和运营管理三方面开展。具体到基础数据平台的建设内容——搭建数据交换平台部署NAS存储集群,设计并实施数据库交换组件和数据区交换组件)、搭建基础计算平台设计并实施贴源数据区,以T1频率整合集团和金融业务数据)、搭建历史归档查询平台归档集团和金融业务数据文件)、搭建内部管理分析应用平台部署MPP集群和BI分析应用环境)、搭建实时分析平台部署内存数据库和实时BI分析环境。预期效果是实现了数据平台内部各数据区之间、数据平台与外部系统间的双向数据传输,实现了业务数据按照贴源数据模型整合,实现了数据按照生命周期的归档管理,实现了内部管理分析和实时分析环境搭建。数据管控方面的建设内容——分析和梳理当前数据管理方面的成果和现状,进行数据管控蓝图和路线图设计,数据管控工作的组织、技术和流程高阶设计;梳理集团大数据平台ETL流程各环节的数据质量要求,制定数据质量检查规则、评价指标、管控流程,并落地实施数据质量管理系统;梳理集团大数据平台包含的技术元数据数据字典、ETL任务、ETL流程、BI语义层等),制定相应管控流程并落地实施元数据管理系统。应用体系方面的建设内容——开展客户信息管理建设设计并实施个人客户和供应商360°视图、客户目标搜索、客户细分等功能)、开展风险管理建设设计并实施供应商和个人客户风险评级模型)、开展运营管理建设设计并实施供应链金融、人人贷等业务条线业务量统计分析)、初步梳理实时准实时分析需求进行高时效分析应用试点。第二阶段2014年—2015年搭建大数据处理平台和实时分析平台应用方面全面开展内部管理分析、实时分析和沙盘演练应用建设,初步展开增值数据产品开发工作。技术方面全面开展企业数字化底座建设,引入更多数据源,丰富并完善平台数据区建设。管控方面随着应用体系的搭建,完善数据质量和元数据建设,开展数据标准化工作。基础数据平台建设内容——数据交换平台增强和优化大数据交换组件设计实施);基础计算平台增强引入更多数据源增强贴源数据区、设计并实施主题数据区打破业务条线整合数据、设计并实施大数据区实现集团内外部非结构化半结构化数据加工处理);搭建沙盘演练平台;实时分析平台增强和优化引入更多应用及相关数据源。预期效果是实现了基础数据一次存储、一次计算、多次使用,建立了数据分析人员的实验环境实现用户自主用数,为实时准实时类分析应用提供平台,为封装销售数据类产品提供了平台。数据管控方面——随着更多数据源的引入进一步增强数据质量管理系统;随着更多数据源和平台的建立梳理并整合更多技术元数据;梳理集团大数据平台包含的业务和管理类元数据业务术语、业务指标、业务定义等),制定相应管控流程并落地实施元数据管理系统;开展基础类数据标准建设基础数据标准、管控流程、评价指标、落地策略。预期效果是完善了数据质量管理体系实现问题及时发现及时解决,实现了集团全方位的元数据管理打通了业务和技术元数据关联关系,为集团数据平台建设提供了基础类数据标准。应用体系方面——随着集团业务展开逐步开展内部管理分析体系建设本阶段重点为客户关系管理、运营管理等);高级业务人员利用沙盘演练平台进行数据挖掘预测和科学试验;进一步梳理实时准实时分析需求深化开展高时效分析应用;开始梳理市场上的数据应用需求尝试封装增值数据产品。预期效果是通过内部管理分析体系建设满足了集团日常经营管理决策分析和进一步提高价值创造力的需要,实现了业务人员自主用数,实现了高时效分析与业务流程的整合,实现了数据产品的封装提升了数据价值。第三阶段2015年以后持续优化提升阶段应用方面深化分析体系,形成深度智能化业务分析。技术方面性能持续优化、数据平台持续完善。管控方面持续深化数据管控体系,形成集团级的数据管控体系。基础数据平台建设内容——基础计算平台持续增强和优化引入更多数据源、优化模型和ETL处理);搭建增值产品平台设计并实施增值产品数据区);数据交换平台、沙盘演练平台、实时分析平台进一步增强和优化。预期效果是数据平台纳入尽可能多的集团内外部数据,数据平台以最优的性能支持各类数据应用。数据管控方面——数据质量管理持续优化并增强;元数据管理持续优化并增强;基础类数据标准逐步落地实施;开展指标类数据标准建设基础数据标准、管控流程、评价指标、落地策略。预期效果是通过完善的数据管控体系,提升数据质量、避免数据二义性、建立数据间的血缘关系,使得业务人员可以方便有效地使用数据,提高数据实用性。应用体系方面——随着集团业务展开进一步完善内部管理分析体系建设市场风险管理、操作风险管理、财务管理等);收集实时分析需求进一步增强并优化实时分析应用体系;增值数据产品设计逐渐成为重点,数据分析师收集集团内外部数据需求设计更完善的增值数据产品。预期效果是通过内部管理分析应用体系建设进一步实现数据共享业务协作与创新,通过实时分析应用体系建设实现大数据平台与业务系统的交互、与业务流程的融合,增值数据产品的开发进一步发挥数据平台的数据价值。这套三阶段路线图的设计逻辑非常清晰——第一阶段打基础贴源整合基础应用管控蓝图),第二阶段补能力主题大数据区沙盘演练数据标准化),第三阶段做深做透增值产品指标标准深度智能化)。每个阶段的应—技—管三条线都在同步推进,不是先做技术后做管理,而是从第一阶段就开始规划数据管控蓝图,这个节奏值得所有类似项目借鉴。七、一期架构落地具体到服务器数量的技术细节方案的第四部分讲了一期架构的具体落地情况,技术细节颗粒度非常细,这是这份方案区别于很多概念性数字化方案的地方。五大子平台构成一期架构方案给出的一期架构包括——基础计算平台基于Hadoop集群构建,按照业务条线以贴源数据模型存储业务系统明细数据)、数据交换平台NAS集群实现进出数据平台数据暂存,业务数据交换组件实现业务系统每日增量数据加载,数据区数据交换组件实现基础计算平台与管理分析平台间数据交换)、流程调度平台自主开发的流程调度引擎实现整个数据平台数据处理任务调度和运行)、管理分析平台由X86分析型数据库集群、BI软件、J2EE应用构成,实现面向应用的数据加工管理分析服务)、实时分析平台由高档X86服务器组成的集群,实现高时效高并发的实时准实时类管理分析需求。数据交换平台的具体部署方案给出的数据交换平台由FTP服务器、加载服务器和NAS存储组成——FTP服务器利用LVS构成集群,接收云数据推送平台处理后的数据存储在NAS集群指定目录;加载服务器部署ETL任务,实现指定目录的文件到达监控、文件级检核、数据加载Hive Load到临时数据区,同时归档到历史数据区;NAS集群按日期和源系统划分目录缓存数据,支持日常数据交换和ETL。云数据推送平台负责源系统数据一次获取、按需分发,采用GoldenGate、JBUS、Flume等技术获取增量数据存储在MySQL集群,按接口规范生成文件LZO压缩后通过FTP传输到NAS指定目录。方案还给出了数据交换平台的参与方责任划分,这一部分非常具体云计算方要设计实施云数据推送平台、按接口定义抽取业务系统数据、按时生成数据文件控制文件DDL文件并FTP传输,若源系统变更需提前提供变更说明;集团研发部门要制定接口规范、梳理业务系统数据字典、开发数据交换组件、对接收数据提供验证功能;运维部门负责安装部署物理环境应用软件基础设施运维,在业务系统数据库服务器安装云数据推送平台客户端;集团业务系统负责针对需求指定接口人提供文档,系统升级导致数据模型变化时及时通知接口责任人。这种责任划分的具体程度,说明方案不只是技术架构,还考虑了多方协作的实施流程。数据交换平台部署架构具体到——由8台X86服务器和一个NAS集群构成,X86服务器按功能分两组一组数据获取,一组数据加载和归档),NAS集群作为公共数据区由8台服务器共享访问。流程调度平台的具体设计流程调度平台通过Task Automation驱动各个平台,实现从数据存入NAS平台到数据集市生成整个处理过程的工作流管理。流程调度元数据统一存储在MySQL数据库中,包含任务定义、任务依赖、任务触发、任务组等属性,元数据由所有流程调度服务器共享。任务调度引擎的触发方式分两类——自动触发定时触发,如每日每周每月的归档任务;事件触发,如数据文件到达指定目录触发加载任务)和手动触发系统管理员通过界面或命令接口执行审计验证、数据清洗或流程修复。集群可靠性方面,流程调度所需元数据统一保存在MySQL数据库中,任何服务器故障不会破坏元数据完整性,故障时只需修改ETL任务属性指定其他服务器执行即可。扩展能力方面,流程调度集群由多台服务器构成按工作负载划分角色,当某类调度负载较大时可通过增加服务器实现横向扩展。部署架构具体到——由8台X86服务器构成,分两类——两台部署MySQL数据库集群存储流程调度元数据,六台部署流程调度引擎负责各数据区数据处理流程调度与运行,并按数据区划分工作流临时/归档区、贴源区、汇总区分别部署独立服务器。基础计算平台的具体设计基础计算平台基于Hadoop集群搭建,采用标准X86服务器,集群弹性架构按需分配计算资源,数据保留三份保证节点故障不影响服务。平台由三个数据区构成——临时数据区缓存当日变化数据,支持后续ELT处理)、贴源数据区按源系统数据模型整合的明细历史数据,一次整合多次使用)、汇总数据区对贴源数据区明细数据预连接预聚合预汇总,一次计算多次使用。方案对每个数据区都给出了具体的设计原则,比方案前面数据存储层部分讲得更细——比如临时数据区的数据库设计原则是对应独立的Hive数据库,不对外提供访问,ETL用户对数据库有增删查改权限;模型设计原则是逻辑模型参考源系统和接口规范定义,物理模型与逻辑模型保持一致,每个实体对应一张Hive表采用LZO压缩存储,不建议考虑索引物化视图等技术特性,以天为单位按业务日期建立分区;历史保留原则是缓存当日业务数据,为数据重跑方便可保留7天历史,过期数据直接删除对应分区不需要归档。贴源数据区的模型设计原则更细致——“针对不需要记录变化的实体,逻辑模型参考缓冲层按贴源设计;针对需要记录变化的数据,需要增加时间字段设计拉链数据模型记录历史;物理模型考虑分区,流水表按业务日期建分区,拉链表按终止日期建分区”历史保留原则是拉链表数据保留最近37个月历史,快照表数据永久保留,交易流水表数据保留最近25个月历史,过期数据归档到历史归档区需要时回迁。这两个具体数字37个月、25个月)说明方案确实结合了金融业务的真实合规和分析需求做了精细化设计,不是随手写的通用规则。汇总数据区的模型设计原则是采用逆范式宽表设计,某种程度上采用维度建模方法,设计首先需要根据业务和应用需要尽量包含更多属性和指标同时兼顾空间,需要针对维度数据执行标准化处理,模型增加数据日期记录历史建议按数据日期建分区;历史保留原则是不同实体采取不同历史保留策略,建议以支持应用为输入避免永久保留,过期数据归档到历史归档区需要时回迁。平台部署架构具体到——由73台X86服务器构成,3台作为Name Node和JobTracker Node,70台作为Data Node和TaskTracker Node。NN负责HDFS元数据管理,元数据信息存储在NAS集群指定目录,通过硬件冗余、RAID01、Slave NN等技术实现高可用性;Secondary NN负责HDFS元数据备份,Secondary JobTracker负责MR计算集群JobTracker高可用性;70台服务器是HDFS数据节点,临时数据区和贴源整合区作为独立数据库部署在此,按3份冗余存储;JobTracker Node负责MR任务分配,通过心跳信号检测TaskTracker活动状态排除失效节点。网络拓扑方面,方案给出了机架分布示意——分成多个RACK,每个RACK约20个Node,体现了大规模Hadoop集群的典型物理部署方式。管理分析平台的安全管理管理分析平台涵盖客户信息管理J2EE框架自主开发,数据集市构建于分析型数据库集群)、运营绩效管理MicroStrategy开发,数据集市构建于分析型数据库集群)、扶贫灵活分析MicroStrategy开发,数据集市构建于内存数据库集群HANA。安全管理架构涵盖身份管理、认证管理、授权管理、账户管理、审计管理,由安全管理员统一负责,平台安全管理信息库存储账户信息、权限信息、日志信息,并通过LDAP实现统一认证。业务应用层覆盖个人客户信息管理、集团客户信息管理、金融业务规模预测等,均纳入统一的安全管控体系。整体物理架构与硬件配置方案给出的物理架构划分为三个子网——WEB服务子网两台服务器构成的Tomcat集群)、应用服务子网两台服务器构成的MicroStrategy集群)、数据服务子网基础计算平台73台服务器的Hadoop集群、数据集市平台30台服务器的集群、流程调度平台7台服务器的Task Automation集群、数据交换平台5台服务器与云数据推送平台接口。一期硬件配置给出了具体参数——基础计算平台Data Node服务器70台,32核CPU,128G内存,2×1Gb网口,Centos 6.3,12×2TB 7200RPM SATA磁盘),Name Node服务器3台,32核CPU,128G内存,4×600GB 15K SAS磁盘RAID 01);历史归档查询平台Data Node服务器30台,12核CPU,24G内存,16×3TB 7200RPM SATA磁盘),Name Node服务器3台,12核CPU,24G内存);沙盘演练平台Data Node服务器30台,32核CPU,128G内存,12×2TB 7200RPM SATA磁盘),Name Node服务器3台,32核CPU,128G内存)。这种具体到服务器数量、CPU核数、内存大小、磁盘规格的硬件配置清单,是很多概念性数字化方案里完全看不到的内容,恰恰说明这份方案是真正指导过实际项目落地的技术文档,而不是停留在PPT层面的规划愿景。八、这份方案值得学习的地方1. 八大数据区的分区设计规范极其具体可直接复用临时数据区7天、贴源数据区拉链表37个月/快照表永久/流水表25个月、大数据区1年、历史归档区7年,这种明确的保留周期规范,是很多数据平台设计文档里容易被忽略但极其重要的细节。2. 三类交换组件按数据源类型分工架构清晰不混乱大数据交换组件管非结构化、数据库数据交换组件管结构化、数据区数据交换组件管平台内部流转,这种按数据类型和流转场景分工的设计思路,避免了一个组件包打天下导致的复杂度失控。3. 三阶段路线图的应—技—管三线同步推进模式值得借鉴很多项目容易犯先建技术平台,后补管理体系的错误,这份方案从第一阶段就同步规划数据管控蓝图,体现了对数据治理长期性的清醒认识。4. 平台发展阶段与应用类型的对应关系提供了合理的建设节奏参考从操作为主到报表为主到分析为主到预测为主再到动态数据仓库,这条演进曲线提醒我们数据应用建设要循序渐进,不能跳过基础阶段直接追求高级预测应用。5. 具体到服务器数量和硬件参数的技术细节让方案真正具备落地指导价值73台Hadoop节点、8台数据交换服务器、8台流程调度服务器,这些具体数字虽然看起来枯燥,但正是这些细节让方案从愿景蓝图变成了可执行的建设指南。九、给正在规划企业级数据平台的团队几点建议1. 数据分区设计要明确每个区的职责边界和保留策略不要把所有数据都堆在一个大数据湖里,参照方案的八大数据区设计,明确临时区、贴源区、主题区、集市区、沙盘区、归档区各自的职责,并给每类数据设定合理的保留周期。2. 数据管控要和技术平台建设同步启动不要滞后方案第一阶段就同步规划数据管控蓝图并落地数据质量和技术元数据管理,这个节奏值得所有正在做数据平台建设的团队参考,不要等平台建完了才想起来做治理。3. 应用建设要遵循从操作到预测的自然演进节奏先把历史查询、报表这类基础应用做扎实,再逐步往管理分析、沙盘演练、数据增值产品这类高级应用推进,不要一开始就追求智能化预测性这类高阶目标。4. 组织架构设计要落到具体岗位角色而不是抽象部门参照方案给出的数据管控经理、数据标准管理员、数据质量管理员、数据安全管理员、元数据管理员这类具体岗位设置,确保数据治理工作有人真正负责,而不是各部门配合这种模糊说法。5. 硬件规划要结合实际数据量和查询负载测算不要凭空估算参照方案给出的具体服务器数量和配置参数的测算逻辑比如Hadoop集群70个数据节点对应贴源和临时数据区,3个Name Node保证高可用),硬件规划应该基于真实的数据量增长预期和查询负载模型来做,而不是拍脑袋定数字。结语数字化底座的终点是让数据真正流动起来、用起来这份《企业数字化底座与数字化转型解决方案》讲的核心逻辑其实很朴素——数字化底座不是建一个大而全的技术平台,而是要让数据从产生到应用的整条链路真正流动起来、可信起来、用得起来。从数据产生层的三类源数据,到数据交换层的三大交换组件,到数据存储层的八大数据区各司其职,到数据应用层的五种应用类型对应不同的成熟阶段,再到数据管控层的组织制度平台三位一体每一层设计都在回答同一个问题——海量的、分散的、异构的企业数据,怎么才能变成决策层看得懂、管理层用得上、业务人员挖得出价值的真正资产。对任何正在规划企业级大数据平台或数字化底座建设的团队来说,这份方案最值得借鉴的不是某个具体技术组件的选型毕竟Hadoop生态在这些年已经有了很大演进),而是它贯穿始终的方法论——先分清数据的类型和流向,再按职责边界设计分层分区的存储架构,同步规划数据管控体系而不是滞后补课,遵循从基础应用到高阶预测的自然演进节奏,并把每一层设计都落实到具体可执行的技术参数上。这套逻辑,比任何单一的技术组件选型都更值得深入理解和复制推广。以下为方案部分截图