酷澎
2019到2022年，全球受到疫情笼罩，线上商务市场大幅拓张。这段期间，酷澎年营收从台币2千亿元，急速成长到6千6百亿元。极其庞大的业务规模扩张，使他们持续升级数据基础建设。
这个基础建设自2019年的大数据平台扩张。不过，他们不再叫它「大数据平台」，而是「数据平台」──这意味著，不管数据大小，只要可以用来辅助决策，都会透过这个平台处理、输出。
截至2022年，这个PB级数据平台一天执行超过5,000个任务，使用超过70个来源的数据。从工程师、商业分析师、高阶主管、外部供应商和外部广告主，超过50个团队使用数据平台。甚至，酷澎预期，此平台未来处理数据量还会再增加数倍，就算目前平台足以支援高时效性、高并行性的PB级数据处理，他们仍不断升级数据处理流程，为未来平台扩充做准备。
靠通用撷取框架来支援高速、多元、大量数据处理
酷澎数据平台的架构主体分为撷取和分析类大平台。撷取平台由网页日志纪录、串流数据架构及通用数据撷取框架组成，从超过70种来源撷取数据。数据平台会自动化调度（Orchestrate）这些数据的储存和处理程序，期间套用资安及数据品质框架。接著，数据会汇入由大数据平台、顾客体验分析平台及机器学习平台构成的分析类平台，依照不同使用需求进一步处理数据，再输出到实际使用这些数据的系统中。
由于数据来源众多，传统手动建置个别数据流程（Date pipeline）的作法会导致管理及维护困难。酷澎做法是，自行打造一个通用数据撷取（UDI，Universal Data Ingestion）框架，能全自动化撷取资料、适用于所有数据源，且数据使用者可以不仰赖数据工程师，自行调整数据撷取设定。
UDI框架设计强调可以处理多元、高速、大量的数据。为了支援多元数据来源，酷澎将UDI框架设计为一个Hadoop的外挂框架，新增数据源时，只要重复套用同一框架便能完成，既不需要撰写大量程式码，更压低了新增流程的成本。
酷澎还设计了各式自动化流程，以实现高速处理大量数据。例如，撷取数据时，此框架会自动化检查数据撷取过程符合资安协定、自动化过滤数据，只存取必要栏位。批次撷取数据时，会自动评估并设定每批数据量，控制在有效率但安全的范围内。
为了处理大量数据，酷澎将数据湖建立在AWS S3环境，以支援大量平行扩充。数据查询及处理也使用各式支援大量数据处理的开源技术。例如，用Hive来设计数据消费层，使用Spark来进行ELT等数据处理，以及使用Presto作为临时资料查询引擎。
未来，酷澎计划调整数据撷取模式，要发展事件驱动型（Event-based）即时资料流处理流程，并从异动资料撷取（CDC）逐渐改为强型别Log-based撷取模式。
打造Hadoop抽象层来提升资源运用效率
数据经过初步处理，流到分析平台，进一步根据实际应用需求来处理。分析平台是大数据分析、数据探勘、数据管理、查询、各式实验、机器学习、顾客体验分析等诸多数据应用场景的基础建设，
随著数据应用需求不断多元化、规模化，酷澎以原本数据处理架构为基础，打造新工作管理机制，借由提升资源利用效率，来支援更多并行工作。这对分析平台中处理最多数据的大数据平台，尤其重要。
酷澎对大数据平台下的Hadoop便下了许多功夫来优化管理机制。他们使用Hadoop环境时，遇到了一些痛点，其一是部分数据使用者不熟悉数据处理指令撰写，成为他们使用数据的阻力，也使资源运用效率较低。
第二个问题较为复杂，涉及到成本、资源运用及Hadoop设计带来的限制。
酷澎在Amazon EMR环境执行Hadoop。随著用量提升，云端储存和运算资源用成本控管成为一大课题。酷澎大多使用较便宜的Spot Instances（竞价型执行个体），而非较贵的Reserved（预留型）或On-Demand Instances（按需计价执行个体）。代价是，颠峰时段，运算资源时常会AWS被收回，给其他更高优先级或开价更高的云端用户使用，导致工作中断，进而影响整体资料品质。
当酷澎能稳定存取的运算资源不足，便衍生出了大量资料回填（Backfill）需求。偏偏，Hadoop设计上对于数据删除、更新及新增 （Upsert）支援度不高，大量回填不仅造成额外运算成本，还可能进一步影响数据品质。甚至，来不及等到资料回填，他们就被迫用低品质的数据来进行决策。
2019年，为了优化云端资源运用效率，酷澎开始依照用途来分类丛集，分出了特定用途、常驻、短期等不同丛集类型，并严格控管每个丛集的生命周期长短，以避免浪费运算资源。同时，他们导入了基于人工预测的扩充机制，依据资源用量峰值分析，来提前排程丛集资源扩充，以避免云端服务商原有的自动扩充功能来不及应对爆量需求。
后来，酷澎还打造了Hadoop抽象层来进一步强化资源分配。Hadoop抽象层是一个Web-based介面，作为中心化监控及管理系统。负责管理的工程师可以用来监控及管理EMR丛集。终端使用者则能透过Airflow operator或Python SDK等管道来提交任务需求到抽象层，再由抽象层自动分配适当的技术、丛集及资源用量。
这个抽象层为Hadoop上的工作流程带来几个益处。其一，简化了大数据处理任务的提交流程；其二，简化了数据丛集的实体细节；其三，透过自动分配机制，每个任务获得适当的运算资源，酷澎暂时避免了靠增加额外Hadoop丛集来扩充资源。
调整Redshift丛集分工来降低资源争夺
大数据平台中，酷澎使用Redshift作为销售、财务、产品目录及行销等不同领域数据的资料仓储。酷澎表示，Redshift管理需求低、上手容易，但随著数据量以及查询需求提升，Redshift开始出现了一些问题。
第一是资源用量低扩充弹性问题。Redshift扩充弹性不如Hadoop，酷澎会随著数据使用需求弹性扩充和缩减。不过，Redshift调整的弹性不足以应付他们数据使用需求变化。这导致工程师调整用量时，时常在使用者沟通及检查系统健康状况，费时甚至多于扩充相关的实际工程作业。
第二个问题是并行任务管理问题。Redshift是大规模平行处理（MPP）架构，任务伫列管理会更加复杂，且同时进行的资料查询或资料处理任务会互相排挤。频宽和算力的排挤，会造成执行速度下滑；数据及元数据存取权的排挤，则会导致资料存取锁定（Data lock）。也由于MPP原本设计上不会于丛集间分享数据，酷澎起初做法是在不同丛集丛集中储存数据副本，虽然一定程度增加任务执行速度，但算力和储存需求负荷便会更重。
后来，酷澎调整Redshift丛集的架构，分为3个数据处理丛集以及5个使用者查询丛集。前者又分为1个关键处理丛集以及2个一般处理丛集。一般处理丛集主要用来处理数据提取及载入（ELT中的E和L），以及少量转换（ELT中的T）；关键处理丛集负责关键资料转换，从原始资料转为符合不同需求的资料市集。
5个使用者查询丛集则分配给不同业务领域的使用者，用来做领域专门的临时分析、额外数据转换，以及重复执行查询指令来做数据追踪。
这种分工模式，使丛集间争取资源的情况减少。他们还将这些丛集转换为Redshift RA3丛集，支援跨丛集数据共享功能，不再需要手动复制数据。
不只如此，他们导入了Redshift Spectrum工具，可以直接从S3环境中查询结构和半结构化资料，而不需要载入数据到Redshift表格中。若使用者要查询的数据不需要经由Redshift丛集处理，便能直接透过Spectrum来快速达成。
未来，他们计划将Redshift资料处理程序转移到资源扩充更弹性的EMR环境，利用Spark来进行资料处理。不过，仍支援使用者用Redshift来处理储存于S3的数据。
建立数据探勘系统来支援全平台元数据检索
良好的元数据搜寻功能对于数据探勘、数据管理、各式数据工程及数据应用来说相当关键。酷澎早期已经开发了元数据搜寻引擎，不过随著数据基础架构演进，此系统不复堪用。
举例来说，Hive元数据储存在Metastore资料库中，但实际数据则储存在HDFS中，使用者常会需要知道数据格式、储存位置、数据沿袭、新鲜度、以及产生时间等资讯。这与传统RDBMS只在意表格Schema的情况非常不同。
近年酷澎更新了数据探勘系统，会自动用Meta query从各式生产系统的资料库以及资料仓储搜集元数据，并统一储存在中央元数据资料库中，供使用者搜寻。此系统1小时内便能反映元数据变动。
这个探勘系统虽然不复杂，却是大数据平台重要的一环，也是酷澎内使用率前几高的数据管理功能，一天会有上百人来从上千个数据表中查询元数据。
打造顾客分析及ML专用平台，统一管理工作流程及资源分配
顾客资料分析以及机器学习模型训练是酷澎两大类关键数据应用情境，经手数据量大、数据处理需求多、应用范围也广。过往，这两类情境的数据流程是逐案建立，不过随著需求量提升，他们便为这两类情境打造了专用自助式平台，以减少重工、统一工作流程、管理资源分配，并降低非工程人员使用门槛。
为顾客资料分析建立的自助式平台名为顾客经验分析平台（CXAP），会搜集各式客户端事件数据并提供分析功能。此平台作用类似于CDP，不过是整合到整个数据平台当中，而非一个独立系统。
使用者于CXAP前端介面可以进行数据分析和探勘。CXAP支援输入SQL指令，也有图形化使用者界面，不需要写程式码就可以做到使用者旅途分析、销售漏斗分析、数据趋势分析等操作。
CXAP后端包含开源关连式资料库ClickHouse，支援接近即时的数据撷取和处理，可以在数据产生数十秒内完成撷取，以加速数据从生成到实际应用。他们还整合了数据分析及探勘工具Superset，可以快速制作视觉化报表。
酷澎也为机器学习模型开发设置了一个平台。机器学习平台则比CXAP更加复杂，统一了数据准备、互动式Notebook开发环境、运算资源存取、超参数调整、模型部署及应用等ML工作流程，并支援常见ML工程所需资源。
此平台将ML模型开发流程分为3阶段：数据准备阶段、训练和追踪阶段、实际应用阶段。数据准备阶段，酷澎使用Airflow来管理并驱动Spark、Hive、Presto等数据处理工具，以导入机器学习所需训练数据。他们更开发了一个SDK，让工程师可以整合、同步、分享及管理不同来源的数据集。
训练和追踪阶段，此平台提供预先封装了各式常见ML/DL框架及数据科学函式库的容器，只要启动一个Jupyter容器即能进行后续开发。开发人员可以透过CLI或API来存取GPU运算资源，进行模型训练，还可以透过视觉化仪表板追踪实验进度。此平台也支援多种超参数调整演算法，来快速实验不同超参数设定。
实际应用阶段，此平台内建模型部署工具，用K8S来管理和执行模型部署及连结到外部应用程式。开发人员也容易透过Jsonnet来设定自动扩充配置，以及产生符合REST格式和使用gRPS协定的模型对外API。
数据经过数据平台一系列处理后，会输出到各式工具及系统，供内外部终端使用者使用。正是利用这些数据，酷澎许多核心竞争能力才变得可能。
接下来，我们将介绍酷澎如何利用这些数据，来支援火箭速配背后的自制地图系统、高科技物流中心背后的SCM应用开发工具，以及支援产品功能设计、产品外观设计、SCM、行销等不同领域利用数据驱动决策的实验平台。
酷澎2022年数据平台架构
酷澎数据平台架构中，数据撷取层从超过70种数据源撷取数据，经过储存、处理、资安及调度等程序，将数据输入到数据分析平台。分析平台会再依据各式数据应用需求进行进阶处理，再输出到串接于平台的不同系统中。图片来源／酷澎
大数据平台的Hadoop抽象层
酷澎为大数据平台的Hadoop打造了一层抽象层。一般使用者可以透过Airflow或SDK来提交数据任务，由抽象层会自动分配任务所需资源和执行环境。系统管理员则能透过此抽象层来中心化管理EMR丛集。图片来源／酷澎
大数据平台的Redshift丛集设计架构
酷澎为大数据平台的Redshift重新设计了丛集架构，数据会先由2个一般处理丛集进行提取和载入，再由关键处理丛集来转换，输入到5个依业务领域分类的使用者查询丛集，进行进一步转换、测试和分析。图片来源／酷澎
大数据平台的数据探勘系统
数据探勘系统会从各式生产资料库及资料仓储搜集元数据，供每天上百个使用者搜寻上千个数据表的各式元数据，包括数据格式、储存位置、沿袭历程、新鲜度、以及产生时间等。图片来源／酷澎
分析类平台的顾客体验分析平台
酷澎分析平台下的顾客体验分析平台可以用SQL指令来搜寻各式客户端事件数据，也能透过No-code工具来生产各式视觉化资料分析报表。图为分析顾客旅途用的桑基图。图片来源／酷澎
分析类平台的机器学习平台
酷澎分析平台下的机器学习平台制定了一个标准化工作流程，涵盖资料准备、训练、GPU资源调度、模型调整、模型储存、模型部署、外部系统串接。平台上提供许多常见ML工程所需资源，并有统一GPU资源分配机制。图片来源／酷澎