中国移动(深圳)有限公司接管中国移动一级经营分析系统-技术方案建议书

技术方案建议书TOC\o"1-2"\h\z\u1. 概述 21.1. 项目概况 21.2. 背景分析 21.3. 建设范围 32. 总体解决方案 42.1. 总体研究理念 42.2. O域数据的理解 42.3. 总体设计架构 42.4. O域数据融合及应用 53. 存储数据架构设计 63.1. 设计要求说明 64. O域数据存储架构设计 74.1. O域数据的底层存储 74.2. 汇总架构设计 75. O域数据融合及应用设计 75.1. 应用指标梳理 75.2. O域数据融合设计 75.3. 应用实现 7概述项目概况中国移动（深圳）接管中国移动一级经营分析系统，当前中国移动一级经营分析系统平台的主数据仓库就是传统数据平台和体系架构，仅存在比较成熟的B域（面向客户服务和业务管理的业务支撑系统）数据的抽样建模和专题建模，生成KPI、报表、专题分析等，为公司考核、总部领导的决策、各部门的管理提供了依据。对于O域数据，还缺乏足够的了解以及处理能力。相比于B域数据，O域数据主要为非结构化数据，数据产生的时间、周期、量级都与B域存在巨大差异。与此同时，O域数据也存在着巨大的应用前景。因此，如果合理、高效的利用O域数据，就必须做好低层设计，通过前端快速收敛、后端精准建模实现大数据的快速精确消噪，得出用户、业务、数据的强相关性，完成对O域应用数据和支撑数据精准搭建数据架构、对跨库（如，与主数据仓库）或跨域（如，与B/O域）数据的融合、技术架构对O域不同数据特征的存储、管控及应用。背景分析运营商网内数据主要来源于业务平台、基础网络、支撑系统，包括O域（面向通信网络管理的运营支撑系统）、B域（面向客户服务和业务管理的业务支撑系统）、M域（面向通信网络管理的运营支撑系统）。从数据来源及走向可以看出，这些数据包罗万象、体量巨大（可达几十个PB），存在各类数据内在相关性弱、密度价值低的问题。经营分析系统（经分）建设运营十多年来，已成为运营商中最大的两级数据仓库系统。面向总部、省公司和地市一线，服务于市场等多专业部门，发挥了“科学决策之器”、“精细化管理之器”、“针对性营销和客户挽留之器”的重要作用。各省经分系统不仅在省内集中支撑了各部门、各地市的管理分析需求，还实现了与生产系统的互动，在客户细分的基础上，将目标客户及其偏好主动推送到前台营业厅，支撑了针对性营销和客户挽留，提升了一线效率。但随着移动互联的发展，对用户的行为分析在经营决策中的重要作用逐渐显现，O域数据作为运营商的数据源中与用户行为最为贴近的部分，应该得到应有的重视并被充分的利用，因此如何高效、充分的利用O域数据这个问题显得愈加迫切。建设范围2、3G网络架构、网络协议的梳理，及相关接口信息的理解包括但不限于2G：Gn、Gb、A、Gp、Gc；3G：lub、Uu、UE等数据，O域数据主要来源于用户行为，其产生的时间、数量、波动情况受用户行为及其他因素的影响较大。此外，O域数据在内容与使用场景上与传统经分所使用的数据也存在极大的不同。因此，如果希望更好的使用O域数据，必须对其内容、结构、数量级等由充分的理解，以支撑后续应用。4G网络架构、网络协议的梳理，及相关接口信息的理解包括但不限于LTE-UU、X2、S1-U、S1-MME等数据，4G网络相较于前两代网络有着更加先进的网络架构，有着更快的通信速度、更宽的网络频谱、更灵活的通信行为和更好的兼容性，随之而来的是其更加复杂的网络架构和网络协议和更多的信令数据。与此同时，随着移动互联的发展普及4G用户数量不断增多，4G流量也成为现网中的主要流量。因此，对要对4G的网络架构、网络协议进行细致的梳理，对其接口信息进行深入的理解。O域数据的存储、汇总架构设计梳理目前系统O域数据加载、存储架构设计、汇总架构设计，及存在的问题，梳理上层应用需求指标。调研目前业界已较成熟稳定运行在系统O域数据的存储架构设计、汇总架构设计、融合架构设计并形成高效、低成本的数据架构方案。O域数据的应用及跨域融合以O域数据为基础，与B域、M域进行有机融合，更大程度的发挥数据价值。主要考虑实现以位置信息为主的交通类应用。系统架构系统概述OSS运营支撑系统(OperationandSupportSystem)简称O域OSS是一个综合的业务运营和管理平台，同时也是真正融合了传统IP数据业务与移动增值业务的综合管理平台。OSS是电信运营商的一体化、信息资源共享的支持系统，它主要由网络管理、系统管理、计费、营业、账务和客户服务等部分组成，系统间通过统一的信息总线有机整合在一起。它不仅能在帮助运营商制订符合自身特点的运营支撑系统的同时帮助确定系统的发展方向，还能帮助用户制订系统的整合标准，改善和提高用户的服务水平。2G、3G、4G网络架构、网络协议UE（UserEquipment）1.UE是用户终端设备,它主要包括射频处理单元,基带处理单元,协议栈模块以及应用层软件模块等.2.UE通过Uu接口与网络设备进行数据交互,为用户提供电路域和分组域内的各种业务功能.包括普通话音,数据通信,移动多媒体,Internet应用,如E-mailWWW浏览FTP等.RNC（RadioNetworkController）RNC是无线网络控制器主要完成连接建立和断开切换宏分集合并无线资源管理控制等功能具体如下：(1)执行系统信息广播与系统接入控制功能(2)切换和RNC迁移等移动性管理功能(3)宏分集合并功率控制无线承载分配等无线资源管理和控制功能CN（CoreNetwork）CN即核心网络负责与其他网络的连接和对UE的通信和管理主要功能MSC/VLRMSC/VLR是WCDMA核心网CS域功能节点，它通过Iu_CS接口与UTRAN相连、通过PSTN/ISDN接口与外部网络PSTNISDN等相连、通过C/D接口与HLR/AUC相连、通过E接口与其它MSC/VLRGMSC或SMC相连、通过CAP接口与SCP相连、通过Gs接口与SGSN相连。MSC/VLR的主要功能是提供CS域的呼叫控制移动性管理鉴权和加密等功能SGSNSGSN服务GPRS支持节点是WCDMA核心网PS域功能节点，它通过Iu_PS接口与UTRAN相连，通过Gn/Gp接口与GGSN相连，通过Gr接口与HLR/AUC相连，通过Gs接口与MSC/VLR，通过Ge接口与SCP相连，通过Gd接口与SMS-GMSC/SMS-IWMSC相连，通过Ga接口与CG相连，通过Gn/Gp接口与SGSN。SGSN的主要功能是提供PS域的路由转发，移动性管理，会话管理，鉴权和加密等功能GGSNGGSN提供数据包在WCDMA移动网和外部数据网之间的路由和封装GGSN主要功能是同外部IP分组网络的接口功能，GGSN需要提供UE接入外部分组网络的关口功能。从外部网的观点来看，GGSN就好象是可寻址WCDMA移动网络中所有用户IP的路由器，需要同外部网络交换路由信息Gi接口Gi接口是GPRS与外部分组数据网之间的接口（在GPRS网络中GGSN与PDN接口），同时也是终端IP地址在外部数据网络的呈现点。GPRS通过Gi接口和各种公众分组网如Internet或ISDN网实现互联，所有用户和控制平面的功能都基于终端IP层之上来处理，所有3GPP范畴的终端移动性能终结在Gi接口前处理，在Gi接口上需要进行协议的封装/解封装、地址转换（如私有网IP地址转换为公有网IP地址）、用户接入时的鉴权和认证等操作。由于GPRS可以支持各种各样的数据网络，故Gi不是标准接口，而只是一参考点。Gn接口Gn接口是同一PLMN中SGSN与SGSN间以及SGSN与GGSN间的接口为Gn接口（在GPRS网络中SGSN之间的接口）。该接口协议支持用户数据和有关信令的传输，支持移动性管理（MM），该接口采用的为TCP/IP协议。Gn提供数据和信令接口，在基于IP的骨干网中Gn(及Gp)接口使用GPRS通道协议(GTP)。GPRS隧道协议(GTP)在GPRS网络中的各GSNs间的Gp和Gn平台上都有定义。Gb接口SGSN与BBS间的接口为Gb接口（在GPRS网络中SGSN与BSS接口）。通过该接口SGSN完成同BSS系统、MS之间的通信，以完成分组数据传送、移动性管理、会话管理方面的功能。该接口是GPRS组网的必选接口。该接口协议即可用来传输信令和话务信息。通过基于帧中继(Frame

Relay)的网络业务提供流量控制，SGSN同BSS之间可以采用帧中继网进行通信，也可以采用点到点的帧中继连接进行通信。支持移动性管理功能和会话功能，如GPRS附着/分离、安全、路由选择、数据连接信息的激活/去活等，同时支持MS经BSS到SGSN间分组数据的传输。A接口是BSC

