集团大数据平台总体设计

集团大数据平台总体设计

目录

1综述 ------------------------------------------------------------------------------------------------ 4

1.1项目背景 --------------------------------------------------------------------------------------------- 4

1.2建设目标 --------------------------------------------------------------------------------------------- 4

1.3需求分析 --------------------------------------------------------------------------------------------- 4

1.3.1基础平台------------------------------------------------------------------------------------------ 5

1.3.2企业画像应用 ----------------------------------------------------------------------------------- 6

2总体建设方案 ----------------------------------------------------------------------------------- 7

2.1平台框架设计理念 -------------------------------------------------------------------------------- 7

2.2功能架构 --------------------------------------------------------------------------------------------- 8

2.3技术架构 --------------------------------------------------------------------------------------------- 9

2.4产品覆盖综述------------------------------------------------------------------------------------- 10

2.5数据分布架构------------------------------------------------------------------------------------- 11

2.6关键技术说明------------------------------------------------------------------------------------- 11

2.6.1云服务平台------------------------------------------------------------------------------------- 11

2.6.2Hadoop平台------------------------------------------------------------------------------------ 23

2.6.3元数据管理------------------------------------------------------------------------------------- 24

2.6.4数据治理---------------------------------------------------------------------------------------- 31

2.6.5爬虫引擎---------------------------------------------------------------------------------------- 36

2.6.6数据探索---------------------------------------------------------------------------------------- 40

2.6.7自助分析---------------------------------------------------------------------------------------- 41

2.6.8企业画像---------------------------------------------------------------------------------------- 42

3技术方案特性 --------------------------------------------------------------------------------- 45

3.1平台开放性 ---------------------------------------------------------------------------------------- 45

3.2高性能----------------------------------------------------------------------------------------------- 46

3.2.1应用高性能------------------------------------------------------------------------------------- 46

3.2.2平台系统资源高性能 ----------------------------------------------------------------------- 46

3.2.3实时数据抽取 --------------------------------------------------------------------------------- 47

3.2.4压缩流处理------------------------------------------------------------------------------------- 48

3.2.5库外处理与计算 ------------------------------------------------------------------------------ 48

3.2.6分布式处理------------------------------------------------------------------------------------- 51

3.2.7多网卡支持------------------------------------------------------------------------------------- 52

3.3高可用性 ------------------------------------------------------------------------------------------- 54

3.3.1Hadoop平台高可用性----------------------------------------------------------------------- 54

3.3.2ETL高可用性 ---------------------------------------------------------------------------------- 58

3.3.3应用高可用性 --------------------------------------------------------------------------------- 59

3.4高可靠性 ------------------------------------------------------------------------------------------- 60

3.5开发易用性 ---------------------------------------------------------------------------------------- 61

3.6可维护性 ------------------------------------------------------------------------------------------- 66

3.7弹性扩展能力------------------------------------------------------------------------------------- 70

3.8资源管控能力------------------------------------------------------------------------------------- 71

3.8.1多租户资源管控 ------------------------------------------------------------------------------ 71

3.8.2任务级资源管控 ------------------------------------------------------------------------------ 73 3.9平台监控能力------------------------------------------------------------------------------------- 79

3.9.1Hadoop平台监控 ----------------------------------------------------------------------------- 79

3.9.2ETL任务监控 ---------------------------------------------------------------------------------- 81 3.10数据管控与平台管理能力 -------------------------------------------------------------------- 82 3.11统一开发平台能力 ------------------------------------------------------------------------------ 82 3.12前端展现能力------------------------------------------------------------------------------------- 83 3.13扩容及升级能力 --------------------------------------------------------------------------------- 83

3.13.1平台基础能力扩容与升级 ------------------------------------------------------------- 83

3.13.2应用扩容与升级 -------------------------------------------------------------------------- 85

1综述

1.1项目背景

互联网、云计算、物联网、及时通讯工具和社交网络的兴起和普及，特别是大数据技术的应用，正深刻改变着当前市场格局。达沃斯世界经济论坛发布的《大数据，大影响：国际发展的新可能》的报告宜称，大数据已成为与货币和黄金一样的一种新的经济资产类别。，美国总统办事室（EOP）公布了《大数据研究和发展规划》，把大数据研发应用从商业行为提升到国家战略层面。

在这种新形式下，大数据项目将会作为整个集团的跨公司、跨部门、跨内外的数据综合服务平台，承载着互联网+业务的核心枢纽。该平台的主要建设目标是为集团及其全部相关机构提供全栈大数据服务，包括技术平台、数据应用及产品、数据服务。该平台的建设目标并不仅仅局限于使用大数据技术构建数据分析系统，而是基于云计算、云服务的理念，打造集团“数据即服务”的平台理念。通过整合集团、子公司、互联网+平台、第三方等数据，通过授权机制为集团本部、各子公司、合作伙伴、投资方等提供经营、决策等所需的相关大数据能力和数据服务。

1.2建设目标

本期项目建设目标：

1.为集团及其全部相关机构提供全栈式大数据服务，包括技术平台、数据应

用及产品、数据服务；

2.基于云计算、云服务的理念，打造集团“能力、数据即服务”的平台理念；

3.为集团本部、各子公司、合作伙伴、投资方等提供经营、决策等所需的相

关大数据基础能力和数据服务。

1.3需求分析

本期大数据云服务平台项目包括大数据基础平台建设、企业画像应用两部分。其中数据云平台接入中信云平台，统一进行运营和对外提供服务。

1.3.1基础平台

基础平台提供一站式大数据解决能力和一站式数据分析能力。平台系统支持PaaS层能力，承载用户创建、修改、删除计算与存储资源，创建、发布、与回收业务应用等平台管理功能以及元数据管理、数据质量等数据管控功能；平台系统支持DaaS层能力，即支持数据采集、存储（数据湖）、计算以及展现四大部分能力；平台系统支持SaaS层能力，支持数据的分发、共享、探索、以及协作等功能。

采集部分支持通过探针、爬虫、ETL手段从数据源将数据录入该平台，从数据类型上看，采集部分支持结构化数据采集与非结构化数据采集；从实效性上看，平台支持实时数据采集、初始化数据采集以及增量数据采集；从业务层面看平台支持业务数据采集与第三方数据采集多个维度。

存储部分负责将采集端收集的数据，以及平台内部处理后生成的数据永久性存放。从数据类型上看，平台支持结构化存储、半结构化存储以及非结构化存储；从使用方式上看可以平台支持归档数据存储、批处理数据存储以及在线热数据存储；从业务层面来看平台支持外部数据、子公司业务主数据以及互联网+平台数据存储。

计算部分负责对存储区的数据进行操作，平台支持增删改查、分析统计、模糊检索、挖掘预测等功能。从数据类型上看，平台支持结构化数据计算（SQL）与半结构化/非结构化数据计算；而从使用方式上看，平台支持离线计算、在线应用以及实时处理。

数据展现层支持开发运维展现与应用展现能力。该平台具有完整的可视化开发运维界面，能够通过图形的方式进行平台的状态与健康监控、性能分析、日志查询、资源管控等运维功能，以及在线开发、调试、部署与诊断功能。平台支持在BI报表，OLAP交互式分析、用户自由查询、交互式挖掘、模糊检索、移动端展示等可视化功能。

平台基于云计算、云存储的理念，打造集团“数据即服务”的平台理念，该平台能够使集团将各个子公司、机构与部门的数据有机地结合到一起，能够使用户在该平台中自由地创建、修改、删除计算存储资源，能够有效灵活地访问到其他用户公开的数据，并自由定义自身需要的数据处理逻辑与报表展现方案，并将

结果数据进行公开与共享。

平台需要能够满足用户自定义数据加工与分析流程，包括：

支撑用户与企业画像应用；

提供物联网数据分析能力；

支撑互联网数据应用；

提供非结构化数据处理能力。

1.3.2企业画像应用

企业画像应用围绕集团的子公司，整合集团内外部数据从多个维度进行企业画像，增强对子公司的洞察和智能管控。企业画像将围绕企业基本资料、股东信息、股权关系、关联图谱、管理层信息等维度展示，以及结合企业动态、其它动态信息等动态更新。内部数据以从多个集团公司上报的股权结构、财务数据、合同文件等为主，同时结合外部数据服务、互联网爬虫收集的企业相关信息，对企业进行多维度深入分析，构建统一的企业画像系统。应用具备良好的用户体验，提供移动端应用。

2总体建设方案

2.1平台框架设计理念

大数据云服务平台整体可分为基础能力、服务管理、应用及工具能力三个层次，基础能力通过通用的服务框架供给出去，让应用和工具无需关心底层细节；服务管理起到承上启下的作用，贯穿基础能力和上层应用及工具；应用框架提供了应用及工具的开发管理、部署和运行服务，通过Docker实现最小化改动和便利部署。

