根據我的觀察，大數據主要存在4大挑戰：
- 大數據中的數據挑戰
- 大數據中的管理挑戰
- 大數據中的分析挑戰
- 大數據中的運營挑戰
一、大數據中的數據挑戰
大數據中的數據挑戰泛指處理數據時必須解決的問題。哪里有大數據，哪里就有大問題。
當您處理一層或另一層數據時，您將需要一些特定的技能，讓我們深入了解它們。
1、數據存儲?
隨著存儲數據量的不斷增加，數據存儲問題歷來是第一位的。這是任何處理數據的系統的基礎——有許多技術可以存儲大量原始數據，這些數據來自傳統來源（如 OLTP 數據庫）和更新的、結構化程度較低的來源（如日志文件、傳感器、Web 分析、文檔檔案） 、媒體檔案等。正如你所看到的，這些是非常不同的領域，有自己的特點，我們需要從所有這些領域收集數據，以獲取有關整個系統的整體信息。
首先需要清楚使用哪種格式存儲數據，如何優化數據結構以及如何優化存儲數據。當然，在這里，您可以想到在大數據世界中非常常見的Parquet、CSV、Avro 格式。此外，可以考慮使用 Bzip2、Snappy、Lzo 等編解碼器。好吧，優化基本上要么是適當的分區，要么是做一些特定于存儲的事情。
使用Hadoop和HDFS構建該層的主要技術之一。它因其耐用性和傳統設備上的無限規模而廣受歡迎。但是，如今，越來越多的數據存儲在云中，或者至少存儲在混合解決方案中——組織正在從過時的本地存儲系統轉移到托管服務，例如 AWS S3、GCP GCS 或Azure Blobs。
對于 SQL 解決方案，流行的項目包括Hive、Apache Drill、Apache Impala、Apache Spark SQL和Presto。此外，還有更多有趣的數據倉庫解決方案，我認為它們位于簡單的 SQL 引擎之上。稍后我們將討論它們。
對于 NoSQL 解決方案，它可以是支持 ACID的Cassandra 、用于文檔數據模型和可管理數據大小的MongoDB ，或者如果您在 AWS 云中，它可以用于可擴展解決方案的AWS DynamoDB 。
對于圖形數據庫，我只能回憶起Neo4j。它非常適合存儲圖形數據或相關信息，例如一群人及其關系。在傳統的 SQL 數據庫中對此類信息進行數據建模是一件痛苦的事情，而且效率非常低。
2、數據湖?
數據湖是企業數據的集中存儲庫，允許存儲有關業務的所有結構化和非結構化數據。在這里，我們按原樣存儲數據，而不對其進行結構化，并在頂部運行不同類型的分析。
如今，數字化轉型實際上是將數據驅動的方法應用于業務的各個方面，以創造競爭優勢。這就是為什么越來越多的公司希望構建自己的數據湖解決方案。這種趨勢仍在繼續，并且仍然需要這些技能。
大多數情況下，Hadoop 發行版的供應商選擇可能由客戶驅動，這取決于他們的個人偏好、供應商的市場份額或現有的合作伙伴關系。用于本地集群的Hadoop分發供應商是Cloudera、Hortonworks、Mapr和BigInsights。本地被認為更安全。銀行、保險公司和醫療機構非常喜歡它，因為數據不會離開他們的場所。然而，在時間和精力方面，獲取和維護基礎設施將花費更多。
還有來自 AWS、GCP 和 Azure 的云存儲解決方案。與本地解決方案相比，云解決方案在可擴展性和即用型資源方面提供了更大的靈活性，但維護成本很高。
除此之外，還有一些數據平臺正在嘗試填補多個細分市場并創建集成解決方案，例如Apache Hudi、Delta Lake。
3、數據倉庫
數據倉庫可以描述為可用于分析和報告的有序數據存儲庫，旨在針對聚合請求進行優化。在任何情況下，它都是構建分析和數據驅動決策的基礎，就像 Data Lake 一樣，它們并不相互排斥，而是相互補充。
數據集市是數據倉庫解決方案的最后一層，旨在滿足特定業務功能的要求。它們從不同來源提取數據并將其提供給業務用戶的能力使它們成為數據倉庫領域的增長趨勢。
趨勢數據倉庫解決方案包括Teradata、Snowflake、BigQuery、AWS Redshift。
4、數據中心
有數據倉庫，其中信息被分類、排序并以最終結論的形式呈現（其余的被丟棄），還有數據湖——“把所有東西都丟在這里，因為你永遠不知道什么會有用”。數據中心專注于不屬于第一類或第二類的人。
數據中心架構允許您將數據留在原處，提供集中處理而不是存儲。數據在當前所在的位置被搜索和訪問。但是，由于數據中心是經過規劃和管理的，因此組織必須投入大量時間和精力來確定其數據的含義、數據來源以及必須完成哪些轉換才能將其放入數據中心。
數據中心是一種不同的存儲架構思考方式。我敢打賭，它在未來會引起一些關注——所有的支持部件今天都可用。
5、數據采集?
要創建數據存儲，您需要將來自各種來源的數據采集到數據層中，無論是數據湖還是數據倉庫，或者只是 HDFS。數據源可以是諸如 Salesforce 之類的 CRM、SAP 之類的企業資源規劃系統、PostgreSQL 之類的 RDBMS 或任何日志文件、文檔、社交網絡圖等系統。數據可以通過批處理作業或通過實時流上傳.
數據采集的工具有很多，最常見的一種是Sqoop。它提供了一個可擴展的基于 Java 的框架，可用于開發用于將數據導入 Hadoop 的驅動程序。Sqoop 在 Hadoop 中的 MapReduce 框架上運行，也可用于將數據從 Hadoop 導出到 RDBMS。
另一種常用工具是Flume。當輸入數據流的速度比使用速度快時使用它。通常，Flume 用于采集 HDFS 或 Kafka 中的數據流，它可以充當 Kafka 生產者。多個 Flume 代理也可用于將來自多個來源的數據收集到 Flume 收集器中。
另一個流行的工具是Nifi。Nifi 處理器是面向文件的，沒有模式。這意味著某些數據表示為 FlowFile（它可以是磁盤上的實際文件或在其他地方獲得的某些數據塊）。每個處理器負責了解數據內容以使用它們。因此，如果一個處理器理解格式 A，而另一個處理器只理解格式 B，則您可能必須在兩個處理器之間轉換數據格式。
消息總線世界中事實上的標準之一是Kafka——一種開源的流式消息傳遞總線，可以從您的數據源創建提要，對數據進行分區，并將其流式傳輸給消費者。Apache Kafka 是一種成熟且強大的解決方案，可大規模用于生產。
6、數據處理?
根據數據采集管道，數據被傳輸到數據層。現在，您需要能夠處理大量數據的技術來促進分析和處理這些數據。數據分析師和工程師希望針對需要巨大計算能力的大數據運行查詢。數據處理層必須優化數據以促進高效分析，并提供計算引擎來執行查詢。
計算機集群更適合滿足大數據管道的高計算需求。使用集群需要一個解決方案來管理集群成員、協調資源共享和調度工作節點上的實際工作。它可以由 Hadoop 的 YARN、Apache Mesos 或 Kubernetes 等軟件處理。
這一層最流行的模式是 ETL（Extract Transform Load）—— 一種流行的數據處理范式。本質上，我們從源中提取數據，對其進行清理，并將其轉換為我們上傳到目標數據庫、數據倉庫或數據湖的結構化信息。
成功實現此模式的工具之一是Apache Spark。這是最重要的大數據多功能工具之一，任何處理大量數據的人都應該掌握它。它對大型集群上的結構化或非結構化數據執行并行查詢和轉換。Spark 還提供了一個 SQL 接口，并具有良好的流式處理和內置的 ML 功能。
7、ETL 到 ELT?
目前，當轉換發生在數據倉庫內部而不是預先進行時，從 ETL 到 ELT 的轉變。在我看來，這是由于缺乏對數據的了解，因為傳統上對于必須進入數據倉庫以使其穩定并可供用戶訪問的內容有很多計劃和嚴格要求。然后是輸入數據格式、輸出結構格式等的變化。
Snowflake、AWS Redshift等工具允許在加載的數據（甚至是非結構化數據）上創建一個抽象層，從而在數據上提供一個簡單的 SQL API，而無需考慮字母 T。另一個支持所有 SQL 相關工作流的工具是dbt。
8、批量到實時?
現在很明顯，實時數據收集系統正在迅速取代批量 ETL，使流數據成為現實。越來越多的攝取和處理層都轉向實時，這反過來又促使我們學習新概念，使用可以進行批處理和實時處理的多功能工具，例如Spark和Flink。
9、內存數據計算?
由于內存變得更便宜并且企業依賴于實時結果，內存計算使他們能夠擁有更豐富、更具交互性的儀表板，這些儀表板可提供最新數據并幾乎可以立即進行報告。通過分析內存而不是硬盤驅動器中的數據，他們可以即時查看數據并迅速采取行動。
在大多數情況下，所有已知的解決方案都已經使用或嘗試使用這種方法。同樣，最容易理解的例子是Spark和Apache Ignite等數據網格的實現。
Apache Arrow將列式數據結構的優勢與內存計算相結合。它提供了這些現代技術的性能優勢，同時還提供了復雜數據和動態模式的靈活性。我實際上不知道任何其他這樣的格式。
二、大數據中的管理挑戰
另一個知識領域，基本上位于稍微不同的平面上，但與數據直接相關。管理挑戰涉及隱私、安全、治理和數據/元數據管理。
1、數據檢索?
數據檢索系統是一個算法網絡，有助于根據用戶需求搜索相關數據/文檔。
為了對大量數據執行有效的搜索，不建議執行簡單的掃描 - 然后會出現各種工具和解決方案。我看到的最常見的工具之一是ElasticSearch。它用于互聯網搜索、日志分析和大數據分析。ElasticSearch 更受歡迎，因為它易于安裝，無需任何額外軟件即可擴展到數百個節點，并且由于其內置的 REST API 易于使用。
此外，著名的工具還有Solr、Sphinx和Lucene。
2、數據治理?
數據治理是一種總稱，用于表示“我想控制我的數據”。這可能是大數據的重要領域之一，在我看來仍然被低估并且沒有好的解決方案。數據治理的目標是建立標準化、集成、保護和存儲數據的方法、職責和流程。如果沒有有效的數據治理，組織不同系統中的數據不一致將無法消除。這會使數據集成復雜化，并產生影響商業智能、企業報告和分析應用程序準確性的數據完整性問題。
我當然不是這個領域的專家，但我在這里看到的工具是Informatica、Talend、Semarchy。
3、數據安全?
由于數據保護水平跟不上數據、供應商和人員的增長，不斷增加的數據量給他們的入侵、泄漏和網絡攻擊防護帶來了額外的挑戰。全面的端到端保護不僅涉及在數據的整個生命周期（靜態和傳輸中）加密數據，還包括從項目一開始就對其進行保護。正如您所看到的，這會影響我們在本文中討論的所有方面，并且就像有關信息安全的所有內容一樣，很難做到正確。
GDPR、CCPA、LGPD 等隱私法的出現對不合規造成了嚴重后果。企業必須考慮數據的機密性。這些領域的專家的存在成為必要。
4、數據目錄?
通常，在公司內部，我們擁有大量不同形式、存儲方式、格式的數據，并具有不同程度的訪問權限。要查找數據，您需要確切地知道在哪里找到它或知道從哪里開始查找（如果有這樣的地方）。這就是所謂的數據目錄或數據目錄發揮作用的地方。
公司數據源的管理是一個基本過程，它基于公司內各種有限群體已知的信息。但是，收集有關存儲在組織內部的數據的所有元數據并進行管理并不容易——人們來來去去，數據被刪除和添加。因此，構建數據目錄是一項重要但復雜的任務。
三、大數據中的分析挑戰
分析和商業智能是一種用于制定數據驅動決策并提供可以幫助企業的信息的方法。使用此級別的技術，您可以啟動查詢以回答企業提出的問題、切片數據、構建儀表板并創建清晰的可視化。
有了更多數據，您就可以做出更準確的預測和更可靠的解決方案，并構建新的解決方案，在 ML 階梯上越爬越高。
1、機器學習?
機器學習，一種特定的分析方法，允許您創建可以分析大型復雜數據并做出預測或決策的模型，而無需明確編程。越來越多的組織使用 ML 方法來補充他們的日常運營分析和正常的業務運營。
過去，ML 在一定程度上受到數據科學家無法在數據工程師團隊將解決方案部署到生產環境之前對其進行評估和測試這一事實的限制。事實上，大多數組織都有一個傳統的 BI/分析團隊，其次是獨立的數據科學團隊和數據工程師團隊。這些技能組合現在已經開始重疊，隨著大數據緩慢地向分析和構建基于大數據的知識，這些團隊更加周到地合作。因為沒有機器學習的幫助，大數據太大了。因此，至少需要理解我認為的 ML 的基本概念。當然，應該特別注意它所依賴的東西，如統計、ML 方法優化方法、偏差/方差、要理解的不同指標（這實際上很重要）等。在應用機器學習中，你需要了解為什么一切正常，公式并不重要，但通常，那些不懂模型背后的語言的人會犯非常愚蠢的錯誤。
還有很多要說的，我下次再說。ML 里面有很多領域——NLP、CV、推薦系統、知識表示等，但是通常，當你至少理解了開始時，你已經理解了你不理解的東西，所以當然，你可以盡可能深入想。
如果您想成為一名機器學習工程師，請確保您了解Python。這是機器學習的通用語。然后值得學習了解用于處理數據的不同類型的框架，例如NumPy、Pandas、Dask和已經提到的Apache Spark。當然，還有最流行的 ML 庫：Scikit-Learn和XGBoost。
我認為每個人都明白，ML 中真正重要的方向長期以來一直與深度學習相關。經典算法當然不會去任何地方。在大多數情況下，它們足以制作一個好的模型，但未來當然在于神經網絡。深度學習的魔力在于它會隨著更多的數據而變得更好。另外，值得一提的是，可以在此處添加遷移學習、1cycle 策略、Cuda 和 GPU 優化等詞。
2、分布式機器學習
另一件值得一提的是分布式機器學習。正如我所說，大數據正在慢慢走向更復雜的大數據分析。存儲在中央存儲庫中的大型數據集需要巨大的處理和計算需求，因此分布式 ML 是正確的方向，盡管它存在很多問題。
我個人對這種方法很感興趣，但除了大公司之外，它對任何人都無關緊要。模型的準確性對他們來說非常重要，這只能通過創建具有數百萬個參數和大量數據的巨大模型來獲得。對于所有其他人，正如我所說，關于子集或預聚合數據的經典算法非常適合實際應用。
3、實時分析
雖然組織通常重視實時數據管理，但并非所有公司都對大數據進行實時分析。原因可能會有所不同——缺乏經驗或資金不足、擔心相關問題或管理層普遍不愿。然而，那些實施實時分析的公司將獲得競爭優勢。
這里的工具是Apache Spark Streaming、Apache Ignite Streaming、Apache Flink、AWS Kinesis。
4、數據科學自動化
為了以某種方式自動化數據預處理、特征工程、模型選擇和配置以及結果評估，發明了 AutoML。AutoML 可以自動執行這些任務，并且可以了解在哪里繼續研究。
當然，這聽起來很棒，但它的效果如何？這個問題的答案取決于你如何使用它。這是關于了解人們擅長的領域以及機器擅長的領域。人們善于將現有數據與現實世界聯系起來——他們了解業務領域，他們了解特定數據的含義。機器擅長計算統計數據、存儲和更新狀態，以及做重復的過程。探索性數據分析、數據預處理、超參數調整、模型選擇和將模型投入生產等任務可以通過自動化機器學習框架在一定程度上自動化，但良好的特征工程和得出可操作的見解可以通過人類數據來完成了解商業環境的科學家。通過分離這些活動，我們現在可以輕松地從 AutoML 中受益，
5、可視化和商業智能?
由于大數據系統中處理的信息類型，識別數據隨時間的趨勢或變化通常比值本身更重要。數據可視化是理解大量數據點的最有用的方法之一。它通過以易于理解的形式引導數據、突出趨勢和偏差來幫助講述故事。
通過 BI 將來自各種來源的未處理信息轉換為方便且易于理解的分析。BI 系統可以應用于任何行業或活動領域——在公司整體層面以及部門或單個產品層面。
最流行的可視化和 BI 工具，在我看來，除了上面描述的所有其他技術堆棧之外，還有Tableau、Looker、Microsoft Power BI、Qlik 。
Tableau 是一款功能強大的表格 BI 和數據可視化工具，可連接到數據并允許您執行詳細、全面的分析以及繪制圖表和儀表板。
Looker 是一個基于云的 BI 平臺，允許您在配置講述數據故事的可視化后，使用 SQL 定義的指標查詢和分析大量數據。
另一種常用于數據交互工作的可視化技術是“筆記本”。它們允許以促進共享、演示或協作的格式進行交互式研究和數據可視化。這種可視化界面的流行示例是Jupyter notebook、Apache Zeppelin和Polynote。
四、大數據中的運營挑戰
要解決其他帖子中描述的所有挑戰，您需要一個具有正確架構的基礎架構以及該基礎架構的正確管理、監控和供應環境。這不是我在本節中包含的全部內容——還包括管道編排和在數據管理的各個領域引入 DevOps 實踐。
1、微服務管理
微服務的建設早已成為一個解決的問題。一種或另一種方式，所有嚴肅的解決方案都建立在微服務架構上。這里有Docker容器、Kubernetes、Helm、Terraform、Vault、Consul以及它周圍的一切。這一切都成為了一個標準而沒有被注意到。
2、監控?
實時數據通常用于可視化應用程序和服務器指標。數據經常更改，指標中的大增量往往表明對系統或組織的健康狀況產生重大影響。在這些情況下，Prometheus等項目可用于處理數據流和時間序列數據可視化。
3、日志管理?
日志管理是處理由不同軟件應用程序及其運行的基礎設施生成的日志事件的過程。它可以包括日志的收集、分析、存儲和搜索，最終目標是使用數據進行故障排除和獲取業務、應用程序和基礎架構信息。
這里的重要工具之一是ELK，它由以下組件組成——Elasticsearch（文本搜索工具）、Logstash 和 Beats（數據發送工具）和 Kibana（數據可視化工具）。它們共同為實時數據分析提供了一個完整的工作工具。雖然它們都旨在協同工作，但它們每個都是一個單獨的項目。ELK 提供了報表創建、告警、日志搜索等在線分析功能。這使得它不僅是 DevOps 的通用工具，也是上述領域的通用工具。
另一種工具Splunk是一種機器數據工具，它使用戶、管理員和開發人員能夠立即接收和分析由應用程序、IT 基礎設施中的網絡設備以及任何其他機器數據創建的所有數據。Splunk 可以通過圖表、警報、報告等方式提供實時信息，從而接收機器數據并將其轉化為實時分析。
4、管道編排?
大多數大數據解決方案都包含封裝在工作流中的重復數據處理操作。管道編排工具有助于自動化這些工作流程。他們可以以容錯的方式計劃作業、執行工作流和協調任務之間的依賴關系。
我以前聽過 Oozie，現在主要是Airflow、Dagster、Prefect或AWS Step Functions。
5、云
在大數據中，很明顯，未來在于云，任何對數據管理感興趣的人都最好了解它的概念。除了在云級別應用的編程模式（Gateway API、Pub/Sub、Sidecars 等）之外，您還會遇到不同的概念，例如基礎架構即代碼、無服務器，當然還有架構概念（N 層、微服務、松散耦合等）。就個人而言，它讓我對更高層次的工程方法原理有了更深入的理解，并（一點）提升了架構方法。有GCP、AWS和Azure等云。我想沒有人會爭辯說沒有其他選擇。例如，您決定選擇 AWS，但所有云的設計方式都相同，盡管它們都有自己的特點，而且并非所有 CSP 服務都相互匹配。
6、數據/解決方案遷移?
從本地解決方案到云的數據遷移的集成和準備過程既復雜又耗時。除了遷移大量現有數據外，公司還必須在遷移完成前的幾周或幾個月內同步其數據源和平臺。除了遷移之外，企業正在準備災難恢復計劃，以便在不犧牲業務的情況下為任何事情做好準備，這里顯而易見的解決方案也是遷移到云。
7、MLOps?
我們的機器學習算法很好，但要取得好的結果確實需要一個由數據專家、數據工程師、現場專家和更多支持人員組成的龐大團隊。雖然專家的成本不夠約束，但我們的理解仍然很原始。最后，將模型投入生產并使其保持最新是最后一個障礙，因為模型創建的結果通常只能通過使用相同的用于學習的昂貴且復雜的架構來實現。應該理解，轉向生產是一個過程，而不是一個步驟，它在模型開發之前很久就開始了。它的第一步是定義業務目標、可以從數據中提取的價值假設以及應用的業務理念。
MLOps 是技術和 ML 流程以及在業務流程中實施已開發模型的方法的組合。這個概念是作為與 ML 模型和 ML 方法相關的 DevOps 的類比而出現的。通常，MLOps 系統包括用于收集和聚合數據、分析和準備用于 ML 建模的平臺、用于執行計算和分析的工具，以及用于在不同生命周期過程之間自動傳輸 ML 模型、數據和衍生軟件產品的工具。這種統一的管道部分或完全自動化了數據科學家、數據工程師、ML 工程師或大數據開發人員的工作任務。
我認為以下是最流行的 MLOps 工具：
- AWS SageMaker是一個基于云的機器學習平臺，允許開發人員在 AWS 云中創建、訓練和部署 ML 模型；
- Google 的Kubeflow for Kubernetes 是一個免費的開源機器學習平臺，用于在 Kubernetes 容器虛擬化環境中使用機器學習管道；
- MLFlow是一個開源平臺，用于管理機器學習的生命周期，包括實驗、復制、部署和 ML 模型的中央注冊表；
- Sacred是一個用于自動化 ML 實驗的工具，從跟蹤參數到保存配置和再現結果；
- DVC是一個類似于 Git 的開源版本控制系統，用于本地使用的 ML 項目。
除此之外，還有很多工具可以將 ML 模型投入生產，除了已經說過的之外，最受歡迎的工具我認為是TensorFlow Serving和Vowpal Wabbit。
結論
結果很多，似乎我什么也沒說。另請查看Tobias Macey 對 2021 年數據工程前景的采訪。
可用的產品太多。他們中的大多數聲稱可以解決您公司遇到的所有數據問題。但事實并非如此。
我不認為自己是所有方面的專家，只是在這里推測技術。但正如您從我的文章中所看到的那樣，許多技能在大數據的幾個領域重疊，并不止于此。有了他們，你就不會害怕找不到工作。
不要追逐趨勢——培養與時俱進的技能。最相關的技能可能是軟技能。
與大量數據工程活動相關的陡峭學習曲線變成了懸崖。開發人員的手工編碼項目需要對組織的許多方面以及大量工具和現有解決方案有深入的了解。
在數據管理方面，我們仍然處于狂野的西部，尤其是在 ML ...