与MSC

之间的信令接口。A1

接口主要用于传送

BSC

与MSC

之间的呼叫控制和移动性管理功能的信令消息。它是国际规范中的一个标准接口。Gp接口Gp接口是GPRS网络间接口，是不同PLMN网的SGSN之间采用的接口，在通信协议上与Gn接口相同，但是增加了边缘网关(BG，Border

Gateway)和防火墙，通过BG来提供边缘网关路由协议，以完成归属于不同PLMN的GPRS支持节点之间的通信。Gc接口Gc接口是GGSN与HLR之间的接口，当网络侧主动发起对的业务请求时，由GGSN用IMSI向HLR请求用户当前SGSN地址信息。由于移动数据业务中很少会有网络侧主动向发起业务请求的情况，因此Gc接口在移动数据业务中作用不大。Uu口控制面协议栈从垂直纵向来看，Uu接口分为接入层(AS)和非接入层(NAS)。接入层通过如下业务接入点(SAP)：通用控制(GC)、通告(Nt)、专用控制(DC)为非接入层提供业务。Uu接口分为三个协议层：物理层(L1)、数据链路层(L2)和网络层(L3)。层2进一步分为下述子层：媒体接入(MAC)、无线链路控制(RLC)、分组数据会聚协议(PDCP)和广播/多播控制(BMC)。层3和层2的RLC子层分为控制平面和用户平面，PDCP和BMC子层仅存在于用户平面。在控制平面，层3分为不同的子层。最低层为无线资源控制(RRC)，它位于接入层，与层2接口，终止于UTRAN。而更高层信令，如移动性管理(MM)和连接管理(CM)属于非接入层。Iub接口协议Iub接口协议栈包含3个协议平面，分别是无线网络控制平面、传输网络控制平面和用户平面，分别对应3个协议的信令流程，即NBAP、ALCAP、Iub

