中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

數據工具產品很重要，但是這方面的人才卻很稀缺。本篇文章作者結合自己的數據產品經驗，介紹了數據探索平臺設計——“CheckStyle”。

在產品的龐大家族中，有一類很重要的產品，他就是工具產品，工具產品具備強服務性，并且使用場景時效性極強，高效便捷的工具極大的方便了我們的生活。

隨著大數據時代的帶來，在工具產品中又衍生出了數據工具產品，隨著數據的增長，數據的價值也亟待我們去挖掘，各大公司正在積極挖掘數據價值，并組建自己的數據團隊，包括數據分析師、數據科學家、數據產品經理、數據工程師等等。

在這樣的契機下，數據探索平臺應運而生，作為一款數據工具產品，數據探索平臺核心功能便是數據開放和探索，支持數據分析師、數據科學家和數據工程師等數據團隊成員和咨詢、BD等業務團隊成員，用他們習慣和擅長的工具，協同進行數據科學項目。

數據工具產品很重要，與此同時，這方面的人才卻很稀缺。

數據工具產品經理不僅僅要求傳統產品經理的基本能力，還對技術背景和大數據架構有一定要求，這里我們不妨看一下業界領先數據產品阿里云對數據產品經理的要求：

阿里云-高級數據產品經理

級別：P7\P8
地點：北京、杭州均可

負責ApsaraDB數據庫產品設計，ApsaraDB數據庫服務是阿里云核心的數據類的產品，是阿里云最為重要的PASS平臺之一。
工作內容：
1. 完成市場調研與競爭對手分析，準確定義數據庫/大數據具有市場競爭力的產品
2. 規劃產品的生命周期和交付形態，對項目結果負責
3. 關注用戶體驗負責，產出安全、穩定、易用的產品
4. 組織研發、測試、運維、運營的高效溝通
5. 支持業務團隊完成營收目標

要求：
1. 計算機科學領域（CS）學士或碩士學位
2. 對大數據架構基本了解，有一定的大數據架構經驗
3. 了解以下Hadoop\Spark\HBase\MongoDB\Redis優先
4. 了解數據庫基本理論、大數據基本理論、云計算
5. 程序員/DBA出身優先
6. 了解大數據方案優先

在我們平時閱讀的文章中，也會看大數據技術相關文章：

類似于《Hadoop架構原理》以便于了解我們數據探索平臺底層數據存儲架構，從而更好的做數據開放和探索。

類似于《為什么Jupyter是數據科學家們實戰工具的首選？》以便于了解我們數據探索平臺用戶的日常工作，以更好的迭代產品，讓科學家們用起來更順暢。

數據工具產品很重要，數據工具產品人才很稀缺，自然，數據工具產品文章也很少。

基于此，結合自己的數據產品經驗，簡單談一下數據探索平臺設計中的一個Feature，“CheckStyle”，和大家探討，希望起到拋磚引玉的效果。

本文核心觀點：

因為用戶編寫的代碼可能存在質量差、性能低、不規范、語法錯誤等問題。CheckStyle將使用我們TD的規則庫，通過平臺和流程來保障代碼質量，希望能盡早、盡快、無感解決故障隱患，以節約時間，提高效率，降低出錯率。

短期內會通過代碼樣例，API半自動化實現，結合實踐不斷完善規則庫形成閉環，最終實現自動優化。

同時在一定程度也可以提升用戶的技能，這也是平臺“自動化”的重要一步。

設計前的小故事

為什么想到設計“CheckStyle”這個Feature呢？

主要是昨天和一位數據分析師同學閑聊，聽到她隨口吐槽一件工作中的小事，見微知著，聊一下數據探索中的“CheckStyle”需求，和大家一起探討哈。

對話大意：

“最近咋樣??？”省略N個字。

進入正題：

分析師：“實習生寫的SQL真是令人痛心，一堆錯?！?/p>

權：“一堆錯？規范問題？語法問題？業務問題？性能問題？或者，都有？”

分析師：“都有，畢竟是實習生?！?/p>

果斷先diss她幾句，招人時咋不想清楚，有經驗的好一點，沒經驗的就要做好培養的準備，而且必然是一段時間細致的培養，答復，雖然她也做了準備，但確實需要時間。

權：“那你現在咋辦？”

分析師：“能咋辦，遇到問題解決問題，一個個看唄！”

權：“那個人力量有限啊，你時間有限，而且我們也只能說熟練使用SQL，不能說精通，大多數場景能搞定，遇到一些問題也需要查，這種事最好交給機器做，產品化。”

