随着社会经济的快速发展以及机动车保有量的急剧增加，城市交通拥堵和污染日益加剧，如何完成城市交通行业的数据采集，以及如何从海量数据中挖掘有效信息，进而改善城市交通状况成为各方关注的焦点。

通过大数据分析，解决城市交通存在的问题，首先要解决的是数据来源。交通数据主要从以下几个方面获得：

交通路网上的视频监控数据、流量采集数据、交通事件数据；道路运输车辆的卫星定位数据和车辆驾驶人员的驾驶行为数据；公安交通管理部门的交通信号控制数据、交通卡口数据和执法数据；交通运输部门采集的客流数据，如城市一卡通刷卡数据、联网售票数据等；用户手机信令、手机App产生的手机UGC数据等。

基于交通行业不同渠道产生的海量数据，有关各方都在积极挖掘和探索数据背后蕴含的奥秘与规律，以期构建一个开放、共享、智慧的出行平台，为城市更加智能、出行更加便捷提供自己的产品和服务。

作为在智慧交通领域耕耘了近二十载的自主创新型企业，千方科技积累了海量的交通数据资源。目前在千方科技的系统平台上，浮动车数据覆盖货运/物流车辆、出租车、私家车等，日均产生超过100亿个定位数据。基于这些数据处理生成的动态交通信息服务覆盖全国200余城市，全国所有高速和90%以上国省道路。

基于自研的大数据平台，千方科技在不断提升数据鲜活度的同时提供丰富的交通信息服务。在2017年的金砖国家峰会、十九大，2018年的全国两会以及上合青岛峰会等重要会议期间，千方科技利用大数据平台提供的服务全力保障了会议期间交通运行的井然有序。在国庆、春节及其他重大节日期间，大数据平台做出的出行研判，对方便民众出行起到了积极作用。此外，基于对全国路网运行情况、城市路网运行监测的能力，千方科技可提供精细化的智慧出行方案。

依托坚实的数据基础、强大的服务转化能力，千方大数据平台在交通规划、交通路网监测与运行研判、交通运行管理等方面发挥着越来越重要的作用。未来，千方科技将与业界同仁一起努力，继续探索和实践交通大数据的前沿应用，深入挖掘交通行业发展的新动能，助推我国智能交通系统实现跨越式发展。

在如今这个信息化的时代，到处都能听到“大数据”：医院通过大数据预测流感趋势、华尔街通过大数据抛售股票、社交平台通过大数据匹配用户、商家通过大数据精准营销……大数据到底是什么？能够这么全能吗？下面我们就来了解一下大数据。

大数据（big data），指无法在一定时间范围内用常规软件工具进行捕捉、管理和处理的数据集合，是需要新处理模式才能具有更强的决策力、洞察发现力和流程优化能力的海量、高增长率和多样化的信息资产。

从字面上解读，大数据的专业术语是“巨量数据集合”，这个“巨量”就是大数据中的“大”，如此大量又不规则的数据，是无法通过传统的数据采集以及处理方式分析、查看的。因此，在维克托·迈尔-舍恩伯格及肯尼斯·库克耶编写的《大数据时代》 中说：“大数据指不用随机分析法（抽样调查）这样捷径，而采用所有数据进行分析处理。”这就需要更加先进的云计算技术来支持，技术上包括这些对海量数据的采集，过滤，清洗，储存，处理，查看等部分。从技术上看，大数据与云计算的关系就像一枚硬币的正反面一样密不可分。大数据必然无法用单台的计算机进行处理，必须采用分布式架构。它的特色在于对海量数据进行分布式数据挖掘。但它必须依托云计算的分布式处理、分布式数据库和云存储、虚拟化技术。

大数据不仅仅包括数字，还包括图片、文本、视频、交互记录等等。具有大量、高速、多样、价值等特点，主要应用于计算机。业界将其归纳为5个"V"——Volume（数据体量大）、Variety（数据类型繁多）、Velocity（处理速度快）、Value（价值密度低）、Veracity（真实性）。

大数据拥有以下几个特征：

（1） 容量大（Volume）：数据的大小决定所考虑的数据的价值和潜在的信息；大数据的起始计量单位至少是P（1000个T）、E（100万个T）或Z（10亿个T）。

（2）种类繁多（Variety）：数据类型具有多样性； 包括网络日志、音频、视频、图片、地理位置信息等等，多类型的数据对数据的处理能力提出了更高的要求。

（3）速度快（Velocity）：指获得数据的速度快，时效高；这是大数据区分于传统数据挖掘最显著的特征。

（4）真实性（Veracity）：数据的质量高

（5）价值高成本低（value）：合理运用大数据，以低成本创造高价值。如随着物联网的广泛应用，信息感知无处不在，信息海量，但价值密度较低，如何通过强大的机器算法更迅速地完成数据的价值“提纯”，是大数据时代亟待解决的难题。

