?

?

本文是神策數(shù)據(jù) CTO 曹犟親筆撰寫的深度招聘解讀系列「神策招人記」的第一篇，還有續(xù)集哦~如果通過我們的這些介紹，讓大家對一個企業(yè)服務(wù)公司，一個大數(shù)據(jù)公司有了新的認(rèn)識，對于大數(shù)據(jù)這件事情增加了一些興趣，那么就達到了我們的目的。

前天，我們發(fā)了一篇文章「“數(shù)”天下神人，都“據(jù)”于此」的招聘文章，秉承我們一貫的作風(fēng)，我們希望能夠讓這些招聘文章盡可能“硬”一點、“干貨”多一點，因此，我們計劃出一系列「神策招人記」的干貨文章，希望大家讀了文章之后，對于一個典型的大數(shù)據(jù)企業(yè)服務(wù)公司是如何運作的？面臨著哪些挑戰(zhàn)？以及是如何不斷解決問題的能夠有更好地了解。

神策數(shù)據(jù)作為一個成立快 4 年的大數(shù)據(jù)企業(yè)服務(wù)初創(chuàng)公司，服務(wù)了越來越多的客戶，在整個行業(yè)里面有了一些影響。同時，我們在博客上分享的神策分析產(chǎn)品的技術(shù)架構(gòu)以及開源的數(shù)據(jù)采集 SDK，也讓越來越多的同學(xué)開始知道并且關(guān)注我們。我們也非常希望能夠有更多志同道合的、對于大數(shù)據(jù)、對于分布式處理感興趣的同學(xué)能夠加入我們，一起做一些有趣并且激動人心的產(chǎn)品，推動整個行業(yè)的發(fā)展。因此，我們覺得有必要通過一系列文章，向那些可能愿意加入我們的同學(xué)們，介紹一下神策數(shù)據(jù)，介紹一下整支團隊具體是做什么的、每天會碰到哪些問題、有哪些有意思的技術(shù)挑戰(zhàn)。

我們首先會從技術(shù)團隊開始聊起。神策數(shù)據(jù)目前擁有一支超過一百人的技術(shù)團隊，相比較創(chuàng)業(yè)之初只有研發(fā)，現(xiàn)在整個技術(shù)團隊的分工越來越明確，整體上可以分為研發(fā)、產(chǎn)品、售前、技術(shù)服務(wù)四個大的部門。在這篇文章里面，我們會首先介紹研發(fā)內(nèi)部各個團隊的職責(zé)和要解決的技術(shù)問題，希望能夠?qū)Υ蠹矣兴鶐椭?/p>

神策數(shù)據(jù)為客戶提供了如下圖的產(chǎn)品矩陣，產(chǎn)品矩陣中的每個產(chǎn)品各自解決不同的問題，例如，神策分析是一個具有較好可視化和分析能力的非常靈活的高性能的海量用戶行為實時分析工具，神策推薦是一個基于強大的數(shù)據(jù)處理分析能力采用領(lǐng)先的深度學(xué)習(xí)算法技術(shù)來提升多維度業(yè)務(wù)指標(biāo)的個性化推薦框架，神策標(biāo)簽和自動化運營產(chǎn)品則主要解決用戶畫像與精準(zhǔn)運營的需求。雖然每個產(chǎn)品解決不同的問題，但與此同時，它們又復(fù)用一套底層的數(shù)據(jù)平臺，共享平臺提供的海量數(shù)據(jù)的處理能力。整個產(chǎn)品矩陣可以針對不同行業(yè)的客戶的不同需求，自由組合，提供了從數(shù)據(jù)采集到傳輸、存儲、分析、建模、可視化、應(yīng)用的整體解決方案。

因此，在研發(fā)團隊內(nèi)部，也基本是按照數(shù)據(jù)處理的過程，劃分為數(shù)據(jù)采集、數(shù)據(jù)導(dǎo)入與預(yù)處理、分布式存儲、分布式查詢、數(shù)據(jù)中臺、基礎(chǔ)平臺化、用戶標(biāo)簽、數(shù)據(jù)可視化、機器學(xué)習(xí)等不同的技術(shù)方向和團隊。下面我們依次進行介紹。

