大多樣性意味著試圖處理來自極多資料來源的資料，造成了資料整合方面的巨大挑戰。我集中考慮結構性資料的整合，由其他人考慮文字資料的整合。
上世紀九十年代，在巨型零售商的帶領下，大多數大型企業建立了“企業資料倉儲”。這些倉庫含有貨品級的銷售歷史資料，供產品經理查詢。實際上，其目的是確定哪些商品開始流行（如芭比娃娃）、哪些商品過時了（如寵物石）。芭比娃娃就被搬到商店前端促銷、寵物石則被快速下架。零售商發現，因存貨週轉和採購決策改善，銷售資料倉儲不到一年就收回了成本。大多數大型企業步零售商後塵，建立了銷售及客戶資料倉儲。此類倉庫一般整合了最多十餘個資料來源，成為ETL（萃取、轉換、載入）供應商的焦點。湧現出的ETL方法論是：
對每個需要整合的資料來源 {
分派一位程式設計師去理解該資料來源（透過與人交談、讀文件等）.
程式設計師用指令碼語言寫程式來從資料來源提取資料
程式設計師弄清如何把該區域性資料來源對映到預先定義的全域性模式（schema）
程式設計師編寫任何所需的資料清理及/或轉換程式
}
這一極其廣泛採用的方法論具有若干劣勢：
全域性模式也許事前並不存在。在我熟悉的一個用例中，一個大型製藥公司意圖把幾千位溼法化學師和生物學家的電子實驗記錄本整合。全域性資料模式必須透過組合區域性模式拼起來。故全域性模式是整合的副產品、而不是一開始就有的。
編寫轉換程式也許很難（甚至不可能）。例如，來自巴黎的區域性資料來源中的“薪金”屬性也許是指某人的稅後歐元工資、包括午餐費。這些語義也許在任何資料字典中都查不到。如此，程式設計師在理解區域性資料來源屬性時會步履艱難。
資料清理程式編寫也許極其困難。例如，很難確定兩個不同的餐館共用一個地址是有效的（如美食廣場）、還是其中一個已經破產被另一個所取代了。
資料整合無法一次完成。所有資料模式、轉換、對映也許會依時間而變化、依區域性資料來源更新而變化。這些要素每月即有變化也並非罕見。
此方法論不具備規模效應。因為許多步驟都靠人力，整個過程規模擴大到幾十個區域性資料來源之後，成本就變得難以承受了。
鑑於大資料的全部理念就在於規模效應，本帖的其餘部分將專注於上述第5條。
我聽說過若干企業把資料整合視為頭等大事。一般而言，大多數都在幾年前投資於資料倉儲，將銷售、客戶、或產品資訊整合成了組合式的資料庫。然而，絕大多數均面臨這個小故事中所顯示的難題。
九十年代晚期我到訪一家大啤酒公司，該公司有個傳統的資料倉儲，存的是銷售資訊，以分銷商、品牌、時間段分類。當時，氣候預報稱將有一個“厄爾尼諾”冬季，即是說，預測西海岸的降雨量和東北地區的溫度均高於常態。我問該公司的商業智慧（BI）員工：“您認為啤酒銷售與溫度或降雨量有關聯嗎？”他們回應說，能找到答案就太棒了，但不幸地是，資料倉儲裡沒有氣候資料。
實際上，業務分析師想透過新資料來源關聯企業資料以期獲得商業洞察力，這一胃口是無法滿足的。一個典型的企業具有5,000以上操作型資料來源，部分涉及對業務的深入瞭解。再者，很多企業的財務資料存於電子表格，也許在財務總監的膝上型電腦中。最後，網際網路上有公開資料來源的金礦（例如氣候資料）。最終結果是，業務分析師施壓要求整合越來越多的資料來源，從而造成了日益艱難的資料整合問題。
新業務需求也將經常產生相同的壓力，例如企業部門產品間的交叉銷售、透過對網站會話中網民的進一步瞭解以改進廣告投放。一個案例是車險行業，該行業正處於把“大規模個性化”用於保險費率的過程。該過程十年前由Progressive保險公司啟動，即在車內安裝感測器、獎勵駕車者的安全駕駛行為。此概念正被推廣到包括駕駛的時間與地點及其他資訊（信用級別、近期生活變化等）。同樣地，新業務需求決定了資料整合相當困難。
本帖其餘部分是我對規模化資料整合的若干建議。
人工干預：首先，傳統方法論的規模可達到幾十個資料來源，但不可能把規模擴大到幾百個、上千個。欲使規模擴大，傳統的方法論不得不讓位於機器學習和統計學以自動“摘取低懸的水果”（譯註：成語，避難就易的意思）。只是在自動演算法失敗時才應人工干預。本人在CIDR '13的論文介紹了此方法的一種策略，可供參閱。
轉換：第二，以程式設計師編寫轉換（transformation）程式絕不可能有規模效應。替代方案是，簡單的轉換應透過自動猜測實現，較複雜的則應採用“所見即所得”（WHYSWIG）式介面供非程式設計師完成。此方向一個好的起點是採用史丹佛大學的軟體Data Wrangler（vis.stanford.edu/wrangler）。只是最複雜的轉換才應需要程式設計師。儘管大部分專有ETL框架具有轉換庫，但是，為轉換建一個不涉及軟體特許權的公共目錄，會是極其有益的服務。我猜測，因為程式設計師找不到已有的轉換版本，故不得不從零開始編寫、重複勞動。
實體合併：其最簡單的例項是資料去除冗餘。然而，在大多數情況下，資料來源對同一實體（entity）所含有的資訊不盡相同，故需要一個合併（consolidation）階段。合併可以是特定領域的（例如英語姓名或公司名稱），也可以是通用的（例如只在屬性空間中尋找記錄叢集）。所有低懸的水果均應由自動演算法摘取，人工干預只用於複雜的情形。
清理：據推測採用“所見既所得”式的清理工具（例如DbWipes，www.mit.edu/~eugenewu/files/papers/dbwipes-vldb2012.pdf/）可獲益良多。我預期將有許多具備大量視覺化元件的好理念出現。
進一步說，當同一個實體（例如名為“紅龍蝦”的餐館）出自多個資料來源時，一些清理工作可在實體合併時自動啟動。假如自動演算法確認同一個實體列在了不同的地址裡或具有不同的電話號碼，那麼資料更正可自動執行。
由於任何自動系統都難免發生錯誤，應該建立處理錯誤資料的業務程式。因此，百分之百的準確性是虛幻的，企業需要應對錯誤的機制。例如，一個大型的網上零售商承認，操作總會發生錯誤，故建有系統來處理由此可能引起的顧客投訴。
包裝器：最頭疼的問題之一是從遺留系統中提取資料（例如從SAP或PeopleSoft系統）、再將其造型（cast）為資料整合系統可讀的格式。遺留系統ETL供應商已經用了大量時間來為流行系統建立包裝器（wrapper）。但對其餘的資料來源如何建包裝器呢？同樣令人望而生畏的是網上資料。儘管在HTML表格中有些資料很容易讀取，但大多數有意義的資料埋在文字、下拉選單之內，或者在按鈕之後（所謂深層網站裡）。在此情況下造出高成本效益的萃取器（extractor）仍問題多多，亟需好的理念。