数据分析系统_APP建设方案

范文一：数据分析系统_APP建设方案

决策分析系统

APP 端建设方案

1. 概述............................................................. 3

1.1. 项目背景 ................................................... 3

1.2. 建设目标 ................................................... 3

2. 设计方案......................................................... 4

2.1. 系统建设的思路如下： ....................................... 4

2.2. 系统架构 ................................................... 4

2.3. 运行环境 ................................................... 5

2.4. 系统组成 ................................................... 5

3. 建设原则......................................................... 5

3.1. 实用性 ..................................................... 5

3.2. 先进性 ..................................................... 6

3.3. 前瞻性和整体性 ............................................. 6

3.4. 集成性 ..................................................... 6

3.5. 扩展性 ..................................................... 6

3.6. 经济性 ..................................................... 6

3.7. 可管理性和可维护性 ......................................... 7

3.8. 安全性 ..................................................... 7

3.9. 稳定性和可靠性 ............................................. 7

3.10. 可重构性 .................................................. 7

3.11. 设计规范 .................................................. 7

4. 架构设计......................................................... 8

5. 功能设计概述.................................................... 12

6. 表样设计........................................................ 13

1. 概述

1.1. 项目背景

移动互联，是基于“个人移动数字信息终端”（如：手机、平板电脑、PDA 等）接入互联网，用户在移动的状态下同时能使用的互联网的业务。移动设备能力不断加强，操作界面不断优化，外观时尚轻薄，能满足8小时以上的连续户外操作的需求，价格也不断下降，智能手机的用户不断增加；同时，随着中国联通、中国电信、中国移动等运营上的3G 网络不断发展，覆盖面至少到乡镇一级，理论速度都提升少2M 以上；根据摩根（Morgan ）的报告，移动互联时代的设备将超过100亿台，一个“人人有手机、时时在移动、处处在互联”的时代，将势不可挡的来临，企业将移动互联网技术应到工作业务中，为工作人员的工作带来方便快捷。

XXXX 在建的数据分析系统，为营销工作带来方便快捷的数据查询服务器，为了使用人员能在脱离办公场所在外的地方进行数据查询分析服务，应用移动互联网技术对数据分析系统进行模块升级扩展，建设数据分析系统APP 移动客户端，方便使用人员在移动的环境下快速进行获数据查询分析工作，更有效率的开展工作。

1.2. 建设目标

将先进的便携终端/移动通讯技术与现代卷烟营销模式紧密结合，不断提升卷烟营销运作、管理和决策支持水平。

（1）在管理决策层面，及时掌握卷烟营销情况，为决策、调度提供信息依据。充分利用营销业务数据库、经营分析数据库等为领导层搭建宏观层面的监控

平台，将分散的、零碎的数据集中化，以可视化的手段展示在移动终端上，为营销管理层人员日常的调度工作提供强有力的数据支持。其意义主要体现如下：

方便快捷的获取营销数据信息。

拥有直观、方便的数据展现形式。

改善了传统信息中心定期汇总形成营销运营情况报告的模式，进一步提高工作效率。

随时随地为领导层提供监控、分析、决策等关键经营指标的数据依据。

（2）使用人员可以在移动环境下快速查阅分析精炼的客户数据，提高工作质量与效率的同时，更好的了解市场、管理市场。

2. 设计方案

2.1. 系统建设的思路如下：

2.2. 系统架构

在防火墙DMZ 区域部署一APP 端前置服务器，负责客户端APP 与数据分析系统（服务端系统）的数据交换。客户端APP 通过移动互联网从服务端系统下载要查询的数据。

服务端系统负责移动APP 的数据提供；移动APP 部分负责数据展示。

2.3. 运行环境

数据分析系统客户端APP 应适用于市面上最主流的基于android 的智能终端设备，可部署在安卓4.0版本以上的终端设备上，终端设备要求支持屏幕分辨率720X1280像素以上，运行内存2G 以上，CPU1.5GHz 以上。

2.4. 系统组成

3. 建设原则

设计遵循以下原则：

3.1. 实用性

方案选择和功能设置应追求实用性，必须切合XXXX 的实际，技术上要有一定高度，手段强调实用，操作直观简便，便于维护。同时，要满足行业要求，符合XXXX 的业务模式和管理模式，不盲目追求不实用的技术，符合经济实用并适度超前的原则。

3.2. 先进性

整体系统应充分体现先进的管理思想和理念，采用先进的、成熟的且可持续发展的技术方法，并与XXXX 的实际相结合。

3.3. 前瞻性和整体性

充分考虑行业信息化的发展趋势和方向，结合XXXX 的实际，对系统的整体架构进行具有前瞻性和整体性的设计。

3.4. 集成性

系统应符合信息集成和信息共享的原则，具有开放、灵活、符合主流标准的集成架构，能够与全区、XXXX 现有的、在建的、将建的各相关应用系统进行无缝的信息集成，做到业务流程的全闭环管理和数据层面的实时、准确传输。

3.5. 扩展性

使用广泛、先进、成熟的标准和协议，系统要具有良好的开放性、扩展性、可移植性和升级前景，系统结构要求模块化，功能模块可以平滑扩充。

3.6. 经济性

系统总体上应具有良好的性价比，应适用于XXXX 现有的网络条件，在保证系统能够安全、可靠运行的前提下，要充分考虑与现有的相关系统兼容性，最大限度地降低系统造价，充分利用现有系统有价值的财富，保护原有投资。同时，在设计时要作到统一规划，避免不必要的投资。充分考虑到系统的可扩充性，避免重复投资。

3.7. 可管理性和可维护性

提供的系统应具有简单、直观、方便的维护和管理手段，尽量减少维护和管理环节，使系统具有良好的可管理性和可维护性。

3.8. 安全性

保证数据的安全以及交换数据的安全和一致性，采用有效手段保障系统和数据的安全性。

3.9. 稳定性和可靠性

系统应具备必要的冗余备份设计，运行应稳定、可靠。要保证应用及数据的高可用性，任何一个运行应用的主机发生故障时，该应用系统能够在保证数据不丢失的情况下自动切换到其他主机上运行，即做到集群功能。

3.10. 可重构性

系统应具备可重构性，保证系统在需要重构时，能够顺利实现系统的重构。

3.11. 设计规范

本项目在系统设计、软硬件采购、应用开发、系统集成和服务过程中应采用已有的国家标准、行业标准和主流国际标准，遵循但不仅限于下列标准体系和要求：

YC/T 203-2006 《XX 行业信息化标准体系》及相关标准

《XX 行业信息化建设统一技术平台要求》

《XX 行业信息系统安全等级保护定级指南》

国家《SOA 标准体系》。

4. 架构设计

本系统采用与数据分析系统共用的技术手段，从而做到了本系统与原有系统的技术手段的统一线，也符合国家局以及XXXX 对于统一技术路线的需要。

（一）系统采用J2EE 技术架构

根据项目建设目标要求，系统建设既要适应本次项目需求，同时也要考虑到将来的系统扩展性和应变性，软件设计要保证在技术上的可扩展性，满足现有和未来不同应用系统的需要，并方便今后进行其他系统的扩展和再开发。因而在结构选型上，要有强的伸缩特性，并且技术上要先进、成熟、可靠和稳定性。经过对用户的现有状况及业务需求比较分析，我们推荐采用基于J2EE 的应用体系结构。

在国际上，Java 技术已成为解决大型应用的事实标准，符合J2EE 规范的应用服务器则是构建面向对象的多层企业应用的中间核心平台。因其具有易移植性，广开放性、强安全性和支持快速开发等特性，成为面向对象开发组织应用的首选平台。基于J2EE 应用服务器支持EJB 组件开发技术，包括消息队列、负载均衡机制和交易管理等。支持中大型网站和中大型组织应用等需要大规模跨平台、网络计算的领域。软件构造有几个不可逆转的发展方向：XML 数据结构、面向对象的构件技术、网络化应用。其中Java 因为与平台无关、安全、稳定、易开发、好维护、很强的网络使用性等，而成为主流环境， J2EE 是企业级应用的标准。

目前基于J2EE 标准的体系结构，由于其以下特征受到了越来越多的大型企业、政府机关欢迎和应用。

1) 可伸缩性，可扩展性、平台无关性；

2) 代码复用性，维护成本低；

3) 快速开发能力，带来系统实用性及系统的灵活应变能力；

4) 集成性，数据访问能力强，可以访问各种异构数据。

应用应当构建在一个构架合理、先进，扩展性强、伸缩性好、安全性高的统一应用服务支撑平台上，这样，才能避免重复开发、在保证系统稳定可靠的基础上加快建设的速度。

根据以上考虑，我们设计本项目的技术架构采用基于J2EE 的MVC 框架来实现。

展现层、控制层和业务逻辑层部署在应用服务器上，并以我公司应用平台来支撑，应用服务器采用符合J2EE 规范的成熟产品，如BEA Weblogic 、IBM Websphere 等，数据层部署在数据库服务器上。系统用户可以通过PC 客户机的浏览器、移动终端等设备来访问系统的展现层，从而实现与业务应用系统的交互。

展现层

展现层完成业务系统信息如客户信息、商品信息、订单信息等信息的提交。展现层采用“请求-应答”方式与控制层交互。为减少展现层与控制层的交互，尽量采用“相关信息一次获得、信息一次提交”方式。

展现层还可以完成各应用系统的界面级整合，包括个性化展示等。

