作者：彭鋒 宋文欣 孫浩峰

來源：數(shù)倉寶貝庫

作為全局數(shù)據(jù)匯總及處理的核心功能，數(shù)據(jù)湖在數(shù)據(jù)中臺建設中必不可少。那么它與數(shù)據(jù)倉庫、數(shù)據(jù)中臺是什么關系？

圖10-1顯示了一個典型的從數(shù)據(jù)采集到數(shù)據(jù)湖、數(shù)據(jù)倉庫及數(shù)據(jù)集市，最后為數(shù)據(jù)應用提供服務的流程。可以看到，除了為數(shù)據(jù)倉庫提供原始數(shù)據(jù)之外，數(shù)據(jù)湖也可以直接為上層的數(shù)據(jù)應用提供服務。

與數(shù)據(jù)湖不同，數(shù)據(jù)倉庫是針對OLAP需求建設的數(shù)據(jù)庫，可以分析來自交易系統(tǒng)或不同業(yè)務部門的結構化數(shù)據(jù)。數(shù)據(jù)倉庫中的數(shù)據(jù)由原始數(shù)據(jù)經過清理、填充和轉換后按照核心業(yè)務邏輯組織生成。數(shù)據(jù)倉庫一般必須預先定義好數(shù)據(jù)庫Schema，重點是實現(xiàn)更快的SQL驅動的深度報告和分析。

▲圖10-1 從數(shù)據(jù)采集到提供數(shù)據(jù)服務的流程

01?數(shù)據(jù)湖的起源與作用

數(shù)據(jù)湖的出現(xiàn)主要是為了解決存儲全域原始數(shù)據(jù)的問題。在捕獲來自業(yè)務應用程序、移動應用程序、IoT設備和互聯(lián)網的結構化和非結構化數(shù)據(jù)時，實際上并沒有預先定義好數(shù)據(jù)結構，這意味著可以先存儲數(shù)據(jù)而無須進行精心設計，也無須明確要進行什么分析，由數(shù)據(jù)科學家和數(shù)據(jù)工程師在后續(xù)工作中探索和嘗試。

這個改動極大推動了大數(shù)據(jù)的發(fā)展，早期大數(shù)據(jù)系統(tǒng)的一大吸引力是能夠存儲大量日志數(shù)據(jù)供后期探索，很多大數(shù)據(jù)應用就是在大數(shù)據(jù)系統(tǒng)將數(shù)據(jù)采集上來之后才出現(xiàn)的。

為什么一定要單獨建立數(shù)據(jù)湖呢？要回答這個問題，我們先來了解數(shù)據(jù)湖的一個重要組成部分——ODS（Operating Data Store，運營數(shù)據(jù)存儲）。

在20世紀90年代數(shù)據(jù)倉庫剛出來的時候，就已經有ODS了。可以說ODS是數(shù)據(jù)湖的先行者，因為ODS和數(shù)據(jù)湖有兩個共同的重要特征：不加轉換的原始數(shù)據(jù)，可以進行不預先設置的分析。

ODS一般用來存儲業(yè)務運營數(shù)據(jù)，也就是OLTP（聯(lián)機事務處理）數(shù)據(jù)的快照和歷史，而數(shù)據(jù)倉庫一般用來存儲分析數(shù)據(jù)，對應OLAP（聯(lián)機分析處理）需求。表10-1列出了OLTP和OLAP的一些區(qū)別。

▼表10-1 OLTP和OLAP的區(qū)別

絕大多數(shù)情況下，業(yè)務數(shù)據(jù)庫的SQL庫表的結構與數(shù)據(jù)倉庫的結構是不一樣的：業(yè)務數(shù)據(jù)庫是為OLTP設計的，是系統(tǒng)實時狀態(tài)的數(shù)據(jù)；而數(shù)據(jù)倉庫的數(shù)據(jù)是為OLAP的需求建設的，是為了深度的多維度分析。這個差異造成基于數(shù)據(jù)倉庫的數(shù)據(jù)分析受到以下限制：

• 數(shù)據(jù)倉庫的架構設計是事先定好的，很難做到全面覆蓋，因此基于數(shù)據(jù)倉庫的分析是受到事先定義的分析目標及數(shù)據(jù)庫Schema限制的；