分析師：“有意思，說說看。”

權：“我想想，寫篇文章總結一下，大家一起探討吧！”

對話基本結束。

一段簡短的對話，一件工作中的常見的小事，但可以挖掘的點很多。

下面說一下我的想法，“CheckStyle”。

一、“CheckStyle”是什么？

1. 背景

工作中類似的問題太多了，用戶編寫的代碼可能存在質量差、性能低、不規范、語法錯誤等問題。

這里的用戶包括：咨詢、分析師、工程師、科學家等。

這里的代碼包括：SQL、Python、Scala、R等。（SQL、Python、Scala、R皆為編程語言）

2. 具體場景

這么一說大家感受可能不深。

我們再來看幾個鮮活的例子，看一線中的具體場景：

1. 前段時間一位數據科學家同學因為輸出數據集目錄命名不規范，導致和DSS的時間分區功能沖突。

數據科學家在我們印象中已經比較專業了，但依然有可能發生偏差。

其實“是人就可能會出錯”，因此需要相應的規則和流程來約束，減少出錯率。

2. 前天看到一篇Python性能提升的文章，大意如下：

Python 是機器學習領域內的首選編程語言，它易于使用，也有很多出色的庫來幫助你更快處理數據。但當我們面臨大量數據時，一些問題就會顯現，因為在這樣的量級上，工作進程中加入任何額外的計算都需要時刻注意保持效率。

在默認情況下，Python程序是單個進程，使用單 CPU 核心執行。而大多數當代機器學習硬件都至少搭載了雙核處理器。

這意味著如果沒有進行優化，在數據預處理的時候會出現「一核有難九核圍觀」的情況，超過 50% 的算力都會被浪費。在當前四核處理器（英特爾酷睿i5）和6核處理器（英特爾酷睿i7）大行其道的時候，這種情況會變得更加明顯。

幸運的是，Python庫中內建了一些隱藏的特性，可以讓我們充分利用所有CPU核心的能力。通過使用Python的concurrent.futures模塊，我們只需要3行代碼就可以讓一個普通的程序轉換成適用于多核處理器并行處理的程序。

測例是將1000張圖片被傳遞到深度神經網絡之前將其調整為600×600像素分辨率的形式。

優化前在酷睿 i7-8700k 6核CPU上，運行時間為7.9864秒，在這樣高端CPU上，這種速度讓人難以接受，優化后運行時間降到1.14265秒，速度提升了近6倍！

看完之后確實是拍手稱快，又get了一項新技能，使用Python的concurrent.futures模塊做性能優化，節約時間，提升效率。

同時想到之前我想落地線下消費標簽使用的一份poiid數據集，代碼早早的寫好，然而排隊等待集群資源運行就等了1天。

查了一下原因，也沒有大任務阻塞集群，確實是大家的任務很多，一個接一個。

3. 解決問題

想要解決，從供需兩端考慮：

• 供給端，擴展集群資源，這個我們正在做，升級到新集群。
• 需求端，大家任務多，集群資源有限，必然存在矛盾，這時可以評估任務的優先級，保證緊急任務優先處理，另一方面，總體任務數量和順序優化后，我們也可以對單個任務的運行時間和效率進行優化，優化代碼，做性能提升，從而提升整體運行效率。

要想優化代碼，做性能提升：

• 會對用戶有更高的技能要求，督促用戶自我提高，在這方面TDU有也相關技能課幫助提高，但畢竟術業有專攻，是不是應該降低用戶的技術門檻，讓其更專注于在具體業務和場景中探索數據價值。
• 學習需要時間，且學無止境，不建議讓用戶承載過多的負擔。

因此，代碼性能提升我可能更傾向于平臺側智能管理，平臺自動優化提升性能，并info給用戶相關建議，感興趣的用戶可以參考info自我提升，進一步學習并反饋規則給TD規則庫，形成閉環不斷優化。

不感興趣的用戶可以直接忽略優化info專注業務，平臺自動優化運行，做到無感體驗，不知不覺中提升整個集群任務的運行效率。

4. 未來趨勢

未來趨勢也應該是朝“自動化”方向走。

現在我們Data ATM數據提取平臺的運行機制類似，前端展示極簡的界面，用戶拖過簡單拖拽完成任務的輸入輸出，后端是將用戶選擇的模塊轉化為SQL在提交到GP網關（Greenplum數據庫）。

即降低用戶的技術門檻，讓其更專注于在具體業務和場景中探索數據價值。

以計算2018年9月APP活躍設備數統計為例：