展现层主要采用JSP 技术，并使用类C/S方式的 WEB 组件实现界面友好的交互。

控制层

控制层实现用户和系统之间的交互管理，提供展现层的展现逻辑和对应用层

的访问接口。控制层主要提供分发服务、会话管理、安全服务、输入校验、错误处理、单点登录等服务和功能，它负责接收客户端的服务请求，进行解析；并根据解析结果调用逻辑层相应业务组件的方法。

安全服务从应用软件的层面来说主要包括认证及授权。

认证：用符合JAAS 规范，统一基于LDAP 的安全认证。认证的主要目的是保护整个应用，在没有通过认证之前，应用的任何资源都是受保护的，在通过了认证之后，才能基于你在LDAP 上的角色来访问具有权限的应用。安全认证可以基于其他第三方安全产品进行扩展，可以基于key 、基于CA 证书认证，应用服务器和安全服务器建立信任关系，所有的安全认证提交给安全服务器来完成，可以利用key 存储用户的电子签名、电子印章，使整个应用的安全得到更好的保障。

授权：采用分层的授权机制，一级权限为子系统的访问权限，二级为子系统内部的功能模块的访问权限，在子系统内部，授权可以再细分，可以根据用户的需求把功能模块的权限赋予相应的角色。

控制层采用Servlet 实现。

逻辑层

业务逻辑的接口，实现业务流程的控制，是业务领域层的服务接口。其责任是提供业务组件和业务服务，这些组件将根据展现层的请求进行相关的业务处理。注意这里的组件是广义上的概念，既可以是EJB ，也可能是普通的Java 类，或者是一个WEB 服务。

逻辑层的业务组件建立在统一的业务模型之上，这些业务模型也将为流程关键型业务使用。

逻辑层会从数据访问层读取数据或将数据写入数据层。逻辑层也可以采用缓

存服务，对于基础类数据使用缓存，直接从内存读取，减轻对数据库的压力并提高响应速度。

数据访问层

完成与数据库的交互，对系统的各种资源和外部系统提供统一的访问逻辑。

可以采用JDBC 、Hibernate 及数据库的优化技术，如翻页、SQL 语句预编译等。

资源层

存放业务数据，是持久化存储的物理设备，包括各种信息系统资源，例如

RDBMS 、文件系统、原有系统、消息服务、邮件服务、交易服务中间件等。

资源层一般采用关系数据库，如DB2、Oracle 等。

（二）系统采用SOA 服务构架

SOA （service-oriented architecture）是面向服务的体系结构，是一类分

布式系统的体系结构, 是构建如何组成一个系统的模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和按松藕合方式整合在一起，即将多个现有的应用软件通过网络将其整合成一个新系统。

企业通过SOA 的实施，可以实现以服务为核心，将企业的IT 资源整合成可

操作的、基于标准的服务，使其能被重新组合和应用，增强业务灵活性，快速响应市场变化，并保护了企业已有应用的投资，降低企业的IT 总成本。

（三）系统遵循的详细技术要求

5. 功能设计概述

跟进初步沟通交流，目前APP 端主要查询以下数据情况

6. 表样设计商定执行

品牌上柜

范文二：WIFI营销—数据分析系统技术方案

WiFi 营销 -

把路人变成粉丝

网络架构

开放式架构 : 放大镜无 ETL

接入支持

开放式架构 :

望远镜

业务处理特征分析

? 客户与网点对应关系分析与维护

– 多种类型的关系分析提取模型

业务处理特征分析

? 客户分析相关参数维护

–

支持多级参数维护管理

业务处理特征分析

? 内存数据库

毫秒时效的保障

Milliseconds

Hundredths of seconds

Second(s)

Minutes

Hours

? Place trade ? Serve ad

? Enrich stream? Examine packet? Approve trans.

? Calculate risk? Leaderboard ? Aggregate ? Count

? Retrieve click ? ? Backtest algo? Algo discovery

业务处理特征分析

Simple Slow Small

Fast Complex Large

A p p l i c a t i o n C o m p l e x i t y

? 内存数据库毫秒时效的保障

业务处理特征分析

? 可按日、周、月进行 , 客户级别、客户产品等多级多维度分析

用户行为分析

通过 WiFi 记录,获得用户访问网站基本数据,对有关数据进行统计、分析,从中发现用户访问网站的规律,并将这些规律与网络营销策略等相结合,从而发现目前网络营销活动中可能存在的问题,并

为进一步修正或重新制定网络营销策略提供依据。

产品柏拉图分析

进度追踪甘特图分析

网点区域时间综合维度分析

产品驾驶仓

市场驾驶仓

产品生命周期分析

客户信息结构分析 (HR模型参考

)

用户行为分析

? 用户行为分析包含以下重点分析数据:

– 用户在网站的停留时间、跳出率、回访者、新访问者、回访次数、回访相隔天数 – 分析用户的浏览习惯

– 用户所使用的搜索引擎、关键词、关联关键词

– 用户选择什么样的入口形式(广告或者网站入口链接)更为有效

– 用户访问网站流程

– 用户在页面上的网页热点图分布数据和网页覆盖图数据

– 用户在不同时段的访问量情况

– 用户是否对于网站的字体颜色的喜好程度

– ... ...

通过对用户行为监测获得的数据进行分析,可以

让企业更加详细、清楚地了解用户的行为习惯,

从而找出网站、推广渠道等企业营销环境存在的

问题,有助于企业发掘高转化率页面,让企业的

方面提升企业的收益。

用户偏好分析

? 第一种类型 : 消费者倾向不稳定、含糊

– 要提供给他们一个满意的解决方案,以满足其偏好是不可能的。然而,因为他们对自己的偏好不了解,因此易被影响,易被企业劝说相信其定制化供给是令人满意的,是真正符合他们喜好的。并且如果定制化供给成功的话,这些消费者就会认为,该定制化符合了他们先前的偏好,并以此为基础.形成他们以后的偏好。 ? 第二种类型 : 消费者知道自己没有稳定、清晰的偏好,

– 他们对供给的评估很有可能是建立在其外观的吸引力上,而不是其是否真的符合他们 (不牢固 ) 的偏好。并且。对有助于他们分辨自己偏好的建议和帮助,这一类型的消费者可能表现出最好的接受性。例如,喜欢喝葡萄酒,但是却又清楚知道自己没有这方面知识的消费者,可能会非常乐意接受有关葡萄酒方面的教育和消费建议。

? 第三种类型 : 消费者有着稳定的消费偏好

– 这种类型的消费者可能最少,这些偏好引导着他们的选择,但是他们却并没有清楚地意识到偏好对他们消费选择的驱动性。例如他们可能自认为选择是建立在理性、客观评判的基础上的.而实际上他们的选择主要考虑的是情感因素或审美因素。因此,这些消费者要么对那些实际上并不符合他们偏好的定制化供给或选择标准,可能会错误地接受,而最终导致不满意。要么,对那些真的能符合他们偏好的定制化供给或选择标准, 却可能选择拒绝。

? 第四种类型 : 消费者既有清晰的偏好又偏好足够了解

–

用户偏好分析

点击统计

用户访问行为统计

性别访问统计

Datameer 行为统计分析 :女性大脑的思维模式 >表象思维 >多任务导向 >本能反应 >社交和口才 >担忧 /换位思考

男性的大脑会优先思考

>具象思维 >结果导向 >逻辑的解决方案 >竞争 /防卫男女差异对市场营销者的意义

目标受众为女性的广告,需要使用有创意的元素和风格来响应女性大脑的思维方式。例如,运用以情感为基础的视觉意象,要比依靠有利于她的事实和数据更能有效地吸引女性关注。同时需要保持可信度,不要使用明显的广告信息如“就要到期啦”或“马上拨打电话”,女性更欣赏和接纳细节的表现。由于女性大脑的思维倾向于交际的和谐, 所以传递的信息不应该关注在冲突上。

当营销活动对准男性群体时,应该用积极的语句快速、明确地直入主题。

男性更关注专门为自己设计的产品,他们是强迫性的购物者,所以可以考虑把广告信息设立在结账出口处,并在售卖点上打上节约成本的旗号。目前来看,把手机广告添加到你的营销计划中来吸引男性客户也是个不错的选择。

时间倾向性指数分析

统计用户在不同时对产品关注的时间倾向 , 来总结推测用户意向

基于 IP

行为统计的即时营销

预测分析

? 根据围观效应分析用户参与围观的行为 , 预测用户认同度 , 从而决定产品针对性

营销的强度

二次聚类匹配营销分析新老客户隐含关联度综合营销

? 聚类营销

– 对现有产品客户进行

聚类分析

– 对新客户与老客户进

行信息聚类分析

– 对新客户进行分析后

营销

访问路径与访问量分析

产品决策树营销模型

? 决策树

– 根据用户的喜欢行为进行决策树预测

用户购买意向树

客户与产品列式依赖分析模型

? 纵向 :用户特性

– 职位

– 年龄

– 性别

– 城市

? 横向 :金融产品

针对已有客户数据统计 , 预测新用户对不同产品的接

受度

产品市场竞争战略分析 ? 产品市场竞争战略分析方法 ,通过对被分析对象的优势、劣势、机会和威胁的加以综合评估与分析得出结论, 通过内部资源、外部环境有机结合来清晰地确定被分析对象的资源优势和缺陷,了解所面临的机会和挑战,从而在战略与战术两个层面加以调整方法、资源以保障被分析对象的实行以达到所要

实现的目标。

Sales Analysis

