c大數據並發處理

1. C語言大數據問題

給你提個思路吧，這種大數據都必須用數組來做的。把數字直接定內義成數組，然後將容轉換規則寫成代碼，而不是直接用取余或取整來做。我給你上傳一個大數加法的代碼，給你些啟發吧。想要代碼可以先採納我，然後我給你寫一個進制轉換的代碼。你這分太少，多些我會直接給你寫個代碼的。

2. c語言處理文件里的大數據

C語言處理大數據一般有三種處理方法：

1.分段處理，即無論文件多大，程序中使用的永遠只是一小段部分，可以使用一個緩沖區，根據用戶交互輸入，分段的輸出；

2.使用內存文件映射，這是最常用的文件的處理方法，Linux和Windows都提供一種內存文件映射的機制，以Windows為例，可以調用 CreateFile、 CreateFileMapping以及 MapViewOfFile三個函數來完成內存文件映射；

3.使用資料庫，藉助SQL查詢語言對大數據進行操作。

3. 如何進行大數據分析及處理

探碼科技大數據分析及處理過程

聚雲化雨的處理方式

• 聚雲：探碼科技全面覆蓋各類數據的處理應用。以數據為原料，通過網路數據採集、生產設備數據採集的方式將各種原始數據凝結成雲，為客戶打造強大的數據存儲庫；

• 化雨：利用模型演算法和人工智慧等技術對存儲的數據進行計算整合讓數據與演算法產生質變反應化雲為雨，讓真正有價值的數據流動起來；

• 開渠引流，潤物無聲：將落下「雨水」匯合成數據湖泊，對數據進行標注與處理根據行業需求開渠引流，將一條一條的數據支流匯合集成數據應用中，為行業用戶帶來價值，做到春風化雨，潤物無聲。

4. 如何處理大量數據並發操作

處理大量數據並發操作可以採用如下幾種方法:

1.使用緩存：使用程序直接保存到內存中。或者使用緩存框架: 用一個特定的類型值來保存，以區別空數據和未緩存的兩種狀態。

2.資料庫優化：表結構優化;SQL語句優化，語法優化和處理邏輯優化;分區;分表;索引優化;使用存儲過程代替直接操作。

3.分離活躍數據:可以分為活躍用戶和不活躍用戶。

4.批量讀取和延遲修改: 高並發情況可以將多個查詢請求合並到一個。高並發且頻繁修改的可以暫存緩存中。

5.讀寫分離: 資料庫伺服器配置多個，配置主從資料庫。寫用主資料庫，讀用從資料庫。

6.分布式資料庫: 將不同的表存放到不同的資料庫中，然後再放到不同的伺服器中。

7.NoSql和Hadoop: NoSql，not only SQL。沒有關系型資料庫那麼多限制，比較靈活高效。Hadoop，將一個表中的數據分層多塊，保存到多個節點（分布式）。每一塊數據都有多個節點保存（集群）。集群可以並行處理相同的數據，還可以保證數據的完整性。

拓展資料:

大數據（big data），指無法在一定時間范圍內用常規軟體工具進行捕捉、管理和處理的數據集合，是需要新處理模式才能具有更強的決策力、洞察發現力和流程優化能力的海量、高增長率和多樣化的信息資產。

在維克托·邁爾-舍恩伯格及肯尼斯·庫克耶編寫的《大數據時代》中大數據指不用隨機分析法（抽樣調查）這樣捷徑，而採用所有數據進行分析處理。大數據的5V特點（IBM提出）：Volume（大量）、Velocity（高速）、Variety（多樣）、Value（低價值密度）、Veracity（真實性）。

5. 數據分析：大數據處理的基本流程（三）

01

什麼是數據分析

隨著數字化進程的高速發展，越來越多的企業面對愈加激烈的競爭，差異化的市場，多變的環境，常常會面臨各種難題，也變得更依賴於數據。

分析的本質是讓業務更加清晰，讓決策更加高效。 數據分析 作為大數據價值產生的必要步驟、整個 大數據處理流程的核心 ，其在企業中的地位也越來越重要。

數據分析的目的 說白了就是把隱藏在一大批看來雜亂無章的數據中的信息集中和提煉出來，對其加以匯總、理解並消化，以求最大化地開發數據的功能，從而找出所研究對象的內在規律，發揮數據的作用。

