若進一步搭配 Elastic Search AI 平台，企業便能高效整合內部資料，實現「向量檢索、語義搜索」與「即時分析」等關鍵功能，顯著提升 AI 搜尋的準確性與效能，進而強化企業競爭力。

隨著 AI 和機器學習（ML）技術的快速發展，向量資料技術已成為處理文字、圖像、音訊等非結構化數據的重要方法。

其中，作為全球使用量最高的向量資料庫 Elasticsearch，憑藉高效的儲存與檢索能力，已成為企業推動 AI 專案的首選解決方案。

Elasticsearch 論壇｜全球使用量最大的向量資料庫

為幫助企業深入了解 Elasticsearch 向量資料庫技術，Elastic 於 2025 年 2 月 21 日攜手 歐立威 舉辦了 Elasticsearch 台灣技術論壇。

本次活動邀請到多位專家，深入解析向量資料庫的核心技術與應用場景，並透過成功案例分享，協助企業掌握 AI 解決方案的落地關鍵。

Elastic 大中華區副總裁 Lloyds Cheung 表示，生成式 AI 正以前所未有的速度重塑各行各業。

例如：ChatGPT，僅用了不到兩個月便突破 1 億用戶，顯示 AI 的強大影響力。

目前，企業在推動 AI 專案時面臨整合大量分散數據的挑戰，搭配 Elastic Search AI 平台，可顯著提升資料檢索的準確性，降低 IT 成本並增強系統效能。

此外，Elastic Search AI 更獲 Forrester 評選為投資報酬率最高的 AI 解決方案。（數據來源：Why public sector needs AI-powered observability: Cost savings, ROI, and analyst efficiency）

長期致力於開源技術推廣的歐立威科技，作為 Elastic Search AI 平台的台灣代理商，持續透過「免費研討會、體驗營、技術小聚」等活動，推動技術交流並分享最新產品資訊。

未來，歐立威科技將持續協助企業落地生成式 AI 專案，共同推動 AI 解決方案的創新與實踐。

Elastic Search AI 平台融合獨家功能 – 打造 AI 專案最佳解決方案

企業推動 AI 專案的成功關鍵之一，在於擁有「高品質」且「大量」的數據。

Elastic Search AI 平台因此受到 Adobe、Walmart、Cisco 和喬治亞州立大學等全球知名企業的青睞，因其具備多項業界領先的核心功能，成為 AI 應用的理想工具。

在資料索引與處理方面，Elastic Search AI 平台能高效儲存來自雲端、內部系統、應用程式等多來源的數據，並建立高效能索引機制，大幅提升資料檢索速度。

此外，透過 AI 向量搜尋技術，該平台支援語意搜索，更精確地理解使用者查詢，提升搜尋結果的相關性。

另一方面，Kibana 儀表板提供直覺化的資料分析工具，幫助企業實現數據可視化，加速決策效率。

在安全性與治理方面，Elastic Search AI 平台內建完善的存取權限管理機制，確保數據安全並降低資料洩漏風險。

Elastic 資深架構師 Jason Chan 指出，生成式 AI 結合 RAG 已成為當前的主流技術架構。

隨著企業每日產生大量數據，Elastic Search AI 平台可提升資料檢索精準度，滿足多元應用場景需求。

此外，平台更提供混合搜尋（Hybrid Search）功能，結合 BM25（傳統關鍵字搜尋） 與向量搜尋（Semantic Search），能夠從 PDF、文件、影片字幕 等非結構化資料中進行關鍵字檢索，進一步提升搜尋結果的準確性。

除了強大的數據分析與搜尋能力，Elasticsearch 亦可應用於多種場景，例如：監控系統異常行為、偵測潛在網路攻擊，甚至用於設備故障監測與異常預測。

當偵測到異常時，系統可自動發送警報，協助企業即時應對，將潛在風險降至最低。

成功案例遍及各產業，加速實現數位轉型願景

如前所述，Elastic 在全球市場已累積眾多成功案例，台灣亦不例外。

隨著數位轉型浪潮席捲各產業，某知名 IC 設計公司 率先洞察生成式 AI 的強大潛力，決定為員工打造專屬 AI 平台，以優化業務流程並消除重複性任務。

該公司採用生成式 AI 結合 RAG 與 Elasticsearch，強化內部搜索能力，顯著減少低效的搜尋時間，最終成功提升知識管理與資訊檢索效益。

此外，該企業更打造 AI Copilot 助理，協助員工處理日常業務，進一步提升整體工作效率。

未來巢科技產品經理 Derreck Lee 表示，金融產業在客戶徵信流程中面臨的最大挑戰之一，就是客戶資料過於分散，導致徵信單位難以整合財務報表、新聞、產業數據，加上人工分析速度較慢，往往難以及時發現潛在風險。

即便企業成功導入生成式 AI，仍可能因生成資訊缺乏可解釋性，影響決策的信任度與準確性。

為解決這些痛點，我們協助客戶運用 Elastic Search AI 平台，確保 AI 能夠找出資料間的因果關係，而不僅是表面的關鍵字匹配。

目前，該金融機構已成功將 AI 應用於「財報分析」與「市場趨勢預測」，不僅提升了徵信作業的準確性，也能為消費者提供更完善的智能理財服務。

