大家上网时应该都有类似经验，就是浏览过某资讯或产品页面之后，接着开启 Facebook，旁边的广告栏就会跳出相关主题的广告。Facebook 到底怎么办到的？其实幕后靠的就是大数据即时分析平台 Vertica。为了揭开其神秘面纱，科技新报独家专访了台湾 Hewlett Packard Enterprise（HPE）的业务总监廖智宁，来为大家揭晓 Vertica 的能耐。
资料“储存、运算、回馈前端”即时完成
关于如何面对大数据，廖智宁说：“把资料传进来储存、运算、然后回馈到前端的 APP，这一连串动作如果没有办法即时完成的话，就不用玩了。”例如现在很流行的物联网，可能一个大系统就有一万多个感应器，每分每秒都会不断收到最新数据，如果还要等周期性 index 更新完才能查询，根本不可能进行“即时”分析，但 Vertica 却能够办得到。
从 IT 的角度来说，Vertica 是一种特殊的数据库，其特色是：
- column（垂直向）based：row（水平向）based 的传统 SQL 数据库每天需要定期更新整个资料表的 index，不然就无法查询；但只更新小范围的 index，又会发生数据库碎片化降低搜寻效率。而 column based 就没有 row based 的这些问题，可以一收到资料，就马上进行查询。
- MPP（Massively Parallel Processing）大量平行处理：不但可横向扩张，还能收缩。
- 跟关联式数据库（RDBMS）语法相容：不用学新的语法。
- 整合 GIS（地理资讯系统）的呼叫：只要会 SQL 指令就可以查询路线、形状、nearby 等资讯，而不需要知道 GIS 系统的技术细节。
Facebook 精准广告的奥秘
row based 跟 column base 的差别在哪里呢？传统数据库是以 row 为基础，记录像是“收件人：王小春；购买产品：铅笔、书本 A；购买日期：2017 年某月某日”这样的资料，一笔一笔储存到硬盘里，且每天需要定期更新整个资料表的 index，才能被查询。这种技术针对以天为周期、相对静态的资料查询是可以的；然而对于全球平均每日流量达 10PB（1PB=1024TB）的 Facebook 而言，投放广告的资料分析，必须在几分钟甚至几秒内即时完成，这是传统的 row based SQL 数据库所无法达成的任务，就算用最高速的 RAM based 数据库也不可能。
至于 column based，其实就是在资料表中以垂直向的“资料属性”为单位来储存资料。以台北市交通为例，实际存到数据库的资料会像这样：“大安区；大安区；万华区；大安区；文山区；大安区”，如果这些资料是 5 分钟内传进来的，就可以很快知道即时趋势集中在大安区，推测有大活动正在该处举行。廖智宁表示：“Vertica 是 column based 的数据库，不需要作 indexing，资料来的当下马上就能进行分析。”
“很多人以为，即时分析是在 Facebook 上面发生点击行为后才发生，其实不然。如果检查 Facebook 的网页 javascript 码，就会发现就算你没点，只是移动鼠标在照片上画个圈，这样的行为也都在 Facebook 追踪下。”廖智宁继续解释道：“Facebook 就是透过 Vertica 即时分析用户的行为模式，再加上合作网站的 cookie，推测出你感兴趣的事物，然后即时媒合广告商，放上投你所好的广告。”大家恍然大悟了吗？Facebook 并非只靠关键字与点击，可是还使用 Vertica 掌握用户的操作行为，才有办法完善消费者偏好分析、进而靠精准的广告投放大捞一笔啊！
▲ Facebook 后台透过 Vertica 大数据即时分析，能洞察用户行为，立刻媒合广告商投放广告。（Source：《科技新报》摄）
主机群可自动扩张，还能收缩
在 MPP 大量平行处理上，也是另一项 Vertica 优于传统 SQL 系的数据库的地方。传统上资讯系统的规划方式，是先问“最多会有多少人来用”，然后估计需要采买的软硬件设备数量。毕竟传统数据库就是一台一台买，如不能应付最大可能，偶发的尖峰到来时就会来不及买新机应付；然而尖峰时可能有 5 万人次的流量，平时却只有 1 万人次，等于平常有大量的机器闲置，造成巨大浪费。
Vertica 就不同了，它会观测流量成长趋势，自行动态增加主机。廖智宁以另一个客户 Twitter 为例：“比如最近的奥斯卡金像奖，颁奖时趋势上有越来越大的流量，本来 N 台的数据库 VM 群不够，就会触发一个事件，自动产生 N+1 台，甚至 N+2、N+3 台。”而 Vertica 更有收缩的能力，待流量尖峰过去后，Vertica 就会逐渐缩减 VM 群数量回到平常的配置。这是传统只能扩张的 SQL 数据库所办不到的。因此，Twitter 就不用因临时爆增的尖峰流量，得从此负担大量备而不用的新主机钜额租金。
理想的交通大数据
除了前述 Facebook、Twitter 以外，还包含 Zynga、Uber 等公司也均采用 Vertica 分析用户行为。
传统 Big Data 常用作大众交通运输的分析，但捷运、火车、公车等毕竟是运行固定的路线，需要叫车服务来完成抵达目的地的最后一哩，然而，叫车的行为通常很突然。站在乘客的立场，会希望不管何时何地，计程车越快来越好；从计程车司机的角度来说，则会希望避免空转，等到有把握载到客人的时段，才开车上路“巡逻”。如何让乘客方便、小客车司机又不空转（同时减少塞车、空污），也是一门大学问。
要应用大数据分析来解决问题，就必须在所有的计程车上布署感应器的节点。廖智宁表示：“姑且不论在台湾的法律问题，纯就技术面看，Uber 的确把这个问题解决了一大半。”Uber 在前端，是安装 APP 在司机们的手机内；在后台，则运用 Vertica 作大数据分析，因此能做到贴心的调派汽车与浮动费率，使得 Uber 尽可能在最需要叫车服务的地方，有最多的车子在跑。
更进一步，在 Uber 系统下，乘客不再是“随机人物”，他们的叫车习惯（喜欢哪种车、叫车的规律为何）被分析后，可以指示司机提早驶向某乘客习惯乘车地点，增加接到客的“命中率”。也就是说，利用 Vertica，Uber 还能够规划车流，提升交通运输效率。
▲ 叫车 APP 利用 Vertica 预估人潮所在，让计程车可提早抵达，帮助改善交通。（Source：Shutterstock）
以旧代新，台湾离“智慧”还有多远？
只要每台计程车都布署好大数据分析的终端节点，不论是 Uber，还是知名大车队，每一个司机都能享受得到好处。于是，去年交通部便推行智能计程车车表，并开启台北、新北两市计程车路线的研究案，由 HPE 与交通大学运输研究所合作承接，这不啻是计程车业的福音。然而，真实的状况却不尽理想，因为智慧车表唯一的资料传输界面，竟然是 1960 年代发明的 RS-232！
没有 NFC、蓝牙、无线网络，甚至没有 USB，完全无法进行即时大数据分析。取而代之的是由工读生带着笔电到计程车行，付钱恳请计程车司机暂停营业参与调查，还得把表从车上拔下来接电脑才能读取资料，而输出资料的指令只有一种──“一次输出一年份，不能按月份输出也不能指定范围”。这一切得在标案预算内达成，且终究只能做到抽样分析，Vertica 功能再强，也只能徒呼负负。
廖智宁解释：“按照中华民国标案的法规，由于不能独厚某间厂商，所以开的规格是‘要有资讯界面、要有输出资料的指令’。”由于没有指名说是“哪一种资讯界面”、“要有哪些输出资料的指令”，得标厂商用 20 多年前的旧科技做出这样“新型”的智能计程车车表，依旧完全符合规格。“政府很多的美意，到这一关就卡住了。”从他的语气中听得出不无遗憾。
▲ 廖智宁认为，大数据即时分析能帮助节省时间人力，提升产品及服务品质，但在纳入新科技时，法规也该做出因应，以免政府美意打折。（Source：《科技新报》摄）
法规没有与时俱进，导致这类化老旧腐朽为最新智慧科技的施政行为层出不穷。即便计程车司机们装了这款车表，也无法享受到类似 Uber 以及大型车队进行大数据分析的好处，于是大者恒大，不公平的状况无从改善。可见智慧新创不能只是口号，必须从法规开始完善配套措施，新科技才能真正落实，造福社会。
（首图来源：《科技新报》摄）