簡而言之， 數據分析就是一個有組織、有目的收集數據、為了使其成為信息而對數據加以詳細研究和概括總結的過程。

在企業實際應用中，數據分析的一系列過程也是產品質量管理體系的支持過程。在企業產品的整個壽命周期，包括從市場調研到售後服務的各個過程都需要適當運用數據分析，以提升數據分析的有效性，能夠適時解決企業難題、識別機會、規避風險。

數據分析的作用及價值，可簡單歸納總結為下面四個方面：

1.追溯過去，了解真相（識別機會、規避風險）

2.洞察本質，尋本溯源（診斷問題、亡羊補牢）

3.掌握規律，預測未來（評估效果、改進策略）

4.採取措施，驅動行動（提高效率、加強管理）

02

數據分析的三個常用方法

數據分析本身是一個非常大的領域，這里將主要討論一下在企業產品整個壽命周期期間，3個常用的數據分析方法 （想看數據分析常用演算法的小夥伴可以點這里跳轉） ：

數據趨勢分析

數據對比分析

數據細分分析

趨勢 ， 對比 ， 細分 ，基本包含了數據分析最基礎的部分。無論是數據核實，還是數據分析，都需要不斷地找趨勢，做對比，做細分，才能得到最終有效的結論。

數據趨勢分析

趨勢分析一般而言，適用於產品核心指標的長期跟蹤，比如產品點擊率、活躍用戶數等。簡單的數據趨勢圖並不算是趨勢分析，趨勢分析更多的是需要明確數據的變化，以及對變化原因進行分析。

趨勢分析，最好的產出是比值。在趨勢分析的時候需要明確幾個概念： 環比，同比，定基比 。

環比 指本期統計數據與上期比較，利用環比可以知道最近的變化趨勢，但是有些數據可能會受季節、時間、地域等因素影響而產生差異。

為了消除差異，於是有了 同比 的概念，例如2019年2月份和2018年2月份進行比較。

定基比 就是和某個基點進行比較，比如2018年1月作為基點，定基比則為2019年2月和2018年1月進行比較。

趨勢分析另一個核心目的則是對趨勢做出解釋，對於趨勢線中明顯的拐點，發生了什麼事情要給出合理的解釋。

數據對比分析

很多時候單獨看數據的趨勢變化並不能說明問題，此時就需要給孤立的數據一個合理的參考系，否則孤立的數據毫無意義，這也是對比分析的意義所在。

一般而言，對比的數據是數據的基本面，比如行業情況，全站的情況等。

有的時候，在產品迭代測試的時候，為了增加說服力，會人為的設置對比的基準，也就是A/B test，比較試驗最關鍵的是A/B兩組只保持單一變數，其他條件保持一致，只有這樣才能得到比較有說服力的數據。可以簡單理解為樣本數量為2的控制變數法。

數據細分分析

在得到一些初步結論後，就需要進一步對數據進行細拆，因為在一些綜合指標的使用過程中，會抹殺一些關鍵的數據細節。

細分分析是一個非常重要的手段，多問一些為什麼，才是得到結論的關鍵，而一步一步拆分，就是在不斷問為什麼的過程。

進行數據細分分析時，一定要進行多維度的細拆，可以包括但不限於：

分時 ：不同時間短數據是否有變化

分渠道 ：不同來源的流量或者產品是否有變化

分用戶 ：新注冊用戶和老用戶相比是否有差異，高等級用戶和低等級用戶相比是否有差異

分地區 ：不同地區的數據是否有變化

組成拆分 ：比如搜索由搜索片語成，可以拆分不同搜索詞；店鋪流量由不用店鋪產生，可以分拆不同的店鋪

03

大數據時代數據分析面臨的挑戰

大數據時代，數據分析技術的發展也並非一直順風順水，眼下可能會面臨一些新的挑戰，主要有以下幾點：

1

數據量大並不一定意味著數據價值的增加，也有可能是意味著數據噪音的增多。

因此，在數據分析之前必須進行數據清洗等預處理工作，但是預處理如此大量的數據，對於計算資源和處理演算法來講都是非常嚴峻的考驗。

2

大數據時代的演算法需要進行調整。

大數據的應用常常具有實時性的特點，演算法准確率不再是大數據應用的最主要指標。很多時候，演算法需要在處理實時性和准確率之間博得一個平衡點。