在媒體產業，某知名台灣新聞公司亦在 AI 轉型過程中選擇導入 Elastic Stack、Elastic Cloud，並結合 RAG 技術，使生成式 AI 發揮最大效益。

該公司團隊透過 Elastic Stack 中的 Kibana，能夠分析、搜尋、操作並視覺化 Elasticsearch 資料庫，確保數據檢索的精準度與效率。

同時，導入 Elastic Cloud 服務，讓企業免除自行維護資訊系統的成本與人力負擔，確保系統始終保持最新版本，持續享有最新 AI 技術的強大優勢。

生成式 AI 搭配 RAG 已成為推動 AI 專案的主流架構，而進一步結合 Elastic Search AI 平台，企業便能實現高效向量檢索、語意搜索與即時分析，全面提升數據處理能力，進而強化市場競爭力。

在 AI 驅動的未來，掌握高效數據檢索與智能分析技術，將成為企業脫穎而出的關鍵，Elastic 將持續助力企業，推動 AI 應用創新，加速邁向智慧化未來。

對於希望加強防禦、獲取即時洞察的組織來說，基於搜尋 AI 平台的 Elastic Security 提供了整個攻擊面可見性，幫助您達成商業目標。

Elastic 如何利用 Elastic Security

在解釋價值驅動因素之前，讓我們聽聽 Elastic 的首席資訊安全官 Mandy Andress 的看法。

Mandy 將她在一家《財富》100 強企業和 Elastic 整合技術堆疊的經驗進行比較，發現 Elastic 的市場上線速度快了 87.5%。

想了解完整影片，請參考：How does Elastic Security drive value to your organization?

以下將 Mandy Andress 的影片，轉為文字檔：

安全團隊帶來的價值

現代安全解決方案通常在以下四個主要領域帶來價值：

成本節省

這包括透過降低直接影響利潤的成本，進而節省的資金。

風險降低

透過 Elastic 減少安全事件發生的可能性和嚴重性，並量化其價值。

Elastic 致力於在風險發生前識別潛在威脅，幫助企業避免損失並實現額外的財務利益。

生產力提升

Elastic 通過加速分析、促進協作以及自動化關鍵步驟來提高生產力，從而提升效率、加速決策並使企業能夠將資源重新分配到新項目中。

收入恢復

「服務中斷」和「客戶體驗問題」可能會影響收入和客戶保留，這一領域反映了降低這些風險的底線價值。

Elastic Security 帶來的價值

安全團隊效率提升

Elastic Security 從商業分析的角度推動安全分析師、工程師和管理人員的生產力增長。

我們首先考慮提高每個安全運營中心（SOC）最有價值資源——技術熟練的從業人員的生產力的經濟價值。

如果時間就是金錢，您的團隊可以通過「自動化威脅檢測」和「簡化調查及事件響應」來節省許多時間。

通過集中數據，安全團隊可以更快地分析信息，並通過嵌入式案件管理和自動化行動加快響應速度。

這使得團隊能夠快速確定根本原因並減少升級。

通過改善平均調查、檢測和響應時間（MTTX），並減少誤報警報和升級，團隊可以降低每次事件的整體成本。

安全技術整合與優化

Elastic Security 將幾種關鍵技術（SIEM、端點和雲安全）統一在一個平台上。

在此計算中，我們估算降低許可證和基礎設施成本、減少技術開銷以及簡化新用例實施的價值。

業務中斷風險降低

任何由安全事件（無論是內部還是外部）造成的業務中斷都可能對您的組織造成損失。

Elastic Security 使您能夠改善可見性、消除盲點、增加自動化並減少事件數量。

在此計算中，我們考慮與內部和面向客戶的服務及應用相關的停機時間。

這可以為員工帶來生產力提升，並恢復先前因停機、SLA違規和客戶流失而損失的收入。

事件風險降低

憑藉強大的端點安全解決方案和能力，Elastic Security 防止並檢測勒索病毒、惡意軟件、釣魚攻擊和其他攻擊，並能在整個環境中啟用自動響應。

在這裡，我們衡量降低這些風險的影響，並根據 IBM 的數據洩露成本報告衡量潛在的財務節省。

避免事件成本

Elastic Security 現代化了安全運營，為從業人員提供了保護、檢測和應對複雜攻擊的能力。

憑藉開放和透明的平台，以及能夠阻止勒索病毒和先進威脅的代理，它幫助組織降低風險，提升安全運營成熟度，並加固 DevSecOps 流程。

在這裡，我們考慮事件後的成本節省，包括系統重建和外部事件響應公司所花費的時間。

Elastic AI 助手

這些計算未反映最近推出的 Elastic AI 助手在 Elastic Security 中所提供的價值。

AI 幫助從業人員利用快速變化的 LLM 環境來解決各種安全用例。

它提供有「關警報摘要、分流步驟、查詢轉換」和「自定義數據攝取」等多種主題的指導。

這些功能簡化了分析師的工作流程，減少了平均調查、檢測和響應時間。

Elastic Security 如何為我們的客戶創造價值？

查看 Proficio 如何轉向 Elastic Security 並使用 Elastic AI 助手將調查時間減少 34% 和項目成本節省。

想要了解更多 Elastic Security 相關資訊，歡迎加入歐立威 Line 好友，或閱讀：10 分鐘掌握 Elastic Security 四大功能

本文翻譯自：How does Elastic Security drive value to your organization?

