Light Gao

Flink实时数仓同步：拉链表实战详解

一、背景

在大数据领域，初始阶段业务数据通常被存储于关系型数据库，如MySQL。然而，为满足日常分析和报表等需求，大数据平台采用多种同步方式，以适应这些业务数据的不同存储需求。这些同步存储方式包括离线仓库和实时仓库等，选择取决于业务需求和数据特性。

一项常见需求是，业务使用人员需要大数据分析平台中查看历史某一天的表数据，示例如下：

[Mysql] 业务数据 - 用户表全量数据：

id	name	phone	gender	create_time	update_time
1	jack	111	男	2023-06-01 13:00:00	2023-06-01 13:00:00
2	jason	222	男	2023-06-01 13:00:00	2023-06-01 13:00:00
3	tom	333	男	2023-06-01 13:00:00	2023-06-01 13:00:00

[Mysql] 2023-06-02 业务数据新增了一名用户，且更改了tom的手机号，此时表数据如下：

id	name	phone	gender	create_time	update_time
1	jack	111	男	2023-06-01 13:00:00	2023-06-01 13:00:00
2	jason	222	男	2023-06-01 13:00:00	2023-06-01 13:00:00
3	tom	444	男	2023-06-01 13:00:00	2023-06-02 09:00:00
4	tony	555	男	2023-06-02 10:00:00	2023-06-02 10:00:00

加粗为更新/新增数据

[大数据平台] 2023-06-02日业务人员在大数据平台中查看用户表实时数据，期望数据和Mysql业务数据一致，如下：

id	name	phone	gender	create_time	update_time
1	jack	111	男	2023-06-01 13:00:00	2023-06-01 13:00:00
2	jason	222	男	2023-06-01 13:00:00	2023-06-01 13:00:00
3	tom	444	男	2023-06-01 13:00:00	2023-06-02 09:00:00
4	tony	555	男	2023-06-02 10:00:00	2023-06-02 10:00:00

[大数据平台] 2023-06-03 日业务人员在大数据平台中查看2023-06-02日用户表的历史数据，期望数据如下：

id	name	phone	gender	create_time	update_time
1	jack	111	男	2023-06-01 13:00:00	2023-06-01 13:00:00
2	jason	222	男	2023-06-01 13:00:00	2023-06-01 13:00:00
3	tom	333	男	2023-06-01 13:00:00	2023-06-01 13:00:00

根据以上需求，业务人员希望既能够查看当天的实时数据，又希望查看以天为粒度的历史数据。这类需求比较常见，通常可以采用两种解决方式：

Lambda架构
实时同步 + 拉链表架构

二、Lambda架构

实时领域的Lambda架构是一种大数据架构模式，旨在处理实时数据流和历史数据批处理，以满足同时满足实时查询和历史数据分析的需求。Lambda架构的核心思想是将数据分成两个独立的流程：实时流程和批处理流程，并在最终层将它们合并，以提供一致的查询结果，如下：

实时流程（Real-time Layer）：实时流程负责处理实时产生的数据流。它通常包括以下关键组件：
- 数据源：实时数据源，如binlog日志等。
- 实时引擎：用于实时数据的处理和转换，例如Apache Kafka、Apache Flink等。
- 存储层：用于存储实时数据，特点是插入快，支持OLAP查询。
离线处理流程（Batch Layer）：离线处理流程用于处理历史数据，通常以 T+1 凌晨跑批方式运行，主要包括以下组件：
- 数据仓库：批处理数据存储，通常使用分布式数据仓库，如Apache Hadoop HDFS、Apache Hive等。
- 批处理作业：用于处理历史数据的定期批处理作业，例如数据清洗、转换和聚合。
合并层（Serving Layer）：合并层负责将实时和历史数据合并以提供一致的查询接口：
- 数据服务：根据用户查询内容选择性调用不同存储服务，用于将实时数据和批处理数据合并以生成一致的视图。
Lambda架构的主要优点包括：
- 实时性：能够提供近实时的数据处理和反馈，适用于需要快速决策和实时监控的场景。
- 容错性：通过将数据存储在持久性存储中，保证了数据的可靠性和可恢复性。
- 灵活性：可以应对多种不同的数据类型和查询需求，适用于各种大数据应用。

注意：尽管Lambda架构可以满足业务人员查看用户的实时或历史数据的需求，但离线数据仓库通常采用T+1批处理方式运行，因此在需要高度一致性的场景下会出现数据不一致问题。故本文未采用Lambda架构；

若想详细了解一致性问题的情况，请参考笔者另一篇文章：深入数仓离线数据同步：问题分析与优化措施

三、实时同步+拉链表架构

为了满足业务人员对实时或历史数据的高度一致性需求，并且为了简化架构，这里采用了实时+拉链表的技术方案。在这个架构中，只使用了一种计算引擎，具体的技术组件为 Flink-cdc-2.x + Doris。以下是我们架构的设计概述：

此架构的关键在于实时同步逻辑及拉链表设计这两块的实现。

3.1、拉链表设计

拉链表是一种维护历史状态以及最新状态数据的表，与快照表类似，算是在快照表的基础上去除了重复状态的数据；使用拉链表在更新频率和比例不是很大的情况下会十分节省存储。

3.1.1、示例

我们以背景需求为例，[Mysql]业务数据用户表如下：

id	name	phone	gender	create_time	update_time
1	jack	111	男	2023-06-01 13:00:00	2023-06-01 13:00:00
2	jason	222	男	2023-06-01 13:00:00	2023-06-01 13:00:00
3	tom	333	男	2023-06-01 13:00:00	2023-06-01 13:00:00

[Doris]此时实时同步到Doris的拉链表数据为：

id	name	phone	gender	create_time	update_time	start date	end date
1	jack	111	男	2023-06-01 13:00:00	2023-06-01 13:00:00	2023-06-01	9999-12-31
2	jason	222	男	2023-06-01 13:00:00	2023-06-01 13:00:00	2023-06-01	9999-12-31
3	tom	333	男	2023-06-01 13:00:00	2023-06-01 13:00:00	2023-06-01	9999-12-31

可以看到拉链表多了expire，start date，end date 三个字段，用于表示该条数据是否过期、开始时间及有效时间，下面会有说明

[Mysql] 2023-06-02 业务数据新增了一名用户，更新了tom的手机号，此时表数据如下：

id	name	phone	gender	create_time	update_time
1	jack	111	男	2023-06-01 13:00:00	2023-06-01 13:00:00
2	jason	222	男	2023-06-01 13:00:00	2023-06-01 13:00:00
3	tom	444	男	2023-06-01 13:00:00	2023-06-02 09:00:00
4	tony	555	男	2023-06-02 10:00:00	2023-06-02 10:00:00

加粗为更改/新增数据

[Doris]此时实时同步到Doris的拉链表数据为：

id	name	phone	gender	create_time	update_time	start_date	end_date	备注
1	jack	111	男	2023-06-01 13:00:00	2023-06-01 13:00:00	2023-06-01	9999-12-31
2	jason	222	男	2023-06-01 13:00:00	2023-06-01 13:00:00	2023-06-01	9999-12-31
3	tom	333	男	2023-06-01 13:00:00	2023-06-01 13:00:00	2023-06-01	2023-06-01	(由9999-12-31改为2023-06-01)
3	tom	444	男	2023-06-01 13:00:00	2023-06-02 09:00:00	2023-06-02	9999-12-31	(新增一条拉链数据)
4	tony	555	男	2023-06-02 10:00:00	2023-06-02 10:00:00	2023-06-02	9999-12-31	(新增一条最新用户数据)

由于tom的手机号被修改，根据拉链表特性此时会新增一条最新的tom数据，且过期时间为9999-12-31，旧数据不会删除而是将有效时间end date改为2023-06-01

[Mysql] 2023-06-03 当天多次更新业务数据jason用户的手机号，sql及表数据如下：

UPDATE `user` SET `phone`='333', `update_time`='2023-06-03 10:00:00' WHERE `id`=2;
UPDATE `user` SET `phone`='444', `update_time`='2023-06-03 12:00:00' WHERE `id`=2;
UPDATE `user` SET `phone`='555', `update_time`='2023-06-03 14:00:00' WHERE `id`=2;

id	name	phone	gender	create_time	update_time	备注
1	jack	111	男	2023-06-01 13:00:00	2023-06-01 13:00:00
2	jason	555	男	2023-06-01 13:00:00	2023-06-03 14:00:00	(jason手机号从222 -> 333 -> 444 -> 555更改了三次)
3	tom	444	男	2023-06-01 13:00:00	2023-06-02 09:00:00
4	tony	555	男	2023-06-02 10:00:00	2023-06-02 10:00:00

[Doris]此时实时同步到Doris的拉链表数据为：

id	name	phone	gender	create_time	update_time	expire	start_date	end_date	备注
1	jack	111	男	2023-06-01 13:00:00	2023-06-01 13:00:00	0	2023-06-01	9999-12-31
2	jason	222	男	2023-06-01 13:00:00	2023-06-01 13:00:00	0	2023-06-01	2023-06-02	(由9999-12-31改为2023-06-02)
2	jason	333	男	2023-06-01 13:00:00	2023-06-03 10:00:00	1	2023-06-03	2023-06-03	(当天更新多次的过期数据)
2	jason	444	男	2023-06-01 13:00:00	2023-06-03 12:00:00	1	2023-06-03	2023-06-03	(当天更新多次的过期数据)
2	jason	555	男	2023-06-01 13:00:00	2023-06-03 14:00:00	0	2023-06-03	9999-12-31	(新增一条拉链数据)
3	tom	333	男	2023-06-01 13:00:00	2023-06-01 13:00:00	0	2023-06-01	2023-06-01
3	tom	444	男	2023-06-01 13:00:00	2023-06-02 09:00:00	0	2023-06-02	9999-12-31
4	tony	555	男	2023-06-02 10:00:00	2023-06-02 10:00:00	0	2023-06-02	9999-12-31