數(shù)據(jù)采集團隊

對于所有的數(shù)據(jù)平臺和數(shù)據(jù)產(chǎn)品來說，數(shù)據(jù)采集都是整個數(shù)據(jù)處理過程的起點和重中之重。不管最后這個數(shù)據(jù)是用于統(tǒng)計報表還是用于個性化推薦，采集到的數(shù)據(jù)質(zhì)量，都直接關(guān)系到最終應(yīng)用的質(zhì)量。正因為如此，我們對于數(shù)據(jù)采集投入了很大的精力，成立了專門的數(shù)據(jù)采集團隊。

數(shù)據(jù)采集團隊主要解決在不同環(huán)境下以最高的效率、最低的代價采集數(shù)據(jù)的問題。目前由于處理的主要是用戶行為數(shù)據(jù)，因此數(shù)據(jù)采集團隊目前主要在 Android App、iOS App、小程序、網(wǎng)頁等客戶端以及服務(wù)端提供具體的方案采集用戶行為相關(guān)的數(shù)據(jù)。

數(shù)據(jù)采集團隊提供的方案會以各個端的 SDK 為載體，SDK 提供了對數(shù)據(jù)的本地緩存、加密、網(wǎng)絡(luò)傳輸、一致性保證等能力的封裝，并對外提供統(tǒng)一的數(shù)據(jù)抓取接口。而在幾個典型的客戶端，如 Android App 和 iOS App，數(shù)據(jù)采集團隊還提供了統(tǒng)稱為“代碼埋點”和“全埋點”的兩種集成方式。

“代碼埋點”可以理解為直接調(diào)用 SDK 提供的數(shù)據(jù)抓取接口來采集用戶行為，而“全埋點”則可以理解為在客戶端用戶進行特定動作時，自動觸發(fā) SDK 的數(shù)據(jù)抓取接口來自動采集對應(yīng)的用戶行為。值得一提的是，數(shù)據(jù)采集團隊的工作基本都以開源項目（開源網(wǎng)址為：https://github.com/sensorsdata/）的形式對外開放，回饋給整個行業(yè)。

除了開發(fā)與維護 SDK 之外，數(shù)據(jù)采集團隊還需要結(jié)合客戶的具體應(yīng)用情況與行業(yè)特性，為客戶制訂整體的數(shù)據(jù)采集方案，并且協(xié)助客戶一起保證數(shù)據(jù)采集的正確性與時效性。當(dāng)然，除了針對用戶行為數(shù)據(jù)的采集之外，隨著神策數(shù)據(jù)整體業(yè)務(wù)范圍的擴大，未來數(shù)據(jù)采集團隊也需要探索更多其它類型數(shù)據(jù)的采集方案。

目前，數(shù)據(jù)采集團隊已經(jīng)在數(shù)據(jù)采集的性能損耗、數(shù)據(jù)傳輸?shù)囊恢滦浴⒔涌诘囊子眯浴DK 的穩(wěn)定性、全埋點的兼容性、數(shù)據(jù)調(diào)試與校驗、與 Deeplink 的結(jié)合等具體技術(shù)點上做了非常多的工作，但也依然有很多技術(shù)難點等待攻克，因此，我們也非常希望有在 Android、iOS、JS 底層開發(fā)方面有經(jīng)驗，并且對數(shù)據(jù)采集、大數(shù)據(jù)感興趣的同學(xué)加入我們，一起打造一個行業(yè)內(nèi)首屈一指的數(shù)據(jù)采集方案。

數(shù)據(jù)導(dǎo)入與預(yù)處理團隊

神策數(shù)據(jù)服務(wù)了不少日 PV 超過百億的客戶，這代表著每天需要導(dǎo)入的數(shù)據(jù)超過百億。而神策分析又是一個純實時的數(shù)據(jù)分析系統(tǒng)，期望所有的數(shù)據(jù)都能夠以秒級的延遲完成導(dǎo)入。在這樣的數(shù)據(jù)量下，如何在保證完成對數(shù)據(jù)的基本預(yù)處理的情況下，還能讓所有的數(shù)據(jù)實時導(dǎo)入，就變成了一個頗具挑戰(zhàn)的技術(shù)難題。

