隨著AI技術的深入發展，近幾年來與企業級資料相關的討論層出不窮。

如何儲存？怎樣呼叫？呼叫的時候又該如何確保隱私不被洩露？

……

儘管資料專家一波接著一波，但針對企業如何理解、儲存、使用資料，並通過其實現更大商業價值的探索從未改變。

對此，百度雲早就get到了開發者們的資料痛點。

就在剛剛結束的、由百度雲主辦的“百度雲ABC Tech Day —— AI時代的智慧儲存分發技術實踐”的活動中，來自百度雲內部的諸多專家現場針對儲存、資料分發、媒體資料處理等領域的資料技術以及AI能力佈局等方面與到場百餘名開發者展開了深入的交流與探討，現場氣氛熱烈。

本次沙龍中被探討的諸多內容，也十分值得相關領域的開發者們認真學習與總結！

沙龍初始，百度雲高階產品經理崔劍首先為與會的開發者們帶來了《百度雲BOS在AI時代的探索和實踐 》的主題演講。他表示，百度雲的儲存產品其實具備了幾種特質。

眾所周知，企業資料要上雲，必然要區分不同的型別，目前百度雲按照三種類型，分別是結構化、非結構化以及半結構化來歸類企業級資料，充分滿足多樣化的需求。

據瞭解，百度雲BOS產品大概整體的資料量已經超過了2000TB，這個產品在內部已經有萬億的記錄。兼顧儲存的效能以及成本，崔劍表示，百度雲BOS整體底層的基礎設施也已經提供了不同檔次的儲存設施，最基本的為藍光，高階的有HDD以及SSD盤等。

隨著資料發展，百度雲的儲存業務不單單是將資料“存上來”，未來更需要將資料放在雲上讓其“說話”，也就是儲存+AI 的概念。

相比於國內各種儲存競品，百度雲物件儲存BOS在自動觸發機制，例如通過訊息佇列、函式計算等“連結”其他雲上產品的能力很強大，主要取決於百度BOS的智慧處理架構。

此外，崔劍指出，物件儲存很大程度上會成為未來的一個表現卓越的儲存產品，因為相比檔案儲存或者塊儲存，物件儲存具備一些獨特的性質。例如能夠支援更加海量的資料儲存，可以提供更高的效能以及資料可靠性等。

在BOS的層面，面向開發者，如何使用才能更方便？

關於這個問題，崔劍表示，百度云為此開放了比較規範的VPI介面。

由於BOS分為幾種產品概念，無論是圖片、內容處理的相關介面，還是圖片旋轉、設定，甚至是對圖片進行一些涉恐、涉黃的檢測等，各有區別。

除了介面外，在前端存在的不同開發語言，開發者希望提供包裝的SDK，而百度雲的SDK語言覆蓋比較全，例如java、安卓、iOS等都會涉及。

從物件儲存產品BOS的架構出發，段立國認為，從本質出發，其實BOS是一個多租戶共享系統，如何做到使用者級別的KOS和使用者相互訪問的隔離，其實是一個很大的挑戰。

從根源上看，儲存系統的流量很大，例如百度雲機房的BOS 入口已經達到了TB級別。如何把資料cache到使用者最近的地方，也就是整個IDC的範圍內？是個問題。

通常來看，IDC並不只是侷限在一個地域範圍內，在大流量的背景下IDC之間的訪問很容易成為制約儲存系統的瓶頸，所以cache就變得非常重要了。

“我們的cache分為兩層，在AZ級別會有一個使用者的熱點開啟，這個cache會與後面的儲存打通，對cache的一致性要求會從前端一直到後端，儘量將這個資料cache到離IDC入口最近地方；第二層cache是當用戶的訪問量很大時，會啟動一個本機開啟，但是連線AZ的cache都不會被提取，而是直接在wep service建立一個cache，儘管這個cache要犧牲一致性。”段立國補充道。

很多開發者們會有疑問，BOS 如何做到在低成本的前提下保持如此高的可用性？

他對此總結道，做到“多運營、多地域接入；四層負載均衡叢集無單點；資料接入層、訪問層無狀態且水平擴充套件；資料EC編碼多冗餘讀寫”四方面就可以。

所謂四層負載均衡裝置，主要實現的是自行調寫的功能，調寫期間並不會把大量的半連線的狀態推遲到之後的業務處理邏輯中。

提到BOS的高安全性，段立國介紹，關於最外層流量入口，百度雲會做一層全流量的旁路檢測機制。

“大概的原理是，在外網核心的地方會通過分裝鏡的方式，把所有資料流量複製到一套旁路的檢測系統中，這套旁路的檢測系統負責某個IP的流量是否根據預設的值，是否超過預設值等。如果有超過的情況，就會接入後面的流量清洗系統，將其清洗掉，然後再轉發給後面的裝置。例如，設定的同一個IP的流量不能超過兩萬QBS，如果超過兩萬，就會在這個旁路資料清洗中被清洗掉。”

關於資料服務端加密、落盤加密、KMS金鑰管理等細節，據悉百度雲是較早能夠提供使用者自定義證書產品的企業，具體就是提供使用者繫結BOS運營的業務，然後使用者將自己的證書上傳到BOS，如此上傳鏈路就可以做到用HITPS覆蓋。

