37手游徐玉立：数据治理之道，37手游高效发行背后有何秘密？

【GameLook专稿，未经授权不得转载！】

GameLook报道/5月16日，由亚马逊云科技举办2023游戏开发者大会Game Tech Day盛大开幕。

在此次开发者大会上，亚马逊云科技就将立足于先进技术的最佳实践与行业发展的深度洞察，通过“构建”、“运行”、“增长”三大分论坛，携手包括完美世界、37手游、柳叶刀工作室、Mattel 163在内的十余位行业先行者，与您一起探索包括 Serverless、微服务、生成式 AI 在内的多个热门技术，并探讨数据、架构、运维、安全、合规等众多行业热门话题，一起将游戏的无限可能变为现实。

而在“运行”分论坛中，37手游数据架构师徐玉立以“37手游高效发行背后的秘密-数据治理之道”进行了精彩的分享。

以下是分享实录：

徐玉立：大家好，欢迎大家来到2023亚马逊云科技游戏开发者大会，首先介绍一下我自己，我是来自于三七互娱集团、37手游数据架构师，主要负责37手游数据仓库与数据中台的建设工作，以及广告归因与广告投放系统的架构设计。

今天我为大家带来的分享是“37手游高效发行背后的秘密 数据治理之道”，下面我将会从一下4个方面进行分享，分别是37手游业务背景，37手游在数据治理方面的实践，以及游戏出海面临的挑战：数据安全合规，再就是未来的一些展望。

首先介绍一下37手游的业务背景，37手游是三七互娱旗下的全资子公司，三七互娱是一家中国领先的游戏开发与发行公司，全球排名Top20的游戏企业，其中2022年全球营收164.06亿元，这当中我们的海外业务发展的很快，2022年海外营收接近60亿元，同比增长25.47%。右边这张展现2022年中国手游发行商海外收入榜中，三七互娱的排名是比较高的。

接下来介绍一下我所在的37手游，它是三七互娱旗下核心的游戏发行子公司，主要从事的是全球手游发行业务，在国内市场37手游发行的市占率可以进入Top3，在海外市场，我们37手游也逐渐发力，海外市场的营收占比逐年提高。

其中值得一提的是，海外发行的《云上城之歌》是2022年H1里国产游戏在韩国市场收入最高的一款手游，同时《云上城之歌》在日本市场的收入增长榜也能够排到前三的位置。

迄今为止，37手游累计发行了近2000余款游戏，其中有一些大家熟知、比较流行的游戏，比如《永恒纪元》《精灵盛典：黎明》《斗罗大陆：武魂觉醒》《斗罗大陆：魂师对决》《云上城之歌》等等。

接下说一下我们37手游在2023年的发行策略，我们将坚持“精品化，多元化，全球化”的发行策略，这里重点说一下全球化，意思是一款游戏既在国内发行也在海外发行，甚至一款游戏全球同服，这样做的好处是，不仅可以提升游戏的知名度，也能够提升玩家的数量与收益。

当然，全球同服也会带来一些新的挑战，比如语言的本地化游戏玩法的本地化等等，还有一方面就是对技术能力的挑战，比如游戏需要做全球同服，我们的玩家身处不同的玩家物理位置相隔千里，网络访问质量对于游戏玩家的体验是至关重要的，我们不可能在每一个国家建立游戏服务器，如何降低网络延迟将是一个非常大的挑战。

我们37手游在实践过程中，比较好的解决了这一难题，主要是我们使用了AWS全球骨干网络，它在海外区域能够形成低延迟、高吞吐高质量的连接，我们测试发现我们海外玩家通过国际互联网连接游戏服务，容易产生一些丢包抖动的现象，使用AWS的全球骨干网络后，玩家访问的丢包时长会明显降低。

这张图片展示的是我们37手游国内海外都会发行的两款游戏，也是我们今年准备大推的产品《Primitive Era》与《Lost Galaxy：Guardian》。

众所周知，我们37手游是一家著名游戏发行公司，对于一家发行商而言核心是什么？在增量时代，多数发行商的要求不外乎低成本的获客能力，强大产品的收容能力、也就是说要有好的产品，但是现在的“玩法”不同了。

首先，现在的移动互联网已经进入存量时代，玩家的数量已经达到顶峰，再加上总量调控，产品数量有限，而市场已经度过了粗放增长期，所以游戏发行商必须具备完善且高效的数据分析应用的能力，才能更具备市场竞争力。

