大家好！我是在冰封风格的数据分析系统部门担任数据工程师的@grassy。我在这里是为了分享冰封风格2022年9日的文章。

各位，你们在12月1日至12月3日举办的@cosme BEAUTY DAY 2022中成功地进行了大量购买，买到了你们想要的化妆品吗？你们已经仔细地查看了昨天刚刚公布的@cosme 2022年度最佳化妆品奖吗？

在下列问题之前

冰样式花了大约20年时间来建立日本最大的与美容有关的数据库。在谈论冰样式的业务时，数据是不可或缺的话题。
我们的数据分析系统部门广泛收集数据，这是冰样式业务的核心，并进行符合数据治理的数据管理、分析和服务提供等工作。
我们是一个保证数据质量的坚固屏障，提高数据价值并促进利用的部门，也是拓展业务潜力的利剑。
我们目前正在全力以赴构建全公司的数据整合基础设施，以统一内部存在的多个数据基础。

作为第一步，我将介绍将品牌官方的数据基础设施从本地的 Hadoop 环境迁移到 Google Cloud 的经历。

介绍旧数据基础设施

首先，让我们介绍旧的数据基础设施。品牌官方的数据基础设施汇集了许多用户行为趋势的数据，并且需要从各种数据源收集数据。当然，不仅仅是关系型数据库（RDBMS）保存了数据，还需要包括每个Web服务器的访问日志以及像RabbitMQ这样的队列系统的数据。

旧有的数据平台是在本地构建的以Hadoop为中心的架构。

各种 RDBMS 的数据通过 Spark 存储到 HDFS（Hadoop 分布式文件系统），访问日志和 RabbitMQ 的数据也通过 Apache Kafka 存储到 HDFS。存储在 HDFS 上的数据由 Spark 进行加工处理，有时会返回到 HDFS，有时则会保留在分布式数据存储系统 Kudu 中，以创建用于品牌官方的数据集市。这些任务分别编译为独立的 JAR 文件，并由作业调度程序 Rundeck 管理和执行任务流程。同时，创建的数据集市以 Parquet 文件的形式存储在 HDFS 上，并通过查询引擎 Impala 从前端应用程序中进行引用。

这张简图虽然被大大地省略，但仍能让人们了解到各种技术、语言和子系统（注意实线彩色箭头代表不同的源代码管理）的使用。

旧有数据基础设施的问题

旧的数据基础设施在商业环境中运营了大约两年半，但在这段时间里一直存在许多问题。为了更好地理解这些问题，将它们分为四个方面进行介绍，请结合上面的图表仔细查看。

1. 关于维持基础设施的挑战
为了维持在本地构建的 Hadoop 环境，必须进行硬件级别的维护，并且需要始终监视各个节点的资源分配，以确保多个组件之间不会争夺资源。此外，为了永久应对不断增加的数据量，还需要增加多台具有大容量存储的物理数据节点。

各个网页服务器的访问日志是通过fluentd经过kafka进行收集。由于fluentd需要在网页服务器端进行设置，因此，在跨多个服务进行收集时，需要在多台服务器上添加设置，而当服务端发生服务器替换等操作时，还需要与应用程序工程师密切合作以作为数据基础设施。依赖于各个服务会导致数据质量的差异和可靠性的降低。
另外，为了支持多样化的数据来源，需要针对每个数据源单独考虑收集方法，并构建相应的收集系统。

3. 批处理时间和响应速度的问题
在旧的数据基础设施中，进行一天的数据汇总需要花费13个小时，从数据生成到数据仓库提供给前端应用程序也需要2到3天的时间。有时候，对于从前端应用程序发送的即席查询，响应时间也接近1分钟，性能方面也存在问题。

4. 开发成本的挑战
使用多种语言和工具进行构建会给开发人员带来繁琐的管理问题，并增加新成员的学习成本。即使进入了维护运营阶段，多年过去了，也无法消除人员依赖，成为长期运营多重化的弊端。

为了解决上述问题，需要着眼于实质性的改进。但是，由于缺乏投入改进的人力资源，一直陷入了恶性循环。为了解决这些问题的一部分，决定将这个数据基础设施从本地迁移到云端。

介绍新数据基础设施

首先我将展示构建的新数据基础设施的整体情况。

从概略图中可以看出，与旧数据基础设施相比，新数据基础设施的结构非常简单。
我们决定将新数据基础设施迁移到Google Cloud。选择Google Cloud的原因是其在数据分析方面的强大性（在技术选择时）以及与同样由Google提供的Google Analytics的高度兼容性。
在新数据基础设施中，我们会将从各个数据源收集到的数据加载到BigQuery，并且所有复杂的处理都将使用标准SQL在BigQuery上进行编写。如果必须以文件形式存储以加载到BigQuery中，我们会将其汇总到Cloud Storage中。

