下载掌阅APP，畅读海量书库
立即打开
随着传统互联网、移动互联网、物联网等技术的兴起，企业的业务形态开始多元化，业务主体类型也愈加丰富，不局限于用户，供应商、员工、设备、车辆等对象的状态与行为都会对业务产生影响。通过行为埋点、爬虫、日志、填报的方式来收集各类业务对象行为数据是企业非常重要的方法和手段。从空间维度来看，对象行为可以分为线上行为和线下行为两类。采集这两类行为所产生的数据的方法是不一样的，而且方法也在随着技术的演进不断发展变化。
线上行为的主要载体可以分为传统互联网和移动互联网两种，对应的形态有PC系统、PC网页、H5、微信小程序、App、智能可穿戴设备、物联网传感设备等。在技术上，数据采集主要有客户端埋点和服务端埋点两种方式。其中客户端埋点主要通过在终端设备内嵌入埋点功能模块，通过模块提供的能力采集客户端的用户行为，并上传回行为采集服务端。
常见的客户端埋点方式有3种：全埋点、可视化埋点和代码埋点。
❑ 全埋点 ：将终端设备上用户的所有操作和内容都记录并保存下来，只需要对内嵌SDK做一些初始配置就可以达到收集全部行为的目的。这也经常被称为无痕埋点、无埋点等。
❑ 可视化埋点 ：将终端设备上用户的一部分操作，通过服务端配置的方式有选择性地记录并保存。
❑ 代码埋点 ：根据需求来定制每次的收集内容，需要对相应的终端模块进行升级。
对于这3种埋点方式，企业可以根据实际业务场景来判断和选择。它们的优劣势对比如下。
全埋点适合于终端设计标准化且有统一系统接口的情形。它利用系统提供的事件捕获机制，在对象事件发生时调用埋点工具中的指定处理逻辑，对该事件相关的信息进行记录。这种方法的优点是不用频繁升级，在一次性验证并发布后，就可以获取终端的全量行为数据。当突然发现需要对某个对象进行分析时，可以直接从历史数据中找到所需的数据，而不需要再次进行数据收集。其缺点是数据存储、传输的成本较高，有些当前不用的数据也需要保留。
可视化埋点适合于需要考虑存储和带宽成本的情形，可通过后端配置来降低对象事件行为采集数量，实现机制和全埋点类似。其优点是发布后不需要频繁升级，成本比全埋点低，并且能够灵活配置；缺点是当需要对某一个对象进行分析，但发现其数据没有采集时，需要重新配置并等数据采集完成后再进行后续工作，容易影响业务进度。
代码埋点主要适合于终端设计非标准化、事件行为需要通过代码来控制的情形。其优点是灵活性强，针对复杂场景可以单独设计方案，对存储、带宽等可以做较多的优化；缺点是成本高，维护难度大，升级周期较长。
图4-1所示为某站点的网站行为埋点日志，该埋点日志中记录了数据的类型（logtype）、内容标题（title）、行为的上一级页面（pre）、用户的屏幕分辨率（scr）、用户标识（cna）、用户名（nick）等各类信息。对于这些数据，后端运营人员可以进行挖掘和分析，从而指导产品、运营的优化。例如：根据用户的屏幕分辨率数据，可以在产品布局上进行更好的适配；通过行为的上一级页面，可以知道用户是从哪个页面进入当前页面的，进而优化用户行为路径。
图4-1 埋点日志
除了客户端埋点，常见的线上埋点还有服务端埋点，即通过在系统服务器端部署相应的数据采集模块，将采集到的数据作为行为数据进行处理和分析。服务端埋点常见的形态有HTTP服务器中的access_log，即所有的Web服务的日志数据。前面提到的客户端的3种埋点方式，常见的简化实现方案一般也会配合HTTP服务器中的access_log来落地，但有时为了更好地融合，会定制一些服务端的SDK，用于捕获服务端系统中无法通过常规访问获取的数据信息，如内部处理耗时、包大小等数据。
服务端埋点的优点很明显，当需要获取的用户行为通过服务端请求就可以采集到或者通过服务端内部的处理逻辑能获取时，采用这种方式来收集用户行为数据能够降低客户端的复杂度，避免一些信息安全问题。但其弊端也很明显，有些用户行为不一定会发出访问服务端的请求，这种方式就无法采集这部分数据。因此，服务端埋点一般会和客户端埋点结合使用，相互补充，以完成全部目标用户行为的采集。
线下行为数据主要通过Wi-Fi探针、摄像头、传感器等硬件采集。随着设备的升级，各种场景中对智能设备的应用越来越多，安防、客户监测、考勤等开始深入人们的工作和生活。常见的线下行为采集方式有网络信号采集、图像识别采集及设备日志采集等。
通过Wi-Fi或移动分光信号采集周边移动设备上的用户行为是早年比较常用的用户行为采集方式，但有些不合规的使用涉及个人隐私，且手机操作系统也针对这类现象进行了一定的防采集处理，出于隐私保护、系统防护等原因，现在这种采集方式仅限于公共安全领域使用。拿Wi-Fi信号采集来说，其主要原理是通过信号探测的协议，在热点附近的移动设备探测SSID时建立网络连接，从网络协议中获取手机的网络设备号。
图像主要通过智能摄像头来采集，采集内容后会根据业务需要及存储成本要求进行处理，既可以输出原始或压缩过的视频流，也可以通过设备本身部署的算法模型识别图像的内容，输出结构化数据。例如，目标对象进入相应区域后摄像头可以识别相关信息，然后采集和保存图像并生成唯一标识（如Face ID）、行为特征等描述信息供后续业务使用。
AIoT设备记录了运行期间各类行为事件日志，这些日志数据的结构相对标准，有较强的时间属性，在工业制造、智能安防、执法稽查等领域广泛应用。由于缺少强制性的行业标准要求，当前大部分设备厂商为了构建自己的生态壁垒而使用私有协议进行数据传输。如果要采集和使用AIoT设备中的日志数据，企业通常需要先使用物联网平台或盒子对设备生产的数据进行协议转换，并通过订阅的方式获取基于标准协议传输的数据。
网络爬虫又称为网页蜘蛛，是一种按照既定规则自动抓取互联网信息的程序或脚本，常用于网站的自动化测试和行为模拟。Google、搜狗、百度等搜索引擎都基于它们内部自建的网络爬虫，在遵守相关协议的情况下不断爬取互联网上的新鲜网页信息，对内容进行处理后提供相应的检索服务。
当企业的内部信息不足时，可以考虑利用外部互联网的数据进行一些“化学反应”，将外部的数据与内部数据有效融合，从而让内部数据在应用上有更多价值。网络爬虫有多种实现方式，目前有较多的开源框架，如Apache Nutch 2、WebMagic、Scrapy、PHPCrawl等，利用它们我们可以快速根据自己的实际应用场景构建数据抓取逻辑。当然，需要遵守相应的协议和法规，同时要避免对目标网站带来过大的请求压力。
受限于业务信息化程度较弱或数据保密要求，并不是所有的数据都会被机器记录，但这部分数据对决策分析等用途又至关重要。因此，为了能够将这些数据重新“信息化”，企业会使用数据填报类工具完成这部分数据的采集。
通常，数据收集员会定义收集数据的规范表单，比如填写字段、预设值、填写时间要求、填报人员等，下发给填报人员填写。数据填报与组织结构紧密关联，涉及多级上报时，还需要设定不同级别表单内容之间的联动计算方式，让整个上报过程更简单精确。
数据汇聚不同于数据采集，数据采集有一定的数据生产的性质，其能力是将终端的对象业务过程信息用特定的方法记录后，通过中间系统的流转写入目标存储系统中。而数据汇聚则是通过一定的手段将已存在的数据从一个数据源搬运到另一个数据源的数据同步过程，也常被称为“数据集成”。企业可以根据汇聚数据类型、汇聚数据模式等维度筛选适合自身的数据汇聚工具。
数据可以根据自身的组织形式划分为3类。
❑ 结构化数据 ：规则、完整、能够通过二维逻辑表现的数据，严格遵循数据格式与长度规范，常见的有数据库表、Excel工作表等二维表。
❑ 半结构化数据 ：数据规则、完整，同样严格遵循数据格式与长度规范，但无法通过二维逻辑来表现，常见的有用JSON、XML等形式表达的复杂结构。
❑ 非结构化数据 ：数据结构不规则或不完整，不方便用二维逻辑来表现，需要经过复杂的逻辑处理才能提取其中的信息内容，如办公文档、图片、图像和音视频等。
应用哪种模式进行数据汇聚，主要依据业务应用的需要。汇聚数据模式主要分为以下两种。
❑ 离线 ：主要用于大批量数据的周期性迁移。这种模式对时效性的要求不高，一般采用分布式批量数据同步的方式通过连接读取数据。读取数据有全量、增量两种方式，将数据经过统一处理后写入目标存储系统。
❑ 实时 ：主要面向低时延的数据应用场景，一般通过增量日志或通知消息的方式实现，如通过读取数据库的操作日志（redo log、binlog）来实现相应的实时数据处理。业界常见的Flink CDC、Canal、MaxWell、StreamSets、NiFi等框架和组件都有较多的实际应用。
基于不同数据汇聚需求、硬件成本及网络带宽要求，可以选择不同的汇聚数据方法。
❑ ETL ：Extract-Transform-Load的缩写，指抽取—转换—存储这一过程，即在数据抽取过程中进行数据的加工转换，然后加载至存储系统中。ETL模式在清洗过程中只抽取有价值的信息进行存储，而是否有价值是基于当前对数据的认知来判断的。由于数据价值会随着我们对数据的认知以及数据智能相关技术的发展而不断被挖掘，因此ETL模式很容易出现一些有价值的数据被清洗掉，导致当某一天需要用这些数据时又需要重新处理，甚至数据丢失无法找回。相比存储的成本，重新处理数据或者数据丢失的代价可能会更大。
❑ ELT ：与ETL的缩写内容一致，只是顺序变为抽取—存储—转换。这种方法更适合大规模数据场景，它将数据抽取后直接加载到存储系统中，再通过大数据和人工智能相关技术对数据进行清洗与处理。在数据存储成本越来越低廉、数据量越来越庞大的今天，ELT是更好的选择。
在数据能力建设过程中，很多企业结合自身的场景和最佳实践开源了一些优秀的汇聚工具，如Flink CDC、Canal、Sqoop、DataX等，这些工具的适用场景不同，也各有优缺点。
Flink CDC于2020年发布，使用CDC（变化数据捕捉）技术，通过源数据库日志更新的订阅及消费捕获源数据库数据的变化，并将数据同步到目的数据库，而且在同步过程中可以对数据进行一定的处理。
受惠于丰富的生态以及良好的场景兼容性，Flink CDC已经成为主流数据同步工具。由于对有界数据流和无界数据流都有完善的兼容性，因此它可以同时应用在离线、实时以及混合的数据同步场景中，令从业人员的学习成本、部署维护成本大幅降低。
Flink CDC的机制决定了它无法支持非结构化数据的同步，因此使用数据湖技术的企业还需选择非结构化数据同步工具。
Canal Server模拟MySQL Slave的交互协议，将自己伪装为MySQL Slave向Master发送dump协议，Master收到请求后开始推送binlog，Canal解析字节流产出解析后的增量数据。
Canal的主要优点是流程架构非常清晰，部署和配置等相对简单，同时可以额外做一些配置管理、开发改造的工作。它的主要缺点是Server中的Instance和Client之间是一对一消费的，不太适用于多消费和数据分发的场景。
Sqoop是目前市面上相对通用的一种解决方案，是在结构化数据和HDFS之间进行批量数据迁移的工具。其整体框架以Hadoop为核心，底层使用MapReduce程序实现，MapReduce天生的特性保证了并行化和高容错率，任务运行在Hadoop集群上，减少了服务器资源的使用情况。
其主要优势是，在特定场景下，数据交换过程会有很大的性能提升。主要缺点是，处理过程定制程度较高，目前主要通过在命令行中配置参数来调整数据同步操作行为，在用户的一些自定义逻辑和数据同步链路监控方面比较薄弱。除此之外，任务运行完全依赖于MapReduce，功能扩展性方面受到比较明显的约束和限制。
DataX是阿里巴巴开源的一套插件式离线数据同步工具，以实现各种异构数据源之间的高效数据同步为目标而设计，提供数据同步作业全链路的流量监控，将作业本身的状态、数据流量、数据速度、执行进度等信息进行展示，提供脏数据探测功能，支持在传输过程中对传输报错（如类型转换错误）进行策略化处理。由于它是基于进程内读写直连的方式，因此在高并发数据同步场景下它对机器内存要求比较高。
与Flink CDC相同，DataX也不支持非结构化数据本身的同步，但它目前支持非结构化数据源。使用非结构化数据源时，在同步路径中需要存储一张逻辑意义上的二维表（如CSV格式的文本信息）供DataX读取，其本质还是将表格内的结构化数据同步到目的端。
在数字化转型过程中，企业会因为自身数据不足无法快速开展业务，而希望从企业外部获取数据或数据能力以增强企业数据的完整性和丰富度，此时就出现了数据在组织之间的供需关系。通常使用数据交换来满足数据供需两端的各类场景诉求。
对于数据需求方，数据交换可以算作一种数据共享与获取的方法，需求方只需要与供给方约定好数据格式、传输协议、计算方式、结算逻辑、交换时间等就可以获取到数据，对于数据源存储的位置、形态、结构都不需要关注，这也是它在数据传输时与数据汇聚最大的区别。
根据业务需求与数据安全要求的不同，数据交换的场景五花八门。例如集团与子公司之间数据的定时报送，通常采用未加密数据的交换传输，更多在传输协议层面进行加密，因为在内网环境交换，数据泄露风险较低；再如企业的业务需求是让预测模型更准确，那么不需要直接获取真实数据，只要通过联邦学习的方式与数据供应方联合计算获取模型即可，虽然没有获取数据，但达到了获取数据的目的。
数据交换是数据中台的能力补充，通过数据交换，数据中台的数据以及数据能力能够逐步提升，也能够基于数据交换构建新的业态（数据交易）。当企业与企业之间的数据中台通过数据交换连接时，就实现了更广泛意义上的数据中台。
在本书中，我们将重点放在企业内部的数据中台建设及实践经验，所以下面以数据汇聚为重点进行讲解。