公司的專案資料量有限，獲取行業線上線下消費資料也困難，沒有足夠的資料量，如何應用大資料？如何在公司現有情況下接觸實際的高并發大資料專案？

就是想實操一下高并發的架構設計或者參與互聯網級別專案的開發，但又不想舍棄現在的作業？

中小企業如何想辦法破局

大資料本身就特別容易形成技術壟斷，讓長尾的中小企業無法形成自己可以擁有的大資料技術方法和經驗，導致很難改變小企業的命運，而且也容易導致優質工程師的流失，如何想辦法突破這個局面呢？

中小企業往往都是長尾的，小資料形態，基本上自身無法產生較大規模資料，更不具備建立資料共享平臺的實力，而且與其他企業也存在著天然的信任隔閡，就很難做到企業資料之間的共享，這些本質的底層邏輯所產生的問題是中小企業很難通過聯合產生足夠規模的資料，所以很難應用大資料技術和大資料平臺化所帶來的優勢，

但是中小企業若有機會，就一定要涉足大資料，因為智能互聯網時代已經到來，要為將來的發展做鋪墊，避免被輕易地淘汰掉，這個時代的企業強者愈強，弱者愈弱，

那有沒有好的辦法呢？中小企業可行的策略就是“吃大戶”，找大戶合作，替大戶服務，然后拿著大戶的平臺資料，鍛煉著自己的大資料能力，這就必須要有過硬的業務與技術合作，開放的心態與持久的耐心！

舉個例子，以前認識一個小微軟體公司的架構師，公司通過商務運作，接手了一個省級的政府大資料專案，按照正常邏輯是沒有能力承接啊！但是專案的關鍵要素是必須懂得核心業務資料如何去做資料清洗，我的朋友公司正好在這方面是業務專家，這才讓企業全力以赴接手了這個專案，關鍵是請來了大資料方面的咨詢師配合我的朋友架構師，就一起做成了該專案的技術架構及資料開發實施，經過兩年左右的時間，迅速使企業具備了大資料專案的承接能力，從此到處標榜大資料技術企業了，我朋友也成為口碑比較厲害的大資料技術架構師了，

當然很多中小企業不是軟體公司，但也可以建立大資料應用部門，招攬一些優秀的人才，或者與其他專業創業型大資料技術團隊，形成戰略同盟，緊扣自身行業所專長的資料業務，制定符合自身企業特色的發展戰略，然后去找政府、電信、銀行、能源、制造等具有產生大資料能力的大戶，提供在大資料方面的服務解決方案，盤活大戶的資料死海成為資料資產，通過服務的形式，使自己成為大資料戰略的一個服務環節提供商，那么就充分具有了大規模資料的使用權，不僅能幫助大戶提供采集，分析，運營資料的服務能力，也能快速打造自身企業在大資料時代的實力與銘牌，

例如：你是做醫療設備的小廠商，雖然在垂直領域你很厲害，但是放眼發展，商業局限性就很大，若將自身銘牌改成醫療大資料與AI設備服務商，通過醫療設備作為資料采集的入口，進一步為政府提供醫療大資料清洗服務，并抓住一個或幾個關鍵醫療分析的亮點資料分析需求，做成AI分析平臺，并加入大資料采購名錄，那么這家小企業的前景肯定就有很大改觀了，

再例如：你是交通視頻系統集成商，還把自己定位成系統設備集成商的話，那么你們始終擺脫不了競爭激烈，低利潤的紅海，若能與AI創新科技公司合作，那么借助你們對行業各種業務資源的靈活把握與市場轉化能力，并將自身定位成交通大資料與AI提供商，那么放眼你們的商業環境，又會是另一番景象了，這樣既能形成一種商業模式，還能為企業在智能互聯網時代打好基礎，

中小企業的技術工程師如何破局

現如今對于工程師來說最難的事情就是在自身發展與企業感情間做選擇，企業發展好，沒感情，干得痛苦；企業發展局限，有感情，又會干得沒信心，

本質上，還是如何能接觸到更優質的專案？例如：高并發、大資料專案，工程師自己既能得到實戰、操練和提升，也能為企業的快速成長提供極有價值的建議，同時自己也不容易被社會發展所淘汰，那么我也給一些分析和辦法，

首先并發與大資料的技術問題，終極方案幾乎都會轉成分布式存盤+實時流處理的解決方案，也就是將高并發的請求負載轉換成大吞吐、有序佇列的方式，降低高并發的同時性請求導致的CPU、記憶體、I/O這些資源爭用的根本性問題，然后通過資料分片，落地在資料庫的不同分布式節點中，實作資料upsert的水平伸縮性，

