Catalyst 是一家總部位于紐約的 SaaS 創(chuàng)業(yè)公司，它提供了一個(gè)直觀且靈活的客戶成功平臺(tái)（Custom Success Platform），可幫助客戶成功團(tuán)隊(duì)匯聚客戶數(shù)據(jù)，洞悉客戶健康狀況，推動(dòng)客戶留存和業(yè)務(wù)增長。目前 Catalyst 已完成了 B 輪融資。

業(yè)務(wù)特點(diǎn)

Catalyst 整合了來自包括 Salesforce、Mixpanel、 PostgreSQL 等不同來源的海量數(shù)據(jù)，并將其納入 Catalyst 生態(tài)系統(tǒng)中進(jìn)行處理、分析并生成可參考執(zhí)行的數(shù)據(jù)洞察。

(相關(guān)資料圖)

Catalyst 主要處理三種類型的數(shù)據(jù)：事務(wù)型數(shù)據(jù)、只讀數(shù)據(jù)和時(shí)序數(shù)據(jù)。

事務(wù)型數(shù)據(jù)主要包括內(nèi)部創(chuàng)建的筆記和任務(wù)，以及從 Salesforce、Zendesk 和其他平臺(tái)收集的外部數(shù)據(jù)。

只讀型數(shù)據(jù)主要是指從 Jira 和 Zendesk 等平臺(tái)收集的工單數(shù)據(jù)。

時(shí)序型數(shù)據(jù)是 Catalyst 最重要和最棘手的數(shù)據(jù)類型之一。能處理這一類型的數(shù)據(jù)，也是 Catalyst 團(tuán)隊(duì)數(shù)據(jù)庫選型的重要需求之一。

以前的數(shù)據(jù)架構(gòu)及其瓶頸

Catalyst 最初使用 PostgreSQL 來處理從外部收集的所有數(shù)據(jù)。然而，隨著其業(yè)務(wù)的增長和數(shù)據(jù)源的迅速擴(kuò)大，PostgreSQL 無法跟上其需求。Catalyst 最初試圖通過將數(shù)據(jù)存儲(chǔ)為 JSON 文檔來彌補(bǔ)這一缺陷，但查詢性能受到了嚴(yán)重影響。

隨后，該團(tuán)隊(duì)轉(zhuǎn)向了 pre-caching 方案。他們采用 Elasticsearch 來存儲(chǔ)結(jié)果，以便更快地響應(yīng)客戶的查詢。然而，由于 Elasticsearch 不支持 SQL 風(fēng)格的 JOIN， Catalyst 必須在將所有內(nèi)容存儲(chǔ)在 Elasticsearch 之前進(jìn)行預(yù)計(jì)算。隨著存儲(chǔ)數(shù)據(jù)量增加，成本也急劇上升。

為了解決這些問題并拓展業(yè)務(wù)增長，Catalyst 團(tuán)隊(duì)決定重新設(shè)計(jì)整個(gè)數(shù)據(jù)處理和存儲(chǔ)系統(tǒng)。他們也是這個(gè)時(shí)候發(fā)現(xiàn)了新一代分布式關(guān)系型數(shù)據(jù)庫 TiDB。

數(shù)據(jù)層重構(gòu)

Catalyst 的新架構(gòu)分為五個(gè)數(shù)據(jù)層：數(shù)據(jù)攝取層、數(shù)據(jù)湖層、Spark 層、數(shù)據(jù)服務(wù)層和 Web 應(yīng)用層。原始數(shù)據(jù)通過攝取層進(jìn)入，并繼續(xù)進(jìn)入數(shù)據(jù)湖層。Spark 層組合數(shù)據(jù)對(duì)象，執(zhí)行預(yù)計(jì)算，確保數(shù)據(jù)有意義。數(shù)據(jù)服務(wù)層存儲(chǔ)所有預(yù)處理過數(shù)據(jù)以供客戶查詢。因?yàn)橹苯佑绊懹脩趔w驗(yàn)，數(shù)據(jù)服務(wù)層對(duì) Catalyst 來是最重要的，也成為 Catalyst 對(duì)新數(shù)據(jù)棧迫切需求的地方。數(shù)據(jù)服務(wù)層以下的各層不需要是實(shí)時(shí)的。然而，在數(shù)據(jù)服務(wù)層，Catalyst 需要亞秒級(jí)的延遲，以便客戶能夠迅速獲得結(jié)果。

