15.2.txt

1
00:00:00,090 --> 00:00:05,400
嗯嗯嗯嗯嗯嗯嗯

2
00:00:14,310 --> 00:00:17,070
先看比如那个四试题的同学，大家好

3
00:00:17,640 --> 00:00:20,610
今天我来讲一下他不但是原理

4
00:00:22,830 --> 00:00:28,140
首先，我叫马小宇，我是新开的AP团队的负责人曾就

5
00:00:28,145 --> 00:00:31,170
由于网页行员担任百度不足的负责人

6
00:00:31,290 --> 00:00:33,630
2017年加入平台

7
00:00:33,990 --> 00:00:37,770
参与平开派d pola产品的研发工作

8
00:00:37,920 --> 00:00:41,940
主要研究方向是大数据，分布式系统和数据库

9
00:00:45,330 --> 00:00:46,710
课程概要

10
00:00:46,980 --> 00:00:48,450
课程背景

11
00:00:48,455 --> 00:00:53,760
Itv作为面向HTC的数据库，能够同时支撑o labor tp凉

12
00:00:53,765 --> 00:00:54,600
业务

13
00:00:54,870 --> 00:00:57,000
而太不安是专门

14
00:00:57,005 --> 00:01:00,990
I敌敌畏了，OLAP，场景打造的存储引擎

15
00:01:01,350 --> 00:01:04,200
将于他离婚，40，同步发布

16
00:01:04,890 --> 00:01:08,670
但是有着与KTV截然不同的设计理念

17
00:01:08,760 --> 00:01:12,390
但他又统一在泰迪熊的全局架构之下

18
00:01:13,170 --> 00:01:14,400
学习目标

19
00:01:14,940 --> 00:01:19,620
今天将带着大家了解太烂时的设计理念和架构

20
00:01:19,800 --> 00:01:22,560
吉他是如何服务于OLED井的？

21
00:01:23,430 --> 00:01:24,480
受众

22
00:01:24,510 --> 00:01:27,810
本科城市和有一定债利率基础的学员

23
00:01:27,870 --> 00:01:29,880
时长为45分钟

24
00:01:30,930 --> 00:01:32,310
完整知识点

25
00:01:32,640 --> 00:01:34,740
OLED的厂景和特征

26
00:01:35,040 --> 00:01:36,870
看出来时的架构原理

27
00:01:36,900 --> 00:01:38,430
而是太多的雏形

28
00:01:42,390 --> 00:01:45,060
第一部分，后来场景特征

29
00:01:46,320 --> 00:01:50,490
在这里，我们将大家看一下一个数据平台的架构

30
00:01:51,120 --> 00:01:53,640
偶尔tp和阿拉伯区别

31
00:01:54,060 --> 00:01:56,610
以及当前后来方案存在的问题

32
00:01:59,550 --> 00:02:01,380
联想的数据平台

33
00:02:01,410 --> 00:02:05,370
首先我们看一下，这是一个大家心目中理想的数据平台

34
00:02:06,900 --> 00:02:10,590
应用APP或者其他数据入口直接进入数据库

35
00:02:11,340 --> 00:02:16,650
而这个数据库，也可以同时提供BI或者同时提供其他的数据业务服务

36
00:02:18,150 --> 00:02:20,520
这其实是早些年

37
00:02:21,120 --> 00:02:23,010
数据库架构的经典

38
00:02:23,610 --> 00:02:26,490
那个时候并没有那么多复杂的数据库架构

39
00:02:26,520 --> 00:02:30,390
并没有能随口，也没有分析型数据库，也没有百度

40
00:02:31,200 --> 00:02:32,130
所以

41
00:02:32,250 --> 00:02:36,840
传统的数据库可以打遍天下，使用，任何使用在任何场景上

42
00:02:40,380 --> 00:02:43,170
而现在实际的数据架构是这样子

43
00:02:43,920 --> 00:02:46,980
你的业务也许一开始只使用一套数据库

44
00:02:47,070 --> 00:02:48,300
不管是

45
00:02:48,420 --> 00:02:53,130
Tp，还是AP，不管是报表还是网站，全都接入，在这个数据库

46
00:02:53,550 --> 00:02:58,800
但是当时当你的数据业务不断增长，你的数据量不断扩大的时候

47
00:02:59,160 --> 00:03:03,990
的业务不断变得更严谨，你这时候会数据平台变得越来越复杂

48
00:03:05,070 --> 00:03:10,020
原来你把所有东西都介入在同一个数据库上，现在你会必须要拆分

49
00:03:10,200 --> 00:03:15,510
你的数据库可能是首先有2 tp层的数据库，这是在线业务直接介入的层面

50
00:03:16,770 --> 00:03:18,720
而偶尔gp数据库

51
00:03:18,750 --> 00:03:20,520
需要到分析的时候

52
00:03:20,610 --> 00:03:24,480
必须通过一条转入到其他的对他外号组建当中

53
00:03:24,660 --> 00:03:28,260
这里有可能是太有可能是百度，或者是爸爸的伤害的

54
00:03:28,890 --> 00:03:30,840
也有可能是分析数据库

55
00:03:30,960 --> 00:03:35,130
而他们会提供你的BI或者20号查询或者其他的数据业务

56
00:03:38,670 --> 00:03:39,960
为什么这样子呢？

57
00:03:42,120 --> 00:03:47,070
数据库变得越来越复杂，并不是说数据库的制造者不够有能力

58
00:03:47,190 --> 00:03:50,160
而是说tp和AP两种

59
00:03:50,165 --> 00:03:53,670
不同场景的数据库制造的理念是不同的

60
00:03:59,220 --> 00:04:02,610
做一个htp场景的基本矛盾有这样

61
00:04:03,030 --> 00:04:04,770
首先是访问模式

62
00:04:05,430 --> 00:04:07,110
OT p的数据库

63
00:04:08,310 --> 00:04:13,620
对优化行为是短查询优化，检查优化和少量的少量

64
00:04:13,625 --> 00:04:15,000
整整行读取

65
00:04:17,010 --> 00:04:20,040
所以他使用的存储格式是行存格式

66
00:04:20,430 --> 00:04:22,200
啊偶尔一个数据库

67
00:04:22,205 --> 00:04:27,510
面向的是长查询批量处理大批量的行扫描，少量的列

68
00:04:28,290 --> 00:04:30,810
所以他们基本都使用列存的格式

69
00:04:31,890 --> 00:04:33,480
而另一个矛盾是

70
00:04:34,290 --> 00:04:38,190
和SAP业务和2G p业务互相之间会有很大的干扰

