数据采集处理项目技术方案

1、精选优质文档-倾情为你奉上精选优质文档-倾情为你奉上专心-专注-专业专心-专注-专业精选优质文档-倾情为你奉上专心-专注-专业xxx大数据库中心数据库投资商和企业数据采集处理项目项目编号：技术方案xxx有限公司 二一七年六月目 录 TOC o 1-3 h z u 1 引言1.1 项目背景XXX大数据中心建设出发点考虑从投资者角度涵盖招商全流程，尽可能为投资者解决项目实施过程中的困难和问题，便于招商部门准确掌握全省招商数据，达到全省招商项目数据共享，形成全省招商工作“一盘棋、一张网、一体化”格局。大数据中心将充分发挥大数据优势，加强对企业投资项目、投资轨迹分析，评估出其到XX投资的可行性，为招商

2、过程留下痕迹、找到规律、明辨方向、提供“粮食”、提高效率，实现数据寻商、数据引商、数据助商，实现数据资源实时共享、集中管理、随时查询，实现项目可统计、可监管、可协调、可管理、可配对、可跟踪、可考核。本次数据运营服务主要是为大数据平台制定数据运营规范及管理办法 ，同时为“企业数据库”提供数据采集、存储与分析服务，并根据运营规范要求持续开展数据运营服务。1.2 项目目标?制定招商大数据运营规范及管理办法。?制定招商大数据相关元数据标准，完成相关数据的采集、整理与存储。?根据业务需求，研发招商大数据招商业务分析模型，并投入应用。?根据运营规范及管理办法的要求持续开展数据运营工作。1.3 建设原则基于

3、本项目的建设要求，本项目将遵循以下建设原则：?前瞻性和高标准 整个项目要按照企业对大数据应用的需要的高要求和高标准建设，参考行业标杆应用，建立满足需求，面向未来的目标，整个项目具有一定前瞻性。?经济性和实用性 整个项目以现有需求为基础，充分考虑未来发展的需要来确定系统的架构，既要降低系统的初期投入，又能满足服务对象的需求，同时系统设计应充分考虑对已有投资的保护，对已建立的数据中心、基础平台、应用软件应提供完备的整合方案。?先进性和成熟性 为了确保项目具有较长的生命周期，应充分考虑到管理创新、技术发展需要，按照先进的建设理念，选择先进的技术架构和成熟技术，满足业务需求。?高性能和安全性 规范地进

4、行系统建设和开发，提供合理且经济有效的应急方案，确保系 统的稳定，向各类服务对象提供可靠的服务。具有安全性，在系统遭到攻击或崩溃时能快速恢复，确保重要数据的机密性和完整性。1.4 参考规范?GB/T 20269-2006 信息安全技术信息系统安全管理要求?GB/T 20984-2007 信息安全技术信息安全风险评估规范?GB/T 22239-2008 信息安全技术信息系统安全等级保护基本要求?GB/T 22240-2008 信息安全技术信息系统安全等级保护定级指南?GA/T 388-2002B 计算机信息系统安全等级保护管理要求?GB/T 8567 -1988 计算机软件产品开发文件编制指?G

5、B/T 11457-1995 软件工程术语?GB/T 11457-2006 信息技术 软件工程术语?GB/T 16260.1-2006 软件工程 产品质量 第 1 部分:质量模型?GB/T 16260.2-2006 软件工程 产品质量 第 2 部分:外部度量?GB/T 16260.3-2006 软件工程 产品质量 第 3 部分:内部度量?GB/T 16260.4-2006 软件工程 产品质量 第 4 部分:使用质量的度量?GB/T 14394-2008 计算机软件可靠性和可维护性管理?GB/T 17544-1998 信息技术 软件包 质量要求和测试1.5 名词解释S2DFS：简单存储分布式文件

6、系统（Simple Storage Distributed File System）D2B:分布式数据库（Distributed Database）JSS：作业调度服务（Job Scheduler Service）DCS：数据计算服务（Data Computer Service）MPS：消息处理服务（Message Process Service）SDS：流数据处理服务（Stream Data Service）DMQ：分布式消息队列（Distributed Message Queue）JGS：作业生成服务（Job Generation Service）ACS：自动清理服务进程（Automati

7、c Cleaning Services）HTTP：超文本传输协定（HyperText Transfer Protocol）SMB：服务器信息块协议（Server Message Block）2 云数据采集中心2.1 需求概述根据规划，云数据采集中心的建立至少满足 1 至 2 年内的 数据存储和计算规模，需要满足： 数据采集范围包括但不限于世界500强、全国500强、行业20强企业相关数据。 总数据容量至少达到30T。2.2 总体设计整个云数据采集中心分为三部分：硬件资源层、软件平台层、软件应用层。硬件资源层主要指实体硬件设备，包括用来存储数据的光纤阵列柜和存储服 务器，用来作统计、分析以及搜索

8、用的计算服务器，用来部署分布式消息（DMQ）/WEB/APP 软件的 WEB 及消息服务器，用来部署用 PostgreSQL 关系数据库软件的应用数据库服务器，用来部署作业调度服务进程（JSS）的作业调度服务器。 作为数据通信用的全千兆三层交换机等等。其中光纤阵列柜主要用来存储统计分 析后的粗颗粒度数据。存储服务器用来部署分布式文件系统和分布式数据库，同 时存储非结构化和结构化（台标图片，电商图片等等）和结构化数据（行为数据， 索引数据，log 数据，清理后的细颗粒度数据等等）。计算服务器主要用来完成数 据的清理、统计、搜索等计算任务。为了节省成本和减少通信代价，建议存储服务器和计算服务器合二