如上图所示，大数据平台功能需包括基础能力服务、服务管理、应用和工具、数据可视化及管控中心五部分内容：

基础能力服务包括中间件及数据库等服务和大数据服务两个方面，为满足本期项目需求，中间件及数据库服务包括Tomcat、Kafka、RabbitMQ、Redis、MongoDB、Greenplum、MySQL、Solr、Flume等基础服务，大数据服务包括HDFS、HBase、Hive、Spark、R等基础服务。

服务管理包括多集群资源调度管理、服务管理和容器编排管理功能。

大数据应用包括企业客户画像应用，工具包括DataHub工具、企业级ETL工具、数据治理工具、自助分析工具、数据探索工具和非结构化数据处理工具。

数据可视化包括平台运维可视化、大数据基础存储与计算能力可视化、大数据开发可视化、自助BI可视化、应用与开发管理可视化、数据交换能力可视化及企业画像应用可视化。

管控中心功能包括租户管理、资源管理、服务集群管理、计费管理、安全管理和系统管理功能。

从技术上，本期提供的基础服务能力包括Tomcat、Kafka、RabbitMQ、Redis、MongoDB、Greenplum、MySQL、Solr、Flume等，Hadoop基础服务能力包括HDFS、HBase、Hive、Spark、R等。

服务管理核心技术包括Mesos（实现多集群资源调度管理）、ServiceBroker （实现基础服务与应用统一的服务管理）、Kubernetes（实现容器编排管理）。

应用与工具都是基于基础服务能力构建起来的:

企业客户画像应用:Web中间件采用Tomcat，数据处理能力采用Greenplum和Spark计算框架；

DataHub工具：Web中间件采用Tomcat，消息中间件采用Kafka，数据库采用MySQL、Redis和MongoDB；

企业级ETL工具：Web中间件采用Tomcat，消息中间件采用Kafka和RebbitMQ，数据库采用MySQL，数据处理采用Hive和Spark；数据采

集使用flume；

数据治理工具：Web中间件采用Tomcat，数据库采用MySQL；

自助分析工具：Web中间件采用Tomcat，数据库采用Greenplum;

数据探索工具：Web中间件采用Tomcat，数据库采用MySQL，数据处理

采用SparkR；

非结构化数据处理工具：Web中间件采用Tomcat，数据库采用MySQL，爬虫采用HttpClient,全文检索采用Solr，图像识别采用

OCRtesseract。

数据可视化能力采用的核心技术包括HTML5、JQuery、BITools、JFreeChart、Canvas等。

管控中心Web中间件采用Tomcat，数据库采用MySQL，Hadoop集中式安全管理框架采用Ranger，Hadoop统一运维监控告警采用Ambari。

2.4产品覆盖综述

产品可完整覆盖上述功能架构：

大数据平台整体框架采用云服务平台产品，Hadoop平台采用Hadoop平台产品，企业客户画像采用企业画像产品，DataHub工具采用DataHub产品，企业级ETL工具采用ETL产品，数据治理工具采用治理产品，自助分析工具采用自助分析产品，数据探索工具采用探索产品，非结构化数据处理工具采用非结构化数据处理产品，包括爬虫工具、图像识别工具和全文检索工具。

2.5数据分布架构

大数据平台数据分布架构如上图所示：

接口机：承担数据采集的功能，内部渠道数据包括合同文件、股东信息、物联网数据等，外部数据包括工商数据、法务数据、运营商数据等，通

过接口机进入HDFS文件系统；

文件系统HDFS：存放企业合同附件（PDF），股东信息、企业关系、法务信息、工商税务信息、数据交换信息等在HDFS上加工处理后入到

HBase、Redis数据库中；

HBase：存放企业股东信息、企业关系等相关数据；外部数据（包括工商税务及外部爬取的相关数据）；物联网相关数据；

Greenplum：存放在线汇总数据（如未来接入的物联网数据二次汇总数据）；

Redis：存放爬虫引擎所需的实例库及DataHub的数据信息；

MySQL：平台配置信息库。

2.6关键技术说明

2.6.1云服务平台

2.6.1.1应用封装工具

Docker是一种容器技术，和Hypervisor（KVM/Xen这类）不同的是，Docker 不会提供一整个操作系统，他能提供隔离的程序运行环境。对一个应用来说这已经够了。

作为一个开源的应用容器引擎，Docker让开发者可以打包他们的应用以及依赖包到一个可移植的容器中，然后发布到任何流行的 linux 机器上，与KVM 这类超级底层虚拟化方案相比，Docker是一种轻量级虚拟化方案，他不需要对内核进行改变，他主要利用linux内核特性实现虚拟化，所有容器运行在同一个内核中。另外，docker还可以部署在KVM/XEN这类虚拟机中！容器与虚拟机对比如下图。

Docker使用客户端-服务器(client-server)架构模式。Docker客户端会与Docker守护进程进行通信。Docker守护进程会处理复杂繁重的任务，例如建立、运行、发布你的Docker容器。Docker客户端和守护进程可以运行在同一个系统上，当然你也可以使用 Docker客户端去连接一个远程的Docker守护进程。Docker客户端和守护进程之间通过socket或者RESTful API进行通信。

Docker主要有三个重要模块：镜像、仓库和容器

●镜像（Image）：Docker镜像是一个只读的模板。举个例子，一个镜像

可以包含一个运行在Apache上的Web应用和其使用的ubuntu操作系统。

镜像是用来创建容器的。Docker提供了简单的，你也可以下载别人已经

创建好的镜像。

●仓库（Image）：Docker仓库用来保存镜像。其相当于一个代码仓库，

同样的，Docker仓库也有公有和私有的概念。公有的Docker仓库名字

是Docker Hub。也可以自己创建仓库。

●容器（Container）：一个Docker容器包含了某个应用运行所有的所需

要的环境。每一个Docker容器都是从Docker镜像创建的。Docker容

器可以运行、开始、停止、移动和删除、保存为镜像。每一个Docker

容器都是独立和安全的应用平台。

Docker内部采用Linux的命名空间机制实现隔离性，采用cgroup实现资源的划分。

我们主要用Docker来做分布式环境下的进程管理。Docker工作流如图7所示，我们不仅把Docker应用到生产阶段，也应用到开发阶段，所以我们每天编辑Dockerfile，提升Docker Images，测试上线，发Docker镜像，在我们内部私有Docker regis里面，再调到我们Docker集群生产环境里面，这和其他的Docker工作流没有什么区别。

应用的Docker化，可以推动应用与平台分离、应用与服务分离、应用与数据分离，给应用的开发、生产和运维带来很大的变化：

1、Docker化给应用带来了一种全新的轻量级虚拟化体验。同样是虚拟化，Docker相对虚拟机最大的优点是复用了宿主机的操作系统，使得Docker的运行和镜像的存储节省了大量存储和计算资源，使得应用在性能和灵活性方面得到很大的改善。

2、采用Docker封装的方式进行应用交付，其封装内容不仅包括程序也包括相关的参数、配置和环境设置。这种带环境的交付方式真正实现了开发运维环境的统一，避免了因为环境不同带来相关组件和程序在开发、测试、生产环境中的反复部署。不仅降低由此带来的额外工作量，同时也避免了环境差异可能造成的各种差错。这种封装使得应用的部署和运维简单到只需关注地址分配和依赖关系，使得应用的自动化运维成为可能。

3、Docker化交付缩短了应用开发、测试和上线的时间，原本以周和月为单位的程序开发、测试和生产环境的准备时间，现在可以以小时和天来计算。同时，我们辅以应用的灰度发布和在线升级技术，大大加快应用迭代速度，通过开发与运维的一体化能力，更好的支撑业务层面的敏捷化要求。

4、Docker容器与集群管理技术相结合不仅实现整个应用集群的资源高效利用，同时实现资源的按需分配和水平方向的自动和手动的扩展和收缩。例如：当业务进入峰值时期，我们可以设置策略，比如CPU或内存超过90%集群自动进行

扩展30%。峰值过后，应用集群可以根据策略实现自动化缩容，把空闲的资源交还给资源池，使得其他的应用能够有足够的资源使用。这种自动化扩展和收缩对业务是透明的，只要资源池里的资源足够业务永远不可能出现性能瓶颈问题。

5、通过应用与平台分离、应用与服务分离，实现应用与平台的合理分工。平台可以聚焦和改善资源和服务的供给、安全及稳定问题，例如：自动化的实现数据库、中间件等服务的部署、配置、开通和故障处置；自动化的实现应用部署、资源分配、运行监控、故障恢复；动态监控业务负荷的变化自动实现应用的扩缩容等。

2.6.1.2分布式集群管理工具

