3.5 数据平台
企业要做AI和大数据分析,首先要考虑数据的准备,这其实就是数据平台的建设。有人也许会问:业务跑得好好的,各系统稳定运行,为何还要搭建企业的数据平台?企业一般在什么情况下需要搭建数据平台,从而实现对各种数据进行重新架构?
• 从业务的视角来看:业务系统过多,彼此的数据没有打通。这种情况下,涉及数据分析就麻烦了,可能需要分析人员从多个系统中提取数据,再进行数据整合,之后才能分析。一次两次可以忍,天天干这个能忍吗?人为地整合出错率高怎么办?分析不及时效率低要不要处理?
• 从系统的视角来看:业务系统压力大,但很不巧,数据分析又是一项比较费资源的任务。那么自然会想到,通过将数据抽取出来,独立服务器来处理数据查询、分析的任务,从而释放业务系统的压力。
• 从数据处理性能的视角来看:企业越做越大,与此同时,数据也会越来越多。可能是历史数据的积累,也可能是新数据内容的加入。当原始数据平台不能承受更大数据量的处理时,或者效率已经十分低下时,重新构建一个大数据处理平台就是必需的了。
这三种情况有时并非独立的,往往是其中两种甚至三种情况同时出现。这时,一个数据平台的出现不仅可以承担数据分析的压力,还可以对业务数据进行整合,从而从不同程度上提高数据处理的性能,基于数据平台实现更丰富的功能需求。
AI和大数据分析的成功需要的不仅仅是原始数据,还需要好的且高质量的数据。更准确的说法应该是,AI的成功需要那些准备好的数据。对于分析,如果进来的是垃圾,那么出去的也是垃圾,这就意味着,如果你把大量参差不齐的数据放到分析解决方案中,你将会得到不好的结果。所以,大多数数据科学家和数据分析师花费大量时间来为AI准备数据。
数据平台通过打通数据通道实现数据汇聚、资源共享,同时提供数据的存储、计算、加工、分析等基础能力。大数据时代的到来,大家开始将数据当成资源,当作资产,数据管理的意义也越来越大。大数据管理平台的建设需要设计以下5个因素。
• 数据集中和共享。企业及基础数据平台是公共的、中性的,数据一定要做到集中和共享,否则就失去了它的意义。
• 数据标准统一。如果每个应用都有自己的一套标准,整个架构会越来越乱。
• 数据管理策略统一。方向是共性的数据一定要下沉,个性的数据逐渐上浮,也就是说,共性数据都尽量落在基础数据平台上,个性数据可以逐渐落在各个应用上处理。
• 减少数据复制。
• 长期和短期相结合。一个完整的企业级基础数据平台包含几个部分,即数据存储平台(包含相应的数据架构、数据存储策略以及应用切分点等)、应用(包含报表、数据挖掘、系统应用等)、数据管控(包含质量管理办法,比如数据标准等)、数据交换采集调度平台和数据处理(包含实施数据区、大数据处理、历史数据存储等)。这类混合架构既要考虑结构性数据的处理方法,也要考虑非结构化数据的处理和文本等的混合运算方法。这个结构能够帮助我们清晰地看到后续要发展成什么样,我们不一定开始就要完成这样一个体系,但是可以考虑好这些相应的数据项目,包括以后扩展的接口。
3.5.1 数据存储和计算
结构化、半结构化、文本、各类传感器的数据,音频、图片、视频等多媒体数据混杂,分别存储在不同的数据库、不同的地域中。如何处理这些数据?没有一个实时计算的数据平台几乎是很难实现的。大数据时代的业务场景是多元化的,不同的数据产品面向的场景很不一样。围绕这些多媒体为存储的核心对象来构建场景,清晰、及时地呈现业务,是非常重要的一项工作。
数据平台建设、部署对数据规范化定义,实现数据的唯一性、准确性、完整性、规范性和实效性,实现数据的共享共用,解决数据层面的孤岛问题。整合企业各个业务系统,形成数据平台。这就要求建立的数据平台能够整合各个业务系统,从物理和逻辑上将数据集中起来,同时数据平台起到了物理隔离生产系统、减轻对生产系统的压力、提升效率的作用。数据平台可以分成以下几类。
1. 常规数据仓库
常规数据仓库的重点在于数据整合,同时也是对业务逻辑的一个梳理。虽然也可以打包成saas(多维数据集)、cube(多维数据库)等来提升数据的读取性能,但是数据仓库的作用更多的是为了解决企业的业务问题,而不仅仅是性能问题。常规数据仓库的优点如下。
(1)方案成熟,关于数据仓库的架构有着非常广泛的应用,而且能将其落地的人也不少。
(2)实施简单,涉及的技术层面主要是仓库的建模以及ETL的处理,很多软件公司具备数据仓库的实施能力,实施难度的大小更多地取决于业务逻辑的复杂程度,而并非技术上的实现。
(3)灵活性强。数据仓库的建设是透明的,如果需要,可以对仓库的模型、ETL逻辑进行修改,来满足变更的需求。同时,对于上层的分析而言,通过SQL对仓库数据的分析处理具备极强的灵活性。
常规数据仓库的缺点如下。
(1)实施周期相对比较长。实施周期的长与短取决于业务逻辑的复杂性,时间花在业务逻辑的梳理,并非技术的瓶颈上。
(2)数据的处理能力有限。这个有限也是相对的,海量数据的处理肯定不行,非关系型数据的处理也不行,但是太字节(TB)以下级别数据的处理还是可以的(也取决于所采用的数据库系统)。对于这个量级的数据,相当一部分企业的数据其实是很难超过这个级别的。
实时处理的要求是区别大数据应用和传统数据仓库技术的关键差别之一。随着每天创建的数据量爆炸性的增长,就数据保存来说,传统数据库能改进的技术并不大,如此庞大的数据量存储就是传统数据库所面临的非常严峻的问题。
2. 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的数据平台。其稳定性是可以从侧面验证的。
Greenplum的缺点如下。
(1)本身来说,它的定位在OLAP领域,不擅长OLTP交易系统。当然,我们搭建的数据中心也不是用来做交易系统的。
(2)成本,有两个方面的考虑,一是硬件成本,Greenplum有其推荐的硬件规格,对内存、网卡都有要求,二是实施成本,这里主要是需要人,从基本的Greenplum的安装配置到Greenplum中数据仓库的构建,都需要人和时间。
(3)技术门槛,这里是相对于数据仓库的,Greenplum的门槛肯定更高一点。
3. Hadoop分布式系统架构
Hadoop已经非常火了,Greenplum的开源跟它也是脱不了关系的。它有着高可靠性、高扩展性、高效性、高容错性的口碑。在互联网领域有着非常广泛的运用,雅虎、Facebook、百度、淘宝、京东等都在使用Hadoop。Hadoop生态体系非常庞大,各公司基于Hadoop所实现的也不仅限于数据平台,还包括数据分析、机器学习、数据挖掘、实时系统等。
当企业数据规模达到一定的量级时,Hadoop应该是各大企业的首选方案。到达这样一个层次的时候,企业所要解决的不仅是性能问题,还包括时效问题、更复杂的分析挖掘功能的实现等。非常典型的实时计算体系也与Hadoop这一生态体系有着紧密的联系,比如Spark。近些年来,Hadoop的易用性有了很大的提升,SQL-on-Hadoop技术大量涌现,包括Hive、Impala、Spark SQL等。尽管其处理方式不同,但相比于原始的MapReduce模式,无论是性能还是易用性都有所提高。因此,对MPP产品的市场产生了压力。
对于企业构建数据平台来说,Hadoop的优势与劣势非常明显:优势是它的大数据处理能力、高可靠性、高容错性、开源性以及低成本(处理同样规模的数据,换其他方案试试就知道了);劣势是它的体系复杂,技术门槛较高(能搞定Hadoop的公司规模一般都不小)。
关于Hadoop的优缺点,对于公司的数据平台选型来说,影响已经不大了。需要使用Hadoop的时候,也没什么其他的方案可选择(要么太贵,要么不行),没达到这个数据量的时候,也没人愿意碰它。总之,不要为了大数据而大数据。
Hadoop生态圈提供海量数据的存储和计算平台,包括以下几种。
• 结构化数据:海量数据的查询、统计、更新等操作。
• 非结构化数据:图片、视频、Word、PDF、PPT等文件的存储和查询。
• 半结构化数据:要么转换为结构化数据存储,要么按照非结构化存储。
Hadoop的解决方案如下。
• 存储:HDFS、HBase、Hive等。
• 并行计算:MapReduce技术。
• 流计算:Storm、Spark。
如何选择基础数据平台?我们至少要从以下几个方面去考虑。
(1)目的:从业务、系统、性能三种视角去考虑,或者是其中几个的组合。当然,要明确数据平台建设的目的,有时并不容易,初衷与讨论后确认的目标或许是不一致的。比如,某企业要搭建一个数据平台的初衷可能很简单,只是为了减轻业务系统的压力,将数据拉出来后再分析,如果目的真的这么单纯,而且只有一个独立的系统,那么直接将业务系统的数据库复制一份就好了,不需要建立数据平台;如果是多系统,选型一些商业数据产品也够了,快速建模,直接用工具就能实现数据的可视化与OLAP分析。但是,既然已经决定要将数据平台独立出来,就不再多考虑一点吗?多个业务系统的数据不趁机梳理整合一下?当前只是分析业务数据的需求,以后会不会考虑历史数据呢?方案能否支撑明年和后年的需求?
(2)数据量:根据公司的数据规模选择合适的方案。
(3)成本:包括时间成本和金钱成本。但是这里有一个问题,很多企业要么不上数据平台,一旦有了这样的计划,就恨不得马上把平台搭建出来并用起来,不肯花时间成本。这样的情况很容易考虑欠缺,也容易被数据实施方忽悠。
在方案选型时,一个常见的误区是忽略业务的复杂性,要用工具来解决或者绕开业务的逻辑。企业选择数据平台的方案有着不同的原因,要合理地选型,既要充分地考虑搭建数据平台的目的,也要对各种方案有着充分的认识。对于数据层面来说,还是倾向于一些灵活性很强的方案,因为数据中心对于企业来说太重要了,更希望它是透明的,是可以被自己完全掌控的,这样才有能力实现对数据中心更加充分的利用。因为不知道未来需要它去担任一个什么样的角色。
3.5.2 数据质量
当前越来越多的企业认识到了数据的重要性,大数据平台的建设如雨后春笋般。但数据是一把双刃剑,它给企业带来业务价值的同时,也是组织最大的风险来源。糟糕的数据质量常常意味着糟糕的业务决策,将直接导致数据统计分析不准确、监管业务难、高层领导难以决策等问题,据IBM统计:
• 错误或不完整数据导致BI和CRM系统不能正常发挥优势甚至失效。
• 数据分析员每天有30%的时间浪费在了辨别数据是否是“坏数据”上。
• 低劣的数据质量严重降低了全球企业的年收入。
可见数据质量问题已经严重影响了企业业务的正常运营。在企业信息化初期,各类业务系统恣意生长。后来业务需求增长,需要按照统一的架构和标准把各类数据集成起来,这个阶段问题纷纷出现,数据不一致、不完整、不准确等各种问题扑面而来。费了九牛二虎之力才把数据融合起来,如果因为数据质量不高而无法完成数据价值的挖掘,那就太可惜了。
大数据时代数据集成融合的需求会愈加迫切,不仅要融合企业内部的数据,也要融合外部(互联网等)数据。如果没有对数据质量问题建立相应的管理策略和技术工具,那么数据质量问题的危害会更加严重。数据质量问题会造成“垃圾进,垃圾出”。数据质量不好造成的结果是对业务的分析不但起不到好的效果,相反还有误导的作用。很多人可能在纠结,数据质量问题究竟是“业务”的问题还是“技术”的问题。根据我们以往的经验,造成数据质量问题的原因主要分为以下几种:
(1)数据来源渠道多,责任不明确。
(2)业务需求不清晰,数据填报缺失。
(3)ETL处理过程中,业务部门变更代码导致数据加工出错,影响报表的生成。
(1)和(2)都是业务的问题,(3)虽然表面上看是技术的问题,但本质上还是业务的问题。因此,大部分数据质量问题主要还是来自于业务。很多企业认识不到数据质量问题的根本原因,只从技术单方面来解决数据问题,没有形成管理机制,导致效果大打折扣。在走过弯路之后,很多企业认识到了这一点,开始从业务着手解决数据质量问题。在治理数据质量问题时,采用规划顶层设计,制定统一数据架构、数据标准,设计数据质量的管理机制,建立相应的组织架构和管理制度,采用分类处理的方式持续提升数据质量。还有,通过增加ETL数据清洗处理逻辑的复杂度,提高ETL处理的准确度。
1. AI系统本身的数据质量
在大数据时代,信息由数据构成,数据是信息的基础,数据已经成为一种重要资源。数据质量成为决定资源优劣的一个重要方面。随着大数据的发展,越来越丰富的数据给数据质量的提升带来了新的挑战和困难。对于企业而言,进行市场情报调研、客户关系维护、财务报表展现、战略决策支持等都需要进行数据的搜集、分析、知识发现,为决策者提供充足且准确的情报和资料。对于政府而言,进行社会管理和公共服务影响面更为宽广和深远,政策和服务能否满足社会需要,是否高效地使用了公共资源,都需要数据提供支持和保障,因而对数据的需求显得更为迫切,对数据质量的要求也更为苛刻。
数据作为AI系统的重要构成部分,数据质量问题是影响AI系统运行的关键因素,直接关系到AI系统建设的成败。根据“垃圾进,垃圾出(garbage in, garbage out)”的原理,为了使AI建设取得预期效果,达到数据决策的目标,要求所提供的数据是可靠的,能够准确反应客观事实。如果数据质量得不到保证,即使AI分析工具再先进,模型再合理,算法再优良,在充满“垃圾”的数据环境中也只能得到毫无意义的垃圾信息。系统运行的结果、做出的分析就可能是错误的,甚至影响后续决策的制定和实行。高质量的数据来源于数据收集,是数据设计以及数据分析、评估、修正等环节的强力保证。因此,对于AI而言,数据质量管理尤为重要,这就需要建立一个有效的数据质量管理体系,尽可能全面地发现数据存在的问题并分析原因,以推动数据质量的持续改进。
2. 大数据环境下数据质量管理面临的挑战
随着移动互联网、云计算、物联网的快速发展,数据的生产者、生产环节都在急速攀升,随之快速产生的数据呈指数级增长。在信息和网络技术飞速发展的今天,越来越多的企业业务和社会活动实现了数字化。全球最大的零售商沃尔玛,每天通过分布在世界各地的6000多家商店向全球客户销售超过2.67亿件商品,每小时获得2.5PB的交易数据。而物联网下的传感数据也慢慢发展成了大数据的主要来源之一。有研究估计,到2020年则高达35.2ZB。此外,随着移动互联网、Web 2.0技术和电子商务技术的飞速发展,大量的多媒体内容在呈指数级增长的数据量中发挥着重要作用。大数据时代的数据与传统数据呈现出了重大差别,直接影响到数据在流转环节中的各个方面,给数据存储处理分析性能、数据质量保障都带来了很大挑战,这更容易产生数据质量问题。
(1)在数据收集方面,大数据的多样性决定了数据来源的复杂性。来源众多、结构各异、大量不同的数据源之间存在着冲突、不一致或相互矛盾的现象。在数据获取阶段,保证数据定义的完整性、数据质量的可靠性尤为必要。
(2)由于规模大,大数据在获取、存储、传输和计算过程中可能产生更多错误。采用传统数据的人工错误检测与修复或简单的程序匹配处理远远处理不了大数据环境下的数据问题。
(3)由于高速性,数据的大量更新会导致过时数据迅速产生,也更易产生不一致数据。
(4)由于发展迅速、市场庞大、厂商众多、直接产生的数据或者产品产生的数据标准不完善,使得数据有更大的可能产生不一致和冲突。
(5)由于数据生产源头激增、产生的数据来源众多、结构各异,以及系统更新、升级加快和应用技术更新换代频繁,使得不同的数据源之间、相同的数据源之间都可能存在着冲突、不一致或相互矛盾的现象,再加上数据收集与集成往往由多个团队协作完成,增大了数据处理过程中产生问题数据的概率。
因此,我们需要一种数据质量策略,从建立数据质量评价体系、落实质量信息的采集分析与监控、建立持续改进的工作机制和完善元数据管理4个方面,多方位优化改进,最终形成一套完善的质量管理体系,为信息系统提供高质量的数据支持。
3. 建立数据质量管理策略和评价体系
为了改进和提高数据质量,必须从产生数据的源头开始抓起,从管理入手,对数据运行的全过程进行监控,密切关注数据质量的发展和变化,深入研究数据质量问题所遵循的客观规律,分析其产生的机理,探索科学有效的控制方法和改进措施。必须强化全面数据质量管理的思想观念,把这一观念渗透到数据生命周期的全过程。建立数据质量评价体系,评估数据质量,可以从以下4个方面来考虑。
(1)完整性:数据的记录和信息是否完整,是否存在缺失情况。
(2)一致性:数据的记录是否符合规范,是否与前后及其他数据集保持统一。
(3)准确性:数据中记录的信息和数据是否准确,是否存在异常或者错误信息。
(4)及时性:数据从产生到可以查看的时间间隔,也叫数据的延时时长。
有了评估方向,还需要使用可以量化、程序化识别的指标来衡量。通过量化指标,管理者才可能了解到当前的数据质量,并确定采取修正措施之后数据质量的改进程度。而对于海量数据,数据量大、处理环节多,获取质量指标的工作不可能由人工或简单的程序来完成,而需要程序化的制度和流程来保证,因此指标的设计、采集与计算必须是程序可识别处理的。
完整性可以通过记录数和唯一值来衡量。比如某类交易数据,每天的交易量应该呈现出平稳的特点,平稳增长或保持一定范围内的周期波动。如果记录数量出现激增或激减,就需要追溯是在哪个环节出现了变动,最终定位是数据问题还是服务问题。对于属性的完整性考量,则可以通过空值占比或无效值占比来进行检查。
一致性检验主要是检验数据和数据定义是否一致,因此可以通过合规记录的比率来衡量。比如取值范围是枚举集合的数据,其实际值超出范围之外的数据占比,比如存在特定编码规则的属性值,不符合其编码规则的记录占比。还有一些存在逻辑关系的属性之间的校验,比如属性A取某定值时,属性B的值应该在某个特定的数据范围内,都可以通过合规率来衡量。
准确性可能存在于个别记录,也可能存在于整个数据集上。准确性和一致性的差别在于,一致性关注合规,表示统一,而准确性关注数据错误。因此,同样的数据表现,比如数据的实际值不在定义的范围内,如果定义的范围准确,值完全没有意义,就属于数据错误。但如果值是合理且有意义的,可能是范围定义不够全面,就不能认定为数据错误,而应该去补充修改数据的定义。
通过建立数据质量评价体系,对整个流通链条上的数据质量进行量化指标输出,后续进行问题数据的预警,使得问题一出现就可以暴露出来,便于进行问题的定位和解决,最终可以实现在哪个环节出现问题就在哪个环节解决,避免将问题数据带到后端以及质量问题扩大。
4. 落实数据质量信息的采集、分析与监控
有评价体系作为参照,还需要进行数据的采集、分析和监控,为数据质量提供全面可靠的信息。在数据流转环节的关键点上设置采集点,采集数据质量监控信息,按照评价体系的指标要求输出分析报告。通过对来源数据的质量分析,可以了解数据和评价接入数据的质量,通过对不同采集点的数据分析报告的对比,可以评估数据处理流程的工作质量。配合数据质量的持续改进工作机制,进行质量问题原因的定位、处理和跟踪。
5. 建立数据质量的持续改进工作机制
通过质量评价体系和质量数据采集系统可以发现问题,之后还需要对发现的问题及时做出反应,追溯问题的原因和形成机制,根据问题的种类采取相应的改进措施,并持续跟踪验证改进之后的数据质量提升效果,形成正反馈,达到数据质量持续改良的效果。在源头建立数据标准或接入标准,规范数据定义,在数据流转过程中建立监控数据转换质量的流程和体系,尽量做到在哪里发现问题就在哪里解决问题,不把问题数据带到后端。
导致数据质量产生问题的原因很多。有研究表示,从问题的产生原因和来源,可以分为四大问题域:信息问题域、技术问题域、流程问题域和管理问题域。“信息类问题”是由于对数据本身的描述、理解及度量标准偏差而造成的数据质量问题。产生这类数据质量问题的主要原因包括:数据标准不完善、元数据描述及理解错误、数据质量得不到保证和变化频度不恰当等。“技术类问题”是指由于在数据处理流程中数据流转的各技术环节异常或缺陷而造成的数据质量问题,产生的直接原因是技术实现上的某种缺陷。技术类数据质量问题主要产生在数据创建、数据接入、数据抽取、数据转换、数据装载、数据使用和数据维护等环节。“流程类问题”是指由于数据流转的流程设计不合理、人工操作流程不当造成的数据质量问题。所有涉及数据流转流程的环节都可能出现问题,比如接入新数据缺乏对数据检核、元数据变更没有考虑到历史数据的处理、数据转换不充分等各种流程设计错误、数据处理逻辑有缺陷等问题。“管理类问题”是指由于人员素质及管理机制方面的原因造成的数据质量问题。比如数据接入环节由于工期压力而减少对数据检核流程的执行和监控、缺乏反馈渠道及处理责任人、相关人员缺乏培训等带来的一系列问题。
了解问题产生的原因和来源后,就可以对每一类问题建立起识别、反馈、处理、验证的流程和制度。比如数据标准不完善导致的问题,就需要有一整套数据标准问题识别、标准修正、现场实施和验证的流程,确保问题的准确解决,不带来新的问题。比如缺乏反馈渠道和处理责任人的问题,则属于管理问题,需要建立一套数据质量的反馈和响应机制,配合问题识别、问题处理、解决方案的现场实施与验证、过程和积累等多个环节和流程,保证每一个问题都能得到有效解决并有效积累处理的过程和经验,形成越来越完善的有机运作体。当然,很多问题是相互影响的,单一地解决某一方面的问题可能暂时解决不了所发现的问题,但是当多方面的持续改进机制协同工作起来之后,互相影响,交错前进,一点点改进,最终就会达到一个比较好的效果。
6. 完善元数据管理
数据质量的采集规则和检查规则本身也是一种数据,在元数据中定义。元数据按照官方定义,是描述数据的数据。面对庞大的数据种类和结构,如果没有元数据来描述这些数据,使用者就无法准确地获取所需的信息。正是通过元数据,海量的数据才可以被理解、使用,才会产生价值。
元数据可以按照其用途分为3类:技术元数据、业务元数据和管理元数据。“技术元数据”是存储关于信息系统技术细节的数据,是开发和管理数据而使用的数据。主要包括数据结构的描述,包括对数据结构、数据处理过程的特征描述,存储方式和位置覆盖涉及整个数据的生产和消费环节。“业务元数据”是从业务角度描述数据系统中的数据,提供了业务使用者和实际系统之间的语义层,主要包括业务术语、指标定义、业务规则等信息。“管理元数据”是描述系统中管理领域相关概念、关系和规则的数据,主要包括人员角色、岗位职责、管理流程等信息。良好的元数据管理系统能为数据质量的采集、分析、监控、改进提供高效、有力的强大保障。同时,良好的数据质量管理系统也能促进元数据管理系统的持续改进,互相促进完善,共同为一个高质量和高效运转的数据平台提供支持。
7. 对不同的数据问题分类处理
从时间维度上分,企业数据主要有三类:未来数据、当前数据和历史数据。在解决不同种类的数据质量问题时,要采取不同的处理方式。
如果你拿着历史数据找业务部门做整改,业务部门通常以“当前的数据问题都处理不过来,哪有时间帮你追查历史数据的问题”为理由无情拒绝。这个时候即便是找领导协调,一般也起不到太大的作用。对于历史数据问题的处理,一般可以发挥IT技术人员的优势,用数据清洗的办法来解决,清洗的过程要综合使用各类数据源,提升历史数据的质量。
当前数据的问题需要从问题定义、问题发现、问题整改、问题跟踪、效果评估5个方面来解决。未来数据的处理一般要采用做数据规划的方法来解决,从整个企业信息化的角度出发,规划统一企业数据架构,制定企业数据标准和数据模型。借业务系统改造或者重建的时机,来从根本上提高数据质量。当然,这种机会是可遇而不可求的,在机会到来之前,应该把企业数据标准和数据模型建立起来,一旦机会出现,就可以遵循这些标准。
总之,通过对不同时期数据的分类处理,采用不同的处理方式做到事前预防、事中监控、事后改善,能从根本上解决数据质量问题,为企业业务创新打通数据关卡。数据质量(Data Quality)管理贯穿数据生命周期的全过程,覆盖质量评估、数据监控、数据探查、数据清洗、数据诊断等方面。数据源在不断增多,数据量在不断加大,新需求推动的新技术也在不断诞生,这些都对大数据下的数据质量管理带来了困难和挑战。因此,数据质量管理要形成完善的体系,建立持续改进的流程和良性机制,持续监控各系统数据质量的波动情况及数据质量的规则分析,适时升级数据质量监控的手段和方法,确保持续掌握系统数据的质量状况,最终达到数据质量的平稳状态,为AI系统提供良好的数据保障。数据质量问题需要业务部门参与才能从根本上解决。要发挥数据资产的价值,需要将组织、技术和流程三者进行有机结合,从业务出发做问题定义,由工具自动、及时发现问题,跟踪问题整改进度,并建立相应的质量问题评估KPI。通过数据质量问题全过程的管理,才能最终实现数据质量持续提升的目标,支撑数据业务应用,体现数据价值。
3.5.3 数据管理
数据管理和数据治理有很多地方是互相重叠的,它们都围绕数据这个领域展开,因此这两个术语经常被混为一谈。此外,每当人们提起数据管理和数据治理的时候,还有一对类似的术语叫信息管理和信息治理,更混淆了人们对它们的理解。关于企业信息管理这个课题,还有许多相关的子集,包括主数据管理、元数据管理、数据生命周期管理等。于是,出现了许多不同的理论描述关于企业中数据/信息的管理以及治理如何运作:它们如何单独运作,又如何一起协同工作,是“自下而上”还是“自上而下”的方法更高效?
1. 数据治理
其实,数据管理包含数据治理,治理是整体数据管理的一部分,这个概念目前已经得到了业界的广泛认同。数据管理包含多个不同的领域,其中一个最显著的领域就是数据治理。CMMI协会颁布的数据管理成熟度(DMM)模型使这个概念具体化。DMM模型中包括6个有效数据管理分类,而其中一个就是数据治理。数据管理协会(DAMA)在数据管理知识体系(DMBOK)中也认为,数据治理是数据管理的一部分。在企业信息管理(EIM)这个定义上,Gartner认为EIM是“在组织和技术的边界上结构化、描述、治理信息资产的一个综合学科”。Gartner这个定义不仅强调了数据/信息管理和治理的紧密关系,也重申了数据管理包含治理这个观点。
在明确数据治理是数据管理的一部分之后,下一个问题就是定义数据管理。数据管理是一个更为广泛的定义,它与任何时间采集和应用数据的可重复流程的方方面面都紧密相关。例如,简单地建立和规划一个数据平台,是数据管理层面的工作。定义谁以及如何访问这个数据平台,并且实施各种各样针对元数据和资源库管理工作的标准,也是数据管理层面的工作。数据管理包含许多不同的领域。
• 元数据:元数据要求数据元素和术语的一致性定义,它们通常聚集于业务词汇表上。对于企业而言,建立统一的业务术语非常关键,如果这些术语和上下文不能横跨整个企业的范畴,那么它将会在不同的业务部门中出现不同的表述。
• 生命周期管理:数据保存的时间跨度、数据保存的位置以及数据如何使用都会随着时间而产生变化,某些生命周期管理还会受到法律法规的影响。
• 数据质量:数据质量的具体措施包括数据详细检查的流程,目的是让业务部门信任这些数据。数据质量是非常重要的。
• “引用数据”管理:“引用数据”提供数据的上下文,尤其是它结合元数据一起考虑的情况下。由于引用数据变更的频率较低,引用数据的管理经常会被忽视。
2. 数据建模
数据建模是另一个数据管理中的关键领域。利用一个规范化的数据建模有利于将数据管理工作扩展到其他业务部门。遵从一致性的数据建模,令数据标准变得有价值(特别是应用于大数据和AI)。我们利用数据建模技术直接关联不同的数据管理领域,例如数据血缘关系以及数据质量。当需要合并非结构化数据时,数据建模将会更有价值。此外,数据建模加强了管理的结构和形式。
数据管理在DMM中有5个类型,包括数据管理战略、数据质量、数据操作(生命周期管理)、平台与架构(例如集成和架构标准)以及支持流程。数据管理本身着重提供一整套工具和方法,确保企业实际管理好这些数据。首先是数据标准,有了标准才有数据质量,质量是数据满足业务需求使用的程度。有了标准之后,能够衡量数据,可以在整个平台的每一层做技术上的校验或者业务上的校验,可以做到自动化的配置和相应的校验,生成报告来帮助我们解决问题。有了数据标准,就可以建立数据模型了。数据模型至少包括以下内容:
• 数据元(属性)定义。
• 数据类(对象)定义。
• 主数据管理。
大数据对现有数据库管理技术产生了很多挑战。同样,在传统数据库上,创建大数据的数据模型可能会面临很多挑战。经典数据库技术并没有考虑数据的多类别(Variety),也没有考虑非结构化数据的存储问题。一般而言,借助数据建模工作也可以在传统数据库上创建多类别的数据模型,或直接在HBase等大数据数据库系统上创建。
数据模型是分层次的,主要分为三层,基础模型一般用于关系建模,主要实现数据的标准化;融合模型一般用于维度建模,主要实现跨越数据的整合,整合的形式可以是汇总、关联,也包括解析;挖掘模型其实是偏应用的,但如果用的人多了,你也可以把挖掘模型作为企业的知识沉淀到平台,比如某个模型具有很大的共性,就应该把它规整到平台模型,以便开放给其他人使用,这是相对的,没有绝对的标准。
3.5.4 数据目录
数据目录管理系统应该具备以下的能力(见图3-14)。
图3-14 数据目录系统功能图
1. 数据的连接和发现能力
做大数据分析和AI首先需要清晰地知道我们有哪些数据,通过人工梳理的方式显然已经跟不上数据增长和变化的速度。所以,一个数据目录最基础的能力就是可以连接我们拥有的多种数据源(如HDFS、MySQL、HBase、ORACLE等),并且可以定时地监测新生成的数据,在数据目录中根据规则自动注册为数据集或更新数据集状态(如关系型数据库新产生的表可注册为数据集,HDFS分区格式数据只更新当前数据集的容量大小,等等,一般需要人工辅助审核和修改)。
2. 元数据管理能力
元数据管理能力包括以下三个方面。
• 数据集基本信息:包括数据集的名称、标签(业务分类)、负责人以及存储详情的变动趋势。
• 字段描述信息:字段的数据类型、字段的业务类型、字段的描述信息、整个Schema的版本控制。
• 数据规格:数据资产部门或者数据负责人维护数据说明的页面,包括数据的生成方式、使用范围、注意事项等。提供数据规格的编写能力,方便版本控制,用户可以按照时间线来查询数据规格。
3. 检索筛选和用户自组织能力
• 检索筛选能力:如果数据目录没有强大的检索能力,系统中数据集的信息和沉淀的相关知识就不能实现其价值,也不能促进系统的良性循环。检索和筛选的内容包括数据集名称、标签、描述、字段相关信息、数据内容、数据规格详情等。
• 用户自组织数据集的能力:不同用户使用数据集的场景不一样,所以组织方式也会不一样。每个用户可以按照自己的理解和需求组织自己的数据目录,方便用户的使用。同时,不同用户根据不同场景对数据集的组织方式也是一种知识,可以沉淀。
4. 安全和共享能力
• 权限和审计:为数据集的访问提供权限控制。主要体现在数据集的访问申请和审批上。想要使用数据集的用户可以在系统中申请,访问申请会自动转向数据集所有者(负责人),数据集所有者需要在系统中答复。所有申请和审批都以时间线的方式组织,方便审计人员查阅和检索。所有用户对数据集的操作都需要做记录。
• 共享能力:数据集及相关信息分享给使用者,使用者可以看到数据集的元数据等详情。
• 开放能力:数据目录应该提供数据集的访问接口,可以支持内部数据探索工具、数据ETL工具的调用,可以支持外部客户的调用和加工。
图3-15是一个数据目录管理系统的实例图。
图3-15 数据目录管理系统实例
3.5.5 数据安全管控
如图3-16所示,安全保障体系架构包括安全技术体系和安全管理体系。安全技术体系采取技术手段、策略、组织和运作体系紧密结合的方式,从应用、数据、主机、网络、物理等方面进行信息安全建设。
图3-16 安全体系框架
(1)应用安全,从身份鉴别、访问控制、安全审计、剩余信息保护、通信完整性、通信保密性、抗抵赖、软件容错、资源控制、代码安全等方面进行考虑。
(2)数据安全,从数据属性、空间数据、数据完整性、数据敏感性、数据备份和恢复等方面进行考虑。
(3)主机安全,从身份鉴别、访问控制、安全审计、剩余信息保护、入侵防范、恶意代码防范、资源控制等方面进行考虑。
(4)网络安全,从结构安全、访问控制、安全审计、边界完整性检查、入侵防范、恶意代码防范和网络设备防护等方面进行考虑。
(5)物理安全,是指机房物理环境达到国家信息系统安全和信息安全相关规定的要求。
安全管理体系建设具体包括安全管理制度、安全管理机构、人员安全管理、系统建设管理、系统运维管理等方面的建设。
数据安全管控是整个安全体系框架的一个组成部分,它是从属性数据、空间数据、数据完整性、数据保密性、数据备份和恢复等几方面考虑的。对于一些敏感数据,数据的传输与存储采用不对称加密算法和不可逆加密算法确保数据的安全性、完整性和不可篡改性。对于敏感性极高的空间数据,坐标信息通过坐标偏移、数据加密算法及空间数据分存等方法进行处理。在数据的传输、存储、处理的过程中,使用事务传输机制对数据完整性进行保证,使用数据质量管理工具对数据完整性进行校验,在监测到完整性错误时进行告警,并采用必要的恢复措施。数据的安全机制应至少包含以下4个部分。
(1)身份/访问控制。通过用户认证与授权实现,在授权合法用户进入系统访问数据的同时,保护其免受非授权的访问。在安全管控平台实施集中的用户身份、访问、认证、审计、审查管理,通过动态密码、CA证书等设置认证。
(2)数据加密。在数据传输的过程中,采用对称密钥或VPN隧道等方式进行数据加密,再通过网络进行传输。在数据存储上,对敏感数据先加密后存储。
(3)网络隔离。通过内外网方式保障敏感数据的安全性,即数据传输采用公网,存储采用内网。
(4)灾备管理。通过数据镜像、数据备份、分布式存储等方式实现,保障数据安全。
3.5.6 数据准备
如今的数据往往来自文件系统、数据库、数据湖、传感器或外部数据源。为了满足各类数据的AI分析需求,我们必须将所有数据采集,并将各个数据源的数据互相关联整合,比如:
• 来自电商平台的数据与客户关系管理中的客户数据集成在一起,以定制营销策略。
• 物联网传感器数据与运营和财务数据库中的数据相关联,以控制吞吐量并报告制造过程的质量。
• 开发预测模型的数据科学家通常会加载多种外部数据源,例如计量经济学、天气、人口普查和其他公共数据,然后将其与内部资源融合。
• 试验人工智能的创新团队需要汇总可用于训练和测试算法的大型复杂数据源。
1. 数据整合工具与平台
那么,用什么工具和做法来整合数据源,什么平台被用来自动化整合数据?主要类型如下:
• 编程和脚本完成数据集成。
• 提取、转换和加载(ETL)工具。
• 数据高速公路SaaS平台。
• 具有数据集成功能的大数据管理平台。
• AI注入数据集成平台。
(1)数据集成编程与脚本
对于工程师来说,将数据从源文件移动到目标文件最常见的方式是开发一个简短的脚本。这些脚本通常以几种模式之一运行:它们可以按照预定义的时间表运行,也可以作为由事件触发的服务运行,或者在满足定义的条件时做出响应。工程师可以从多个来源获取数据,在将数据传送到目标数据源之前加入过滤、清理、验证和数据转换。
脚本是移动数据的快捷方式,但它不是专业级的数据处理方法。要成为生产级的数据处理脚本,需要自动执行处理和传输数据所需的步骤,并处理多种操作需求。例如,若脚本正在处理大量数据,则可能需要使用Apache Spark或其他并行处理引擎来运行多线程作业。如果输入的数据不干净,程序员应该启用异常处理并在不影响数据流的情况下踢出记录。数据集成脚本通常难以跨多个开发人员进行维护。出于这些原因,具有较大数据集成需求的组织通常不会只用编程和脚本来实现数据集成。
(2)提取、转换与加载工具
自20世纪70年代以来,ETL技术已经出现,IBM、Informatica、微软、Oracle、Talend等公司提供的ETL工具在功能、性能和稳定性方面已经成熟。这些平台提供可视化编程工具,让开发人员能够分解并自动执行从源中提取的数据,执行转换并将数据推送到目标存储库的步骤。由于它们是可视化的,并将数据流分解为原子步骤,与难以解码的脚本相比,管道更易于管理和增强。另外,ETL平台通常提供操作界面来显示数据管道崩溃的位置并提供重启它们的步骤。
多年来,ETL平台增加了许多功能。大多数平台可以处理来自数据库、平面文件和Web服务的数据,无论它们在本地、云中,还是在SaaS数据存储中。它们支持各种数据格式,包括关系数据、XML和JSON等半结构化格式,以及非结构化数据和文档。许多工具使用Spark或其他并行处理引擎来并行化作业。企业级ETL平台通常包括数据质量功能,因此数据可以通过规则或模式进行验证,并将异常发送给数据管理员进行解决。
当数据源持续提供新数据并且目标数据存储的数据结构不会频繁更改时,通常会使用ETL平台。
(3)面向SaaS平台的数据高速公路
是否有更有效的方法从常见数据源中提取数据呢?也许主要数据目标是从Salesforce、Microsoft Dynamics或其他常见CRM程序中提取账户或客户联系人。或者,营销人员希望从Google Analytics等工具中提取网络分析数据。我们应该如何防止SaaS平台成为云中的数据孤岛,并轻松实现双向数据流呢?如果我们已经拥有ETL工具,则需要查看该工具是否提供通用SaaS平台的标准连接器。如果我们没有ETL工具,那么可能需要一个易于使用的工具来构建简单的数据高速公路。
Scribe、Snaplogic和Stitch等数据高速公路工具提供了简单的网络界面,可以连接到常见的数据源,选择感兴趣的领域,执行基本转换,并将数据推送到常用目的地。数据高速公路的另一种形式有助于更接近实时地整合数据。它通过触发器进行操作,因此当源系统中的数据发生更改时,可以将其操作并推送到辅助系统。IFTTT、Workato和Zapier就是这类工具的例子。这些工具对于将单个记录从一个SaaS平台转移到另一个SaaS平台时特别有用。在评估它们时,请考虑它们集成的平台数量、处理逻辑的功能和简单性以及价格。
(4)大数据企业平台与数据集成功能
如果正在Hadoop或其他大数据平台上开发功能,则可以选择:
• 开发脚本或使用支持大数据平台的ETL工具作为端点。
• 具有ETL、数据治理、数据质量、数据准备和主数据功能的端到端数据管理平台。
许多提供ETL工具的供应商也出售具有这些新型大数据功能的企业平台。还有像Datameer和Unifi这样的新兴平台可以实现自助服务(如数据准备工具),并可以在Hadoop发行版上运行。
(5)AI驱动型数据集成平台
一些下一代数据集成工具将包括人工智能功能,以帮助自动化重复性任务或识别难以找到的数据模式。例如,Informatica提供了智能数据平台Claire,而Snaplogic正在营销Iris,它“推动自我驱动整合”。
2. ETL
ETL就是对数据的合并、清理和整合。通过转换可以实现不同的源数据在语义上的一致性。数据采集平台主要是ETL,它是数据处理的第一步,一切的开端。有数据库就会有数据,就需要采集。在数据挖掘的范畴中,数据清洗的前期过程可简单地认为是ETL的过程。ETL伴随着数据挖掘发展至今,其相关技术也已非常成熟。
(1)概念
ETL是Extract(提取)、Transform(转换)、Load(加载)三个单词的首字母。ETL负责将分散的、异构数据源中的数据(如关系数据库数据、平面数据文件等)抽取到临时中间层后,进行清洗、转换和集成,最后加载到大数据平台中,成为为分析处理、数据挖掘提供决策支持的数据。
ETL是构建大数据平台重要的一环,用户从数据源抽取所需的数据,经过数据清洗,最终按照预先定义好的数据模型将数据加载到大数据平台中。ETL技术已发展得相当成熟,似乎并没有什么深奥之处,但在实际的项目中,却常常在这个环节上耗费太多的人力,而在后期的维护上,往往更费脑筋。导致上面的原因往往是在项目初期没有正确地估计ETL的工作,没有认真地考虑其与工具支撑有很大的关系。
在做ETL产品选型的时候,仍然必不可少地要考虑4点:成本、人员经验、案例和技术支持。ETL工具包括Datastage、Powercenter、Kettle等。在实际ETL工具应用的对比上,对元数据的支持、对数据质量的支持、维护的方便性、对定制开发功能的支持等方面是我们选择的切入点。一个项目,从数据源到最终目标平台,多则达上百个ETL过程,少则也有十几个。这些过程之间的依赖关系、出错控制以及恢复的流程处理都是工具所需要重点考虑的内容。
(2)过程
在整个数据平台的构建中,ETL工作占整个工作的50%~70%。要求的第一点就是,团队协作性要好。ETL包含E、T、L,还有日志的控制、数据模型、数据验证、数据质量等方面。例如,我们要整合一个企业亚太区的数据,但是每个国家都有自己的数据源,有的是ERP,有的是Access,而且数据库都不一样,要考虑网络的性能问题,如果直接用JDBC连接两地的数据源,这样的做法显然是不合理的,因为网络不好,经常连接,很容易导致数据库连接不能释放导致死机。如果我们在各地区的服务器放置一个数据导出为Access或者文件的程序,这样文件就可以比较方便地通过FTP的方式进行传输。下面我们指出上述案例需要做的几项工作。
① 有人写一个通用的数据导出工具,可以用Java、脚本或其他的工具,总之要通用,可以通过不同的脚本文件来控制,使各地区的不同数据库导出的文件格式是一样的。而且还可以实现并行操作。
② 有人写FTP的程序,可以用BAT、ETL工具或其他的方式,总之要准确,而且方便调用和控制。
③ 有人设计数据模型,包括在1之后导出的结构。
④ 有人写SP,包括ETL中需要用到的SP和日常维护系统的SP,比如检查数据质量之类的。
⑤ 有人分析源数据,包括表结构、数据质量、空值和业务逻辑。
⑥ 有人负责开发流程,包括实现各种功能,还有日志的记录,等等。
⑦ 有人测试真正好的ETL,都是团队来完成的,一个人的力量是有限的。
(3)ETL处理步骤
主要从E、T、L和异常处理简单地说明。
① 数据清洗
• 数据补缺:对空数据、缺失数据进行数据补缺操作,无法处理的做标记。
• 数据替换:对无效数据进行数据的替换。
• 格式规范化:将源数据抽取的数据格式转换成为目标数据格式。
• 主外键约束:通过建立主外键约束,对非法数据进行数据替换或导出到错误文件重新处理。
② 数据转换
• 数据合并:多用表关联实现,大小表关联用lookup,大大表相交用join(每个字段加索引,保证关联查询的效率)。
• 数据拆分:按一定规则进行数据拆分。
• 行列互换、排序/修改序号、去除重复记录。
• 数据验证:loolup、sum、count。
实现方式包含两种,一种是在ETL引擎中进行的(SQL无法实现的);另一种是在数据库中进行的(SQL可以实现的)。
③ 数据加载
• 时间戳方式:在业务表中统一添加字段作为时间戳,当业务系统修改业务数据时,同时修改时间戳字段值。
• 日志表方式:在业务系统中添加日志表,业务数据发生变化时,更新维护日志表的内容。
• 全表对比方式:抽取所有源数据,在更新目标表之前先根据主键和字段进行数据比对,有更新的进行update或insert。
• 全表删除插入方式:删除目标表数据,将源数据全部插入。
④ 异常处理
在ETL的过程中,面临数据异常的问题不可避免,处理办法为:
• 将错误信息单独输出,继续执行ETL,错误数据修改后再单独加载。或者中断ETL,修改后重新执行ETL。原则是最大限度地接收数据。
• 对于网络中断等外部原因造成的异常,设定尝试次数或尝试时间,超数或超时后,由外部人员手工干预。
• 诸如源数据结构改变、接口改变等异常状况,应进行同步后,再装载数据。
ETL不是想象中的一蹴而就,在实际过程中,你会遇到各种各样的问题,甚至是部门之间沟通的问题。给它定义到占据整个项目50%~70%是不足为过的。
如图3-17所示是一个大数据采集平台,提供数据获取、清理、更换和存储数据。该平台允许访问不同的数据源,让不同的采集任务可以同时访问多个数据源。它可以追踪采集过程中的每个步骤。该产品既可以作为云服务部署来确保数据准备的灵活性,也可以作为内部部署的解决方案,可以整合到Hadoop、数据库和各种报表呈现工具中,以更快获取价值。
图3-17 大数据采集平台
总之,大数据现在是一个热门话题,但企业和IT领导者需要明白,分析糟糕的数据意味着糟糕的分析结果,可能会造成错误的商业决策。正因为如此,读者一定要高度重视数据准备。在大数据平台建设中,推进数据标准体系建设,制定有关大数据的数据采集、数据开放、分类目录和关键技术等标准,推动标准符合性评估。要加大标准实施力度,完善标准服务、评测、监督体系,坚持标准先行。
3. 数据profile能力
数据的profile能力包括:
• 数据集的条数、空值等。
• 针对枚举字段枚举值的统计,针对数据类型字段数值分布范围的统计。
• 用户自定义策略的统计。提供用户自定义界面,可以组合各种规则统计数据集中满足条件的数据条数。
• 针对各类指标的时序可视化展示。数据profile有了时序的概念,才能做一些数据趋势的分析,以及监控和报警。
数据平台应该可灵活配置数据集profile的计算频率。对于不同的数据集,数据量差距很大。针对一个小表,数据集的profile可能秒出,大库大表的数据集的profile只能定时运行了。
3.5.7 数据整合
数据整合是对导入的各类源数据进行整合,新进入的源数据匹配到平台上的标准数据,或者成为系统中新的标准数据。数据整合工具对数据关联关系进行设置。经过整合的源数据实现了基本信息的唯一性,同时又保留了与原始数据的关联性。具体功能包括关键字匹配、自动匹配、新增标准数据和匹配质量校验4个模块。有时,需要对标准数据列表中的重复数据进行合并,在合并时保留一个标准源。对一些拥有上下级关联的数据,对它们的关联关系进行管理设置。
数据质量校验包括数据导入质量校验和数据整合质量校验两个部分,数据导入质量校验的工作过程是通过对原始数据与平台数据从数量一致性、重点字段一致性等方面进行校验,保证数据从源库导入平台前后的一致性;数据整合质量校验的工作是对经过整合匹配后的数据进行质量校验,保证匹配数据的准确性,比如通过SQL脚本进行完整性校验。
数据整合往往涉及多个整合流程,所以数据平台一般具有BPM引擎,能够对整合流程进行配置、执行和监控。
3.5.8 数据服务
将数据模型按照应用要求做了服务封装,就构成了数据服务,这个跟业务系统中的服务概念是完全相同的,只是数据封装比一般的功能封装要难一点。随着企业大数据运营的深入,各类大数据应用层出不穷,对于数据服务的需求非常迫切,大数据如果不服务化,就无法规模化,比如某移动运营商封装了客户洞察、位置洞察、营销管理、终端洞察、金融征信等各种服务共计几百个,每月调用量超过亿次,灵活地满足了内外大数据服务的要求。
数据服务往往需要运行在企业服务总线(Enterprise Service Bus, ESB)之上。ESB基于SOA构建,完成数据服务的释放、监控、统计和审计。除了直接访问数据的服务之外,数据服务还可能包括数据处理服务、数据统计和分析服务(比如Top N排行榜)、数据挖掘服务(比如关联规则分析、分类、聚类)和预测服务(比如预测模型和机器学习后的结果数据)。有时,算法服务也属于数据服务的一种类型。
3.5.9 数据开发
有了数据模型和数据服务还是远远不够的,因为再好的现成数据和服务也往往无法满足前端个性化的要求,数据平台的最后一层就是数据开发,其按照开发难度也分为三个层次,最简单的是提供标签库,比如,用户可以基于标签的组装快速形成营销客户群,一般面向业务人员;其次是提供数据开发平台,用户可以基于该平台访问所有的数据并进行可视化开发,一般面向SQL开发人员;最后就是提供应用环境和组件,比如页面组件、可视化组件等,让技术人员可以自主打造个性化数据产品,以上层层递进,满足不同层次人员的要求。
3.5.10 数据平台总结
大数据行业应用持续升温,特别是企业级大数据市场正在进入快速发展时期。越来越多的企业期望实现数据孤岛的打通,整合海量的数据资源,挖掘并沉淀有价值的数据,进而驱动更智能的商业。随着公司数据爆发式增长,原有的数据库无法承担海量数据的处理,那么就开始考虑大数据平台了。大数据平台应该支持大数据常用的Hadoop组件,如HBase、Hive、Flume、Spark,也可以接Greenplum,而Greenplum正好有它的外部表(也就是Greenplum创建一张表,表的特性叫作外部表,读取的内容是Hadoop的Hive中的),这可以和Hadoop融合(当然也可以不用外部表)。通过搭建企业级的大数据平台,打通各系统之间的数据,通过多源异构接入多个业务系统的数据,完成对海量数据的整合。大数据采集平台应支持多样数据源,接口丰富,支持文件和关系型数据库等,支持直接跨库跨源的混合计算。
大数据平台实现数据的分层与水平解耦,沉淀公共的数据能力。这可分为三层:数据模型、数据服务与数据开发,通过数据建模实现跨域数据的整合和知识沉淀,通过数据服务实现对于数据的封装和开放,快速、灵活地满足上层应用的要求,通过数据开发工具满足个性化数据和应用的需要。图3-18是某运营商的数据平台。
图3-18 数据平台实例
数据平台还涉及三方面内容。第一是数据技术。大家都有自己的数据中心、机房、小数据库。但当数据积累到一定体量后,这方面的成本会非常高,而且数据之间的质量和标准不一样,会导致效率不高等问题。因此,我们需要通过数据技术对海量数据进行采集、计算、存储、加工,同时统一标准和口径。第二是数据资产。把数据统一之后,会形成标准数据,再进行存储,形成大数据资产层,进而保证为各业务提供高效服务。第三是数据服务,包括指数,就是数据平台面向上端提供的数据服务。
数据平台应确保大家在使用数据的过程中,口径、标准、时效性、效率都有保障,能有更高的可靠性和稳定性。