搜狗大數(shù)據(jù)平臺建設(shè)

1、 搜狗大數(shù)據(jù)平臺建設(shè)目 錄 TOC o 1-3 h z u HYPERLINK l _Toc520827925 1.前言 PAGEREF _Toc520827925 h 3 HYPERLINK l _Toc520827926 2.搜狗大數(shù)據(jù)業(yè)務(wù)概況 PAGEREF _Toc520827926 h 4 HYPERLINK l _Toc520827927 3.搜狗基礎(chǔ)運(yùn)維平臺簡介 PAGEREF _Toc520827927 h 8 HYPERLINK l _Toc520827928 4.搜狗大數(shù)據(jù)產(chǎn)品化實(shí)踐 PAGEREF _Toc520827928 h 16前言如果大家遇到大數(shù)據(jù)的問題，如何進(jìn)一

2、步找到自己的價(jià)值，如何探索適合自己的中型或者小型公司數(shù)據(jù)團(tuán)隊(duì)在其管理方向的思考和探索。我做過很多項(xiàng)目，負(fù)責(zé)過搜索、運(yùn)維、云平臺、大數(shù)據(jù)，見證搜狗的成長過程，目前在做大數(shù)據(jù)基礎(chǔ)平臺建設(shè)和數(shù)據(jù)管理應(yīng)用方向。本文分為三部分：第一，搜狗大數(shù)據(jù)業(yè)務(wù)概況，做個(gè)基本的介紹。無論是運(yùn)維平臺還是大數(shù)據(jù)平臺，對公司來說都是支撐平臺，沒有好與壞，只有適合與不適合。第二，搜狗基礎(chǔ)運(yùn)維平臺簡介。分享跟大數(shù)據(jù)系統(tǒng)相關(guān)的組件和模塊。第三，搜狗大數(shù)據(jù)產(chǎn)品化實(shí)踐。我們在大數(shù)據(jù)系統(tǒng)從工具到產(chǎn)品的探索和思路，更多的是產(chǎn)品介紹、思路及我們的理念。搜狗大數(shù)據(jù)業(yè)務(wù)概況搜狗是典型的大數(shù)據(jù)公司，我想表達(dá)的是我們的大數(shù)據(jù)團(tuán)隊(duì)也并不容易。如果了

3、解搜索引擎的實(shí)現(xiàn)機(jī)制會知道，搜索的好與壞和數(shù)據(jù)量規(guī)模有關(guān)系，無論市場多大，都必須收集很多的數(shù)據(jù)，才能保證數(shù)據(jù)的覆蓋度。對搜狗來說，搜索引擎本身的數(shù)據(jù)量非常大，很多年前我要處理上百億的數(shù)據(jù)，現(xiàn)在整個(gè)搜索的覆蓋大概在2000億左右。搜狗輸入法目前是行業(yè)第一的產(chǎn)品，DAU用戶規(guī)模4億+，我們在很早的時(shí)候就已經(jīng)面對 4G 內(nèi)存的機(jī)器上萬并發(fā)的情況。我們在規(guī)模體量上和數(shù)據(jù)規(guī)模上面對的問題挺多。通過我的思考，把我對大數(shù)據(jù)演化方向的理解分享給大家。近期比較火的是以Hadoop 生態(tài)為依托的生態(tài)系統(tǒng)。經(jīng)歷了幾個(gè)階段，每個(gè)時(shí)間節(jié)點(diǎn)并不代表Hadoop的研發(fā)時(shí)間點(diǎn)，而是被行業(yè)接受和逐步用起來的時(shí)間點(diǎn)。第一階段，H

4、adoop高速發(fā)展階段，2010年之前，MapReduce剛剛出來，我們也是從Hadoop0.2版本跟起，更多的解決批量計(jì)算問題；第二階段，2010年前后，從我的感受來說，面太窄，只能依靠數(shù)據(jù)工程師去寫MapReduce。當(dāng)時(shí)Hive的出現(xiàn)，對于大數(shù)據(jù)系統(tǒng)有了質(zhì)的飛躍，用戶查詢使用量也上來了，這時(shí)候解決了使用門檻問題，傳統(tǒng)的BI、數(shù)據(jù)工程師、SQL 工程師、傳統(tǒng)數(shù)據(jù)分析工程師都可以學(xué)習(xí)用到大數(shù)據(jù)的系統(tǒng)；第三階段，2012年前后，阿里雙十一是代表，整個(gè)行業(yè)對實(shí)時(shí)計(jì)算的需求比較強(qiáng)烈；第四階段，近兩年來公有云廠商，大家都知道數(shù)據(jù)應(yīng)用的價(jià)值非常高，有很多的方向。典型的機(jī)器學(xué)習(xí)組件、廣告算法等，原來的門