例如：Nginx無論組成有多么高性能的負載群，調度到業務處理、資料庫查詢和寫入都可能會是瓶頸，所以這時候的設計是需要將請求的資料進行佇列轉換，例如通過Kafka、RocketMQ，然后由流式節點快速的處理掉，而且涉及到流庫連接，例如：Hbase、MongoDB、Kudu等實作行級事務就夠了，
最后就是如何練習了：需要的業務需求和業務模型直接參考你們企業專案的業務系統，往往業務復雜度和大資料、高并發關系不大，資料集從Google Kaggle下載與你們業務相似的資料集，然后進行清洗改造，這個程序也可以練習一下資料清洗，ETL怎么搞，清洗出自己需要的資料，做成大資料源，Kaggle實在沒有與你們業務相類似的資料了，那就自己寫模擬客戶端程式造資料，跑上3天看結果，

在采集自己的資料源的程序中，嘗試kafka，redis，hbase，tidb，mysql，elk，mongodb，hadoop的不同組合的方案效果，最終達到三個目標，1.資料集的ACID事務，2.資料的分布式存盤，3.資料的處理和查詢實作亞秒級回應，這些搞定的話，其實高并發環境下的大資料事務處理（OLTP）與資料分析（OLAP）架構，最終也跳不出這個架構方案模式，

最關鍵的是：這個方法適合小資料企業的工程師拿來自己練手，掌握的技術面肯定比大廠工程師更全面，但不否認大廠工程師的實戰性認識要深入得多，

最終資料在流式處理后，形成多流聚合，庫表業務模型寫入，這時候再選擇MySQL Cluster或者NewSQL的TiDB，形成關系型資料模型，在分布式事務環境下的資料落地，

查詢的程序Nginx+Redis（二級快取）+MySQL（讀寫分離負載），或TiDB（分布式資料庫）等，配合上MongoDB（部分業務可替換MySQL）和Elasticsearch（搜索引擎），基本上這個模式能扛得住絕大多數的查詢回應了，

其次我們通過一個實體博客文章架構，如下圖所示：看看在極高并發的情況下，每天過億資料的文章記錄產生，是如何架構操作的？

常做自媒體的朋友會知道，文章編輯的程序會頻繁地進行修改，云端也會不斷保存草稿，作為一個發文章的頂流大站，這種內容頻繁寫入的規模，是任何關系資料庫都是扛不住的，就需要利用大資料平臺的K-V資料庫特性，實作高速與海量文章的頻繁編輯與操作，

然后系統總會在提交后進入一個審核程序，我們總要等待上幾秒、幾分鐘甚至是幾十分鐘，為什么呢？因為提交的內容正在訊息排隊，需要等待多久是根據某個時間段內文章發表與修改的佇列吞吐量所能處理完的速度決定的，佇列處理的程序要進行各種機器AI演算法完成對文章內容的流式過濾，例如：敏感詞、SH、內容重復等等，

真正意義上的業務關系入庫——文章正式發布，是需要等到審核完，這時候才會形成真正地達到了業務一致性，是不是這個時候已經極大的降低了關系資料庫的高并發壓力，

最后就是如何練習了：需要的業務需求和業務模型直接參考你們企業專案的業務系統，往往業務復雜度和大資料、高并發關系不大，資料集從Google Kaggle下載與你們業務相似的資料集，然后進行清洗改造，這個程序也可以練習一下資料清洗，ETL怎么搞，清洗出自己需要的資料，做成大資料源，Kaggle實在沒有與你們業務相類似的資料了，那就自己寫模擬客戶端程式造資料，跑上3天看結果，

在采集自己的資料源的程序中，嘗試kafka，redis，hbase，tidb，mysql，elk，mongodb，hadoop的不同組合的方案效果，最終達到三個目標，1.資料集的ACID事務，2.資料的分布式存盤，3.資料的處理和查詢實作亞秒級回應，這些搞定的話，其實高并發環境下的大資料事務處理（OLTP）與資料分析（OLAP）架構，最終也跳不出這個架構方案模式，

最關鍵的是：這個方法適合小資料企業的工程師拿來自己練手，掌握的技術面肯定比大廠工程師更全面，但不否認大廠工程師的實戰性認識要深入得多，

可以閱讀另一篇關于高并發和大資料技術的詳細文章：

博客站的架構漸進升級優化，億級日寫量架構又是什么樣呢？

前往讀位元組創作中心——了解”讀位元組“更多創作內容

標籤：大數據

上一篇：常見資料庫介紹和使用場景

下一篇：現在后端都在用什么資料庫存盤資料？