技术博客


  • 首页

  • 关于

  • 标签

  • 分类

  • 归档

  • 搜索

数据驱动应用(五):基于时间序列数据的异常识别模型

发表于 2018-11-20 | 分类于 数据驱动 | | 阅读次数:
字数统计: 2.4k | 阅读时长 ≈ 8

抽时间将数据驱动的一些内容进行了总结,先整理下面五篇,后续将不断完善。。

  • 数据驱动应用(一):整体概述
  • 数据驱动应用(二):架构设计
  • 数据驱动应用(三):数据服务
  • 数据驱动应用(四):数据决策
  • 数据驱动应用(五):基于时间序列数据的异常识别模型

1. 概述

大型集群系统中,可能存在软件问题和硬件问题导致的系统故障,严重影响了系统的高可用性。这就要求7*24小时,对系统不间断监控。这就意味着需要不间断地监控大量时间序列数据,以便检测系统潜在的故障和异常现象。然而,实际当中的系统异常很多,且不容易发现;从而导致人工方式监控方式效率很低。

异常场景本质上是一个或者多个数据点;数据点一般在系统运行过程中产生,且能反应系统的功能是否正常,多以日志形式呈现。当系统功能发生异常时,就会产生异常数据。快速高效地发现这些异常值,对于快速止损具有重要意义。对此,我们提出一种基于时间序列的异常识别模型,用来及时发现异常。

对于多数系统,一般都有成功率、流量等指标,故障发生时,这些指标也会出现响应的异常。我们将系统成功率、流量统一称为特征值变量,并对其进行建模,从而方便后续其它特征变量的扩展。为了更好地感知这些特征变量的突变,需要对特征变量进行计算处理或者空间转换。那么异常识别问题就转换为以下两个问题:

  • 特征变量的计算处理和转换
  • 突变的判断

针对这两个关键问题,我们将在下文中进行建模和分析。

2. 异常识别

如下图,通过计算器进行特征变量的计算处理和转换,通过异常检测器来判断数值的突变,从而解决上面的两个问题。其中,异常检测器由比较器和决策器组成。

image-20180815093422131
image-20180815093422131

对于给定时间序列二维矩阵\(X=\{x^m_t∈R:∀t≥0, ∀m≥0\}\) ,\(x_t^m\)为\(t\)时刻的第m个指标的真实数据,\(u_t^m\)表示时间\(t\)的\(x_t^m\)的计算值,\(y_t^m\)为第m个指标的输出结果,\(y_t\)为整体预测结果。

\(x_t^m\)通过计算器得到计算值\(u_t^m\),然后\(x_t^m\) 和 \(u_t^m\)分别作为比较器的输入,得到第m个指标的输出\(y_t^m\)。\(y_t^1\),\(y_t^2\)…\(y_t^m\)作为决策器的输入得到\(y_t\)。\(y_t\)是一个二元值,可以用TRUE(表示输出数据正常),FALSE(表示输入数据异常)表示。下面对计算器和检测器进行说明。

2.1 计算器

计算器用来对输入值\(x_t^m\) 进行计算或者空间转换,从而得到特征变量的计算值\(u_t^m\)。一般情况下,特征变量具有趋势性、周期性等特征。基于这些特征,计算值的获取,可以使用以下三种方式:累计窗口均值计算器、基于趋势性的环比计算器、基于周期性的同比计算器。

2.1.1 累积窗口均值计算器

输入值为\(x_t\)(为了方便省略指标参数m),如果直接只用单个点\(x_t\)的抖动来判断,受噪声影响较大。因此,使用累积窗口均值的方式:

\[ u(t)={\dfrac{x_t+x_{t-1}+...+x_{t-w+1}}{w}} \tag{1}\]

其中,\(w\)为累计窗口的大小。通过窗口平滑之后,会过滤掉尖刺等噪声。

2.1.2 基于趋势性的计算器

为了描述数据的趋势性,引入环比类算法。对\(x_t\)进行空间转换,得到环比,再使用检测器进行检测。

\[u(t)={\dfrac{x_t+x_{t-1}+...+x_{t-w+1}}{x_{t-w}+x_{t-w-1}+...+x_{t-2w+1}}} \tag{2}\]

其中,分子为当前窗口\(w\)内的数据,分母为上一窗口\(w\)内数据。通过窗口\(w\)对数据进行平滑。

2.1.3 基于周期性的计算器

为了描述数据的周期性,引入同比算法。当同比值过大或者过小时,认为发生故障。同比公式如下:

\[u(t)={\dfrac{x_t+x_{t-1}+...+x_{t-w+1}}{x_{t-kT}+x_{t-kT-1}+...+x_{t-kT-w+1}}} \tag{3} \]

其中\(T\)为周期,\(k\)表示第几个周期。一般选取\(k\)为1、7、30,来表示昨天、上周、上个月。

2.1.4 其他类型计算器

计算器还可以使用其他算法,包括:

  • 统计类算法:包括同比、环比算法的改进,或者其他统计算法。此时,计算器的输出结果为预测值,预测值和输入值进行比较即可。
  • 时序型算法:包含ARIMA、Holter-Winter等时序型算法。计算器的输出结果为预测值。
  • 机器学习:根据有监督、无监督、深度学习(LSTM)等算法,训练出的模型即为计算器。此时,计算器的输出结果一般为归一化的值,根据归一化的值进行比较。

这些算法,在这里不再做深入研究和阐述。

2.2 异常检测器

当数据出现异常时,计算值会出现较大偏差,该偏差由异常检测器来判断。异常检测器由比较器和决策器组成,计算值和真实值通过该模块后,得到最终预测结果。

2.2.1 比较器

比较器的本质是求解如下公式的过程:

\[f(x^m_t,u^m_t;h^m)\ \ = \ \ boolean \tag{4}\]

