人工智能与大数据技术导论

1. 系统特征

Storm系统的主要特征如下。

(1)简单编程模型。用户只需编写Spout和Bolt部分的实现，因此极大地降低了实时大数据流式计算的复杂性。

(2）支持多种编程语言。默认支持Clojure、Java、Ruby和Python，也可以通过添加相关协议实现对新增语言的支持。

（3）作业级容错性。可以保证每个数据流作业被完全执行。

（4）水平可扩展。计算可以在多个线程、进程和服务器之间并发执行。

(5）快速消息计算。通过ZeroMQ作为其底层消息队列，保证消息能够得到快速的计算。

Storm系统存在的不足主要包括：资源分配没有考虑任务拓扑的结构特征，无法适应数据负载的动态变化；采用集中式的作业级容错机制，在一定程度上限制了系统的可扩展性。

3.4.6 Kafka 系统

Kafka是Linkedin所支持的一款开源的、分布式的、高吞吐量的发布订阅消息系统，可以有效地处理互联网中活跃的流式数据，如网站的页面浏览量、用户访问频率、访问统计、好友动态等，开发语言是Scala，可以使用Java进行编写。Kafka系统在设计过程中主要考虑了以下需求特征。

（1）消息持久化是一种常态需求。

(2）吞吐量是系统需要满足的首要目标。

(3）消息的状态作为订阅者（consumer）存储信息的一部分，在订阅者服务器中进行存储。

(4）将发布者（producer）、代理（broker）和订阅者（consumer）显式地分布在多台机器上，构成显式的分布式系统。

形成了以下关键特性。

(1）在磁盘中实现消息持久化的时间复杂度为O(1)，数据规模可以达到太字节（TB)级别。

(2)实现了数据的高吞吐量，可以满足每秒数十万条消息的处理需求。

（3）实现了在服务器集群中进行消息的分片和序列管理。

(4)实现了对Hadoop系统的兼容，可以将数据并行地加载到Hadoop集群中。

1. 系统架构

Kafka消息系统的架构是由发布者、代理和订阅者共同构成的显式分布式架构，它们分别位于不同的节点上，如图3-13所示。各部分构成一个完整的逻辑组，并对外界提供服务，各部分间通过消息（message）进行数据传输。其中，发布者可以向一个主题（topic）推送相关消息，订阅者以组为单位可以关注并拉取自己感兴趣的消息，通过ZooKeeper实现对订阅者和代理的全局状态信息的管理及其负载均衡的实现。

人工智能与大数据技术导论

84

1. 数据存储

Kafka消息系统通过仅进行数据追加的方式实现对磁盘数据的持久化保存，实现了对大数据的稳定存储，并有效地提高了系统的计算能力。通过采用Sendfile系统调用方式优化了网络传输，提高了系统的吞吐量。即使对于普通的硬件，Kafka消息系统也可以支持每秒数十万的消息处理能力。此外，在Kafka消息系统中，通过仅保存订阅者已经计算数据的偏量信息，一方面可以有效地节省数据的存储空间，另一方面也简化了系统的计算方式，方便系统的故障恢复。

3.消息传输

Kafka消息系统采用推送、拉取相结合的方式进行消息的传输。其中，当发布者需要传输消息时，会主动地推送该消息到相关的代理节点；当订阅者需要访问数据时，其会从代理节点进行拉取。通常情况下，订阅者可以从代理节点中拉取自己感兴趣的主题消息。

4.负载均衡

在Kafka消息系统中，发布者和代理节点之间没有负载均衡机制，但可以通过专用的第4层负载均衡器在Kafka代理上实现基于TCP连接的负载均衡的调整。订阅者和代理节点之间通过Zookeeper实现负载均衡机制，在Zookeeper中管理全部活动的订阅者和代理节点信息。当有订阅者和代理节点的状态发生变化时，才实时地进行系统的负载均衡的调整，保障整个系统处于一个良好的均衡状态。

1. 存在不足

Kafka系统存在的不足之处主要包括：只支持部分容错，节点失效转移时会丢失原节点内存中的状态信息；代理节点没有副本机制保护，一旦代理节点出现故障，该代理节点中的数据

第3章 数据

85

将不再可用；代理节点不保存订阅者的状态，删除消息时无法判断该消息是否已被阅读。

3.4.7 各类技术平台比较

一般而言，批量计算相关的大数据系统，如批量处理系统（如MapReduce）、大规模并行数据库等，在数据吞吐量方面具有明显优势，但在系统响应时间方面往往在秒级以上。而当前的流式计算相关的大数据系统，如流式处理系统、内存数据库、CEP（复杂事件处理）等，在系统响应时间方面虽然维持在毫秒级的水平，但数据吞吐量往往在吉字节（GB）级别，远远满足不了大数据流式计算系统对数据吞吐量的要求。通常情况下，一个理想的大数据流式计算系统在响应时间方面应维持在毫秒级的水平，并且数据吞吐量应该提高到拍字节（PB）级别及以上水平。

流式大数据作为大数据的一种重要形态，在商业智能、市场营销和公共服务等诸多领域有着广泛的应用前景，并已在金融银行业、互联网、物联网等场景的应用中取得了显著的成效。但流式大数据以其实时性、无序性、无限性、易失性、突发性等显著特征，使得传统的先存储后计算的批量数据计算理念不适用于大数据流式计算的环境中，也使得当前诸多数据计算系统无法更好地适应流式大数据在系统可伸缩性、容错、状态一致性、负载均衡、数据吞吐量等方面所带来的诸多新的技术挑战。

1. 可伸缩性

在大数据流式计算环境中，系统的可伸缩性是制约大数据流式计算系统广泛应用的一个重要因素。Storm和Kafka等系统没有实现对系统可伸缩性的良好支持：一方面，流式数据的产生速率在高峰时期会不断增加且数据量巨大，持续时间往往很长，因此需要大数据流式系统具有很好的“可伸”的特征，可以实时适应数据增长的需求，实现对系统资源进行动态调整和快速部署，并保证整个系统的稳定性：另一方面，当流式数据的产生速率持续减小时，需要及时回收在高峰时期所分配的但目前已处于闲置或低效利用的资源，实现整个系统“可缩”的友好特征，并保障对用户是透明的。因此，系统中资源动态的配置、高效的组织、合理的布局、科学的架构和有效的分配是保障整个系统可伸缩性的基础，同时又尽可能地减少不必要的资源和能源的浪费。

大数据流式计算环境中的可伸缩性问题的解决需要实现对系统架构的合理布局，系统资源的有序组织、高效管理和灵活调度。在保证系统完成计算的前提下，尽量不要太久、太多地占用系统资源，通过虚拟化机制实现软、硬件之间的低耦合，实现资源的在线迁移，并最终解决大数据流式计算环境中的可伸缩性问题。

1. 系统容错

在大数据流式计算环境中，系统容错机制是进一步改善整个系统的性能、提高计算结果的满意度、保证系统可靠持续运行的一个重要措施，也是当前大多数大数据流式计算系统所缺失的。Kafka等系统实现了对部分容错的支持，Storm系统实现了对作业级容错的支持。大数据流式计算环境对容错机制提出了新的挑战，一方面，数据流是实时、持续地到来的，呈现出时间上不可逆的特征，一旦数据流流过，再次重放数据流的成本是很大的，甚至是不现实的，由于数据流所呈现出的持续性和无限性，也无法预测未来流量的变化趋势；另一方面，在流式大数据的计算过程中，大部分“无用”的数据将被直接丢弃，能被永久保存下来的数据量是极少的。当需要进行系统容错时，其中不可避免地会出现一个时间段内数据不完整的情况。再则，需要针对不同类型的应用，从系统层面上设计符合其应用特征的数据容错级别和容错策略，避免不必要的资源浪费及应用需求的不吻合。

人工智能与大数据技术导论

86

大数据流式计算环境中的容错策略的确定，需要根据具体的应用场景进行系统的设计和权衡，并且需要充分考虑到流式大数据的持续性、无限性、不可恢复性等关键特征。但是，没有任何数据丢失的容错策略也未必是最佳的，需要综合统筹容错级别和资源利用、维护代价等要素间的关系。但在对系统资源占用合理、对系统性能影响可接受的情况下，容错的精度越高必将越好。

1. 状态一致性

在大数据流式计算环境中，维持系统中各节点间状态的一致性对于系统的稳定高效运行、故障恢复都至关重要。然而，当前多数系统不能有效地支持系统状态的一致性，如Storm和Kafka等系统尚不支持维护系统状态的一致性。大数据流式计算环境对状态一致性提出了新的挑战：一方面，在系统实时性要求极高、数据速率动态变化的环境中，维护哪些数据的状态一致性，如何从高速、海量的数据流中识别这些数据是一个巨大的挑战；另一方面，在大规模分布式环境中，如何组织和管理实现系统状态一致性的相关数据，满足系统对数据的高效组织和精准管理的要求，也是一个巨大的挑战。

大数据流式计算环境中的状态一致性问题的解决需要从系统架构的设计层面上着手。存在全局唯一的中心节点的主从式架构方案无疑是实现系统状态一致性的最佳解决方案，但需要有效避免单点故障问题。通常情况下，在大数据流式计算环境中，程序和数据一旦启动后，将会常驻内容，对系统的资源占用也往往相对稳定。因此，单点故障问题在大数据流式计算环境中并没有批量计算环境中那么复杂。批量计算环境中的很多策略将具有很好的参考和借鉴价值。

1. 负载均衡

在大数据流式计算环境中，系统的负载均衡机制是制约系统稳定运行、高吞吐量计算、快速响应的一个关键因素。然而，当前多数系统不能有效地支持系统的负载均衡，如Storm系统不支持负载均衡机制，Kafka系统实现了对负载均衡机制的部分支持。一方面，在大数据流式计算环境中，系统的数据速率具有明显的突变性，并且持续时间往往无法有效预测，这就导致在传统环境中具有很好的理论和实践效果的负载均衡策略在大数据流式计算环境中将不再适用；另一方面，当前大多数开源的大数据流式计算系统在架构的设计上尚未充分地、全面地考虑整个系统的负载均衡问题。在实践应用中，相关经验的积累又相对缺乏，因此，给大数据流式计算环境中负载均衡问题的研究带来了诸多实践中的困难和挑战。

大数据流式计算环境中的负载均衡问题的解决需要结合具体的应用场景，系统地分析和总结隐藏在大数据流式计算中的数据流变化的基本特征和内在规律，结合传统系统负载均衡的经验，根据实践检验情况，不断进行相关机制的持续优化和逐步完善。

第3章 数据

87

1. 数据吞吐量

在大数据流式计算环境中，数据吞吐量呈现出了根本性的增加。在传统的流式数据环境中，所处理的数据吞吐量往往在吉字节（GB）级别，这满足不了大数据流式计算环境对数据吞吐量的要求。在大数据流式计算环境中，数据的吞吐量往往在太字节（TB）级别以上，且其增长的趋势是显著的。然而，当前流式数据处理系统（如Storm）均无法满足太字节（TB）级别的应用需求。

大数据流式计算环境中的数据吞吐量问题的解决，一方面需要从硬件的角度进行系统的优化，设计出更符合大数据流式计算环境的硬件产品，在数据的计算能力上实现大幅提升；另一方面，更为重要的是，从系统架构的设计中进行优化和提升，设计出更加符合大数据流式计算特征的数据计算逻辑。

3.5 数据平台

企业要做AI和大数据分析，首先要考虑数据的准备，这其实就是数据平台的建设。有人也许会问：业务跑得好好的，各系统稳定运行，为何还要搭建企业的数据平台？企业一般在什么情况下需要搭建数据平台，从而实现对各种数据进行重新架构？

从业务的视角来看：业务系统过多，彼此的数据没有打通。这种情况下，涉及数据分析就麻烦了，可能需要分析人员从多个系统中提取数据，再进行数据整合，之后才能分析。一次两次可以忍，天天干这个能忍吗？人为地整合出错率高怎么办？分析不及时效率低要不要处理？

●从系统的视角来看：业务系统压力大，但很不巧，数据分析又是一项比较费资源的任务。那么自然会想到，通过将数据抽取出来，独立服务器来处理数据查询、分析的任务，从而释放业务系统的压力。

从数据处理性能的视角来看：企业越做越大，与此同时，数据也会越来越多。可能是历史数据的积累，也可能是新数据内容的加入。当原始数据平台不能承受更大数据量的处理时，或者效率已经十分低下时，重新构建一个大数据处理平台就是必需的了。

这三种情况有时并非独立的，往往是其中两种其至三种情况同时出现。这时，一个数据平台的出现不仅可以承担数据分析的压力，还可以对业务数据进行整合，从而从不同程度上提高数据处理的性能，基于数据平台实现更丰富的功能需求。

AI和大数据分析的成功需要的不仅仅是原始数据，还需要好的且高质量的数据。更准确的说法应该是，AI的成功需要那些准备好的数据。对于分析，如果进来的是垃圾，那么出去的也是垃圾，这就意味着，如果你把大量参差不齐的数据放到分析解决方案中，你将会得到不好的结果。所以，大多数数据科学家和数据分析师花费大量时间来为AI准备数据。

人工智能与大数据技术导论

88

数据平台通过打通数据通道实现数据汇聚、资源共享，同时提供数据的存储、计算、加工、分析等基础能力。大数据时代的到来，大家开始将数据当成资源，当作资产，数据管理的意义也越来越大。大数据管理平台的建设需要设计以下5个因素。

数据集中和共享。企业及基础数据平台是公共的、中性的，数据一定要做到集中和共享，否则就失去了它的意义。

●数据标准统一。如果每个应用都有自己的一套标准，整个架构会越来越乱。

●数据管理策略统一。方向是共性的数据一定要下沉，个性的数据逐渐上浮，也就是说，共性数据都尽量落在基础数据平台上，个性数据可以逐渐落在各个应用上处理。

减少数据复制。

长期和短期相结合。一个完整的企业级基础数据平台包含几个部分，即数据存储平台(包含相应的数据架构、数据存储策略以及应用切分点等)、应用（包含报表、数据挖掘、系统应用等）、数据管控（包含质量管理办法，比如数据标准等）、数据交换采集调度平台和数据处理（包含实施数据区、大数据处理、历史数据存储等）。这类混合架构既要考虑结构性数据的处理方法，也要考虑非结构化数据的处理和文本等的混合运算方法。这个结构能够帮助我们清晰地看到后续要发展成什么样，我们不一定开始就要完成这样一个体系，但是可以考虑好这些相应的数据项目，包括以后扩展的接口。

3.5.1数据存储和计算

结构化、半结构化、文本、各类传感器的数据，音频、图片、视频等多媒体数据混杂，分别存储在不同的数据库、不同的地域中。如何处理这些数据？没有一个实时计算的数据平台几乎是很难实现的。大数据时代的业务场景是多元化的，不同的数据产品面向的场景很不一样。围绕这些多媒体为存储的核心对象来构建场景，清晰、及时地呈现业务，是非常重要的一项工作。

数据平台建设、部署对数据规范化定义，实现数据的唯一性、准确性、完整性、规范性和实效性，实现数据的共享共用，解决数据层面的孤岛问题。整合企业各个业务系统，形成数据平台。这就要求建立的数据平台能够整合各个业务系统，从物理和逻辑上将数据集中起来，同时数据平台起到了物理隔离生产系统、减轻对生产系统的压力、提升效率的作用。数据平台可以分成以下几类。

1. 常规数据仓库

常规数据仓库的重点在于数据整合，同时也是对业务逻辑的一个梳理。虽然也可以打包成saas（多维数据集）、cube（多维数据库）等来提升数据的读取性能，但是数据仓库的作用更多的是为了解决企业的业务问题，而不仅仅是性能问题。常规数据仓库的优点如下。

（1）方案成熟，关于数据仓库的架构有着非常广泛的应用，而且能将其落地的人也不少。

(2）实施简单，涉及的技术层面主要是仓库的建模以及ETL的处理，很多软件公司

第3章 数据

89

具备数据仓库的实施能力，实施难度的大小更多地取决于业务逻辑的复杂程度，而并非技术上的实现。

(3)灵活性强。数据仓库的建设是透明的，如果需要，可以对仓库的模型、ETL逻辑进行修改，来满足变更的需求。同时，对于上层的分析而言，通过SQL对仓库数据的分析处理具备极强的灵活性。

常规数据仓库的缺点如下。

(1）实施周期相对比较长。实施周期的长与短取决于业务逻辑的复杂性，时间花在业务逻辑的梳理，并非技术的瓶颈上。

（2）数据的处理能力有限。这个有限也是相对的，海量数据的处理肯定不行，非关系型数据的处理也不行，但是太字节（TB）以下级别数据的处理还是可以的（也取决于所采用的数据库系统）。对于这个量级的数据，相当一部分企业的数据其实是很难超过这个级别的。

实时处理的要求是区别大数据应用和传统数据仓库技术的关键差别之一。随着每天创建的数据量爆炸性的增长，就数据保存来说，传统数据库能改进的技术并不大，如此庞大的数据量存储就是传统数据库所面临的非常严峻的问题。

1. MPP(大规模并行处理)架构

传统的数据库模式在海量数据面前显得很弱。造价非常昂贵，同时技术上无法满足高性能的计算，其架构难以扩展，在独立主机的CPU计算和IO吞吐上，都没办法满足海量数据计算的需求。分布式存储和分布式计算正是解决这一问题的关键，无论是MapReduce计算框架(Hadoop)）还是MPP计算框架，都是在这一背景下产生的。

Greenplum是基于MPP架构的，它的数据库引擎是基于PostgreSQL的，并且通过Interconnnect连接实现了对同一个集群中多个PostgreSQL实例的高效协同和并行计算。同时，基于Greenplum的数据平台建设可以实现两个层面的处理：一个是对数据处理性能的提升，目前Greenplum在100TB级左右的数据量上是非常轻松的；另一个是数据仓库可以搭建在Greenplum中，这一层面上也是对业务逻辑的梳理，对公司业务数据的整合。Greenplum的优点如下。

（1）海量数据的支持，存在大量成熟的应用案例。

(2）扩展性：据说可线性扩展到10000个节点，并且每增加一个节点，查询、加载性能都成线性增长。

(3）易用性：不需要复杂的调优需求，并行处理由系统自动完成。依然是SQL作为交互语言，简单、灵活、强大。

(4)高级功能：Greenplum还研发了很多高级数据分析管理功能，例如外部表、Primary/Mirror镜像保护机制、行/列混合存储等。

(5)稳定性：Greenplum原本作为一个纯商业数据产品，具有很长的历史，其稳定性比Hadoop产品更加有保障。Greenplum有非常多的应用案例，纳斯达克、纽约证券交易所、平安银行、建设银行、华为等都建立了基于Greenplum的数据平台。其稳定性是可以从侧面验证的。

人工智能与大数据技术导论

90

Greenplum的缺点如下。

(1）本身来说，它的定位在OLAP领域，不擅长OLTP交易系统。当然，我们搭建的数据中心也不是用来做交易系统的。

(2)成本，有两个方面的考虑，一是硬件成本，Greenplum有其推荐的硬件规格，对内存、网卡都有要求，二是实施成本，这里主要是需要人，从基本的Greenplum的安装配置到Greenplum中数据仓库的构建，都需要人和时间。

(3)技术门槛，这里是相对于数据仓库的，Greenplum的门槛肯定更高一点。

1. Hadoop分布式系统架构

Hadoop已经非常火了，Greenplum的开源跟它也是脱不了关系的。它有着高可靠性、高扩展性、高效性、高容错性的口碑。在互联网领域有着非常广泛的运用，雅虎、Facebook、百度、淘宝、京东等都在使用Hadoop。Hadoop生态体系非常庞大，各公司基于Hadoop所实现的也不仅限于数据平台，还包括数据分析、机器学习、数据挖掘、实时系统等。

当企业数据规模达到一定的量级时，Hadoop应该是各大企业的首选方案。到达这样一个层次的时候，企业所要解决的不仅是性能问题，还包括时效问题、更复杂的分析挖掘功能的实现等。非常典型的实时计算体系也与Hadoop这一生态体系有着紧密的联系，比如Spark。近些年来，Hadoop的易用性有了很大的提升，SQL-on-Hadoop技术大量涌现，包括Hive、Impala、SparkSQL等。尽管其处理方式不同，但相比于原始的MapReduce模式，无论是性能还是易用性都有所提高。因此，对MPP产品的市场产生了压力。

对于企业构建数据平台来说，Hadoop的优势与劣势非常明显：优势是它的大数据处理能力、高可靠性、高容错性、开源性以及低成本（处理同样规模的数据，换其他方案试试就知道了）；劣势是它的体系复杂，技术门槛较高（能搞定Hadoop的公司规模一般都不小）。

关于Hadoop的优缺点，对于公司的数据平台选型来说，影响已经不大了。需要使用Hadoop的时候，也没什么其他的方案可选择（要么太贵，要么不行），没达到这个数据量的时候，也没人愿意碰它。总之，不要为了大数据而大数据。

Hadoop生态圈提供海量数据的存储和计算平台，包括以下几种。

●结构化数据：海量数据的查询、统计、更新等操作。

●非结构化数据：图片、视频、Word、PDF、PPT等文件的存储和查询。

●半结构化数据：要么转换为结构化数据存储，要么按照非结构化存储。

Hadoop的解决方案如下。

存储：HDFS、HBase、Hive等。

并行计算：MapReduce 技术。

流计算：Storm、Spark。

如何选择基础数据平台？我们至少要从以下几个方面去考虑。

（1）目的：从业务、系统、性能三种视角去考虑，或者是其中几个的组合。当然，要明确数据平台建设的目的，有时并不容易，初衷与讨论后确认的目标或许是不一致的。比如，某企业要搭建一个数据平台的初衷可能很简单，只是为了减轻业务系统的压力，将数据拉出来后再分析，如果目的真的这么单纯，而且只有一个独立的系统，那么直接将业务系统的数据库复制一份就好了，不需要建立数据平台；如果是多系统，选型一些商业数据产品也够了，快速建模，直接用工具就能实现数据的可视化与OLAP分析。但是，既然已经决定要将数据平台独立出来，就不再多考虑一点吗？多个业务系统的数据不趁机梳理整合一下？当前只是分析业务数据的需求，以后会不会考虑历史数据呢？方案能否支撑明年和后年的需求？

第3章 数据

91

（2）数据量：根据公司的数据规模选择合适的方案。

(3）成本：包括时间成本和金钱成本。但是这里有一个问题，很多企业要么不上数据平台，一旦有了这样的计划，就恨不得马上把平台搭建出来并用起来，不肯花时间成本。这样的情况很容易考虑欠缺，也容易被数据实施方忽悠。

在方案选型时，一个常见的误区是忽略业务的复杂性，要用工具来解决或者绕开业务的逻辑。企业选择数据平台的方案有着不同的原因，要合理地选型，既要充分地考虑搭建数据平台的目的，也要对各种方案有着充分的认识。对于数据层面来说，还是倾向于一些灵活性很强的方案，因为数据中心对于企业来说太重要了，更希望它是透明的，是可以被自己完全掌控的，这样才有能力实现对数据中心更加充分的利用。因为不知道未来需要它去担任一个什么样的角色。

3.5.2 数据质量

当前越来越多的企业认识到了数据的重要性，大数据平台的建设如雨后春笋般。但数据是一把双刃剑，它给企业带来业务价值的同时，也是组织最大的风险来源。糟糕的数据质量常常意味着糟糕的业务决策，将直接导致数据统计分析不准确、监管业务难、高层领导难以决策等问题，据IBM统计：

●错误或不完整数据导致BI和CRM系统不能正常发挥优势甚至失效。

●数据分析员每天有30%的时间浪费在了辨别数据是否是“坏数据”上。

●低劣的数据质量严重降低了全球企业的年收入。

可见数据质量问题已经严重影响了企业业务的正常运营。在企业信息化初期，各类业务系统恣意生长。后来业务需求增长，需要按照统一的架构和标准把各类数据集成起来，这个阶段问题纷纷出现，数据不一致、不完整、不准确等各种问题扑面而来。费了九牛二虎之力才把数据融合起来，如果因为数据质量不高而无法完成数据价值的挖掘，那就太可惜了。

大数据时代数据集成融合的需求会愈加迫切，不仅要融合企业内部的数据，也要融合外部（互联网等）数据。如果没有对数据质量问题建立相应的管理策略和技术工具，那么数据质量问题的危害会更加严重。数据质量问题会造成“垃圾进，垃圾出”。数据质量不好造成的结果是对业务的分析不但起不到好的效果，相反还有误导的作用。很多人可能在纠结，数据质量问题究竟是“业务”的问题还是“技术”的问题。根据我们以往的经验，造成数据质量问题的原因主要分为以下几种：

人工智能与大数据技术导论

92

（1）数据来源渠道多，责任不明确。

（2）业务需求不清晰，数据填报缺失。

(3）ETL处理过程中，业务部门变更代码导致数据加工出错，影响报表的生成。

（1）和（2）都是业务的问题，（3）虽然表面上看是技术的问题，但本质上还是业务的问题。因此，大部分数据质量问题主要还是来自于业务。很多企业认识不到数据质量问题的根本原因，只从技术单方面来解决数据问题，没有形成管理机制，导致效果大打折扣。在走过弯路之后，很多企业认识到了这一点，开始从业务着手解决数据质量问题。在治理数据质量问题时，采用规划顶层设计，制定统一数据架构、数据标准，设计数据质量的管理机制，建立相应的组织架构和管理制度，采用分类处理的方式持续提升数据质量。还有，通过增加ETL数据清洗处理逻辑的复杂度，提高ETL处理的准确度。

1. AI系统本身的数据质量

在大数据时代，信息由数据构成，数据是信息的基础，数据已经成为一种重要资源。数据质量成为决定资源优劣的一个重要方面。随着大数据的发展，越来越丰富的数据给数据质量的提升带来了新的挑战和困难。对于企业而言，进行市场情报调研、客户关系维护、财务报表展现、战略决策支持等都需要进行数据的搜集、分析、知识发现，为决策者提供充足且准确的情报和资料。对于政府而言，进行社会管理和公共服务影响面更为宽广和深远，政策和服务能否满足社会需要，是否高效地使用了公共资源，都需要数据提供支持和保障，因而对数据的需求显得更为迫切，对数据质量的要求也更为苛刻。

数据作为AI系统的重要构成部分，数据质量问题是影响AI系统运行的关键因素，直接关系到AI系统建设的成败。根据“垃圾进，垃圾出（garbage in，garbage out）”的原理，为了使AI建设取得预期效果，达到数据决策的目标，要求所提供的数据是可靠的，能够准确反应客观事实。如果数据质量得不到保证，即使AI分析工具再先进，模型再合理，算法再优良，在充满“垃圾”的数据环境中也只能得到毫无意义的垃圾信息。系统运行的结果、做出的分析就可能是错误的，其至影响后续决策的制定和实行。高质量的数据来源于数据收集，是数据设计以及数据分析、评估、修正等环节的强力保证。因此，对于AI而言，数据质量管理尤为重要，这就需要建立一个有效的数据质量管理体系，尽可能全面地发现数据存在的问题并分析原因，以推动数据质量的持续改进。

1. 大数据环境下数据质量管理面临的挑战

随着移动互联网、云计算、物联网的快速发展，数据的生产者、生产环节都在急速攀升，随之快速产生的数据呈指数级增长。在信息和网络技术飞速发展的今天，越来越多的企业业务和社会活动实现了数字化。全球最大的零售商沃尔玛，每天通过分布在世界各地的6000多家商店向全球客户销售超过2.67亿件商品，每小时获得2.5PB的交易数据。而物联网下的传感数据也慢慢发展成了大数据的主要来源之一。有研究估计，到2020年则高达35.2ZB。此外，随着移动互联网、Web2.0技术和电子商务技术的飞速发展，大量的多媒体内容在呈指数级增长的数据量中发挥着重要作用。大数据时代的数据与传统数据呈现出了重大差别，直接影响到数据在流转环节中的各个方面，给数据存储处理分析性能、数据质量保障都带来了很大挑战，这更容易产生数据质量问题。

第3章 数据

93