其次，分布式並發計算系統是進行大數據處理的有力工具，這就要求很多演算法必須做出調整以適應分布式並發的計算框架，演算法需要變得具有可擴展性。許多傳統的數據挖掘演算法都是線性執行的，面對海量的數據很難在合理的時間內獲取所需的結果。因此需要重新把這些演算法實現成可以並發執行的演算法，以便完成對大數據的處理。

最後，在選擇處理大數據的演算法時必須謹慎，當數據量增長到一定規模以後，可以從少量數據中挖掘出有效信息的演算法並非一定適用大數據。

3

數據結果的衡量標准。

對大數據進行分析並非易事，同樣的，對大數據分析結果好壞如何衡量也是大數據時代數據分析面臨的更大挑戰之一。

大數據時代的數據體量大、類型混雜、產生速度快，進行分析時如果沒有對整個數據的分布特點了如指掌，無疑會導致在設計衡量的方法、指標時遇到困難。

企通查-企業大數據平台基於 數據採集、特徵提取、信息關聯、機器學習和深度學習演算法模型、NLP文本分析 等先進技術，清晰構建企業全維度動態畫像，通過 企業風控指數、企業信用指數、企業活力指數 三大指數模型體系和基於 企業基本能力、創新能力、經營能力、核心能力、財務能力和風險能力 六大方面的大數據風控體系，實現對企業和客戶的 全流程主動感知、重點監控、變動提醒和風險預警 。此外，企通查還可以根據客戶的不同需求定製所需的一系列企業數據。

6. C/C++大數據處理問題

昨天下班後沒上QQ，答了！

7. 大數據量實時統計排序分頁查詢(並發數較小時)的幾點建議

大數據量實時統計排序分頁查詢的瓶頸不是函數（count，sum等）執行，

不是having, 也不是order by，甚至不是表join, 導致慢的原因就在於「數據量太大本身」

就是將表劃分為M份相互獨立的部分,可以是分表，也可以是不分表但冗餘一個取模結果欄位

實際結果是不分表比分表更加靈活，只需稍加配置，就可以動態切分大表，隨意更改M的大小。

將1條慢sql（大於30秒）拆分成為N條查詢速度巨快的sql(單條sql執行時間控制在20毫秒以內)

然後再web應用中以適當的線程數去並發查詢這些執行時間快的N條小sql再匯總結果

第一步查詢中去並發執行這N條小sql, 只取排序欄位和標識欄位，其他欄位一律丟棄

匯總結果後定位出當前頁面要顯示的pageNum條數據，再進行第二步查詢，取出頁面上需要展示的所有欄位

PS：這一點是至關重要的，其他幾點都可以不看，這點是最關鍵的。慢慢解釋一下：

有三種方式統計所有的記錄，

a) 第一種方式是把資料庫中所有記錄（只取排序欄位和標識欄位並且不做任何sum，count having order by等操作）

全部拉到web應用中，在web應用中完成所有的計算

b) 第二種方式是把資料庫中所有記錄做sum count having等操作之後的所有行數拉到web應用中，在web應用中完成剩餘計算

c) 第三種方式是把資料庫中所有記錄做sum count having order by等操作之後把limit後的數據拉到web應用中，

在web應用中對limit後的數據再計算

顯然，第一種方式 資料庫什麼活都不做只取數據 是不可行的。以lg_order_count_seller為例，1500萬行，

如果只算id, seller_id和order_count 這三個bigint類型，至少需要拉8*3*1500 0000 = 360000000=340M,

拉到內存中之後存儲需要8*4*15000000= 460M,這還不算List是的2的n次方這個特點和計算排序等的內存開銷，

不僅資料庫與web應用機器IO扛不住，就是應用自身恐怕也要OOM了。

第二種方式，所有記錄做sum count having等操作之後,由於是group by seller_id的，總得數據量變為100萬（就是賣家總數），

這樣子一來，共需要拉8*3*100 0000 = 23M,拉到內存之後，需要8*4*100 0000 = 30M, 再算上List是的2的n次方這個特點和

計算排序等的內存開銷也不會超過100M, IO的時間和內存開銷勉強可以考慮接受。

