大數據

2021年6月24日，中國信息通信研究院（以下簡稱“中國信通院”）在北京主辦“2021大數據產業峰會成果發佈會”，發佈會上信通院第十二批“大數據產品能力評測”結果正式公佈，阿里雲實時計算 Flink 版通過分佈式流處理平臺測評，成為國內首批通過測試的廠商。據瞭解，該專項測試是信通院今年首次開設的全新資質測評方向，僅2款產品通過本次測評。 近年來，“中國信通院大數據產品能力評測”作為國內首個大數據產品權威評測體系，已成為廠商產品研發和用戶採購選型的風向標。本次阿里雲實時計算 Flink 版在該項性能測評中，通過了12個子項目評測，作到整體性能較開源項目提高200%；在應用場景的檢測中，實時計算 Flink 版實現在億級數據高壓環境下，數據不重不丟和精準一致，高分通過本次測評。 作為國內最早佈局實時計算技術方向的企業之一，早在2016年阿里巴巴就已經開始大規模上線使用實時計算產品。本次通過測試的阿里雲實時計算 Flink 版，是國內完全以“Ververica Platform”為內核的阿里雲產品。實時計算 Flink 版產品相對於開源 Apache Flink擁有更具優勢的功能和穩定性，除了運維方面的優勢，開箱即用也讓用戶更加方便。 實時計算 Flink 版產品在阿里巴巴的發展歷程 實時計算 […]

還在手工統計組織內成員的疫苗接種情況嗎？ 還在用Excel文件傳輸的方式來蒐集大家的接種信息嗎？ …… 現在，放棄上述方式吧！ 釘釘宜搭已經在模板市場上架了全新模板——帶消息提醒功能的新冠疫苗接種統計模板，在線提報，一人一入口，提報安全又方便！ 模板地址 點擊入口>>>>新冠疫苗接種統計模板 即開即用 適用場景 用於組織內統計當前成員疫苗接種的場景，並可通知未接種的成員儘快完成疫苗接種。 模板特點 1、根據新冠疫苗接種階段、品牌進行了數據統計。 2、數據管理頁配置了可視化圖表，統計情況一目瞭然。 3、支持消息提醒功能，可通知未接種的成員儘快完成疫苗接種。 現在，放下手中的蒐集表，試試即開即用的接種統計模板吧！ 點擊體驗新冠疫苗接種統計模板 ——宜搭動態 | 掃碼關注—— 

竹翁，OceanBase 內核研發總監 楊志豐，花名竹翁，畢業於北京大學，長期從事分佈式系統和數據庫的研發工作，現於阿里巴巴/螞蟻金服自主研發的分佈式關係數據庫 OceanBase 團隊負責研發工作，致力於把設計先進的 HTAP 數據庫系統打造成技術業內標杆的核心基礎設施。在 OceanBase 系統中，他先後負責研究 OceanBase 的 SQL 引擎、分佈式主控模塊、多模數據庫方向以及 OceanBase 的數據庫平臺產品研發，並於近期開始負責內核創新研發工作。竹翁對 C++、分佈式系統原理、SQL 查詢處理、事務處理、編譯技術、工程效率等方面具有深入的理解。 引言 在數據庫 OceanBase

本文整理自直播《基於Hologres的實時數倉新架構-金曉軍(仙隱)》視頻鏈接:https://c.tb.cn/F3.0dOBIZ 典型業務場景列舉 提到實時數倉，我們可以看一下數據業務典型的應用場景。 如上圖所示，第一類場景是實時大屏。如今一般來說，不管是做to C還是to B的業務，或者說給上司看，都喜歡做一個業務大盤，來展現整個業務的運行情況。 第二類場景是BI報表，這類業務是從傳統的離線BI報表產生的，只不過隨著實時數據、實時業務的需求越來越旺盛，所以實時BI報表的需求也越來越多。 第三類場景是用戶畫像，不管是做金融還是做推薦，都是做千人千面，希望能夠通過歷史數據、用戶行為數據得到用戶的興趣，來給用戶提供更好的服務。 第四類場景是預警監控，或者說是流量監控。不管是做APP的還是做服務器端的監控，最終都是把數據收集上來，以這樣大盤的形式進行展現。最終可以在這些預警指標進行報警，來保證監控業務的穩定性。 數據業務無論是離線還是實時，大致可以分為以上這麼四類。 傳統數據倉庫數據處理流程 接下來我們看一下傳統離線數倉是怎麼樣的一個處理流程。 上方是一個典型的傳統離線數倉的數據處理鏈路。 首先，從業務系統CRM、ERP或者其他數據源把這些業務數據收集上來，然後經過離線數倉的ETL，然後對數據的話進行數據清洗、數據加工。在這個過程中涉及數據建模、數據分層，最終會把加工後的數據，或者是最終要產生BI報表的數據，通過BI工具或者寫到數據庫裡面，推到一個在線系統裡面去，最後提供給用戶進行訪問，這些用戶可能包括產品的用戶、運營同學或老闆。 用戶希望能夠從這樣的數據裡面看到，比如整個產品的售賣情況，或者業績的增長趨勢，系統的一些指標等，這就是一個比較典型的離線數倉的處理流程。 批量數據分析流程有以下幾個特點： T+1數據接入多種數據源接入 定時數據開發與應用1）數據提取/數據轉換/數據加載2）ODS數據處理3）DWD標準數據場景4）MDM元數據5）數據集市應用 核心痛點1）ETL計算/存儲/時間成本過高2）數據處理鏈路過長3）無法支持實時/近實時數據分析 Lambda：割裂的架構，需要變革