在用戶操作層面，用戶可以感知的就是簡單拖拽活躍設備和篩選設備統計兩個功能模塊，然后選擇時間2018-09，僅此而已，完成數據提取。

大大降低用戶的操作門檻，這也是我們數據提取平臺的初衷，讓業務人員（銷售、咨詢等）在不懂SQL等語言時也能通過簡單拖拽完成數據提取，讓其更專注于在具體業務和場景中探索數據價值。

數據提取平臺，作為一款數據產品，簡單易用的背后是什么？

還是看這個例子：

作業轉化為SQL語句，然后提交到GP網關，SQL語句大致如下：

我們做了什么？

1. 模塊的封裝，對應底層數據集，如活躍設備模塊對應device_app_active系列數據集；
2. 選項的封裝，對應底層數據集相應字段，如2018-09時間對應數據集的monthid；
3. 作業的封裝，將作業所有條件轉化為SQL語句；
4. UDF（User Defined Function，用戶自定義函數）的定義，復雜操作通過UDF實現并優化；
5. 數據結構的定義，使用Bitmap，大大提升計算效率；
6. 數據庫選型，使用GP，提升整體效率。
7. ……

好的工具，真正讓用戶易用，易用背后的邏輯我們沉淀，我們做的多，用戶想的少。用戶專注于數據業務，讓業務方和工具平臺都發揮最大的價值。

發生上述這些問題，有些可能是初出茅廬不諳世事的實習生，無經驗，技能上的短板、未養成好的規范，也可能是現在玩轉業務，熟練SQL的高級數據分析師，畢竟學海無涯，技能上的盲點永遠存在。

還可能是用戶有相關經驗，但就是百密一疏，或者寫代碼一時隨意， 最終結果將會因為一人疏忽造成整個集群任務隊列效率低下，或者之后運用時出現意想不到的錯誤。

相關問題還是需要嚴格的約束，從平臺和流程層面管控。

將數據探索任務中遇到的各種問題整理后，結合開源規范，一起作為我們TD的規則庫。

綜上在此嚴格定義一下CheckStyle：

CheckStyle將使用我們TD的規則庫，通過平臺和流程來保障代碼質量，希望能盡早、盡快、無感解決故障隱患，以節約時間，提高效率，降低出錯率。

短期內會通過代碼樣例，API半自動化實現，結合實踐不斷完善規則庫形成閉環，最終實現自動優化。

二、為什么要做“CheckStyle”？

在說完什么是CheckStyle后，再來說為什么要做CheckStyle就很清晰了。

1. 動力

因為用戶編寫的代碼可能存在質量差、性能低、不規范、語法錯誤等問題，通過CheckStyle可以盡早、盡快、無感解決故障隱患，以節約時間，提高效率，降低出錯率。

同時在一定程度也可以提升用戶的技能，完善我們TD規則庫。

這也是平臺“自動化”的重要一步。

2. 阻力

代碼樣例的梳理和準備。

規則庫的制定，包括常見問題和開源規范的梳理。

產品研發側的設計和研發，DataCloud已經停止迭代，綜合考慮DSS需求池和研發資源的現狀，現在有支持新集群等緊急需求在做，本需求相對而言優先級低一些，可以后續排期考慮。具體研發細節可以一起討論。

三、怎么做“CheckStyle”？

我們不妨參考借鑒一下同行，挑選國內外的兩款優秀競品，這里選擇國外的Dataiku DSS和國內的阿里云數加：

1. Dataiku DSS 實踐

Dataiku DSS還處于一個相對早期的狀態，在“CheckStyle”這一塊的實踐主要是Validate和code samples：

1. Validate功能會檢查查詢語法錯誤和Schema的一致性問題。
2. code samples功能則是插入代碼樣例，供用戶參考編輯。

2. 阿里云數加 實踐

我和阿里云的同學們溝通過，確實是踩過了很多坑，在推廣過程中碰到大量的SQL優化問題，我們的結論也一致，無論是通過培訓還是其他方式，其實都遠沒有系統固化規則更好，用系統流程化的方式解決問題是平臺能夠規模化的核心要素。

數加也確實走在行業的前列，基于IntelliJ IDEA開發插件MaxCompute Studio，MaxCompute 編譯器是新一代的SQL引擎，顯著提升了SQL語言編譯過程的易用性與語言的表達能力。

定制化開發，更加靈活，功能強大。

本篇主要介紹以下兩點：

（a）MaxCompute Studio會對代碼進行靜態編譯檢查并給出修改建議，同時有計算健康分體系，提交有錯誤的腳本會被扣計算健康分，導致以后提交任務的優先級被下調。