使用 expire 字段来表示记录是否过期，下面会说明

说明

start_date表示该条记录的生命周期开始时间【第一次全量同步时为系统时间，增量同步时为update_time时间】，end_date表示该条记录的生命周期结束时间
end_date = '9999-12-31’表示该条记录为最新数据
end_date = '2023-06-02’表示该条记录仅在2023-06-02当日有效
expire字段用于标识记录的状态，1表示记录已过期，0表示记录有效。该字段目的是用于过滤那些在一天之内多次更新的数据
如果查询当前的最新记录，sql为：select * from user where end_date = ‘9999-12-31’
如果查询2023-06-02的历史快照，sql为：select * from user where start_date <= ‘2023-06-02’ and end_date >= ‘2023-06-02’ and expire = 0（此处是拉链表比较重要的一块）
解释上一条sql：需求是要查2023-06-02的历史快照，故start_date <= ‘2023-06-02’；而end_date = '2023-06-02’表示该条记录在2023-06-02当日是有效的，又因为end_date = '9999-12-31’表示目前一直处于有效状态【有可能从2023-06-02到目前一直有效的数据】，所以end_date >= ‘2023-06-02’
示例：查询2023-06-01日历史数据：select * from user where start_date <= ‘2023-06-01’ and end_date >= ‘2023-06-01’ and expore = 0

id	name	phone	gender	create_time	update_time	start date	end date
1	jack	111	男	2023-06-01 13:00:00	2023-06-01 13:00:00	2023-06-01	9999-12-31
2	jason	222	男	2023-06-01 13:00:00	2023-06-01 13:00:00	2023-06-01	2023-06-02
3	tom	333	男	2023-06-01 13:00:00	2023-06-01 13:00:00	2023-06-01	2023-06-01

示例：查询2023-06-02日历史数据：select * from user where start_date <= ‘2023-06-02’ and end_date >= ‘2023-06-02’ and expore = 0

id	name	phone	gender	create_time	update_time	start date	end date
1	jack	111	男	2023-06-01 13:00:00	2023-06-01 13:00:00	2023-06-01	9999-12-31
2	jason	222	男	2023-06-01 13:00:00	2023-06-01 13:00:00	2023-06-01	2023-06-02
3	tom	444	男	2023-06-01 13:00:00	2023-06-02 09:00:00	2023-06-02	9999-12-31
4	tony	555	男	2023-06-02 10:00:00	2023-06-02 10:00:00	2023-06-02	9999-12-31

示例：查询最新实时数据：select * from user where end_date = ‘9999-12-31’

id	name	phone	gender	create_time	update_time	start date	end date
1	jack	111	男	2023-06-01 13:00:00	2023-06-01 13:00:00	2023-06-01	9999-12-31
2	jason	555	男	2023-06-01 13:00:00	2023-06-03 14:00:00	2023-06-03	9999-12-31
3	tom	444	男	2023-06-01 13:00:00	2023-06-02 09:00:00	2023-06-02	9999-12-31
4	tony	555	男	2023-06-02 10:00:00	2023-06-02 10:00:00	2023-06-02	9999-12-31

3.1.2、建表设计

在Doris中的表设计中，采用了Unique数据模型，这个决策的背后有一个关键因素，即利用唯一Key来处理Flink作业崩溃和重新启动时的数据覆盖操作，以及通过下游的幂等性来确保端到端的数据一致性。

唯一Key的选择在这里起到了至关重要的作用。在拉链表中，由于用户ID可能重复出现的情况【例如2023-06-02号tom就有两条数据】，故选择了一个组合Key: UNIQUE KEY(id, update_time) 来确保数据的唯一性。这种设计使得无论在什么情况下，我们都能够通过这个唯一Key来维护数据的一致性，即使在处理实时数据时发生了异常情况或重新启动作业时也不会出现问题。

以上述为例建表语句如下：

CREATE TABLE IF NOT EXISTS example_user_zip
(
    `id` LARGEINT NOT NULL COMMENT "用户id",
    `update_time` DATETIME COMMENT "用户更新时间",
    `create_time` DATETIME COMMENT "用户注册时间",
    `name` VARCHAR(50) NOT NULL COMMENT "用户昵称",
    `phone` LARGEINT COMMENT "手机号",
    `gender` VARCHAR(5) COMMENT "用户性别",
    `expire` TINYINT DEFAULT '0' COMMENT "数据是否过期:0为有效,1为过期",
    `start_date` DATE COMMENT "开始时间",
    `end_date` DATE COMMENT "有效时间"
)
UNIQUE KEY(`id`, `update_time`) -- UNIQUE模型
COMMENT "用户拉链表"
DISTRIBUTED BY HASH(`id`) BUCKETS 32
PROPERTIES (
"replication_allocation" = "tag.location.default: 1"
);

关于doris更多数据模型可参考官网

3.2、实时同步逻辑【重要】

为了更清晰地解释拉链表的同步逻辑，我将以场景的方式逐步说明，如下：

全量更新
增量更新
1. 新增数据
2. 跨天更新数据
3. 某条数据当天多次更新
4. 删除数据
并发更新

3.2.1、全量更新

需先明确一点：拉链表的历史数据查询范围是从实时任务同步的那天开始，因为只有在实时任务开始同步的那一天之后，拉链表才正式形成，之前的历史数据是不可查询的。因此，当进行第一次全量同步时，我们会将 start_date 设置为当前系统日期。
另外，由于实时拉链表同步需要明确区分全量和增量更新，以及后续对 binlog 数据进行解析及判断增量更新操作类型，因此，Flink CDC SQL 方式的表建立不再满足我们的要求。为了更好地实现这一功能，我们需要采用 API 方式来构建解决方案，代码如下：

import org.apache.flink.api.common.eventtime.WatermarkStrategy;
import org.apache.flink.streaming.api.environment.StreamExecutionEnvironment;
import com.ververica.cdc.debezium.JsonDebeziumDeserializationSchema;
import com.ververica.cdc.connectors.mysql.source.MySqlSource;

public class MySqlSourceExample {
  public static void main(String[] args) throws Exception {
    MySqlSource<String> mySqlSource = MySqlSource.<String>builder()
        .hostname("yourHostname")
        .port(yourPort)
        .databaseList("yourDatabaseName") // 设置捕获的数据库， 如果需要同步整个数据库，请将 tableList 设置为 ".*".
        .tableList("yourDatabaseName.yourTableName") // 设置捕获的表
        .username("yourUsername")
        .password("yourPassword")
        .deserializer(new JsonDebeziumDeserializationSchema()) // 将 SourceRecord 转换为 JSON 字符串
        .build();

    StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment();

    // 设置 3s 的 checkpoint 间隔
    env.enableCheckpointing(3000);

    env
      .fromSource(mySqlSource, WatermarkStrategy.noWatermarks(), "MySQL Source")
      // 设置 source 节点的并行度为 4
      .setParallelism(4)
      .print().setParallelism(1); // 设置 sink 节点并行度为 1 

    env.execute("Print MySQL Snapshot + Binlog");
  }
}

代码摘自mysql-cdc-connector官网示例

这里我们仍以2023-06-01的[Mysql]业务数据为例：

id	name	phone	gender	create_time	update_time
1	jack	111	男	2023-06-01 13:00:00	2023-06-01 13:00:00
2	jason	222	男	2023-06-01 13:00:00	2023-06-01 13:00:00
3	tom	333	男	2023-06-01 13:00:00	2023-06-01 13:00:00

此时Flink应用获取到的数据如下：仅展示一条

{
	"before": null,
	"after": {		 # 实际数据
		"id": 1,
		"name": "jack",
		"phone": "111",
		"gender": "男",
		"create_time": "2023-06-01T05:00:00Z",  # 该日期是UTC时间,只需增加8小时即可转化为北京时间
		"update_time": "2023-06-01T05:00:00Z"	# 该日期是UTC时间,只需增加8小时即可转化为北京时间
	},
	"source": {		 # 元数据
		"version": "1.6.4.Final",
		"connector": "mysql",
		"name": "mysql_binlog_source",
		"ts_ms": 0,
		"snapshot": "false",
		"db": "yushu_dds",
		"sequence": null,
		"table": "user",
		"server_id": 0,
		"gtid": null,
		"file": "",
		"pos": 0,
		"row": 0,
		"thread": null,
		"query": null
	},
	"op": "r",  	 # 记录每条数据的操作类型[重要]
	"ts_ms": 1705471382867,
	"transaction": null
}

在我们使用 Flink CDC MySQL 同步数据时，默认采用 initial 模式，这意味着首先进行全量同步，然后再进行增量同步。因此，在区分全量和增量同步时，关键在于观察获取到的数据中的 op 字段。op 字段是用来记录每条数据的操作类型的标志。具体的操作类型如下：
- op=d 代表删除操作
- op=u 代表更新操作
- op=c 代表新增操作
- op=r 代表全量读取，而不是来自 binlog 的增量读取
在 Flink 程序中，只需要通过 op=r 即可筛选出全量数据。在全量数据同步阶段，Doris 拉链表的 start_date 字段设置为系统当前日期，而 end_date 字段则设置为 ‘9999-12-31’。导入语句如下：

INSERT INTO example_user_zip (id, update_time, create_time, name, phone, gender, expire, start_date, end_date)
VALUES 
(1, '2023-06-01 13:00:00', '2023-06-01 13:00:00', 'jack', 111, '男', 0, '2023-06-01', '9999-12-31'),
(2, '2023-06-01 13:00:00', '2023-06-01 13:00:00', 'jason', 222, '男', 0, '2023-06-01', '9999-12-31'),
(3, '2023-06-01 13:00:00', '2023-06-01 13:00:00', 'tom', 333, '男', 0, '2023-06-01', '9999-12-31');

此时doris拉链表数据如下所示：