大数据的价值并不在“大”，而在于“有用”。价值含量、挖掘成本比数量更为重要。

大数据在各行各业的应用十分广泛，比如在零售业中，企业利用相关数据和分析可以帮助它们降低成本、提高效率、开发新产品、做出更明智的业务决策等等。它的价值在于：

1)对大量消费者提供产品或服务的企业可以利用大数据进行精准营销；

2) 做小而美模式的中小微企业可以利用大数据做服务转型；

3) 面临互联网压力之下必须转型的传统企业需要与时俱进充分利用大数据的价值。

比如，做专业时装零售的企业，为了向客户提供差异化服务，从社交网络上收集了大量社交信息，参考各类时尚产品的营销模式，分析出最具有价值的两类客户：高消费者和高影响者。通过用户间的口碑宣传，从而达到交易数据与交互数据的完美结合。这家企业就是通过社交平台上的数据获得了客户的数据，使他们的业务服务更具有目标性。

零售企业也监控客户的店内走动情况以及与商品的互动。它们将这些数据与交易记录相结合来展开分析，从而在销售哪些商品、如何摆放货品以及何时调整售价上给出意见，此类方法已经帮助某领先零售企业减少了17%的存货，同时在保持市场份额的前提下，增加了高利润率自有品牌商品的比例。

既有的技术架构和路线，已经无法高效处理如此海量的数据，而对于相关组织来说，如果投入巨大采集的信息无法通过及时处理反馈有效信息，那将是得不偿失的。可以说，大数据时代对人类的数据驾驭能力提出了新的挑战，也为人们获得更为深刻、全面的洞察能力提供了前所未有的空间与潜力。

489034603

由于大数据的迅猛发展，数据正在呈指数级增长，各种传感器的剧增，高清晰度的图像和视频都是数据爆炸的原因。腾讯、淘宝掌握了大量的用户数据，力图描绘出用户的整体“画像”。面对大数据的汹涌来袭，传统的数据存储和数据库技术已经难以应对，那么，大数据技术如何存储海量数据并提高系统容错性？目前，较为主流的海量文件存储技术有Google的GFS和Hadoop的HDFS，HDFS是GFS的开源实现。它们均采用分布式存储的方式存储数据，用冗余存储的模式保证数据的可靠性。

下面我们通过几个问题，来让大家更好的了解数据存储应该如何解决？

1、大数据的处理流程包括了哪些环节？每个环节有哪些主要工具？

数据采集： 半结构日志文件可使用flume； 结构化数据可以使用传统的E TL工具如，datastage、kettle 等等

数据存储：hadoop hdfs存储海量数据；也可用传统的oracle、sysbase iq等数据仓库解决方案

数据统计： 使用hive、impala对hadoop进行统计分析；

数据挖掘：可使用mahout进行数据挖掘

2、大数据的数据库相比于传统数据库有何变化？出现了哪些新的大数据的数据管理方式？

量大、结构多样、速度要求高等特点； 出现了以hadoop为代表的分布式存储和nosql等数据存储管理方案

3、大数据工程师应该都知道，现在处理大数据文件的存储，比较典型的有Google的Big Table和Hadoop的HBase，它们有哪些相似点和不同点？

Hadoop的HBase是Google的Big 的开源实现，每个人都可以下载来使用，也可以根据自己需要进行修改和完善

以上都为个人观点，谨供大家参考一下，如果感觉写的可以，即可给自己一个比较准确的定位，为以后的学习找准正确的方向。

另外，如果小伙伴想学习大数据技术，可以加下图片下面的交流群，群里有很多学习视频都可以下载，而且每天大数据架构师马士兵老师都会在群里分享大数据的技术。。

我秀中国物联网地图服务平台目前接入的监控车辆近百万辆，每天采集GPS数据7亿多条，产生日志文件70GB，使用传统的数据处理方式非常耗时。

比如，仅仅对GPS做一些简单的统计分析，程序就需要几个小时才能跑完一天的数据，完全达不到实时分析的要求，更无法对数据进行一些深层次的挖掘。

另外历史数据的存储也是一个亟待解决的问题，目前大多采用的方式是将日志文件进行压缩后上传到服务器上进行存储。

这种方式既原始又不可靠，一是需要作业员每天定时手动上传数据，操作不方便；二是一旦存储数据的服务器出现问题，可能会造成大量数据的丢失，造成不可挽回的损失。

随着大数据技术的成熟和普及，我们发现借助于大数据技术可以完美的解决上述问题。根据目前的需求和对大数据相关软件的掌握，我们对GPS日志分析系统做了初步的设计，架构如下图所示：

大数据日志分析主要是对开源大数据组件进行整合开发而成，分为：数据采集层、数据预处理层、数据存储层、数据处理层和数据分析层等5个层次。

01、数据采集层