尊敬阿里雲用戶： 感謝大家在公測期間對遷移助手的支持，DataWorks遷移助手將在2021年8月1日開啟商業化，部分功能需要在DataWorks增值版本中使用， 具體區別參考如下： 如果您有需要開通增值版本，請前往DataWorks官網https://dw-common-buy.data.aliyun.com/?frompath=/plan

背景 日常的數據庫優化中，在數據庫的表上創建合適的索引是解決慢SQL查詢問題的一種非常重要且常用的方案。在處理過程中，DBA或者開發人員通常會根據實例上的慢SQL信息進行優化，DAS自動SQL優化功能已經實現了根據慢SQL進行自動診斷，並創建合適的索引。但該方案會面臨如下幾個挑戰： 數據採集問題：一些業務SQL並沒有達到慢SQL採集的閾值（比如1s），而這些SQL查詢本身沒有很好的利用索引，查詢效率不高，仍然有很大的優化空間。在併發量增大或者表數據增多的情況下，這些查詢很容易造成實例性能突然惡化而引起故障。 寫入代價問題：在創建索引時通常更注重提高數據讀取的效率，而忽略索引維護對寫入性能的影響和空間佔用的成本，對於寫多讀少的表，創建太多索引反而會影響系統吞吐。 workload變化問題：索引一旦創建，通常情況下很少變化，而業務卻一直在動態變化中。隨著業務不斷迭代變化，一些索引可能不再有SQL使用，或者使用頻率很低，此時需要引入更優的索引設計來提升數據庫的處理性能。 為了解決上述問題，DAS推出了全局Workload優化功能，它可以及時檢測到數據庫的負載變化，識別到新增SQL、執行變化的SQL以及性能不佳的SQL，並綜合考慮SQL的執行頻率和相關SQL信息，給出優化建議。 解決方案介紹      全局Workload優化，主要由三部分組成。      Workload檢測：根據數據庫實例上和Workload相關的性能指標(如RT，CPU等)以及全量SQL相關指標(執行次數、執行耗時、掃描行數等)，訓練數據模型，實時檢測Workload的SQL執行情況，從而識別新增SQL、執行變化的SQL，以及整個負載變化的週期。       如下圖所示，全量SQL執行狀況指標在period1和period2呈週期性狀態，至period3，執行狀況發生變化。全局Workload優化，根據數據訓練模型，輕鬆實現識別負載變化的時間區間。     全局診斷：全局診斷優化則根據數據庫在某一時間範圍內的全部SQL執行情況，綜合考慮SQL的查詢和寫入性能以及空間佔用情況，推薦最優索引組合，從而從SQL角度最大限度提高數據庫的性能，降低數據庫導致的問題的概率。

前言 本文翻譯自大數據技術公司 Databricks 針對數據湖 Delta Lake 系列技術文章。眾所周知，Databricks 主導著開源大數據社區 Apache Spark、Delta Lake 以及 ML Flow 等眾多熱門技術，而 Delta Lake 作為數據湖核心存儲引擎方案給企業帶來諸多的優勢。 此外，阿里雲和 Apache

簡介 數據分析中經常會用到很多統計類的方法，本文將會介紹Pandas中使用到的統計方法。 變動百分百 Series和DF都有一個pct_change() 方法用來計算數據變動的百分比。這個方法在填充NaN值的時候特別有用。 ser = pd.Series(np.random.randn(8)) ser.pct_change() Out[45]: 0 NaN 1 -1.264716 2 4.125006 3 -1.159092 4 -0.091292