其中,\(x^m_t\)为真实值,\(u\)为计算值,\(h^m\)为阈值参数,\(boolean\)为结果TRUE/FALSE。真实值已知,计算值通过计算器得到;剩下的阈值参数\(h^m\),则需要根据故障发生时的实际值进行参数估计。

很多场景下,该公式还可以简化为:\(f(u^m_t;h^m)\ \ = \ \ boolean\) ,即计算值直接和阈值比较即可。

2.2.1.1 比较器种类

比较器有两种:相对值比较器和绝对值比较器。给定计算值\(u^m_t\)和输入值\(x^m_t\),得到绝对值比较器:

\[f= x_t^m−u_t^m\ \ opretor \ \ h^m \tag{5}\]

其中,\(opretor\)为比较操作符,比如> < >= <=。由于\(u_t\)由\(x_t\)得到,所以很多情况下公式可以简化为 $ u_t^m    opretor    h_t^m$,即确定计算值的阈值即可。

对于一些场景来说,需要捕获特征变量的相对性。因此,引入相对值比较器:

\[ f={\dfrac{x_t^m−u_t^m}{u_t^m}}\ \ opretor \ \ h^m \tag{6} \]

通过对相对值比较器进行阈值处理,既可以检测异常值,同时还能对期望值进行归一化。

2.2.1.2 比较器阈值\(h\)的选取

一般情况下,阈值参数决定了异常检测模块的敏感度。最优阈值的选择,取决于数据分布的性质以及先验数据。一般情况下,阈值的选取方法为:

  • 方法一:跟踪一组故障数据和正常数据,根据经验估计阈值。
  • 方法二:跟踪一组故障数据和正常数据,根据经验,并结合3σ准则确定,来确定阈值。(特征变量或者特征变量的组合,服从正态分布)

2.2.2 决策器

如下公式,基于逻辑操作符,对比较器结果进行合并.

  • 方式一:逻辑组合

\[ y_t=y_t^1 \ \ \&| \ \ y_t^2 \ \ \&| \ \ y_t^3 \ \ \&| \ \ ... \ \ y_t^m \tag{7}\]

其中,\(|\)表示逻辑或操作,\(\&\)表示逻辑与操作。

  • 方式二:权重设置法

    \[y_t=k_1*y_t^1 \ \ + \ \ k_2*y_t^2 \ \ + \ \ k_3*y_t^3 \ \ + \ \ ... \ \ k_m* y_t^m \tag{8}\]

其中,\(k_m\)为系数,这种方式一般适合基本无负样本的场景,参数的确定需要使用层次分析法,将在后面的文章进行说明。

3. 故障止损

上面主要阐述了异常识别的方式。如果条件过于严格,刚开始并不容易被识别出来;如果条件过松,可能导致误识别。对此,我们将止损策略分为两级:

  • 级别一:预警。对于不能完全确定故障发生的场景,使用级别一。
  • 级别二:预警+止损(踢IDC)。对于能确定IDC故障的场景,使用级别二。

4. 实际场景应用

下面通过一个规则的场景,进行举例说明。假如存在如下异常场景:

image-20181108211144340
image-20181108211144340

体现在模型中,则级别一(预警)的模型图

image-20180815093336600
image-20180815093336600

级别二(预警+踢IDC)的模型图:

image-20180815093352931
image-20180815093352931

最终,得到故障识别规则:

  • 级别一触发条件: \(u_1<h_1 \ \ | \ \ (u5<h5 \ \ \& \ \ u6<h6 \ \ \& \ \ u7<h7 )\)
  • 级别二触发条件:\(u_1<h_2 \ \ \& \ \ u_3>h_3​\)

其中,\(h_1, h_2,h_3,h_5,h_6,h_7\)为阈值参数。需要结合经验和实际数据估计得到。

5. 小结

本文主要基于时间序列的数据,提出了异常场景识别模型,并重点对基于规则的识别进行了说明。

参考

  • Generic and Scalable Framework for Automated Time-series Anomaly Detection

数据驱动应用(四):数据决策

发表于 2018-11-20 | 分类于 数据驱动 | | 阅读次数:
字数统计: 2.9k | 阅读时长 ≈ 9

抽时间将数据驱动的一些内容进行了总结,先整理下面五篇,后续将不断完善。

  • 数据驱动应用(一):整体概述
  • 数据驱动应用(二):架构设计
  • 数据驱动应用(三):数据服务
  • 数据驱动应用(四):数据决策
  • 数据驱动应用(五):基于时间序列数据的异常识别模型

概述

决策引擎主要目标是将业务决策逻辑从系统逻辑中抽离出来,使两种逻辑可以独立于彼此而变化,这样可以明显降低两种逻辑的维护成本。下面列举三种方案,然后分析各自优缺点,从而确定本文的方案。

方案一:硬编码实现方式

优点:

  • 当规则较少、变动不频繁时,开发效率最高。
  • 稳定性较佳,语法级别错误不会出现,由编译系统保证。

缺点:

  • 规则迭代成本高,对规则的少量改动就需要走全流程(开发、测试、部署)。
  • 当存量规则较多时,可维护性差。
  • 规则开发和维护门槛高,规则对业务分析人员不可见。业务分析人员有规则变更需求后无法自助完成开发,需要由开发人员介入开发。

方案二:开源方案Drools

配置流程

使用 Drools 的规则配置流程如下图。一般只适合开发人员使用。

image-20181107174702180
image-20181107174702180

优点:

  • 策略规则和执行逻辑解耦方便维护。

缺点:

  • 业务分析师无法独立完成规则配置,由于规则主体 DSL 是编程语言(支持 Java,Groovy,Python),因此仍然需要开发工程师维护。
  • 规则规模变大以后也会变得不好维护,相对硬编码的优势便不复存在。
  • 规则的语法仅适合扁平的规则,对于嵌套条件语义(then 里嵌套 when...then 子句)的规则只能将条件进行笛卡尔积组合以后进行配置,不利于维护。