Profit Center Analysis

What-IF

RTB

广告推送

用户产品浏览 -购买状况分析

网络运营

把网络流量数据与社交媒体、营销、销售及其他数据结合起来,将重点放在网站转换率上。网页分析应注重效果,而不仅仅是注重点击率。 Datameer 功能齐全,可帮您详细了解任何数据源。诸如会话流程、点击路径、 URL 参数提取等多项功能,也可使您更全面了解、并与页面访问者进行互动,为用户提供更个性化的体验,以提

高转换率。

客户 -网点 -产品之间无限关联性分析无限关联性

Datameer 关联多种复杂

且不相关的数据,并对

其反复地进行时间序列

分析。分析结果是无穷

尽的 , 其中包括信用卡交

易与持卡人的授权、网

络流通数据、营销互动

数据及其他因素等之间

的关联性。最终呈现的

结果可以作为指导您进

行业务操作的一个窗口,

提供深度洞察以助您做

出正确的商业决策。

产品与客户关注点热度分析

Twitter happiness Analysis

社交热门话题 Twitter

数据分析

社交统计

Facebook

数据分析

分析的自由定制

关键特性 : 基于网络的数据库集群复制

VoltDB 包括一个网络复制 Agent

这个 Agent 将事物异步从主集群(可读可写)复制到备集群(只读)

异步的方式最大限度容忍网络可能出现

的问题

可线性扩展的性能

右边表格源自于独立的测试机构 Percona ,标示出线性扩展到每秒 150万次的运算和最高推断值达到 30个服务器。这个表也表明 VoltDB 线性扩展具备 K-Safety

高弹性的毫秒级访问支持

范文三：污染源智能视频数据分析系统建设方案

重点污染源企业

智能视频监控分析系统

解

决

方

案

成都之维安科技股份有限公司

2016年3月

第1章. 建设概述 ............................................................................................................................ 3

1.1建设背景 . ...................................................................................................................................... 3

1.2建设目标 . ...................................................................................................................................... 3

1.3主要建设内容 . .............................................................................................................................. 3

1.4建设技术标准 . .............................................................................................................................. 4

第2章. 总体设计 ............................................................................................................................ 4

2.1设计原则 . ...................................................................................................................................... 4

2.1.1先进性原则 . .......................................................................................................................... 4

2.1.2可扩展性原则 . ...................................................................................................................... 5

2.1.3安全性原则 . .......................................................................................................................... 5

2.1.4实用性原则 . .......................................................................................................................... 5

2.1.5稳定性原则 . .......................................................................................................................... 5

2.2系统架构 . ...................................................................................................................................... 6

2.2.1网络架构 . .............................................................................................................................. 6

第3章. 现场端设计 ........................................................................................................................ 7

3.1现场端—污染源企业监控点详细设计 ....................................................................................... 7

3.1.1. 企业现场端建设拓扑图 . ................................................................................................... 8

3.1.2. 建设位置选点示意 . ........................................................................................................... 8

3.1.3现场端—视频采集摄像机 ................................................................................................. 10

3.1.4现场端—视频存储设备介绍 ............................................................................................. 12

3.1.5现场端核心—环保智能视频检测器主要功能介绍 ......................................................... 13

3.1.6视频数据存储设计 . ............................................................................................................ 16

3.2企业现场端点位详细设计 ......................................................................................................... 17

3.2.1 CEMS 站房1 . ...................................................................................................................... 17

3.2.2 CEMS 站房2 . ...................................................................................................................... 17

第4章. 污染源企业安装部署环境要求 . ....................................................................................... 19

第5章. 设备清单及造价 . .............................................................................................................. 20

第1章. 建设概述

1.1建设背景

为贯彻落实环保部印发的《环境监测数据弄虚作假行为判定及处理办法》（环发〔2015〕175号），进一步促进提升我区直征企业污染源在线监控设施运行管理水平，提高在线监测数据真实性、准确性和有效性，自治区环保厅决定组织全区37家直征电力企业于2016年上半年全面完成污染源智能视频监控系统建设工作，污染源智能视频监控系统是当前污染源在线监控设施的重要组成部分，可实现视频监控企业的废气排口污染物排放情况及在线监测设备的CEMS 站房，将污染源排放实时在线监测数据与排放口视频监控实时图像数据叠加，并同步传输至相关环保部门及企业安环部门。

1.2建设目标

全区37家直征电力企业应于2016年6月30日前自筹资金完成污染源智能视频监控系统现场端及链路传输建设，将在线监测数据与排放口视频监控实时图像叠加数据传输至自治区污染物监控与信息中心，有利于及时发现污染源在线监控不正常运行及污染物超标排放情况，为控制和减轻污染、保障在线监测数据真实准确提供有力的技术支持。将目前对直征电力企业污染源现场的监控模式由传统的单一型、粗放型向综合型、智能化、集约型转变。

1.3主要建设内容

为有效提升监管力度，现针对大唐新疆呼图壁热电厂展开现场实时监测点位部署，建设主要建设内容为：

在企业废气排放口及CEMS 站房安装高清摄像机、部署智能视频服务器及软件、安装视频存储器、配置光纤网络模块及视频监控数据传输链路。

1.4建设技术标准

《环境信息系统集成技术规范》（HJ/T 418-2007）

《安全防范工程技术规范》（GB50348-2004）

《图像信息管理系统技术规范》（DB11/Z384.1-18）

《民用闭路监视电视系统工程技术规范》GB50198-2011

《视频安防监控系统技术要求》GA/T367-2001

《报警图像信号有线传输装置》GB/T16677-1996

《视频安防监控数字录像设备》 GB20815-2006

《环境信息网络建设规范》 HJ460-2009

《环境信息系统集成技术规范》 HJ/T418-2007

《污染源在线自动监控（监测）系统数据传输标准》 HJ/T212-2005 《污染源在线自动监控（监测）数据采集传输仪技术要求》 HJ 477-2009 《环境污染源自动监控信息传输、交换技术规范（试行）》

第2章. 总体设计

2.1设计原则

2.1.1先进性原则

硬件设备的先进性：硬件设备选用性能价格比高的设备，保障性能和长寿命使用，保障在未来软件系统不断提升的情况下能够尽可能长地支持软件计算系统。

软件先进性：软件采用基础软件系统标准化、功能软件系统定制化的方式。在标准化的软件系统上实现环保业务平台的功能，并为未来的软件功能扩充打下基础；

技术方法的先进性：采用先进的技术方法和理论，联合我自治区优秀的高校智力资源，设计可靠、具有先进理论水平的分析模型和应用模型。

2.1.2可扩展性原则

业务扩展：随着信息技术的不断深入发展，各类数据库以及业务管理模式都可能发生变化；同时各种流程以及相关表格也可能发生变化，系统应能够适应变化，进行动态更新、修改和扩充。

功能扩展：为了满足用户今后系统扩容和扩大应用范围的需求，系统应充分考虑从系统结构、功能设计、管理对象等各个方面的功能扩展。

软硬件升级：系统应充分考虑软硬件平台的可扩展性及软、硬件的负载均衡机制。随着关键软件和硬件的发展以及管理功能的增加，系统具有灵活和平滑的扩展能力。

2.1.3安全性原则

系统的安全保密性是系统设计的重要原则。系统将采用权限控制和网络控制两种方法，保证整个软件体系不会出现非法访问和各个子功能的非法使用。一些承载重要数据信息的硬件设备需要考虑采用冗余方式工作，软件和数据库需要安装用于备份和恢复的软件系统。

2.1.4实用性原则

系统在深入调查研究的基础上设计研发，使得软件功能设计合理、全面、实用，能最大限度地满足相关行业的工作需求。具体包括做到界面设计人性化，尽量符合业务人员的工作流程和工作习惯。业务处理的操作，尽量做到简单、易用、便于操作；同时也提供复杂但功能强大的管理操作功能。

2.1.5稳定性原则

设计、开发和应用时，从系统结构、技术措施、软硬件平台、技术服务和维护响应能力等方面综合考虑，确保系统具有较高的性能和较低的故障率。系统建设采用先进和高度商品化的软件和硬件平台、网络设备和二次开发工具。在进行系统设计、实现和测试时采用科学有效的技术和手段，确保系统交付使用后能持

续稳定地运行。

2.2系统架构

2.2.1网络架构

在对自治区直征电力企业数据采集和视频监控系统的网络结构设计中充分考虑环保行业的业务需求，同时结合环保监管部门和企业的实际情况，采用二级架构分布式部署：

第一级为自治区直征电力企业现场端，通过环保智能视频检测器实现对企业是否超标排放等情况进行智能分析以及对进出CEMS 站房的行为报警等。对超标排污数据进行现场视频取证，并通过传输网络，将叠加后的监控视频数据发送给第一级监控中心。现场端系统建成后，实现现场端高清视频采集，数采仪污染物排放数据采集，智能分析、报警等。

第二级为自治区级监控中心，该体系架构既能实现对本级所辖自治区直征电力企业的监管，也能满足自治区环保部门“统一规划、统一部署、统一接入、统一监控”的要求。自治区直征电力企业智能视频监控通过光纤专线接入自治区污染物监控与信息中心平台，进行视频调阅、实时查看、数据分析与统计功能，同时共享自治区环境监察总队。

图网络拓扑图

现场端系统建成后，实现现场端高清视频采集、并由环保智能视频检测器结合所接数采仪等设备进行相应智能分析、处理，同时现场常规视频60天存储。

第3章. 现场端设计