9、为一，所以该服务器同时具有计算和存储数据的功能，前 期也可以考虑把作业调度服务进程（JSS）进程部署在存储/计算服务器上。由于 云数据采集中心需要面对多种宽带用户（电信、移动、联通），所以，数据中心 的对外的网络需要直连上电信、移动、联通三家公司的网络，保证以上三家公司间的通信性能高速和可靠。软件平台层是云数据采集中心的核心支撑层，也是我们这次方案设计和实施的主体部分，在核心技术章节会对“分布式文件系统（S2DFS）”、“分布式数 据库（D2B）”、“分布式消息服务（DMQ）”“作业调度服务进程（JSS）、数 据计算服务进程（DCS）”主要部分加以详细的描述。软件平台层的所有服务器都统一部署的

10、 64 位操作系统 CentOS 6.5（也可以选择 RHEL 6.5 x64）；其核心软 件或者进程有：分布式文件系统（S2DFS）、分布式数据库（D2B）、作业调度服 务进程（JSS）、数据计算服务进程（DCS）、作业生成服务进程（JGS）、消息处 理服务进程（MPS）、流数据处理进程（SDS）等等。WEB 及应用服务器软件 Apache&Tomcat，消息队列软件分布式消息（DMQ）。还要实现整个云数据采集 中心的资源管理及监控管理系统。软件应用层是云数据采集中心的功能实现及 UI 表达层，功能实现需要基于 软件平台层的支撑，后期设计和实施的主体。该层的主要功能应用有：数据采集应用、数据

11、统计应用、云数据采集中心的资源监控及调度。通过公共数据网（电信、联通、移动）和 HTTP 协议，把采集的海量文本、图片数据以及用户行为数据存储在云数据采集中心里，以供后期分析计算用。 云数据采集中心整体架构图云数据采集中心网络结构图2.3 核心技术及功能2.3.1 分布式文件存储技术（1） 传统存储技术面临的问题：?构建成本高：大容量及高网络带宽的高端存储系统架构昂贵。?文件系统功能和性能差强人意：难以实现全局命名空间的文件共享、 文件系统难以扩展，容易形成瓶颈。?扩展性困难：技术存在瓶颈（Scale-up 架构决定的）、扩展成本无法 控制。?可用性问题：潜在的单点故障,数据恢复困难，代价高。

12、?应用目标差异：主要面临运营商、金融行业的 OLTP 应用、很少针 对海量的流数据，或者非结构化数据进行设计和优化。?异构设备繁杂：不同时期、不同公司、不同操作系统的异构设备纷 繁复杂，无法整合，资源利用率极低。分布式文件系统主要为解决以上问题而出现的一种新型大规模数据存储技 术架构。主要为非结构化数据（视频/文件/文档/图像/音频等非结构化数据）提 供海量的存储平台，以集群的方式提供线性横向扩展能力。分布式文件系统是一种构建于通用 x86 部件之上的高可用、高可靠、高可扩 展的新型分布式文件系统。应用分布式文件系统，用户可以采用廉价可靠的通用 服务器、SATA/SAS 硬盘以及以太网络来构建

13、媲美企业级存储产品的存储系统。（2） 分布式文件系统应对的数据特性和访问特性：?数据量巨大，数百 TB 或 PB 级，增长迅速；?类型多样化，包括图像、文本、语音、视频等文件数据；?按时间有序生成，数据均带有时间标志 ；?前端数据写入速度很高，每秒钟写入数据可达几万甚至几十万条记 录或者上 GB 量数据 ；?更新操作极少：追加方式写入，一旦写入，几乎没有数据修改，查 询涉及大量的磁盘读操作，查询处理产生大量的临时结果，不同类 型的数据存在联合分析查询；分布式文件系统的基本原理是采用集群方式来整合物理上独立的多个存储 资源，以软件方式提供单一的名字空间；采用多副本的方式保证数据的高可用性， 任意

14、单一节点失效均不会导致数据丢失和数据服务的正常运行；同时，分布式文 件系统通过良好设计的系统结构和数据分布策略，可保证系统性能的高可扩展性， 并支持存储容量/性能的在线扩展。相比较于 DAS（直连存储）、SAN（存储区域网络）和 NAS（网络存储）， 应用分布式文件系统构建的网络存储系统更像是一个 NAS，提供类似于传统 NAS 的文件级访问接口（SAN 和 DAS 都是块设备级别的访问接口）。（3） 分布式文件系统与传统 NAS/SAN 设备的比较：比较项高端 NASFC-SAN分布式文件系统性能一般双端口，性能受机头影响，难以扩展，出口带 宽是瓶颈一般双端口，性能受机头影响，难以扩展， I

15、OPS 较好性能随节点数的增加成线性增长扩展能力性能及容量无法扩展，或者有限扩展能较好扩展，但成本高昂性能及容量按需扩展，动态均衡可用性RAID 方式保护， 双机保护，停机 RAID Rebuid，耗 时RAID 方式保护，双机保 护 ， 停 机 RAID Rebuid，耗时基于灵活的多副本机制，自动检测，自动故障恢复， 无需停机数据管理企业级功能需要单独购买企业级功能需要单独购买（还需要单独的文件系统，100 多万一套）内嵌多种企业级应用：快照、镜像、回收站成本专有的硬件平台，软件拥有成本高，扩展成本高专有的硬件平台，软件拥有成本高，扩展 成本高开发通用的硬件平台，一体化的软件，成本低，扩