方案三:设计轻量级决策引擎

针对硬编码和drools方案的不足,我们开发了一套适用于运营、产品、业务、开发等人员的决策引擎。

下图是配置系统,业务人员配置决策、决策树和决策列表,开发人员负责配置底层更原子的一些组件:规则、动作和因子。随着平台积累和完善,逐渐也将规则、动作和因子交给业务人员去配置。配置后的决策元数据落地到决策库。决策引擎从决策库获取元数据,依次经过获取因子数据-->规则解析-->决策执行,将结果输出到数据应用层。

image-20181107181546309
image-20181107181546309

优点:

  • 规则配置门槛低,因此业务分析师很容易上手。
  • 系统支持规则热部署。
  • 业务和规则解耦,可以推广到别的业务。

小结

通过三种方案的分析,总结如下:

  • 硬编码迭代成本高。
  • Drools 维护门槛高。视图对非技术人员不友好,即使对于技术人员来说维护成本也不比硬编码低。
  • 自开发决策引擎,配置门楷低,可以方便推广到其他业务。同时,后期还可以扩展更多能力:灰度、试跑、效果评估等。

因此,我们自开发一套数据决策引擎。主要功能包括:

  • 基础决策能力:包含单个决策、决策树和决策表。

  • AI决策:部署训练后的模型,提供基于AI算法的决策。

领域模型

image-20181107192620073
image-20181107192620073

领域模型,由下往上依次为:

  • 决策的最小元素是因子,因子由数据字段的取值和可选项组成,可选项主要用作配置过程中,方便非开发人员选择可选的值。
  • 条件由因子和操作符组成,操作符包括:加、减、乘、除、包含、不包含等。
  • 规则由多个条件,通过连接符and/or组成。本质上,规则就是一些条件,通过语法树组合而成。
  • 决策输出的3种模式:
    • 决策:决策时对外输出的最小方式,由规则和Action组成。
    • 决策树:本质上是一颗多叉树,每个节点由规则和Action组成。根节点没有规则和Action,叶子节点必有规则和Action,中间节点必有规则(Action可选)。
    • 决策表:多个决策组成决策表。
  • 业务单元:用来做业务隔离,类似于类目管理的作用。不同业务单元之间的因子、规则模板和动作模板,都是相互隔离的。一般来讲,业务单元都是比较大的概念,整个公司不会有太多业务单元。

技术架构

image-20181107194934545
image-20181107194934545

架构主要流程:

  1. 最底层为数据层,HBASE主要存放一些实时计算的结果;MySQL为业务数据;API为http/https/dubbo接口数据,异步消息主要是Kafka数据。
  2. 算法平台使用数据层的数据,进行模型训练,再通过实时打分模块输出结果。结果输出给数据服务,或者直接输出到数据决策。
  3. 数据服务将数据层和算法的结果输出给数据决策。
  4. 数据决策模块,基于规则和算法模型,进行评分或者匹配,同时可以对结果进行排序。将决策的结果和动作,通过dubbo服务提供出去。
  5. 数据应用层使用数据决策和数据服务的能力,完成自己的功能。
  6. 通过埋点数据,进行决策效果评估和监控,评估的结果可以反馈给算法平台和管控平台。
  7. 管控平台,主要配置规则、因子、Action,进行灰度发布,规则试跑,多版本管理等。

数据决策的主要流程:

  1. 元数据加载:
    • 缓存:引擎运行过程中,需要使用缓存技术降低远程通信开销。
    • 预解析:缓存解析后的规则,而不是原始规则。从而,减小解析开销。
  2. 因子数据获取:获取决策所需要的实例数据,直接使用数据服务DS的输出。
  3. 执行:基于表达式解析引擎MVEL(表达式引擎性能对比,详见参考文档),提供决策、决策树、决策表3种决策能力。
    • 决策:多个规则和一个Action。
    • 决策表:N * (多个规则+1个Action)。注:决策表种的每个决策都有自己的优先级,默认值为100。
    • 决策树:通过深度优先遍历或者广度优先遍历,根据节点优先级,执行每个决策点。注:每个决策点,都有自己的优先级,默认值为100。
  4. 执行策略:针对决策树和决策表,两种模式:
    • ONCE:只将匹配的第一个叶子节点的结果返回。
    • ALL:将匹配到的所有叶子节点都返回。
  5. 结果拼装:
    • 执行路径拼装:主要针对决策树和决策列表,将执行路径返回。
    • 匹配Action:将所有匹配到的Action返回,同时返回其优先级。
    • Rank:主要是针对批量决策,将匹配到的结果进行排序,并返回。
  6. Facade:将拼装的结果通过统一接口返回。

系统实现

Facade接口

提供两种类型的决策:单个决策和批量决策。批量决策主要是为了减少多次接口调用的消耗。

语法树抽象

缓存

缓存的主键key为业务单元-决策类型-决策code。如下图:

缓存数据前需要对元数据进行预解析,从而决策引擎可以执行预解析后的数据。需要预解析的部分:

  • 将模型转换为表达式引擎可执行的形式。
  • 决策树:先遍历,将遍历的结果缓存。而不是每次都遍历执行树。

决策执行

将执行过程抽象为两部分:决策执行层和公共执行层。

  • 决策执行层:实现了决策、决策树和决策表的执行逻辑。
  • 公共执行层:为决策执行层提供公共的执行组件,包括动作执行器和规则执行器。

决策执行层

决策树执行器

加载元数据后,利用深度优先遍历的方式执行决策树,本质是一个递归的过程。执行方式有两种:ONCE,即执行的过程匹配到一个叶子节点后,停止执行;ALL,即要执行玩所有分支,才停止。执行结束后,对结果进行封装,并返回。决策树的节点,分为3种类型:根节点、中间节点和叶子节点。各节点和Rule、Action的关系如下表:

Rule Action
根节点 无 无
中间节点 有 无
叶子节点 可选 有
决策执行器

决策执行器是决策树执行器的一种特殊形式,即:一个只包含Action和Rule的节点。

决策表执行器

决策表执行器是决策执行器的List形式,也包含ONCE和ALL两种执行模式。

公共执行层

规则执行器

规则执行器的作用是,根据表达式和参数得到执行结果。底层采用成熟的表达式引擎来实现。为了方便扩展,使用工厂设计模式,可以方便地切换到不同的表达式引擎。各表达式引擎对比详见详见 表达式引擎性能比较。经过比对发现使用Mvel预编译,且指定输入值类型的方式效率最高,故采用该方式。该方式没有缓存,因此自己实现一层缓存,来缓存预编译的结果。同时,采用2小时无访问,则失效缓存的策略;从而防止堆积过多无用规则配置。

动作执行器

根据入参、规则结果和上下文,执行响应操作,得到结果code。Action的执行类型有多种,用户可以自己定制。下面说两种执行器:

  • 返回固定内容:匹配到规则后,直接返回配置的内容。
  • 返回动态内容:根据入参和规则结果,对其进行处理,然后返回动态内容。

小结

本文实现一个轻量级的决策引擎,本方案具有以下特点:

  • 规则表达能力强:通过决策、决策列表和决策树3种模式,可以覆盖多数的规则需求。
  • 接入成本低:统一的页面配置,统一的接口接入。
  • 规则运行/切换效率高:引擎运行过程中,需要使用缓存技术降低远程通信开销。同时,需要缓存解析后的规则,而不是原始规则。
  • 两种运行模式:执行模式和调试模式。
  • 易用性:方便配置,面向业务人员。
  • 易管理:通过因子、规则、动作等领域模型的抽象,更方便元数据的管理。通过业务单元进行业务隔离,从而既具有隔离性又具有复用性。
  • 规则迭代安全:规则支持热部署:系统通过版本控制,可以灰度一部分流量,增加上线信心。

当然本方案还有一些不足,比如没有实现复杂的决策场景,如动态规划、决策树剪枝等;没有实现复杂的规则能力。 ​
​

数据驱动应用(三):数据服务

发表于 2018-11-20 | 分类于 数据驱动 | | 阅读次数:
字数统计: 3.7k | 阅读时长 ≈ 12

抽时间将数据驱动的一些内容进行了总结,先整理下面五篇,后续将不断完善。

  • 数据驱动应用(一):整体概述
  • 数据驱动应用(二):架构设计
  • 数据驱动应用(三):数据服务
  • 数据驱动应用(四):数据决策
  • 数据驱动应用(五):基于时间序列数据的异常识别模型

概述

主要概念

  • 数据服务(Data Service):对异构数据源,基于有向无环图,提供异构数据的查询和推送能力。
  • 指标:用于衡量事物发展程度的单位或方法,它还有个IT上常用的名字,也就是度量。例如:人口数、GDP、收入、用户数、利润率、留存率、覆盖率等。
  • 维度:是事物或现象的某种特征,如性别、地区、时间等都是维度。一般指查询约束条件。
  • 粒度:维度的一个组合。描述分析需要细分的程度。
  • 数据集:用来描述数据从哪里来,有哪些字段输出,提供哪些能力(过滤、分组),数据表的Join关系,粒度等等
  • HTAP数据库:Gartner提出了HTAP数据库概念,一个数据库既能支持OLTP(在线事务处理),又能支持OLAP(在线分析处理),涵盖大部分企业级应用的需求,一站解决这些问题。

异构数据查询产品对比和分析

本文的主要目的是设计一个轻量级的异构数据查询和推送系统。首先,先看下主流的异构数据查询系统,如下表格:

Presto F1:Query Calcite TiDB
描述 分布式大数据查询引擎(SQL) 大数据异构查询引擎 动态数据管理框架 分布式 HTAP数据库
interactive交互式查询 提供 提供:集中式查询、分散式、批量查询ETL 支持 支持
数据源类型 多种 多种 多种 多种
支持自定义数据源 支持
使用公司 Facebook Google
代码开源 是 否 是 是
异构聚合 是 是 是
模式 Coordinator-Worker Master-Server-Worker
存储数据 否 否 否 是
分布式 是 是 是
ACID事务特性 分布式事务
UDF UDF server
水平弹性扩展 支持 支持
HTAP(OLAP/OLTP) 支持 支持
特性 批量化 + 异步化 + 流水线化DAG

空白部分,表示没有找到相关说明。

本文的目标

本文设计的数据服务,基于有向无环图DAG,对异构数据源进行处理和聚合,主要提供简单数据查询复合、复杂数据查询服务和数据实时推送服务。 优势

  • 轻量级的异构数据查询引擎
  • 结构化语义,无SQL
  • 融合数据管理
  • 支持异步消息的推送
  • 面向智能应用

存在的缺点

  • 不支持离线批处理
  • 不支持分布式计算
  • 只支持大量数据的异构join和聚合

三层数据集思想

根据功能和层次的不同,将数据集分为3类,由下向上依次为原子数据集、公共层数据集、应用层数据集,如下图所示。

  • 原子数据集:原子数据集是一层逻辑上面的概念,用来接入数据源,包括各种数据源的数据,如HBASE/MySQL/API等。
  • 公共层数据集:多个原子数据集沉淀之后,形成公共层数据集;当然,一个原子数据集也可以被多个公共数据集使用。前期,该层也是一个逻辑概念,需要随着时间慢慢积累;用来管理不同业务的数据,原则上同一个业务可以抽象为几个公共数据集。公共层主要起到 了管理作用,并确定统一的数据口径。
  • 应用层数据集:一个公共数据集可以产生多个应用数据集,面向智能应用,直接赋能给应用。