接下来，说一下数据分析应用能力在游戏发行业务三个重要的应用方面。第一块是精细化运营，指的是针对游戏产品不同的玩家群体，通过数据分析、数据应用，实现个性化、精准化的服务，主要目的是提高玩家的留存率、活跃以及付费率这些核心指标。

第二块是广告投放效果分析，是指对广告投放数据的统计与挖掘，评估广告投放计划的效果和方案，为投手提供数据支撑，可以说数据就是投手的眼睛，没有数据支撑投手就和盲人一样、无从决策。

第三块，我们是游戏发行公司，如果我们对游戏市场缺乏足够的了解，我们无法判断我们发行的游戏品类，所以我们需要对游戏市场的分析与挖掘了解各个游戏品类的市场情况与竞争状态，从而预测市场的趋势与变化，为我们的游戏发行提供市场定位与产品规划方案，也就是说，数据能力已经成为每个游戏发行公司必须掌握的核心能力。

因为极其重要，所以我们公司也很重视数据的能力建设，其中我们打造了像数据分析系统、监控预警系统以及用户画像系统等基础平台能力建设，也打造了像智能化投放系统“量子”以及运营分析系统“天机”等核心业务系统。

我们通过大数据赋能，高效研发的理念，借助大数据分析与数据挖掘技术，为我们的研发团队提供了数据支撑与分析能力，赋能他们让他们实现高效率研发，同时我们也将数据能力赋能给业务团队，通过“量子”“天机”这样的系统，帮助业务实现智能化投放、智能化分析功能，实现了流量的精细化运营。

下面就是介绍我们的智能投放系统“量子”带来的业务价值，在“量子”之前，我们的广告投放需要投手自己去创建广告计划，在使用了“量子”之后，投手可以使用智能化创建工具，进行程序化创建广告，极大的提升了投放效率，我们后续统计下来，它大概可以节省三分之二的人力成本。

第二，投手也可以利用智能监控与数据分析能力，以数据为驱动、以数据结论为依据对广告做策略调控，统计下来可以提升近5%的利润率。

投手在使用“量子”的智能创建工具与实时调控工具后，程序会根据投手的配置实时对有潜力的广告进行调控，可以快速的发现一些流量机会，在保证利润的前提下，整体的广告消耗可以增长30%左右。

接下讲一讲我们37手游对数据能力的理解，我们将整个数据能力抽象成4个层次，首先最上层的能力是数据的可视化以及应用能力，这也是用户最直接能感受到的能力，是将数据分析的结果以利于沟通的方式进行可视化展示，呈现数据背后的一些逻辑与价值，这样业务人员能够更有效的去根据我们的数据沟通应用。在37手游，我们这一层的能力对应的是刚刚提到的“量子”“天机”“雅典娜”这类的数据应用系统。

往下一级是数据分析与建模能力，这一层说的是能够运用各种分析工具与挖掘工具进行数据探索、建模以及预测，从而发现数据中隐藏的规律以及一些趋势，提供合理的数据决策支撑，我们只有具备这一层级的能力，才能够支持上层的数据应用能力。在37手游，这一层能力对应的是比如我们的数据中台、一些模型构建、怎么规范数据开发平台、任务调度等都构建在这一层。

再往下一级是数据质量的保证能力，这个能力是保证我们整个数据分析以及数据应用的可信性与有效度，只有我们提供的数据是准确的、是具有可信度的，才能够真正的发挥数据的价值，否则不仅无法发挥数据价值，还会给使用者提供错误的支撑带来更大的损失。这一层能力对应的是我们37手游的技术组件，比如技术开发平台，数据存储平台、计算引擎、调度、监控系统等。

最后也是最基础的能力是数据安全与隐私保障能力，能够保护数据的安全与隐私，确保数据的完整性与可靠性，这是我们整个数据能力中最底层的能力，因为我们的基础设施都上云了，所以这一层我们主要依托云平台能力支撑构建，比如最基础的一些资源管控、网络的管控等等。其中，数据安全、数据质量的能力，也是37手游中数据治理最重要的一部分。