71
00:04:39,690 --> 00:04:45,000
AP，业务的理念是使用最大的资源量，尽快地将查询完成

72
00:04:45,120 --> 00:04:48,360
而tp的业务希望就是说近小的波动

73
00:04:48,600 --> 00:04:53,220
所以两者放在一起进行工作的时候，会互相之间影响

74
00:04:57,930 --> 00:04:58,530
我觉得

75
00:04:59,610 --> 00:05:01,470
当前流行的方案

76
00:05:01,620 --> 00:05:03,540
使用不同种类的数据库

77
00:05:03,570 --> 00:05:05,430
这是一个基本的方案

78
00:05:05,880 --> 00:05:11,190
比如说使用偶尔tp类型的数据库MySQL oracle或者其他类型的数据库

79
00:05:11,850 --> 00:05:13,950
来处理在线交易型业务

80
00:05:15,420 --> 00:05:17,370
而你使用分析的时候

81
00:05:17,460 --> 00:05:20,160
需要把这些数据导出到另外的人

82
00:05:20,220 --> 00:05:23,070
架构上，比如说现在流行的海渡

83
00:05:23,580 --> 00:05:25,170
或者分析型数据库

84
00:05:27,150 --> 00:05:31,020
那整个物理层面数据是分离的

85
00:05:31,470 --> 00:05:33,600
所以你需要用一条

86
00:05:33,840 --> 00:05:37,290
将交易数据迁移到海璐或者分析数据库

87
00:05:37,800 --> 00:05:43,110
这个迁移过程一般是定期的，比如说每天每月或者再短一点每小时

88
00:05:47,820 --> 00:05:48,420
我想听

89
00:05:50,400 --> 00:05:51,780
这样的架构

90
00:05:51,840 --> 00:05:53,820
相对来说会比较复杂

91
00:05:54,660 --> 00:05:58,170
你需要使用不同的组件，应对不同的任务

92
00:05:59,340 --> 00:06:02,070
而不同的组件与笑不同的人来维护

93
00:06:02,610 --> 00:06:07,920
所以有的时候你可能会希望说，如果我能使用同一套组件或者同一个瓶

94
00:06:07,925 --> 00:06:08,700
你猜

95
00:06:08,705 --> 00:06:11,640
完成这所有的任务，是不是会更方便一点？

96
00:06:14,430 --> 00:06:15,690
实时性

97
00:06:16,440 --> 00:06:20,100
由于数据需要在不同的平台之间互相导来的

98
00:06:22,800 --> 00:06:24,090
实时性

99
00:06:24,180 --> 00:06:27,210
由于数据需要在不同的平台之间

100
00:06:27,330 --> 00:06:29,130
做一条导入导出

101
00:06:30,150 --> 00:06:35,460
所以你实际拿到数据，能够查询的状态已经不是最新鲜的数据了

102
00:06:36,330 --> 00:06:38,820
如果我希望查询最新鲜的数据

103
00:06:38,970 --> 00:06:43,470
那么肯定是在数据生产的地方直接查询是最为便捷的

104
00:06:46,710 --> 00:06:47,760
一致性

105
00:06:49,440 --> 00:06:52,530
数据在易购的数据平台之间流动

106
00:06:52,680 --> 00:06:55,500
数据的一致性是很难达到保证呢？

107
00:06:55,560 --> 00:06:56,460
例如

108
00:06:56,730 --> 00:06:58,080
我转账

109
00:06:58,140 --> 00:07:01,080
减减少钱，对方增加前的状态

110
00:07:01,085 --> 00:07:06,000
在数据导出的时候，很难达到一个平衡很难达到一个一致性的保证

111
00:07:06,570 --> 00:07:11,880
也许你在数据平台之间分析的数据并不能完整的保证说我的存在

112
00:07:11,885 --> 00:07:13,980
莼交易是完整落地的

113
00:07:14,610 --> 00:07:19,230
而是你可能搜索到一个我少了钱，但是他没有多钱的状态

114
00:07:23,940 --> 00:07:24,540
我不知道

115
00:07:25,770 --> 00:07:29,550
第二部分我们讲一下探探认识的战斗原理

116
00:07:30,330 --> 00:07:32,760
这部分包含他虽然是战斗

117
00:07:32,820 --> 00:07:34,560
场存和内存的区别

118
00:07:34,890 --> 00:07:37,500
数量级的数据同步是如何实现的？

119
00:07:37,650 --> 00:07:40,770
而在此之上，我们又是如何实现强一致？

120
00:07:41,370 --> 00:07:43,350
水平扩展是如何实现？

121
00:07:44,010 --> 00:07:45,120
业务隔离

122
00:07:46,590 --> 00:07:48,510
以及高度整合的状态

123
00:07:49,350 --> 00:07:52,020
另外是APP的支持以及性能

124
00:07:56,430 --> 00:07:57,750
看不上甘肃

125
00:07:59,040 --> 00:08:01,560
酞普兰氏是泰迪比较裂成引擎

126
00:08:02,790 --> 00:08:06,000
它支持内存存储也支持向量化计算

127
00:08:08,520 --> 00:08:11,910
它使用扩展的大的共识算法做数据同步

128
00:08:11,940 --> 00:08:17,250
这样才能达到强一致，而且使用非常小的开销，对gp基本不造成

129
00:08:17,255 --> 00:08:18,480
多少压力？

130
00:08:20,220 --> 00:08:25,530
另外，它有严格的任务隔离，因为他使用了一组不同的物理节点，因此她在

131
00:08:25,535 --> 00:08:29,070
进行查询的时候并不会使tp业务受到阻塞

132
00:08:29,310 --> 00:08:31,440
或者受到波动干扰

133
00:08:33,780 --> 00:08:36,180
同时，它也与泰迪的高度整合

134
00:08:36,600 --> 00:08:40,710
如果你并不希望完全隔离的话，你可以使用整合的形态

135
00:08:40,830 --> 00:08:45,120
这样子的形态底下，他和太太必须使用同样的同样的地位

136
00:08:45,210 --> 00:08:48,450
你可以同时在查询当中访问缓存和内存

137
00:08:51,150 --> 00:08:53,310
现在我们来看一下KB b的价格

138
00:08:55,650 --> 00:08:58,020
经典的泰利宾价格分成两层

139
00:08:58,170 --> 00:09:02,340
上层是计算层，包含泰迪b和太极8和2种组件

140
00:09:02,610 --> 00:09:04,830
下层是继AKB存储层