想在 Kubernetes（K8s）環境部署 ELK 軟體，可以分成手動設定和自動設定兩種方式。

所謂手動方式，是指管理員編輯資源配置檔內容，像是指定 StatefulSets 或 Deployment 來進行設定和管理，因為這些運營應用程式的知識都在管理員的腦子裡，也可能散見於 Shell Script 或 Ansible 腳本裡，很難被管控或重覆利用。

為了簡化這個流程，讓管理運營 Kubernetes 的知識能被轉化為軟體形式，一套稱為 Operator Framework 的開源工具集應運而生，它能用來管理 K8s 應用程式，其中也包括稱為 Operator 的原生應用程式。

在 Kubernetes 導入 Operator 之後，開始有了第二種自動設定的方式，透過 Elastic 官方釋出的 ECK 工具，我們就可以更方便地進行 ELK 的自動部署和管理。

ECK 是 Elastic Cloud on Kubernetes 的縮寫，有了它，就能在 Kubernetes 環境快速完成下列的常見工作： 

1.  管理和監控多個群集
2.  安全地執行設定調整以完成滾動升級
3.  橫向延展群集的資源和空間
4.  設定群集的 TLS 憑證
5.  設定「熱-暖-冷」資料節點的架構

Operator 運作原理

雖然 Operator 和 ECK 處理掉許多複雜的工作，還是值得我們稍微理解它背後的原理。

在 Kubernetes 裡有個稱為控制器 (Controller) 的核心概念，控制器在 Master 節點裡是個不停執行的程式，並且針對特定物件進行監控。

例如，使用者指定 Deployment 新的 replica 數量為 3 之後，控制器在接收到更新通知，就會比對 Kubernetes 群集狀態，努力確保狀態和宣告的指定值能夠一致。

因為 Kubernetes 1.7 版本之後導入稱為客製化資源定義（Custom Resource Definition, CRD）的機制，讓開發者可以仿照控制器的原理，自行設定 Operator 來包裝管理應用程式，你可以想像 Operator 就是一種控制器，差別在於它是作用於應用程式的層級。

從 Operator 的視角，我們不再把應用程式看成是一堆 Pod、Deployment、Service、ConfigMap 的資源集合，而在邏輯上把應用程式看成單一物件，直覺地當成一按搞定的快速鍵。

本文要跟大家介紹的主角 ECK，就是一套由 Elastic 公司提供的 Operator 工具，它透過 CRD 定義了一系列新的物件類別，使用者能夠依照一致而直覺的操作介面來管理 ELK 元件。

舉例來說，我們也可以找到 MongoDB 的 Kubernetes Operator [1] 來用，而且它還分成 社群版 和 企業版 兩種，使用者依照需要來決定哪一種。

ECK 事前準備

在開始前，應該要先確認手邊的作業環境是否完整被 ECK 版本所支援，以 ECK 2.5.0 為例，它在 2022 年 11 月釋出，相容的 Kubernetes 版本是 1.21 到 1.25。

如果使用的是 GKE 平台，要確認擁有 cluster-admin 權限，如果是用 Amazon EKS 平台，要確認 443 埠號能夠連通。

更多詳細的版本細節，可參考：

• https://www.elastic.co/guide/en/cloud-on-k8s/current/k8s_supported_versions.html
• https://www.elastic.co/support/matrix#matrix_kubernetes

確保 Kubernetes 節點至少擁有 2GB 的記憶體剩餘空間，不然 Elasticsearch 的 Pod 容易卡在 Pending 狀態。

另外 Kibana 或 APM Server 都有各自合適的運算資源下限，請參考：https://www.elastic.co/guide/en/cloud-on-k8s/current/k8s-managing-compute-resources.html

ECK 快速上手

首先，利用下列指令來完成 CRD 安裝：

$ kubectl create -f https://download.elastic.co/downloads/eck/2.5.0/crds.yaml

順利的話，會看到螢幕回應成功建立 Elastic 資源的訊息。也可以執行下列指令來查看 crd 資訊：

$ kubectl get crd

接著，利用下列指令安裝 Operator 和 RBAC 規則：

$ kubectl apply -f https://download.elastic.co/downloads/eck/2.5.0/operator.yaml

值得注意的是，我們預設使用 elastic-system 命名空間來管理 ECK Operator，也建議針對工作環境選定 elastic-system 或 default 之外的命名空間。

$ kubectl -n elastic-system logs -f statefulset.apps/elastic-operator

以上指令可以觀察 Operator 的日誌訊息。

ECK 佈署 Elasticsearch

最簡單的起手式是建立單一節點的 Elasticsearch (ES) 群集，我們可以編輯 quickstart-es.yml 檔案，內容如下：

apiVersion: elasticsearch.k8s.elastic.co/v1
kind: Elasticsearch
metadata:
  name: quickstart
spec:
  version: 8.5.1
  nodeSets:
  - name: default
    count: 1
    config:
      node.store.allow_mmap: false

接著，執行下列指令讓上述的設定檔生效：

$ kubectl apply -f quickstart-es.yml

檢查 ECK 是否順利讓設定值生效：

$ kubectl get elasticsearch

上述指令可以簡化成 kubectl get es 形式。留意到指令輸出結果的 HEALTH 欄位，它會提示部署中的 Elasticsearch 健康狀態，如果不是 green 的話，可以再透過 kubectl describe pod quickstart-es-default-0 之類的指令來查看細節。