新技術(shù)棧的必備能力

為了服務(wù)不斷增長的客戶，Catalyst 迫切需要一個(gè)具備以下特性的數(shù)據(jù)庫：

支持混合事務(wù)型和分析型工作負(fù)載。Catalyst 必須處理事務(wù)型和只讀數(shù)據(jù)，以及時(shí)序數(shù)據(jù)。他們需要的解決方案，無論是單一的數(shù)據(jù)庫還是一個(gè)數(shù)據(jù)庫組合，必須能夠同時(shí)處理交易型和分析型工作負(fù)載。

快速響應(yīng)。新的數(shù)據(jù)庫解決方案必須比 Catalyst 以前的解決方案更靈活，特別是在查詢速度和用戶界面性能方面。它必須在幾秒鐘內(nèi)對(duì)查詢作出反應(yīng)，并具有較低的更新延時(shí)。

處理復(fù)雜和高度定制的數(shù)據(jù)。Catalyst 的客戶可以在 Catalyst 平臺(tái)內(nèi)部以及 Salesforce 和 Zendesk 等數(shù)據(jù)源平臺(tái)上自定義許多設(shè)置，包括查詢、數(shù)據(jù)轉(zhuǎn)換和關(guān)系。與許多自定義字段集成的自定義對(duì)象的組合可能相當(dāng)復(fù)雜。新的解決方案必須能夠處理這種情況。

高可用。Catalyst 需要對(duì)他們的客戶作出敏捷的反應(yīng)。維持系統(tǒng)運(yùn)行是 Catalyst 的首要任務(wù)。一旦 Catalyst 宕機(jī)，客戶往往幾十秒內(nèi)就會(huì)投訴。因此，新的數(shù)據(jù)庫解決方案必須是高度可用的，以幫助 Catalyst 輕松應(yīng)對(duì)任何可能的系統(tǒng)事故。

水平擴(kuò)展性。可擴(kuò)展性是另一個(gè)必須具備的條件。Catalyst 處理的數(shù)據(jù)量非常大，而且數(shù)據(jù)量還會(huì)不斷擴(kuò)大。數(shù)據(jù)庫解決方案必須易于擴(kuò)展到巨大的規(guī)模。

數(shù)據(jù)強(qiáng)一致性。數(shù)據(jù)一致性是另一個(gè)要求。但考慮到有如此多的數(shù)據(jù)處理在流中進(jìn)行，要在整個(gè)系統(tǒng)中保持?jǐn)?shù)據(jù)強(qiáng)一致性是非常困難的。因此 Catalyst 可以接受最終一致性 （Eventual Consistency）。

TiDB 在性能測(cè)試中脫穎而出

Catalyst 在選擇新的數(shù)據(jù)庫時(shí)非常謹(jǐn)慎；他們調(diào)研了 TiDB 和另外兩種選擇： Aurora 與 AWS Timestream 結(jié)合，以及 YugaByte 與 AWS Timestream 結(jié)合的方案。這些選項(xiàng)是聯(lián)機(jī)事務(wù)處理（OLTP）數(shù)據(jù)庫和時(shí)序數(shù)據(jù)庫的組合。

為了測(cè)試這三個(gè)候選解決方案，Catalyst 采用來自內(nèi)部 Salesforce 和 Jira 實(shí)例的大型真實(shí)數(shù)據(jù)集作為負(fù)載，通過連續(xù)并行的方式運(yùn)行分組查詢。查詢響應(yīng)速度是最重要的評(píng)估標(biāo)準(zhǔn)之一。

TiDB 對(duì)典型查詢和聚合查詢的響應(yīng)時(shí)間都在幾秒鐘之內(nèi)，比其他候選解決方案快得多。同時(shí)，TiDB 對(duì)時(shí)序聚合查詢的表現(xiàn)也足夠靈活敏捷，7 秒內(nèi)返回結(jié)果。下表總結(jié)了一些關(guān)鍵的測(cè)試結(jié)果。

查詢的類型有：

典型查詢：客戶最感興趣的查詢。

聚合查詢：主要是基于復(fù)雜 JOIN 的計(jì)算。

