国产日韩一区二区,精品久久久日本综合电影 ,天天综合在线你懂的

現在應用中的報表大都使用報表工具開發，成熟的報表工具提供了豐富的顯示設置、圖表類型、導出打印等功能可以簡化報表開發，非常方便。但是，實際報表開發中還是經常碰到一些非常棘手的深層次問題，即使是已經熟練使用報表工具的開發老手也會很撓頭。為什么有了報表工具還會出現這些問題呢？報表開發，看起來就是將數據按照指定格式的表格或圖形呈現出來，這也是報表工具一直很擅長的環節。但是，原始數據經常并不適合直接呈現，需要先做一些復雜的處理，這就是數據準備環節。從報表工具的眼光上看，數據準備屬于報表之外的事情，可以堂而皇之地拒絕處理。但是，拒絕不等于不存在，這個工作總還要做。沒有好的工具，目前報表的數據準備還處于比較原始的硬編碼階段，幾百上千行的 SQL、幾十上百 K 的存儲過程和大量的 JAVA 代碼充斥在報表之后。落后的工具必然導致低下的生產效率，會嚴重拖累整個報表開發的進程，也就出現了前述的“撓頭”現象。再由于大多數報表工具的不重視，這個問題遲遲還沒有被解決的跡象。報表數據準備之于報表有如樹根之于大樹，如果根本得不到解決，在枝葉上花多少精力都是白費。開源 SPL 的出現，將使報表數據準備的困難得到巨大的改觀。SPL（Structured Process Language）是專業的開源結構化數據計算引擎，提供了豐富的計算類庫，支持過程計算，擅長完成各類復雜計算。同時開放計算體系支持多數據源混合計算，支持熱切換，提供標準 JDBC 接口可與報表工具無縫集成。

降低報表的開發工作量

報表開發主要分兩個階段：第一階段是為報表準備數據，也就是把原始數據通過 SQL/ 存儲過程 /Java 加工成報表可用的數據集；第二階段是使用已準備的數據編寫表達式進行報表呈現。數據呈現使用報表工具可以簡單地完成，尤其近些年前端可視化技術的進步，越來越多報表都以圖形的方式呈現，這更降低了報表呈現階段的難度。然而，數據準備并沒有工具化。粗略統計，在報表工具支持下，數據呈現在當前報表開發的工作量占比能降到 20%，剩下80% 都是數據準備，甚至更高。這時候，如果要優化報表開發、提升報表開發效率也要從報表數據準備方面入手。當前數據準備的主要方式是 SQL（包括存儲過程）和 Java。后者要比前者麻煩得多，主要是因為 Java 缺少結構化計算類庫，并非專門的集合計算語言。但 SQL 缺乏分步機制實現復雜計算時也非常繁瑣，加上只能基于數據庫，當碰到其他類型的數據源時就只能依靠 Java 了。另外，目前的一些前后端分離、微服務架構要求只能在應用端用 Java 硬編碼。這些因素都增加了報表數據準備的工作量，導致報表開發效率不高。使用開源 SPL 可以輔助 / 替代原有的報表數據準備方式，借助 SPL 簡潔的語法和豐富的類庫可以快速完成報表數據準備任務，從而減少報表開發的工作量。豐富的計算類庫：

與 SQL 不同，SPL 提倡分步計算，算法可以按照自然思維一步步實現，這樣就可以避免編寫過于復雜的 SQL（復雜 SQL 不僅難寫，維護也不方便）。

這里拿 SPL 和 SQL 做個對比（Java 計算要復雜得多，不太具備可比性）。查詢目標：根據股票記錄表查詢股價連續上漲超過 5 天的股票及上漲天數（股價相等記為上漲）SQL 實現要嵌套 3 層子查詢才能完成：