id	name	phone	gender	create_time	update_time	start_date	end date
1	jack	111	男	2023-06-01 13:00:00	2023-06-01 13:00:00	2023-06-01	9999-12-31
2	jason	222	男	2023-06-01 13:00:00	2023-06-01 13:00:00	2023-06-01	9999-12-31
3	tom	333	男	2023-06-01 13:00:00	2023-06-01 13:00:00	2023-06-01	9999-12-31

3.2.2、增量更新

当全量更新结束后即为增量更新，请注意以下内容：

在增量更新时，Doris 拉链表中的 start_date 字段【即开始时间】不再使用系统时间，而是业务数据的 update_time 截取后的日期。例如，update_time 为 “2023-06-02 13:00:00”，则对应的 start_date 为 “2023-06-02”。这么做的目的是为了确保使用事件时间来划分数据的开始时间，而不是系统时间。
举例来说，如果采用系统时间，假设实时同步任务某一天宕机并且没有重启，等到隔天再重启，那么 start_date 就会变成隔天日期，从而导致昨天的数据丢失。
为什么不使用业务数据的 create_time 作为拉链表的 start_date 呢？这是因为在业务数据更改时，通常只会更新 update_time。例如，2023-06-02 日更新了 “Tom” 的手机号码，此时同步到 Doris 新增的拉链数据如果使用 create_time，那么 start_date 仍然会是 “2023-06-01”，而实际上该条数据应该从 “2023-06-02” 日开始生效。因此，使用 update_time 更加合理，确保拉链表中的数据始终按照业务数据的更新时间来进行正确的版本管理。

接下来，我们将逐一讲解以下四个场景：新增更新、跨天更新、某条数据当天多次更新以及删除更新。

3.2.2.1、新增更新

我们仍以最初的示例为例：[Mysql] 2023-06-02 业务数据新增了一名用户，此时表数据如下：

id	name	phone	gender	create_time	update_time
1	jack	111	男	2023-06-01 13:00:00	2023-06-01 13:00:00
2	jason	222	男	2023-06-01 13:00:00	2023-06-01 13:00:00
3	tom	333	男	2023-06-01 13:00:00	2023-06-01 13:00:00
4	tony	555	男	2023-06-02 10:00:00	2023-06-02 10:00:00

加粗为更新/新增数据

此时Flink应用获取到的数据如下所示：

{
	"before": null,
	"after": {
		"id": 4,
		"name": "tony",
		"phone": "555",
		"gender": "男",
		"create_time": "2023-06-02T02:00:00Z",
		"update_time": "2023-06-02T02:00:00Z"
	},
	"source": {
		# 此处元数据省略
	},
	"op": "c",
	"ts_ms": 1705477497504,
	"transaction": null
}

可以看到op=c 代表新增操作，对于新增操作doris拉链表的start_end为业务数据的update_time，而end_date均设置为9999-12-31，导入语句如下：

INSERT INTO example_user_zip (id, update_time, create_time, name, phone, gender, expire, start_date, end_date)
VALUES 
(4, '2023-06-02 10:00:00', '2023-06-02 10:00:00', 'tony', 555, '男', 0, '2023-06-02', '9999-12-31');

此时doris拉链表内容如下所示：

id	name	phone	gender	create_time	update_time	start_date	end_date
1	jack	111	男	2023-06-01 13:00:00	2023-06-01 13:00:00	2023-06-01	9999-12-31
2	jason	222	男	2023-06-01 13:00:00	2023-06-01 13:00:00	2023-06-01	9999-12-31
3	tom	333	男	2023-06-01 13:00:00	2023-06-01 13:00:00	2023-06-01	9999-12-31
4	tony	555	男	2023-06-02 10:00:00	2023-06-02 10:00:00	2023-06-02	9999-12-31

加粗表示更新/新增数据

3.2.2.2、跨天更新

首先，解释一下为何要需要区分两种不同的更新场景：跨天更新和当天多次更新。这涉及到拉链表的历史数据粒度，拉链表通常以天为单位。如果一条数据在同一天内多次更新，那么每次更新后的数据的生存时间将只有几小时甚至几分钟。在这种情况下，我们希望在拉链表中将这种多次更新的临时数据设为过期数据；细节在后续会有讲解，先来解释跨天更新场景。

我们仍以最初的示例为例：[Mysql] 2023-06-02 业务数据更新了tom的手机号，此时表数据如下：

id	name	phone	gender	create_time	update_time
1	jack	111	男	2023-06-01 13:00:00	2023-06-01 13:00:00
2	jason	222	男	2023-06-01 13:00:00	2023-06-01 13:00:00
3	tom	444	男	2023-06-01 13:00:00	2023-06-02 09:00:00
4	tony	555	男	2023-06-02 10:00:00	2023-06-02 10:00:00

加粗为更新/新增数据

此时Flink应用获取到的数据如下所示：

{
	"before": {	 # 更新前的数据
		"id": 3,
		"name": "tom",
		"phone": "333",
		"gender": "男",
		"create_time": "2023-06-01T05:00:00Z",
		"update_time": "2023-06-01T05:00:00Z"
	},
	"after": {	# 更新后的数据
		"id": 3,
		"name": "tom",
		"phone": "444",  # 手机号更新
		"gender": "男",
		"create_time": "2023-06-01T05:00:00Z",
		"update_time": "2023-06-02T01:00:00Z"  # 更新时间更新
	},
	"source": {
		# 此处元数据省略
	},
	"op": "u",
	"ts_ms": 1705479637926,
	"transaction": null
}

当我们在Flink应用中遇到op=u（代表更新操作）时，首先需要检查before和after字段中的update_time是否跨越了天粒度。可能跨越一天，也可能跨越多天，我们将在Doris拉链表中执行两条SQL语句：一条更新语句和一条插入语句。
1. 对于更新语句，我们将更新拉链表中旧数据id的end_date字段，将其设置为after字段中update_time的前一天2023-06-01。
2. 对于插入语句，我们将插入after字段中的新数据，将start_date设置为update_time的日期，end_date设置9999-12-31），以确保该数据在拉链表中一直有效。
3. sql如下所示：

-- 更新语句：
UPDATE example_user_zip SET end_date = '2023-06-01' WHERE `id`=3 AND `update_time`='2023-06-01 13:00:00';

-- 插入语句：
INSERT INTO example_user_zip (id, update_time, create_time, name, phone, gender, expire, start_date, end_date)
VALUES 
(3, '2023-06-02 09:00:00', '2023-06-01 13:00:00', 'tom', 444, '男', 0, '2023-06-02', '9999-12-31');

此时doris拉链表内容如下所示：

id	name	phone	gender	create_time	update_time	start_date	end_date
1	jack	111	男	2023-06-01 13:00:00	2023-06-01 13:00:00	2023-06-01	9999-12-31
2	jason	222	男	2023-06-01 13:00:00	2023-06-01 13:00:00	2023-06-01	9999-12-31
3	tom	333	男	2023-06-01 13:00:00	2023-06-01 13:00:00	2023-06-01	2023-06-01
3	tom	444	男	2023-06-01 13:00:00	2023-06-02 09:00:00	2023-06-02	9999-12-31
4	tony	555	男	2023-06-02 10:00:00	2023-06-02 10:00:00	2023-06-02	9999-12-31

加粗表示更新/新增数据

此时若要查看2023-06-01历史数据只需执行：

SELECT * FROM example_user_zip WHERE start_date <= '2023-06-01' AND end_date >= '2023-06-01' AND expire = 0;

id	name	phone	gender	create_time	update_time	start date	end date
1	jack	111	男	2023-06-01 13:00:00	2023-06-01 13:00:00	2023-06-01	9999-12-31
2	jason	222	男	2023-06-01 13:00:00	2023-06-01 13:00:00	2023-06-01	9999-12-31
3	tom	333	男	2023-06-01 13:00:00	2023-06-01 13:00:00	2023-06-01	2023-06-01

3.2.2.3、某条数据当天多次更新

在我们的拉链表中，数据的粒度是以天为单位。如果一条数据在同一天内多次更新，我们的处理策略是取最后一次更新为有效数据，而将之前的更新标记为过期数据。为了标记数据是否过期，我们会将过期数据的expire字段设置为1。

我们仍以最初的示例为例：[Mysql] 2023-06-03 当天多次更新业务数据jason用户的手机号，sql及表数据如下：

UPDATE `user` SET `phone`='333', `update_time`='2023-06-03 10:00:00' WHERE `id`=2;
UPDATE `user` SET `phone`='444', `update_time`='2023-06-03 12:00:00' WHERE `id`=2;
UPDATE `user` SET `phone`='555', `update_time`='2023-06-03 14:00:00' WHERE `id`=2;

id	name	phone	gender	create_time	update_time	备注
1	jack	111	男	2023-06-01 13:00:00	2023-06-01 13:00:00
2	jason	555	男	2023-06-01 13:00:00	2023-06-03 14:00:00	(jason手机号从222 -> 333 -> 444 -> 555更改了三次)
3	tom	444	男	2023-06-01 13:00:00	2023-06-02 09:00:00
4	tony	555	男	2023-06-02 10:00:00	2023-06-02 10:00:00

此时Flink应用获取到的数据如下所示：

{
	"before": {
		"id": 2,
		"name": "jason",
		"phone": "222",
		"gender": "男",
		"create_time": "2023-06-01T05:00:00Z",
		"update_time": "2023-06-01T05:00:00Z"
	},
	"after": {
		"id": 2,
		"name": "jason",
		"phone": "333",
		"gender": "男",
		"create_time": "2023-06-01T05:00:00Z",
		"update_time": "2023-06-03T02:00:00Z"
	},
	"source": {
		# 元数据忽略		
	},
	"op": "u",
	"ts_ms": 1705548298335,
	"transaction": null
},
{
	"before": {
		"id": 2,
		"name": "jason",
		"phone": "333",
		"gender": "男",
		"create_time": "2023-06-01T05:00:00Z",
		"update_time": "2023-06-03T02:00:00Z"
	},
	"after": {
		"id": 2,
		"name": "jason",
		"phone": "444",
		"gender": "男",
		"create_time": "2023-06-01T05:00:00Z",
		"update_time": "2023-06-03T04:00:00Z"
	},
	"source": {
		# 元数据忽略		
	},
	"op": "u",
	"ts_ms": 1705548298392,
	"transaction": null
},
{
	"before": {
		"id": 2,
		"name": "jason",
		"phone": "444",
		"gender": "男",
		"create_time": "2023-06-01T05:00:00Z",
		"update_time": "2023-06-03T04:00:00Z"
	},
	"after": {
		"id": 2,
		"name": "jason",
		"phone": "555",
		"gender": "男",
		"create_time": "2023-06-01T05:00:00Z",
		"update_time": "2023-06-03T06:00:00Z"
	},
	"source": {
		# 元数据忽略
	},
	"op": "u",
	"ts_ms": 1705548298484,
	"transaction": null
}