接下来说一下我们37手游在数据治理方面的实践，首先说一下我们37手游数据治理的理念，主要分为4个方面，第一个是数据安全合规，数据安全是企业的生命线，我们作为一家互联网企业，数据已经成为我们企业中最重要的组成，比如客户信息、研发的成果、商业经历等，一旦这些数据被泄露将会给企业带来极大的损失，也可以说数据安全是我们企业发展的基石，所以我们需要采取一些的措施来保证数据安全，比如我们的数据会加密，完善我们的网络确保其是安全的，还有一些我们内部的控制，一些数据权限等。

第二块是数据质量，这是我们开发人员的生命线，数据开发人员必须要保证数据的准确性与完整性等，只有这样企业才能基于业务人员去作出正确的判断，所以我们需要采取一些的措施保证数据质量，比如建立数据质量评估体系，加强数据管理等。

第三块是存储治理，进入大数据时代，随着数据规模的不断增加，我们的数据存储成本也在不断攀升，所以我们也需要对存储做相应的一些处理工作，比如规范存储策略、优化存储体系等，来减少数据冗余提高存储利用率，从而实现降本增效的效果。

最后一款是计算治理，同样现在是数据时代，我们的业务对于数据的依赖与要求也在不断增加，他们有更多的想法更多的需求，而我们的开发人员为了满足业务需求，有时候为了开发效率会采用低效的开发手段，导致出现大量的计算任务，这些低效的计算任务不断的在消耗计算资源，所以我们也要对计算任务做一些治理工作，包括规范计算资源的使用，优化计算资源的配置，加强对计算任务的监控与管理等，督促开发人员提高整体的计算效率。

下面我们先从数据质量说起，讲一讲37手游在这方面的一些经验，首先我们先盘点一下常见的数据质量问题有哪些，这里举了几个例子也是真实案例，比如投手突然发现他配置的广告计划突然之间被程序关停了，但是投手发现广告的实际ROI效果很好，后来排查发现是因为转化数据延迟太高，程序计算ROI时计算错误，导致程序异常关停了这个计划，其实这就是一个典型的数据延迟导致的问题。

又比如经常会有运营人员找我们数据开发人员说数据有问题，为什么纯新用户日报表的ROI、付费的ARPU与游戏大盘的ARPU对不上，后来发现，这两个指标在命名上一致，但在计算口径上有很大的差别，这其实给业务人员使用时带来混乱。

第三个例子是，我们的监控系统突然发现某一个渠道的游戏包，广告归因成功率大幅降低，后来排查发现，是因为这个游戏包上报的IDFA出现了很多异常值导致归因失败率上升，这就是因为数据源、数据上游导致的数据质量问题。

提到了这么数据质量问题，那么我们如何评估一个数据质量是好是坏，其实业界很早就有一套评估数据质量的标准，通常有以下4个方面，一个是准确性，说的是数据是否准确、是否反映真实的情况，这也是一个最基础的要求，比如我们要构建一个电商系统，它的商品价格、库存数量等数据必须是准确的、精确的才能反映真实的数据情况。

第二块是数据的完整性，数据是否完整、是否包含必要的信息，比如订单信息一定要包含订单的名称，订单的单价以及订单的总金额等。

第三块是数据一致性，这说的是同一份数据在不同的系统、不同的地方表现的是否一致，不能说同样一份数据在不同的页面、不同的系统出现偏差，这样也是不行的。

最后就是数据的及时性，也就是说我们的数据是否有延迟，我们系统展示的数据是否是最新的，能否反映最新的情况，业界比较统一的数据质量标准，不仅仅可以评估现有的数据质量，用这些标准也可以指导数据开发过程中，怎样去控制数据质量，一些准则。

像我们大数据项目的开发项目一般都比较长，比如我们需要做数据采集、数据清洗加工、建模数据处理，再到最后数据的实时应用，其中任何一个环节出错都会导致数据质量问题。

我们能不能将数据质量问题原因进行归纳，这是我们归纳出一些常见的原因。比如第一个是数据源端的问题，我们的数据采集端有时候会缺乏标准，没有数据质量管控，导致我们的输入数据不一致和异常，比如我们上游的业务流程变更、上游的数据格式发生变化，但是我们数据采集没有进行必要的监测，势必会导致后续的数据处理流程出现问题，或者是出现我们的计算结果是不真实的，最终导致我们输出错误的结论，这也是常见的数据质量原因。

