大数据之路：阿里巴巴大数据实践——日志采集与数据同步

第1章 综述

数据采集层

• Aplus.JS：Web端日志采集技术方案。
• UserTrack： APP端日志采集技术方案。
• TimeTunnel：DB增量数据传输及日志数据传输，支持流式计算和基于时间窗口的批量计算。
• DataX：阿里数据同步工具，直连异构数据库来抽取各种时间窗口的数据。

数据计算层

• MaxCompute：离线大数据存储及计算平台。
• StreamCompute：实时大数据存储及流式计算平台。
• OneData：数据整合及管理（如指标体系和数据服务）的方法体系和工具，包含OneID、OneMetric和OneService。
• 离线数仓：数据计算主要以天为单位（包含小时、周、月），每日凌晨处理T-1的数据。
• 实时数仓：实时计算更新数据，如实时数据大屏。
• 数仓分层
  • 操作数据层（ Operational Data Store, ODS）
  • 明细数据层（ Data Warehouse Detail , DWD ）
  • 汇总数据层（ Data Warehouse Summary, DWS ）
  • 应用数据层（ Application Data Store, ADS ）
• 元数据管理：数据源元数据、数据仓库元数据 、数据链路元数据、工具类类元数据、数据质量类元数据。
• 元数据应用：主要面向数据发现、数据管理等 ，如用于存储、计算和成本管理等。

数据服务层

• OneService：统一数据服务平台，以数据仓库整合计算好的数据作为数据源，对外通过接口的方式提供数据服务。
• 功能：提供简单数据查询服务、复杂数据查询服务和实时数据推送服务。

第2章 日志采集

浏览器的页面日志采集

• 基础指标：页面浏览量（ Page View, PV）和访客数（ Unique Visitors, UV ）。
• 页面浏览日志采集流程
  • 客户端日志采集：由植入HTML页面的JS脚本来执行，采集脚本被浏览器加载解析后执行。
  • 客户端日志发送：采集脚本执行时，会向日志服务器发起一个日志请求，以将采集到的数据发送到日志服务器。
  • 服务端日志收集：服务器接受客户端日志请求后，放入日志缓冲区。
  • 服务端日志解析：日志处理程序会对日志缓冲区顺序读取并进行处理解析。
• 页面交互日志采集
  • 步骤一：业务方在日志服务的元数据管理界面依次注册需要采集交互日志的业务、业务场景和具体的交互采集点。
  • 步骤二：业务方将交互日志采集代码植入目标页面，并将采集代码与需要检测的用户行为相绑定。
  • 步骤三：当用户在页面上产生指定行为时，采集代码和正常的业务互动响应代码一起被触发和执行。
  • 步骤四：采集请求到服务端后，不做解析处理，只做简单的转储。
• 页面日志的服务端清洗和预处理：识别流量攻击、网络爬虫和流量作弊、数据缺项补正、无效数据剔除、日志隔离分发。

APP端的日志采集

• UserTrack：利用采集SDK来进行APP端的日志采集。
• 事件类型：页面事件（页面浏览）和控件点击事件（页面交互）等。
• 页面事件
  • 日志记录：①设备及用户的基本信息；②被访问页面的信息及业务参数 ; ③访问基本路径（如页面来源、 来源的来源 ）。
  • 手动埋点：UserTrack提供三个接口（展现、退出、扩展），分别在页面展现、页面退出时调用记录用户操作信息。
  • SPM（Super Position Model）：越级位置模型，可以进行来源去向追踪，通过透传机制还原用户行为路径。
• 控件点击：①设备信息；②用户信息；③控件所在页面；④控件名称；⑤控件业务参数。
• 其他事件：①事件名称；②事件时长；③事件所携带的属性；④事件对应的页面。
• H5&Native日志统一
  • 步骤一：H5页面手动植入日志采集的JS脚本。
  • 步骤二：JS脚本执行时将所采集的数据打包到一个对象，利用WebView的JSBridge进行通信存储到客户端。
  • 步骤三：移动客户端日志采集 SDK ，封装提供接口，实现将传入的内容转换成移动客户端日志格式。
• 日志传输：APP端产生日志后先存储在本地，然后伺机上传到服务器，服务端对不同等级的日志需要进行分流。

日志采集的挑战

• 日志分流及定制处理：日志解析和处理过程中必须考虑业务分流、日志优先级控制，以及根据业务特点实现定制处理。
• 采集与计算一体化设计
  • 背景：超大规模日志进行URL分流，使用正则匹配计算时会拖垮整个硬件计算集群。
  • 方案：通过 SPM 的注册和简单部署即可将任意的页面流量进行聚类得到聚合数据，避免服务端计算。

