在降本增效的大環境下，人力資源和服務器資源都愈發的緊張，但人們對于數據獲取的需求卻在不斷的提高。大家期望可以查詢的速度更快，查詢的數據量更大，查詢的交互更友好，查詢工具的使用門檻更低......本文從大數據的起源講起，逐步講解到現在的大數據取數產品。

一、大數據起源

1.1、google論文發布

如果問存儲數據量最大的互聯網公司是哪家？那做搜索的Google應該是一個有力的競爭者。

作為一家搜索引擎公司，Google需要保存大量網頁數據，還要對海量的數據進行快速的搜索、計算、排名等處理。而在這個過程中，有大量的數據需要存儲和計算，所以Google內部研發出了對應的解決方案，并在2003年開始相繼公布了對應的技術解決方案，也就是開啟大數據工業時代的三駕馬車。

其中兩篇論文是：

• 于2003年發布《The Google File System》，用于處理海量網頁的存儲
• 于2004年 發布《MapReduce: Simplified Data Processing on Large Clusters》，可用于處理海量網頁的索引計算問題

這兩篇論文讓業界為之一振，這時突然大家恍然大悟，原來還可以這么玩。Google的思路是部署一個大規模的服務器集群，通過分布式的方式將海量數據分散的存儲在這個集群的不同節點上，然后再利用集群上的所有機器進行數據計算。 通過這種方式，Google其實不需要買很多很貴的服務器，而是把很多普通的服務器組織到一起，實現了更加強大的功能。

1.2、Hadoop誕生

Lucene（ES）創始人Doug Cutting閱讀了Google的論文后，他非常興奮，緊接著就根據論文原理初步實現了類似GFS和MapReduce的功能。這也就是后來的Hadoop，主要包括Hadoop分布式文件系統HDFS（Hadoop Distributed File System）和大數據計算引擎MapReduce。

1.2.1、HDFS

HDFS是一種分布式文件系統，用于存儲和管理大規模數據集的分布式存儲解決方案，通過目錄樹來定位文件。

HDFS的思想：

1、文件數據以數據塊的方式進行切分，數據塊可以存儲在集群任意服務器上，所以HDFS存儲的文件可以非常大。

2、DataNode存儲的數據塊會進行復制，使每個數據塊在集群里有多個備份，保證了數據的可靠性。

HDFS的目錄：

你看到的是一個文件系統而不是很多文件系統。比如你說我要獲取/hdfs/tmp/file1的數據，你引用的是一個文件路徑，但是實際的數據存放在很多不同的機器上。

1.2.2、MapReduce

MapReduce是一個分布式運算程序的編程框架，核心功能是將用戶編寫的業務邏輯代碼和自帶默認組件整合成一個完整的分布式運算程序，并發運行在一個Hadoop集群上。

MapReduce的思想：

這個模型既簡單又強大，簡單是因為它只包含Map和Reduce兩個過程，強大之處又在于它可以實現大數據領域幾乎所有的計算需求。我們用大數據里面的HolleWorld，也就是wordcount為例說明

代碼實現：

Map

Redece

1.3、一點思考

現在大家聽到分布式、大數據之類的詞，肯定一點兒也不陌生。

但如果我們回到03、04年，那時鵝廠剛才在香港上市，Facebook和支付寶都是剛剛創立，整個互聯網還處于懵懂時代。

大多數公司對數據處理的關注點其實還是聚焦在單機上，在思考如何提升單機的性能，尋找更貴更好的服務器，大家覺得一切都是那么順理成章。

如果回到那個時候，我們能不能跳出思維限制，給出其它方向的解決方案。

二、Hive

2.1、Hive的出現

MapReduce降低了大數據編程的難度，很多工程師都可以通過MapReduce開發大數據程序來進行數據獲取。

但是對于其他有大數據分析需求的人，比如數據分析師，他們對SQL更加熟悉，但是去編寫MapReduce程序還是有一定的學習成本。而且如果每次統計和分析都開發相應的MapReduce程序，人力成本也比較高。那么有沒有辦法進行優化，讓SQL直接運行在大數據平臺上呢？

這樣的產品一出現，瞬間把大數據取數的門檻大幅度降低，研發的效率提高的同時，用戶范圍也進一步擴大。

更進一步的，把這些SQL沉淀成模板后，一些愿意動手的業務人員也可以初步進行大數據分析。

2.2、一點思考

思路打開之后，各種類似的SQL引擎產品被設計了出來，例如執行在HBase上的SQL引擎。

有時兩個已經存在的東西做結合可以產生非常好的效果，例如人臉識別、掌紋和支付結合，功能機上疊加拍照，大模型和各種數據產品的結合等等。

三、指標庫表取數

雖然Hive降低了大數據分析的難度，讓更多的人可以參與的大數據的使用上，但很多業務人員有沒有數據相關基礎。那能不能有一種不需要有代碼基礎，明白業務邏輯就能使用的數據工具。這類分析工具很多公司都會做，大家的思路也基本類似。

3.1、交互邏輯

主要的產品交互模式就是基于拖拽或篩選的方式，對需要的指標和維度進行選擇后進行分析。本質其實就是引導用戶寫一條SQL，而用戶并不需要關注SQL的語法，進一步降低用戶使用的門檻。

火山：

指標支持自己配置和直接選擇已有指標，維度支持功能比較豐富

神策：

3.2、一點思考

1、對于一個工具類的產品，經常會面臨著易用性和靈活性的矛盾。如果設計的足夠靈活，這樣可以支持更多更復雜的情況，但往往也意味著使用門檻的提高，目標用戶的減少。

相反如果設計的足夠易用，雖然門檻低了，目標用戶多了，但很多情況支持不到，或者支持的不完整。在做產品設計的時候經常需要基于業務需求、實現成本、項目發展階段來進行設計。

2、如果我們進一步對指標和庫表取數在易用性上提升，那會是什么產品形態