第二个比较常见的原因是，我们在数据处理过程中的一些问题，比如这当中，一般开发人员都会有相关的测试流程，但是有可能因为业务变更，或者说开发人员写的SQL不规范，导致的一些数据问题。举个例子，一个应用的枚举值只有1或2，如果是非1比如Tab不等于1，那就代表我想要的结果是等于2，但如果后面业务变更，更多的枚举值，这种写法就会有问题，如果后面做3或4这样的枚举值，这种写法就会出错、从而导致数据不准确，这也是比较常见引起数据质量的原因。

第三块就是数据口径的问题，因为不同的部门和业务人员对相同的指标定义是不同的，比如同样是大R用户，平台月推广可能对大R的定义不一样，但命名确是一样的，这可能导致其他部门的业务人员使用过程中数据混乱。

还有数据延迟导致的问题，这个很容易理解，比如前面说到的“量子”系统会实时计算广告投放的消耗和广告投放转化的数据，实时计算广告计划的投产出比，如果数据产生延迟，这个计算就不准确会对投手产生极大的影响，投手没有办法准确判断广告计划的实际效果。

最后一块也是大家容易忽略的一块，主要是数据维护过程中，会产生一些数据质量问题，引起的原因是没有按照规范修数导致的一些数据隐患，可能会导致更多的潜在风险爆发。

那么，我们37手游是怎样去解决这些数据问题？下面就简单说一些我们解决这些问题的心得。

首先，我们认为数据质量问题不仅仅是一个技术问题，它是一个长期管理过程，因为我们的数据处理流程一般是比较长的，我们只是数据的加工方并不是数据的生产方，我们的数据通常会跨越不同的团队与业务部门，这使得我们像确保数据的准确性更难，我们不单单要对自身做管控，还要跨团队跨部门协作才行，所以要想确保数据尽可能的准确，是需要建立统一的标准与流程，而且基本都是要跨部门协作，这里单纯靠我们自己是没法保证，我们只能要求我们自己，这就需要更一层管理者的支持，而且要将数据质量问题视为整个技术团队的责任，不单单是数据部的责任。

所以，37手游在解决这个问题的时候分了以下三个步骤，首先我们要制定整个部门、统一的数据质量标准，明确哪些问题是数据质量问题，哪些不是数据质量问题，可能是因为口径等其他问题导致，而且还要明确数据质量问题的归属，是归属于上游的业务部门还是上游的业务开发者，还是我们的开发人员。我们的数据质量考核也要纳入绩效考核内，这样才能形成一些强有力的约束。

在指定标准后，就是全面推广和应用这些标准，并且要将数据质量纳入到考核中，将责任的归属讲清楚。最后就是，通过明确标准流程，我们要提高数据开发组以及整个组织对数据质量的关注度，并形成数据质量管理体系与长效机制。

下面是我们37手游设计与实施的管理体系，最右边的是质量规范与考核标准，其中质量规范包含质量标准与监控规范，质量标准主要是衡量哪些是数据质量问题，以及明确了数据质量问题的严重程度、责任归属，比如我们的数据质量是不是直接导致了经济损失、经济损失规模，我们通过相应的量化来定级数据质量的等级，以及责任归属到底归属哪一方。

数据质量的监控规范是，我们要明确不同等级的数据资产应该配置怎样的监控规则，更加完善的数据质量监控，才能降低数据质量问题的潜在风险，考核标准主要就包括告警数量以及故障数量，像告警我们一般也分为一般告警与严重告警。我们的考核标准还明确了这些告警数量与故障数量对绩效考核的具体影响。整个数据质量管理体系，建立在数据平台、数据加工链路之上的一系列流程标准与措施，最终的目的是确保我们的数据能达到标准性、完整性、及时性以及一致性。

上面说了我们37手游的数据管理体系，我们可以看出针对整个数据质量流程是比较长的，而且我们的存量数据是海量的数据，所以我们不可能对所有的数据都一视同仁，我们必须有所倾向，否则就算投入更大的资源与精力，我们也是事倍功半，所以我们需要区分数据的重要程度，有些数据很重要，一旦出错可能会引起重大的资产损失，向这种数据我们视为A1最高级别的数据，比如客户的明细数据、财务的一些纪录等等，这些级别的数据需要最高级别的保护与管理措施，比如数据加密、一些更细节更详细的访问控制策略，还有数据备份等等。

还有些数据用户我们业务效果评估和一些重要的决策，像这种数据我们记录为A2，比如我们广告效果投放的表，这种数据一旦出错，会给业务方带来一些错误的决策，从而导致一些直接的经济损失。