• 從OLTP的實時狀態(tài)到OLAP的分析數(shù)據(jù)的轉換中會有不少信息損失，例如某個賬戶在某個具體時間點的余額，在OLTP系統(tǒng)里一般只存儲最新的值，在OLAP系統(tǒng)里只會存儲對賬戶操作的交易，一般不會專門存儲歷史余額，這就使得進行基于歷史余額的分析非常困難。

因此，在建立數(shù)據(jù)倉庫的時候，我們必須先將OLTP數(shù)據(jù)導入ODS，然后在ODS上進行ETL操作，生成便于分析的數(shù)據(jù)，最后將其導入數(shù)據(jù)倉庫。這也是為什么ODS有時也被稱為數(shù)據(jù)準備區(qū)（staging area）。

隨著Hadoop的逐漸普及，大家發(fā)現(xiàn)數(shù)據(jù)倉庫底層的技術（關系型數(shù)據(jù)庫）無法處理一些非結構化數(shù)據(jù)，最典型的就是服務器日志包含的數(shù)據(jù)。除了這些分析上的功能缺陷之外，傳統(tǒng)數(shù)據(jù)倉庫底層使用的關系型數(shù)據(jù)庫在處理能力上有很大局限，這也是數(shù)據(jù)湖，直至整個大數(shù)據(jù)生態(tài)出現(xiàn)的一個主要原因。

在Hadoop出現(xiàn)之前，就有Teradata和Vertica等公司試圖使用MPP（Massively Parallel Processing，大規(guī)模并行處理）數(shù)據(jù)庫技術來解決數(shù)據(jù)倉庫的性能問題。在Hadoop出現(xiàn)之后，Hive成為一個比較廉價的數(shù)據(jù)倉庫實現(xiàn)方式，也出現(xiàn)了Presto、Impala這些SQL-on-Hadoop的開源MPP系統(tǒng)。

從2010年開始，業(yè)界逐漸將ODS、采集的日志以及其他存放在Hadoop上的非結構或半結構化數(shù)據(jù)統(tǒng)稱為數(shù)據(jù)湖。有時，數(shù)據(jù)湖中直接存儲源數(shù)據(jù)副本的部分（包括ODS和日志存儲）被稱為貼源數(shù)據(jù)層，意思是原始數(shù)據(jù)的最直接副本。

從根本上來講，數(shù)據(jù)湖的最主要目標是盡可能保持業(yè)務的可還原度。例如，在處理業(yè)務交易的時候，數(shù)據(jù)湖不僅會把OLTP業(yè)務數(shù)據(jù)庫的交易記錄采集到數(shù)據(jù)湖中的ODS，也會把產生這筆交易的相關服務器日志采集到數(shù)據(jù)湖的HDFS文件系統(tǒng)中，有時還會把發(fā)回給客戶的交易憑證作為文檔數(shù)據(jù)存放。

這樣，在分析與這筆交易相關的信息時，系統(tǒng)能夠知道這筆交易產生的渠道（從服務器分析出來的訪問路徑），給客戶的憑證是否有不合理的數(shù)據(jù)格式（因為憑證的格式很多時候是可以動態(tài)變化的）。

02 數(shù)據(jù)湖建設的4個目標

數(shù)據(jù)湖的建設方式有很多種，有的企業(yè)使用以Hadoop為核心的數(shù)據(jù)湖實現(xiàn)，有的企業(yè)以MPP為核心加上一些對象存儲來實現(xiàn)。雖然建設方式不同，但是它們建設數(shù)據(jù)湖的目標是一致的，主要有以下4點。

高效采集和存儲盡可能多的數(shù)據(jù)。將盡可能多的有用數(shù)據(jù)存放在數(shù)據(jù)湖中，為后續(xù)的數(shù)據(jù)分析和業(yè)務迭代做準備。一般來說，這里的“有用數(shù)據(jù)”就是指能夠提高業(yè)務還原度的數(shù)據(jù)。

對數(shù)據(jù)倉庫的支持。數(shù)據(jù)湖可以看作數(shù)據(jù)倉庫的主要數(shù)據(jù)來源。業(yè)務用戶需要高性能的數(shù)據(jù)湖來對PB級數(shù)據(jù)運行復雜的SQL查詢，以返回復雜的分析輸出。