141
00:09:05,460 --> 00:09:07,110
而存储的数据

142
00:09:07,950 --> 00:09:09,780
国际单元是锐阵

143
00:09:10,740 --> 00:09:14,550
鱼卷和瑞士之间组成了连续的数据段

144
00:09:16,290 --> 00:09:19,050
而于正本身会有多个副本

145
00:09:19,200 --> 00:09:20,550
在这张图上

146
00:09:20,940 --> 00:09:23,070
如荼如云正式

147
00:09:23,220 --> 00:09:24,510
还有三个副本

148
00:09:24,515 --> 00:09:27,300
这三个副本是由@串联的

149
00:09:32,010 --> 00:09:32,610
不知道

150
00:09:35,490 --> 00:09:37,710
泰迪宾加上泰斯拉史的架构

151
00:09:38,580 --> 00:09:42,840
我们再来看一下泰泰迪迪，如果加上态度，按时节点的架构会是什么样子？

152
00:09:44,340 --> 00:09:49,650
在这个架构下，上层仍然是同样的计算层，包含泰迪币和泰迪帕克两种

153
00:09:50,460 --> 00:09:53,610
而下层多了一种角色，就是他不按时节点

154
00:09:54,240 --> 00:09:59,040
数据仍然使用为准，加上娜娜的方式进行串联

155
00:09:59,760 --> 00:10:02,040
而在有弗兰克的情况底下

156
00:10:02,520 --> 00:10:06,810
每个抑郁症都可以使用大富翁的进行一份数据同步

157
00:10:06,930 --> 00:10:10,710
这份数据同步会传输数据到探负29点

158
00:10:10,770 --> 00:10:13,170
而她出来时节点会将数据

159
00:10:13,290 --> 00:10:14,520
拆分成列

160
00:10:15,000 --> 00:10:16,440
存到磁盘上

161
00:10:20,250 --> 00:10:25,500
大家可以看到说炭黑冰节点跟碳酸节点是两组不同的物理节点

162
00:10:25,620 --> 00:10:30,930
因此，在查询的时候，你可以选择使用炭，可以解点，还是使用type ii节点

163
00:10:31,710 --> 00:10:37,020
如果你需要高隔离性，那么你可以设置为只查询态度，按时节点

164
00:10:37,025 --> 00:10:38,760
而不影响它可以一点点

165
00:10:39,060 --> 00:10:43,200
如果你希望更便捷，只是希望提供更高效的读取

166
00:10:43,205 --> 00:10:48,000
那你可以同时提供他不但是他可以给你解决和他们来解决共同

167
00:10:48,060 --> 00:10:49,290
服务于查询

168
00:10:54,000 --> 00:10:54,600
我不知道

169
00:10:54,605 --> 00:10:56,370
看不出是引擎的架构

170
00:10:56,790 --> 00:11:00,480
这是他发来的是引擎单一进程级别的架构

171
00:11:01,230 --> 00:11:06,030
左边是泰KTV，右边是太太太，写点这是一个对比的图

172
00:11:06,090 --> 00:11:09,390
大家可以看到说两边的架构是非常类似的

173
00:11:10,200 --> 00:11:14,580
最大的区别是它开始节点是需要将行转为列

174
00:11:14,820 --> 00:11:20,130
转换的过程当中太重要节点，需要使用手机嘛，也就是一张表

175
00:11:20,135 --> 00:11:23,850
里面有多少字段，每个字段分别是什么样的类型？

176
00:11:24,030 --> 00:11:25,770
而有了这样的信息

177
00:11:25,775 --> 00:11:29,550
看出来，职业点在接受到委托人的同步数据之后

178
00:11:29,610 --> 00:11:34,920
将会拆分，根据CD码，然后把数据拆成一列一列存档的怎么？

179
00:11:34,925 --> 00:11:35,700
很少

180
00:11:36,660 --> 00:11:40,380
其他的架构基本都和范冰冰非常非常类似

181
00:11:40,770 --> 00:11:43,410
另外一个区别是在读取的时候

182
00:11:44,040 --> 00:11:46,350
派饭时节点会根据

183
00:11:46,620 --> 00:11:48,000
读取的请求

184
00:11:48,150 --> 00:11:49,170
发送

185
00:11:49,230 --> 00:11:54,540
对应的love sports，然后再由伦伦伦伦跑步，可以转发到对应的离解决

186
00:11:54,545 --> 00:11:55,170
点点

187
00:11:55,350 --> 00:11:59,400
这样子可以完成人人瑞的细节，会在后面继续说

188
00:12:04,110 --> 00:12:04,710
我想想

189
00:12:06,090 --> 00:12:09,420
现在我们来探讨一下航程和内存之间的区别

190
00:12:09,960 --> 00:12:13,440
长城是偶尔tp多年来最佳实践

191
00:12:15,330 --> 00:12:20,190
它能很方便的快速定位某一个行，也能支持，很好地整行存取

192
00:12:20,580 --> 00:12:23,700
而不至于l或者mo非常多

193
00:12:24,060 --> 00:12:27,810
但这样子的方式，对于o IP场景并不是非常友好

194
00:12:28,320 --> 00:12:29,400
排列成

195
00:12:29,580 --> 00:12:31,410
正式和RAP场景

196
00:12:32,580 --> 00:12:37,890
他也天然地支持向量化处理，能更好的利用CPU以及有更加的看看了

197
00:12:37,895 --> 00:12:38,670
开了几？

198
00:12:39,300 --> 00:12:41,310
它也支持非常好的压缩

199
00:12:41,820 --> 00:12:42,900
可以在

200
00:12:42,990 --> 00:12:45,840
还有使用率上得到很好的提升

201
00:12:46,800 --> 00:12:48,510
但是他的问题是

202
00:12:48,570 --> 00:12:53,460
由于列和列同一行的列和列之间的数据并不是连续排布的

203
00:12:53,490 --> 00:12:57,450
因此，进行整形的随机访问，或者进行短小的查询

204
00:12:57,455 --> 00:12:59,280
会有更多的磁盘搜索

205
00:13:03,990 --> 00:13:07,470
这张图左边是杭城，右边是列存

206
00:13:08,340 --> 00:13:13,110
当然可以认为银行存的数据就是以航为单位连续排布

207
00:13:13,920 --> 00:13:15,540
对于左边这张图

208
00:13:15,780 --> 00:13:19,770
所畏寒为单位连续排布的意思就是银行的数据

209
00:13:19,800 --> 00:13:24,030
0962，接下去马上会存银行的名字

