雲智慧（北京）科技有限公司柳東浩
最近互聯網都漲思維了，移動互聯網更是得瑟地不行，在風口上嗷嗷地飄，PE/VC沒事兒就就往那兒蹭，而那物流網的天兒還剛矇矇亮，這就是我們這些攻城獅所處的有點兒霧霾的時代。這年頭攻城獅總有不寐的夜，爲啥糾結呢？還不是讓數據給鬧的。這裏一篇小文只是一盤關於數據的小菜，一款關於數據的管絃譜，怎麼演奏，那得看自己，看情況，不解決啥實質問題，該鬧還得鬧，該糾結還得糾結，誰讓你拱呢。
說倆詞兒
數據庫：就叫D吧，就是你可以把東西放D那兒，回頭兒你還可以從D把東西拿出來。跟火車站旁邊那個存包的一回事兒，而且也得要身份證，別忘了哈。
機構：提供一個或多個服務的一組機器，他們協同完成一大類事。
下面就嘮點正嗑兒，說點行話吧。
問題的產生
任何存儲介質，其存儲容量總歸是有限的。因此，隨着業務的發展，甚至突發的業務高峯，水平擴展能力總是不可迴避的挑戰。這也必然要求數據是分佈式存儲的，而解決問題的基本指導思想也必然是分而治之，否則那電費、流量費恐怕就不知道翻多少倍了，要命的是生意沒法做了，這年頭慢的東西就會被淘汰。
數據路由概念
在分佈式環境中，對於一個請求而言，總是要決策到哪裏去讀/寫，這就是數據路由問題，也是一個基本問題。寫操作決定了讀操作，因此寫操作中針對具體的設計目標如何分而治之就成爲了問題的關鍵。但是反過來說也是正確的，讀的需求決定寫的方式，而且應該這樣考慮，因爲寫的目的不僅僅是存在那裏，更是要考慮讀的過程如何發揮價值。換句話說，數據路由首先要解決寫到哪裏和如何寫的問題，但它是爲如何讀而準備的。關於寫的設計應當是服從於讀的方式、方法、形式和策略。就像接力賽一樣，你把接力棒放在前面隊友的手裏就是寫，他接到了，跑了，就是讀，當你遞過去的時候你在想什麼？對了，就是應該像你此刻那樣想。當你在使用、架構或自研某種廣義數據庫的時候，你首先考慮接棒了嗎？當然這個問題涉及面更廣，這裏僅僅侃侃“到哪裏”的問題-雅名“數據路由”。老是做海底撈，憋不？別淹着，當是潛伏哈。
問題的內在特質與歸結
設：
請求=R
服務=S，可以是一個服務實例，也可能是一個服務集羣
顯然問題可以歸結爲集合R到集合S的映射，數學上就是一個函數，f(R)=S。
要求對於任何特定的請求Rx，必須總是映射到特定的Sx，不論它們的元素如何變化，這就是問題的內在特質。你不能說，我存了個包在XX，到時候你讓我到YY去取，取完了那警察來了你替我哈。
挑戰
假定我們已經實現了一種規則可以完成R到特定S的映射，該規則就是數據路由要實現的，但是隨着業務的發展，S必然會變大，這時候挑戰就來了，怎樣的規則才能動態地適應這種改變呢？這就是挑戰所在。
數據在存儲上有時會有一個要求，那就是要力求數據的均衡分佈而不是Skew，這就意味着特定的S存儲的數據需要再分配，這也內在地要求數據路由具備及時調整映射的能力。聽着有點高大上，簡單類比，可以這麼說，想象一個二維座標系，X軸是數據系統的所有硬盤，Y軸是各自保存的數據量，畫一個曲線，如果它看上去像個心電圖，那是有病啊，應該相對平直纔好（跟現實相反哈）。你做架構的時候，在這點上，那就是要把它整地“沒有生命體徵”，一條線倍兒值，你厲害。拿HADOOP來說，要是BLOCK都集中在某些服務器上，其它都基本閒着，那就像一個人五官都糾結在一起，跟包子一樣，美不？答案正確，軟件設計的美與現實世界的美學它就那麼任性地統一着。要不然，那結果就是小瀋陽穿那蘇格蘭格裙的Style，跑偏了。
路由方式
通常路由都是通過制定一個這裏統稱爲Key的東西來指路，不同的產品叫法不同，如Key, Rowkey, Field等等。無所謂，皮兒不同，餡兒是一樣的。按照拱城獅看世界的極簡風格來看，這個世界就是兩根手指頭就能表達，串和數，剩下的都是關係。這個Key，別管他穿啥馬甲，裏子就這兩樣。
完全映射
映射執行機構，即數據路由機構，包含R和S的所有元素，構成全映射。缺點在於需要更大的內存來提供高速的路由服務。並且要求快速地從大量的元素中找到特定元素。這就像你有點事到學校班裏接你家少爺（假定你不知道在哪個班），到學校了，人家給你一摞花名冊，你就一個名字一個名字地看，要是像字典一樣排序了還好，但你也得掃一遍。這個比擬的要點在於，所有的名字都在花名冊上，然後由一個具體的名字找到班級-119，最後人家告訴你119班在哪兒，看到沒，“到哪裏”，路由就是給你指路的警察美女，人家那服務最後就是一句話，給你指路，別沒話找話哈。
範圍映射
R經過某種換算得找到一個可落座的範圍，再從範圍映射到S。優點在於數據路由機構可以大大節約存儲，但要求快速的換算。HBase算是這樣的一個例子，它通過把按字典順序排序的rowkey爲標識的行數據用基於3級B-Tree的LSM Tree組織起來來實現行的快速定位，找到Region就是範圍的映射。MongoDB也有對這種方式的支持。你要是靠把治療帕金森的藥推銷到兒童醫院問鼎年度銷售冠軍，那你絕對是一罐愛膚樂油，讓人醉了，顯然範圍沒有overlap。
哈希
該方式力求數據的均勻分佈，性質上基本就是隨機撒，對於大塊讀取連續的或一個範圍的數據是不利的。MongoDB支持根據哈希值來分散數據。
知道北京火車站吧，如果把人映射到進站口，那就是這種方式，一個人從那個口進，沒什麼約定。至於在軟件的世界裏，中間怎麼哈希的，那方式多了去了。如果人都擁擠到特定的口，那就是北京站的管理層哈希砸了，它肯定會想法兒把它弄勻乎了。如果你一個公司的一羣人真被哈了，比如說，你規定每個人的身份證號的尾數對應着進站口號，那就得化整爲零進去，進去後想再化零爲整，那就得再做些功，所以也有缺點，如果你是具有獨特健身pattern的導遊。
不可變S的映射
最常見的就是hash-mod方式，最大的缺點在於不具備擴容能力。優點在於路由過程資源佔用很小。現實中也有存在，比如說，但凡說集羣的shard/partition等數值不可變的情況都屬於此類。ElasticSearch大體上就是屬於這種情況，對於一個Index，一旦建立了，就不能改變其shard數量。可實操的擴容方法就是建立更多的Index，但這要求在Index之上建立更上一層的路由。交警美女上面還有個交警大叔呢，你得先約他，記着哈，別急。
其實沒有什麼最好的方案，一切都取決於需求的定位或設計目標是什麼，簡而言之，結果導向的。比如說，重寫輕讀和重讀輕寫在整體設計上就會意味着不同的指導意義。側重順序讀還是隨機讀也會影響整體設計，當然適用的場景也就有分別了。說俗點，那你得爲接棒的服務，遞的時候就得想着接。
時間是個人們杜撰的偉大概念，基本上信息系統都離不開，而且讀的時候基本上都跟它有關，還而且，經常關注的就是最近一段時間的東西，別說你就愛吃蔫兒菜啊。但是磚家說了，如果你給這樣一個系統做個心電圖，那圖的節奏看着可能就跟着雷劈了差不多。這只是一個時間維度。
人，他貪啊，其實現實世界的需求是，點、線、面、體甚至更高維度的信息可能同時都需要。這裏以時間線爲例，提一丟丟拙案，那些造NoSQL或者別的什麼東西的大牛們，對於那些人家認爲新鮮的，能不能把那個叫Replica的隨便設個想要的數量，甚至於智能地自主決策，別一刀切行不，這樣起碼併發壓力圖看着不雷劈了。對，最新的大片兒你得多備幾份，看的人多嗎，當口的生意你不做，年終了你想讓人家抽富士蘋果啊，我看中。
實時監測
在整個數據服務體系中，對CPU、內存和磁盤空間的監測是必要的，至少它可以提醒人工擴容的必要性，以及壓力或數據量的不均衡性，以便採取應對措施。廣義講，任何分佈式系統，如果沒有一箇中樞神經系統，比如說NameNode,HMaster和Mongos等（在這一點上，目前他們做的可能還不是特別好），掌握着各個節點與讀寫路由決策相關的關鍵指標，那就只能無理決策了，閉着眼睛拍腦門，“反正我沒看見，都在那了，自己看”。畢竟每個節點時刻在發生着變化，刻舟求劍必然淹死在紅海里，只有動態閉環反饋才能保持均衡。一碗水端平，難，你造吧。
浮雲下的展望-智能擴展
近兩年，雲計算甚囂塵上，也漲翅膀了，會飛了。如果你的數據系統存在一個全面的健康監測機構，使得通過一些規則設定實現全自動的擴展成爲可能，那就有點智能了。例如在一定條件下，通過Python調用OpenStack API完成虛機和數據庫等的安裝、配置、優化及初始化。這可能是當下雲服務商努力的方向之一。記着，如果你的產品設計能讓人變懶，那就對路了，信不，你孫子肯定比你懶。從呱呱墜地開始一直到一縷青煙，人的一切的事，就是通過一個click，一個手勢，一句話，一個眼神甚至一個念頭，立馬變成現實，風就是往這兒吹地。要不你到盤古大廈樓頂吹吹風，來個真實體驗。
結束語
在當今數據量Big bang的時代，如果您有幸致力於自主研發或使用數據處理系統，希望這碟小菜您還覺得有一丟丟嚼頭，浪費你視覺神經細胞了，我可沒@U奧。
關於作者：
柳東浩（David），雲智慧軟件架構師，15年軟件研發、技術團隊管理經驗，對大規模、分佈式、高併發、高可用、高可靠和水平伸縮系統的設計和實現有豐富的經驗。有多年英文環境的工作經驗，對遺傳算法、聚類、神經網絡等算法有所研究。對以HADOOP爲核心的大數據技術、NoSQL、搜索等擁有豐富的理論和實操經驗。在雲智慧主要負責通過字節碼技術實現非侵入式的JAVA後臺的性能監控和Android APM SDK的研發，目前負責雲智慧移動研發工作。