16、展成本低可维护性专门的技术支持服务，需要培训结构异常复杂，需要大量培训，厂商服务 昂贵内嵌多种自动化的故障检测和恢复功能，国内开发， 技术支持快速用户使用分布式文件系统如同使用本地文件系统。所不同的是，传统 NAS 通常以单一节点的方式实现，容量和性能的扩展能力有限，易于成为性能瓶颈和 单一故障点。而分布式文件系统则有多个节点集合地提供服务，由于其结构特征， 分布式文件系统的性能和容量均可在线线性扩展，并且系统内不存在单一故障点。 对比参看下面两幅示意图：传统存储架构图分布式文件系统架构图分布式文件系统的设计应用特别适合海量非结构化数据存储，大量客户端并发的 I/O 密集型应用。目前，分布式文

17、件系统已经被应用于政府、医疗影像、 勘查数据计算、视频服务以及动画制作等领域。这些领域的数据访问特征均为： 数据量巨大，I/O 吞吐率高，数据增长迅速以及数据可用性要求高。经过长时间 的实际生产环境使用，分布式文件系统已被证明是该类型应用的有效解决方案。布式文件系统的服务器端程序运行于 Linux x64 系统之上，支持多种 Linux64 位发行版，包括 Redhat、CentOS 等。分布式文件系统客户端则支持 Linux 和 Windows，同时分布式文件系统还可以通过第三方软件输出 CIFS 和 NFS 接口， 可以兼容大多数应用。（4） 分布式文件系统的核心技术及特征：?扩展性和高性

18、能：分布式文件系统利用双重特性来提供几 TB 至数 PB 的高扩展存储解决方案。Scale-Out 架构允许通过简单地增加资源 来提高存储容量和性能，磁盘、计算和 I/O 资源都可以独立增加， 支持 10GbE 和 InfiniBand 等高速网络互联。分布式文件系统弹性哈 希（Elastic Hash）解除了分布式文件系统对元数据服务器的需求， 消除了单点故障和性能瓶颈，真正实现了并行化数据访问。?高可用性：分布式文件系统可以对文件进行自动复制，如镜像或多 次复制，从而确保数据总是可以访问，甚至是在硬件故障的情况下 也能正常访问。自我修复功能能够把数据恢复到正确的状态，而且 修复是以增量的方

19、式在后台执行，几乎不会产生性能负载。分布式 文件系统没有设计自己的私有数据文件格式，而是采用操作系统中 主流标准的磁盘文件系统（如 XFS/EXT4/ZFS）来存储文件，因此 数据可以使用各种标准工具进行复制和访问。?全局统一命名空间：全局统一命名空间将磁盘和内存资源聚集成一 个单一的虚拟存储池，对上层用户和应用屏蔽了底层的物理硬件。 存储资源可以根据需要在虚拟存储池中进行弹性扩展，比如扩容或 收缩。当存储虚拟机映像时，存储的虚拟映像文件没有数量限制， 成千虚拟机均通过单一挂载点进行数据共享。虚拟机 I/O 可在命名 空间内的所有服务器上自动进行负载均衡，消除了 SAN 环境中经常 发生的访问

20、热点和性能瓶颈问题。?弹性哈希算法：分布式文件系统采用弹性哈希算法在存储池中定位 数据，而不是采用集中式或分布式元数据服务器索引。在其他的 Scale-Out 存储系统中，元数据服务器通常会导致 I/O 性能瓶颈和单 点故障问题。分布式文件系统中，所有在 Scale-Out 存储配置中的存 储系统都可以智能地定位任意数据分片，不需要查看索引或者向其 他服务器查询。这种设计机制完全并行化了数据访问，实现了真正 的线性性能扩展。?弹性卷管理：数据储存在逻辑卷中，逻辑卷可以从虚拟化的物理存，不会导致应用中断。逻辑卷可以在所有配置服务器中增长和缩减，可以在不同服务器迁移进行容量均衡，或者增加和移除系统

21、， 这些操作都可在线进行。文件系统配置更改也可以实时在线进行并 应用，从而可以适应工作负载条件变化或在线性能调优。?完全软件实现（Software Only）：分布式文件系统认为存储是软件问 题，不能够把用户局限于使用特定的供应商或硬件配置来解决。分 布式文件系统采用开放式设计，广泛支持工业标准的存储、网络和 计算机设备，而非与定制化的专用硬件设备捆绑。对于商业客户， 分布式文件系统可以以虚拟装置的形式交付，也可以与虚拟机容器 打包，或者是公有云中部署的映像。开源社区中，分布式文件系统 被大量部署在基于廉价闲置硬件的各种操作系统上，构成集中统一 的虚拟存储资源池。简而言之，分布式文件系统是开放

22、的全软件实 现，完全独立于硬件和操作系统。完整的存储操作系统栈（Complete Storage Operating System Stack：分 布式文件系统不仅提供了一个分布式文件系统，而且还提供了许多 其他重要的分布式功能，比如分布式内存管理、I/O 调度、软 RAID 和自我修复等。分布式文件系统汲取了微内核架构的经验教训，借 鉴了 GNU/Hurd 操作系统的设计思想，在用户空间实现了完整的存 储操作系统栈。?用户空间实现（User Space）：与传统的文件系统不同，分布式文件系 统在用户空间实现，这使得其安装和升级特别简便。模块化堆栈式架构（Modular Stackable A