针对本次建设企业特点，设计将采用摄像机进行排污监控，同时通过环保智能视频检测器对接数采仪进行视频叠加分析、处理，现场端采用视频储存设备实现监控视频数据存储，详细设计如下：

3.1现场端—污染源企业监控点详细设计

污染源企业现场端视频系统，依据实际情况设计安装摄像机，保证架设摄像机可以有效监控指定区域，同时对接环保数据采集设备，一并接入环保智能视频检测器对其数据进行实时分析、处理，并为环保智能视频检测器搭配存储设备，实现视频数据60天存储。环保智能视频检测器作为核心设备完成数据分析、处

理等智能运算，并对接自治区污染与监控与信息中心平台实现向上级发送数据等功能。

3.1.1. 企业现场端建设拓扑图

废气污染源企业监控点配置为：

（1）在厂区内办公楼顶安装1台枪式摄像机（针对排口排放情况进行实时监控）

（2）两个CEMS 站房内各安装1台高清半球（针对CMES 间进行实时监控）

（3）CEMS 站房内安装1台环保智能视频检测器（可同时对接两个CMES 间的数采仪，直接与摄像机、数采仪相连接，完成数据分析、处理、叠加等相关功能。）

（4）CEMS 站房内安装视频存储设备一台（提供60天视频存储）

图废气排放监控企业前端设备结构图

3.1.2. 建设位置选点示意

根据企业现场实际情况确认点位

建议1:企业监控点的位置可针对废气处理环节中污染治理的废料排口区域。建议2:企业监控点的位置可针对废气排口区域。

图排放口取景（示例）

图室外摄像机安装位置实景（示例）

注：安装点位选定位置，在实际施工中根据实际情况调整。

3.1.3现场端—视频采集摄像机

现场端视频采集，摄像机设计采用的高清摄像机，直接与相应设备进行连接，对所指定区域视频监控，监控中心可实时查看，提供视频图像。

本次选用安装摄像机简介如下：

（一）高清半球摄像机，主要用于CEMS 间的视频监控

图设备参考图

光学特性

? 1/2.8 inch逐行扫描200万像素CMOS 图像传感器

? 焦距范围：3~10.5mm，手动变焦

? 1080P(1920*1080)最大30帧/秒

? 120dB 光学宽动态，满足高反差场景监控

? 3D 降噪

编码特性

? 双流套餐能力，满足不同带宽及帧率的实时流、存储流需求 ? 区域增强(ROI)功能，提高低带宽网络环境下重点区域图像质量 ? 9:16走廊模式，纵向场景下有效监控区域提升一倍

? 定制化OSD ，提供多种内容样式的自定义效果

网络特性

? 网络自适应，丢包环境下提供有效监控

? UNP技术，解决公私网NAT 穿越

? 双路iSCSI 数据块直存

网络安全

? 支持授权用户和口令访问，能进行弱口令检测与错误登录抑制，提升口令安

全性

? 支持HTTPS 安全Web 访问

? 支持RTSP 访问鉴权认证，确保视频流请求合法 ? 支持IP 过滤，有效屏蔽非法IP 地址访问 ? 支持网关ARP 绑定，防止网关MAC 地址欺骗防护等级 ? IP66

（二）高清枪式摄像机，用于排口视频监控

图设备参考图

成像器件 1/1.9 inch逐行扫描200万像素CMOS 图像传感器焦距/变倍焦距范围：6.5~143mm，电动变焦，22倍光学变倍光圈 DC-Iris，支持精确光圈控制，F1.5~F3.4 快门自动/手动，快门范围：1/6~1/8000s 最低照度 0.001lux(F1.5，50IRE) 0lux(开启红外) 信噪比 >52dB 宽动态 120dB

日夜切换方式自动红外滤片切换彩转黑编码协议 H.264

编码制式 1080P(1920*1080)最大60帧/秒 9:16走廊模式支持

区域增强(ROI) 支持视频流三码流 OSD

时间OSD ，自定义OSD

隐私遮盖支持

协议 L2TP、IPv4、IGMP 、ICMP 、ARP 、TCP 、UDP 、DHCP 、PPPoE 、 RTP 、RTSP 、DNS 、DDNS 、NTP 、FTP 、UPnP 、HTTP 、SNMP 、SIP 等

兼容接入 ONVIF、GB/T28181、IMOS 、API 接口特性描述

音频输入输出音频接线输入：阻抗35K Ω，幅值2V[p-p] 输出：阻抗600Ω，幅值2V[p-p]

网口 10M/100M自适应以太网电口本地视频输出 BNC接口：阻抗75Ω，幅值1V[p-p] 电源 AC24V ±25%、PoE （IEEE802.3at ） AC24V ±25%

功耗：本体5.5W ，最大19W(红外：13.5W) 功耗：本体7.5W ，最大21W(红外：13.5W)

尺寸(长x 宽x 高) 396.5mmx137mm x112mm(15.6” x 5.4” x 4.4”) 重量 3.7kg(8.2lb)

工作环境 -40℃~60℃(-40°F ~ 140°F) ，≤90%RH 防护等级 IP67

3.1.4现场端—视频存储设备介绍

现场端存储设备主要完成视频数据实时存储，实现现场端视频60天存储周期，存储容量根据实际现场摄像机路数进行对应配置。

图设备参考图

3.1.5现场端核心—环保智能视频检测器主要功能介绍

现场端环保智能视频检测器采用嵌入式系统，是新一代的智能化视频、采集数据、处理分析产品，它集视频采集、视频压缩、视频分析、采集数据实时叠加、网络传输等功能为一体，采用物联网、互联网和智能图像分析算法，根据不同的环境监控应用集成多种视频分析算法，由一个简单的设备来完成以往需要由PC 主机加视频采集卡组成的系统才能完成的功能。

图设备参考图

摄像机可直接或间接通过视频存储设备，两种连接方式和环保智能视频检测器相连接，将视频数据传送至环保智能视频检测器，同时环保数采仪设备对接环保智能视频检测器，环保智能视频检测器对接收数据进行分析、处理、叠加，同时进行防串改数据运算、存储。

图 B/S管理配置界面

现场端环保智能视频检测器所具有强大的视频分析等数据处理能力： ? 排污口有无违规排放（如：排放污染物发生重大变化等）； ? 数采仪数据现场端数据接入采集结果； ? 数采仪数据与视频实时叠加；结合数采仪品牌实际情况，进行对接设置。

具体功能如下：

3.1.5.1数采仪实时数据的采集

现场端环保智能视频检测器以简单、可靠性高的方式与数采仪实时通信，按照《污染源在线自动监控（监测）系统数据传输标准》（ HJ/T212-2005）的传输标准，接收如下数据：

废气指标：烟气排放量、二氧化硫、氮氧化物、烟尘排放浓度；废水指标：废水排放量、PH 、COD 、企业特征污染物浓度。

显示烟气监控指标：采用循环流化床工艺，8个指标（SO 2、NOx 、烟尘、流速/流量、烟气温度、烟气压力、含氧量、含水量）；采用石灰石膏法工艺，17个指标SO 2、NOx 、烟尘、流速/流量、烟气温度、烟气压力、含氧量、含水量等脱硫前、后的数据和旁路开关量），及其他工艺的相关指标数据。

图部分指标阀值设置参考例图

图采集数据视频截图（示例）

3.1.5.2数采仪数据叠加

现场端环保智能视频检测器将采集到的数采仪数据实时叠加到视频上，并存储、传输，保证实时数据的完整性和防篡改性。根据已设置的阀值，对采集到的已超出阀值的数据及时发出预警信息。

图数采仪数据分析、叠加截图（示例）

数采仪所获数据通过环保智能视频检测器将数据与视频信息集合，对其完整性和防篡改性等处理、分析、叠加，从而有效规避进入监控中心后对数据的修改等违规行为。

3.1.6视频数据存储设计

系统采用多级存储方式，现场端环保智能视频检测器连接视频存储设备（NVR ），对现场端常规监控视频数据进行现场端保存，存储视频高清模式下存储时间为30天，存储空间满后，自动对其滚动覆盖。

所保存视频数据（存储只需采用一种方式）可选择： 1、存储处理、叠加后的视频数据；

2、存储未经过处理、叠加后的原始视频数据。

3.2企业现场端点位详细设计

CEMS 站房作为存放监测设备的敏感区域，对其监控将有效监管违法行为。采用不间断视频监控，实时记录进入人员特征，可进行实时查看或录像回放等监控功能。

3.2.1 CEMS 站房1

CEMS 站房1实际环境安装点位示意图如下：

图安装点位布局图（示例）

3.2.2 CEMS 站房2

CEMS 站房2实际环境安装点位示意图如下：

图安装点位布局图（示例）

图 CEMS站房数采仪设备照片（示例）

第4章. 污染源企业安装部署环境要求

1. 供电要求：现场需提供摄像机等相关设备的电力电路接入支持。

2. 网络要求：污染源企业需提供运营商专线（非互联网）连接本企业CEMS 站房到自治区污染物监控与信息中心，且数据做透明传输，以保障环保厅的访问接入，带宽要求为8Mbps （专线详情请咨询当地运营商）。

3. 数采仪要求：数采仪需符合《污染源在线自动监控（监测）系统数据传输标准》HJ/T 212-2005 等相关国家及行业标准，支持将采集数据通过RS232（或RS485）

串口输出能力。

4．防雷接地要求：现场需具备符合国家相关标准要求接地点，以保障摄像机等设备的良好接地。