再往下一级的数据，虽然也是直接引用在某条业务线上，但是这些数据只是给应用方做提效用的，如果出现问题带来的业务影响也不会太大，这种我们标记为A3。比如客户部门、销售部门的绩效排行榜等等，即使出现问题我们也能很快的修复，出现问题也不会带来太大的影响。

最后一级的应用主要运用于日常简单的数据分析，它们往往不直接用户业务，出现问题时带来的问题也比较小，像这种我们就定为A4，比如一些不常用的报表数据等。

我们在确定了这些数据指标的资产等级后，我们根据数据血缘就能推断出相应数据表的资产等级，为我们后续数据质量的管理以及后面要做的存储治理提供依据。

下面是我们根据数据质量数据资产的等级制定的监控规范，前面已经提到了数据质量管理体系使用的监控规范是核心位置，从这张表里能看出，我们不同级别的表所要求的监控规范也是不一样的，比如ODS A1层的监控规范，必须要求数据量规则的监控、主键规则的监控、离散值与业务规则的监控，但对于A3级别的表，我们只需要有基础的数量监控与主键监控。

不同的储藏级别要求也不一样，比如DW层的A1级别与ODS的A1级别多了一个汇总值的规则，因为要做同级计算。

我们对于一些监控规则也进行了一些分类，主要是为了方便我们去指定监控的规范，比如将常用的监控类型区分为5种类型，简单的就比如数据量规则、主键规则、离散值、汇总值的规则，还有一个是业务规则，我们还总结了每种监控下的使用场景以及场景的监控规则，比如针对数据量规则，我们基本要求一天所有任务的写入表都必须配入数据了规则，数据量规则能够确保我们一条数据量任务是正常执行的，举个理解，我们行数的波动率以及当天新增的表行数必须大于0，一旦配置这些数据量规则的话，能确保数据正常写入这些表单，一旦出现空跑或者数据没有写入，那么就会出现告警。

这里重点说一下业务规则，前面提到的数据量我们认为它是技术型规则，主要监控任务是否被正确的触发、是否正确的运行起来，但其实这远远还不够，有时候任务是被正常的调起运行，但是由于SQL写的不规范、或者是上游发生业务变化，它并不会得到真正的计算结果，这个时候就需要我们的业务规则来上场。

比如我们有一个任务是计算玩家的玩新值，这个值是根据用户的充值金额与一定的计算公式得来，这样我们就可有配置一个多表关联的监控，这个监控规则是判断我们当天分发下去的所有玩新值与所有的新增充值金额，在大盘上是不是符合我们的计算公式，如果符合就说明没有出现问题，一旦不符合肯定就说明有问题，要么是上游出现问题， 要么是计算结果出现问题。

所以在实际的实施过程中，我们发现越丰富的业务规则、监控规则，能够避免很多潜在的数据质量问题，所以我们也将这个业务监控规则的覆盖率，作为评估某个业务线数据质量是否完善的重要评估因素。

下面举例了一些我们常见的监控规则，比如我们针对单列最基础的不可为空，像充值表的支付类型这个字段不能为空，又比如说常见的语法约束，邮箱格式、手机号格式等，还有跨表即跨列的对象规则，比如某个字段和其他字段有一些潜在的关联因素，有可能是一些计算公式，这也是我们比较常用的业务规则。

最后说一下我们在数据质量方面的工具建设，上面提到了很多规范与数据监控规则，这些规则我们需要一些天网系统支撑，简单说一下我们天网的执行流程。

天网系统主要分两部分，一部分是天网的后台系统部分，包括规则的录入与解析，这部分数据部署在AWS的EC2上，数据存储在RDS和Elastic Cache上。

第二部分是天网的计算引擎部分，我们使用的是AWS的EMR，基于此，我们可以很容易启动基于YARN的监控任务，这个任务也是一个分布式计算任务，而且我们可以选择按实际使用量进行收费，这样我们可以根据需求随时停止任务，避免资源的浪费。

整个流程是，开发者会根据上面的规范，在天网系统上录入数据质量监控规范，具体的规则经过天网解析后存储在RDS上，配置完后相关的ETL调用任务会在执行前检测ETL任务管理表是否配有任务，如果配有任务天网就会触发这个任务并且提交到YARN上去执行，而YARN则部署在EMR之上，监控任务执行完成后返回一个是否出现问题，如果有问题，而且ETL任务配的是强依赖，那么会阻断ETL执行，同时我们的天网也会发出告警以及通知数据开发人员，让他解决数据质量问题。