210
00:13:24,240 --> 00:13:28,410
这样然后马上会存滴航的a30

211
00:13:28,440 --> 00:13:30,780
然后再存放的是第二行的数据

212
00:13:31,200 --> 00:13:35,160
以这种方式，一行银行连续排布存放就是行存

213
00:13:36,120 --> 00:13:38,700
右下角的数据是内存的排布

214
00:13:39,930 --> 00:13:44,070
这样才能排布，也就是说你会一定数量的行

215
00:13:45,450 --> 00:13:47,070
存放为一个处

216
00:13:47,550 --> 00:13:50,730
然后这个醋的数据，或者这个组的数据

217
00:13:51,720 --> 00:13:53,610
是以列为单位切割

218
00:13:54,870 --> 00:13:58,920
相对这张示意图上，我们是以四行数据为一组

219
00:13:59,310 --> 00:14:04,620
这组数据会以列的方式进行切割，也就是说，首先会存放IP的数据

220
00:14:05,760 --> 00:14:08,340
第一条第一行的IP数据09

221
00:14:08,400 --> 00:14:13,710
二二，然后紧接着就存放第二行的数，第二行二第六数据7658第四

222
00:14:13,715 --> 00:14:15,150
三行第四行

223
00:14:15,510 --> 00:14:17,610
接着再试存放名字

224
00:14:18,060 --> 00:14:19,950
症状正

225
00:14:20,310 --> 00:14:22,110
然后再存放的是a制

226
00:14:22,650 --> 00:14:25,500
大家可以看一下右上角这样的一个查询

227
00:14:25,560 --> 00:14:27,780
It avon tee se不让

228
00:14:27,810 --> 00:14:28,890
Pp表

229
00:14:29,550 --> 00:14:34,020
这样的一个查询止访问了整张表三个裂当中的一个列

230
00:14:34,620 --> 00:14:38,220
那么多人行存来说，它需要访问所有的数据

231
00:14:38,640 --> 00:14:40,290
而作为列车来说

232
00:14:40,295 --> 00:14:42,480
她只需要访问控制那一列

233
00:14:42,510 --> 00:14:44,820
连续读取就可以完成查询

234
00:14:47,220 --> 00:14:50,850
这是行存和内存在l效率上的基本区别人

235
00:14:55,560 --> 00:14:56,160
我不知道

236
00:14:57,540 --> 00:14:59,160
现在我们看一下

237
00:14:59,280 --> 00:15:02,400
碳酸是实现叶醇和

238
00:15:03,090 --> 00:15:07,200
TIka，实现行存的具体数据结构也是有不同的

239
00:15:09,300 --> 00:15:11,430
Tak t使用的是二三十岁

240
00:15:12,390 --> 00:15:15,210
而泰flash使用的是只要他妹子

241
00:15:16,050 --> 00:15:18,690
条件是一个很经典的数据结构

242
00:15:19,740 --> 00:15:21,990
他能非常快乐，支持写入

243
00:15:22,050 --> 00:15:23,880
但是在范围扫描

244
00:15:23,910 --> 00:15:25,710
却并不是非常有优势

245
00:15:26,850 --> 00:15:29,490
这里的原因是然后上面说的

246
00:15:29,790 --> 00:15:32,490
数据被分成不同的行不同的层

247
00:15:33,060 --> 00:15:35,130
而层和层之间的数据

248
00:15:35,760 --> 00:15:37,080
是欧巴love的

249
00:15:37,650 --> 00:15:41,670
也就是说，如果你需要完整扫描一个数据段

250
00:15:41,880 --> 00:15:45,390
这个数据段的数据有可能会分布在各个层

251
00:15:46,110 --> 00:15:49,590
而各个层之间的数据还会有重复

252
00:15:49,650 --> 00:15:53,340
而不同的版本之间，你需要做铁需需要做折叠

253
00:15:55,800 --> 00:16:01,110
要完成这样一个操作，你必须把所有层之间进行一个多六规定，然后你们

254
00:16:01,115 --> 00:16:05,250
才能选出所有的数据，并且版本是你需要的版本

255
00:16:06,210 --> 00:16:08,610
这样子的一个操作是非常重的操作

256
00:16:09,120 --> 00:16:11,400
而这样的数据结构在

257
00:16:12,270 --> 00:16:15,480
CP，查询当中并不是一个非常合适的设计

258
00:16:15,720 --> 00:16:21,030
所以看出来是这边采用了不同的数据结构，也就是说是主流的表达他魅力

259
00:16:21,035 --> 00:16:24,210
数据结构，而这条隐形的名字叫江他们儿子

260
00:16:25,200 --> 00:16:27,330
这套引擎的基本思路是

261
00:16:27,810 --> 00:16:32,730
数据和数据之间维持一个互相之间不相干的数据段

262
00:16:32,760 --> 00:16:34,170
而这个数据段

263
00:16:34,620 --> 00:16:36,750
你可以认为它很像

264
00:16:37,020 --> 00:16:38,610
Ikv之间的容易整

265
00:16:41,790 --> 00:16:47,100
每一个数据都会被分成两部分，一部分是非某数据段，一部分是调查数据段

266
00:16:47,220 --> 00:16:49,140
微博数据显示，根据

267
00:16:49,290 --> 00:16:51,240
逐渐进行排序的数据段

268
00:16:51,270 --> 00:16:56,340
比方说，数据段是类似于lc MC当中美媒体推广的作用

269
00:16:56,490 --> 00:16:59,700
是不断地向后添加的一个数据段

270
00:17:01,440 --> 00:17:03,000
在读取的时候

271
00:17:04,140 --> 00:17:05,940
由于是代购，还是代购？

272
00:17:06,390 --> 00:17:10,920
这根本和之间是并不会有阿拉伯，因此我不需要进行多路归并

273
00:17:11,820 --> 00:17:17,130
但是需要规定的是，CF数据段和调查数据段需要进行一次二路归并

274
00:17:18,540 --> 00:17:19,890
而实际上

275
00:17:20,100 --> 00:17:21,480
实现当中

276
00:17:21,690 --> 00:17:25,980
我们使用了索引，也就是说表达数据每插入一笔

277
00:17:26,070 --> 00:17:31,380
都有可以建立一比，所以关联到说我在这笔数据在CT室具体在哪儿？

278
00:17:31,385 --> 00:17:32,250
哪个位置？

279
00:17:32,490 --> 00:17:36,990
通过这个索引信息，我们可以进一步加速收购和加工之间的妹子