第5章. 设备清单及造价

设备参数要求，如下表：

范文四：基于SYBASE数据库的银行客户数据分析系统解决方案

内容摘要:

数据收集和数据存储技术的快速进步使得各个组织机构都能够积累海量数据，但是怎样从这些数据中提取有用的信息已经成为巨大的挑战。特别是对于银行部门来说，他们对于数据处理提出了更高的要求。他们需要从浩如烟海的数据中提取出有用的关键信息，使得能够在一些重大事件上作出正确的决策，最终通过市场上的竞争转变为利润。目前市面上常用的数据库产品有Oracle，IBM的DB2，微软的SQL Server以及Sybase的ASE，这四大数据库产品在功能和应用上各有千秋，因此在市场上都占有一席之地。作为Sybase公司的旗舰产品，ASE数据库系统面向的客户群主要由各大银行机构构成。因此，Sybase公司不满足于仅仅为这些大型银行组织提供一个基本的关系型数据库系统，而是希望能够为他们提供更加强大的数据分析和处理的功能。

本文致力于提供一个基于SysBase数据库的银行客户数据分析系统的解决方案。论文首先阐述当前银行业对数据挖掘工具的迫切需求，接着对银行客户数据分析系统做了详细的需求分析，包括系统的方案设计、可行性分析，然后对银行客户数据分析系统做了总体概述，概要介绍了系统解决方案，并以系统的数据库连接模块和分类模块为例，详细介绍了系统各模块的流程设计。论文的最后对文中所提出的解决方案进行总结。

关键词:数据挖掘分类决策树归纳最近邻分类 bagging 银行客户数据分析

1.概述 ................................................................................................................................................ 4

1.1.背景 ......................................................................................................................................... 4

1.2意义 ......................................................................................................................................... 4

2.银行客户数据分析系统技术难点 .................................................................................................. 4

3.银行客户数据分析系统的需求分析 .............................................................................................. 4

3.1方案介绍.................................................................................................................................. 4

3.2方案面向的用户群 .................................................................................................................. 4

3.3可行性分析 .............................................................................................................................. 4

4.银行客户数据分析系统的解决方案 .............................................................................................. 4

4.1系统解决方案 .......................................................................................................................... 4

4.1.1数据挖掘技术的实现步骤及方法 ..................................................................................... 4

4.1.2系统架构设计 ................................................................................................................... 4

4.2系统概述.................................................................................................................................. 4

4.3数据库连接模块设计 ............................................................................................................... 4

4.4分类模块设计 .......................................................................................................................... 5

4.4.1决策树归纳流程设计 ............................................................................................................ 5

4.4.2最近邻分类器流程设计 ........................................................................................................ 5

4.4.3朴素贝叶斯分类器流程设计 ................................................................................................ 5

4.4.5BAGGING算法以及改进的BAGGING算法流程设计 ................................................................... 5

5.结束语 ............................................................................................................................................ 5

参考文献 ........................................................................................................................................... 5

参考文献

[1] .L. Breiman. 1996. Bagging predictors. Machine Learning[J]. 24(7):123-140.

[2] .L. Breiman, Bias. 1996. variance and arching classifiers. Technical Report 460[R].

UC-Berkeley. CA.

[3] .R. Schapire. 1990. The strength of weak learnability. Machine Learning[J]. 5(8):197-227.

[4] .J. Quinlan. 1993. C4.5: Programs for Machine Learning[M]. [5] .D. Newman, S. Hettich, C. Blake, C Merz. 1998. UCI Repository of machine learning[M].

th[6] .W. Iba and P. Langley. 1992. Induction of one-level decision trees[A]. in Prof. of the 9

ICML Conference. 468-471.

[7] .Witten, and E. Frank, Data Mining. 1999: Practical Machine Learning Tools and

Techniques[M]. Morgan Kaufmann.

[8] .A. Kuncheva & C. Whitaker. 2003. Measures of diversity in classifier ensembles[A]. Machine Learning. 51(2):111-119.

[9] .S. Viaene, et al. 2004. A case study of applying boosting Na?ve Bayes to claim fraud diagnosis[J]. IEEE TKDE. 14(8):50-56.

[10] .X. Zhu and Y. Yang. 2008. A lazy bagging approach to classification[J]. Pattern Recognition. 41(15):215-221.

th ICML [11] .X. Fern & C. Brodley. 2003. Boosting lazy decision trees[A]. In Proc. of the 20Conference.

[12].A. Jain, R. Duin, and J. Mao. 2000. Statistical pattern recognition: A Review[J]. IEEE Trans. on PAMI, 22(1):15-21.

[13] .P. Sahoo. 1988. A survey of thresholding techniques[J]. Computer Vision, Graphics, and Image Proc, 41(2):89-95.

[14] .Xingquan Zhu, Chenyi Bao, Weidong Qiu. 2008. Bagging Very Weak Learners with Lazy Local Learning[A]. IEEE.

[15] .New Zealand. 1997. Waikato Environment for knowledge Analysis. the University of Waikato.

[16] .Pang-Ning Tan，Michael Steinback，Vipin Kumar著.2007.数据挖掘导论[M].范明，范

宏建等译.北京:人民邮电出版社.

[17] .K.P.Soman，Shyam Diwakar，V.Ajay著.2008.数据挖掘基础教程[M].范明，牛常勇等

译.北京:机械工业出版社.

[18] .Bruce Eckel著.2005.Java编程思想[M].陈昊鹏，饶若楠等译.北京:机械工业出版社.

[19] .孙卫琴编著.2006.Java面向对象编程[M].北京:电子工业出版社.

[20].Weiss, Mark Allen编著.2004.Data structures & algorithm analysis in Java[M].

北京:科学出版社.

[21].梁玉龙.2008.数据挖掘技术及其应用研究[D]:硕士.南京:南京邮电大学.

[22].王伟.2008.基于数据挖掘的银行客户分析系统的设计实现[D]:硕士.大连:大连理工大

学.

[23].高亚波.2008.文本分类系统的设计与实现[D]:硕士.北京:北京交通大学.

[24].Margaret H.Dunham著.2006.数据挖掘教程.郭崇慧,田凤占,靳晓明等译.北京:清华

大学出版社.

[25].李明壮.2008.基于决策树的数据挖掘算法研究与应用[D]:硕士.青岛:中国石油大学.

[26].沈学华，周志华，吴建鑫等.2000.Boosting和Bagging综述[J].计算机工程与应用.

[27].张翔，周明全，耿国华等.2009.Bagging算法在中文文本分类中的应用[J].计算机工

程与应用.

[28].王黎.2008.基于融合决策的多分类器系统研究[D]:硕士.西安:西安理工大学. [29].吴林.2009.基于J2EE B/S架构的金融业务软件开发工具[D]:硕士.合肥:中国科学技

术大学.

[30].孙源泽.2008.朴素贝叶斯算法及其在电信客户流失分析中的应用研究[D]:硕士.长沙:湖南大学.

本文由论文天下网整理。

范文五：金服平台数据分析系统各类日志数据采集方案

金服平台数据分析系统

各类日志数据采集系统总体方案修订记录

1. 金服平台移动 App 日志内容要求规范

1.1 日志系统需收集更多数据时移动应用采用埋点上传日志技术与 App 日志上传暂行规定

很早之前,也就是当年的 PC 时代,由于受限于存储和计算能力,大家一般很少用日志来分析业务。而是在业务逻辑里, 将业务需要分析的数据事先写入到库里, 针对库的数据进行统计分析。所以之前做 OLAP ,需要很高级的硬件支持,大家都去 IOE 等买昂贵的服务器来做数据仓库以及进行数据分析。由于成本的问题, 拿到的数据是很少的, 所以进行统计分析和挖掘所得到的收益微乎其微。

随着 Hadoop 的兴起,分布式文件系统和分布式计算大大降低了存储成本和计算成本, 使得现在用日志分析业务成为了可能。

1.1.1 移动 App 分析的数据类型

对于移动端的 App 来说, 分析的数据大致上都可以分为俩种, 一种是在线数据 , 一种是离线数据 ,还有 App业务需要的综合动态数据(简称动态数据)。

1.1.1.1 在线数据

在线数据 ,即 App 后端服务所产生的日志数据,例如服务接口的性能数据, 服务接口的调用及其参数等, 通过服务端的日志数据, 我们不但可以统计服务接口的性能指标, 还可以针对具体的业务逻辑,做相关的分析,一些常见的 App 分析指标如新增,活跃,累计, 留存等,也都可以通过服务日志来统计出来。

因为 App嵌入了移动 Web 的 Html5 页面,故 App的在线数据包含了 App 原生应用后端服务接口性能数据和移动 Web 日志数据。

1.1.1.2 离线数据

对应的离线数据即是 App 客户端本身产生的数据, 这种情况一般是发生在客户端不调用底层服务的情况下, 需要了解用户在客户端的行为, 就需要用到离线数据。离线日志一般记录用户在客户端的具体行为, 如用户在客户端的拖动, 上下滚动, 翻页等不涉及到后端服

务的操作, 以及 App 本身的崩溃行为产生的数据, 都可以被记录, 一般的, 记录的内容包括事件类型,控件编号,控件属性及相关参数,事件时间等。

因为 Html5提供离线功能应用 , 故这里的离线数据也要考虑离线状态下 Html5前端产生或者使用的数据。

对于离线数据还要考虑原生与 Html5 混搭 Hybrid 接口上原生到 JS 和 JS 到原生的数据调用情况。