時(shí)序聚合查詢： Catalyst 沒有在 Aurora 和 Yugabyte 解決方案上測(cè)試時(shí)序聚合查詢，因?yàn)闀r(shí)間有限，而且 TiDB 的性能對(duì)他們來說已經(jīng)足夠印象深刻。

關(guān)鍵測(cè)試結(jié)果

為什么選擇 TiDB？

查詢響應(yīng)快

根據(jù)查詢類型的不同，TiDB 的響應(yīng)時(shí)間比其競(jìng)爭(zhēng)對(duì)手快 10 到 60 倍。這是 Catalyst 選擇 TiDB 的最重要原因。

完美支持在線 DDL

TiDB 支持在線數(shù)據(jù)定義語言（DDL）操作，且不會(huì)影響在線業(yè)務(wù)。TiDB 提供無憂的模式變化，并允許 Catalyst 更快地添加或刪除索引，特別是對(duì)于大表。當(dāng)他們遇到慢查詢并需要快速添加索引以提高性能時(shí)，這尤其有用。通過在線模式變更，Catalyst 無須停下在線業(yè)務(wù)或預(yù)留長時(shí)間的維護(hù)窗口。

HTAP 混合負(fù)載數(shù)據(jù)庫

TiDB 是一個(gè)混合事務(wù)和分析處理的（HTAP）數(shù)據(jù)庫。在 Catalyst 評(píng)估的三個(gè)候選項(xiàng)中，TiDB 是唯一一個(gè)技術(shù)?？梢酝瑫r(shí)處理對(duì)象數(shù)據(jù)和時(shí)序數(shù)據(jù)的數(shù)據(jù)庫。這不僅非常高效，而且還為 Catalyst 節(jié)省了大量的時(shí)間、精力和金錢。

水平擴(kuò)展性

TiDB 具有高度的水平擴(kuò)展性。這完美地滿足了 Catalyst 應(yīng)對(duì)不斷擴(kuò)大的數(shù)據(jù)量的業(yè)務(wù)需求。TiDB 還支持計(jì)算和存儲(chǔ)資源分離，這使得 Catalyst 可以單獨(dú)擴(kuò)展這兩種資源，也有助于控制成本。

快速的容災(zāi)恢復(fù)

TiDB 使用 Raft 共識(shí)算法來確保數(shù)據(jù)的高度可用性和安全復(fù)制。TiKV 是 TiDB 的存儲(chǔ)服務(wù)器，數(shù)據(jù)在 TiKV 節(jié)點(diǎn)之間進(jìn)行冗余復(fù)制，并放置在不同的可用區(qū)域，以防止機(jī)器或數(shù)據(jù)中心故障。這確保了 Catalyst 的系統(tǒng)正常運(yùn)行時(shí)間。此外，TiDB 提供了多種災(zāi)難恢復(fù)方案的選擇，每一種方案都適用于不同的場(chǎng)景，成本靈活。

全面的托管服務(wù)

Catalyst 有一個(gè)小的 DevOps 團(tuán)隊(duì)，所以他們需要一個(gè)完全托管的數(shù)據(jù)庫解決方案，以減輕團(tuán)隊(duì)的負(fù)擔(dān)并控制成本。TiDB 的全托管服務(wù) TiDB Cloud 滿足了這一需求。

云中立

Catalyst 的服務(wù)采取跨云部署的方式以保證其業(yè)務(wù)的靈活性：一些工作負(fù)載在谷歌云平臺(tái)（GCP）上運(yùn)行，一些在亞馬遜（AWS）上運(yùn)行。因此，他們需要一個(gè)支持多云部署的云數(shù)據(jù)庫解決方案。TiDB Cloud 正是這樣的解決方案。

總結(jié)

Catalyst 之前主要使用 PostgreSQL 來處理客戶數(shù)據(jù)，但系統(tǒng)很快遇到了瓶頸。他們重新設(shè)計(jì)了數(shù)據(jù)架構(gòu)，并引入新的數(shù)據(jù)庫來為客戶提供數(shù)據(jù)。通過采用 TiDB, Catalyst 能夠提供更好的客戶體驗(yàn)，包括更快的查詢響應(yīng)、更有彈性的系統(tǒng)、更強(qiáng)大的數(shù)據(jù)存儲(chǔ)、處理和分析能力。Catalyst 還降低了它們的整體維護(hù)成本。

關(guān)鍵詞：