一、主要討論人員

　　提問：陳超，七牛云技術總監

　　回答：朱冠胤，百度資深大數據專家，連續兩次百度***獎得主。

二、引言

　　“坐而論道”是一個輪流問答的玩法。本文是大數據主題周中，幾位國內一線專家激情問答的一部分內容。期間，各位群友也積極參與。

　　三、問題集錦

　　1.MongoDB在百度的使用場景及規模?

　　2.假設現在讓你完全主導一個類似Hadoop的項目，你會選擇哪種語言?

　　3.分享你在百度各種大數據項目中踩過的坑?

　　4.你所在團隊在自研和使用開源方案的主要考慮因素?

　　5.新一代分布式數據庫(NewSQL，類似Spanner)是一個好的創業方向嗎?

四、精彩回答

　　問：我們都知道你深度參與了百度多個成功的大數據項目，你是否可以分享下這個過程中踩過的典型的坑?

　　答：主要包括如下這些：

　　1.避免過度設計；有些問題考慮太早沒用；快速迭代，小步快跑！

　　2.防御性編程，認為一切都是不靠譜的(同時避免走向1的極端，例如離線系統，就不要考慮跨IDC高可用了)。

　　3.很多工作盡可能量化(能量化***先量化)；if you can’t measure it，you can’t improve it!

　　4.對外接口一定要慎重，不要輕易變動，兼容性尤其重要。

　　5.做好各種預案、監控，出現異常能快速定位是系統上游還是本系統還是系統下游的問題。

　　6.提供好架構和機制，讓業務方去調整配置各種策略。

　　7.將例行手工勞動自動化，人是不靠譜的；不要相信系統是***的，要有例行check機制。

其他Tips：

　　1.嚴格遵守編碼規范。

　　2.采用最嚴格的編譯選項。

　　3.做好CodeReview。

問：假設現在讓你完全主導一個類似Hadoop的項目，你會選擇哪種語言?(不考慮團隊，僅從語言層面出發)

　　答：類似Hadoop的項目：如果想開源，并且讓業界更多人參與進來，***Java；Hadoop能取得巨大成功，我個人認為這與它選擇Java有很大關系。

　　相反，Storm選擇了一個比較小眾的語言Clojure，我聽到的一些消息，twitter重寫Storm其中一個原因就是，精通Clojure的程序員比較難招，開源社區很多人也參與不進來，項目本身的活躍度也會受影響。

　　一個完整系統，要考慮項目推廣(業務方接受程度)、項目開發、調試和維護成本，***是性能。

　　拿Hadoop來說，接口層面需要支持Python、Php；如果是百度內部業務，還需要支持C++；如果是開放云對外服務，必須支持Java(對內則不用考慮，很少業務使用Java開發)。

　　對性能要求較高的部分，會考慮用C++；例如向量計算，會考慮SSE向量化，或一些業界成熟的高性能庫，甚至會考慮GPU或FPGA實現。

　　除了這兩部分，就考慮公司通用基礎服務，盡量減少重復造輪子，多利用程序的基礎庫，例如序列化、rpc實現支持情況等，結合百度情況，會優先考慮C++。

問：面對眾多開源解決方案，你所在團隊在自研和使用開源方案的主要考慮因素有哪些?

　　答：1.首先搞清楚究竟想解決什么業務場景的問題，包括已明確需求和潛在需求。

　　2.優先并充分調研業界已有實現(論文、代碼、論文活躍度和主要committer交流等)，要想清楚該系統試圖解決的業務場景是否是我們準備解決的；該方案在業界有哪些公司在站臺(爭取拿到一些內部消息)，構造一定規模測試，內部組織分享調研成果。

　　3.該方案是否能hold住(從設計理念到代碼級深度理解)，是否容易維護(選擇了Clojure估計難度不是一點半點)，是否容易推廣(看業務方對它的接受程度)。

　　4.如果上述3個都回答了，且答案是yes，此時看看該系統的論文(或原理)。和論文(或原理)對比，假設論文沒有缺陷且能很好覆蓋典型業務場景，則看該系統對論文的實現情況，是否有重大缺陷，如果有，一票否決；如果沒有，不猶豫，選它好了：)

　　5.能達到這點的不多，所以很多項目都自研了......

問：請說一下MongoDB在百度的使用場景及規模。

　　答：MongoDB在百度比較小眾，應用規模應該在百臺量級，基礎架構部對內不提供統一服務，都是各業務線自行維護。

　　百度開放云對外提供MongoDB，主要是在BAE(BaiduAppEngine)產品中提供共享模式的Mongo服務。

　　問：你覺得現在新一代分布式數據庫(NewSQL，類似Spanner)是一個好的創業方向嗎?

　　答：選擇類Spanner系統來創業，注定不走尋常路，挑戰極大。

　　首先，看該產品的受眾，有這類需求的客戶似乎都是大企業(一般用mysql就搞定了，需要拆到128個實例太少見了)，銀行、能源行業等，都是不差錢的主。

　　如果自己創業，即便做出來了，客戶一般也基本不考慮，他們不會相信一個創業公司能提供這樣的質量和服務能力。

　　其次，實現難度，實現Spanner的技術難度不小。

　　從我不專業的角度來看，類似RedShift的系統是個不錯的創業方向，很多公司都有這類需求，目前業界缺乏很好的開源實現，而已有商業化實現成本都比較高。

如何一起愉快地發展

“高效運維”公眾號（如下二維碼）值得您的關注，作為高效運維系列微信群的唯一官方公眾號，每周發表多篇誠意滿滿的原創好文：來自于系列群的討論精華、運維講壇線上精彩分享及群友原創。“高效運維”也是互聯網專欄《高效運維***實踐》及運維2.0官方公眾號。

提示：目前高效運維新群已經建立，歡迎加入。您可添加蕭田國個人微信號xiaotianguo8 為好友，進行申請，請備注“申請入群”。

重要提示：除非事先獲得授權，請在本公眾號發布2天后，才能轉載本文。尊重知識，請必須全文轉載，并包括本行。