等到 ES 群集健康值顯示為 green，再透過下列的指令群，可以看到 ES 成功連線的訊息。

$ PASSWORD=$(kubectl get secret quickstart-es-elastic-user -o go-template='{{.data.elastic | base64decode}}')
$ kubectl port-forward service/quickstart-es-http 9200
$ curl -u "elastic:$PASSWORD" -k "https://localhost:9200"

同樣建立一個 quickstart-kb.yml 檔案，編輯內容如下：

apiVersion: kibana.k8s.elastic.co/v1
kind: Kibana
metadata:
  name: quickstart
spec:
  version: 8.5.1
  count: 1
  elasticsearchRef:
    name: quickstart

執行下列指令來完成 Kibana 佈署：

$ kubectl apply -f quickstart-kb.yml

$ kubectl port-forward service/quickstart-kb-http 5601

Kibana 登入 Elasticsearch 的帳號是 elastic 而密碼可由 Secret 資源內容取得：

一切順利的話，就可以打開瀏覽器來存取 Kibana 的登入畫面。

總結

透過 ECK 在 K8S 環境部署 ELK 有下列好處和注意事項：

1. 想要清空部署環境的相關資源，可以使用 kubectl delete elasticsearch quickstart 之類的指令，將 ES 或 Kibana 當成資源單位，相當直覺。

2. 如果遇到錯誤訊息，同樣要透過 K8S 環境的除錯工具和步驟，可參考官網的說明文件。

3. ES 或 Kibana 的成功啟動需要合理時間的等待，特別是 ES 最後階段是 Readiness Probe 的確認，如果超過十分鐘沒有正常反應，動手除錯吧。

–

想了解更多資訊，歡迎聯絡我們，或是 加入歐立威 Line 好友！

本篇文章你會學到:

1. 單節點安裝
2. Elasticsearch 基本 API 指令

那我們廢話不多說，馬上開始建立我們第一個 Elasticsearch 吧！

單節點安裝建置

前置作業

1. 準備環境，筆者環境規格如下：

2. 確認 Elasticsearch 和作業系統版本是否匹配：Support Matrix | Elastic
3. 下載 Elasticsearch:8.3.3：https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-8.3.3-x86_64.rpm
4. Elasticsearch 使用 java 開發，因此安裝包內皆會自帶 OpenJDK
5. Elasticsearch 預設目錄：

安裝步驟

1. 確認作業系統版本

$ sudo cat /etc/redhat-release
CentOS Linux release 7.9.2009 (Core)

2. 關閉防火牆

為了快速建立，筆者先關閉防火牆。若大家有需要，也可為 Elasticsearch 設定防火牆規則。

$ sudo systemctl stop firewalld
$ sudo systemctl status firewalld

3. 建立管理目錄

建立專用目錄是筆者習慣，對於未來要增加新的 Elasticsearchs 安裝包或其他 Elasticsearch 相關東西，管理上會更加方便。

$ mkdir -p ~/elk/es

切換至該目錄下

$ cd ~/elk/es

4. 下載 Elasticsearch GPG Key (選擇性)

此步驟為選擇性，即使不安裝也不會影響，頂多會在後續安裝時跳出告警訊息。

GPG Key 的目的簡單來說，是用於驗證安裝包是否和官方相符。

$ sudo rpm --import https://artifacts.elastic.co/GPG-KEY-elasticsearch

5. 下載 Elasticsearch:8.3.3 安裝包及 sha 檔

$ wget https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-8.3.3-x86_64.rpm
$ wget 
https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-8.3.3-x86_64.rpm.sha512

6. 確認檔案並驗證

檔案若無損壞，則會回傳:OK。

$ ll $ shasum -a 512 -c elasticsearch-8.3.3-x86_64.rpm.sha512

注意：若出現 bash: shasum: command not found，請執行以下指令：

$ sudo yum install -y perl-Digest-SHA

7. 安裝 Elasticsearch

$ sudo rpm --install elasticsearch-8.3.3-x86_64.rpm

從以上資訊我們可以注意到 5 個階段:

a. 內建腳本會自動幫我們建立 Elasticsearch 的使用者及群組
b. 預設開啟 HTTP/Transport 的加密模式
c. 提供 Elasticsearch 的 superuser 密碼 (此為預設值，可更改，務必記下來!!!)
d. 改預設密碼的指令
e. 建立 token 值的指令(是不是跟 k8s 有點像~)

8. 編輯 jvm.options 文件

預設是使用 4G，但因為筆者環境記憶體資源不夠多，因此將設定改為 1G。

$ sudo vi /etc/elasticsearch/jvm.options

更改前：

更改後：

9. 重新加載配置文件

$ sudo systemctl daemon-reload

10. 設定開機自動啟動 (選擇性)

$ sudo systemctl enable elasticsearch.service

11. 啟動 Elasticsearch 服務

$ sudo systemctl start elasticsearch.service
$ sudo systemctl status elasticsearch.service

Elasticsearch API

在進行 Elasticsearch API 操作之前，這邊為大家解析 Linux 裡，常用來呼叫 API 的指令及其組成方式，以便大家理解。

呼叫 Elasticseach API 基本組成如下：

curl --cacert <Cert_Path> -u <User_Name:Password> https://<IP | Domain_Name>:<Port_Number>

A：透過 HTTP Protocol 來呼叫 API 的指令

