A. 100個欄位的hive大寬表kylin如何處理
只要是sql中需要查的欄位，在建立cuboid時全部需要作為維度指定，不可以只設置其中幾個維度，只有cuboid個數是可以通過優化減少的
B. 大數據平台建設有哪些步驟以及需要注意的問題
大數據平台的搭建步驟：
1、linux系統安裝
一般使用開源版的Redhat系統--CentOS作為底層平台。為了提供穩定的硬體基礎，在給硬碟做RAID和掛載數據存儲節點的時，需要按情況配置。
2、分布式計算平台/組件安裝
國內外的分布式系統的大多使用的是Hadoop系列開源系統。Hadoop的核心是HDFS，一個分布式的文件系統。在其基礎上常用的組件有Yarn、Zookeeper、Hive、Hbase、Sqoop、Impala、ElasticSearch、Spark等
使用開源組件的優點：1）使用者眾多，很多bug可以在網上找的答案（這往往是開發中最耗時的地方）。2）開源組件一般免費，學習和維護相對方便。3）開源組件一般會持續更新，提供必要的更新服務『當然還需要手動做更新操作』。4）因為代碼開源，若出bug可自由對源碼作修改維護。
3、數據導入
數據導入的工具是Sqoop。用它可以將數據從文件或者傳統資料庫導入到分布式平台『一般主要導入到Hive，也可將數據導入到Hbase』。
4、數據分析
數據分析一般包括兩個階段：數據預處理和數據建模分析。
數據預處理是為後面的建模分析做准備，主要工作時從海量數據中提取可用特徵，建立大寬表。這個過程可能會用到Hive SQL，Spark QL和Impala。
數據建模分析是針對預處理提取的特徵/數據建模，得到想要的結果。這一塊最好用的是Spark。常用的機器學習演算法，如樸素貝葉斯、邏輯回歸、決策樹、神經網路、TFIDF、協同過濾等，都已經在ML lib裡面，調用比較方便。
5、結果可視化及輸出API
可視化一般式對結果或部分原始數據做展示。一般有兩種情況，行數據展示，和列查找展示。要基於大數據平台做展示，會需要用到ElasticSearch和Hbase。Hbase提供快速『ms級別』的行查找。 ElasticSearch可以實現列索引，提供快速列查找。
大數據平台搭建中的主要問題
1、穩定性 Stability
理論上來說，穩定性是分布式系統最大的優勢，因為它可以通過多台機器做數據及程序運行備份以確保系統穩定。但也由於大數據平台部署於多台機器上，配置不合適，也可能成為最大的問題。
2、可擴展性 Scalability
如何快速擴展已有大數據平台，在其基礎上擴充新的機器是雲計算等領域應用的關鍵問題。在實際2B的應用中，有時需要增減機器來滿足新的需求。如何在保留原有功能的情況下，快速擴充平台是實際應用中的常見問題。
C. 大數據存儲與應用特點及技術路線分析
大數據存儲與應用特點及技術路線分析
大數據時代，數據呈爆炸式增長。從存儲服務的發展趨勢來看，一方面，對數據的存儲量的需求越來越大；另一方面，對數據的有效管理提出了更高的要求。大數據對存儲設備的容量、讀寫性能、可靠性、擴展性等都提出了更高的要求，需要充分考慮功能集成度、數據安全性、數據穩定性，系統可擴展性、性能及成本各方面因素。
大數據存儲與應用的特點分析
「大數據」是由數量巨大、結構復雜、類型眾多數據構成的數據集合，是基於雲計算的數據處理與應用模式，通過數據的整合共享，交叉復用形成的智力資源和知識服務能力。其常見特點可以概括為3V:Volume、Velocity、Variety(規模大、速度快、多樣性)。
大數據具有數據規模大(Volume)且增長速度快的特性，其數據規模已經從PB級別增長到EB級別，並且仍在不斷地根據實際應用的需求和企業的再發展繼續擴容，飛速向著ZB(ZETA-BYTE)的規模進軍。以國內最大的電子商務企業淘寶為例，根據淘寶網的數據顯示，至2011年底，淘寶網最高單日獨立用戶訪問量超過1.2億人，比2010年同期增長120%,注冊用戶數量超過4億，在線商品數量達到8億，頁面瀏覽量達到20億規模，淘寶網每天產生4億條產品信息，每天活躍數據量已經超過50TB.所以大數據的存儲或者處理系統不僅能夠滿足當前數據規模需求，更需要有很強的可擴展性以滿足快速增長的需求。
(1)大數據的存儲及處理不僅在於規模之大，更加要求其傳輸及處理的響應速度快(Velocity)。
相對於以往較小規模的數據處理，在數據中心處理大規模數據時，需要服務集群有很高的吞吐量才能夠讓巨量的數據在應用開發人員「可接受」的時間內完成任務。這不僅是對於各種應用層面的計算性能要求，更加是對大數據存儲管理系統的讀寫吞吐量的要求。例如個人用戶在網站選購自己感興趣的貨物，網站則根據用戶的購買或者瀏覽網頁行為實時進行相關廣告的推薦，這需要應用的實時反饋;又例如電子商務網站的數據分析師根據購物者在當季搜索較為熱門的關鍵詞，為商家提供推薦的貨物關鍵字，面對每日上億的訪問記錄要求機器學習演算法在幾天內給出較為准確的推薦，否則就丟失了其失效性；更或者是計程車行駛在城市的道路上，通過GPS反饋的信息及監控設備實時路況信息，大數據處理系統需要不斷地給出較為便捷路徑的選擇。這些都要求大數據的應用層可以最快的速度，最高的帶寬從存儲介質中獲得相關海量的數據。另外一方面，海量數據存儲管理系統與傳統的資料庫管理系統，或者基於磁帶的備份系統之間也在發生數據交換，雖然這種交換實時性不高可以離線完成，但是由於數據規模的龐大，較低的數據傳輸帶寬也會降低數據傳輸的效率，而造成數據遷移瓶頸。因此大數據的存儲與處理的速度或是帶寬是其性能上的重要指標。
(2)大數據由於其來源的不同，具有數據多樣性的特點。
所謂多樣性，一是指數據結構化程度，二是指存儲格式，三是存儲介質多樣性。對於傳統的資料庫，其存儲的數據都是結構化數據，格式規整，相反大數據來源於日誌、歷史數據、用戶行為記錄等等，有的是結構化數據，而更多的是半結構化或者非結構化數據，這也正是傳統資料庫存儲技術無法適應大數據存儲的重要原因之一。所謂存儲格式，也正是由於其數據來源不同，應用演算法繁多，數據結構化程度不同，其格式也多種多樣。例如有的是以文本文件格式存儲，有的則是網頁文件，有的是一些被序列化後的比特流文件等等。所謂存儲介質多樣性是指硬體的兼容，大數據應用需要滿足不同的響應速度需求，因此其數據管理提倡分層管理機制，例如較為實時或者流數據的響應可以直接從內存或者Flash(SSD)中存取，而離線的批處理可以建立在帶有多塊磁碟的存儲伺服器上，有的可以存放在傳統的SAN或者NAS網路存儲設備上，而備份數據甚至可以存放在磁帶機上。因而大數據的存儲或者處理系統必須對多種數據及軟硬體平台有較好的兼容性來適應各種應用演算法或者數據提取轉換與載入(ETL)。
大數據存儲技術路線最典型的共有三種：
第一種是採用MPP架構的新型資料庫集群，重點面向行業大數據，採用Shared Nothing架構，通過列存儲、粗粒度索引等多項大數據處理技術，再結合MPP架構高效的分布式計算模式，完成對分析類應用的支撐，運行環境多為低成本 PC Server，具有高性能和高擴展性的特點，在企業分析類應用領域獲得極其廣泛的應用。
這類MPP產品可以有效支撐PB級別的結構化數據分析，這是傳統資料庫技術無法勝任的。對於企業新一代的數據倉庫和結構化數據分析，目前最佳選擇是MPP資料庫。
第二種是基於Hadoop的技術擴展和封裝，圍繞Hadoop衍生出相關的大數據技術，應對傳統關系型資料庫較難處理的數據和場景，例如針對非結構化數據的存儲和計算等，充分利用Hadoop開源的優勢，伴隨相關技術的不斷進步，其應用場景也將逐步擴大，目前最為典型的應用場景就是通過擴展和封裝 Hadoop來實現對互聯網大數據存儲、分析的支撐。這裡面有幾十種NoSQL技術，也在進一步的細分。對於非結構、半結構化數據處理、復雜的ETL流程、復雜的數據挖掘和計算模型，Hadoop平台更擅長。
第三種是大數據一體機，這是一種專為大數據的分析處理而設計的軟、硬體結合的產品，由一組集成的伺服器、存儲設備、操作系統、資料庫管理系統以及為數據查詢、處理、分析用途而特別預先安裝及優化的軟體組成，高性能大數據一體機具有良好的穩定性和縱向擴展性。
以上是小編為大家分享的關於大數據存儲與應用特點及技術路線分析的相關內容，更多信息可以關注環球青藤分享更多干貨
D. 大數據的分布式資料庫技術的對比
大數據技術的實現離不開很多其他的技術，我們提到最多的就是Hadoop技術，其實就目前而言，Hadoop技術看似是自成一套體系，其實並不是這樣的，Hadoop和Spark以及分布式資料庫其實也是存在差異的，我們就在這篇文章中給大家介紹一下這些內容。
首先我們說一說大數據分析，現在的大數據分析體系以Hadoop生態為主，而近年來逐漸火熱的Spark技術也是主要的生態之一。可以這么說，Hadoop技術只能算是以HDFS+YARN作為基礎的分布式文件系統，而不是資料庫。我們提到的Hadoop的歷史可以向前追溯10年，當年穀歌為了在幾萬台PC伺服器上構建超大數據集合並提供極高性能的並發訪問能力，從而發明了一種新的技術，而這個技術，也是Hadoop誕生的理論基礎。如果我們從Hadoop的誕生背景可以看出，其主要解決的問題是超大規模集群下如何對非結構化數據進行批處理計算。實際上，在Hadoop架構中，一個分布式任務可以是類似傳統結構化數據的關聯、排序、聚集操作，也可以是針對非結構化數據的用戶自定義程序邏輯。
那麼Hadoop的發展道路是什麼樣的呢。最開始的Hadoop以Big、Hive和MapRece三種開發介面為代表，分別適用於腳本批處理、SQL批處理以及用戶自定義邏輯類型的應用。而Spark的發展更是如此，最開始的SparkRDD幾乎完全沒有SQL能力，還是套用了Hive發展出的Shark才能對SQL有了一部分的支持。但是，隨著企業用戶對Hadoop的使用越發廣泛，SQL已經漸漸成為大數據平台在傳統行業的主要訪問方式之一。
下面我們就說一說分布式資料庫，分布式資料庫有著悠久的歷史，從以Oracle RAC為代表的聯機交易型分布式資料庫，到IBM DB2 DPF統計分析性分布式資料庫，分布式資料庫覆蓋了OLTP與OLAP幾乎全部的數據應用場景。而大部分分布式資料庫功能集中在結構化計算與在線增刪改查上。但是，這些傳統的分布式資料庫以數倉及分析類OLAP系統為主，其局限性在於，其底層的關系型資料庫存儲結構在效率上並不能滿足大量高並發的數據查詢以及大數據數據加工和分析的效率要求。因此，分布式資料庫在近幾年也有著極大的轉型，從單一的數據模型向多模的數據模型轉移，將OLTP、聯機高並發查詢以及支持大數據加工和分析結合起來，不再單獨以OLAP作為設計目標。同時，分布式資料庫在訪問模式上也出現了K/V、文檔、寬表、圖等分支，支持除了SQL查詢語言之外的其他訪問模式，大大豐富了傳統分布式資料庫單一的用途。一般來說，多模資料庫的主要目的是為了滿足具有高性能要求的操作型需求以及目標明確的數據倉庫功能，而不是類似大數據深度學習等數據挖掘場景。這就是分布式資料庫的實際情況。
我們在這篇文章中給大家介紹了大數據分析以及分布式資料庫的相關知識，通過這些內容相信大家已經理解了其中的具體區別了吧，如果這篇文章能夠幫助到大家這就是我們最大的心願。
E. 利用MySQL資料庫如何解決大數據量存儲問題
mysql解決大數據量存儲問題的方法是分表。
1.如何去分表
根據什麼策略把現有表中的數據分到多個表中，並且還有考慮到以後的擴展性上。
建立一張索引表，用戶id與資料庫id對應，（這里他將相同結構的表分在了不同的資料庫中進一步減少壓力，但同時對於數據的同步也需要通過其他手段來解決），其本質也是分表了同時分庫了。這么做的好處是便於以後的擴展，但損耗一點性能，因為會多一次查詢。這樣索引表可能會成為新的瓶頸，除非用戶不會一直增長哈。
我的做法屬於另一種，寫了個演算法通過計算某列值，按照一定規律將數據大致均分在每個分表中。至於擴展性，寫演算法時候考慮進去了以後增加分表數的問題了。
選擇哪種策略，是要看自己的表的業務特點了，方法沒有絕對的優缺，還是要根據自己的需求選取。
2.分表之後主鍵的維護
分表之前，主鍵就是自動遞增的bigint型。所以主鍵的格式已經提早被確定了，像什麼uuid之類的就被直接pass掉了。
還有想過自己寫一個主鍵生成程序，利用Java 的Atomic原子量特性，但是考慮還需要增加工作量並且高並發下，這里很可能是個隱患。
還有就是通過應用層上管理主鍵，如redis中有原子性的遞增。
F. 常見的基於列存儲的大數據資料庫有哪些
目前大數據存儲有兩種方案可供選擇：行存儲和列存儲。業界對兩種存儲方案有很多爭持，集中焦點是:誰能夠更有效地處理海量數據，且兼顧安全、可靠、完整性。從目前發展情況看，關系資料庫已經不適應這種巨大的存儲量和計算要求，基本是淘汰出局。在已知的幾種大數據處理軟體中，Hadoop的HBase採用列存儲，MongoDB是文檔型的行存儲，Lexst是二進制型的行存儲。在這里，我不討論這些軟體的技術和優缺點，只圍繞機械磁碟的物理特質，分析行存儲和列存儲的存儲特點，以及由此產生的一些問題和解決辦法。
G. 金融大數據平台應該如何搭建及應用是否有金融案例可以借鑒的
金融大數據平台的搭建和應用是兩個部分，對於金融大數據平台來說，這兩個部分都很重要。所以以下的部分我們從大數據平台和銀行可以分析哪些指標這兩個角度來闡述。
一、大數據平台
大數據平台的整體架構可以由以下幾個部分組成：
1.一個客戶
客戶主題：客戶屬性（客戶編號、客戶類別）、指標（資產總額、持有產品、交易筆數、交易金額、RFM）、簽約（渠道簽約、業務簽約）組成寬表
2.做了一筆交易
交易主題：交易金融屬性、業務類別、支付通道組成寬表。
3.使用哪個賬戶
賬戶主題：賬戶屬性（所屬客戶、開戶日期、所屬分行、產品、利率、成本）組成寬表
4.通過什麼渠道
渠道主題：
渠道屬性、維度、限額組成寬表
5.涉及哪類業務&產品
產品主題：產品屬性、維度、指標組成寬表
三、案例
鑒於篇幅問題，此處可以參考這篇文章：
華夏銀行：大數據技術服務業務需求，實現銷售高速增長
H. 微服務容器平檯面對大數據存儲是怎麼做的
整體而言，大數據平台從平台部署和數據分析過程可分為如下幾步：
1、linux系統安裝
一般使用開源版的Redhat系統--CentOS作為底層平台。為了提供穩定的硬體基礎，在給硬碟做RAID和掛載數據存儲節點的時，需要按情況配置。例如，可以選擇給HDFS的namenode做RAID2以提高其穩定性，將數據存儲與操作系統分別放置在不同硬碟上，以確保操作系統的正常運行。
2、分布式計算平台/組件安裝
目前國內外的分布式系統的大多使用的是Hadoop系列開源系統。Hadoop的核心是HDFS，一個分布式的文件系統。在其基礎上常用的組件有Yarn、Zookeeper、Hive、Hbase、Sqoop、Impala、ElasticSearch、Spark等。
先說下使用開源組件的優點：1）使用者眾多，很多bug可以在網上找的答案（這往往是開發中最耗時的地方）。2）開源組件一般免費，學習和維護相對方便。3）開源組件一般會持續更新，提供必要的更新服務『當然還需要手動做更新操作』。4）因為代碼開源，若出bug可自由對源碼作修改維護。
再簡略講講各組件的功能。分布式集群的資源管理器一般用Yarn，『全名是Yet Another Resource Negotiator』。常用的分布式數據數據『倉』庫有Hive、Hbase。Hive可以用SQL查詢『但效率略低』，Hbase可以快速『近實時』讀取行。外部資料庫導入導出需要用到Sqoop。Sqoop將數據從Oracle、MySQL等傳統資料庫導入Hive或Hbase。Zookeeper是提供數據同步服務，Yarn和Hbase需要它的支持。Impala是對hive的一個補充，可以實現高效的SQL查詢。ElasticSearch是一個分布式的搜索引擎。針對分析，目前最火的是Spark『此處忽略其他，如基礎的MapRece 和 Flink』。Spark在core上面有ML lib，Spark Streaming、Spark QL和GraphX等庫，可以滿足幾乎所有常見數據分析需求。
值得一提的是，上面提到的組件，如何將其有機結合起來，完成某個任務，不是一個簡單的工作，可能會非常耗時。
3、數據導入
前面提到，數據導入的工具是Sqoop。用它可以將數據從文件或者傳統資料庫導入到分布式平台『一般主要導入到Hive，也可將數據導入到Hbase』。
4、數據分析
數據分析一般包括兩個階段：數據預處理和數據建模分析。
數據預處理是為後面的建模分析做准備，主要工作時從海量數據中提取可用特徵，建立大寬表。這個過程可能會用到Hive SQL，Spark QL和Impala。
數據建模分析是針對預處理提取的特徵/數據建模，得到想要的結果。如前面所提到的，這一塊最好用的是Spark。常用的機器學習演算法，如樸素貝葉斯、邏輯回歸、決策樹、神經網路、TFIDF、協同過濾等，都已經在ML lib裡面，調用比較方便。
5、結果可視化及輸出API
可視化一般式對結果或部分原始數據做展示。一般有兩種情況，行熟悉展示，和列查找展示。在這里，要基於大數據平台做展示，會需要用到ElasticSearch和Hbase。Hbase提供快速『ms級別』的行查找。 ElasticSearch可以實現列索引，提供快速列查找。
平台搭建主要問題：
1、穩定性 Stability
理論上來說，穩定性是分布式系統最大的優勢，因為它可以通過多台機器做數據及程序運行備份以確保系統穩定。但也由於大數據平台部署於多台機器上，配置不合適，也可能成為最大的問題。 曾經遇到的一個問題是Hbase經常掛掉，主要原因是采購的硬碟質量較差。硬碟損壞有時會到導致Hbase同步出現問題，因而導致Hbase服務停止。由於硬碟質量較差，隔三差五會出現服務停止現象，耗費大量時間。結論：大數據平台相對於超算確實廉價，但是配置還是必須高於家用電腦的。
2、可擴展性 Scalability
如何快速擴展已有大數據平台，在其基礎上擴充新的機器是雲計算等領域應用的關鍵問題。在實際2B的應用中，有時需要增減機器來滿足新的需求。如何在保留原有功能的情況下，快速擴充平台是實際應用中的常見問題。
上述是自己項目實踐的總結。整個平台搭建過程耗時耗力，非一兩個人可以完成。一個小團隊要真正做到這些也需要耗費很長時間。
目前國內和國際上已有多家公司提供大數據平台搭建服務，國外有名的公司有Cloudera，Hortonworks，MapR等，國內也有華為、明略數據、星環等。另外有些公司如明略數據等還提供一體化的解決方案，尋求這些公司合作對 於入門級的大數據企業或沒有大數據分析能力的企業來說是最好的解決途徑。
對於一些本身體量較小或者目前數據量積累較少的公司，個人認為沒有必要搭建這一套系統，暫時先租用AWS和阿里雲就夠了。對於數據量大，但數據分析需求較簡單的公司，可以直接買Tableau，Splunk，HP Vertica，或者IBM DB2等軟體或服務即可。
-