大資料淺談1

大資料架構簡介

1.HDFS：伺服器的硬碟存儲空間交給HDFS去管理

2.YARN伺服器的CPU和記憶體交給YARN去管理（2x）

3.HBase：HBase分布式列式資料庫：支不支援transcation rollback，分布式不支援rollback，半實時資料庫（資料入庫，不一定能查的到，之前能查出來現在也不一定能查出來）

HBase優勢：滿足兩個條件（叢集足夠大-記憶體足夠大；查詢的條件是rowkey的精确比對；），不管查詢的資料量多大，時間都是毫秒級。
   HBase劣勢：對于程式設計和維護，比較頭疼。
   HBASE替代方案：1）redis，有資料壓力，不管是不是大資料，都可以使用redis（MongDB存在安全問題）
                     redis主要擔心問題，記憶體爆掉。需要手動幹預，寫記憶體清理規則。
                  2）Cassandra（性能）+kylin（用于查詢）：Kylin的限制-多張表做JOIN，最多支援到億級别。cassandra是一套開源分布式NoSQL資料庫系統;提升存儲性能。kylin是一個開源的分布式分析引擎，提供Hadoop/Spark之上的SQL查詢接口及多元分析（OLAP（聯機分析處理））能力以支援超大規模資料。
                  3）Kudu：适用于中小型企業；有HBase的好處，避開了HBase所有缺點。隻要符合sql标準，就可以在kudu上直接跑；可以直接把存在oracle和MySQL上的表拿到kudu上。注:如果想用一套叢集解決所有問題，就用kudu架構。
   美團是國内應用HBase最好的一家公司           

4.Batch（MapReduce)：一個作業涉及到40T資料以上，用MR（Spark經過優化後可以跑80T的資料，80T以上會有局限）

MR能做的事情：SQL03标準能做的，MR可做；分布式下已經實作的數學模型，MR也能做；           

5.Streaming(Storm,Flink,Spark streaming）

處理速度最快的是Storm，spark streaming抗壓性非常好。流對接時用storm           

6.In-Memory（Spark）：Spark是分布式記憶體計算，搭建Spark Server時，需要配記憶體和CPU。Spark的缺陷，CPU使用率不高（一個任務最多能使用70%）

執行個體：一億條資料，一個字段的模糊查詢+排序：關系型資料庫20min左右；Spark（20核20G記憶體），需8s2。           

7.Interacting（Tez）：對MR優化，業務較複雜，做一些複雜的存儲時，推進使用Tez

8.Pig被淘汰了

9.Hive：底層是MR，給不會大資料，又想玩大資料的人用的。給老DB人員使用的，能寫出高品質SQL+語義分析。

10.Mahout：資料模組化+AI使用，底層是MR，将MR的缺陷無限制的擴大，主要是注重底層的算法。

AI不是随便哪個企業都可以上，上了效果也會不佳。
          AI應用較實在的（使用者喜好比較假，成果大都不佳）：醫療方面-抗癌藥；
          AI招聘人才：以前要求-985數學系大學生；211/985數學相關專業的碩士、博士；其他人-中西方課程相結合（中-求答案；西-求過程和為什麼），把所有數學相關課程撿起來；
          AI薪資：30萬+，上不封頂；BAT年薪70~80萬；           

11.Flume：把遠端資料，安全拽到中心機房來；flume和kafka

12.Sqoop：底層是MR，Sqoop對Oracle的支援非常差，替代方案dataX(datax是阿裡雲開源的一個項目，是一個異構資料源離線同步工具)

13.Oozie：排程器

14.ZooKeeper：投票器，分布式鎖，協同；部署節點數按基數算，至少3個，用于保證投票。