当我们在Flink应用中遇到op=u（代表更新操作），且检查before和after字段中的update_time属于同一天，我们将在Doris拉链表中执行两条SQL语句：一条更新语句和一条插入语句。

对于更新语句，我们将更新拉链表中旧数据id的expire字段设置为1，将其设置为end_date字段值设置为update_time的当天日期2023-06-03。
对于插入语句，我们将插入after字段中的新数据，将start_date设置为update_time的当天日期，end_date设置9999-12-31），以确保该数据在拉链表中一直有效。
sql如下所示：

-- 222 -> 333 跨天更新语句：
UPDATE example_user_zip SET end_date = '2023-06-02' WHERE `id`=2 AND `update_time`='2023-06-01 13:00:00';

-- 222 -> 333 跨天插入语句：
INSERT INTO example_user_zip (id, update_time, create_time, name, phone, gender, expire, start_date, end_date)
VALUES 
(2, '2023-06-03 10:00:00', '2023-06-01 13:00:00', 'jason', 333, '男', 0, '2023-06-03', '9999-12-31');

-- 333 -> 444 同一天更新语句：
UPDATE example_user_zip SET expire = 1, end_date = '2023-06-03' WHERE `id`=2 AND `update_time`='2023-06-03 10:00:00';

-- 333 -> 444 同一天插入语句：
INSERT INTO example_user_zip (id, update_time, create_time, name, phone, gender, expire, start_date, end_date)
VALUES 
(2, '2023-06-03 12:00:00', '2023-06-01 13:00:00', 'jason', 444, '男', 0, '2023-06-03', '9999-12-31');

-- 444 -> 555 同一天更新语句：
UPDATE example_user_zip SET expire = 1, end_date = '2023-06-03' WHERE `id`=2 AND `update_time`='2023-06-03 12:00:00';

-- 444 -> 555 同一天插入语句：
INSERT INTO example_user_zip (id, update_time, create_time, name, phone, gender, expire, start_date, end_date)
VALUES 
(2, '2023-06-03 14:00:00', '2023-06-01 13:00:00', 'jason', 555, '男', 0, '2023-06-03', '9999-12-31');

此时doris拉链表内容如下所示：

id	name	phone	gender	create_time	update_time	expire	start_date	end_date	备注
1	jack	111	男	2023-06-01 13:00:00	2023-06-01 13:00:00	0	2023-06-01	9999-12-31
2	jason	222	男	2023-06-01 13:00:00	2023-06-01 13:00:00	0	2023-06-01	2023-06-02	(由9999-12-31改为2023-06-02)
2	jason	333	男	2023-06-01 13:00:00	2023-06-03 10:00:00	1	2023-06-03	2023-06-03	(当天更新多次的过期数据)
2	jason	444	男	2023-06-01 13:00:00	2023-06-03 12:00:00	1	2023-06-03	2023-06-03	(当天更新多次的过期数据)
2	jason	555	男	2023-06-01 13:00:00	2023-06-03 14:00:00	0	2023-06-03	9999-12-31	(新增一条最新数据)
3	tom	333	男	2023-06-01 13:00:00	2023-06-01 13:00:00	0	2023-06-01	2023-06-01
3	tom	444	男	2023-06-01 13:00:00	2023-06-02 09:00:00	0	2023-06-02	9999-12-31
4	tony	555	男	2023-06-02 10:00:00	2023-06-02 10:00:00	0	2023-06-02	9999-12-31

此时若要查看2023-06-03历史数据只需执行：

SELECT * FROM example_user_zip WHERE start_date <= '2023-06-03' AND end_date >= '2023-06-03' AND expire = 0;

id	name	phone	gender	create_time	update_time	start_date	end_date
1	jack	111	男	2023-06-01 13:00:00	2023-06-01 13:00:00	2023-06-01	9999-12-31
2	jason	222	男	2023-06-01 13:00:00	2023-06-01 13:00:00	2023-06-01	2023-06-02
3	tom	444	男	2023-06-01 13:00:00	2023-06-02 09:00:00	2023-06-02	9999-12-31
4	tony	555	男	2023-06-02 10:00:00	2023-06-02 10:00:00	2023-06-02	9999-12-31

3.2.2.4、删除更新

由于[Mysql]业务数据都具备唯一键，故业务数据的删除同步至拉链表无需判断是否跨天，只需更新删除数据的end_date日期为前一天即可。

[Mysql] 2023-06-04 当天删除业务数据jack，表数据如下：

id	name	phone	gender	create_time	update_time	备注
2	jason	555	男	2023-06-01 13:00:00	2023-06-03 14:00:00	(jason手机号从222 -> 333 -> 444 -> 555更改了三次)
3	tom	444	男	2023-06-01 13:00:00	2023-06-02 09:00:00
4	tony	555	男	2023-06-02 10:00:00	2023-06-02 10:00:00

此时Flink应用获取到的数据如下所示：

{
	"before": {
		"id": 1,
		"name": "jack",
		"phone": "111",
		"gender": "男",
		"create_time": "2023-06-01T05:00:00Z",
		"update_time": "2023-06-01T05:00:00Z"
	},
	"after": null,
	"source": {
		# 忽略元数据
	},
	"op": "d", 	# 操作类型
	"ts_ms": 1705561813650,
	"transaction": null
}

可以看到op=d 代表删除操作，对于删除操作doris拉链表只需将before数据的date_date日期更新为前一日2023-06-03，导入语句如下：

-- 更新语句
UPDATE example_user_zip SET end_date = '2023-06-03' WHERE `id`=1 AND `update_time`='2023-06-01 13:00:00';

此时doris拉链表内容如下所示：

id	name	phone	gender	create_time	update_time	expire	start_date	end_date	备注
1	jack	111	男	2023-06-01 13:00:00	2023-06-01 13:00:00	0	2023-06-01	2023-06-03	(由9999-12-31改为2023-06-03)
2	jason	222	男	2023-06-01 13:00:00	2023-06-01 13:00:00	0	2023-06-01	2023-06-02
2	jason	333	男	2023-06-01 13:00:00	2023-06-03 10:00:00	1	2023-06-03	2023-06-03
2	jason	444	男	2023-06-01 13:00:00	2023-06-03 12:00:00	1	2023-06-03	2023-06-03
2	jason	555	男	2023-06-01 13:00:00	2023-06-03 14:00:00	0	2023-06-03	9999-12-31
3	tom	333	男	2023-06-01 13:00:00	2023-06-01 13:00:00	0	2023-06-01	2023-06-01
3	tom	444	男	2023-06-01 13:00:00	2023-06-02 09:00:00	0	2023-06-02	9999-12-31
4	tony	555	男	2023-06-02 10:00:00	2023-06-02 10:00:00	0	2023-06-02	9999-12-31

此时若要查看2023-06-04数据只需执行：

SELECT * FROM example_user_zip WHERE start_date <= '2023-06-04' AND end_date >= '2023-06-04' AND expire = 0;

id	name	phone	gender	create_time	update_time	start_date	end_date
2	jason	222	男	2023-06-01 13:00:00	2023-06-01 13:00:00	2023-06-01	2023-06-02
3	tom	444	男	2023-06-01 13:00:00	2023-06-02 09:00:00	2023-06-02	9999-12-31
4	tony	555	男	2023-06-02 10:00:00	2023-06-02 10:00:00	2023-06-02	9999-12-31

3.2.3、并发更新

这里单独强调并发更新场景是因为在关系型数据库中，例如MySQL，通常使用timestamp类型来表示update_time，而该数据类型的最细粒度是秒。因此，当多个并发操作同时更新同一条数据时，update_time的值只会发生一次变化，但会产生多条binlog日志。由于Doris的拉链表以id + update_time作为唯一键，这种情况下会导致同一条数据多次更新。因此，这里单独讲解并发更新的情况。

需要注意的是，并发问题只存在于更新操作，删除和创建操作不会出现上述问题。

[Mysql] 2023-06-05 当天 15:00:00 并发更新业务数据tony的手机号，表数据如下：

id	name	phone	gender	create_time	update_time	备注
2	jason	555	男	2023-06-01 13:00:00	2023-06-03 14:00:00
3	tom	444	男	2023-06-01 13:00:00	2023-06-02 09:00:00
4	tony	777	男	2023-06-02 10:00:00	2023-06-05 15:00:00	(tony手机号从555-> 666-> 777 并发更改两次)

此时Flink应用获取到的数据如下所示：

{
	"before": {
		"id": 4,
		"name": "tony",
		"phone": "555",
		"gender": "男",
		"create_time": "2023-06-02T02:00:00Z",
		"update_time": "2023-06-02T02:00:00Z"
	},
	"after": {
		"id": 4,
		"name": "tony",
		"phone": "666",
		"gender": "男",
		"create_time": "2023-06-02T02:00:00Z",
		"update_time": "2023-06-05T07:00:00Z"
	},
	"source": {
		# 元数据忽略
	},
	"op": "u",
	"ts_ms": 1705564093414,
	"transaction": null
},
{
	"before": {
		"id": 4,
		"name": "tony",
		"phone": "666",
		"gender": "男",
		"create_time": "2023-06-02T02:00:00Z",
		"update_time": "2023-06-05T07:00:00Z"
	},
	"after": {
		"id": 4,
		"name": "tony",
		"phone": "777",
		"gender": "男",
		"create_time": "2023-06-02T02:00:00Z",
		"update_time": "2023-06-05T07:00:00Z"
	},
	"source": {
		# 元数据忽略
	},
	"op": "u",
	"ts_ms": 1705564093478,
	"transaction": null
}

