​搜尋文章

在現代資料棧 ( MDS ) 裡的轉換層 ( transformation layer ) 主⾓其實是 SQL ，⽽ dbt ( Data Build Tool ) 則是擔任輔助⽣成 SQL 的⾓⾊。dbt 加 SQL 的組合可以完成之前許多困難的事情。 這裏分成幾個方向介紹 dbt + SQL 可以完成的事。例如: 組合 SQL、動態生成 SQL、輔助程式語言、版本控制。 組合 SQL SQL 有提供視圖 ( view ) 的機制：「 我們可以把任意的 SQL 查詢 (query)，變成一個對應的視圖 ( view ) ，並且為其命名」。從這個角度來看， SQL view 本身就是一種模組化與抽象化機制。 模組化機制： 把某個查詢變成視圖，其它的查詢⼜可以利⽤這個視圖的結果。 抽象化機制： 可以對視圖加以命名。 綜合上述， SQL 的 view 機制，就已足以讓我們靈活地組合小的查詢而生成複雜的資料轉換，同時，我們所需要的資料建模 ( data modeling ) ，恰好可以由大量的視圖 ( view ) 來構成 動態⽣成 SQL 常常遇見 SQL 結構類似 ，只是些許內容不同，每當要增加新的資料表、條件 ... ，就要修改許多程式段落。 例如 ： 該公司的用戶只有 A , B , C 三個用戶，同時訂單表的欄位只有 w , x , y , z，SQL 的內容如下 SELECT w, x, y, z, "A" AS user_name FROM A.invoices UNION ALL SELECT w, x, y, z, "B" AS user_name FROM B.invoices UNION ALL SELECT w, x, y, z, "C" AS user_name FROM C.invoices 若用戶的數量有變動時，就要不斷的修改 SQL。 若透過 jinja 樣板語言 (template language) 動態生成相同的 SQL，就可以免除不斷大幅修改。 {% set users = ["A", "B", "C"] %} {% for user in users %} SELECT w, x, y, z, '{{user}}' AS user_name FROM A.invoices {{ "UNION ALL" if not loop.last }} {% endfor %} 如果⽇後⽤⼾的數⽬改變，只需要改變 {% set users = ... } 這⼀⾏即可以。 輔助程式語言 動態生成 SQL 可以選擇各式各樣的程式語言來做這件事，然而，該用什麼樣子的語言來輔 助動態生成 SQL 最合理呢 ？自家公司最主要的通用型程式語言嗎？還有更好的選項嗎 ？ 如果選擇像 jinja 這樣子的樣板語言 ( template langauge ) 而非通用型程式語言 ( general purpopse language ) 的話，可以有下列的優點： 樣板語言的語法相對少，因為只適合處理樣板類的應用情境。 語法相對少、所以也相對容易學習。 專案會變得對通用型程式語言 ( GPL ) 顯得語言無關 ( language agnostic ) 負責維護此資料建模專案的人，進入門檻會比較低。 版本控管 如果要有系統地透過 SQL 來做出資料建模，需要做下列的事： 準備一個資料建模資料夾，裡頭放的檔案都是一個又一個的 ${model_name}.sql 檔。而檔案的內容，每個都是一個 SQL 查詢，它會生成對應的 SQL 視圖。 準備一個組態設置檔 ( config.yaml )，裡頭放一些參數，這些參數可能是用來指定資 料倉儲的連線方式，包含使用者名稱、密碼、主機名稱等。 準備一隻程式，它會結合「組態設置檔」與「資料建模資料夾」內的檔案，透過執行 jinja 語法，來產生確實可以直接對資料倉儲執行的 SQL 檔。 把步驟 3 產生的 SQL 檔，照著它們彼此相依 (dependency) 的順序，去對資料倉儲執 行。 所以要對專案做版本控管的話，只需要把前述的「資料建模資料夾」、「組態設置 檔」納入版本控管即可。 總結 綜合所述，結合 SQL 與 dbt 不僅能靈活地模組化與抽象化資料查詢，還能利用動態生成技術簡化資料處理。通過樣板語言 jinja，可以降低學習曲線及難度。搭配版本控制，能更有效管理與追蹤資料建模變更。 作者簡介 陳家宏 (Laurence Chen)，從事十年以上的軟體開發，現職 IT 顧問，同時也是 Clojure 社群、dbt Taipei 社群的線下活動主辦人之一。 主要協助企業導入現代資料棧 (modern data stack)、改善資料處理、軟體開發、應用資料分析。著有《從錯誤到創新：跨領域的錯誤處理、創新之道》。