接下来说我们的存储治理，在说这部分之前简单的说一下37手游的存储现状已经为什么要做存储治理。

37手游的存储现状可以总结为3点，我们的存量数据、PB级别的存储量，而且我们从2013年到现在有近万张数据表，我们现在的业务规模是比较大的我们每天有TB级的新增数据量。

为什么要进行存储治理，主要的原因是随着时间的增长，数据量不断的累计上升，如果我们不对存储管理，所有数据存在一起，就会导致存储器容量变得异常大，有些查询并不需要查询历史数据，但是数据放在一起会显著降低查询效率，所以我们存储治理的核心目的就是识别与清理无用的数据，同时我们还要针对不同数据的查询特点指定合适的存储数列，优化存储资源的使用效率，最终降低存储成本的效果。

下面说一下37手游在实践过程中发现的一些难点，最大的一个难点其实就是开发人员的成本意识薄弱，在数据开发过程中，有的数据开发人员会遇到一些比较紧急的需求，开发人员往往为了开发速度选择了一些快速开发但不一定是最佳的方案。

比如一些ETL任务明明可以采取增样拉取的方式，但开发人员为了简单开发就选择了全样拉取的方式，又比如某些数据，应用方只用看最近3个月的数据就可以，但是我们开发人员不想去做更多的工作，比如没有进行定事清理，导致大量无用的数据被存储下来。

第二个难点是数据关系非常复杂，我们近万张表，其中表和表的关系异常复杂，很难搞清楚之间的关联关系，还有需求的时效性到底是怎样的，因为关系复杂所以导致我们很难对表做分级管理。

最后一块就是缺乏明确的存储管理标准，我们开发人员往往凭借着个人经验或凭感觉来制定数据表，而且不同的开发人员他的开发标准也不同，势必会带来一些混乱。

我们37手游在存储治理上总结出的一些理念，就是数据生命周期管理，即在数据的各个阶段进行管理，主要分为3个方面，第一我们首先要确定数据的资产等级，也就是确定数据表的等级，然后根据我们的数据等级来分配相应的存储分级策略，最后就是沟通建设，榜单管理、定期巡查等，督促开发人员能够长期稳定的按照规范执行。

这里说的数据资产等级其实前面已经提到过了，核心思路是根据我们数据指标的等级，通过数据血缘来确定表的资产等级，然后可以通过表的资产等级确定他相应的存储策略。

这是存储治理比较核心的一块，即如何制定数据存储的分级策略。这部分的核心思想是根据数据的重要性与使用频率这些因素，将数据分为不同层次的存储，进而选择不同的存储方式，一些常见的存储策略，比如周期性删除等等。

对于重要且历史数据不可恢复的数据，我们可能会采用永久存储、定期备份的存储策略，比如订单的数据可能比较重要而且需要回看历史状态，所以我们不仅需要永久存储，而且还要定期、每天做备份。对于使用低频，但需要保持历史的数据可以选择冷存储，比如登录日志，对着这类数据我们可以采取分级存储冷热分离的方式，对近30天数据热存储，久远的数据冷存储。而对一次性需求的数据或者临时中间表可以采取用完即删的策略。

在这里提一下，我们用AWS S3的智能分层能够快速实现存储策略的自动优化，相当于是对我们做了一些存储优化的工作，S3的智能分层是一种优化存储成本的功能，它可以将数据根据访问频率与访问时间的不同自动的分层到不同的存储类型中，从而可以最大程度降低我们的存储成本。比如S3提供了多种存储类型，如标准存储，这也是我们最常用的存储，但这种存储的成本相对较高，我们可以对高频访问的数据标准层，对于低频访问可以使用S3的Infrequent存储类型，它的存储成本比标准存储更低，但访问数量高一些，最后对于几乎不需要访问但需要长期保存的数据可以使用Glacier，它的存储成本最低，但访问成本会高一点，应为要将数据提前恢复后才可以访问。

我们在实践中使用S3智能分层，它能够替我们根据访问频率与访问时间去自动分配不同的存储类型从而降低成本，我们只需要制定好一些标准即可。

