Pinkoi资料团队如何打造Data工作流？资料处理关键细节大解密

全台最大的设计品购物网站Pinkoi，站上品牌超过一万八千家，贩售的商品更是琳琅满目，为了让用户快速找到喜欢的品项，Pinkoi资料团队的任务，就是要不断优化站内的搜索引擎、推荐系统以及商品排序的技术，来提升用户体验。Pinkoi资料团队工程师Ben，就在一场活动上揭露Pinkoi资料工作流（Data Pipeline）作法的演进，说明Pinkoi如何随着更多资料分析的需求，逐步调整Data Pipeline的架构与资料工程作法，来进一步优化网站。

Pinkoi的资料团队，从早期只有资料科学家的角色，至今已经成长为一个涵盖4个角色的团队，包括资料分析师、资料科学家、ML工程师以及资料工程师。其中，资料分析师属于产品组与市场组，负责仪表板开发、资料视觉化等应用，资料科学家则负责数据库查询、数据转换等应用，资料工程师主要负责资料工程相关的任务，ML工程师则偏向算法的开发。Ben表示，每一个角色都有其主要擅长的技能，但也需对其他技能有基本的认识或涉猎，才能更紧密的协同合作。

从钻木取火到火石取火：Pinkoi资料分析的演进历程

Pinkoi早期主要以机器学习进行资料分析，来预测用户对不同类别商品的喜好程度，最刚开始的Data Pipeline，是先用程式语言Python，将所需的资料从数据库取出，放置到云端储存服务AWS S3之中，再以这些资料来训练ML模型，同时将运算的结果放回S3与后端的数据库，提供后端人员运用资料。这就是最初设计的Data Pipeline，由于整个流程较原始、单纯，Ben也将这个资料运用方式，比喻为钻木取火。

不过，随着更多资料分析需求出现，若要回答出哪些商品页被浏览过、特定商品被加入购物车的次数、哪些商品被放入欲望清单等问题，由于数据库纪录的资料（如使用者、品项、交易纪录等），通常是最新状态且不可回溯，换句话说，数据库顶多记录了当前购物车内有哪些商品，无法提供过去一段时间内的购物车状态。

为了进一步找出数据洞察，Pinkoi导入了Server-side Tracking的机制，借由用户端（Client-side）在呼叫后端API时，将呼叫的内容转换成定义好的事件（Event），来更详细纪录下每一笔用户行为资料。

举例来说，有个用户将Pinkoi站上的商品加入购物车，透过Server-side Tracking就能记录下这个事件，包括使用的装置（Device）、发生时间（Created）、行为（Action）、对什么物件进行操作（Entity）、商品的ID（Entity_id）以及对这个行为或物件的备注说明（Props），在纪录下更多资料后，就能去回答前述想解决的问题，Ben也将这个更进阶的资料搜集方法，比喻为火石取火。

在运用了Server-side Tracking后，Pinkoi的Data Pipeline也随之改变。Ben表示，现行的Data Pipeline可大致分为5个部分，第一为资料来源，主要从数据库与Server-side Tracking机制来取得；第二是资料储存位置，会在资料团队将需要的资料取出（Ingest）后，以Parquet的格式存到S3；第三是资料的计算方式，早期资料团队用数据仓储工具Hive来计算资料，但后来转用丛集运算框架Spark，“因为Hive基本上还是用来写SQL，ML模型需要大量的特征工程，用Hive比较难写、也很难维护，所以我们后来转用Spark。”

Data Pipeline的第四部分，则是资料的管理方法，Ben说明，Pinkoi主要用Hive Metastore来管理S3的Parquet文件，也用工作流管理平台Airflow，来进行相依性（Dependency）的管理与排程；而最后一个部分，则是这些资料分析后的应用方式，其一是置于BI系统，让PM、分析师来运用，其二则是回馈给站上的推荐系统或搜索引擎使用。

运用了Server-side Tracking后的Data Pipeline。

资料分析无法面面俱到，需要权衡与选择较佳做法

除了导入Server-side Tracking，Pinkoi也进一步导入了Client-side Tracking的机制，来搜集更多用户行为资料，比如特定商品在个页面实际的曝光次数、新上线的功能是否被点击使用、用户停留在哪些页面的时间最久？这些以前无法回答的问题，也在导入了Client-side Tracking的技术后迎刃而解。

不过，Ben也提醒，虽然导入了Client-side Tracking后，能搜集更多用户行为资料，但仍无法涵盖站上所有发生的事情，也就是说，还是得做出权衡与选择（Trade-Off），搜集最需要了解的资料来应用。

比如说，为了提升用户体验，用户在网站中各种操作的反应时间要越短越好，但如果要搜集用户行为资料，势必要在更多程式码中埋Log，就会导致API携带的资讯量变多，反而拖累了反应速度，这就需要权衡出较佳的解方。另一个例子，则是App与Web用户的行为差异大，在埋事件追踪码时，要以App还是Web的用户行为来规划？也是一大需权衡的问题。

导入Client-side Tracking遇到的Trade-Off挑战。

“如果要买Client-side Tracking，会需要进行很多讨论，要先去衡量埋了Log可以带来什么价值，怎么做才能降低成本，而不是全部都靠Client-side Tracking来解决。”Ben说。

Ben也举例说明这些讨论的必要性。假设要了解首页上哪个版位的成效较佳，直接搜集每个版位的曝光点击，以点击率作为版面曝光的成效优劣，可能是最直觉的作法，但是，也不排除部分版位可能因设计较佳，让用户可以很快找到喜欢的商品，进而被导流到其他页面来浏览，以至于其他设计较差的版位根本没有曝光机会，造成了资料偏误（Bias）的问题；这时，就可能得靠A/B测试（A/B Testing）的方式，来找出更好成效的版位。而这些决策，就需要透过讨论，来权衡出较好的作法。

透过良好的ETL Pipeline设计，来确保资料处理正确、高效

在Data Pipeline之中，Ben形容，还有一个如黑盒子般的存在，也就是ETL Pipeline。ETL也就是Extract-Transform-Load的缩写，用来描述将资料从经过抽取（Extract）、转换（Transform）、载入（Load）的流程。

Ben说明Pinkoi的ETL Pipeline作法。若简单把ETL Pipeline分为三个阶段，第一阶段是资料撷取（Ingestion），也就是资料团队将资料取出、放到S3的过程，在这之后进入资料精炼（Refined）的阶段，将不需要的资料清除、并进行商业逻辑的转换，最后则进入资料整合（Aggregate）阶段，将资料整合到不同模型所需的资料中。

在设计ETL pipeline的过程中，Ben也特别点出几个需注意之处，包括需确保Pipeline在不同时间点的执行结果一致，需透过良好的资料分割设计（Partition）来提升运算效能，且在Airflow上的任务越来越多的同时，也需注意不同工作相依性的设计，来确保资料被正确处理与运用。

最后，Ben也提出Pinkoi正在解决的问题。第一，是在资料团队校核时，常需回滚大量资料，来执行新的POC，如何快速扩张运算资源来满足一次性的工作需求，是为一大挑战。第二，则是要做到更即时的模型决策，甚至在用户刚看过某一类别的商品时，下一秒，就能根据这个行为来提供回馈。第三，则是仍有许多事件无法被记录下来，数据库往往只有当前的用户行为资料，这部分也是团队努力精进的方向。