大幅簡化資料轉換流程 在當今數據驅動的世界中，如何將數據轉換成有價值的資產，領先同業、創造價值是很重要的。如何將散落、品質不一的數據進行轉換，尋求更高效、更精確的方法來管理和轉換大量數據是每間公司需要考量的。在這種時空背景下，選擇一款優秀的數據轉換工具就顯得尤為重要。 dbt 正是這樣一個引領數據轉換革命的工具。 下面將說明 dbt 的功能、不同版本間的選擇以及為什麼要採用 dbt 來提升數據轉換的理由。 什麼是 dbt dbt 全名為 Data Build Tool，是一款以 SQL 為基礎的資料轉換工具，適用於 ELT（Extract、Load、Transform）流程中的 Transform 部分。 它允許資料分析師和資料工程師使用 SQL 來編寫、測試和部署資料轉換任務，進而建立資料表或視圖，提高資料處理的效率。 dbt 具有下列功能及特點 轉換資料： dbt 允許使用者通過 SQL 來實現資料轉換，將原始資料轉換為業務分析所需的資料模型。 模組化和可重用性： dbt 採用模組化的方式結合 SQL 和軟體工程的最佳實踐，讓資料轉換過程變得更可靠、快速。 測試和版本控制： dbt 支持資料品質測試、版本控制，通過 YAML 文件來聲明屬性，確保轉換過程的準確性和可追溯性。 廣泛支援資料庫： dbt 支援多種資料庫，包括 Azure Synapse、BigQuery、Databricks、Dremio、Postgres、Redshift、Snowflake 等。 dbt 版本 dbt Core： 免費開源版本，提供基礎的資料建模和轉換功能。 dbt Cloud： 付費的雲端版本，提供託管服務、CI/CD 部署及圖形化使用介面，適合非技術人員使用。 針對不同公司運用場景提供了兩種版本，分別是雲端 ( dbt Cloud ) 和地端 ( dbt Core ) ，公司可視需求選擇基本的 dbt Core 或是更加友善、強大的 dbt Cloud。 採用 dbt 的理由 一般採用 stored procedure 的資料轉換，在共用、版本控制、除錯上皆不易管理。 而採用分散式技術，資料分散式運算的技術門檻對於一般公司又顯得略高了一些。 dbt 剛好介於兩者之間，它具有下列的優勢。 降低轉換門檻 ：傳統 ETL 需要較高的技術門檻，而 dbt 透過 SQL 技術讓資料轉換變得簡單，降低了對資料工程能力的要求。 軟體工程實踐： dbt 將軟體工程實踐引入到資料轉換過程中，例如 版本控制、自動化測試和文件，提供開發一致性和開發效率。dbt 提供了一套指南，幫助開發者輕鬆使用這些最佳實踐 擴展與整合： dbt 可以與現有的資料工具和雲端服務（如：Apache Airflow、AWS、GCP ... 等）進行整合，靈活地建構、管理資料管道。 資料品質管理： dbt 支援自動化資料品質測試。透過編寫測試來確保資料的準確性和一致性，並進一步強化資料品質檢查。 模組化和自動化： dbt 支援 SQL 模組化，這不僅提升了開發效率，也減少了重複工作的問題。通過 dbt run 命令，可以自動執行整個資料轉換流程，避免了手動操作的繁瑣和錯誤。 資料血緣圖： dbt 透過 DAG 很容易的產生資料血緣圖。可以用它找出資料管道損壞的原因。利用它提升資料的透明度，讓業務人員更加了解資料源由。 豐富的社群和資源： dbt 擁有廣大的社群支援，提供了豐富的教學和範例，讓新手更容易入門。 總結 dbt 是現代數據堆棧中不可或缺的工具，通過簡單的 SQL 組成，讓資料分析師、工程師能夠有效的進行資料轉換和建模，適合希望提升資料轉換效率和品質的團隊。 dbt 軟體工程實踐，大幅提升資料處理的可靠性和效率，使得數據團隊能夠專注於生產價值更高的數據分析工作。

為什麼需要資料基礎建設 想像⼀間企業，當總經理在聽取財務單位與業務單位的報告，居然發現有兩個不同的營收數字，一時間不知道該相信誰。其實這是很⾃然的，因為業務與財務認定的「 營收 」是不⼀樣的，同樣都叫做「 營收 」但定義卻不相同。 好不容易釐清了財務與業務的不同觀點後，當總經理請財務與業務解釋指標是怎麼產生的，由於兩個部門是各自獨立做出需要的資料指標，所以從最初的資料採取、資料轉換、套⽤的公式，全部都不同。所以總經理又搞不清哪⼀個單位的原始資料採集⽅法才是合理的呢？ 若是公司有投入在資料基礎建設，上面這些定義不清、資料產出合理性的狀況就可以適時的改變。 圖: 「 資料基礎建設 」讓資料有所依據 資料基礎建設發展的三階段 就作者的觀察，在多數的企業裡，資料基礎建設的發展⼤概可以分成三個階段： ⼤表 ( one big table ) 整合 BI 軟體 資料建模層 ( data modeling layer ) 一、大表 ( one big table ) 所謂的⼤表 ( one big table )，就是一堆資料用反正規化的格式 ( denormalization form ) 形成一個龐大的資料表提供給使用者。 初期公司都會使用 "大表" 來得到想要分析的資料，因為它上手的門檻低，只要把需要的資料集合在一個表上，就可以讓使⽤者透過試算表分析資料。 然⽽，這個⽅式有⼀個明顯的缺點：「 每次增加新指標 ( metrics ) 都要等 」。要等的原因是每次都要新增對應的 ETL ( extract-transform-load )，⽽ ETL 只有⼯程⼈員有辦法寫，這時分析⼈員就得要等待。增加等待時間的原因有： ⼯程⼈員主是維護公司軟體系統，有空時才能寫 ETL 程式。 資料分析的需求的速度比開發 ETL 程式的速度快上許多。 舊的指標會過期，於是⼜要開發新的指標。 二、整合型 BI 軟體 Tableau 和 Power BI 是最流⾏的整合型BI軟體，它們能夠直接連接到資料倉儲  (Data Warehouse) 或匯入 csv 檔案，讓資料分析人員利用圖形界面快速提取指標，從而大幅縮短開發ETL程序的時間。 這些軟體還提供了強大的『領域專⽤語⾔』 (Domain specific language)，如 DAX 和 MDX，來支持深入分析。 然而，這個方式的缺點是同一家公司內不同的部門、團隊可能會『 指標定義不⼀致 』，導致報表之間存在矛盾，難以整合，這反映了在使用這些強大工具時需要有統一的指標定義標準。 例如：⼀間公司有業務團隊、⽣產團隊、⾏銷團隊，這三個團隊都要利⽤資料來輔助決策，三個團隊各⾃透過 BI 軟體做出指標。由於三組⼈是獨立運⽤ BI 軟體做出的指標，⼀間公司可能有好幾個名稱相近、定義略有差距的指標，於是三個團隊產出的報表，總是充滿互相⽭盾，難以調合。 三、資料建模層 (data modeling layer) 當我們覺得某個銷售業績預測數字看起來不太合理時，我們常會問：「 這個數字怎麼來的？」。而分析人員常會回答：「 這個要從資料源頭、運算過程逐一說明，你才會明白。明天我有空再解釋給你聽 」。而資料建模層就是解決這種要從資料源頭往上追朔，才能讓人明白數字怎麼來的窘況。 資料建模 (data modeling) 就是將中間層資料 ( intermediate data ) 與⾼階指標合起來。 由於資料建模都統⼀地存放在資料倉儲裡頭，資料分析⼈員要⽣成新的指標時，也會儘量地去複⽤既有資料建模，既可以提⾼⼀致性、⼜可以減少重複的⼯作，⽽且全公司的資料分析⼈員也可以共⽤⼀組通⽤的資料建模。 資料建模的特性： 不只提供最終資料和高階決策指標，還會記錄產生高階指標過程中的所有中間層資料 (intermediate data) 到資料倉儲裡 ，讓使用者能夠清楚了解數字如何產生的，以完善資料治理。 資料建模層算是最現代化的作法，該作法也可以視為是把軟體⼯程累積的經驗與紀律，應⽤在資料分析領域。而 現代資料棧 ( MDS ) 就非常適合⽤來做出清楚的資料建模層。 作者簡介 陳家宏 (Laurence Chen)，從事十年以上的軟體開發，現職 IT 顧問，同時也是 Clojure 社群、dbt Taipei 社群的線下活動主辦人之一。 主要協助企業導入現代資料棧 (modern data stack)、改善資料處理、軟體開發、應用資料分析。著有《從錯誤到創新：跨領域的錯誤處理、創新之道》。

除了自動化作業流程以及數位化顧客服務，建立數據民主化 (data democracy)及數據驅動決策 (data-driven decision making) 的文化，也是企業進行數位轉型時的一大目標。但與前兩者相比，如何形塑從上到下皆擁有數據思維的企業文化，是異常困難：不少企業儘管已經成立了資料團隊、建構了資料中台、打造了 ETL 資料流水線，業務團隊對於資料的需求也源源不絕，但資料對於決策的影響力卻始終未見顯著成效。 為了減少企業組織在資料民主化道路上的阻礙， 哈佛商業評論 於去年 11 月發表了一篇文章，列出了數據導向文化的組織的五個重要因素，可以歸納成三大方向： 1. 工具：要讓 所有員工 都能更方便地取得資料，並能自行進行資料分析。 2. 教育：要教育員工，讓他們具備資料素養，讓員工正確解讀資料所傳遞的資訊。 3. 氛圍：要透過不同的活動以及管道形塑重視「資料思維」的氛圍。 Generated by Glibatree Art Designer 本文將會針對「工具」進行介紹，拆解其需要具備哪些功能，才能打破現今資料的影響力瓶頸，讓 所有員工 都更方便地取得資料並進行探索。 還沒完全自動化的資料團隊作業流程 「業務團隊的資料需求，時常需要透過資料分析師、資料工程師或是資料科學家親自寫程式碼才能取得對應的資料。」不論企業是否已經搭設資料中台或是資料倉儲等基礎建設，上述的作業流程對業務團隊或是對資料團隊來說肯定都不陌生。 這些資料需求很多時候只是將同一組資料集，針對不同的觀眾進行不同的分群或是視覺化，符合當下所需要的敘述邏輯，如： 主管對老闆一次性地簡報使用， 業務針對客戶說明的分析報告等等。 同仁的 OKR 報告等等。 也有些時候，這些需求不太屬於分析的範疇，需求之間的性質甚至相當接近，如： 顧客清單。 最近 30 天消費超過 1000 元的顧客清單。 最近 30 天點擊過 A 產品頁面的顧客清單等等。 雖然從形式上來說，提出需求的人最終還是能取得資料，但這樣的流程使得資料團隊成為了資料取得的瓶頸，業務部門也需要耗費等待的時間，才能取得資料。碎片化資料需求儼然已成為企業要推動數據決策文化時不可忽視的障礙。 那麽，又該如何解決大量的碎片化資料需求呢？ 打造自助式分析工具 「 使用者應該要能透過已經建立好的資料模型以及指標層自行滿足 96 % 的需求」這一句話摘述自 Microsft 商業智慧資深專案經理 Alex Dupler ，也可以從中看出該如何打造自助式分析工具的端倪： 建立良好的資料模型: 資料模型是簡化並模擬企業本身的商業流程，而非一次次資料需求的雜燴，如此才能提供足夠的彈性讓使用者自行完成多數分析。 指標層：業務單位進行分析時，事實上是指標思維，而不是表格思維。因此在打造自助式分析工具時，應該將指標當作最小元件讓商業使用者排列組合，而不是讓使用者從表格裡加減乘除找出想要的數字。 除了打造出一致、有彈性的指標計算邏輯，為了「讓所有員工都能更方便地取得資料，並進行自助分析」還需要適合商業使用者的視覺化介面。因此組織文化不同，適合採用的工具就會不盡相同，例如： 在科技新創，大部分的使用者都懂一些簡單的 SQL ，加上 SQL 並不難學， 圖形化的 SQL 操作工具就是很好的選擇。 台灣多數的企業，都是 Microsoft 的愛用者，PowerBI 以及 Excel 就很有可能是現行很好的工具。 資料基礎建設與資料團隊的未來 為了打造自助式分析工具，資料基礎建設除了傳統的資料管線、資料倉儲、資料治理或是資料整合等議題外，也需要加入新的元素，例如： 語義層 (Semantic Layer) / 指標層 (Metrics Layer)：提供一致的指標運算邏輯，是視覺化工具跟資料倉儲中的資料模型溝通的橋樑，通常會以 API 的形式供應給不同的下游應用。 資料目錄 (Data Catalogue)：集中、即時且完整的文件，讓商業使用者能了解指標定義、資料目前的品質以及更新狀況等等，增加使用者對資料的信任並避免資料誤用。 而除了導入上述工具以外，資料團隊更需要意識到新的思維以及工作流程，比方說： 當資料團隊接收到碎片化需求時，是慣性地馬上去撈取相應的資料，只著重在解決當下需求，還是能意識到，自己的任務其實是在建立資料產品 / 資料平台，進而來回溝通以理解業務單位的商業模式以及脈絡。 實務中，資料建模以及資料管線經常是由資料工程師進行，但從經驗來看，資料工程師通常缺少如何量化商業表現的場域知識 (Domain Knowledge)，做出來的資料建模若直接開放給業務部門，也會過於複雜而難以使用，導致最後又回過頭來請資料分析師協助。此時便需要變更團隊配置，建立資料管線的人應該具備理解商業知識的能力，才能打造出符合業務需求的資料模型，國外新興的職位 Analytics Enginner 便是如此因應而生。 當 96% 的資料需求都能由業務部門自助完成時，資料工程師才能有更多時間去完善基礎建設、開發更多型態的資料工具，讓資料平台的體驗更加友善；資料分析師以及資料科學家才有餘裕找出真正的商業洞見、建出能落地的機器學習模型，讓每個商業決策都有數據支援。 利用現代數據棧 (MDS) ，替資料基礎建設「都更」。 數位轉型的概念從 2016 年開始就已經廣為人知，現在不少企業都已經有了自己的資料團隊以及資料基礎建設。但也因爲新團隊的加入，許多工作流程都還處在摸索的階段。現代數據棧是一個工具集錦，是國外資料團隊經驗與智慧的結晶，它改善了以往資料工作團隊的作業流程，讓資料變成資訊的過程更為順暢、彈性並且透明。 如果資料團隊發現： 自己彷彿是 SQL ATM，工作時程被無止盡的破碎資料需求排滿。 雖然有資料中台或是資料基礎建設了，但新資料源的整合異常艱辛、緩慢。 業務單位經常反映數據不一致，對資料信任度極低。 現代數據棧提供的知識、框架以及工具，便是為了解決這些問題而生。適當地運用這些工具，重新打造資料棧或是改善已經建構好的資料中台，都能讓企業在推動數據驅動決策的道路上走得更加順利。

Document AI 與 OCR 一同開創數位轉型新天空 追求數位化的時代裡，企業期許能將手邊的資料轉化為未來成長的動力。 但第一步卻往往很難踏出，企業有眾多歷史文件資料以及紙本作業的沉重包袱。一時之間不能馬上用資訊系統取代，比較合宜的方式是將紙本文件轉化為數位資料再轉置資訊系統之中。 而將紙本文件轉化成數位資料，常見的選擇有這些。 1. 採用 人工 將紙本內容手動輸入電腦，這種方式費時、費力，而且有高昂人力成本問題。 2. 運用 OCR (光學字元辨識) 將紙本內容快速轉化成電腦可讀的數位資料，此種方式成為高效輸入的首選。 然而，OCR 也有限制，常會受到文件髒污、浮水印…干擾，進而影響到文字辨識率。最終需以人工辨識逐一過濾紙本文件方式，將不合宜的文件挑選出來另行處理，整個過程耗時耗力。 Document AI 是什麼 ? Document AI 可以有效縮短紙本文件和 OCR 之間的隔閡。透過 AI 影像技術分析，協助改善下列情況 印刷圖片變形矯正 變形 壓痕 旋轉 歪斜 辨認字體 印刷體 印章 浮水印去除 Document AI 先預處理紙本文件影像，以提高 OCR 辨識率，也可以抓取印章影像這種不易辨認的資訊。 Document AI 範例 Document AI 常見的運用如下。 偵測文件影像斜度並校正斜度，提供校正後文件給 OCR 辨識。 透過印章訓練，有效將印章標示出來 (黃色方框)，並提供印章內容值。 去除浮水印，將後景干擾因素去除，增加 OCR 辨識率。 Document AI 亦可作下列改善運用 複印本（字較模糊、黑白） 紙張有折痕 ... Document AI + OCR 場景運用 醫療 引入 Document AI + OCR 可以輕鬆地將龐大醫療記錄轉換為數位格式。消除人為錯誤，加快醫療記錄歸檔的過程，提高資訊的訪問性。無論是各種醫療表格、處方記錄…等醫療文件，都可以根據需要隨時獲取。 對於講求精確的醫療行業來說，醫療記錄數位化可以大幅減少因醫療記錄遺失、人為因素...造成的錯誤。 零售業 Document AI + OCR 可以極大地提升了零售業的運作效率，尤其在出貨處理和資訊接收方面。主要應用包括從包裝單中提取數據、掃描訂單、發票數位化和庫存追蹤…等。 無需使用者介入的情況下，可以將庫存單位（SKU）、價格和產品名稱轉換為數位資料，節省大量人力成本。 房地產 房地產公司常需處理大量文書工作。例如: 買賣、費用、維護、契約 ... 等文件都需要被簽署、歸檔。過往常用人工方式進行，不僅費時費力，也容易出錯。文件內容搜索只能靠著記憶翻查眾多文件。 若透過 Document AI + OCR 數位輸入的方式，搭配文件管理系統，可以讓這些文件輕鬆被歸檔、搜索。 銀行業 Document AI + OCR 能夠準確地從業務 (一般貸款申請、抵押貸款申請、工資單...) 中提取銀行資料，完成後續應用。 亦可讓電腦讀取支票，並準確識別帳號、簽名和金額的差異，完成行動支票存款功能。 保險 Document AI + OCR 能夠加速保險業務的日常工作。例如: 每次有新的保險文件時，只需掃描即可將其納入系統。當客戶有保單相關問題，想要更改保單內容或提出索賠時，保險公司可以隨時查詢相關資訊，提出回覆。 除此之外，Document AI + OCR 還可以處理像是保單建議書、新客戶建檔、保險合約更新和索賠處理，這種需要大量勞動成本的文書工作。 人才招聘 人力招聘在公司業務中佔用著重要地位且耗時較長。招聘人員平均需要花費數天的時間來聘請一名新員工。 如何加速篩選應聘者，可透過 Document AI + OCR 批量處理求職申請進行。通過程式處理，自動提取相關數據並進行分類。招聘人員隨後可以使用這些提取的數據，將職位要求與應聘者進行匹配。 讓招聘過程更加迅速，大幅節省招聘人員寶貴的時間，求職者無需漫長等待通知。 總結 如何在數位轉型中站穩腳步，文件數位化一直都是不可或缺的。透過 Document AI + OCR 處理，讓企業能更快速、準確地轉換大量紙本文件至數位格式，從而提高生產力、降低錯誤率，並加強資訊存取性以及後續 BI、AI 的運用。 Document AI + OCR 應用可為企業帶來更順暢、高效的運作，持續推動數位轉型並取得可觀成果。

圖資料庫與您的業務：關鍵考量因素 面對海量資料，企業選擇適合的資料庫系統對效能提升和資料分析是一件重要的事。 圖資料庫擅長處理高度關聯的資料，尤其在關係查詢速度、因果關係分析都有很好的表現。 但真的適合你的業務需求嗎 ？ 本文將探討圖資料庫在線上交易處理 (OLTP) 和 線上分析處理 (OLAP) 上的狀況，讓企業透過決策表檢視自己是否適合。先讓我們從圖資料庫的優缺點開始檢視。 圖資料庫優缺點 以下清楚列示圖資料庫的優劣勢，好讓企業評估您的需求，是否可以透過圖資料庫來解決。 優勢 1. 數據模型靈活：沒有 RDB 般需要嚴格的資料表結構定義，方便未來的各種擴展。 2. 高效圖分析：適合海量資料進行路徑查詢、網絡分析 ... 這類關係式分析。 3. 關聯查詢低延遲：直接將資料間的關係儲存，避免像 join 這種昂貴的查詢。 4. 數據可視化：能直觀地展現資料間的關聯，有助於理解和解釋。 劣勢 1. 資源較少：相較於主流資料庫 RDB，圖資料庫的資源相對較少。 2. 適用於某些情境：在非高度資料關聯的場景，得到的效益不明顯。 3. 不適合大規模頻繁更新：更新資料也一併要更新關係，造成額外的成本。 4. 需要額外的成本：在現有系統資料庫中增加圖資庫，都需轉換成本。 簡而言之在資料高度關聯且資料量龐大下，若要用資料的關聯進行分析、查詢 ...，圖資料庫也許是個好的選擇，相對的也需額外資源支援。 圖資料庫決策表 考量圖資料庫是否導入的過程中，應時常審視決策表的檢核問題，才能發揮圖資料庫的最大效益，避免走向誤區。 圖資料庫決策表依應用分成下述兩種情境 線上交易處理 (OLTP) 決策表 在資料異動低、資料關聯複雜的系統中，使用圖資料庫作為 OLTP，可提升關聯查詢、分析的效率，也避免頻繁更新造成圖資料庫負擔。 線上分析處理 (OLAP) 決策表 圖資料庫 OLAP 適合在海量資料下用圖分析解決業務問題，這些是傳統 RDB 無法解決的問題。 總結 圖資料庫以高效處理高度相關資料著稱，但並不是每個場景都適用。文中探討圖資料庫在OLTP（線上事務處理）和OLAP（線上分析處理）環境的適用性並提出了一份決策表。這份決策表可以幫助讀者判斷圖資料庫是否適合業務需求，並根據企業的具體情況做出明智的選擇。

現今台灣企業中，大多數公司都已經具備 BI 的能力，無論是透過 Excel、Tableau 或是Power BI，都能利用現有數據分析，了解「過去」營業額、產品銷售數量等趨勢。 面對下半年甚至是明年的業績預測，大多數的企業依然採用移動平均線，或是直接乘上目標成長率，把數字往上堆疊，然而，這樣的方式，是精準有意義的數據嗎？ 以下的圖表讓您了解，為何您會需要 AI。 從圖表清楚了解，BI 是透過數據分析，了解「過往」公司發生什麼事情、為什麼會發生，但是面對不確定性極高的未來，唯有 AI 才能給予您精準預測，讓您做出正確的決策。 ML (Machine Learning) 是什麼？ AI 的重要技術之一，機器學習，又稱 ML (Machine Learning)，主要是透過機器，從過往資料中學習並找到其運行規則，建立模型，予以預測。 傳統的機器學習開發過程需要豐富的技術和經驗，包括特徵選擇、模型選擇和調整參數等繁瑣步驟。光建立一個演算法模型，往往耗時 2~3 個月，甚至半年，都是常見的。 AutoML (Automated Machine Learning) 又是什麼？ AutoML 是自動機器學習，透過減少人工干預，讓機器自主學習，快速完成數據模型的建立。 以建立一個演算法為例，AutoML 僅需 2~4 周，即可協助企業從上百個演算法中，自動挑選最合適的演算法進行建模，當然，包含特徵選擇、參數調整也是自動化完成。 面對 AI，企業最擔心「怎麼用？」 根據 Gartner 調查報告顯示，在推動 AI/ML 的計畫中，以下是企業所遇到的三大困境 人才短缺 (56%) 應用場景 (42%) 數據品質 (34%) 與台灣客戶的訪談中，確實也感受到客戶的擔心如上述三項，因此，對於企業面臨的困境，QUBIX 團隊建議引進採用 AutoML 的三大原因如下： 1. 技術低門檻、好操作 數據建模需要豐富專業與經驗人才，這樣的人才相對稀少，聘請也相對昂貴。 利用 AutoML 建立數據模型的好處之一是，透過低門檻、高自動化的方式，例如 No-Code 的方式，快速產生可信賴的數據預測模型，即使不是資料科學專家，也能輕易上手。 另外，大型企業中，常常因為人員流動率高，導致後續維護不佳，若採用產品化 AutoML 工具好處之一是有標準化的建立流程，即使人員更替，往後也能順利銜接。 2. 省時省力 相較傳統建模需要 2~3 個月的時間，透過 AutoML 建模，僅 2~4 周即可完成，省下 6 成以上的時間，讓企業有更充足的時間，專注未來策略規劃和執行。 3. AutoML 專業顧問團隊的協助 面對各行各業的應用場景、該從那個命題開始導入？如何做短、中、長期的導入規劃，又與如何利用 AI 數據，漸進式推動企業組織再造？ 請交由 QUBIX 團隊為您解決。 QUBIX 團隊夥伴擁有上百場專案導入經驗，從一開始的數據品質評估、需求訪談到應用場景的討論，將以顧問方式，協助企業放心導入。 最後，若您對 AutoML 有進一步的需求或疑問，非常歡迎點擊右上角「與我聯繫」，讓我們一同與您從 BI 世代成功跨入 AI 新時代！

實際走訪客戶，初期最常被問的問題之一是「 Neo4j 企業版和社群版的差異是什麼呢 ？」 言下之意問的是，企業付費購買 Neo4j 企業版的價值在哪裡，這些功能對企業是否具備不可取代性。 首先，為了簡化說明，我們以 Neo4j 地端 (On-Premises) 為例，地端共分「社群版」和「企業版」兩個版本。 若以技術面向評估，以下五點是 QUBIX 團隊認為採用企業版的重要考量因素： 1. 具備水平及橫向擴充功能 企業版 Neo4j 支援多叢集，若交易情境可能出現瞬間高頻交易或爆量，透過水平橫向擴充功能，可為企業瞬間提供處理大流量之運算效能。 2. 細緻的權限控管 大型企業必須考量，「跨部門單位」與「垂直管理」間的權限控管，在 Neo4j 的企業版中，區分「Graph」、「Database」和「DBMS」三個階層權限控管設定，以滿足企業個情境最細緻的權限控管。 3. 圖型演算法 (GDS) 建模數量不設限 在社群版中，僅提供 3 個演算法模組，在實務上，3 個模組完全無法滿足企業需求，且一旦關機，系統還會將資料刪除，導致每次開機需要重新計算模型，使用上也相當不方便。 因此，採購 Neo4j 企業版另一個好處就是可以享有無限建立模組，即使關機，資料系統會予以保存，讓您隨開即用。 4. Cypher 語法回應速度快速 相較於社群版，企業版在 Cypher 查詢的速度快上 50～100%，在海量資料查詢速度上，立即展現快速優勢。 5. 享有原廠完整資源與在地專業即時服務 從一開始的軟體安裝、及時問題處理到顧問服務，QUBIX 將以專業為您服務，讓您免走冤枉路，精準快速使用 Neo4j ，創造企業技術優勢。 綜上所述，總結如下 1. Neo4j 社群版 Community Edition 社群版是免費且具有基本功能，但無論是節點數量、圖型演算法建模數量等功能都有所限制，若使用目的為學習、試用和小規模的專案驗證，社群版是一個很好的選擇。 2.  Neo4j企業版 Enterprise Edition 若企業具有巨量資料、應用環境重視穩定性，並確保高效能的運行，建議您使用 Neo4j 企業版，以獲取全面的功能和支援。 最後，無論您的企業正在搜尋 Neo4j 產品資訊，或是進入產品評估導入期，有任何疑問，都歡迎與我們聯繫！

影像 AI 如何改變安全防範 影像人工智慧( AI )近年來在各行各業的應用日益增加，車牌辨識的快速停車場閘道已經普及應用，刷臉打卡已經有落地案例。 案例 加州消防局 隨著技術進步，AI能使用的情境也日益豐富，近期、加州林業與消防局宣布一項以人工智慧 檢測野火的計畫「Alert California AI」，希望能藉此改善長年因為野火延燒造成傷亡與裁損問題。透過 1032 組可 360 度環景拍攝影像的攝影鏡頭捕捉影像，並且透過人工智慧方式辨識影像中異常情況，藉此預先告知相關單位確認是否有潛在形成火災風險，進而提早採取因應措施。[註 1] 宜蘭縣環保局 無獨有偶，宜蘭縣環保局在利澤焚化廠高達 120 公尺的煙囪頂部，安裝了全台最高監錄系統。這個系統可以覆蓋半徑 8 公里的範圍，包括龍德和利澤兩大工業區。以 AI 準確辨識空氣污染，不但能即時記錄異常狀態（空氣污染可能很快散去），也利於環保人員快速進行稽查。[註 2] 德國洪堡游泳池 在德國西部城市洪堡的游泳池最近為救生員添加了 AI 人工智慧好幫手，可以在偵測到緊急情況下通知救生員，第一時間將溺水者救起。[註 3] 優勢 從上述例子可以得知，影像 AI 的優勢大致上有幾個 即時性：偵測到異常情況時（如不明物體、可疑活動等），AI 系統在可快速發出警報，防止事故發生。 擴張性：只要軟硬體足夠，影像 AI 便可全面、無死角的監控，避免疏漏。 精準性：影像 AI 是透過大量影像資料的訓練所產出的智能模型，精確度高。 客觀性：AI 運行遵循演算法，其判斷不受主觀情緒影響。 自動化：影像 AI 可以代替人類進行重複性的工作，並能 24 小時運作。 工安的一位前輩曾經感嘆：『即使統計的發生率很低，但事故一旦發生，對當事人的傷害就是百分之百』，言下之意就是，安全防範理當以零災害為職志。 而AI在安防領域具有的特性，除了預防災害的發生，例如石化廠的管線鏽蝕檢測、鋼鐵及營造業的危險區域劃定，PPE 穿戴檢視.... etc ，也可以在事故剛產生時，就以 AI 偵測並告警，將危害扼殺於搖籃之中，此類應用則見於火焰與煙霧偵測、人員跌倒、軌道異物掉落.... etc 。 2023 年開始，職安人力不足持續了一段時間，如果能趁著 AI 崛起善用新的工具，對於職安領域，也許會是一次數位轉型的契機。長短期都能增進公司的競爭優勢。 註 1. 註 2. 註 3.