image-20181106201548669
image-20181106201548669

领域模型

如下图,领域模型分为逻辑层和物理层。

  • 物理层:数据源主要是各种数据的来源,包括MySQL、HBASE、kafka等。数据源里面的表抽象为物理表,表中包含物理字段,物理字段主要有维度、指标和标签3种类型。
  • 逻辑层:数据集是对物理表的逻辑抽象,一个数据集可能来自不同数据源的多个物理表,其字段称为数据集字段。对数据集字段包装的时候,可以使用自定义的Transform和UDF。通过主题来管理数据集,一个主题包含多个数据集,一个数据集也可以属于多个主题。
image-20181106202720647
image-20181106202720647

技术架构

image-20181106204030223
image-20181106204030223
  • 元数据管理:主要提供数据集、物理表、标签、指标等元数据能力。
  • Meta Data Local Cache: 提供元数据的本地缓存。元数据使用定时刷新机制。
  • 数据安全:主要是SQL注入等安全问题。
  • 数据权限:主要是权限的控制,分为数据集维度和字段维度的权限控制。
  • Query Parser:查询条件的解析,以及元数据的解析。一般减少每次解析的工作量,需要缓存解析后的元数据。
  • Query Plan Builder (构建执行计划):主要是根据查询条件和元数据信息,构建有向无环图DAG。这里是本系统的难点。
  • Optimizer (执行计划的优化):根据查询条件和元数据信息,对执行计划进行优化。
  • Scheduler (调度):根据构件好的DAG,调度相应的执行器Executor执行。
  • Executor (执行器):这里的执行,多线程并发执行。
  • Runner:主要是各种数据源的适配和性能优化,是一个原子的取数逻辑。主要是实时返回数据的数据库,不支持ETL离线型数据源。
  • Merger (合并):主要是数据的合并,可以抽象为left join和full join两种类型。
  • Assemble (包装):对字段进行包装,对行列数据进行转换。同时,可以自定义用户函数。这里会用到标签和指标元数据等信息。包装后的结果,将直接输出。

注:OLTP和OLAP两类查询是隔离的,OLTP为快查询,OLAP为慢查询,因为OLAP一般耗时会到1s左右,可能影响OLTP的性能。

系统整体设计

数据集设计

根据查询粒度的不同,将查询分为三类:多为统计查询、主键查询和非主键多条件查询。其中,主键查询和非主键多条件查询为单维查询,主键查询的维度就是主键。

-w661
-w661

1.多维统计

多维统计是由"维度+指标"组成的聚合类数据,即聚合字段(group by)+过滤字段(where)+筛选字段(select)。数据集中的粒度(grain)决定了需要输出的维度组合,聚合维度(group by)字段属于粒度的子集,查询条件中的维度字段属于聚合维度的子集。多维统计由多个异构主表(事实表)内存Join,分别查完后按同粒度Grain进行join后输出。如下图所示,两个事实表包含相同的维度,不同的指标,经过内存join后,输出所需指标和维度。

image-20181107102744337
image-20181107102744337

2.单维详情查询——按主键PK查询

通过主键(PK)查询主表一条记录,通过主表的外键查连接其他表(一般是维表)的数据,并且可以支持多级连接,支持多个主表查询。通过主键,在内存进行merge join,输出结果一般为单条记录。

3. 单维详情查询——非主键查询

通过非主键的各种条件,查询一批主表记录。该查询中需要有一个确定的主表,通过主表来对结果进行分页查询;其他的表均为关联表,通过主表的外键连接多个关联表。

image-20181107111452242
image-20181107111452242

参考:

  • 大数据分析:多维数据分析基础与方法(钻取、切片和切块)

系统详细设计

系统流程

如下图,描述了整个系统的设计流程上的关键部分,同时,对各部分的关键点和设计模式进行了说明。

image-20181107113511326
image-20181107113511326

元数据加载

该部分主要做了:入参解析、元数据解析、元数据缓存。

  • 入参解析:将用户的查询解析为系统参数,主要包含3种解析类型:GroupByQuery/PkQuery/NormalQuery

  • 元数据解析:将数据库非结构元数据解析为结构对象,减少每次结构化的成本。同时,将查询入参和结构化元数据进行合并,得到一个内部对象。

  • 元数据缓存:缓存采用定时刷新机制。根据数据集name加载数据集配置信息,包含:数据集、数据集字段、用到的物理表和用到物理表的字段。

执行计划构建

执行计划构建就是根据请求参数和元数据,生成数据查询的执行计划。构建的查询计划是一个有向无环图DAG(Directed Acyclic Graph),每个节点是一个原子数据集。执行计划生成逻辑如下图,左边为加载的元数据信息,中间为执行计划构建流程,右边为执行计划的内容。

执行计划调度

执行计划调度是指,根据前面构建的执行计划DAG,分配线程、调用Runner执行查询,再合并结果。

执行模式

DAG的执行过程,就是执行各个子节点(原子数据集)的过程。根据每次执行节点数的不同,分为三种执行模式:Single模式,串行模式、并行模式。如图,每个阶段均为一次原子执行,同时节点中还可能包含合并merge操作。

  • single模式:一次只支持一种原子查询。
  • 串行模式:支持多次原子查询及合并。在同一个线程中串行执行,有多少个节点就串行执行多少次。
  • 并行模式:支持多次原子查询及合并。在多个线程中并行执行。根据DAG层数进行调度,即DAG有多少层,就并发执行多少次。执行过程中,每次执行入度为零的所有节点。如图所示,第一次执行node1/node2/node4,第二次执行node3,第三次执行node5。
-w676
-w676

调度执行过程

如下图,左侧为执行环境(元数据),右侧为调度过程。首先将DAG拍平,每次找出入度为零的节点执行、合并结果,执行完该节点后,对被引用的节点入度减一。递归执行,直到所有节点入度为-1。

