大数据阶段

阿里巴巴大数据

• 数据采集层
  （1）数据库同步（DataX/同步中心）
  （2）消息中间件（离线、实时）
• 数据计算层
• 数据服务层
• 数据应用层

一. 日志收集

二、数据同步

1.同步基础

（1）直连同步

image.png

• 直连同步是指通过定义好的规范接口APi（ODBC/JDBC等），直接连接数据库。
• 优点：配置简单，实现容易，适合操作型业务系统的数据同步。
• 缺点：对原系统性能影响大，大批量数据同步会降低甚至拖垮业务系统性能，业务库使用主备策略，从备库抽取数据可避免性能影响。但数据量交大，采用抽取方式性能较差，不太适合从业务系统到数仓系统的同步。

（2）数据文件同步

image.png

• 数据文件同步：通过约定好的文件编码、大小、格式等，直接从原系统生成数据的文本文件，从专门的文件服务器（如ftp）加载到目标数据库系统中。
• 适用场景：数据源包括多个异构的数据库系统，互联网的日之类数据通常以文本文件形式存在，这些都适合数据文件同步方式。
• 缺陷：文件上传下载可能会导致丢包活错误，一般会添加校验文件（记录文件数据量以及文件大小等），以供下游目标系统验证数据同步的准确性。
  可以增加压缩和加密操作，提高文件传输效率和安全性。

（3）数据库日志解析同步

image.png

• 目前主流数据库实现了使用日志文件进行系统恢复，通过解析日志文件获取变更数据，从而实现增量数据同步需求。

• 数据库日志解析同步方式实现了实时与准实时同步的能力，延迟
  以控制在毫秒级别，并且对业务系统的性能影响也比较小，目前广泛应
  用于从业务系统到数据仓库系统的增量数据同步应用之中。

• 缺点：
  (1)数据延迟：处理高峰可能数据延迟
  (2)投入较大：需要日志实时抽取任务
  ***(3)数据漂移和遗漏：数据漂移， 般是对增量表而言的，通常是指
  该表的同一个业务日期数据中包含前一天或后一天凌晨 附近的
  数据或者丢失当天的变更数据。

2. 阿里数据仓库的同步万式

特点：a. 数据源种类多 b. 数据量大

（1）批量数据同步：
DataX：支持异构数据或文件系统之间高速数据交换。

image.png

（2）实时数据同步
TimeTunnel:

image.png

Time Tunnel 支持主动、被动等多种数据订阅机制，订阅端自动负载均衡，消费者自己把握消费策略。对于读写比例很高的 Topic ，能够做到读写分离，使消费不影响发送。同时支持订阅历史数据，可以随意设置订阅位置，方便用户回补数据。

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

（1）分库分表的处理

• 背景：业务增长，数据量飞速增加，需要剧本灵活的系统扩展能力和高并发处理能力。主流数据库提供了分布式分库分表方案来解决这个问题。
• 缺陷： 分库分表设计增加了数据同步的复杂度。
  如果有一个中间表，具备将分布在不同数据库中的不同表集成为 个表的能力，就能让下游应用像访问单库单表一样方便。
