定義好資料庫大架構後，就可以開始思考，個股的資料要從哪裡來，一般有幾個常用來源，台灣證卷交易所、 Yahoo Finance及Google Finance ，但Yahoo一直有要收費的訊息，Google用起來好像沒有很順暢，最後還是直接到證交所去抓資料，但有些上櫃及興櫃資料則要到櫃買中心抓了。

實際驗證起來，透過不同API取得資料的複雜度好像都差不多，都需要先弄清楚他的資料格式。目前透過Web API取得的資料大部分都是用JSON這個格式，以下來分析證交所的資料格式，我們以每日收盤的個股股價資訊來分析，但證交所只能抓上市個股，上櫃股票只能由櫃買中心想辦法了。

證交所的每日個股URL格式為 https://www.twse.com.tw/exchangeReport/MI_INDEX?date=20210903&type=ALLBUT0999 ，但我們的目標是讓系統可以自動抓每天的股價，由上面的URL，可以看到date這個參數，因此我們可以改變這個參數來調整抓資料的日期，當然透過這個參數，也是可以抓到更久以前的資料。

另外，櫃買的每日個股URL格式為https://www.tpex.org.tw/openapi/v1/tpex_mainboard_daily_close_quotes?l=zh-tw&d=110/09/03&s=0,asc,0 ，他的日期格式則有些不一樣，在設計時要特別注意。

證交所資料格式分析

由抓到的格式，我們先一層一層分析，先看結構的第一層，有兩個重要資訊，”date” 可以讓我們確認抓到的日期是否符合，”stat”則用來確認URL下的指令是否正確。

確認了指令的正確性後，可以發現這資料還有另一個規則性，他有9個資料區塊，每個資料都有Subtitle、Fields 、 AlignsStyle 、Data及Note開頭的欄位名稱，但我們主要是要抓各股的交易價、量等資訊， 所以直接抓”data9″的資料就行了，當然可以參照一下”fields9″這個資訊，確認data9的資料內容。

找到了個股的收盤行情後，依照”field9″，就可以對應到”data9″的內容，”data9″是用array的方式紀錄每一筆個股的收盤資訊，如下的對應。

之後抓資料只要先把抓到的資料，轉成php的json_decode函數將抓到的資料轉成array，再取data9的資料並轉入資料庫即完成這第一個資料的轉換。

櫃買中心資料格式分析

透過櫃買中心的URL取得資料後，可以發現他的資料格式跟證交所的不大一樣，不過他比較單純一些，資料就是把每一檔個股的收盤資料一筆一筆的列出來，如下的呈現，

因此我們只要分析單一筆資料就行了，如下對應到相關的資料，以下就列出會用到的部分。

定時採集各股資料

了解了資料格式後，就可以著手開始蒐集資料，主程式是到證交所即櫃買中心蒐集當天的資料後，接著再把資料轉到資料庫。可以參考如下的流程設計，

但是這只有當天的資料，所以我們只要再去設定，開發環境的作業系統 ubuntu的cronjob功能，就可以每天定時去做資料採集了。

36 13-14 * * * /usr/bin/php /home/kevin/TWStock/html/twstock/main/tool/transtockcounter_twse.php > /tmp/tmp_transtockcounter_twse.log 2>&1

因為台灣股市在1:30會結束交易，而盤後交易會在14:00~14:30，因此，設定在13:36 及14:36時去抓股市資訊。

開發環境架構底定後，接下來的設計或規畫也比較能夠固定下來，當然最好是能把開發環境直接架起來，這樣在思考設計的過程也能夠直接簡單的驗證思考的方向是否正確，並且可以隨時調整開發環境。接下來就由資料庫的規畫開始。

考量到小白未來在搜尋及應用上可以即時的取得分析結果，以及大量資料的搜尋問題等，那資料庫的設計盡量達到以下幾個點，

1. 不要太複雜及關聯太多資料表(Table)，這樣可以提高未來查詢效能。
2. 資料分流，目前個股、ETF集權証等，大約有10000隻，如果全部放一個檔案可能會造成資料庫查詢效能緩慢問題，而且資料庫還是有一些容量上限問題，一般是幾TB，但還是想辦法分流，是比較好，小白的分流方式是一個個股，就自動建立一個資料表(table)，這樣應該可以有效的達到分流及提高效能的目標。
3. 資料欄位(Field)，規劃上是希望在查詢個股資料時，就可以把每天分析的結果一併找出來，因此在每日的資料表上，就保留分析結果及其他常規計算的欄位，讓每日分析後的結果存放，缺點就是每一筆資料的欄位數會變得許多，沒結構化，但這問題倒不用在意，設計的目的在於平衡，而不在炫技。

有了這3個概念想法後，大部分資料寫入資料庫前或後，會即時或直接進行分析跟複雜的計算，更新資料庫裡的分析、均量價等欄位，以下就是設計的資料格式(Table Schema)。

我們定義了三個資料表(Table)，關聯性並不複雜，但實際上比較複雜會落在第三個資料表-StockDaliy，因為他要負責做分流的工作，我的做法是這個資料表由程式自動產生，只要有新的個股在蒐集資料時發現，就產生一個StockDaliy，資料表的格式就會變成”StockDaliy_” + {Stock id}，基本上是對應Stock這個資料表的，當然之後如果StockDaliy要增減欄位(Field)，那就必須要寫一隻程式做批次修改，但這應該是可以接受的範圍。

因此未來每日蒐集完資料料就要同時更新Stock及StockDaliy，一個是記錄最近的記錄，另一個則是記錄每天的資訊，當分析完資料後，也是用同一個邏輯來記錄。

在StockDaliy上有一個type的欄位，這個欄位用來記錄該筆記錄是每日、每周、每月、每季等總合記錄，因此在蒐集資料的同時，也會順便算出周、月、季等統計型的資料並放入StockDaliy，未來想要查詢周、月、季，就依type查詢即可。

未來如果要繼續增加個股資料時，可以以Stock這個資料表為主關聯，並往外延伸，如除權息、EPS、營利等資訊，另外大盤指數、類股指數目前也是定義在Stock 資料表 裡面，透過Category這個資料表來做分辨，好處是以後除了分析個股外，也可以一併分析大盤指數跟類股指數，那程式設計起來也相對單純，並且可重複利用，也許只要調整一下參數就可以搞定。

雖然想做小白的目的不單純，但還是著手規劃，開始先來釐清需求到底是甚麼，

1. 可以自動抓出可能會漲的個股
2. 準確度要高
3. 操作要簡單，最好不要動腦(純粹自己需求)
   這需求好像一句話就可以歸納了，”百發百中自動選股”，在我內心深處依稀可聽到下聯”賺錢賺不完”，不過如果可以，分析師應該不知道賺到哪裡了，雖然不切實際，但做了才知道效果如何，反正需求者是自己，隨便做(哈哈哈~)。

為了要做到小白的需求，我們思考了幾個大元素的組合，大致如下，

資料庫，這是主要的核心，等於是資料交換中心，畢竟股票的每日交易數據、基本資料、法人等等等的，相當的多，而且要做到分析資料，這就不是一、兩天的資料就可以進行的，預計是把股市的一開始開市到現在的所有個股每日的資訊全部抓下來，這樣未來可備不時之需，但考量到是做盤後分析，所以就不抓每日的即時交易，如果這個抓下來，那我的主機大概負荷不了。但光每天盤後的交易資訊就很驚人了，試想2000支股票，30年的交易，最少有30萬筆資料，這麼大的資料量，就要思考使用資料伺服器來維護，而且查詢的速度要快、效能要好、可存的最大筆數要越大越好，重點要Free，在我心裡的清單就MySQL及PostgreSQL，最後是選擇MySQL，主要考量是自己比較習慣，相關的Tool也是蠻齊全的。當然除了資料庫伺服器外，資料庫的設計把資料做分流的重要關鍵，這個未來再做說明。

資料蒐集，這絕對是另一個主要因素，在這裏要思考到的是資料來源在哪裡以及資料格式要怎麼分析、轉換，一次性資料還是不斷更新的資料，甚至要考慮到蒐集資料時，會不會被對方給鎖住，這裡講的不是盜資料，而是大部分提供資料的網站擔心同時太多人上線，所以不希望有人占住頻寬而採取的機制。當然設計就要考慮到這個部分，不然被鎖住或被認定是奧客，以後再去要資料就很困難了，基本上算是網路禮儀的一種。

資料分析，如果把小白用人來做比喻，資料庫是小白的身體，資料蒐集可謂是養分，而資料分析就是小白的內涵及靈魂，最後的使用者介面則是小白的外表，人的內涵決定了未來的走向。因此，資料分析的方式也就決定了小白是否可以達到需求的關鍵因素了，為了讓分析的方法更彈性，所以設計上會先做第一個階段的分析，把基礎的資訊先運算後存入資料庫，如5均量價、10均量價，5日線、10日線等，這樣好處是下一階段分析可以節省運算時間，在整個分析上分了3個階段，未來在其他章節再說明。

使用者介面，雖然說他是外表，但往往他就是系統成功的關鍵，畢竟人是視覺性動物，有了順暢、簡單及清楚的操作介面，這樣像我這種真正的小白才不會有操作不良等副作用，也比較有機會讓小白發揮真正的效果。

有了上篇的需求分析後，大概清楚知道設計的目標在哪裡，這樣就可以先來把開發的環境建構起來，在使用者介面的設計上採用網站的方式設計，這樣對於有選擇障礙的我是一勞永逸，只要我手上有3C裝置(手機、平板、電腦)，隨時都可以好好的研究研究，不會受限，套一句話”小孩才做選擇”。

有了這概念後就著手應用網路既有資源，把相關的環境建構出來，如下

在這個開發架構的規畫上，是有些目的性的，

網頁前端

jQuery是網頁前端設計，相當成熟的Javascript的函式庫，相當適合來做互動式的Ajax設計，網路上的範例及介紹也相當豐富，資源取得容易。

Material Design是由Google主導定義的網頁風格設計，對工程型的設計師是一個福音，這個設計的好處是可以相容大部分的瀏覽器，不會像早期設計網頁時常有不相容問題，因此，使用Materialize css來做為小白網頁的骨架，他的設計依照Material Design的定義設計，未來不同瀏覽器、顯示裝置相容性問題應該可以大大減少。

HighCharts也是網路上常用畫圖表的工具，但這方面的工具野蠻多的，選他主要是可以輕易的畫出股票的紅黑K及相關資訊，功能也相當完整，導入也不複雜，網路上也可以輕易的找到相關文章，未來要求救也方便。

網頁後端

規劃上採用常見的Apache2 + Php7.x + MySQL5.x，作業系統則使用ubuntu18.04，為了不影響原本主機的運作，所以就建了一個Docker Container，把ubuntu, apache, php, mysql通通放到Docker 裡面，並建好相關環境。當然這樣的好處是未來如果要把小白移到別的主機或要複製小白的環境，只要將小白的Docker Container轉成檔案，搬到其他有Docker的環境就行了，也不用考慮到作業統的相容性問題。以下為幾個套件的簡單介紹，

網頁伺服器，這算是一個功能總稱，就小白而言，就Apache+Php+MySQL，一齊談的概念是ubuntu有個LAMP的套件，剛好就是這三個程式，因此安裝上還蠻容易的，但我使用的是PHP7.x的版本，所以只能一個一個安裝。

Docker，一個類似虛擬器的軟體，有點像Virtual Machine，但是它並沒有完整的占用CPU資源，而是比較像是共用CPU資源的概念，因此他執行的效能就比Virtual Machine好許多，如前段所述，當我們把小白的開發環境完整的建立在Docker的Container後，以後的移植性就相當的高，而且未來想開發新軟體，就不用擔心開發環境問題(通常是某些套件已找不到之類的)。

Apache，一個相當老牌的網頁伺服器，可大可小，但架設容易又相容PHP，在ubuntu直接安裝就行了，他的進階設定上也是相當複雜像虛擬伺服器之類的功能，但一般基本功能就挺好用了。

PHP語法直譯器，相當多的人使用的語法，據說由Perl演伸出來，因為5.x的版本，有安全及效能問題，就直上7.x版本，選用這個與法的另一個好處是他也可以直接當成script執行。

MySQL資料庫，是一套免費但功能強大的資料庫系統，速度跟容量不輸商業的資料庫，使用標準的SQL語法，而且也有現成的php管理程式。

綜合以上的軟體，共同特色都是Open Source以及有許多人使用，安全性跟效能上也都試相當的嚴謹。