1.1.1.3 动态数据

针对 App,为了统计和分析服务成功率、服务耗时、连接成功率和连接耗时等性能和质量,新增加除了上述在线数据和离线数据的第三种类型数据,暂时命名为综合动态数据 (简称动态数据 ) ,一个 (综合 ) 动态数据内容主要记录了用户开始操作一个 App 界面元素、发送 Http 请求、接收对应的 Http 响应、界面展现等时间点、过程中内存流量和处理失败原因, 对 (综合 ) 动态数据和与之关联的在线数据进行关联分析, 可以统计出服务成功率、服务耗时、连接成功率和连接耗时等性能和质量数据。

1.1.2 在线日志

在线日志,一般来讲,有两种:

?web 服务器的配置化 log(如 Nginx, apache等 web 服务器的 access.log) 这一类日志不需要用户自己做实现, 只需要开启 web 服务器的相关日志功能,即可完成日志记录。 ?应用服务器的 log 一般包括应用服务器的配置化 log 以及用户自定义的 log 。用户自定义 log 包括用户通过相关日志组件自己的 debug, waring ,error, info 等级别的日志。这一类日志没有固定的格式, 完全有用户自行控制。在线日志一般会伴随业务直接产生在相关的业务服务器上 (web服务器日志产生在 web 服务器上 ) ,但是有的时候,为了将相关服务的监控日志与业务分析日志分离, 会将业务日志直接记录在一**立的日志服务器上。

这里, App的在线日志主要包含上述 1.1.1 章节涉及的在线数据类型包含的 App 原生应用后端服务接口性能数据日志和 Html5移动后端 Web 日志。

1.1.3 离线日志

离线日志(和离线数据有关的),一般也有两种:

?客户端的 (本地 ) 行为日志 :用户在操作 App 的时候 (客户端不调用底层服务的情况下 ) 产生的行为,都可以记录下来。行为日志一般是用来研究用户使用习惯,分析应用的使用热度的。同时可以结合客户端异常日志来分析异常原因。

?客户端的 (本地 ) 异常日志:用来监控客户端异常原因,帮助解决相关问题。

针对 App的离线日志除了涉及到 App 客户端行为日志与异常日志,还要包含 Html5离线状态数据日志和 Hybrid 接口数据日志。

1.1.4 (综合 ) 动态日志

(综合 ) 动态日志是针对 App统计和分析服务成功率、服务耗时、连接成功率和连接耗时等性能和质量新增加的日志,该日志数据类型是上述 1.1.1章节涉及的 (综合 ) 动态数据。 1.1.5 埋点及上传

不管是在线日志, 还是离线日志, 或者 (综合 ) 动态日志 , 首先都要确认在什么地方记录日志 , 于是就引入了埋点的概念。通俗的讲, 在正常业务代码逻辑上, 添加记录日志的代码, 都叫做埋点。但是一般的,埋点只用来描述客户端日志记录。

由于在线日志是直接产生在服务器端, 日志采集工具可以直接从含有日志的服务器上采集日志数据到相应的文件系统,所以不存在日志上传的问题。但是对于离线日志和(综合 ) 动态日志来说, 数据是产生在 App 客户端的, 所以上传机制必须考虑。

1.1.6 离线日志和动态日志上传机制

业界采用的离线日志上传机制如下 :

①服务端提供日志记录接口, 当客户端有事件时, 直接调用日志记录接口将日志记录在服务器端。

②服务端提供日志上传接口, 客户端先将日志暂存客户端本地, 当达到一定的大小, 网络环境允许的情况下,通过上传接口,将日志文件打包压缩后上传。

第一种上传方式, 时效性方面有一定的保障 , 在网络环境允许的情况下, 能及时的将信息记录到服务器, 但是当埋点较多时,记录日志产生的流量会很大 ,占据很大的带宽,给

用户带来损失。同时,前端的某些行为,如在某个 activity 停留时间等也无法通过这种在线的方式捕获。还有一个重要的问题是, 由于客户端数据没有暂存机制, 当网络暂时无法使用时,日志记录接口无法正常调用,所有的日志也就随之丢失。

第二种方式, 在时效性上较差 , 因为它需要等待数据累计到一定程度, 或者网络允许的情况下,如在 wifi 情况下,才发送,但是占用的带宽相对较小,对客户端动作的捕获较为灵活。

对于的离线日志和(综合 ) 动态日志,建议采用第二种日志上传方式。

App 的实时日志和 PC-web 的页面实时日志在后台的 Action 或者 Controller 上处理, 详细参见 3.2 移动 App 和 Web 的实时业务日志采集方案。

1.1.7 埋点的三种方案

开发者直接在客户端埋点。 ?

优点: 开发者可以随意的在任何地方添加埋点。

? 缺点: 成本高,每次埋点的增删改都需要发版,很难控制。启明星现在采用的就是传统

的埋点方式, 由于之前没有统一的规划, 相关页面的同一个按钮, 不同的版本功能不同, 但却埋了同一个点,造成统计比较混乱。之后引入了埋点下发平台,虽然一定程度上缓解了这种问题,但是由于其灵活性以及主观性,问题依然无法避免。

由于传统埋点的一系列问题, 自然而然的就产生了可视化埋点的方案, 用可视化交互的手段来代替写代码, 将核心代码和配置, 资源分开, 在 App 启动时通过网络更新配置和资源来实现埋点功能。

可视化埋点的大体流程如下: ? 首先埋点服务平台与埋点客户机做关联, 包括客户机包含的埋点模块扫描当前整个客户

端页面的控件,形成控件树,并将当前页面截图,发送给埋点服务端平台;

? 埋点服务端平台接收到截图和控件树数据后, 在服务端重新绘制 App 界面, 通过可视化交

互的方式,给当前页面需要埋点的控件上添加事件,添加完毕后,形成配置文件, 并发布上线;

装有埋点模块的所有客户端,接收到配置文件并解析, 根据配置为页面中相关的控件添

加监听事件, 当这些控件出发事件时记录日志。

其中有很多细节的地方需要注意:

可视化埋点也需要考虑不同版本之间埋点的差异; ? 可视化埋点在分发埋点配置文件的时候,会有延迟或者丢失的情况, 有的客户端有可能

收不到或者很久才能收到配置文件,这样埋点的时效性会大打折扣。

所谓的无埋点,其实也就是全埋点,它和可视化埋点很像,可视化埋点是根据埋点配置来收集数据,而无埋点方案则是尽可能的收集所有控件的操作数据。实现原理也很简单, 客户端添加扫描代码,为每个扫描到的控件添加监听事件。当事件被触发后,记录日志。

其实,大家对此也不陌生,比如很早之前,对 PC 站点的统计,各大分析平台,都需要在网页之间添加一段 js 代码。其实那段 js 代码, 就是现在提到的无埋点的扫描代码。

这里强调一下, 由于可视化埋点是在需要的时候才埋点, 所以它并不能回溯事件, 也就是说, 只能统计需求提出后,埋点开始的所有的数据,埋点之前的数据是拿不到的。而无埋点方案, 在开始埋点的时候, 所有的数据已经都被记录了, 所以它可以查看之前的数据 (这里的之前也是相对与提统计需求的时间,而不是相对于埋点的时间 ) ,也就是说它可以做回溯。而这种回溯是建立在大量存储要求的基础上的。

App暂行采用传统埋点方案。

1.2 移动 App 日志内容参考格式 (具体根据需求确定 )

1.2.2 App客户端离线日志内容格式 (参考或草拟 )

device_model string 手机或终端的机型

resolution string 手机或终端的屏幕分辨率

os string 操作系统,如 : Android、 iPhone OS

os_version string 操作系统的版本

carrier string 移动运营商,如:中国移动、中国联通、中国电信

access string 连接的网络,如:2G 、 3G 、 Wi-Fi 、 4G

access_subtype string 网络类型,如:HSPA 、 EVDO 、 EDGE 、 GPRS 等

network_type string 根据 access,acess_subtype转化后的网络类型

school string 根据 client_ip如果为校园网解析出的学校 (由服务器分析 )

client_ip string 客户端 ip(是服务端获取到的外网 IP ,不是 app 上传的 )

longitude string 经度,

latitude string 纬度,

country string 根据 client_ip解析出的国家或地区 (由服务器分析 )

province string 根据 client_ip解析出的省、直辖市、自治区 (由服务器分析 ) city string 根据 client_ip解析出的地级市 (由服务器分析 )

district string 根据 client_ip解析出的区、县、县级市 (由服务器分析 )

session_id string 用户的一次会话 id ,就是 token

reach_time string

到达日志服务器的时间,此时间可作为日志时间直接使用,格式为:

yyyyMMddHHmmss (注意本字段在 App 上传时为空 )

event_id string 埋点的事件 ID(或者用户行为的标识 ID)

last_page string 当前页面来源页 (上一页 ) 的页面标题

Last_url string 当前页面来源页 (上一页 ) 的页面 URL, 可以是空

start_nowpage_time string 用户最初进入当前页面的时间点 (用于计算当前页面的停留时间 ) now_page_title string 当前用户离线行为发生时的当前页面

now_page_time string 当前用户离线行为发生时的时间

now_page_area_id string 标记点击所在页面的栏位所属的区域,如首页的个性化栏位

now_content_id string 表示业务内容的 ID ,例如栏目页的分类 ID ,搜词页的关键词,促销页的促销活动 ID ,详情页的商品 ID ,或者下单页的订单 ID