-w526
-w526

Runner执行

类似于jdbc模块的方案,本文使用SPI(Service Provider Interface)机制发现服务,从而实现模块的解耦。同时,如果需要在外部开发定制Runner,使用SPI机制可以更好地实现。Runner种类包括MySQL、HBASE、kafka、dubbo等。下面主要介绍一种实现,即SQL类Runner:SqlRunner

SqlRunner

如下图所示,SqlRunner主要作用是将结构化的对象解析为数据库可执行的SQL。解析工具包括:FilterBuilder、JoinBulider、GroupByBulider、SortBuilder、PageBuilder。

FilterBuilder
  • 根据Filter构造Where子句。需要对"=”、"in”、"range”、"like"四种类型的Filte进行解析。其中,range条件已经被上层区分为“>”、“>=”、“<”、“<=”,可以与"="、"like”共同视为单一条件值条件,组装为“字段操作符条件值”,其中条件值要根据类型决定是否加单引号。
  • 特殊类型字段(如时间) 需要根据底层DB的标准进行翻译。
JoinBulider

构造Join子句,包括left join和full join。

GroupByBulider

根据grain字段构造group by子句,聚合列以grain为准。

SortBuilder

取OrderBy对象中的字段名和升降序类型拼接ORDER BY子句。

PageBuilder

取原子数据集上面的pageSize和pageNum字段。如果~,则无偏移;否则用(pageNum-1)*pageSize计算偏移,拼接LIMIT子句。

Kafka-Runner

系统监听指定的Topic消息,收到消息后进行处理,并以异步消息的方式再把消息发送出去。其中,发送出去的消息中,携带其他异构Runner的数据信息。

执行流程

如下图所示,接收到消息后,通过KafkaRunner处理后,再将消息发送出去。

  • 接收端:
    • 接收不同的topic,接收的topic对应于领域模型的Table。使用同一个groupId,每个消息只接收一次。
    • 将入参解析为KV的map,本期只解析一层,后续有需求再支持解析多层。
    • 异步数据集,只能通过消息来触发。
    • 一个数据集只支持引用一个Topic。(引用多个Topic,会导致消息等待的问题,暂时不考虑支持这种复杂场景。)
  • 发送端:
    • 将经过处理后的数据,以消息形式发送出去。对应领域模型的数据集Dataset。
image-20181107155543474
image-20181107155543474
运行时更新Topic

对于Kafka,一张物理表对应一个Topic。动态新增一张表的时候,需要在运行时,定时更新其对应的Topic。其中的关键点在于,更新Topic要保证在元数据加载完成之后,否则,可能导致接收到的消息数据,无法消费发送出去。kafka对自动新增和删除topic支持不是很好,需要自己实现一些内容。具体可以参考下面链接。

参考:

  • how can i set consumer's topic by code
  • https://github.com/spring-projects/spring-kafka/issues/213

数据组装

组装器是对字段或者行列的处理,包含包装、转换、排序、内存分页。

  • 包装:针对单字段的处理。
    • 类型转换包装
    • 展示数据包装
    • 可视化参数包装
    • 字段跳转URL包装
  • 转换:行列转换、多行转单行等。
  • 排序:主要是对异构合并的数据进行排序。优先使用Runner自身的分类器。
  • 分页:对异构合并的数据进行分页返回。总条目数不宜过多。

总体原则:优先使用底层的能力,比如要分页的时候,如果Runner底层不能满足的时候,才使用上层的Pager。或者要进行数据合并时,优先使用数据库自身的join,不能满足时再考虑内存Merger。

小结

本文主要介绍了一个轻量级的异构数据查询和推送系统。由于内容较多,本设计的很多细节没有深入介绍。

数据驱动应用(二):架构设计

发表于 2018-11-20 | 分类于 数据驱动 | | 阅读次数:
字数统计: 2.3k | 阅读时长 ≈ 7

抽时间将数据驱动的一些内容进行了总结,先整理下面五篇,后续将不断完善。

  • 数据驱动应用(一):整体概述
  • 数据驱动应用(二):架构设计
  • 数据驱动应用(三):数据服务
  • 数据驱动应用(四):数据决策
  • 数据驱动应用(五):基于时间序列数据的异常识别模型

整体概述

在本文中,我们采用整体到部分的分析思路。首先介绍大数据系统在整个公司架构中的位置,然后具体介绍大数据系统的架构实现,再次对大数据系统中的数据驱动部分进行分析,最后对数据驱动中的各个部分依次概述。 ## 整体架构 首先,我们需要确定大数据系统在一个公司整体架构中的位置。为了方便分析,我们引入云计算中的四个概念来设计整体架构,包括:IaaS、PaaS、SaaS、DaaS。不同于云计算中服务的概念,本文主要使用这4个概念对整体架构进行粗略划分。如下图,各层依次为:

  • IaaS:意思是基础设施即服务。主要包括虚拟机、网络、负载均衡等一些基础设施。
  • PaaS:意思是平台即服务。主要包括限流、通讯(RPC/http)、消息组件、注册中心、安全组件、文件系统等平台类软件。
  • SaaS:意思是软件即服务。主要是公司的业务应用,具有很强的领域特性。
  • DaaS:意思是数据即服务。可以简单的理解为,大数据系统是DaaS的一种实现形式。这里我们将其分为五层,由下往上依次为:采集层、计算层、存储层、驱动层、应用层。
image-20181103180601858
image-20181103180601858

大数据系统架构

架构分层设计