5、檻很高，但是現(xiàn)在正在逐步的降低門檻，能夠比較快的把初級模型搭起來。搜狗大概也有幾個(gè)階段：第一階段，我把他稱之為專用的搜索大數(shù)據(jù)時(shí)代。我做過研發(fā)，我認(rèn)為搜索是非常典型的系統(tǒng)。大家知道搜索的核心要抓取全網(wǎng)的數(shù)據(jù)，這就是數(shù)據(jù)采集的過程。抓下來大量數(shù)據(jù)要存下來，就是數(shù)據(jù)存儲的問題，而且是大規(guī)模數(shù)據(jù)存儲的問題。把數(shù)據(jù)抓下來后要做排序、超鏈分析等，這是一個(gè)數(shù)據(jù)分析的過程。后面是快速的搜索和檢索。在2006年之前對搜狗來說，我覺得還是一個(gè)上古時(shí)期，幾乎沒有開源技術(shù)，所有的東西都靠自己研發(fā)，一切的一切只是為搜索服務(wù)。第二階段，跟著Hadoop演化，我給定為行業(yè)接軌的時(shí)代。這時(shí)候各種工具和版圖慢慢起來，包括核心

6、產(chǎn)品、數(shù)據(jù)報(bào)表、實(shí)時(shí)計(jì)算等應(yīng)用起來了。第三階段，從2016年開始我們開始向人工智能發(fā)力，前一段時(shí)間在互聯(lián)網(wǎng)大會上，我們有同聲傳譯。由于去年搜狗 IPO 后，我們在商業(yè)化方向有很多新的需求。在此情況下，誕生了對大數(shù)據(jù)團(tuán)隊(duì)的新需求和依賴。這是基本服務(wù)版圖，相信各大公司的差別不太明顯，一般都是有數(shù)據(jù)源、數(shù)據(jù)采集Agent、數(shù)據(jù)存儲、數(shù)據(jù)計(jì)算、數(shù)據(jù)應(yīng)用等等方向。但在每個(gè)細(xì)節(jié)上的優(yōu)化非常多，包括模塊與模塊之間連接的地方，服務(wù)監(jiān)控管理、資源調(diào)度管理等是很重要的一部分。搜狗也是如此，在擁抱開源技術(shù)的基礎(chǔ)之上，把周邊的服務(wù)、模塊逐漸的普及和優(yōu)化的過程。搜狗基礎(chǔ)運(yùn)維平臺簡介下面簡單分享搜狗基礎(chǔ)運(yùn)維平臺的思考和建

7、設(shè)情況。大概2012年前后，由于當(dāng)時(shí)機(jī)器數(shù)量比較少，只有小幾千臺。當(dāng)時(shí)也有類似規(guī)模的小公司，大量運(yùn)維平臺開源工具，很多套系統(tǒng)滿天飛的狀態(tài)。后來隨著機(jī)器和管理規(guī)模變大，2012年前后下定決心，完全從開源走向自研。走自研路線主要的需求有：我們需要靈活性的變化，我們要與商業(yè)計(jì)劃、OA系統(tǒng)、財(cái)務(wù)系統(tǒng)、預(yù)算系統(tǒng)打通。管理這么多問題的成本非常高，所以我們有需要打通的需求。并不希望在解決問題時(shí)要打開七八個(gè)系統(tǒng)，分別找數(shù)據(jù)來排查問題。在這樣的背景下，我們在 2012 年前后把運(yùn)維工具從開源逐漸轉(zhuǎn)向自研平臺。希望平臺更加易用，所以我們把所有的從業(yè)務(wù)視角、用戶視角把所有的業(yè)務(wù)整合起來，我們內(nèi)部稱之為ROC系統(tǒng)，實(shí)