我們的數(shù)據(jù)導(dǎo)入預(yù)處理團隊，主要就是解決數(shù)據(jù)導(dǎo)入過程中的一系列問題。例如，在數(shù)據(jù)導(dǎo)入過程中，如何高效率地完成一些數(shù)據(jù)預(yù)處理工作，從最簡單的 IP、User-Agent 等基礎(chǔ)字段的解析，到會有上下文依賴的 ID-Mapping（在實時系統(tǒng)中，有上下文依賴的處理環(huán)節(jié)一直都會是一個技術(shù)挑戰(zhàn)，這里也不例外）；當(dāng)突發(fā)流量高峰時，如何保證數(shù)據(jù)不丟失；在多個數(shù)據(jù)處理節(jié)點組成的集群內(nèi)，如何做好各個節(jié)點之間的協(xié)同；如何設(shè)計良好的對外編程接口，讓客戶能夠方便高效地在數(shù)據(jù)導(dǎo)入環(huán)節(jié)嵌入自己的數(shù)據(jù)處理邏輯。以上所列出的這些技術(shù)問題，由于海量數(shù)據(jù)與實時處理兩個大的前提，會變得更有挑戰(zhàn)，當(dāng)然，也會更有趣。

我們歡迎所有對于數(shù)據(jù)預(yù)處理、分布式處理有興趣，或者有一定 Java 開發(fā)經(jīng)驗的同學(xué)加入我們，跟我們一起探討這些很有可能在如此大規(guī)模數(shù)據(jù)和如此高時效性要求下才會發(fā)現(xiàn)的問題，一起讓客戶有限的硬件能夠處理更大量級的數(shù)據(jù)。

分布式存儲團隊

采集的數(shù)據(jù)，最終要通過預(yù)處理環(huán)節(jié)后導(dǎo)入到存儲介質(zhì)中。而分布式存儲團隊，則主要圍繞著如何更有效率地存儲數(shù)據(jù)來進行工作。

存儲的效率可以從這幾個方面來衡量，數(shù)據(jù)寫入的效率、數(shù)據(jù)讀取的效率以及數(shù)據(jù)所占用的磁盤空間。數(shù)據(jù)寫入的效率，是指如何用盡可能短的時間，實時寫入盡可能多的數(shù)據(jù)；數(shù)據(jù)讀取的效率，則是指針對特定的數(shù)據(jù)讀取和掃描請求，如何在盡可能短的時間內(nèi)完成；數(shù)據(jù)所占用的磁盤空間，則是指相同的數(shù)據(jù)到底需要在磁盤上占用多少空間。

從具體的工作內(nèi)容上講，分布式存儲團隊會基于 Kudu、HDFS 等開源組件，在列存儲、數(shù)據(jù)壓縮算法、查詢算子下推、掃描預(yù)測算法、數(shù)據(jù)一致性等方面，進行深入的探索與研究。我們非常歡迎在分布式存儲方面有經(jīng)驗或興趣，或愿意參與對主流開源組件的修改與優(yōu)化的技術(shù)同學(xué)加入我們，一起繼續(xù)這方面的工作，探索如何用最好的方式，存儲每天千億級別的數(shù)據(jù)，并且在數(shù)據(jù)的寫入和查詢上達到一個平衡。

分布式查詢團隊

數(shù)據(jù)的查詢是數(shù)據(jù)的非常基本也是非常重要的應(yīng)用，以神策分析為例，作為一款用戶行為分析產(chǎn)品，最重要的就是要為客戶提供靈活快速的分析能力。從最初只有 3 個單薄的基礎(chǔ)分析功能，到現(xiàn)在支持 10 個復(fù)雜的分析模型聯(lián)合構(gòu)建的場景化分析能力，離不開對數(shù)據(jù)查詢引擎的深度開發(fā)。同時，面對數(shù)以 TB 級別的海量數(shù)據(jù)，如何還能保證隨機查詢的秒級響應(yīng)，也是分布式查詢團隊面臨的主要的挑戰(zhàn)。

