Hadoop 和 BI 如何結合？搭建一個基於 Hadoop+Hive 的數據倉庫，它的前端展現如何實現？如何實現 BI？

01-05

單就和Hadoop/Hive相結合的BI前端展現來說，沒有必要自己去實現，pentaho是最好的選擇。Business analytics and business intelligence leaders

1、開源

2、對Hadoop支持的好，對於幾大Hadoop Dis廠商都有很直接的支持。

3、非常的優美

就BI的數據挖掘部分來說，hadoop是不適用的，而且一般建設BI的都是大型企業，他們都具有海量數據並且已經在傳統數據倉庫模式上建立了應用，所以一般不會冒險（也沒有必要）將數據挖掘部分遷移到hadoop上。

反倒是數據挖掘之前的ETL部分，因為數據運算比較簡單，而且需要處理很多格式的大規模文本（或其他）文件，比較適用hadoop的。

一方面降低成本，方便擴容，一方面減輕主數據倉庫的壓力。

無非兩種方式：

把hive的數據轉換成SQL數據，重用以前的BI工具
重新根據需求實現BI的邏輯

另外我知道rice已經有人在做hive上實現全SQL語義的工作。

推薦這兩篇博客：

http://www.cloudera.com/blog/2010/05/considerations-for-hadoop-and-bi/

http://www.cloudera.com/blog/2010/06/considerations-for-hadoop-and-bi-part-2-of-2/

那些認為已經有數據倉庫的傳統企業不需要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）。

Hadoop is another data storage choice in this technology continuum. The Hadoop Distributed File System (HDFS) or Hive is often used to store transactional data in its 「raw state.」 The map-reduce processing supported by these Hadoop frameworks can deliver great performance, but it does not support the same specialized query optimization that mature relational database technologies do. Improving query performance, at this time, requires acquiring query accelerators or writing code. In other words, retrieving a list of transactions for specific dates, geography and so forth may be fast and simple but aggregate-oriented calculations – average same-store sales or sales by square feet , for example – will likely require programming skills to obtain the desired performance.
Hadoop-based data tends to be limited to reporting capabilities in a business intelligence application due to its batch oriented processing. Good performance for interactive capabilities may be achieved for specific areas, but performance for general ad hoc queries may not be satisfactory due to the overhead in setting up jobs for processing. Contributions, such as Impala, to the Apache open source project establish a starting point for delivering better performance for interactivity, but this technology needs to evolve and mature before broad adoption is feasible.
Leveraging systems that are optimized for interactive analytics is recommended when data is frequently analyzed or being delivered to interactive dashboards. The diagram below extends the previous diagram to convey where Hadoop-based data fits in the data store continuum.

Reference:

1. Where Does Hadoop Fit in a Business Intelligence Data Strategy?

從facebook的ppt上了解到的是他們在hive上做大數據量的分析，計算結果放到oracle上做BI展示和計算

搜索easyhadoop

以互聯網電商行業為例，直接上架構圖吧。

很多互聯網公司的都是hadoop +ETL+關係型資料庫然後連接一些報表工具，比如FineReport或者BI工具FineBI來呈現分析結果的。

關於Hadoop與BI的應用

Hadoop是個很流行的分散式計算解決方案，是Apache的一個開源項目名稱，核心部分包括HDFS及MapReduce。其中，HDFS是分散式文件系統，MapReduce是分散式計算引擎。時至今日，Hadoop在技術上已經得到驗證、認可甚至到了成熟期，同時也衍生出了一個龐大的生態圈，比較知名的包括HBase、Hive、Spark等。HBase是基於HDFS的分散式列式資料庫，HIVE是一個基於HBase數據倉庫系統。Impala為存儲在HDFS和HBase中的數據提供了實時SQL查詢功能，基於HIVE服務，並可共享HIVE的元數據。Spark是一個類似MapReduce的並行計算框架，也提供了類似的HIVE的Spark SQL查詢介面，Hive是基於hadoop的數據分析工具。

很多企業比如銀行流水作業很多，數據都是實時更新且數據量很大。會採用hadoop作為底層資料庫，藉由中間商處理底層數據，然後通過BI系統去連接這些中間數據處理廠商的中間表，接入處理數據，尤其以星環、華為這類hadoop大數據平台商居多，使用也較為廣泛。

以星環大數據+帆軟大數據BI工具FineBI的結合為例。

由於星環也是處理hadoop下的hive資料庫，其本質都是差不多的，可以使用Hive提供的jdbc驅動，這個驅動同樣可以讓FineBI連接星環的資料庫並進行一些類關係型資料庫的sql語句查詢等操作。

將這些驅動拷貝到BI工程下面，然後重啟BI伺服器。重啟後可以建立與星環資料庫的數據連接，最後通過連接進行數據查詢。

1、本地部署

下圖是FineBI內部測試用的hadoop的jar包（將以下jar包放置於webinf-lib文件夾下），親測，可連接成功，如下圖所示：

2、數據連接

測試連接成功之後，點擊確定，可直接選擇資料庫中對應的表加入業務包（文末有闡述）中，類似於Mysql這些最常見的資料庫取表方式。

