周末參加了小馬智行的線下分享，獲益良多。很羨慕北京的環境，大部分的線下都是在北京，難得有在深圳的。深圳雖然被譽為最有創新價值的城市，但關於技術方面的交流簡直少的令人髮指。
下面根據這次分享的內容，依次介紹下我的一些思考。
首先分享的是無人駕駛的基礎架構。如果說之前自動駕駛秀肌肉，都是通過demo演示下雨天真實路況穿越隧道。那麼之後會逐步轉變為秀基礎架構。我覺得現在如果哪個無人駕駛公司對基礎架構還不夠重視，基本上就已經掉出第一梯隊了。那麼我們需要哪些基礎架構呢？
下面根據各個模塊的內容，逐個分析下有哪些應用場景，為什麼我們需要這些系統。
存儲
首先我們看下存儲，在自動駕駛中如何應用，有哪些應用場景？
- 文件系統
- 資料庫
- 數據meta
自動駕駛每天會產生大量的數據，之所以有這麼多數據是因為無人車配置了多種傳感器，這些傳感器包括攝像頭，雷射雷達，GPS等。每秒鐘會生產大量的數據，30分鐘的數據量就有幾百G，如果是一天的時間一輛車可能就產生幾T的數據。由於數據量太大，我們有3種處理方式，第一種，緩存最近2分鐘的數據，其他的數據處理完之後丟棄，這也是無人車正常情況下的做法，但是這種場景只適合正常運行的無人車，如果我的需求是採集地圖，或者收集訓練數據，那麼就不太合適了。為了解決上述問題，後面的2種方法就是考慮如何把數據保存下來。第二種，保存到硬碟，之後再回傳到數據中心，這種方法是目前普遍的方法，由於磁碟讀寫速率要求太大，普通的機械硬碟根本滿足不了需求，只能採用SSD硬碟，1T的SSD硬碟1200多塊錢，還是很燒錢的。最後一種就是通過網絡傳輸，目前4G的網速肯定是支持不了這麼大數據的，5G目前看是有可能，但也禁不起這麼大流量，合理的做法是小數據通過網絡傳輸，大數據落盤，把車的位置信息通過網絡實時回傳到數據中心，實現所有無人車的管理，其他的信息落到硬碟，記錄運行情況。
介紹了自動駕駛的數據生產場景，那麼再接下來看我們需要什麼樣的存儲，首先我們需要一個分布式的文件系統，大數據時代已經被廣泛證明了分布式文件系統的好處，最主要的好處就是容量可以水平擴展，而且可靠性高。這樣每天產生的幾十T的數據都可以通過分布式文件系統保存下來。
接下來就是資料庫的要求，這裡主要分析下自動駕駛場景和傳統網際網路的區別，分享的老師也提到了，網際網路的數據生產方式是幾億用戶，每人產生幾條數據，合起來幾個T，而無人車是一輛車，每天產生幾T數據，這裡的差別很大。網際網路中針對幾億用戶，一般是選擇key-value結構的資料庫，例如Hbase。但是如果把hbase照搬到自動駕駛的場景就很彆扭，因為hbase的單條數據最好是10M以內，否則會影響讀寫性能。這時候有人說我們可以把數據做拆分，把幾個T的數據，根據地理位置信息或者時間做拆分，把地理位置信息或者時間作為key，當時的數據作為value，這樣就可以實現一條數據很小，拆分成很多key-value的小數據了。我們再回過頭去看下網際網路的應用場景，網際網路場景下是拿用戶的ID作為key，如果同時頻繁的命中相鄰的ID，被稱為單點問題，即容量上不去，每次訪問都到一台機器上面去了。而按照地理位置或者時間的方式剛好又導致了這個問題，因為數據讀取的時候就是按照地理位置順序讀取的，每次都命中到一台機器，導致整個系統的容量上不去。如果我們把key做哈希散列，把地理位置信息打散，這樣容量是提高上去了。而這恰恰又和我們的應用場景有衝突，我們需要的不是高並發讀取，即同時幾十萬的並發，而是一個用戶連續讀取大量數據，這樣反而是單台讀取的性能最高，因為會對數據做預取。所以我一度懷疑，自動駕駛的大數據需求都是偽需求，雖然說數據幾T幾T的，但是根本不是大數據，就是數據量大而已，根本不需要資料庫，只需要文件系統就可以了。如果需要管理結構化的數據，還不如用資料庫存儲文件路徑，而文件本身放到文件系統中。
所以以後自動駕駛的公司再提到大數據，別以為有多了不起，就是一個人虛胖了而已。但有一點我認為很重要，就是數據meta，為什麼需要數據meta呢？數據meta是詳細的記錄了數據信息的數據，比如採集的時間，地點，天氣，採集的人，當時的情況等信息，對數據做分類管理。類似你到了一個圖書館，圖書館的書都是按照類目分門別類，然後你找書的時候直接按照索引來找就行了，試想一下，如果你去了一個圖書館，沒有分類，書是按照出版時間來放置的，那麼讓你找一本烹飪類的但是不知道出版時間的書，試問你如何找到呢？由於自動駕駛的數據極其不具備可視化，就是一大堆二進位文件，沒有什麼可視化的信息。而且自動駕駛的場景多樣，路況，時間，天氣都不一樣，數據量巨大，版本更新快。如果不分門別類，做好信息的meta，那麼後面假如你需要找所有下雨天的數據來進行測試，你如何去找呢？還得每個包確認下是否下雨？另一種應用場景就是測試數據的管理，每天測試的大量數據，什麼時候因為什麼原因接管的，這在後面回歸測試和仿真中很關鍵，如果沒有這些meta信息，假如我需要查找所有紅綠燈引起的問題，來回歸測試，我怎麼怎麼去查找呢？數據meta對自動駕駛的數據管理尤為關鍵，甚至目前我覺得自動駕駛只需要數據meta和文件系統就可以了。
當然有一個hbase的Committer加入了小馬，我覺得hbase可能主要應用在他們的打車服務上，比如routing路線的記錄，車和用戶的信息管理等。可以看得出來小馬對基礎建設這塊還是很重視的，也希望更多的人能夠提出更多更好的基礎建設。
計算
有了數據之後，需要計算才能得到結果，這就要用到計算平台。計算可以分為2塊，一塊是離線計算，一塊是在線計算。離線計算就是數據的處理，這一塊應該是可以完全借鑑網際網路的分布式計算平台，因為無人車收集的數據需要分類，清洗，以及一些處理。一部分的應用場景是高精度地圖的製作，需要把採集到的地理位置信息離線計算生成高精度地圖；另一部分的應用場景是離線計算好一些數據給到在線，利用空間換時間。比如planning模塊reference line的生成；routing線路事先計算保存；感知的ROI區域；定位的點雲數據處理等。主要的需求是能夠更快的處理數據，這一部分用spark就可以解決了。
在線計算主要是無人車的實時計算，感知車當前的環境，控制車輛前進。這一部分目前主要是一些異構計算，通用的計算放在CPU上，神經網絡的計算放在GPU上，控制部分有單獨拿處理器做的，這一塊可以參考下博世等廠家。目前看好的趨勢是拿FPGA做一些定製的算法開發，好處是比純軟體快，而且靈活，並且FPGA可以和硬體傳感器深度定製。比如4路camera，之前遇到一個問題是關於4個camera如何保持同步，即每個攝像頭拍照的時間戳如何同步，看起來很難處理，你怎麼保證它們同時拍攝呢，其實攝像頭有一個trigger功能，即每次拍照類似按下快門，如果每次拍照的時候同時按下4個攝像頭的快門，這樣就能保證攝像頭的同步了，高級點的攝像頭都帶有這個功能，可以預見FPGA和硬體算法的融合，會在在線計算中扮演越來越重要的角色。在線計算還需要低時延，這一塊在自動駕駛平台中再介紹，我們到底需要一個什麼樣的自動駕駛平台？
基礎服務
有了計算和存儲，我們可以搭建基礎的自動駕駛服務，但是如果要提供更多的服務，我們還需要以下幾個部分。
- RPC
- 消息隊列
- 配置中心
- 容器
基本就是網際網路服務的編排，部署和運維了。主要的應用場景比如打車服務，需要用到微服務架構，需要消息隊列，需要配置中心，需要容器編排，這些都是比較成熟的架構了，網上有大量資料，就不展開了。
下面我們主要講下實時計算平台，也就是無人車的自動駕駛平台，聽到小馬說我們是自己研發的一套自動駕駛作業系統，我還是感到有點震驚的，後面仔細想想其實可以把問題轉換一下，看起來也就不是那麼遙不可及了，當然如果要自研一套這樣的系統，肯定是需要一個穩定成熟的團隊。首先看下我們需要一個什麼樣的自動駕駛平台呢？我們由自動駕駛需要哪些模塊來進行展開。
下面我們看下各個模塊是如何工作的，我們以雷射雷達來舉例子，雷射雷達實時的拍攝了一幀數據，然後放到了系統內存，這時候感知和定位模塊都需要處理雷射雷達的數據，一個不好的方式的是把數據拷貝一份分別給感知和定位模塊，因為大數據的拷貝很耗時間，影響系統性能。我們需要換一種方式，以傳遞內存地址的方式把數據給感知和定位模塊，減少內存的拷貝，分享的老師也強調了這點。接下來我們把剛才的過程抽象一下，即來了一份雷射雷達的數據之後，系統分別調用定位和感知的函數，並且把數據在內存中的地址作為參數傳遞進去。接著我們把模塊抽象一下，我們有3個模塊，系統平台需要把A模塊的數據傳遞給B和C模塊，這樣一來，我們需要的是一個能夠同時發送消息給多個模塊的功能，即一個分布式的消息隊列。
也就是說自動駕駛平台實際上實現2個功能就可以了，一個是分布式消息隊列，一個是各個模塊的調度執行。所以我們把研發一個自動駕駛作業系統，轉換為研發分布式消息隊列和進程調度的問題了，這樣看起來就簡單了很多，因為都有現成的例子可以借鑑，回過頭來看Apollo的cyber也就是實現了這2件事。最後還分享了一下研發效率提升的一些基礎建設，包括代碼管理，代碼review，內存泄露檢測，代碼掃描等，這些都代表了開發質量和生產力。
業務場景
上面主要是分享了一下基礎的建設，那麼如何和業務場景聯繫呢，我們接下來看目前的一些業務場景：
- 打車服務 - 小馬主打L4的自動駕駛，目前主要是運營打車業務，類似一個滴滴提供的服務。
- 地圖服務 - 主要是提供高精度地圖服務。
- 人機互動 - 主要是人和車如何交互，如何知道車當前的狀態，所處的環境等。比如坐車的時候可以通過介面知道車當前的狀態，自己所處的位置，有沒有異常等。不僅僅應用在乘客，還可以應用在內部測試和研發。這一部分我覺得主要是夸平台，免得二次開發，目前來看大部分的公司採用的都是web服務。
- 車輛管理 - 類似現在的美團外賣，實時知道外賣員的位置和派單信息，用算法來動態調度，無人車還需要多一個功能就是實時監控無人車的健康狀態，可以理解為監控滿大街在跑的伺服器？
- 數據採集 - 主要是針對測試和採集地圖的場景，需要一套全自動的採集流程，並提供可視化的交互，如果全部手工完成工作量太大了。
- 測試平台 - 主要是針對無人車的各項測試，包括硬體和軟體，這涉及到各個模塊，我覺得主要是流程的維護和測試項的定義，保證質量。
- 仿真平台，仿真是介紹的重點之一，在版本發布之前，都需要在仿真平台測試，目前宣稱的測試里程是30W公里，這一塊肯定用到了分布式計算，否則沒法實現。另外我覺得這個流程也挺有意義，在無人車路測之前進行仿真，可以減少故障，類似發布之前的集成測試。由於不需要真車，可以跑大量的測試，對工程化是很重要的一環。關於仿真還有另外的用途就是復現場景，比如一次撞車或者接管事故，現場不可能再去復現，成本太高，而通過仿真去模擬復現這些問題就變得容易多了，另外一個應用是訓練模型，對於需要大量數據的訓練，仿真可以虛擬和合成大量的數據，提高效率。關於仿真可以參考。
總結
以上就是根據上次宣講憑記憶整理出來的一些思考和體會，有錯誤或者疏漏的地方歡迎指正，另外也期待更多的關於基礎架構的介紹和分享，後面會接著介紹硬體和感知的分享和體會。