TVBS
数位转型初期，TVBS目标是活化电视台以外的数位通路经营，来提升这些通路的广告营收。不过，旗下5大数位品牌，横跨不同装置共十几种通路，全都共用同一个后端资料库，每天要处理TB级数据，从排程、提取、载入、转换等作业，都在同一台共用工作站上执行。
先前介绍TVBS数位转型历程的文章中，我们也介绍过，这个架构与工作模式，如何使他们难以运用数据，或导入更多新技术。TVBS意识到，要数位转型，数据处理架构必须先支援。不只得排除高筑的技术债，更要根据应用目标，重新设计基础架构。
TVBS历代数据处理架构
自2019年起，TVBS历经了两次大型数据处理架构翻新。第一次翻新的关键在于，明确定义资料处理的流程及技术，并将不同数位通路的后端系统分离。第二次则是进一步定义资料存取的权限和最佳实践方法，并且打造出数据平台，以API模式处理资料存取。图片来源／TVBS
五年内翻新两次数据处理架构，并根据转型目标改造数据处理流程
TVBS第一代数据基础架构相当简单，所有资料来源汇入单一工作站，初步处理后存入资料库。资料库的资料需要再次处理，则会抛回工作站上执行。对外数位通路及对内应用程式，都从这一个后端资料库提取所需资料。
TVBS第一代数据处理架构图。图片来源／TVBS
2019年，TVBS展开第一次翻新时，首先将架构改为前后端分离，独立出各品牌的后端系统。有别与过往在单一VM上执行的做法，新架构明确区分出每一个处理阶段及执行环境，也多采用MDS（Modern Data Stack，现代数据架构）常见的SaaS工具。
第二代数据基础架构强调应用数据的速度及弹性。TVBS希望新架构有能力随时整合新技术。当品牌产品团队需要对市场做出反应，打造新功能时，不会受到技术限制。
转换到新架构后，TVBS每2至4周即会更新旗下不同数位通路的App，以更新底层开发框架及函式库版本，或优化系统架构。更新周期最快两周，最慢一个月。这些都是为了尽可能降低未来技术债累积的速度。
第二代架构的资料处理流程是，利用Airbyte、Fivetran、BigQuery DTS等数据提取和载入工具，将社群媒体、数位通路、应用程式商城等各种来源的数据，抛转到BigQuery。转换时，利用学习曲线较低的DBT（Data Build Tool），输出到BI工具Looker Studio，供IT及非IT数据使用者存取和分析。
TVBS第二代数据处理架构图。图片来源／TVBS
这一系列数据流程，则是用Apache Airflow来排程、监控。这些工具与技术，大部分都用SQL为核心语言，来一定程度降低学习这些工具的门槛。
费时两年翻新后，资料处理流程更加明确、单点故障风险减少。有明确定义流程和工具后，更降低IT部门交流技术及学习使用工具的门槛。不只如此，根据TVBS计算，新架构的数据处理成本较旧架构低上63%。
这个时期，为了提高数据应用弹性，快速迭代版本，他们还导入敏捷方法Scrum，在数位团队内设置专职Scrum Master，以及导入DevOps做法，改善IT团队的DORA绩效指标。导入容器化技术，来强化CI/CD及自动化部署能力。
2024年，TVBS以第二代架构为基础，开始打造升级版的第三代架构。
几年数位转型下来，内部资料使用频率增加，且更多非技术人员开始进行资料操作。伴随而来的需求是，更严谨的定义资料处理流程与权限。「过往做法，大家都是一家人，要我的资料，我开权限给你，你自己来我的资料库捞。一旦工具变多、资料处理量更大，就不可行。」策略与新创事业部数位开发中心副总监陈宏益解释。
举例来说，「有次，BigQuery当月费用暴增三倍。一问才知道，有团队为了新专案，不断存取资料来研究，以及制作素材，但不知道自己的做法超花钱。」陈宏益苦笑道。
为了让非技术人员根据需求使用资料处理工具时，能避免发生此类问题，TVBS在第三代架构中，加入更多有助于FinOps的做法，来节省营运所需数据处理支出。例如，他们设计了数据平台，作为系统间的资料存取介面。任何系统，包括外部系统要存取TVBS资料时，只能透过数据平台提供API来存取资料，以方便管理资料存取格式。
TVBS参考了Data Mesh（数据网格）与Data Fabric（数据经纬）的概念来设计新架构，前者做法是，适当将控管数据的责任指派给最靠近数据的营运端，支援不同数位通路品牌及行销等团队，依据时事和当下策略需求，灵活发展数位应用。
后者则是中心化的定义关键资料格式与处理流程，让数据能轻易流通于不同团队和部门，促成更多跨团队的协作，同时，确保内部人员都能遵循最佳实践方法。
陈宏益说，第三代数据处理架构的设计，一方面是为了支援更大量数据应用，尤其是支援非技术人员应用。另一方面，还要支援他们未来导入新技术。