next_page string 当前用户行为导致的切换页面

next_page_timesize string 切换页面后打开页面时间大小

arg1 string 事件参数,当前页面更新时间点 (不涉及页面切换 )

arg2 string 事件参数,内存流量峰值 (参考

http://blog.csdn.net/wuxuehong0306/article/details/50698298)

arg3 string 事件参数 , 电池消耗下降峰值 (参考 http://www.cnblogs.com/hyddd/p/4402621.html) arg4 string 保留事件参数 1

arg5 string 保留事件参数 2

args string 事件参数, 00000表示事件成功, 99999表示离线行为事件的结果为失败 (arg1对应失败原因,如“ sysexit ” -异常退出;“ actfail ” -离线行为失败;“ sysdie ” -系统僵死 )

字段名类型注释

local_time string 终端时间 (格式为 yyyy-mm-dd hh24:mi:ss),上报服务器时的时间 local_timestamp string 终端时间 (格式为数字型的 unix 时间 , 精确到毫秒 , 可通过

from_unixtime函数转换成日期 )

utdid string 服务端生成的设备唯一标识符 (设备出厂参数有关,与 SIM 卡无关

)

user_nick string 长登录会员名称, 长登录是指只要登录一次就会记住该设备最近一次登录

会员, 即使该设备下一次打开 App 且没有登录, 其日志也会记录该设备最

近一次登录会员

user_id string 长登录会员 id

short_user_nick string 短登录会员名称,短登录是指当前处于登录状态的会员

short_user_id string 短登录会员 id

ds string 分区字段,表示日期,一般格式为 yyyymmdd

hour string 分区字段,表示小时,一般格式为 hh

abtest string 用于 AB 测试的流量分组 ID ,例如 a 表示第一组, b 表示第二组, c 表示

第三组 ,Z 表示当前 0组即没有分组

事件 ID (即 event_id)类型如下:

1.2.3 App客户端 (综合 ) 动态日志内容格式 (参考或草拟 )

当前字段有:

字段名类型注释 app_id string 当前统一为 888888

app_name string app_id对应的 app 中文名称

app_version string app 的应用版本号

channel string 应用分发渠道

imei string 移动设备国际身份码的缩写

imsi string 国际移动用户识别码

brand string 手机或终端的品牌

device_model string 手机或终端的机型

resolution string 手机或终端的屏幕分辨率

os string 操作系统,如 : Android、 iPhone OS os_version string 操作系统的版本

carrier string 移动运营商,如:中国移动、中国联通、中国电信

access string 连接的网络,如:2G 、 3G 、 Wi-Fi

access_subtype string 网络类型,如:HSPA 、 EVDO 、 EDGE 、 GPRS 等

network_type string 根据 access,acess_subtype转化后的网络类型

school string 根据 client_ip如果为校园网解析出的学校 (由服务器分析 ) client_ip string 客户端 ip(是服务端获取到的外网 IP ,不是 app 上传的 ) longitude string 经度,

latitude string 纬度,

country string 根据 client_ip解析出的国家或地区 (由服务器分析 )

province string 根据 client_ip解析出的省、直辖市、自治区 (由服务器分析 ) city string 根据 client_ip解析出的地级市 (由服务器分析 )

district string 根据 client_ip解析出的区、县、县级市 (由服务器分析 ) session_id string 用户的一次会话 id ,就是 token

reach_time string 到达日志服务器的时间,此时间可作为日志时间直接使用,格式为: yyyyMMddHHmmss (注意本字段在 App 上传时为空 )

event_id string 埋点的事件 ID(或者用户行为的标识 ID ,例如点击商品详情为。。。 ) , 和 App 访问服务器的原生接口方法名是一一对应的

last_page string 当前页面来源页 (上一页 ) 的页面标题

Last_url string 当前页面来源页 (上一页 ) 的页面 URL, 可以是空

start_nowpage_time string 用户最初进入当前页面的时间点 (用于计算当前页面的停留时间 ) now_page_title string 当前用户行为发生时的页面

now_page_area_id string 标记点击所在页面的栏位所属的区域,如首页的个性化栏位

now_content_id string 表示业务内容的 ID ,例如栏目页的分类 ID ,搜词页的关键词,促销页的促销活动 ID ,详情页的商品 ID ,或者下单页的订单 ID

now_page_time string 当前用户行为发生 (或者触发 click) 时的时间(一般情况与 arg4相同) next_page_title string 当前用户行为导致的切换页面

next_url string 当前用户行为导致的切换页面 URL, 可以是空

next_page_jumptime string 页面即将切换或者跳转的时间点

arg1 string 事件参数, (不是页面变换的 ) 当前页面更新时间点

arg2 string 事件参数,内存流量峰值 (参考

http://blog.csdn.net/wuxuehong0306/article/details/50698298)

arg3 string 事件参数 , 电池消耗下降峰值 (参考

http://www.cnblogs.com/hyddd/p/4402621.html)

arg4 string 事件参数,发送 http 请求时间点 arg5 string 事件参数,接收到 http 响应时间点 arg6 string 保留事件参数 1

arg7 string 保留事件参数 2

args string 事件参数, 00000表示事件成功, 99999表示事件失败 (argg1对应失败原因,如“ timeout ” -超时;“ netexcept ” -网络异常 )

字段名类型注释

local_time string 终端时间 (格式为 yyyy-mm-dd hh24:mi:ss),上报服务器时的时间 local_timestamp string 终端时间 (格式为数字型的 unix 时间 , 精确到毫秒 , 可通过

from_unixtime函数转换成日期 )

utdid string 服务端生成的设备唯一标识符 (设备出厂参数有关,与 SIM 卡无关 )

user_nick string 长登录会员名称, 长登录是指只要登录一次就会记住该设备最近一次登录

会员, 即使该设备下一次打开 App 且没有登录, 其日志也会记录该设备最

近一次登录会员

user_id string 长登录会员 id

short_user_nick string 短登录会员名称,短登录是指当前处于登录状态的会员

short_user_id string 短登录会员

ds string 分区字段,表示日期,一般格式为 yyyymmdd

hour string 分区字段,表示小时,一般格式为 hh

abtest string 用于 AB 测试的流量分组 ID ,例如 a 表示第一组, b 表示第二组, c 表示

第三组 ,Z 表示当前 0组即没有分组

事件 ID (即 event_id)类型如下:

2. 金服平台业务系统 Web 日志内容要求规范 2.1 网站 Web 收集数据常用方法简介

眼下网站分析数据主要有三种收集方式:

Web 日志、 JavaScript 标记和包嗅探器。 2.1.1 以 Web 日志的方式

Web 日志收集数据的过程示意图如下:

从上图可以看出网站分析数据的收集从网站访问者输入 URL 向网站服务器发出 http 请求就开始了。网站服务器接收到请求后会在自己的 Log 文件中追加一条记录, 记录内容包括:远程主机名(或者是 IP 地址)、登录名、登录全名、发请求的日期、发请求的时间、请求的详细(包括请求的方法、地址、协议)、请求返回的状态、请求文档的大小。随后网站服务器将页面返回到访问者的浏览器内得以展现。

一些专业的工具厂商会有专门的处理服务器对大量的 Log 数据进行处理, 并将处理后的数据存放入自己的数据库中。网站经营人员通过访问分析报表系统查看网站的分析数据。也有一些中小网站主出于成本的考虑不会求助于专业的工具厂商, 他们会借助简单的网站日志分析软件完成对 Log 数据的处理,当然处理后的数据会有一定的局限性。

2.1.2以 JavaScript 标记的方式 -又称“埋码技术”或者网络信标

JavaScript 标记收集数据的过程示意图如下:

上图所示 JavaScript 标记同 Web 日志收集数据一样, 从网站访问者发出 http 请求开始。不同的是, JavaScript 标记返回给访问者的网页代码中会包含一段特殊的 JavaScript 代码, 当页面展示的同时这段代码也得以执行。这段代码会从访问者的 Cookie 中取得详细信息 (访问时间、浏览器信息、工具厂商赋予当前访问者的 userID 等)并发送到工具商的数据收集服务器。数据收集服务器对收集到的数据处理后存入数据库中。网站经营人员通过访问分析报表系统查看这些数据。

网站统计中的 JS 方式的数据收集原理及实现,详情参见 http:

//www.admin10000.com /document /1089.html。

JavaScript 标记以其快捷性和精确性已经得到大多数工具厂商的青睐,已经发展成为当前最为流行的数据收集方式。

2.1.3 包嗅探器的方式

下图是包嗅探器收集数据过程的示意图。

定位。

当然也有一些网站为了获得多方面的数据而同时采取多种数据收集方式。例如采用 JavaScript 标记收集精确数据的同时,为了搜索引擎优化对 Web 日志中的搜索引擎爬虫记录也进行分析。也有已经采用包嗅探器收集数据, 但为获取缓存访问而同时进行 JavaScript 标记。

金服平台业务 PC Web 页面非实时日志采集方案采用 JS 标记 (埋码或者网络信标 ) 方式。金服平台业务 PC Web 页面实时日志采集方案, 详细参见 3.2 移动 App 和 Web 的实时业务日志采集方案。

3. 业务系统移动 App 日志和 Web 页面非实时日志与实时采集与收集方案

3.1 移动 App 和 Web 页面非实时日志采集与收集采用 Countly 框架 3.1.1 Countly简介

Countly 是一站式的数据分析平台,可同时跟踪移动和网络用户,分为社区版、云版本和企业版,版本提供的功能对比表如下:

Countly 是一款创新实时移动和 Web 分析软件, 专注于易用性、扩展性和功能丰富程度。 Countly 包括服务器、移动 SDK (适用于移动分析)或 Web SDK (适用于 Web 分析) ,所有组件均可根据许可条款在公司内应用程序中自由使用。

Countly 服务器部分由在端口 80 运行的服务组成, 允许系统管理员连接到用户界面并获取关于被跟踪应用程序的见解。移动部分包括适用于各种智能手机、平板电脑和桌面操作系统(Windows 和 Mac OS X)的 SDK 。 Web SDK 与之类似,用于跟踪整个站点的网页活动。

3.1.2 Countly自定义事件

自定义事件。它是一种可用于将任何类型的数据发送到 Countly 服务器的强大功能。基本结构

最简单的事件对象的结构如下:

JavaScript

{

}

以下属性是事件的唯一强制属性:

?key 识别事件

?count 是发生此事件的次数

如果事件与全部数值数据(如购买)紧密相关,我们可以使用 sum 进行跟踪:

?JavaScript

{

}

分段

在基础部分中, 我们会看到只有 count 和 sum 属性的示例 in_app_purchase事件。能够跟踪购买总数和购买总金额非常好,但有时我们可能需要更详细的信息:

?购买次数最多的是哪种商品?

?根据应用程序内购买哪个国家是顶级销售员?

?哪个应用程序版本销量更高?

通过分段可以对事件进行归类 /标记以回答所有这些问题和更多问题。通过简单地将分段键值对添加到事件便可以跟踪详细指标;

?JavaScript

{

}

3.1.3 使用 Countly 常见技术问题

请介绍 Countly 平台如何操作。

在应用程序中安装 Countly SDK 后, 该应用程序用户开始将事件数据发送至 Countly 服务器。 Countly 从这些事件中收集用户操作、行为、所使用电信公司等相关信息。

Countly 使用哪种语言编写?

正在使用 Node.js 和 MongoDB . 。后端和前端完全由 javascript 编写。您可以查看 API 代码 ,该代码从客户端 SDK 收集数据并将此数据写入数据库。

事件和会话数据如何发送至 Countly?

随着用户打开应用程序, Countly SDK 将开始按您定义的方式收集数据。对事件和会话进行收集,随后每 60 秒使用 HTTPS 请求发送至 Countly(或您的)服务器。

如果在应用内记录超过 10 个不同事件,甚至无需等到下次发送,将立即发送。

Countly 是否实时显示我的数据?

所有报告和图表均实时显示。后台中不运行批处理以可视化或收集数据, 因此无需等待下次处理运行。

Countly 是否会降低移动应用程序反应速度?

轻型 SDK 异步工作, 不会阻碍代码内任何函数调用。 iOS 性能分析表明 SDK 只占用总 CPU 使用量的 2%。与发送应用内视频的高 CPU 和数据占用服务相比,我们明显具有优势。

使用 Android 性能分析程序进行的测试表明, 在 5 分钟会话, 发送 5 个事件和 8 条请求的典型使用场景中,对于单核 CPU Countly 占用不到 0.1% 的 CPU 时间。对于多核 CPU, 此数值将低于 0.1%。

SDK 无法发送请求时会发生什么情况?

如果移动程序无法发送事件信息 (主要是由于设备未连接到互联网、用户乘坐飞机或地铁等事实) ,此时此信息将存储在非易失性存储器中。连接建立后,将立即发送至服务器并将数据从队列中移除。

Countly 服务器能够处理多少用户?

在测试中, 高配置服务器每秒可以处理 700 个事件,约为 20, 000 个并行移动用户。请参见实施和配置场景了解可选安装方案。但请勿将此数字作为参考, 该数字在很大程度上依赖于事件数量、网络负载、配置、磁盘速度、 RAM 大小和许多其他条件。

请注意这些数字适用于 Countly 社区版。

3.1.4使用 Countly 的用户

3.1.5移动和 Web 页面非实时日志采用 Countly 实现日志采集与收集实现方案 3.1.5.1 非实时日志收集与采集实现架构

3.1.5.2 Web页面定制 /埋点 JS(信标 ) 实现采集非实时 web 日志

1. npm install countly-sdk-web

2. 设置异步使用 Web SDK

异步使用 Web SDK , 不阻止加载内容, 并在它没加载统计脚本情况使用, 通过 Countly.q 调用或同步允许脚本加载。在页面的关闭前标签插入异步代码,举例如下:

3. 页面自定义事件

onclick =

自定义事件可跟踪您的网站上的任何行为。也可提通过分段(segments )查看段值 (segment values)以分解用户行为 , 举例如下:

Countly . q . push (['add_event',{

}

}]);

4. 采用辅助方法轻松地跟踪网络上最常见的行为

自动化跟踪用户会话 Countly.q.push(['track_sessions']);

跟踪页面浏览数 (page views) 使用 location.path 为页面名称跟踪当前页面 Countly.q.push(['track_pageview']);

Ajax web应用程序更新的内容和单页传递页面名称以记录新页面浏览记录 Countly.q.push(['track_pageview','pagename']);

其他常见行为不一一列举。

这些辅助跟踪网络常见行为的事件记录结构,详解参见 CountlyWebSDK 里

Countly.js 。

5. 修改 CountlyWebSDK 里 Countly.js 里 sendXmlHttpRequest(params, callback) apiPath的值

apiPath 对应 CountlyServer Web插件处理页面非实时 web 日志的 URL 路径后面部分。

3.1.5.3 CountlyServer Web插件定制 Ajax get/post处理 Web 页面非实时 web 日志

CountlyServer Web插件位置在 countly-server-master\plugins\web,需要处理前端页面非实时 web 日志的文件是 \web\frontend\app.js

1. 解析页面自定义事件

2. 解析网络常见行为 (请求事件 )

3. 归纳综合自定义事件和请求事件为统一页面采集非实时业务字段存入 Web 业务 log 文本文件

in_action_array数据结构里每个 action 字段表格

in_nonaction_array数据结构每个 action 字段表格

暂不设计。

3.1.5.4 安卓 APP 定制 /埋点实现采集非实时 app 日志

1. 基于 countly-sdk-android 实现采集安卓用户行为非实时日志的流程

2. 下载安装并添加 countly-sdk-android 到安卓 App 项目工程

3. 设置 countly-sdk-android

首先,您需要确定要使用的设备 ID 生成策略。

? 只需让该策略生效即可。在此情况下,最简单的方法最适用。切勿在服务器 URL 结尾放置后缀“/”, 否则将失效。

Countly.sharedInstance().init(this,

? 如有设备 ID 可自行指定(每台设备均唯一):

Countly.sharedInstance().init(this,

DeviceId.Type.ADVERTISING_ID)

? 也可以使用 OpenUDID:

Countly.sharedInstance().init(this,

Countly.sharedInstance().init(...) 方法应从应用程序子类(首选)或 onCreate 方法主活动调用。对于 OpenUDID,您需要将以下声明添加到 AndroidManifest.xml:

对于 Google Advertising ID , 请确保项目中已添加 Google Play 服务 4.0+。同时请注意 Advertising ID 会在设备上 Google Play 不可用导致 Advertising ID 获取失败时,在无提示情况下返回 OpenUDID。

调用 Countly.sharedInstance().init(...) 后,您需要为所有活动添加以下调用:

? 在 onStart 中调用 Countly.sharedInstance().onStart()。

? 在 onStop 中调用 Countly.sharedInstance().onStop()。

此外,清单文件中无 Internet 权限时,应确保设置 INTERNET 权限。

使用乱码器

乱码器为 OpenUDID 添加乱码,如将其用作 ID, Countly 将无法生成 ID,导致无法发送任何信息。因此您需要使用以下单行语句防止

OpenUDID 产生乱码:

-keep class org.openudid .** { *; }

注意:确保使用应用密钥(在管理 -> 应用程序下查找),而非 API 密钥。输入 API 密钥无效。

4. 设置自定义事件

以下示例中将以记录 purchase 事件为例,简单介绍各种用法;

? 用法 1:purchase 事件发生次数。

? 用法 2:purchase 事件发生次数 + 购买总金额。

? 用法 3:purchase 事件发生次数 + 购买发生国家 /地区和应用程序版本。

? 用法 4:purchase 事件发生次数 + 总金额,同时细分为发生国家 /地区和应用程序版本。 (1)事件键和计数

Countly . sharedInstance ().recordEvent (

HashMap segmentation = new HashMap (); segmentation . put (

(

Countly . sharedInstance ().recordEvent (

HashMap segmentation = new HashMap (); segmentation . put (

Countly . sharedInstance ().recordEvent (

请记住对要使用的细分键 /值对不存在限制,因此可以扩展以上示例和使用国家 /地区、 app_version、 game_level、 time_of_day 和其他细。

5. 一个实现简单例子

ackage ly.count.android.demo;

import android.app.Activity; import android.os.Bundle; import android.view.View;

import java.util.HashMap; import java.util.Map;

import ly.count.android.sdk.Countly;

public class ActivityExampleCustomEvents extends Activity {

Activity activity;

@Override

public void onCreate(Bundle savedInstanceState) {

activity = this;

super.onCreate(savedInstanceState);

setContentView(R.layout.activity_example_custom_events);

Countly.onCreate(this);

}

public void onClickRecordEvent01(View v) {