會議名稱：2016全球軟件開發(fā)大會QCon 會議時間：2016年4月22日（下午）會議地點：國際會議中心二號C，下午主要是一些追型規(guī)模的，冉冉上升的互聯(lián)網(wǎng)公司和大數(shù)據(jù)公司和我們一，首先要請下午第一位奇虎360系統(tǒng)建設部經(jīng)理，來Spark在360的，目前就職于360IT架構中心系統(tǒng)部，我們主要是給子公司提供通用分布式的架構平臺。我今天給大家?guī)淼氖荢park平臺在360的實驗及經(jīng)驗。Spark這兩年作為計算平臺發(fā)展的非常迅速，在國內(nèi)很多互聯(lián)網(wǎng)公司都有很多成使用案例，我介紹一下360內(nèi)部的使用情況，跟大家做種類型，一種是做通用計算，我們的定位主要是提供SparkSQI，有3000+節(jié)點的部署，節(jié)點的配置相對補是很高，64G天大概有15000的數(shù)據(jù)在跑另外是機器學習我們公司現(xiàn)在有用Spark比較多，這個集群的特點是配置比較高，288G內(nèi)存，節(jié)點數(shù)有500+，部署方式跟前面不太一樣，是獨占的，完全為Spark做沿用，服務的學習（英文）圖計算庫，這兩塊5000+左右的機器學習的算法在上面跑。360Spark，20155Spark1.3.1，5Standalone201581.4.1多租戶資源，這時候Spark有多個業(yè)務線在嘗試的用了，自己加了一套多戶資源，做到給多個用戶做資源，這個時候我們已經(jīng)搭建了機器學習的1000201511Standalone上可以把Yarn所有的接口做成內(nèi)部的版本就是把所有Spark的集成放到Yarn1.6.05003000多每天作業(yè)數(shù)兩萬多支持公司搜索安全數(shù)據(jù)分析360現(xiàn)在Spark提供了幾個比較大的套件，因為我們公司業(yè)務線比較多，所以對Spark的使用也很廣泛。對MLLib講有幾個算法，LDA、LR、ALS隨機，主要業(yè)務是推薦，APP推薦，代碼，檢測，后續(xù)的時候會深入的介紹一些使用場景另外是GraphX是另外一個組件用到PageRank做數(shù)據(jù)發(fā)現(xiàn)LPA做數(shù)據(jù)發(fā)現(xiàn)業(yè)務主要是兩塊一個是公司360搜索已經(jīng)把PageValue做進來了，外是SparkSQL，在社區(qū)里面Spark是最火的一個組建了，我們用Spark做的數(shù)據(jù)倉庫，現(xiàn)在會把SparkSQL替代原有的Hive，遷徙了每天全公司1.5萬個作業(yè)。HiveSQLMR2—5另外介紹一下PageRank的模型，這是一個，每個點代表一個網(wǎng)頁。給每值的時候有一定的保留，把小部分的節(jié)點發(fā)給虛擬的節(jié)點。S完成了一個黑洞的套出這個模型其實很簡單原來我們是用MPR做的事情，SparkSparkSparkPageRankSpark這有個初始的數(shù)據(jù)級，代表著一個廣義，key是一個（英文）ID，Val是每個（到下游的page額比例植。Rank代表每個網(wǎng)頁的權重（英文）的目的就是要計算最終每個網(wǎng)頁的傳輸。另外是（英文）的集合，S節(jié)點匯總，按照一定的比例分發(fā)75%、80%是比較合適的。PageRank重值，可以完成這一步。第二步把（英文）IPD重總和，αSαSS復雜了，在把（英文）SS次相加，就得到了（英文）計算的每個網(wǎng)頁的權重。所以說思路很簡單，用Spark實現(xiàn)的話是一個非常簡單可以使顯得。這是PageRank意的發(fā)現(xiàn)，這個項目的背景是什么呢。我們公司那邊有已知的，已標注好，我們希望從這些為出發(fā)，能夠挖掘出來的，這是怎么做到的？這個事情也是在Spark的基礎上完成的。除了標記好的，能拿到一個解析的，有這個解析之后就可以通過Spark的發(fā)現(xiàn)算法，相當于矩列算法。首先要構造出來一張之間的圖關系，構建過程非常簡單，DNS大家知道，每個在每個時間點可能會解析到多個IP層。藍色的代表，這代表的P的是RP，B可能會在一定時間到RP3上。兩個RP這兩個可以構造出一條邊，組合這樣的數(shù)據(jù)就得到了一張之間的圖，代表之間的關系，這是通過推導得出來的一。接下來怎么做呢？我們得到了這張，做一個發(fā)現(xiàn)，數(shù)據(jù)發(fā)現(xiàn)很簡單?？梢园岩蛔龀上鄬τ诰垲惖牟賰?nèi)部的聯(lián)系非常密切說明他們經(jīng)常會解析到同一個RP上操作這樣的社群RP關系就比較密切，但是這個關系不是很強。這邊我們又做了另外的對本身進行聚類這樣又得出來一個Kmeans聚類，長得非常像，可能是相同的IP。這樣把兩個關系疊加，它在網(wǎng)絡連接比較密切，并且長的比較像，求一次交集，這樣在交集里面的，網(wǎng)絡連接很密切，而且長得很像。參照之前已經(jīng)挖掘出來的一部分，確實了非可以下一個判斷，如果交集的數(shù)據(jù)集里面超過域值的是黑的話，我們就說剩下的是黑的概率非常大，這是我們挖掘黑的一個小項目，總體是通過Spark來完因為它是基于（英文）做的，里面有很多，每個代表社群號，每個點都defmap，而且這個操作是個迭代的操作。但mapLouvain，我們自己實現(xiàn)了一套自己SparkSQLHiveSparkSpark的時候加上Phive參數(shù)另外部署SparkYarn集群另外配置SparkSQL共用Hive的元數(shù)據(jù)庫，用Sparkhive工具替換原有hive命令，或者直接提交作業(yè)，整個遷原來的部署方案最上層是hive，然后分解成hive為元數(shù)據(jù)，到MR。遷移后SQLhiveHive遷移SparkSQL有這樣的遷移方法，我們在整個的作業(yè)管理系統(tǒng)里提供了一個新的SparkHive的類型，做的時候把原來Hive的類型批量的改為SparkHive，WSparkSQLSparkSQL.0，SparkSQLBroadcastHashjoinSortMergeJoin，1.6.0Hive時候內(nèi)存比較小，不支持后面的Join（英文）值是聚合的表達式的結果，又有（因為數(shù)據(jù)是套序的，所以完全不會（英文。1.4.1一個節(jié)點上，使用起來效果非常差。1.6.0里面用的是聚合的方式，性能會好很多，所以大家選擇版本的時候還是建議大家選擇的版本。還有Hive版本的選擇1.4.1以后Spark支持多版本之前主要是支持0.12、用不同的版本，把（英文）不同的（英文HiveMetaStore（英文）會切換到剛才定義的Wrapper，具體反映具體的Hive函數(shù)，這HiveSpark1.6.0里面提供了Hive的分裝，只要是實現(xiàn)自己版本的Hive就可以了，提Hive1.1介紹一下我們在SparkSQLHiveSQL（英文）HiveSparkSQL把它轉化的語法數(shù)是新加一個WriteToDirectory邏輯計劃就可以了在物理計Spark里，但是支持到（英文）LOCAL的的話，希望把結果Hive另外也有其他的問題，比如說二義性的問題。如果一個SQL從兩個表里join數(shù)據(jù)按照條件取CID的話比較奇怪的是不知道CID是取A點還是BA、B另外還遇到了很多坑，我挑了一部分影響使用的bug，可以跟大家做一次分享。比如說做transformation的時候，我們在主程序里面要（英文）一個，尾部連續(xù)多個分隔符的話會，導致三列數(shù)據(jù)變成兩列，這樣作的時候都bug，這個做一些處理就可以了。bugtransformationlog（英文分這樣就會導致標準輸出transformation做標準輸出的時候就會把transformation另外我們還發(fā)現(xiàn)了一些小的問題，比如說這個表的數(shù)據(jù)是小文件，而（英文Spar（英文常多，他算排列性的時候（英文）方法。因為小文件多的話，就會導致（英文formatHadoopRDDSparkSQL二個小文件比較多，會增加的壓力，這是我們不希望看到的，這個優(yōu)化也非常簡單。我們最后在計劃的時候可以加一個（英文）partition另外SparkSQL提供的工具有問題他只支持Yarncluster模式但是會很占內(nèi)存。我們在使用Yarn的時候有一些架包，另外還有權限問題，另外（英文）要多寫一層，但是這也需要編碼，我們建立cluster模式的時候還要做一次，cluster另外JoinJoin對應的partition左邊一個，右邊一個。從右邊哈希map里取出來做，當你partition（英文）key了，然后辨別左邊partition，完成數(shù)據(jù)合并的操作。但是數(shù)據(jù)傾斜是怎么產(chǎn)生Spark做一個。推廣平臺的時候要找到用戶的痛點，要說服用戶用你的平臺，因為比較好，口口相傳的話大家可能會對我們的平臺比較感。deadline說我們要設定一個時間線，設定一個具體的時間，遷移起來才更有動力。量減少運維的工作量，這是我對360對Spark推廣方面做一點小小的，謝謝嘉賓：問一下關于Spark平臺的推廣，比如說其他部門，開發(fā)人員基SparkSparkAPR：對，我們業(yè)提供Spark的工具，可以直接在里面寫SQL就可以了，：謝謝老師：上一場360為大家了在Spark的應用，接下來來自美團的會繼續(xù)與大家，除了聚焦在某一個點上的還有構建整體的大數(shù)據(jù)，以及各種各樣技術的應用，接下來讓為大家一下整體上構建大數(shù)據(jù)平臺2011年加入美團最開始負責統(tǒng)計報表還有數(shù)據(jù)倉庫的建設2012年推動了數(shù)據(jù)Hadoop上，2014么做的，以及一些和應對策略，最后總結一下，聊一聊我對平臺化的看法。撐這一系列的有一個數(shù)據(jù)開發(fā)的平臺，這比較細，這是我們詳細的整體數(shù)據(jù)首先是數(shù)據(jù)介入與流式計算，系統(tǒng)產(chǎn)生數(shù)據(jù)分兩個場景，一個是追加Flume（英文有三個下游。所有的流失數(shù)據(jù)都是走（英文）Binlog些變更沒法發(fā)現(xiàn)等等的情況通過Binlog可以解決通過一個消息隊列集850構建流式計算平臺的時候充分考慮了開發(fā)的復雜度有一個的開發(fā)平臺，測試開發(fā)過程都在平臺上做，每年提供一個相當于對（英文）應用場景的封裝，有一個拓撲開發(fā)框架，因為是流式計算，我們也做了延遲統(tǒng)計和，現(xiàn)在1100這上面可以配置公司內(nèi)部定的某個，某個代碼，可以在平臺上編譯有調(diào)是基于Hadoop的數(shù)據(jù)應用主要是展示了對數(shù)據(jù)倉庫分成的規(guī)劃包括原始數(shù)據(jù)接入，到數(shù)據(jù)倉庫的基礎層，包括事實和衍生事實，維度表橫跨了聚合的結這幅圖是離線數(shù)據(jù)平臺的部署架構圖，三個基礎服務，包括Yarn、HDFS、流。CloudTable是自己做的分裝，我們使用Hive構建數(shù)據(jù)倉庫，用Spark在機器學習上查詢，也可能寫一些復雜的SQL。這里（英文）沒有部署到Yarn，跟Yarn是同步的（英文跟著Yarn目前還是依（英文目前嘗試著Hive目前每天有15萬個（英文）任務，有2500萬節(jié)點，后機房數(shù)據(jù)一會兒會介紹，總結了16K數(shù)據(jù)表，復雜度還是蠻高的。這是數(shù)據(jù)倉庫開發(fā)過程中的模板化SQL，上面有調(diào)配系統(tǒng)，然后數(shù)據(jù)質量的，資源管理和任務審核一條開發(fā)配置中心等等，數(shù)據(jù)管理體系我們這邊主要實現(xiàn)了幾點，第一點我們是基于SQL解析去做了ETL的資源大體是跑到Yarn上的，每個業(yè)務線會有一些承諾資源、保證資源，還可以彈性伸縮，里面會有一些預算。下面是我們工作的重點，對于關鍵性任務會SLA保障，并且包括數(shù)據(jù)內(nèi)容質量，數(shù)據(jù)時效性內(nèi)容都有一定的。給每個業(yè)務線做成本核算。這是對于數(shù)據(jù)中心，圖比較小，上面可以寫一些簡單的SQL，某一個表的數(shù)據(jù)結果是否符合我們業(yè)務的預期。下面是數(shù)據(jù)管理，就是我們剛剛提到的，對每個關鍵的數(shù)據(jù)表都有一些SLA的保障，下面是BI產(chǎn)品數(shù)據(jù)應用平臺化的場景我們的查詢主要是有一個查詢中心SQL上面的表有多少（英文做一些SQL的建設在統(tǒng)一來做，前面是一系列的BI產(chǎn)品，大部分是自研的，面向用戶可以直接寫SQL的自主查詢，并且看某一個指標，某一個時間段類似于（英文）的分析，以及給們看的系統(tǒng)。這是指標提取工具，其實跟（英文）先端分析引擎設計是比較類似的，20112011業(yè)務去共享的，跟業(yè)務的非常弱，跟業(yè)務是強耦合的，而且每次來數(shù)據(jù)需求是重度依賴SQL。我們對SQL分裝了一些報表工具，對SQL做了一兩個工具。主要是在SQL層面做一些模板化的工具，寫（英文某一個時間，某一個變量。這個變量會有一些外部的參數(shù)傳遞進來然后替換到SQL的行為我們在2011下半ETLETL越大，原來基于單機（英文）的數(shù)據(jù)解析是綁定的，所以2012年我們上了四臺機ETL（英文）2014有關系型數(shù)據(jù)同步模式，改為最高的統(tǒng)計模式。我們也是在國內(nèi)比較早的上了Hadoop2.0SparkOLAP下面重點講三個還有應對策略，首先是Hadoop多機房。Hadoop為什要多機房部署呢？非常的一件事之前只有淘寶這樣做2015年初我們500違約。我們溝通到新的離線機房需要在9月份交付，2015年6月份我們需要一千個計算節(jié)點，12月份的時候需要1500個計算節(jié)點，這肯定是不夠的。那就要進HadoopG，但是機房HadoopHadoop種。首先是APP內(nèi)部，就是任務內(nèi)部（英文）通信的網(wǎng)絡交換，比較明確的場景就是map額和（英文，第二個是非DataNode本地，如果跨機房部署讀數(shù)據(jù)就是跨機房的，帶寬量非常大。第三個寫入數(shù)據(jù)的時候要構建一個三節(jié)點的Space，這跟淘寶方案有所差別。我們每個節(jié)點都有一個所屬的機房屬性，把這個東西起來，基本上也是YarnBlock過Balancer模塊的接口把所有數(shù)據(jù)最終都搬遷到了大的離線計算機房做這個有那么深的對Hadoop代碼的掌控，我們要保證設計出來的結果，對于Hadoop原第三個整個遷移過程是業(yè)務全透明的，只要在他數(shù)據(jù)之前把塊分布到我希望Hadoo（請，提key，這個管理成本非常高。而且同一個團隊共個虛擬機開發(fā)總會遇到一個問題，某個虛擬機會被內(nèi)存任務占滿，要解決這個問題。而且由于在Spark發(fā)展的過程中，我們會持續(xù)地給業(yè)務提供Spark技術支持們都沒法第一時間獲取，這個溝通成本是非常高的。同時在推Spark的時候，我了zeppelin他們，最后選擇了zeppelin，覺得比較成熟?；诤笳唛_發(fā)，修復了一系列bug，補充登陸認證。這是任務主管部門，提交代碼到公司原有的（他要查查接口有一些（英文Spark（英文）管理起來非常不另外有一些先行Spark嘗試者寫了一些Spark的應用，這些應用如何讓其他最后聊一下在OLAP引擎部分的探索，大概2015年末的時候，我們開始關注非?？臁＿@些業(yè)務也比較，他們都會做一些特殊的方法來支持。我們調(diào)研了20（英文）一般都是提供給銷售管理團隊去看業(yè)績，對延遲要求比較高，對我們當時TP99，前99%查詢要小于3秒鐘。有多種維的指標要求比較精確，因為有些涉及到是你這個團購單，去重用戶數(shù)如果有當時考慮到了可能的方案一個是原來推薦的使用方法就是Prestohive、Spark，ORCFile這是最早的方案。另外有一個grouset，把grouset導到HBase里，有個二級索引的方案，這其實還是有一些瓶頸的。還有社區(qū)起的Druid、Kylin這些分按，我們這樣的場景思路是這樣的。首先直觀的躍度，我們Kylin團隊有兩個（英文。由于前面有這樣多的解決方案，我們怎么DPCStarWSchemaBenark構造了OLAP場景用這一套數(shù)據(jù)結構和數(shù)據(jù)內(nèi)容對不同的引擎進試，看它的表現(xiàn)和功能性，滿足的情況。并且推動的過程中持續(xù)的Kylin具體它提供一個界面你的維度、事實，有哪些指標，這些指標會被怎樣很度掛在上面，我們做了很多不同數(shù)據(jù)量級的參照，也參照了現(xiàn)實的數(shù)據(jù)。Presto、Kylin1.3、Kylin1.5，Drudi個確實比KylinBI7場景下的分析，用快法周期做一系列的聚合表，梳理聚合成績，這些聚合成73，TP95%1S2是不是數(shù)據(jù)平臺，作為一個平臺的團隊，價值其實就是這三個。第一個是對再一個所謂平臺化的公司，有多個業(yè)務線，甚至各個業(yè)務線已經(jīng)是（英文們的目標是跟這些先行業(yè)務線，我們跟他們一起走的過程中，一方面是輔助Kylin。我們的策略聞，他們會講新出的一個項目怎么推，不推我們推了，我們可能需要持bug、問題內(nèi)部也會有一個表共享，內(nèi)部patch。最后到拓撲模型的時候才會大改，特別在選擇的時候我們起實施的方案，我的就到這里，謝謝大家。：謝謝謝老師給我們帶來的精采，除了美團的實踐之外，還有關嘉賓：謝老師您好，想問一下像用了這么多開源組件，他們的可用性是怎么去保證的？某個組件可能會有依賴關系，就是數(shù)據(jù)完方面。他的架構和概念，這是最根本的?；谶@個最根本的概念、流程，要設計有效的和體系。我們有很多的重構，很多的代碼改動都是為了面向和的。比如說前一段時間我們了Yarn系統(tǒng)的問題，我們改了代碼，加了內(nèi)且持續(xù)去看這些數(shù)據(jù)，只能通過這個來保證整套體系的可靠性。其實數(shù)據(jù)平？2012Hive從（英文）我還沒這么干過。2：在分析解決方案的時候，你選沒選擇（英文：為什么沒考慮（英文）呢？首先是歷史原因，我們在推動倉庫遷移Hve（我當時是這么考慮的，我們也嘗試了兩個（英文）的方案。2：StomDM英文據(jù)的數(shù)據(jù)，離線流會進行補充。因為開發(fā)成本比較高，我們沒有都這數(shù)據(jù)。2：還是剛才第一個問題，你（英文）：當時比較，就直接（英文）可以了，包括穩(wěn)定性、可靠性，數(shù)Blog3：Kylin3觀的，我們看一個城市某一天的數(shù)據(jù)、銷售數(shù)據(jù)，這是非常宏觀的，但是事實數(shù)據(jù)行數(shù)比較多。Kylin的優(yōu)化和壓縮，放在（英文）CQL（英文）3：：接下來有請來自于Elastic公司的唯一一個員工介紹一下Elastic的情況，我們以前以為Elastic就是做數(shù)據(jù)丟進去做搜索的，但是實際上Elastic不光有ES，今天他會節(jié)ElasticStack整個技術架構，有非常多的叫，英文名Medcl，是Elastic的工程師。接觸Elastic比較早，2010年的ElasticBasteElastic是一個分布式公司，總部在硅谷那邊，另外一個硅谷在荷蘭特丹。我們有300多位員工，分布在很多的國家和不同的時區(qū)，各種各樣的語言。我們有一些開源的項目，Elastic，有很多在國內(nèi)還用不了。這張地圖是我們員工的分布，大部分都是交流、討ELK？ELK常用日志的搜索和分析。ELK也是麋鹿的單詞，所以有這么一個形象。ELK現(xiàn)在已經(jīng)OUT了，我們現(xiàn)在有一個新的產(chǎn)品叫Beats，所以用了這么一個形象，雖然比較搞笑。我們產(chǎn)品有各種各樣版本的LOGO，每個人用的LOGO不一樣，工作內(nèi)容就要用特定的版本。所以我們經(jīng)常會頭疼，ES2.0應該用什么版本的Beats，kibanba用什么樣的ES，是不是有對應關系。既然我們都很困惑，就從5.0開始kibana5.0ElasticStack場景是搜索，Elastic搜索的。還可以做一些簡單的聚合，比如說左邊代碼對不同語言進行統(tǒng)計。有探測器，發(fā)送到火星上，探索1號、探索2號。他們有很多傳感器，會收集各探測器的正常運行電池也很小只有100W怎么來保證呢？就是用ElasticStack來分析。另外可以做運維日志的分析，比如說Datadog是用來收集服務器的一些ElasticStackElasticStackUserIntertfaceElasticsearchIngestBeatsLogstashLogstash200以把IP對準坐標，幫你查出來，附加到消息上，消息會更加豐富，可以做的Packetbeat，還有系統(tǒng)狀態(tài)性的，系統(tǒng)相關的信息，還有日志的相關信息。Packetbeat是在網(wǎng)絡層面做的，跟Sniffs是一樣的，它有網(wǎng)卡，它可以解MySQL、HTTP，對一個端口數(shù)據(jù)可以進行，一個包再做分析。如果別人是，在局域網(wǎng)嘗試，已經(jīng)文件了，這時候你要把IP給干掉，發(fā)現(xiàn)人家早做完，跑掉了，我們是一個實時的工具，實時包，做分析、。還有日志的Winlogbeat，是收集Windows系統(tǒng)的一些細細的另外Filebeat是收集文件的工具，可以文件，把這些內(nèi)容傳給Elasticsearch，更加輕量級，對系統(tǒng)開銷要小很多。還有一個beat是Topbeat，和Linx下面的很類似，MetricbeatMySQL我們下面有一個就是用來生成一個beat的一個快速可以在里面展你想要的內(nèi)容。Demo整個ElasticStack最 的就是Elasticsearch，Elasticsearch到底規(guī)模能做到多大？他們有100多個集群1700多個節(jié)點netflix而有150多個集群，3500個節(jié)點，非常大。前面說ElasticStack有展現(xiàn)，你只用Elasticsearch就各種各樣的事情，比如說有來用Elasticsearch進行數(shù)據(jù)分析，做日志分析，這Elasticsearch不是一個搜索引擎嘛，你說這么多是不是太夸張了？其實Elasticsearch最早只是在1.0的時候，了Facets，只是做一個簡單的數(shù)據(jù)聚合統(tǒng)計。當時遇到了各種各樣的問題，內(nèi)存、效率問題。之后重新設計了，叫Aggregation2.0PipelineAggregation。最開始叫你懂得，現(xiàn)在還得會分析。，Aggregation據(jù)分布統(tǒng)計導入方差等等還有基于地理位置的周邊一個范圍的數(shù)據(jù)ElasticsearchElasticsearch刷新，刷新時間越頻繁數(shù)據(jù)統(tǒng)計的壓力就會越大，它是可嵌套的，是如果做的搜索商品的分類分類如果是3C里面又有電腦每個分類出現(xiàn)多少次，做一個層級的統(tǒng)計。，AggregationBuckets，TermsHistogramGeohash坐標點很細，你站在這里，我站在那里都不一樣，但是我們分析的時候這較好的。Metrics，是用來對你數(shù)據(jù)進行加工的，比如說數(shù)據(jù)包括架構信息，一個平均的價格或者最大值，99%的價格是多少，就可以用Metrics來應到Buckets的概念，再分別統(tǒng)計下面的總數(shù)，個數(shù)，這兩個操作對應的是Aggregation特征，或者是一些有的東西。就像我們在地面上什么都看不到，在天上就可以做這樣的一個事情。當然如果在上空搞航拍的話可能什么都看不到，因為我們的天氣是這樣的。后續(xù)可以基于PM2.5的數(shù)據(jù)進行簡單的分析，看這些先看數(shù)據(jù)是長什么樣的，Elasticsearch面數(shù)據(jù)有一個字段叫city有多城市光是的還有時每一天都有PM2.5PM2.5們。如果要用Aggregation的話，先了解一下它大概的結構。Elasticsearch查詢表達式是Aggregations格式的，Aggregations是一個特定的名稱，當然也可以簡寫。下面可以看到每個Aggregation的名字，自定義的名字。因為那個類型有很多，可能會做很多操作，也可以定義操作的名字。也可以定義多個Aggregation過來再刷一次另外Aggregation是個層級的比如說我們想做多級分類的統(tǒng)計，這是統(tǒng)計全年的空氣質量，這是一個統(tǒng)計地址，標紅的是表示用terms我們可以看一下右邊出來的是查詢和分析出來的結果，keyaqlevel質量的評價，空氣是優(yōu)還是良還是嚴重污染，良就是我們其中的一個key。一共11818剛剛說了這是全年的，比如說某一天我們想看城市的分布，比如說照城市先做一個分組，嵌套進來，對城市PM2.5做一個平均，這是我們所有時間源是38點多，佛山是42點多，相對來講好很多了PipelinePM2.5為一天數(shù)據(jù)不太多了，知道這一個月的，用了平均的算法，interval，做一步的加工，然后以30天為單位進行處理。前面第一個是按天的平均值，movingavg5067Aggregation層，做數(shù)據(jù)的計算。Aggregation的列式，如果說你的數(shù)據(jù)是實質類型的，我們在已經(jīng)轉化數(shù)字類型了對內(nèi)存和效率來講計算起來都是非?？斓?。例外我們的數(shù)據(jù)有這么多，Aggregation只要數(shù)據(jù)跑一遍就可以了。現(xiàn)在有一個新的操作做計算，做Aggregation，是要多跑幾次？不需要，只需要跑一次，跟查詢在一起跑一次就可以了，不管AggregationCPU話磁盤什么的基本上不會有太大的變化。Coord里面有兩個數(shù)據(jù)。一個是DocValues，數(shù)據(jù)原始值，因為我們要做計算，肯定不是針對他的值做計算，而是需要知道原始值，要分析的時候肯定是需要原始的Luceneindex。在這一層有個評分的，另外還有做運行計算的。AggregationAggregation，Aggregation度很慢，是用了Approximatealgorithms的算法，它的內(nèi)存是固定的，不管是幾十條還是一條，他們都可以用幾k來做內(nèi)存。所以如果你做大數(shù)據(jù)分析的話，5%中一個三個很難都滿足Hdoop可以用ExtrackAggregation關注的是大數(shù)據(jù)，另外Time是精準的如果數(shù)據(jù)量非常大也想做這么一個統(tǒng)計的話有兩種模能不是全量數(shù)據(jù)，這個模式會不符合數(shù)據(jù)的量。另外可以Sampier而對數(shù)據(jù)做采理位置來算。比如說分析周邊300公里哪些地方是不是有嚴重污染，因為沒有什么比較大的污染工業(yè)工廠，肯定是飄過來的，300公里發(fā)現(xiàn)哪個地例，上面是我們持續(xù)分析的可視化案例，好幾個指標統(tǒng)計在一起，可以看和的比較。上面是的，下面是的，進行了一個比較。還有云圖，還有地理位置的熱點圖，可以看到這邊果然主要是河北這一塊，自然也受到一定的影響造出這樣一個圖象，6月份的時候是比較不錯的，2月份比較差，這是基于地理位graph，它是做關聯(lián)分析的，還可做參照，做比較。這邊和好幾個污染都有關系，輕度污染、中度污染、重度污染，很多時間都在污染中渡過。也有優(yōu)的情況，優(yōu)的線只有一根，每個點都比較不錯，我們可以看到周邊的城市跟這幾個污染指標都有關系，也ElasticStacklogstashbeatsQQDemo嘉賓：問一下關于權限的控制和告警的機制，不知道Elastic是怎么設Elasticeasearch（英文）們做到了（英文）嘉賓：我們采取了很多日志，但是發(fā)現(xiàn)日志有問題，需要批量刪除，Elasticeasearch到2.0以后好像就需要安裝一個插件，就要重啟，導致服務終這跟Elastic底層有關系你刪除服務尤其刪除之后它有可能還在，的重建，現(xiàn)在我們是數(shù)據(jù)可以很方便的從Elastic到另外的一個Elastic，可以設新的分池，我們在2.3之后實現(xiàn)了一個新的任務管理。以前的東西，比如說查都放在運行，可以看到它的狀態(tài)，并且可以控制它，Elastic就是這樣一個任務，在去做重建，也可以它的一個情況，把這個給刪掉。嘉賓：但是都是需要的是吧ElasticAPI：我們開始今天最后一場，邀請到來自京東架構師先生，介紹“Presto2012的相關事情，去年的時候，在2014年開始進入Presto，在公司內(nèi)部Presto的應用比較廣，2016年已經(jīng)把Presto集成到京東云公共開發(fā)平臺里了，今天主要給Presto國內(nèi)相關公司最初接觸到Presto的時候，美團公司他們在研究Presto的時候比較早，與他們了解的過程中，他們在公司內(nèi)部做Presto的推廣，后來沒有推的很開。我們對Presto進行對比、研究性能方面的以后，我們覺得Presto臉書自己之外，還有（英文）是一個商業(yè)集成公司，他們對Presto的應用也比較深。首先我給大家簡單介紹一下Presto的架構概念，這是發(fā)布的圖，這個圖Presto著具體的計算業(yè)務。在解析的時候，形成執(zhí)行計劃的時候，也是將SQL五分成了各個階段。比如說有專門從數(shù)據(jù)源數(shù)據(jù)的過程，也有做聚合操作的，還有其PrestoB級別的時候兩個最重要的，或者可以擴展的一個特點，就是可擴展性數(shù)據(jù)源查詢的功能，這也是當初為什么選擇Presto引擎作為解決我們某個場景時候很重要的決策因一可擴展性是Presto從開始到慢慢的形成過程中它開放的非常方便或者是非?？蓴U展的API框架可以擴展的數(shù)據(jù)源操作比如說MySQL，ESSQL比如說是（英文）SQL各個數(shù)據(jù)源之間完全是一套統(tǒng)一的CQL邏輯查詢，比如我需要一個維度表，互，或者是可以帶給我們一些便捷性。我們的匯總了當時做這個事情時候的Presto層，在公司數(shù)據(jù)業(yè)務發(fā)展到一定程度的時候，帶來的必然的結果。原東數(shù)據(jù)底層平臺架構中會有的想法需要我們實現(xiàn)比如說要一個比Hive更快Presto項目。財務審計在公司內(nèi)部中數(shù)據(jù)在非常多的地方，在MySQL里等等，這么數(shù)據(jù)源做ETL的操作是非常麻煩的，或者很難在很短的時間內(nèi)，或者很快速的將PrestoSparkCQL們也想用SparkCQL解決這個模型，但是數(shù)據(jù)源操作等等的情況，在公司，我們公司有一個和臉書聯(lián)系比較緊密的介紹了Presto可能會更合適。所以PrestoSparkHold100GB圖紅色線代表的是SparkCQL，藍色的是Presto，可以看一下耗時Spark比Presto好一點，中間有兩個柱狀的比較高的，SparkSparkSQLPrestoPrestoPresto2015Presto20122013Hadoop2015Prestobug2015年底我們就有了第一個運行項目的上線，在2015年我們通過半年先后推出了兩個Presto的項目我們也想放到臉書那個版本中但是臉書覺得我開了Presto的兩個開源版本，我們公司內(nèi)部也是大量開Presto的版本。2015年維，成功的沉淀，我們在2015年年初的時候，開始講Presto向京東的共有云，Presto，豐富Hiveconnector語法版本的定位和我們的定位不太一樣出點PrestoMyCQLETLMyCQLMySQLMyCQLMySQL片，要有跨分片查詢，系統(tǒng)的操作，在分表之間的一些操作，這都是較難的。，我們有這個特性以后就主動改造了這一點，就是MySQL分工，將查詢類型條件下推到MySQL層面。Presto是把數(shù)據(jù)到里面的，關系數(shù)據(jù)庫也是這樣的，將數(shù)據(jù)拉取到Presto集成內(nèi)部中。舉個簡單的例子，比如說我們要做量表的（現(xiàn)的呢？其實第一點就是將CQL云進行解析，到MySQL只是加一個條件，A點某某某的時候，會根據(jù)你的條件將關系，將CQL簡化到MySQL執(zhí)行，盡量使MySQL其實我們有時候也使用Spark，我們在優(yōu)化的時候，或者我們在MR做優(yōu)化的時候，是優(yōu)化最初input的數(shù)據(jù)量盡量少，優(yōu)化其實也是基于這個條件去優(yōu)化的。對于Hiveconnector的優(yōu)化，是集中在語法上的優(yōu)化。其實他很多語法是Hiveconnector公司內(nèi)部中他們用Hive都非常習慣了當然你要讓他從Hive轉成Presto的份驗證和權限控制首先說驗證我們的過程中都是需要來支持的，對Presto的支持也是必須的，兩個操作HDFSHivemetastore也是需要通過kerberos驗證的，以及對庫/表操作時需要判斷是否有相應的權限，是否有Database、TableonYarnonYarn一種趨勢，或者是一種使用方式的改變。onYarnSliderYarnPresto做的事情主要是集中在和容錯處理。比如說NodeManager宕機了，以及AppMaster/CoordinatorcontainershutdownIPshutdownIPIPrestoHiePresto，YarnPresto在UDF層面改造也是來自于公司內(nèi)部流考慮的一個方式，他