Kubernetes是Google推出的开源容器集群管理系统，基于Docker构建一个容器调度服务，为容器化的应用提供资源调度、部署运行、均衡容灾、服务注册、扩容缩容等功能，其本质上可看作是基于容器技术的mini-PaaS平台，提取PaaS中的业务编排和管理模块而形成的。部署容器的过程中最大化利用资源是十分重要的，Docker和Kubernetes组合就可以完美的实现这一点。

Kubernetes以RESTFul形式开放接口，用户可操作最基本的REST对象有三个：Pod、Service和ReplicationController。

pod：是Kubernetes最基本的部署调度单元，可以包含container，逻辑上表示某种应用的一个实例。比如一个web站点应用由前端、后端及

数据库构建而成，这三个组件将运行在各自的容器中，那么我们可以创

建包含三个container的pod。

●service：是pod的路由代理抽象，用于解决pod之间的服务发现问题。

因为pod的运行状态可动态变化(比如切换机器了、缩容过程中被终止了

等)，所以访问端不能以写死IP的方式去访问该pod提供的服务。service

的引入旨在保证pod的动态变化对访问端透明，访问端只需要知道

service的地址，由service来提供代理。

●replicationController：是pod的复制抽象，用于解决pod的扩容缩容

问题。通常，分布式应用为了性能或高可用性的考虑，需要复制多份资

源，并且根据负载情况动态伸缩。通过replicationController，我们

可以指定一个应用需要几份复制，Kubernetes将为每份复制创建一个

pod，并且保证实际运行pod数量总是与该复制数量相等(例如，当前某

个pod宕机时，自动创建新的pod来替换)。

Kubernetes的优点是可以通过定义一个Replicationcontroller来将同一个模块部署到任意多个容器中，并且由Kubernetes自动管理。比如定义了一个Apache Pod，通过Replicationcontroller设置启动100个Replicas，系统就会在Pod创建后自动在所有可用的Minions中启动100个Apache Container。并且轻松的是，当Container或者是所在的服务器不可用时，Kubernetes会自动通过启动新的Container来保持100个总数不变，这样管理一个大型系统变得轻松和简单。

Master运行三个组件：

●apiserver：作为kubernetes系统的入口，封装了核心对象的增删改查

操作，以RESTFul接口方式提供给外部客户和内部组件调用。它维护的

REST对象将持久化到etcd（一个分布式强一致性的key/value存储）。

●scheduler：负责集群的资源调度，为新建的pod分配机器。这部分工作

分出来变成一个组件，意味着可以很方便地替换成其他的调度器。

●controller-manager：负责执行各种控制器，目前有两类：

●endpoint-controller：定期关联service和pod(关联信息由endpoint

对象维护)，保证service到pod的映射总是最新的。

●replication-controller：定期关联replicationController和pod，

保证replicationController定义的复制数量与实际运行pod的数量总

是一致的。

Slave(称作minion)运行两个组件：

●kubelet：负责管控docker容器，如启动/停止、监控运行状态等。它会

定期从etcd获取分配到本机的pod，并根据pod信息启动或停止相应的

容器。同时，它也会接收apiserver的HTTP请求，汇报pod的运行状态。

●proxy：负责为pod提供代理。它会定期从etcd获取所有的service，

并根据service信息创建代理。当某个客户pod要访问其他pod时，访

问请求会经过本机proxy做转发。

下面分别从它们的对象创建出发，通过时序图来描述Kubernetes各个组件之间的交互及其工作流。

Kubernetes和Docker可以运行在物理机上，也可以运行在虚拟机上。提供Pass支撑，对项目的开发、测试、实施运行、运维都提供极大的便利，是目前最先进的技术，在国内外得到较多的采用，如google、阿里等。Kubernetes和Docker支持集群服务，自动负载均衡和提供高可靠的稳定服务。

2.6.1.3实例的注册与发现

服务发现可以让一个服务实例发现其运行环境以及其它服务实例的信息。它通常采用分布式key-value的存储方式，它也用来作为查询配置细节信息。通过服务发现工具可以将Docker实例与运行的配置分离，使得用户就可以在一个集群中使用同一镜像运行多个实例以构建分布式应用。

服务注册与发现

服务发现的基本思想是任何一个应用的实例能够以编程的方式获取当前环境的细节。这是为了让新的实例可以嵌入到现有的应用环境而不需要人工干预。服务发现工具通常是用全局可访问的存储信息注册表来实现，它存储了当前正在运行的实例或者服务的信息。

虽然服务发现平台的初衷是提供连接信息来连接不同组件的，但是它们更普遍地是用来存储任何类型的配置信息。许多部署工具通过写入它们的配置信息给

发现工具来实现这个特性。如果容器配置了这些，它们就可以去查询这些预配置信息，并根据这些信息来调整自身行为。

服务发现的机制

每一个服务发现工具都会提供一套API，使得组件可以用其来设置或搜索数据。正是如此，对于每一个组件，服务发现的地址要么硬编码到程序或容器内部，要么在运行时以参数形式提供。通常来说，发现服务用键值对形式实现，采用标准HTTP协议交互。

服务发现门户的工作方式是：当每一个服务启动上线之后，他们通过发现工具来注册自身信息。它记录了一个相关组件若想使用某服务时的全部必要信息。例如，一个Docker启动后会在注册它运行的IP、端口等信息。当服务消费者（有依赖关系的节点）上线时，它能够通过服务发现机制查询到该Docker的配置信息，然后基于查到的信息与其需要的Docker进行交互。

服务发现机制可以让容器的部署、变更更加灵活，不受限于特定的配置信息，同时容器与容器之间交互时变得简单，可以动态进行调整配置。

全局配置存储

在Docker部署中，分布式键值对存储其中一个功能是对集群成员的存储和管理。配置存储是为了追踪Docker集群宿主机成员变更和管理工具的最好环境。这些信息是：

宿主机的IP地址

宿主机自身的链接信息

跟调度信息有关的标签或元数据信息

集群中的角色（如果是采用了主从模式的集群）

……

在正常情况下，使用一个服务发现平台时，这些细节可能不是你需要考虑的。但是他们为管理工具提供了一个可以查询或修改集群自身信息的地方。

故障检测机制

故障检测的实现方式也有很多种。需要考虑的是如果一个Docker出现故障，服务发现能否更新状态指出该Docker不再提供服务。这种信息是至关重要的，关系到将应用或服务故障可能性降到最低。

许多服务发现平台允许赋值时带一个可配置的超时时间。服务可以设置一个超时时间，并能定期去请求服务发现来重置超时时间。如果该服务出现故障，超时时间达到设定值，那么这个服务的连接信息就会从服务发现的存储中被去掉。超时时间长度在很大程度上是它与应用需要多快去应对一个组件的故障的函数。

这也可以通过将一个基本的“助手”容器与每一个组件相连来实现,而它们唯一的责任是定期的健康检查组件以及更新注册表如果组件关闭。这种类型的架构值得担忧是，如果辅助容器出现故障，将导致不正确的信息在存储中。一些系统解决这个问题的方法是在服务发现的工具中定义健康检查。这样,发现平台本身可以定期检查已注册组件是否仍然可用。

配置变更机制

对于基本的服务发现模型来说，一个关键的改进就是动态重新配置。普通服务发现工具允许用户通过检查在启动时的信息来影响组件的初始配置，而动态重新配置涉及配置组件来反映配置存储中的新信息。例如，当你在运行一个负载均衡，后端服务器上的健康检查可能会提示集群中的某一个成员出现故障了。运行中的成员需要知道这个信息，并调整配置信息和重新加载它的负载。

由于负载均衡的例子是这个功能的主要应用场景之一，在当配置变动时重新配置负载均衡，例如HAProxy的配置调整。这些工具周期性的去请求服务发现工具，并且当变更被发现，利用模板系统和服务发现工具中的值来生成新配置文件。当配置文件生成结束，相应的服务将被重新加载。

这种类型的动态配置在构建过程中需要更多的规划和配置，因为这些所有的策略都需要存在于组件容器之中。这使得组件容器负责调整自身的配置。

服务发现的安全性

有许多不同的方法来解决这个问题：一种解决方案是继续允许开放发现服务平台本身，但是对于写入数据进行加密，使用者必须用相应的密钥来解码从服务发现中获取的信息才能使用。其他组件不可以获取到未加密的数据。还有不同的方法，例如采用访问控制列表，将不同的键值切分到不同的分组中。他们可以根据访问需要来制定不同的秘钥来访问相应的分组。这种简单的方式既保证了能够给特定组件提供信息又保证了对其他组件的不可访问性。每个组件都可以被配置为只允许访问它所需要的连接信息。

大数据处理平台构架设计说明书

大数据处理平台及可视化架构设计说明书 版本：1.0 变更记录

目录 1 1. 文档介绍 (3) 1.1文档目的 (3) 1.2文档范围 (3) 1.3读者对象 (3) 1.4参考文献 (3) 1.5术语与缩写解释 (3) 2系统概述 (4) 3设计约束 (5) 4设计策略 (6) 5系统总体结构 (7) 5.1大数据集成分析平台系统架构设计 (7) 5.2可视化平台系统架构设计 (11) 6其它 (14) 6.1数据库设计 (14) 6.2系统管理 (14) 6.3日志管理 (14)

