導讀 火花思維作為線上教育領域的佼佼者，深知數據對於決策和營運的重要性。為進一步釋放數據資源的價值，公司從 0 到 1 構建了一站式數據開發治理平台，實作了數據整合、數據開發、數據分析、數據服務等全流程整合，為公司的長遠發展奠定了堅實的數據基礎。
主要內容包括以下幾個部份：
1. 背景
2. 產品簡介
3. 關鍵技術與創新點
4. 實施與營運
5. 成效與收獲
6. 總結與展望
分享嘉賓｜劉世超 火花思維 大數據架構師
內容校對｜李瑤
出品社群｜ DataFun
01
背景
火花思維是一家專註於青少年思維訓練及綜合素質提升的互聯網教育企業，產品包含邏輯思維、中文素養、火花編程等。累計學員已超 70 萬，遍布全球 100 多個國家和地區。其主要采用直播、真人互動 AI 的方式進行授課，透過將老師的啟發引導和動畫、遊戲、趣味教具等多種方式立體結合，將能力、思維、訓練三者互相連線、層層遞進，在互動實踐中培養孩子的觀察思考、邏輯思維以及自主解決問題等核心基礎能力。
隨著火花思維的業務發展，數據量和數據訴求呈現出爆炸式增長的態勢。然而數據使用與管理模式已逐漸出現捉襟見肘，難以支撐企業高效營運與決策支持的核心需求。具體而言，當時我們面臨著以下幾大突出問題：
數 據開放自助程度明顯不足，嚴重制約了數據價值的充分釋放；
系 統性故障頻發，對數據資產的可靠性構成了嚴重挑戰；
ET L 效率低下已成為制因數據處理能力的關鍵因素。為了解決這些問題，我們需要一個更加高效、智慧的數據開發治理平台，以提升數據價值的挖掘能力、保障數據資產的可靠性、最佳化數據處理效率，並降低技術成本。
在產品建設初期，我們曾考慮過第三方的現有產品。然而，經過深入調研，我們發現了許多問題，最終決定自主研發。首先，當時我們發現市場上的現有產品雖然在基本 SQL 開發、排程配置、任務運維等方面表現出色，但在異源數據整合、DDL 適配、跨雲部署等場景存在局限性。其次，我們對第三方產品的叠代速度和穩定性存在擔憂。我們需要確保產品能夠滿足公司數據生產和消費方對大數據的期望，並在使用過程中不會出現重大問題。如果我們純依賴三方產品的方法論以及售後支持和研發資源，那麽會出現「不會用」、「加資源」、「等叠代」等常見矛盾現象。最後，我們認為自主研發將為我們帶來更多的機遇和優勢。透過自主研發，我們可以更好地把控產品的套用場景、功能矩陣和核心技術，以便更好地滿足需求，並根據需求變化及時進行調整和改進。
02
產品簡介
1. 功能介紹
Athena 數據工廠是火花自研的一站式數據開發治理平台，主要為營運、BA、產品、研發、財務、技術支持等多樣化角色提供任務開發、任務運維、提數分析、資源管理全方位的產品服務，幫助數據生產者和數據消費者專註於數據價值的挖掘和探索。該平台核心功能主要包含以下幾個部份：
離線開發模組 ：此模組致力於為數據生產者提供高效的數據處理工具。它支持定時及依賴觸發的離線任務，任務型別豐富，涵蓋 HiveSQL、DorisSQL、Python、Mysql 與 Hive 間的數據互動，以及 Hive 至 ES/MQ、Hive 至 Doris 的數據同步。此外，我們提供了一鍵 API 生成功能，使得數據消費者能夠便捷地透過介面獲取所需數據，極大地提升了數據獲取的效率。
即時開發模組 ：基於 Spark 和 Flink 兩大引擎，我們構建了準即時/即時任務開發平台。目前，該平台已成功支撐營運分析、指標監控、日誌采集、CDC 同步等多元化場景的需求，為使用者提供即時數據處理和分析的能力。
運維中心模組 ：在運維方面，我們提供多維度的看板分析，從任務成功率、及時率、成本等多個角度全面展示數據處理的狀況。同時，我們還支持上下遊查詢、重跑當前及下遊、數據回溯、批次下線、任務監控等基礎功能，確保數據處理流程的順暢與高效。
自助提數模組 ：該功能基於 Hive、Spark 和 Presto 三種引擎，為數據分析師提供了強大的 SQL 互動能力，使他們能夠輕松地提取和下載所需數據。此外，我們還特別針對增長業務，提供了使用者三方標簽的提取和下載功能，滿足使用者在增長業務場景下的數據需求。
數據地圖模組 ：數據地圖作為平台的重要組成部份，為使用者提供了詳盡的數據資產資訊。使用者可以透過該模組檢視數據目錄、明細資訊、血緣關系、排程資訊、更新記錄以及生產邏輯等關鍵資訊，從而更好地理解和利用數據資源。
控制台模組 ：控制台作為計畫管理員和系統管理員的操作後台，具備強大的管理功能。管理員可以透過該模組管理計畫成員、資料來源、庫表許可權、佇列分配以及敏感資訊查詢記錄等，確保數據的安全性和合規性。
透過該平台可以輕松地完成數據的采集、清洗、加工和分析，提高數據的品質和利用率。同時，平台的視覺化操作界面和靈活的配置選項，讓使用者可以快速上手並進行個人化設定。此外，平台還提供了豐富的數據服務和套用，包括使用者標簽、數據入湖、數據安全等，這些數據服務和套用可以幫助企業更好地利用和管理數據資源，提高數據的價值和效益。
2. 架構設計
Athena 數據工廠主體架構分為以下幾個模組：
互動層 ：采用了主流的 Vue 框架和 Monaco 外掛程式，為使用者提供了簡潔直觀的數據探查和任務釋出界面。使用者可以透過簡單的操作，輕松地進行標準化 ETL 流程的定義和執行。此外，使用者互動層還提供了豐富的視覺化功能，使使用者能夠直觀地監控和管理任務的執行情況。互動層還支持多語言界面，方便全球使用者使用。
服務層 ：這些服務包括 SQL 開發套件、整合偵錯、依賴推薦、後設資料管理等。此外，服務層也為各自計畫提供了全方位的許可權管理和資源管理功能。服務層還提供 API 介面，方便與其他系統進行整合。該層整體采用微服務架構，服務之間的界限和功能清晰，不同模組不同服務，各自按照需求場景選擇適合的技術棧和擴充套件套用，同時，獨立部署和執行，這有助於提高開發部署效率以及系統容錯性。
引擎層 ：透過對接各種生態元件，並封裝儲存計算能力，使得上層套用無需關心過多的技術棧和升級最佳化。例如，HiveSql 偵錯在引擎層既支持 Hive On Tez，也支持 SparkSql，並相容各自的參數最佳化。這使得使用者可以靈活地選擇適合自己業務需求的引擎進行數據處理。引擎層還提供了豐富的外掛程式和橫向擴充套件機制，能夠根據使用者的需求進行客製化開發。引擎層還支持多租戶模式，方便多個計畫共享數據工廠資源。
元件層 ：數據工廠的底層元件包括排程引擎所依賴的 Airflow、Python 引擎依賴的騰訊雲 SCF 產品 API 等。這些底層元件為數據工廠提供了穩定可靠的執行基礎。底層元件還采用了高可用架構，支持容錯處理和數據備份，確保數據工廠的穩定執行。底層元件還支持分布式架構，方便水平擴充套件和效能提升。
3. 使用場景
火花思維大數據計算鏈路經過多年的發展和演變，已經形成了 T/H+x、分鐘級、即時和 AI 四種場景的計算鏈路，支撐了多方面的數據處理和分析場景。
T/H+x 鏈路： T/H+x 是行業通用的離線計算，主要用於離線數倉、數據報表、套用統計等場景。具體實作方式是透過數據整合元件定時將 Mysql、日誌等資料來源的數據同步到數倉 ODS 層，其中 80% 的數據會被加工成主題寬表，然後被其他數據生產者利用，按需構建 ADS 套用數據，並最終以資料庫表、訊息佇列或者 API 方式提供數據服務。
分鐘級鏈路： 分鐘級套用主要針對 OLAP 多維分析場景，透過 FlinkCDC 等方式將資料來源數據同步到 OLAP 引擎，然後逐層定時拉寬聚合，最終以 API 方式對外提供數據。早期的 OLAP 引擎主要是 Kudu 和 ClickHouse，現在以 Doris 為主。
即時鏈路： 即時計算鏈路主要包括以 Spark Streaming 為核心計算棧的客製化數據服務和以 Flink 和 IceBerg 為核心的即時湖倉。其中，Spark Streaming 主要用於歷史遺留的 ToC 數據場景，如學員學情報告、CRM 營運數據、使用者標簽建設等。而 IceBerg 則主要用於解決即時日誌流水鏈路，Flink 則既可以用於構建即時數據報表，也可以用於營運監控統計。
AI 鏈路： AI 計算鏈路主要用於訓練和推理模型，包括數據預處理、模型訓練、模型評估和模型部署等環節。
03
關鍵技術與創新點
1. 離線 ETL
在離線開發整合角度，Athena 數據工廠提供了豐富的功能，旨在滿足使用者在基礎數據 ETL 以及分析挖掘領域的多樣化需求。該模組的核心能力體現在 Hive、Doris、Python 以及與其他元件的整合上，為使用者提供高效、穩定且靈活的數據 ETL 鏈路。
HiveSQL 作為離線開發任務的重要組成部份，先後經歷從 Hive 1.2 到 Hive 3.1 的版本升級。前期主要依賴 Tez 引擎進行數據處理，其中 Tez 0.10 引擎以其更高效的執行計劃和資源管理能力，為 HiveSQL 提供了強大的效能支持。隨著大數據 ServerLess 技術的演進，在 2023 年完全適配了商業化數據湖計算 DLC SparkSQL，基於存算分離的整體架構使得離線 SQL 在大數據處理上更加靈活和高效。
Doris 計算也是 Athena 數據工廠的一大亮點，其作為一種高效能的分布式 OLAP 引擎，具有快速查詢分析和高並行等特性。透過整合 Doris 計算，能夠支持使用者對海量數據進行分鐘級離線運算分析，借助一鍵 API 功能，滿足 CRM 業務數據時效性的高要求。
Python 作為一種通用程式語言，在數據開發領域也發揮著重要作用。在 AI 大模型「肆孽」的當下，Athena 選擇 Python 3.10 版本支持使用者編寫離線數據處理任務，利用雲函式 Python 豐富的庫和 MB 級記憶體資源管控能力，重點處理 SQL 不易甚至不能解決的場景，實作復雜的數據分析和處理邏輯，使得使用者可以更加靈活地處理數據，提高開發效率。
在與其他元件的整合方面，比如 Mysql<->Hive 的整合任務，Athena 依賴 Sqoop 整合工具進行數據傳輸和同步。我們還透過異步監聽 Mysql 的 DDL 變化，實作了數倉 ODS 層的欄位新增、刪除以及 Comment 變化的適配，以及在使用者互動中實作自動建表、欄位同名對映等功能。分庫分表合並則利用 CDC 模式實作。對於 Hive 與其他元件的整合，我們則依賴 DataX 這一強大的數據交換平台。DataX 支持多種資料來源之間的數據交換，包括 Hive、ES、MQ 等。目前，為了積極擁抱彈性計算，我們根據火花數據的特有使用場景，透過二次開發改造 Seatunel，計劃在第二季度徹底替換 Sqoop 和 DataX。
2. 排程系統
Athena 數據工廠的底層排程元件，正是基於業界知名的 Airflow 2.0 構建而成。Airflow 作為一個靈活且可延伸的分布式工作流排程系統，早已在大數據領域贏得了廣泛的套用。它不僅能夠高效地排程各種數據處理任務，還具備豐富的 API 支持，使得開發者能夠輕松整合各種功能，滿足復雜的業務需求。
在我們的排程系統中，除了支持任務啟停、依賴繫結、失敗重試、重跑上下遊等基礎功能外，我們還透過深度整合排程系統後設資料和 Athena 數據工廠後設資料，實作了更為精細化的排程管理。這使得我們能夠即時掌握任務的執行狀態，及時發現並解決問題，確保數據處理的穩定性和準確性。
3. 即時計算
Athena 數據工廠的即時計算模組功能主要支持 Spark Jar、Flink Jar 以及 Flink SQL 三種開發任務。
在 Flink SQL 方面，它已經成為非大數據使用者的首選。Flink SQL 以其簡潔易懂的語法和強大的即時處理能力，受到了廣大使用者的青睞。目前，我們的平台已經支持 Kafka、RocketMQ、Mysql、Doris、Elasticsearch、Hive、Hudi、Iceberg 等眾多 Connector。這些 Connector 的存在，使得 Flink SQL 能夠輕松接入各種資料來源，實作數據的即時采集、處理和輸出。
在 Jar 任務方面，無論是 Spark Jar 還是 Flink Jar，它們都以公司 GitLab 的倉庫地址為基準。這意味著，開發人員可以將自己的 Jar 包上傳到公司程式碼倉庫，並透過Athena 輕松實作打包、部署和執行。這種整合方式不僅提高了開發效率，還確保了 Jar 包的版本管理和安全性。
今年，我們的即時計算底層也計劃基於 Oceanus 彈性伸縮排行改造。根據業務需求的變化，我們可以自動化調整計算資源，實作動態計算能力的彈性伸縮。透過合理的資源排程和容錯機制，我們能夠確保即時計算任務的穩定性和可靠性。
4. 監控預警
在任務級別的監控方面，Athena 數據工廠能夠即時監控任務的執行狀態，包括是否成功、失敗或超時。這些監控項是確保任務穩定執行的關鍵指標。一旦任務失敗或超時，平台會立即觸發預警機制，透過飛書群或飛書個人等方式通知相關人員，以便及時介入處理。
除了任務級別的監控，Athena 數據工廠還提供了表級別的監控功能。這包括主鍵唯一性檢查、雙端對比以及表行數校驗等。主鍵唯一性檢查能夠確保表中數據的唯一性，防止重復數據的出現；雙端對比則能夠對不同資料來源之間的數據進行比對，確保數據的一致性；表行數校驗則可以檢查表中數據的數量是否正確，防止數據遺失或異常增多。這些表級別的監控項能夠全面保障數據的品質和準確性。此外，Athena 數據工廠還支持欄位級別的監控。這包括空值檢查、異常值監控、求和、均值、極值等。空值檢查能夠發現數據中的缺失值，確保數據的完整性；異常值監控則可以辨識並報警異常數據，防止其對後續分析造成影響；求和、均值和極值等統計指標則能夠幫助我們了解數據的分布情況，為後續的數據處理和分析提供重要參考。
Athena 數據工廠的監控程式與監控任務是緊密繫結的。這種一體化的設計不僅方便了使用者對監控任務的管理和維護，還能夠實作任務與監控的成本核算。透過監控程式，我們可以清晰了解每個監控任務的資源消耗情況，為成本控制和資源最佳化提供了有力支持。
04
實施與營運
1. 演進歷程
Athena 數據工廠於 2021 年底正常上線，初期目標就是將以 Azkaban 和 Crontab 上的 HiveSQl 和 Sqoop 指令碼全部遷移至數據工廠，讓資料倉儲、數據服務和 BA 自助的指令碼能夠在各自計畫空間下有序地依賴執行。
2021 年 11 月， Athena 數據工廠邁出了堅實的第一步， v1.0 版本的上線標誌著它正式踏入數據開發領域。這個版本以離線開發、排程配置、任務運維三大核心功能為基礎，為使用者提供了穩定可靠的數據開發平台。
僅僅三個月後， 2022 年 2 月，我們成功完成了資料倉儲的 HiveSQL 和 mysql<->hive 相關任務的全量遷移，這標誌著 Athena 數據工廠在支撐火花思維基礎數據處理能力上邁出了重要的一步。
同年 4 月，我們又實作了 Hadoop 集群從依賴社群自建到商業化 EMR 的順利遷移，這一變革極大地提升了基礎元件的穩定性和效能。
2022 年 7 月， Athena 數據工廠再次迎來重大更新，新增了 Doris 引擎和 SparkSQL 引擎，為使用者提供了更多樣化的數據處理引擎的選擇。此外，上線一鍵 API 生成功能，方便數據生產者透過 API 通道分享數據。
同年 10 月，我們整合了原【大數據即時開發平台】至 Athena 數據工廠，構建了獨立的即時開發模組，以滿足使用者對於即時數據處理的需求。
進入 2023 年， Athena 數據工廠的叠代速度更是加快。 3 月實作表級別血緣關系解析以及整合公司 GitLab 實作版本管理，並基於此上線依賴推薦、跨周期依賴、數據回溯、 BI 建模血緣跟蹤等輔助開發能力。
6 月，成功實作了離線開發和自主提數的 SQL 引擎對商業化 ServerLess 的適配，進一步提升了數據處理效率。
8 月推出了欄位級血緣關系以及數據監控功能，為使用者提供了更加精細化的數據管理和品質保證。同時，基於 HiveMeta 實作表資產生命周期治理能力。
2023 年 11 月，基於騰訊雲雲函式產品，我們推出了 Python 開發模組，為 BA 、演算法、研發等角色提供了解決 SQL 無法實作或較難實作場景的全新功能。
到了 2024 年 1 月，我們再次進行了一次重大的技術革新，適配 Hdfs 遷移至 COS ，實作了使用者無感的存算分離，為各計畫空間提供了更加靈活和高效的數據儲存和計算服務。
2. 日常營運
Athena 數據工廠的日常營運在 2023 年 3 月前後經歷了兩個階段，每個階段都有其獨特的營運策略與特點。在 2023 年 3 月之前，我們采用的是計畫制的營運模式。每個計畫都建立了專門的營運群，並配備了專業的營運人員。這些營運人員不僅具備豐富的數據開發經驗和深厚的技術功底，還擅長與使用者溝通，能夠迅速把握使用者需求並提供相應的解決方案。他們會在群裏積極回答使用者的問題，提供細致的解答和培訓，確保使用者能夠順利使用我們的產品。同時，他們還會根據使用者的反饋和需求，不斷最佳化我們的產品和服務，持續提升使用者體驗。
然而，隨著使用者數量的不斷增加和計畫規模的擴大，我們意識到這種計畫制的營運模式存在一些問題。比如，不同計畫之間的資訊交流不暢，導致一些共性問題無法得到及時解決；同時，營運人員的工作負擔也逐漸加重，難以保證服務品質和效率。因此，在 2023 年 3 月之後，我們對產品營運模式進行了調整，建立了【大數據服務中心】千人話題群。該話題群將所有使用者集中在一起，方便他們之間的交流和互動。同時，我們實施了輪崗機制，由 Athena 數據工廠的產品、研發、測試多方人員輪流擔任值班人員，負責解答群內使用者的問題，不僅提高了服務效率，還確保了問題的專業性和準確性。為了確保值班人員能夠準時上線並積極參與群聊，我們還引入了機器人提醒功能。機器人會在每天下午 18 點定時提醒值班人員上線，並在群裏積極回答使用者的問題。透過這種方式，我們確保了服務的及時性和連續性。
05
成效與收獲
1. 釋放自助能力
我們一直秉持著「生產力改變生產關系」的原則，致力於提供便捷、高效的數據開發工具和服務，幫助公司各部門、各角色更加自主地開展數據分析和套用，實作公司數據自助開放的整體策略目標緊密相連。
從數據層面來看，Athena 數據工廠每日承載的離線任務執行例項數量已達到約2 萬個，它表明我們的平台已經能夠穩定、高效地處理大量的數據任務，為公司的數據分析和套用提供了強有力的支持。同時，內部使用者數量也達到了約 470 人，MAU 約 130，這說明已經得到了廣泛的認可和使用。由 BA、營運、產品、研發等非大數據角色發起的新增任務占比高達 92%。這一數據不僅凸顯了 Athena 數據工廠在跨角色數據開發方面的廣泛套用，更體現了平台在推動公司內部數據自主開放方面的卓越成效。
具體來說，僅在 2023 年非大數據角色透過 Athena 數據工廠新增的任務數量就達到了 2700+ 個（忽略數據資產生命周期治理）。從更宏觀的視角來看，結合數據需求叠代頻率，Athena 數據工廠實際上在 2023 年支撐了公司內部的 3000+ 個數據需求。這意味著，Athena 數據工廠已改變公司數據訴求供需關系，為增長和變化預留了足夠的空間，更為公司提供了一個穩定、可靠的數據基礎設施，使得公司能夠更加自信地面對未來的數據挑戰，實作數據價值最大化。
2. 提升可靠性
事前檢查：在任務上線之前，Athena 數據工廠會進行強邏輯的檢查，以確保數據任務的穩定、正確產出。這些檢查規則包括指令碼語法、排程配置、資源許可權等多方面的檢查，可以避免數據上線後出現錯誤和異常，從根本上降低值班人員起夜率。
事中預警：在數據生產和消費過程中，平台會進行即時監控，並提供豐富的預警機制。當數據出現異常或達到預警閾值時，平台會及時發出預警訊號，通知相關人員進行處理。這樣就可以及時發現和解決數據異常，避免數據遺失和錯誤，保證數據的可靠性和穩定性。
事後復盤：故障發生後， QA 同學利用 GPT 依據 5why 分析法構建了復盤機器人，帶領故障幹洗人對 SLA 問題進行深度引導分析，找到根本解決方法，並預防類似問題的再次發生。
3. 最佳化 ETL 效率
自從排程任務遷移至 Athena 數據工廠後，透過分析 ETL 任務的執行數據，從多方面提升了整體執行效能，天排程 SQL 任務 24 年 3 月同比 23 年 3 月增加 107%，單平均任務執行時長降低 48%。這主要得益於三個方面的改進：
DAG 最佳化：首先，透過分析 Airflow 節點資源利用率，結合各型別任務 Client 執行所需的 CPU 和記憶體資源，合理分配整體 Pool 和 Worker Pool 的閾值，實作執行節點任務吞吐最大化。其次，由於各型別 DAG 執行周期交叉，最典型的就是天排程 DAG 與零散 DAG 的交叉，會發生排程資源、算力資源甚至 IO 資源競搶，透過分析統計各 DAG 任務重要性和影響度，以及任務特征，合理分配各 DAG 的 Pool 大小，實作整體資源利用最大化。最後，根據單 DAG 上依賴模型和各任務自身特點，動態調整各 SLA 等級的任務權重，讓重依賴、重保障的任務盡早執行，從而實作更高效的任務執行。
慢任務最佳化：治理團隊投入最大的精力就是辨識最佳化慢 SQL ，而慢 SQL 最常見的場景就是兩種：（ 1 ）數據掃描量大，要麽忘記加分區限制要麽讀取分區太多；（ 2 ）通常是巢狀 With as 較多臨時查詢的任務，導致解析計劃中某一個或幾個 Reduce 卡住，但寫 SQL 的人員優先滿足計算口徑，而忽略數據傾斜或笛卡爾問題。由於目前底層 SQL 算力引擎已彈性，故在基線保障和成本控制的背景下，優先解決慢任務是效果最佳的治理手段，也是持續保障任務平均執行效率和效能的最佳實踐。
元件最佳化：無論是 SQL 任務或是整合任務，都會依賴其他元件，而很多時候，隨著數據量或讀寫壓力的增加，元件出現效能瓶頸，而在任務角度觀察是整體執行變慢或夯死，這時候就可以透過多維分析任務執行數據，觀測拐點的任務特征，結合幹系元件的效能監控波動，辨識並對癥下藥。例如： JournalNode 、 RDBS 以及磁盤故障等。
4. 降低成本
Athena 數據工廠透過底層技術的最佳化進一步降低了綜合技術成本。近兩年，我們將hive 底層引擎先進行了 tez 升級後切換至 Spark，儲存從 HDFS 遷移到 COS，今年3 月天排程單任務計算成本同比去年降低 29%。而這些切換過程中，我們充分利用了 Athena 數據工廠對底層的隔離和封裝能力，降低技術升級對使用者的影響，甚至部份遷移工作對使用者無感。
在 Athena 數據工廠上線前，BA 和研發人員面臨著繁瑣且耗時的數據任務上線釋出流程。他們需要透過一套基礎配置工具，歷經八個步驟才能完成整個操作。這包括編寫配置檔和 SQL、上傳程式碼、配置依賴、構建任務、部署任務和釋出任務等。每一步都需要手動操作，稍有不慎就可能導致錯誤或異常情況，進一步增加了解決問題的難度和時間成本。然而，使用 Athena 數據工廠後，這一切得到了徹底的改變。據調查統計，每個數據任務的上線釋出過程至少可以節省 3 小時以上的時間。
06
總結與展望
1. 經驗教訓
在 Athena 數據工廠構建過程中，我們積累了許多寶貴的經驗教訓。以下是一些關鍵的點：
註重目標使用者體驗：我們深刻認識到使用者體驗是平台成功的關鍵因素。在平台建設前期，團隊投入了大量的時間與精力，組織數次產品 MVP 功能調研問卷，對目標使用者群體進行了深入的調研，明確了他們的需求和期望。這不僅幫助我們確定了平台需要實作的核心功能，還讓我們能夠避免在設計過程中添加不必要的功能和復雜性，確保平台始終保持簡潔、直觀和易於使用的特性。此外，為了進一步最佳化使用者體驗，產品上線首年每月進行 Top3 使用者測試和反饋收集，傾聽使用者的聲音，並根據他們的反饋對平台進行了持續改進。
選擇合適的技術棧：選擇合適的技術棧對於平台的成功同樣至關重要。在選擇技術棧時，我們充分考慮了平台規模、效能需求、可延伸性以及維護成本等因素。我們進行了深入的技術調研和評估，與業內專家進行了充分的溝通和交流，最終選擇了既符合平台需求又具有前瞻性的技術組合。
構建可延伸的架構：在構建平台的過程中，我們還特別註重架構的可延伸性。我們深知，隨著業務的發展和數據的增長，平台的架構必須能夠輕松應對未來的挑戰。因此，我們采用了分布式系統、微服務架構等技術手段，確保平台能夠靈活地擴充套件和適應新的需求。這種可延伸的架構不僅提高了平台的效能和穩定性，還為我們後續的維護和升級帶來了極大的便利。
學習和不斷改進：產品構建是一個不斷學習和改進的過程。在產品的開發、測試、上線和營運等各個階段，我們都保持高度的敏感性和警覺性，不斷反思和評估平台的效能、使用者需求反饋。雖然我們暫未建立成熟的 「 數據飛輪 」 ，但積極收集和分析數據，透過數據驅動的方式發現平台存在的問題和不足，並制定相應的改進措施。這種持續改進的態度不僅幫助我們不斷最佳化平台的功能和使用者體驗，還讓我們能夠緊跟行業發展的步伐，保持平台的競爭力和創新性。
2. 未來叠代
對於使用者自助開發過程中的程式碼偵錯和報錯任務，提供基於 AI 的分析協助能力。利用大語言模型，我們能夠快速準確地理解使用者的問題，並提供有針對性的解決方案。這種智慧化的分析協助能力不僅可以提高使用者的工作效率，還可以減少使用者的焦慮和壓力，提升他們的使用體驗。
最佳化可觀測能力，解決大任務等對穩定性和效能帶來的系統性負面影響。持續評估和最佳化計算資源的效能，確保它們在處理大量數據時高效執行。定期進行基準測試和效能評估，以確定計算資源的瓶頸和潛在最佳化機會。利用效能監控工具和指標來即時監測計算資源的使用情況，並及時采取措施解決效能問題。同時，最佳化計算資源的配置，例如調整 CPU 、記憶體、儲存等參數，以提高資源利用率和效能。
將核心功能和底層引擎容器化，這樣可以實作資源的動態分配和管理，提高系統的靈活性和可延伸性。同時，可以更輕松地部署和管理應用程式，提高資源利用率和效率，降低成本，並確保系統的穩定性和可靠性。同時，要開始在架構層次思考低成本支持跨平台和雲原生套用，這可以提高系統的靈活性和可延伸性，同時降低開發和維護成本。
結語： 透過對一站式數據開發治理平台的構建與實踐，火花思維成功提升了數據管理效率，最佳化了數據利用價值，為公司發展註入了新的活力。未來，隨著技術的不斷進步和業務的持續拓展，公司將繼續深化數據治理與開發工作，為線上教育行業數據驅動的創新發展貢獻更多力量。
以上就是本次分享的內容，謝謝大家。
分享嘉賓
INTRODUCTION
劉世超
火花思維
大數據架構師
10 年大數據領域實戰經驗，專註於數據整合、資料倉儲、數據治理、資源管理等關鍵領域。主導完成火花思維從 0 到 1 大數據開發治理平台的建設，助力實作數據價值最大化 。
往期推薦
點個 在看 你最好看
SPRING HAS ARRIVED