可以看到op=u 代表更新操作，这里我们仍沿用增量更新的逻辑，第一条日志中业务数据555->666属于跨天更新，第二条日志中业务数据666->777属于一条数据当天多次更新，DorisSql如下所示：

-- 555 -> 666 跨天更新语句：
UPDATE example_user_zip SET end_date = '2023-06-04' WHERE `id`=4 AND `update_time`='2023-06-02 10:00:00';

-- 555 -> 666 跨天插入语句：
INSERT INTO example_user_zip (id, update_time, create_time, name, phone, gender, expire, start_date, end_date)
VALUES 
(4, '2023-06-05 15:00:00', '2023-06-02 10:00:00', 'tony', 666, '男', 0, '2023-06-05', '9999-12-31');

-- 666 -> 777 同一天更新语句：
UPDATE example_user_zip SET expire = 1, end_date = '2023-06-05' WHERE `id`=4 AND `update_time`='2023-06-05 15:00:00';

-- 666 -> 777 同一天插入语句：
INSERT INTO example_user_zip (id, update_time, create_time, name, phone, gender, expire, start_date, end_date)
VALUES 
(4, '2023-06-05 15:00:00', '2023-06-02 10:00:00', 'tony', 777, '男', 0, '2023-06-05', '9999-12-31');

此时doris拉链表内容如下所示：

id	name	phone	gender	create_time	update_time	expire	start_date	end_date	备注
1	jack	111	男	2023-06-01 13:00:00	2023-06-01 13:00:00	0	2023-06-01	2023-06-03
2	jason	222	男	2023-06-01 13:00:00	2023-06-01 13:00:00	0	2023-06-01	2023-06-02
2	jason	333	男	2023-06-01 13:00:00	2023-06-03 10:00:00	1	2023-06-03	2023-06-03
2	jason	444	男	2023-06-01 13:00:00	2023-06-03 12:00:00	1	2023-06-03	2023-06-03
2	jason	555	男	2023-06-01 13:00:00	2023-06-03 14:00:00	0	2023-06-03	9999-12-31
3	tom	333	男	2023-06-01 13:00:00	2023-06-01 13:00:00	0	2023-06-01	2023-06-01
3	tom	444	男	2023-06-01 13:00:00	2023-06-02 09:00:00	0	2023-06-02	9999-12-31
4	tony	555	男	2023-06-02 10:00:00	2023-06-02 10:00:00	0	2023-06-02	2023-06-04	(由9999-12-31改为2023-06-04)
4	tony	777	男	2023-06-02 10:00:00	2023-06-05 15:00:00	0	2023-06-05	9999-12-31	(新增一条最新数据)

此时可以看到新增了一条Tony的数据，有些人可能注意到少了一条姓名为Tony、手机号为666、expire字段为1的数据。这是因为最后的更新和插入语句中的id + update_time完全一致，触发了Doris的replace替换操作。因此，最后一条插入语句覆盖了前一条更新语句，即"Tony, 666, expire=1"的数据被覆盖掉了。而这种替换操作反而变相解决了并发更新的问题。

此时若要查看2023-06-04数据只需执行：

SELECT * FROM example_user_zip WHERE start_date <= '2023-06-05' AND end_date >= '2023-06-05' AND expire = 0;

id	name	phone	gender	create_time	update_time	start_date	end_date
2	jason	222	男	2023-06-01 13:00:00	2023-06-01 13:00:00	2023-06-01	2023-06-02
3	tom	444	男	2023-06-01 13:00:00	2023-06-02 09:00:00	2023-06-02	9999-12-31
4	tony	777	男	2023-06-02 10:00:00	2023-06-05 15:00:00	2023-06-05	9999-12-31

此时有些同学会提出问题，即这个情况和上文中的跨天更新以及当天多次更新的逻辑有何不同? 似乎没有特殊的操作逻辑。确实，从逻辑上看，这两种情况是一致的。这是因为我们先执行更新操作，然后再执行新增操作。如果我们反过来，先执行新增操作，然后再执行更新操作，就会导致数据丢失。接下来，让我们看一下如果先执行新增操作再执行更新操作会发生什么情况。首先，我们将Doris拉链表恢复到前一天，如下所示：

id	name	phone	gender	create_time	update_time	expire	start_date	end_date	备注
1	jack	111	男	2023-06-01 13:00:00	2023-06-01 13:00:00	0	2023-06-01	2023-06-03	(由9999-12-31改为2023-06-03)
2	jason	222	男	2023-06-01 13:00:00	2023-06-01 13:00:00	0	2023-06-01	2023-06-02
2	jason	333	男	2023-06-01 13:00:00	2023-06-03 10:00:00	1	2023-06-03	2023-06-03
2	jason	444	男	2023-06-01 13:00:00	2023-06-03 12:00:00	1	2023-06-03	2023-06-03
2	jason	555	男	2023-06-01 13:00:00	2023-06-03 14:00:00	0	2023-06-03	9999-12-31
3	tom	333	男	2023-06-01 13:00:00	2023-06-01 13:00:00	0	2023-06-01	2023-06-01
3	tom	444	男	2023-06-01 13:00:00	2023-06-02 09:00:00	0	2023-06-02	9999-12-31
4	tony	555	男	2023-06-02 10:00:00	2023-06-02 10:00:00	0	2023-06-02	9999-12-31

接下来我们将更新插入操作调换顺序，sql如下所示：

-- 555 -> 666 跨天插入语句：
INSERT INTO example_user_zip (id, update_time, create_time, name, phone, gender, expire, start_date, end_date)
VALUES 
(4, '2023-06-05 15:00:00', '2023-06-02 10:00:00', 'tony', 666, '男', 0, '2023-06-05', '9999-12-31');

-- 555 -> 666 跨天更新语句：
UPDATE example_user_zip SET end_date = '2023-06-04' WHERE `id`=4 AND `update_time`='2023-06-02 10:00:00';

-- 666 -> 777 同一天插入语句：
INSERT INTO example_user_zip (id, update_time, create_time, name, phone, gender, expire, start_date, end_date)
VALUES 
(4, '2023-06-05 15:00:00', '2023-06-02 10:00:00', 'tony', 777, '男', 0, '2023-06-05', '9999-12-31');

-- 666 -> 777 同一天更新语句：
UPDATE example_user_zip SET expire = 1, end_date = '2023-06-05' WHERE `id`=4 AND `update_time`='2023-06-05 15:00:00';

此时doris拉链表内容如下所示：

id	name	phone	gender	create_time	update_time	expire	start_date	end_date	备注
1	jack	111	男	2023-06-01 13:00:00	2023-06-01 13:00:00	0	2023-06-01	2023-06-03
2	jason	222	男	2023-06-01 13:00:00	2023-06-01 13:00:00	0	2023-06-01	2023-06-02
2	jason	333	男	2023-06-01 13:00:00	2023-06-03 10:00:00	1	2023-06-03	2023-06-03
2	jason	444	男	2023-06-01 13:00:00	2023-06-03 12:00:00	1	2023-06-03	2023-06-03
2	jason	555	男	2023-06-01 13:00:00	2023-06-03 14:00:00	0	2023-06-03	9999-12-31
3	tom	333	男	2023-06-01 13:00:00	2023-06-01 13:00:00	0	2023-06-01	2023-06-01
3	tom	444	男	2023-06-01 13:00:00	2023-06-02 09:00:00	0	2023-06-02	9999-12-31
4	tony	555	男	2023-06-02 10:00:00	2023-06-02 10:00:00	0	2023-06-02	2023-06-04	(由9999-12-31改为2023-06-04)
4	tony	777	男	2023-06-02 10:00:00	2023-06-05 15:00:00	1	2023-06-05	2023-06-05	(更新拉链数据)

可以看到已经没有tony的最新数据了。

此时查看2023-06-05数据执行：只有两条数据

SELECT * FROM example_user_zip WHERE start_date <= '2023-06-05' AND end_date >= '2023-06-05' AND expire = 0;

id	name	phone	gender	create_time	update_time	start_date	end_date
2	jason	222	男	2023-06-01 13:00:00	2023-06-01 13:00:00	2023-06-01	2023-06-02
3	tom	444	男	2023-06-01 13:00:00	2023-06-02 09:00:00	2023-06-02	9999-12-31

根据以上的测试结果，我们可以得出以下结论：当涉及到更新操作时，最好的做法是先执行更新，然后再执行插入操作。这种顺序可以有效避免并发更新问题。

此外，在实时引擎中处理数据通常涉及到分布式计算，因此需要特别注意确保相同ID的数据只在一个线程中按顺序执行，而不是让执行器01执行Tony的更新操作，而执行器02执行Tony的插入操作。相反，应该将具有相同ID的数据放置在同一个执行器中执行，以确保顺序性和一致性。这对于处理并发更新场景非常重要。

四、总结

本文我们深入探讨了如何使用Apache Flink实现实时数据仓库中拉链表的同步。拉链表是一种重要的数据模型，用于跟踪数据的历史变化，以便在分析和报告中提供准确的历史视图。我们介绍了如何借助Flink以及其他相关技术构建一个强大的实时同步引擎，以应对多种数据同步场景。

我们首先介绍了传统Lambda架构到实时同步+拉链表单引擎架构它们之间的区别。随后，我们深入讨论了Flink CDC（Change Data Capture）和Doris数据库的结合使用，以实现实时数据同步的基础架构。我们详细讨论了全量同步和增量同步两种关键同步模式，以及如何应对不同的更新场景。

在全文中，强调了以下关键点：