第三種方式，所有記錄做sum count having order by等操作之後把limit後的數據拉到web應用中，因為做了limit，所以，

數據量很小了，無論是IO還是內存開銷都已經很小了。可以忽略。

綜合以上三種，第三種方式適用於頁面的前n頁和後n頁，因為這個limit的數據量隨著頁數的增大而增大，

當大到每個切分後的小表的數據量時就轉為第二種方式了。

第二種方式適用於頁面的第[n+1, totaoPageNum-n]頁。

① 問題描述：

優化之前，還是是一條大慢sql查詢時，由於資料庫排序是穩定排序，

所以當兩條記錄排序欄位值相同時他們在頁面上的頁碼位置是固定的。

優化之後，當並行執行這N條小sql時，由於無法控制這些小sql的先後執行順序，

導致在web應用中當兩條記錄的排序欄位值相同時在頁面上的頁碼位置是隨機的。

② 解決辦法：

除了拉標識欄位(seller_id)和排序欄位(order_count_sum)之外，再取一個unique（id）的欄位，當兩條記錄的排序欄位值相同時，

再用這個unique的欄位（在賣家監控中這個欄位是id）進行第二次排序.這樣就解決了排序不穩定的問題。

③ 也許，看到這里會有疑問，為什麼不用seller_id？seller_id也是唯一， 這樣子不是少取id這個欄位，減少IO了？

seller_id雖然也是唯一，可以輔助排序，但是不要忘記資料庫的排序規則是：

如果兩列的值相等，那麼序號在前的排在前面，這里的序號就是主鍵(自動生成，autoincrement),

如果用seller_id的話還是不能保證排序的穩定性，只能用主鍵id.

把資料庫的連接，掃表，計算等資源優先讓給用戶關注的主要元素，次要元素可等主要元素載入完成之後再載入。

反應在賣家監控頁面中，查數據和查頁頁碼的sql語句基本相同，是在競爭同一資源，

所以，需要做一個策略，優先把資源讓給查數，數據查完之後再去查頁碼。

由於多線程取數據並沒有從本質上提高資料庫性能，所以必須針對大數據量實時統計排序分頁查詢做限流

我這里打個比方：食堂有6個窗口，物流團隊吃飯要買6個菜，平均每買1個菜需要1分鍾的時間，

如果派我一個人去一個窗口買的話需要6分鍾的時間

假如派6個人分別去6個窗口買這6個菜，只需要1分鍾的時間

但是，如果除了物流團隊，再來其他5個團隊呢，也就是說6個團隊每個團隊買6個菜共買36個菜，

這樣子有的團隊先買完，有的團隊後買完，但平均時間還是6分鍾。本質上沒有變化。

所以，對於特定的查詢條件，必須進行限流。讓每分鍾至多有6個團隊買菜，這樣子能使得情況變得不至於太糟糕。

這一點從目前來看只能是展望了，比如mysql資料庫換更為強大的oracle資料庫，

或更換InnoDb引擎為其他，或更換SATA硬碟為SSD 。。。。。。

相同的查詢條件，原來一個頁面查詢時間由於超過60秒超時了，根據1-6點建議優化之後，查詢時間變為2秒至3.5秒之間。

8. c/c++對大數據有用嗎

cloudera自己的大數據生態就是C++的, 比如Impala,ku。
java 把寫大規模並發程序的難度降低了，但內是把問題挪到了容JVM上面，雖然內存分配省心了，但是問題在JVM上面表現出來了。
C++ 是寫的時候難了，但是用起來爽
GO 的話，並發解決了， GC問題還是沒解決 和java 一樣一樣的！

9. 如何進行大數據處理

大數據處理之一：收集

大數據的收集是指運用多個資料庫來接收發自客戶端(Web、App或許感測器方式等)的 數據，而且用戶能夠經過這些資料庫來進行簡略的查詢和處理作業，在大數據的收集進程中，其主要特色和應戰是並發數高，因為同時有可能會有成千上萬的用戶 來進行拜訪和操作

大數據處理之二：導入/預處理

雖然收集端本身會有許多資料庫，但是假如要對這些海量數據進行有效的剖析，還是應該將這 些來自前端的數據導入到一個集中的大型分布式資料庫，或許分布式存儲集群，而且能夠在導入基礎上做一些簡略的清洗和預處理作業。導入與預處理進程的特色和應戰主要是導入的數據量大，每秒鍾的導入量經常會到達百兆，甚至千兆等級。