1 1. 文档介绍 1.1 文档目的 设计大数据集成分析平台，主要功能是多种数据库及文件数据；访问；采集；解析，清洗，ETL，同时可以编写模型支持后台统计分析算法。 设计数据可视化平台，应用于大数据的可视化和互动操作。 为此，根据“先进实用、稳定可靠”的原则设计本大数据处理平台及可视化平台。 1.2 文档范围 大数据的处理，包括ETL、分析、可视化、使用。 1.3 读者对象 管理人员、开发人员 1.4 参考文献 1.5 术语与缩写解释

2 系统概述 大数据集成分析平台,分为9个层次，主要功能是对多种数据库及网页等数据进行访采集、解析，清洗，整合、ETL，同时编写模型支持后台统计分析算法，提供可信的数据。 设计数据可视化平台 ,分为3个层次，在大数据集成分析平台的基础上实现大实现数据的可视化和互动操作。

3 设计约束 1.系统必须遵循国家软件开发的标准。 2.系统用java开发，采用开源的中间件。 3.系统必须稳定可靠，性能高，满足每天千万次的访问。 4.保证数据的成功抽取、转换、分析，实现高可信和高可用。

中位物联网大数据平台总体设计V1.0

物联网大数据平台总体设计V0.2

目录 1.引言 (3) 1.1.文档目的 (3) 1.2.文档范围 (3) 1.3.预期的读者及阅读建议 (3) 1.4.术语 (3) 2.项目概述 (4) 2.1.项目背景 (4) 3.1.设计目标 (4) 3.1.1.技术规划路线建议 (4) 3.1.2.大数据软硬平台/网络架构规划建议 (5) 3.1.3.大数据应用集成点规划建议 (5) 3.1.4.大数据团队建设规划建议 (5) 3.1.5.大数据系统实施指导建议方案 (5) 3.数据平台总体架构规划 (5) 3.1.数据平台愿景 (5) 3.2.数据处理流程 (8) 3.3.主要功能 (8) 3.4.设计原则 (9) 3.5.平台建设路线 (9) 4.数据平台软件架构设计 (10) 4.1.数据平台结构图 (10) 4.2.数据采集系统 (11) 4.3.数据存储系统 (11) 4.4.离线计算系统 (12) 4.5.海量数据库系统 (12) 4.6.管理系统 (13)

5.应用平台架构设计 (14) 5.1.应用平台架构图 (14) 6.平台安全 (15) 7.平台监控 (15) 8.部署架构 (15) 9.平台运维 (15) 10.团队建设 (16) 10.1.运维工程师 (16) 10.2.应用开发工程师 (16) 10.3.通信协议开发工程师 (16) 10.4.基于Hadoop的开发工程师 (16) 10.5.数据开发工程师 (16) 10.6.数据挖掘工程师 (17)

1.引言 1.1.文档目的 本文档是关于xx公司物联网大平台的总体架构设计方案。本文包括以下内容： 1.平台总体架构设计； 2.五大子系统设计； 3.应用平台设计 4.平台部署架构设计； 5.平台运维及团队建设； 1.2.文档范围 本文档仅限于北京xx科技公司内部人员和直接协助北京xx科技进行大平台建设的相关人员阅读。 1.3.预期的读者及阅读建议 本文档的预期读者： 1.北京xx科技的大平台项目相关人员； 2.直接协助北京xx科技进行大平台建设的相关外部人员； 1.4.术语 1.Hadoop: Apache的分布式框架。 2.HDFS : Hadoop的分布式文件系统。 https://www.sodocs.net/doc/b05595963.html,Node : Hadoop HDFS元数据主节点服务器。负责保持DataNode文件存 储元数据信息。

大数据平台概要设计说明书

计算平台 概要设计说明书 作者：日期：2013-01-28批准：日期： 审核：日期： （版权所有，翻版必究）

文件修改记录

目录 1.引言 ........................................................................................... 1.1编写目的................................................. 1.2术语与缩略词............................................. 1.3对象及范围............................................... 1.4参考资料................................................. 2.系统总体设计 ............................................................................. 2.1需求规定................................................. 2.1.1数据导入............................................ 2.1.2数据运算............................................ 2.1.3运算结果导出........................................ 2.1.4系统监控............................................ 2.1.5调度功能............................................ 2.1.6自动化安装部署与维护................................ 2.2运行环境................................................. 2.3基本设计思路和处理流程................................... 2.4系统结构................................................. 2.4.1大数据运算系统架构图................................ 2.4.2hadoop体系各组件之间关系图......................... 2.4.3计算平台系统功能图.................................. 2.4.4系统功能图逻辑说明.................................. 2.4.5计算平台业务流程图..................................

技术向如何设计企业级大数据分析平台

技术向：如何设计企业级大数据分析平台？ 传统企业的OLAP几乎都是基于关系型数据库，在面临“大数据”分析瓶颈，甚至实时数据分析的挑战时，在架构上如何应对？本文试拟出几个大数据OLAP平台的设计要点，意在抛砖引玉。 突破设计原则 建设企业的大数据管理平台（Big Data Management Platform），第一个面临的挑战来自历史数据结构，以及企业现有的数据库设计人员的观念、原则。数据关系、ACID 在关系数据库几十年的统治时期是久得人心，不少开发人员都有过为文档、图片设计数据表，或将文档、图片序列化为二进制文件存入关系数据库的经历。在BDMP之上，我们需要对多种不同的格式的数据进行混合存储，这就必须意识到曾经的原则已经不再适用——One size dosen’t fit all，新的原则——One size fits a bunch. 以下是我列出的一些NoSQL数据库在设计上的模式： 文档数据库：数据结构是类JSON，可以使用嵌入（Embed）或文档引用（Reference）的方式来为两个不同的文档对象建立关系；

列簇数据库：基于查询进行设计，有宽行（Wild Rows）和窄行（Skinny Rows）的设计决策； 索引数据库：基于搜索进行设计，在设计时需要考虑对对每个字段内容的处理（Analysis）。 搜索和查询的区别在于，对返回内容的排序，搜索引擎侧重于文本分析和关键字权重的处理上，而查询通常只是对数据进行单列或多列排序返回即可。 数据存储的二八原则 不少企业在解决海量数据存储的问题上，要么是把关系数据库全部往Hadoop上一导入，要么是把以前的非结构化数据如日志、点击流往NoSQL数据库中写入，但最后往往发现前者还是无法解决大数据分析的性能瓶颈，后者也无法回答数据如何发挥业务价值的问题。 在数据的价值和使用上，其实也存在着二八原则： 20%的数据发挥着80%的业务价值； 80%的数据请求只针对20%的数据。 目前来看，不管是数据存储处理、分析还是挖掘，最完整和成熟的生态圈还是基于关系型数据库，比如报表、联机分析等工具；另外就是数据分析人员更偏重于查询分析语言如SQL、R、Python数据分析包而不是编程语言。 企业大数据平台建设的二八原则是，将20%最有价值的数据——以结构化的形式存储在关系型数据库中供业务人员进行查询和分析；而将80%的数据——以非结构化、原始形式存储在相对廉价的Hadoop等平台上，供有一定数据挖掘技术的数据分析师或数据工

政务大数据平台建设项目总体设计方案

政务大数据平台建设项目总体设计方案 1.1.总体设计原则 本设计应遵循以下基本原则： （1）先进性和可扩展性 设计时充分考虑技术的先进性、前瞻性和可扩展性，以保证系统在相当长的时间内能满足XXX社会治理大数据平台建设项目对社会管理和社会服务的实际需要。 （2）实用性和便捷性 设计时应考虑不同层次、不同岗位、不同专业用户需求的差异性，提供统一的访问接口、便捷的操作方式和友好的用户界面。 （3）可行性和可操作性 设计时应充分考虑建设的可行性和可操作性，在详细分析建设现状、建设需求和条件的基础上，制订合理的设计方案，提出合理的项目建设与运行管理方案。同时，系统的建设还应考虑XXX现有电子政务系统已有资源利旧与整合，减

少投资。 （4）经济性与安全性 XXX社会治理大数据平台建设项目数据都是比较敏感的工作数据，必须在现有资金预算的前提下建立相对完善的网络与信息安全保障体系，妥善解决信息安全的问题，处理好经济与安全的关系，综合平衡成本和效益。综合考虑信息采集、传输、处理和应用等各个环节应用的实际需要，在多方案论证和综合比较的基础上提出了既安全又经济的设计方案。 （5）可靠性和合理性 XXX社会治理大数据平台建设项目建设服务范围广、涉及内容多，需要具有较高的可靠性，设计时除了充分保证可靠性外，还应建设合理的运行维护管理模式及相关保障体系，为系统的运行维护管理奠定良好的基础。 （6）需求主导，整合应用的原则 以需求为主导，突出重点，认真分析系统流程，充分利用现有的通信及计算机网络、数据库资源，加强整合，促进