分布式查詢引擎團隊的首要職責(zé)就是要配合產(chǎn)品設(shè)計，高效地實現(xiàn)各種靈活復(fù)雜的分析模型。這里所謂的“高效”，一方面指開發(fā)速度快、穩(wěn)定性高，另一方面也要求最終實現(xiàn)的功能在性能方面達到最優(yōu)。為此我們已經(jīng)做了大量的努力，例如我們基于 Impala 原有的執(zhí)行框架，設(shè)計實現(xiàn)了 Transform 數(shù)據(jù)處理模型，以此為基礎(chǔ)實現(xiàn)的各種分析模型，不但邏輯結(jié)構(gòu)簡單、代碼少，執(zhí)行性能也比使用 Impala 的原有方式有 10 倍以上的提升。同時，為了盡可能地為客戶節(jié)省寶貴的計算資源，也是進一步提高查詢的整體響應(yīng)速度，我們還研發(fā)了適用于用戶行為分析場景的查詢緩存機制。正是這層層優(yōu)化的不懈努力，保證了神策分析卓越的用戶體驗。

除了功能研發(fā)之外，分布式查詢引擎作為計算的“終結(jié)者”，如何保障其穩(wěn)定運行，亦是同樣重要的工作。神策眾多家客戶的環(huán)境可謂千差萬別，除了框架的保障，我們也開發(fā)了各種針對查詢的監(jiān)控及問題排查工具，以方便定位問題，節(jié)約運維成本。

不僅僅是神策分析，產(chǎn)品矩陣內(nèi)的很多其它數(shù)據(jù)產(chǎn)品，也需要用到查詢能力，分布式查詢團隊，還需要考慮如何為這些產(chǎn)品來提供統(tǒng)一的查詢能力，并進行相應(yīng)的性能優(yōu)化。在這個過程中，對于需求的抽象、架構(gòu)的設(shè)計都有很高的要求。

分布式查詢引擎的研發(fā)方向充滿挑戰(zhàn)，但這也同樣證明了我們團隊對技術(shù)的不懈追求。我們熱切期盼對分布式查詢引擎有所研究，并且熟練掌握 C/C++ 和 Java 語言的資深研發(fā)工程師的加入，與我們一起追求性能的極致，讓數(shù)據(jù)本身成為數(shù)據(jù)分析能力的唯一局限。

數(shù)據(jù)中臺團隊

神策數(shù)據(jù)目前正處于從單一產(chǎn)品向產(chǎn)品矩陣演進的過程中，而這多個產(chǎn)品都是圍繞數(shù)據(jù)處理展開的，所以每個產(chǎn)品都有數(shù)據(jù)導(dǎo)入、數(shù)據(jù)存儲、數(shù)據(jù)查詢這方面的功能需求。在這個前提下，數(shù)據(jù)中臺團隊的工作，就是對這些通用的數(shù)據(jù)處理能力進行很好的抽象與平臺化，讓我們在研發(fā)不同的產(chǎn)品時可以專注于產(chǎn)品本身的業(yè)務(wù)與功能，而不用從頭開始造輪子。

數(shù)據(jù)中臺團隊目前面臨的主要技術(shù)挑戰(zhàn)有：如何提供一個在產(chǎn)品功能需要急速迭代的情況下仍然能夠保證整個后臺穩(wěn)定可靠的業(yè)務(wù)開發(fā)框架；如何設(shè)計良好可靠且易擴展的 API 接口，既能滿足可視化團隊同學(xué)的使用需求，又能滿足深度集成客戶的 API 調(diào)用需求；如何在多個產(chǎn)品線既有大量的邏輯耦合又有自己的特殊要求的情況下劃分服務(wù)的邊界和進行微服務(wù)的設(shè)計；如何解決分布式事務(wù)和元數(shù)據(jù)緩存的問題。數(shù)據(jù)中臺團隊已經(jīng)在解決以上問題的過程中積累了豐富的經(jīng)驗，也進行了很多有效的嘗試，但同時我們也面臨著很多新的技術(shù)挑戰(zhàn)。

