⑴ apache安裝後我用的8000埠 輸入localhost:8000 IE顯示it works 而火狐和谷歌瀏覽器顯示index of/
8000埠已經被佔用了，你查一下看是哪個服務用了這個埠，可以改下apache的默認埠版（埠號要沒被佔用權），也可以把另外那個服務的默認埠改下。
改apache的默認埠的方法：找到apache安裝目錄，下面有一個conf的文件夾，進去裡面有個httpd.conf的文件，用記事本打開，ctrl+f 查找Listen,找到
#Listen 12.34.56.78:80
Listen 8000
這一段，把8000改下就好了。你輸入網址的時候埠號要對應改下
⑵ Google guava和Apache commons哪個好
guava是通過maven構建的,最新代碼可以從github上下載, 在Eclipse中,通過File-Import,選擇maven就可以輕松導入了
⑶ Google推出了Apache Beam以後，spark和flink的路已經要走完了么
可能是這樣的：後期大數據處理平台變得很多之後，各領域需要使用不同的平台處回理不一樣的業務，這樣就答需要了解各種平台的二次開發。
且如果業務之間有交互，就會對業務人員編程能力有較高的要求。如果用了Beam，Bang！你只需要學會Beam的編程模式就可以了，底層執行通過配置項來實現。
⑷ apache日誌如何記錄百度谷歌等蜘蛛（追加分）
你想要查看網路或者是谷歌的蜘蛛是否爬過自己的網站，我可以給你提供一下例子，呵呵版，把自權己的日誌分享給你看一下，告訴你如何來看蜘蛛來訪情況。
你打開網站的日誌，在裡面查找網路或者是谷歌蜘蛛的名字
網路的蜘蛛是spider，谷歌的蜘蛛是Googlebot
然後可以看一下具體的情況，假如像下面這個例子：
GET /index.htm - 80 - 220.181.7.32 Baispider+(+http://www..com/search/spider.htm) 200 0 0
它的含義是：來自220.181.7.32這個IP地址的網路蜘蛛來到你的網站，成功的抓取了index.htm首頁，200代碼表示的是成功抓取，404是錯誤頁，還有一些其他的代碼你可以在網上查一下。
希望通過上面的這個例子，你能了解自己站的情況。
⑸ Google guava和Apache commons哪個好
Guava 的 FAQ 部分有專門解答：
Why did Google build all this, when it could have tried to improve the Apache Commons Collections instead?
The Apache Commons Collections very clearly did not meet our needs. It does not use generics, which is a problem for us as we hate to get compilation warnings from our code. It has also been in a "holding pattern" for a long time. We could see that it would require a pretty major investment from us to fix it up until we were happy to use it, and in the meantime, our own library was already growing organically.
An important difference between the Apache library and ours is that our collections very faithfully adhere to the contracts specified by the JDK interfaces they implement. If you review the Apache documentation, you'll find countless examples of violations. They deserve credit for pointing these out so clearly, but still, deviating from standard collection behavior is risky! You must be careful what you do with such a collection; bugs are always just waiting to happen.
Our collections are fully generified and never violate their contracts (with isolated exceptions, where JDK implementations have set a strong precedent for acceptable violations). This means you can pass one of our collections to any method that expects a Collection and feel pretty confident that things will work exactly as they should.
簡單地說：
Apache Commons Collections 3.x 不支持泛型，Guava 支持
Guava 實現了 JDK 的標准介面，而 Apache Commons Collections 3.x 有很多違反標準的地方
Apache Commons Collections 4.x 的發行注記如下：
Majorchangessince3.2.1
(varargs,Iterable)
Removeddeprecatedclasses/
.util.Queue
/Get(seealsopackagesplitmap)
從 4.x 開始，Apache Commons Collections 開始使用 JDK 5 的特性（包括泛型），此外也去除、添加了很多內容
各有千秋, 我主要使用Apache Commons ,輔助使用 Google guava
但是細節方法上還是有區別的, 比如
GoogleGuava Splitter 對比 Apache StringUtils
apache commons的StringUtils提供的常用功能介紹，但是google的guava也提供了一些字元串處理的常見功能，所以，將對兩者的字元串分割函數做一次比較詳細的對比（結果比較surprise）。
區別
首先看基本的使用方法：
//ApacheStringUtils...
String[]tokens1=StringUtils.split("one,two,three",',');
//GoogleGuavasplitter...
Iteratable<String>tokens2=Splitter.on(','),split("one,two,three");
google提供的方法更加的面向對象一點，因為它要先創建一個Splitter對象，然後使用它來分割字元串，而apache的方法則有點函數式編程的味道，它的方法都是靜態的。
這里我更加傾向於採用google的splitter，因為這個對象是可以重用的，且可以在其上附加更多的功能，比如trim，去掉空的元素等，一切都很簡單。
SplitterniceCommaSplitter=Splitter.on(',').omitEmptyString().trimResults();
niceCommaSplitter.split("one,,two,three");//"one","two","three"
niceCommaSplitter.split("four,five");//"four","five"
看起來有點用，還有其他區別么？
另外一個需要注意的地方就是Splitter返回的是Iteratable<String>，而StringUtils.split返回的是一個String數組。
大部分使用分隔符的情況是我們需要對字元串按照分隔符進行遍歷處理，僅此而已。
下面就是常用的代碼性能對比的例子：
finalStringnumberList="One,Two,Three,Four,Five,Six,Seven,Eight,Nine,Ten";
longstart=System.currentTimeMillis();
for(inti=0;i<1000000;i++){
StringUtils.split(numberList,',');
}
System.out.println(System.currentTimeMillis()-start);
start=System.currentTimeMillis();
for(inti=0;i<1000000;i++){
Splitter.on(',').split(numberList);
}
System.out.println(System.currentTimeMillis()-start);
代碼很簡單，就是都對同一個字元串進行100萬次的分隔操作，看看時間上的區別，結果如下：
983
165
很明顯，guava的速度快很多，這個程序如果運行在每天處理大量字元串的服務中，那麼性能差異更加明顯。我想其中的原因是Splitter返回的是Iterable<String>，而StringUtils.split返回的是一個String[]，需要創建新的String對象，導致耗時增加。
如果我們對Splitter對象緩存，那麼速度提高更多：
start=System.currentTimeMillis();
Splitters=Splitter.on(',');
for(inti=0;i<1000000;i++){
s.split(numberList);
}
System.out.println(System.currentTimeMillis()-start);
結果為12，神奇吧，呵呵
⑹ 開源項目屬於誰就像安卓 apache開源等開源項目，那麼谷歌擁有安卓嗎
谷歌當然擁有安卓，要不然谷歌不會花那麼多錢、人力與精力推廣安卓。
開源項目屬於開發開源項目的個人或者公司所有，正常不收費，如果要企業定製就需要收費了。
⑺ Google guava和Apache commons哪個好
Guava 的 FAQ 部分有專門解答：
Why did Google build all this, when it could have tried to improve the Apache Commons Collections instead?
The Apache Commons Collections very clearly did not meet our needs. It does not use generics, which is a problem for us as we hate to get compilation warnings from our code. It has also been in a "holding pattern" for a long time. We could see that it would require a pretty major investment from us to fix it up until we were happy to use it, and in the meantime, our own library was already growing organically.
An important difference between the Apache library and ours is that our collections very faithfully adhere to the contracts specified by the JDK interfaces they implement. If you review the Apache documentation, you'll find countless examples of violations. They deserve credit for pointing these out so clearly, but still, deviating from standard collection behavior is risky! You must be careful what you do with such a collection; bugs are always just waiting to happen.
Our collections are fully generified and never violate their contracts (with isolated exceptions, where JDK implementations have set a strong precedent for acceptable violations). This means you can pass one of our collections to any method that expects a Collection and feel pretty confident that things will work exactly as they should.
簡單地說：
Apache Commons Collections 3.x 不支持泛型，Guava 支持
Guava 實現了 JDK 的標准介面，而 Apache Commons Collections 3.x 有很多違反標準的地方
Apache Commons Collections 4.x 的發行注記如下：
Major changes since 3.2.1
Use of generics and other language features introced in Java 5 (varargs, Iterable)
Removed deprecated classes / methods and features which are now supported by the JDK
Replaced Buffer interface with java.util.Queue
Added concept of split maps with respective interfaces Put / Get (see also package splitmap)
Added new Trie interface together with an implementation of a Patricia Trie
從 4.x 開始，Apache Commons Collections 開始使用 JDK 5 的特性（包括泛型），此外也去除、添加了很多內容
各有千秋, 我主要使用Apache Commons ,輔助使用 Google guava
⑻ Google推出了Apache Beam以後，spark和flink的路已經要走完了么
實時領域不一定要使用它這個架構，但是可以借用這個框架，尤其是在一些內細分的場景上。
一個簡單的容場景是提供一套API可以在Storm和Flink上切換引擎。不過自從Flink問世後，開源Storm的使用價值已經不大了，除了360攜程等廠使用自己改造的Storm或者JStorm，新上線的業務一般還是走了Spark Streaming 或者Flink.
⑼ Apache的Mesos和Google的Kubernetes 有什麼區別
Kubernetes是一個開源項目，它把谷歌的集群管理工具引入到虛擬機和裸機場景中。它可以完美運行在現代的操作系統環境（比如CoreOS
和Red Hat
Atomic），並提供可以被你管控的輕量級的計算節點。Kubernetes使用Golang開發，具有輕量化、模塊化、便攜以及可擴展的特點。我們
（Kubernetes開發團隊）正在和一些不同的技術公司（包括維護著Mesos項目的MesoSphere）合作來把Kubernetes升級為一種
與計算集群交互的標准方式。Kubernetes重新實現了Google在構建集群應用時積累的經驗。這些概念包括如下內容：
Pods：一種將容器組織在一起的方法；
Replication Controllers：一種控制容器生命周期的方法（譯者註：Replication Controller確保任何時候Kubernetes集群中有指定數量的pod副本(replicas)在運行）；
Labels：一種可以找到和查詢容器的方法；
Services：一個用於實現某一特定功能的容器組；
因此，只要使用Kubernetes你就能夠簡單並快速的啟動、移植並擴展集群。在這種情況下，集群就像是類似虛擬機一樣靈活的資源，它是一個邏輯運算單元。打開它，使用它，調整它的大小，然後關閉它，就是這么快，就是這么簡單。
Mesos和Kubernetes的願景差不多，但是它們在不同的生命周期中各有不同的優勢。Mesos是分布式系統內核，它可以將不同的機器整
合在一個邏輯計算機上面。當你擁有很多的物理資源並想構建一個巨大的靜態的計算集群的時候，Mesos就派上用場了。有很多的現代化可擴展性的數據處理應
用都可以在Mesos上運行，包括Hadoop、Kafka、Spark等，同時你可以通過容器技術將所有的數據處理應用都運行在一個基礎的資源池中。在
某個方面來看，Mesos是一個比Kubernetes更加重量級的項目，但是得益於那些像Mesosphere一樣的貢獻者，Mesos正在變得更加簡
單並且容易管理。
有趣的是Mesos正在接受Kubernetes的理念，並已經開始支持Kubernetes
API。因此如果你需要它們的話，它將是對你的Kubernetes應用去獲得更多能力的一個便捷方式（比如高可用的主幹、更加高級的調度命令、去管控很
大數目結點的能力），同時能夠很好的適用於產品級工作環境中（畢竟Kubernetes仍然還是一個初始版本）。
當被問到區別的時候，我會這樣回答：
如果你是一個集群世界的新手，那Kubernetes是一個很棒的開始。它可以用最快的、最簡單的、最輕量級的方式來解決你的問題，並幫
助你進行面向集群的開發。它提供了一個高水平的可移植方案，因為很多廠商已經開始支持Kubernetes，例如微軟、IBM、Red
Hat、CoreOS、MesoSphere、VMWare等。
如果你擁有已經存在的工作任務（Hadoop、Spark、Kafka等），那Mesos可以給你提供了一個將不同工作任務相互交錯的框架，然後還可以加入一些新的東西，比如Kubernetes應用。
如果你想使用的功能Kuberntes還沒實現，那Mesos是一個不錯的替代品，畢竟它已經成熟。
⑽ 為什麼Google用Apache Beam徹底替換掉MapRece
原因主要有兩點：
1、盡管在過去谷歌一直是閉源的，但在為雲客戶服務的過程中，谷歌已經認識到了開源軟體的的巨大價值，比如基於谷歌三篇論文產生的Hadoop社區就是一個非常好的例子。思想上的轉變使Apache Beam的誕生成為可能；
2、就Beam這個項目而言，要成功的必要條件之一是，必須有已經開源的Runner為Beam模型提供充分的支持，這樣它才會在自建雲和非谷歌雲的場景下成為一個非常有競爭力的備選方案。去年Apache Flink在他們的系統內採用了Beam模型，這一條件也得到了滿足；
無利不起早，谷歌這樣做也是有著直接商業動機的，就是希望能有盡可能多的Apache Beam數據處理流水線可以運行在谷歌的Cloud Dataflow上，別忘了這是Apache Beam的原型。進一步說，採用開源的方式來引導這件事，也是有許多直接好處的：
1、支持Apache Beam的Runner越多，它作為一個平台的吸引力就越大；
2、使用Apache Beam的用戶越多，想在谷歌雲平台上運行Apache Beam的用戶也就越多；
3、開發Apache Beam過程中吸引到的夥伴越多，那對這樣的數據處理模型的推廣就越有利；
而且，好處也不會全都歸於谷歌，Apache Beam項目中的所有參與方都會受益。如果在構建數據處理流水線時存在著這樣一個可移植的抽象層，那就會更容易出現新的Runner，它們可以專注於技術創新，提供更高的性能、更好的可靠性、更方便的運維管理等。換句話說，消除了對API的鎖定，就解放了處理引擎，會導致更多產品之間的競爭，從而最終對整個行業起到良性的促進作用。
谷歌堅信Apache Beam就是數據批量處理和流式處理的未來。這么做會為各種不同的Runner營造一個健康的生態系統，讓它們之間相互競爭，而最後可以讓用戶得到實在的好處。