快捷導(dǎo)航

ES業(yè)務(wù)數(shù)據(jù)遷移遇到的精度問(wèn)題BUG

更新時(shí)間：2022年06月21日 14:05:10 作者：CKL的思考空間

這篇文章主要為大家介紹了ES業(yè)務(wù)數(shù)據(jù)遷移遇到的BUG精度問(wèn)題，有需要的朋友可以借鑒參考下，希望能夠有所幫助，祝大家多多進(jìn)步，早日升職加薪

前言

最近在協(xié)助團(tuán)隊(duì)完成 ES 數(shù)據(jù)的切換（業(yè)務(wù)數(shù)據(jù)遷移），過(guò)程中遇到一個(gè)比較好玩的 BUG ，和大家分享并作為經(jīng)驗(yàn)記錄。

01 問(wèn)題發(fā)現(xiàn)過(guò)程

通過(guò)前期的方案設(shè)計(jì)和比較，我們決定通過(guò) elasticdump 工具來(lái)做 ES 的數(shù)據(jù)遷移，這個(gè)也是比較普遍的遷移方案，于是就動(dòng)手實(shí)施了，過(guò)程中也沒(méi)遇到什么問(wèn)題。在最后的數(shù)據(jù)驗(yàn)證環(huán)節(jié)，發(fā)現(xiàn)有一個(gè) ID 對(duì)應(yīng)不上了，如下圖所示，通過(guò)對(duì)比工具，發(fā)現(xiàn)一個(gè)長(zhǎng)度較大的 ID 發(fā)生了偏移，其他的數(shù)據(jù)都沒(méi)有問(wèn)題。這是為什么呢？一頭霧水。

根據(jù)二分法的排錯(cuò)思路，我們需要先確認(rèn)是導(dǎo)出數(shù)據(jù)的問(wèn)題，還是導(dǎo)入數(shù)據(jù)的問(wèn)題。查看導(dǎo)出過(guò)程的中間文件，發(fā)現(xiàn)在導(dǎo)出的時(shí)候就出現(xiàn)了錯(cuò)誤。于是懷疑是 elasticdump 導(dǎo)出功能的問(wèn)題。因?yàn)檫@個(gè)出錯(cuò)的字段，主要的特征就是長(zhǎng)度比較長(zhǎng)（18 位），于是懷疑是精度的問(wèn)題。就去查了下 elasticdump 的源碼，一番查找后，果然發(fā)現(xiàn)有人遇到過(guò)同樣的問(wèn)題，并已經(jīng)修復(fù)了這個(gè) BUG，并給出了解決方案和一些猜測(cè)的原因。于是這個(gè)問(wèn)題就得到了解決。在 elasticdump 的導(dǎo)出命令中，加上－-support-big-int 參數(shù)，就可以了。

好像也很簡(jiǎn)單嘛，不是么。其實(shí)排錯(cuò)的過(guò)程也走過(guò)很多彎路，只是現(xiàn)在回顧起來(lái)看著比較輕松而以。

02 問(wèn)題的根因是什么

只解決問(wèn)題并不是我的風(fēng)格，總得看看讓我繞這么大圈才解決的問(wèn)題根因是什么嘛。于是查了相關(guān)資料（結(jié)合上面 GIT 上的對(duì)話），可以確認(rèn)，是因?yàn)?elasticdump 中有部分功能是用 JS 寫(xiě)的，而 Js 遵循 IEEE754 規(guī)范，采用雙精度存儲(chǔ)，占用 64 位，從左到右的安排位第一問(wèn)表示符號(hào)位，11 位表示指數(shù)，52 位來(lái)表示尾數(shù)，因此 Js 中能精確表示的最大整數(shù)是 253（十進(jìn)制為 9007199254740992），那么大于這個(gè)數(shù)（本文中數(shù)值長(zhǎng)度 18 位）就可能會(huì)丟失精度，因?yàn)槎M(jìn)制只有 0 和 1，數(shù)值太大，于是就出現(xiàn)了精度丟失的問(wèn)題?？梢栽?Chrome Console 里面試了一下，果然是這樣，（不是超過(guò)了能表示的最大值，而是超過(guò)了能精確表示的最大值），和 elasticdump 導(dǎo)出的數(shù)據(jù)變化基本類似。

再往深了想，為什么用 double 類型會(huì)出現(xiàn)這個(gè)問(wèn)題，其他的數(shù)據(jù)類型是否會(huì)有同樣的問(wèn)題呢？這就涉及了數(shù)據(jù)精度的問(wèn)題，在這里篇幅有限，就不再展開(kāi)，有興趣的同學(xué)可以自己去查看相關(guān)資料，本質(zhì)上還是十進(jìn)制小數(shù)與二進(jìn)制小數(shù)相互轉(zhuǎn)換產(chǎn)生的誤差。