所有的工作都在Cloud Composer中进行统一管理。首先，每个RDBMS的数据都会通过在Cloud Composer上启动的Dataproc进行汇总，并存储到Cloud Storage中。RabbitMQ的数据也通过在AWS上新建的中间件进行同样的存储，实现了多云架构（请期待第17天的@shirakih详细介绍一下这个中间件^^）。将存储在Cloud Storage中的数据加载到BigQuery中进行加工处理，以创建数据集。此外，作为数据集的BigQuery表可以通过前端应用程序直接通过Google API进行访问。

虽然运营开始了几个月（2022年8月，正式发布到商用环境），目前还无法确定这是否是最佳配置，但可以肯定的是，通过这种迁移，我们获得了巨大的好处。

通过云迁移解决的问题

1. 优先选择使用Google Cloud的托管服务，并统一语言为标准SQL和Python（部分仍使用Scala是因为正在利用旧的数据基础设施资产），通过将主要业务逻辑集中到一个源代码中，使系统的运维工作更加轻松。这一成果也体现在每月的运维时间上（见下图）。此举可以降低系统学习成本和代码复杂性，同时也降低了团队加入的门槛。

2. 在这次搬迁之际，我们做出了采用谷歌分析数据来替代收集网页服务器访问日志的决策，以追踪用户的浏览行为数据。尽管在每个页面上都需要实施标签，但无需通过其他模块或中间件，并且可以直接收集到BigQuery中，减少了维护的难度，降低了关注点。此外，通过选择与以前在公司内部用于分析的相同数据源，也促进了数据的标准化。

通过使用可自动伸缩的Cloud Composer来运行作业，批处理的执行时间大大减少，与由物理服务器组成的内部环境不同。由于这个原因，之前需要花费13个小时的日常处理现在只需约3小时左右，而以前需要花费大约10天的处理工作（根据每月分类汇总的全部数据），现在可以在两天内完成。此外，由于决定直接连接到BigQuery而不是通过前端应用程序进行连接，虽然出现了按量计费的成本问题，但是响应速度在大多数页面上都有显著改善（如下图所示）。

这样列举优点，看起来云迁移只有出色的结果，但要实现这种迁移，需要克服一些障碍。

在转型过程中遇到的障碍

我從舊有數據基礎架構的初期開發就成為了這個團隊的工程師，但這並不代表我完全理解這個系統的所有內容。這個數據基礎架構是為了彙總大部分使用者在Aistyle上的行為而開發的，為了能夠以容易分析的方式展示龐大的數據給品牌使用，需要複雜且龐大的數據處理邏輯。在內部，只有很少數的人理解這個邏輯的全部，根據這次的轉換，重新檢視需求以及解讀複雜的系統結構是一項非常困難的任務。

与以前在本地基础设施上构建的数据基础设施相比，最大的区别在于云端特有的按量计费系统。值得庆幸的是，@cosme的用户数量日益增长，设计时计算的数据量与发布时的实际数据量之间存在着意想不到的差异，这导致了在批量执行时估算所需资源和扫描大小的设计与实际需求相差较大。通过一定程度的分区设计和查询优化，已经取得了改善，但仍然面临问题，并且正在不断进行改进。

为了发布新的数据基盘，我们也需要解明与旧数据基盘之间发生的数据差异的原因。在这次迁移方针中，对于业务逻辑来说，基本上是沿用旧数据基盘，除了进行数据源的更改外，不会出现大的差异。然而，当我们使用新开发的源代码在实际的商业环境数据中进行聚合时，部分数据出现了数％至数十％的差异，我们花费了大量时间来确定其原因。其中许多原因是因为获取数据源的数据库状态发生了变化，这也让我们反省移迁计划阶段的风险管理不足。

总结

云云移行只是解决问题的一个选择，不是银弹。正如本文所述，我们已经解决了一些重大问题，但这并不适用于所有情况。我们还需要继续思考剩下的问题、新出现的问题，以及如何改善运营维护和开发周期。然而，通过解决许多问题并且凸显出剩下的问题，我们感觉到我们需要以组织的眼光来应对问题，而不仅仅是考虑某一个产品。

正如之前所提到的，我们将继续努力构建整合数据基础设施以实现我们的使命。此次品牌官方的云迁移将成为迈向这一目标的重要一步。通过云迁移成功地将超过100亿个数据保留在数据基础设施中，不仅增强了团队的自信，而且能够更顺利地与即将实现的整合数据基础设施和新数据基础设施进行协作！非常期待！！

如果您在阅读本文后对Ice Style的数据基础设施开发感到兴趣，我们非常期待您通过这里与我们联系。

冰淇淋风格的圣诞倒数日历仍将继续，敬请于明日开始继续享受！