8、際是資源管理的中心。我把它定義為更廣義的運(yùn)維平臺，因?yàn)樗粌H有常規(guī)的集群管理、域名帶寬管理、存儲系統(tǒng)管理、監(jiān)控管理，還有安全審計(jì)、采購、工單等平臺，把他們都整合在一起，現(xiàn)在搜狗的整個(gè)基礎(chǔ)運(yùn)維平臺都在這個(gè)平臺上運(yùn)行。接下來分享一點(diǎn)搜狗關(guān)于在機(jī)器管理方面的思考和想法。從機(jī)器到集群。我們核心理念是從機(jī)器到機(jī)群，我們堅(jiān)持從原來對機(jī)器的管理變化到對機(jī)群的管理，這件事談起來很容易，要完整的運(yùn)轉(zhuǎn)是成本很高的事情，我們至少花了3年時(shí)間才把這套東西完整的運(yùn)行在以目錄樹管理方式的機(jī)群管理方向上。機(jī)群葉子為最小模塊單位。對于以業(yè)務(wù)為服務(wù)模塊時(shí)，不管里面有多少臺機(jī)器，這是標(biāo)準(zhǔn)化的整塊服務(wù)。實(shí)現(xiàn)了所有日常操作組件。為了

9、打造這個(gè)目標(biāo)，我們實(shí)現(xiàn)了很多服務(wù)的組件，如系統(tǒng)重裝、機(jī)器保障、上下架搬遷、配置IPNAT、基本軟件運(yùn)行環(huán)境，對普通運(yùn)維工程師來說，在界面操作便能完成日常工作。大數(shù)據(jù)本身依賴大量的進(jìn)程、日志數(shù)據(jù)產(chǎn)生的模塊，搜狗以業(yè)務(wù)集群的葉子節(jié)點(diǎn)為最小的運(yùn)維單位，可以串聯(lián)進(jìn)程和日志的定義。舉例說明，在任何一種機(jī)器上跑一個(gè)模塊或者一組進(jìn)程，只需要模塊和配置文件，便能完成對進(jìn)程本身的運(yùn)維平臺的接入。只需要定義進(jìn)程的基本形態(tài)、運(yùn)行基本情況，這個(gè)進(jìn)程就已經(jīng)被運(yùn)維平臺接管了。做了這個(gè)基本定義后，后面提到跟大數(shù)據(jù)有關(guān)的是我們會對里面的日志做簡單的配置，日志就被管理起來。我們的日志管理包括日志在數(shù)據(jù)上的存儲生命周期、日志適合

10、做什么樣的壓縮、日志進(jìn)入大數(shù)據(jù)系統(tǒng)中的限流限速。對進(jìn)程的定義和對日志怎樣進(jìn)去到大數(shù)據(jù)的定義，我認(rèn)為這是大數(shù)據(jù)系統(tǒng)依賴的基本工具。這兩個(gè)東西已經(jīng)做得比較輕量級，只需要在平臺上做技術(shù)的管理便能達(dá)到操作。切到監(jiān)控版塊。我們對大數(shù)據(jù)運(yùn)維平臺管理/運(yùn)維人員的日常工作有幾大類。其中一類是針對任務(wù)失敗情況、任務(wù)延時(shí)情況做事。這依賴的就是監(jiān)控系統(tǒng)，我們用了很多年監(jiān)控系統(tǒng)，我會分享介紹我們在監(jiān)控上的思考和理念。監(jiān)控分為兩大類：第一類，黑盒監(jiān)控，是用戶視角的模擬。我不知道系統(tǒng)長什么樣，我們會把所有用戶可能訪問系統(tǒng)的方式定義出來，各種可能性。我們支持多種監(jiān)控插件，從TCP、MySQL、Redis等，給定義成黑盒。除