23、rchitecture）：分布式文件系统 采用模块化、堆栈式的架构，可通过灵活的配置支持高度定制化的 应用环境，比如大文件存储、海量小文件存储、分布式文件系统、 多传输协议应用等。每个功能以模块形式实现，然后以积木方式进 行简单的组合，即可实现复杂的功能。比如，Replicate 模块可实现 RAID1，Stripe 模块可实现 RAID0，通过两者的组合可实现 RAID10 和 RAID01，同时获得高性能和高可靠性。原始数据格式存储（Data Stored in Native Formats）：分布式文件系统 以原始数据格式（如 EXT3、EXT4、XFS、ZFS）储存数据，并实现 多种数

24、据自动修复机制。因此，系统极具弹性，即使离线情形下文 件也可以通过其他标准工具进行访问。如果用户需要从分布式文件 系统中迁移数据，不需要作任何修改仍然可以完全使用这些数据。无元数据服务设计（No Metadata with the Elastic Hash Algorithm）：对 Scale-Out 存储系统而言，最大的挑战之一就是记录数据逻辑与物理 位置的映像关系，即数据元数据，可能还包括诸如属性和访问权限 等信息。传统分布式存储系统使用集中式或分布式元数据服务来维 护元数据，集中式元数据服务会导致单点故障和性能瓶颈问题，而 分布式元数据服务存在性能负载和元数据同步一致性问题。特别是 对于

25、海量小文件的应用，元数据问题是个非常大的挑战。分布式文 件系统独特地采用无元数据服务的设计，取而代之使用算法来定位，服务器都可以智能地对文件数据分片进行定位，仅仅根据文件名 和路径并运用算法即可，而不需要查询索引或者其他服务器。这使 得数据访问完全并行化，从而实现真正的线性性能扩展。无元数据 服务器极大提高了分布式文件系统的性能、可靠性和稳定性。?基于标准协议：分布式文件系统存储服务支持 NFS, CIFS, HTTP, FTP 以及分布式文件系统原生协议，完全与 POSIX 标准兼容。（5） 分布式文件系统技术及性能指标：?支持设备数量：最大百万台以上?支持存储容量：最大 1024PB 以上

26、?客户端的数量：最大支持上亿并发网络支持：以太网：1Gbps、10Gbps/INFINIBAND：10Gbps、40Gbps?文件副本数量：任意(缺省 1 份)协议： NFS/CIFS/HTTP/FTP/WEB DAV，及原生协议,兼容 POSIX 标准?支持文件数量：最大上亿个文件?最大单个文件：16TB（6） S2DFS 与 HDFS 的比较对比项HDFS（GFS）S2DFS架构类型带元数据库中心架构(瓶颈及故障易发生点)全分布式去中心架构存在方式分布式文件系统软件，基于 x86 平台使用方式CLI/REST APINATIVE CLIENT/CIFS/NFS 标准协议（应用代码与平台无关

27、性，便于移植和维护）系统可用性低高数据可用性复制类 RAID数据定位方式INodeHash同步方式异步同步负载均衡自动自动支持网络千兆以太网千兆/万兆以太网，IB 网网络写：读（万兆/单流）约 100MB/s：160MB/s约 800MB/s：1000MB/s读（1*20GB）（万兆）约 125s约 25s写（1*20GB）（万兆）约 200s约 20s读/写（千兆）差距不大2.3.2 分布式并行计算技术（1） 概述 并行计算技术真正将传统运算转化为并行运算，从而更加充分的利用广泛部署的普通计算资源实现大规模的运算和应用的目的，在此基础上为第三方开发者 提供通用平台，为客户提供并行服务。这里主

28、要为门户网站提供作业调度平台， 实现日志分析，性能优化，全文检索，视频处理，用为分析等等的支撑平台。用户通过统一计算平台把任务分派给系统内的多个节点，调度节点资源执行 任务，发挥多核并行处理优势，提升运算效率，充分运用网络内的计算资源达到 解决大规模计算问题的目的。（2） 分布式并行计算架构图分布式并行计算架构图（3） 作业调度及计算过程（4） 分布式并行计算技术特点?池化资源管理 利用池化技术，任何一台联在互联网上的普通 PC 机从硬件到软件，可通过池化技术加入服务器池中，等待任务分配,系统能充分利用现 有服务器资源，将所有运算子任务分配给节点服务器，有效避免计 算资源闲置现象的发生。?无中

29、心系统架构 在平台管理下的单节点能力一致，使节点在部署上和使用上具备无 差别性，任一节点功能可由其他节点替代或强化，可以最大程度确 保平台资源使用的灵活性以及在灾备环境下的可靠性系统架构。?通道式工作机制 平台为用户提供一个并行任务处理通道，处理过程对用户来说完全 透明，由平台自动进行负载均衡、资源匹配、任务传输等，使用户 专注于自身任务管理，将执行过程交由平台完成。2.3.3 分布式数据库技术D2B 是一个 具有高性能的 高性能，可扩展，无模式，面向文档(document-oriented)的数据库，其内存储的是一种 JSON-like 结构化数据的分布式 数据库软件，尤其具有高扩展性和高可