B：開啟 TLS 模式時，需指定憑證檔路徑。(Elasticserch 從版本 8 開始，預設開啟 TLS)。

C：使用者名稱和密碼。

D：服務的網址。這邊需要特別注意是否有開啟 TLS 模式：

• 開啟 TLS：https
• 未開啟 TLS：http

常用 Elasticsearch API

1. 確認 Elasticsearch 版本資訊

$ sudo curl --cacert /etc/elasticsearch/certs/http_ca.crt -u elastic:oYt3J2uBZnHNLNhmoNxY https://localhost:9200

2. 確認節點狀態

$ sudo curl --cacert /etc/elasticsearch/certs/http_ca.crt -u elastic:oYt3J2uBZnHNLNhmoNxY https://localhost:9200/_cat/nodes?v

3. 確認節點或集群的健康狀態

$ sudo curl --cacert /etc/elasticsearch/certs/http_ca.crt -u elastic:oYt3J2uBZnHNLNhmoNxY https://localhost:9200/_cat/health?v

注意：單節點的狀態欄 (Status) 若出現 Yellow 是正常狀況，因為這跟 Elasticsearch 的機制有關。當我們有一筆資料進入 Elasticsearch，預設會建立一個主分片 (Shard) 和副本 (Replica)，Elasticsearch 作為分散式資料庫，必須確保災難發生 (如節點故障、服務失效等等) 時，資料不會因為都存在同一台主機上導致遺失或損毀。因此，主分片和副本必定不會被分配到同一個節點上，節點狀態值可參考注意事項的表格。

4. 確認分片

$ sudo curl --cacert /etc/elasticsearch/certs/http_ca.crt -u elastic:oYt3J2uBZnHNLNhmoNxY https://localhost:9200/_cat/shards?v

注意事項

1. 節點狀態值

2. Elasticsearch 預設不允許使用 root 來啟動服務。

3. 在終端機上輸入 API 時，若 https 這段有使用參數 &，記得要加上雙引號將其框起來，因為在 Linux 中，參數 & 代表背景執行的意思。範例如下：

因查詢語法裡有參數 &，因此加上雙引號將其框起來 (下方灰框處)。

$ sudo curl --cacert /etc/elasticsearch/certs/http_ca.crt -u elastic:oYt3J2uBZnHNLNhmoNxY "https://localhost:9200/_cat/nodes?v&h=name,ip,pid,r"

若沒有框起來，依然可以執行，但會停留在結果畫面不動，須按 Enter 來結束。

$ sudo curl --cacert /etc/elasticsearch/certs/http_ca.crt -u elastic:oYt3J2uBZnHNLNhmoNxY https://localhost:9200/_cat/nodes?v&h=name,ip,pid,r

4. 因為 Elasticsearch 的 jvm 預設使用 4G 記憶體，需注意自身主機的記憶體資源，若資源不夠則無法啟動，並出現以下訊息。

$ sudo systemctl start elasticsearch.service

error 資訊：

$ sudo less /var/log/elasticsearch/elasticsearch.log
[2022-08-18T11:06:24,582][ERROR][o.e.b.Elasticsearch      ] [localhost] fatal exception while booting Elasticsearchorg.elasticsearch.bootstrap.StartupException: java.security.AccessControlException: access denied ("java.io.FilePermission" "/tmp" "read")

結語

本次 Elasticsearch 單節點的安裝流程到這邊結束。另外推薦大家可以安裝 Kibana，Kibana 作為圖形化 Dashboard，藉由圖表或視覺化畫面，幫助我們更快上手和管理數據。附上官方連結給大家參考：Install Kibana with RPM | Kibana Guide [8.3] | Elastic

本文章由歐立威技術顧問撰寫而成，轉載請註明出處，內容若有侵權請來信告知

Elasticsearch 不僅是一個強大的搜尋引擎，也是一個分散式資料庫。

它同時具備「資料搜尋、資料分析、高可用性」和「處理各類型資料」的能力，多元的使用場景與豐富的全球開放生態系，使它在權威指標 DB-Engines 的搜尋引擎分類中，持續蟬聯全球第一名的寶座。

隨著生成式 AI 與大型語言模型（LLM）的全面普及，如今 Elasticsearch 更是企業建置 RAG 等 AI 應用時，首選的向量資料庫（Vector Database）。

本篇文章將介紹 Elasticsearch 的核心基本概念，協助你快速掌握這套強大的搜尋與分析工具。

推薦閲讀：Elastic 9.4 新版本：Workflows 正式版上線、Agent Builder 優化與全面支援 PromQL

Elasticsearch 數據儲存類型

Elasticsearch 可以儲存「結構化」與「非結構化」等不同類型的數據。

類型1：結構化數據

一般來說，能整理成表單的資料就是結構化數據，它們通常有固定欄位、格式與順序。

舉例來說，申請信用卡時需要填寫的各項資料，就是典型的結構化數據表。

類型2：非結構化數據

結構化數據以外的資料，皆可以視為非結構化數據，例如：聲音、圖片、影片等。

它們缺乏可識別的架構、沒有固定的欄位及格式，無法被放入預定義的框架內。

在網路時代，非結構化資料量快速增長，有別於傳統的關聯式資料庫 （RDBMS） 如 Oracle, MS SQL 將資料轉為行列式的欄位進行儲存。