11、了是活和不活之外，我們還做了語義的定制，根據(jù)內(nèi)容訪問的不同，選擇不同的報(bào)警策略。還有一塊是完整的現(xiàn)場快照，搜索引擎對這個(gè)要求非常高，搜狗可以找到99.994%-99.996%左右，百度可以做到99.997%。我們每個(gè)月會抓出幾個(gè)失敗，排查問題非常麻煩。針對該情況，我們做了很詳細(xì)的現(xiàn)場快照的匯總工作。以前排查千萬分之一出錯(cuò)的可能性，是非常困難的。當(dāng)你發(fā)現(xiàn)監(jiān)控出一個(gè)問題時(shí)，可以快速的看到里面的快照信息，包括監(jiān)控機(jī)網(wǎng)絡(luò)狀況、執(zhí)行過程、抓包網(wǎng)卡，看服務(wù)器的每一個(gè)包和每一個(gè)網(wǎng)絡(luò)如何進(jìn)行傳輸，有非常明確的記錄。后面即使有非常小概率錯(cuò)誤，排查問題也能一目了然，這對我們來說是比較順手的工具。第二類，白盒監(jiān)控，

12、是系統(tǒng)視角。對搜狗來說如何設(shè)計(jì)白盒，黑盒是從業(yè)務(wù)視角看業(yè)務(wù)模塊好不好，那反過來白盒就是已經(jīng)知道系統(tǒng)的一切運(yùn)行狀態(tài)和日志都收集上來了，要如何發(fā)現(xiàn)系統(tǒng)的隱患和問題。我們把所有的數(shù)據(jù)、模塊運(yùn)行系統(tǒng)日志、進(jìn)程日志、打印日志都做成標(biāo)準(zhǔn)結(jié)構(gòu)，它一定是標(biāo)準(zhǔn)的結(jié)構(gòu)才能清晰入到監(jiān)控庫中。我覺得它非常好用，它可以做靈活的語義定制。比如我的進(jìn)程有很多的數(shù)據(jù)，可以做加減乘除以及各種各樣的條件，這對我們來說是搜狗運(yùn)維平臺的利器，我們可以對任何一個(gè)我們運(yùn)維的服務(wù)和模塊做各種可能監(jiān)控的方法，這在界面設(shè)置可以完成，對Ky的值做各種各樣的組合。接下來時(shí)報(bào)警策略的問題。搜狗發(fā)展十幾年，我們經(jīng)歷過有大量的監(jiān)控報(bào)警和大量問題出現(xiàn)的階

13、段，每天在被報(bào)警的汪洋大海中活著，我們?yōu)楫?dāng)時(shí)的狀態(tài)解決問題。靈活報(bào)警，報(bào)警策略有很多種，輕量級只是簡單的提醒你，比如郵件或者電話提醒你解決問題。我們采集各種各樣的數(shù)據(jù)進(jìn)行條件的組合，比如10臺機(jī)器有1臺機(jī)器故障，你可以發(fā)郵件，我第二天處理。如果5臺機(jī)器故障，會直接把你叫起來。這都可以靈活的配置，這是搜狗用得比較廣的方向。監(jiān)控系統(tǒng)是我們大數(shù)據(jù)運(yùn)維工程師日常經(jīng)常面對的問題，保證日常服務(wù)穩(wěn)定的基礎(chǔ)上，我們不斷的挖掘系統(tǒng)的隱患，不斷的補(bǔ)齊各種各樣的監(jiān)控手段和方法，讓系統(tǒng)更加穩(wěn)定和可靠。我門大數(shù)據(jù)運(yùn)維團(tuán)隊(duì)有大量的工作是配合公司和業(yè)務(wù)資源的管理，有人申請新機(jī)器、擴(kuò)容、搬遷、調(diào)整，這會占一定的工作時(shí)間，我們

14、做了大量系統(tǒng)化和信息化的工作。其思路有點(diǎn)像公有云，對搜狗公司的業(yè)務(wù)來說，其產(chǎn)品受到嚴(yán)格的管理流程，每個(gè)人用多少資源與其商業(yè)計(jì)劃完整掛鉤。首先是整個(gè)資源，如提預(yù)算，我們不是按照機(jī)器來算的，而是今年或未來一個(gè)季度可能會用到多少存儲、多少內(nèi)存、多少計(jì)算資源等，這些資源會轉(zhuǎn)換為業(yè)務(wù)考核目標(biāo)，比如產(chǎn)品日活、產(chǎn)品收入增加多少。到了一定規(guī)模，到CFO審核后，自動形成機(jī)器的采購、上線單，這套流程完全打通。對運(yùn)維人員來說清晰可見，機(jī)器采購?fù)旰螅瑫诩汗芾砩仙刹少弳?，我們就可以進(jìn)行擴(kuò)容，然后開放申請。這是申請界面，多租戶問題的核心是資源是不是多了，是不是不夠，怎樣加資源等等如何解決。搜狗在這方面比較清晰，每個(gè)