FP。FP所承载的协议包括无线资源控制，包数据集中协议等。这3个协议有着紧密的联系，当无线网络控制器发起传输信道管理或者无线连接管理相关过程的时候，是通过NBAP协议的相关过程来实现，比如Common

Transport

Channel

Setup，Radio

Link

Setup，Radio

Link

Addition等。但同时需要对用户平面链路进行分配或删除，在Iub接口上，用户数据（FP）通过ATM结构中的AAL2传送，此时需要建立控制机制，ALCAP定义了与用户面建立、释放传输承载的方式，因此需要ALCAP协议来完成这些操作LTE层结构左边端口LTE-Uu，右边端口S1-MME控制平面不包含IP报文压缩功能，RRC协议主要起到对底层的控制功能和信令传输功能。S1接口1.采用SCTP/IP协议栈结构2.SCTP协议延续了TCP协议的特点，保证所需要的信令安全传输，其中多流处理容易实现网络冗余传输，避免头行阻塞、多重寻址。3.相比较UMTS而言，去掉连接管理协议，使连接在S1-AP协议中处理。4.S1-U位于eNB与S-GW之间，提供两个网元之间的不可靠传输。在UDP/IP基础上通过GTP-U协议传输用户面PDU。系统架构设计接口层：是指存储从业务系统抽取的接口数据的区域，大多数接口是文件接口，在实时性比较强的地方也可能使用到TCP/IP接口等。清洗、转换层：是从源系统的接口数据过渡到数据仓库数据的中间存储区域，其目的是对接口层的数据在数据仓库内进行暂存，并将其在数据库内进行清洗、转换，然后生成基础数据层。ODS模型的数据结构与源系统接口基本保持一致，但不做历史存储。基础数据层：即明细数据层，是数据仓库核心层数据模型之一，用于存放由清洗、转换层来的数据或者接口层直接来的数据，其设计目标是为后续的汇总数据层提供数据基础。基础数据层数据不涉及跨主题/跨业务系统整合，实体之间的关系与业务系统接口数据之间关系基本相同。该层数据一般需要长期保存，具体保存周期参考移动总的相关规范。汇总层：即轻度汇总数据层。该层实现两个目的：一是数据的整合处理，包括主题内的数据整合处理和跨主题整合处理；二是对数据做轻量汇总。目前该层按照混合模式设计，设计目标是为应用数据层、应用数据层数据提供足够灵活方便和扩展性的基础数据，并保证从该层获取数据是性能最优，而不是从基础数据层经过复杂操作获取数据。应用层：在汇总数据层之上，数据按照应用需求做数据聚合，生成相关应用所需数据的数据层。应用数据层按照维度建模理论设计，目标是最大程度的满足应用的灵活扩展需求并保证前台应用的数据展现性能。应用数据层是面向应用的，但是也不是每个应用都在应用数据层对应一个表，对应用要在数据应用层中进行整合。应用数据层的数据基于汇总数据层，一般不需要基础数据层的支持。该层数据一般需要长期保存，具体保存周期参照集团公司相关规范。数据应用移动互联网时代，如何利用用户位置数据挖掘出用户空间轨迹、行为轨迹，将以位置数据为核心的信息最大限度的发挥价值，同时优化内部运营分析流程，是运营商能力建设的重要步骤。根据以上需求，本项目将建立基于用户位置的商业选址和精准营销系系统项目系统。数据采集处理：采集结构化数据，以及非结构化数据、用户属性数据等导入，可以根据配置规则对数据进行清洗。数据分析层：接收数据接口层的数据，并对数据进行挖掘处理。采用分布式实时流处理框架,实时处理数据，输出结果。包括数据适配模块、逻辑处理模块、数据输出模块和调度控制模块。Hadoop：全配置驱动，可以根据用户配置对接入数据进行清洗、抽取和转换，可以在现有数据的基础上根据一定规则叠加维度数据，如用户标签叠加，并可以按用户指定数据列对数据进行分发，如IMSI、LAC、CI等，一个数据适配模块实例根据输入数据的大小，可以将数据分发到多个逻辑处理模块实例。深度分析云：包括数据预处理、数据挖掘和机器学习三大部分。数据仓库：存储清洗后的轻量汇总数据。开放应用平台：对用户提供自助服务，自主开发、分析。选择的区域、模型等信息，生成数据挖掘任务。并能根据输入数据的大小自动调整逻辑处理模块的线程数量，提高数据挖掘的性能，并可实现自动负载均衡。多渠道访问门户：通过多种形式、电脑、平板等方式访问开放平台，对接开放平台。存储数据架构设计相对于业务架构和应用架构，数据架构在总体架构中处于基础和核心地位。因为信息系统支撑下的业务运作状况，是通过信息系统中的数据反映出来的，数据信息系统管理的重要资源。因此构建海关的IT总体架构时，首先要考虑数据架构对当前业务的支持。理想的IT总体架构规划逻辑上是数据驱动的，即：首先根据业务架构分析定义数据架构；然后根据数据架构结合业务功能定义应用架构；最后根据应用架构与数据架构的定义，来设计技术架构。数据的基本结构分三个层次，反映了观察数据的三种不同角度。(1)概念数据层。它是数据的整体逻辑表示。指出了每个数据的逻辑定义及数据间的逻辑联系，是存贮记录的集合。它所涉及的是数据所有对象的逻辑关系，而不是它们的物理情况。(2)物理数据层。它是物理存贮设备上实际存储的数据的集合。这些数据是原始数据，是用户加工的对象，由内部模式描述的指令操作处理的位串、字符和字组成。(3)逻辑数据层。它是用户所看到和使用的数据，表示了一个或一些特定用户使用的数据集合，即逻辑记录的集合。批处理满足非实时数据处理业务场景，将批量数据以任务的方式进行处理，并以异步方式提交计算结果，典型场景包括：数据挖掘模型计算、指标引擎计算、OLAP多维分析计算、MapReduce批处理等。数据挖掘模型计算，可以依靠传统的自我编程实现，但受限于开发水平和开发时间要求，且性能也常常不如商业工具强劲和稳定。目前在中国市场上最为流行的三大数据挖掘软件(SAS公司的EnterpriseMiner、IBM公司的IntelligentMiner和SPSS公司的Clementine。在选择合适的数据发掘工具产品时，需要考虑以下几点：数据挖掘是短期使用还是长期行为，数据挖掘经验和水平，数据状态，预算和性能要求。指标引擎计算与OLAP多维分析计算，可以通过关系型数据库计算引擎，在库内实现。考虑数据量级和计算性能，建议使用完全并行的MPP+SharedNothing架构数据库产品，由许多松耦合的处理单元组成，以保证每一个节点（node）都是独立的、自给的、节点之间对等，而且整个系统中不存在单点瓶颈，具有非常强的扩展性。技术要求：1、支持X86PCserver以及虚拟化环境运行，具有低成本优势；2、采用列存储和高效透明压缩技术，降低I/O，提高存储能力；3、具有基于全部字段，自动建立粗粒度智能索引，快速过滤数据包，提高查询性能；4、具有多种数据分布算法策略，确保数据均匀分布在集群节点上，提高整体批量计算性能；5、利用多核CPU，多个I/O通道等硬件资源，具有并行加载，并行计算与并行导出等场景的良好性能；6、具有多种OLAP函数，支持动态hashjoin，静态hashjoin等智能算法适配功能，满足强一致性关联要求；图SEQ图\*ARABIC2静态hashjoin技术图SEQ图\*ARABIC3动态hashjoin技术具有高并发特点，有效支撑自助查询等大规模查询服务和批量调度任务；8、具有线性扩展能力，硬件扩容与计算能力近似线性增长关系。MapReduce是一种编程模型，用于大规模数据集（大于1TB）的并行运算。概念"Map（映射）"和"Reduce（规约）"，主要思想，都是从函数式编程语言里借来的，还有从矢量编程语言里借来的特性。当前的实现是指定一个Map（映射）函数，用来把一组键值对映射成一组新的键值对，指定并发的Reduce（规约）函数，用来保证所有映射的键值对中的每一个共享相同的键组。实现过程：一个代表客户机在单个主系统上启动的MapReduce应用程序称为JobTracker。类似于NameNode，它是Hadoop集群中惟一负责控制MapReduce应用程序的系统。在应用程序提交之后，将提供包含在HDFS中的输入和输出目录。JobTracker使用文件块信息（物理量和位置）确定如何创建其他TaskTracker从属任务。MapReduce应用程序被复制到每个出现输入文件块的节点。将为特定节点上的每个文件块创建一个惟一的从属任务。每个TaskTracker将状态和完成信息报告给JobTracker。流式处理满足实时处理业务场景，实现数据的实时，高效处理计算。典型产品包括：storm，S4，StreamBase等。非实时计算几乎都基于MapReduce计算框架，但MapReduce并不是万能的。对于搜索等应用环境中的某些现实问题，MapReduce并不能很好地解决问题。商用搜索引擎，像Google、Bing和Yahoo!等，通常在用户查询响应中提供结构化的Web结果，同时也插入基于流量的点击付费模式的文本广告。为了在页面上最佳位置展现最相关的广告，通过一些算法来动态估算给定上下文中一个广告被点击的可能性。上下文可能包括用户偏好、地理位置、历史查询、历史点击等信息。一个主搜索引擎可能每秒钟处理成千上万次查询，每个页面都可能会包含多个广告。为了及时处理用户反馈，需要一个低延迟、可扩展、高可靠的处理引擎。然而，对于这些实时性要求很高的应用，尽管MapReduce作了实时性改进，但仍很难稳定地满足应用需求。因为Hadoop为批处理作了高度优化，MapReduce系统典型地通过调度批量任务来操作静态数据；而流式计算的典型范式之一是不确定数据速率的事件流流入系统，系统处理能力必须与事件流量匹配，或者通过近似算法等方法优雅降级，通常称为负载分流（load-shedding）。当然，除了负载分流，流式计算的容错处理等机制也和批处理计算不尽相同。最近Facebook在Sigmod11上发表了利用HBase/Hadoop进行实时数据处理的论文，通过一些实时性改造，让批处理计算平台也具备实时计算的能力。这类基于MapReduce进行流式处理的方案有三个主要缺点。将输入数据分隔成固定大小的片段，再由MapReduce平台处理，缺点在于处理延迟与数据片段的长度、初始化处理任务的开销成正比。小的分段会降低延迟，增加附加开销，并且分段之间的依赖管理更加复杂（例如一个分段可能会需要前一个分段的信息）；反之，大的分段会增加延迟。最优的分段大小取决于具体应用。为了支持流式处理，MapReduce需要被改造成Pipeline的模式，而不是Reduce直接输出；考虑到效率，中间结果最好只保存在内存中等。这些改动使得原有的MapReduce框架的复杂度大大增加，不利于系统的维护和扩展。用户被迫使用MapReduce的接口来定义流式作业，这使得用户程序的可伸缩性降低。综上所述，流式处理的模式决定了要和批处理使用非常不同的架构，试图搭建一个既适合流式计算又适合批处理计算的通用平台，结果可能会是一个高度复杂的系统，并且最终系统可能对两种计算都不理想。数据分析系统整体组成示意图上图从整个分析系统的架构角度，给出了实时计算子系统所处的位置。实时计算系统和批处理计算系统同属于计算这个大的范畴，批处理计算可以是MapReduce、MPI、SCOPE等，实时计算可以是S4、Storm等，批处理和实时都可以或不依赖统一的资源调度系统。另外，计算系统的输入、输出，包括中间过程的输入、输出，都与存储系统交互，可以是块存储系统HDFS，也可以是K-V存储系统Hypertable等。计算层的上层是数据仓库，或者直接和用户交互，交互方式可以是SQL-like或者MR-like等。安全审计数据安全审计是对每个用户在计算机系统上的操作做一个完整的记录，以备用户违反安全规则的事件发生后，有效地追查责任。安全审计需要对关键性数据的操作访问进行详细的记录，并支持违规事件的告警通知等服务。访问控制访问控制是信息安全保障机制的前提和基础，是实现数据保密性和完整性的必要手段。访问控制通过限制访问主体（或称为发起者，是一个主动的实体，如用户，进程，服务等）对访问客体(需要保护的资源，如文件，系统等）访问权限的方法，是资源在合理范围内使用。数据加密加密是一个过程，使数据只对正确的接收者可读，其他用户看到的是杂乱无序的数据。只能使用相应的密钥解密之后才能显示出数据本来内容。以此达到保护数据不被非法人窃取、阅读的目的。数据迁移一方面不再频繁访问的历史数据占据了大量的存储空间，影响系统的响应时间和性能，无形中增加成本。另一方面，这些数据对仍具有价值甚至是宝贵资产，同时受法律、法规、规章要求需要存储关键数据。由于应用场景不同，数据迁移归档策略也不相同。备份恢复为了很好地保护重要数据，除了做好在线数据的存储管理外，还应该有一个良好的数据备份管理策略。主要包括以下内容：备份类型的选择（全备份、增量备份、差分备份）、备份窗口选择、确定存储介质保存时间、计算所需存储介质数量、备份介质的管理等等。数据管理元数据是指关于数据的数据，即对数据的描述信息。根据其属性的不同，元数据可分为技术元数据和业务元数据。元数据管理是元数据的定义、收集、管理和发布的方法、工具及流程的集合，通过完成对相关业务元数据及技术元数据的集成及应用，提供数据路径、数据归属信息，并对业务术语、文档进行集中管理，借助变更报告、影响分析以及业务术语管理等应用，以此保证数据的完整性、控制数据质量、减少业务术语歧义和建立业务人员之间、技术人员之间，以及双方的沟通平台。元数据管理包括元数据采集、元数据维护、元数据变更管理、元数据质量管理、元数据版本管理、标准术语管理、元数据查询、元数据统计、血缘分析、影响分析、差异分析、元数据架构模型管理和接口服务等功能。元数据驱动的全生命周期管理是支持业务建模、分析、设计、开发、测试、组装、发布、部署、运行监控等应用开发过程的。实现各种管理工具、设计器、监控工具，以及软件配置管理。采用模型驱动开发的方式，通过上一阶段的输出与下一阶段的输入结合起来，通过可视化的设计器或工具将开发过程串接起来，大大降低了开发的难度，并降低各个阶段之间的鸿沟以及不一致性。元数据模型描绘出业务的原始状态，业务信息的载体就是最基本的数据实体，建立实体把所有业务信息的含义清晰的展现在用户面前，再通过描述实体的操作来表达业务功能，灵活的信息描述让信息可扩展可配置，并且实体间是支持多种聚合的复杂关系。业务对象元模型按照模块-组件-实体三层关系进行组织。图4-9-4元数据框架图上图所示实体模型存储在元数据仓库中，元数据框架支持访问服务、开发服务、管理服务，支持建模开发工具整合与适配其它系统模型数据。元数据提供统一的查询服务使所有应用清楚的使用统一的实体，基于元数据的访问及持久化让信息的保存查询更加方便透明，通过元数据生成相关代码及数据库脚本加快了开发，使平台上的开发者只需要关注业务逻辑，让业务与技术分离。生命周期管理在数据的整个生命周期中，不同的数据需要不同水平的性能、可用性、保护、迁移、保留和处理。通常情况下，在其生命周期的初期，数据的生成和使用都需要利用高速存储，并相应地提供高水平的保护措施，以达到高可用性和提供相当等级的服务水准。随着时间的推移，数据的重要性会逐渐降低，使用频率也会随之下降。伴随着这些变化的发生，我们就可以将数据进行不同级别的存储，为其提供适当的可用性、存储空间、成本、性能和保护，并且在整个生命周期的不同阶段都能对数据保留进行管理。随着海关科技信息化建设的深入开展，各种电子信息系统不断上线运行，越来越多的通关管理、政务管理通过电子化手段实现，电子数据成了最宝贵的财富。伴随海关信息化的深入和发展，信息资源在为提升海关的服务能力、管理能力提供强有力支持的同时，其自身也变得越来越庞大，不仅难于管理，而且给系统的稳定运行带来了阻碍。为了更好的管理、利用、存放电子数据，需要对数据实施生命周期管理，依据数据的价值与应用的性质将数据进行划分，分别制定相应的管理策略，并建立配套的管理制度，解决目前海关信息系统数据管理策略单一所带来的各种问题，进一步提升系统性能、降低运维成本，为保障海关信息系统的高效、稳定运行提供数据基础。信息资源规模庞大、难以管理的现象在金关一期的通关管理系统中体现得最为突出，同时在电子口岸也积累大量的海关预录入数据以及与各部委的交换数据。因此金关二期建设中将首先对通关管理系统的数据实施生命周期管理，将数据划分为在线数据、近线数据、历史数据、归档数据，依据数据的价值，制定不同的管理策略，更加有效的利用存储空间，避免由于数据量过大引起通关管理系统的性能问题，提高通关管理系统的可用性，降低异地容灾备份的难度，减小高端设备的不断增长，解决运行管理问题。然后，以此为基础，建立起海关数据生命周期管理框架，推动海关各信息系统对数据进行科学、有效的管理，提高信息管理能力。数据生命周期管理主要包括如下功能：对数据实施生命周期管理，将数据划分为在线数据、近线数据、历史数据、归档数据，并制定配套的管理制度。数据质量管理数据质量管理是指对支持业务需求的数据进行全面质量管理，通过数据质量相关管理办法、组织、流程、评价考核规则的制定，及时发现并解决数据质量问题，提升数据的完整性、及时性、准确性及一致性，提升业务价值。通过数据质量管理，保证数据的完整、准确、合法，并能够和运行监控平台结合，及时发现异常数据，及时处理。数据质量管理主要由数据质量检测规则设置、异常数据处理和数据质量检控报告等功能组成。O域数据存储架构设计O域数据的底层存储数据库区在物理上和应用服务器在一个位置,但可以通过防火墙的通过逻辑隔离,将应用服务器和数据库服务器分离。实际上应用服务器和数据库服务器都是通过VMware服务器虚拟化上创建的虚拟服务器，但可以通过交换机策略将两者逻辑分开。存储数据区因为不需要外网直接访问，因此可以通过网络和地址的规划完全与IP网络分离。在本区部署两台IP存储阵列，一台是高性能的SAS硬盘

FAS2240-2，配置24块

15K

600G硬盘，总容量14.4T，经过Raid后还有大约9.6T的实际存储容量。此硬盘可以分为两部分使用，一部分用于虚拟化软件共享存储，用于存放各类虚拟机的数据和用户数据库数据，大约分配3.6T。另外一部分用于存储应用软件的存储的用户数据，此类数据主要存放活跃数据，大约6T。另外一台存储使用高容量SATA存储，配置24块3000G硬盘，总共72T存储容量，经过Raid后，实际存储容量为48T。在此处配置一台F5文件虚拟化管理系统ARX500，用于调度存储阵列内的文件调度。当目前存储容量不足之后，可以随时增加存储容量，这时的存储可以采用更为便宜的基于Windows

storage的存储系统。在整个架构中，我们搭建了两个网络：一个是作为生产网络（根据实际应用可以划分多个VLAN），另外一个作为虚拟中心管理网络和虚拟机动态迁移VMotion网络。另外根据实际的网络环境，结合实际生产环境中的要求，将网卡分别设置在不同的网段上。使用新购置服务器作为ESX虚拟服务器，另外可以利用旧的1台服务器作为VMware

Virtual

Center管理中心。将数据库服务器和应用服务器部署在三台ESX虚拟服务器上，利用VMWareVMotion功能，使得数据库服务器在ESX虚拟服务器硬件环境出现问题的情况下，能够自动的迁移到另一台ESX虚拟服务器上运行，不会因为硬件环境出现的问题而导致应用服务停止运作，保证了业务连续性。再利用VMWare

VCB技术，定时针对应用系统做备份，当应用系统出现损坏的情况下，可以在最短的时间内，恢复到健康的应用系统生产环境。使用VMware

High

Availability功能在整个虚拟化

IT

环境中提供高可用性，而没有传统群集解决方案的成本或复杂性。VMware

HA

可为在虚拟机中运行的任何应用程序提供经济高效的高可用性解决方案，而不需要考虑其应用操作系统设置或应用系统基础硬件配置。VMware

HA

不需要专门的备用硬件和附加软件支持。同时，VMWare系统提供VMWareHA、VMWareVMotion、VMWareDRS的系统资源高可用与自动资源调节能力，可自动平衡应用间对CPU、内存的资源分配，保证应用系统维持在最佳运行状态。VMWare高可用特性，可彻底保证用户关键性应用系统不间断运行。若实施VMWare高可用架构，要求虚拟化应用系统必须接入SAN存储区域以作数据存储共享设置。利用原有两台服务器，一台作为VMware

VirtualCenter服务器，管理整个虚拟化数据中心系统。在存储方面，采用万兆以太网接入的IPSAN存储，具有保障级业务持续性的多种特性，包括热插拔冗余硬件、热备份硬盘、多路经故障切换、快照、克隆、本地/远程镜像和非破坏性固件升级等。汇总架构设计数据采集（ETL）：负责源数据的采集、清洗、转换和加载包括：1、把原始数据加载到Hadoop平台。2、把加工后的数据加载分布式数据库和主数据仓库Hadoop云平台：负责存储海量的流量话单数据，提供并行的计算和非结构化数据的处理能力，实现低成本的存储和低时延、高并发的查询能力。分布式数据库（MPP）：存储加工、关联、汇总后的业务数据，并提供分布式计算，支撑数据深度分析和数据挖掘能力，向主数据仓库输出KPI和高度汇总数据。主数据仓库（与MPP合设）：存储指标数据、KPI数据和高度汇总数据。Hadoop主要功能Hadoop平台提供了海量数据的分布式存储与处理的框架。基于服务器本地的计算与存储资源，Hadoop集群可以扩展到上千台服务器。同时，Hadoop在设计时充分考虑了硬件设备的不可靠因素，在软件层面提供数据和计算的高可靠保证。HDFS：分布式文件系统有较强的容错性可在x86平台上运行，减少总体成本可扩展，能构建大规模的应用HBase：非结构化NoSQl分布式数据库基于分布式文件系统HDFS，保证数据安全列式存储，节省存储空间提供大数据量的高速读写操作Hive：分布式关系型数据库数据可保存在HDFS，可提供海量的数据存储类SQL的查询语句，提供大数据的统计和分析操作，适合海量数据的批处理通过MapReduce实现大规划并行计算MapReduce：大规划并行计算引擎可将任务分布并行运行在一个集群服务器中O域数据应用设计从本质上来说，大数据环境下交通分析技术完成的是一种将数据组织成为信息，从信息提炼特征，从特征变化中发现规律，就对策进行追踪评估的信息处理过程。而模型所处理的问题领域可以划分为系统状态分析和交通行为分析两个基本板块。系统架构针对现代智能交通的海量数据特点，结合与其融合的大数据典型平台架构，搭建一种智能交通海量数据平台其基本架构应包含以下三个部分，即数据采集层、数据架构层以及数据服务层。其中数据采集层采集的数据就是智能交通系统的所有所需处理信息数据，采集后得到的数据通过数据传输到交通云平台，交通云平台会根据不同的应用需求进行分类存储到相应的内存数据库中，此后便按照处理的不同需求选用不同的数据架构层进行处理，最终实现数据服务层对其提供实时快速高效的服务。提前配置Apache

Hive、Apache

Pig以及Impala等多种工具进而实现多种数据的快速分析、甄别和处理。存储模块也会相应的启动数据处理和分析Job的任务。就目前而言数据处理和分析的主要任务类型有：最近数据的查阅和数据简单统计并通过Apache

Hive和ApachePig支持的SQL语句当中查询。然而在这一过程需要注意数据采集层在数据传输系统当中，其统计和分析的数据范围一般为最近的活跃数据，这样的设计就会受限于网络带宽。这样就会造成实时数据传输系统以外的系统为大数据海量数据提供访问接口进而实现批量处理功能。

数据仓库系统

在构建智能交通大数据系统平台少不了数据仓库系统。近些年来，数据仓库系统已经成为数据管理研究领域的热点，而其中的主要原因为数据仓库系统在当前所面临在数据源的需求以及、所处的硬件环境加上需提供的数据服务等都发生了诸多本质性的变化，这些本质性的变化就必须让我们重新改进和利用数据仓库系统。而对于智能交通海量大数据，其应该在现有数据仓库系统的基础上完成对方案的重新审视，并需要具备以下几个重要的特性：1、高度的可扩展性：面对现代交通的发展其数据呈现几何增长的趋势，数据库已经不能仅依靠l台或几台