數(shù)據(jù)中臺團隊作為整個神策數(shù)據(jù)平臺前端請求的排頭兵和后臺查詢的守門員，承擔(dān)著非常多的產(chǎn)品功能迭代和產(chǎn)品矩陣化的需求，一方面需要團隊同學(xué)有著扎實的技術(shù)和代碼基礎(chǔ)，另一方面也需要對整個業(yè)務(wù)需求有著清醒的認(rèn)識和理解。我們也歡迎更多的對大數(shù)據(jù)產(chǎn)品后臺、業(yè)務(wù)框架開發(fā)、微服務(wù)設(shè)計感興趣，或者有 Web 開發(fā)相關(guān)經(jīng)驗的同學(xué)加入我們，我們可以一起一邊解決有挑戰(zhàn)性的技術(shù)難題，一邊去打造全新的有創(chuàng)造性的大數(shù)據(jù)分析產(chǎn)品。

基礎(chǔ)平臺化團隊

雖然與大部分 SaaS 公司在商業(yè)模式上一樣，都是以按年收取產(chǎn)品和服務(wù)費用為主。但與大部分 SaaS 公司不同的是，出于對數(shù)據(jù)隱私、數(shù)據(jù)安全性、數(shù)據(jù)的充分應(yīng)用等方面的考慮，神策數(shù)據(jù)在第一個產(chǎn)品的第一個版本，就具有私有化部署的能力。而隨著這幾年我們的客戶規(guī)模進一步擴大，大部分客戶也的確如我們預(yù)料的那樣選擇了私有化部署模式，私有化部署能力也客觀上成為我們的一大殺手锏。

不過，私有化部署也會帶來很多技術(shù)上的挑戰(zhàn)，如何能夠讓一套產(chǎn)品兼容不同的軟硬件環(huán)境，在數(shù)百上千個環(huán)境內(nèi)穩(wěn)定運行，如何能夠盡可能減少安裝、部署與運維的代價等等，都是客觀存在的技術(shù)難題。這幾年里，我們也注意到市場上的不少友商也先后嘗試私有化部署，有些也最終放棄了。這些都說明私有化部署相對于 SaaS 服務(wù)具有自己的獨特技術(shù)難題。

我們的基礎(chǔ)平臺化團隊就是致力于解決這類問題。他們工作包括兼容市面上各種不同的 Hadoop 發(fā)行版；開發(fā)無人值守、一鍵安裝的自動化部署工具；開發(fā)統(tǒng)一的資源調(diào)度與管理平臺等。我們歡迎在自動化運維方面有經(jīng)驗，或?qū)λ接谢渴鹩信d趣的同學(xué)加入我們，一起在這方面進行更加深入的探索。

用戶標(biāo)簽團隊

我們目前主要處理的還是用戶行為相關(guān)的數(shù)據(jù)，而在用戶行為相關(guān)的應(yīng)用上，基于用戶行為來理解用戶，據(jù)此生成用戶標(biāo)簽，完成對用戶的刻畫與畫像是一個廣泛存在并且非常有意義的應(yīng)用場景。也因為此，我們將于用戶標(biāo)簽、用戶畫像相關(guān)的工作單獨抽象成一個具體的技術(shù)方向。

用戶標(biāo)簽團隊主要負責(zé)與用戶標(biāo)簽的計算、管理、展示、查詢、審批、權(quán)限等功能的設(shè)計和研發(fā)工作，并與我們的數(shù)據(jù)分析師、行業(yè)專家團隊一起，抽象銀行、券商、零售等各個不同行業(yè)對于人群刻畫、用戶畫像方面的需求，與機器學(xué)習(xí)團隊一起選擇合適的算法完成對人群的分類與預(yù)測等。我們歡迎那些對于用戶畫像有興趣，或者有分布式數(shù)據(jù)應(yīng)用經(jīng)驗的同學(xué)加入這個團隊，一起探索用戶畫像與用戶標(biāo)簽在各個不同行業(yè)的落地與應(yīng)用。

數(shù)據(jù)可視化團隊