15、人都知道產(chǎn)品下來有多少賬號，我申請了多少，留了多少，哪個(gè)用得多，哪個(gè)用得少，比較便于我們的管理。不存在說不清我們到底要加多少臺機(jī)器，這對機(jī)器和成本管理來說非常有意義。資源管理的后續(xù)是如何開放和使用的過程，我們大數(shù)據(jù)方向做了很多工作。第一，每個(gè)產(chǎn)品線和每個(gè)業(yè)務(wù)單元使用的資源，每個(gè)月都有對賬單，你在哪個(gè)集群、哪個(gè)資源上用了多少，峰值多少，花費(fèi)多少錢。對我們來說，每一臺機(jī)器如何使用有非常清晰的流程。第二，除了對賬單，我們還有后續(xù)的措施。每個(gè)資源和賬號使用的過程，我們可以幫他分析和優(yōu)化。有些產(chǎn)品線和業(yè)務(wù)資源使用不夠均勻，空洞很多。每年做商業(yè)計(jì)劃，這一塊是有問題的，你不需要申請那么多，大家是有共識的。這

16、是我們在資源管理方面的思路和想法。整個(gè)運(yùn)維平臺涉及很多，對我們大數(shù)據(jù)團(tuán)隊(duì)來說更多面臨的問題是日常資源管理、體系管理、成本管理，還有我們要排查解決日常性能、優(yōu)化性能，對監(jiān)控系統(tǒng)的依賴和對集群的管理。搜狗大數(shù)據(jù)產(chǎn)品化實(shí)踐到了第三塊的主題，搜狗大數(shù)據(jù)產(chǎn)品化實(shí)踐，我們談?wù)劜町惢臇|西。近幾年搜狗的發(fā)展不是特別快，我們把可靠和穩(wěn)定問題解決得差不多，最近我們在糾結(jié)大數(shù)據(jù)平臺價(jià)值問題，我們的運(yùn)維團(tuán)隊(duì)和大數(shù)據(jù)團(tuán)隊(duì)如何創(chuàng)造更多的增值價(jià)值和提供服務(wù)的思考，希望給大家一些思考。主要為大家介紹我們的思路和實(shí)踐。最近一兩年，我們遇到很多新的問題。AI產(chǎn)品驅(qū)動和商業(yè)化大數(shù)據(jù)時(shí)代，很多公司出現(xiàn)新問題。原來的數(shù)據(jù)是自己產(chǎn)的數(shù)

17、據(jù)自己用，我們只要做好多租戶隔離。到現(xiàn)在這個(gè)階段，這時(shí)候數(shù)據(jù)附加值非常高，表現(xiàn)明顯的問題是產(chǎn)品之間數(shù)據(jù)依賴非常高，以前自己用自己的，現(xiàn)在是混在一起大家都在用。這個(gè)時(shí)候，業(yè)務(wù)對數(shù)據(jù)的安全更敏感，跨產(chǎn)品數(shù)據(jù)共享門檻非常高，我們最近在解決的是如何讓公司的數(shù)據(jù)安全有效的共享。數(shù)據(jù)安全，我們有以下探索：Hadoop自研。搜狗大概在2009年初開使用Hadoop的系統(tǒng)，當(dāng)時(shí)第一個(gè)系統(tǒng)不是做報(bào)表這種小打小鬧的東西，Hadoop有一個(gè)核心算法，就是典型算網(wǎng)頁超鏈關(guān)系和排序效果。做了這個(gè)之后，這時(shí)候多租戶管理的問題出現(xiàn)了。我們自己研發(fā)了Hadoop權(quán)限管理，即使到現(xiàn)在為止，我們還在使用。雖說行業(yè)有很多安全和授權(quán)