280
00:17:38,520 --> 00:17:43,830
当着一套积攒到一定的时间一定的大小之后，我们会使用，恐怕是把c

281
00:17:43,835 --> 00:17:45,630
如何脚踏进行规定

282
00:17:45,960 --> 00:17:51,270
而且对内每个三个门头的物理大小，如果超过一定范围之内，我们也会进行

283
00:17:51,600 --> 00:17:52,890
加一个那个分裂

284
00:17:53,640 --> 00:17:56,190
通过这样的方式，我们保持数据

285
00:17:56,250 --> 00:17:58,470
在一定程度当中有趣

286
00:17:58,500 --> 00:18:02,760
然后又不至于像一像这样涉及很多路的重量规定

287
00:18:07,470 --> 00:18:08,070
我不知道

288
00:18:09,420 --> 00:18:11,910
让我们来说一下，同步算法

289
00:18:13,050 --> 00:18:15,480
看出来是使用的轻量的数据同步

290
00:18:16,020 --> 00:18:17,130
这个同步

291
00:18:17,550 --> 00:18:19,530
是使用了软质的协议

292
00:18:21,180 --> 00:18:26,130
所以看出来是提供的是只读服本身本身并不能直接进行修改

293
00:18:26,160 --> 00:18:28,980
所有的修改都必须通过，太低微

294
00:18:29,010 --> 00:18:33,240
写入太偏僻，然后再进行数据同步到太傅来时

295
00:18:34,770 --> 00:18:36,960
这个副本也不参与选举

296
00:18:38,010 --> 00:18:38,850
所以

297
00:18:39,450 --> 00:18:43,710
它的可用性并不会计算在整个让它的肉可当中

298
00:18:45,930 --> 00:18:49,320
另外，这个同步本身是一个异步同步的协议

299
00:18:49,380 --> 00:18:54,600
因此，对于泰KTV这边的业务并不会造成多大的开销

300
00:18:57,630 --> 00:18:59,880
让我们来看一下具体的同步流程

301
00:19:03,600 --> 00:19:08,910
这边是一个cover let写入太低，必须写入太KB集群的佛

302
00:19:08,915 --> 00:19:10,410
多副本的一个

303
00:19:10,560 --> 00:19:11,400
智力

304
00:19:12,420 --> 00:19:17,730
首先，它可以可爱的向丽的节点进行写入，然后离这儿点由上正常的方式

305
00:19:17,735 --> 00:19:20,010
是正常的情况，底下一样

306
00:19:20,370 --> 00:19:22,320
对于罗尔进行同步

307
00:19:22,325 --> 00:19:25,020
而这个时候，只要有多数派能达到

308
00:19:25,050 --> 00:19:27,390
写入完成就可以返回数据

309
00:19:28,290 --> 00:19:31,110
而在异步的背景县城当中

310
00:19:31,620 --> 00:19:36,930
会有一部分数据慢慢在一部的方式同步到他们开始节点

311
00:19:36,935 --> 00:19:39,540
而这部分节点收到数据之后

312
00:19:39,545 --> 00:19:41,520
会把数据写成列成

313
00:19:42,630 --> 00:19:44,040
石头关注的是

314
00:19:44,220 --> 00:19:46,590
这边的正常写入流程

315
00:19:46,770 --> 00:19:52,080
没没有太复杂的节点的情况是一样的，也就是说离着进行写入，然后多数

316
00:19:52,085 --> 00:19:53,100
给我说了啊！

317
00:19:53,880 --> 00:19:59,190
能够写入数据之后，这个蠢残损或者这笔写入就已经可以向扣

318
00:19:59,195 --> 00:20:01,320
户端返回收拾完成

319
00:20:01,350 --> 00:20:02,880
而并不需要等待

320
00:20:02,910 --> 00:20:06,330
在哪儿这一点？或者看佛按时节点接收到数据

321
00:20:08,880 --> 00:20:13,800
所以，这样的同步方式，会对正常的tp业务并不会带来多少大的干扰

322
00:20:13,950 --> 00:20:19,260
尤其是说你的雷诺兹也并没有并并没有因为一个同步协议而上升

323
00:20:22,860 --> 00:20:27,930
但在这样一部同步的方式底下，我们仍然能提供一个强一致的读取

324
00:20:31,170 --> 00:20:36,480
这个强一致是什么样的强一致？首先逻辑上看kt的数据和肽负26

325
00:20:36,485 --> 00:20:39,780
数据对于同一个人圈或者对同一部分的数据

326
00:20:40,740 --> 00:20:46,050
逻辑上来说是同一份是一致的数据，而并不是通过某种异构的架构进行机构的

327
00:20:46,055 --> 00:20:47,220
复制的数据

328
00:20:48,600 --> 00:20:53,910
而这份同一份的数据可以提供一个块状和粒级别，而且能保护

329
00:20:53,915 --> 00:20:58,080
正说你写下去了数据，但它不但是这边肯定能读得到

330
00:21:02,310 --> 00:21:05,880
读操作的强一致是使用在那儿等进行

331
00:21:06,330 --> 00:21:11,640
而这个棱锐锐的还需要配合MV CC这样加起来，我们能完成一个

332
00:21:11,645 --> 00:21:12,960
要不要的快照？

333
00:21:14,100 --> 00:21:15,150
的一致性

334
00:21:15,155 --> 00:21:18,120
而这个一致性，其实是和skt

335
00:21:18,180 --> 00:21:23,040
她KB配合CD b的一致性是一样的，包括气候能读

336
00:21:23,045 --> 00:21:26,970
包括不会有脏足是快快让隔离级别的读取

337
00:21:31,440 --> 00:21:33,420
然后这个读取是怎么完成的呢？

338
00:21:36,720 --> 00:21:41,280
现在来看一下，冷冷热热，如何配合？CC c来提供一个强一致的读取

339
00:21:42,060 --> 00:21:46,920
首先，在客户端需要读取数据之前需要向PT申请，一个时间戳

340
00:21:47,250 --> 00:21:52,560
这个申请时间做的动作和任何客户端读取IP b的数据也是一致的

341
00:21:55,020 --> 00:21:56,700
再拿到时间戳之后

342
00:21:57,120 --> 00:22:02,100
后端向太出来写点当中的拉出来轮轮发送读取请求

343
00:22:03,390 --> 00:22:08,610
而拉斯拉斯拉会将自己所携带的拉弗拉格的复制进度

344
00:22:09,120 --> 00:22:11,580
发送给亚斯雷德尔进行校对

345
00:22:12,780 --> 00:22:15,780
在这里挖出来，哪儿复制到了印度二？