大數據處理之三：核算/剖析

核算與剖析主要運用分布式資料庫，或許分布式核算集群來對存儲於其內的海量數據進行普通 的剖析和分類匯總等，以滿足大多數常見的剖析需求，在這方面，一些實時性需求會用到EMC的GreenPlum、Oracle的Exadata，以及根據 MySQL的列式存儲Infobright等，而一些批處理，或許根據半結構化數據的需求能夠運用Hadoop。 核算與剖析這部分的主要特色和應戰是剖析觸及的數據量大，其對系統資源，特別是I/O會有極大的佔用。

大數據處理之四：發掘

主要是在現有數據上面進行根據各種演算法的核算，然後起到預測(Predict)的作用，然後實現一些高等級數據剖析的需求。主要運用的工具有Hadoop的Mahout等。該進程的特色和應戰主要是用於發掘的演算法很復雜，並 且核算觸及的數據量和核算量都很大，常用數據發掘演算法都以單線程為主。

關於如何進行大數據處理，青藤小編就和您分享到這里了。如果您對大數據工程有濃厚的興趣，希望這篇文章可以為您提供幫助。如果您還想了解更多關於數據分析師、大數據工程師的技巧及素材等內容，可以點擊本站的其他文章進行學習。

10. C/C++大數據處理：10Gtxt資料庫文件

10G 連一次導入內存都不行，而且你說的串除了出現1次沒有其他特徵，只能文件分塊讀入用KMP匹配
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#define MAX 1024*1024*10
int index_KMP(char *s,int n,char *t,int pos);
//利用模式串的t的next函數求t在主串s中的第pos個位置之後的位置的KMP演算法（t非空，1<=pos<=Strlength(s)）。

void get_next(char * t,int * next);
//求模式串t的next函數的並存入數組next[]中。
int next[MAX];
int main()
{
char* s= (char*)malloc(MAX+1);
memset(s,0,MAX+1);
char t[256]={0},c;
printf("請輸入檢測字元串，以#號結尾");
int i=0;
while((c=getchar())!='#'&&i<256)
{
t[i++]=c;
}
fflush(stdin);
//strcpy(t,"2014-04-28 18:14:33,333");
get_next(t,next);
FILE* pf = NULL;
if((pf = fopen("1.txt","r"))==NULL){
printf("打不開文件！\n");
return 0;
}
int cur=0,n=0;
unsigned long long pos=0,sum=0;
while(!feof(pf))
{
int len = fread(s,1,MAX,pf);
sum+=len;
printf("讀取第 %5d 次，長度 %5d ，總長:%ld\n",cur+1,len,sum);
n=index_KMP(s,MAX,t,pos);
if(n>0)
{
pos = n+cur*MAX;
break;
}
++cur;
}
fclose(pf);

free(s);
if(n!=0)
printf("\n模式串 t 在主串 s 中第 %ld 個位置之後。\n\n",n);
else
printf("\n主串中不存在與模式串相匹配的子串!\n\n");

}

int index_KMP(char *s,int n,char *t,int pos)
//利用模式串的T的NEXT函數求t在主串s中（長度n)的第pos個位置之後的位置的KMP演算法，（t非空，1<=pos<=Strlength(s)）.
{
int i=pos,j=1;
while (i<=n &&j<=(int)strlen(t))
{
if (j==0 || s[i]==t[j-1]) //繼續進行後續字元串的比較
{
i++;
j++;
}

else j=next[j]; //模式串向右移動
}
if (j>(int)strlen(t)) //匹配成功
return i-strlen(t)+1;
else //匹配不成功
return 0;
}

void get_next(char *t,int *next)
//求模式串t的next函數的並存入數組next[]中。
{
int i=1,j=0;
next[0]=next[1]=0;
while (i<(int)strlen(t))
{
if (j==0 || t[i]==t[j])
{
i++;
j++;
next[i]=j;
}
else j=next[j];
}
}
替換文件名，每次讀10M，我測試50M的1S搞定，因為尋找串可能再兩次讀取之間，完美的做法是後一次要把前一次的最後N個字元重新讀取，N為尋找的子串長度，計算長度時需要特殊考慮，我簡略了該種情況