第3章 数据同步

数据同步基础

• 直连同步：通过定义好的规范接口API和基于动态链接库的方式直接连接业务数据库，如ODBC/JDBC。
  • 痛点：执行大量数据同步时会降低甚至拖垮业务系统的性能。
• 数据文件同步：直接从源系统生成数据的文本文件，由文件服务器传输到目标系统后，加载到目标数据库系统中（如日志同步）。
• 数据库日志解析同步：以通过源系统的进程，读取归档日志文件用以收集变化的数据信息，将其解析到目标数据文件中。
  • 痛点：大量数据同步导致数据延迟、数据漂移和遗漏。

阿里数据仓库的同步方式

• 批量数据同步：多源数据 ➡️ 数据仓库；数据仓库 ➡️ 业务系统。
  • DataX：能满足多方向高自由度的异构数据交换服务产品。
  • Framework + Plugin： Framework处理缓冲、流程控制、并发、上下文加载。
  • Job：数据同步作业。
  • Splitter：作业切分模块，将1个大任务分解成多个可以并发行的小任务。
  • Task：数据同步作业切分后的小任务。
  • Reader：数据读入模块，负责运行切分后的小任务，将数据从源系统装载到 DataX。
  • Channel： Reader 和 Writer 通过 Channel 交换数据。
  • Writer：数据写出模块，负责将数据从 DataX 导入目标数据系统。
• 实时数据同步：日志需要快速以数据流的方式不间断地同步到数据仓库。
  • TimeTunnel：是一种基于生产者、消费者和 Topic 消息标识的消息中间件，将消息数据持久化到 HBase 的数据交互系统。
  • 生产者：消息数据的产生端，向 TimeTunnel 集群发送消息数据。
  • 消费者：消息数据的接收端，从 TimeTunnel 集群中获取数据进行业务处理。
  • Topic：消息类型的标识。
  • Broker： 负责处理客户端收发消息数据的请求，然后往 HBase 取发数据。

数据同步遇到的问题与解决方案

• 分库分表处理：通过建立中间状态的逻辑表来整合统一分库分表的访问，如TDDL数据访问引擎。

• TDDL：实现了 SQL 解析、规则计算、表名替换、选择执行单元并合并结果集的功能。

• 高效同步和批量同步

  • 痛点：大量重复的数据任务操作、数据源种类太多需要特殊配置。
  • OneClick：对不同数据源同步配置透明化，自动生成配置信息；简化步骤，建表、配置任务、发布、测试操作一键化处理。
  • IDB：集数据管理、结构管理、诊断优化、实时监控和系统监控于一体的数据管理服务。

• 增量与全量同步的合并

  • 增量同步：每次只同步新变更的增量数据到目标系统。
  • 全量同步：每次同步数据源数据表的所有数据到目标系统。
  • 合并技术：全外连接（full outer join） + 数据全量覆盖重新加载（insert overwrite）（全量更新比update性能高很多）。
  • 分区技术：每日调度最新的数据到新的分区，和原来所有分区的数据组成全量数据

• 同步性能处理

  • 痛点：部分同步任务分发到CPU比较繁忙的机器会拖垮数据同步性能；数据同步任务无优先级，导致重要同步任务得不到调度。
  • 计算量级：估算该同步任务需要同步的数据量、平均同步速度、首轮运行期望的线程数、需要同步的总线程数。
  • 数据分发：根据同步的总线程数将待同步的数据拆分成相等数量的数据块，一个线程处理个数据块。
  • 同步控制：同步控制器判断待同步的总线程数是否大于首轮运行期望的线程数，大于则跳转至多机处理；否则跳转至单机处理。
  • 多机处理：准备该任务第一轮线程的调度，优先发送等待时间最长、优先级最高且同步任务的线程。
  • 单机处理：优先发送等待时间最长、优先级最高且单机 CPU 剩余资源可以支持首轮所有线程数且同任务的线程，如果没有满足条件的机器，则选择 CPU 剩余资源最多的机器进行首轮发送。

• 数据漂移处理：通常是指 ODS 表的同一个业务日期数据中包含前一天或后凌晨附近的数据或者丢失当天的变更数据。

  • 时间戳字段：modified_time数据表更新时间；log_time 数据日志更新时间；proc_time数据表业务发生时间；extract_time数据抽取时间。
  • 漂移场景：数据抽取时间extract_time有延迟；业务系统未更新modified_time；系统压力导致log_time、modified_time延迟。
  • 处理方法：多获取后一天的数据，业务根据延迟时间确定；通过多个时间戳字段获得相对精确的值。