互联互通、信息共享。 1.2.总体目标 XXX社会治理大数据平台建设项目的总体目标是以项目建设为契机，以“一个网络体系、一套应用系统、三个基础库”为依托，充分利用大数据挖掘、云计算等先进技术，有效整合各方信息资源，实现“人、地、物、事、组织”的网格化管理，从而带动XXX社会管理源头治理体系、动态协调机制、应急管理体制建设，实现XXX社会管理“精确化”、社会服务“人性化”，提升社会服务效能，并为XXX实现智慧城市奠定信息化基础。 主要建设目标是为政府社会管理良性有序运行提供基本手段和保证，促进政府对社会系统的组成部分、社会生活的不同领域以及社会发展的各个环节进行组织、协调、服务、监督和控制，整合政府各部门资源，实现统一运维管理，并建立安全和运维保障体系。科学划分网格单元，优化网格资源配置，构筑“区—街道—社区—网格”的四级管理架构，

某大型企业大数据平台整体解决方案

某大型企业数据平台整体解决方案

目录 1项目概述 (15) 1.1建设背景 (15) 1.1.1集团已有基础 (15) 1.1.2痛点及需提升的能力 (15) 1.1.3大数据趋势 (16) 1.2建设目标 (16) 1.2.1总体目标 (16) 1.2.2分阶段建设目标 (17) 1.3与相关系统的关系 (18) 1.3.1数据分析综合服务平台 (18) 1.3.2量收系统 (19) 1.3.3金融大数据平台 (20) 1.3.4各生产系统 (20) 1.3.5CRM (20) 1.4公司介绍和优势特点 (20) 1.4.1IDEADATA (20) 1.4.2TRANSWARP (22) 1.4.3我们的优势 (24) 2业务需求分析 (27) 2.1总体需求 (27)

2.2.1数据采集 (29) 2.2.2数据交换 (29) 2.2.3数据存储与管理 (29) 2.2.4数据加工清洗 (30) 2.2.5数据查询计算 (31) 2.3数据管控 (32) 2.4数据分析与挖掘 (32) 2.5数据展现 (33) 2.6量收系统功能迁移 (34) 3系统架构设计 (35) 3.1总体设计目标 (35) 3.2总体设计原则 (35) 3.3案例分析建议 (37) 3.3.1中国联通大数据平台 (37) 3.3.2恒丰银行大数据平台 (49) 3.3.3华通CDN运营商海量日志采集分析系统 (63) 3.3.4案例总结 (69) 3.4系统总体架构设计 (70) 3.4.1总体技术框架 (70) 3.4.2系统总体逻辑结构 (74)

3.4.4系统接口设计 (83) 3.4.5系统网络结构 (88) 4系统功能设计 (91) 4.1概述 (91) 4.2平台管理功能 (92) 4.2.1多应用管理 (92) 4.2.2多租户管理 (96) 4.2.3统一运维监控 (97) 4.2.4作业调度管理 (117) 4.3数据管理 (119) 4.3.1数据管理框架 (119) 4.3.2数据采集 (122) 4.3.3数据交换 (125) 4.3.4数据存储与管理 (127) 4.3.5数据加工清洗 (149) 4.3.6数据计算 (150) 4.3.7数据查询 (170) 4.4数据管控 (193) 4.4.1主数据管理 (193) 4.4.2元数据管理技术 (195)

大数据平台建设方案设计

大数据平台建设方案 （项目需求与技术方案） 一、项目背景 “十三五期间，随着我国现代信息技术的蓬勃发展，信息化建 设模式发生根本性转变,一场以云计算、大数据、物联网、移动应用等技术为核心的“新IT潮风起云涌，信息化应用进入一个“新 常态。***（某政府部门）为积极应对“互联网+和大数据时代的 机遇和挑战，适应全经济社会发展与改革要求，大数据平台应运而生。 大数据平台整合社会经济发展资源，打造集数据采集、数据处、监测管、预测预警、应急指挥、可视化平台于一体的大数据平 台，以信息化提升数据化管与服务能，及时准确掌握社会经济发展情况，做到“用数据说话、用数据管、用数据决策、用数据创新，把握社会经济发展主动权和话语权。 二、建设目标 大数据平台是顺应目前信息化技术水平发展、服务政府职能改革的架构平台。它的主要目标是强化经济运监测分析，实现企业信用社会化监督，建规范化共建共享投资项目管体系，推进政务数据共享和业务协同，为决策提供及时、准确、可靠的信息依据，提高政务工作的前瞻性和针对性，加大宏观调控，促进经济持续健康发

展。 1、制定统一信息资源管规范，宽数据获取渠道，整合业务 信息系统数据、企业单位数据和互联网抓取数据，构建汇聚式一体化数据库，为平台打下坚实稳固的数据基础。 2、梳各相关系统数据资源的关联性，编制数据资源目录，建 信息资源交换管标准体系，在业务可性的基础上，实现数据信息共享，推进信息公开，建跨部门跨领域经济形势分析制。 3、在大数据分析监测基础上，为政府把握经济发展趋势、预见经济发展潜在问题、辅助经济决策提供基础支撑。 三、建设原则 大数据平台以信息资源整合为重点，以大数据应用为核心，坚持“统筹规划、分步实施，整合资源、协同共享，突出重点、注重实效，深化应用、创新驱动的原则，全面提升信息化建设水平，促进全 经济持续健康发展。

集团企业大数据云平台建设方案

集团企业大数据云平台建设方案

目录 第1章方案总述 (1) 1.1项目背景 (1) 1.2项目目标 (2) 1.3项目建设原则 (2) 第2章系统建设规划 (4) 2.1项目建设目标的理解 (4) 2.1.1 项目建设范围 (4) 2.1.1.1 业务范围 (4) 2.1.1.2 组织范围 (4) 2.1.1.3 数据范围 (4) 2.1.2 项目建设内容 (4) 2.1.2.1 基础数据平台 (5) 2.1.2.2 集团级指标体系 (6) 2.1.2.3 统一报表平台 (6) 2.2集团（企业）数据平台的建设目标 (7) 2.2.1 集团（企业）数据平台一期建设目标 (7) 2.2.2 集团（企业）数据平台二期建设目标 (7) 第3章整体设计方案 (8) 3.1系统设计方法论 (8) 3.1.1 方法论 (8) 3.1.2 设计原则 (10) 3.1.2.1 标准规范 (11) 3.1.2.2 开放性 (12) 3.1.2.3 可扩展性 (12) 3.1.2.4 高性能 (13)

3.1.2.5 可管理性 (14) 3.1.2.6 高可用性 (15) 3.1.2.7 安全性 (16) 3.1.2.8 可重用性 (17) 3.2数据平台技术体系 (18) 3.2.1 数据平台逻辑架构 (18) 3.2.1.1 数据集成区 (18) 3.2.1.2 集团分析型数据区 (19) 3.2.1.3 管理平台区 (19) 3.2.1.4 统一报表展现平台 (20) 3.2.1.5 ETL设计关键技术点说明 (20) 3.2.1.5.1.1 ETL处理策略 (20) 3.2.1.5.1.2 ETL处理流程 (21) 3.2.1.5.2 质量检核 (21) 3.2.1.5.2.1 ETL处理原则 (21) 3.2.1.5.2.2 ETL处理方法 (21) 3.2.2 数据采集设计 (21) 3.2.2.1 T+1数据采集 (22) 3.2.2.2 数据补录 (23) 3.2.2.2.1 检核规则管理 (24) 3.2.2.2.2 录入任务管理 (24) 3.2.2.2.3 数据录入 (26) 3.2.2.2.4 查询操作 (27) 3.2.2.2.5 录入任务审批 (28) 3.3数据平台数据体系 (28) 3.3.1 数据架构设计 (28) 3.3.1.1 源系统数据落地区 (29) 3.3.1.2 缓冲数据层(ODM) (30)

中位物联网大数据平台总体设计V1.0

物联网大数据平台总体设计V0.2 拓 2015.10

目录 1.引言 (3) 1.1.文档目的 (3) 1.2.文档围 (3) 1.3.预期的读者及阅读建议 (3) 1.4.术语 (3) 2.项目概述 (4) 2.1.项目背景 (4) 3.1.设计目标 (4) 3.1.1.技术规划路线建议 (4) 3.1.2.大数据软硬平台/网络架构规划建议 (5) 3.1.3.大数据应用集成点规划建议 (5) 3.1.4.大数据团队建设规划建议 (5) 3.1.5.大数据系统实施指导建议方案 (5) 3.数据平台总体架构规划 (5) 3.1.数据平台愿景 (5) 3.2.数据处理流程 (8) 3.3.主要功能 (8) 3.4.设计原则 (9) 3.5.平台建设路线 (9) 4.数据平台软件架构设计 (10) 4.1.数据平台结构图 (10) 4.2.数据采集系统 (11) 4.3.数据存储系统 (11) 4.4.离线计算系统 (12) 4.5.海量数据库系统 (12) 4.6.管理系统 (13)

