本文作者：wisecrazycat。更多內(nèi)容請關(guān)注：Map_technology。
簡介
LBS云存儲云檢索系統(tǒng)是百度地圖針對LBS開發(fā)者，結(jié)合已有的地圖API和SDK服務(wù)推出的平臺級服務(wù)，通過開放服務(wù)端存儲，計算能力，提供海量位置數(shù)據(jù)實時存儲、檢索、展示一體化的解決方案。
開發(fā)者無需考慮軟硬件部署和配置、升級和擴展，數(shù)據(jù)安全，數(shù)據(jù)一致性，檢索性能，索引結(jié)構(gòu)設(shè)計，實時更新等復(fù)雜的技術(shù)問題，僅通過云存儲API或LBS云數(shù)據(jù)管理平臺就可以將數(shù)據(jù)托管到LBS云，完成海量數(shù)據(jù)存儲，獲得高性能大數(shù)據(jù)檢索的能力，從而能夠把更多精力集中在自身的業(yè)務(wù)邏輯上。
一、系統(tǒng)特點
1. 開放免費大量存儲空間：支持千萬級數(shù)據(jù)(單個數(shù)據(jù)表百G)存儲。
2. 支持高效的地理空間檢索：采用GeoHash算法，QPS每秒上萬。
3. 高實時性：數(shù)據(jù)更新到存儲推送到檢索端耗時在秒級別，可以支撐實時性要求比較高的業(yè)務(wù)。
4. 高可用性：存儲可用性4個9，檢索可用性5個9以上。
5. 很強的靈活性：允許自定義數(shù)據(jù)列，列屬性，字段是否參與檢索等
6. 數(shù)據(jù)安全：包括safety和security，所有數(shù)據(jù)都有3份副本復(fù)制，不會丟失數(shù)據(jù)。數(shù)據(jù)隔離，用戶A不能訪問用戶B的數(shù)據(jù)，用戶憑唯一的AK獲取自己的數(shù)據(jù)。
二、初期架構(gòu)以及演化史
主要模塊介紹：
控制服務(wù)：負(fù)責(zé)鑒權(quán)轉(zhuǎn)發(fā)，流量控制，配額控制。所有LBS云對外提供的服務(wù)都通過控制服務(wù)接入。
存儲接入層：解析轉(zhuǎn)發(fā)存儲請求，可根據(jù)用戶的設(shè)定，控制更新的數(shù)據(jù)是否需要發(fā)布到云檢索。
檢索接入層：解析檢索請求，從存儲集群讀取數(shù)據(jù)的列屬性，轉(zhuǎn)化成AS可解析的請求，向后端檢索集群發(fā)起檢索，根據(jù)獲取的索引內(nèi)容，從存儲集群中讀取數(shù)據(jù)的詳細(xì)摘要返回。
AS：高級檢索單元，將接受到請求經(jīng)過DA分析后進一步發(fā)送到基礎(chǔ)檢索集群，并把結(jié)果歸并過濾后返回。
DA：query解析(包括不同粒度分詞，where + what解析等)
AC：路由，負(fù)責(zé)將檢索請求/增量庫更新消息路由到指定的基礎(chǔ)檢索單元。
建庫集群：負(fù)責(zé)定期將全量庫與增量庫合并推送到基礎(chǔ)檢索集群以及增量更新數(shù)據(jù)的轉(zhuǎn)發(fā)。
云分析：為用戶提供用戶檢索行為分析報告
云展示：對檢索、分析數(shù)據(jù)可視化
問題1：云存儲保證用戶數(shù)據(jù)互相隔離，A用戶不能訪問B用戶的數(shù)據(jù)，但云檢索中索引全量庫的設(shè)計是：將所有用戶數(shù)據(jù)的索引混建在一起，在取得倒排拉鏈后，再根據(jù)用戶的唯一標(biāo)識user_id做過濾，這種設(shè)計使得某用戶的檢索會被其他用戶的數(shù)據(jù)增長影響性能變差，更嚴(yán)重的是會導(dǎo)致一些用戶的數(shù)據(jù)由于拉鏈過長截斷而一直沒有機會返回，隨著接入LBS云的用戶越來越多，這種索引沒有分離的設(shè)計對用戶體驗造成了極大的傷害。
目標(biāo)：
1. 全面隔離用戶，用戶之間互不干擾，有各自獨立的索引區(qū)間。
2. 重構(gòu)后性能要比現(xiàn)狀好，解決系統(tǒng)性能不合理地變差問題。
方案：
1. 重新設(shè)計了全量庫索引結(jié)構(gòu)，提供了支持區(qū)間有序，允許全局有重復(fù)key的基礎(chǔ)索引文件結(jié)構(gòu)，提供了區(qū)間二分檢索的查詢。
2. 采用新的keyfile結(jié)構(gòu)的同時，設(shè)計了Table.meta二級索引結(jié)構(gòu)，通過記錄(起始位置，長度) 來維護每個用戶對應(yīng)的索引區(qū)間。
上圖中table A B C ....的索引內(nèi)容完全分離，互不影響?；A(chǔ)檢索集群的平響從12.7毫秒降到了7毫秒，檢索平響超過100ms的長尾比例從原來的2.82%，12%減少到1.58%，5.89%，徹底解決了用戶檢索效果的問題。
問題2：初期的檢索架構(gòu)性能非常差，一次檢索需要幾百毫秒，而主要瓶勁在接入層。其實接入層本身的邏輯非常簡單，但由于需要多次訪問存儲集群而且是PHP模塊，db-php-driver耗時幾乎是db-c-driver的10倍，于是首先對檢索做了C++化的重構(gòu)改造，與存儲集群的連接由短連接改成長連接，平響降到了幾十毫秒。
問題3：之前的檢索架構(gòu)，檢索接入層從倒排拉鏈獲取到數(shù)據(jù)id后，會查存儲集群獲取摘要詳情，而由于存儲性能上的局限性，一次摘要檢索的耗時在20+毫秒。分析過LBS云檢索的用戶流量后，我們發(fā)現(xiàn)其實大量的query都集中在對某些數(shù)據(jù)熱表的訪問上，于是我們引入了cache。
目標(biāo)：
摘要檢索平響從20+毫秒優(yōu)化到10毫秒。
方案：
使用高性能的redis集群做cache。
為保證檢索接入層的性能，未命中的數(shù)據(jù)同步到cache采用異步的方式，將 message發(fā)送到消息系統(tǒng)即返回，之后由di-sync di-manager配合完成cache的更新。
為了減少訪問cache的次數(shù)，我們將存儲集群中存儲用戶數(shù)據(jù)相關(guān)的三張表合并成兩張表存到cache中，減少了一次請求。
如何保證時序性。設(shè)計di-manager時，更新同一條數(shù)據(jù)id的message只會被一個線程順序執(zhí)行，更新不同數(shù)據(jù)的操作可以并發(fā)執(zhí)行。由于數(shù)據(jù)都是全字段帶版本信息更新，保證了數(shù)據(jù)不會因為消息到達順序的不同而出現(xiàn)不合理的更新。同時，我們也設(shè)計了轉(zhuǎn)發(fā)層，根據(jù)請求中數(shù)據(jù)的唯一標(biāo)識id，做一致性hash，將請求發(fā)送到后端的實例，構(gòu)建了一個非常方便水平擴展的集群。
重構(gòu)優(yōu)化后的架構(gòu)參考下圖：
問題4：在v2版本后，云存儲引入了批量操作，用戶可方便靈活地對一個位置數(shù)據(jù)表進行各種批量操作，包括：上傳多條數(shù)據(jù)，刪除多條數(shù)據(jù)，刪除多個自定義擴展列，更新數(shù)據(jù)(如字段、字段屬性、字段對應(yīng)的值等)等，“批量操作”接口采用異步方式推送到檢索，但在引入強大功能的同時也引入了不穩(wěn)定因子。我們發(fā)現(xiàn)：
用戶的一些批量操作會使得原本控制層的配額保護機制失效。
系統(tǒng)并沒有恰當(dāng)?shù)牧髁靠刂?，?dǎo)致用戶觸發(fā)大量的異步任務(wù)時，對建庫集群造成了非常大更新的壓力，消息系統(tǒng)中出現(xiàn)了嚴(yán)重的數(shù)據(jù)堆積。
于是，我們結(jié)合用戶的默認(rèn)配額，對批量操作做了配額的管理限制，超過配額的批量上傳任務(wù)會被直接丟棄。根據(jù)后端的處理能力對批量任務(wù)做了合理的流量控制，避免了批量任務(wù)對實時更新數(shù)據(jù)流的影響，后續(xù)我們還會進一步的優(yōu)化。
三、總結(jié)
以上內(nèi)容是在對之前的架構(gòu)進行系統(tǒng)分析后，做過的一些優(yōu)化迭代演進，未來我們還會對系統(tǒng)的實時更新能力做進一步的擴展提升，也會結(jié)合業(yè)務(wù)擴展存儲內(nèi)容(支持線面等的存儲)以及相關(guān)的檢索需求，為開發(fā)者提供存儲內(nèi)容更豐富、更可靠、檢索更高效的系統(tǒng)。
{{item.content}}