數(shù)據(jù)探索、發(fā)現(xiàn)和共享。允許高效、自由、基于數(shù)據(jù)湖的數(shù)據(jù)探索、發(fā)現(xiàn)和共享。在很多情況下，數(shù)據(jù)工程師和數(shù)據(jù)分析師需要運行SQL查詢來分析海量數(shù)據(jù)湖數(shù)據(jù)。諸如Hive、Presto、Impala之類的工具使用數(shù)據(jù)目錄來構建友好的SQL邏輯架構，以查詢存儲在選定格式文件中的基礎數(shù)據(jù)。這允許直接在數(shù)據(jù)文件中查詢結構化和非結構化數(shù)據(jù)。

機器學習。數(shù)據(jù)科學家通常需要對龐大的數(shù)據(jù)集運行機器學習算法以進行預測。數(shù)據(jù)湖提供對企業(yè)范圍數(shù)據(jù)的訪問，以便于用戶通過探索和挖掘數(shù)據(jù)來獲取業(yè)務洞見。

基于這幾個目標，數(shù)據(jù)湖必須支持以下特性。

• 數(shù)據(jù)源的全面性：數(shù)據(jù)湖應該能夠從任何來源高速、高效地收集數(shù)據(jù)，幫助執(zhí)行完整而深入的數(shù)據(jù)分析。

• 數(shù)據(jù)可訪問性：以安全授權的方式支持組織/部門范圍內的數(shù)據(jù)訪問，包括數(shù)據(jù)專業(yè)人員和企業(yè)等的訪問，而不受IT部門的束縛。

• 數(shù)據(jù)及時性和正確性：數(shù)據(jù)很重要，但前提是及時接收正確的數(shù)據(jù)。所有用戶都有一個有效的時間窗口，在此期間正確的信息會影響他們的決策。

• 工具的多樣性：借助組織范圍的數(shù)據(jù)，數(shù)據(jù)湖應使用戶能夠使用所需的工具集構建其報告和模型。

03 數(shù)據(jù)湖數(shù)據(jù)的采集和存儲

數(shù)據(jù)采集系統(tǒng)負責將原始數(shù)據(jù)從源頭采集到數(shù)據(jù)湖中。數(shù)據(jù)湖中主要采集如下數(shù)據(jù)。

1. ODS

存儲來自各業(yè)務系統(tǒng)（生產系統(tǒng)）的原始數(shù)據(jù)，一般以定時快照的方式從生產數(shù)據(jù)庫中采集，或者采用變化數(shù)據(jù)捕獲（Change Data Capture，CDC）的方式從數(shù)據(jù)庫日志中采集。

后者稍微復雜一些，但是可以減少數(shù)據(jù)庫服務器的負載，達到更好的實時性。在從生產數(shù)據(jù)庫中采集的時候，建議設置主從集群并從從庫中采集，以避免造成對生產數(shù)據(jù)庫的性能影響。

2. 服務器日志

系統(tǒng)中各個服務器產生的各種事件日志。典型例子是互聯(lián)網服務器的日志，其中包含頁面請求的歷史記錄，如客戶端IP地址、請求日期/ 時間、請求的網頁、HTTP代碼、提供的字節(jié)數(shù)、用戶代理、引用地址等。

這些數(shù)據(jù)可能都在一個文件中，也可能分隔成不同的日志，如訪問日志、錯誤日志、引薦者日志等。我們通常會將各個業(yè)務應用的日志不加改動地采集到數(shù)據(jù)湖中。

3. 動態(tài)數(shù)據(jù)

有些動態(tài)產生的數(shù)據(jù)不在業(yè)務系統(tǒng)中，例如為客戶動態(tài)產生的推薦產品、客戶行為的埋點數(shù)據(jù)等。這些數(shù)據(jù)有時在服務器日志中，但更多的時候要以獨立的數(shù)據(jù)表或Web Service的方式進行采集。

埋點是數(shù)據(jù)采集領域（尤其是用戶行為數(shù)據(jù)采集領域）的術語，指的是對特定用戶行為或事件進行捕獲、處理和發(fā)送的相關技術及其實施過程，比如用戶點擊某個圖標的次數(shù)、觀看某個視頻的時長等。

埋點是用戶行為分析中非常重要的環(huán)節(jié)，決定了數(shù)據(jù)的廣度、深度、質量，能影響后續(xù)所有的環(huán)節(jié)。因此，這部分埋點數(shù)據(jù)應該采集到數(shù)據(jù)湖中。

4. 第三方數(shù)據(jù)

從第三方獲得的數(shù)據(jù)，例如用戶的征信數(shù)據(jù)、廣告投放的用戶行為數(shù)據(jù)、應用商店的下載數(shù)據(jù)等。

