第四方物流信息平台运营研究

4.1面向业务的运营分析

      随着物流业务规模的不断发展，各类应用系统的数量和规模也迅速增长，其所产生的数据量也越来越大。在这些日益增长，趋近海量的数据中，除了核心的业务数据之外，还存在着一类规模巨大且未得到有效利用的数据，这就是日志数据。应用系统每时每刻都在产生日志数据，这些日志种类繁杂，格式多样，散落在生产系统的各个角落，往往只有在系统出现问题时才会临时到日志中去查找和分析，大部分日志数据都会在暂存一段时间后被永久清理。而这些日志文件作为应用系统在实际生产运行过程中的忠实记录者，包含了大量能够反映出应用系统运行情况的有效信息，这些信息可以对系统的优化、运维以及运营带来重要的决策参考。因此，如何克服当前商业银行应用系统中存在的日志量巨大、日志分布情况复杂、日志记录格式不规范等问题，实现对日志文件的有效分析，从中提取出有效的信息来指导生产、优化决策，成为面临的一项重大问题。

 

4.1.1系统画像模型研究

      目前大数据领域一个较为前沿的研究热点就是用户画像（Personas），所谓用户画像，即根据用户的一些基本信息及行为数据进行分析，在不同的维度，抽象出能够反映用户特征的标签，用标签的集合对用户进行描述。简言之，用户画像的核心即是标签的集合，根据不同的应用场景，定义不同的标签，再根据不同用户的标签，针对不同用定义不同的营销及推送策略，是用户画像在大数据领域的一个典型应用。

    同样，对于第四方物流的众多应用系统，每个应用系统都具有不同的运行特征，通过对这些不同的运行特征进行提取和归纳，形成相应的标签，其所组成的集合，也即本文所提出的应用系统画像。应用系统画像与日志分析可以完美的结合，从日志中能够提取到应用系统不同维度的有效信息，通过对这些信息进行计算，形成特征，而从这些特征中归纳出的标签的集合，即应用系统画像，又可以直观的让人们认知这个系统，从而对系统的运行特征、业务特征、性能特征等方面有一个充分的了解，进而对应用系统进行系统运维或运营策略的调整。

    第四方物流日志中类繁多，用途各有不同，经过前期的调查与研究，目前的日志大致可分为以下几个大类：

1. 交易日志：交易日志是指系统所记录的业务流水、交易报文等信息，可用于分析系统的业务特征，如交易量、活跃客户数、交易流动性等。
2. 应用日志：应用日志包括系统自身所记录的程序日志、数据日志以及后台服务日志，可用于分析该应用的运行情况，包括异常率、异常种类、响应时间等。
3. 系统日志：系统日志记录了系统所部属的物理载体的运行情况包括内存使用率、CPU 占用率、磁盘使用率等。

（4）运维与操作日志：运维与操作日志记录了系统的变更、应急以及日常操作行为，包括变更频率、变更成功率、应急次数、登录次数、登录时长等信息，可用于分析系统的奖状性、稳定性和安全性。

（5）网络日志：网络日志记录了应用系统的网络状态，包括丢包率、拥堵情况、带宽变化等，可用于分析该系统的网络联通性、交易顺畅性。

      以上五类日志，涵盖了第四方物流信息平台应用系统的大部分日志，而目前这五类日志并未得到广泛的应用和分析，大部分日志都设置了清理策略，在暂存一段时间后都会被永久删除。究其原因，一方面是因为目前日志数据的分析和管理尚未引起高度重视，目前应用系统仍然以响应业务为第一要素，系统上线后的运维也仅限于保证业务连续性等方面，虽然近些年来已经有一些利用大数据技术对系统数据进行分析的探索，但并未十分深入；而另一方面，也是由于对于日志的分析确实存在一些难点和问题。通过目前日志存储、产生、利用等相关情况的调查和分析，日志数据目前面临的几个问题主要有以下几个：

（1）日志规模大（仅包括企业、个人、手机等）一天产生的日志数量就达到 71GB，这还仅仅是应用日志及交易日志，如果再加上系统日志、数据库日志、网络日志等数据，保守估计每日会产生近 100GB 的日志数据。