30、靠性，支持大表水平折分，以及分区镜像。 提供内存缓存数据，所以数据存取速度非常快，主要是由于它处理写入的方式： 它们存储在内存中，然后通过后台线程写入磁盘。该软件支持的数据结构非常松散，是类似 json 的 bjson 格式，因此可以存储 比较复杂的数据类型。D2B 另外的最大的特点是他支持的查询语言非常强大，其 语法有点类似于面向对象的查询语言，几乎可以实现类似关系数据库单表查询的 绝大部分功能，而且还支持对数据建立索引。它的特点是高性能、易部署、易使 用，存储数据非常方便。主要功能特性：?面向集合存储，易存储对象类型的数据“面向集合”（Collenction-Oriented），意思是数据

31、被分组存储在数据集 中，被称为一个集合（Collenction)。每个 集合在数据库中都有一个唯一 的标识名，并且可以包含无限数目的文档。集合的概念类似关系型数据 库（RDBMS）里的表（table），不同的是它不需要定义任何模式（schema)。?模式自由模式自由（schema-free)，意味着对于存储在 D2B 数据库中的文件，我们 不需要知道它的任何结构定义。如果需要的话，你完全可以把不同结构 的文件存储在同一个数据库里。?自动分片以支持云级别的伸缩性：自动分片功能支持水平的数据库集群， 可动态添加额外的机器。?支持动态查询?支持完全索引，包含内部对象。?自动处理碎片，以支持云计算层次

32、的扩展性。?可通过网络访问 可用于 Windows?、Mac OS X、Linux? 和 Solaris 的官方二进制版本。 可用于 C、C#、C+、Haskell、Java?、JavaScript、Perl、PHP、Python、 Ruby 和 Scala 的官方驱动程序，以及广泛可用于其他语言的社区支持 的驱动程序。?Ad-hoc JavaScript 查询让您能够使用基于任何文档属性的任何条件来查 找数据。这些查询对应于 SQL 查询的功能，使 SQL 开发人员能够很 直观地编写 D2B 查询。?支持查询中的正则表达式。? D2B 查询结果存储在提供过滤、聚合和排序等一系列功能的游标中，

33、包 括 limit()、skip()、 sort()、count()、 distinct() 和 group()等等高级特性。 高级聚合的 map/reduce 实现。? 类似于 RDBMS 的属性索引支持，可以直接在文档的选定属性上创建索引。?使用提示、解释计划和分析的查询优化特性。?类似于 MySQL 的主/从复制，支持复制和故障恢复。?基于集合的对象存储，在需要规范化数据时允许参考查询。?通过自动分片功能水平扩展。?高性能无争用并发机制的即时更新。D2B 服务端可运行在 Linux、Windows 或 OS X 平台，支持 32 位和 64 位应 用。推荐运行在 64 位平台，因为 D2

34、B 在 32 位模式运行时支持的最大文件尺寸 为 2GB。分布式数据库（D2B） 集群示例图 D2B 与关系型数据库的逻辑结构对比:D2B关系型数据库数据库(database)数据库(database)集合(collection)表(table)文档(document)行(row)D2B 的性能指标：10 亿约 600GB 以上（与每条记录大小有关系，这里的数据：1Kb/条）写（1 亿,无索引）约 15000-20000 条/s写（1 亿,有索引）约 10000 条/s写（1 亿：Replica Sets + Sharding 模式）约 6000-8000 条/s读（1 亿）约 80MB-12

35、0MB/s读（1 亿）8000-10000 个查询/s统计一个值（10 亿）1024（理论上）测试环境的硬件配置：Intel Xeon E7-8837 2 路 16 核心,256GB 内存，15k SAS 16*600GB硬盘，RAID50；总共 12 台设备；D2B 的架构模式：Replica Sets + Sharding。2.3.4 负载均衡1)开源负载均衡软件比较LVSNginxHAProxyLVS（Linux Virtual Server）可以实 现Linux平台下的负载均衡, 提供 了含有三种IP负载均衡技术的IP 虚拟服务器软件IPVS、基于内容请 求分发的内核Layer-7交换

36、机 KTCPVS和集群等功能Nginx是一款轻量级、高可用性的 Web服务软件及反向代理软件，基 于HTTP（第七层）应用代理服务 器。在国内大型的互联网公司都有 使用。HAProxy是一款提供高可用性的 基于TCP（第四层）和HTTP（第 七层）应用的代理软件。在国内大 型的互联网公司都有使用。1、抗负载能力强、是工作在网络4 层之上仅作分发之用，没有流量的 产生，这个特点也决定了它在负载 均衡软件里的性能最强的；2、配置性比较低，这是一个缺点 也是一个优点，因为没有可太多配 置的东西，所以并不需要太多接 触，大大减少了人为出错的几率；3、工作稳定，自身有完整的双机 热备方案，如LVS+Ke

37、epalived和 LVS+Heartbeat；4、无流量，保证了均衡器IO的性 能不会收到大流量的影响；5、软件本身不支持正则处理，不 能做动静分离；1、工作在网络的7层之上，可以针 对http应用做一些分流的策略，比 如针对域名、目录结构，它的正则 规则比HAProxy更为强大和灵活；2、Nginx对网络的依赖非常小，理 论上能ping通就就能进行负载功 能；3、Nginx安装、配置、维护比较简 单；4、可以承担高的负载压力且稳定， 一般能支撑超过几万次的并发量；5、Nginx可以通过端口检测到服务 器内部的故障，不支持url来检测；6、Nginx也可作为Web反向加速缓 存器；1、能够补