采集這些原始數(shù)據(jù)的常見方式如下。

• 傳統(tǒng)數(shù)據(jù)庫數(shù)據(jù)采集：數(shù)據(jù)庫采集是通過Sqoop或DataX等采集工具，將數(shù)據(jù)庫中的數(shù)據(jù)上傳到Hadoop的分布式文件系統(tǒng)中，并創(chuàng)建對應的Hive表的過程。數(shù)據(jù)庫采集分為全量采集和增量采集，全量采集是一次性將某個源表中的數(shù)據(jù)全部采集過來，增量采集是定時從源表中采集新數(shù)據(jù)。

• Kafka實時數(shù)據(jù)采集：Web服務的數(shù)據(jù)常常會寫入Kafka，通過Kafka快速高效地傳輸?shù)紿adoop中。由Confluent開源的Kafka Connect架構能很方便地支持將Kafka中的數(shù)據(jù)傳輸?shù)紿ive表中。

• 日志文件采集：對于日志文件，通常會采用Flume或Logstash來采集。

• 爬蟲程序采集：很多網頁數(shù)據(jù)需要編寫爬蟲程序模擬登錄并進行頁面分析來獲取。

• Web Service數(shù)據(jù)采集：有的數(shù)據(jù)提供商會提供基于HTTP的數(shù)據(jù)接口，用戶需要編寫程序來訪問這些接口以持續(xù)獲取數(shù)據(jù)。

數(shù)據(jù)湖需要支持海量異構數(shù)據(jù)的存儲。下面是一些常見的存儲系統(tǒng)及其適用的數(shù)據(jù)類型。

• HDFS：一般用來存儲日志數(shù)據(jù)和作為通用文件系統(tǒng)。

• Hive：一般用來存儲ODS和導入的關系型數(shù)據(jù)。

• 鍵-值存儲（Key-value Store）：例如Cassandra、HBase、ClickHouse等，適合對性能和可擴展性有要求的加載和查詢場景，如物聯(lián)網、用戶推薦和個性化引擎等。

• 文檔數(shù)據(jù)庫（Document Store）：例如MongoDB、Couchbase等，適合對數(shù)據(jù)存儲有擴展性要求的場景，如處理游戲賬號、票務及實時天氣警報等。

• 圖數(shù)據(jù)庫（Graph Store）：例如Neo4j、JanusGraph等，用于在處理大型數(shù)據(jù)集時建立數(shù)據(jù)關系并提供快速查詢，如進行相關商品的推薦和促銷，建立社交圖譜以增強內容個性化等。

• 對象存儲（Object Store）：例如Ceph、Amazon S3等，適合更新變動較少的對象文件數(shù)據(jù)、沒有目錄結構的文件和不能直接打開或修改的文件，如圖片存儲、視頻存儲等。

一般來講，數(shù)據(jù)湖的存儲應該支持以下特性。

1. 可擴展性

企業(yè)數(shù)據(jù)湖充當整個組織或部門數(shù)據(jù)的集中數(shù)據(jù)存儲，它必須能夠彈性擴展。注意，雖然云原生架構比較容易支持彈性擴展，但是數(shù)據(jù)中心都會有空間和電力限制，準備建設大規(guī)模數(shù)據(jù)湖的企業(yè)需要考慮多數(shù)據(jù)中心或混合云的架構，否則就會陷入幾年就要“搬家”的窘境。

2. 數(shù)據(jù)高可用性

數(shù)據(jù)的及時性和持續(xù)可用性是輔助決策制定的關鍵，因此必須使用HDFS、Ceph、GlusterFS等支持多備份、分布式高可用的架構。

3. 高效的存儲效率

數(shù)據(jù)湖的數(shù)據(jù)量是以PB計的，而且因為需要多備份（3份或更多），其存儲效率就非常重要。例如，使用LZO壓縮存儲HDFS文件可以達到1∶6甚至1∶7的壓縮比例，而且可以通過系統(tǒng)支持實現(xiàn)透明訪問，也就是說，程序可以直接使用數(shù)據(jù)而無須先展開到臨時空間。

另外，列式存儲也是一種常用的利于壓縮的存儲方式。存儲效率越高，意味著需要的服務器越少，使用的電量越少，擴容的時間間隔越長，因此存儲效率對數(shù)據(jù)湖的運營非常重要。

4. 數(shù)據(jù)持久性