Elasticsearch 將數據以 JSON 格式儲存，因為不須預先定義格式，使用上更靈活，此外，針對圖片或長文本等非結構化資料，Elasticsearch 也能將其轉化為「高維向量 (Vectors)」儲存，這使得它具備處理語義搜尋的能力。這也是能夠快速儲存、搜索與分析各類數據的 Elasticsearch 被廣泛使用的原因之一。

雖然 Elasticsearch 使用的術語和 SQL 不同，但本質上是差不多的，差異可參考下方術語對照表 [1]：

Elasticsearch 數據搜索方式

Elasticsearch 的搜尋方式，可以分為兩種：

1. 全文檢索 （full-text search）
2. 倒排索引 （Inverted index）
3. 向量搜索 （Vector Search / kNN）

全文檢索

將非結構化的數據提取出來並重新組織，使其變得有一定結構，並對此結構的數據進行搜尋。

因此先建立索引，再對索引進行搜尋的過程，叫做「全文檢索」。

假設有一筆資料如下：

Elasticsearch 和傳統的 RDBMS 一樣，透過對 table 設定 primary key 將其設為索引，透過搜尋索引快速找到相關的資料內容。

但是，若想要針對關鍵字「登入」進行查詢，則會搜尋整個 table，因此資料量越大，效能就會越慢。

因此，Elasticsearch 還使用了「倒排索引」來提升搜尋速度。

倒排索引

紀錄每個字詞出現在哪些文檔及文檔中的位置，藉由搜尋字詞，快速地定位到有包含這些字詞的文檔及其出現位置。

假設有一筆資料如下表：

首先，我們可以對資料進行切分，至於要切分成多細，可自行規劃設定，例如：

若今天想要針對關鍵字「登入」進行查詢，可以知道 「id：1,2」內有此關鍵字。

再藉由 id 找到對應的資料內容，因為不需要搜尋整張 table，因此查詢效率大大地提高。

向量搜索

除了傳統的文字比對，Elasticsearch 現在也支援語義搜索。透過將資料轉換為數值向量，系統可以計算向量間的距離（相似度），進而實現「以圖搜圖」或「理解問題背後的含義」而非僅僅是字面上的匹配。這讓 Elasticsearch 成為目前主流 AI 應用（如 RAG 架構）中首選的向量資料庫之一。

近即時搜索 （Near Real-time, NRT）

近即時搜索是 Elasticsearch 的另一項重要特性。以往因為硬體所造成的效能瓶頸，導致每一筆新資料皆需等待 fsync 將 segment 寫入硬碟後，才能對 segment 進行檢索，從寫入到檢索往往會超過 1 分鐘。

傳統資料寫入流程如下：

1. 一筆新資料寫入記憶體的 buffer 中
2. 每隔一段時間，進行 commit：將 buffer 的資料寫入新的 segment
3. 新 segment 寫入作業系統的快取區 （cache）
4. 透過 fsync 將快取區的 segment 寫入硬碟，並清空 buffer
5. 可對 segment 進行檢索

Elasticsearch 優化這項流程：

1. 一筆新資料寫入記憶體的 buffer 中
2. 每隔一段時間，buffer 的資料寫入新的 segment
3. 新 segment 優先寫入作業系統的快取區
4. 寫入至快取區的 segment，不須等到 commit，便可直接檢索

在 Elasticsearch 中，寫入和開啟新 segment 的過程，稱為 refresh，並且預設每 1 秒刷新一次，以此實現近即時搜索。

核心基本概念

節點 （Node）

一個 Elasticsearch node 代表在一台主機上安裝 Elasticsearch 引擎，我們也可稱其為一個 Elasticsearch instance。

節點負責的工作有：

1. 傳遞數據
2. 節點之間的通訊
3. 網路（HTTP）的流量傳輸等

根據不同的工作需求，Elasticsearch 節點可以分配多種功能角色 [2]，其中常用的包括：

推薦閲讀：Elasticsearch 介紹 – 單節點安裝建置篇

集群（Cluster）

一般來說，集群通常都具備以下特性：

1. 高可用性 （HA）
2. 易擴展性
3. 負載平衡（Load Balance）

一個 Elasticsearch 集群通常「至少」由 3 個到數個節點組成，我們可以透過增加節點擴大集群規模，不僅可以提高整體效能、也能增加儲存空間。

另外，Elasticsearch 會自動分配分片（primary shard） 和副本 （replica shard） 至集群的各節點上，用來確保資料的安全性，也就是雞蛋不要放在同一個籃子的概念。

文檔 （Document）

• Elasticsearch 最小數據單元
• 通常以 json 格式表示
• 資料使用 key:value 的形式
• 可以是一條客戶數據、商品分類數據、訂單數據等。

一個 document 裡有多個 field，一個 field 為一個數據字串，document 的重要結構名詞解釋整理如下：

索引 （Index）

• Elasticsearch 的 index 就像是關聯式資料庫中的 database
• index 在 Elasticsearch 中是用來儲存 document 的容器，而這些 document 數據皆具有相似結構
• index 重要結構名詞解釋整理如下 [4]：

類型（Type）

重要更新：自 Elasticsearch 7.x 版本起已徹底棄用 Mapping Type。
過去一個 Index 可以包含多個 Type（類似一個資料庫有多張表），但現在一個 Index 只能對應一種資料型態（相當於一張 SQL Table）。如果你使用的是新版本，開發時可以直接忽略 Type 的設定。