• 阿里巴巴的 TDDL ( Taobao Distributed Data ayer ）就是这样一个
  分布式数据库的访问引擎，通过建立中间状态的逻辑表来整合统一分库
  分表的访问。
  TDDL 是在持久层框架之下、 JDBC 驱动之上的中间件，它与 JDBC
  规范保持一致，有效解决了分库分表的规则引擎问题，实现了 SQL
  析、规则计算、表名替换、选择执行单元并合并结果集的功能，同时解
  决了数据库表的读写分离、高性能主备切换的问题，实现了数据库配置
  信息的统一管理。

image.png image.png

（2）高效同步和批量同步
（3）增量与全量同步的合并

• 合并技术大多采用 merge 方式( update+insert ）：当前流行的大数据平台基本都不支持 update 操作 ，现在我们比较推荐的方式是全外连接（ full outer join) ＋数据全量覆盖重新加载（ insert overwrite ），即如日调度，则将当天的增量数据和前一天的全量数据做全外连接，重新加载最新的全量数据。
  在大数据量规模下，全量更新的性能比 update 要高得多。此外，如果担心数据更新错误问题，可以采用分区方式，每天保持一个最新的全量版本，保留较短
  的时间周期（如3~7 天）

  
  image.png

（4）同步性能的处理

（5）数据漂移的处理

• 背景：ods 层的数据需要根据按时间切分，通常根据数据中的时间戳来切分，单实际由于时间戳字段准确性而导致数据发生漂移。

常用数据字段：
modified time：数据库表中标识数据记录更新时间的时间戳字段
log_time：数据库日志中用来标识数据记录更新时间的时间戳字段
proc_time：记录具体业务过程发生时间的时间戳字段
extract time：标识数据记录被抽取到时间的时间戳字段

• 数据漂移原因：
  a. 由于数据抽取是需要时间的， extract_ti me 往往会晚于前三个时
  间。
  b. 前台业务系统手工订正数据时未更新 modified_time
  c. 由于网络或者系统压力问题， log_time 或者 modified_time 会晚
  proc time

• 通常做法: proc_time< modified_time< log_time< extract_time

• 根据 extract_time 来获取数据。这种情况数据漂移的问题最明显

• 根据 modified_time 限制。在实际生产中这种情况最常见，但是往往会发生不更新 modified time 而导致的数据遗漏，或者凌晨时间产生的数据记录漂移到后 天。

• 根据 log_time 限制。由于网络或者系统压力问题， log time 会晚proc_time ，从而导致凌晨时间产生的数据记录漂移到后一天。例如，在淘宝“双 l l ”大促期间凌晨时间产生的数据量非常大，用户支付需要调用多个接口，从而导致 log time 晚于实际的支付时间。

• 根据 proc_time 限制。仅仅根据 proc_time 限制，我们所获取的ODS 表只是包含一个业务过程所产生的记 ，会遗漏很多其他过程的变化记录，这违背了 ODS 和业务系统保持 致的设计原则

处理方法主要有以下两种：
( l ）多获取后一天的数据

• 向后多取一天，保障数据只多不少。具体数据切分下游根据不同业务场景使用pro_time限制，会有数据误差。例如 个订单是当天支付的，但是第天凌晨申请退款关闭了该订单，那么这条记录的订单状态会被更新，下游在统计支付订单状态时会出现错误。

(2 ）通过多个时间戳字段限制时间来获取相对准确的数据
首先根据 log_time 分别冗余前一天最后 15 分钟的数据和后一天凌晨开始 15 分钟的数据，并用 modified time 过滤非当天数据，确保数据不会因为系统问题而遗漏。然后根据 log_time 获取后一天 15 分钟的数据 针对此数据，按照主键根据 log_time 做升序排列去重。因为我们需要获取的是最接近当天记录变化的数据（数据库日志将保留所有变化的数据，但是落地到 DS 表的是根据主键去重获取最后状态变化的数据）。最后将前两步的结果数据做全外连接，通过限制业务时间proc_time 来获取我们所需要的数据。

TODO 没懂

三、离线数据开发

了解需求→模型设计→ETL 开发→测试→发布上线→日常运维→任务下线。

image.png
image.png

SQLSCAN 主要有如下三类规则校验：
代码规范类规则，如表命名规范、生命周期设置、表注释等。
代码质量类规则，如调度参数使用检查、分母为 提醒、 NULL
值参与计算影响结果提醒、插入字段顺序错误等。
代码性能类规则，如分区裁剪失效、扫描大表提醒、重复计算检
测等。

image.png
image.png
image.png
image.png

四、实时数据开发

常见问题：

1. 去重指标：

（1）精确去重：需要记录之前的所有明细
（2）模糊去重：

• 布隆过滤器
• 基数统计：是利用哈希的原理，按照数据的分散程度来估算现有数集
  的边界，从而得出大概的去重值总和

2.数据倾斜

( 1 ）去重指标分桶
通过对去重值进行分桶 Hash ，相同 值一定会被放在同一个桶去重，最后再把每个桶里面的值进行加和就得到总值，这里利用了每个桶的 CPU 和内存资源。
(2 ）非去重指标分桶
数据随机分发到每个桶中，最后再把每个桶的值汇总，主要利用的是各个桶的能力。

3.事务处理

的几个流计算系统几乎都提供了数据自动 ACK 、失败重发以及事务信息等机制。

• 超时时间 :由于数据处理是按照批次来进行的，当 批数据处理超时时，会从拓扑的 端重发数据。另外，批次处理的数据量不宜过大，应该增加一个限流的功能（限定一批数据的记录数或者容量等），避免数据处理超时。
• 事务信息:每批数据都会附带 个事务 ID 的信息，在重发的情况下，让开发者自己根据事务信息去判断数据第一次到达和重发时不同的处理逻辑。
• 备份机制: 开发人员需要保证内存数据可以通过外部存储恢复，因此在计算中用到的中间结果数据需要备份到外部存储中。

为了保证数据的幕等性。

4.数据存储

（1）表名设计
设计规则：汇总层标识＋数据域＋主维度＋时间维度
（2）rowkey 设计
设计规则： MD5 ＋主维度＋维度标识＋子维度1 ＋时间维度＋子维度2

5.数据服务

实时数据落地到存储系统中后，使用方就可以通过统一的数据服务
获取到实时数据。

6.流式数据模型

五层（ DS DWD DWS ADS DIM ）
下面通过简单的例子来说明每一层存储的数据。

• ODS层（原始数据层）：订单粒度的变更过程， 一笔订单有多条记录。
• DWD层（事实明细层）：订单粒度的支付记录，一笔订单只有一条记录。
• DWS层（通用汇总层）： 卖家的实时成交金额，一个卖家只有一条记录，并且
  指标在实时刷新。
• ADS层（个性化汇总层）：外卖地区的实时成交金额，只有外卖业务使用。

• DIM 层（维度表）：订单商品类目和行业的对应关系维表。

  
  image.png

7.多流关联

image.png

左右表都要缓存。
双流关联流程，在实际处理时，考虑到查找数据的性能，实时关联这个步骤一般会把数据按照关联主键进行分桶处理，并且在故障恢复时也根据分桶来进行，以降低查找数据量和提高吞吐量。

8.维表使用

在实时计算中，关联维表一般
会使用当前的实时数据（ T）去关联 T-2 的维表数据，相当于在 的数
据到达之前需要把维表数据准备好，并且一般是 份静态的数据。

采用维表关联的原因：

1 数据无法及时准备好
0点时前一天的数据没有准备好

2. 无法准确获取全量的最新数据
   需要当天获取实时的最新数据。
3. 数据无序性

维表关联： 全量加载和增量加载

如何进行实时任务优化

• ( 1 ）独占资源和共享资源的策略
  在一台机器中，共享资源池可以被多个实时任务抢占，如果一个任务在运行时80% 以上的时间都需要去抢资源，这时候就需要考虑给它分配更多的独占资源，避免抢不到 CPU资源导致吞吐量急剧下降。
• (2 ）合理选择缓存机制，尽量降低读写库次数
  内存读写性能是最好的，根据业务的特性选择不同的缓存机制，让
  最热和最可能使用的数据留在内存中，读写库次数降低后，吞吐量自
  就上升了。
• (3 ）计算单元合并，降低拓扑层级
  拓扑结构层级越深 性能越差，因为数据在每个节点间传输时，
  部分是需要经过序列化和反序列化的，而这个过程非常消耗 CPU 和时间
• (4 ）内存对象共享，避免字符拷贝
  在海量数据处理中，大部分对象都是以字符串形式存在的，在不同
  线程间合理共享对象，可以大幅降低字符拷贝带来的性能消耗，不过
  注意不合理使用带来的内存溢出问题。
• (5 ）在高吞吐量和低延时间取平衡
  高吞吐量和低延时这两个特性是一对矛盾体，当把多个读写库操作
  或者 ACK 操作合并成一个时，可以大幅降低因为网络请求带来的消耗，
  不过也会导致延时高一些，在业务上衡量进行取舍。

六、数据服务

image.png

DWSOA

image.png

OpenApi

image.png

SmartDQ

image.png

OneService

image.png

1. 资源

系统的资源是有限的，如果能合理分配资源，使资源利用最大化，
那么系统的整体性能就会上一个台阶。下面讲述合理的资源分配是如何
提高性能的。
( 1 ）剥离计算资源
调用者调用接口获取的数据，有些指标需要多天数据的聚合，比如
最近 天访客浏览量、最近 365 天商品最低价格等；有些指标还包含一
些复杂的计算逻辑，比如成交回头率，其定义为在统计时间周期内，有
两笔及以上成交父订单的买家数除以有成交父订单的买家数。
如此复杂的计算逻辑，如果放在每次调用接口时进行处理，其成本
是非常高 的。因此剥离复杂的计算统计逻辑，将其全部交由底层的数据
公共层进行处理，只保留核心的业务处理逻辑。详细内容请参见第 章。
(2 ）查询资源分配
查询接口分为两种： Get 接口，只返回一条数据； Lis 接口，会返
回多条数据。一般来说， Get 查询基本都转换为 查询，响应时间比
较短，或者说查询代价比较小。而 List 查询的响应时间相对较长，且返
回记录数比较多，这就增加了序列化以及网络传输的成本，查询代价肯
定会更高一些。

image.png
image.png

(3 ）执行计划优化
①查询拆分。

image.png

②查询优化。
查询优化是分析用户请求中的 SQL 语句，将符合条件的 List查询转换为 Get 查询，从而提高性能。

（4）缓存优化

• 元数据缓存

• 模型缓存

  
  image.png
  

  对 DSL 进行语法、词法分析，并替换 WHERE 中的常量。比如
  where user_id = 123 替换为 where user_id ＝？。
  ·以替换后的语句做 key ，去本地缓存中进行查找。如果命中，则
  提取出缓存中的模型，直接将 SQL 提交给 查询。
  如果上一步没有命中， 则进行正常的解析处理，并缓存解析后的
  结果。
  需要注意的是，由于模型缓存在本地，为了避免占用太多的内存，
  需要定期将过期 的模型淘汰掉。假如元数据有变更，则缓存中的模型有
  可能已经失效或者是错误的，因此需要全部清理掉。

(3 ）结果缓存

image.png

3.查询能力
( 1 ）合并查询
(2 ）推送服务

4. 稳定性

5. 发布系统
   ( l ）元数据隔离
   一般的应用都会有 个环境：日常环境、预发环境和线上环境。日常环境用于线下开发测试。预发环境隔离了外部用户的访问，用于在正式发布前校验即将上线的代码。

   
   image.png

(2 ）隔离发布

隔离：机房隔离，分组隔离
安全限制：数据limit，字段限制，超时时间

监控：
( 1 ）调用日志采集
如果要对调用做监控，首先要保证调用日志的完整性。对于每次调
用都进行了采集，采集的信息包括：

• 基础信息 ，包括调用时间、接口名、 方法名、返回记录数等。
• 调用者信息，包括调用者应用名、来源 IP 地址等。
• 调用信息，包括调用指标、查询筛选条件等。
• 性能指标，包括响应时间、是否走缓存等。
• 错误信息，包括出错原因、错误类型、数据源、错误堆械等。
  (2 ）调用监控
  有了调用日志，就可以监控系统的健康状况，及时发现问题。监控可以从以下几个方面展开：
• 性能趋势。总体 QPS 趋势图、 RT 趋势图、响应时长区间分布。分组性能统计、单机 QPS 统计，以对当前系统容量做评估。
• 零调用统计。找出最近 天无调用的表，进行下线处理，节约成本。
• 慢 SQL 查找。找出响应时间较长的 SQL ，及时进行优化。
• 错误排查。当系统的调用错误数突增时，能从错误日志中及时发现出错原因、出错的数据源等。

5. 降级、限流
   ( 1）限流
   是应用内的 QPS保护
   如果某个调用者的调用量突增 ，或者对某个数据源的查询流量突增，超过了预设的QPS 阑值，则后续的请求立即失败返回，不再继续处理。通过快速失败，将超出系统处理能力的流量直接过滤掉，保障了系统的可用性。
   (2 ）降级
   降级主要有两种做法：

• 通过限流措施，将 QPS 置为 0，则对应的所有访问全部立即失败，防止了故障的扩散。
• 通过修改元数据，将存在问题的资源置为失效状态，则重新加载元数据后，对应的访问就全部失败了，不会再消耗系统资源。

五、数据挖掘

略