阿里慢sql
『壹』 阿里的UMP雲資料庫和RDS雲資料庫的關系是什麼
RDS是阿里雲提供的即開即用的關系型資料庫服務，兼容了Mysql和SQL Server兩種資料庫引擎。在傳統資料庫的基礎上，阿里雲RDS提供了強大豐富的功能從而保證了高可用性、高安全性以及高性能。此外，RDS還提供了諸多便利功能提升了RDS的易用性。
★高可用：
採用主從熱備的架構。主機down機或者出現故障後，備機秒級完成無縫切換,服務可用性承諾：99.95%
提供自動多重備份的機制。用戶可以自行選擇備份周期，也可以根據自身業務特點隨時進行臨時備份,數據可靠性承諾：99.9999%
數據回溯到任意時間點。用戶可以選擇7天內的任意時間點創建一個臨時實例，臨時實例生成後驗證數據無誤，即可將數據遷移到RDS實例，從而完成數據回溯操作。
★高安全
提供白名單訪問策略。可自行設置允許訪問的IP及IP段，有效防止黑客掃描埠進行伺服器攻擊。
提供閾值報警的功能。支持實例鎖定報警、連接數報警、IOPS報警、磁碟空間使用報警、CPU報警等。
提供SQL注入告警。將對發往RDS的疑似SQL注入的語句進行記錄並展示，供用戶進行程序調整，杜絕SQL注入的發生。
SQL審計。記錄所有發往RDS的SQL語句，系統將記錄SQL語句相關的連接IP、訪問資料庫的名稱、執行語句的賬號、執行時間、返回記錄數等信息。供用戶對RDS安全性進行排查。
控制台操作日誌。記錄所有在控制台上進行的修改類操作，便於管理員查看並管理RDS。
★高性能
RDS使用高端伺服器來保障每個資料庫都擁有良好的性能。
針對MySQL類型的RDS，資料庫版本融合了阿里巴巴官方資料庫補丁，有效的提升了RDS的性能。
性能監控。提供多種監控圖方便用戶跟蹤RDS的性能狀況。如IOPS、連接數、磁碟使用空間、CPU利用率、QPS\TPS、網路流量以及多種資料庫的內部監控指標圖
慢SQL匯總分析。將資料庫中的慢SQL進行相似語句去重，按照指定方式排序後進行展示，為用戶排查慢SQL優化資料庫性能提供幫助。
優化建議。提供多種優化建議方便用戶優化資料庫性能,如：存儲引擎檢查、大表檢查、無主鍵檢查、索引過多表檢查、缺失索引檢查等
★易用性：
提供向導式遷移服務，使用戶能夠通過WEB端管理控制台輕松將自建資料庫遷移至RDS。
快捷查看資料庫系統日誌，用戶能夠RDS管理控制台查看資料庫級別的系統日誌。
便捷操作資料庫實例。提供完善的WEB端管理控制台，幫助用戶操作資料庫實例，如重啟實例、刪除BINLOG、備份等等。
輕松升級，按量付費。RDS提供實例配置和資料庫版本的在線升級服務，隨開隨用，按量付費，資源業務輕松拓展。
『貳』 阿里雲慢sql告警，單個sql執行時間很短，會不會出現多個sql累計排隊導致cpu飆升
如果是使用頻次比較高的sql，很容易出現連接暴漲，cpu飆升或者網路帶寬佔用太高等問題。
『叄』 技術面試會問很多技術問題嗎
筆者其實沒有想到去面試，只是在智聯上更新了一下簡歷，就陸陸續續接到很多獵頭的郵件和電話，實在是沒准備好要去面試，就推掉了幾家公司的面試了。正因為筆者也很久沒有面試了，筆者也想去面試學習一下，閑話少說，下面就分享給大家筆者在2018年1月4號上午10點30分的面試經歷：
首先，獵頭或者公司人資會把公司的介紹及崗位要求發到你郵箱（或者QQ、微信），下面這份是獵頭發給我的崗位說明，為了職業道德操守，公司的介紹和面試通知信息我就不貼出來了，我就把崗位要求貼出來：
職位描述：
1、 負責應用伺服器的安裝、配置、優化與維護；
2、 負責應用系統的日誌信息備份、管理、維護與分析；
3、 負責應用系統的日常監測於維護、故障處理、性能分析與優化；
4、 負責應用部署系統、環境配置系統、監控系統的開發、部署、升級與維護，建設高性能的運維平台。
崗位要求:
1、 熟悉linux操作系統的基礎知識，熟練使用Linux常用操作命令；
2、 熟練配置Nginx、HAproxy 等應用相關軟體的部署、配置與優化維護；
3、 熟悉網路基礎知識、熟悉TCP/IP的工作原理，會配交換機或路由器，能熟練的對網路情況進行分析
4、 熟悉shell/perl/python中的一種或多種進行運維程序的開發；
5、 熟悉Nagios,Ganglia等監控軟體
看著上面的要求大家是不是覺得要求也不高啊，你要細看就會發現，這家公司要求的還挺多，不僅要會網路知識（熟悉TCP/IP好像是每家單位的都會寫這樣的要求），還要會開發技能。相信很多做運維的兄弟在網路這一塊是個頭疼的事情，都對交換機和路由器不怎麼會配置和管理。
然後，筆者詳細了解他們公司，了解崗位要求，在突擊復習一下可能會問到的知識點和技術點。到了面試的這天時間，早早的起床，把牙一定要刷干凈，特別是有口臭的兄弟，最好准備點口香糖，到達面試公司前嚼塊口香糖，以免因為口氣的原因熏到面試官，讓你在面試官心裡減分。早點要記得吃，如果你是下午面試的話也要吃午飯，吃早點了精氣神就有了。還要注意，帶上你的簡歷和一支筆，雖然他們那邊也會有你的簡歷，為了以防萬一還是准備好簡歷。
最後，關鍵點來了，就是和面試官溝通了，有筆試的公司會讓你做些面試題，沒有筆試就直接和面試官聊了，下面是我和面試官溝通完之後記住的一些問題，分享給大家看一下，筆者一共記住了7個問題，好像還有兩個問題實在想不起來了，如果大家有更恰當的回答一定要貼出來一起探討和進步：
1、介紹下自己？（幾乎每家公司首先都會讓你做個自我介紹，好像是必修課一樣）
筆者回答：此處省略筆者的自我介紹，筆者建議介紹自己的時間不宜過長，3-4分鍾為宜，說多了面試官會覺得你太啰嗦了。說太少了也不行，那樣會讓人感覺你的經歷太簡單了、太空了。正常情況下，一般你在做自我介紹的同時，面試官這個時候在看你的簡歷，他需要一邊看簡歷、一邊聽你介紹自己，如果你說個幾句話就把自己介紹完了，他肯定還沒緩過神來，對你的映像會減分的。在介紹的同時思維要清晰，邏輯要清楚，最好是根據你簡歷上寫的經歷來介紹，這樣可以把面試官的思路帶到你這里來，讓他思路跟著你走。不要東扯一句，西扯一句。竟量少介紹自己的性格、愛好（最好能不說就不說），你可以簡單羅列干過幾家公司（最多羅列3家公司/也包含目前所在的公司，注意順序不要亂），都在那幾家公司負責什麼工作，都用過什麼技術，在著重介紹一下你目前所在的公司是負責哪些工作的，可以稍微詳細一點介紹，不要讓面試官聽著暈頭轉向的感覺。
2、灰度發布如何實現？
筆者回答：其實對這個問題筆者也答的不好，就不寫出來誤導大家了。大家有好的方法可以共享出來。不過筆事後在知呼上看到了一位網友的建議覺得不錯，大家可以參考看一下 ：https://www.hu.com/question/20584476
3、Mongodb熟悉嗎，一般部署幾台？
筆者回答：部署過，沒有深入研究過，一般mongodb部署主從、或者mongodb分片集群；建議3台或5台伺服器來部署。MongoDB分片的基本思想就是將集合切分成小塊。這些塊分散到若乾片裡面，每個片只負責總數據的一部分。 對於客戶端來說，無需知道數據被拆分了，也無需知道服務端哪個分片對應哪些數據。數據在分片之前需要運行一個路由進程，進程名為mongos。這個路由器知道所有數據的存放位置，知道數據和片的對應關系。對客戶端來說，它僅知道連接了一個普通的mongod，在請求數據的過程中，通過路由器上的數據和片的對應關系，路由到目標數據所在的片上，如果請求有了回應，路由器將其收集起來回送給客戶端。
4、如何發布和回滾，用jenkins又是怎麼實現？
筆者回答：發布：jenkins配置好代碼路徑（SVN或GIT），然後拉代碼，打tag。需要編譯就編譯，編譯之後推送到發布伺服器（jenkins裡面可以調腳本），然後從分發伺服器往下分發到業務伺服器上。
回滾：按照版本號到發布伺服器找到對應的版本推送
5、Tomcat工作模式？
筆者回答：Tomcat是一個JSP/Servlet容器。其作為Servlet容器，有三種工作模式：獨立的Servlet容器、進程內的Servlet容器和進程外的Servlet容器。
進入Tomcat的請求可以根據Tomcat的工作模式分為如下兩類：
Tomcat作為應用程序伺服器：請求來自於前端的web伺服器，這可能是Apache, IIS, Nginx等；
Tomcat作為獨立伺服器：請求來自於web瀏覽器；
6、監控用什麼實現的？
筆者回答：現在公司的業務都跑在阿里雲上，我們首選的監控就是用阿里雲監控，阿里雲監控自帶了ECS、RDS等服務的監控模板，可結合自定義報警規則來觸發監控項。上家公司的業務是託管在IDC，用的是zabbix監控方案，zabbix圖形界面豐富，也自帶很多監控模板，特別是多個分區、多個網卡等自動發現並進行監控做得非常不錯，不過需要在每台客戶機（被監控端）安裝zabbix agent。
7、你是怎麼備份數據的，包括資料庫備份？
筆者回答：在生產環境下，不管是應用數據、還是資料庫數據首先在部署的時候就會有主從架構、或者集群，這本身就是屬於數據的熱備份；其實考慮冷備份，用專門一台伺服器做為備份伺服器，比如可以用rsync+inotify配合計劃任務來實現數據的冷備份，如果是發版的包備份，正常情況下有台發布伺服器，每次發版都會保存好發版的包。
總結
總結一下面試注意幾點事項，可能筆者也說得不太對，為了我們運維工作的兄弟們都能拿到高薪，大家一定要指證出來一起進步、一起探討：
第一，你要對自己的簡歷很熟悉，簡歷上的寫的技能自己一定要能說出個一二，因為面試官的很多問題都會挑你簡歷上寫的問。比如你簡歷上寫了這么一條技能「熟悉mysql資料庫的部署安裝及原理」。你即然寫了這么一條技能，你在怎麼不熟悉你也要了解mysql的原理，能說出個大概意思。萬一面試官問到了你寫的這一條，你都答不上來，那在他心裡你又減分了，基本上這次面試希望不大。
第二，如果面試官問到你不會的問題，你就說這個不太熟悉，沒有具體研究過，千萬別不懂裝懂，還扯一堆沒用的話題來掩飾，這樣只會讓面試官反感你。
第三，准備充分，竟可能多的記住原理性的知識，一般面試問的多的就是原理。很少問具體的配置文件是怎麼配置的。面試前也要了解清楚「職位描述」和「崗位要求」，雖然有時候大多數不會問到崗位要求的問題，但也要了解和熟悉。
第四，面試完後一定要總結，盡量記住面試官問的每一個問題，回去記錄下來，如果問到不會的問題，事後要立馬查網路或者找朋友搞清楚、弄明白，這樣你才能記勞，下次面試說不定又問到同樣的問題。
問完之後，面試官就跟我聊薪資待遇了，問我多少錢能達到自己的要求，我就不便透露了，可以私聊，哈哈，後續筆者會陸陸續續更新以前面試的經歷和問題，有需要的朋友可以轉載或者收藏起來一起討論。
基於大家熱情高昂的氣氛，筆者又花了一個下午的時間回憶並整理在2017年2月24號筆者在東三環邊上（快到東四環了，沒有地鐵過去，到了四惠還要轉公交車）的一家傳媒公司的面試經歷，還好筆者有做筆記的習慣，把之前面試的問題都記錄在案，這一次的面試筆者可是記憶猶新，因為這次這家公司都跟筆者發offer了，實在是真心不想去這家公司就找原因推掉了，大家可別學我這么不靠譜。下面是這家公司中的崗位要求說明：
崗位職責：
1、負責公司產品的版本控制、構建和發布管理；
2、負責公司統一配置庫管理工作，許可權管理與分配准確及時，定期完成配置備份；
3、負責公司內部開發/測試伺服器的運行管理工作；
4、負責Linux操作系統的安裝、配置、監控和維護、問題處理、軟體升級、 數據備份、應急響應、故障排除等、保證線上環境的穩定運行；
5、負責支撐平台24×7穩定運行，並進行前瞻性容量規劃；
6、負責公司機房伺服器日常維護及網路系統安裝、部署、維護工作。
崗位要求：
1、計算機相關專業本科及以上學歷，2年以上運維或配置管理工作經驗；
2、至少熟悉一種監控系統搭建，如Nagios/Zabbix/等；
3、至少熟悉一種集群管理工具，如Ansible/SaltStack等；
4、有使用集成發布工具發布構建經驗優先。比如：bamboo或者Jenkins；
5、熟悉Unix/Linux操作系統，熟悉Weblogic/tomcat等中間件，能夠編寫shell腳本，熟悉軟體開發過程及過程產品，有一定的網路基礎；
6、熟悉rsyslog, flume等日誌收集和處理系統；
7、具有強烈的安全意識及較強的溝通協調和學習能力，良好的團隊合作精神，工作積極主動。
過去之後，前台美眉把我帶到他們公司的地下室，我掃視了一下周圍的環境，貌似旁邊就是機房，因為我聽到伺服器的聲音。等了幾分鍾，面試官下來了，面試官目測比較瘦，看著跟我身材差不多（應該不到120），他說他是負責運維部的，然後開始就叫我先自我介紹，都是一個套路，免不了介紹的，所以兄弟們一定要把自我介紹練好。然後開始問我問題了，跟面試官聊得還行，問我應該有不下10個以上的問題，我記住了下面有10個問題：
1、LVS負載的原理，和Nginx負載有啥區別？
筆者回答：這個問題我覺得面試官司沒問好，正常都會這么問「LVS有哪些負載均衡技術和調度演算法?"。我回答就是按我說的這種問法回答的，反正他也頻繁點頭，當然，筆者回答的可能沒有下面我整理出來的那麼詳細，大概意思我都說明白了。
LVS是Liunx虛擬伺服器的簡稱，利用LVS提供的負載均衡技術和linux操作系統可實現高性能、高可用的伺服器集群，一般LVS都是位於整個集群系統的最前端，由一台或者多台負載調度器（Director Server）組成，分發給應用伺服器（Real Server）。它是工作在4層（也就是TCP/IP中的傳輸層），LVS是基於IP負載均衡技術的IPVS模塊來實現的，IPVS實現負載均衡機制有三種，分別是NAT、TUN和DR，詳述如下：
VS/NAT： 即（Virtual Server via Network Address Translation）
也就是網路地址翻譯技術實現虛擬伺服器，當用戶請求到達調度器時，調度器將請求報文的目標地址（即虛擬IP地址）改寫成選定的Real Server地址，同時報文的目標埠也改成選定的Real Server的相應埠，最後將報文請求發送到選定的Real Server。在伺服器端得到數據後，Real Server返回數據給用戶時，需要再次經過負載調度器將報文的源地址和源埠改成虛擬IP地址和相應埠，然後把數據發送給用戶，完成整個負載調度過程。
可以看出，在NAT方式下，用戶請求和響應報文都必須經過Director Server地址重寫，當用戶請求越來越多時，調度器的處理能力將稱為瓶頸。
VS/TUN ：即（Virtual Server via IP Tunneling）
也就是IP隧道技術實現虛擬伺服器。它的連接調度和管理與VS/NAT方式一樣，只是它的報文轉發方法不同，VS/TUN方式中，調度器採用IP隧道技術將用戶請求轉發到某個Real Server，而這個Real Server將直接響應用戶的請求，不再經過前端調度器，此外，對Real Server的地域位置沒有要求，可以和Director Server位於同一個網段，也可以是獨立的一個網路。因此，在TUN方式中，調度器將只處理用戶的報文請求，集群系統的吞吐量大大提高。
VS/DR： 即（Virtual Server via Direct Routing）
也就是用直接路由技術實現虛擬伺服器。它的連接調度和管理與VS/NAT和VS/TUN中的一樣，但它的報文轉發方法又有不同，VS/DR通過改寫請求報文的MAC地址，將請求發送到Real Server，而Real Server將響應直接返回給客戶，免去了VS/TUN中的IP隧道開銷。這種方式是三種負載調度機制中性能最高最好的，但是必須要求Director Server與Real Server都有一塊網卡連在同一物理網段上。
回答負載調度演算法，IPVS實現在八種負載調度演算法，我們常用的有四種調度演算法（輪叫調度、加權輪叫調度、最少鏈接調度、加權最少鏈接調度）。一般說了這四種就夠了，也不會需要你詳細解釋這四種演算法的。你只要把上面3種負載均衡技術講明白面試官就對這道問題很滿意了。接下來你在簡單說下與nginx的區別：
LVS的優點：
抗負載能力強、工作在第4層僅作分發之用，沒有流量的產生，這個特點也決定了它在負載均衡軟體里的性能最強的；無流量，同時保證了均衡器IO的性能不會受到大流量的影響；
工作穩定，自身有完整的雙機熱備方案，如LVS+Keepalived和LVS+Heartbeat；
應用范圍比較廣，可以對所有應用做負載均衡；
配置性比較低，這是一個缺點也是一個優點，因為沒有可太多配置的東西，所以並不需要太多接觸，大大減少了人為出錯的幾率。
LVS的缺點：
軟體本身不支持正則處理，不能做動靜分離，這就凸顯了Nginx/HAProxy+Keepalived的優勢。
如果網站應用比較龐大，LVS/DR+Keepalived就比較復雜了，特別是後面有Windows Server應用的機器，實施及配置還有維護過程就比較麻煩，相對而言，Nginx/HAProxy+Keepalived就簡單一點
Nginx的優點：
工作在OSI第7層，可以針對http應用做一些分流的策略。比如針對域名、目錄結構。它的正則比HAProxy更為強大和靈活；
Nginx對網路的依賴非常小，理論上能ping通就就能進行負載功能，這個也是它的優勢所在；
Nginx安裝和配置比較簡單，測試起來比較方便；
可以承擔高的負載壓力且穩定，一般能支撐超過幾萬次的並發量；
Nginx可以通過埠檢測到伺服器內部的故障，比如根據伺服器處理網頁返回的狀態碼、超時等等，並且會把返回錯誤的請求重新提交到另一個節點；
Nginx不僅僅是一款優秀的負載均衡器/反向代理軟體，它同時也是功能強大的Web應用伺服器。LNMP現在也是非常流行的web環境，大有和LAMP環境分庭抗禮之勢，Nginx在處理靜態頁面、特別是抗高並發方面相對apache有優勢；
Nginx現在作為Web反向加速緩存越來越成熟了，速度比傳統的Squid伺服器更快，有需求的朋友可以考慮用其作為反向代理加速器；
Nginx的缺點：
Nginx不支持url來檢測。
Nginx僅能支持http和Email，這個它的弱勢。
Nginx的Session的保持，Cookie的引導能力相對欠缺。
2、redis集群的原理，redis分片是怎麼實現的，你們公司redis用在了哪些環境？
筆者回答：reids集群原理：
其實它的原理不是三兩句話能說明白的，redis 3.0版本之前是不支持集群的，官方推薦最大的節點數量為1000，至少需要3(Master)+3(Slave)才能建立集群，是無中心的分布式存儲架構，可以在多個節點之間進行數據共享，解決了Redis高可用、可擴展等問題。集群可以將數據自動切分(split)到多個節點，當集群中的某一個節點故障時，redis還可以繼續處理客戶端的請求。
redis分片：
分片(partitioning)就是將你的數據拆分到多個 Redis 實例的過程，這樣每個實例將只包含所有鍵的子集。當數據量大的時候,把數據分散存入多個資料庫中,減少單節點的連接壓力,實現海量數據存儲。分片部署方式一般分為以下三種：
（1）在客戶端做分片；這種方式在客戶端確定要連接的redis實例，然後直接訪問相應的redis實例；
（2）在代理中做分片；這種方式中，客戶端並不直接訪問redis實例，它也不知道自己要訪問的具體是哪個redis實例，而是由代理轉發請求和結果；其工作過程為：客戶端先將請求發送給代理，代理通過分片演算法確定要訪問的是哪個redis實例，然後將請求發送給相應的redis實例，redis實例將結果返回給代理，代理最後將結果返回給客戶端。
（3）在redis伺服器端做分片；這種方式被稱為「查詢路由」，在這種方式中客戶端隨機選擇一個redis實例發送請求，如果所請求的內容不再當前redis實例中它會負責將請求轉交給正確的redis實例，也有的實現中，redis實例不會轉發請求，而是將正確redis的信息發給客戶端，由客戶端再去向正確的redis實例發送請求。
redis用在了哪些環境：
java、php環境用到了redis，主要緩存有登錄用戶信息數據、設備詳情數據、會員簽到數據等
3、你會怎麼統計當前訪問的IP，並排序？
筆者回答：統計用戶的訪問IP，用awk結合uniq、sort過濾access.log日誌就能統計並排序好。一般這么回答就夠了，當然你還可以說出其它方式來統計，這都是你的加分項。
4、你會使用哪些虛擬化技術？
筆者回答：vmware vsphere及kvm，我用得比較多的是vmware vsphere虛擬化，幾本上生產環境都用的vmware vsphere，kvm我是用在測試環境中使用。vmware 是屬於原生架構虛擬化技術，也就是可直接在硬體上運行。kvm屬於寄居架構的虛擬化技術，它是依託在系統之上運行。vmware vcenter
管理上比較方便，圖形管理界面功能很強大，穩定性強，一般比較適合企業使用。KVM管理界面稍差點，需要管理人員花費點時間學習它的維護管理技術。
5、假如有人反應，調取後端介面時特別慢，你會如何排查？
筆者回答：其實這種問題都沒有具體答案，只是看你回答的內容與面試官契合度有多高，能不能說到他想要的點上，主要是看你排查問題的思路。我是這么說的：問清楚反應的人哪個服務應用或者頁面調取哪個介面慢，叫他把頁面或相關的URL發給你，首先，最直觀的分析就是用瀏覽器按F12，看下是哪一塊的內容過慢（DNS解析、網路載入、大圖片、還是某個文件內容等），如果有，就對症下葯去解決（圖片慢就優化圖片、網路慢就查看內網情況等）。其次，看後端服務的日誌，其實大多數的問題看相關日誌是最有效分析，最好用tail -f 跟蹤一下日誌，當然你也要點擊測試來訪問介面日誌才會打出來。最後，排除sql，，找到sql去mysql執行一下，看看時間是否很久，如果很久，就要優化SQL問題了，expain一下SQL看看索引情況啥的，針對性優化。數據量太大的能分表就分表，能分庫就分庫。如果SQL沒啥問題，那可能就是寫的邏輯代碼的問題了，一行行審代碼，找到耗時的地方改造，優化邏輯。
6、mysql資料庫用的是主從讀寫分離，主庫寫，從庫讀，假如從庫無法讀取了、或者從庫讀取特別慢，你會如何解決？
筆者回答：這個問題筆者覺得回答的不太好，對mysql比較在行的朋友希望能給點建議。以解決問題為前提條件，先添加從庫數量，臨時把問題給解決，然後抓取slow log ，分析sql語句，該優化就優化處理。慢要不就是硬體跟不上，需要升級；要不就是軟體需要調試優化，等問題解決在細化。
7、cpu單核和多核有啥區別？
筆者回答：很少有面試官會問這樣的問題，即然問到了，也要老實回答。還好筆者之前了解過CPU，我是這么說的：雙核CPU就是能處理多份任務，順序排成隊列來處理。單核CPU一次處理一份任務，輪流處理每個程序任務。雙核的優勢不是頻率，而是對付同時處理多件事情。單核同時只能幹一件事，比如你同時在後台BT下載，前台一邊看電影一邊拷貝文件一邊QQ。
8、機械磁碟和固態硬碟有啥區別？
筆者回答：我擦，啥年代了，還問磁碟的問題，這面試官有點逗啊。那也要回答啊：
HDD代表機械硬碟，SSD代表固態硬碟。首先，從性能方面來說，固態硬碟幾乎完勝機械硬碟，固態硬碟的讀寫速度肯定要快機械硬碟，因為固態硬碟和機械硬碟的構造是完全不同的（具體的構造就沒必要解釋了）。其次，固態盤幾乎沒有噪音、而機械盤噪音比較大。還有就是，以目前的市場情況來看，一般機械盤容量大，價格低；固態盤容量小，價格偏高。但是企業還是首選固態盤。
9、說一下用過哪些監控系統？
筆者回答：這個監控的問題又問到了，筆者在2018年1月4號也被問到類似這樣的問題，筆者曾經用過zabbix、nagios、 cacit等。但是在這次面試中只說用過zabbix和nagios。說完了之後，面試官就讓我說一下這兩個監控有啥區別：
從web功能及畫圖來講：
Nagios簡單直觀，報警與數據都在同一頁面， 紅色即為問題項。Nagios web端不要做任何配置。 Nagios需要額外安裝插件，且插件畫圖不夠美觀。
Zabbix監控數據與報警是分開的，查看問題項需要看觸發器，查看數據在最新數據查看。而且zabbix有很多其它配置項， zabbix攜帶畫圖功能，且能手動把多個監控項集在一個圖中展示。
從監控服務來講：
Nagios自帶的監控項很少。對一些變動的如多個分區、多個網卡進行監控時需要手動配置。
Zabbix自帶了很多監控內容，感覺zabbix一開始就為你做了很多事，特別是對多個分區、多個網卡等自動發現並進行監控時，那一瞬間很驚喜，很省心的感覺。
從批量配置和報警來講：
Nagios對於批量監控主機，需要用腳本在server端新增host，並拷貝service文件。 Nagios用腳本來修改所有主機的services文件，加入新增服務。
Zabbix在server端配置自動注冊規則，配置好規則後，後續新增client端不需要對server端進行操作。 Zabbix只需手動在模板中新增一監控項即可。
總體來講：
Nagios要花很多時間寫插件，Zabbix要花很多時間探索功能。
Nagios更易上手，Nagios兩天弄會，Zabbix兩周弄會。
Zabbix畫圖功能比Nagios更強大
Zabbix對於批量監控與服務更改，操作更簡潔；Nagios如果寫好自動化腳本後，也很簡單，問題在於寫自動化腳本很費神。
10、給你一套環境，你會如何設計高可用、高並發的架構？
筆者回答：如果這套環境是部署在雲端(比如阿里雲)，你就不用去考慮硬體設計的問題。可直接上阿里雲的SLB+ECS+RDS這套標準的高可用、高並發的架構。對外服務直接上SLB負載均衡技術，由阿里的SLB分發到後端的ECS主機；ECS主機部署多台，應用拆分在不同的ECS主機上，盡量細分服務。資料庫用RDS高可用版本（一主一備的經典高可用架構）、或者用RDS金融版（一主兩備的三節點架構）。在結合阿里其它的服務就完全OK，業務量上來了，主機不夠用了，直橫向擴容ECS主機搞定。
如果這套環境託管在IDC，那麼你就要從硬體、軟體（應用服務）雙面去考慮了。硬體要達到高可用、高並發公司必須買多套網路硬體設備（比如負載設備F5、防火牆、核心層交換、接入層交換）都必須要冗餘，由其是在網路設計上，設備之間都必須有雙線連接。設備如果都是跑的單機，其中一個設備掛了，你整個網路都癱瘓了，就談不上高可用、高並發了。其次在是考慮應用服務了，對外服務我會採用成熟的開源方案LVS+Keepalived或者Nginx+Keepalived，緩存層可以考慮redis集群及Mongodb集群，中間件等其它服務可以用kafka、zookeeper，圖片存儲可以用fastDFS或MFS，如果數據量大、又非常多，那麼可採用hadoop這一套方案。後端資料庫可採用 「主從+MHA」。這樣一套環境下來是絕對滿足高可用、高並發的架構
『肆』 怎樣去學java
想要學好Java，需要有正確的學習路線，有堅持不懈的學習毅力，也需要有專業老師的指導，這樣才能學得更好。那麼，學習Java需要掌握哪些知識和技能呢？這里簡單列舉一些。
Java學習需要掌握的知識與技能：
1、Java SE部分初級語法，面向對象，異常，IO流，多線程，Java Swing，JDBC，泛型，註解，反射等。
2、資料庫部分，基礎的sql語句，sql語句調優，索引，資料庫引擎，存儲過程，觸發器，事務等。
3、前端部分， HTML5 CSS3 JS， HTML DOM Jquery BootStrap等。
4、Java EE部分，Tomcat和Nginx伺服器搭建，配置文件，Servlet，JSP，Filter，Listener，http協議，MVC等。
5、框架部分，每個框架都可以分開學，在去學如何使用SSM 或者SSH框架，如何搭建，如何整合。開發中為什麼會用框架，Rest是啥？Spring為啥經久不衰，底層如何實現等。
6、23種設計模式，掌握常用的，比如單例模式的多種實現，責任鏈模式，工廠模式，裝飾器模式等，了解常用場景。
7、基礎演算法和數據結構，八大排序演算法，查找演算法。
8、熟練使用maven等構建工具，git等版本控制工具，熟悉常用linux命令，log4j，bug，junit單元測試，日誌列印工具，Redis等NoSql。
互聯網行業目前還是最熱門的行業之一，學習IT技能之後足夠優秀是有機會進入騰訊、阿里、網易等互聯網大廠高薪就業的，發展前景非常好，普通人也可以學習。
想要系統學習，你可以考察對比一下開設有大數據及雲計算專業的熱門學校，好的學校擁有根據當下企業需求自主研發課程的能力，建議實地考察對比一下。
祝你學有所成，望採納。
『伍』 如何選擇阿里雲雲伺服器ECS操作系統
方法/步驟
首先，我們要清楚的便是每個系統之間的差別，以及在阿里雲上的差別：
1. Windows
1.1) 系統內含正版激活。
1.2) 適合於運行Windows下開發的程序，如.net等。
1.3) 支持SQL Server等資料庫(需自行安裝)。
1.4) 可以使用遠程桌面方式登錄進行管理。
註：512內存不支持選擇Windows系統，1G以上內存才能很好支持該系統。
2. Linux
2.1.1) 最流行的伺服器端操作系統，強大的安全性和穩定性。
2.1.2) 免費且開源，輕松建立和編譯源代碼。
2.1.3) 通過SSH方式遠程訪問您的雲伺服器。
2.1.4) 一般用於高性能web等伺服器應用，支持常見的PHP/Python等編程語言，支持MySQL等資料庫(需自行安裝)。
2.2 CentOS (推薦)請使用yum方式在線安裝軟體。
2.3 Ubuntu請使用aptitude方式在線安裝軟體。
2.4 Debian請使用apt-get方式在線安裝軟體。
2.5 Aliyun Linux(兼容 Red Hat)請使用yum方式在線安裝軟體，yum源需要自行購買redhat的商業支持。
操作系統更換規則：
1.更換操作系統
更換系統之前請先停止雲伺服器，雲伺服器更換操作系統會直接重置系統盤【IP不變】，系統盤數據將會丟失!
請您注意：
1.1. 更換操作系統會使雲伺服器的系統盤更換為新的鏡像，原有系統盤的數據都會丟失。
1.2. 雲伺服器數據盤的數據不會受到影響。
1.3. 建議您將系統盤的個人數據備份到數據盤中，或採用其他方式進行備份。
1.4. 因您沒有備份系統盤相關個人數據而造成的數據丟失，阿里雲不承擔責任。
1.5. 內存為512M雲伺服器不支持更換Windows操作系統。
2. CPU/內存與操作系統的選擇
2.1)如需選擇/變更4G以上內存請您選擇64位操作系統(32位操作系統存在定址限制)。
2.2) 如您選擇32位操作系統，4G以上內存頁面暫不展示，只有雲伺服器更換為64位操作系統才可展示。
2.3)Windows 32位操作系統支持最高CPU為4核。
2.4)配置：[CPU：1核;內存：512M] 的雲伺服器不支持選擇/更換Windows操作系統。
Windows篇
阿里雲提供了6種window系統，涵蓋了Server 2003 sp2以及Server 2008 R2這兩大類操作系統。
其中又分為了32位和64位
(1)如何選擇32位還是64位
32位系統相比64位系統，最主要的限制體現在內存的大小上。因為32位本身的限制，其最大隻可支持到4GB內存，如果您的網站要使用高於4GB的內存或者以後有擴充內存尋到4GB以上的打算，請使用64位操作系統。
(2)選擇2003還是選擇2008
對於windows來說，我個人建議是選擇版本越高的越好。相對來說新版本漏洞相對來說更少，而且IIS 7.5相對於IIS6提供了更多的功能以及更方便的控制台。但是考慮到大家的機器配置不同，在此給出一下幾種選擇：
A：配置低於雙核 2GB內存：選擇server2003 不裝資料庫配置雙核4GB： server 2003 mssql 或者 server 2008 R2 不帶資料庫
B：配置高於雙核 8GB：serever 2008 R2 mssql 建議如果大家要在雲伺服器上跑資料庫，盡量選擇大內存配置，或者降低配置去選用RDS
(3)中英文、安全加固版如何選擇
這個就依據大家各自的喜好來了，在此不多說了至於Windows伺服器配置教程，因為網上教程很多而且相對於Linux來說Windows配置難度更低，所以Windows的配置教程會比較晚的放出。
Linux篇
(1)這些linux大類有什麼區別
Debian：用的deb包，使用APT包管理系統。
同時Debian提供了大多數軟體比較新的版本，並且提供了更多的軟體包(相對於原版Red Hat)。Debian的優點在於更新迅速，軟體包完善(Ubuntu尤其)，操作便利。缺點是部分時候穩定性欠佳，跟進最新軟體有可能存在Bug。
Centos：用rpm包，使用yum包管理系統。
相對於Debian來說，Centost的一大特點就是慢。大部分軟體停留在穩定版本，而且相距最新版版本也差較多。而且某些新版軟體的一些新特性支持也比較慢，比如php-fpm。
因為Centos是面向企業用戶提供的操作系統，所以在穩定性上十分突出，一般在新功能或穩定性的選擇上更傾向於後者。只有當某個功能完全確定穩定了，才會加入到系統里。優點是系統穩定，技術文檔完善，如果付費的話能得到企業級別的技術支持。缺點是軟體包比較老舊，而且一些較新功能會欠缺。
總結一下：如果你喜歡嘗鮮，喜歡用最新的功能或喜歡折騰系統，那麼Debian是個更好的選擇。
上手難度 Ubunt<Debian<Redhat=Centos
(2)Debian與Ubuntu的選擇
Ubuntu是基於Debian所開發，可以簡單地認為Ubuntu是Debian的功能加強版。
與Debian相比，Ubuntu提供了更人性化系統配置，更強大的系統操作以及比Debian更激進的軟體更新。
Ubuntu與Debian比較，可以認為Debian更趨向於保守一些，Ubuntu對新手友好度更高，上手更容易。
用過Ubuntu的都會體會到它的易用，反之如果用過Ubuntu再換到別的系統，都會覺得不適應，Ubuntu真的很方便。
個人建議，如果你打算選擇Debian類的，建議選擇Ubuntu。
Ubuntu提供了更好的操作，更激進的軟體更新，更方便管理軟體以及相差無幾的穩定性。
如果你不想放棄穩定，那麼請選擇Debian。
關於Ubuntu版本選擇：
在此解釋下Ubuntu的版本支持時間。Ubuntu普通版本只提供18個月的技術支持，過期則不管。
伺服器版本提供長達五年的技術支持。所以建議大家選擇12.04 版，提供長達5年的技術支持，可以確保在靜候相當長的一段時間內你的伺服器可以繼續收到系統升級補丁以及可用的軟體源。
(3) Centos 的選擇
對於阿里雲Centos的選擇，建議選擇Centos 6.5版本，帶來了更多的新特性以及更多的新功能。
除非你的軟體需要php 5.1的環境，那麼就選擇Centos6.5。如果網站需要支持php5.1，只能選用Centos 5.8。
至於具體版本選擇，建議php 5.1用戶選擇Centos 5.8，其他的用戶則為Centos 6.5。
『陸』 我想學軟體開發專業0基礎可以學習嗎
可以的 0基礎是可以學習的，任何事情都是從不會到到會的，態度端正，有條件的可以報個培訓機構，自學可以在網上找找視頻多向有經驗的人學習學習，功夫不負有心人，會達到你想要的結果的。
軟體開發需要學習的課程
1.數據結構與演算法，只要你做開發，這一點就必須好好的學習，把它學透了，對編程的優化幫助很大。
2.計算機組成原理，一門特別難學的課程，學透了，是大牛級別的。
3. 資料庫，作為一名軟體開發人員，資料庫肯定是要會的，必備的知識，目前來說，MySQL 資料庫用的比較多，可以多研究研究。
4.網路編程，軟體終歸都是通過網路來交互的，所以網路編程同樣蠻重要的，TCP，UDP協議等。
互聯網行業目前還是最熱門的行業之一，學習IT技能之後足夠優秀是有機會進入騰訊、阿里、網易等互聯網大廠高薪就業的，發展前景非常好，普通人也可以學習。
想要系統學習，你可以考察對比一下開設有相關專業的熱門學校，好的學校擁有根據當下企業需求自主研發課程的能力，建議實地考察對比一下。
祝你學有所成，望採納
北大青鳥學生課堂實錄
『柒』 大數據需要學編程嗎
導讀：
第一章：初識Hadoop
第二章：更高效的WordCount
第三章：把別處的數據搞到Hadoop上
第四章：把Hadoop上的數據搞到別處去
第五章：快一點吧，我的SQL
第六章：一夫多妻制
第七章：越來越多的分析任務
第八章：我的數據要實時
第九章：我的數據要對外
第十章：牛逼高大上的機器學習
數據量大，TB->PB
數據類型繁多，結構化、非結構化文本、日誌、視頻、圖片、地理位置等；
商業價值高，但是這種價值需要在海量數據之上，通過數據分析與機器學習更快速的挖掘出來；
處理時效性高，海量數據的處理需求不再局限在離線計算當中。
Hadoop 1.0、Hadoop 2.0
MapRece、HDFS
NameNode、DataNode
JobTracker、TaskTracker
Yarn、ResourceManager、NodeManager
0和Hadoop2.0的區別；
MapRece的原理（還是那個經典的題目，一個10G大小的文件，給定1G大小的內存，如何使用Java程序統計出現次數最多的10個單詞及次數）；
HDFS讀寫數據的流程；向HDFS中PUT數據；從HDFS中下載數據；
自己會寫簡單的MapRece程序，運行出現問題，知道在哪裡查看日誌；
會寫簡單的SELECT、WHERE、GROUP BY等SQL語句；
Hive SQL轉換成MapRece的大致流程；
Hive中常見的語句：創建表、刪除表、往表中載入數據、分區、將表中數據下載到本地；
為什麼Spark比MapRece快。
使用SparkSQL代替Hive，更快的運行SQL。
使用Kafka完成數據的一次收集，多次消費架構。
自己可以寫程序完成Kafka的生產者和消費者。
經常有初學者在博客和QQ問我，自己想往大數據方向發展，該學哪些技術，學習路線是什麼樣的，覺得大數據很火，就業很好，薪資很高。如果自己很迷茫，為了這些原因想往大數據方向發展，也可以，那麼我就想問一下，你的專業是什麼，對於計算機/軟體，你的興趣是什麼？是計算機專業，對操作系統、硬體、網路、伺服器感興趣？是軟體專業，對軟體開發、編程、寫代碼感興趣？還是數學、統計學專業，對數據和數字特別感興趣。。
其實這就是想告訴你的大數據的三個發展方向，平台搭建/優化/運維/監控、大數據開發/設計/架構、數據分析/挖掘。請不要問我哪個容易，哪個前景好，哪個錢多。
先扯一下大數據的4V特徵：
現如今，正式為了應對大數據的這幾個特點，開源的大數據框架越來越多，越來越強，先列舉一些常見的：
文件存儲：Hadoop HDFS、Tachyon、KFS
離線計算：Hadoop MapRece、Spark
流式、實時計算：Storm、Spark Streaming、S4、Heron
K-V、NOSQL資料庫：HBase、Redis、MongoDB
資源管理：YARN、Mesos
日誌收集：Flume、Scribe、Logstash、Kibana
消息系統：Kafka、StormMQ、ZeroMQ、RabbitMQ
查詢分析：Hive、Impala、Pig、Presto、Phoenix、SparkSQL、Drill、Flink、Kylin、Druid
分布式協調服務：Zookeeper
集群管理與監控：Ambari、Ganglia、Nagios、Cloudera Manager
數據挖掘、機器學習：Mahout、Spark MLLib
數據同步：Sqoop
任務調度：Oozie
……
眼花了吧，上面的有30多種吧，別說精通了，全部都會使用的，估計也沒幾個。
就我個人而言，主要經驗是在第二個方向（開發/設計/架構），且聽聽我的建議吧。
第一章：初識Hadoop
1.1 學會網路與Google
不論遇到什麼問題，先試試搜索並自己解決。
Google首選，翻不過去的，就用網路吧。
1.2 參考資料首選官方文檔
特別是對於入門來說，官方文檔永遠是首選文檔。
相信搞這塊的大多是文化人，英文湊合就行，實在看不下去的，請參考第一步。
1.3 先讓Hadoop跑起來
Hadoop可以算是大數據存儲和計算的開山鼻祖，現在大多開源的大數據框架都依賴Hadoop或者與它能很好的兼容。
關於Hadoop,你至少需要搞清楚以下是什麼：
自己搭建Hadoop，請使用第一步和第二步，能讓它跑起來就行。
建議先使用安裝包命令行安裝，不要使用管理工具安裝。
另外：Hadoop1.0知道它就行了，現在都用Hadoop 2.0.
1.4 試試使用Hadoop
HDFS目錄操作命令；
上傳、下載文件命令；
提交運行MapRece示常式序；
打開Hadoop WEB界面，查看Job運行狀態，查看Job運行日誌。
知道Hadoop的系統日誌在哪裡。
1.5 你該了解它們的原理了
MapRece：如何分而治之；
HDFS：數據到底在哪裡，什麼是副本；
Yarn到底是什麼，它能幹什麼；
NameNode到底在幹些什麼；
ResourceManager到底在幹些什麼；
1.6 自己寫一個MapRece程序
請仿照WordCount例子，自己寫一個（照抄也行）WordCount程序，
打包並提交到Hadoop運行。
你不會Java？Shell、Python都可以，有個東西叫Hadoop Streaming。
如果你認真完成了以上幾步，恭喜你，你的一隻腳已經進來了。
第二章：更高效的WordCount
2.1 學點SQL吧
你知道資料庫嗎？你會寫SQL嗎？
如果不會，請學點SQL吧。
2.2 SQL版WordCount
在1.6中，你寫（或者抄）的WordCount一共有幾行代碼？
給你看看我的:
SELECT word,COUNT(1) FROM wordcount GROUP BY word;
這便是SQL的魅力，編程需要幾十行，甚至上百行代碼，我這一句就搞定；使用SQL處理分析Hadoop上的數據，方便、高效、易上手、更是趨勢。不論是離線計算還是實時計算，越來越多的大數據處理框架都在積極提供SQL介面。
2.3 SQL On Hadoop之Hive
什麼是Hive？官方給的解釋是：
The Apache Hive data warehouse software facilitates reading, writing, and managing large datasets residing in distributed storage and queried using SQL syntax.
為什麼說Hive是數據倉庫工具，而不是資料庫工具呢？有的朋友可能不知道數據倉庫，數據倉庫是邏輯上的概念，底層使用的是資料庫，數據倉庫中的數據有這兩個特點：最全的歷史數據（海量）、相對穩定的；所謂相對穩定，指的是數據倉庫不同於業務系統資料庫，數據經常會被更新，數據一旦進入數據倉庫，很少會被更新和刪除，只會被大量查詢。而Hive，也是具備這兩個特點，因此，Hive適合做海量數據的數據倉庫工具，而不是資料庫工具。
2.4 安裝配置Hive
請參考1.1 和 1.2 完成Hive的安裝配置。可以正常進入Hive命令行。
2.5 試試使用Hive
請參考1.1 和 1.2 ，在Hive中創建wordcount表，並運行2.2中的SQL語句。
在Hadoop WEB界面中找到剛才運行的SQL任務。
看SQL查詢結果是否和1.4中MapRece中的結果一致。
2.6 Hive是怎麼工作的
明明寫的是SQL，為什麼Hadoop WEB界面中看到的是MapRece任務？
2.7 學會Hive的基本命令
創建、刪除表；
載入數據到表；
下載Hive表的數據；
請參考1.2，學習更多關於Hive的語法和命令。
如果你已經按照《寫給大數據開發初學者的話》中第一章和第二章的流程認真完整的走了一遍，那麼你應該已經具備以下技能和知識點：
從上面的學習，你已經了解到，HDFS是Hadoop提供的分布式存儲框架，它可以用來存儲海量數據，MapRece是Hadoop提供的分布式計算框架，它可以用來統計和分析HDFS上的海量數據，而Hive則是SQL On Hadoop，Hive提供了SQL介面，開發人員只需要編寫簡單易上手的SQL語句，Hive負責把SQL翻譯成MapRece，提交運行。
此時，你的」大數據平台」是這樣的：
那麼問題來了，海量數據如何到HDFS上呢？
第三章：把別處的數據搞到Hadoop上
此處也可以叫做數據採集，把各個數據源的數據採集到Hadoop上。
3.1 HDFS PUT命令
這個在前面你應該已經使用過了。
put命令在實際環境中也比較常用，通常配合shell、python等腳本語言來使用。
建議熟練掌握。
3.2 HDFS API
HDFS提供了寫數據的API，自己用編程語言將數據寫入HDFS，put命令本身也是使用API。
實際環境中一般自己較少編寫程序使用API來寫數據到HDFS，通常都是使用其他框架封裝好的方法。比如：Hive中的INSERT語句，Spark中的saveAsTextfile等。
建議了解原理，會寫Demo。
3.3 Sqoop
Sqoop是一個主要用於Hadoop/Hive與傳統關系型資料庫Oracle/MySQL/SQLServer等之間進行數據交換的開源框架。
就像Hive把SQL翻譯成MapRece一樣，Sqoop把你指定的參數翻譯成MapRece，提交到Hadoop運行，完成Hadoop與其他資料庫之間的數據交換。
自己下載和配置Sqoop（建議先使用Sqoop1，Sqoop2比較復雜）。
了解Sqoop常用的配置參數和方法。
使用Sqoop完成從MySQL同步數據到HDFS；
使用Sqoop完成從MySQL同步數據到Hive表；
PS：如果後續選型確定使用Sqoop作為數據交換工具，那麼建議熟練掌握，否則，了解和會用Demo即可。
3.4 Flume
Flume是一個分布式的海量日誌採集和傳輸框架，因為「採集和傳輸框架」，所以它並不適合關系型資料庫的數據採集和傳輸。
Flume可以實時的從網路協議、消息系統、文件系統採集日誌，並傳輸到HDFS上。
因此，如果你的業務有這些數據源的數據，並且需要實時的採集，那麼就應該考慮使用Flume。
下載和配置Flume。
使用Flume監控一個不斷追加數據的文件，並將數據傳輸到HDFS；
PS：Flume的配置和使用較為復雜，如果你沒有足夠的興趣和耐心，可以先跳過Flume。
3.5 阿里開源的DataX
之所以介紹這個，是因為我們公司目前使用的Hadoop與關系型資料庫數據交換的工具，就是之前基於DataX開發的，非常好用。
可以參考我的博文《異構數據源海量數據交換工具-Taobao DataX 下載和使用》。
現在DataX已經是3.0版本，支持很多數據源。
你也可以在其之上做二次開發。
PS：有興趣的可以研究和使用一下，對比一下它與Sqoop。
如果你認真完成了上面的學習和實踐，此時，你的」大數據平台」應該是這樣的：
第四章：把Hadoop上的數據搞到別處去
前面介紹了如何把數據源的數據採集到Hadoop上，數據到Hadoop上之後，便可以使用Hive和MapRece進行分析了。那麼接下來的問題是，分析完的結果如何從Hadoop上同步到其他系統和應用中去呢？
其實，此處的方法和第三章基本一致的。
4.1 HDFS GET命令
把HDFS上的文件GET到本地。需要熟練掌握。
4.2 HDFS API
同3.2.
4.3 Sqoop
同3.3.
使用Sqoop完成將HDFS上的文件同步到MySQL；
使用Sqoop完成將Hive表中的數據同步到MySQL；
4.4 DataX
同3.5.
如果你認真完成了上面的學習和實踐，此時，你的」大數據平台」應該是這樣的：
如果你已經按照《寫給大數據開發初學者的話2》中第三章和第四章的流程認真完整的走了一遍，那麼你應該已經具備以下技能和知識點：
知道如何把已有的數據採集到HDFS上，包括離線採集和實時採集；
你已經知道sqoop（或者還有DataX）是HDFS和其他數據源之間的數據交換工具；
你已經知道flume可以用作實時的日誌採集。
從前面的學習，對於大數據平台，你已經掌握的不少的知識和技能，搭建Hadoop集群，把數據採集到Hadoop上，使用Hive和MapRece來分析數據，把分析結果同步到其他數據源。
接下來的問題來了，Hive使用的越來越多，你會發現很多不爽的地方，特別是速度慢，大多情況下，明明我的數據量很小，它都要申請資源，啟動MapRece來執行。
第五章：快一點吧，我的SQL
其實大家都已經發現Hive後台使用MapRece作為執行引擎，實在是有點慢。
因此SQL On Hadoop的框架越來越多，按我的了解，最常用的按照流行度依次為SparkSQL、Impala和Presto.
這三種框架基於半內存或者全內存，提供了SQL介面來快速查詢分析Hadoop上的數據。關於三者的比較，請參考1.1.
我們目前使用的是SparkSQL，至於為什麼用SparkSQL，原因大概有以下吧：
使用Spark還做了其他事情，不想引入過多的框架；
Impala對內存的需求太大，沒有過多資源部署；
5.1 關於Spark和SparkSQL
什麼是Spark，什麼是SparkSQL。
Spark有的核心概念及名詞解釋。
SparkSQL和Spark是什麼關系，SparkSQL和Hive是什麼關系。
SparkSQL為什麼比Hive跑的快。
5.2 如何部署和運行SparkSQL
Spark有哪些部署模式？
如何在Yarn上運行SparkSQL？
使用SparkSQL查詢Hive中的表。
PS: Spark不是一門短時間內就能掌握的技術，因此建議在了解了Spark之後，可以先從SparkSQL入手，循序漸進。
關於Spark和SparkSQL，可參考http://lxw1234.com/archives/category/spark
如果你認真完成了上面的學習和實踐，此時，你的」大數據平台」應該是這樣的：
第六章：一夫多妻制
請不要被這個名字所誘惑。其實我想說的是數據的一次採集、多次消費。
在實際業務場景下，特別是對於一些監控日誌，想即時的從日誌中了解一些指標（關於實時計算，後面章節會有介紹），這時候，從HDFS上分析就太慢了，盡管是通過Flume採集的，但Flume也不能間隔很短就往HDFS上滾動文件，這樣會導致小文件特別多。
為了滿足數據的一次採集、多次消費的需求，這里要說的便是Kafka。
6.1 關於Kafka
什麼是Kafka？
Kafka的核心概念及名詞解釋。
6.2 如何部署和使用Kafka
使用單機部署Kafka，並成功運行自帶的生產者和消費者例子。
使用Java程序自己編寫並運行生產者和消費者程序。
Flume和Kafka的集成，使用Flume監控日誌，並將日誌數據實時發送至Kafka。
如果你認真完成了上面的學習和實踐，此時，你的」大數據平台」應該是這樣的：
這時，使用Flume採集的數據，不是直接到HDFS上，而是先到Kafka，Kafka中的數據可以由多個消費者同時消費，其中一個消費者，就是將數據同步到HDFS。
如果你已經按照《寫給大數據開發初學者的話3》中第五章和第六章的流程認真完整的走了一遍，那麼你應該已經具備以下技能和知識點：
從前面的學習，你已經掌握了大數據平台中的數據採集、數據存儲和計算、數據交換等大部分技能，而這其中的每一步，都需要一個任務（程序）來完成，各個任務之間又存在一定的依賴性，比如，必須等數據採集任務成功完成後，數據計算任務才能開始運行。如果一個任務執行失敗，需要給開發運維人員發送告警，同時需要提供完整的日誌來方便查錯。
第七章：越來越多的分析任務
不僅僅是分析任務，數據採集、數據交換同樣是一個個的任務。這些任務中，有的是定時觸發，有點則需要依賴其他任務來觸發。當平台中有幾百上千個任務需要維護和運行時候，僅僅靠crontab遠遠不夠了，這時便需要一個調度監控系統來完成這件事。調度監控系統是整個數據平台的中樞系統，類似於AppMaster，負責分配和監控任務。
7.1 Apache Oozie
1. Oozie是什麼？有哪些功能？
2. Oozie可以調度哪些類型的任務（程序）？
3. Oozie可以支持哪些任務觸發方式？
4. 安裝配置Oozie。
第八章：我的數據要實時
在第六章介紹Kafka的時候提到了一些需要實時指標的業務場景，實時基本可以分為絕對實時和准實時，絕對實時的延遲要求一般在毫秒級，准實時的延遲要求一般在秒、分鍾級。對於需要絕對實時的業務場景，用的比較多的是Storm，對於其他准實時的業務場景，可以是Storm，也可以是Spark Streaming。當然，如果可以的話，也可以自己寫程序來做。
8.1 Storm
1. 什麼是Storm？有哪些可能的應用場景？
2. Storm由哪些核心組件構成，各自擔任什麼角色？
3. Storm的簡單安裝和部署。
4. 自己編寫Demo程序，使用Storm完成實時數據流計算。
8.2 Spark Streaming
1. 什麼是Spark Streaming，它和Spark是什麼關系？
2. Spark Streaming和Storm比較，各有什麼優缺點？
3. 使用Kafka + Spark Streaming，完成實時計算的Demo程序。
如果你認真完成了上面的學習和實踐，此時，你的」大數據平台」應該是這樣的：
至此，你的大數據平台底層架構已經成型了，其中包括了數據採集、數據存儲與計算（離線和實時）、數據同步、任務調度與監控這幾大模塊。接下來是時候考慮如何更好的對外提供數據了。
第九章：我的數據要對外
通常對外（業務）提供數據訪問，大體上包含以下方面：
離線：比如，每天將前一天的數據提供到指定的數據源（DB、FILE、FTP）等；離線數據的提供可以採用Sqoop、DataX等離線數據交換工具。
實時：比如，在線網站的推薦系統，需要實時從數據平台中獲取給用戶的推薦數據，這種要求延時非常低（50毫秒以內）。
根據延時要求和實時數據的查詢需要，可能的方案有：HBase、Redis、MongoDB、ElasticSearch等。
OLAP分析：OLAP除了要求底層的數據模型比較規范，另外，對查詢的響應速度要求也越來越高，可能的方案有：Impala、Presto、SparkSQL、Kylin。如果你的數據模型比較規模，那麼Kylin是最好的選擇。
即席查詢：即席查詢的數據比較隨意，一般很難建立通用的數據模型，因此可能的方案有：Impala、Presto、SparkSQL。
這么多比較成熟的框架和方案，需要結合自己的業務需求及數據平台技術架構，選擇合適的。原則只有一個：越簡單越穩定的，就是最好的。
如果你已經掌握了如何很好的對外（業務）提供數據，那麼你的「大數據平台」應該是這樣的：
第十章：牛逼高大上的機器學習
關於這塊，我這個門外漢也只能是簡單介紹一下了。數學專業畢業的我非常慚愧，很後悔當時沒有好好學數學。
在我們的業務中，遇到的能用機器學習解決的問題大概這么三類：
分類問題：包括二分類和多分類，二分類就是解決了預測的問題，就像預測一封郵件是否垃圾郵件；多分類解決的是文本的分類；
聚類問題：從用戶搜索過的關鍵詞，對用戶進行大概的歸類。
推薦問題：根據用戶的歷史瀏覽和點擊行為進行相關推薦。
大多數行業，使用機器學習解決的，也就是這幾類問題