• type 是 index 中，一個邏輯數據分類
• 每個 index 裡，可以有一個或多個 type
• 一個 type 下的 document，都有相同 field，例如：
  • type：日常商品 type ： product_id, product_name, product_desc, category_id, category_name
  • type：電器商品 type ： product_id, product_name, product_desc, category_id, category_name, service_period
  • type：生鮮商品 type ： product_id, product_name, product_desc, category_id, category_name, eat_period

分片（Shard）

Shard 全名為 primary shard，用於存放 index 數據。

當資料量過大，單一節點無法儲存時，就需要利用 Shard 拆分資料來儲存。

舉例來說，我們有三個節點，每個節點有 500G 的硬碟空間，當資料量為 1TB 時，此時任一節點都無法承載。

因此，透過切分 index 數據，使每個 Shard 皆包含一部分的 index，這樣便能將大量的資料分散並儲存在 Elasticsearch 集群的節點中，進而實現資料擴充以及效能提升。

Shard 可以實現：

1. 在多台伺服器上分散式執行搜尋和分析等操作，以此提高性能和流量
2. 快速橫向擴展 （scale），彈性滿足使用需求

補充：在建立 index 時，可以同時定義 primary_shard 數量，一旦設定完成並且建立 index 後，便無法再做修改。若無指定，預設的 shard 數量為 1。

副本（Replica）

Replica 全名為 replica shard，是 shard 的副本，replica 數量可以隨時修改，預設一個 shard 最少配一個 replica （版本 7.0.0 開始，shard 和 replica 預設從 5 個改為 1 個）。

Replica 的目的有兩個：

1. 高可用性：
   是最主要的目的，防止服務器故障，造成 shard 數據丟失。為了避免一個節點掛掉實影響到整個集群運作，可以為每個 shard 建立多個 replica 確保資料安全性。shard 和 replica 絕對不會同時存在同一個 Elasticsearch 節點上，以保持高可用性，但「單節點模式」例外。
2. 提升流量和性能：
   由於查詢時會在所有的 replica shard 上執行，因此可以提高查詢效率。

參考網址

• [1] Mapping concepts across SQL and Elasticsearch | Elasticsearch Guide [8.3] | Elastic
• [2] Node | Elasticsearch Guide [8.3] | Elastic
• [3] Sequence IDs: Coming Soon to an Elasticsearch Cluster Near You | Elastic Blog
• [4] Index modules | Elasticsearch Guide [8.3] | Elastic
• [5] Removal of mapping types | Elasticsearch Guide [7.17] | Elastic

本文章由歐立威技術顧問撰寫而成，轉載請註明出處，內容若有侵權請來信告知

加入歐立威 LINE 好友，了解更多產品資訊

總部位於英國的新興金融科技公司，Thought Machine ，在倫敦、新加坡、紐約和澳洲皆設有辦事處。而 Vault，其原生雲核心銀行系統，已被整合到著名的銀行業，包括Lloyds Bank、SEB、Standard Chartered、Curve 和 Atom bank。 Vault 使銀行能夠利用雲端計算，提供高度可配置的平台更好地為客戶服務。此外，無論是對現有銀行的架構進行複製或是全新的整合，身為基礎層的 Vault 都可以達成。

使用產品

Elasticsearch
Logstash
Kibana

解決方案

• 更強大的安全性

Thought Machine 使用 Elastic 保護銀行客戶的系統，保護企業及其客戶免受外部威脅。

• 更快速的合規性

Thought Machine 透過 Elastic 在不到一年的時間內實現了 ISO 27001 和 SOC 2 Type 1 的合規性，有助於建立客戶信任並獲得新客戶的支持。

• 更好的可觀察性

Thought Machine 開發人員可以透過 Elastic 快速獲得反饋，使企業在競爭中脫穎而出。

核心銀行系統的智能新方法

Thought Machine 的 CIO，Matt Wilkins 認為，COVID-19 的大流行、亞洲的光棍節等大型電子商務活動，甚至是居家辦公的趨勢，都在推動企業走向雲端，以便他們能夠提升競爭力，並更好地服務顧客。
Wilkins 指出，有遠見的業者高度仰賴雲端的運行。在娛樂、教育、政府服務等等，雲端提供了成本效益、可擴展性和靈活性的好處，而銀行業也不例外。
Vault 提供單一的軟體解決方案，銀行可以透果配置以提供任何產品、用戶體驗、營運模式或資料分析能力。此外，Vault 的部署提供客戶端客製化其平台的功能。
Vault，一個完全屬於原生雲的平台，可以作為軟體即服務 (SaaS) 交付，或託管在銀行選擇的雲端供應商上。Vault 中的所有資料在傳輸和靜態時均已加密。客戶資料由複雜的權限系統屏蔽，阻止未經授權的存取。

鎖定 Elastic 的強大功能，加強 Vault 客戶的資料安全性

儘管 Thought Machine 提供了高級別的安全性，但他們希望進一步加強資料保護，並更好地觀察不一致的系統行為和潛在威脅。
Wilkins 指出，銀行業對遷移到雲端的優勢持開放態度，但他們提出的第一個問題是如何實現與現有系統相同的安全性水準。為了保護自己的企業，確保為客戶提供的良好的服務，並使用 Elastic 進行監控和修復問題，上述皆是 Thought Machine 將 Elastic 視為安全基礎架構核心的原因。