03 類似的問(wèn)題有哪些

因?yàn)檫@個(gè)問(wèn)題比較好玩，就又找了一些資料看了下，發(fā)現(xiàn)還有兩個(gè)精度有關(guān)的 BUG，還蠻好玩的。

千年蟲(chóng)問(wèn)題：

這個(gè)問(wèn)題相信很多人 IT 人都聽(tīng)說(shuō)過(guò)，簡(jiǎn)單來(lái)說(shuō)，就是由于前期計(jì)算機(jī)的存儲(chǔ)資源較為昂，在表達(dá)時(shí)間時(shí)，為了節(jié)約空間，有位科學(xué)家提出了一個(gè)方案，把1960年8月11日，簡(jiǎn)寫(xiě)成 600811。但這樣會(huì)有一個(gè)問(wèn)題，就是當(dāng)時(shí)被縮寫(xiě)掉的是 19XX 年中 19，如果時(shí)間來(lái)到 2000 年，程序就無(wú)法準(zhǔn)確表達(dá)時(shí)間。比如：2000年1月1日，簡(jiǎn)寫(xiě)成六位數(shù)是 000101。計(jì)算機(jī)就會(huì)懷疑人生，怎么時(shí)間倒流了呢？然后就會(huì)導(dǎo)致計(jì)算機(jī)系統(tǒng)發(fā)生紊亂。當(dāng)時(shí)大家都覺(jué)得自己的程序不會(huì)運(yùn)行到 2000 年，所以就沒(méi)太放在心上，而大多數(shù)后來(lái)人習(xí)慣了這種記錄方式，就忘記了這回事，結(jié)果引發(fā)了千禧年的大 BUG，造就了多少程序員的不眠之夜。

2038 年問(wèn)題：

現(xiàn)在很多時(shí)候，我們?cè)谔幚頃r(shí)間問(wèn)題時(shí)，都喜歡用時(shí)間戳來(lái)記錄，因?yàn)楹?jiǎn)單方便，不需要考慮時(shí)區(qū)問(wèn)題（時(shí)區(qū)問(wèn)題很讓人頭疼的，一不小出就容易出錯(cuò)）。但是這里面會(huì)有一個(gè)小 BUG 喲。什么是時(shí)間戳呢？簡(jiǎn)單來(lái)說(shuō)就是：以1970年1月1日0 時(shí) 0 分 0 秒為起點(diǎn)，然后通過(guò)計(jì)算秒數(shù)來(lái)算出當(dāng)前時(shí)間。比如：2021年5月7日15:00:00，換算一下就是 1620370800 秒。但是由于 32 位操作系統(tǒng)所能計(jì)算的秒數(shù)有限，到2038年1月19日3:14:07，就會(huì)達(dá)到極限。二進(jìn)制：01111111 11111111 11111111 11111111，其后一秒，二進(jìn)制數(shù)字會(huì)變?yōu)?10000000 00000000 00000000 00000000，發(fā)生溢出錯(cuò)誤，造成系統(tǒng)將時(shí)間誤解為1901年12月13日20 時(shí) 45 分 52 秒，然后系統(tǒng)就會(huì)發(fā)生各類錯(cuò)誤，是不是和上面的千年蟲(chóng)一樣？理論上到了 2038 年，人們應(yīng)該淘汰掉了 32 位操作系統(tǒng)， 64 位操作系統(tǒng)就不存在這個(gè)問(wèn)題。但是從前面的 “千年蟲(chóng)” 事件來(lái)看，人類從歷史中吸取的唯一教訓(xùn)，就是人類不會(huì)吸取任何教訓(xùn)。

04 小結(jié)

對(duì)于發(fā)現(xiàn)的缺陷，不能僅停留在把問(wèn)題解決了就完事。有時(shí)間和精力，還是需要更深層次的去了解缺陷背后的邏輯和根因是什么，觸類旁通。以避免更多類似的問(wèn)題發(fā)生。

在寫(xiě)這篇文章的時(shí)候，又想起了自己以前做報(bào)表相關(guān)的業(yè)務(wù)時(shí)，對(duì)于時(shí)間的精度特別敏感，也會(huì)遇到一些關(guān)于精度上的取舍問(wèn)題，這需要我們和業(yè)務(wù)方面討論并確認(rèn)清楚，是精確到秒，還是毫秒，以避免出現(xiàn)數(shù)據(jù)邊界的小問(wèn)題。

以上就是ES業(yè)務(wù)數(shù)據(jù)遷移遇到的BUG精度問(wèn)題的詳細(xì)內(nèi)容，更多關(guān)于ES數(shù)據(jù)遷移精度BUG的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章！

您可能感興趣的文章: