開源SPL的出現(xiàn)，將使報表數(shù)據(jù)準(zhǔn)備的困難得到巨大的改觀
現(xiàn)在應(yīng)用中的報表大都使用報表工具開發(fā)，成熟的報表工具提供了豐富的顯示設(shè)置、圖表類型、導(dǎo)出打印等功能可以簡化報表開發(fā)，非常方便。但是，實(shí)際報表開發(fā)中還是經(jīng)常碰到一些非常棘手的深層次問題，即使是已經(jīng)熟練使用報表工具的開發(fā)老手也會很撓頭。為什么有了報表工具還會出現(xiàn)這些問題呢？報表開發(fā)，看起來就是將數(shù)據(jù)按照指定格式的表格或圖形呈現(xiàn)出來，這也是報表工具一直很擅長的環(huán)節(jié)。但是，原始數(shù)據(jù)經(jīng)常并不適合直接呈現(xiàn)，需要先做一些復(fù)雜的處理，這就是數(shù)據(jù)準(zhǔn)備環(huán)節(jié)。從報表工具的眼光上看，數(shù)據(jù)準(zhǔn)備屬于報表之外的事情，可以堂而皇之地拒絕處理。但是，拒絕不等于不存在，這個工作總還要做。沒有好的工具，目前報表的數(shù)據(jù)準(zhǔn)備還處于比較原始的硬編碼階段，幾百上千行的 SQL、幾十上百 K 的存儲過程和大量的 JAVA 代碼充斥在報表之后。落后的工具必然導(dǎo)致低下的生產(chǎn)效率，會嚴(yán)重拖累整個報表開發(fā)的進(jìn)程，也就出現(xiàn)了前述的“撓頭”現(xiàn)象。再由于大多數(shù)報表工具的不重視，這個問題遲遲還沒有被解決的跡象。報表數(shù)據(jù)準(zhǔn)備之于報表有如樹根之于大樹，如果根本得不到解決，在枝葉上花多少精力都是白費(fèi)。開源 SPL 的出現(xiàn)，將使報表數(shù)據(jù)準(zhǔn)備的困難得到巨大的改觀。SPL（Structured Process Language）是專業(yè)的開源結(jié)構(gòu)化數(shù)據(jù)計算引擎，提供了豐富的計算類庫，支持過程計算，擅長完成各類復(fù)雜計算。同時開放計算體系支持多數(shù)據(jù)源混合計算，支持熱切換，提供標(biāo)準(zhǔn) JDBC 接口可與報表工具無縫集成。
與 SQL 不同，SPL 提倡分步計算，算法可以按照自然思維一步步實(shí)現(xiàn)，這樣就可以避免編寫過于復(fù)雜的 SQL（復(fù)雜 SQL 不僅難寫，維護(hù)也不方便）。
這里拿 SPL 和 SQL 做個對比（Java 計算要復(fù)雜得多，不太具備可比性）。查詢目標(biāo)：根據(jù)股票記錄表查詢股價連續(xù)上漲超過 5 天的股票及上漲天數(shù)（股價相等記為上漲）SQL 實(shí)現(xiàn)要嵌套 3 層子查詢才能完成：
每步計算的結(jié)果都可以實(shí)時查看，相比 SQL 和存儲過程不好調(diào)試要方便高效得多。SPL 可以與報表工具集成嵌入使用，SPL 提供了標(biāo)準(zhǔn) JDBC 接口供報表工具調(diào)用，這樣就可以無縫取代原來實(shí)現(xiàn)報表數(shù)據(jù)準(zhǔn)備的硬編碼方式，甚至可以與原有方式共存。
這個運(yùn)算復(fù)雜度是平方級的，數(shù)據(jù)量小的時候沒什么影響，數(shù)據(jù)量稍大時性能就會急劇下降。解決辦法是將在報表端實(shí)現(xiàn)的多數(shù)據(jù)集關(guān)聯(lián)運(yùn)算轉(zhuǎn)移到數(shù)據(jù)準(zhǔn)備階段完成。如果是同一個數(shù)據(jù)庫可以使用 SQL，但如果 SQL 運(yùn)行效率不高，或者數(shù)據(jù)來自多源時，可以使用 SPL 完成關(guān)聯(lián)計算。仍然是借助 SPL 的多源能力、高性能算法以及高性能存儲來達(dá)到提速的目的。
降低報表的開發(fā)工作量
報表開發(fā)主要分兩個階段：第一階段是為報表準(zhǔn)備數(shù)據(jù)，也就是把原始數(shù)據(jù)通過 SQL/ 存儲過程 /Java 加工成報表可用的數(shù)據(jù)集；第二階段是使用已準(zhǔn)備的數(shù)據(jù)編寫表達(dá)式進(jìn)行報表呈現(xiàn)。數(shù)據(jù)呈現(xiàn)使用報表工具可以簡單地完成，尤其近些年前端可視化技術(shù)的進(jìn)步，越來越多報表都以圖形的方式呈現(xiàn)，這更降低了報表呈現(xiàn)階段的難度。然而，數(shù)據(jù)準(zhǔn)備并沒有工具化。粗略統(tǒng)計，在報表工具支持下，數(shù)據(jù)呈現(xiàn)在當(dāng)前報表開發(fā)的工作量占比能降到 20%，剩下80% 都是數(shù)據(jù)準(zhǔn)備，甚至更高。這時候，如果要優(yōu)化報表開發(fā)、提升報表開發(fā)效率也要從報表數(shù)據(jù)準(zhǔn)備方面入手。當(dāng)前數(shù)據(jù)準(zhǔn)備的主要方式是 SQL（包括存儲過程）和 Java。后者要比前者麻煩得多，主要是因?yàn)?Java 缺少結(jié)構(gòu)化計算類庫，并非專門的集合計算語言。但 SQL 缺乏分步機(jī)制實(shí)現(xiàn)復(fù)雜計算時也非常繁瑣，加上只能基于數(shù)據(jù)庫，當(dāng)碰到其他類型的數(shù)據(jù)源時就只能依靠 Java 了。另外，目前的一些前后端分離、微服務(wù)架構(gòu)要求只能在應(yīng)用端用 Java 硬編碼。這些因素都增加了報表數(shù)據(jù)準(zhǔn)備的工作量，導(dǎo)致報表開發(fā)效率不高。使用開源 SPL 可以輔助 / 替代原有的報表數(shù)據(jù)準(zhǔn)備方式，借助 SPL 簡潔的語法和豐富的類庫可以快速完成報表數(shù)據(jù)準(zhǔn)備任務(wù)，從而減少報表開發(fā)的工作量。豐富的計算類庫：與 SQL 不同，SPL 提倡分步計算，算法可以按照自然思維一步步實(shí)現(xiàn)，這樣就可以避免編寫過于復(fù)雜的 SQL（復(fù)雜 SQL 不僅難寫，維護(hù)也不方便）。這里拿 SPL 和 SQL 做個對比（Java 計算要復(fù)雜得多，不太具備可比性）。查詢目標(biāo)：根據(jù)股票記錄表查詢股價連續(xù)上漲超過 5 天的股票及上漲天數(shù)（股價相等記為上漲）SQL 實(shí)現(xiàn)要嵌套 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(selectcode,ddate,case when price>=lag(price) over(partition by code order by ddate)then 0 else 1 end changeSignfrom 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 |
計算每只股票的連續(xù)上漲天數(shù) |
| 4 | =A3.select(maxrisedays>=5) | 選出符合條件的記錄 |
SPL 還提供了簡潔易用的開發(fā)環(huán)境，單步執(zhí)行、設(shè)置斷點(diǎn)，所見即所得的結(jié)果預(yù)覽窗口…
每步計算的結(jié)果都可以實(shí)時查看，相比 SQL 和存儲過程不好調(diào)試要方便高效得多。SPL 可以與報表工具集成嵌入使用，SPL 提供了標(biāo)準(zhǔn) JDBC 接口供報表工具調(diào)用，這樣就可以無縫取代原來實(shí)現(xiàn)報表數(shù)據(jù)準(zhǔn)備的硬編碼方式，甚至可以與原有方式共存。改善存儲過程和 JAVA 做數(shù)據(jù)準(zhǔn)備的缺點(diǎn)
在報表開發(fā)中為了應(yīng)對復(fù)雜的數(shù)據(jù)準(zhǔn)備邏輯而使用存儲過程和 Java 處理數(shù)據(jù)的情況并不少見，在獲得非常有限的開發(fā)便利時，卻帶來了巨大的麻煩。存儲過程編輯調(diào)試?yán)щy，沒有移植性更難以擴(kuò)展，會造成報表與數(shù)據(jù)庫的高度耦合，創(chuàng)建修改存儲過程需要較高的數(shù)據(jù)庫權(quán)限會帶來安全隱患，存儲過程往往需要專門的 DBA 維持，也推高了報表開發(fā)成本。不僅如此，同一個存儲過程還可能被不同模塊甚至不同應(yīng)用共用，這就造成了應(yīng)用間的緊耦合，牽存儲過程一發(fā)而動應(yīng)用全身。SPL 提供了不依賴數(shù)據(jù)庫的計算能力，從存儲過程的角度看 SPL 類似一種“庫外存儲過程”。這樣可以充分解耦報表和數(shù)據(jù)庫、應(yīng)用與應(yīng)用，不再存在安全問題，移植性也大大增強(qiáng)，再借助 SPL 開放的多樣數(shù)據(jù)源支持，數(shù)據(jù)庫擴(kuò)展或更改時只需要修改數(shù)據(jù)源連接，無需更改計算邏輯，可以很好實(shí)現(xiàn)平滑移植。Java 由于缺少結(jié)構(gòu)化計算類庫，實(shí)現(xiàn)報表數(shù)據(jù)準(zhǔn)備代碼編寫難度大，同樣存在依賴專業(yè)程序員推高報表開發(fā)成本的問題。Java 實(shí)現(xiàn)數(shù)據(jù)準(zhǔn)備還會造成報表模塊和應(yīng)用其他模塊的緊耦合，不利于將查詢壓力大的報表模塊單獨(dú)維護(hù)。作為編譯型語言，Java 缺乏有效的熱切換機(jī)制，對頻繁多變的報表業(yè)務(wù)十分不利。SPL 的語法更為簡潔，實(shí)現(xiàn)同樣的計算代碼更短，報表開發(fā)人員就可以學(xué)習(xí)使用，人力成本更低。SPL 可以與報表模塊集成，獨(dú)立于應(yīng)用其他模塊，單獨(dú)運(yùn)行維護(hù)，降低應(yīng)用間的耦合性。同時，SPL 解釋執(zhí)行支持熱切換，可以更好適應(yīng)多變的報表業(yè)務(wù)。減少數(shù)據(jù)庫中的中間表
為了簡化 SQL 運(yùn)算難度或提高查詢性能，或應(yīng)對多源情況，經(jīng)常會進(jìn)行數(shù)據(jù)預(yù)處理，事先加工出一部分中間結(jié)果存在數(shù)據(jù)庫中形成數(shù)據(jù)庫中間表。報表開發(fā)時數(shù)據(jù)準(zhǔn)備基于這些中間表完成，通常可以一定程度簡化開發(fā)難度并獲得較高的查詢性能。但中間表是一把雙刃劍，提供便利的同時缺點(diǎn)也很多。大多數(shù)情況下的中間表一旦建立幾乎就無法刪除（因?yàn)閿?shù)據(jù)庫表的管理機(jī)制是線性的，很難分類以確定中間表的歸屬，不敢輕易刪除），這就會導(dǎo)致中間表越來越多，有時竟然高達(dá)數(shù)萬。中間表要占用數(shù)據(jù)庫空間，導(dǎo)致數(shù)據(jù)庫容量不夠；而加工中間表則需要數(shù)據(jù)庫計算資源，導(dǎo)致數(shù)據(jù)庫性能下降，中間表過多會導(dǎo)致數(shù)據(jù)庫面臨擴(kuò)容壓力。SPL 提供了不依賴數(shù)據(jù)庫的計算能力，可以將中間表存儲到庫外文件中（開放數(shù)據(jù)文件格式或 SPL 存儲格式），SPL 基于文件進(jìn)行數(shù)據(jù)處理為報表輸出計算結(jié)果，完成數(shù)據(jù)準(zhǔn)備。將大量中間表外置到文件系統(tǒng)可以大幅減輕數(shù)據(jù)庫的壓力，既不用占用數(shù)據(jù)庫的寶貴空間，更不需要犧牲數(shù)據(jù)庫計算資源來加工中間表可謂一舉兩得。不僅如此，“庫外中間表”可以使用文件系統(tǒng)的樹狀結(jié)構(gòu)進(jìn)行管理，不同目錄的中間數(shù)據(jù)對應(yīng)不同業(yè)務(wù)的報表，不僅方便管理，還能進(jìn)一步降低報表模塊間的耦合性。實(shí)現(xiàn)報表的熱切換
熱切換（Hot Swap）是指在系統(tǒng)不停機(jī)的情況下更換系統(tǒng)部件，在報表業(yè)務(wù)中則是指在不重啟報表及相關(guān)應(yīng)用的情況下完成對報表的維護(hù)（新增、修改、刪除），實(shí)時修改，實(shí)時生效。目前大部分報表工具開發(fā)的呈現(xiàn)模板都能熱切換，不過作為報表一部分的數(shù)據(jù)準(zhǔn)備情況卻有所不同。使用數(shù)據(jù)庫 SQL 完成數(shù)據(jù)準(zhǔn)備可以直接做到熱切換，但編譯型的 Java 不行。而現(xiàn)在隨著更先進(jìn)架構(gòu)（如微服務(wù)）的應(yīng)用，使用 Java 完成報表數(shù)據(jù)準(zhǔn)備的情況非常常見。為了解決報表熱切換的問題，可以使用 SPL 替代 Java 完成諸如微服務(wù)架構(gòu)中的報表數(shù)據(jù)準(zhǔn)備工作。SPL 解釋執(zhí)行，天然支持熱切換，同時具備完善的計算體系以及敏捷語法可以很方便地實(shí)現(xiàn)數(shù)據(jù)處理任務(wù)。解決多樣性數(shù)據(jù)源
當(dāng)前報表的數(shù)據(jù)來源十分豐富，RDB、NoSQL、CSV、Excel、HDFS、Restful/Webservice、Kafka…都可以成為報表數(shù)據(jù)源，多樣性數(shù)據(jù)源會帶來兩個問題，如何連接這些數(shù)據(jù)源？連接后如何關(guān)聯(lián)計算？而在前后端分離、微服務(wù)等架構(gòu)下，幾乎所有報表都不會直接基于數(shù)據(jù)庫開發(fā)，多樣數(shù)據(jù)源問題就更加嚴(yán)重。以往解決報表多樣源問題的方式有三種：一是借助報表工具的能力。有些報表工具提供了多種數(shù)據(jù)源連接支持，分別取數(shù)后在報表呈現(xiàn)模板中完成關(guān)聯(lián)等計算。不過，報表工具的計算能力很弱，只能實(shí)現(xiàn)很有限的多源混合計算。二是將多源數(shù)據(jù) ETL 到一個 RDB 中，將多源轉(zhuǎn)化成單源再借助 SQL 能力完成計算。這種方式不僅很繁瑣，數(shù)據(jù)也不實(shí)時，數(shù)據(jù)量大或計算復(fù)雜時還會引發(fā)數(shù)據(jù)庫性能問題。而且這也嚴(yán)重有悖于微服務(wù)架構(gòu)的原則。三是使用 Java 硬編碼。Java 的問題我們已經(jīng)說過多次，不僅編碼難度高，而且也不支持熱切換。開源 SPL 目前提供了幾十種數(shù)據(jù)源支持，可以快速連接這些數(shù)據(jù)源完成取數(shù)計算。不僅是連接取數(shù)，SPL 提供豐富的計算類庫可以很方便進(jìn)行異構(gòu)源混合計算，實(shí)現(xiàn)多源關(guān)聯(lián)等復(fù)雜計算。 SPL 實(shí)時基于多源完成計算，將計算后結(jié)果直接輸出報表進(jìn)行呈現(xiàn)，不僅解決了數(shù)據(jù)實(shí)時性問題，也改善了報表工具計算能力不足、Java 編碼難熱切換難的困境，是報表多樣源問題的有效解決方式。提升報表性能
報表性能是總也避不開的話題，報表作為 OLAP 中的最主要應(yīng)用場景，涉及的數(shù)據(jù)可能很多，大數(shù)據(jù)量、計算邏輯復(fù)雜經(jīng)常會引發(fā)報表性能問題。而報表是面向業(yè)務(wù)用戶呈現(xiàn)的，性能差就會帶來很惡劣的用戶體驗(yàn)。報表性能問題表象上是報表查詢慢，但其實(shí)絕大多數(shù)都是數(shù)據(jù)準(zhǔn)備引起的，一旦數(shù)據(jù)準(zhǔn)備好，呈現(xiàn)效率往往很高。報表數(shù)據(jù)準(zhǔn)備是將原始數(shù)據(jù)加工成報表需要的數(shù)據(jù)集，報表要呈現(xiàn)的通常是聚合后的匯總結(jié)果數(shù)據(jù)量并不大，但原始數(shù)據(jù)卻可能非常大，不僅數(shù)據(jù)量大，數(shù)據(jù)處理邏輯也可能很復(fù)雜，這些都會造成低性能。解決辦法除了常見的優(yōu)化 SQL 以外，還可以使用 SPL 提速。SQL 執(zhí)行效率依賴數(shù)據(jù)庫的優(yōu)化能力，而對復(fù)雜 SQL 數(shù)據(jù)庫優(yōu)化引擎經(jīng)常失效，導(dǎo)致執(zhí)行效率不高。這時可以將計算邏輯使用 SPL 實(shí)現(xiàn)，借助 SPL 的高性能算法達(dá)到提速的目的。如果因?yàn)閿?shù)據(jù)庫過于繁忙（壓力過大）導(dǎo)致查詢慢，優(yōu)化 SQL 也無能為力；甚至根本無 SQL 可用（非 RDB 源）時，使用不依賴數(shù)據(jù)庫能力的 SPL 就比較有效了。特別說明的是，對于計算密集型任務(wù)，使用 SPL 優(yōu)化時經(jīng)常需要將數(shù)據(jù)事先外置到文件系統(tǒng)再進(jìn)行，目的是減少 RDB 到 SPL 的 IO 時間，如果從數(shù)據(jù)庫實(shí)時取數(shù)計算，IO 時間可能比計算時間還要長。另外，SPL 存儲在數(shù)據(jù)組織方式上有很大優(yōu)勢，基于 SPL 存儲計算可以獲得更高性能。除了數(shù)據(jù)準(zhǔn)備外，數(shù)據(jù)傳輸也是另一個瓶頸。報表通過 JDBC 接口訪問數(shù)據(jù)庫讀取所需數(shù)據(jù)時，如果數(shù)據(jù)量比較大或者數(shù)據(jù)庫 JDBC 性能較差（各種數(shù)據(jù)庫的 JDBC 效率是不同的）會導(dǎo)致數(shù)據(jù)傳輸時間過長，導(dǎo)致報表變慢。對于數(shù)據(jù)密集型的報表，可以通過 SPL并行取數(shù)來提速。在 SPL 中建立多個數(shù)據(jù)庫連接（這時要求數(shù)據(jù)庫相對空閑），采用多線程的方式同時讀取報表所需數(shù)據(jù)，可以是同一個表，也可以是多個表關(guān)聯(lián)計算后的結(jié)果，這樣數(shù)據(jù)傳輸?shù)臅r間理論上就會縮短到原來的 1/n（n 是線程數(shù)），從而提升報表性能。此外，報表本身也可能發(fā)生計算較慢的問題。比如報表工具完成多數(shù)據(jù)集的關(guān)聯(lián)是在報表單元格的表達(dá)式中完成的，類似這樣 ds2.select(ID==ds1.ID)，報表引擎在解析這個表達(dá)式時會按照順序遍歷的方式完成關(guān)聯(lián)，即從 ds2（數(shù)據(jù)集 2） 中拿出一條記錄，到 ds1 （數(shù)據(jù)集 1）中遍歷，查找 ID 相同的記錄；然后再拿第二條再去遍歷查找；…這個運(yùn)算復(fù)雜度是平方級的，數(shù)據(jù)量小的時候沒什么影響，數(shù)據(jù)量稍大時性能就會急劇下降。解決辦法是將在報表端實(shí)現(xiàn)的多數(shù)據(jù)集關(guān)聯(lián)運(yùn)算轉(zhuǎn)移到數(shù)據(jù)準(zhǔn)備階段完成。如果是同一個數(shù)據(jù)庫可以使用 SQL，但如果 SQL 運(yùn)行效率不高，或者數(shù)據(jù)來自多源時，可以使用 SPL 完成關(guān)聯(lián)計算。仍然是借助 SPL 的多源能力、高性能算法以及高性能存儲來達(dá)到提速的目的。
低成本應(yīng)對沒完沒了
報表不同于企業(yè)信息系統(tǒng)的其他部分，會伴隨系統(tǒng)生命周期一直不斷新增、修改。這是由于企業(yè)在生產(chǎn)經(jīng)營過程中會不斷催生出新的報表需求，這就造成了沒完沒了的報表。沒完沒了的報表無法消除，只能適應(yīng)，這就需要低成本的適應(yīng)方案。總體來講，想要高效率、低成本地應(yīng)對報表沒完沒了可以按照這樣幾步來走：第一步，引入報表工具解決報表呈現(xiàn)階段的人力。先把最容易解決的問題解決掉，通過引入專業(yè)的報表工具解放報表數(shù)據(jù)呈現(xiàn)階段的人力，完成各類圖表呈現(xiàn)。目前大部分用戶都會使用報表工具開發(fā)報表，因此這一步已基本實(shí)現(xiàn)。第二步，引入計算工具解決報表數(shù)據(jù)準(zhǔn)備階段的人力。跟第一步類似，要將報表數(shù)據(jù)準(zhǔn)備也工具化才能徹底解決以往報表數(shù)據(jù)準(zhǔn)備效率低下的問題。前文我們討論的都是這個階段的問題，利用開源 SPL 編碼簡潔、多源支持、熱切換等特性可以很好實(shí)現(xiàn)數(shù)據(jù)準(zhǔn)備工具化。配合第一步，可以讓整個報表開發(fā)工作全面工具化，從而獲得更高的開發(fā)效率。第三步，獨(dú)立報表模塊優(yōu)化應(yīng)用結(jié)構(gòu)。報表開發(fā)全面工具化后，就可以調(diào)整應(yīng)用結(jié)構(gòu)，把報表模塊從業(yè)務(wù)系統(tǒng)中解耦出來。報表模塊僅僅共享業(yè)務(wù)系統(tǒng)的數(shù)據(jù)源（數(shù)據(jù)庫或別的數(shù)據(jù)存儲介質(zhì)），而不再和業(yè)務(wù)系統(tǒng)緊密耦合。報表呈現(xiàn)和數(shù)據(jù)準(zhǔn)備都工具化之后，報表運(yùn)算可以被中間件解釋執(zhí)行，這樣，報表的頻繁修改增加也不需要讓業(yè)務(wù)系統(tǒng)都重新啟動，大幅降低運(yùn)維的復(fù)雜度。這個過程特別重要的是梳理數(shù)據(jù)源，把報表模塊需要的數(shù)據(jù)源單獨(dú)整理出來，以后開發(fā)報表只需要和這些數(shù)據(jù)源打交道。通過這樣三步將報表開發(fā)全面工具化，提升了報表開發(fā)效率，同時還優(yōu)化了應(yīng)用結(jié)構(gòu)，獨(dú)立后的報表模塊單獨(dú)運(yùn)維，無論從技術(shù)架構(gòu)上還是人員架構(gòu)上都更為合理，有效應(yīng)對沒完沒了的報表。審核編輯 ：李倩
聲明：本文內(nèi)容及配圖由入駐作者撰寫或者入駐合作網(wǎng)站授權(quán)轉(zhuǎn)載。文章觀點(diǎn)僅代表作者本人，不代表電子發(fā)燒友網(wǎng)立場。文章及其配圖僅供工程師學(xué)習(xí)之用，如有內(nèi)容侵權(quán)或者其他違規(guī)問題，請聯(lián)系本站處理。
舉報投訴
-
數(shù)據(jù)
+關(guān)注
關(guān)注
8文章
7297瀏覽量
93492 -
spl
+關(guān)注
關(guān)注
0文章
20瀏覽量
16644 -
開源工具
+關(guān)注
關(guān)注
0文章
27瀏覽量
4720
原文標(biāo)題：有了這個開源工具，數(shù)據(jù)準(zhǔn)備太方便了！
文章出處：【微信號：DBDevs，微信公眾號：數(shù)據(jù)分析與開發(fā)】歡迎添加關(guān)注！文章轉(zhuǎn)載請注明出處。
發(fā)布評論請先 登錄
相關(guān)推薦
熱點(diǎn)推薦
開源鴻蒙（金華）應(yīng)用創(chuàng)新示范中心”在浦江揭牌，浦江打造開源鴻蒙生態(tài)城市新標(biāo)桿！
開源
深開鴻
發(fā)布于 :2025年10月20日 14:15:49
EM儲能網(wǎng)關(guān) ZWS智慧儲能云應(yīng)用(21) — 自定義報表
在儲能運(yùn)營中，精準(zhǔn)的電量數(shù)據(jù)統(tǒng)計對客戶收益與運(yùn)營策略意義重大。客戶電表種類多樣，希望在儲能平臺查看數(shù)據(jù)。儲能云平臺的自定義報表功能可滿足多樣化需求，內(nèi)置統(tǒng)計方式，統(tǒng)一報表風(fēng)格。前言在儲
fn_u-boot-spl.bin和u-boot-spl.bin區(qū)別是什么？請問如何從u-boot-spl.bin生成fn_u-boot-spl.bin？
fn_u-boot-spl.bin = bootrom頭 + u-boot-spl.bin ；生成過程見后面代碼片段；
bootrom頭(格式詳見) + u-boot-spl.bin(標(biāo)準(zhǔn)的一級
發(fā)表于 07-11 07:58
使用AD芯片對正弦波采樣，得到這樣的結(jié)果，可能是哪里出現(xiàn)問題？
使用AD芯片對正弦波采樣，得到這樣的結(jié)果，可能是哪里出現(xiàn)問題？
發(fā)表于 04-03 18:51
使用Newlib時出現(xiàn)FreeRTOS硬故障怎么解決？
（不精確的數(shù)據(jù)總線）
已附加項(xiàng)目
切換到 Redlib 工作正常，newlib 崩潰
如果我關(guān)閉空閑功能，似乎工作正常，盡管我沒有進(jìn)一步排除故障
我的目標(biāo)是讓 Segger RTT 在 CM4 內(nèi)核上運(yùn)行，事實(shí)證明這比預(yù)期的要困難得多。有沒有這方面的例子？
發(fā)表于 04-02 07:08
NVIDIA推出開源物理AI數(shù)據(jù)集
標(biāo)準(zhǔn)化合成數(shù)據(jù)的初始版本預(yù)計將成為世界上最大的此類數(shù)據(jù)集，目前已作為開源版本提供給機(jī)器人開發(fā)人員。
i.mx8m如何在u-boot SPL階段啟用pwm？
硬件：i.mx8m mini。
U-Boot 版本：2023.01 DFSG-2
我想讓 pwm 點(diǎn)亮我的 spl.c 中的 LED，這樣用戶在接通板子電源后就可以立即看到燈亮了。
我沒有找到將
發(fā)表于 03-21 07:51
【貝啟科技BQ3568HM開源鴻蒙開發(fā)板深度試用報告】1 - 開箱測試和技術(shù)資料準(zhǔn)備
科技BQ3568HM開源鴻蒙開發(fā)板、5.5寸觸摸屏、電源適配器、USB數(shù)據(jù)線及WiFi天線。
開機(jī)測試
插上電源開機(jī)后，系統(tǒng)顯示的是潤和的DAYU的logo，看來廠商提供的軟件包主要來自主線代碼，定制的內(nèi)容不多
發(fā)表于 01-21 11:17
DDC112只是做一個通道的轉(zhuǎn)換，是否可以直接用CONV置高或者置低，轉(zhuǎn)換得到的是40位的數(shù)據(jù)，還是20位的數(shù)據(jù)？
按照datasheet 中兩通道轉(zhuǎn)換，用CONV控制.
假設(shè)我僅僅只是做一個通道的轉(zhuǎn)換，是否可以直接用CONV置高或者置低，轉(zhuǎn)換得到的是40位的數(shù)據(jù)（20位和不轉(zhuǎn)換交替出現(xiàn)），還是20位的數(shù)
發(fā)表于 01-14 06:53
用ADS1256結(jié)合飛思卡爾的單片機(jī)設(shè)計一個數(shù)據(jù)采集系統(tǒng)，為什么采用SPI通信時得到的總是一個固定的數(shù)？
我準(zhǔn)備用ADS1256結(jié)合飛思卡爾的單片機(jī)設(shè)計一個數(shù)據(jù)采集系統(tǒng)，但是不知道為什么采用ＳＰＩ通信時，得到的總是一個固定的數(shù)。
發(fā)表于 01-02 06:02
自動化報表生成：水庫水雨情監(jiān)測系統(tǒng)的數(shù)據(jù)可視化功能
在現(xiàn)代水庫管理中，水雨情監(jiān)測系統(tǒng)不僅承擔(dān)著實(shí)時監(jiān)測水情、降水、氣象等數(shù)據(jù)的任務(wù)，同時還通過數(shù)據(jù)可視化功能將復(fù)雜的水文信息呈現(xiàn)為易于理解的圖表、報表等，極大提升了水庫管理的決策效率和準(zhǔn)確性。自動化
使用ads131a04過程中，實(shí)際采集得到的最大數(shù)據(jù)約為理論的1.8倍，為什么？
大家好，我在使用ads131a04過程中出現(xiàn)一個問題，我是使用外部參考電壓模式，參考電壓為2.5V，ADC前端輸入差分信號，AINP和AINN輸入信號峰峰值為700mVpp，ADC采用16位數(shù)據(jù)
發(fā)表于 12-17 08:07
ADS1256設(shè)置不同的數(shù)據(jù)輸出速率的時候，得到的24bit的輸出數(shù)據(jù)不相同，為什么？
在使用ADS1256采集數(shù)據(jù)時出現(xiàn)問題描述如下：當(dāng)設(shè)置不同的數(shù)據(jù)輸出速率的時候，得到的24bit的輸出數(shù)據(jù)不相同。
采集系統(tǒng)硬件描述如下，
發(fā)表于 12-13 06:34
LSTM神經(jīng)網(wǎng)絡(luò)的訓(xùn)練數(shù)據(jù)準(zhǔn)備方法
LSTM（Long Short-Term Memory，長短期記憶）神經(jīng)網(wǎng)絡(luò)的訓(xùn)練數(shù)據(jù)準(zhǔn)備方法是一個關(guān)鍵步驟，它直接影響到模型的性能和效果。以下是一些關(guān)于LSTM神經(jīng)網(wǎng)絡(luò)訓(xùn)練數(shù)據(jù)準(zhǔn)備的
工商網(wǎng)監(jiān)
評論