讲师：晋银龙 浙江森马数仓高级经理
本次案例主要分享森马集团面对多年自建的多套数仓产品体系，通过阿里云MaxCompute+Hologres+DataWorks统一数仓平台，保障数据生产稳定性与数据质量，减少ETL链路及计算时间，每年数仓整体费用从300多万降到180万。
一、森马集团介绍
森马创立于1996年，产品及品牌定位于年轻、时尚、活力、高性价比的大众休闲服饰。2023年实现营业收入百亿+，旗下涵盖森马、巴拉主品牌以及涵盖时尚、运动、家居的领域的其他子品牌运营。森马在2010年实现第一个品牌上市，然后在2014年的创建了森马电商。2022-2023年开始做两个公司的融合，在这个过程中，其实也伴随着森马股份的一个大数据平台和电商的大数据平台的融合过程。 
二、数据上云探索
森马在数据分析和数据探索过程中，也经历了从最基本的基于开源自研的数仓到商用产品数仓的基本过程，最终我们选择的是阿里云MaxCompute+Hologres+DataWorks来构建我们的大数据平台。最早我们使用的是SQL Server来去实现做我们有三四千家门店的零售数据分析。后来就是在森马上市的时候，要做SAP项目，附带着赠送一个ERP之后去实现数据分析的套件，这个套件一直沿用到2015年。随着这个数据量，门店，品牌的增多，这个数据量就会变得庞大。当时我们数据变动的时候，从数据抽取到最终的数据展现，大概需要12个小时。所以我们在2015年的时候开始探索，是使用hadoop，还是用Spark，或者说使用商用的一些其他的MPP的数据库来去满足我们数据分析的需求。
在选型期间，基于当时森马的现状，我们整个数据的团队，大概只有在3到4个人。我们经过评估下来，当时的开源大数据对我们来讲，不管是技术转变的成本和最终数据运维的成本都会比较大。所以说在2015年的时候，其实是用的是SAP的HANA去实现在一定阶段下，一定数据量的分析。电商创建之后，因为电商部门倾向于现有的这些零售数据分析通过EMR这样开源的大数据平台去实现。2022年的时候，森马股份和集团开始做融合项目的时候，这时候我们有一个目标就是数据要上云，而且要用商用的平台。刚开始在选型的时候，内部有一种声音说，一定要用开源的云平台，可以用workflow加Spark，或者Hive，去实现数据仓库和数据服务的一个构建。但是在过在这个过程中，我们是踩了很多坑，在后面的章节里面会去介绍。
截止到2022年，森马股份的数仓的数据量已经达到了一个15T，大概有十多个品牌，二十几套数据库，数据都会流到一个数仓平台里面。电商我们在数仓下面做了很多数据集成表，来提升数据性能，里面大概有60T的数据。我们第一目标就是数据首先要上云，利用云上的分布式计算能力，来实现我们超大数据量的一个计算。数仓需要保证每天十点之后门店关闭，或者线上的一个零售结算回传到数据大数据平台之后，开始做ETL计算，最终要在早上七点，要把这个数据分发到分析库，保证第二天业务分析和报表查询。最早在森马股份层面去做大数据计算的时候，利用的是SAP的HANA，但是SAP HANA的一台服务器当时大概是在500万。在我们的IDC机房里面，大概有6台，总的内存数已经超过了大概20T，整体的成本非常的昂贵，对我们来说需要弹性的扩展来实现降本。
在选择大数据平台的时候，森马同样是经历了这种先在云上买云主机，然后自己搭一个HIVE, 在上面去使用Spark的计算能力，然后将数据的ADS层，或者说数仓的一些模型层，放到click house里面。在这个过程中，整个作业调度用的是airflow，在这整个链路的运维过程中，我们团队里面可能总共是3个人来支撑这一套体系的搭建，运维，还有数据报表需求的开发。实际上运用了这一套开源的大数据架构，面临很多问题。比如Clickhouse刚接进来的时候，有数据优化的问题，构建整个分布式的MPP数据库，如何搭建，ZooKeeper里面的队列又要超时了，或者产生了一些OOM的错误，几乎是每一周都会有。后来我们有一个方向要通过云上的Data Factory, 然后再加上Synapse来做整体的数仓架构。在整体的数据处理速度上面，或者说在那就是在提取的MSSQL的license费用上面。在我们项目实施的一个初期阶段，就评估下来费用后面会不可控。所以在最终在去年9月份的时候，由于森马电商这边和阿里云合作比较深，我们就开始尝试使用，MaxCompute+Hologres+DataWorks来构建。
三、森马旧版烟囱型数据架构
2022年到2023年，中间有一段时间非常痛苦的平台架构。数仓采取的基本上都是属于结构化的数据，包括我们的ERP系统，一些客流采集系统，主数据，一些线上的CRM系统。数仓平台有两套，森马股份建了一个，森马电商也建了一个。 第一条链路是把这些数据先同步到A云上，然后在A云上经过Spark处理程序去运行之后，生成的一个数据结果，然后把它推到CK的集群来做数据消费。
第二条链路基于以前伯俊的零售订单，因为之前用的是HANA数据库，数据同步到里面，然后去完成绿色部分的计算。把云上的一些订单，通过开源的组件，直接去抽取数据库，然后经过Spark的计算，处理完之后，再经过CK。CK里面有一个CK39，其实指的是给业务分析师专门独享的一个分析库。因为业务分析师一般情况下，会拿着python的代码，或者拿着一些他们自己的BI工具，比如Power BI或者Tableau，直接去连数据库来消费数据，这样的数据请求实际上是不可控的。所以说我们又独立了一台CK的查询库。HANA最主要承接了我们道讯和SAP两大系统，这个是我们从2015年遗留下来的一个数据资产。
第三条链路最右边是我们电商平台，电商平台从聚石塔里面将数据同步到阿里妈妈，这里面也用到了HIVE+Impala的技术。
这几条链路我们在做森马股份和电商的数据融合的时候，其实我们只是在两套数仓中间架了一个桥，然后中间是通过Oracle来实现数据交换，在服务层我们又是通过了CK、HANA、Hologres三套服务层来提供数据服务，最终分别来去承接了数字门店，还有森马的数据分析平台，包括商品分析、商品运营分析、直播分析，对接BI工具除了观远、帆软、SAP、还有一些我们自己开发的数据应用。
可以看到整条链路非常复杂，很容易有数据链路中断的问题，从最初的一个数据到最高的三个分析库里面，经历了三层，从我们电商的云平台，到EMR里面，然后再经过机房里面的Oracle, 然后再传给HANA，甚至有一部分还会传给A云上的一个数据仓库来做数据的处理。任何一个节点的报错，我们整条链路就会瘫痪，结果我们取了一个比较耗人力的办法，在Airflow上面和DataWorks上面配置了一个电话通知告警，一旦任何一个节点的链路报错，那就会打电话把人给叫起来。当然从我个人觉得这是一个比较傻的一个动作，但是面对这样子的状况下，这个也是没有办法的办法。这个就是我们在2022年做大数据平台融合之前的一个状态。
四、森马数据中台建设目标
总结一下刚才的那个架构图，可以很清晰地看得到我们的痛点真的很痛，用我们习惯的话来说就是数据孤岛，数据烟囱式。因为我们的组织在变，从第一个尝试开源的数仓，然后在搭建开源的数仓同时，要保证数据服务的延续性，然后保留HANA这一套链路体系，最后还有合并的电商数仓，就是基于OSS+EMR的一套数据仓库。3套数据仓库同时在运行提供服务，CK、HANA、Oracle、Hologres等四个不同的库，一共1200张表来提供数据服务。有一次那个老板也在问，为什么我们的数据仓库里面有1200多张表，我们有那么多要的分析需求？这个是我们的烟囱式建模所带来的一个必然，产生数据计算和存储的冗余。
针对这3套数仓，我们一边要运维，因为3套数仓属于不同的3个技术体系，Airflow的，CK的优化、HANA的、还有Spark开发的。每个人的技术背景，技术粘都是不一样的。虽然说从电商融合过来有一些同技术背景的伙伴，但是一个人只能负责一条线，一旦这一条线有问题，那我这个伙伴今天的工作可能就做不了，只能去做运维，而且只能依靠这一位同事来去处理。这个是对于数仓的管理和数据质量，以及提供服务的延续性来讲，是一个很大的一个风险。所以说我们一边在运维，一边在堵漏，一边我们还要支持新的一个数据需求的开发。
在基于各个平台上面所搭建出来的新老数据产品，都有数据透出，在这个数据流转合并处理的过程中，必然会出现一个数据打架的情况。虽然说大家底层通过繁琐的数据流程，可以让你用一套数据，但是大家在不同的技术背景和知识背景，还有一些需求接入的情况下，用的多套数仓的开发。带来的就是每一个数据产品上面的数据可能都不一样。有些指标，比如说线上算了一遍，线下也算了一遍，这个其实也分散了开发资源，重复计算带来了数据成本的增加。在这个过程中，针对于开源的系统主要是CK的集群，CK的集群通过Zookeeper来去实现异步的处理，这个过程中会出现的主要是异步写入，数据删不掉，一直往里面去写。有一天我们的数据翻很多倍，老板还以为真的做了这么多钱。实际过程中，有时候log分区满了，或者说Zookeeper的某个节点，某个作业写不进去，导致整个的一个队列卡住了。这样子的话，半夜好多电话，那一到周末，基本上没有一个完整的周末。数据链路冗长复杂，然后技术多元运维困难，如果说公司的团队不是那么的庞大的话，这条路会有很多坑。
针对这样的一个难题，我们在想怎么去解决。第一首要目标就是统一技术平台。大家不在一个统一技术平台，做深耕，做沉淀，做开发，这样子的情况就会一直持续下去。对于我们的KPI，保障数据服务的连续性，更是无从谈起。所以我们第一个任务就是要统一平台，让大家用同样的技术栈。然后在同样的一个技术平台下面，来完成整个数仓的业务模型、分析模型、数据服务的沉淀。
第二个我们的目标是一定要用商用平台，当然不是说开源平台不好，因为开源平台对于森马这种服装公司来讲，对做零售来讲，我们的第一要务不是去解决技术，第一要务是能够提供稳定有效的数据服务来支撑前端销售人员来去做准确的运营决策。如果出现了一些技术问题，我们当然会有一些内部技术专家在背后处理这些问题，但是这个时效性上来讲是得不到保障的。所以对于我们的体感来讲，一定要用商用的平台来得到及时有效的技术支持和保障。而且对于一些成熟的商用平台的运行稳定性，我们也会有更多的信心。这样对比开源平台，要省去很多一些繁杂的内容。
第三个我们也要考虑后面的一些发展，具备数据湖的功能，比如说数据集成存储管理，在数据集成里面，其实是要求具备、批的、实时的，结构化的，非结构化的，还有一些数据服务的接入。比如数据存储后怎么管理权限和安全性，会用到大数据平台里面数据存储管理的能力。以及构建数仓的时候，后面我们也会有一些标准化的要求，因为虽然说我们当前的数仓建设是我们基于自己的经验来建的，但是选这个平台 上还是需要有数据建模的套件来支持我们做数仓的标准化。再比如说对于数据质量，对于数据治理，或者对于数据服务，还有数据安全上的一个管控，后续我们都需要套件来支持。这个也是之前为什么要选商用大数据平台来实现的原因。如果森马需要，可以和我们的合作伙伴一起去沟通，使用这些套件，也免去了很多的开发的环节。
第四个就是数据处理能力的一个要求。这个其实基于商用的云平台大家的数据处理能力都差不多，最主要的还是对于弹性计算能力，我们现在的目标整个ETL链路从我们的2个OMS系统，以及8个品牌的道讯服务，然后通过清洗转换，整合到我们的数据仓库里面，最终分发到前置库里面，要求整个时间在7个小时以内，这是我们选型或者建设的一个目标，基于这些目标我们和阿里云的伙伴们一起去去沟通需求。
五、森马数据中台方案-MaxCompute+Hologres+DataWorks
最终我们选用了MaxCompute作为离线计算，加上Hologres作为OLAP分析平台，然后DataWorks作为统一的开发平台。其实最早我们的项目里面，只有批的，先通过全量或者增量抽到MaxCompute里面，存在ODS层，然后建立DWD的数据明细层，然后做一些数据的联合或者汇总，生成一些DWS层。最终整个分析模型和BI的需求都落在了ADS层，包括移动端的数据请求，万能工具的一些请求、扫码数据大屏的请求
这些应用请求都是由Hologres来提供服务，我们的Hologres是一主三从的架构，一个主要的Hologres实例来做数据的更新与写入，另外三个并行的执行库来做分析。为什么我们会需要采用Hologres这种一拖三的架构呢？因为在我们实际应用中，比如分析师的需求，区域运营管理的需求，门店运营的需求，重点运营的需求，他们所需要的数据量，查询的方式，需要的资源量，其实是不一样的，这种一主多从的架构不仅能保证大家在同一份数据上分析，保持数据的统一，同时能基于不同的部门的需求实现隔离，保证每种分析需求的隔离性，不会互相影响，而且每个部分还能保持弹性的扩展。未来我们还在规划让代理商接入我们的数据产品，提供数据赋能等等，通过Hologres我们计划将架构水平扩展到1主5从，1主6从的架构。这里面实施的时候也会遇到一些问题，不过阿里云对我们的支持还是比较到位的，很多问题在2小时内基本都能得到一个解决。在DataWorks这套数据平台上，实现了我们数据质量、数据保护伞、数据资产、运维监控等各种套件的需求。
六、森马数据中台建设过程
在阿里云这个统一平台上，我们都做了哪些事情。首先我们从15个系统里面抽取了1800多个表，进到ODS层，其实我们是先有STG层，先把数据存在一个临时表里，然后处理完之后，基本上只是做一个转存，转存之后会到正式的ODS表里面，这里面我们会做一些微小的改动，比如数据格式，可能有些格式上的一些调整，但是不会做一个个变动。数据源最主要的还是HANA里面的比如说SAP的财务、采购、库存这些数据，还有一些我线下各种EMR的业务系统。每个品牌1套，大概有十几套oracle数据库，分别是12C和19C的版本。
电商部分我们主要用的Mysql, CDM层支持了8个品牌的基础业务价值链的分析。包括从服装行业里面最开始的订货会，到下给SAP的采购订单，然后产生库存，由代理商一起发起采购合同，形成SAP的销售出库，配发到的门店库存，包括线上的各类电商平台，这样一整套全域的数据模型。在这个里面我们同时做了会员的模型，我们会把CRM的数据从达摩，易客等平台上抽取下来，形成一个会员数据模型。这些基础模型构成了森马CDM层数据业务价值链的底座。
基于这个底座，我们将订货、采购、批发、全域库存、全域零售、全域会员(CDP)六个基础模块做成了服务，包含历史的1500多张表，在做数据平移的时候，所有ADS层的数据最终数据来源于这六大表。只要控制了这六大表的数据质量，那么整体的数据质量在平移的时候是可以保证的。当然我们通过六大表还开发了500多个ADS表，满足了数字门店、万能工具等场景的数据需求。
七、森马数据中台建设成果
从2023年12月底到2024年2月初，其实也就大概2个月的时间，过完年阶段上线的，那上线之后，带来了哪些提升？上线之后，我们其实就有点如释重负的感觉了，周末可以过完整的周末了，几乎没有说因为平台技术所导致的，老板说今天的数据为什么又没有，因为一般情况下门店运营都是在周末看数据的。周末是服装零售行业大部分的销售产生的时间点，店长每天在上午10点或者12点，下午4点和6点，或者晚上9点的时候，他都会看一下今天的销售情况。如果这时候数据没有，立马各个门店的店长或者区域经理就会投诉过来。上线之后，基本上数据异常情况从每周发现，每周都有，到现在几乎是没有，每个月当然还有一些，但是那个是后续我们在数据开发管理可以更深入的一些地方，有些是因为开发的问题，导致ETL的异常，但是它不会影响我们的数据透出。
所以我们夜间的值班机制还在，我们后续的目标也是消除夜间值班的情况。当然带来的另外一个收益是ETL时间的缩短。ETL在我们原先三个数仓体系下，大概需要10个小时，其实不止10个小时，因为有一个关键的报网频率数据分析，它调用的资源量会比较大，可能要在11点到12点才能出来。我们要求整个链路从10个小时缩短到6个小时，使得团队能够在7点之前看到数据。因为还会有一个测试的团队来监控我们的数据产品，今天这个数据质量产出如何，如果ETL的数据有异常，那就会直接暴露在数据消费上面，直接产生投诉。
最后是基础资源的降本增效，从森马股份到电商的融合，只是算数仓部分，包含HANA（没有计算费用）、EMR、A云上的存储计算资源，大概有300多万，大概在今年8月底我们所有A云上数仓和大数据相关的资源都会释放掉，以及后续我们内部的一些迁移和扫尾工作，我们预计整体成本会降到180万甚至更低。
八、未来展望
关于未来的展望。首先基础的部分肯定是我们统一的技术平台，上云，然后大家统一技术栈，统一数仓的开发，合并归口，解决数据孤岛的问题。然后是梳理下我们数据产品线，刚才也看到了我们大概有5套BI产品，这些数据产品也需要梳理统一，这部分是我们今年已经做了的。那今年计划中的，第一个在技术上我们要探索实时计算，基于Flink的实时模型，在618的工作大屏里面上线，赋能业务决策。第二个，我们很多分析师具备python分析能力，甚至有些具备一些java或者SQL的开发能力。我们不希望他们再通过各个数据查询库来做处理，我们可能会提供一个数据开放的接口，让他们的代码进行整合之后，接到大数据平台里面去做数据处理，当然这个是我们还在规划验证阶段。第三块当前数据统一平台之后，我们会建两层服务。一层服务是基于业务价值链的查询服务，另外一层是数据分析体系所映射出来的数仓层分析模型，这些分析该怎么去用，它是在什么场景下使用数据，数据质量如何，这些主要的服务管控，主要的负责人是谁。我们想通过这样的一个数据服务来透给数据分析师，或者说透给代理商，让他们可以通过数据服务或者数据产品来查看数仓有什么样的数据资产，这些数据资产给可以带来什么样的一个帮助，来帮助我们去做数据分析。
另外一部分是数据质量，之前因为不同的开发体系，对于数据处理，或者是代码的开发质量可能不太一样。今年借助于数据平台项目，在基础模型层，我们已经实现了数据统一，数据质量已经得到了一个改善，但是各个产品里面可能还会有指标口径所带来数据不一致的问题。举一个售罄率的一个例子，对于森马股份来讲，对于品牌方来讲，售罄率是基于品牌的采销，但是对于客户，对于门店来讲，更多是用它的成交去计算售罄率。如果说我们在之前的构建过程中，因为有些是电商，有些是我们股份的分析体系，对这些指标了解不够透彻，很容易在查看数据，或者说在理解这个数据上产生偏差。所以说今年我有一个中控部门专门来输出森马的分析指标体系。这个指标体系包括数据模型、数据服务等等构建起来后，就会形成我们的数据资产。
产品上我们希望实现客户的赋能，当前所有代理商、分销，还是通过ERP来获取数据，但是他们在数据分析上的投入是有限的，更多的是总部能够给他们更多的门店运营或者业务运营上的指导。我们现在也在做一些爆品的运营策略，今年计划将建设出来的一些分析决策，通过数据服务的方式提供给数据产品，比如说导购，或者店长，在做补货的时候，在出现爆款的时候，或者门店遇到一些库存不足的困难的时候，我们数据决策服务，能够通过数据产品直接送达到业务运营的手中。
另外大数据平台上面都在讲大模型，AI怎么能够和数仓或者数据服务能够结合起来，通过这种对话问答的这种方式，能够带来更大的数据价值。这个我们也在探索，如果说我们的数据资产在今年能够逐步的建立和完善，那么我们就会和AI技术结合，看看能不能通过大模型做出一些成绩或者亮点。数仓的建设一定是不断沉淀的。因为业务发生变化，我们的数据分析风格，或者说场景也在发生变化，这些分析的场景和我们之前分析出来的一些沉淀，都属于数据知识，这些知识能不能以模型、指标的形式沉淀，形成森马业务分析的知识库，这会是一个漫长迭代的过程。数据产品上面，如果数据决策服务能够构建起来，那我们的数据产品就会更好地和终端业务融合，这个是我们大概2到3年的一个建设方向和想法。
下面是我们整体未来展望的技术架构图，是未来我们需要慢慢建设的目标，除了内部各种PLM、DRP、OMS、SAP、CRM等系统，后面会更多行业数据，包括未来的一些非结构化，或者半结构化或者视频。因为我们线下的门店，还有很多视频、音频类的数据，可以先把它存储起来，等大数据平台的建设完成之后，回过头再来挖掘一下。比如基于历史的三年，森马所有的客流量音频分析或者视频分析，能不能挖掘出一些知识来，所以针对于大数据平台后面我们会往数据湖的一种方向发展。
主要套件包括集成套件、存储管理、计算引擎、数据管理或者说安全管控这几个业务方面来管理数据库和对数据库做一些要求。前面数仓已经搭建起来了，数仓的知识沉淀还需要不断迭代，我们现在也在跟我们的分析师和业务运营选型BI, 最主要的目标还是说这个分析模型层到底沉淀在哪个。数据湖上面的计算能力，包括了离线计算和实时计算，目前还没有遇到什么问题，数据治理是今年我们的一个重头目标，包括对于数据源的一个业务价值链的模型，元数据构建，或者说分析模型的元数据构建，来形成数据资产。我们当前还在做主数据合并，之前的主数据也是有2-3套的主数据管理，每个品牌都在管理自己的主数据，但是上了后台，所有的主数据要有一个统一的主数据管理平台来去实现主数据的管理和分发，这是今年数据治理里面要做的一个内容。机器学习和AI, 过去我们一直也有在做基于规则模型下数据分析的探索。因为最近三年，我们集中在平台建设，等回过头就开始做机器学习和业务方面的深度探索和发掘数仓的知识能力。
最后还是想通过BI工具，数据服务等，不管是对接供应商的平台也好，或者说提供给上层的数据开发也好，可以有标准的API服务，提供给上游的数据消费者。基于整套数仓所构建起来的业务层，从商品企划到生产、采购、库存、订货、上市、分销，柔性的供应，库销分析，一些复杂的大概有七八十个指标合并评估促销情况，以及零售运营，线上的零售毛利情况，终端门店的运营，都会形成基础的数据分析底座。在这个基座上会有经营毛利、成本费用、库存周转、产品的生命周期、店铺的盈利及运营效率等门店360度的全维度分析。基于上面的这些分析，可以更多支撑运营层的战略规划或者经营企划，还有商品运营的集中补货、尾货处理，零售运营当前各个渠道不同平台的流量情况，毛利情况，运营健康度的分析。