【IT168 专稿】本文根据【2016 第七届中国数据库技术大会】现场演讲嘉宾张粤磊老师分享内容整理而成。录音整理及文字编辑IT168@田晓旭@老鱼。

　　嘉宾介绍：

▲飞谷云创始人 张粤磊

　　张粤磊，飞谷云(www.feiguyun.com)创始人，前平安付大数据平台架构师。历经了DBA，到开发工程师，再到大数据平台架构师的转变，有着10余年各行业(制造，咨询服务，互联网金融)一线数据处理及技术实践经验。

　　正文：

　　我最早是做数仓和ETL架构系统，后来开始做大数据架构，现在在自主创业，做了一个技术分享的网站。这个网站主要是结合我自己目前在做的大数据、数据处理、数据分析的项目，以及圈里朋友的经验技巧来给大家做一些技术分享。

　　我从2005年开始接触DBA工作，2010年在HP 的TRAM项目中担任ETL开发组长，2012年，在外汇交易中心ETL项目担任开发经理，2014年，在平安付做大数据架构师。在这些年的工作过程中，接触了很多数据库，也有一些数据处理的经验想和大家来分享。

　　我今天演讲的主要分三个部分，第一部分是分享一下我在传统数据仓库的一些数据处理技术和配置方面的思考;接下来讲一下大数据环境下，公共数据和行为数据的数据处理技术;最后会讲一下从传统数据仓库迁移到大数据数据仓库的数据处理实践思考及建议。

　　传统数据仓库的数据处理技术及思考

　　我从自己实际参与的大型数据仓库项目出发，和大家分享一下传统数据仓库的数据处理技术。这个案例融合了我在外资企业、央企、民企、金融行业等等各个行业的项目实践经验，它是涵盖了整个传统数据仓库的标准流程。坦白讲，现在很多企业没有很标准的数据模型。数据模型是国外最早开始做的，比较经典的是惠普和eBay，他们的数据处理和数据模型的领导力比较强，也比较规范和科学，这两个团队在整体数据模型方面有一套成熟的方法论。数据处理方法同样适用整体的数据平台。

　　做一个数据管理仓库首先要做概念定义，这个一般是针对大型项目，分为企业内部和客户群体两部分，接下来是Portal和对应的权限管理，中间部分是根据实际业务去定义功能，有些功能是比较经典的，还有一些是根据特定业务场景去设计的。再下面一层是我们整体的数据集成层，再底层就是元数据层。

　　概念定义的产出一般是SOW，用来表明数据治理要做的功能单位。在这之下是业务定义，细化业务、系统功能，包括客户部分对应的联系人以及对应的清单，包括报表需要用哪些数据的实现。如果按实际应用来分的话，假设这是一个IT服务系统，下面会分服务管理和性能管理，性能管理又分硬件和软件的管理。

　　业务定义之后会有一个业务清单，业务清单里会有详细的业务要求以及相对应的工作项，这样可以保证数据不会出现遗漏，保证业务落实到位。

　　业务定义之后是逻辑定义，逻辑定义划分的就更细了，涉及具体业务怎么实现、由什么来实现。我们通常的做法是选择一些工具来实现报表的权限管理、元数据管理。ETL我们选择了informatics，数据文件的传输，尤其是跨域网站的数据传输，我们也是选用组件来完成的。再底层的话是业务系统，这个业务系统比较详细，一般都会定义到具体的业务名，清单里面也会有系统、接口这些信息。接下来还要进一步细化，比如业务DB的名称后，要去查看它的网段、所在服务器、端口、防火墙等等信息并需要做连通性验证等。这样就实现了从业务层到物理层面的落地。

　　物理层面落地之后就应该进行数据规则定义。规则定义就是要把数据像整理衣柜一样分层治理好，比较经典的就是三层维度模型。从元数据层到数据仓库层再到管理层，把元数据原封不动的抽到对应的数据仓库层。图中的Level 1层主要是数据仓库的技术层，包括维度表和事实表的加载、各业务系统的维度表和事实表的加载、各业务整体维度表的生成以及基于事实表产生对应的维度指标和度量值。这层同时也是整体数据仓库的核心层或生成层。Level 2层主要是为报表服务做一些聚合，根据不同的业务需要会产生按周、按天、按月等等不同维度的报表去维护。

　　规则定义之后就是具体的设计，这个设计一般就是我们架构组里面的建模组长、ETL组长干的事情，具体的有源系统信息、目标系统信息和ETL抽取。做数据管理首先要做好设计定义，之后你就只需要根据设计文档去做具体的开发实现。图上是我们做的一个设计定义，大家可以参考一下。

　　我在09-14年之间，做了大概6年的Infomatica的开发和管理工作，在ITPub上还有很多笔记，大家要是有兴趣，可以去了解一下。

　　做Infomatica比较成熟的是惠普和eBay的，国内对Infomatica比较熟悉的企业应该就是神州数码了，因为神州数码是第一家代理厂商。Infomatica相对Datastag、SSIS来说，元数据管理平台更完善。我们不仅可以从之前的模型定义去实现主数据管理的一致性，还可以将Infomatica跑出来的数据和元数据抽取出来的信息做及时的校验比对。Infomatica后来也有了自己的元数据管理工具，现在也在接触一些Hadoop工具。

