提供了一個關於FineBI系統中使用者准入管理、開發流程以及效能優化的詳細指南。
文檔旨在幫助使用者理解在BI系統中如何進行有效的使用者管理和開發流程，同時提供了確定系統效能和資料品質的最佳實踐。
在BI中，根據使用者行為的不同，使用者可分為以下幾種：
對於不同的使用者，在系統中需要分配不同的權限，詳見：資料體系&權限管理
為保障BI環境各項資料資產的規範性、高效能，在允許使用者進入生產環境進行自助開發前，管理者應檢查使用者，需先完成標準規範學習、透過准入考覈，可以“帆軟認證初級BI工程師”為參考標準見：FCA-FineBI
注：對於【資料BP使用者】和【IT使用者】，要求應適當提升，要求其掌握一定的資料處理能力和思維、擁有一定的規範意識，因為無限制的資料處理可能會導致系統效能問題。
查看可見範圍：查看當前公開的儀表盤和資料列表。
確認分析權限：針對自己的分析相關的資料，覈對有無權限。
進行權限申請：無權限，則進行申請。
權限二次複覈：申請透過後再次確認權限是否解決。
對於擁有公共資料夾權限的開發使用者，在資料集開發完之後可以透過將資料集發佈到「公共資料」的形式，發佈資料需注意幾點：
規範性：遵守企業規定的命名規範。
安全性：檢查資料敏感性，對其中敏感資料，與次管確認資料權限管控是否到位。
準確性：對於資料來源、計算指標、有歧義的資料等應當作出解譯，可以放在資料集的備註中。
流程性：發佈前需向次管確認，發佈後即時記錄資訊。例如：
與5.x版本不同，6.0在開發時，新增了“分析主題”的概念。
在分析主題中，存在3種實體：
資料集
組件
儀表板
分析文檔
在使用路徑上，先有資料，再製作組件，最後組成儀表板。
注：不同於5.x的分散，6.0中使用者可以根據業務/分析內容來組織這4種實體，在結構上更方便查看和使用。
在個人的分析主題中，使用者可以對資料集和組件進行開發，無法直接在公共業務包內建立資料集。
【我的分析】可以認為是一個相對獨立且自由的空間，類似於個人PC，使用者可以在裏面進行各種各樣的資料組合和處理，探索各種資料的特徵，不會影響到其他人的使用。同時，在“我的分析”中，不支援設定資料集的更新頻率，所有的資料集都是跟隨公共資料內引用的父表而更新的。
【公共資料】則可以認為是一個企業內的網盤，資料必須有一定的複用性、符合一定的規範才能夠進入此區域，供他人使用。同時個人需對自己發佈到公共區域的資料進行擔責和維護。只要是進入“公共資料"中，就肩負起了維護和建設一個良好資料品質的責任，邏輯變更時，一定要考慮到會不會對其他使用者造成不好的影響。如果公共資料中的表出現了錯誤，那麼對應的資料管理者就有責任要儘快修復這個問題。如果這個資料將要跳出公共資料，那麼也要走流程來進行下架，來減少對其他使用者的影響。
命名應當以簡潔性、特徵性為追求。
規範範例：
“分析主題-分析內容-建立人”
“分析內容-使用場景-建立人”
“組內序號-分析內容-建立人”
使用者開發的儀表板，在視覺上需遵守一定的規則，要注意 看板的可讀性 和 表達的合理性 ，主要體現在：
字體字號要合理。
排版佈局要遵從“主次原則”，有主要部分和次要部分的差別，尊重閱讀順序。
圖表選擇要合理，儘可能將能同時分析的資料放在同一個圖表中。
整體配色要和諧，避免對比色
必要時新增文字註釋，例如對資料來源做出解譯、對資料結論做出總結。
必要時新增logo。
佈局
比如分析型儀表板應該具有以下佈局元素：
更多詳情參見：頁面佈置
色彩
比如，如果你是互網路連結科技型公司，可以將藍色作為 BI 平台的主色相。
更多配色詳情參見：幾套預定義樣式推薦
1）團隊內分享
若分析主題是小團隊使用，或者僅需某些使用者查看，可以不發佈到公共目錄。此時需注意以下幾點：
分享的使用者是否有對應資料的權限。
是否想讓分享的目標使用者看到製作者能看到的資料。
是否告知分享的使用者本主題內資源的內容、使用場景、資料來源。
2）公共目錄掛出（發佈設定）
需要掛出到公共目錄時，掛出的主題 配套資料源 一定是已在公共目錄下的，否則無法給使用者授權資料源查看權限和配置行權限。
若使用到的資料源目前尚不存在公共目錄下，需先參考本文的 「3.2節資料開發與上架」步驟進行相關資料發佈 。
申請掛出到公共目錄的主題資源，必須進行如下檢查：
資料準確性：有特殊處理的資料是否做了解譯。
可讀性：查看者能否清晰且快速瞭解到儀表盤內容，認知無偏差。
資料保密性：若有敏感資料，是否已經配置權限。
UI標準性：是否符合企業的UI標準、視覺效果是否合理。
3）建立公共連結
公共連結開啟能看的資料權限，跟製作者是完全一致的，故而使用公共連結功能時，需格外注意資料保密性。
公共連結使用完後應即時關閉。
4）協作
在5.x中，BI支援將資料集進行分享協作，詳見分享/協作自助資料集，但該功能無法滿足“查看儀表板製作程式”的需求。
在 6.0 中，使用者可以將資料夾或者主題進行點對點的協作，被協作的使用者能查看或者使用相關分析主題的內容，實現分析主題的協同編輯。詳情請參見：協作
在FineBI中，展現速度是隨着儀表板組件的複雜程度而各有不同的，組件越複雜，展現速度越慢。
此處列出一些會導致效能表現差異的因素，和它們對應的時間指標。
對FineBI的抽取資料來說，最大支援的底表資料量是1億（行），在不超過此限制的情況下，單組件迴應時長應在3秒內，儀表板有15個組件時，迴應時長應在30秒內。
1）1億行以下的分組表
以下場景在3秒以內展現出來是合理的：
求記錄數
快速計算：環期值、環期比
函式計算：todouble、DAYSOFYEAR、DAYS360、DATESUBDATE
以下場景在5秒以內展現出來是合理的：
匯總計算：求和、平均、中位數、最大值、最小值、標準差、方差
合計方式：自動、中位數、平均、方差、最小值、標準差
單維度排序，其他維度組內排序
被聯動（帶有過濾）
分析區、待分析區的過濾：屬於、介於/不介於、結尾是、TopN（最大的N個、前N個）
複雜場景：過濾+計算+排序
函式計算（5個維度5個指標的情況下，計算越多越慢）：tointeger、todouble、lower、len、find、SWITCH、RAND、MAX、INT、IF、EXP、DAYSOFYEAR、DAYS360、DATESUBDATE、DATEDIF、AND
注：如果在1kw原始資料的情況下，出現了100w個分組，則會影響展現表現（因為分組越多計算量越大）。其中快速計算和維度排序的表現在30秒以內都是合理的。
2）交叉表
在不做複雜計算、資料集行數在一億行以內的情況下，10行*10列*10指標和5行*5列*10指標的交叉表，都應在5秒以內展現出來。
3）對於開啟了大數據模式的圖表來說
若資料集的行數在1kw以內，在圖表分析時產生的維度分組數在5000以內，柱形圖、點、線、面積圖這些圖表的展現應該在5秒之內完成。
若資料集的行數在1kw以內，在圖表分析時產生的維度分組數在100w以內，儀表盤、填充地圖、正文、漏斗圖、熱力點、矩形塊、餅圖、多層餅圖、漏斗圖、矩形樹塊、聚合氣泡圖、詞雲、雷達圖、流向地圖、點地圖、熱力地圖這些圖表的展現應該在5秒之內完成。
固定配置下，儲存格越少、分組數越低、計算越簡單，系統能支撐的最大併發數越大。超過推薦的最大併發數時系統仍然支援，不會報錯，但迴應時間將大於等於單獨匯出時的3倍。
匯出時長包括兩部分
準備匯出時長：開始匯出至服務端匯出資料準備完畢的時長。該段時長依賴於計算速度，主要由工程分配記憶體和範本本身的計算量有關。
資料傳輸時長：伺服器資料傳回使用者端以完成請求迴應的時長。該段時長受網路傳輸、瀏覽器、網路環境、伺服器等因素影響。
Excel匯出速率和儲存格數量的關係：最快10w儲存格/秒，標準在20~40w儲存格/秒。
1）不同類型表的匯出特性：
2）匯出效能表現標準：
4.2.1.1 通用規範
新增基礎資料集時，欄位數建議不超過100個，欄位數增多對效能會有一定程度的影響。
如果需要對基礎表進行欄位類型轉換，建議改成SQL表，在SQL中進行欄位類型轉換。
若資料表在資料庫中查詢超5s，則不推薦新增成DB表，建議優化資料庫中對應的表SQL（直連+抽取）。優化程式參考一份非常完整的MySQL規範、SQL 效能起飛了。
建議使用的基礎表資料量不超過1kw，或者先過濾到1kw再進行分析。
4.2.1.2 Excel資料集使用
1）匯入Excel時，若資料量過大，會導致匯入慢，或造成前端卡死。
因此建議：
限制單個Excel匯入的檔案大小在100M以下。
去除Excel中無用行/空行，只保留有效資料。
Excel落庫，透過新增SQL表或DB表的形式替代。
2）如果在直連模式下使用excel，製作大量自助資料集，且自助資料集的血緣層級很深，對擁有複雜血緣的自助資料集資料集進行編輯、預覽、製作組件等操作時，容易佔用大量記憶體造成當機。
使用Excel進行資料分析時，如非必須使用實時資料的場景，建議在抽取資料下新增Excel。
直連模式下的Excel表不建議超過10w行。
Excel與其他資料集進行融合分析時，資料集所在的最深血緣層級不能超過3層。
4.2.1.3 直連sql資料集使用
建立SQL資料集時，避免寫非常複雜的SQL語句，查詢時間不超過5s。若SQL表的查詢時間過長，使用SQL表製作儀表板和自助資料集只會更慢。可將一個表分成若干部分，減少單次掃描的資料量，提升效率。
SQL書寫效能規範：
使用 SELECT 語句時，應指出列名，只取需要的欄位，不應使用列的序號或者用“*”替代所有列名，所有操作儘量明確指定列名。
大表聯動查詢語句中，做到先過濾再聯動，不允許使用WHERE來進行聯動。
如果SQL語句中有多處重複的子查詢，可以將其提取出來，進行參數化，減少資料庫查詢次數。減少子查詢（巢狀查詢）至三層以內（即三次以內的左右合併、上下合併），巢狀太多則會影響最終展現的效能。
減少不必要的掃描計算。如果UNION ALL可滿足要求，就使用UNION ALL，而不用UNION，因為UNION會有一個比較然後去重的程式，而UNION ALL沒有。
避免對大表的全表掃描操作，經常查詢的大數據量表，需要在資料庫底表中建立索引，過濾和排序儘量放在索引列上操作，提高SELECT效率，WHERE 語句儘量避免使用函式和算數運算等。
區間範圍比較（特別是索引列比較）要有明確邊框，降低比較時的計算精度，用>=、<=代替>、<。
大表查詢時，避免不必要的排序，排序需放在執行計劃最後一步。儘量在子查詢中避免ORDER BY、DISTINCT等語句。其中ORDER BY是對結果進行排序，而DISTINCT和GROUP BY是在計算程式中排序。子查詢資料量較大時用EXISTS子句代替DISTINCT。
檢查 SQL 邏輯是否笛卡爾積，或者檢查資料量是不是太大，資料量大的情況就採用分表、分割槽、瘦身、合併、索引等資料庫策略。
3. 合理使用直連快取。參考【直連】快取設定，對高頻使用但每次查詢效能較差的資料集，可依據資料時效性配置快取功能，減少資料庫查詢，提升展示效率。
4.2.2.1 欄位數建議
選欄位欄位數建議不超過30個。
建立自助資料集，在選欄位階段應只選擇需要用到的欄位，不建議直接全選，避免造成伺服器物理空間浪費與更新耗時增加
4.2.2.2 步驟數建議
單個資料集資料處理步驟不超過 15步。
新增列不超過 10列。
左右合併步驟不超過 3 步。
分組匯總步驟不超過 3 步。
超過推薦步驟數，建議轉化成資料庫表再加入使用。
4.2.2.3 步驟順序建議
優先對資料進行過濾，不要用全部資料進行計算。
大數據量排序效能不佳，把排序的步驟儘量放在過濾步驟之後。
新增公式列後再對新增列進行排序或者匯總，效能會非常差，建議減少在新增列後使用排序和匯總。
4.2.2.4 步驟類型建議
左右合併、分組匯總、其他表新增列、行列轉換 步驟效能偏弱，資料量大於 1000w 行時儘量減少使用，若超過1kw則先進行過濾以減少資料量。
左右合併/其他表新增列避免出現 N:N 情況，若邏輯需要 N:N，控制笛卡爾積後的資料量不超過 1000w 行。
分組匯總欄位總數不超過10個，包含匯總條件的欄位數不超過3個，結果不超過 1000w 行。
新增列計算效能和函式複雜度強相關，函式公式越複雜效能越差；使用DEF函式的欄位不超過3個，且避免巢狀；新增列-所有值匯總、新增列-匯總值含分組 效能偏弱；資料處理公式 同比環比等日期形式的計算在組件中「快速計算」中進行。
欄位設定-欄位類型轉換建議在SQL表中使用SQL語句進行欄位類型轉換。若自助資料集最簡表中有欄位類型轉換操作，建議增加步驟，使表抽取到本地。
若步驟公式過於複雜，建議轉化成資料庫表再加入使用。
4.2.2.5 血緣層級
自助資料集血緣關係過於複雜時，會導致基礎表、自助資料集更新慢，相關基礎表長時間無法使用。
抽取自助資料集所在的最深血緣層級，建議不超過 5 層。
直連資料集所在的最深血緣層級，建議不超過 2 層。
若超過，建議透過SQL資料集實現，或下沉到資料庫表再透過新增DB表新增使用。
自助資料集符合效能標準的場景
自助資料集不符合效能標準的場景
首先建議開發時使用的瀏覽器，儘可能使用新版，例如chrome要使用110版本及以上，太舊的瀏覽器也會導致請求卡頓。
組件數量很多時，完全載入出儀表板所需時間很長；30+的複雜圖表組件很容易出現渲染慢，view請求慢，導致範本存取白屏。
佈局優化建議：
減少組件總數量：最好不超過30個。
使用TAB組件的方式進行非同步載入：不推薦過多組件全堆砌在一頁，組件越多效能越差。
合理使用頁面拆分、頁面跳轉方式佈局：具備下鑽邏輯的組件，可以採取頁面跳轉的方式，減少同一頁面內組件數量。
組件選擇優化建議：
組件類型簡化：如無必須使用圖表組件的場景，使用表格組件代替；交叉表僅使用行維度或列維度時，使用分組表代替。
分析維度簡化：使用諸如柱形圖、條形圖、散點圖等圖表時，儘量選取更高效的分析維度，分析維度不宜過多，在X個之內。
資料展示簡化：原始表行數在1kw以上時，不建議開啟指標資料條。
資料量級簡化：使用大分組圖表（分組超過5k）時，建議取消勾選“查看所有資料”。
資料量優化建議：
減少欄位總數量：組件使用到的計算欄位數不超過15個，在主題內的資料集，可以透過欄位設定取消勾選不會用到的欄位，以限制可能被組件使用的欄位數量；同時需要定期檢查，去除無用欄位。
減少編輯預覽計算資料量：編輯組件時，取消分組表/圖表組件的“查看所有資料”，取消勾選即使用部分資料（1萬條）查詢，可以顯著提升效能體驗。
組件中新增計算指標時，若新增指標多、公式複雜，會導致計算慢，進而導致計算執行緒池滿，造成系統卡慢。
儀表板有很多的欄位和計算指標，編輯狀態下，新增、刪除、行動欄位前端迴應慢。
同時，若有些欄位標紅，檢查邏輯會導致在編輯、匯出時損失效能。
組件計算優化建議：
單個組件新增計算不超過5個。
手動檢查，確定儀表板中沒有標紅欄位。
減少計算欄位間相互巢狀。
複雜公式下放到自助資料集中計算，如去重計數、表頭過濾、公式過濾、維度轉指標。
減少使用效能偏弱的場景，如：去重計數、表頭過濾、公式過濾、維度轉指標、分組匯總-環期值&環期比、組件過濾-TopN過濾、過濾混合二次計算混合排序、合計方式-中位數&方差&標準差&求平均&最小值、DEF函式、EXP、TODOUBLE、DATESUBDATE、DAYS3600、行表頭欄位a按照相聯動欄位b升冪。
特殊函式使用注意點：
正文函式中減少使用長正文，長正文很容易導致當機，建議正文處理儘量都放在資料集中進行。
IN/NOT函式，裏面參數不宜過多，建議不超過100個；如果是長正文的話儘量控制在10個值以內。
IF公式巢狀不要超過4層，儘量用SWITCH代替IF巢狀。
明細過濾欄位不使用FIXED/DEF函式。
明細函式不與聚合函式混用。
日期轉換公式儘量簡單。
例如，正確方式：TODATE(TOSTRING(${日期}),"yyyyMMdd")
錯誤方式：TODATE(CONCATENATE(LEFT(${日期},4),"- ",MID(${日期},5,2),"-",RIGHT(${日期},2))) 。
過濾優化建議：
對於及相對固定的一些過濾，下放到自助資料集中進行；在組件中使用過濾組件的參數參與計算和過濾時，除非需要查看時動態改變參數值，否則儘量放在自助資料集解決。
將表頭過濾 修改為 結果過濾器過濾 或者 過濾組件過濾，達到同樣的過濾效果。
用“包含/不包含”等條件，替代 “屬於固定值再進行模糊搜尋”的過濾 。
減少過濾組件和明細過濾的聯動，儘量使用FineBI自帶組件過濾。
為過濾組件配置對應的維度表作為下拉選項，過濾元件綁定值不要與事實表綁定。
維度表：用來綁定參數元件值的資料表，例：產品維度表。
事實表：資料庫表某業務表明細資料，資料量大，例：產品銷售明細表。
使用【BI預覽自動重新整理範本】插件對範本進行定時重新整理時，若重新整理頻率設定過高，或者同一時間重新整理的範本過多，會導致系統卡慢。
重新整理優化建議：
單張範本重新整理頻率不低於60s。
如果有較多範本需要重新整理，將大範本的開始重新整理時間點錯開。
在5.X版本中，新增組件時，當多個組件使用的資料表是同一張資料表，或者使用的資料表之間有聯動關係，那麼這多個組件之間有系統預設設定的聯動。
在6.0版本中，新增組件時，當多個組件使用的資料表是同一張資料表，那麼這多個組件之間有系統預設設定的聯動。
編輯或者預覽時點選觸發聯動，多層聯動巢狀場景，類似 組件A 聯動到 組件B 再聯動 組件C ，在多個組件間互相點選進行聯動，超過 5 個組件時，會造成前端瀏覽器卡死，伺服器的cpu記憶體上升，日誌膨脹，進而導致服務不可用。
聯動優化建議：
如果實際業務場景並不需要預設聯動，則關閉儀表板的【開啟預設聯動】；根據組件間邏輯手動新增需要的聯動。
如果實際業務場景需要預設聯動，但並不需要多次聯動後的結果，則可以在組件間聯動三次後，手動清除儀表板聯動。
匯出優化建議：
限制匯出數量：在所用表資料量較大的儀表板中說明匯出限制，全局匯出限制xx，組件匯出限制xx。
減少資料量：透過組件過濾的方式，減小資料量、分多次匯出。（BI v5.1.20及之後的版本，預設限制交叉表匯出列數為100，不建議匯出超過100列的資料，會有當機風險。建議超過該限制的表格透過調整資料來滿足限制。）
減少計算量：包括排序，分組匯總，計算指標，過濾等，如果計算量過大，可以做成抽取自助資料集優化。
限制匯出時間：使用排程管理功能，在工程閒置時段進行匯出。
滑鼠選中內容，快速回饋問題
滑鼠選中存在疑惑的內容，即可快速回饋問題，我們將會跟進處理。
不再提示
10s後關閉
反馈已提交
网络繁忙