5.应用平台架构设计 (14) 5.1.应用平台架构图 (14) 6.平台安全 (15) 7.平台监控 (15) 8.部署架构 (15) 9.平台运维 (15) 10.团队建设 (16) 10.1.运维工程师 (16) 10.2.应用开发工程师 (16) 10.3.通信协议开发工程师 (16) 10.4.基于Hadoop的开发工程师 (16) 10.5.数据开发工程师 (16) 10.6.数据挖掘工程师 (17)

1.引言 1.1.文档目的 本文档是关于xx公司物联网大平台的总体架构设计方案。本文包括以下容： 1.平台总体架构设计； 2.五大子系统设计； 3.应用平台设计 4.平台部署架构设计； 5.平台运维及团队建设； 1.2.文档围 本文档仅限于xx科技公司部人员和直接协助xx科技进行大平台建设的 相关人员阅读。 1.3.预期的读者及阅读建议 本文档的预期读者： 1.xx科技的大平台项目相关人员； 2.直接协助xx科技进行大平台建设的相关外部人员； 1.4.术语 1.Hadoop: Apache的分布式框架。

软件开发规范之总体设计方案模板

一．引言 1.1编写目的 本文档作为***与XXXXXXXXXX公司之间就***建立XXXX司（局或单位）XXXXXXXXXX系统需求理解达成一致共识的基础文件，作为双方界定项目范围、签定合同的主要基础，也作为本项目验收的主要依据。同时，本文档也作为***XXX后继工作开展的基础，供双方项目主管负责人、项目经理、技术开发人员、测试人员等理解需求之用。 1.2适用范围 本文档适用于所有与本项目有关的软件开发阶段及其相关人员，其中：***方面的项目负责人、公司方项目经理、技术开发人员（包括分析人员、设计人员、程序人员）、测试人员应重点阅读本文档各部分，其他人员可选择性阅读本文档。 1.3文档概述 本文档主要描述了XXXXXXXXXX系统项目的软件总体设计思路。 本文档首先从业务背景、系统功能、运行环境等方面概要描述系统，其次从设计原则、功能设计、数据结构设计等方面描述系统的总体设计情况，然后进一步详细描述系统技术实现策略、项目实施以及待确定的问题。 1.4参考资料 [列出本文的参考文件清单，包括出版单位、作者、版本、日期等信息。]示范：―――仅供参考，不具备任何实质性的内容。 《XXX总体需求书》（XXX单位XXX提供） 《XXX需求调研报告》作者：XXX 《设计模式》XXXXXX出版社 《UML用户指南》XXXXXXX出版社

1.5术语、定义和缩写 [列出本文档所涉及的专业术语、缩写词及相关定义。定义所有必要的术语，以便读者可以正确地解释软件需求规格说明，包括词头和缩写。你可能希望为整个公司创建一张跨越多项项目的词汇表，并且只包括特定于单一项目的软件需求规格说明中的术语。] 示范：―――仅供参考，不具备任何实质性的内容。 1)OLTP：On-line Transaction Processing，联机事务处理。 2)OLAP：On-Line Analytical Processing，联机分析处理；是使分析人员、管 理人员或执行人员能够从多角度对信息进行快速、一致、交互地存取, 从而获得对数据的更深入了解的一类软件技术。 二．总体概述 2.1现有系统描述 [简要描述客户现有系统的功能、性能以及其他方面，若客户没有系统，则可裁减。另外，可描述客户现有系统的应用状况以及系统规模、人员使用状况。描述客户对象的应用环境平台，如软件环境、硬件环境、网络环境、通讯状况以及人员计算机使用水平等。] 示范：―――仅供参考，不具备任何实质性的内容。 针对金融快报工作，***以前曾开发过一个C/S结构的系统，后台数据库为SQL Server，开发工具是VB6.0。该系统主要完成以下工作： 1.根据人行各业务司局每日上报的数据传真，将数据补录到系统中。 2.根据上报的数据制作金融快报文档。 3.将金融快报的数据转发到人行时间序列数据库中。 金融快报系统的工作流程如下： 2.2存在问题 [通过上述现状描述，分析现有组织结构、现有系统等方面存在的问题。]示范：―――仅供参考，不具备任何实质性的内容。

企业大数据案例分析(公司大数据、集团大数据)

企业大数据案例分析

目录 1中国联通大数据平台 (4) 1.1项目概述 (4) 1.2项目实施情况 (5) 1.3项目成果 (10) 1.4项目意义 (11) 2恒丰银行大数据平台 (12) 2.1项目概述 (12) 2.2项目实施情况 (15) 2.3项目成果 (21) 2.4项目意义 (21) 3华通CDN运营商海量日志采集分析系统 (24) 3.1项目概述 (24) 3.2项目实施情况 (24) 3.3项目成果 (28) 3.4项目意义 (28) 4案例总结 (30)

1中国联通大数据平台 联通XX公司公司按照工信部的的要求（见《工业和信息化部、国务院国有资产监督管理委员会关于开展基础电信企业网络与信息安全责任考核有关工作的指导意见》和《工业和信息化部办公厅关于印发<2013年省级基础电信企业网络与信息安全工作考核要点与评分标准>的通知》），于2013年启动IDC/ISP日志留存系统的建设，其中XX 公司侧的集中留存系统软件由联通研究院负责开发。为了满足海量数据条件下的处理效率的要求，XX公司侧集中留存系统软件除研究院自主开发外，基于Hadoop的数据存储部分计划进行外包，通过软件技术服务，来进行系统优化和维护支撑。 1.1项目概述 目前，联通XX公司公司全国IDC出口的访问日志预计两个月产生的数据量约20 PB至30PB，每秒写入大概6千万至7千万条数据，在如此巨大的数据量下，原有Ter adata和Oracle已经不能满足快速读写的性能要求了。同时为了实现快速检索以及分析处理的性能要求，需要引入分布式大数据平台，利用分布式文件存储系统，提高数据的存储入库能力，利用Hadoop/HBase架构克服磁盘I/O瓶颈导致的数据读写延迟；基于联通IDC出口流量详单数据进行快速存储和检索以及分析处理，同样要求数据处理平台具备快速读写的高性能。 中国联通公司全国IDC日至留存项目对分布式集群的要求非常高： (1)日志数据量非常大，存储的总日志数据量将达到20PB-30PB。 (2)要求集群的数据吞吐量非常高，每秒的日志写入量将达到6千万至七千万条，

大数据处理综合处理服务平台的设计实现分析报告

大数据处理综合处理服务平台的设计与实现 （广州城市职业学院广东广州510405） 摘要：在信息技术高速发展的今天，金融业面临的竞争日趋激烈，信息的高度共享和数据的安全可靠是系统建设中优先考虑的问题。大数据综合处理服务平台支持灵活构建面向数据仓库、实现批量作业的原子化、参数化、操作简单化、流程可控化，并提供灵活、可自定义的程序接口，具有良好的可扩展性。该服务平台以SOA为基础，采用云计算的体系架构，整合多种ETL技术和不同的ETL工具，具有统一、高效、可拓展性。该系统整合金融机构的客户、合约、交易、财务、产品等主要业务数据，提供客户视图、客户关系管理、营销管理、财务分析、质量监控、风险预警、业务流程等功能模块。该研究与设计打破跨国厂商在金融软件方面的垄断地位，促进传统优势企业走新型信息化道路，充分实现了“资源共享、低投入、低消耗、低排放和高效率”，值得大力发展和推广。 关键词：面向金融，大数据，综合处理服务平台。 一、研究的意义 目前，全球IT行业讨论最多的两个议题，一个是大数据分析“Big Data”，一个是云计算“Cloud Computing”。

中国五大国有商业银行发展至今，积累了海量的业务数据，同时还不断的从外界收集数据。据IDC（国际数据公司）预测，用于云计算服务上的支出在接下来的5 年间可能会出现3 倍的增长，占据IT支出增长总量中25%的份额。目前企业的各种业务系统中数据从GB、TB到PB量级呈海量急速增长，相应的存储方式也从单机存储转变为网络存储。传统的信息处理技术和手段，如数据库技术往往只能单纯实现数据的录入、查询、统计等较低层次的功能，无法充分利用和及时更新海量数据，更难以进行综合研究，中国的金融行业也不例外。中国五大国有商业银行发展至今，积累了海量的业务数据，同时还不断的从外界收集数据。通过对不同来源，不同历史阶段的数据进行分析，银行可以甄别有价值潜力的客户群和发现未来金融市场的发展趋势，针对目标客户群的特点和金融市场的需求来研发有竞争力的理财产品。所以，银行对海量数据分析的需求是尤为迫切的。再有，在信息技术高速发展的今天，金融业面临的竞争日趋激烈，信息的高度共享和数据的安全可靠是系统建设中优先考虑的问题。随着国内银行业竞争的加剧，五大国有商业银行不断深化以客户为中心，以优质业务为核心的经营理念，这对银行自身系统的不断完善提出了更高的要求。而“云计算”技术的推出，将成为银行增强数据的安全性和加快信息共享的速度，提高服务质量、降低成本和赢得竞争优势的一大选择。