報表與多維查詢，都是非常直觀也非常有價值的數(shù)據(jù)應(yīng)用方式。而對這一類數(shù)據(jù)應(yīng)用類型來說，如何讓查出來的數(shù)據(jù)，以圖形化手段，更加清晰和有效地將信息傳達給數(shù)據(jù)的使用者，就是一個非常有意義的話題。從很多實際的例子中我們可以知道，同樣的一組數(shù)據(jù)，可視化展示得好還是不好，會直接影響使用者對于數(shù)據(jù)的解讀，從而最終影響基于數(shù)據(jù)做出的決策。因此，在我們看來，數(shù)據(jù)可視化并不是一個讓數(shù)據(jù)“好看”的花里胡哨的工作，而是一種真正專注于讓揭示繁雜的數(shù)據(jù)背后的規(guī)律，給使用者提供靈感，輔助使用者完成決策的很有意義的事情。

具體到實際的工作中，數(shù)據(jù)可視化團隊需要從頭研發(fā)或者基于開源組件，完成各個分析模型分析結(jié)果的圖表化展示，以直觀便捷的方式讓使用者能夠與數(shù)據(jù)進行交互，方便地完成數(shù)據(jù)的鉆取與篩選。同時，數(shù)據(jù)可視化團隊還有一部分工作是完成產(chǎn)品矩陣內(nèi)各個產(chǎn)品的用戶交互界面的開發(fā)。我們非常歡迎對數(shù)據(jù)可視化感興趣，有一定前端開發(fā)經(jīng)驗的同學(xué)們加入這個團隊，一起開發(fā)一個極美觀與易用性一體的數(shù)據(jù)產(chǎn)品。

機器學(xué)習(xí)團隊

大數(shù)據(jù)與機器學(xué)習(xí)，在很多應(yīng)用場景上是一體兩面。除了神策推薦這樣一個一聽名字就知道用到了機器學(xué)習(xí)技術(shù)的個性化推薦產(chǎn)品以外，在神策分析、標(biāo)簽和運營產(chǎn)品中，機器學(xué)習(xí)技術(shù)也廣泛得到了應(yīng)用。例如，在神策分析中，我們需要用到機器學(xué)習(xí)技術(shù)來預(yù)測流量趨勢，當(dāng)數(shù)據(jù)發(fā)生異常時來自動發(fā)現(xiàn)異常主要體現(xiàn)在哪些維度上，或是找到某個特定流程中完成了轉(zhuǎn)化和未完成轉(zhuǎn)化的兩類典型客戶群體在用戶屬性和行為上有什么差異。在神策標(biāo)簽和運營產(chǎn)品中，機器學(xué)習(xí)技術(shù)也被廣泛用于對用戶的精準(zhǔn)識別、預(yù)測和運營中。也正因為如此，我們的機器學(xué)習(xí)團隊除了繼續(xù)開發(fā)、交付神策推薦產(chǎn)品之外，還需要和其他團隊的同事一起合作，探索機器學(xué)習(xí)技術(shù)在其他幾個數(shù)據(jù)產(chǎn)品中的落地可能性等。

機器學(xué)習(xí)團隊內(nèi)部分為算法與策略工程化兩個技術(shù)方向，算法方向的同事會更專注于算法本身的選擇、開發(fā)與調(diào)優(yōu)，而策略工程化方向的同事則會更專注于算法的工程化、數(shù)據(jù)流的開發(fā)，服務(wù)的穩(wěn)定性等。我們非常歡迎對機器學(xué)習(xí)有興趣，愿意在真實的海量數(shù)據(jù)環(huán)境下驗證算法的實際效果的同學(xué)們加入我們，一起來探索數(shù)據(jù)除了分析報表以外，還能有哪些更智能的、更有趣的應(yīng)用。

謹(jǐn)以此文章，獻給在人生十字交叉口徘徊、或在求職路上迷茫、或?qū)Υ髷?shù)據(jù)和數(shù)據(jù)分析感興趣、或渴望加入我們卻不知突破點的有志之士們，希望對你們有所幫助！

?

更多詳情，可關(guān)注【神策數(shù)據(jù)】公眾號了解~?

總結(jié)

以上是生活随笔為你收集整理的为了找到你，CTO 和你唠唠研发都做啥？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。