數(shù)據(jù)一旦存儲，就不能因為磁盤、設備、災難或任何其他因素而丟失。除了使用分布式架構，一般還需要考慮多數(shù)據(jù)中心和混合云架構支持的異地備份。

5. 安全性

對于本地和基于云的企業(yè)數(shù)據(jù)湖來說，安全都是至關重要的，應將其放在首位。

例如，數(shù)據(jù)必須經過加密，必須不可變（在任何需要的地方），并且必須符合行業(yè)標準；數(shù)據(jù)系統(tǒng)的訪問必須支持端到端的授權和鑒權集成等。應該從剛開始建設數(shù)據(jù)湖時就進行安全性的設計，并將其納入基本的體系結構和設計中。只有在企業(yè)整體安全基礎架構和控件的框架內部署和管理，數(shù)據(jù)湖的安全性才有保障。

6. 治理和審計

要能夠應用治理規(guī)則及數(shù)據(jù)不變性，識別用戶隱私數(shù)據(jù)以及提供完整的數(shù)據(jù)使用審計日志的能力，這對于滿足法規(guī)和法定要求至關重要。

7. 可以存儲任何內容

數(shù)據(jù)湖在設計之初，有一個主要考慮的因素：存儲任何格式（結構化和非結構化）的數(shù)據(jù)并提供快速檢索。當然，這里的“快速”并不是說要像面向用戶的系統(tǒng)一樣提供實時響應，在數(shù)據(jù)湖上運行的應用對交互的要求會低一些。即便如此，Presto、Impala等SQL-on-Hadoop的解決方案正在逐步提高數(shù)據(jù)湖的交互體驗。

8. 可以支持不同存儲文件的大小和格式

在很多場景中，系統(tǒng)需要存儲很多小文件，這些文件的尺寸遠小于Hadoop文件系統(tǒng)（HDFS）的默認塊大小128MB。在基于Hadoop的框架中，每個文件在集群的名稱節(jié)點的內存中均表示為一個對象，每個對象通常占用150B。這意味著大量文件將消耗大量內存。

因此，大多數(shù)基于Hadoop的框架無法有效使用小文件。另一個重要方面是文件的格式，例如使用列存儲（ORC和Parquet）可以加大文件的壓縮比例，在讀取時僅解壓縮和處理當前查詢所需的值，這樣可以大大減少磁盤I/O和查詢時間。

04 數(shù)據(jù)湖中的數(shù)據(jù)治理

很多人認為數(shù)據(jù)湖中存儲的是原始數(shù)據(jù)，不需要治理，這其實是個誤區(qū)。確切地說，數(shù)據(jù)湖存儲的是未經轉換的數(shù)據(jù)，任何需要支持分析的數(shù)據(jù)都是需要治理的。數(shù)據(jù)治理是指對企業(yè)中數(shù)據(jù)的可用性、完整性和安全性的全面管理，具體內容主要取決于企業(yè)的業(yè)務策略和技術實踐。

比如，我們可以要求寫入數(shù)據(jù)湖的ODS數(shù)據(jù)經過Schema的檢查，確保業(yè)務系統(tǒng)Schema的改變不會未經協(xié)調就進入數(shù)據(jù)湖，造成現(xiàn)有數(shù)據(jù)湖應用的失效。

再比如合規(guī)的要求，數(shù)據(jù)湖負責全域數(shù)據(jù)采集，其中往往包括消費者的個人可識別信息。這些敏感數(shù)據(jù)必須經過合規(guī)處理，以確保系統(tǒng)遵守隱私法律和法規(guī)。因此，從最開始就應將數(shù)據(jù)治理納入數(shù)據(jù)湖的設計中，至少應采用最低的治理標準。

數(shù)據(jù)湖中的數(shù)據(jù)治理主要涵蓋以下領域。

1. 數(shù)據(jù)目錄

由于數(shù)據(jù)湖中存儲的數(shù)據(jù)量非常大，因此很難跟蹤有哪些數(shù)據(jù)可用，而且數(shù)據(jù)容易被淹沒。解決方案是維護數(shù)據(jù)目錄。數(shù)據(jù)目錄是元數(shù)據(jù)的集合，結合了數(shù)據(jù)管理和搜索工具，可幫助分析師和其他用戶查找數(shù)據(jù)。數(shù)據(jù)目錄充當可用數(shù)據(jù)的清單，并提供信息以評估適用數(shù)據(jù)的預期用途。