38、充Nginx的一些缺点比如 Session的保持，Cookie的引导等工 作；2、HAProxy对网络的依赖非常小， 理论上能ping通就就能进行负载 功能；3、它跟LVS一样，本身仅仅就只 是一款负载均衡软件；单纯从效率 上来讲HAProxy更会比Nginx有更 出色，在并发处理上也是优于 Nginx；4、HAProxy安装、配置、维护比 较简单；5、可以承担高的负载压力且稳定， 一般能支撑超过几万次的并发量；建议用 Nginx（或者 HAProxy）作为负载均衡（反向代理）软件配合硬件负 载均衡使用。究竟选择 Nginx 还是 HAProxy 要看团队对这两种软件的熟悉程度， 越熟悉，就能

39、容易掌控，减少风险，我们团队对 Nginx 非常熟悉，所以，这里我们推荐用 Nginx 作为软件的反向代理工具。2.3.5 数据采集1)概述数据采集功能主要完成海量数据采集、上传。 数据采集的来源有： 国家工商局、企业网站、百度、谷歌等。根据特定的数据源，不同应用，不同类型 的数据进行收集，并提供统一的数据采集方式，方便后台数据集成、数据存储。 数据采集结构图：数据采集主要是由采集服务器，通过 HTTP 协议和 Restful 技术把数据上传并缓存在 WEB 及消息服务器上，WEB 及消息服务器可以缓存一周的数据上传 量，数据上传后，再由消息处理服务进程（MPS）进程完成数据的最终清洗及格 式

40、，并最终入库存储。台标等非结构化数据存储在分布式文件系统（S2DFS）中， log 或者行为等结构化数据存储在分布式数据库（MongonDB）中。参见如下数 据采集/存储流程图：DMQ 是一个分布式的消息服务平台，提供的功能包括：配置维护、名字服 务、分布式同步、组服务等，能提供一种高性能、可靠的、可扩展的、分布式的、 可配置关键特性，DMQ 的核心技术特点：?大容量堆内存和高可用性：假设你有 100 台服务器, 并且每个节点有 2GB 的空间用于复制缓存,最终你获得的总数据量的大小为 200GB， 每台服务器仅仅是一个拷贝。相反，借助于分布式复制架构，可获得 100GB 的备份虚拟堆内存，并

41、且在网格中的任何位置都能访问。如果 某台服务器崩溃了, 网格只需要简单地创建一份丢失数据的新副本， 并将它们放到另一台服务器上。应用也无需再借助于一个巨大的独立 数据库来获取数据以追求最大性能的 - 这是 80%以上的企业应用中 的瓶颈所在!?扩展性：由于数据是均匀分布的，所以除了考虑到网络上的组通讯， 根本就没有必要来限制网格的大小网络上的组通讯只要能够发现 一个新的节点即可. 所有的数据获取方式都是通过点对点通信，即节点之间直接进行通信，非常容易控制。 DMQ 的增加或者减少不需要 关闭整个服务。 简单的添加删除集群中的机器不会引发任何服务中断。?数据分布：DMQ 使用一致性哈希算法来决定

42、集群中键值的存储位置。 一致性哈希算法成本低，速度快并且最重要的是不需要额外的元数据 或者网络通信就能确定键值的位置。 数据分布的目的是为了在集群 环境下保持足够的状态副本以使其具备可持续性和容错性，但是又不 会有过多的副本而阻碍 DMQ 的可扩展性。?原子性：一个 Update 操作不是成功就是失败，不会有第三种状态出现。?顺序性：在一个 DMQ 集群中，其中一台 DMQ 服务器上的消息 a 在 消息 b 之前发布，那么在所有的 DMQ 服务器上的消息 a 都会在消息 b 之前被发布，DMQ 会保持一致顺序。?实时性：对于每个 Client，DMQ 集群中的所有服务器都会保持实时更 新制度，

43、使得所有的服务视图都会是最新的。?分布式统一镜像：Client 无论连接到集群中的哪一个 DMQ 集群节点 服务，都是得到同样的镜像视图。?可靠性：数据在内存中缓存了 2 份，任何一台计算机故障，都不会造 成数据的丢失。2)分布式消息管理架构图：心跳/同步DMQ 有以下几种关键较色，每类较色的职责如下表格描述？角色名称职责领导者(Leader)就是DMQ集群的老大，它不接受Client的请求，是管理其他DMQ服务的，只负责进行投票的发起和决议，最终更新状态.追随者(Follower)追随者（Follower）的上司是领导者（Leader），参与领导者（Leader）发起的投票，向下是面向客户端

44、的交互，用于接收客户端的请求和反 馈客户端的结果。参与领导者（Leader）发起的投票。观察者(Observer)观察者可以接收客户端连接，将写请求转发给领导者（Leader）节点。但是Observer不参加投票过程，只是同步领导者（Leader）的状态。 Observer为系统扩展提供了一种方法。DMQ 的核心是原子广播，这个机制保证了各个 Server 之间的同步,有两种模 式，它们分别是恢复模式和广播模式。恢复模式：一般是在服务刚启动或者在领导者（Leader）崩溃后，开始进入 恢复模式，此时先就会开始选举领导者（Leader），当领导者（Leader）被选举出 来，并且追随者（Foll