18、解決方案，但我們依然還在用。其好處是輕量級，在Hadoop體系中不需要維護(hù)單獨(dú)的服務(wù)，不會對系統(tǒng)配置產(chǎn)生額外的管理成本。關(guān)于數(shù)據(jù)敏感的問題，每個(gè)賬號支持賬號密碼級登錄認(rèn)證，我們也支持IP雙重認(rèn)證授權(quán)，對IP段進(jìn)行雙重認(rèn)證。即使賬號密碼被盜了也沒關(guān)系，有IP的限制，才能同時(shí)訪問到數(shù)據(jù)。雖然是輕量級的工具，對我們后來享受安全的靈活性可以提供很多解決方案和思路。數(shù)據(jù)使用嚴(yán)格審批和監(jiān)督。我們開始嘗試數(shù)據(jù)的審批和監(jiān)管，數(shù)據(jù)有大量的訪問集、資源分配和提高任務(wù)管理，有很多會產(chǎn)生誰，什么時(shí)間，哪臺機(jī)器在用什么數(shù)據(jù)。我么也嘗試將這樣的數(shù)據(jù)做信息化，大家從業(yè)務(wù)方面看到誰在用。數(shù)據(jù)加密和脫敏。這是我們在產(chǎn)品和產(chǎn)品之

19、間數(shù)據(jù)交換是做的探索。解決安全問題后，更重要的是如何讓不同的產(chǎn)品之間進(jìn)行共享。搜狗大概有1萬多種數(shù)據(jù)種類，每天涉及的數(shù)據(jù)文件有一二十億，很多歷史源產(chǎn)生的數(shù)據(jù)，有一定的管理難度。每個(gè)人生活在自己的世界里，只有自己知道自己有什么，你難以知道別人有什么。這是對我們現(xiàn)階段的一個(gè)挑戰(zhàn)。我們面對幾個(gè)問題：公司到底有哪些數(shù)據(jù)，每天會產(chǎn)生大量的數(shù)據(jù)、計(jì)算結(jié)果；公司數(shù)據(jù)應(yīng)該怎么申請，才能滿足安全和審計(jì)規(guī)范；如何使用這些數(shù)據(jù)。第一個(gè)方向，我們開始對公司數(shù)據(jù)做自動發(fā)現(xiàn)，我用旁路的模式對數(shù)據(jù)進(jìn)行管理和支撐。數(shù)據(jù)全生命期的管理成本是極高的，剛起步做這件事是非常麻煩，要做大量的工作，本來是可以快速完成的方式，會變得非常慢

20、。我們采用旁路的方式來關(guān)聯(lián)和發(fā)現(xiàn)數(shù)據(jù)，我們是做搜索起家的，我們有很多數(shù)據(jù)，只要任何一個(gè)地方串聯(lián)了數(shù)據(jù)，上了集群，通過發(fā)現(xiàn)機(jī)制都可以被發(fā)現(xiàn)。我們根據(jù)數(shù)據(jù)的路徑和歸屬發(fā)推薦，讓他做認(rèn)領(lǐng)。比較有意思的地方是我們參考了豆瓣看影評的方式，我們對每個(gè)數(shù)據(jù)貼了很多標(biāo)簽，標(biāo)簽對我們做檢索、分類和查驗(yàn)數(shù)據(jù)非常方便。每天搜索關(guān)鍵詞的指數(shù)可以做很多標(biāo)簽，只需要做簡單的檢索就可以看到。我們把旁路的系統(tǒng)稱之為數(shù)據(jù)云，它更像一個(gè)搜索引擎，有輸入框、分類和導(dǎo)航，讓大家對公司全部數(shù)據(jù)一目了然，有直觀的感受。第二個(gè)方向，發(fā)現(xiàn)了數(shù)據(jù)后，就是檢索數(shù)據(jù)。我們對數(shù)據(jù)做了大量結(jié)構(gòu)化和信息化的工作，我們可以通過關(guān)鍵詞搜索各種各樣的數(shù)據(jù)。我