select code,max(risenum)-1 maxRiseDays from (  select code,count(1) risenum from  (    select code,changeSign,sum(changeSign) over(partition by code order by ddate) unRiseDays from    (        select               code,              ddate,              case when price>=lag(price) over(partition by code order by ddate)              then 0 else 1 end changeSign        from stock_record     )  )  group by code,unRiseDays)group by codehavingmax(risenum)>5

而同樣的計算用 SPL 則要簡單很多：

	A
1	=connect@l("orcl").query@x("select * from stock_record order by ddate")
2	=A1.group(code)
3	=A2.new(code,~.group@i(price	計算每只股票的連續上漲天數
4	=A3.select(maxrisedays>=5)	選出符合條件的記錄

SPL 還提供了簡潔易用的開發環境，單步執行、設置斷點，所見即所得的結果預覽窗口…

每步計算的結果都可以實時查看，相比 SQL 和存儲過程不好調試要方便高效得多。SPL 可以與報表工具集成嵌入使用，SPL 提供了標準 JDBC 接口供報表工具調用，這樣就可以無縫取代原來實現報表數據準備的硬編碼方式，甚至可以與原有方式共存。

改善存儲過程和 JAVA 做數據準備的缺點

在報表開發中為了應對復雜的數據準備邏輯而使用存儲過程和 Java 處理數據的情況并不少見，在獲得非常有限的開發便利時，卻帶來了巨大的麻煩。存儲過程編輯調試困難，沒有移植性更難以擴展，會造成報表與數據庫的高度耦合，創建修改存儲過程需要較高的數據庫權限會帶來安全隱患，存儲過程往往需要專門的 DBA 維持，也推高了報表開發成本。不僅如此，同一個存儲過程還可能被不同模塊甚至不同應用共用，這就造成了應用間的緊耦合，牽存儲過程一發而動應用全身。SPL 提供了不依賴數據庫的計算能力，從存儲過程的角度看 SPL 類似一種“庫外存儲過程”。這樣可以充分解耦報表和數據庫、應用與應用，不再存在安全問題，移植性也大大增強，再借助 SPL 開放的多樣數據源支持，數據庫擴展或更改時只需要修改數據源連接，無需更改計算邏輯，可以很好實現平滑移植。Java 由于缺少結構化計算類庫，實現報表數據準備代碼編寫難度大，同樣存在依賴專業程序員推高報表開發成本的問題。Java 實現數據準備還會造成報表模塊和應用其他模塊的緊耦合，不利于將查詢壓力大的報表模塊單獨維護。作為編譯型語言，Java 缺乏有效的熱切換機制，對頻繁多變的報表業務十分不利。SPL 的語法更為簡潔，實現同樣的計算代碼更短，報表開發人員就可以學習使用，人力成本更低。SPL 可以與報表模塊集成，獨立于應用其他模塊，單獨運行維護，降低應用間的耦合性。同時，SPL 解釋執行支持熱切換，可以更好適應多變的報表業務。

減少數據庫中的中間表

為了簡化 SQL 運算難度或提高查詢性能，或應對多源情況，經常會進行數據預處理，事先加工出一部分中間結果存在數據庫中形成數據庫中間表。報表開發時數據準備基于這些中間表完成，通?？梢砸欢ǔ潭群喕_發難度并獲得較高的查詢性能。但中間表是一把雙刃劍，提供便利的同時缺點也很多。大多數情況下的中間表一旦建立幾乎就無法刪除（因為數據庫表的管理機制是線性的，很難分類以確定中間表的歸屬，不敢輕易刪除），這就會導致中間表越來越多，有時竟然高達數萬。中間表要占用數據庫空間，導致數據庫容量不夠；而加工中間表則需要數據庫計算資源，導致數據庫性能下降，中間表過多會導致數據庫面臨擴容壓力。SPL 提供了不依賴數據庫的計算能力，可以將中間表存儲到庫外文件中（開放數據文件格式或 SPL 存儲格式），SPL 基于文件進行數據處理為報表輸出計算結果，完成數據準備。將大量中間表外置到文件系統可以大幅減輕數據庫的壓力，既不用占用數據庫的寶貴空間，更不需要犧牲數據庫計算資源來加工中間表可謂一舉兩得。不僅如此，“庫外中間表”可以使用文件系統的樹狀結構進行管理，不同目錄的中間數據對應不同業務的報表，不僅方便管理，還能進一步降低報表模塊間的耦合性。

實現報表的熱切換

熱切換（Hot Swap）是指在系統不停機的情況下更換系統部件，在報表業務中則是指在不重啟報表及相關應用的情況下完成對報表的維護（新增、修改、刪除），實時修改，實時生效。目前大部分報表工具開發的呈現模板都能熱切換，不過作為報表一部分的數據準備情況卻有所不同。使用數據庫 SQL 完成數據準備可以直接做到熱切換，但編譯型的 Java 不行。而現在隨著更先進架構（如微服務）的應用，使用 Java 完成報表數據準備的情況非常常見。為了解決報表熱切換的問題，可以使用 SPL 替代 Java 完成諸如微服務架構中的報表數據準備工作。SPL 解釋執行，天然支持熱切換，同時具備完善的計算體系以及敏捷語法可以很方便地實現數據處理任務。

解決多樣性數據源

當前報表的數據來源十分豐富，RDB、NoSQL、CSV、Excel、HDFS、Restful/Webservice、Kafka…都可以成為報表數據源，多樣性數據源會帶來兩個問題，如何連接這些數據源？連接后如何關聯計算？而在前后端分離、微服務等架構下，幾乎所有報表都不會直接基于數據庫開發，多樣數據源問題就更加嚴重。以往解決報表多樣源問題的方式有三種：一是借助報表工具的能力。有些報表工具提供了多種數據源連接支持，分別取數后在報表呈現模板中完成關聯等計算。不過，報表工具的計算能力很弱，只能實現很有限的多源混合計算。二是將多源數據 ETL 到一個 RDB 中，將多源轉化成單源再借助 SQL 能力完成計算。這種方式不僅很繁瑣，數據也不實時，數據量大或計算復雜時還會引發數據庫性能問題。而且這也嚴重有悖于微服務架構的原則。三是使用 Java 硬編碼。Java 的問題我們已經說過多次，不僅編碼難度高，而且也不支持熱切換。開源 SPL 目前提供了幾十種數據源支持，可以快速連接這些數據源完成取數計算。不僅是連接取數，SPL 提供豐富的計算類庫可以很方便進行異構源混合計算，實現多源關聯等復雜計算。 SPL 實時基于多源完成計算，將計算后結果直接輸出報表進行呈現，不僅解決了數據實時性問題，也改善了報表工具計算能力不足、Java 編碼難熱切換難的困境，是報表多樣源問題的有效解決方式。

提升報表性能

報表性能是總也避不開的話題，報表作為 OLAP 中的最主要應用場景，涉及的數據可能很多，大數據量、計算邏輯復雜經常會引發報表性能問題。而報表是面向業務用戶呈現的，性能差就會帶來很惡劣的用戶體驗。報表性能問題表象上是報表查詢慢，但其實絕大多數都是數據準備引起的，一旦數據準備好，呈現效率往往很高。報表數據準備是將原始數據加工成報表需要的數據集，報表要呈現的通常是聚合后的匯總結果數據量并不大，但原始數據卻可能非常大，不僅數據量大，數據處理邏輯也可能很復雜，這些都會造成低性能。解決辦法除了常見的優化 SQL 以外，還可以使用 SPL 提速。SQL 執行效率依賴數據庫的優化能力，而對復雜 SQL 數據庫優化引擎經常失效，導致執行效率不高。這時可以將計算邏輯使用 SPL 實現，借助 SPL 的高性能算法達到提速的目的。如果因為數據庫過于繁忙（壓力過大）導致查詢慢，優化 SQL 也無能為力；甚至根本無 SQL 可用（非 RDB 源）時，使用不依賴數據庫能力的 SPL 就比較有效了。特別說明的是，對于計算密集型任務，使用 SPL 優化時經常需要將數據事先外置到文件系統再進行，目的是減少 RDB 到 SPL 的 IO 時間，如果從數據庫實時取數計算，IO 時間可能比計算時間還要長。另外，SPL 存儲在數據組織方式上有很大優勢，基于 SPL 存儲計算可以獲得更高性能。除了數據準備外，數據傳輸也是另一個瓶頸。報表通過 JDBC 接口訪問數據庫讀取所需數據時，如果數據量比較大或者數據庫 JDBC 性能較差（各種數據庫的 JDBC 效率是不同的）會導致數據傳輸時間過長，導致報表變慢。對于數據密集型的報表，可以通過 SPL并行取數來提速。在 SPL 中建立多個數據庫連接（這時要求數據庫相對空閑），采用多線程的方式同時讀取報表所需數據，可以是同一個表，也可以是多個表關聯計算后的結果，這樣數據傳輸的時間理論上就會縮短到原來的 1/n（n 是線程數），從而提升報表性能。此外，報表本身也可能發生計算較慢的問題。比如報表工具完成多數據集的關聯是在報表單元格的表達式中完成的，類似這樣 ds2.select(ID==ds1.ID)，報表引擎在解析這個表達式時會按照順序遍歷的方式完成關聯，即從 ds2（數據集 2）中拿出一條記錄，到 ds1 （數據集 1）中遍歷，查找 ID 相同的記錄；然后再拿第二條再去遍歷查找；…
這個運算復雜度是平方級的，數據量小的時候沒什么影響，數據量稍大時性能就會急劇下降。解決辦法是將在報表端實現的多數據集關聯運算轉移到數據準備階段完成。如果是同一個數據庫可以使用 SQL，但如果 SQL 運行效率不高，或者數據來自多源時，可以使用 SPL 完成關聯計算。仍然是借助 SPL 的多源能力、高性能算法以及高性能存儲來達到提速的目的。

低成本應對沒完沒了

報表不同于企業信息系統的其他部分，會伴隨系統生命周期一直不斷新增、修改。這是由于企業在生產經營過程中會不斷催生出新的報表需求，這就造成了沒完沒了的報表。沒完沒了的報表無法消除，只能適應，這就需要低成本的適應方案。總體來講，想要高效率、低成本地應對報表沒完沒了可以按照這樣幾步來走：第一步，引入報表工具解決報表呈現階段的人力。先把最容易解決的問題解決掉，通過引入專業的報表工具解放報表數據呈現階段的人力，完成各類圖表呈現。目前大部分用戶都會使用報表工具開發報表，因此這一步已基本實現。第二步，引入計算工具解決報表數據準備階段的人力。跟第一步類似，要將報表數據準備也工具化才能徹底解決以往報表數據準備效率低下的問題。前文我們討論的都是這個階段的問題，利用開源 SPL 編碼簡潔、多源支持、熱切換等特性可以很好實現數據準備工具化。配合第一步，可以讓整個報表開發工作全面工具化，從而獲得更高的開發效率。第三步，獨立報表模塊優化應用結構。報表開發全面工具化后，就可以調整應用結構，把報表模塊從業務系統中解耦出來。報表模塊僅僅共享業務系統的數據源（數據庫或別的數據存儲介質），而不再和業務系統緊密耦合。報表呈現和數據準備都工具化之后，報表運算可以被中間件解釋執行，這樣，報表的頻繁修改增加也不需要讓業務系統都重新啟動，大幅降低運維的復雜度。這個過程特別重要的是梳理數據源，把報表模塊需要的數據源單獨整理出來，以后開發報表只需要和這些數據源打交道。通過這樣三步將報表開發全面工具化，提升了報表開發效率，同時還優化了應用結構，獨立后的報表模塊單獨運維，無論從技術架構上還是人員架構上都更為合理，有效應對沒完沒了的報表。