3、實際分析案例

某銀行的總行層面-機構維度-四象限圖

（2）總行層面-機構維度-趨勢分析

（3）總行層面-產品維度-盈利產品

4．關於FineBI的FineIndex和FineDirect功能

hadoop是底層，hive是資料庫，上述案例採用的是FineIndex（cube連）連接，用的是hiveserver的方式進行數據連接的；數據連接成功之後，將hive資料庫中的表添加到業務包中，也就是將庫中數據拿到我們的多維資料庫（FineIndex），當然抓取的過程中也可以讀取資料庫關聯和轉義，也可以手動轉義和進行關聯，同時也可以做一些etl操作如新增公式列/行列轉換/join/union/過濾/分組統計/自循環列/新增分組列/使用部分欄位等，做過處理的這些數據表用於前端分析。

也就是說資料庫-FineIndex-前端分析，這裡的FineIndex相當於一個中間庫的形式，用來存儲數據表，關聯轉義索引等。這些都對後續前台分析處理數據效率有很大的提升（因為直接sql取數，效率受資料庫本身的限制，數據量大時，一般分析工具很容易就卡死升職內存溢出導致系統無響應），這也是FineIndex方案的初衷。FineIndex存在有兩個意義，一個是提升效率，一個就是對數據進行二次整合處理。

FineBI還有一個連接方式FineDirect（資料庫直連），主要是應對如下需求：

1、分析結果的實時性

企業用戶在使用BI工具的時候，多數情況下是對大量的歷史數據進行OLAP分析，但是也有部分用戶需要展現結果的實時性。例如金融行業對於交易風險的分析，是對每一筆流水實時進行分析的，如果需要經過構建多維資料庫的過程，數據到來就會有延遲，影響分析結果的準確性。但是因為計算的過程交給了資料庫，響應速度更多的取決於資料庫的性能。

2、大數據平台的充分利用

隨著各種分散式計算方案的不斷優化，數據的計算性能也有了快速的發展，計算能力有了顯著的提高，不少企業已經有了自己的大數據計算平台，例如hadoop，kylin，greenplum，vertica等，這些平台的對於大數據量的處理性能已經足以滿足使用需求，不再有建模的需求，因此FineBI直連引擎提供了對接這些數據平台的功能。

BI=ETL+Data Mining+Data Presentation；可以將數據存儲在MySQL中，之後導入到Hadoop，通過Hive管理Hadoop的數據存儲，用RHive實現R與Hive的對接，並在RHive中完成ETL。前端直接通過Rstudio展現

hadoop MR or hive上ETL計算完的結果表，同步到oracle中，連接傳統BI工具，呈現報表，阿里、騰訊、盛大都是這樣的

BI包含了數據採集數據處理和分析數據顯示，單純hadoop只能做etl部分，也就是中間這塊，前端採集用canal（阿里開源採集資料庫binlog），flume採集日誌。數據顯示部分可以調研下dashboard。綜上所述，用kettle…

hadoop只是處理大數據的一個平台，計算出來的結果都很小，放到前端資料庫中，給展現和應用層使用，一個是經濟性好，另一個是可以處理資料庫無法處理的海量數據，推薦http://velocity.oreilly.com.cn/2010/index.php?func=sessionname=%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

沒完整做過bi系統。但我們公司的訂單數據我都要求實時拋給我，我都扔到隊列，然後按財物、運營、倉儲採購的業務需要，每個訂單都跑一段邏輯，各種計算和拆分，然後保存結果到mysql。保存起來的都是各種最終結果，業務方查詢都是超快！數據再大，可以在此基礎再做一次拆分，就時間維度而言。這個時候還需要hadoop，hbase，spark這些架構嗎？請教！

對大數據的入倉操作，使用hive是合適的，通過一定的計算處理（包括離線計算、挖掘、內存計算等），將計算結果另存到資料庫，根據類別分為sql和NoSQL，再用OLAP引擎等進行分析建模。僅供參考http://zior.org/archives/614.html

Hadoop上可以集成mahout工具，用來實現複雜的BI運算

Apache Zeppelin, 很快1.0了

分為有錢和沒錢兩種方式

有錢:

tableau + aws redshift 如果數據量大可以前面再接emr

優點省心，快速開發，

沒錢:

superset + druid + hive

優點成本只有硬體。一次性投入。

如果需要做複雜的中國式報表，只能再加php了。

etl用airflow 自己集成dbapi 不亦樂乎。

開發語言只需要python 和sql

目前我在的公司數據有錢的，只有兩個人做數據，輕鬆搞定數據倉庫和報表不加班。當然業務也不太複雜。

Hadoop的生態圈越來越豐富和完善，所有2年前的答案和現在的答案完全不同

HIVE查詢非常慢的，它的強大之處在於應用MapReduce處理框架能夠很好的計算數據，本身就不是做查詢的，大部分做法都是HIVE作為一個海量存儲的倉庫，後續處理完的匯總數據挪到關係型資料庫中，供前端查詢，如果數據量還是非常大，可以使用ES。

傳統bi工具都能支持，不用特別開發。