業務背景: DAS(Database autonomy service)為上百萬數據庫實例的穩定運行保駕護航，其中精準定位數據庫運行過程中的異常SQL是DAS最基本的功能。數據庫90%以上的問題都來源於數據庫的異常請求，無論是雙十一的集團海量交易請求行為，還是用戶業務變化的請求行為，每時每刻都影響著數據庫的性能。自動駕駛汽車通過感知路況圖像變化的行為來掌握車的方向，而自動駕駛數據庫通過感知和識別用戶請求行為來不斷修復優化數據庫的各種問題，為雲數據庫保駕護航。如何從海量數據庫中的海量請求定位出不同數據庫引擎不同場景的問題是多年以來困擾DBA的難題。在推薦領域，通過分析用戶的行為習慣代替了機械式網頁展示精準推薦給用戶期望的文字/視頻/產品，提升用戶體驗和產品轉化率，同樣下一代數據庫自動駕駛平臺也需要分析用戶請求行為，用戶開發業務行為，推薦出相應優化修復擴容等操作，提升自動駕駛數據庫的效率，讓數據庫更快更穩更安全。所以從用戶請求行為和業務行為出發，在海量數據庫實例的海量請求中進行數據挖掘是一個非常值得深入研究的課題，同時也是數據庫自動駕駛平臺非常依賴的底層技術能力, 向上支撐DAS數據庫自治服務各個場景的自治能力。 DAS這這些年提供了多個對SQL數據進行分析的L2功能包括：專業版SQL洞察，全量SQL，慢日誌， 一鍵診斷， 鎖分析，會話等。每一個功能沉澱了DBA在不同角度分析不同問題的方法，不同實例，不同業務診斷問題的方法略有不同。對於並不是很熟悉DB運維的用戶來說，DAS在提供一個統一高效簡單的方式去幫助用戶去定位問題。我們結合SQL變慢的多指標特徵，提出一種基於特徵相似度匹配的方法 VLDB 2020 沉澱到自治中心功能當中, 但對於異常SQL中存在的業務屬性的相似性以及錯綜複雜的影響與被影響的關係，理清楚問題SQL與各種資源的異常現象的傳播關係是具有挑戰的問題，DAS團隊仍然在如何找到異常SQL這個課題上繼續進行了研究和探索，在探索的過程中我們提供了一個新的分析功能SQL請求行為識別幫助用戶更好的定位SQL問題。 問題描述: 以下圖為例，實例CPU出現尖刺突增的現象，數據庫有cpu打滿潛在風險，當用戶的請求量較少或者請求的SQL模式較少的時候，通過指標的排序篩選是很容易找到問題SQL的，但當用戶的全量SQL模板超過上萬甚至上億條，用戶通過當前DAS頁面無法快速定位異常SQL，我們需要通過更多數據提供更高效的方式，來定位異常請求。 當用戶使用DAS專業版SQL洞察的功能的時候，即使我們將全量SQL流水，壓縮聚合成模板，模板的數量也是驚人的，我們可以看到大量特徵趨勢相近的模板。所以如果我們根據SQL的請求行為將模板進一步壓縮，這樣用戶可以更好的定位異常SQL的問題 目前DAS產品功能和業界AWS Azure等其他產品都有初步的異常SQL定位能力，通過對採集的SQL數據在各個維度的排序，讓用戶自己定位數據庫問題，這種方式對於80%以上簡單的數據庫問題是有效的，但是在複雜業務場景和DBA都很難定位的數據庫問題效果是很差的。以阿里雲內部管控的元數據庫集群實例為例，今年平均每月發生10多次的CPU打滿問題，全年發生數次性能相關的故障問題，但是每次的問題都不同，有時候DBA只能找到現象，難以快速定位問題根因。所以通過對用戶請求行為的分析，會更好的迭代DAS數據庫自治服務產品，解決我們複雜場景的數據庫性能問題，提高整個數據庫各個引擎的穩定性，易用性，效率。 業界產品: AWS: RDS： Performance Insight 和目前DAS產品功能一樣，採集的數據維度類似，通過Top

閱讀時長：5分鐘 適讀人群：搜索運營崗位、產品崗位、及對搜索技術感興趣的人； 搜索是每個產品必備的功能，也是業務增長最重要的一項，信息越豐富的產品越會重視搜索能力，並且搜索場景下是用戶“主動”產生內容，這就需要搜索技術可以精準分析召回，命中搜索意圖，從而才能達到業務轉化的目的。 市面上大部分產品的搜索都是技術同學在不斷的優化迭代，很容易忽視可以直接觸達業務側的運營同學的作用和價值。那今天就和大家分享下運營同學在搜索上有哪些玩法？阿里雲開放搜索作為一站式可視化搜索開發平臺，產品/運營同學可以在控制檯參與哪些優化動作呢？ 在搜索上可以做哪些運營工作那？ 與產品技術協同，對搜索指標負責，持續跟進搜索能力迭代； 通過分析業務指標輸出搜索評測報告，制定優化解決方案，提升產品能力和用戶體驗； 從產品和運營層面做用戶體驗突破性探索，結合搜索引導功能配合運營方案，提升業務轉化； 根據法律法規，把控內容安全性，及時處理平臺內不良信息內容； 運營同學難點 缺乏搜索相關技術知識儲備，技術理念、邏輯不清晰，不利於運營工作的開展和項目的推進； 改寫、分詞、召回、排序在搜索中如何運作，運營可以參與哪些優化？ 個性化搜索可以有哪些玩法？ 如何優化搜索提高用戶商業變現？ 需求解決週期長，難以做到及時快速響應，業務發展遲緩； 企業不具備完善的數據管理能力，運營不能實時查看搜索業務指標數據做出相應運營分析和運營決策； 核心搜索運營數據：搜索，流量，行為，成交，用戶分析，Query分析等； 個性化搜索引導：下拉提示、熱詞、底紋等數據分析； 搜索核心邏輯解讀 搜索業務流程：