数据采集层主要利用开源组件Flume对日志文件进行采集。Flume是一个分布式、高可靠、高可用的海量日志采集软件，支持定制各类的数据发送方，在收集数据的同时能够对数据进行简单的处理，然后写到各种数据接收方。

目前我们是对Flume采集的日志文件做两个操作，一是直接发送给kafka进行缓存，二是将数据进行压缩后写入HDFS供之后的分析用。

02、数据预处理

数据预处理主要对日志文件进行初步的简单处理。目前采用Storm从Kafka接收数据，然后对数据进行实时统计。

Storm是一个分布式、容错的实时计算系统。它的编程模型非常简洁，主要包括三个组件：Topology、Spout和Bolt。Topology是一个由多个计算节点构成的拓扑图，Spout和Bolt是两种结算节点，它们一起构成了一个完整的数据流向图。

03、数据存储层

数据存储层主要用于数据的存储。目前采用MongoDB存储结果数。

通过Storm处理后的数据，首先缓存到Redis中，每隔一定得时间间隔，将数据批量转存到MongoDB中。

MongoDB是一个高性能、易部署、易使用的分布式数据存储系统，介于结构化数据库和非结构化数据库之间，数据存储格式不固定，可以非常方便的进行扩充。

04、数据处理层

数据处理层主要采集一些数据挖掘算法对数据进行挖掘，或者进行实时计算。

数据挖掘主要借助于统计学方法、机器学习方法、神经网络方法等对数据进行知识挖掘，发掘潜在的价值。

比如利用线性回归算法，预测车辆的停留时间。利用k-means算法对位置临近的出租车做聚类分析，从而发现最有可能搭载乘客的热点区域。根据速度将轨迹数据进行分段，从而分析某个时间段的道路畅通状况等。

05、数据分析层

数据分析层主要是数据的展示和分析。

比如将GPS数据加载到地图上，利用抓路算法将GPS数据和地图数据进行融合，对分段的轨迹进行不同颜色的显示，可以让调度人员对当前时间段的道路通行情况一目了然，辅助车辆的调度。

我们不断提高自身数据处理能力，就是为了给您提供更快速、更精准、更丰富的数据分析功能。

【IT168 技术】本文根据徐小飞在2018年5月12日【第九届中国数据库技术大会(DTCC)】现场演讲内容整理而成。

讲师简介：

徐小飞，阿里巴巴技术专家，目前就职于阿里计算平台大数据基础工程技术团队，主要负责支撑阿里大数据智能运维体系(公司内部产品名称——Tesla)的建设，团队致力于打造通用的智能化SRE中台，目前该中台运维体系承载阿里10w+规模节点运维工作。

本文摘要：

介绍Tesla如何支撑阿里离线计算和实时计算两大海量大数据平台的标准化日常运维运营，以及探索如何构筑运维领域的知识图谱，打造针对大数据平台和大数据业务的数据化全息投影，实现多维的立体化监控、智能决策分析、自动化执行的运维闭环。Tesla是面向企业级复杂业务系统的数据化驱动运维解决方案，解决方案包含一个统一运维门户(运维工单、运维垂直搜索)和四个运维基础平台(流程平台、配置平台、作业平台、数据平台)，集日常运维工单管理、自动化发布变更、统一配置管理、统一任务调度、智能监控告警管理、异常检测预测、故障自愈等。

分享大纲：

·运维新趋势

·Tesla运维解决方案

·DataOps数据化运维

·数据价值转化

·AIOps征程

演讲正文：

大家好，我叫徐小飞，很开心能够有这样的一个机会在这里和大家交流。今天主要给大家介绍一下围绕阿里大数据体系的的运维智能化实践。

我所在的团队叫大数据基础工程技术，通俗点说就是大数据SRE(为什么起基础工程技术这个名字? SRE文化里有个最核心的点就是使用软件工程的思想来解决运维问题)，我们团队支撑的是整个阿里大数据生态的运维运营，并沉淀出一套自己的运维解决方案体系——Tesla，这套体系是一个分层体系，包含了面向运维领域功能的运维中台和面向具体大数据平台业务的运维应用。目前Tesla承载了阿里大数据平台及业务共10w+规模节点的日常运维工作。相信了解阿里的人都听过这样一个词——“大中台和小前台”战略，同样在运维领域，我们也是利用这个战略来构筑我们的业务：大中台提供通用的运维领域功能，而小前台可以基于业务场景快速试错、创新。首先我们先看下运维的新趋势。

一.运维新趋势

刚好这几天Google IO大会也正在召开，相信在座的很多同学都会关注，今年的大会中有一个很吸引眼球的话题，就是在开场第一天放出来的两段Demo视频，是个电话录音视频，内容是Google助手帮助客户打电话到发廊或餐厅去做预约。那么亮点在哪里呢?在整个电话预约的过程中，发廊和餐厅的人完全没有感知到和他们交流的是AI机器人。换句话说，AI机器人已经达到了以假乱真的效果，不仅在交流过程中有语气词和思考，而且当话题出现中断时，还会提出反问句，能让话题回到机器人所要的情景进行下去。