最有效的方法是維護中央數(shù)據(jù)目錄，并在各種處理框架（如Hadoop、Spark以及其他可用工具）中使用，這樣可以應用簡單的數(shù)據(jù)治理規(guī)則來確保元數(shù)據(jù)的完整性。

2. 數(shù)據(jù)質量

數(shù)據(jù)質量系統(tǒng)應該確保數(shù)據(jù)的完整性、準確性、一致性以及標準化，否則基于數(shù)據(jù)得出的結果是不可靠的，所謂的“垃圾進，垃圾出”（Garbage In, Garbage Out）就是這個意思。現(xiàn)在并沒有一個通用的數(shù)據(jù)質量管理系統(tǒng)適用于數(shù)據(jù)湖，但是類似于Delta Lake這樣的項目已經在探索如何解決這些問題。

3. 數(shù)據(jù)合規(guī)

根據(jù)所運營的業(yè)務領域，數(shù)據(jù)湖必須滿足一些合規(guī)要求，例如GDPR（《通用數(shù)據(jù)保護條例》）、HIPAA（《健康保險便利和責任法案》）和ISO等標準和規(guī)范。對于很多企業(yè)而言，數(shù)據(jù)合規(guī)是很重要的工作，數(shù)據(jù)合規(guī)一旦出問題，可能導致巨額罰款或者數(shù)據(jù)泄露，損害企業(yè)的信譽。

關于作者：彭鋒，智領云科技聯(lián)合創(chuàng)始人兼CEO。武漢大學計算機系本科及碩士，美國馬里蘭大學計算機專業(yè)博士，主要研究方向是流式半結構化數(shù)據(jù)的高性能查詢引擎，在數(shù)據(jù)庫頂級會議和期刊SIGMOD、ICDE、TODS上發(fā)表多篇開創(chuàng)性論文。2011年加入Twitter，任大數(shù)據(jù)平臺主任工程師、公司架構師委員會大數(shù)據(jù)負責人，負責公司大數(shù)據(jù)平臺及流水線的建設和管理。

宋文欣，智領云科技聯(lián)合創(chuàng)始人兼CTO。武漢大學計算機系本科及碩士，美國紐約州立大學石溪分校計算機專業(yè)博士。曾先后就職于Ask.com和EA（電子藝界）。2016年回國聯(lián)合創(chuàng)立智領云科技有限公司，組建智領云技術團隊，開發(fā)了BDOS大數(shù)據(jù)平臺操作系統(tǒng)。

孫浩峰，智領云科技市場總監(jiān)。前CSDN內容運營副總編，關注云計算、大數(shù)據(jù)、人工智能、區(qū)塊鏈等技術領域，對云計算、網絡技術、網絡存儲有深刻認識。擁有豐富的媒體從業(yè)經驗和專業(yè)的網絡安全技術功底，具有超過15年的企業(yè)級IT市場傳播、推廣、宣傳和寫作經驗，撰寫過多篇在業(yè)界具有一定影響力的文章。

本文摘編自《云原生數(shù)據(jù)中臺：架構、方法論與實踐》，經出版方授權發(fā)布。

延伸閱讀《云原生數(shù)據(jù)中臺：架構、方法論與實踐》

點擊上圖了解及購買

轉載請聯(lián)系微信：DoctorData

推薦語：前Twitter大數(shù)據(jù)平臺主任工程師撰寫，融合硅谷與國內經驗，全面講解云原生數(shù)據(jù)中臺架構、選型、方法論、實施路徑，國內外專家聯(lián)袂推薦。

劃重點👇

干貨直達👇

• 什么是物聯(lián)網？有哪些應用？終于有人講明白了
  

• 終于有人把云原生講明白了
  

• 為什么你一直在寫bug？原因找到了
  

• 吐血整理：人工智能、機器學習領域13個常見概念

更多精彩👇

在公眾號對話框輸入以下關鍵詞

查看更多優(yōu)質內容！

讀書?|?書單?|?干貨?|?講明白?|?神操作?|?手把手

大數(shù)據(jù)?|?云計算?|?數(shù)據(jù)庫?|?Python?|?爬蟲?|?可視化

AI?|?人工智能?|?機器學習?|?深度學習?|?NLP

5G?|?中臺?|?用戶畫像?|?數(shù)學?|?算法?|?數(shù)字孿生

據(jù)統(tǒng)計，99%的大咖都關注了這個公眾號

👇

總結

以上是生活随笔為你收集整理的终于有人把数据湖讲明白了的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。