呂信：PrestoDB在京東的應用實踐
京東商城集團運維部數據庫工程師呂信在為大家分享了京東在PrestoDB方面的使用經驗與研究工作。以下是演講速記：
呂信：大家好，我是來自于京東商城運維部的呂信。我在京東商城期間，我其實在這三年內主要是從事大數據相關的開發、調研以及架構數據的工作，因為我之前是在京東商城主要負責京東商城整個的Hadoop的運維管理和架構升級和改造，后來京東商城有一個在大數據方面有一個戰略調整，我們急需要構建我們的數據倉庫。要求很簡單，要求實時和準實時的數據分析和計算，經過我們調研，后來我們選到了PrestoDB。這中間的就要求很多，是我們的首席科學家與 Hadoop中間達成協議，通過內部的代碼公開，我們會有深度合作，在京東推廣PrestoDB，作為京東實時數據倉庫，其他的待會兒會跟大家做詳細的介紹。
今天的主要內容首先我先給大家介紹一下PrestoDB它是一個什么樣的東西，以及它的架構是怎么樣的？我們選擇PrestoDB進行測試和對比，以及PrestoDB在京東商城的使用過程中存在哪些問題？以及跟京東商城的耦合度上有什么樣的困難，以及我們京東商城在使用 PrestoDB過程中遇到的問題，和我們已經采取和實現了的解決方案。最終我會跟大家簡單介紹一下PrestoDB在京東哪些業務方面進行使用。
PrestoDB 我相信大家應該都或多或少聽說過，或者是已經在使用了，因為它是一個比較新的一個產品，它的出現其實主要是從非死book，大家知道還是 非死book的產品，對于實時和準實時的交互分析它顯得有點力不從心，因為大家都知道了Hadoop如果要做一個簡單的數據查詢，你可以輸入一個簡單的語句，喝杯茶過二十分鐘就可以出結果了，對于我們京東商城來說這種現象是可以承受的，它有很多數據核查和比對的工作，你不能讓我輸一個很簡單的語句等二十分鐘，他們覺得不可接受，他們要求是能夠讓我在秒級，最多在20分鐘之內出結果，最后我們經過調研選擇了PrestoDB。非死book PrestoDB它也是為了解決同一個問題而發起的項目，他在解決這個問題之前也嘗試了很多的開源的產品和工具，都不能夠達到他的要求，要不他支持的語法簡單，就是功能性有一些限制。它在2010年秋季啟動了PrestoDB的項目，在2013年下半年它在公司內部已經大量地推廣使用了，通過我們與他們這個項目的領導人交流，他們內部其實每天有一千個員工在使用集群，數據掃描能達到300P，每天能夠執行上萬個這樣的查詢，我們也相信在京東應該也可以這樣使用。
其實PrestoDB在國內用得比較少，但是在北美的公司都在大范圍地使用，所以說我們相信PrestoDB在京東，以至于在國內會得到大量的推廣和使用。因為這個PPT寫得比較早，寫這個PPT的時候很有幸京東占據了四個區，PrestoDB在0.54版本第一次發布，到今年兩三年的時間已經更新了0.96，每兩個星期會更新一個版本，社區還是非常活躍的。
我介紹一下PrestoDB是一個什么樣的東西呢？它是一個分布式的基于內存的分析工具，它能夠支持這種交互式的數據分析和計算，它能夠處理的數據量大家比較關心，它能夠支持多大數據量，它只是一套純數據框架，不涉及到數據存儲，你能夠處理的數據量是根據你的集群的規模是成正比的，如果你的集群規模節點數比較小，它處理的數據就會比較小。我們在京東使用的經驗，我們的集群有 94個節點，每天掃描數據量在500T左右。它快其實是針對于Hive相比，它是基于這種架構，它不會產生數據的堵塞和等待的過程，它的性能非常快。如果大家沒有用過Hive的話，它完全支持標準的規范。
PrestoDB它最大的一個亮點就是最后一個亮點，它作為一個純計算框架，可以跨越多個數據源，可以很簡單地把一個表進行關聯計算，是沒有任何問題的。
PrestoDB 整體的架構是這樣的，因為PrestoDB它有一個框架，就是PrestoDB的整體計算框架，它的數據源是完全解藕的，如果你要去截取PrestoDB 請求，它可以截取你所有的信息進行計算，整個的過程其實下面這些就是Presto可以支持的，它本身提供的有HDFS、MySQL等這些，紅的這部分是我們京東自己開發的，因為我們有這種業務需要，紫的這些是我們經過了改造，PrestoDB除了讀取數據源之外，它會有這種概念。PrestoDB提供兩種方式的訪問，它提供JDBC去訪問，也可以提供客戶端去訪問。
這個是官方提供的一個整體架構圖，這個架構圖其實說白了只是針對于Hive的架構，它在讀取Hive的數據的時候會通過你的KLAN端，它從字面來說是協調者，把你的查詢發給數據，會執行你的計劃，它會根據你的要求來執行計劃。它最終會把你的計劃分成四種，（S）是專門負責數據源和數據讀取的，（P）是用來做最后的全局排序，或者是最終要把這個數據輸出給用戶的時候，是要通過這個反饋的。它對于DDL的支持會是比較弱的，但是它支持部分DDL的語句，所以說當你執行DDL語句的時候會在最終有一個過程。
這就是說比較深入代碼的，也不算太深，這是一個很簡單的一個客戶端，往PrestoDB集群里面進行查詢的過程，客戶端這樣一個對象，最后它啟動的時候會在每個節點上啟動一個LTP監控的框架，我的客戶端發送一個請求，發送給我的Coordinator，然后通過這個地方去生成各個執行計劃、子執行計劃以及其他的執行計劃，它會根據數據本地性發送到相應的節點去啟動相應的步驟去完成查詢。
剛才說了那么多，其實大概有這幾步，首先我Client發送一個請求，發送到本地，最終它會生成一個請求，然后根據數據的本地性發送到相應的節點上，啟動相應的（T），任意的一個查詢首先都是去讀取數據，讀取數據之后，它下面會有直接的（S），完成聚合、操作和計算，最終反饋給你的Client。
這是我們在進行PrestoDB調研的時候做的一些對比的數據，如果說你的這個查詢是涉及到計算的，你應該就能夠看得到。如果說你的查詢涉及到計算的，PrestoDB的性能會比Hive的性能高出來幾倍，但是如果要是說你沒有計算和查詢，它們的性能是相當的，大家可以看到這個，如果我是在Hive里面，它是不涉及到計算的，只是作為一個數據文件的掃描而已。
這個是我們針對于單個查詢語序做的測試，我們在PrestoDB上針對我們實際的業務做了相關的測試，我們實際相關的業務涉及到的場景比較多，我們涉及到有十二個實際業務場景，有我們的精準營銷、個性化報表，以及安全性查閱分析等等很多業務場景。我們的測試的硬件環境是按照軟環境下去做的，我們當時拿來測試的數據總量是6.7T，平均單次掃描量是450G，涉及到查詢語句很多很多。最終我們得到一個結論，跟PrestoDB官方發布的測試結論是非常吻合的，因為我們知道有很多這種產品大家為了推銷自己的產品有很多公司或者社區避重就輕，他在測的時候會專門選擇適合他的場景去測。
上面是 PrestoDB公共的東西，以及我們對PrestoDB發布一些性能的驗證，下面這一半主要是京東商城做了哪些工作，京東商城其實做的最大的工作是 PPDO的開發，因為京東商城跟非死book這邊實現業務場景還是有所不同的，因為非死book那邊大部分的業務都是對于ETL完成之后的數據進行了分析和查詢。但是京東它有一個很廣的應用的業務場景，比如說6.18、或者雙11我要實現查詢我當前這一刻的成交量或者是訂單量。以前京東商城 6.18期間需要在6.19才能看到我當天的成交量，所以京東商城有迫切的需要我要看到我當時的成交量，我們當時采用的方案，我們用PrestoDB它跨數據源的特性，PrestoDB數據源我們選擇的是線上從庫的從庫，直接去讀取數據進行計算，這是我們TTBO完成的主要的功能。
我們做的第二個工作是數據瓶頸的突破這一塊，因為大家用過Spark，可能我的主要精力在Presto上，Spark我也有所涉獵，雖然不深入，但是我們經過測試發現這種分布式的內存查詢和分析引擎有一個很致命的短版，我的全局排序是我的短版。如果說我一個表數據量是20G，我們去做排序。但是據我們測試的結論，我們當時用Spark做過測試，但是一旦涉及到它有一些過程，這也是我們當時沒有選擇Spark的一個原因，去年上半年測試的，不知道現在Spark有沒有把這個問題解決掉。
我們對這樣一個問題進行了修正和更改，我們整個集群里面，它在做全局排序的時候，我們有一套完整的調度機制，會讓它調度到我們的PrestoDB上，我們PrestoDB集群里面有四到八個專門完成全局排序的計算。
我們做的下面一點工作是PrestoDB是默認不支持身份的認證以及權限控制，我們對PrestoDB進行了改造，它可以支持身份認證和權限控制，從而可以在企業內部得到大規模的應用，PrestoDB是不對Lzo文件進行支持的，我們建議數據部門把數據重做一遍，我們修改了Hadoop，讓它能夠支持 Lzo文件。PrestoDB我們進行了insert的功能開發，我知道現場每個人都知道Hive，所以我們PrestoDB為了滿足我們工程師的使用方便他們，我們實現了完全覆蓋Hive功能的開發。Presto它默認不支持Create功能的，我們在集群管理方面做了一些工作，我們運用官方的 Presto可能在非死book內部已經比較成熟了，不會我今天有個新的業務加入了你的集群，明天又有一個新的業務加入你的集群，這方面做得不是太完善，你業務加入集群之后，我可以直接放在你的文件夾下，我在接入新的業務或者更改新的配置的時候，我不需要集群準時、馬上就可以刷新到你的更改。
因為Presto是強類型的，我在做數據查詢，等號兩邊的條件要完全一致，所以說在使用過程中你如果想用Presto完成數據類型的轉換，對于我們熟悉 Hive的工程師來說比較麻煩，我們為了方便京東商城眾多BI工程師的需求，我們也是完全向Hive靠齊。京東版的Presto跟Hive使用是一模一樣的，但是它的性能比Hive要高。
下面我們詳細介紹一下京東PDBO有哪些功能，它支持數據的緩存、并存、讀取及性能的智能優化，京東商城大數據量的查詢是在內部分表里面去做的，我們業務研發人員會通過業務代碼把這些都給組織起來。但是我們在推廣Presto的過程中，他們就提出一個要求，我有一個1024張分表，你能不能給我形成一個TABLE，你只讓我查詢我的邏輯名就可以了，我們京東的Presto可以做到這一點，默認的Presto 只支持一個庫一個表，我們對它進行了改造。我們可以支持只讀你的邏輯表，把它抵成了所有的影射關系，大家可以看到我們到每個（W）上就可以有Cache，我查詢完了之后，它是通過我們的RBD五去做查詢的，我們會有一個表，記錄了我各個分庫分表的信息，我的路由器會把我各個分庫分表的信息組織到一塊，把所有信息讀到我的集群里。
我剛才已經說了，Presto它默認你從社區上可以下載一個版本去試用，但是它都是單個Worker對應單個表，我們公司的網絡是牽涉到的網絡很大，比如說我達到了五百多G，我通過這個去讀就讀死了。但是我怎么樣才能夠加快它的讀取的速率呢，我都個Worker去讀這樣一張表，我們的Presto集群有一個數據庫，數據庫里面就是我剛才說的信息，里面記錄了我的目標表需要多少個Worker去讀，在選擇Worker的時候，會就近選擇我的同一個（R）上的Worker去讀我這一個表里面的數據。
Presto做的另一個比較高大上的工作，我們實現了 PDBO的智能優化，這個智能優化是怎么來的呢？是基于這樣一個并行讀取來做的，我讀一個數據，有一個十個Worker去讀，每個Worker就要讀一片數據，我這一片數據應該怎么分呢？你需要指定你切割自斷，一般情況下我們通過逐漸切割，如果說逐漸從1到1萬去分布，我每一個Worker去讀一千個記錄，我們讀的是線上的從庫，這個數據是實時變化的。所以說你切割的主件有可能分布不均勻，你起始是1到1萬，這樣我們就面臨一個問題，你分了十個 Worker去讀，你第一個節點讀了一千，第二個節點是零，第三個是一千、第四個是一千，我所有的Worker節點沒有得到充分的利用。然后我們就是學習里面的一個機制，我們能夠對它動態度曲的數據進行動態的分析和智能的優化，是一個學習和改進的過程。我剛開始做一個初始化的配置，第一次查詢性能低下，每一個Worker會實時采集到數據，我根據每一個結點上讀取數據的疏希程度，最后拿到一個結果。我不管切分的主件是否均勻，也能夠滿足我的每一個節點讀的數據大致相似。
再一個就是現在這個主題是我要講的我們Presto集群在使用過程中，不光是Presto集群，Spark集群讀取過程中不想看到的，它給你一個排序，你就去等，等很長時間才出結果，甚至等了很長時間它的查詢失敗了。我們在使用Presto的過程中也發現了這個問題，我讀的這個數據量超過128G的時候它就會失敗，當時我們給內存搞到256G不就完了呢？Presto在各個節點選取的過程中就是一個隨機選取的過程做這樣一個排序的節點，如果你要滿足這樣一個查詢所有的都要升級，我們修改了Presto的調度機制，它在調度Spark的機制，我們加入了一種概念，我在集群里面選擇少數的幾排節點作為頭級節點進行升級，同時我整個就會形成非對稱式的結構，我里面有十分之一的節點。平時它只會用到它內存的50%以下，一旦有全局排序的過程過來之后，我在調度的時候，我其他任何都不會在我這個節點上分配任務，這個就完全支持我的全局排序的計算，從而能夠在很小的成本基礎上達到我集群的計算性能。
我們在京東推廣Presto的過程中，很多業務部門剛開始的時候不想使用，為什么呢？就是Presto本身它是不支持身份認證和權限控制的，默認情況下你發現我只要知道你的地址，我隨便從網上下載一個端只要能夠連到你的服務器，我就可以用你的計算機完成計算，這是個很嚴重的問題。另外一個更嚴重的問題，有很多業務涉及到很多敏感的數據，這個數據只能他自己查看，他不想讓別人去查看，所以說Presto也不支持這種權限的控制，我們就遇到了很大的阻力，我們專門組成一個小組，花費了兩個月的時間自主研發出來一套在Presto上運行的一整套的權限管理系統。它的整個過程其實從邏輯上來說很簡單，就是我的Client端會對你的數據進行解析，解析出來我需要得到哪些？我就會去我的服務器上我的所有的用戶的權限信息都是通過我們的DB系統進行申請和發放的，它申請和發放完這些數據之后會在一個表上，我會通過這張表去查詢，它有沒有這樣一個權限去查詢？如果沒有這樣一個權限你最后反饋有沒有查詢的信息，如果你登錄的時候沒有提供任何密碼是登錄不進來的。如果要是說通過了身份認證，后面的機制完全就是Presto本身的計算機制，就可以成功愉快地運行你的數據了。
下面是我們進行的Insert的操作，你可以插入多列或者多行都沒有問題的，其中最大的一個亮點是讓我們使用 Hive的BI工程師可以支持動態分析的插入，這個語法我就不用跟大家說了，大家應該都知道這種動態分區，它也支持了我們Hive里面的操作。現在也就是我們在京東商城推廣Presto，線上有四個業務都在大范圍地使用Presto，因為我們已經做到了權限的認證、控制，所有的用法都跟Hive一樣。
我們還做了一些功能的改造，上面黃色的部分是Presto官方的版本，我只是創建這樣一個表，并且這樣一個結構是OK的。然后我也可以創建分區表，大家用過 Hive的應該都知道，我可以指定一二三級分區都是OK的，出了新版本之外其他的可能沒有。有一個最大的亮點Hive沒有這樣的功能，這個功能也是我們的業務提出的，他們提出一個什么要求呢？我在使用你的Presto，我的成本很高，我要做一個數據的初始化，我做一個數據的初始化，我要先把結構建起來，我再寫更多的Insert語句，你能不能把這部分工作合成一條完成呢？我們可以得到，我們實現了這樣的一個動態分區的工作，Coordinator會把你動態查詢語句的最后兩列作為你的分區的值，完成動態分區并創建表，完成數據的導入，所以說在我們的業務部門使用Presto的過程中會感覺到很愉快，為什么呢？因為它已經完全可以擺脫繁瑣復雜的工作。
我們整個Presto執行架構是這樣，我們創建了一整套的IDE的調度機構，完成任務的定時，能夠定頻率的調度，所有的調度通過CLI的方式去讀取，這就是我們整個的架構，架構很清晰。
下面我說一下Presto在京東上的使用場景，它可以滿足數據查詢，能夠短時間內反饋出一個結果。它可以做準實時的查詢，在京東我們使用的業務是精準營銷和個性化報表，大部分的查詢都能夠在一到兩分鐘之內完成。我剛才也說了，也很方便地完成數據的抽取，我們以前用Hadoop都很繁瑣，你所有的ETL的工作都可以用一條語句去完成。其實我們也很歡迎各個有志人士加入我們一起去完成這樣一個非常酷的工具類的開發，如果大家對我們的Presto產品以及想要和我們一起做這樣的一個很偉大的事情，大家可以通過掃二維碼加入我們的技術群，也可以加入我們的中文社區，這個是得到非死book授權的，非死book在中國區的非死book網，技術由京東商城的集團運維部來負責，可以加入到這樣一個社區網站大家一起交流，如果有深入的問題可以找我們的接頭人，這是他的聯系方式，加入我們，謝謝大家！
提問環節
提問：如果說資料毀損的話你怎么去做？
呂信：Presto是完全數據源解藕，我可以查詢我們LDF的數據是三備份的，我損失一份它會自動完成第三份的復制，這其實是LDF的機制，對于其他的數據，也就是說我的從庫，比如說我的從庫掛了，我們京東會有一個事實切換的機制，它切換之后我們Presto會去探測你的兩個主從庫用的是哪一個IP，我們探測之后會回寫到我們的表里頭，有稍微的服務中斷，不會超過一分鐘。
提問：這個主要用于報表？
呂信：我們在京東實際在線上使用的業務有一個精準營銷，還有一個個性化報表，就是這位朋友說的個性化數據的分析，各個報表，這是一個很大的業務場景。另外，我們京東還有安全部門要對所有的用戶存在的風險進行分析查詢以及比對，還有另外一個業務我們現在正在逐步取代ETL的工具，用Presto完成數據的導入和到處的工作，一共有這四個應用領域。
提問：你們聯機基本上沒有什么大的壓力是嗎？平時做的業務，我們在京東上買東西，那個壓力比你這個分析還大吧？呂信：是這樣，Presto它是不支持事務的，它是一個跟你的想法不一樣，京東訂單的處理沒有這些，但是Presto主要做我出報表是OK的，分析型的工作，非事務性的，ORAT的工作，我們京東的訂單沒有在這上面，如果在這上面可能就會出大亂子了。
提問：我還想問一個問題，我看到你們做了很多對Presto的擴展，這些擴展我個人感覺不一定是符合Presto當初的架構的本意的，那你們是自己分出來了？
呂信：這些代碼PDBO的代碼已經提交給非死book了，這方面的代碼量很大，設計得也很復雜，我們與非死book正在進行交流，他們最初交流的意見是我們Presto最初的定位是完成數據的導出，他們暫時不會接受我們的代碼，我們Insert這種功能提交給社區了，Presto馬上發布1.0，有可能在1.0看我們做的很酷的功能，轉換已經提交上去了。
以上為現場速記文稿，錯誤疏漏再所難免，歡迎批評指正。更多精彩內容，請查看大會直播專題</b>：http://special.csdncms.csdn.net/OSTC2015/