Google对外宣称在某些特定领域，例如预约领域，他们已经通过了图灵测试。图灵测试大家可以去了解一下，图灵有一篇针对未来机器智能的论文，一句话解释论文里的图灵测试：当人机交互时，人类完全感觉不到对方是个机器人，那么就标志着进入了机器智能的时代。

大概在三年前，Google提出了AI战略。时至今日，我们看到Google在很多领域都渗透了AI，Google的AI并不是做一个全新的AI产品，而是将AI赋能到它的顶尖产品中。所以，我们表面看到的是预约服务，但其实为了达到这个效果是需要很强大的数据+算法的支撑。我们经常提到的ABC(AI，BigData，Cloud)，想要实现AI，前提一定是大数据和云计算，而在运维领域也同样是如此。这两年AIOps特别火，同样地我们认为要实现AIOps，一定是先有运维的数据和计算，就是说从DevOps到AIOps之间，有一段DataOps必经之路。

如何理解DataOps呢?首先，我们要拿数据来感知我们所运维的系统，继而利用数据分析做一些决策，再往下就是去触发自动化的智能闭环。我们认为DataOps中最核心的过程就是运维感知、决策和执行。

我们把无人驾驶和无人运维做了一个类比。无人驾驶也是Google第一个提出来的，现在有很多厂商投身其中，如果细看无人驾驶，其实我们发现与无人运维类似——无人驾驶是在传统汽车上附加智能感知、决策、智能控制系统。但是真正的无人驾驶还没有达到，即使是Tesla(马斯克的特斯拉)也不例外。而终极AIOps想要达到的是也是无人运维的效果，即在DataOps 的感知、决策和执行三个阶段都附加上AI智能。接下来先看下整体的Tesla运维解决方案。

二.Tesla运维解决方案

上面这张图是阿里大数据的体系，左边最底层是基础设施，包含了底层依赖，机房、天基、Staragent;其上有两大基础平台，一个是飞天平台，这是完全自研的，另一个是Hadoop平台。这两套平台之上分别对应的是MaxCompute和StreamCompute两大存储计算平台;再往上是数据应用层。而右边是Tesla大数据运维解决方案，我们可以看到Tesla贯穿了整个阿里的大数据体系，负责从基础设施到基础平台到存储计算平台的所有产品的运维支撑。

简而言之，Tesla就是在为阿里的大数据保驾护航。

MaxCompute是大数据的核心业务，而DataWorks可以理解为是一个面向开发者的前端，是MaxCompute的门户。 MaxCompute基本上承载了集团90%以上的计算和存储。在阿里，凡是和数据打交道同学都会用到DataWorks。StreamCompute承载了集团几十个BU的实时作业。大家可能感触最多的是每年的双11大屏，这背后都是由StreamCompute实时作业传上去的，可以达到秒级、毫秒级。最后是我们内部的机器学习PAI和AnalyticDB。

这张图是Tesla运维解决方案架构图。整个Tesla运维解决方案是一个分层的体系，从SRE中台到SRE应用。整体是一个垂直体系，也可以拿SPI来分，中台最底层是IaaS，IaaS层是最基础的公共集团的设施，之上是核心运维PaaS层，其中包含四大平台+两大类服务。 四大平台与运维人日常的工作相关，分别是配置平台、作业平台、流程事件平台和数据分析平台。再往上就是SaaS层，提供了所有的平台和服务。Tesla平台支撑了阿里大数据的十几个平台，因为每个大数据平台业务产品的运维特性都是不一样的，肯定无法做到一套运维系统支撑所有的产品运维运营，所以我们就采用了分层战略： 运维开发团队提供平台，而针对具体产品的运维应用由SRE同学利用平台去构筑。典型的SRE应用包括常见的集群管理、资源管理、监控告警、故障管理等。在这张图里我们可以看到DataOps体现在数据分析平台这一层。

这张图是应用维度。SRE应用这一层的功能也是分层的，最下面是其所依赖的基础平台，往上是面向业务的功能(包含业务中心、服务管控、平台运营、工具服务、运维中心和运筹优化)，利用这些功能向上支撑具体的运维场景(围绕稳定性、成本、质量、效率、安全以及体验的维度)，最终服务好业务的各类用户。

在运维/运营平台中抽象出了几块内容，开发框架、资源整合、运维数据化和智能分析。因为最终系统都是相似的，所以我们会给提供前后端框架、服务网关、二方依赖包以及工具插件，业务SRE只需在环境上去获取数据，做数据处理、元数据管理以及提供数据查询的服务。运维数据化(DataOps)就是我们前面提到的，智能分析支撑常见的运维场景，比如最典型的故障处理、监控分析、大促保障以及值班客服等，他们面临的客户是一堆客户，这也是DataOps在SRE应用上的体现。接下来我们重点解释到底什么是DataOps。

