1樓：Kyligence
Hadoop之上一般用Hive來作為資料倉儲進行OLAP計算與儲存。但Hive與前端BI展現層之間天生就隔著一層障礙。Hive比較適合做資料處理與儲存，但是在其上做資料查詢，可以說慢得無法忍受（我們不可能每發一條查詢，就去喝一杯咖啡吧）。
因此通常會有三種方案來實現BI（實際當然不止三種，但我們需要考慮併發性，基於記憶體實時計算的瓶頸，以及對SQL的支援程度）：
1. 在Hadoop之上又誕生了一些組建，比如Impala，Presto, Drill，Spark SQL等，他們的作用就是能快速響應查詢。然後再對接前端的一些BI展現工具（通過JDBC, ODBC連線），形成一套在Hadoop之上的完整BI方案。
這種方案的查詢效率確實有很大提公升，資料量小的話可以達到秒級，一般在分鐘級別以內。但由於查詢統計時，仍然使用的是實時計算，因此消耗資源極大，併發一直上不去，隨著資料量的增長，查詢響應時間也會增長。
2. Hive上的資料加工完之後，把資料再寫回到傳統的關係型資料庫中（如Oracle, MySQL），在這些資料庫上建立很多中間表，彙總表，以減少查詢時需要檢索的資料量，從而提公升查詢效能。前端BI展現工具可以像以前一樣直接對接關係型資料庫。
這種方案已經用到了預計算的思想，並且充分利用了關係型資料庫的查詢優化效能。但這種結構非常臃腫，用完Hadoop之後還要再用關係型資料庫不說，單單建立那麼多中間表，彙總表，開發以及運維人員就不可能有時間去約會喝咖啡。
3. 直接在 Hadoop之上做預計算，從而提公升查詢效能（Hadoop + Apache Kylin）。這種方式比較簡潔，很多網際網路公司都在用。
優點是查詢響應快，併發高，資料不再需要轉存到關係型資料庫，乙個Kylin的cube就可以代替很多彙總表，運維簡單。當然也有缺點，需要事先定義好cube的維度和度量，不適合業務需求頻繁變動的場景。
對資料改變商業這件事感興趣的小夥伴可以來 Kyligence 官網兜兜
2樓：加肥貓
分為有錢和沒錢兩種方式
有錢:tableau + aws redshift 如果資料量大可以前面再接emr
優點省心，快速開發，
沒錢:superset + druid + hive優點成本只有硬體。 一次性投入。
如果需要做複雜的中國式報表，只能再加php了。
etl用airflow 自己整合dbapi 不亦樂乎。
開發語言只需要python 和sql
目前我在的公司資料有錢的，只有兩個人做資料，輕鬆搞定資料倉儲和報表不加班。當然業務也不太複雜。
2023年4月8日更新答案.
最近在嘗試Kudu了.cloudera公司的配合Impala,發現效能和速度都可以滿足需求.目前也沒沒有遇到大規模使用.
據我所知cloudera公司也不建議在金融領域高精度要求的場景使用Kudu,資料完整性保證為99.9%,但是一般企業資料倉儲應該可以.可以大大簡化hadoop元件生態和維護成本.
便於快速搭建和開發.
3樓：肖梓
HIVE查詢非常慢的，它的強大之處在於應用MapReduce處理框架能夠很好的計算資料，本身就不是做查詢的，大部分做法都是HIVE作為乙個海量儲存的倉庫，後續處理完的彙總資料挪到關係型資料庫中，供前端查詢，如果資料量還是非常大，可以使用ES。
4樓：顧西樓
沒完整做過bi系統。但我們公司的訂單資料我都要求實時拋給我，我都扔到佇列，然後按財物、運營、倉儲採購的業務需要，每個訂單都跑一段邏輯，各種計算和拆分，然後儲存結果到mysql。儲存起來的都是各種最終結果，業務方查詢都是超快！
資料再大，可以在此基礎再做一次拆分，就時間維度而言。這個時候還需要hadoop，hbase，spark這些架構嗎？請教！
5樓：王騰
推薦關注兩個專案可以看下，Horonworks的HDP和Cloudera的CDH，兩個專案都提供了基於VM的quickstart。主要是幫助了解資料平台基本組成和流程。
國內的資料平台已經開始形成正規化，組成有資料交換系統(資料同步中心)、資料開發平台(SQL/Python/Shell開發及管理)、任務排程系統、報表展示系統、實時計算框架、元資料管理、許可權管理、資料探勘演算法框架、資料質量管理、集群效能監控、簡訊報警中心等等。
6樓：sink
BI=ETL+Data Mining+Data Presentation；可以將資料儲存在MySQL中，之後匯入到Hadoop，通過Hive管理Hadoop的資料儲存，用RHive實現R與Hive的對接，並在RHive中完成ETL。前端直接通過Rstudio展現
7樓：錢宇翔
BI包含了資料採集資料處理和分析資料顯示，單純hadoop只能做etl部分，也就是中間這塊，前端採集用canal（阿里開源採集資料庫binlog），flume採集日誌。資料顯示部分可以調研下dashboard。綜上所述，用kettle…
8樓：李智慧型
那些認為已經有資料倉儲的傳統企業不需要Hadoop的，很快就要out了。
據我所知，很多銀行已經開始評估將data warehouse遷移到Hadoop相關產品上來了，倒不是為了利用Hadoop的低成本優勢做傳統BI，而是看中大資料平台上的各種成熟的machine learning，data mining，大資料對傳統行業的改造和洗牌剛剛開始。
至於傳統BI工具如何結合Hive，介面上問題不大，JDBC，ODBC都可以，自己寫thrift client也問題不大，麻煩在於，目前Hive（以及Impala，Shark）這些支援的都不是標準SQL，歷史遺留下來的那些動輒幾頁的SQL根本沒法在Hive上執行。
開源專案intel-hadoop/project-panthera · GitHub 目標是支援Hive（Shark）實現標準SQL，目前基本功能已經完成，（TPCH通過率100%，此前測試的Hive0.10通過率0）。
9樓：田原Junshen
單就和Hadoop/Hive相結合的BI前端展現來說，沒有必要自己去實現，pentaho是最好的選擇。Business analytics and business intelligence leaders
1、開源
2、對Hadoop支援的好，對於幾大Hadoop Dis廠商都有很直接的支援。
3、非常的優美
10樓：阿外
對大資料的入倉操作，使用hive是合適的，通過一定的計算處理（包括離線計算、挖掘、記憶體計算等），將計算結果另存到資料庫，根據類別分為sql和NoSQL，再用OLAP引擎等進行分析建模。僅供參考http://
zior.org/archives/614.html
11樓：binlijin
hadoop只是處理大資料的乙個平台，計算出來的結果都很小，放到前端資料庫中，給展現和應用層使用，乙個是經濟性好，另乙個是可以處理資料庫無法處理的海量資料，推薦http://
velocity.oreilly.com.cn
/2010/index.php?func=session&name=%E6%B7%98%E5%AE%9D%E4%BA%91%E6%A2%AF%E5%88%86%E5%B8%83%E5%BC%8F%E8%AE%A1%E7%AE%97%E5%B9%B3%E5%8F%B0%E6%95%B4%E4%BD%93%E6%9E%B6%E6%9E%84
12樓：阿杜
可以使用hadoop儲存，計算利用其它工具（我們使用greenplum）,這樣完全就可以使用SQL無縫銜接hadoop,然後再連線其它傳統BI工具進行報表和分析等等
13樓：易鐸
微軟最近也開發了SQL Server 和 Hadoop 的資料介面。這樣計算放在Hadoop，前端展現還是使用傳統的報表、Excel等。
14樓：
就BI的資料探勘部分來說，hadoop是不適用的，而且一般建設BI的都是大型企業，他們都具有海量資料並且已經在傳統資料倉儲模式上建立了應用，所以一般不會冒險（也沒有必要）將資料探勘部分遷移到hadoop上。
反倒是資料探勘之前的ETL部分，因為資料運算比較簡單，而且需要處理很多格式的大規模文字（或其他）檔案，比較適用hadoop的。
一方面降低成本，方便擴容，一方面減輕主資料倉儲的壓力。
15樓：xoyowade
無非兩種方式：
把hive的資料轉換成SQL資料，重用以前的BI工具重新根據需求實現BI的邏輯
另外我知道rice已經有人在做hive上實現全SQL語義的工作。
推薦這兩篇部落格：
如何進行Hadoop集群搭建？
邱同學 想切換到其他使用者，提示sudo命令不存在？這是你當前使用者環境變數有些問題吧？可以進入到hadoop的安裝路徑執行，或者執行一下 whereis hadoop查詢一下hadoop所在路徑，用完整的命令路徑執行。 題主應該先問為什麼 hadoop 找不到命令。先檢查一下 PATH 環境變數 ...
BI在企業的應用和前景如何？
叮噹 在過去的幾十年裡，BI經歷了從工具到 決策大腦 的角色轉變，而未來一定是向 智慧型決策大腦 轉型，對於企業而言,尤其是與一定資料積累的企業,應用及前景處於急速發展期 為什麼會對這些概念這麼敏感,因為我們自己公司就用了一整套BI解決方案,是由Wyn提供的，我們整體已經形成了乙個非常良性的迴圈。我...
機械和程式設計如何結合？
卡卡羅特 本人和你很像啊 機械工程系，現在自學Python中，不為以後，只是興趣，當然也對以後學機械電子工程的程式設計打基礎。現在主要以學習機械基礎為主，把基礎打紮實了，接著工作時候再把所學大部分知識運用起來，才可在這個行業立於不敗 宋永鑫Jsd 上位機 各種語言都可以我用labview 控制plc...