如下图,结合上篇文章介绍的数据金字塔理论,得到如下分层。

  • 纵向分析:由下往上是一个逐步递进的关系,最上层数据量最小,但是为最有用的部分。大数据系统架构,主要从数据流的角度出发,将其分为:采集层、计算层、存储层、驱动层、应用层。
  • 横向分析:如图所示,通过颜色将金字塔理论和架构分层映射起来,渐进色表示涉及到了多层。
    • 采集层:对应金字塔理论的“数据”。
    • 计算层和存储层:对应金字塔理论的“数据”、“信息”和“知识”。
  • 应用层和数据驱动应用层:对应金字塔理论的“知识”和“AI”。
image-20181103181134952
image-20181103181134952

架构设计

如图所示,为大数据系统的架构图,主要分为采集层、计算层、存储层、驱动层、应用层5层。大数据系统根据采集的数据,使用实时计算和离线计算能力进行初步加工,然后,再利用规则、算法等能力赋能数据应用。

image-20181103181314458
image-20181103181314458

采集层

致力于全面、高性能、规范地完成海量数据的采集,并将其传输到计算层。被采集的数据种类包括:数据库数据和日志数据。

  • 数据库数据:一般是采用T+1方式,离线同步到Hadoop。
  • 日志数据:包括应用日志和系统日志,通过Flume采集日志,以Kafka消息的方式实时同步给Storm集群和Hadoop。

计算层

采集层得到的数据,将进入数据计算层中被进一步整合和计算。数据只有经过计算和整合,才能被用于洞察商业规律,挖掘潜在信息,从而实现大数据价值,达到赋能于商业和创造价值的目的。对于海量的数据,从数据计算频率来看,包括实时计算和离线计算两种方式。

  • 实时计算:一般采用Storm、Spark等技术,提供秒级的计算能力。
  • 离线计算:一般采用Hadoop技术。数据计算频率主要以天(还包括小时、周、月)为单位,比如T-1,则每天凌晨处理上一天的数据。接收kafka消息数据,计算的结果输出到存储层,或直接给驱动层。

工具平台提供数据管理、开发和整合的方法体系。用来构建统一、规范和可共享的全域数据体系,避免数据冗余和重复计算,规避数据烟囱和不一致性。

存储层

该层主要用来存储计算层加工后的数据。

  • 关系型DB:用来存储业务数据和元数据。
  • 分析型DB:用来存储报表、多维查询类数据。一般RT较高,为百ms级别,甚至s级。
  • 时序型DB:用来存储状态数据、时间序列数据。
  • 消息:以推的方式将数据传输到上层。
  • KV数据库:实时计算的结果一般流出到Hbase,Hbase为分布式架构,方便扩容,从而做到容量大、QPS高、低RT。
  • API(Dubbo/Https)提供一些业务系统数据,或者公司外部数据。注:业务相关的DB,通过dubbo接口查询。
  • 缓存数据:通过分布式缓存对数据查询进行加速。

数据驱动层

该层主要是给数据应用层提供平台能力。包含3大部分:

  • 数据服务:提供数据的查询和推送能力。
  • 数据决策:提供数据的决策能力。
  • AI算法平台:特征提取、模型选择、参数校验、模型训练。

应用层

基于数据服务、数据决策和AI算法这些基础能力,创建数据驱动型的应用。

管控层

提供数据的管理能力、监控能力、运维能力等,包括:配置管控、数据治理、元数据管理、血缘关系管理、监控、运维等。

数据驱动的架构

数据驱动的思想和架构对应关系

上篇文章讲到了数据驱动的思想,现在将其对应到架构中,则对应数据驱动层和数据应用层。如下图,感知器即为数据服务模块;决策器为数据决策模块和AI算法模块;执行器为数据应用层。

image-20181103181723636
image-20181103181723636

数据驱动的架构

下面对数据驱动的架构进行详细说明。下图是数据驱动的关键架构,也是我们要探讨的重点内容。

image-20181103181931158
image-20181103181931158

数据服务

通过接入数据存储层的各种数据源,基于异构分布式数据库访问层DAG,实现了对异构数据源进行处理和聚合,主要提供简单数据查询复合、复杂数据查询服务和数据实时推送服务。该模块主要将能力输出给数据引用层,好比将眼睛有选择地看到一些事物,然后传输给大脑。

AI算法平台

包括统计类算法、机器学习、深度学习、时间序列算法等。该模块接收存储层的数据进行离线训练得到所需算法模型,在对新数据进行预测。就好像大脑基于历史经历得到经验,经验即为模型。

数据决策

基于规则引擎、动作、决策树,提供决策能力。同时,也可以使用算法平台的算法能力进行决策。好比大脑根据经验,做出决策结果。

数据应用层

对于多类数据应用,抽象出执行组件和状态管理两部分。基于这两类组件,可以构建出行领域、运营领域、风控领域、信用领域等应用。该层使用了数据驱动层的平台能力,可以方便的创建各类数据应用,让数据快速、方便、有效地发挥价值。该层负责将眼睛看到的新数据传输给大脑,得到大脑的决策结果后,再用手去执行。

数据管理

对计算层、数据服务、数据决策、AI算法平台、数据应用层的配置进行管控。计算层包括Pipline、DSL、Transform、UDF等元数据;数据服务包括数据集配置和数据资产管理;算法平台包含算法相关配置;决策模块包括决策配置、规则配置、动作配置和算法配置;应用层包括各个应用的配置。

小结

本文重点讲述了数据驱动的架构。在后面的文章中会依次介绍数据服务、数据决策、算法3部分的详细架构实现。对于数据采集层、数据计算层和数据存储层成熟方案已有很多,非本系列文章重点。

参考

  • 大数据之路——阿里巴巴大数据实践
  • 数据即服务(Data as a Service; DaaS)
  • 云计算四层分——IaaS、PaaS、SaaS、DaaS

数据驱动应用(一):整体概述

发表于 2018-11-20 | 分类于 数据驱动 | | 阅读次数:
字数统计: 1.7k | 阅读时长 ≈ 5