三.DataOps数据化运维

什么是DataOps?如何做DataOps?阿里五新战略中有一个新能源，我们认为数据就是新能源，现在已经进入到信息爆炸的时代，大家刷淘宝天猫时的每一次行为都会触发日志，这些日志最终都流到我们的平台里。如此海量的数据，如果能有效的组织管理好，那么就可以从中挖掘出价值，但如果管理不好，就可能会是个大灾难。

算法+技术，再结合数据就会产生新能源，而现在比较通用的数据挑战是我们怎么有效的去收集、清洗数据?如何保证数据的实时性、准确性?如何将无序的、没有结构的数据有序、有结构的分类、组织、存储管理起来?如何通过算法去打通数据，连接、分析数据，并从中提炼出价值?这一系列的问题就是DataOps需要解决的。

什么是数据化运维? 我们这样定义：就是把所有系统的运维数据全部采集起来、真正打通，深度挖掘这些数据的价值，为运维提供数据决策基础和依赖。 从系统“稳定性、成本、效率、安全”多个维度去驱动自动化、智能化的运维运营，从而助力实现真正的AIOps。

相比于传统运维，DataOps的改变可能就是把传统的使用命令、人工决策的运维过程转变成数据+算法的模式。

DataOps是实现AIOps的一个必经之路，是一个运维闭环。如何做数据化运维呢?右边这张图来自《大数据之路》这本书，当然这张图说的是阿里整个的数据中台，阿里数据中台把全公司所有和数据相关的东西都整合了起来，提供了一套统一的数据中台。其中，最下面是数据采集层，往上是数据库同步工具，中间是MaxCompute和StreamCompute，也就是数据存储计算层，最上面是数据服务层和数据应用层。

数据中台中的方案体系是OneData，它是用来规范数据中台，如何维护、组织、管理和使用数据的。OneData之上是OneService，有了这套组织管理和两大计算平台之后，就可以提供各式各样的数据服务，并再向上提供数据应用。在阿里，基本上所有的业务部门都是按照这个套路来做的。

如何做数据化运维?其实就是利用这套大数据体系来构筑大数据的数据化运营体系。这句话可能有点难以理解，更直白一点说，这套体系是由我们来运维保障的，但是过程中我们也利用其来构筑了运维运营体系。因为我们的使命是为阿里大数据保驾护航，而我们的做法也是用阿里大数据来做运维分析，数据化运维分解下来就是运维的数据采集、运维的数据计算、运维的数据服务以及运维的数据应用。

前面讲的是方法论，现在讲讲具体的实操。利用数据中台，我们首先做的是按照OneData规范建立运维的数据仓库，然后把所有运维相关的数据做分类抽象，包含公共数据、业务数据、元数据，runtime实时数据。基于这些数据抽象，我们提供了大量的运维服务和数据服务，比如异常检测分析、故障自愈、可视化流程、运维搜索、运筹优化、全链路诊断以及业务驱动。下面结合几个例子来具体解释下如何做数据化运维。

以全链路分析诊断为例，MaxCompute是一套离线计算平台框架，每天有百万级的任务在跑，这些任务都是由开发同学提交，当作业因为各种原因出现不可预知的错误，大家就会@运维值班人员看看是哪里的问题。后来我们发现，大部分问题是相似的，所以就总结经验，从用户都在这个平台上提交作业到最后执行的每个阶段都去打点、采集分析，做了一套全链路作业诊断工具。

这是一个自助式的全链路诊断产品，提供一个入口，用户只要输入作业ID，我们就能延伸到整个上下游去查询所有的有可能的问题，包括它的资源申请情况、配置是否正确、数据依赖是否都已满足、历史情况如何、是否有长尾倾斜等等。

上图中有我们工具的页面截图，可以看到左边是有分类的，其实在做这个全链路分析工具的时候，我们就把这个场景和去医院体检做了个类比，体检时医生要针对病人的各个环节做判断，然后输出病人的状态，OK还是不OK?如果有问题，立即提出来让病人去某诊室随诊。同样的，我们也是针对作业做了多个维度的检测，而且还会将诊断详情、时间分析、图表分析以及历史对比等，全部都透视给用户。最后的结果报告是用图表分析的，例如稀疏图形资源争抢，毛刺图形部分长尾、任意机器进程CPU消耗分析。

第二个案例场景是硬件自愈，目前我们已经有10万+台物理机了，每天有大量的硬件故障在发生，比如硬盘坏了，主板坏了等等。如果机器比较少，那么我们可能人肉或者直接提单就可以了，但是当量级到了一定程度，每天几十单或者是上百单的硬件故障，这种方式就不适用了。

