数据增量更新定义_TiDB 在 OPPO 准实时数据仓库中的实践
作者介紹
OPPO 數(shù)據(jù)分析與解決方案團(tuán)隊主要負(fù)責(zé) OPPO 全集團(tuán)的大數(shù)據(jù)分析和解決方案提供,團(tuán)隊成員多來自一線互聯(lián)網(wǎng)公司及著名高校,在 OPPO 眾多場景的大數(shù)據(jù)應(yīng)用方面有很深經(jīng)驗,極大的支撐了業(yè)務(wù)迅速發(fā)展。文章具體作者:羊歡,代凱,柳青,陳英樂。
OPPO 大數(shù)據(jù)中心在 2019 年初承接了接入某業(yè)務(wù)線核心數(shù)據(jù)的重要任務(wù):一期目標(biāo)是建立一個能提供準(zhǔn)實(shí)時大數(shù)據(jù)查詢服務(wù)的數(shù)據(jù)倉庫。我們選用了之前從未在公司大規(guī)模正式使用過的 TiDB 作為核心數(shù)據(jù)庫引擎。本文記錄這次吃螃蟹的一些經(jīng)驗和教訓(xùn),供大家參考。前期工作核心挑戰(zhàn)
經(jīng)過需求調(diào)研階段,我們發(fā)現(xiàn)面臨以下核心的挑戰(zhàn):
1. 大數(shù)據(jù)能力支持。從業(yè)務(wù)數(shù)據(jù)量看,當(dāng)前雖然尚在 TB 級別,但增長速度非???#xff0c;業(yè)務(wù)本身有進(jìn)行全量整合分析查詢的需求。
2. 數(shù)據(jù)接入困難。數(shù)據(jù)分散且多樣,跨國,多種 DB 類型,多網(wǎng)絡(luò)環(huán)境,接入難度較大。
3. 數(shù)據(jù)變動頻繁。核心數(shù)據(jù)存在生命周期,在生命周期內(nèi)變動頻繁,這與互聯(lián)網(wǎng)的核心數(shù)據(jù)一旦生成就不再變化有較大不同。
4. 服務(wù)實(shí)時性較高。數(shù)據(jù)整合的速度和查詢結(jié)果越實(shí)時,對業(yè)務(wù)價值就越大。現(xiàn)有技術(shù)架構(gòu)體系
公司數(shù)據(jù)中心目前承載著公司各業(yè)務(wù)系統(tǒng)積累的數(shù)據(jù)。
數(shù)據(jù)倉庫方面的技術(shù)體系:
離線數(shù)據(jù)的存儲和應(yīng)用架構(gòu)是主流的 Hadoop+Hive/Spark/Presto。
實(shí)時數(shù)據(jù)服務(wù)則基于 Kafka/Flink/SparkStreaming 等流行的框架。
技術(shù)選型考量
一開始我們打算采用業(yè)界常用的辦法,即利用數(shù)據(jù)中心現(xiàn)有的基礎(chǔ)設(shè)施開發(fā)出離線和實(shí)時兩套體系的數(shù)據(jù)并進(jìn)行整合后提供給報表查詢接口。但其實(shí)這個方案其實(shí)有一個最致命的問題:大部分此業(yè)務(wù)數(shù)據(jù)在完整的生命周期里是經(jīng)常發(fā)生變動的。而項目里一個重要的需求是要能近實(shí)時(最多半個小時)的查詢出結(jié)果。離線任務(wù)運(yùn)行后的結(jié)果很可能很快就失效了,需要重新計算。而離線計算耗時較長,根本無法滿足準(zhǔn)實(shí)時需求;如果把大部分計算交給實(shí)時引擎,也要進(jìn)行較為復(fù)雜的代碼設(shè)計和框架的修改適配。
事實(shí)上我們已經(jīng)做好了服務(wù)降級的打算。我們面臨困境的實(shí)質(zhì)是接入頻繁變動的行業(yè)數(shù)據(jù)對于主要源自互聯(lián)網(wǎng)的大數(shù)據(jù)技術(shù)體系是一種新的挑戰(zhàn)。因此我們繼續(xù)不斷的尋找更好的方案。我們的目標(biāo)是找到具有以下特點(diǎn)的體系:
1. 能近實(shí)時的對所有層級的數(shù)據(jù)進(jìn)行更新(主要是原始數(shù)據(jù)和各層聚合數(shù)據(jù))。
2. 秒級的查詢性能。
3. 不再有實(shí)時和離線的界限,只需要同一套代碼。
4. 方便的存儲擴(kuò)展,支持大數(shù)據(jù)。
5. 較低的技術(shù)棧要求。
在這種背景下,我們關(guān)注到了已經(jīng)在 OPPO 內(nèi)部進(jìn)行著少量測試(作為備份從庫等)的 TiDB。它的主要特點(diǎn)及帶來的好處是:
1. 完全兼容?MySQL?協(xié)議。低技術(shù)棧,在合理的索引設(shè)計下,查詢性能優(yōu)異到秒級出結(jié)果;對小批量的數(shù)據(jù)的更新和寫入也相對優(yōu)秀。
2. 水平彈性擴(kuò)展。能支持大數(shù)據(jù)存儲,擴(kuò)容成本僅為機(jī)器成本。
3. 支持大數(shù)據(jù)情況下的復(fù)雜查詢(TiSpark 組件可使用 Spark 引擎)。
4. 可用性高。Raft 協(xié)議保證數(shù)據(jù)強(qiáng)一致且在不丟失大多數(shù)副本的前提下能自動恢復(fù)。
5. 完全開源,社區(qū)活躍。開源約 4 年,GitHub Star 數(shù) 2 萬,Fork 數(shù) 3 千。根據(jù)官方數(shù)據(jù):截止 19 年 8 月,已經(jīng)有約 3 千家企業(yè)建立了規(guī)模不一的測試集群,500 家企業(yè)有線上集群,其中包括數(shù)家銀行(北京銀行,微眾銀行)的核心交易系統(tǒng)。網(wǎng)絡(luò)上也能看到眾多一線互聯(lián)網(wǎng)公司的案例分享。
6. 作為 HTAP,未來將可以方便的對接?TP 類系統(tǒng)。當(dāng)前離線架構(gòu)的數(shù)據(jù)經(jīng)常需要再次出庫到諸如 MySQL 庫里以便 TP 系統(tǒng)快速讀取,無疑增加了系統(tǒng)復(fù)雜度。HTAP 將交易和分析系統(tǒng)的界限消除,交易數(shù)據(jù)生成即可用于分析,而分析結(jié)果生成后即可以用于交易,沒有了 ETL 過程,非常便利,而且讓 IT 架構(gòu)邏輯更近似業(yè)務(wù)邏輯。
對于這次的項目來說,我們最看重的三點(diǎn)是:
1. 可以很方便的支持?jǐn)?shù)據(jù)頻繁更新。
2. 優(yōu)秀的查詢響應(yīng)速度。
3. 支持方便的無限擴(kuò)容。
由于并不可見的重大缺陷,且閱讀了許多比此次項目數(shù)據(jù)量級大得多的成功案例,我們正式開始了吃螃蟹的征程。實(shí)踐過程
項目架構(gòu)和實(shí)施
項目一期的架構(gòu)和實(shí)施相對簡單。主要是集群建設(shè)+數(shù)據(jù)同步+模型建設(shè)+任務(wù)調(diào)度。下面簡要介紹一下。
集群建設(shè)
TiDB集群的架構(gòu)圖及部署文檔參考官方網(wǎng)站即可,不再贅述,以下是項目配置供參考:
關(guān)于存儲官方推薦采用 NVME SSD,這樣能最大發(fā)揮 TiKV 的 IO 能力 。目前由于某些原因,暫時退而求其次采用 SATA SSD,通過把磁盤分成 2 組 TiKV 數(shù)據(jù)盤,每一組 3 塊盤做 RAID0,最后剩余 2 塊盤做 RAID1 作為系統(tǒng)盤,將磁盤 IO 能力提升。然后每組數(shù)據(jù)磁盤上部署一個 TiKV 節(jié)點(diǎn)。TiDB 的部署采用官網(wǎng)推薦的 TiDB Ansible 部署方式,這里不再贅述,大家可以去 PingCAP 官網(wǎng)查看。
數(shù)據(jù)同步
項目采用了定期(每 10 分鐘,可調(diào)整)調(diào)度 Python 腳本以實(shí)現(xiàn)增量抽取數(shù)據(jù)。源數(shù)據(jù)庫是 Oracle/SQLServer,目標(biāo)數(shù)據(jù)庫是 TiDB 集群。數(shù)據(jù)同步腳本是自研的,代碼簡潔但非常強(qiáng)大,核心是采用 pyodbc 開源庫,并具有以下特點(diǎn):
1. 支持多種數(shù)據(jù)目標(biāo)/源 DB,豐富的自定義 DDL 支持(包括自動建表,添加字段注釋,自定義字段處理),自定義抽取 SQL(既可以完整同步數(shù)據(jù),亦可以同步前就進(jìn)行一些預(yù)處理,靈活性強(qiáng))。
2. 便捷的讀寫并發(fā)量控制(讀寫依賴數(shù)據(jù)隊列溝通,還可以平衡數(shù)據(jù)源并發(fā)查詢壓力及目標(biāo)庫的寫壓力,以及歷史數(shù)據(jù)同步)。
同步腳本要求有增量抽取的控制字段,比如 update_time 等,一般規(guī)范的表設(shè)計均能滿足,但項目中確實(shí)遇到一些因歷史原因?qū)е挛覀儾坏貌贿M(jìn)行全表覆蓋同步,部分表還存在“硬刪除”的情況 。最后通過開發(fā)新的刪除服務(wù)以記錄刪除的主鍵,進(jìn)行同步刪除同步。
對于普通的一次增量同步,比如同步最近 10 分鐘的數(shù)據(jù)。我們是定義好同步腳本,傳入時間周期及合理的并發(fā)數(shù),發(fā)起查詢請求,并將返回的數(shù)據(jù)返回到臨時隊列中;寫進(jìn)程則按 5 千條一次讀隊列中的數(shù)據(jù),按主鍵先刪后插,實(shí)現(xiàn)了增量的數(shù)據(jù)新增或者更新。
另外,出于項目周期及成本等考慮,項目并未采用讀取 Oracle Redo Log 的方式。這種方式的優(yōu)點(diǎn)是最小化地減少讀寫操作;缺點(diǎn)是需要付費(fèi)組件支持,需要單獨(dú)開發(fā),以及日志容量問題導(dǎo)致的系統(tǒng)運(yùn)維難度高等。
數(shù)據(jù)同步看起來簡單,但實(shí)際上還是遇到了以下困難并進(jìn)行了相應(yīng)的解決:
1. 由于是多進(jìn)程同步,部分異常捕獲在初期被忽略了,在后來驗證的過程中一一補(bǔ)齊,最后保證了只要任務(wù)正常完成,同步即無誤。
2. 數(shù)據(jù)并發(fā)寫壓力較大(初始化時數(shù)據(jù)同步量非常大)的情況下,會出現(xiàn) TiDB 承壓,存在 TiKV 寫失敗的情況,需要控制并發(fā)量,并在實(shí)踐中得到最佳的配置。
3. 連接頻繁失敗問題,用 Proxy 解決,以及高可用方案。由于 TiDB 在遇到超大 SQL 請求時,會一直申請內(nèi)存直到 OOM,最后 TiDB 重啟,最后采用 HAPROXY 來解決 TiDB 的高可用性。這樣一個節(jié)點(diǎn)重啟盡量不影響其他 SQL 的運(yùn)行。另外 HAPROXY 本身也需要保證高可用,最后是借助運(yùn)維的 OGW 集群來負(fù)責(zé)HAPROXY的高可用。
4. 聯(lián)合索引設(shè)置不合理,導(dǎo)致索引浪費(fèi),未來需要進(jìn)行索引優(yōu)化。
5. 國外數(shù)據(jù)庫與國內(nèi)網(wǎng)絡(luò)連接不穩(wěn)定,主從庫同步延遲導(dǎo)致無法完整同步數(shù)據(jù)。最后采取了實(shí)時監(jiān)控主從同步延遲及獲取數(shù)據(jù)業(yè)務(wù)時間最大值等雙重措施保證數(shù)據(jù)同步的準(zhǔn)確性和及時性。
6. 數(shù)據(jù)同步缺少監(jiān)控機(jī)制,對同數(shù)據(jù)同步過程中是否有數(shù)據(jù)丟失,或者說怎么保證兩邊數(shù)據(jù)庫是一致的,時間久了會不會出現(xiàn)不一致的情況,怎么快速修復(fù)等,目前是通過腳本定期統(tǒng)計兩邊表記錄數(shù)的方式進(jìn)行監(jiān)控。模型建設(shè)
一期項目主要目標(biāo)是將分散的數(shù)據(jù)統(tǒng)一存儲起來,以及進(jìn)行一些大量數(shù)據(jù)明細(xì)表之間的關(guān)聯(lián)查詢。當(dāng)時面臨兩種選擇:
方案一:
僅對源數(shù)據(jù)進(jìn)行基礎(chǔ)性的處理,然后使用復(fù)雜的 SQL 完成業(yè)務(wù)模型的定義(OPPO 自研報表平臺 InnerEye 支持按 SQL 語句自定義查詢接口),每次用戶查詢的時候,都通過這個模型 SQL 即時的運(yùn)算并返回結(jié)果(可設(shè)置緩存時間)。這個做法的好處是幾乎沒有任何的中間甚至結(jié)果數(shù)據(jù)的開發(fā)工作;壞處是對算力的極大浪費(fèi),而且后期并發(fā)度變大后,性能將是瓶頸。
方案二:進(jìn)行常規(guī)的分層模型開發(fā),按周期更新數(shù)據(jù)。由于一期項目較少聚合類報表,多是明細(xì)級數(shù)據(jù)查詢,我們僅僅將模型主要分為共享層和應(yīng)用層。查詢接口直接使用應(yīng)用層單表查詢,可以通過優(yōu)化索引實(shí)現(xiàn)秒查數(shù)據(jù);共享層則是為各個應(yīng)用層的結(jié)果表提供一些公共的基礎(chǔ)數(shù)據(jù)支持。這種做法將面臨的挑戰(zhàn)將是:如何在 10 分鐘內(nèi),將所有的數(shù)據(jù)模型都完成相應(yīng)的增量更新或者插入。評估方案一的時候,使用了 TiSpark 進(jìn)行了驗證,然而結(jié)果并不是很好,響應(yīng)時間達(dá)數(shù)分鐘,當(dāng)然原因可能是集群算力不夠,也可能是 SQL 不夠優(yōu)化。最終考慮到未來并發(fā)的壓力,很快把這個偷懶的方案最終否決了。在實(shí)施方案二的過程中發(fā)現(xiàn),有良好的索引的情況下,只要遵循增量更新的原則,完全能滿足性能需求。模型建設(shè)的輸出是一系列的 SQL 計算腳本。最后,根據(jù)此業(yè)務(wù)系統(tǒng)目前的數(shù)據(jù)情況將數(shù)據(jù)模型設(shè)計為三層設(shè)計,基礎(chǔ)數(shù)據(jù),共享數(shù)據(jù),應(yīng)用數(shù)據(jù)。另外有獨(dú)立的維表數(shù)據(jù)層及系統(tǒng)數(shù)據(jù)層。以上各層的數(shù)據(jù),沒有進(jìn)行分庫分表(在 TiDB 的技術(shù)框架中,不需要進(jìn)行分庫分表來提升性能),數(shù)據(jù)生成后的一段時間(一般最長一個月)內(nèi)都會發(fā)生變更。由于采用的是增量更新,因此能很快的完成。唯一的缺點(diǎn)是:在系統(tǒng)初始化或者要修復(fù)很長時間段的數(shù)據(jù)時,由于索引的存在導(dǎo)致寫入速度較慢(相對無索引的文件表),但依然可以通過一定技術(shù)方案來規(guī)避。任務(wù)調(diào)度
目前 OPPO 的分布式調(diào)度系統(tǒng)是基于 airflow 開源項目搭建。同步任務(wù)與計算任務(wù)分屬獨(dú)立的 DAG,這樣雖然會多一些體力活(建立跨 DAG 依賴任務(wù)),但減少了不同類型/國家的任務(wù)的耦合度,方便了運(yùn)維,提高了數(shù)據(jù)服務(wù)的可用性。
調(diào)度系統(tǒng)的使用過程中,需要注意的點(diǎn)主要有:
1. 隊列數(shù)量。合理設(shè)置任務(wù)隊列的總數(shù),保證任務(wù)執(zhí)行的及時性及機(jī)器負(fù)載的平衡。
2. 多機(jī)器。由于系統(tǒng)的準(zhǔn)實(shí)時性,至少準(zhǔn)備兩臺計算和同步的物理服務(wù)器,以保證數(shù)據(jù)服務(wù)不中斷。
3. 優(yōu)化 airfow 本身。由于 airflow 本身存在一些問題,因此需要建立獨(dú)立于 airflow 的運(yùn)行監(jiān)控機(jī)制。比如通過對其 db 表的查詢來監(jiān)控其是否出現(xiàn)任務(wù)長時間阻塞等異常情況;另外需要定時清除歷史運(yùn)行記錄,以提升 airflow 的 web 服務(wù)體驗。
4. 時差問題。由于各國家地區(qū)數(shù)據(jù)庫存在時差問題,最后采用了腳本共用、調(diào)度分離的方式,減少耦合帶來的調(diào)度堵塞問題。遇到的問題
從最開始的 2.x 版本,到現(xiàn)在穩(wěn)定運(yùn)行的 2.1.13,主要遇到了以下幾個重要的問題:1. 提交事務(wù)大小限制問題
TiDB 本身是 TP 系統(tǒng),因此出于對事務(wù)穩(wěn)定性的考慮,對每次提交事務(wù)涉及的數(shù)據(jù)量大小有所限制。但由于項目本身每個任務(wù)涉及的數(shù)量有可能高達(dá)千萬行,因此需要打開TiDB的允許批量插入/刪除設(shè)置項。
TiDB 特意對事務(wù)大小設(shè)置了一些限制以減少這種影響:
單個事務(wù)包含的 SQL 語句不超過 5000 條(默認(rèn))。
每個鍵值對不超過 6MB。
鍵值對的總數(shù)不超過 300,000。
鍵值對的總大小不超過 100MB。
為了避免在運(yùn)行中出現(xiàn)過大事務(wù),在項目中采取以下配置:
SET SESSION TiDB_batch_insert = 1;SET SESSION TiDB_batch_delete = 1;set autocommit=1;同時由于索引的存在,在進(jìn)行數(shù)據(jù)的寫入過程中,過多的索引會加大事務(wù)的開銷,可以通過減少批次大小來降低單次事務(wù)(默認(rèn)是 20000):set @@session.TiDB_dml_batch_size = 5000;
2.?Proxy 連接失敗的問題
項目運(yùn)行過程中多次應(yīng)用端出現(xiàn) connect timeout 的情況,除去 TiDB Server 本來實(shí)例重啟的問題,haproxy 的連接超時時間設(shè)置過短,導(dǎo)致執(zhí)行時間稍長的 SQL 就會被斷開連接,這個時候需要調(diào)整 haproxy 的超時參數(shù):
timeout queue 30mtimeout connect 30m
timeout client 30m
timeout server 30m
3. TiDB Server 服務(wù)重啟問題
在項目過程中曾出現(xiàn)了多次 TiDB Server 服務(wù)重啟的現(xiàn)象,主要原因及措施如下:
TiDB Server 節(jié)點(diǎn)出現(xiàn)了 OOM。由于前期負(fù)載較低,將 TiSpark 服務(wù)直接部署在了 TiDB Server 節(jié)點(diǎn),導(dǎo)致有大查詢時經(jīng)常出現(xiàn) OOM 情況。后面將 TiSpark 服務(wù)和 TiDB Server 服務(wù)進(jìn)行了分開部署,并調(diào)整 OOM 相關(guān)配置為:oom-action: "cancel"。
- 機(jī)器故障問題。更換相關(guān)硬件設(shè)施。
4. 無法鎖表問題
為了解決“硬刪除”問題,對小表同步的時候采取了覆蓋更新的模型,即先刪除全表再寫入新數(shù)據(jù)。但由于目前 TiDB 沒有鎖表的功能(鎖寫或者讀),導(dǎo)致這個小小的空檔如果被其他任務(wù)讀取就會造成數(shù)據(jù)錯誤。雖然由于有任務(wù)依賴關(guān)系的存在,這種情況非常少發(fā)生,但在數(shù)據(jù)修復(fù)或者人工運(yùn)行任務(wù)的時候,還是會造成問題。
目前的解決方案是手工實(shí)現(xiàn)簡單的鎖表機(jī)制;另外就是可以使用臨時表然后 replace into 來解決。至于 TiDB 的系統(tǒng)級別的鎖表功能已經(jīng)在規(guī)劃中了。5. 與 Hadoop 數(shù)據(jù)湖的打通
項目受到了上級的一個重大的挑戰(zhàn):在 TiDB 中的數(shù)據(jù)無法與現(xiàn)有數(shù)據(jù)(主要以 hive 表形式存儲于 Hadoop 集群中)形成協(xié)同作用,項目價值會因此大打折扣。?
針對這個挑戰(zhàn),最開始打算再同步一份數(shù)據(jù)到 Hadoop 集群中,但這樣做其實(shí)是存儲的極大浪費(fèi),但在當(dāng)時似乎是唯一的辦法。在項目快接近尾聲的時候,發(fā)現(xiàn)可以通過在 TiSpark 集群上通過 thriftServer(最后進(jìn)化到使用 Livy 服務(wù))的方式,打通兩個體系的數(shù)據(jù),實(shí)現(xiàn) hdfs 和 TiKV 兩個數(shù)據(jù)源的混合查詢。最后也確實(shí)取得了成功并已經(jīng)服務(wù)了數(shù)個需求。相關(guān)的技術(shù)細(xì)節(jié)未來將以另外的文章進(jìn)行說明和分享。6.?臟數(shù)據(jù)處理
假設(shè)要插入 20 萬條數(shù)據(jù),但由于事務(wù)限制,系統(tǒng)只能 5000 行條提交一次,一共需要提交 40 次。
現(xiàn)在的問題是這 40 次可能在任一一次提交中失敗,這樣先前提交的數(shù)據(jù)就成了臟數(shù)據(jù),因此在重試的時候需要刪除這些數(shù)據(jù)后再做。因為數(shù)倉任務(wù)經(jīng)常有重跑的需求,而目前 TiDB 體系下沒有分區(qū)覆蓋,因此這是一個需要注意的點(diǎn)。運(yùn)行性能
目前系統(tǒng)上線約三個月,暫未出現(xiàn)任何較大的技術(shù)問題,運(yùn)行非常平穩(wěn)。以下是抽取的一些日常運(yùn)行數(shù)據(jù)或壓測數(shù)據(jù)供參考。1. 集群 OPS 和 QPS
在現(xiàn)有環(huán)境上,集群 OPS 最大可達(dá)到 61K,QPS 最大可達(dá)到 12.11K,查詢性能比較穩(wěn)定。
2. 高可用
主要基于 TiDB Server 之上負(fù)載均衡組件 Haproxy 和 TiKV 的多副本機(jī)制實(shí)現(xiàn)。3.?查詢穩(wěn)定性
上圖中,除了有部分整機(jī)信息聚合查詢外耗時較長(主要使用 TiSpark 組件)外,可以看到 99% 的查詢在 4S 內(nèi)進(jìn)行了返回,而 95% 的查詢在 104ms 內(nèi)返回,可以說性能是非常不錯。目前表的數(shù)據(jù)行量主要處于百萬到百億行級別,而且索引數(shù)量并不多,因此能獲得當(dāng)前的性能可以說超出預(yù)期。
升級 3.0.5
由于 2.X 版本在達(dá)到 250 萬個 region 左右出現(xiàn)了一些性能問題,IO/CPU 負(fù)載接近滿負(fù)荷。跟官方溝通后,我們決定升級到 3.0.5 這一穩(wěn)定版本。升級后,在沒有任何硬件變更的情況下,性能有了接近翻倍的提升,目前系統(tǒng)的核心資源都出現(xiàn)大幅空閑。
TiDB 技術(shù)體系的限制
項目結(jié)束后,現(xiàn)在回過頭來看 TiDB,我們認(rèn)為有以下一些比較重要的點(diǎn)需要注意:1. TiDB 首先是一個 TP 系統(tǒng)。即:目前來看 TiDB 主要是為了 TP 系統(tǒng)設(shè)計的,AP 方面的功能有待加強(qiáng)。事實(shí)上 PingCAP 已經(jīng)認(rèn)識到了 AP 的重要性,在 3.x 中,AP 的功能將會通過引入 TiFlash 組件而大大加強(qiáng),從而成為真正的 HTAP。2. TiDB 存儲成本相對 Hadoop 集群來說較高。目前至少要求是 SSD;加上未來 TiFlash 的引入,1 份數(shù)據(jù)將會存 4 份,存儲成本相對更大。3. TiDB 目前(截止 2019 年 9 月)尚未有 PB 級別的生產(chǎn)集群。因此可能直接應(yīng)用于海量數(shù)據(jù)的互聯(lián)網(wǎng)數(shù)據(jù)應(yīng)用可能會遇到其他一些問題。其他經(jīng)驗教訓(xùn)
1.?不要在一個可能包含很長字符串的列上創(chuàng)建索引
在 TiDB 建立索引可以極大提高查詢性能,但要避免在一個可能包含很長字符串的列建索引,否則在創(chuàng)建和使用索引時,都會花費(fèi)較大的代價。而且當(dāng)大小超過默認(rèn)的 3072 byte 時,TiDB 會報錯。
2.?確保開啟位置標(biāo)簽機(jī)制
當(dāng)一個機(jī)器部署多個 TiKV 實(shí)例,未提高系統(tǒng)穩(wěn)定性和可用性,一定要確保開啟了位置標(biāo)簽機(jī)制。前期部署集群服務(wù)時,雖然在 inventory.ini 文件中設(shè)置了以下內(nèi)容?location_labels = ["host"],但是后來發(fā)現(xiàn)并沒有生效,導(dǎo)致一個機(jī)器 down 了以后,集群中某些數(shù)據(jù)查詢出現(xiàn)了嚴(yán)重問題:
究其原因是因為位置標(biāo)簽機(jī)制沒有生效,導(dǎo)致同一個節(jié)點(diǎn)上存在同一個 region 的兩個副本(一共 3 副本),導(dǎo)致不能再正常對外提供相關(guān)服務(wù)了??梢酝ㄟ^ pd-ctl 確認(rèn)位置標(biāo)簽機(jī)制生效,如 config show all 的時候有如下內(nèi)容,代表已生效:如果沒有生效,可通過以下方式使得生效:config set location-labels "host"總結(jié):一臺機(jī)器部署多個 TiKV 實(shí)例的場景,要充分利用 location_labels 機(jī)制,將副本部署到不同的機(jī)器上,以增強(qiáng)系統(tǒng)的穩(wěn)定性。
3.?不支持三段式查詢
目前 TiSpark 還不支持如下的三段式查詢。
dbname.tablename.columnname如以下 sql 會執(zhí)行失敗:select dbname.tablename.columnname from dbname.tablename可以通過別名的方式加以解決:
select A.columnname from dbname.tablename as A4.?主鍵變更
目前在 TiDB 上進(jìn)行變更主鍵(增加或者刪除字段)是不被支持的,唯一的辦法只有重建表。這在某些場景會成為一個較為痛苦的經(jīng)歷。因此在表設(shè)計階段需要非常的小心,爭取一次做對。總結(jié)
項目以極小的人力投入較為成功的實(shí)現(xiàn)了預(yù)定目標(biāo),也陸續(xù)服務(wù)到了許多其他部門和項目,產(chǎn)生了良好的數(shù)據(jù)協(xié)同效應(yīng)。
從此次實(shí)踐中,我們認(rèn)為:隨著 AP 能力的加強(qiáng),TiDB 幾乎可以做為大多數(shù)亞 PB 級別數(shù)據(jù)應(yīng)用的存儲引擎。因為它的 HTAP 優(yōu)雅架構(gòu)能大大簡化運(yùn)維和開發(fā)人員的工作,讓他們集中到業(yè)務(wù)邏輯表達(dá)和處理上。
當(dāng)前的主流大數(shù)據(jù)技術(shù)主要源于互聯(lián)網(wǎng)平臺,大多在某些方面有妥協(xié),因而需要相互補(bǔ)充,導(dǎo)致系統(tǒng)整體架構(gòu)越來越復(fù)雜,最終讓運(yùn)維及開發(fā)門檻也越來越高,這也是目前沒有更好辦法的辦法。但最優(yōu)的數(shù)據(jù)系統(tǒng)架構(gòu)應(yīng)該是將業(yè)務(wù)邏輯無關(guān)的技術(shù)工作盡可能掩藏起來,交給數(shù)據(jù)庫引擎來打理。在這個話題上我看一篇非常不錯的文章大家可以參閱:《從大數(shù)據(jù)到數(shù)據(jù)庫》。
事實(shí)上,隨著越來越多的非互聯(lián)網(wǎng)業(yè)務(wù)越來越信息化,其系統(tǒng)數(shù)據(jù)增長雖然尚達(dá)不到互聯(lián)網(wǎng)動輒就PB級,但也很輕易的達(dá)到TB級別;這個級別的TP/AP系統(tǒng)技術(shù)選型其實(shí)還是一個較大的空白。目前看TiDB是該領(lǐng)域的一個非常好的選擇。
項目中 PingCAP 團(tuán)隊給予了大量的直接幫助,在此致謝!典型實(shí)踐
知乎?|?萬億量級業(yè)務(wù)數(shù)據(jù)下的實(shí)踐和挑戰(zhàn)
平安科技?|?核心系統(tǒng)的引入及應(yīng)用
北京銀行?| 1.?兩地三中心實(shí)踐?2.?在線縮容遷移
微眾銀行?|?數(shù)據(jù)庫架構(gòu)演進(jìn)及 TiDB 實(shí)踐經(jīng)驗
華泰證券?|?TiDB 在華泰證券的探索與實(shí)踐
豐巢?|?支付平臺百億級數(shù)據(jù)
美團(tuán)點(diǎn)評?|?深度實(shí)踐之旅
貝殼金服?|?在線跨機(jī)房遷移實(shí)踐
易果生鮮?|?實(shí)時數(shù)倉
小紅書?|?從 0 到 200+ 節(jié)點(diǎn)的探索和應(yīng)用
小米?|?TiDB 在小米的應(yīng)用實(shí)踐
58 集團(tuán)?|?應(yīng)用與實(shí)踐
愛奇藝?|?邊控中心/視頻轉(zhuǎn)碼/用戶登錄信息系統(tǒng)
Shopee?|?東南亞領(lǐng)先電商 Shopee 業(yè)務(wù)升級
轉(zhuǎn)轉(zhuǎn)二手交易網(wǎng)?|?TiDB 在轉(zhuǎn)轉(zhuǎn)的應(yīng)用實(shí)踐
同程藝龍?|?1.?票務(wù)項目??2.自研 TiDB 運(yùn)維工具 Thor?
今日頭條?|?核心 OLTP 系統(tǒng)
摩拜單車?| 1.?深度實(shí)踐及應(yīng)用?2.?在線數(shù)據(jù)業(yè)務(wù)
更多:https://pingcap.com/cases-cn/
創(chuàng)作挑戰(zhàn)賽新人創(chuàng)作獎勵來咯,堅持創(chuàng)作打卡瓜分現(xiàn)金大獎總結(jié)
以上是生活随笔為你收集整理的数据增量更新定义_TiDB 在 OPPO 准实时数据仓库中的实践的全部內(nèi)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 平流式初沉池贮砂斗计算_?初沉池、二沉池
- 下一篇: pyHook pyHook3 区别_一般