• 那就請開始吧!

  • 我們稍微介紹一下Fusions360,我們今年4月成立,我們家董事長王可言博士之前是在資策會當副執行長,我之前是在資策會數據科技與應用研究所當組長,與王可言博士出來開這一家公司。公司到現在有二十個人,我們有一些願景跟服務,我稍微說明一下。

  • 我們其實想要做一個融合的數據平台,透過這一個數據平台focus金融科技創新的生態圈,這個是公司的想法,其實我們短期已經著手一些大數據的蒐集——其實也沒有到大數據——因為我們要做金融科技相關的服務,所以我們有意識地在蒐集一些data,比如一些金融的交易、期貨交易、總體經濟數據指標等等之類的,長期則是希望我們這一個平台可以變成是臺灣所有新創產業或是做金融服務產業的共通平台,此為平台長期的目的。

  • 我們平台有一些核心價值,我們認為這個平台能提供給金融機構來加速調整事業模式跟創新,為什麼我們會這麼想?因為這一個平台現在所有的數據資料是透過API的方式取用,API的好處是使用方式統一、一致、快速、有彈性。以臺灣現在發展FinTech的新創產業與團隊,目前取得數據資料有一定的難度,比如蒐集、處理、儲存資料等等這些事。他們應該把核心價值放在核心服務業務發展上而不是作蒐集或整理這些data,因此我們希望透過這一個平台可以幫助平台上的事業夥伴

  • 剛剛提到我們有意識地在蒐集一些data,我們data現在有幾個主要的來源,一個是證交所每一日的交易歷史資料,接著是像提供企業風險管理與分析「Dun & Bradstreet 鄧白氏全球商業數據和專業分析」的數據,也有跟TEJ台灣經濟新報、cnYES鉅亨網、時報資訊、Systex精誠資訊合作,而其實這一些數據來源,對我們來說,來源不同、license授權方式不同,還有這一些格式也不一樣,除了必須處理多重資料蒐集、彙整及處理的基礎工作之外,前端仍有很多的工作,像是我們花了很多時間在設計取得data的API。所以從4月到現在,有一些data現在已經已經透過API開放出來,所以在我們服務的前端,看起來是一個API Store,在這個Store上我們有依資料集的內容作比較細緻的分類,但大方向是分成"數據服務的API",再往上一點是提供"分析服務的API",這個分析服務的API其實是去呼叫一些"數據服務的API"來提供分析服務的。平台不管是數據本身或者是服務本身也好,我們都將其API化,所以平台上只有一種方式可以取用服務,也就是透過API。

  • 剛剛提到已經開放的一些資料,像在data API這一層,我們現在有超過80個DaaS APIs(Data-as-a-Service),20個AaaS APIs(Analytic-as-a-Service),API Store可以看到有一些公司分析、個人分析、交易策略及財富管理等等的分析,這些分析並不完全是我們公司自己做的,但因為我們公司是利用API Store來做到API交換平台,我們把API當作是電子商務的一種商品,所以API store交易的是API,因此,可以透過其他的夥伴讓他們自己把他們的服務上架,真是針對平台上目前有這麼多的API,但為什麼並不完全是我們自己做的原因所做的進一步說明。

  • 今天來拜會主委主要是因為看到一些報導,瞭解到政委其實對於開放政府、開放API的想法,我們認為我們的平台其實跟政委的目標和計畫要執行的方向是一致的。再回頭去看金管會最近提到要做金融資料協作中心,都是一樣的概念,但我們回去看政府的公開資料網站,資料其實還是散布在各個不同的政府單位,在取用這一件事情上,還是有很多種資料模式——依然還是很多資料模式——因此希望在這一個議題上,希望能跟政府、政委這邊有一些合作或者一些交流的部分,這個是今天來訪的主要目的。

  • 非常感謝。

  • 謝謝(笑)。

  • 我現在看一下「政府資料開放平台」,我站在使用者的角度來看還是有一點困難使用,因為並沒有統一一致的資料取用方式,或者是現在資料提供出來的格式也不同,我們在想說因為我們自己其實也是需要蒐集這一些資料,因為政府的開放資料跟發展金融科技是有蠻大的關聯,事實上我們沒有這麼多資源去做完這一些事。

  • 剛剛提到因為我們的平台是可以讓夥伴自己把他的API上架,這一件事對於整個生態圈的夥伴而言,我覺得這個是可以讓大家去共享、共創的平台,因為我們畢竟還是一間公司一家私人企業,當然說這一個資料也許從政府公開資料的角度而言是沒有要收費的,但是在這個平台上的資料,如果經過使用者取用、做了使用跟分析,所產生出來的價值可以再回到這一個平台上架,這一個價值是他創造的,所以可以變成在這一個平台claim這一個API的收費方式,這個會變成對於資料取用或者是使用的人有另外一層incentive,這個對我們而言也有好處,因為我們也減少蒐集資料和發展分析服務力氣,我們雖然正在做,但也沒有辦法這麼多人都在做這一件事,如果全公司只做這一件事的話,我們公司就會先完蛋(笑),所以得透過一個共創平台與社群朋友或是政府這邊協力來發展平台上的服務,希望透過共創、共享的方式把平台越滾越大,這個是我今天來的主要目的。

  • 如果你捲到左下角還有一個機器對機器專區——「M2M」——你們現在從政府資料開放平台是選擇特定的抓或者是用這一個M2M?全部都有,然後從那個索引下抓?

  • 我們沒有直接對這個方式抓,我們還是選某幾個特定的檔案做。

  • 因為其實我們這邊PDIS剛開始做的——差不多第一件事吧——幫忙把機器對機器的部分盤點,包含本來界接規範裡面其實有一些文件跟它的實作不完全一致的地方,還有把它的文件從給人看的PDF檔改成機器也可以看的描述檔,也就是Open API,是他們(右側辦公室同仁)所做的工作,未來政府進行一些開發案的時候,目前有兩個方向:一個方向是拿既有的系統,在不改變既有系統的前提下,把讀取跟寫入的部分盡可能訂出機器可讀的Open API來,因為這樣的關係就可以把兩個其實不同廠商,甚至在不同部會的系統去進行自動地界接,而界接的開發可以由第三方,包含我們或者是其他的業者來開發,這是我們目前實際在進行的工作。

  • 另外一個正在進行的工作是,也就是你剛才所講的新聞裡面說的,公共工程委員會正在應我們的要求修正資訊服務採購的相關辦法,這一個辦法具體條文是在說政府機關在評選廠商的時候,可以增列共通應用程式介面的開發評分項目,有得分的話,得標機會增加。

  • 在寫資訊服務裡面寫的開發或增修的話,把應用程序介面寫出來的過程裡,同時也要出一份Open API的描述檔,這是直接寫在採購契約範本裡,如果政府只是採買網站,那就無所謂,但如果開標案的那個人如果知道API這一件事網站之外還說要有應用程式介面,那麼履約的廠商就應該要使用Open API的方式來說明API,並不是用word檔來說明他的API。

  • 所以結合這兩個我們達到的目的,是隨著各個機關的系統,汰舊換新或者是更新,可以變成前後端分開採購的狀況,也就是當採購完後端,而且當後端訂下API的需求之後,就可以直接產生機器可讀給前端用的API,前端的API可以與時俱進,甚至可以有好幾個不同的前端或者是沒有前端專門只是為了別的服務站臺所使用的,這一個東西具體的說明可以看「join.gov.tw」有一個說明,不然「http://pdis.nat.gov.tw/」也有說明。

  • 當然這個不是一蹴可及的事情,這個規範下去之後,當然我們也知道政府機關編列預算的方式最快也是明年年底才會看到第一批用這樣方式的政府內部服務開始建置完成,而且很多Open API的意思是機器可讀、可寫,但並沒有說要開放給不特定人給外面使用,所以如同你說的,API可以收費,或者不是收根本只有內部網路的人可以用,那就符合API的精神,因為API只是格式上的開放,並不包含授權上的開放。所以等我們覺得哪一些已經準備好了可以作為開放資料或者是公眾可讀的開放API來釋出,我們才會轉成所謂的開放資料或者是公眾可以讀取的開放API,這個跟採購是拆開來的,這個是我們目前實作的方法。

  • 現在這一個平台是host在哪一個單位?

  • 我們現在有兩個平台,對不對?(詢問辦公室同仁Mark)一個是我們網站本身,是host在國外的一個Github廠商(笑),我們可以隨時移回院裡面。我們平常作業的平台是「iss.nat.gov.tw」,它是國發會跟應該是中華電信的採購的一個雲端資料中心,之前的用法大部分是把後端的電腦整台變成虛擬機器,然後上傳到這一個中心去,也就是省一台電腦運行,但是我進來之後一直在推輕量級的包裝容器,所以我們現在是用容器的方式來使用,其實沒有幾台,但是在上面跑了上百或者是上千個小容器,這個是任何機關都可以申請的。

  • 一開始提到處理檔案的事,像PDF,我們也自己在做這樣一個文件擷取,所以像這一些句子和關鍵字的斷、截、群、類也都做了,可能很多單位都在做類似的事,我在想說要怎麼去把大家的能量集中,而不是大家各自再做一套自己的系統,透過這個平台便能節省重覆開發類似功能的資源浪費,這才是我們認為平台自己該有的角色跟價值。

  • 剛才我看到你有開到某一位人事的FB,所以我們直接看一下他的作品好了。「SheetHub.com」這個你們有看過嗎?

  • 這兩位朋友所做的事情就是把剛才所說的開放資料平台的機器可讀介面裡面每一筆資料都全部下載下去,而且已經用半自動化的方式做了資料清理跟擷取的工作。依我所知,他們並沒有做按結構化到結構化的轉換,如:PDF到Excel。但是他們有做結構化的清理,比如Big5的資料集或者是欄位有不全的地方,他們用機器自動清理比對,而且把資料格式,好比像日期格式都做的這一種規劃,你們這一種有使用嗎?或者是?

  • 我們自己做了類似的自動化服務來加速我們做資料清理跟擷取的動作,但這是平台上的使用者看不到的基礎工程。在包裝發展這一個平台,我們比較希望它走的是服務化或者是商業化的概念,節省使用者做資料清理跟擷取惱人的基礎工程,只管如何在平台取用資料,在這個API Store裡面取得資料有JSON格式跟CVS檔等等的輸出,我們想做的是把像這樣的功能和服務綜合起來,變成比較像是國外類似的服務網站,比如說Mashape的網站。順帶一提,我們公司自己的服務在12/22(四)在君悅飯店有一個Service Launch Event,那時就會把API store開放出來,使用者可以進到這一個store裡面查閱搜尋有什麼API、怎麼用、如何取用。我們現在只有一種使用方式就是呼叫API,但我們比較強調的是API Store的概念。所以API Store裡面的API看得到也不見得能用,平台仍需要用Access Key去做存取控管,目的是希望大家使用或參與這平台服務並同時兼顧存取權限、使用紀錄與帳務管理——但產業環境現況實在是太發散了——事實上大家還是重複做別人已經做過或者是正在做的事情,這其實對每一個產業的每一個參與者都不是很好的一件事;即使如此,我們這個平台的特性是能透過共享、共創、共榮來解決產業現況,即便我們的服務目前並不是那麼完整,所以需要結合政府或者是業界的力量共同來做這一件事。

  • 有聽懂。所以隨著我們推行Open API在政府裡面越來越多,你在「data.gov.tw」上面慢慢看到不只是一筆筆資料集,而比較多的是可以開放存取的API服務,當然對你來講,這個你就省去了資料清理的工作,因為等於系統不但先清好,而且有機器可讀的描述檔。以我所知,我們現在用的是Open API的標準,這一代的標準裡面還沒有好比像觸發式服務的概念,但是下一版就要有了,所以理論上政府的服務慢慢轉到API裡面,我瞭解你們的跟我們的一樣,有了,應該是可以對接過來才對。

  • 假設我們用政府做好的API,我們變成繼承這個license的許可,是這樣嗎?

  • 我們一定提供政府資料的開放授權,那個其實是非常開放的授權,只要註明出處,其他要改做或者是販賣都可以,所以基本上就是你只要註明來源什麼事都可以做。

  • 講到這個授權,其實剛剛的網站上是英文授權的license跟中文的license字有寫錯;不過這個小事。

  • 這個小事。(閱覽網站後說)其實不是啦!那個是切換的意思。

  • 喔!我瞭解。

  • 當看到英文的意思是跑去英文的部分。

  • 原來是這樣。

  • 但是我同意理解,它是方括號,是按鈕的形狀,如果是圓括號,是註解的意思。

  • 「data.gov.tw」,你把node拿掉,直接打入「data.gov.tw/政府資料開放跨平臺介接規範.yaml」,目前我們做到只有如果你剛好能夠讀它的話,這個其實是不需要用猜的,也就是「data.gov.tw」json裡面就有了,我們是跟目錄裡面有一個「data.gov.tw/apis.json」就會列出這一個政府網站裡面的API,其中一個就是你剛剛看的那一個,其中一個是給各地方寫入的,我們目前短期的目標是跟我們合作的一些網站只要開始做出了API描述檔之後「data.gov.tw/apis.json」就要宣告,目前政府是這兩個平台。以這樣的格式,你們有可能做自動挖掘或者是探勘嗎?

  • 那這樣子的話,未來即使是政府網站分散在十七個,只要都遵循「data.gov.tw/apis.json」規範,其實也不是大問題。

  • 這樣授權跟格式大致都有提供了,如果你們平台需要我們做加值服務之前需要我們幫忙再跟我們說,但是至少這邊跟你們所用的技術標準格式是完全相同的?

  • 再來一點是,我們以站在業者的角度,其實我們很難要求政府做一些資料的開放。

  • 為什麼?不是有一個「要資料」這一頁嗎?

  • (笑)比如說我們會希望臺灣的徵信單位這樣的資料開放,這一件事我們就一直遇到很大的困難,我不曉得這邊能不能協助?

  • 就是同一個網站的底下是有一個討論區,看「data.gov.tw」下面有一個「我想要更多」,我看到有人說要開放聯徵信用評分的線上查詢,我不確定這個跟你們要的是不是同一個。

  • 應該是同一個。

  • 如果你打「聯徵」的話,應該可以看得到。

  • (黃建霖關鍵字輸入「聯徵」)

  • 一個(問題)是說個人信用評分,聯徵已經說沒有要提供了;各信用評分區間於銀行各產品別,他說授信信用卡相關資料選項,目前還沒有辦法開放,恐將對既有系統效能造成不利影響,所以目前看起來是有這樣的回應,我不確定你們要的是哪一些欄位。

  • 其實我們在取data這一件事,如果可以的話,我們希望是整個資料源都取得,這樣會讓我們做資料分析這一件事會比較精準。

  • 困難的是,這一些資料源是不是能就這樣開放出來?因為我們也有一些自動化的服務來加速我們做資料清理跟擷取的動作,只要讓我們接上第一筆,我們就有辦法把它變成API,這個也是我們希望在政府單位各個不同單位去介接資料源。

  • 你們希望做是你們要捐助這樣的技術嗎?

  • 我們可以把這一個技術…你說捐助,可以啊!但是重點是我們要接到我們需要的DB。

  • 理解啊!就是有一個對價關係在。

  • 那我們開始問細節,我知道大部分最多的是微軟的、Oracle跟比較小的,你們都可以接嗎?

  • 對,像我們接了精誠是SQL(音譯)Oracle…DB2…

  • 對,因為你們執行長,所以DB2一定都可以的。

  • 老實講DB2還沒有在data provider partners之中遇過,我想也許政府有,但是我們並沒有接觸到。也許將來有機會,我們是可以做這一件事,其實對我們而言是該發生的,例如說有一個需求進來的時候,觸發我們發生,也許不在原本公司計畫的roadmap裡面,但是data的來源就是它,所以就是得做,就是這樣的狀況。

  • 我剛剛的對價我可以講得更清楚一點嗎?就是說貴公司現在有可能我不知道幾十個標的上面覺得如果拿得到完整資料會比選擇性的開放資料還要好的標的,然後針對這一些標的你們並不反對一種很有趣的採購,就是說這個標的的主管機關單位不付你錢,但是是導入你的技術,但是代價是說把轉換過的東西公開資料、公開API,然後不得讓人取用?

  • 代價是他的資料要匯到我們的數據庫裡面。

  • 放到開放資料平台,也可以到數據庫裡面,所以你們並不是排除性,而是說其他包含你們在內的人可以用就可以用?

  • 對,我們的平台就是希望人家把資料拿去用,他可以拿去做他的數據分析、解決他自己的問題,也許這個資料來自於政府,也因為我們繼承政府開放資料的license,這個是不能收錢的,但他創造出來的價值或服務之後,服務可以再回到這一個平台上架,這個時候就是他可以自己去claim這一個API的收費方式,平台可以幫忙處理帳務和金流的部分並與之分享利潤。

  • 所以現在你直接從資料庫裡面的那一些描述欄位,你就可以直接生出Open API的描述檔嗎?

  • 我們自動產生API描述檔其實已達七、八成的自動化,還沒有到完全,剩下的就得花工程師的時間下去調整。

  • 所以我們那一個DB…

  • 不確定,但是背後是關聯式資料庫。

  • 但是他們的意思是關聯式資料庫都要做到八成,其他是要再清一下。

  • ETL的部分我們基本上都全自動化了,但在產生API描述檔的時候只有七、八成是機器寫出來,由於前面那一段ETL像我們已經接過精誠、時報、TEJ等等的資料,ETL自動化這部分算是蠻成熟穩定了——您提到的關聯式資料庫,我不確定能不能做——我們的狀況其實是他的資料源讓我們接進來之後,因為我們平台是在Amazon上,我們其實是把他的資料匯入我們的平台,然後存在DynamoDB裡,由於他的資料源原先並沒有API取用模式,但匯入我們的平台後便有了API的取用模式,整段歷程直到API完成上架提供訂閱服務已達七、八成自動化,雖然如此,但我還是不確定能不能做,還是得實際對接看看才能確定。

  • 所以你們現在用的是哪一個機房?

  • Amazon的日本機房。

  • 為什麼不考慮Google的彰化機房?

  • 我們一開始在選擇的時候,Amazon的入門門檻比較低,也就是計價方式對我們從4月開幕到現在,是比較低的。

  • 比較友善。

  • (笑)這個字比較友善。

  • 資料是不是都不能出臺灣?

  • 確實,也有資料不能出境的情況,所以我們也花了很多時間在做Database abstract那一層,所以我們也不完全依賴於Amazon、Google or Azure,所以我們實際上花了很多時間做打底的基礎工程。

  • …這樣聽起來的意思是如果你們哪一天要用Google雲端資料儲存或者是Big Table,也不是不可能,如果客戶極力要求你們的話。

  • 這個是屬於你們工作的優先順序,其實跟我們的關係不大,大家只是學這個的,好奇一下(笑)。

  • 這個必須,沒有辦法。畢竟我們target的客戶有一部份是finance institute,特別是當他們願意將部分data匯入我們平台的話,我們就一定得這麼做,若只是單純取用平台上的資料就另當別論了。

  • 我們自己的開發機器是在彰濱機房,在Google,但是那個是開發時用的,我們部署用的時候一定要用放在中華電信的政府雲,有各種各樣的原因。如果你們的軟體並不完全依賴於Amazon,未來談的東西會變多,如果要放到日本的話,我們至少從開放資料做起,因為沒有授權問題,但是如果是政府裡面自己對接的話,那就沒有辦法用日本的,要移到國內運行,這個是很明顯的事情。

  • 至於你們剛剛有興趣的資料集,如果可以給我們清單,這個就可以跟會議紀錄一起發布,我們才可以做媒合的工作,當然這個媒合也要看金管會跟其他部會的態度,並不是我們說了就算,至少你們這邊是有一個很明確的說法,這一些資料沒有被結構化資料方法的話,你們願意無償提供關聯式資料庫轉結構化資料的服務,只要願意用開放資料的方式放出來,可以這樣說嗎?

  • 那就是這樣。麻煩給我們清單。

  • 如果一開始有一、兩次成功的實例,我相信就還可以再跟別的部會談,也許是他們覺得你們會感興趣的,但是你們可能還要再評估;當然反過來,一些可能不一定依賴於Amazon的,可以移到臺灣運行,可以再談政府對接的這一個部分。

  • 我們的平台如果移到政府雲的單位裡,可以這樣嗎?

  • 那個就是屬於採購了,如果那個是常規系統的一部分,當然該做的審核、滲透測試都還要做,當然那個就不是開放資料,就不適用於剛剛講的對價,這個東西只是屬於第一步。

  • 那今天就到這邊,謝謝。

  • (會議結束)