作者介紹

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ù)據(jù)平臺可以提供 T+1 及小時級別的數(shù)據(jù)計算服務(wù)；而實(shí)時數(shù)據(jù)服務(wù)主要適用于互聯(lián)網(wǎng)應(yīng)用場景，即大多行為數(shù)據(jù)生成后不再發(fā)生變化。這也是業(yè)界非常典型的基礎(chǔ)技術(shù)架構(gòu)。

技術(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 30m
timeout 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 A

4.?主鍵變更

目前在 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)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。