智慧政务数据中心平台总体设计方案

智慧政务数据中心平台总体设计方案

目录 第1章项目整体理解与分析 (2) 1.1项目概述 (2) 1.1.1建设背景 (2) 1.1.2建设目标 (4) 1.1.3建设内容 (5) 1.1.4建设标准 (6) 1.1.5建设原则 (8) 1.2项目建设需求分析 (9) 1.2.1信息化建设现状 (9) 1.2.2信息资源管理现状 (11) 1.2.3存在的主要问题 (12) 1.2.4本期项目建设意义 (13) 1.2.5标准与规范分析 (13) 1.2.6流程与功能分析 (14) 1.2.7用户角色分析 (14) 第2章项目总体设计方案 (16) 2.1数据中心总体架构 (16) 2.2总体标准规范架构 (17) 2.3目录系统业务架构 (18) 2.4目录系统技术架构 (19) 2.5目录系统数据结构 (20)

第1章项目整体理解与分析 1.1 项目概述 1.1.1建设背景 在信息化时代背景下，数据资源的多寡、数据质量的高低直接决定着各类社会主体的运作效率，数据分析应用能力也影响着决策者前面的方向，对数据的全面搜集和有效挖掘利用已经成为当今世界各国信息化建设的重要内容。 智慧城市顶层设计总规中用系统论的方法，以全局视角，明确了全局性的构成要素和体系结构，提出了清晰、协同、可实施的方案。该设计中分政府主导领域和市场主导领域，从市级、部门和区县三个层次，系统地开展全市顶层设计。其中，在政府主导领域，明确由决策分析与公众服务统领全局发展。并以此为依据，出台了数据中心辅助决策平台顶层设计，明确要建立各区县、各行业建设区县数据中心辅助决策平台。 政府也提出加强数据中心工作，在区领导、创新办就多次提出要加强数据整合、共享和分析，支撑领导决策能力，并从多方面已具备了开展数据中心建设的基础。 在理论研究方面，2012年开展了《网格化社会服务管理基础数据架构、信息资源利用模式及服务体系研究》项目，在基础数据架构方面，提出了基于配置开放式基础数据架构设计理念的“三层四区”的基础库总体架构；在信息资源开发利用方面，提出了“四横两纵”的信息资源开发利用框架，设计了“1图（基础地图）、1库（人房关联主题库）、1表（重大事件跟踪表）、1报（民情日报）、1刊（便民服务快刊）、1年鉴（网格化年鉴）”6大数据产品，；在云服务中心服务体系方面，提出了云服务中心内容体系、流程规范、组织架构、运行模式和支撑平台需求，为数据中心决策支持系统建设工作的开展奠定了理论基础，并为其实施提供了指导意见。 在数据资源方面，通过网格化社会服务管理工作，充分利用现有资源，挖掘数据关系，建成了相互关联的人、地、物、组织、房屋、地下空间基础数据库的建设，整合了120多万条基础数据，其中常驻人口953,998条、流动人口220,444

集团公司大数据平台整体建设方案

集团公司大数据平台整体建设方案

目录 1项目概述 (11) 1.1建设背景 (11) 1.1.1集团已有基础 (11) 1.1.2痛点及需提升的能力 (11) 1.1.3大数据趋势 (12) 1.2建设目标 (12) 1.2.1总体目标 (12) 1.2.2分阶段建设目标 (13) 1.3与相关系统的关系 (13) 1.3.1数据分析综合服务平台 (13) 1.3.2量收系统 (14) 1.3.3金融大数据平台 (15) 1.3.4各生产系统 (15) 1.3.5CRM (15) 1.4公司介绍和优势特点 (15) 1.4.1IDEADATA (15) 1.4.2TRANSWARP (17) 1.4.3我们的优势 (18) 2业务需求分析 (21) 2.1总体需求 (21) 2.2数据管理 (22) 2.2.1数据采集 (23) 2.2.2数据交换 (23) 2.2.3数据存储与管理 (23) 2.2.4数据加工清洗 (24) 2.2.5数据查询计算 (24) 2.3数据管控 (25) 2.4数据分析与挖掘 (26)

2.6量收系统功能迁移 (27) 3系统架构设计 (28) 3.1总体设计目标 (28) 3.2总体设计原则 (28) 3.3案例分析建议 (29) 3.3.1中国联通大数据平台 (29) 3.3.2恒丰银行大数据平台 (36) 3.3.3华通CDN运营商海量日志采集分析系统 (48) 3.3.4案例总结 (53) 3.4系统总体架构设计 (54) 3.4.1总体技术框架 (54) 3.4.2系统总体逻辑结构 (57) 3.4.3平台组件关系 (59) 3.4.4系统接口设计 (64) 3.4.5系统网络结构 (68) 4系统功能设计 (70) 4.1概述 (70) 4.2平台管理功能 (70) 4.2.1多应用管理 (70) 4.2.2多租户管理 (74) 4.2.3统一运维监控 (75) 4.2.4作业调度管理 (94) 4.3数据管理 (96) 4.3.1数据管理框架 (96) 4.3.2数据采集 (98) 4.3.3数据交换 (101) 4.3.4数据存储与管理 (102) 4.3.5数据加工清洗 (120) 4.3.6数据计算 (121)

车联网大数据平台架构设计

车联网大数据平台架构设计-软硬件选型 1.软件选型建议 数据传输 处理并发链接的传统方式为：为每个链接创建一个线程并由该线程负责所有的数据处理业务逻辑。这种方式的好处在于代码简单明了，逻辑清晰。而由于操作系统的限制，每台服务器可以处理的线程数是有限的，因为线程对CPU的处理器的竞争将使系统整体性能下降。随着线程数变大，系统处理延时逐渐变大。此外，当某链接中没有数据传输时，线程不会被释放，浪费系统资源。为解决上述问题，可使用基于NIO的技术。 Netty Netty是当下最为流行的Java NIO框架。Netty框架中使用了两组线程：selectors与workers。其中Selectors专门负责client端（列车车载设备）链接的建立并轮询监听哪个链接有数据传输的请求。针对某链接的数据传输请求，相关selector会任意挑选一个闲置的worker线程处理该请求。处理结束后，worker自动将状态置回‘空闲’以便再次被调用。两组线程的最大线程数均需根据服务器CPU处理器核数进行配置。另外，netty内置了大量worker 功能可以协助程序员轻松解决TCP粘包，二进制转消息等复杂问题。 IBM MessageSight MessageSight是IBM的一款软硬一体的商业产品。其极限处理能力可达百万client并发，每秒可进行千万次消息处理。 数据预处理 流式数据处理 对于流式数据的处理不能用传统的方式先持久化存储再读取分析，因为大量的磁盘IO操作将使数据处理时效性大打折扣。流式数据处理工具的基本原理为将数据切割成定长的窗口并对窗口内的数据在内存中快速完成处理。值得注意的是，数据分析的结论也可以被应用于流式数据处理的过程中，即可完成模式预判等功能还可以对数据分析的结论进行验证。 Storm Storm是被应用最为广泛的开源产品中，其允许用户自定义数据处理的工作流（Storm术语为Topology），并部署在Hadoop集群之上使之具备批量、交互式以及实时数据处理的能力。用户可使用任意变成语言定义工作流。 IBM Streams IBM的Streams产品是目前市面上性能最可靠的流式数据处理工具。不同于其他基于Java 的开源项目，Streams是用C++开发的，性能也远远高于其他流式数据处理的工具。另外IBM 还提供了各种数据处理算法插件，包括：曲线拟合、傅立叶变换、GPS距离等。 数据推送 为了实现推送技术，传统的技术是采用‘请求-响应式’轮询策略。轮询是在特定的的时间间隔（如每1秒），由浏览器对服务器发出请求，然后由服务器返回最新的数据给客户端的浏览器。这种传统的模式带来很明显的缺点，即浏览器需要不断的向服务器发出请求，然而HTTP request 的header是非常长的，里面包含的数据可能只是一个很小的值，这样会占用很多的带宽和服务器资源。

(完整)系统总体设计原则汇总,推荐文档