21、們會把很多數(shù)據(jù)設(shè)置數(shù)據(jù)大小、文件數(shù)量、更新時(shí)間，便于我們做排查，這對管理運(yùn)維有幫助。我們想處理一塊數(shù)據(jù)時(shí)，只需要在系統(tǒng)上花一分鐘，便能查到哪些賬號下，哪些數(shù)據(jù)已經(jīng)半年沒人用了，確認(rèn)后可以刪除。這算是完整的信息化的支持。在數(shù)據(jù)上跑的任務(wù)，我們開始構(gòu)建依賴的路徑和版圖。我們正在做的更進(jìn)階，數(shù)據(jù)和數(shù)據(jù)之間的任務(wù)有篩查關(guān)系，從管理中生產(chǎn)出多任務(wù)多路徑的關(guān)系，我們嘗試構(gòu)建這個(gè)路徑，更容易看到它的上下游及誰在依賴它。第三個(gè)方向，關(guān)于數(shù)據(jù)共享，簡單介紹數(shù)據(jù)倉庫。數(shù)據(jù)倉庫的底層引擎很成熟，2010年開始，從Hive開始到后面的Spark、SQL特別多，這是分分鐘可以搭起來用的。從搜狗的搜索來說，從這個(gè)東西出來

22、之前，還只是專業(yè)數(shù)據(jù)人員在用。后來我們嘗試做一些改進(jìn)，源于谷歌的一個(gè)產(chǎn)品，我們把所有的數(shù)據(jù)通過產(chǎn)品化結(jié)構(gòu)化的方式，讓每個(gè)人很清晰的看到數(shù)據(jù)有什么含義，你們可以預(yù)覽TOP10的數(shù)據(jù)，方便感知這個(gè)東西。第四個(gè)方向，在數(shù)據(jù)共享方面的嘗試，除了數(shù)據(jù)倉庫外，我們可以公開Schema和demo的數(shù)據(jù)，定義為數(shù)據(jù)字典。通過任務(wù)的推薦，每個(gè)用戶知道哪些數(shù)據(jù)熱門，大家都可以用，其價(jià)值是什么，可以看到如何定義這些內(nèi)容。第五個(gè)方向，移動審批。前面主要是數(shù)據(jù)的發(fā)現(xiàn)和數(shù)據(jù)的查找，我們有移動OA系統(tǒng)，任何數(shù)據(jù)的使用和申請有流程的。對于搜狗來說，我們覺得現(xiàn)在太麻煩了，即使開源軟件或者我們有很多成熟的基礎(chǔ)組件，但使用成本依然

23、很高。從數(shù)據(jù)的產(chǎn)生到數(shù)據(jù)的使用流程非常長，在里面摸爬滾打很多年才能了解怎么運(yùn)作起來，數(shù)據(jù)的使用門檻非常高，數(shù)據(jù)的清洗、協(xié)議處理成本非常高，我們?yōu)榇瞬稍L過很多公司，70%的時(shí)間在清洗數(shù)據(jù)，我們后來花了很長時(shí)間想解決這件事。易用性問題，開源性平臺有很多基礎(chǔ)組件，但想用得好還是比較難的。我們帶著新問題切入，如何讓大數(shù)據(jù)平臺使用逐步簡單，這是我們的出發(fā)點(diǎn)。第一，我們做了類似SaaS產(chǎn)品的產(chǎn)品級數(shù)據(jù)解決方案。做數(shù)據(jù)時(shí)，如果小公司創(chuàng)建，做一個(gè)App的時(shí)候要用到統(tǒng)計(jì)，一定是用現(xiàn)在成熟的技術(shù)。我們會有這樣的解決方案。搜狗公司在嘗試很多新產(chǎn)品，他們只需要裝SDK，讓所有的數(shù)據(jù)一目了然。第二，為了讓流程變得簡單，所有的數(shù)據(jù)清洗完后可以一鍵進(jìn)入數(shù)據(jù)倉庫，讓準(zhǔn)備工作變得足夠少。第三，我們做了一個(gè)像google的BigQuery系統(tǒng)，大家寫SQL搭一個(gè)引擎就可以用，但有這個(gè)和沒有這個(gè)的用戶量差好幾倍。純粹非技術(shù)人員也可以方便用這個(gè)系統(tǒng)，我們用戶使用的規(guī)模和量差很多。第四，在報(bào)表方面，由于搜狗大量工作和報(bào)表有關(guān)系，我們在此基礎(chǔ)之上，配上時(shí)間、命名關(guān)系，每天都會形成報(bào)表，報(bào)表的生成工作變得非常