数据中台第5章数据汇聚联通：打破企业数据孤岛

要构建企业级的数据中台，第一步就是要让企业内部各个业务系统的数据实现互联互通，从物理上打破数据孤岛，这主要通过数据汇聚和交换的能力来实现。在面向具体场景时，可以根据数据类型将汇聚对象分为结构化和非结构化、大文件和小文件、离线与在线等几种，不同类型的数据对存储的要求不同。同时，与业务数据化的方式也有关系，有些场景需要通过线上或线下的方式来实现数据的汇聚。

在数据采集和汇聚过程中，需要特别注意的一点是数据的隐私和安全，数据采集和汇聚是最容易触碰法律红线的环节，因此在制订相应的方案时，一定要考虑当地安全法规的要求，避免侵犯用户的个人隐私，导致用户信息安全受损。

5.1　数据采集、汇聚的方法和工具

随着互联网、移动互联网、物联网等技术的兴起，企业的业务形态开始多元化，通过行为埋点、爬虫的方式来收集过程数据是企业非常重要的方法和手段。从空间维度来看，用户行为可以分为线上行为和线下行为两类，采集这两类行为所产生的数据所使用的方法是不一样的，而且方法也在随着技术的演进不断发展和变化。

1.线上行为采集

线上行为的主要载体可以分为传统互联网和移动互联网两种，对应的形态有PC系统、PC网页、H5、小程序、App、智能可穿戴设备等。在技术上，数据采集主要有客户端SDK埋点和服务端SDK埋点等方式。其中客户端SDK埋点主要是通过在终端设备内嵌入埋点功能模块，通过模块提供的能力采集客户端的用户行为，并上传回行为采集服务端。

（1）客户端埋点

常见的客户端埋点方式有三种：全埋点、可视化埋点和代码埋点。这三种方式的应用场景企业可根据自身需求进行选择。

·全埋点：将终端设备上用户的所有操作和内容都记录并保存下来，只需要对内嵌SDK做一些初始配置就可以实现收集全部行为的目的。这也经常被称为无痕埋点、无埋点等。
·可视化埋点：将终端设备上用户的一部分操作，通过服务端配置的方式有选择性地记录并保存。
·代码埋点：根据需求来定制每次的收集内容，需要对相应的终端模块进行升级。

针对这三种埋点方式，企业可以根据实际业务场景来判断和选择。它们的优劣势对比如下：

全埋点适合于终端设计标准化且有统一系统接口的情形，用户在终端上的操作，通过系统提供的事件捕获机制，在对象事件发生时调用埋点工具中的指定处理逻辑，对该事件相关的信息进行记录。这种方法的优点是不用频繁升级，一次性验证并发布后，就可以获取终端的全量行为数据。当突然发现需要对某个对象做分析时，可以直接从历史数据中找到所需的数据，不需要再次进行数据收集。缺点是数据存储、传输的成本会高一些，有些当前不用的数据也需要保留。

可视化埋点适合于需要考虑存储和带宽成本的情形，可通过后端配置来降低对象事件行为采集数量，实现机制和全埋点类似。其优点是发布后不需要频繁升级，成本比全埋点低，并且能够灵活配置；缺点是当需要对某一个对象进行分析，但发现其数据没有被采集时，需要重新配置并等数据采集完成再进行后续工作，容易影响业务进度。

代码埋点主要适合于终端设计非标准化、事件行为需要通过代码来控制的情形。其优点是灵活性强，针对复杂场景可以单独设计方案，对存储、带宽等可以做较多的优化；缺点是成本高，维护难度大，升级周期较长。
图5-1所示为某站点的网站行为埋点日志，该埋点日志中记录了数据的类型（logtype）、内容标题（title）、行为的上一级页面（pre）、用户的屏幕分辨率（scr）、用户标识（cna）、用户名（nick）等各类信息。在收集到这些数据后，后端运营就可以据此进行挖掘和分析，从而

（2）服务端埋点

除了前面介绍的客户端埋点，常见的线上埋点还有服务端埋点，通过在系统服务器端部署相应的数据采集模块，将这部分数据作为行为数据进行处理和分析。服务端埋点常见的形态有HTTP服务器中的access_log，即所有的Web服务的日志数据。前面提到的客户端的三种埋点方式，常见的简化实现方案一般也会配合HTTP服务器中的access_log来落地，但有时为了更好地融合，会定制一些服务端的SDK，用于捕获服务端系统中无法通过常规访问获取的数据信息，如内部处理耗时、包大小等数据。

服务端埋点的优点很明显，如果需要获取的用户行为通过服务端请求就可以采集到或者通过服务端内部的一些处理逻辑也能获取时，为了降低客户端的复杂度、避免一些信息安全的问题，常常会采用这种方式来收集用户行为数据。但其弊端也很明显，有些用户的行为不一定会发出访问服务端的请求，这种方式就无法采集这部分数据。因此，服务端埋点

2.线下行为采集

线下行为数据主要通过一些硬件来采集，如常见的Wi-Fi探针、摄像头、传感器等。随着设备的升级，各种场景中对智能设备的应用也越来越多，安防、客户监测、考勤等都开始深入到生活中。常见的主要有Wi-Fi信号采集、信令数据采集、图像视频采集以及传感器探测等。通过Wi-Fi信号采集周边移动设备是之前比较常用的方式，但由于有些不合规的使用涉及个人隐私，手机操作系统也针对这类现象做了一定的防采集处理，出于隐私保护、系统防护等原因，现在这种采集方式已经不怎么被使用。其主要原理是通过信号探测的协议，当热点附近的移动设备在探测SSID时，会建立网络连接，从网络协议中获取手机的网络设备号。