每类系统每天都会产生大量的日志数据，传统的日志分析方法，如利用 Linux 脚本如 grep、awk 等已经无法满足如此海量日志的分析需求。

（2）日志格式不规范、

存储形式复杂且分散：系统组成复杂，有自行开发的，有外购的，有外购二次开发的，也有开源改造的，如此复杂的系统构成，再加上对日志格式并未有明确的书写规范，导致各类日志的记录格式多样且不规范。且各应用系统的日志多为分散存储，形式多样，应用日志有记录在数据库中的，有记录在文本文件的，系统日志在不同的平台上更是有不同的存储路径和格式，各类日志散落在不同的地点，缺乏统一收集和管理的平台。

（3）日志用途单一：目前对于日志的用途多是用来查找问题，当生产系统出现问题时，查找该时点的日志，分析该问题产生原因。对日志的利用相对来讲较为单一，没有对日志进行更深层次的挖掘和分析。

 

1. 标签自取

针对不同种类的日志，采取代理服务、文件传输、数据库、程序抓取、通信管道等形式对数据进行统一采集;处理层为架构的核心层，处理层包括三个阶段，从下至上分别是日志预处理及存储、日志特征提取和标签画像，完成日志的采集之后，首先要进行数据清洗、结构化、标准化、转码、特殊字段处理等预处理手段，且由于数据量巨大，需要采取分布式文件存储系统HDFS进行存储预处理之后，利用Hadoop分布式集群，编写MapReduce分布式处理程序，利用数据挖掘、统计分析等算法，从日志中提取有效特征;根据从日志中提取的特征，从基本信息、业务运营、应用运行、运维操作、物理环境等五个维度，将各类特征归纳为标签，形成系统画像。应用层根据系统画像可了解自己所关注的系统运行情况，从而做出最优的决策分析，典型的应用场景有运营情况分析、系统健康检查、安全审计等。

                          表 标签

基本信息C1	开发工具c11，上线时间c12，地点c13
业务运营C2	用户数c21，商品种类c22，交易生成量c23
应用运行C3	响应时间c31，QPS(TPS)c32、并发数c33、响应时间c34.
运维操作C4	应急次数c41，操作频率c42
物理环境C5	CPU占用率c51，内存占用c52，磁盘文件占用c53

1. 权重评分矩阵

（1）AHP法

首先将第四方物流信息平台用户画像层次化，根据问题的性质和要达到的总目标，将问题分解成不同的组成因素，按照因素间的相互关系及隶属关系，将因素按不同层次聚集组合，形成一个多层分析结构模型，最终归结为最低层（方案、措施、指标等）相对于最高层（总目标）相对重要程度的权值或相对优劣次序的问题。

运用层次分析法建模，大体上可按下面四个步骤进行：

1. 建立递阶层次结构模型；

2. 构造出各层次中的所有判断矩阵；

3. 一致性检验；

一致性指标：CI=λ−n/n−1，,CI=0时A一致，CI越大，A的不一致性程度越严重

 随机一致性指标RI：

维数	1	2	3	4	5	6	7	8	9
RI	0	0	0.58	0.9	1.12	1.24	1.32	1.41	4.45

 

一致性比率（用于确定A的不一致性的容许范围）

CR=CI/RI

当CR<0.1时，A的不一致性程度在容许范围内，此时可用A的特征向量作为权向量。

λmax=5.073对应于λmax的正规化的特征向量为：

ω(2)=(0.263,0.475,0.055,0.099,0.110)T

（2）基于TF-IDF的权重法

TF-IDF算法是什么思想，这里不做详细展开，简而言之：一个词语的重要性随着它在该文章出现的次数成正比，随它在整个文档集中出现的次数成反比。

比如说我们这里有3个系统和4个标签，标签和系统之间的关系将会在一定程度上反应出标签之间的关系。这里我们用w（P , T）表示一个标签T被用于标记用户P的次数。TF（P , T）表示这个标记次数在用户P所有标签中所占的比重，公式如下