346
00:22:16,560 --> 00:22:20,370
他发送校对请求携带自己的复制进度给说服力的人

347
00:22:22,380 --> 00:22:24,960
而离的呢？收到，校对请求之后

348
00:22:25,260 --> 00:22:28,800
会将缺失的数据一并补上

349
00:22:29,610 --> 00:22:32,160
而且那个收到补上的数据之后

350
00:22:32,790 --> 00:22:34,710
就可以提供读取服务

351
00:22:35,550 --> 00:22:37,320
但大家也需要问你

352
00:22:39,030 --> 00:22:42,570
煮取一张表，可能包含很多个大学生那儿的校对

353
00:22:42,575 --> 00:22:47,340
而这些教练有可能会先到达率队，有可能会有些会后到达绿地

354
00:22:47,580 --> 00:22:51,030
所以大家补上的数据进度也是不完全一样的

355
00:22:51,390 --> 00:22:56,700
如何保证说不会有臧族或者说能保证一个快照读取的隔离几点？

356
00:22:57,930 --> 00:22:59,460
事实上来说

357
00:22:59,940 --> 00:23:03,930
在当日进行数据校验，校验补充数据之后

358
00:23:03,990 --> 00:23:07,830
实际上，读取还需要通过mac c配合时间出来进行

359
00:23:08,220 --> 00:23:10,260
大家请回想一下之前

360
00:23:10,770 --> 00:23:13,950
查询之前会先向pd申请时间出

361
00:23:13,955 --> 00:23:16,560
然后才会发送仍了校对的请求

362
00:23:17,100 --> 00:23:21,000
换句话说，时间戳的时间，车前盖的时间

363
00:23:21,030 --> 00:23:23,100
肯定是一个较早的时间

364
00:23:23,130 --> 00:23:26,880
而人类进行数据校对，并进行数据补充的时候

365
00:23:26,885 --> 00:23:29,490
肯定会包含时间戳之后的数据

366
00:23:30,390 --> 00:23:35,700
只要所有的衣服了，那都包含时间戳之后的数据，那我再读取的时候只要包含

367
00:23:36,300 --> 00:23:40,050
只要将时间小于等于时间戳的数据进行筛选

368
00:23:40,055 --> 00:23:42,750
那我就可以拿到一个完整的块状隔离的

369
00:23:43,020 --> 00:23:44,220
强一致读取

370
00:23:46,110 --> 00:23:49,470
而这种读取，由于时间戳的时间是比

371
00:23:49,740 --> 00:23:52,170
用户写入的时间更晚

372
00:23:52,500 --> 00:23:53,370
因此

373
00:23:53,910 --> 00:23:59,220
你如果进行一次写入，然后再通过时间戳进行查询，那么你写入的数据

374
00:23:59,610 --> 00:24:01,560
肯定是能被查询到的

375
00:24:06,270 --> 00:24:08,370
现在来讲一下

376
00:24:08,670 --> 00:24:11,010
他虽然是比裂成更多的东西

377
00:24:15,120 --> 00:24:16,230
水平扩展

378
00:24:16,620 --> 00:24:20,880
他们是本身并不指使，并不仅仅是一个劣存格式

379
00:24:23,340 --> 00:24:25,680
他本身也提供了水平扩展的能力

380
00:24:25,890 --> 00:24:30,270
由于太低，必须上taxi的战斗使用了么？俱乐部的提供水平扩展

381
00:24:30,570 --> 00:24:33,300
所以它拥有一键增减节点

382
00:24:33,570 --> 00:24:37,170
自动扩展和无痛，平滑重分布的一个特性

383
00:24:37,620 --> 00:24:42,930
而泰服暂时使用的，让人能人士接入了太困于整体的架构，因此他拥有同样的特点

384
00:24:46,590 --> 00:24:47,640
有隔离

385
00:24:48,990 --> 00:24:52,380
由于探出来学点使用的是一种不同的物理节点

386
00:24:52,650 --> 00:24:53,610
因此

387
00:24:53,700 --> 00:24:55,980
他拥有良好的业务隔离的特性

388
00:24:58,170 --> 00:25:01,620
节点和节点之间被分成不同的肉

389
00:25:02,460 --> 00:25:04,110
因此，你可以华芬

390
00:25:04,290 --> 00:25:05,460
Pp的业务

391
00:25:05,970 --> 00:25:07,230
他QQ节点

392
00:25:07,320 --> 00:25:08,700
作为gp的重

393
00:25:09,210 --> 00:25:11,850
而type当时的节点做APP业务

394
00:25:12,450 --> 00:25:13,770
存在APP中

395
00:25:18,480 --> 00:25:19,080
我不知道

396
00:25:23,790 --> 00:25:24,390
我知道

397
00:25:24,870 --> 00:25:30,180
如果你并不完完全全希望说非常良好的业务隔离，那么

398
00:25:30,630 --> 00:25:33,390
他不但是其实还提供了另外一种形态

399
00:25:33,450 --> 00:25:35,610
这种形态有点类似于

400
00:25:35,615 --> 00:25:38,130
内存索引的形态，也就是说

401
00:25:38,400 --> 00:25:43,530
菜分量是不再是作为一个隔离的数据区提供AC太平的服务

402
00:25:43,535 --> 00:25:48,840
而是作为和泰KB同时有机的整体接入泰迪b和态度

403
00:25:48,845 --> 00:25:49,680
体系的

404
00:25:49,980 --> 00:25:51,900
套特殊的数据索引

405
00:25:53,520 --> 00:25:57,150
在这种情况底下，计算层态度，并和泰斯巴克

406
00:25:57,180 --> 00:26:01,530
可以根据代价去任意选择从她闺蜜还是从泰富20

407
00:26:01,620 --> 00:26:03,780
进行行存或者内存的读取

408
00:26:05,250 --> 00:26:06,840
还开出来是几点？

409
00:26:07,140 --> 00:26:12,450
哪怕只有一部分也可以很方便的，feel沃尔到泰kv上的主数据区

410
00:26:13,770 --> 00:26:18,300
而一个查询可以同时使用行存和内存两种形式提供服务

411
00:26:21,990 --> 00:26:23,430
接下来看一个例子

412
00:26:25,110 --> 00:26:27,390
这是一个高度整合查询的例子

413
00:26:27,540 --> 00:26:31,320
也就是说，将type但是作为一个内存索引使用的例子

414
00:26:32,160 --> 00:26:37,470
在这个查询当中，有两张表，一张表叫她他的表，一张表叫464表