所以我们就利用这套数据化的思路做了一个硬件自愈的流程。我们也是从服务器上采集到数据，然后流进流计算平台Blink再到数据仓库，做检测分析并得出决策。决策触发流程平台做一些自动化执行的action，调用集群操作系统去做机器维修等。

硬件自愈的本质也是一个三阶段的闭环，在这其中我们的角色有很多。例如有些故障重启一下服务或者双向配置即可解决，而有些故障需要使用万能大法，重启机器才能解决。如果碰到解决不了的问题就要进入无盘状态，去做业务隔离、重新克隆、整机维修，维修完之后自动上线。整套流程全部是自动流转，我们是无人值守的状态。

四.数据价值转化

通过前文的方法论和两个案例，我们大概解释了一下如何做数据化运维，接下来，我们再透视一下数据化运维的本质——从运维数据到知识的价值提取。

这里会涉及到几个概念，数据化运维的前提是先将一切对象数据化，也就是运维的全域数据，构筑完之后，使用知识图谱将这些数据连接起来，之后将数据当做服务提供给人，利用运维搜索去提供一些快速直达的服务。...

随着大数据应用的不断发展和成熟，一些监控系统企业已收获可观的回报。近来，大数据的处理更是发展到了一个更高的新水平，即人工智能（AI）平台的形式。AI平台预计将在未来十年产生重大影响（或颠覆）。在各种技术中，人工智能用于处理海量数据集将前所未有地提升商业智能和分析。

AI智能机器学习是运用算法来分析数据，并从中学习和做出预测。算法包括决策树学习、聚类、强化学习和归纳逻辑编程。

人工智能和机器学习现在主要用作研究和网络活动的个人助理，以及完成诸如接电话、做销售预测和驾驶车辆之类的任务。这些技术综合在一个AI平台中时，将显示出巨大的应用前景

AI平台是一种比传统框架更高效、更智能化的框架。设计得好的话，它可为组织或监控系统企业提供与数据科学家和员工更快、更高效和更有效的协作。它可以帮助以多种方式降低成本——防止重复工作、使简单任务自动化，以及消除一些费用昂贵的活动，例如复制或提取数据等。AI平台还可以提供数据治理，确保由AI科学家和ML工程师组成的团队的最佳实践应用。它还可以帮助确保工作更均匀地分配、更快地完成。

AI平台一般将其要素组织成五个逻辑层：

数据和集成层提供对数据的访问。这种访问是至关重要的，因为开发人员不手工编写规则，相反，规则是由AI运用它所访问的数据进行“学习”的。

实验层允许数据科学家开发、测试和证明假设。设计良好的实验层将提供自动化的特征工程、特征选择和模型选择。

操作和部署层提供模型治理和部署。正是在这里对模型进行风险评估，允许模型治理团队验证它。这一层提供了跨平台部署各种容器化模型和组件的管理工具。

智能层提供对人工智能工作的支持（培训活动在实验层进行）。智能层组织和提供智能服务，并且是用于指导服务交付的主要组件。理想情况下，在该层实现诸如动态服务发现之类的概念，以提供支持认知交互的灵活响应平台。

体验层通过诸如增强现实、会话UI和手势控制之类的技术与用户交互。这一层通常由认知体验团队控制，该团队努力创建丰富且有意义的、由AI技术支持的体验。

使用人工智能分析大数据可以提供对影响企业的外部和内部机制更深入的理解。采用最新的大数据体系结构和机器学习可以更好地支持人工智能的使用。一个现代的、先进的基于人工智能的平台具有以下特征：

· AI可以访问所有可用的数据

· 它从客户或潜在客户的历史中学习

· 它从以前的类似客户那里获取经验，并展示过去行之有效的策略

· AI监控和学习，发现人类可能错过的模式

· AI实时学习，并根据新数据作出实时响应

· 基于变化的数据提供指导

· AI融合机器学习

为了使用先进的AI收获最大的结果，应满足以下三个基本要求：

一、是分析框架。分析框架是随着时间推移而开发的用于解决特定业务问题（通常是复杂的）的方法。使用分析框架是支持系统的AI和机器学习能力的关键。

二、是语境。目前AI和机器学习在判断语境方面表现还非常差。AI可以发现趋势，并且从数据中判断发生了什么，但是超越趋势来推荐员工应该做什么，就必须要考虑语境。虽然人们希望AI能够学习如何确定语境，但这目前还不是现实，还需要由人工确定语境并将其添加到模型中。

三、是适当的技术。与传统的分析系统不同，AI支持的平台必须是可扩展的，以便AI学习和创建解决方案。传统的分析系统会提供对数据的洞察力，而AI会实时地提供建议。