（b）使用MaxCompute SQL，規范代碼，預防預期外的錯誤，并對代碼運算效率進行優化。

2.1 MaxCompute Studio

如上圖，靜態編譯發現第一個 insert 語句中的UDF wm_concat函數參數錯誤。

如上圖，鼠標停止在錯誤或者警告上，會直接提示具體錯誤或者警告信息。如果不修改錯誤，直接提交，會被 MaxCompute Studio 阻攔。

修改完畢后，再次提交，便可以順暢運行。

2.2 MaxCompute SQL

基于SQL，使用MaxCompute SQL，規范代碼，預防預期外的錯誤，并對代碼運算效率進行優化：

（a）代碼規范，如別名，即子查詢必須要有別名。建議查詢都帶別名。

（b）預防預期外的錯誤，如精度問題，Double 類型因為存在精度問題，不建議在關聯時候進行直接等號關聯兩個 Double 字段。一個比較推薦的做法是把兩個數做下減法，如果差距小于一個預設的值就認為是相同，比如 abs(a1- a2) < 0.000000001。

（c）代碼優化，如分區裁剪，對分區列指定過濾條件，使得 SQL 執行時只用讀取表的部分分區數據，避免全表掃描引起的數據錯誤及資源浪費。

3. TD 實踐

具體落地可以先從SQL語言及相關用戶入手，后期視情況慢慢推廣：

1. 代碼樣例的準備，結合日常工作中的常見作業，總結提煉幾套常見的代碼樣例和常用語法。

2. 規則庫的制定，包括常見問題和開源規范的梳理，目前規則可以分為以下幾類：

（1）語法類規則，如類方法的歸屬問題，主要由編譯器處理；

（2）規范類規則，如表、目錄的命名規范，注釋等，不斷總結+借鑒開源規范；

（3）質量類規則，如參數檢查、分母0、NULL值等，不斷總結+借鑒開源規范；

（4）性能類規則，如并行計算、分區、重復計算、大表裁剪等，不斷總結+借鑒開源規范；

（5）其他規則。

3. 產品研發側的設計和研發，整體流程：

（1）平臺側配置好規則庫；

（2）用戶提交代碼后，結合規則庫進行校驗；

（2.1）平臺可以自動化處理重要缺陷，顯示相關info，任務提交運行；

（2.1.1）感興趣的用戶可以參考info自我提升，進一步學習并反饋規則給TD規則庫，形成閉環不斷優化；

（2.1.2）不感興趣的用戶可以直接忽略優化info，專注業務，做到無感體驗，相關info記錄留存，供資深分析師總結規則并反饋規則給TD規則庫，形成閉環不斷優化；

（2.2）平臺無法自動化處理重要缺陷，顯示更改tip，任務被阻斷，用戶可以結合更改tip，并可請教資深的分析師一起協助修改，修復代碼后才可提交，并在此檢驗規則，同時將規則反饋給TD規則庫，形成閉環不斷優化；

（3）完成任務提交，不知不覺中提升整個集群任務的運行效率，最終實現盡早、盡快、無感解決故障隱患，以節約時間，提高效率，降低出錯率。從長遠考慮，將自研和借鑒市場上的SQL Studio，定制化開發，更加靈活。

綜合考慮DSS需求池和研發資源的現狀，短期內可能還是：

1. 準備代碼樣例；
2. 在實戰中總結規則，結合開源規范不斷完善規則庫；
3. 對用戶進行規則庫和代碼樣例的相關培訓，并結合TDU的優質教育資源，進行專項技能提升（備注：相關培訓可以視用戶的興趣和時間酌情參與，但最好有幾位資深分析師全程深入學習，以備在關鍵時刻提供相關指導）；
4. 同時根據規則在平臺側封裝相關API供用戶使用，結合實踐不斷完善規則庫形成閉環，最終實現自動優化。

最后，引用曾鳴老師的一段話：

“未來創業很重要的一個方向就是把傳統上大家認為必須由人來做的服務，把它中間越來越多的環節拆解，變成可以在線化、機器化、智能化完成的任務?！?/p>

個人認為，這也是數據工具產品的發展方向，復雜工作簡單化，簡單工作智能化。

以上便是我關于“CheckStyle”的初步想法，歡迎大家一起探討。

作者：楚權（MR.Quan），東北大學2016屆畢業生，TalkingData高級數據產品經理，熱愛數據&產品&技術，不斷挑戰自我。

本文由 @楚權?原創發布于人人都是產品經理。未經許可，禁止轉載。