实时同步+拉链表单引擎架构的设计和实施。
全量同步和增量同步是实时数据仓库同步的两种关键模式，详细介绍了它们的实现逻辑。
跨天更新和当天多次更新是需要特别注意的场景，提供了解决方案以确保数据的完整性。
并发更新可能导致数据重复，需要采取适当的措施来应对。

通过深入了解实时同步和拉链表的实现细节，读者可以更好地理解如何构建强大的实时数据仓库，并满足不断变化的业务需求。

五、相关资料

Doris 数据模型
MySQL CDC Connector
深入数仓离线数据同步：问题分析与优化措施

你可能感兴趣的:(大数据,实时数仓,flink,大数据,数据仓库,拉链表,doris)

数据仓库——维度表一致性墨染丶eye 背诵数据仓库
数据仓库基础笔记思维导图已经整理完毕，完整连接为：数据仓库基础知识笔记思维导图维度一致性问题从逻辑层面来看，当一系列星型模型共享一组公共维度时，所涉及的维度称为一致性维度。当维度表存在不一致时，短期的成功难以弥补长期的错误。维度时确保不同过程中信息集成起来实现横向钻取货活动的关键。造成横向钻取失败的原因维度结构的差别，因为维度的差别，分析工作涉及的领域从简单到复杂，但是都是通过复杂的报表来弥补设计
nosql数据库技术与应用知识点皆过客，揽星河 NoSQL nosql 数据库大数据数据分析数据结构非关系型数据库
Nosql知识回顾大数据处理流程数据采集(flume、爬虫、传感器)数据存储(本门课程NoSQL所处的阶段)Hdfs、MongoDB、HBase等数据清洗(入仓)Hive等数据处理、分析(Spark、Flink等)数据可视化数据挖掘、机器学习应用(Python、SparkMLlib等)大数据时代存储的挑战(三高)高并发(同一时间很多人访问)高扩展(要求随时根据需求扩展存储)高效率(要求读写速度快)
ES聚合分析原理与代码实例讲解光剑书架上的书大厂Offer收割机面试题简历程序员读书硅基计算碳基计算认知计算生物计算深度学习神经网络大数据 AIGC AGI LLM Java Python 架构设计 Agent 程序员实现财富自由
ES聚合分析原理与代码实例讲解1.背景介绍1.1问题的由来在大规模数据分析场景中，特别是在使用Elasticsearch（ES）进行数据存储和检索时，聚合分析成为了一个至关重要的功能。聚合分析允许用户对数据集进行细分和分组，以便深入探索数据的结构和模式。这在诸如实时监控、日志分析、业务洞察等领域具有广泛的应用。1.2研究现状目前，ES聚合分析已经成为现代大数据平台的核心组件之一。它支持多种类型的聚
《吹牛大王历险记》读书随笔赵炳森
这本书的作者是埃·拉斯伯戈·毕尔格。（没查到相关内容，好像他只写过《吹牛大王历险记》。）最让人百思不得其解的是他居然能自己拉自己的辫子出泥潭？！我觉得自己拉自己的辫子只会把自己的辫子拉断，而不会飞出泥潭。（问:图片中底下的屁股为什么插了一根钢针？）屁股底下居然有根钢针？在泥潭应该是滑滑的吧，可是他怎么能夹紧马肚呢？马肚子应该是在马的下方。还有如果能从泥潭里把连人带马都给拽出来的话，他力气肯定很大，
2024.8.22 Python，链表两数之和，链表快速反转，二叉树的深度，二叉树前中后序遍历，N叉树递归遍历，翻转二叉树 RaidenQ python 链表开发语言
1.链表两数之和输入：l1=[2,4,3],l2=[5,6,4]输出：[7,0,8]解释：342+465=807.示例2：输入：l1=[0],l2=[0]输出：[0]示例3：输入：l1=[9,9,9,9,9,9,9],l2=[9,9,9,9]输出：[8,9,9,9,0,0,0,1]昨天的这个题，用自己的办法写的麻烦的要死，然后刚才一看chat归类的办法，感觉自己像个智障。classListNode
[Python] 数据结构详解及代码 AIAdvocate 算法 python 数据结构链表
今日内容大纲介绍数据结构介绍列表链表1.数据结构和算法简介程序大白话翻译,程序=数据结构+算法数据结构指的是存储,组织数据的方式.算法指的是为了解决实际业务问题而思考思路和方法,就叫:算法.2.算法的5大特性介绍算法具有独立性算法是解决问题的思路和方式,最重要的是思维,而不是语言,其(算法)可以通过多种语言进行演绎.5大特性有输入,需要传入1或者多个参数有输出,需要返回1个或者多个结果有穷性,执行
WebMagic：强大的Java爬虫框架解析与实战 Aaron_945 Java java 爬虫开发语言
文章目录引言官网链接WebMagic原理概述基础使用1.添加依赖2.编写PageProcessor高级使用1.自定义Pipeline2.分布式抓取优点结论引言在大数据时代，网络爬虫作为数据收集的重要工具，扮演着不可或缺的角色。Java作为一门广泛使用的编程语言，在爬虫开发领域也有其独特的优势。WebMagic是一个开源的Java爬虫框架，它提供了简单灵活的API，支持多线程、分布式抓取，以及丰富的
windows下python opencv ffmpeg读取摄像头实现rtsp推流拉流图像处理大大大大大牛啊 opencv实战代码讲解视觉图像项目 windows python opencv
windows下pythonopencvffmpeg读取摄像头实现rtsp推流拉流整体流程1.下载所需文件1.1下载rtsp推流服务器1.2下载ffmpeg2.开启RTSP服务器3.opencv读取摄像头并调用ffmpeg进行推流4.opencv进行拉流5.opencv异步拉流整体流程1.下载所需文件1.1下载rtsp推流服务器下载RTSP服务器下载页面https://github.com/blu
免费的GPT可在线直接使用（一键收藏） kkai人工智能 gpt
1、LuminAI（https://kk.zlrxjh.top）LuminAI标志着一款融合了星辰大数据模型与文脉深度模型的先进知识增强型语言处理系统，旨在自然语言处理（NLP）的技术开发领域发光发热。此系统展现了卓越的语义把握与内容生成能力，轻松驾驭多样化的自然语言处理任务。VisionAI在NLP界的应用领域广泛，能够胜任从机器翻译、文本概要撰写、情绪分析到问答等众多任务。通过对大量文本数据的
自定义队列 junjun2018
队列：像排队吃饭一样，先到的先点菜，后来的后点菜。以下代码展示使用单向列表实现的队列。//链表是以节点为单位的，对于单向链表，每个节点中包含一个值和指向下一个对象的引用publicclassNode{Objectvalue;Nodenext;publicNode(Objectvalue){this.value=value;}publicObjectgetValue(){returnvalue;}p
《 C++ 修炼全景指南：四》揭秘 C++ List 容器背后的实现原理，带你构建自己的双向链表 Lenyiin 技术指南 C++修炼全景指南 c++list 链表 stl
本篇博客，我们将详细讲解如何从头实现一个功能齐全且强大的C++List容器，并深入到各个细节。这篇博客将包括每一步的代码实现、解释以及扩展功能的探讨，目标是让初学者也能轻松理解。一、简介1.1、背景介绍在C++中，std::list是一个基于双向链表的容器，允许高效的插入和删除操作，适用于频繁插入和删除操作的场景。与动态数组不同，list允许常数时间内的插入和删除操作，支持双向遍历。这篇文章将详细
如何利用大数据与AI技术革新相亲交友体验 h17711347205 回归算法安全系统架构交友小程序
在数字化时代，大数据和人工智能（AI）技术正逐渐革新相亲交友体验，为寻找爱情的过程带来前所未有的变革（编辑h17711347205）。通过精准分析和智能匹配，这些技术能够极大地提高相亲交友系统的效率和用户体验。大数据的力量大数据技术能够收集和分析用户的行为模式、偏好和互动数据，为相亲交友系统提供丰富的信息资源。通过分析用户的搜索历史、浏览记录和点击行为，系统能够深入了解用户的兴趣和需求，从而提供更
拉不近的距离，解不开的未知数没有故事v没有酒
《六弄咖啡馆》1.喜欢是一种能力，被喜欢是一种天赋。2.年少轻狂，我们都是这样过来的，包括暗恋。3.拉不近的距离，解不开的未知数。原来距离真的会让两个原本相爱的人越走越远，在困难面前无所适从，我需要的时候你不在，过去了，就不想再说了。这大概就是大多数异地恋最后都会分手的原因吧。《等一个人咖啡》1.咖啡店老板VS老板娘：学会放下，过去的就让它过去吧，生活还要继续。你的爱人虽然不在了，但是他一定也希望
《拖延心理学》（一）你为什么会拖延？|木盒笔记纯se蓝调
《拖延心理学》是帮助你向拖延症宣战的一本书，作者简·博克和莱诺拉·袁是全球知名的拖延症治疗专家。大概每个人或多或少总会有一点拖延症的行为。比如明天要叫论文了，今天你还没有写好，你一边在焦虑症怎么办，一边又拿着手机漫无目的的刷新闻；比如你想了很久准备减肥，但是迟迟又没有行动，想着今天晚上少吃一点吧、明天我就开始运动。今天分析的笔记来告诉你“你为什么会拖延？”，解读人杨坚。有人说拖延就像巨大的泥沼，让
康定城，一颗镶嵌在康巴藏区上的明珠，一曲《康定情歌》传唱至今蚕子桑叶
蚕子在桑叶上行走，小编在地球上旅游，嗨，大家好，我们又见面了！今天继续向大家分享我的“川西自驾游日记”。康定是甘孜州州府所在地。康定历史悠久，是川藏咽喉，茶马古道重镇，藏汉交汇中心。自古以来就是康巴藏区政治、经济、文化、商贸、信息中心和交通枢纽。康定系汉语名，因丹达山以东为“康”，取康地安定之意，故名。藏语称康定为“打折多”，意为打曲（雅拉河）、折曲（折多河）两河交汇处。这里海拔低了不少（2560
未来软件市场是怎么样的？做开发的生存空间如何？ cesske 软件需求
目录前言一、未来软件市场的发展趋势二、软件开发人员的生存空间前言未来软件市场是怎么样的？做开发的生存空间如何？一、未来软件市场的发展趋势技术趋势：人工智能与机器学习：随着技术的不断成熟，人工智能将在更多领域得到应用，如智能客服、自动驾驶、智能制造等，这将极大地推动软件市场的增长。云计算与大数据：云计算服务将继续普及，大数据技术的应用也将更加广泛。企业将更加依赖云计算和大数据来优化运营、提升效率，并
leetcode021-合并两个有序链表陆阳226
问题描述将两个升序链表合并为一个新的升序链表并返回。新链表是通过拼接给定的两个链表的所有节点组成的。示例：输入：1->2->4,1->3->4输出：1->1->2->3->4->4解答递归法：每一层减去一个较小的节点，直到某个链表为null递归结束。publicstaticListNodesolution(ListNodel1,ListNodel2){if(l1==null){returnl2;}
MySQL事务隔离级别和MVCC 简书徐小耳
MySQL事务隔离级别和MVCC参考：https://mp.weixin.qq.com/s/Jeg8656gGtkPteYWrG5_Nw1.MVCC只对读已提交和可重复的读有效果，而未提交读和串行则无意义。2.每条记录都会有trx_id(事务修改记录的id）和roll_pointer是一个指针指向旧版本的undo日志链表（row_id不是必必要的，如果有主键存在就不需要了）3.版本链的头结点就是记
app推广一手资源在哪里找？盘点2024年必备的八大app拉新渠道 U客直谈APP
在2024年即将来临之际，还是有许多小伙伴表示不知道app推广一手资源在哪里找，又要从哪里去了解各个资源渠道的不同特性。好消息来啦，本篇文章就将带大家盘点24年必备的八大app拉新渠道，全文干货，拆解分析点评一步到位，还不快快收藏起来~1.app推广一手资源来源：U客直谈U客直谈是一个资源对接平台，专注于为推广人员提供海量丰富的app拉新任务。其具有数量丰富且类型多样的app拉新任务，使得U客直谈
Hadoop架构 henan程序媛 hadoop 大数据分布式
一、案列分析1.1案例概述现在已经进入了大数据(BigData)时代，数以万计用户的互联网服务时时刻刻都在产生大量的交互，要处理的数据量实在是太大了，以传统的数据库技术等其他手段根本无法应对数据处理的实时性、有效性的需求。HDFS顺应时代出现，在解决大数据存储和计算方面有很多的优势。1.2案列前置知识点1.什么是大数据大数据是指无法在一定时间范围内用常规软件工具进行捕捉、管理和处理的大量数据集合，
[转载] NoSQL简介 weixin_30325793 大数据数据库运维
摘自“百度百科”。NoSQL，泛指非关系型的数据库。随着互联网web2.0网站的兴起，传统的关系数据库在应付web2.0网站，特别是超大规模和高并发的SNS类型的web2.0纯动态网站已经显得力不从心，暴露了很多难以克服的问题，而非关系型的数据库则由于其本身的特点得到了非常迅速的发展。NoSQL数据库的产生就是为了解决大规模数据集合多重数据种类带来的挑战，尤其是大数据应用难题。虽然NoSQL流行语
大模型训练数据库Common Crawl WindyChanChan 数据集语言模型数据库
CommonCrawl介绍‌‌CommonCrawl是一个非营利组织，致力于通过大规模分布式爬虫系统定期抓取整个Web并将其存储在一个可公开访问的数据库中。CommonCrawl的数据收集和处理过程包括使用Python开源爬虫工具收集全球范围内的网站数据，并将其上传到‌CommonCrawl基金会的数据仓库中。该项目从2008年开始，至今已经积累了大量的原始网页数据、元数据和文本提取数据。这些数据
教师资格考试中学《教育知识与能力》知识点｜高频考点汇总小山丘
温馨提示：更多汇总详情留言小编哦！！！认知过程之易混知识点剖析社会中心课程论情绪——重要考点皮亚杰教你带孩子斯金纳强化规律你的心理足够强大吗?教育心理学的效应德育有规律常考人物思想之夸美纽斯中学常考教学原则孔子及《论语》中的重要教育思想教育学创立阶段人物之赫尔巴特学习策略分类知识点梳理教师资格证辨析题作答思路综合课程的类型班杜拉的学习理论马斯洛需要层次理论记忆类型的四大分类柏拉图和他的《理想国》感
每日一题《leetcode--LCR 022.环形链表||》 Peace & Love487 题目分享 leetcode 链表算法笔记数据结构
https://leetcode.cn/problems/c32eOV/我们使用两个指针，fast与slow。它们起始都位于链表的头部。随后slow指针每次向后移动一个位置，而fast指针向后移动两个位置。如果链表中存在环，则fast指针最终将再次与slow指针在环中相遇。structListNode*detectCycle(structListNode*head){structListNode*
LCR 078. 合并 K 个升序链表装B且挨揍の LeetCode 链表算法数据结构经验分享笔记 java
https://leetcode.cn/problems/vvXgSW/description/https://leetcode.cn/problems/vvXgSW/description/解题思路方法一：每个链表维护一个索引，每次找到值最小的节点，索引加一。可以采用优先队列实现。/***Definitionforsingly-linkedlist.*publicclassListNode{*i
数组模拟单链表 Star_. 蓝桥杯 java 数据结构链表
实现一个单链表，链表初始为空，支持三种操作：向链表头插入一个数；删除第k个插入的数后面的数；在第k个插入的数后插入一个数。现在要对该链表进行M次操作，进行完所有操作后，从头到尾输出整个链表。注意:题目中第k个插入的数并不是指当前链表的第k个数。例如操作过程中一共插入了n个数，则按照插入的时间顺序，这n个数依次为：第1个插入的数，第2个插入的数，…第n个插入的数。输入格式第一行包含整数M，表示操作次
Kafka详细解析与应用分析芊言芊语 kafka 分布式
Kafka是一个开源的分布式事件流平台（EventStreamingPlatform），由LinkedIn公司最初采用Scala语言开发，并基于ZooKeeper协调管理。如今，Kafka已经被Apache基金会纳入其项目体系，广泛应用于大数据实时处理领域。Kafka凭借其高吞吐量、持久化、分布式和可靠性的特点，成为构建实时流数据管道和流处理应用程序的重要工具。Kafka架构Kafka的架构主要由
转班遇上星期六凝结的海
晚上上班的时候，我感觉有点饿，就在十点五左右去食堂，看看有没有什么吃的，一路上同事们都在说可能已经关门了，走快一点或许能碰得到。庆幸的是我到了他还没来得及关，我买了一个粽子和一个咸鸭蛋，总共花了四块三，总感觉比外面卖的要贵的多。后来我在三点多近四点的时候，我和三号前化料的一起去保安室拉了一大车水，我们装好之后，我让他先拉到我的岗位上，我去拉点原材料。他把水拉走之后我就出去把充电动车的电拔掉，又到路
分享一个基于python的电子书数据采集与可视化分析 hadoop电子书数据分析与推荐系统 spark大数据毕设项目（源码、调试、LW、开题、PPT) 计算机源码社 Python项目大数据大数据 python hadoop 计算机毕业设计选题计算机毕业设计源码数据分析 spark毕设
作者：计算机源码社个人简介：本人八年开发经验，擅长Java、Python、PHP、.NET、Node.js、Android、微信小程序、爬虫、大数据、机器学习等，大家有这一块的问题可以一起交流！学习资料、程序开发、技术解答、文档报告如需要源码，可以扫取文章下方二维码联系咨询Java项目微信小程序项目Android项目Python项目PHP项目ASP.NET项目Node.js项目选题推荐项目实战|p
疫情，疫情东山草
2020年，疫情爆发，至今已近三年，反反复复，此起彼伏。不但没被消灭，还自我发展，从德尔塔到奥密克戎，与时俱进的变异着。去年11月，疫情之下，大数据800米范围内，都成为时空伴随者。“你的码儿有没有变颜色”“你绿码还是黄码”成为那段时间的流行语，当然少不了的还有全员核酸。段子手整出来一首歌：我走过你走过的路,这算不算相逢？我吹过你吹过的风，这算不算相拥？800米内我们不曾擦肩而过，你却要我14天相
Java 并发包之线程池和原子计数 lijingyao8206 Java计数 ThreadPool 并发包 java线程池
对于大数据量关联的业务处理逻辑，比较直接的想法就是用JDK提供的并发包去解决多线程情况下的业务数据处理。线程池可以提供很好的管理线程的方式，并且可以提高线程利用率，并发包中的原子计数在多线程的情况下可以让我们避免去写一些同步代码。这里就先把jdk并发包中的线程池处理器ThreadPoolExecutor 以原子计数类AomicInteger 和倒数计时锁C
java编程思想抽象类和接口百合不是茶 java 抽象类接口
接口c++对接口和内部类只有简介的支持,但在java中有队这些类的直接支持 1 ,抽象类 : 如果一个类包含一个或多个抽象方法,该类必须限定为抽象类(否者编译器报错) 抽象方法 : 在方法中仅有声明而没有方法体 package com.wj.Interface;
[房地产与大数据]房地产数据挖掘系统 comsci 数据挖掘
随着一个关键核心技术的突破,我们已经是独立自主的开发某些先进模块,但是要完全实现,还需要一定的时间... 所以,除了代码工作以外,我们还需要关心一下非技术领域的事件..比如说房地产 &nb
数组队列总结沐刃青蛟数组队列
数组队列是一种大小可以改变，类型没有定死的类似数组的工具。不过与数组相比，它更具有灵活性。因为它不但不用担心越界问题，而且因为泛型（类似c++中模板的东西）的存在而支持各种类型。以下是数组队列的功能实现代码： import List.Student; public class
Oracle存储过程无法编译的解决方法 IT独行者 oracle 存储过程　
今天同事修改Oracle存储过程又导致2个过程无法被编译，流程规范上的东西，Dave 这里不多说，看看怎么解决问题。 1. 查看无效对象 XEZF@xezf(qs-xezf-db1)> select object_name,object_type,status from all_objects where status='IN
重装系统之后oracle恢复文强chu oracle
前几天正在使用电脑，没有暂停oracle的各种服务。突然win8.1系统奔溃，无法修复，开机时系统提示正在搜集错误信息，然后再开机，再提示的无限循环中。无耐我拿出系统u盘准备重装系统，没想到竟然无法从u盘引导成功。晚上到外面早了一家修电脑店，让人家给装了个系统，并且那哥们在我没反应过来的时候，直接把我的c盘给格式化了并且清理了注册表，再装系统。然后的结果就是我的oracl
python学习二（一些基础语法）小桔子 pthon 基础语法
紧接着把！昨天没看继续看django 官方教程，学了下python的基本语法与c类语言还是有些小差别： 1.ptyhon的源文件以UTF-8编码格式 2. / 除结果浮点型 // 除结果整形 % 除取余数 * 乘 ** 乘方 eg 5**2 结果是5的2次方25 _&
svn 常用命令 aichenglong SVN 版本回退
1 svn回退版本 1)在window中选择log,根据想要回退的内容,选择revert this version或revert chanages from this version 两者的区别: revert this version:表示回退到当前版本(该版本后的版本全部作废) revert chanages from this versio
某小公司面试归来 alafqq 面试
先填单子，还要写笔试题，我以时间为急，拒绝了它。。时间宝贵。老拿这些对付毕业生的东东来吓唬我。。面试官很刁难，问了几个问题，记录下； 1，包的范围。。。public,private,protect. --悲剧了 2，hashcode方法和equals方法的区别。谁覆盖谁.结果，他说我说反了。 3，最恶心的一道题，抽象类继承抽象类吗？（察，一般它都是被继承的啊） 4，stru
动态数组的存储速度比较集合框架百合不是茶集合框架
集合框架：自定义数据结构(增删改查等) package 数组; /** * 创建动态数组 * @author 百合 * */ public class ArrayDemo{ //定义一个数组来存放数据 String[] src = new String[0]; /** * 增加元素加入容器 * @param s要加入容器
用JS实现一个JS对象，对象里有两个属性一个方法 bijian1013 js对象
<html> <head> </head> <body> 用js代码实现一个js对象，对象里有两个属性，一个方法 </body> <script> var obj={a:'1234567',b:'bbbbbbbbbb',c:function(x){
探索JUnit4扩展：使用Rule bijian1013 java 单元测试 JUnit Rule
在上一篇文章中，讨论了使用Runner扩展JUnit4的方式，即直接修改Test Runner的实现(BlockJUnit4ClassRunner)。但这种方法显然不便于灵活地添加或删除扩展功能。下面将使用JUnit4.7才开始引入的扩展方式——Rule来实现相同的扩展功能。 1. Rule &n
[Gson一]非泛型POJO对象的反序列化 bit1129 POJO
当要将JSON数据串反序列化自身为非泛型的POJO时，使用Gson.fromJson(String, Class)方法。自身为非泛型的POJO的包括两种： 1. POJO对象不包含任何泛型的字段 2. POJO对象包含泛型字段，例如泛型集合或者泛型类 Data类 a.不是泛型类， b.Data中的集合List和Map都是泛型的 c.Data中不包含其它的POJO
【Kakfa五】Kafka Producer和Consumer基本使用 bit1129 kafka
0.Kafka服务器的配置一个Broker，一个Topic Topic中只有一个Partition（） 1. Producer： package kafka.examples.producers; import kafka.producer.KeyedMessage; import kafka.javaapi.producer.Producer; impor
lsyncd实时同步搭建指南——取代rsync+inotify ronin47
1. 几大实时同步工具比较 1.1 inotify + rsync 最近一直在寻求生产服务服务器上的同步替代方案，原先使用的是 inotify + rsync，但随着文件数量的增大到100W+，目录下的文件列表就达20M，在网络状况不佳或者限速的情况下，变更的文件可能10来个才几M，却因此要发送的文件列表就达20M，严重减低的带宽的使用效率以及同步效率；更为要紧的是，加入inotify
java-9. 判断整数序列是不是二元查找树的后序遍历结果 bylijinnan java
public class IsBinTreePostTraverse{ static boolean isBSTPostOrder(int[] a){ if(a==null){ return false; } /*1.只有一个结点时，肯定是查找树 *2.只有两个结点时，肯定是查找树。例如{5,6}对应的BST是 6 {6,5}对应的BST是
MySQL的sum函数返回的类型 bylijinnan java spring sql mysql jdbc
今天项目切换数据库时，出错访问数据库的代码大概是这样： String sql = "select sum(number) as sumNumberOfOneDay from tableName"; List<Map> rows = getJdbcTemplate().queryForList(sql); for (Map row : rows
java设计模式之单例模式 chicony java设计模式
在阎宏博士的《JAVA与模式》一书中开头是这样描述单例模式的：　　作为对象的创建模式，单例模式确保某一个类只有一个实例，而且自行实例化并向整个系统提供这个实例。这个类称为单例类。单例模式的结构　　单例模式的特点：单例类只能有一个实例。单例类必须自己创建自己的唯一实例。单例类必须给所有其他对象提供这一实例。　　饿汉式单例类 publ
javascript取当月最后一天 ctrain JavaScript
 <script language=javascript> var current = new Date(); var year = current.getYear(); var month = current.getMonth(); showMonthLastDay(year, mont
linux tune2fs命令详解 daizj linux tune2fs 查看系统文件块信息
一.简介： tune2fs是调整和查看ext2/ext3文件系统的文件系统参数，Windows下面如果出现意外断电死机情况，下次开机一般都会出现系统自检。Linux系统下面也有文件系统自检，而且是可以通过tune2fs命令，自行定义自检周期及方式。二.用法： Usage: tune2fs [-c max_mounts_count] [-e errors_behavior] [-g grou
做有中国特色的程序员 dcj3sjt126com 程序员
从出版业说起网络作品排到靠前的，都不会太难看，一般人不爱看某部作品也是因为不喜欢这个类型，而此人也不会全不喜欢这些网络作品。究其原因，是因为网络作品都是让人先白看的，看的好了才出了头。而纸质作品就不一定了，排行榜靠前的，有好作品，也有垃圾。许多大牛都是写了博客，后来出了书。这些书也都不次，可能有人让为不好，是因为技术书不像小说，小说在读故事，技术书是在学知识或温习知识，有
Android：TextView属性大全 dcj3sjt126com textview
android:autoLink 设置是否当文本为URL链接/email/电话号码/map时，文本显示为可点击的链接。可选值(none/web/email/phone/map/all) android:autoText 如果设置，将自动执行输入值的拼写纠正。此处无效果，在显示输入法并输
tomcat虚拟目录安装及其配置 eksliang tomcat配置说明 tomca部署web应用 tomcat虚拟目录安装
转载请出自出处：http://eksliang.iteye.com/blog/2097184 1.-------------------------------------------tomcat 目录结构 config：存放tomcat的配置文件 temp ：存放tomcat跑起来后存放临时文件用的 work ：当第一次访问应用中的jsp
浅谈：APP有哪些常被黑客利用的安全漏洞 gg163 APP
首先，说到APP的安全漏洞，身为程序猿的大家应该不陌生；如果抛开安卓自身开源的问题的话，其主要产生的原因就是开发过程中疏忽或者代码不严谨引起的。但这些责任也不能怪在程序猿头上，有时会因为BOSS时间催得紧等很多可观原因。由国内移动应用安全检测团队爱内测（ineice.com）的CTO给我们浅谈关于Android 系统的开源设计以及生态环境。 1. 应用反编译漏洞：APK 包非常容易被反编译成可读
C#根据网址生成静态页面 hvt Web .net C#asp.net hovertree
HoverTree开源项目中HoverTreeWeb.HVTPanel的Index.aspx文件是后台管理的首页。包含生成留言板首页，以及显示用户名，退出等功能。根据网址生成页面的方法： bool CreateHtmlFile(string url, string path) { //http://keleyi.com/a/bjae/3d10wfax.htm stri
SVG 教程（一）天梯梦 svg
SVG 简介 SVG 是使用 XML 来描述二维图形和绘图程序的语言。学习之前应具备的基础知识：继续学习之前，你应该对以下内容有基本的了解： HTML XML 基础如果希望首先学习这些内容，请在本站的首页选择相应的教程。什么是SVG？ SVG 指可伸缩矢量图形 (Scalable Vector Graphics) SVG 用来定义用于网络的基于矢量
一个简单的java栈 luyulong java 数据结构栈
public class MyStack { private long[] arr; private int top; public MyStack() { arr = new long[10]; top = -1; } public MyStack(int maxsize) { arr = new long[maxsize]; top
基础数据结构和算法八：Binary search sunwinner Algorithm Binary search
Binary search needs an ordered array so that it can use array indexing to dramatically reduce the number of compares required for each search, using the classic and venerable binary search algori
12个C语言面试题，涉及指针、进程、运算、结构体、函数、内存，看看你能做出几个！刘星宇 c 面试
12个C语言面试题，涉及指针、进程、运算、结构体、函数、内存，看看你能做出几个！ 1.gets()函数问：请找出下面代码里的问题： #include<stdio.h> int main(void) { char buff[10]; memset(buff,0,sizeof(buff));
ITeye 7月技术图书有奖试读获奖名单公布 ITeye管理员活动 ITeye 试读
ITeye携手人民邮电出版社图灵教育共同举办的7月技术图书有奖试读活动已圆满结束，非常感谢广大用户对本次活动的关注与参与。 7月试读活动回顾： http://webmaster.iteye.com/blog/2092746 本次技术图书试读活动的优秀奖获奖名单及相应作品如下（优秀文章有很多，但名额有限，没获奖并不代表不优秀）：《Java性能优化权威指南》