2018 年天貓雙 11 全球狂歡節已正式落下帷幕，最終成交額定格在 2135 億元，物流訂單總數飆升至 10.42 億單，再次刷新歷史記錄。與往年的雙 11 不一樣的是，爲解決龐大的包裹量，數字化和精細化成爲行業關鍵詞，第十個雙 11，是在智能物流骨幹網協同下，全行業資源優化的一次大考，和依託 IoT 技術的一場新物流大練兵。github
正如菜鳥網絡 CTO 谷雪梅在 ArchSummit 2018 全球架構師峯會「菜鳥智慧新物流專場」致辭時所說，如何把平臺、架構、算法、數據和業務場景融合在一塊兒，爲物流行業降本提效，同時促進行業技術不斷向前發展，這是菜鳥技術人，也是整個智慧物流行業人最重要的使命。算法
那麼，如何讓無處不在 AI 技術在傳統物流領域發揮必要的價值？柔性自動化這個新興的技術方向將爲電商物流帶來怎樣的變革？自動化倉儲系統的技術和應用的算法又是什麼？如何依靠數據、技術來進行統籌安排，打造敏捷供應鏈？帶着對這些問題的解答，菜鳥網絡研究員徐盈輝、資深技術專家朱禮君、裘民民、許俊開始了這場佈道。數據庫
如何思考物流行業中人工智能的落地？
只有當物流資源變得可視、可預測、可控制，並能獲得有效反饋，這時的物流體系才能真正實現降本提效。其中，資源共享是關鍵。菜鳥經過創建協同化 IT 技術平臺，共享資源，並在物流網絡中優化節點與鏈接，最終促進物流行業共同發展。編程
降本提效須要減小包括生產過多、生產過快、生產過晚等無謂資源浪費。菜鳥網絡研究員徐盈輝在演講中提到，對於雙 11 所需求的大量商品，菜鳥會對消費者進行理解，並作到庫存合理分佈，在合適地方存放適當貨量來避免必定的資源浪費。緩存
值得注意的是，包裹從網點由快遞員送到消費者的過程，是一個高頻動態環節。爲此，菜鳥圍繞倉儲物流智能化，優化了包括銷量預測、實效預測、智能交互、機器視覺等技術。但因爲數據量龐大，須要經過機器學習算法讓消費者感知包裹位置，根據快遞員的配送狀況作合理的預測。此外，快遞包裹的配送會根據目的區域作包裹再組織，進行合理 ETA 預測，並經過快遞員的派送習慣，預測包裹時空特徵，使得預測模型訓練達到預期效果。安全
現現在，全部行業都須要讓消費者知情。當快遞員與消費者聯繫溝通時，這在無形中增長了快遞員的工做負荷。包裹放置地點、包裹配送時間等問題都是需與消費者互動才能得到的時空特徵，爲此菜鳥圍繞 POI 體系創建了 AOI 層次性地址知識圖譜，經過智能交互機器人與消費者互動解決了這個問題。性能優化
對於物流在線決策的內容，徐盈輝講解道，之前倉庫大量揀選做業單都是人工完成，這樣大大限制了算法在海量空間裏作組合的效果。菜鳥打破了這個邊界，讓全部訂單在倉庫裏更合理的組合並預測將來訂單。同時，對訂單的商品選擇最合理的包材打包以此來下降成本。比方說，有 N 個商品，已知這些商品的三維尺寸，包材優化要作的事情就是根據這些商品的三維尺寸信息，計算一個最優裝箱順序、合理的朝向、正確的位置，找到一個包材，最終它的成本最小。服務器
而在運輸優化中常常考慮的一個問題是：貨物如何以最短距離，最合理線路運到目的地。這是一個複雜的帶有時間窗約束的多商品流優化問題，制定合理的優化目標就是但願使用較少車輛，包裹走最短的距離，最小的空載率，這是一個超大規模且不可追溯的混合整數規劃問題。經過合理的問題拆解使得問題能被有效求解且可解釋。網絡
全流程優化的終極夢想——柔性自動化
中國勞動力總人口減小、電商倉庫大、存儲商品多、時效要求高等挑戰推進着物流行業自動化的發展。對此，菜鳥網絡資深算法專家朱禮君解釋道：
- 電商訂單變化快，業務變化也很是快。菜鳥經過人工智能技術，使得更多機器人解決物流自動化問題；
- 柔性自動化倉庫的機器人靈活，容易擴張及改造；
- 柔性自動化控制邏輯很是複雜，這是一個缺點也是優勢，這樣能夠把全部智能移到雲端，便可進行性複製。從某種意義上來講，這也把難問題統一解決掉了。
在自動化倉庫裏面的作長距離搬運基本做業單元 AGV，能夠從倉庫裏面任意兩點之間進行搬運工做。在倉庫相對可控一個環境，其導航定位方式能夠設置多種：貼二維碼、激光導航、視覺導航等。而比較成熟的自動化 AGV 系統，機器小車只需頂起貨架，移動到工人處，工人再根據系統指示揀選對應的商品，單個揀選站故障也不會影響其他揀選站。
值得注意的是，在電商倉庫中貨架能夠動態分佈，並實行多區並行方案，同一個訂單的全部商品到達合流區域纔可出庫，全部過程均自動化完成。菜鳥自動化倉儲系統架構的最核心的調度引擎是調度算法，包括訂單生成、揀選任務生成、合流區調度、多區協同調度等等都是由調度引擎完成。
如何爲同時在同一倉庫的機器人規劃行駛路徑？假設兩個機器人都從 A1 到 A2，若都走最短路徑時則會相撞，這時只能其一避讓纔可避免，爲實現這個過程菜鳥對傳統 AI 算法作了改造，在考慮機器人的加速度、減速度的基礎下進行智能路徑規劃。
在演講中，朱禮君還爲你們分享了 AGV 網絡掉線的例子：在很窄的通道中堆滿機器人的「堵車」情景，其學術名詞爲死鎖。那麼提早避免死鎖，或迅速恢復異常狀況，這可能比在正常狀況的算法還要重要。
對此，菜鳥總結了一套準則：全部模型都是理想化的模型。起初物流行業的目標就是優化整體吞吐量，調度模型也最簡單，但這跟實際狀況並不相符，並須要不斷的自我質疑和假設。因此在最終的模型中，還需考慮目標各區域做業的均衡，從實踐出真知，纔是真正的物流優化。
雙 11 物流能力應當如何沉澱？
雙 11 是一個系統工程，須要極多人力物力的準備，而在雙 11 大促以前，大數據最重要的使命就是幫助雙 11 作一個肯定性預計和預測。
菜鳥網絡資深數據技術專家裘民民進一步分析：首先針對雙 11 大促，菜鳥須要預測物流單量來決定後續社會化運力與倉儲面積的籌備狀況。但單量預測影響因素很是之多，除了每一年的歷史數據以外，更多的是平常變化的一些趨勢。此外，預售工做的啓動也一樣能夠幫助迭代優化單量的預估。
其次，整個訂單的產生都須要通過商家的 ERP 系統進行處理，這條交易鏈導致整個信息的交互流過程變得十分複雜，這就涉及到商家行爲分析。不只如此，因爲包裹量巨大，單量的實際倉庫面積、網絡流速、訂單出庫時間等等都會涉及預測與決策。爲此，菜鳥從預測模型到優化模型，肯定每一個環節物流資源，把它工序化，並根據預測評估能夠承受的行業物流成本，決定物流資源的總體佈局。
一旦雙 11 開始，菜鳥的首要任務就轉變爲，從技術角度監控包裹和物流訂單以及實際做業的具體狀況，所以菜鳥對實時計算和實時監控都有着很是高的需求。
雙 11 當天菜鳥但願基於實時計算數據估計出總的訂單量。但因爲歷史數據的有限性，導致去年訂單量乘以比例的預估方式不切實際。所以菜鳥借鑑在機器學習裏的特殊工程概念，把實際發生曲線和歷史數據曲線相互作一些交叉和拼接，並進行動態調整，將這兩步疊加起來才能預測一個比較好的結果。
對於比較抽象的數據分析，第一步爲定位步驟，對應一個 top 指標，找到影響指標波動的細粒度維度。當肯定定位之後，就能夠開始第二步——推理，好比定位到某地，其爲什麼發生如此變化，諸如此類爲一個推理過程。
那麼這些步驟能夠經過技術解決嗎？能夠。對於定位來講，本質上就是找最關鍵組合，並計算出它對整個指標的貢獻度。推理層面則須要找到指標與事件之間的關係，而後把歷史事件與數據變化經過學習的方式找到，造成知識圖譜，將來發生變化時就可較快找到數據變化對應的背後緣由，並在很大程度上提升分析效率。
10 億包裹背後的技術定義者——菜鳥智慧新物流
菜鳥智慧新物流究竟是什麼樣？菜鳥網絡資深技術專家許俊在演講中從總體平臺架構和工程技術角度進行了闡述。
汗水物流時代向智能物流新時代的演進，變化背後承載着這樣的技術演變：信息化階段與數字化階段。早年大型物流園區裏，單個機房須要上百人來運維，如今幾萬臺服務器僅需一人管理。智慧新物流的體系結構究竟是什麼？首先要有一個智能化基礎設施。其次，須要在不少核心的做業環節，實現柔性自動化的技術體系。最後，面向物流技術的前沿儲備做爲體系結構的基礎服務層。
對於信息化架構，菜鳥的技術站和總體運維，在過去很長時間與阿里共享一個機房，並與淘寶、天貓不少技術一脈相承。這會帶來一些新問題，第一，對於物流系統，資源的彈性會面臨挑戰；第二，物流系統搭建在在單機房中，這就演變爲一個單點問題，但這並不具有多地容災的能力；第三，全球化購買背景中，海外部署的基礎架構也會發生大變化。
在這樣背景下，菜鳥從 2017 年開始研發混合雲架構，經過研發和運維繫統線上線下一體化，保證研發體系的一致性。經過高速專線的方式，讓雲上 VPC 和 IDC 實現網絡高速通訊，實現一套代碼多套部署，實現應用系統編程過程。
針對數字化架構，許俊基於技術角度闡述了關於物流領域藉助數字化待需解決的問題：第一個維度，不管是物品仍是裝備，其數字化爲主動性仍是被動性的問題；第二個維度，物流領域的核心要素所存在的運動環境問題；第三個維度，物品是運動仍是靜止，好比某位置種 AGV 不斷運動的狀況是遇到網絡問題，仍是掉線。而其數字化思路就是基於數字化技術模型影射到中間技術架構，從感知層、鏈接層再到應用層，最終數據與上層物流、供應鏈業務系統進行數據迴環，這與物流領域的 IOT 技術架構比較相似。
在演講的最後，許俊分享了在安防方面菜鳥所作的嘗試——「天眼」。當包裹通過商家發貨流動到攬收網點，中間須要經歷複雜的流轉過程。爲此，菜鳥在攬收網點、分佈中心、驛站等中轉環節架設大量攝像頭，以保障整個物流的全程實時監控及反饋。
因爲攝像頭數量龐大，「天眼」系統面臨的包括攝像頭管理、在線率、視覺計算網絡傳輸的穩定性等技術挑戰被菜鳥統一概括爲大規模弱中心集成管理技術問題。把攝像頭與雲端對接，通過編解碼體系爲這個技術問題的解決方案，但若視頻 24 小時不斷上傳，那麼一家快遞公司僅僅支付網絡費用就已高達每一年幾千萬。爲此，菜鳥經過引入邊緣網關和邊緣計算體系，並對數據進行預處理，以此來下降成本。
將來，天眼上會集成愈來愈多視覺識別模式，全部都會經過菜鳥算法容器進行高效率算法迭代和新算法引入。而菜鳥天眼系統也將進一步與實時調度系統產生聯動，經過雲和端實現包裹全鏈路可視化，實現基於大數據以外的全新視覺管理體系。
英特爾發佈 CPU 新架構，突破性採用 3D 堆棧法
閱讀數：13622018 年 12 月 13 日 15:01
當地時間 12 月 12 日，英特爾在「架構日」活動中公佈了下一代 CPU 微架構—Sunny Cove，這個微架構採用 10 納米工藝製造，會成爲英特爾下一代酷睿和至強處理器的基礎。一同發佈的還有全新的 GPU 核芯顯卡。
據瞭解，新架構「Sunny Cove」有以下性能方面的提高：
一、單線程性能（僅此一點架構變化確定就不小）
二、下降功耗（筆記本的續航時間有可能大幅增長）
三、 改進擴展性、可並行執行更多操做（或許是支持更多核心）
四、 可加速 AI、加密等專用計算任務的新功能
這一架構不一樣於過去，衆所周知，傳統的芯片結構爲 2D 平面，但英特爾突破性地使用了 3D 堆棧結構，名爲：Foveros。按照英特爾的說法：這樣的結構就像樂高積木同樣，甚至可能改變芯片結構的發展。
Moor Insights＆Strategy 首席執行官 Patrick Moorhead 表示，2D 方法能夠實現多種多樣，同時也會犧牲性能並消耗更多功率。而英特爾的 3D 堆棧結構彷佛已經避開了這些問題。Moorhead 說：「當你把這些小芯片放在一塊兒時，幾乎沒有功率損失，也沒有性能損失。」不過，英特爾仍然須要證實這一結構能夠在一樣的投入中產生相同的結果。
英特爾採用的 3D 堆棧結構
電力傳輸也是英特爾認爲已經解決的問題之一。幾十年來，人們一直在尋求一種成功的 3D 包裝技術，但因爲電力、熱量和價格等因素，這項技術一直未能實現。若是底層變熱，熱量就會上升，在 3D 堆棧的方法中，若是在組裝完全部東西后意識到其中一層是壞的硅，那就只能扔掉全部東西。這樣的代價是很是很是昂貴的。
英特爾從 AMD 挖走的芯片架構專家 Raja Koduri 對英特爾如何破解這些問題的細節守口如口。但他表示，結合嚴格的測試、新的供電流程，以及一種全新的隔熱材料來散熱，英特爾已經學會避免了典型的缺陷。
此外，英特爾還宣佈將推出一個新的微架構，2020 年的新架構是「Willow Cove」（柳樹海灣），主要是從新設計緩存，對晶體管進行新的優化，並有新的安全特性。2021 年的新架構是「Golden Cove」（金色海灣），繼續提高單線程性能，並強化 AI、5G、網絡、性能，同時繼續強化安全。
除了發佈新的架構，英特爾還發布了第 11 代核心顯卡，獨立顯卡會在 2020 年發佈。這意味着除了 AMD 或英偉達外，將來的 MacBook Pro、iMac、iMac Pro 和 Mac Pro 也能夠選擇英特爾的獨立顯卡。
據瞭解，第 11 代核顯將在明年集成於 10nm 工藝的 Ice Lake 處理器，下半年發佈，官方稱會在性能、能效、3D 和媒體技術、遊戲體驗方面都有飛躍。Intel 宣稱，新核顯的每時鐘計算性能會提升一倍，浮點運算性能突破每秒一萬億次 (1TFlops)。
此外，11 代核顯 (GT2 級別) 會集成多達 64 個執行單元 (EU)，比如今的 24 個多了將近 1.7 倍。它們分爲四個區塊 (slice)，各有兩個媒體取樣器、一個 PixelFE、載入 / 存儲單元，而後每一個區塊又細分爲兩個子區塊 (sub-slice)，都有本身的指令緩存、3D 取樣器。
EU 內的 FPU 浮點單元進行了從新設計，可是 FP16 單精度浮點性能不變，同時每一個 EU 繼續支持七個線程，暗示仍是 512 個併發流水線，同時從新設計了內存界面，三級緩存增大至 3MB。
Intel 還披露了一些具體的細節，好比 D 流水線方面支持基於區塊的渲染 (TBR)，從新設計了內存子系統等。
參考內容：
https://www.cnbeta.com/articles/tech/797865.htm
https://www.wired.com/story/intel-foveros-chips-breakthrough/
百度研究院今日再升級，迎來 9 位世界級科學家
閱讀數：9502018 年 11 月 14 日 15:43
美國時間 11 月 13 日，百度研究院在美國硅谷召開會議，宣佈百度研究院顧問委員會正式成立，並宣佈在 2018 年陸續迎來 9 位世界級科學家加盟。當天，百度研究院院長王海峯領銜的百度研究院顧問委員會和核心科學家亮相百度美國辦公室。
新成立的百度研究院顧問委員會共包含 5 名成員，包括 AT&T 和貝爾實驗室前副總裁及首席科學家 David Belanger，伊利諾伊大學厄巴納 - 香檳分校終身教授、計算機視覺領域頂級科學家 David Forsyth，著名的計算語言學專家 Mark Liberman，卡耐基梅隆大學終身教授、機器人技術領域專家 Martial Hebert，明尼蘇達大學終身教授、知識發現與數據挖掘（KDD）領域的最高技術榮譽 ACM SIGKDD 創新獎得主 Vipin Kumar 等，均是國際上享有盛譽的知名科學家。
這些科學家的研究領域包括信息挖掘、計算機視覺、語音技術、機器人、大數據挖掘、商業智能等，幾乎囊括了 AI 領域從底層基礎到認知、感知技術的全領域範疇。他們將成爲百度研究院的「智囊」，帶來最頂尖的研究經驗，推進產出更多擁有世界級影響力的研究成果。此外，顧問委員會也將基於對百度 AI 技術的瞭解，爲百度提供 AI 發展趨勢的判斷和將來研究方向的建議。
百度高級副總裁、AI 技術平臺體系（AIG）總負責人、百度研究院院長王海峯在現場發言中對各位顧問委員的加入表示熱烈歡迎。他提到，學術研究一直是產業間 AI 核心競爭力的重要組成部分。這次新成立的顧問委員會將爲百度研究院的 AI 研究注入學術端的血液，讓百度研究院在前瞻性的研究方向上，更具深遠佈局。將來咱們將與這些科學家一塊兒，繼續去突破解決 AI 問題，用 AI 更好的服務社會和普通人的生活。
發展數年來，百度研究院不只匯聚了 Kenneth Ward Church、吳華、李平、熊輝、楊睿剛、浣軍、馬豔軍等國內外 AI 領域世界級專家, 還在 2018 年陸續引入了天然語言理解、機器翻譯領域專家黃亮，計算機視覺和生物特徵領域專家郭國棟，悉尼科技大學教授、計算機視覺和人工智能專家楊易，馬里蘭大學終身教授、馬里蘭大學帕克分校計算機科學系及電氣與計算機工程系主任、自動駕駛和機器人領域領軍人物 Dinesh Manocha 等科學家及顧問。
百度研究院顧問委員會成立大會上，新加入的顧問委員分別就當下最熱門的 AI 研究領域進行了分享，並發表了本身的觀點。
目前，百度研究院旗下共有深度學習實驗室（IDL）、大數據實驗室（BDL）、硅谷人工智能實驗室（SVAIL）、商業智能實驗室（BIL）和機器人與自動駕駛實驗室（RAL）5 個實驗室，覆蓋了包括天然語言處理、計算機視覺、語音技術、大數據、自動駕駛和機器人以及通用人工智能技術等全領域，重點聚焦前瞻基礎技術探索，佈局 AI 將來方向。
會上，百度研究院還公佈了近期在天然語言處理、語音、高性能計算、深度學習等 9 個領域的重要成果。
-
在天然語言處理（NLP）領域，百度構建了最大的中文異構知識圖譜，研發基於多文檔校驗的閱讀理解技術、基於交互式學習的對話理解技術等，在 AI for Prosthetics Challenge 等國際知名賽事中屢獲冠軍。目前百度 NLP 技術幾乎支持百度全部應用，天天被調用超過 3000 億次，並經過百度 AI 開放平臺對外開放。
-
基於天然語言處理技術和語音技術，百度創建了世界上第一個具備集成預期和可控延遲的語音實時翻譯系統，這一技術已被成功應用於百度同傳產品中，並在 11 月 1 日的百度世界大會上進行了展現。
-
在語音合成領域，百度提出了第一個徹底端到端的深度神經網絡模型，可合成出接近於真人聲音的語音。
-
在 AI 醫療領域，百度發佈了擁有強大的腫瘤病理切片檢測能力的「神經條件隨機場」算法，可爲癌症診斷和治療提供重要助力，其檢測準確率已經突破此前最高記錄，甚至超過專業病理醫生。
-
在機器人領域，百度開發了世界首個基於視覺的低成本建築機械傳感控制系統。基於該技術打造的無人挖掘機，可減小 40％人力成本，同時工程收益能夠提高 50%。
-
在商業智能領域，百度致力於區域畫像、POI 知識圖譜和用戶畫像等基礎能力的研發，生成了數以千萬條 POI 屬性和數以億條關係數據，完成了多尺度百萬級區域的百餘項指標的計算，並將這些能力成功應用於數讀城市和百度地圖的智能出行等產品中。
-
在高性能計算領域，百度做爲主要創始機構發佈了國際業界公認的開源深度學習性能基準平臺 MLPerf 併產生巨大影響力，目前已吸引了 50 多家公司，和哈佛等 7 所頂級大學加入。
-
在深度學習平臺方面，做爲國內惟一開源開放的深度學習框架，PaddlePaddle 近期正式發佈了 1.x 的穩定版本，並在官方支持模型的完備性、超大規模深度學習並行技術和高速推理引擎等技術領域取得了領先優點。同時，PaddlePaddle 持續下降深度學習門檻，深度賦能各行各業，助力實體經濟發展。
-
基於開放普惠 AI 理念，百度還開發了自動深度學習技術 AutoDL，支持深度學習的自動設計、遷移和邊緣計算適配。AutoDL 的設計能力已經經過百度平臺 EasyDL、AI Studio 免費向開發者開放，廣大中小初創企業和我的無需特殊軟硬件和工程團隊，也能創建強大 AI 模型，加速 AI 應用落地。
-
在大數據方向上，百度快速檢索算法處於世界領先地位，同時專一開發實用機器學習算法平臺，該算法在搜索、信息流、知識圖譜等百度關鍵產品和技術上發揮着重要價值。
圍繞核心 AI 技術，百度已構建起完整的 AI 技術佈局，包括算法、算力、大數據等底層基礎，語音、視覺等感知技術和知識圖譜、天然語言處理等認知技術，深度支持百度搜索、信息流、百度地圖等內部業務，並經過百度 AI 開放平臺對外開放 130 多項 AI 核心能力。王海峯表示：「咱們對人工智能的探索將不斷前行，將來無止境。」
解祕：百度 PaddlePaddle 深度學習框架和搜索引擎基礎架構
閱讀數：68092016 年 10 月 24 日 08:00
前不久在百度世界大會上，百度首席科學家吳恩達首次宣佈對外開放百度深度學習平臺，以推進人工智能技術的快速普及，把在搜索、圖像識別、語音識別、天然語言處理、用戶畫像及情感分析等人工智能領域的優點整合升級，爲程序開發者提供了一個功能更全、效果更好的深度學習框架。
其實，百度很重視對於開源軟件的使用，也願意把內部的技術以開源的形式貢獻出來，正如在 10 月 22 號由百度開發者中心、百度開源委員會聯合舉辦的第 67 期「百度開源專場」技術沙龍上，來自百度的工程師於洋和顏世光，分別分享了百度開源的兩個最新項目：PaddlePaddle 百度深度學習框架和百度搜索架構開源產品線（例如 Tera、BFS、Galaxy 等），並結合具體的產品案例，分享百度開源技術最新實踐經驗。目前這些項目都已經在 github/baidu 上開源。
什麼是 PaddlePaddle 深度學習平臺？
首先作個簡單的介紹，PaddlePaddle 是百度自主研發的性能優先、靈活易用的深度學習平臺，是一個已經解決和將要解決一些實際問題的平臺。目前百度有超過 30 個主要產品都在使用 PaddlePaddle。關於機器學習、深度學習和淺層學習的內容就不詳細介紹了，接下來重點講述一下 PaddlePaddle 的總體架構。
關於 PaddlePaddle 總體架構（ PPT 下載）
說到 PaddlePaddle 的總體架構，主要從這幾個方面入手：多機並行架構、多 GPU 並行架構、Sequence 序列模型和大規模稀疏訓練。多機的並行架構和序列模型的實現都是實現神經網絡最複雜的東西，那麼具體怎麼實現全鏈接？
PaddlePaddle 是 2013 年啓動時比較流行的架構是 Pserver 和 Trainer 的架構。在多機並行架構中數據分配到不一樣節點，下圖裏灰色部分表示機器，方框裏表示一個進程，Pserver 和 Trainer 是分佈在兩個進程裏，中間的部分是網絡通信鏈接。
下面來介紹一下什麼是大規模稀疏模型訓練。稀疏模型訓練是說輸入數據是稀疏的，因爲稀疏輸入，那麼灰色的神經元和鏈接在訓練中都沒有做用，灰色神經元的輸出是 0，灰色鏈接的梯度是 0，梯度是 0 的話，簡單的 SGD 不更新權重。因此只有藍色的鏈接有價值，須要從 PServer 服務器得到最新參數，須要計算梯度，並將梯度傳送回參數服務器。（以下圖）
除了上面所提到的，還有兩外兩種狀況下的稀疏模型：
- 大規模稀疏模型（多機器）——每一個 Trainer Prefetch 出自身須要的參數和服務器通訊。
- 大規模稀疏模型（正則化）——簡單的 SGD 確實在梯度爲 0 的時候，不去更新參數，可是加上正則化就不必定了；好比 L2 正則化，就要求參數的 2 範數持續減少。
PaddlePaddle 實現時的一些思考
基於 OP（操做）仍是基於 Layer（層）？
- 基於 OP——從矩陣乘法配起，一步一步對應一個一個數學運算。
- 基於層——直接寫一個全鏈接層，LSTM 層。
- 基於 OP 的優點 Tensorflow——更靈活，更可讓研究人員構造新的東西
- 基於 Layer 的優點 Caffe——更易用，讓細節暴露的更少；更容易優化。
基於 OP 仍是基於 Layer？——支持大部分 Layer，可是也支持從 OP 開始配網絡（矩陣乘發，加法，激活等等）；對於成型的 Layer（LSTM）使用 C++ 從新優化。緣由在於，PaddlePaddle 是企業解決現有問題的框架，不是純粹的科研框架；企業須要性能，也須要靈活性。
多機通訊基於 MPI 仍是 Spark 仍是 K8s + Docker？PaddlePaddle 底層通訊不依賴於任何網絡框架，PaddlePaddle 的網絡任務需求相對簡單，根源在於任務週期短（連續運行幾周）；任務能夠失敗（多存 checkpoint）。同時，PaddlePaddle 的網絡須要高性能，從頭手寫網絡庫更方便性能調優，RDMA 能夠更好的支持。同理，PaddlePaddle 底層不依賴任何 GPU 通訊框架。
百度搜索開源基礎架構（ PPT 下載）
顏世光是百度搜索基礎架構負責人，在此次沙龍上介紹了百度當前的這套搜索引擎，以及搜索引擎背後的事件。重點部分是百度這套開源的基礎架構軟件站，它包括分佈式數據庫、文件系統、管理系統、分佈式協調服務、網絡通訊框架。下面來一一介紹。
當前，用戶經過互聯網搜索引擎的指望在不斷的變化，整個搜索引擎的指望從以前的幾周變成如今的幾分鐘，以前幾周以內能夠處理幾百億的數據，如今要在幾分鐘以內處理幾萬億的數據，這是個鮮明的矛盾。其實解決方案就是構建一個大數據處理平臺，也稱之爲「基礎架構系統」。這個基礎架構系統目標首先是海量的目標數據。其次就是在於集羣利用率的保證，這個利用率多是 CPU 利用率，它會爲你節省成本。
這裏能夠簡單介紹一下百度內從事開發的平臺——baidu stack（如上圖）。這個平臺分三層，最的底層是網絡通信，是一個高性能的 RPC 框架，它會把全部的網絡問題屏蔽掉，讓上層的系統在開發中不須要考慮網絡拓撲。中間一層是基礎服務，包括分佈式文件系統，它解決了數據處理。第二就是集羣管理系統，它管理的數據可讓程序部署變得代價很小。第三是分佈式的協調服務，一方面用作服務發現，另外就是分佈式。最上層是核心數據庫和數據處理系統。在理解上能夠將這套系統和 Hadoop 相關的系統類比。從中間這層提及，Hadoop 有 HDPS，Hadoop 在分佈式服務這塊使用 Cukaber，好比也有 Storm、Spark 這些。整個基礎架構系統的設計思想有兩個，第一是分層。不管是 Hadoop 系仍是谷歌，他們都使用相似的思想，這個思想主要是分工和借用，讓不一樣分工解決不一樣問題。另一個思想就是高效，解決用戶對處理速度的指望。百度主要使用 SSD、萬兆網卡，這套分佈式基礎架構徹底是用 C++ 實現的。首先是核心的數據庫 Tera，這裏列了 Tera 數據庫的核心功能，包括全局有序、自動分裂、合併、支持快照。
Tera 的架構能夠看（如上簡圖），從圖上咱們能夠看到它有核心就是綠色兩部分，是 Master 和 TableServer，提供整個數據節點都是 TableServer，全部的訪問通過 Master，讓它擴展到幾千臺服務器中。灰色的底層數據都是在分佈式文件系統上，自身沒有任何數據，被設計成無狀態，當一個 TableServer 宕機後，會從另一個機器拉取數據，不會有任何損失。一樣底層的分佈式文件系統能夠提供很大的幫助，它是經過 Nexus 作的。
這裏簡單介紹一下 Tera 的核心技術。⽔水平擴展方面能作到無單點；在線分裂、合併；⾃自動負載均衡；經過 LSM-Tree 作到實時同步，而且 Tera 還具備多語言支持的特色。Tera 在百度內部有很是普遍的應用，例如百度的網頁庫, 百度將萬億量級的網頁存儲在 Tera 中。
這裏再介紹一下如上圖的百度文件處理系統（BFS），不只在百度，BFS 在外部的使用價值也是很高的。那麼 BFS 具備哪些特色呢？首先是持續可⽤：分佈式 Master，多機房數據冗餘。其次就是實時高吞吐：慢節點處理，元數據管理。
由於篇幅有限的緣由，這裏就介紹這麼多，更多詳細的內容，你們能夠下載兩位講師的演講 PPT，也能夠觀看後期整理出來的演講視頻。
百度萬億量級數據庫 Tera 架構應用、設計與實踐全攻略
閱讀數：24402017 年 5 月 25 日 19:00
信息技術發展日新月異，網絡數據呈現爆炸之勢，搜索引擎的實時性面臨巨大挑戰。百度搜索引擎天天處理着數萬億次的連接分析和數百億次的互聯網資源採集。做爲百度搜索引擎的核心數據庫 Tera，是如何支撐萬億量級的實時數據處理呢？
在 5 月 20 日百度開發者中心主辦、極客邦科技承辦的 71 期百度技術沙龍上，百度網頁搜索基礎架構技術經理齊志宏和資深工程師鄭然，爲你們免費放送了大型分佈式表格系統 Tera 在百度搜索引擎中的應用、以及 Tera 架構設計與實踐的全攻略。
Tera 在百度搜索引擎中的應用（講義PPT ）
在講解 Tera 的應用以前，百度網頁搜索基礎架構技術經理齊志宏首先介紹了百度搜索架構，百度搜索引擎的做用是鏈接人與信息、鏈接人與服務，信息抓取、索引構建、檢索系統構成了搜索引擎最經典的三大板塊。
互聯網上的信息是如何經過搜索引擎最終展現給用戶的？首先，網頁被搜索引擎發現，經過抓取進入搜索引擎；而後，有價值的網頁通過篩選，進行正排計算和倒排計算，完成索引構建；最後，經過檢索系統將最終的結果呈現給用戶。
伴隨互聯網信息爆發式的增加，百度搜索架構也在逐漸向實時化方向演進，在介紹完搜索架構以後，齊志宏從連接存儲、索引篩選、用戶行爲分析三個場景切入，詳細講解了 Tera 在實時搜索架構中的應用。
齊志宏先爲你們解釋什麼是 Tera：一種大型分佈式表格存儲系統，具備高性能、可伸縮等存儲特色，最初的設計是爲了管理萬億量級的超鏈和網頁信息。Tera 在架構演進中到底扮演了怎樣的核心角色呢？
首先來看存儲連接。百度推出的 Spider 3.0 系統是基於 Tera 的實時架構，以 Tera 爲核心，承載了連接庫、網頁庫的存儲，將原有基於 MapReduce 的批量計算轉變爲基於 Tera 的實時計算，實現每秒億級的數據隨機讀寫、天天處理萬億量級的連接操做，信息抓取模塊（即 Spider）進入了實時處理時代。
第二個是索引篩選。索引篩選的核心做用是讓有價值的信息進入索引。Tera 架構做爲數據存儲中心，存儲了包含網頁庫、去重庫、結果庫在內的全部中間數據和最終結果，經過流式計算的方式完成頁面特徵拼接、頁面價值計算、網頁去重以及索引排序等核心操做的實時化改造。網頁從抓取到篩選完成的整個過程，實現了從天級變到分鐘級甚至秒級的飛躍。
最後一個是用戶行爲分析。用戶行爲分析在搜索效果改進和搜索引擎的評價等方面，都具備重要價值。基於 Tera 的實時用戶行爲數據流，將用戶數據的時效性推向新高度。實時數據產出的延遲可降至秒級，突發時效性識別、用戶意圖分析、產品迭代評估等多個維度都可實時獲取用戶數據，進行實時分析，對時效性和用戶體驗有很大的提高。
整體上，Tera 支撐了着搜索引擎大規模的實時數據讀寫，將批量、全量計算轉變爲增量、實時的數據計算，極大的提高了搜索引擎的實時數據處理能力，Tera 是百度搜索引擎從批量處理邁向實時計算的架構基礎。
Tera 大型分佈式表格系統的設計與實踐（講義PPT ）
Tera 完成了百度搜索向萬億級數據實時搜索的躍進，成爲煊赫一時的數據庫系統，那麼，如何作好 Tera 架構的設計與實踐成爲開發者最爲關心的問題。百度網頁搜索基礎架構資深工程師鄭然在演講過程當中，圍繞背景、數據模型、架構與設計、高可用實踐以及性能優化等方面，詳細講解了 Tera 設計和實踐過程。
鄭然表示，百度搜索引擎面臨三大業務特色，（1）數據量大，PB 到百 PB 這樣的量級；（2）離線處理過程當中，以站點等前綴方式訪問數據是廣泛的需求；（3）數據類型不固定。這樣的業務特色決定着 Tera 設計和實踐的過程。
Tera 設計的數據模型
Tera 的數據模型有如下幾個特色，首先它是 Key-Value 模型，再深刻一層，它是典型的 BigTable 模型，同時，一個很是重要的特色就是全局有序。這幾個特色結合在一塊兒，就是 Tera 數據模型的設計目標。
Tera 設計的系統架構
Tera 系統主要由 Tabletserver、Master 和 ClientSDK 三部分構成, 數據持久化到底層的分佈式文件系統中。其中 Tabletserver 是核心服務器，承載着全部的數據管理與訪問；Master 是系統的仲裁者，負責表格的建立、Schema 更新與負載均衡；ClientSDK 包含供管理員使用的命令行工具 Teracli 和給用戶使用的 SDK。
表格被按 RowKey 全局排序，並橫向切分紅多個 Tablet，每一個 Tablet 負責服務 RowKey 的一個區間，表格又被縱向且分爲多個 LocalityGroup，一個 Tablet 的多個 LocalityGroup 在物理上單獨存儲，能夠選擇不一樣的存儲介質，用以優化訪問效率。
Tera 的高可用實踐
Tera 的高可用性比較關鍵，直接影響整個系統的服務質量，其實現方式包括兩個方面：Tablet Server 可用性以及負載均衡。
- Tablet Server 的可用性：1）Tablet Server 向 ZooKeeper 註冊，利用 ZooKeeper 檢測 Tablet Server 的存活；2）Tablet Server 掛掉以後，Master 收到 ZooKeeper 通知，進行 Tablet 遷移。具體遷移過程，會把掛掉的 Tablet Server 節點遷移到 Kick 節點上，當 Tablet Server 發現本身出如今 Kick 節點下面，自行退出。
- 負載均衡：負載均衡會直接影響整個集羣的可用性，因此負載均衡更本質上來講是實現高可用的技術手段。影響 Tera 負載均衡的因素相對較少，主要在 SSD 容量、隨機讀和隨機寫這三個方面。針對上述影響因素, Tera 從兩個層面來進行負載均衡策略的設計。首先平衡各個 Tablet Server 讀請求 Pending 的數據量, 同時利用歷史值來平滑負載短期內抖動的影響 ; 其次根據 SSD 容量平衡各個 Tablet 的數據大小。
Tera 設計的性能優化
鄭然表示，Tera 設計的性能優化，是百度在作設計過程當中總結出來的，實用性較強。
第一個經驗是須要考慮對分佈式文件系統友好。Tera 的數據持久化在分佈式文件系統上，必須考慮對其友好的使用。根據 LevelDb 的特色，數據首先要持久化在 WAL 上，確保異常狀況下不丟數據，因此寫 WAL 的延遲和吞吐直接決定了用戶寫請求的延遲和吞吐。然而分佈式文件系統須要寫多個數據副本，在某些副本異常狀況下，若是依賴分佈式文件系統層面去自動恢復的話，可能大幅增長延遲。Tera 針對寫 WAL 異常狀況，採用關閉舊文件建立新文件的方法，規避分佈式文件系統的短板。同時 WAL 持久化成功才能保證用戶數據不丟，因此 WAL 寫完以後必須 sync 強制數據落盤，而 sst 文件不強制要求每次寫請求落盤，從而減小對分佈式文件系統的壓力。
第二個經驗是關於 SSD 的運用。SATA 的隨機讀能力不好，雖然 LevelDb 作了不少優化，可是仍然沒法突破硬件瓶頸，SSD 的價格如今是愈來愈便宜，但成本依然比 SATA 高。Tera 的數據所有持久化在 SATA 上，僅把 SSD 做爲 Cache 使用，這是平衡性能和成本的一種途徑。
第三個經驗是異步邏輯設計。Tera 裏面全部可能阻塞的邏輯都是異步的，異步邏輯能夠很好提升性能，另外客戶端緩存 Tablet 位置信息，由於 tablet 位置信息一般狀況下變化的也不頻繁，同時擴展了 LevelDb 的 BloomFilter 機制，能夠提高 20% 左右的讀性能。
百度萬億量級數據庫Tera架構應用、設計與實踐全攻略
獨家揭祕騰訊千億級參數分佈式機器學習系統無量-InfoQ
螞蟻金服黑科技:SOFA DTX分佈式事務,保障億級資金操做一致性-InfoQ
我所經歷的大數據平臺發展史(四):互聯網時代 • 下篇-InfoQ
專訪RocketMQ聯合創始人:項目思路、技術細節和將來規劃-InfoQ
百度萬億量級數據庫Tera架構應用、設計與實踐全攻略-InfoQ
百度第三代 Spider 背後的萬億量級實時數據處理系統
信息技術發展日新月異，網絡數據呈現爆炸之勢，線性擴展面臨高昂成本。Spider系統是百度搜索引擎的主要數據來源，天天處理着數萬億次的連接分析和數百億次的互聯網資源採集。那麼，第三代Spider是怎樣「化繁就簡」實現增量式流式處理的呢？
本文整理自今年12月顏世光在全球架構師峯會2016北京站的演講。回覆關鍵詞「百度」，下載完整版PPT。
在過去，百度搜索引擎的數據處理的多數工做是由MapReduce系統完成的，處理延時達到天級。從2014年開始，Spider系統進行了大規模重構，以搜索結果更新延遲從周級縮短到分鐘級爲目標，設計實現了海量實時數據庫Tera。在此基礎上，構建了天天實時處理幾萬億連接與網頁更新的百度第三代Spider系統。
區別於上一代系統，新系統的核心流程所有實時化，從互聯網上出現一篇新網頁，到基於歷史分析與機器學習快速發現連接，到基於連接價值的抓取調度，再到對網頁進行分類、篩選每一個步驟都在幾秒鐘內完成，以保證新網頁能以分鐘級更新到搜索結果中。
也就是說，當互聯網上產生一個新的網頁時，Spider 2.0把它下載回來的時間大概是2-3天，而Spider 3.0卻只須要5分鐘，至關於大概是3個量級的提高。
我從一加入百度，就開始構想第三代Spider了，後面的五年幾乎都在開發百度Spider第三代系統。由於它是一個很是龐大的業務系統，因此底層須要各類各樣的基礎架構系統支持，包括分佈式文件系統、集羣管理系統和數據庫系統等等。當前，這些底層系統都已經開源，若是有興趣能夠一塊兒參與進來。
首先故事從互聯網和搜索引擎開始，你們平時常常接觸到的互聯網以及百度搜索引擎，不少人也思考過互聯網上的網頁怎麼轉化成百度搜索引擎裏面這十條結果的。這裏面的工做分爲不少階段，以下圖所示。最開始，由Spider去作信息採集。
後面的Pagerank其實表明了一系列的計算，包含了反做弊、去重和基於頁面質量的篩選等等。此階段以後會對網頁進行切詞，計算網頁的正排，再作轉置變成倒排。最後進入檢索系統供網民直接檢索。Spider是該系統的起點，它的主要目的就是快速、全面地採集全網數據。那麼，全網數據究竟是什麼概念呢？
你們設想一下，當前中文互聯網到底有多少網頁？不知道有多少人嘗試算過或者估算過，其實咱們也不知道具體的數字，可是咱們經過搜索引擎估算，結果大概有100萬億的網頁。其中高質量的部分大概有10萬億，這10萬億就是百度Spider所要採集網頁的核心任務。
可是，光采集回來還不夠，還要知道它到底有沒有價值。中文互聯網天天新增多少網頁？100億，也就是說互聯網天天就會產生100億的新網頁。那麼會產生多少條超級連接呢？每一個網頁上會有多少條連接？百度統計的大概結果是，平均一張網頁上有120條連接，這不是指特定某個網頁上有120條，而是平均值。從這一點就看到整個百度Spider天天要處理的數據量，大概天天要處理1萬多億的連接。
怎麼去處理這麼大規模的數據，其實在過去有個比較通用的解決方案：Hadoop。基於Hadoop的第二代Spider主要流程以下圖所示，全部持久化數據存儲在HDFS中，經過MapReduce任務進行選取、挖掘、回灌和抓取結果入庫。
Hadoop時代的百度Spider
但這個Spider有什麼問題嗎？其實它的首要問題就是線性擴展的問題。不少時候你們接觸到的線性擴展或者水平擴展都是一個褒義詞，即用10倍的機器就能處理10倍的數據，線性增加，處理能力沒有明顯的降低。
可是，在這裏它卻變成了一個嚴重的問題：舉個例子，在過去Spider系統天天處理1000億連接的時候須要500臺服務器，而今天互聯網上的連接呈爆炸性的增加，系統天天要處理10萬億級的連接，就須要5萬臺服務器，這確定是一個不可承受的代價或者成本，因此這時候咱們必須得有新的解決方案，不能再作全量的處理，必須有一種增量的，只處理新連接的方式。
咱們指望的處理過程如圖所示。
不少人看到後可能有些失望，百度Spider就這麼點東西嗎？其實你們仔細去想，簡單表明了更更大的靈活性和更強的擴展性。它其實就是一個流式計算系統，而後系統中的每個策略也好，或者過程也好，都是流式系統上的一個算子，好比調度、抓取、頁面解析、頁面打分、連接權值打分。
整套系統的核心在於數據。一方面，咱們作實時數據處理，表面上完成工做的是這些算子和計算流程，而每一個算子的計算都依賴與數據的輸入和輸出，算子的計算延遲很大程度上決定於輸入數據的獲取延遲，輸出數據的寫出延遲。算子計算的穩定性又依賴與數據的不重不丟，這些數據必須有一個持久存儲，又能隨時、隨地獲取的方式，這樣才能更好的去作實時的流式的處理。
另外一方面，區別於普通的流式處理，若是僅去對單個連接或網頁作流式處理，常規的Strom、Flink這些框架都是能夠作到的。那麼，它的真正的難點是什麼？其實整個搜索引擎的計算，數據之間是有依賴性的，一張網頁的價值誰說了算，一部分是由所在站點的權值和路徑深度決定，更多的是由指向它的連接（前鏈）來投票決定。
也就是說處理一張網頁時其實要同時處理整個數據集裏面上百處位置的狀態，一張網頁價值變化了，要同時更新網頁上包含的全部連接對應網頁的權值，一樣，在判斷一個連接的價值時，也可能要依賴它的成百上千個前鏈上的實時數據。這就要求前面提到的那個能夠隨時、隨地訪問的數據集不是一個局部數據集，而是涵蓋互聯網全網數據的全集。
--> 算法上能夠啓發式地優化？對於非 top 的，不須要精確的rank 值，啓發式地去除大量的連接計算？
hierarchically 地計算？
百度的第三代Spider系統，它的核心在於實時的數據處理，這些實時的數據處理的主要挑戰：
-
第一個挑戰就是全量數據的數據集比較大，大概10萬億條，百PB量級。若是是冷數據，把它放在冷備存儲上能夠很低價的維護，可是在Spider中不可能作到這樣，由於每時每刻這個數據集中的每一條都有可能被改變，要保證它被改變時隨時被更新，也就是在10萬億條數據級上隨時去讀寫。
-
第二個挑戰就是天天新抓網頁100億，觸發1萬億條連接更新，每秒屬性更新近億次，這帶來的是一個量級的提高，會對底層數據庫形成每秒上億次的隨機讀寫訪問。另外搜索引擎有一個特色，就是須要作調度，底層數據訪問既能夠隨機訪問也能夠順序訪問，要求底層存儲裏的這些數據有序，這樣就能夠很好的統計一個站點上到底抓了多少，我們知道咱們如今控制的一個站點壓力不要把這個站點壓跨，因此說須要不少維度的調度。
面對這些挑戰，咱們給出來的解決方案就是分佈式的數據庫 Tera ，首先容量自沒必要多說，必需要達到萬億量級百P的容量，再就是它要多維度的調度，支持區間訪問，方便統計，就必須是一個有序表，它最核心的點是要支持自動的負載均衡，自動擴容，自動縮容。
由於衆所周知的一種狀況是互聯網上熱點頻發，常常有一些站點成爲爆發狀態，還有一些站點忽然就消失了。還有一種狀況就是業務迭代很是快，可能有些業務剛建立了表，只須要10臺機器進行服務，可一旦快速擴張，可能就須要幾百臺機器了，你應該很快地實現這種擴容，一樣當它的峯值過去後也能很快地實現縮容。
除此以外，這個系統還要有一個多版本特色。有這麼一種狀況，上線一種新的策略或者新的活動時，由於有些地方邏輯出了個BUG，把數據庫寫壞了，這時候需快速恢復或者止損，就只有一個辦法，就是將整個數據庫狀態回滾。此外，這個數據庫還有一個特性，好比列存儲、分佈式事務，都是一些比較擴展性的特徵。
該數據庫的核心數據模型是三維的，除了行和列還有時間的維度，經過這個維度咱們能夠存儲網頁或普通的歷史數據，這樣一方面方便咱們去作歷史行爲的挖掘，另外一方面它也實現了剛纔我說的回滾，可回滾到昨天前天或者某個時間的特殊狀態。
第二點就是說這個數據庫它的分片（sharding）方式，是一個全順序按行去切分的，也就是說行與行之間絕對有序，而後在中間把它切開之後分到不一樣的區間上去，區間與區間之間也是有順序的。
按行切分紅多區間（Tablet）
在這裏你們能夠看到它的一個簡化的架構圖，咱們把整個數據表按行去切分層多個Tablet，或者切分爲一個子區間，每個子區間均可以在TabletServer上服務，這張圖其實還有一個核心點，我想讓你們注意一下就是它的一個核心設計的思想在於它把全部的數據所有放在底層的分佈式文件系統，這裏面提到的BFS上，這樣整個數據庫都是無狀態的，它的全部的數據所有是落在分佈式文件系統上的，這就爲了後面的不少特徵的實現提供了可能。
Tera架構
這個具體作的事就是一件事，就是把隨機寫轉換成順序寫，讓咱們對整個海量的順序這種隨機讀寫的訪問成爲了可能，它把隨機寫轉換成順序寫的算法也很簡單，他經過先寫Log再寫內存，等內存寫到必定量的時候，把內存成爲一種靜態文件，這種方式去實現了支持順序寫，還可以保證最後下去的數據有序，而後再去後臺，進行垃圾收集，保證總體的數據量有限的膨脹。
以上就是它的架構了，那麼它給爲咱們帶來什麼呢？首先，它實現了在流式的處理系統中作到海量數據隨時隨處可用，上層的計算系統有很大的空間，有PB級的內存，統一的地址空間，幾乎你在任何一臺機器上想存的數據都是能夠存下。再下面就是百PB級存儲，不用擔憂持久化，你不用擔憂數據丟失，它作到了數據寫下去之後，任何其餘機器實時可讀，寫入當即可讀。
不少人都用過Hbase，下面列一下它和HBase的一些相同點和不一樣點。
-
Bigtable數據模型
-
開源
-
一是可用性，這個系統最核心的一點就是說咱們經過提高可用性，來解決了在咱們上層實時業務中可以真正去支持實時業務。這一點怎麼去作到的，後面會詳細介紹。它主要解決了區間熱點的問題，不會由於某些區間熱點致使區間不可服務。
-
二是吞吐和延遲，Tera是C++實現，效率更高的同時，沒有內存GC，不存在延遲不穩定的問題。
-
三是擴展性，HBase能夠作到數百臺，而它能夠作到數千臺。
以上這些咱們怎麼作到的？首先就是快速負載均衡，其實更核心的一個點在於熱點區間的分裂，就是說咱們若是因爲業務的變化，或者說上層用戶行爲的變化，致使一個區間變成了一個熱點區間，那麼咱們會在很快的時間內把它分裂開，一個區間分裂成多個區間，而後把其中的一部分遷移到比較空閒的機器上，經過這種方式實現了快速的負載均衡。這個快速負載均衡是經過文件引用的方式去實現的，也就是說不管是區間的分裂仍是區間的遷移都是沒有任何數據拷貝的，由於數據所有分佈在底層的分佈式系統上的。
在此你們也會想到其實HBase也是有這個功能，它熱點區間也是能夠提供這種在線的分裂，可是這裏每每會引入這麼一個問題，就是原來0這個區間是個熱點的時候把它分爲1和2，很快2這個區間又成爲熱點了，你把2再分紅3和4，若是如今4這個區間又成爲熱點又怎麼辦？
在HBase上敢這麼分嗎？你剛開始初期建立了一個表，有一千個分片，那麼可能兩天三天之後就變成一千萬個分片，由於不停分裂下去，分片數就徹底不可控了，因此這裏負載均衡核心問題不在於快速分裂，而在於很好的處理分裂後的碎片問題，能作到一旦一個區間再也不是熱點區間了，能瞬間合併。
因此在此要強調一點，能快速合併才能作到敢分裂，這纔是一個真正的解決熱點問題的方式。在這一點上TabletServer系統就是區間快速遷移，區間快速合併，僅有元數據變動，代價小，時間短，全自動，無人工干預。
表面上咱們解決熱點問題的方式是用快速的區間分裂和遷移去作的，實際上這個問題本質上是經過什麼方式解決的呢？這裏經過一張圖去展現這一點，即連續區間自己是存在一臺機器上服務的，可是這一個區間內部可能會有不少這種SST這種靜態文件，這種靜態文件實際上在底層分佈式文件系統上是散在幾百臺甚至上千臺機器上的，這種很是強的隨機讀能力去解決的熱點問題，也就是說雖然你看到了一個區間是在一臺機器上服務，實際上它的全部數據文件，全部你讀它產生的IO都會被打散到底層的幾百臺機器上去。
這裏有一個背後的英雄，就是百度文件系統BFS，這套文件系統的設計很是複雜，可是它核心是解決了HDFS的擴展性以及延遲的問題，能夠真正面向實時應用，作到持續可用、低延遲。這個文件系統當前也已經開源。
下面介紹一些在構建上層業務系統、底層分佈式系統中積累的一些經驗。
第一個經驗，是採用分層設計的原則，以下圖所示。
工業實踐-分層設計
從圖中能夠看到當前百度網頁搜索的軟件棧，最底層的網絡框架包含了分佈式文件系統、集羣調度系統和分佈式協調服務；再上層是數據庫；再上層纔是實際的業務。
這些技術系統都是一層一層堆上去的，好比說最底層的網絡通訊框架，全部的網絡問題，包含Socket編程的封裝，網絡的流量控制，跨地域的連接優化，所有會封裝在這一層。上層用它開發分佈式文件系統時，就徹底不須要考慮網絡問題、流量控制問題了，只須要關注分佈式文件系統的邏輯就能夠了。
而後，把全部數據持久化甚至IO相關的一些工做所有放在分佈式文件系統這一層。在構建上層的分佈式數據庫、分佈式數據處理框架，乃至上層業務系統的時候，都再也不須要考慮數據持久化的問題，也不須要考慮IO持久能力的問題。這樣就能讓數據庫能夠作到徹底無狀態的。你們可能接觸過不少數據庫，沒有任何一個數據庫系統能夠作到徹底無狀態的。這個徹底無狀態甚至包含cache無狀態。
也就是說這種分層設計帶來一個最大的好處，就是任何問題在一處解決了，不少處都會受益，一樣問題在一個地方解決一次就夠了，上層系統徹底不須要考慮網絡問題、丟數據的問題、IO能力的問題。
第二個經驗，是要去爲可用性設計，要能作到容錯。一般咱們計算可用性能夠用：可用性=(總時間-故障數*恢復時間)/總時間。不少工程師和架構師作系統設計的時候，會把不少精力放在下降故障發生的頻率，下降故障發生的機會，儘可能讓系統不要出故障，以這種方式來提升可用性，而在咱們這套設計思想裏，咱們不經過這種方式提升可用性，爲何？
由於故障不可避免。假設咱們單臺服務器的平均故障間隔時間是30年，在市場上你是絕對買不到這種30年都不會壞的服務器的，但咱們假設你有這種服務器，你去搭建一個萬臺的集羣，你在使用這個集羣的過程當中會發現每一兩天就會壞一臺機器。也就是說不管你的服務器再好，都不能避免故障。
咱們提升可用性的思路就是下降故障恢復的時間，日常所說的幾個9，就是總請求數減去故障數，乘以故障影響的數，經過這套思想，這套分佈式數據庫作到比之前高一個9，就在於故障恢復時間。
第三個經驗，是要去爲低延遲設計。由於咱們如今整個上層的業務系統都在從批量到實時過渡，咱們要作實時系統，實時系統很大程度上對延遲有很高的要求，backup request是個很好的選擇，我但願他99.9分位的延遲不要超過10毫秒。我期待這個服務平均1毫秒返回，若是2毫秒還沒返回，我就再發一個請求到備份節點，這樣來下降延遲的長尾。
另外是慎用自動GC的語言，實時處理，大量小請求，頻繁觸發STW，服務無響應，沒必要要的failover，致使整個系統不穩定，因此儘可能不要用這種自動GC語言。剩下可選的語言可能就很少了，因此咱們這套系統選擇用C++開發。
這套系統將來的工做是走出百度、走向社區。今天，百度這一套核心的分佈式系統已經徹底開源了，咱們也把全部的開發、codereview和版本的發佈，所有放在GitHub上，外部提交的代碼已經在驅動百度的這套搜索了。
你們能夠登陸Github，關注咱們的項目，共同交流：
做者介紹
顏世光，百度搜索基礎架構團隊技術負責人。2011年加入百度，從事Spider系統架構相關研發，期間主持了百度第三代Spider系統的設計與實現。 當前主要研究方向爲大規模分佈式系統，是百度海量數據庫Tera、百度文件系統BFS和集羣操做系統Galaxy的主要做者。 熱衷開源，前後推進了百度多個重量級系統對外開源。