“使用DataEase後，我們把使用過程中發現的一些不友善的地方提出來，項目團隊和使用者一起想辦法解決和優化，共同把這個産品做得更好。DataEase是一個開發者和使用者共創的開源産品。”
——DataEase開源社群核心使用者 馬先生
編者注：以下内容基于DataEase開源社群核心使用者馬先生的社群分享整理而成。
馬先生任職于一家全球化社交娛樂公司，公司日常業務營運涉及到大量平台的日活、月活等資料資訊。從2021年至今，公司根據自身的業務營運需要，前後選擇了三款BI工具，分别是Quick BI、Superset和DataEase，而每款産品的選擇與淘汰，都與公司的需求息息相關。
■Quick BI時期：在2021年8月之前，該公司還沒有建立完善的資料倉庫，公司内部也隻有一個人負責資料可視化工作，使用的産品是Quick BI個人版。當時大部分資料都是以郵件的形式發送給業務部門，但郵件的資料是靜态資料，無法直接查詢曆史資料，曆史資料需要查詢曆史郵件，比較耗費人力；
■Superset時期：随着公司業務的發展，該公司逐漸成立了一個成熟的資料部門，搭建了自己的數倉系統，并開始使用Superset。相比Quick BI，Superset最大的優勢在于這是一款開源軟體，不必通過以資料下載下傳或者頁面截圖之後發郵件的方式分享給業務部門。僅需登入同一個系統，資料部門做完的資料就可以呈現給業務部門，并且可以由業務部門自行查閱曆史的留存資料。無論是明細資料還是某個單一次元的資料，都可以檢視曆史資料。在此基礎上，他們完成了Quick BI時期（郵件需求）到Superset時期的第一次跨越——也就是從靜态資料到動态資料的轉變；
■ DataEase時期：完成第一次轉變後，馬先生所在的資料團隊開始思考第二個問題。Superset雖然是開源軟體，但它畢竟是外國的開源項目，不符合國人的使用習慣，并且在使用功能上也不能完全滿足公司的需求。例如，技術部門需要制作一個性能監控資料的展示大屏，通過Superset來實作很麻煩。于是資料團隊開始尋找下一個更适合自己公司的的BI産品。這時他們偶然發現了國産的開源可視化産品——DataEase，這款産品完美地解決了馬先生所在團隊在使用Superset時碰到的兩個問題：即不滿足國人使用習慣，以及實時資料重新整理不好處理。于是，他們實作了第二次跨越——從可用産品到易用産品。
在馬先生使用Quick BI、Superset再到DataEase的BI産品更新過程中，DataEase開源社群也見證了他逐漸加入到開源世界，從産品使用者到産品貢獻者的旅程。
社群使用者訪談
什麼樣的契機讓您開始接觸并使用DataEase的呢？
馬先生：之前我們公司一直使用Superset作為資料圖表展示系統。随着業務的增長，有很多營運和産品同僚希望自己配置報表，他們接觸Superset之後，普遍回報說Superset配置比較繁瑣。比如配置折線圖，Superset要配置時間列、時間粒度、名額、次元、分組等，很多業務同僚在配置圖表這一步就迷糊了，很難了解次元、分組這些術語。實際上，業務同僚需要的是一個能夠把資料集、圖表、儀表盤和配置項都內建在一起的、友善配置的圖表系統。這種圖表系統的學習成本低，可以讓業務同僚快速上手。
經過了一系列的産品調研之後，發現了DataEase。我在DataEase官網上的測試環境試用了一下，發現還挺好用的，于是就開始給業務部門部署使用了。
▲ 圖1 Superset的視圖設計頁面
▲ 圖2 DataEase的視圖設計頁面
■ DataEase視圖設計功能區介紹
【序号1】：資料操作區、樣式編輯區和進階功能區切換
【序号2】：搜尋
【序号3】：字段編輯
【序号4】：更換資料集
【序号5】：可選次元清單
【序号6】：可選名額清單
【序号7】：圖表類型（包括ECharts和AntV）
【序号8】：結果展示
【序号9】：次元設定區
【序号10】：名額設定區
【序号11】：結果過濾器
【序号12】：鑽取次元設定區
【序号13】：圖表展示
您認為DataEase的優勢是什麼，缺點是什麼呢？
馬先生：我們公司目前Superset和DataEase都在使用。産品部門主要用的是Superset，營運部門主要用的是DataEase。此外，DataEase主要用來展示UID粒度的資料。
相比DataEase，Superset的優勢主要展現在它的緩存機制。随着建立的報表越來越多，請求量增大帶來的問題也随之出現。由于我們采用的是直連方式，在應對并行的幾百個查詢時，DataEase的緩存效果不太明顯，響應比較慢。Superset可以自定義緩存的失效時間或者不緩存，這個功能點對我們來說是比較實用的。
DataEase的優勢也比較明顯，具體包括以下幾點：
1. DataEase給我的第一感覺就是界面簡潔并且漂亮，它可以友善地制作各種樣式的圖表，背景圖案、圖表的樣式邊框都可以自定義設定。最重要的是，它配置圖表的過程足夠簡潔，對于業務人員來說，他隻需要知道需要什麼樣的資料集，就可以直接建立儀表闆。Superset的資料集是一個雜亂無章的清單結構，而DataEase的資料集可以分級分類。
▲ 圖3 Superset的使用界面
▲ 圖4 DataEase的使用界面
2. DataEase的社群交流群内非常活躍，客服也會耐心地解答我們的問題。這是一種開源的生态環境，讓我們相信DataEase是一個有活力的項目。
3. DataEase的社群版完全開源，用我們最為熟悉的Springboot+Vue.js技術棧開發，有利于我們在其基礎上做一些定制化的東西。
DataEase解決了您公司什麼樣的業務需求呢？是如何使用DataEase的？
馬先生：為了讓業務方（例如銷售、營運等企業内檢視或制作儀表闆的人員）更便捷地使用，我們會在DataEase中提前準備好資料集并做好分類。具體操作就是，我們會給每個業務單獨建立檔案夾，業務下還會根據區域和功能繼續建立二級檔案夾。通過這樣的分類方法，業務方就能很清楚地知道這是什麼資料。
有了資料之後，業務方可以很友善地配置自己的報表，釋放了開發團隊的人力。DataEase還支援分享報表，使用者可以把自己的報表友善地分享給别人。現在，如果是業務人員自行配置生成儀表闆，就會選擇使用DataEase。
DataEase社群版有一些局限性，面對這些局限性你們是怎麼做的呢？
馬先生：是的，DataEase的社群版沒有開放權限管控功能，這對沒有二次開發能力的公司來說比較麻煩。是以，如果是以一個團隊為機關來使用DataEase，最好還是需要購買企業版。DataEase企業版的權限管控功能可以管控到行權限和列權限，這是很厲害的功能。面對一些需求場景，比如一個儀表闆要給不同的業務部門看他們對應的資料，如果通過DataEase的行權限功能來配置，幾十秒就搞定了。目前我們則隻能給每個業務部門都做一個儀表闆。
其次，針對我們自己的業務需求，營運的同僚希望對看闆名額進行監控，是以我們開發了DataEase的報警功能，對于達到門檻值的名額可以直接發送報警郵件、短信、電話等。
在DataEase的模闆市場裡，使用者可以免費下載下傳模闆直接應用到自己的儀表闆中。您覺得這會帶給使用者一些便利嗎？
馬先生：我用過DataEase的模闆市場，感覺挺友善的。我們把模闆下載下傳下來之後可以直接替換資料來使用模闆，不用自己再去做樣式。聽說使用者也可以給模闆市場投稿，不過我們還沒有投過稿。有個小建議，模闆市場裡大多數是深色系的模闆，我們公司用的是則是淺色系的儀表闆居多。因為深色的儀表闆視覺上比較晃眼，淺色的儀表闆會給人幹淨清爽的感覺。
您之前提到了DataEase的社群交流群比較活躍，那您和您的同僚在群裡也會和大家一起溝通交流或者問問題嗎？
馬先生：我把我的同僚們都拉到社群群了。雖然我們對DataEase做了二次開發，但是很多小的功能點我們依然不清楚，是以同僚們遇到問題也會在交流群裡提問。有時候我看到了别人問的問題我能解答，我也會回答一下。
我還給DataEase修複過幾個小Bug，送出過兩次PR，都已經被合并到主分支中了。因為我之前做過開源，是以對提PR、跑測試、合并到主分支等整個代碼開發的流程規範都很清楚。有時候我們可能發現了一些小Bug，但不是很影響DataEase的主功能，我們就會按照流程提一個PR。
您現在對DataEase項目已經非常了解了。對它有什麼建議嗎？
馬先生：我之前提到過對比Superset，DataEase的一個不足就是DataEase的緩存效果不太明顯，這個問題我覺得如果能做個前端異步就能完美解決。這個不足主要出現在兩種使用場景中：
第一種場景是使用者點選一個頁面沒有加載完成時，又點選了另一個頁面，DataEase不會立刻跳轉，而是需要等到上一個頁面加載完成才會跳轉。對于使用者而言，最好是不用等待目前頁面加載完成就可以直接跳轉；
第二種場景是，不論是在編輯儀表闆還是拖拽次元名額時，DataEase都需要請求資料，是以在資料量大的情況下操作起來就沒那麼順滑。如果設定一個按鈕，使用者點選那個按鈕後儀表闆才向背景請求資料，做到編輯完再進行整體重新整理，這樣可以減少請求，讓使用者使用起來更加絲滑。
緩存問題可以參考一下其他的開源BI産品。企業在選擇可視化産品時會有一種本能的不信任，就是使用者不知道拿過來之後，這個東西到底能不能用。很多開源BI産品其實也沒有怎麼運作宣傳，但是它們能吸引客戶的主要原因在于，這些産品經曆了很多使用者的實踐，是以使用者的使用黏性需要時間來沉澱。ToB端的産品需要疊代和更新，吸引更多的企業來使用，進而驗證産品的穩定性。這也印證了飛緻雲的那句口号：“軟體用起來才有價值，才有改進的機會”。
DataEase項目之前疊代的速度很快，最近幾個月因為要做2.0版本，1.0版本疊代的速度會慢一些。其實我覺得目前這個更新頻率也挺好的，Bug修複的速度還是很快，Feature可以慢慢來。因為做産品要考慮到大多數的使用者，而不是為某個單一的使用者服務，每個需求都要考察得比較全面才好，需要考慮新版本會不會對其他的使用者産生影響。