对于安防监控系统AI，看上去是AI，实际上最后是大数据，大数据才是智能化的基础。人工智能、深度学习、机器学习、大数据应用在安防监控系统AI中， 说到底都是对大数据的采集、建模和应用。本文大致说一下安防监控系统AI中，对于大数据的运用过程与环节，让大家有个大致的印象。

安防监控系统AI大数据流程三个环节

1、数据采集

数据采集，有说数据获取，这是数据的来源，安防监控系统AI中这个数据是来源于视频监控系统中的视频流，当然往大了说安防监控系统，还包括很多内容，但是基本都是以视频监控为核心，这里主要指视频监控系统。

2、数据预处理

对于采集到的实时或者历史视频，是只能看不能应用的，要调用就得结构化，先给视频流解码，把视频流还原成一张张图片，再对图片进行预处理。可能不同的公司对预处理包含的步骤内容说法不太一致，我是以安软慧视的技术负责人介绍为准。先对图片进行目标清洗垃圾，清洗掉模糊的、不合尺寸的，目标无法识别的、无目标对象的等等。

当然，有些场景可能只有这样的图像，这需要用到另外一些图像处理方法，和我们的主题相关但不是一回事。这样我们就可以得到基本符合要求的图像。然后对这些图像中的目标对象进行检测和分割，并改变目标的大小与标准图片大小一致，目标对象包括人形、人脸、车形等，这样就可以拿去训练模型了。

3、模型训练

对图片中的目标对象进行识别，提取和构建模型，在安防监控系统AI中，需要的结构化描述是比较具体的，比如对人的描述就包括性别、年龄、发型特征、发饰、上衣款式特征、下衣款式特征、鞋帽款式特征、交通工具特征、随身物品特征、同行人特征等一系列描述。对车的描述包括车牌号码、厂牌、车身颜色、车辆品牌、车辆类型、车辆特征物（如：年检标、挂饰、纸巾盒、遮阳板）等。

有了这些识别模型，就可以通过语义分析等技术对视频数据进行分类处理存储，并通过后端服务器的智能分析功能进行业务处理，将人、车、物的信息从数据中分离出来。这样公安民警就可以进行快速检索、条件搜图（人）、以图搜图，再配以图片的拍摄地点、时间等数据，就可以进行轨迹查询，再匹配一下大安防监控系统系统中的住宿、手机号码、车票等大数据，基本上嫌疑人就是插翅难逃，这对民警的破案效率将是百千倍的提升。这才是安防监控系统AI真正的价值所在。

安防监控系统AI数据预处理技术及方法

目前常见的数据预处理技术

1）数据清理

数据清理例程就是通过填写缺失值、光滑噪声数据、识别或者删除离群点，并且解决不一致性来进行“清理数据”。

2）数据集成

数据集成过程将来自多个数据源的数据集成到一起。

3）数据规约

数据规约是为了得到数据集的简化表示。数据规约包括维规约和数值规约。

4）数据变换

通过变换使用规范化、数据离散化和概念分层等方法，使得数据的挖掘可以在多个抽象层面上进行。数据变换操作是提升数据挖掘效果的附加预处理过程。

数据清理方法

1）缺失值

对于缺失值的处理，一般是能补的就想办法把它补上，实在补不上的就丢弃处理。通常的处理方法有：忽略元组、人工填写缺失值、使用一个全局变量填充缺失值、使用属性的中心度量填充缺失值、使用与给定元组属同一类的所有样本的属性均值或中位数、使用最可能的值填充缺失值。

2）噪声数据

噪声是被测量变量的随机误差或方差。去除噪声、使数据“光滑”的技术有分箱、回归、离群点分析等。

3）数据清理过程

这个环节主要包括数据预处理、清理方法、校验清理方法、执行清理工具及数据归档。数据清理的原理是通过分析“无效数据”产生的原因和存在形式，利用现有的技术手段和方法去清理，将“无效数据”转化为满足数据质量或应用要求的数据，从而提高数据集的数据质量。常用的工具有Excel、Access、SPSS Modeler、SAS、SPSS Statistics等。

4）模型构建数据统计分析

数据统计为模型构建提供基础，只有通过数据统计分析探索到了数据中隐藏的规律，深度学习才有意义，人工智能才有可能。数据统计又包括数据分析与结果分析，基本的分析方法有：对比分析法、分组分析法、交叉分析法、因素分析法、结构分析法、漏斗图分析法、矩阵关联分析法、综合评价分析法等。

高级的分析方法有：主成分分析法、因子分析法、对应分析法、相关分析法、回归分析法、聚类分析法、判别分析法、时间序列等。这些类别并不是独一使用的，往往是混合使用的，然后再通过进一步的分析对比从中挑选某些组合模型。

5）数据可视化

数据可视化，就是通过一些可视化图形或者报表形式进行展示，增强对分析结果的理解。再针对结果进行进一步的数据再分析，使得整个业务环节形成闭环。只有闭环的数据才能真正发挥出深度学习的效用。