Elastic 的原生雲環境、運用 Kubernetes （K8s）運行是 Thought Machine 的理想選擇

Thought Machine 的技術領導經理 Feroz Salam 指出，另外兩個絕佳的因素吸引 Thought Machine 使用 Elastic。首先，Elastic 是原生雲的，可以將 Elastic 部署到任何環境中。第二，Elastic 也可以輕鬆作為 Kubernetes 部署運行。Elastic 在 Kubernetes 投入大量努力，因此能夠像使用所有其他軟體的方式部署 Elastic 是非常重要的。Elastic 現在支援 Thought Machine 的安全事件響應系統，使用 Beats data shippers 從整個企業中提取資料，此外，在雲端、筆記型電腦和工作站以及伺服器上都有 Beats。資料被提取到我們的集中監控系統中，該系統會自動通知我們安全異常或是其他問題，以便立即處理。
Thought Machine 也使用 Elastic 為部署 Vault 的 SaaS 版本的客戶提供安全事件響應。每個客戶都有自己的 SaaS Kubernetes 叢集，我們收集和分析每個叢集中發生的所有操作的安全和稽核日誌。 Beats 再次發揮了收集資料的核心作用，然後將其推送到 Logstash 資料處理管道中，再饋送到 Elastic 中。
Elastic 使 Thought Machine 能夠管理大量資料。這包括每天在 Thought Machine 的所有生產叢集中提取 500GB、在 Vault SaaS 安全監控叢集中每天提取 275GB，以及在 Filebeats 中每天提取 60GB 的端點資料。

對關鍵漏洞的即時響應

在企業部署和 SaaS 場景中，Elastic 簡化了安全事件檢測流程，使銀行能夠確定問題的優先順序並解決問題，同時節省時間並優化資源利用。響應工程師不需要在 Elasticsearch 之外尋找影響公司資產的安全事件。藉由集中式雲端基礎架構稽核日誌、內部身份驗證日誌、雲端儲存庫日誌和端點日誌，工程師可以從 Elasticsearch 內部進行檢索，以全面了解雲端資源的生命週期，並在必要時進行跟進。
Salam 舉出了一個例子，Linux 操作系統中的「Sudo」漏洞被駭客利用，漏洞在未受保護的系統中獲得 root 存取權限。 這時，必需迅速採取行動，保護系統免受此類漏洞的影響。使用端點上的 Auditbeat agents 提供我們的連續資料，我們能夠立即識別集群中易受攻擊的機器，而無需等待漏洞掃描器更新。
借助 Elastic，Thought Machine 能夠在幾分鐘內搜尋，並視覺化整個集群中更新包的部署。在嚴重漏洞或零時差漏洞（zero-days）情況下，Elasticsearch 將成為了解其影響的關鍵工具。

快速達到 ISO 27001 合規性

選擇 Elastic 的決定還源於 Thought Machine 為了符合最新的安全標準。其中包括 ISO 27001（資訊安全管理的一系列標準最佳實踐）和 SOC 2 Type 1（確認諸如 Thought Machine 等供應商是否能夠實踐關鍵信任和安全原則報告）。Elastic Stack 包含的安全功能為我們提供實現 ISO 27001 合規性所需的許多功能，包括細粒度的存取控制，使 Thought Machine 能夠定義索引或索引子集，操作人員也可以使用這些索引維護安全性。借助 Elastic，我們顯著降低了實現 ISO 和 SOC 2 Type 1 合規性的成本和時間，使我們能夠吸引更多客戶，並增強現有客戶的安全性。
資料備份是 ISO 27001 的另一個重要特性，而 Elastic 在這方面也發揮著重要作用。 我們必須表明，我們有根據策略定義的期限內保留資料。Elastic 透過雲端備份的支援幫助我們實現這一點。

一鍵啟動新環境

Wilkins 補充：為了在產業中保持領先，需要創新，並以閃電般的速度響應客戶反饋和對新功能的要求。

Elastic 是我們可觀察性操作的核心，這意味著我們的開發人員可以查看來自他們運行容器的日誌，立即查看他們的 code 是否有任何問題，並修復它們。

在 Kubernetes 上利用 Elastic Cloud 意味著開發團隊可以快速啟動，並運行新的應用程式和功能。將所有的 Elastic 配置都作為代碼，這讓我們可以非常輕鬆地啟動新環境。只需按下按鈕，我們就可以設定一個新的 Elasticsearch 叢集，從我們的 Vault 環境中提取日誌。
展望未來的同時，Wilkins 相信 Elastic 將繼續在 Thought Machine 中發揮作用。在繼續發展其安全產品方面，該公司正在密切評估 Elastic Security 的安全資訊和事件管理 (SIEM) 以及端點安全功能，作為潛在的新工具添加到其堆棧中，以實現自動化、實時的威脅響應。

Elastic 透過報告、監控和可觀察性功能，幫助我們與客戶建立信譽和信任方面發揮了至關重要的作用。我們相信，我們可以比以前更快且安全地擴展我們的國際客群和合作夥伴關係。  – Matt Wilkins, CIO, Thought Machine

本文翻譯自：https://www.elastic.co/customers/thoughtmachine 
參考更多 Elastic 相關資訊：https://www.omniwaresoft.com.tw/elastic/