1.1系统总体设计原则 为确保系统的建设成功与可持续发展，在系统的建设与技术方案设计时我们遵循如下的原则：1、统一设计原则统筹规划和统一设计系统结构。尤其是应用系统建设结构、数据模型结构、数据存储结构以及系统扩展规划等内容，均需从全局出发、从长远的角度考虑。 2、先进性原则系统构成必须采用成熟、具有国内先进水平，并符合国际发展趋势的技术、软件产品和设备。在设计过程中充分依照国际上的规范、标准，借鉴国内外目前成熟的主流网络和综合信息系统的体系结构，以保证系统具有较长的生命力和扩展能力。保证先进性的同时还要保证技术的稳定、安全性。 3、3、高可靠/高安全性原则系统设计和数据架构设计中充分考虑系统的安全和可靠。 4、4、标准化原则系统各项技术遵循国际标准、国家标准、行业和相关规范。 5、5、成熟性原则系统要采用国际主流、成熟的体系架构来构建，实现跨平台的应用。 6、6、适用性原则保护已有资源，急用先行，在满足应用需求的前提下，尽量降低建设成本。 7、7、可扩展性原则信息系统设计要考虑到业务未来发展的需要，尽可能设计得简明，降低各功能模块耦合度，并充分考虑兼容性。系统能够支持对多种格式数据的存储。 1.2业务应用支撑平台设计原则 业务应用支撑平台的设计遵循了以下原则：1、遵循相关规范或标准遵循J2EE、XML、JDBC、EJB、SNMP、HTTP、TCP/IP、SSL等业界主流标准2、采用先进和成熟的技术系统采用三层体系结构，使用XML规范作为信息交互的标准，充分吸收国际厂商的先进经验，并且采用先进、成熟的软硬件支撑平台及相关标准作为系统的基础。3、可灵活的与其他系统集成系统采用基于工业标准的技术，方便与其他系统的集成。4、快速开发/快速修改的原则系统提供了灵活的二次开发手段，在面向组件的应用框架上，能够在不影响系统情况下快速开发新业务、增加新功能，同时提供方便地对业务进行修改和动态加载的支持，保障应用系统应能够方便支持集中的版本控制与升级管理。5、具有良好的可扩展性系统能够支持硬件、系统软件、应用软件多个层面的可扩展性，能够实现快速开发/重组、业务参数配置、业务功能二次开发等多个方面使得系统可以支持未来不断变化的特征。6、平台无关性系统能够适应多种主流主机平台、数据库平台、中间件平台，具有较强的跨系统平台的能力。7、安全性和可靠性系统能保证数据安全一致，高度可靠，应提供多种检查和处理手段，保证系统的准确性。针对主机、数据库、网络、应用等各层次制定相应的安全策略和可靠性策略保障系统的安全性和可靠性。8、用户操作方便的原则系统提供统一的界面风格，可为每个用户群，包括客户，提供一个一致的、个性化定制的和易于使用的操作界面。 9、应支持多CPU的SMP对称多处理结构 1.3共享交换区数据库设计原则 1.统一设计原则为保证数据的有效性、合理性、一致性和可用性，在全国统一设立交换资源库基本项目和统一编码的基础上，进行扩展并制定统一的交换资源库结构标准。 2.有效提取原则既要考虑宏观决策需要，又要兼顾现实性，并进行业务信息的有效提取，过滤掉生产区中的过程性、地方性数据，将关键性、结果性数据提交集中到交换区数据库中。 3.保证交换原则统一设计数据交换接口、协议、流程和规范，保证数据通道的顺畅。 4.采用集中与分布式相结合的系统结构根据XX电子政务网络发达，地区经济差异性等特点，交换区采用集中与分布式相结合的数据库系统结构，并逐步向大型集中式数据库系统过渡。这些与外部系统交换的数据也需要从生产区数据得到，也就是说需要XXXX数据和各XXXX

大数据中心建设总体要求

实用标准文档 数据中心建设总体要求 中信北京国安电气责任有限公司二○一二年四月二十六日

一、建设环境要求 数据中心大楼或具有数据中心功能要求的办公大楼建设位置、周边环境应符合下列要求： 1、电力供给应稳定可靠，交通通信应便捷，自然环境应清洁； 2、应远离产生粉尘、油烟、有害气体以及生产或贮存具有腐蚀性、易燃、易爆物品的场所； 3、远离水灾火灾隐患区域； 4、远离强振源和强噪声源； 5、避开强电磁场干扰； 6、距离停车场不小于10m； 7、距离铁路或高速公路的距离不小于100m； 8、距离飞机场不小于1600m； 9、距离化学工厂中的危险区域、垃圾填埋场不小于400m； 10、距离军火库不小于1600m； 11、距离核电站的危险区域不小于1600m； 12、有可能发生洪水的地区不应设置机房； 13、地震断层附近或有滑坡危险区域不应设置机房。 当无法满足上述要求时，可采取必要措施加以解决，必要时更换建设地点。 二、数据中心对建筑与结构的要求

1、抗震设防分类不应低于丙类（地震作用和抗震措施均应符合本地区抗震设防烈度的要求）； 2、耐火等级不低于二级； 3、屋面的防水等级Ⅰ； 4、拟确定数据中心建设的区域，可不进行物理分割； 5、根据数据中心的特殊性，考虑到今后机房的扩容和调整，数据中心机房层承载不小于1000公斤/平方米，UPS电池间如设置在楼上，承载要求不小于1600公斤/平方米； 6、拟确定机房建设的区域，地面应做找平处理，地面和顶面应做防水和保温处理； 7、拟确定机房建设的区域，应满足设备进出的要求（走廊、货梯、门的尺寸不小于1500*2100）； 8、拟确定机房建设的区域可做无窗设计； 9、拟确定机房建设区域的核心筒（电梯厅）平面高于本层平面400mm以上，以保证抗静电活动地板铺设后无高差； 10、大楼层高，应保证梁下高度不低于3.5米； 11、建筑物要有空调和新风机室外机安装位置，楼顶应为平顶设计； 12、与机房建设区域无关的给排水管道不得穿越主机房，临近上下楼层禁止有商场、饭店、食堂等易产生人员、气体、水源影响的隐患，机房不应设在水泵房、厕所和浴室等潮湿场所的正下方或贴邻布置；

系统总体设计原则信息化项目

1.1 系统总体设计原则 为确保系统的建设成功与可持续发展，在系统的建设与技术方案设计时我们遵循如下的原则： 1、统一设计原则统筹规划和统一设计系统结构。尤其是应用系统建设结构、数据模型结构、数据存储结构以及系统扩展规划等内容，均需从全局出发、从长远的角度考虑。 2、先进性原则系统构成必须采用成熟、具有国内先进水平，并符合国际发展趋势的技术、软件产品和设备。在设计过程中充分依照国际上的规范、标准，借鉴国内外目前成熟的主流网络和综合信息系统的体系结构，以保证系统具有较长的生命力和扩展能力。保证先进性的同时还要保证技术的稳定、安全性。 3、高可靠/高安全性原则系统设计和数据架构设计中充分考虑系统的安全和可靠。 4、标准化原则系统各项技术遵循国际标准、国家标准、行业和相关规范。 5、成熟性原则系统要采用国际主流、成熟的体系架构来构建，实现跨平台的应用。 6、适用性原则保护已有资源，急用先行，在满足应用需求的前提下，尽量降低建设成本。 7、可扩展性原则信息系统设计要考虑到业务未来发展的需要，尽可能设计得简明，降低各功能模块耦合度，并充分考虑兼容性。系统能

够支持对多种格式数据的存储。 1.2 业务应用支撑平台设计原则 业务应用支撑平台的设计遵循了以下原则： 1、遵循相关规范或标准遵循J2EE、XML、JDBC、EJB、SNMP、HTTP、TCP/IP、SSL 等业界主流标准 1 / 13 2、采用先进和成熟的技术系统采用三层体系结构，使用XML 规范作为信息交互的标准，充分吸收国际厂商的先进经验，并且采用先进、成熟的软硬件支撑平台及相关标准作为系统的基础。 3、可灵活的与其他系统集成系统采用基于工业标准的技术，方便与其他系统的集成。 4、快速开发/快速修改的原则系统提供了灵活的二次开发手段，在面向组件的应用框架上，能够在不影响系统情况下快速开发新业务、增加新功能，同时提供方便地对业务进行修改和动态加载的支持，保障应用系统应能够方便支持集中的版本控制与升级管理。 5、具有良好的可扩展性系统能够支持硬件、系统软件、应用软件多个层面的可扩展性，能够实现快速开发/重组、业务参数配置、业务功能二次开发等多个方面使得系统可以支持未来不断变化的特征。 6、平台无关性系统能够适应多种主流主机平台、数据库平台、中间件平台，具有较强的跨系统平台的能力。 7、安全性和可靠性系统能保证数据安全一致，高度可靠，应提供多