　　数据仓库的治理六大要素：完整性、准确性、规范性、唯一性、一致性、关联性。下面我主要讲解两点，第一个是完整性，传统的RDBMS无论是哪一种都无法涵盖大量的非结构化业务数据。作为一个数据架构师、数据处理师不应该有依赖工具的思想，任何一个工具都不是完美的。

　　第二个是准确性，不同RDBMS对数据类型的定义精确度各有不同，当源系统与目标系统属于不同RDBMS或字符集等情况，可能存在字符类型不兼容问题，如：Oracle 的date数据类型有时分秒，而DB2的date数据类型不含时分秒;oracle的Integer数据类型是8字节38位精度，DB2的Integer数据类型是4字节10位精度。

　　公共数据及行为数据的数据处理技术

　　接下来我们讨论一下公共数据及行为数据的处理技术。一般我们处理的数据分为三类，一种是公共数据，常用的获取数据的工具是基于各种语言的爬虫框架，目前流行的是Python。第二种是埋点数据，通常是接入Talkingdata、友盟平台来获取对应的行为数据，或者是自己开发SDK采集工具。第三种是用户及交易数据，此类数据一般存储在结构化数据库中，获取数据的常用工具是SQOOP工具。

　　数据进入大数据平台的HDFS后，会使用大数据的数据仓库工具HIVE进行数据的ETL和模型构建。这里一般是三层结构：第一层是数据的原始落地层;第二层是数据的集成层，是模型的主要构建层;第三层是数据的分析层，主要用于数据的分析挖掘。

　　数据经过大数据仓库HIVE基础模型化后，会利用Spark工具对Hive的处理逻辑进行计算引擎的提升，一般会提升10倍左右的计算速度，并利用Spark的ML技术进行数据挖掘分析，SparkR进行图形化分析展现。

　　大数据经过挖掘分析处理后的统计数据，或需要自定义分析即席报表所需的基础模型表，一般使用HBase或RDBMS来保证查询显示的快速调用和结果反馈。

　　在处理公共数据的时候应该注意以下几个方面：

　　1.接口定义加入接口规范变更版本及内容到数据库字段中;

　　2.落地后的文件时间和成功标志信息同样参与数据处理;

　　3.在数据仓库处理和分析展示中添加数据处理的可追溯信息;

　　4.埋点数据一定要符合业务数据信息流才能保证数据处理的完整性和确保数据的业务可用性;

　　5.行为数据的标识健(UID，DID)要与其它数据源统一关联健和对应时间周期，确保数据的一致性和关联性;

　　6.行为数据的元数据信息尽可能从源头以字段化方式植入数据处理的数据文件中。

　　我们从公共数据网站抓取一些信息，然后通过SparkR脚本放到Hive模型里，执行hql任务，生成分析图，最后通过调度系统和监控系统来保证系统的完善统一。

　　传统数仓到大数据数仓的数据处理

　　从传统数据仓库到大数据仓库里面应该处理哪些呢?我认为从传统数仓到大数据仓库首要面对的就是数据同步与脱敏。传统数仓是以RDBMS为主要的数据处理存储层，数据库安全级别相对来说比较高。从传统数仓到大数据平台最好的实践方法就是把传统数据仓库与Level 0表全部同步到大数据平台，此时它的数据应该是RDBMS的结构化数据、公共数据和埋点数据全部统一在一起的全样本数据，数据在进入大数据平台后一定要进行脱敏处理，确保数据安全。然后到达以HDFS为主的数据处理层，数据处理的工具要根据数据来源来选择，一般来说，RDBMS采用SQOOP，实时数据采用Kafka、Storm等等。报表层采用自主开发的或者是大数据平台工具。另外，大数据平台一定要注意安全管理。

　　从传统数据仓库到大数据数据仓库的数据处理的建议：首先数据基因定义一定要完整准确，比如文件从别的地方传输过来，首先要验证文件大小有没有改变，如果没有改变就传一个成功标志位，然后把文件大小、产生时间这些信息添加到数据中，最后将数据整体传到数据层。

　　其次，数据血缘设计清晰可溯，有时候我们理解写完设计，从最初的源数据一直到最后报表展现的数据，它们之间的关系一定是很清晰的，确保它是可查可控的。

　　第三，数据安全机制原子化，对数据平台的分层数据做到基于存储机制的原子化安全控制，确保从底层实现数据的安全分层控制。

　　最后，核心指标及元数据做到可视化和监控自动化，它可以实现元数据数据治理的一个良性循环。通过监控报警发现哪些数据不一致，数据校验的比率、倾斜度超过什么样的指标规则，查看元数据业务或者技术元数据产生的信息，可以及时发现并解决问题。

　　飞谷云是我们做的一个大数据的平台，现在主要是做数据处理和分析的项目，里面搭建了OpenStack和Hadoop的多种版本。我们和各大公司有经验的技术人员建立了一个社区，主要在数据治理方面为大家做一些技术分享。