45、ower）完成了和当前领导者（Leader）的状态及数据同步以 后，恢复模式就结束了。广播模式：恢复模式结束后，即领导者（Leader）已经和追随者（Follower） 进行了状态同步以后，他就可以开始广播消息了，即进入广播状态。3)分布式消息数据架构图：上图的 MM（Messages Manager）：消息数据管理者。通过嵌入式 nosql 内核完 成上百万并发量的缓存数据来提供异步发布和订阅。应用程序通过 JDBC/REST/Memcached 等符合业界标准接口完成集群中的消息缓存数据的操作， 集群成员之间也通过该接口完成成员之间的数据同步，状探测步。4)典型分布式消息平台比较：由于常见

46、的 RabbitMQ、ActiveMQ 和 ZeroMQ 消息中间件不具备分布式功能， 所以不在比较之列。数据采集中心面对的是高并发海量数据上传，所以分布式消息平台必须在数据接收?数据缓存数据发布整个过程保证数据的高性能吞吐、高可靠性、高扩展性、可维护性等属性。注：*越多速速越快。3 大数据计算平台3.1 需求概述根据应用，这个项目数据量30T，企业数据量非常大，需要大量并发，网络爬虫爬取的企业数据信息存储在数据中心。 此数据量跟企业记录相关。 同时，需要对清洗后的记录和计算好的推荐结果进行存储，但是这些数据不放在数据中心。此项目之后会做成实时计算，需要用到流式计算的相关计算和调度。计算量很大

47、，可以多部署 DCS 进程，提高计算并发度，作业调度也要采用分部署调度架构。3.2 总体设计云数据采集中心与大数据计算平台的关系是，云数据采集中心提供存储和计 算资源，通过 API 的方式访问资源，大数据计算平台主要实现核心算法，包括图 像匹配算法，挖掘算法，智能推荐算法，知识学习算法等等，也能够通过 API的方式建立统计应用、智能推荐应用等等。大数据计算平台 的需要的数据：包括网上实时爬取得、二次计算分析而获取的等等，都通过通用接口存储在云数据采集中心的分布式存储平台中（分布式文件 系统（S2DFS）、分布式数据库（D2B）。计算时候，通过接口发起作业，由云 数据采集中心的作业调度服务进程（

48、JSS）负责调度，由数据计算服务进程（DCS） 负责计算处理，并把结果反馈给大数据计算平台的各个应用。根据 2.3.2 小节对 S2DFS分布式文件系统的详细介绍，本章节就不重复叙述， 由于要增加新的存储设备，对于新设备上安装分布式文件系统是否继续选用 S2DFS 还是 HDFS，我们需要回答以下几个问题：第一，预算增加及扩展问题：要部署 HDFS，还得单独购买两台高性能设备 作为 HDFS 的元数据库服务器（注：两台设备，构成主备；配置不能 比我们现在选择的设备配置差，不然就会成为瓶颈，如果差了，数据 节点就扩展不了几台。）。第二，学习成本及进度问题：要使用 HDFS，必须熟悉它的 API，

49、以及后面 带来的整个 HDFS 集群部署维护等工作，这个与可利用的团队资源相 冲突；S2DFS 提供标准的 POSIX 协议接口，应用程序代码不需作任 何改变就可以执行。如果采用 HDFS，为了保证应用系统的透明，那 么统一接口的底层必须要写两种代码，第一是对面 S2DFS，第二是面 对 HDFS。新增加了开发、维护、测试的时间。第三，空间浪费及孤岛问题：S2DFS 与 HDFS 是两套不同体系的文件系统， 他们之间设备及存储空间是不能共用的，后面增加的6台，设备存储与前面部署的 10 台设备通过对原始数据处理压缩后，存储空间还有多余。二者构成了孤岛，同时造成空间浪费。第四，应用场景问题：HD

50、FS 对存储网页等文件比较友好，毕竟它的基因就 是为互联网搜索而开发出来的。3.3 数据模型设计数据模型主要主企业数据模型与投资商数据模型两个部分。3.3.1 企业数据模型字段名备注name公司名称econ_kind企业类型regist_capi注册资本scope经营范围term_start营业开始日期term_end营业结束日期belong_org所属工商局oper_name法人start_date成立日期status在业employees.job_title主要人员职位employees.sex主要人员性别主要人员姓名分支机构名称changerecords.change_item变更项目c

51、hangerecords.change_date变更日期changerecords.before_content变更前内容changerecords.after_content变更后内容partners.stock_name股东姓名partners.stock_type股东类型partners.identify_type证照/证件类型partners.identify_no证照/证件号码partners.should_capi_items.shoud_capi认缴出资额partners.should_capi_items.invest_type出资方式partners.should_capi_

52、items.should_capi_date出资时间partners.real_capi_items.real_capi实缴出资额partners.real_capi_items.invest_type出资方式partners.real_capi_items.real_capi_date实缴时间3.3.2 投资商数据模型字段名备注name投资商名称econ_kind企业类型regist_capi注册资本scope经营范围term_start营业开始日期term_end营业结束日期belong_org所属工商局oper_name法人start_date成立日期status在业employees.