安防监控系统AI大数据的应用

安防监控系统大数据的应用当前是围绕提升破案率和提升警务工作效率为中心的，要想在安防监控系统数据的基础上开发出优秀的应用，必须要深入了解警务工作流程，从接处警、现场勘查、情报研判、应急指挥、关联碰撞、合成作战，再到各类型警用装备间的互联互通，再到各警种间的配合，再到各警种业务数据库间的融合。这些都要有详细地了解，才能发现针对刑侦破案、治安防监控系统控、交通管理的应用间的差异。

说到底，大数据最终是为应用服务的，只有最后真正提高了公安民警的工作效率和破案率，才能证明安防监控系统AI的价值和意义。这就要求我们既要懂AI业务，又要懂公安业务。脱离了这两者，想让安防监控系统AI得到大面积推广是连想都不要想的。

内容来源：2017年8月12日，滴滴实时计算平台负责人梁李印在“网易博学实践日：大数据与人工智能技术大会”进行《滴滴海量数据实时计算实践》演讲分享。IT 大咖说（ID：itdakashuo）作为独家视频合作方，经主办方和讲者审阅授权发布。

阅读字数：1260 | 4分钟阅读

嘉宾演讲视频及PPT回顾，请复制链接：http://t/RdTjLOS，粘贴至浏览器地址栏即可。

摘要

本次演讲主要是和大家分享一下实时计算在滴滴的应用场景和一些实践。

滴滴大数据体系

滴滴大数据体系的主要特点在于数据都是实时的，数据采集可以采集到90%以上的数据。我们的数据来源一共有三类，一类是Binlog数据，所有端上数据进数据库通过Binlog进行实时采集；另外有publiclog，服务端的所有日志也做了实时采集；还有端上埋点上报数据。

因为我们所有数据基本都是实时采集，所以客户级的处理流程也广泛运用了实时的技术。实时存储方面用了三个产品，一个是ES，主要是做日志检索和实时分析；另一个是Druid，用于做实时报表和实时监控；HBase是做查询和数据扫描。

离线这部分目前用了Hive和Spark。Hive主要负责ETL工作，Spark做数据分析以及分析后的查询。流计算方面我们用了Spark Streaming和Flink Streaming。

从规模上来说，我们实时存储和离线规模都已经做到了国内的领先水平。

实时计算场景

实时计算有四大场景，ETL、实时报表、实时监控和实时业务。

因为我们90%的数据都是通过实时采集，采集过来之后第一个环节就是做ETL，所以现在ETL的规模是最大的。实时报表可以给运营和客服可以用来做报表展示。

实时监控的规模仅次于ETL，内部有两类监控需求，一类是机器层面的，用了其它的技术方案；剩下就是业务类的实时监控，例如每天的订单量、平衡率等数据，都运用了实时计算体系。

实时业务是我们今年重点突破的部分，我们想把流计算在端上的场景去做一些突破。

实时ETL

为了方便使用ETL，我们把它做了平台化，用户只需要在web上配置就可以实现数据清洗。现在的清洗量可以达到每秒350万左右的数据量，每天大约会清洗几个P的数据量。这完全是基于Spark Streaming的云计算来实现的。

实时报表

实时报表主要用的实时技术有Spark Streaming和Druid。Spark Streaming还是做数据清洗。Druid可以实时消费Kafka数据，但对数据是有要求的，所以要先经过一轮清洗并转化。

实时报表的场景也比较多，有客服大屏、异常统计大盘和订单热力图。

客服大屏就是一个可以显示客服电话的应答率、投诉热点及排队情况等信息的屏幕。

异常统计大盘包括了端上向服务端发起请求的监控，请求的成功率失败率、请求数，都可以通过这种方式进行监控。

订单热力图可以看到某个区域的订单量、乘客量、司机量，通过地图的方式进行展现。

我们选择了Druid是因为它有一些特点，比如查询灵活。

实时监控

为了提升以后的监控效率，我们构建了一站式自助监控平台，进行了全链路的平台建设。

基于这个平台，我们滴滴内部接入的数据源大概有两百个，指标监控大概有四五百个。

实时业务

Flink Streaming是今年刚引入的引擎，我们想通过实时的业务对延迟性非常高、数据丢失以及数据重复等问题提出更好的解决方案。

面临挑战

降低实时计算开发成本：相对于Hive等等，开发实时计算的难度还是比较大，我们也在探索更简单的开发方式。

实时业务拓展与挑战：我们在实时ETL、实时报表、实时监控的领域目前技术已经非常成熟，也基本上涵盖了所有滴滴内部的业务场景。实时业务对时延、容错的要求非常高，这是我们现在面临的一个重要挑战。

业务峰谷资源合理分配：我们现在要做的就是如何将资源合理分配，让资源能够更合理地使用，为公司节省成本。

我今天的分享就到这里，谢谢大家！