例如：系统1身上打了标签A 5个，标签B 2个，标签C 1个，那么用户1身上的A标签TF=5/（5+2+1）。相应的IDF（P , T）表示标签T在全部标签中的稀缺程度，即这个标签的出现几率。如果一个标签T出现几率很小，并且同时被用于标记某用户，这就使得该用户与该标签T之间的关系更加紧密。

     然后我们根据TF * IDF即可得到该系统该标签的权重值。到这里还没结束，此时的权重是不考虑业务场景，仅考虑用户与标签之间的关系，显然是不够的。还需要考虑到该标签所处的业务场景、发生的时间距今多久、用户产生该标签的行为次数等等因素。总结下：

4.2交易监控分析研究

对于交易监控一般采用正态分布模型、 周均值波动和前 N 分钟波动模型等实时交易监控模型来实现。但是，常规模型存在探测维度单一、历史样本选择等问题，导致模型的检测效果较差。针对此问题，本文通过研究常规的交易分布和波动模型得出一种新型的IT 系统交易异常检测方法，即采用增加探测维度的方式有效提高对 IT 系统交易异常监测的准确性。

 

存在的问题 ：

一般认为不同日期同时点（纵向时间轴上）的交易数据基本服从同样的数据分布规律，所以常规模型（正态分布模型、周均值模型）通常直接选取同时点样本测 算纵向距离，并通过判断纵向距离是否超阈值来确定实 时交易数据是否异常。然而，常规模型存在以下四个缺 陷，导致模型查全率和查准率较低。

1. 仅监测纵向距离，容易产生无效报警

                       图 仅判断纵向距离问题示意

 

1. 历史样本数据选取问题导致模型失效无法命 中故障点 / 造成无效报警事件。 此问题主要有以下两种 表现形式：

①直接使用历史样本数据，纵向阈值线容易受极值 影响而失真走低，从而使模型失效无法命中故障点，如 图 所示。 故障期间，受样本极值的影响，模型失效，阈值异常走低，无法检测故障点。

                       图 模型阈值失真走低示意

 

② 在历史样本选取时直接剔除报警点，由于无效报 警量大导致剔除过多正常小交易数据点，造成纵向阈值 线失真走高，从而使模型失效产生过多无效报警，如图 所示。正常交易期间，由于模型失效阈值持续走高，导致产生无效告警。

1. 直接使用单点超阈值报警，造成交易毛刺产生无效报警。如图由于存在交易毛刺。导致产生单点无效告警。

1. 纵向距离检测模型选择问题。 常规模型的适用场景未明确，完全依赖人工选择， 容易造成模型选择不合适而失效。 由于周均值模型随机性较大，缺乏理论依据。

     新算法优先选择正态分布 3 倍标准差模型监测纵向距离。根据切比雪夫定理，对于任何数据集，位于平均值 3 倍标准差范围内的数据比例总是至少为 8/9(89%), 检测结果具有一定的统计学意义。而仅当交易量较小，且在数据离散度很大的场景下（一般变异系数大于 0.2 的情况下），数据自身随机性较高，纵向距离检测才建议选择周均值模型。

根据对异常交易模式的识别和现有模型问题的分析，提出本文多维交易监控算法。如图 6 所示。 选择纵向同时点样本数据，剔除最大三位数和最小三位数，避免极值影响检测模型效果。算法步骤如下：

1. 判断样本数据分布是否随机性高。 若否，则选择正态分布模型。若交易量小，且变异系数大（一般大于0.2），则数据随机性高，选择周均值模型。
2. Ti 时刻 , 判断纵向距离 是否超阈值。若正常，则不产生报警信息，算法结束。 若 异常，则转步骤 4。
3. 查看 Ti-1 时刻是否产生报警 , 或者是否有数据异常标记。若无，则转步骤 5。 若有，则产生报警信息，算法结束。
4.  判断横向距离是否超阈值，即相对 Ti-1 交易量是否下降超过 20%。 若超阈值，则产生数据异常标记。 若正常，则不产生报警信息，算法结束。

若系统故障期间，模型可全面检测出所有的异常数据（模型查全率高），且系统正常运行期间，模型不会产生过多无效报警（模型查准率高），则说明模型的生 产实用性较高。所以本文通过以下两个指标评价模型的有效性。

1. 故障命中率：

故障命中率 = 模型检测出的故障点总数 / 样本故障点总数

1. 无效报警量：

无效报警量 = 模型检测出的异常点总数 - 样本故障点总数

故障命中率越高（模型查全率高）、无效报警量越低（模型查准率高），则说明模型