415
00:26:37,680 --> 00:26:41,760
其中，科大代表在外才第一次建立了一条，所以

416
00:26:43,800 --> 00:26:46,770
那我们看这个查询是一个表连接的查询

417
00:26:47,220 --> 00:26:48,060
在

418
00:26:48,065 --> 00:26:53,370
通过办事还第一进行过滤之后，两张表通过pad进行连接，最后计算

419
00:26:54,300 --> 00:26:56,310
COC I ri bao

420
00:26:57,300 --> 00:26:59,070
那么在这个计算题上

421
00:26:59,280 --> 00:27:00,210
由于

422
00:27:00,215 --> 00:27:03,240
在飘荡表上，有一张带出来的，所以

423
00:27:03,390 --> 00:27:06,180
而带出来的正好匹配的某个位置

424
00:27:07,170 --> 00:27:10,800
假设说这个谓词通过，所以之后只需要返回

425
00:27:10,890 --> 00:27:13,530
非常少的记录，比如说一条或者两条

426
00:27:13,830 --> 00:27:14,820
这无疑

427
00:27:15,810 --> 00:27:21,120
拿到表的读取，肯定是在行存加上索引的情况底下会更加快速

428
00:27:21,270 --> 00:27:22,320
更加优秀

429
00:27:23,310 --> 00:27:24,990
而对于瘦子们来说

430
00:27:25,050 --> 00:27:27,900
这个查询当中没有提供任何的过滤条件

431
00:27:27,930 --> 00:27:31,770
或者说过滤条件并不能很好的过滤数据

432
00:27:32,040 --> 00:27:35,040
而这个表的搜索，只提供了两个列

433
00:27:36,060 --> 00:27:41,370
因此，在这个场景底下，袖子表通过探出来进行裂唇

434
00:27:41,790 --> 00:27:44,880
加上列过滤的方式读取是非常快的

435
00:27:45,150 --> 00:27:46,710
而整个查询

436
00:27:46,860 --> 00:27:52,170
状元的方式肯定是一边通过航程，一边通过内存进行查询湿作用

437
00:27:52,175 --> 00:27:53,070
随便截的

438
00:27:54,750 --> 00:28:00,060
这个例子体现了说如果你不需要进行业务隔离的情况，底下航程和猎者

439
00:28:00,065 --> 00:28:01,740
同时进行查询

440
00:28:01,800 --> 00:28:03,810
可以提供非常好的效果

441
00:28:05,280 --> 00:28:09,360
而整个索引的选择并不需要任人唯用户去干涉

442
00:28:10,530 --> 00:28:14,010
泰利斌和态度吧，可以优化器会根据当前的

443
00:28:14,610 --> 00:28:19,920
查询通过不同的数额，暂时提供的代价来估算说我需要

444
00:28:19,925 --> 00:28:22,320
通过列车，还是通过长存进行查询

445
00:28:24,540 --> 00:28:27,960
Pp，支持他确实也将提供APP的支持

446
00:28:28,470 --> 00:28:32,250
换句话说，太不节点之间会形成APP的架构

447
00:28:32,970 --> 00:28:35,520
类似于一个需要拿起的分布式数据库

448
00:28:36,060 --> 00:28:39,240
而每个单机都拥有自己独特的计算能力

449
00:28:39,480 --> 00:28:44,790
而在一些特殊操作会需要在节点和节点之间进行数据交换，以完成最终

450
00:28:45,060 --> 00:28:45,960
就算任务

451
00:28:48,300 --> 00:28:52,980
通过这种支持，我们可以几乎把所有的计算都下推到

452
00:28:53,190 --> 00:28:57,570
判断时间点，这对于泰迪犬来说将会是一个非常大的加成

453
00:28:57,960 --> 00:29:02,190
而哪怕是泰斯巴克这样已经有分布式计算框架的产品

454
00:29:02,310 --> 00:29:03,600
也可以通过

455
00:29:04,320 --> 00:29:07,560
Mp p架构来进一步提高速度

456
00:29:08,640 --> 00:29:10,440
特别是在阿德好的场景

457
00:29:10,470 --> 00:29:13,650
用户其实往往并不需要一个高容错的沙漠

458
00:29:13,770 --> 00:29:14,580
设计

459
00:29:14,910 --> 00:29:16,770
犹如像太出来，现在这样子

460
00:29:17,040 --> 00:29:22,350
那么，熊APP的查询引擎会更加提速爱好查询，或者说一些短小的查询

461
00:29:23,130 --> 00:29:28,440
好像在这个时候，我们会希望说20号查询短号查询走踏出20

462
00:29:28,445 --> 00:29:29,610
Pp的引擎

463
00:29:29,730 --> 00:29:33,270
而他算了引擎可以继续服务于一体的架构

464
00:29:33,540 --> 00:29:37,560
因为一切而需要使用更长的时间，而需要更好的容错

465
00:29:40,470 --> 00:29:43,110
Mp p支持的示意图是这样子

466
00:29:46,500 --> 00:29:48,540
也就是说，它出来写点

467
00:29:49,650 --> 00:29:52,560
本身都会具有一部分的计算功能

468
00:29:52,830 --> 00:29:57,750
这部分的计算功能，你可以理解为和泰KB的QQ相册是非常类似的

469
00:29:58,020 --> 00:30:03,330
但是看kt的QQ 30为什么不能把所有的计算都从泰迪b这边

470
00:30:03,810 --> 00:30:05,010
下推下来呢？

471
00:30:05,460 --> 00:30:09,840
大家可以想一下，如果我做一张两表两张大表的关联

472
00:30:10,530 --> 00:30:13,740
那么，实际上来说，计算引擎需要做的事情是

473
00:30:13,890 --> 00:30:18,600
把相同属于关联关联键当中相同哈希值的

474
00:30:18,605 --> 00:30:21,510
数据全都搬送到同一台机器上

475
00:30:21,660 --> 00:30:24,000
然后这台机器就可以

476
00:30:24,090 --> 00:30:25,050
分布的

477
00:30:25,140 --> 00:30:28,260
分配的计算，这一部分转移的

478
00:30:28,440 --> 00:30:29,850
数据结果

479
00:30:31,650 --> 00:30:36,960
而这一个数据交换的过程，在当前的skt跟他出来的节点都是不去

480
00:30:36,965 --> 00:30:37,710
对的

481
00:30:37,830 --> 00:30:39,660
因此，我们正在努力

482
00:30:39,750 --> 00:30:42,930
使太初来时节点之间能做数据交换

