個推透明儲存實踐
列式儲存（Column-oriented Storage）是大資料場景中面向分析型資料的主流儲存方式。與行式儲存相比，列式儲存只提取部分資料列、同列同質資料，具有更優的編碼及壓縮方式。目前，個推的核心資料正逐步切換為Parquet等新型資料格式儲存以獲得更高的I/O效能和更低的儲存成本。
個推資料部降本提效團隊 資深資料研發工程師筱得圍繞透明儲存概念、檔案讀取流程、透明儲存實現方式等，為大家詳細解讀了個推透明儲存優化的全過程。
分享過程中的相關問答：
Q1：如何量化和評估透明儲存的收益？
A：量化維度分兩方面，首先是從提效方面來衡量，即使用效率是否提升，比如使用者（資料分析師）處理業務需求時的資料使用效率提升情況。目前我們結合多個型別的任務綜合來看，透明儲存能夠使跑數時間縮短30%；其次是降本方面，即資源消耗是否有減少，可以通過CPU核的使用時長以及記憶體使用時長進行量化評估。
Q2：透明儲存如何實現歷史工程對資料格式的相容和切換？
A：在相容方面，我們是通過擴充套件Hadoop的讀寫API，來增加儲存格式自動識別和切換能力；在切換方面，我們先對Hadoop、Spark的提交命令進行了擴充套件，增加hook，並引入了切換資料格式的黑白名單，從而讓任務啟動時能夠獲取要變更的資訊；通過以上方式，最終實現了對歷史工程的資料格式無感知切換。
標籤存算在每日治數平臺的實踐之路
個推依託海量資料資源和強大的建模能力，形成3,000餘種資料標籤，構建了豐富、立體、多維的畫像標籤體系，從而為行業客戶提供資料洞察相關服務，比如APP精細化運營、廣告投放人群定向等。
由於業務方的標籤組合複雜多樣，所以在對大規模資料進行計算和標籤構建的過程中，如何加速標籤計算，實現秒級人群圈選和洞察便成為我們需要攻克的難題。
個推每日治數平臺團隊 高階資料研發工程師之昂基於每日治數平臺DIOS的開發實踐，深度剖析了有效提升標籤存算以及人群圈選效率的核心技術手段。
分享過程中的相關問答：
Q1：Spark的shuffle和Hadoop的shuffle（MapReduce)有什麼區別？
A：MapReduce的shuffle和Spark的shuffle在功能上是幾乎沒有區別的，都是對Map端的資料進行分割槽（有聚合排序和不聚合排序兩種方式），然後在Reduce端或者下一個排程階段拉取資料，從而完成Map端到Reduce端的資料傳輸功能。
Q2：直播中講到ClickHouse不支援高併發，原因是什麼？對於叢集的ClickHouse寫入，有哪些需要注意的地方？
A： ClickHouse之所以快是因為底層採用了並行處理機制，預設單次查詢使用的CPU核數是伺服器核數的一半，所以對高併發的使用場景支援得不是很好。如果一定要支援高併發，建議在查詢層增加限流。
提升IT資源效率，顯著降低IT總投入
降低企業IT成本的一個有效手段是大幅提升IT資源的利用效率。麥肯錫的一份研究報告顯示，全球伺服器的平均每日利用率通常低於10％，Flexera的一份報告也顯示，企業上雲後平均浪費了30%的雲支出，雲成本優化是企業在2021年最想做的事情。那麼如何提升IT資源效率，降低IT總投入？
來自貝聯珠貫的楊少華博士為大家分享了大資料任務優化、在/離線混部等能夠有效提升IT資源效率的核心技術手段。
分享過程中的相關問答：
Q1：一般如何實現在/離線混部？
A： 不同公司的實現方式可能不一樣。我們是這樣做的：Step1. 將離線任務通過k8s排程到線上機器上；Step2. 使用Agent動態調節在/離線資源的配額；Step3. 利用核心的一些隔離技術進行隔離，在必要時進行干預，例如在緊急情況下限制離線任務的資源，這種方式會對機器核心版本有一些要求。
Q2：對於Spark/Flink on k8s，是引入YuniKorn/Volcano等第三方排程外掛，還是自研類似元件來解決計算資源分配和管理的問題呢？
A： 我們的方案主要還是Yarn on k8s，然後Spark/Flink on Yarn。這裡主要考慮的是客戶對接的侵入性問題，大部分情況下上層資料開發平臺都還是接Yarn。