需要提及的一點，物件儲存BOS可以實現透明加密，這樣所有的資料都是加密之後才會落盤。

段立國表示，在落盤之前，通過NS在最上層進行資料加密，BOS 的技術人員在最前端做解密，通過KMS管理金鑰。此外，物件儲存BOS還提供了十分豐富的認證和鑑權機制，相對國內以及國際都比較領先。

精彩的技術乾貨分享之餘，百度雲人力資源部的經理還就百度人才觀、招聘體系以及招聘職位等資訊同與會開發者展開了交流與探討。

如今音視訊的直播火熱不斷，無論是一月之前全民樂看的世界盃比賽，還是人們每天玩到不停歇的快手抖音，百度雲對新的內容分發形式有何見解呢？

基於此話題，百度雲高階產品經理程鴻認為， 如今網際網路直播平臺的興起確實在很大程度上促進了網際網路直播服務的革新。

對此，百度雲將網際網路直播1.0，也就是傳統的直播轉變成為雲化的服務。例如LSS。提供了一個端到端的、即開的雲化服務，主要由三個模組組成，分別是主播的推流端、中間進行接流處理和分發的環節、最後使用者在播放端觀看直播。

據瞭解，在推流端，百度雲會提供一些實時美顏、濾鏡以及特效等功能， 同時還會涉及到實時轉碼、鑑黃等功能，終端使用者在觀看的時候，比例如首屏秒開、推帪播放、位元速率自適應等這功能也會被一一呈現。

談及百度雲有關直播的關鍵點以及技術，程鴻進一步總結道：“目前主流的是RTMP、HLS、HTTP-FLV三種協議，但協議在使用上也是有區別的。例如，RTMP協議由於資料的立刻轉發性，所以延遲比較低，但在H5的使用中卻需要首外掛，所以在通常H5頁面的一些直播會使用HLS協議；HLS協議因為生成ts檔案切片，更新m3ue索引，又會導致延遲比較低，大概5-10秒，所以目前主流採用flv協議比較多，因為延遲比較低，並且穿透性比較好，方便排程。”

據瞭解，百度現在又自研了一種HLS+協議，能夠達到與FLV延時，並與ap一致的互動體驗。此外，程鴻表示，百度雲將網際網路直播2.0與AI結合，在效果增強、稽核監督、精細運營、簡化人工四個方向做了相關優化，能夠為現在的直播帶來更多的新鮮元素。

緊接著直播的話題，百度雲高階架構師沈慧峰為現場熱情的開發者們帶來了百度雲關於CDN的技術創見。

有關直播CDN，本質上需要探究的還是一個系統架構的事兒，主要就是邊緣的接流轉發到多個源站進行處理，然後根據使用者請求再進行邊緣分發。

瞭解直播的人都清楚，直播的協議中主要就是RTMP。

“如果從上行來看，其實就是RTMP推到我們的邊緣節點，然後就會有一個接流叢集，再轉發到主源站和備源站，根據級別的配置轉發到一個播放的叢集。任何一個直播系統都會有一個播放叢集去快取流，其實記憶體快取就是快取最新的資料，源源不斷。”沈慧峰說。

如果涉及使用轉碼的話，百度雲可能會使用一些轉碼單，但是轉碼也是基於播放請求。轉碼和轉發以後的資料就快取在剛才提到的播放叢集，僅供下游播放。這樣來看，整個上行環節就是視訊從主播端通過邊緣節點一直轉推到中心節點的過程。

直播CDN是一個龐大的網路，由邊緣節點和源站組成，除此之外還需要依靠監控系統和波測系統確保可用性，例如排程系統。

通過排程系統去排程節點，主要可分為策略層以及執行層。所謂策略層就是掌握這些資料以後怎麼去排程？

沈慧峰表示，其中涉及到容量和質量策略計算，還有回源鏈路的選擇，這也是決策系統中的一部分，此外還有故障動態容災，就是一個節點掛掉後，自動從DNS中及時將壞節點移動。所謂執行層，就是執行者就會利用策略完成排程，對於直播、點播“一視同仁”，主要是DNS排程以及HTTPDNS。

關於CDN延遲問題，沈慧峰認為客戶之間的認知和接受程度大不相同。

例如，線上教育對於延遲要求高一些，因為涉及到學員間的很多互動環節；而對於泛娛樂，卡頓方面就會要求比較高。

“所以針對不同的客戶場景就要有與之區別的技術設計，一個是針對小於GOP的延遲要求，在伺服器上會追趕播放技術；如果對於遊戲直播，延遲可以放寬到大於一個GOP，就會有一個帪級別的快取控制。”沈慧峰補充道。

此外，百度雲還會為客戶考量如何監控自己的直播服務體驗，為此提供了一個APM SDK，也就是在直播APP中加入SDK，同時提供多維度的雲端資料分析。

具體來說，就是從直播請求開始，將打點的資料放到準備好的SDK 中。如果過程中出現卡頓，直播結束後SDK 就會將資料上報給相應的伺服器，隨後進行彙總，進而去細緻統計計算這場直播的卡頓率、首屏時間、可用性、下載速度等，甚至可以區分維度。

如今企業越發重視資料層面的技術，深挖企業級資料價值在很長一段時間內都將成為不容忽視的重點。