抽时间将数据驱动的一些内容进行了总结,先整理下面五篇,后续将不断完善。

  • 数据驱动应用(一):整体概述
  • 数据驱动应用(二):架构设计
  • 数据驱动应用(三):数据服务
  • 数据驱动应用(四):数据决策
  • 数据驱动应用(五):基于时间序列数据的异常识别模型

概述

随着互联网的快速发展和广泛普及,产生的数据也在呈几何倍数增长。数据成了企业至关重要的资源,企业产生、收集和分析的数据也达到了前所未有的规模。从而,进一步加速了大数据技术的快速发展。

近几年,出现了各种驱动技术,包括产品驱动、技术驱动、政策驱动等,大数据也不甘寂寞,于是乎“数据驱动”一词也渐渐热了起来。那么到底什么是数据驱动呢?在讨论数据驱动前,先看几个不同领域的场景:

  • 运营场景:当你在下午五点来到商场时,口碑或者美团自动给你推送“XX火锅优惠券”,正好这就是你非常喜欢吃的火锅店,于是你毫不犹豫地选择去消费。
  • 出行场景:当打滴滴快车出行,到达目的地后发现比预计费用多了一倍,此时滴滴自动提醒你司机是否绕道,点击“是”后自动把你多付的钱退了回来。
  • 运维场景:当系统或者业务在运行过程中出现问题时,自动根据历史数据和当前数据识别该故障故障,并快速止损。
  • 客服场景:当你在支付宝咨询智能客服时,根据你的提问,并结合你的历史操作,给出最佳解答。

数据驱动是指,以公司内部数据(业务数据、系统数据)和公司外部数据为基础,对数据进行组织形成信息,之后利用规则、算法、机器学习、深度学习等手段进一步处理信息,最终形成自动化的决策模型,同时还要形成闭环,自动调整决策模型。当新的情况发生时,系统利用前面建立的决策模型,以人工智能的方式,对新数据进行处理,得到决策结果。

数据金字塔

为了更好地理解数据驱动,我们引入数据分析模型——数据金字塔理论。数据本身是没有意义的,如果它不能转化为信息和知识的话;但如果没有数据,或者数据匮乏,信息和知识的产生也就成了无水之源。数据金字塔理论可以帮助我们理解数据、信息、知识和人工智能的关系。

在数据金字塔(即 DIKW pyramid)体系中,每一层比下一层赋予某些特质。数据层是最基本的,信息层加入内容,知识层加入“如何去使用”,智慧层加入“什么时候才用”。

  • 信息:是被组织起来的数据,是为了特定目的对数据进行处理和建立内在关联,从而让数据具有意义,它可以回答谁(who)、什么(what)、哪里(where)、什么时候(when)的问题。
  • 知识:对信息的总结和提炼。是基于信息之间的联系,总结出来的规律和方法论,主要用于回答为什么(why)和怎么做(how)的问题,在企业里的应用包括问题诊断、预测和最佳做法。
  • 人工智能:机器对信息和知识的自主应用。人工智能是系统基于数据、信息和知识,形成类似于人脑的思维能力(包括学习、推理、决策等)。在信息和知识层面,数据都是提供决策支持作用,而到了人工智能阶段,则是系统模仿人类应用信息和知识进行自主决策了。

总之,DIKW理论是一个数据分析模型,由下往上依次递进,其递进关系需要借助数据驱动技术实现。

数据驱动型应用

​ 数据驱动型应用是数据驱动的体现形式。从数据到应用,它是一个不断进化的过程。如下图,主要包含这四步:数据获取、数据应用、效果评估、算法挖掘。通过数据采集得到日志数据、关系型数据、事件数据。基于决策模型和算法,形成具体的应用和产品,包括可视化类、推荐类、客服类、风控类、保险类等产品。再通过效果评估和算法挖掘形成的闭环,自动调整模型、改进结果。

image-20181101132248766
image-20181101132248766

数据驱动型应用功能抽象

​ 每个智能应用都可以分解为感知器(眼)、决策器(手)、执行器(脑)。如下图,基础能力层提供这3类基础能力,智能应用层使用这3类基础能力,快速组装成需要的各种智能应用。

image-20181101132442134
image-20181101132442134
  • 感知器是智能应用的眼睛。就像人有两只眼睛一样,智能应用可以基于有向无环图DAG获取多种数据源的数据,甚至可以将多个数据源数据进行聚合,比如同时获取消息数据和数据库数据。这些数据可以通过推和拉两种方式,提供给智能应用。
  • 决策器是智能应用的大脑。决策器是整个智能应用的核心所在,主要提供规则决策、决策树、统计类算法、AI等决策能力。规则决策是基于简单规则的决策,决策树提供有优先级的复杂决策。统计类算法提供概率统计相关的一些算法,包括同比类算法、环比类算法、时间序列算法等。AI主要针对复杂场景,并且有足够的数据量,可以提供机器学习、深度学习能算法能力。
  • 执行器是智能应用的手。执行器主要用来执行任务,将执行过程抽象为工作流。将各种执行能力不断积累下来,从而方便智能应用的快速实现。

小结

本文首先介绍了数据驱动的基本概念和相关理论,然后引出了数据驱动型应用的基本思想和功能抽象。下一篇文章将主要介绍数据驱动的整体架构。

参考

  • 什么叫做「数据驱动方法」

  • 数据驱动到底是什么?如何驱动,又能驱动什么?
  • 数据驱动产品智能——数据应用与用户智能
  • 数据驱动:从方法到实践
  • 基于 AIOps 的无人运维

12…8
DanielJyc

DanielJyc

数据驱动 Java 大数据 算法

40 日志
5 分类
28 标签
RSS
Links
  • Danieljyc blog
© 2014 — 2019 DanielJyc | Site words total count: 53k
由 Hexo 强力驱动
|
主题 — NexT.Muse v5.1.4
京ICP备 - 19007489号