这里举个例子，日志数据经过S3这种存储策略优化。我们首先会写到S3中，它的智能监控访问模式就会自动将30天内未被访问的数据应用到不频繁访问层中，这样我们就可以节省接近40%的存储空间，而且在连续90天后未访问的话，这个时候S3会将对象移动到归档访问层，这样又可以节省68%的存储成本，而且访问性能也不会受影响，因为如果数据访问了不频繁访问层，S3就会自动将这些数据移回到频繁访问层，我们的产品性能没有受影响但我们的存储成本降低了很多。当然，最终超过了一定的时间，我们也会将这些历史数据进行删除，一些数据超过一年的话我们也会进行删除，进一步降低成本。

有了这样的分级策略后，我们的数仓也按照相应的规范制定数仓的存储策略。比如ODS层，它是外部数据，有些数据是不可恢复的，所以我们要选择长期保留的策略，答案对于数仓加工层比如DWD，因为我们ODS层已经长线保留了，所以我们合理选择了按需保留。

对于DWS层，因为我们DWS是共享层，很难区分哪些数据是短期哪些是长期，所以DWS层也是我们数据加工之后保留的计算结果，所以需要长期保留下来。而对于ADS层，有些业务不需要太久远的数据，而且随着业务的变更，我们的ADS层更新换代很快，所以这里也是按需保留。

最后说一下存储治理的管理手段，对于数据治理来说，它不单单是一个一次性治理工作，它是一个需要我们长期坚持做的事情，这是我们就需要一些管理措施及流程去保证我们在治理过程中长期坚持下去，所以我们也会在数据治理过程中制定相应的管理手段，主要分三块。

一个就是转向治理，当我们的存储系统使用达到一定程度后，这个数据就需要通过相互管理的模式，集中力量制定一些合理的目标，集中资源开展一次治理工作，当然我们也不能全靠专项治理，我们也会有一些定期巡查的机制，每个月或每个季度会定期的巡检，检查我们的资源是否合理，存储策略是否规范。最后在日常开发过程中，我们也制定一些使用资源TopN榜单，这也是一种比较直观的观察方式，我们日常开发中，开发人员也会去观察这个表，看一下谁有一些异常 情况出现，比如没那么重要的业务使用的存储量最近攀升的比较快，可能说明使用的存储有不合理的，需要人工核查一下。

最后说一下游戏出海面临的新挑战，就是数据安全合规。

数据安全合规在我们37手游主要有一下几个方面，数据访问控制、数据加密以及数据合规检测。因为我们37手游也要在海外发行游戏，意味着数据在不同的国家与地区都需要在当地遵守数据安全合规政策，所以我们在数据合规监测这块十分重视。

这里提一下AWS比较好的服务WAF，因为它可以过滤大量的恶意流量，很好的地狱DDoS攻击，还有就是可以利用AWS的IAM身份验证服务来去与我们的数据访问控制系统做结合，替我们做一些数据访问服务。还有一些数据加密服务，比如KMS它的密钥管理服务能够帮助我们更好的控制我们访问的加密密钥。

这里给大家提一下，我们作为游戏出海的发行商，各个国家与地区的政府普遍加强了在数据安全与隐私合规方面的法律监管与执法力度，更严格的监管体系，也意味着游戏出海或者企业出海都要针对当地的法律法规制定不同的合规策略，包括网络、存储方面的法律法规，所以在实践过程中，我们使用AWS，亚马逊云作为一个覆盖全球用户的云服务厂商，本身就拥有很多云自身安全的合规政策，我们使用AWS后，也为我们游戏出海的合规政策扫除了一些障碍，因为AWS本身就有一些法律法规文献的安全认证。

最后说一下我们37手游未来在数据治理方面的展望，主要分两块。一块是最近比较火的AIGC，我们其实在探索AIGC，比如我们在探索使用AWS的CodeWhisperer，根据自然语言生成SQL，并尝试将这些SQL应用于自动化的报表以及更深层次的自动化分析等场景。还有就是利用AWS的CodeGuru进行一些安全扫描的功能，它会探索发现利用CodeGuru发现难以检测的漏洞、扫描我们现在的代码以及开发人员编写的代码来寻找潜在的漏洞。

第二方面就是，我们借助AWS完善的监控工具，进一步完善我们的数据质量管理体系，协助我们实现业务洞察、神话运营管理工具使用，优化资源使用配比，提升数据治理的效率。

我今天的分享到此结束，谢谢大家。