483
00:30:43,110 --> 00:30:48,240
而这个数据交换本身可以完成刚才所说的那样子分布式

484
00:30:48,540 --> 00:30:50,220
大表关联

485
00:30:52,800 --> 00:30:58,110
而一旦完成了数据交换之后，整个探测项目应该可以计算所有

486
00:30:58,470 --> 00:31:00,750
当成泰迪并能接受到的寇瑞

487
00:31:00,960 --> 00:31:03,570
这样子的话，在AP的场景底下

488
00:31:03,720 --> 00:31:04,830
哈尔滨可以

489
00:31:04,860 --> 00:31:08,070
将所有的计算全都吓退到了复旦时节点

490
00:31:09,780 --> 00:31:12,480
这样可以大大提升太低必须的，计算的速度

491
00:31:12,810 --> 00:31:17,490
也会减少很多泰迪比喻人生会on会内存不足的场景

492
00:31:20,700 --> 00:31:21,600
性能

493
00:31:22,410 --> 00:31:27,720
在当成预发布的环境底下，我们测试的性能大致是一款贵极品的

494
00:31:28,950 --> 00:31:30,270
这样说的是

495
00:31:30,360 --> 00:31:34,290
由于跑酷是一个静态的格式，并不支持动态数据的变更

496
00:31:34,320 --> 00:31:38,340
因此，静态的格式是非常容易优化的速度非常快的地步的

497
00:31:39,360 --> 00:31:40,110
我们

498
00:31:40,260 --> 00:31:43,140
针对爸爸23再加跑酷

499
00:31:43,470 --> 00:31:46,230
在单机上进行呢？T PC at的测试

500
00:31:47,160 --> 00:31:50,370
这个测试当中，计算引擎都是办法

501
00:31:51,090 --> 00:31:55,290
而存储引擎分别是百度服，加上反馈或者

502
00:31:55,380 --> 00:31:56,310
还不让人吃？

503
00:31:57,210 --> 00:31:59,070
这是一个对比的图

504
00:32:00,210 --> 00:32:01,770
咱可以看到说

505
00:32:02,010 --> 00:32:06,000
我们的速度太，发货速度跟跑快的速度基本是一致的

506
00:32:06,360 --> 00:32:08,370
有一些他们会有一些我们快

507
00:32:08,520 --> 00:32:11,070
但正是基于一个预发布版本

508
00:32:11,430 --> 00:32:14,760
相信在正式发布版本，这个速度将会变得更快

509
00:32:19,470 --> 00:32:20,070
我不知道

510
00:32:21,510 --> 00:32:23,640
第三部分，而且TB的图形

511
00:32:24,840 --> 00:32:29,760
首先是HTC形态下的数据平台，另外是HTC对于业务的变革

512
00:32:33,000 --> 00:32:36,000
回想一下刚才课程当中所说的

513
00:32:36,810 --> 00:32:39,360
数据平台会变得越来越复杂的问题

514
00:32:39,450 --> 00:32:44,760
其实有很多用户希望数据平台能回到自己业务最初数据非常少，业务非常

515
00:32:44,765 --> 00:32:46,290
简单的情况底下

516
00:32:46,440 --> 00:32:50,160
有一两个这边一然后用户同一套数据库能完成的状态

517
00:32:51,060 --> 00:32:52,710
通过CD b

518
00:32:53,160 --> 00:32:55,680
你也许可以做到这件事情

519
00:32:56,100 --> 00:32:58,590
她利于本身提供了tp的能力

520
00:32:58,980 --> 00:33:04,290
然后再一部分数据服务层，他离毕业可以提供通过索引进行AP查询的能力

521
00:33:04,890 --> 00:33:09,270
而报表和BI的能力可以通过太傅来进行补充完成

522
00:33:09,660 --> 00:33:10,500
因此

523
00:33:10,890 --> 00:33:14,820
在很多情况底下，你也许可以尝试使用它的币

524
00:33:14,880 --> 00:33:18,930
加上太多了，一一整套，作为你唯一的数据平台

525
00:33:22,470 --> 00:33:25,260
另外，HTC，对于数据的变革

526
00:33:26,580 --> 00:33:27,570
由于

527
00:33:28,440 --> 00:33:32,850
使用APP的形态，使用type 2形态，你不再需要

528
00:33:33,060 --> 00:33:36,000
进行很大量的数据搬迁，因此

529
00:33:36,030 --> 00:33:39,180
你可以非常方便的，在直接主控

530
00:33:40,050 --> 00:33:42,360
数据上进行数据查询

531
00:33:43,590 --> 00:33:46,500
这对你的业务变革，区别是非常明显的

532
00:33:46,680 --> 00:33:51,450
在之前你如果需要通过一条导出数据，在进行数据分析的时候

533
00:33:51,455 --> 00:33:54,030
你能问的问题是昨天发生了什么？

534
00:33:55,380 --> 00:34:00,030
而对使用type 20这样HTC的形态，你可以直接查询

535
00:34:00,120 --> 00:34:01,710
当前发生的事情

536
00:34:02,310 --> 00:34:07,620
这对你的业务也许是一个很大的帮助，比如说你的风控也可以进行实时的疯狂

537
00:34:08,280 --> 00:34:13,590
每笔数据进入之后，你都可以针对这个数据进行一定程度的校验

538
00:34:13,920 --> 00:34:17,910
或者是说金融或者银行进行实时的对账

539
00:34:18,300 --> 00:34:20,550
你可以不再等待约一个小时

540
00:34:20,820 --> 00:34:22,950
将数据导出到另外一套系统

541
00:34:23,130 --> 00:34:26,520
而且这个导出很有可能会丢失你的数据一致性

542
00:34:26,550 --> 00:34:29,370
在这样一致性要求非常严格的情况底下

543
00:34:29,375 --> 00:34:32,400
你可以使用python来进行实时的对账

544
00:34:34,170 --> 00:34:36,450
相信这样的案例会非常非常多

545
00:34:37,410 --> 00:34:41,040
一旦数据可以实时的到账，可以实时的查询

546
00:34:42,240 --> 00:34:44,790
这对你的业务相信是一个很大的帮助

547
00:34:48,210 --> 00:34:51,240
啥安排，请登录片，看网上官方

548
00:34:51,660 --> 00:34:53,880
你那边事情点评，看扁桃吗？

549
00:34:54,330 --> 00:34:55,770
你也可以扫描二维码

550
00:34:58,260 --> 00:34:59,250
谢谢大家

551
00:35:03,960 --> 00:35:04,560
我不知道