53、job_title主要人员职位employees.sex主要人员性别主要人员姓名分支机构名称changerecords.change_item变更项目changerecords.change_date变更日期changerecords.before_content变更前内容changerecords.after_content变更后内容partners.stock_name股东姓名partners.stock_type股东类型partners.identify_type证照/证件类型partners.identify_no证照/证件号码partners.should_capi_items.sh

54、oud_capi认缴出资额partners.should_capi_items.invest_type出资方式partners.should_capi_items.should_capi_date出资时间partners.real_capi_items.real_capi实缴出资额partners.real_capi_items.invest_type出资方式partners.real_capi_items.real_capi_date实缴时间Investment_industry投资行业investment投资金额4 数据运营4.1 数据挖掘分析行业数据挖掘分析普遍采用CRISP-DM方法论

55、。CRISP-DM将一个数据挖掘项目的生命周期定义为六个阶段：业务理解（也称为商业理解）、数据理解、数据准备、建立模型、模型评估、模型发布。1.业务理解：从业务的角度理解项目目标和需求，然后将这种需求转换成一种数据挖掘的问题定义，并设计出达到目标的一个初步计划。2.数据理解：收集初始数据，识别数据的质量问题，找到对数据的基本观察、或假设隐含的信息来监测出感兴趣的数据子集。3.数据准备：对可用的原始数据进行一系列的组织以及清洗,使之达到建模需求。4.建立模型：选择各种建模技术，并将其参数校正到优化值。常常要退回到数据准备阶段。5.模型评估：对建立的模型进行评估，重点具体考虑得出的结果是否符合第一

56、步的商业目的。6.模型发布：将发现的结果进行总结与应用。4.2 数据分析处理的主要工作首先，是数据仓库或数据集市的建立，对数据进行预处理。数据分析处理以企业经营管理需求为基础，根据不同分析主题，从企业许多来自不同的运作系统的数据中提取出有用的数据，以保证数据的正确性，然后经过抽取、转换和装载，即ETL过程，合并到一个企业级的数据仓库里，得到企业数据的一个全局视图。其次，是联机分析处理和数据挖掘，进而将数据转化为信息和知识。联机分析处理是在数据仓库的基础上，对商业问题进行建模和数据进行多维分析。而数据挖掘通过分析每个数据，从大量数据中寻找其规律的技术。即使用诸如神经网络、规则归纳等技术，用来发现

57、数据间的联系，做出基于数据的推断。通过联机分析处理和数据挖掘，决策人员和高层管理能从多维角度准确掌控企业的经营状况和了解不同数据之间的相关关系，以便制定正确的决策。最后，是知识结论的可视化展示，实现知识向智慧转变。通过借助信息化系统，以简单、丰富和直观的形式，将查询报表、统计分析、多维联机分析和数据发掘的结论展现企业管理者和决策者的面前。而随着管理者对知识的不断积累和更新，会进一步将知识转化为企业管理者的智慧。最终成果为：根据招商大数据平台数据运营规范相关要求至少进行三个月的数据运营服务，并提供数据运营报告。验证数据运营规范的流程、优化数据模板，并形成特定的数据运营操作指南。4.3 数据分析团

58、队组织和管理数据分析团队负责开展数据采集、数据处理、数据管理和数据综合分析等工作。分析专家做的是预测建模、数据挖掘以及其他一些高级分析工作，而不是像定制报表和电子表格这样程序化的工作。他们解决问题的环境，使用的方法，甚至需要参加的各类培训都有很大的不同。因此在数据分析团队建设和组织管理上有其非常特殊的要求。1、数据分析团队建设（一）合理组建数据分析团队。整合客服中心人才资源，组建数据分析团队，负责开展数据采集、数据处理、数据管理和数据综合分析等工作。（二）强调共同价值体现。数据分析团队成员在目标、达到这些目标的路径和所需的合作上要努力达成一致，这样可以增强团队的认同感。强调数据分析团队的整体利

59、益，确定共同的目标，鼓励分析团队共享信息和思想，互相帮助实现共同目标。（三）引入过程分析会议。过程分析会议是数据分析团队内部充分讨论的平台，通过过程分析会议，增强彼此的沟通，要求每个数据分析人员都提出实现共同目标的方法、思路。（四）鼓励和促进团队内部相互交流。提供数据分析团队的定期交流机会，鼓励每个数据分析人员在完成某个大数据挖掘分析课题后，进行充分的交流与总结，增强数据分析团队能力与水平，提炼数据分析经验。（五）公开数据挖掘分析成果形成激励。及时将数据分析分析团队的应用情况向办内发布，使数据分析分析团队成员增强使感。2、团队组织建设（一）为分析团队树立榜样。要让数据分析团队发挥作用，首先是要

60、在团队中突出一个或多个优秀的团队成员，成为数据分析团队成员的表率，将优良的工作作风带入团队中，影响团队中的每一位成员。（二）传授经验培养团队精英。要在数据分析团队中做好培训、培养工作，把数据分析思路的形成方法传授给团队成员，团队组织要培养团队精英，发挥团队精英的作用，成为团队的主力。（三）灵活授权。随着数据分析团队的逐渐形成与发展，团队组织要通过合理授权让团队成员分担责任，使团队成员更多的参与团队工作中，允许团队成员灵活的开展工作，给予团队成员信任，让他们更积极的为开展挖掘数据价值服务，也给予团队成员学习与成长空间，实现团队成员自我价值的体现。（四）发挥团队凝聚力。数据分析团队的凝聚力是团队精