图像视频主要通过智能摄像头来采集，目标对象进入相应区域后摄像头可以识别相关信息，然后采集和保存图像并生成唯一标识，如Face ID用于信息的组织。

3.互联网数据采集

网络爬虫又称为网页蜘蛛，是一种按照既定规则自动抓取互联网信息的程序或者脚本，常用来做网站的自动化测试和行为模拟。Google、搜狗、百度等提供的互联网信息检索能力，都是基于它们内部自建的网络爬虫，在遵守相关协议的情况下，不断爬取互联网上的新鲜网页信息，对内容进行处理后提供相应的检索服务。

当企业的内部信息不足时，可以考虑利用外部互联网的数据进行一些“化学反应”，将外部的数据与内部数据有效融合，从而让内部数据在应用上有更多价值。网络爬虫有多种实现方式，目前有较多的开源框架可以使用，如Apache Nutch 2、WebMagic、Scrapy、PHPCrawl等，可以快速根据自己的实际应用场景去构建数据抓取逻辑。当然，需要遵守相应的协议和法规，同时避免对目标网站造成过大的请求压力。

4.内部数据汇聚

数据汇聚不同于数据采集，数据采集有一定的数据生产属性，将终端的用户行为信息通过特定的方法记录后，通过中间系统的流转写入目标存储中。当然，也能通过某种形式在某个数据源中落地，如数据库或日志文件等，然后通过数据汇聚的能力实现数据采集和存储。

从数据组织形式来分，数据主要分成三类：

·结构化数据：规则、完整，能够通过二维逻辑来表现的数据，严格遵循数据格式与长度规范，常见的有数据库表、Excel等二维表。
·半结构化数据：数据规则、完整，同样严格遵循数据格式与长度规范，但无法通过二维关系来表现，常见如JSON、XML等形式表达的复杂结构。
·非结构化数据：数据结构不规则或不完整，不方便用二维逻辑表来表现，需要经过复杂的逻辑处理才能提取其中的信息内容，如办公文档、图片、图像和音视频等。

从时效性和应用场景来分，数据汇聚可以分成离线和实时两类：

·离线：主要用于大批量数据的周期性迁移，对时效性要求不高，一般采用分布式批量数据同步的方式，通过连接读取数据，读取数据过程中可以有全量、增量的方式，经过统一处理后写入到目标存储。
·实时：主要面向低时延的数据应用场景，一般通过增量日志或通知消息的方式实现，如通过读取数据库的操作日志（RedoLog、BinLog）来实现相应的实时处理，业界常见的Canal、MaxWell、StreamSets、NiFi等框架和组件都有较多的实际应用。

在数据能力建设过程中，很多企业结合自身的场景和最佳实践也开源了一些优秀的汇聚工具，如Sqoop、DataX、Canal等，适用场景不同，也各有优缺点。

（1）Canal

Canal Server模拟MySQL Slave的交互协议，伪装自己为MySQL的Slave向Master发送dump协议，Master收到请求后开始推送binary log，Canal解析byte流产出解析后的增量数据。主要优点是流程架构非常清晰，部署和配置等相对简单，同时可以额外做一些配置管理、开发改造的工作。Canal的主要缺点是Server中的Instance和Client之间是一对一的消费，不太适用于多消费和数据分发的场景。

（2）Sqoop

Sqoop是目前市面上相对通用的一种解决方案，是在结构化数据和HDFS之间进行批量数据迁移的工具。整体框架以Hadoop为核心，底层使用MapReduce程序实现，MapReduce天生的特性保证了并行化和高容错率，任务运行在Hadoop集群上，减少了服务器资源的使用情况。其主要优势是，在特定场景下，数据交换过程会有很大的性能提升。主要缺点是，处理过程定制程度较高，目前主要通过在命令行中配置参数来调整数据同步操作行为，在用户的一些自定义逻辑和数据同步链路监控方面比较薄弱。除此之外，任务运行完全依赖于MapReduce，功能扩展性方面受到比较明显的约束和限制。

（3）DataX

DataX是阿里巴巴开源的一套插件式离线数据交换工具，以实现各种异构数据源之间的高效数据交换为目标而设计，提供数据交换作业全链路的流量监控，将作业本身的状态、数据流量、数据速度、执行进度等信息进行展示，提供脏数据探测功能，支持传输过程中对传输报错（如类型转换错误）进行策略化处理。由于它是基于进程内读写直连的方式，高并发数据交换场景下对机器内存要求比较高。除此之外，DataX不支持非结构化数据的同步，目前支持结构化数据源、半结构化数据源、非结构化数据源，但是非结构化数据源中需要存储的是一张逻辑意义上的二维表，例如CSV格式的文本信息，本质上还是结构化数据。

数据源

针对这些场景，涉及的数据源会有很多种，大致可以分成：

·关系型数据库：如Oracle、MySQL、SQL Server、Greenplum等。
·NoSQL存储：如HBase、Redis、Elasticsearch、Cassandra、MongoDB、Neo4J等。
·网络及MQ：如Kafka、HTTP等。
·文件系统：如HDFS、FTP、OSS、CSV、TXT、Excel等。
·大数据相关：如Hive、Impala、Kudu、MaxCompute、ADB、LibrA、ELK等

5.3 数据存储的选择

OLTP与OLAP的关系