常见问题现象：RAM子账号运行主账号创建实验报异常：Access Denied - Authorization Failed [4002], You don't exist in project XXXXX.由于PAI的工作空间与DataWorks的工作空间在底层是打通的，DataWorks中的开发角色，拥有MaxCompute数据开发相关权限。因此操作主账号创建的实验需要将RAM用户添加MaxCompute开发角色。详情请参考文档：云产品依赖与授权：Designer1.为子账号授予MaxCompute开发角色过程简单演示操作流程主账号登录PAI控制台在左侧导航栏，单击工作空间列表，然后在工作空间列表页面，单击目标工作空间的名称。在工作空间详情页面，单击工作空间成员后面的编辑，即可进入成员管理面板。在成员管理面板，单击添加成员。在添加成员对话框，将相应子账号添加MaxCompute开发角色。单击确定具体操作流程可参考官网文档：管理成员主账号登录PAI控制台，工作空间列表单击目标工作空间的名称进行编辑在工作空间为相应账号添加MaxCompute开发角色登录子账号再次运行主账号创建的实验更多参考云产品依赖与授权：Designer管理成员

　　DataWorks安全模型　　DataWorks提供多人协同数据开发工作的平台，其安全模型需要考虑几方面：　　企业之间数据的安全隔离。　　数据开发即ETL过程中的安全问题，如生产任务如何保障不可随意变更;如哪个成员可以进行代码编辑调试，哪个成员可以进行发布生产任务等。　　由于底层MaxCompute有自己的安全模型，项目成员做ETL过程肯定会需要MaxCompute的各种资源(table、Resource、function、instance)的相关权限。　　针对第一点，DataWorks的用户认证，DataWorks对接RAM，云账号可作为主账号进行开通并创建DataWorks项目，而项目成员必须为该主账号的RAM子账号不能是其他云账号。　　另外，同个主账号创建的项目作为一个组织，项目与项目之间的任务可以进行依赖配置;不同主账号创建的项目之间数据(各种任务)隔离。　　针对第二点，DataWorks通过业务划分“开发项目”、“生产项目”进行任务开发调试和稳定生产的隔离;通过成员角色控制哪个成员可以进行任务开发调试，哪个成员可以运维生产任务等。　　针对第三点，DataWorks在MaxCompute Project创建成功的同时，在MaxCompute Project里对应DataWorks的角色创建role，并给不同role赋权。

DataWorks数据治理中心在2022年7月5日全面开放使用，提供为期1个月的限时体验，2022年8月5日后，所有能力将在DataWorks企业版中提供。DataWorks企业版开通>>DataWorks企业版除了数据治理中心，还有数据安全、开放平台等众多功能：数据治理中心新能力解读>>DataWorks数据治理中心通过治理健康分量化评估，有效推动治理问题解决。治理健康分由存储、计算、开发、质量和安全五个维度构成，可自动发现和预防各类数据治理问题。在成本治理方面，数据治理中心提供任务资源消耗明细、资源消耗整体趋势、单任务费用预估等丰富功能，可帮助您对各类资源使用费用进行有效的优化控制。详情请参考帮助文档>>目前在如下区域支持数据治理中心功能，欢迎体验使用，您可以通过下方地址，快速跳转至对应区域数据治理中心首页：华东二（上海）用户，点击此处开始使用。华东一（杭州）用户，点击此处开始使用。华北二（北京）用户，点击此处开始使用。华南一（深圳）用户，点击此处开始使用。西南一（成都）用户，点击此处开始使用。新加坡用户，点击此处开始使用。美国（硅谷）用户，点击此处开始使用。

读书的时候，语文老师总会让同学看看作者的生平简介，谈谈作者为什么会写出这篇文章，文章诞生的背景是什么背景，一方面是让同学理解文章，另外一方面是让同学感同身受。鄙人，不是大厂，也不算外包，算是靠在阿里系的一家创业公司的交付部门的小小大数据工程师，心比天高，命比纸薄。当然，也和上学没有好好学习有关系，怨不得其他人。回到正题，咋们先从我的个人经历聊一下大数据工程师现在面临的困境和我的一些解决思路。数据的不整齐什么是数据的不整齐，这是我自己定义的一个概念，将不符合数据质量以及元数据模糊的数据定义为不整齐的数据。当我刚开始工作的时候，需要抽出数据用quickbi做一个bi看板，整体的逻辑相对来说很简单，根据商品名称的维度，日周月的维度划分出不同粒度的销售金额，退款金额等数据。听起来很容易，可到了正式实践的时候，发现问题来了。数据提供方根本没有办法提供需要的数据，就说商品金额和商品名称，没有对应的商品信息维表，订单中存储的商品名称会根据活动的不同增加不同的前缀，商品的金额也会因为优惠的波动而波动，不要说算roi，就按百分比算个成本价，一个商品可以出四五个不同的成本价，更不要说还有0的数据。当时我和其他同事拟定，选取订单中价格最小，但不是0的数据作为商品本身的价格，暂时将bi做了出来，不过真的有人在用吗？至于元数据的模糊，这个问题是大数据绕不开的问题，就单说订单表中商品数量一个字段，这里的商品数量指的是一个订单的购买的总的商品数量，还是一个订单下一个商品的购买数量？最近在看一本叫dama数据管理的书，里面有一大章专门讲元数据治理，感觉要想解决这个问题，必须是公司内有一个领导可以拍板说做数据治理，才能解决这个问题，不然越往后，治理难度会更大。也可能是我目前接触过的业务仅仅是零售行业，感觉行业内的数据有点一拍脑门的感觉，金额数据中写“按照第一季度金额走”，字段写的是coupon_id，注释里面写的是项目id，前者看到的时候除了暂时用rlike匹配正则把数据清除掉，只能跟产品反映，产品再跟对接人反映，对接人再跟业务反映；后者更是找不到对应的负责人，只能自己看数据确定关联关系。这就引出了新的问题-业务还是数据？业务的刁难业务是永远的痛。数据本身是没有价值的，这句话在零售行业一点也没有出错，零售的大数据想创造价值，那必须是和业务紧密对接，而我目前处理的需求，也基本上都是业务的需求。可业务需要什么样的数据呢？业务本身知道，但是他们不会主动将自己的想法说出来，而是需要技术来揣摩，接触的久了，就不会发现不了，如果不是有了固定模板的数据，业务需要的数据其实只是看起来正常的数据。比如，我去年关注小程序的用户是一千万，那明年关注小程序的用户是十万，这数据肯定就不对，这个时候就需要技术来查，是不是计算逻辑出了问题，最后查到是不是源数据里面没有数据。这个故事听起来还算靠谱，但有时候需求真的过分不合理，开发一张大屏，临近尾声，节点都已经从开发提交到生产，忽然提出质疑，这里的数据不对，一查，是数据源是刚上线不久，之前的数据都是线下数据。但也不可否认，业务确实在督促技术进步。技术的进步从业务督促我进步的例子举几个，首先我接触的数据基本都在dataworks，而业务很多时候都需要抽出超过一万条的数据，我去之前，其他同事都是导出到oss，再从oss下载，可为了偷懒，当然也是在官方文档看多了，我用idea配置conf，就可以在idea搭建一个maxcomputer studio，直接下载数据，避免二次导出。再比如，有一张表里面的数据，如果有两个不同的维度，而这两个维度还互不相干，应该如何分组呢？写两个sql吗？或者抽明细数据在数据集等看板里面再聚合？也是在那个时候，我学会了cube，roullup和grouping up，简单的sql处理就可以实现复杂的逻辑。业务发现问题会来和产品唠嗑，产品又会找我唠嗑，为了提前他们发现问题，学会使用dataworks的强弱规则，真的没有话说，每天早上起来看一眼短信就可以，尤其是针对递增的数据，同周期的波动率让我更快一步。当然，还有的需求，需要将错误数据抽离出来，dataworks自己带的python节点，利用opds配合钉钉机器人，每天将错误信息打包成markdown格式报给业务。技术的局限不知道有没有人看到这里，如果看了上面，不难发现，我的每天工作似乎都在dataworks上，我承认这上面的东西很多，数据集成，离线开发，实时开发，hologres，function studio，数不清的好东西，可权限就那么多，我甚至连hologres的权限都没有。每天做的更多的是odps离线的开发，最开始还好，技术的成长很快，但几个月后，sql的基本能力就到了瓶颈期，没有大的项目，很难再有突破。最让我难受的是，一次和业务沟通，业务忽然问我，为什么用trino，而不是使用implama，我感觉自己如果再这么下去，很可能真的一辈子是个sqlboy，三十岁前可能就得找个零售行业干业务了。我不能接受这样的我，那应该怎么学习呢？自我的进步首先是发掘目前使用的工具的潜能，就拿dataworks来说，进不去function studio，我就进idea，在idea开发自定义函数，从最简单的udf到后面的udtf和udaf，再到mapreduce。传统的sql写腻歪了，那我就尝试sql组件节点，尝试赋值节点和分支节点。再就是学习阿里的训练营和定期的活动，都说人需要好的反馈来刺激自己继续努力，没有比这些小活动更好的激励方式，而且千万不要认为学习的东西是没有用的，触类旁通的道理武侠小说里面都有写。就拿我最近正在看的polardb，polardbx和polardb for postgre的课程来说，我从里面看到了数据库ap查询和tp查询的区别，理解大数据的存储大多都以列存储是为了更好的压缩和查询，掌握了docker的部分知识，自己去思考数据库和大数据的本质区别。干活可能没有那么多，但是希望诸君共勉。

大家好，很高兴在开发者社区中分享自己对于ESC阿里云服务器的使用体验，我是一名数据科学与大数据专业的大三学生，在暑假学习过程中由于专业需要影响，我想要学习关于大数据数仓理论并进行项目实践。在此学习过程中我发现自身机器已经无法满足项目运行的需求，但是重新购买电脑对于我来说花费有点过于庞大且性价比不高。在此基础上我开始寻求解决方案。在B站浏览过程中，我了解到了“飞天加速计划·高校学生在家实践“这个活动，我意识到可以把项目在云服务器上运行，我开始了解关于ESC的使用。 ESC可以根据自身的项目需求自定义选择的配置，并且部署过程简单，软件与系统镜像丰富，主要在网页中点点就可以部署好一台主机，这对之前的我减轻了不少工作量，之前在组件电脑虚拟机配置系统和集群下载软件是我最痛苦的事情，有时候一个粗心就要重新安装。在飞天加速计划中中我试用领取了一台ESC，和购买了两天服务器进行尝试试用。ESC可以根据自己的需求包年包月或选择按量收费，其他两个两台我采用按量收费的方式短时间试用一些。对于我，首先利用xshell远程连接的方式进行操作，下载jdk，配置免密登录这些等等。在这过程中也有一些问题，我发现不同地区的云服务器只能试用公网IP进行通信，而同一地区，私网、公网都可以。但整体过程还是比较轻松愉快的。在此过程中我也对于阿里云其他一些大数据组件进行了解，阿里云对于传统的大数据框架进行了开发与优化。例如阿里云中的datahub功能就类似于大数据框架中的kafka，RDS就像我们平时使用的mysql，还有maxcomputer、dataworks这些与传统大数据框架的相似，但是它们在基础功能的上也有着自己的特点，我只能说在使用上功能有一定的类似而已。在过程中我更加体会到了云服务器的好处，对于自身机器来说24小时运行有点困难也是很消耗内存的，而云服务器的运行是24小时不停的，这让我们部署项目的一些定时任务显得更加便捷，而且其特点让我们部署网站显得十分轻松，这也是我在这段时间的体验之一。 经过这段时间的了解与应用，我发现阿里云拥有非常丰富与强大的组件与生态系统，这段时间仅仅是将初略试了一下，还有很多地方不会，在后面还需要继续学习，在后面ECS的学习中将会继续运用，在将来面对工作也会优先选择阿里云。

加入DataWorks钉钉交流群，获取技术支持，收看产品最新直播与最佳实践，答疑时间：工作日9:00-18:00，优先在群内@机器人非工作时间请提工单。

日志报错异常信息：TFJob dlc1qvkyrnwcpbxz is failed because 1 Worker replica(s) failed1.问题复现过程简单演示操作流程DataWorks数据准备1.Dataworks中创建数据表SQL脚本create table if not exists bank_datapython ( age BIGINT comment '年龄', job STRING comment '工作类型', marital STRING comment '婚否', education STRING comment '教育程度', credit STRING comment '是否有信用卡', housing STRING comment '是否有房贷' ); show tables; INSERT into table bank_datapython values (18,"支持","否","高中","否","有"); select * from bank_datapython;配置读数据表组件配置Python脚本V2组件main.pyimport os import argparse import json """ Python V2 组件示例代码 """ # 当前工作空间下的默认MaxCompute执行环境，包含MaxComputeProject的名称以及Endpoint. # 需要当前的工作空间下有MaxCompute项目时，作业的执行环境才会注入。 # 示例: {"endpoint": "http://service.cn.maxcompute.aliyun-inc.com/api", "odpsProject": "lq_test_mc_project"} ENV_JOB_MAX_COMPUTE_EXECUTION = "JOB_MAX_COMPUTE_EXECUTION" def init_odps(): """初始化一个ODPS实例，用于读写MaxCompute数据. 具体API请参考PyODPS的文档: https://pyodps.readthedocs.io/ """ from odps import ODPS # 当前工作空间的默认MaxCompute项目信息. mc_execution = json.loads(os.environ[ENV_JOB_MAX_COMPUTE_EXECUTION]) o = ODPS( access_id="XXXXXXXXX", secret_access_key="XXXXXXXXX", # 请根据Project所在的Region选择: https://help.aliyun.com/document_detail/34951.html endpoint=mc_execution["http://service.cn-shanghai.maxcompute.aliyun.com/api"], project=mc_execution["anPythonTest"], ) return o def parse_odps_url(table_uri): """解析输入的MaxCompute Table URI 需要打开的MaxCompute表名，格式为odps://${your_projectname}/tables/${table_name}/${pt_1}/${pt_2}/ 示例：odps://test/tables/iris/pa=1/pb=1，其中pa=1/pb=1是一个多级partition。 Returns: 返回三元组(ProjectName, TableName, Partition) """ from urllib import parse parsed = parse.urlparse(table_uri) project_name = parsed.hostname r = parsed.path.split("/", 2) table_name = r[2] if len(r) > 3: partition = r[3] else: partition = None return project_name, table_name, partition def parse_args(): """解析给到脚本的arguments.""" parser = argparse.ArgumentParser(description="PythonV2 component script example.") # 从上游连线输入当前组件端口的输入，会通过arguments的方式传递给到执行的脚本 # 1. 组件输入 # - OSS的输入: # 来自上游组件的OSS输入，会被挂载到脚本执行的节点上， 然后挂载后的文件路径，会arguments的形式，传递给到运行的脚本。 # 例如 "python main.py --input1 /ml/input/data/input1 " # - MaxComputeTable的输入: # MaxComputeTable的输入不支持挂载，对应的Table信息会以URI的形式，作为arguments传递给到运行脚本 # 例如 "python main.py --input1 odps://some-project-name/tables/table # 对于ODPS URI形式输入，可以用示例的parse_odps_url函数解析出对应的元信息。 parser.add_argument("--input1", type=str, default=None, help="Component input port 1.") parser.add_argument("--input2", type=str, default=None, help="Component input port 2.") parser.add_argument("--input3", type=str, default=None, help="Component input port 3.") parser.add_argument("--input4", type=str, default=None, help="Component input port 4.") # 组件输出 # - OSS输出 # 组件的输出端口1和输出端口2是两个OSS输出端口，可以用于下游的使用OSS路径作为输入的组件。 # 配置组件输出任务输出路径，对应的输出目录会被挂载到 /ml/output/ 下。 # 组件的输出端口 "OSS输出-1"和"OSS输出-2"，分别对应子目录/ml/output/output1 和 ml/output/output2。 # - MaxComputeTable的输出 # 组件的输出端口3和输出端口4是MaxComputeTable输出. # 如果当前的工作空间配置了MaxComputeProject项目，则组件传递一个临时表URI给到脚本。 # 例如 python main.py --output3 odps://<some-project-name>/tables/<output-table-name> # 用户的代码可以构建对应的表，写出数据到对应表，然后通过组件连线将表传递给到下游组件。 parser.add_argument("--output1", type=str, default=None, help="Output OSS port 1.") parser.add_argument("--output2", type=str, default=None, help="Output OSS port 2.") parser.add_argument("--output3", type=str, default=None, help="Output MaxComputeTable 1.") parser.add_argument("--output4", type=str, default=None, help="Output MaxComputeTable 2.") args, _ = parser.parse_known_args() return args def write_table_example(args): """示例：复制将PAI提供公共表的数据，作为当前组件的临时表输出: 更多PyODPS请参考PyODPS文档: https://pyodps.readthedocs.io/ """ output_table_uri = args.output3 o = init_odps() project_name, table_name, partition = parse_odps_url(output_table_uri) o.run_sql(f"create table {project_name}.{table_name} as select * from pai_online_project.heart_disease_prediction;") def write_output1(args): """将数据结果写入Mount的OSS路径上(output1子目录)，对应的结果可以通过连线传递到下游""" output_path = args.output1 os.makedirs(output_path, exist_ok=True) p = os.path.join(output_path, "result.text") with open(p, "w") as f: f.write("TestAccuracy=0.88") if __name__ == "__main__": args = parse_args() print("Input1={}".format(args.input1)) print("Output1={}".format(args.output1)) # write_table_example(args) # write_output1(args)运行测试2.问题临时解决方案这个一般是配置了相同的OSS Path （代码和任务输出路径）导致的bug，可以将代码和任务输出路径配置成不一样的临时性解决。代码和任务输出路径配置为两个不同路径再次运行测试更多参考Python脚本V2

导读：本次分享题目为淘系数据模型治理，主要介绍过去一年淘系数据治理工作的一些总结。具体将围绕以下4部分展开模型背景&问题2问题分析3治理方案4未来规划▌模型背景&问题1.整体情况首先介绍一下淘系的整体数据背景。淘系的数据中台成立至今已有7年左右，一直未作数据治理，整体数据生成构成比为：人工创建（22%）+机器生成78%。其中活跃数据占比：9%，不规范数据占比：21%。数据活跃以倒三角形状分布，整体分布比例为ads:dws:dwd:dim=8:2:1:1，分布还算合理。上图中下半部分是模型的生命周期，增长和留存情况。淘系的业务还属于快速变化中，模型变化比较快。模型生命周期为25个月，模型年增长比例30%，模型留存44%。2.公共层公共层两大核心问题为：首先，公共层表复用性不高。在2014年的时候公共层还比较规范，但可持续性不强。随着时间流逝，业务增长和变化，复用性就逐年降低。因为大部分的数据是应用层做的，他们会开发自己的公共层，复用性降低，大部分都是无效表。另外，公共数据表在各个团队分布不合理。这是由于数据团队多，为了满足业务开发效率，每个团队都有自己的公共表，容易出现公共表复用占比低，重复建设的场景。其中淘宝数据团队负责最多的公共数据表。3.应用层分析应用层的主要问题包括：第一，公共层建设不足或公共层透出不足。随着时间增长，公共层的指标不能满足ads层的业务需要，ads复用指标逻辑没有下层，引用cdm层的ads表占比逐年降低，引用ads的ads表占比逐年增高。第二，较多的ads表共性逻辑未下沉，统计显示超过17.63%ads表被下游ads复用。第三，跨集市依赖严重，统计显示，整体跨集市依赖占比为30%，特别是大进口和淘宝数据跨集市依赖达到了40%，影响模型的稳定性，影响了模型的下线、修改。▌问题分析1.问题汇总以上这副图是简化后的数据模型，我们可以发现存在很多不规范问题影响了模型的稳定性。业务在快速发展的情况下，为了快速响应业务需求，产生模型问题是必然的。日常工作中，数据研发流程大致如下，接到业务需求，直接引用ODS层表开发ADS数据，待数据需要复用的时候就把逻辑沉淀到公共层，同理指标也会有类似情况。主要问题可以归纳为七点：系统临时表多，只增不删，对于消费侧影响较大，因为表量巨大，有效比例低，很难检索到；命名不规范；公共层过度设计；ADS重复建设；ADS跨集市依赖；ADS共性未下沉；ADS穿透依赖ODS。2.原因分析从问题分类上看，主要有三大类问题：规范性问题，公共层复用性问题和应用层复用性问题。从问题原因上看，主要有四大类原因：架构规范，流程机制，产品工具，以及研发能力。3.模型治理的问题模型治理的挑战：业务价值不明显，治理带来的是长期价值，短期对业务影响不大。治理协作复杂，治理需要ODS、CDM、ADS层多人多团队协作问题治理难根治，容易出现新模型依赖有问题模型模型平均生命周期不长（25个月）综上所述，模型治理的ROI比较低，我们的问题就是如何模型治理才最高效？▌治理方案1.整体方案基于以上的问题原因分析，我们制定了如下治理方案。核心策略为以下三点：1：盘点存量，掌握数据的整体情况2：规范增量，避免新增模型走老路，重复出现相同问题，考虑到数据的生命周期，历史数据可以先不管。3：日常治理保健康，以数据化驱动长期治理2.机制规范架构分层标准往年我们关注的是数据视角，今年关注的是业务视角，业务视角核心诉求主要有四点，交付效率、产出时效、质量可靠、成本可控。过去OneData定义了每一层的作用，但每个层次的分工定位不清晰，针对这些问题重新做了清晰的定义。应用层核心是专注支持业务，需要考虑研发效率、交付数据口径一致性和稳定性。通过集市规范来控制复杂度，通过轻度聚合的中间层确保口径统一，通过扁平化设计确保稳定。公共层的核心是抽象复用来提升效率，需要考虑易用性和稳定性。通过规范和冗余宽表提升复用性，通过解耦来确保稳定性。ODS层的核心是合规高效，需要考虑接入效率和性能稳定。通过工具化提升效率、优化治理确保性能的稳定。特别是在数据达到一定量之后要考虑采用merge的方式接入数据。集市划分规范数据集市，是用来满足特定部门或者用户的需求，按照多维的方式进行存储。通过对相似数据业务场景内聚进行抽象分类，以降低ADS层重复建设和数据管理复杂度，让应用研发更聚焦更高效。集市划分的原则有以下两点：原则一：以业务场景或者服务对象作为划分原则，对相似数据业务场景内聚抽象进行分类。原则二：集市划分需要统一标准，尽量符合MECE原则。公共层共建机制在建设公共层的建设过程中，我们通常会遇到以下两个痛点：应用研发的痛点：公共层相应效率低。公共层研发的痛点：如果统一承接开发工作，涉及的业务很广泛，研发资源不足。为了解决以上两个痛点，我们通过以下核心原则来解决：原则一：公共层开放共建，事后审计治理应用开发整理需求，把需要下沉的公共维度提给公共层研发，公共开发需求评估。原则二：以应用需求驱动，设计开发共建 以需求为驱动，拆分出核心模型和非核心模型，核心模型公共研发负责，非核心模型由业务开发进行，共同开发以提高效率。原则三：公共层研发统一运维保障非核心模型上线并完成相关测试（准确性、确定性、治理）后转交给公共层研发，由公共层统一运维。3.智能建模在数据治理中有数据规范与共建机制依然是不够的，还需要结合自动化工具来提升效率、保障规范。我们是从以下4个方面入手的（详情可以体验DataWorks的产品）：数据体系目录结构化模型设计线上化打通研发流程（自动化生成简代码）对接地图数据专辑数据目录体系结构化形成数据体系目录有利于了解掌握数据，分门别类的方式降低了大家的使用成本。首先要对表命名做一些管控，我们做了可视化的表命名检测器，来确保规范性。另外，淘系不是一个单空间的数据体系，因此要解决跨多个空间的复杂数据体系的统一建模问题。模型设计线上化改变模型设计方式，由线下设计迁移到线上，通过一些自动化工具，提升效率，保证规范。打通研发流程（自动化生成简代码）模型迁移到线上后，打通研发流程自动生成简代码，生成代码框架，建表语句，显著提高了研发效率。对接地图数据专辑形成相应的地图数据专辑，方便其他用户使用数据。4.模型治理打分模型模型治理需要量化，如果没有量化全靠专家经验效率是非常低的，我们通过模型的指标形成到表级别的模型分。通过多维度对模型进行打分。打分机制精细化的打分机制，针对团队、数据域、核心进行打分，形成相应的标签。整体流程以数据驱动，上图左边，以模型评估数据为出发点，通过各个维度对模型进行评估，得到各个域、各个团队的评分，形成相应的问题标签。以产品驱动，上图右边，通过专家经验判断新上线模型升级搜索权限、下线模型降权限，让业务迅速感知数据变化，引导业务。▌未来规划应用层效率在整个数据体系中，应用层的数据体量是最大的，投入了大量的人力。OneData缺少对应用层的数据建设指导，集市高度耦合，给运维效率带来了不少问题，如跨集市依赖、依赖深度的问题。过去都是以业务为主导，为了保障研发效率放弃了部分研发规范，以后要完善应用层的研发规范，同时通过工具做好研发效率与规范的平衡。架构规范管控基于分层标准落地，对研发过程规范完善，包括对设计、开发、运维、变更、治理等规范进行细化。目前核心是表命名规范，对依赖规范、代码规范、运维规范等管控能力尚不足。产品工具提效将继续与Dataworks共建。应用层智能建模能力还不能满足研发效率要求，因此会继续功能提效；数据测试功能集成；数据运维功能升级；事中数据治理能力构建（开发助手）；事后治理能力提效（批量删除、主动推送优化等)；数据地图，找数用数提效。▌问答环节1：核心公共层的建设是自顶向下还是自底向上？ 采用的是两者相结合的方式。以需求为驱动，没有需求就会导致过渡设计，在应用层有复用之后再下沉到公共层，这是自顶向下的。 在公共层设计阶段是面向业务过程的，这时是自底向上的。2：多BU公共层是否需要统一规范？怎么去做？怎么量化价值？需要做统一的规范，规范利于数据流通，才能体现数据价值 。但是具体怎么规范需要具体去看，如电商、本地生活，业务和目标不一样，很难做到统一的规范。3：怎么判断指标需要下沉到公共层？公共层的开发是需要成本的，是否需要下沉到公共层核心是看是否需要复用，可以从两个方面入手。专家经验判断：如电商交易环节数据，这类数据是核心数据，是要建设到公共层的。事后判断：如玩法之类的业务稳定性不强，那一开始不需要下沉到公共层，避免过度设计，事后再去判断是否需要下沉。4：关于表、字段的命名规范，是否需要先定义好词根再开发？需要分开看。对于公共层设计到的业务过程是有限的，对于公共部分要先定义好再开发。对于应用层，维度采用的是总建架构所以还需要先定义，对于指标特别是派生指标是多的，不建议先定义在开发。5：如何解决口径一致命名不一致，或者口径不一致或者命名一致的场景。模型是演变的。对于应用层，80%都是自定义的，第一次出现的时候都是不标准的，这部分如果采用先定义后开发的方式，效率是很低的，只有在下沉到公共层的时候才能够管控。对于公共层，能做的是保障核心指标90%的规范与定义统一，剩下的那部分也无法保证。 6：跨集市依赖下沉到公共层的必要性？短期来看，是没影响的，新增效率高。长期来会给数据的运维、治理带来很多影响，在数据下线、变更、治理过程中不得不考虑到下游依赖，会影响全流程的开发效率。

分享嘉宾：吴荣彬 分贝通 大数据部负责人导读：本文将介绍分贝通在大数据领域的一些建设经验。分贝通在ToB领域是一个年轻的公司，成立六年多，大数据体系刚刚建立一年多，整个团队不到二十人，整体的大数据建设处于初级和摸索的阶段。本次将总结在大数据业务上的实践和思考，希望给大家带来启发。主要内容包括以下几方面：公司介绍大数据建设背景大数据建设方案大数据应用场景 ▌公司介绍先简单介绍一下分贝通。我们平常公司中可能会遇到这种场景，比如出差时通过公司OA或邮件进行审批，然后去订机票、火车票、酒店等，到了目的地之后很多费用还要自己垫付，回来再通过发票报销，发票数量多且金额大，时间耗费多；同时对公司而言，因为要对接很多外部平台，对企业和员工而言都是非常麻烦的。分贝通致力于解决企业这方面的痛点，除了差旅这部分大的支出，我们也希望在所有的支出管理场景提供整体解决方案，实现企业在预算、审批、交易、报销的全流程闭环。对员工而言，所有支出都在一个平台，可以不用垫资和发票，使用非常便捷。对企业而言，可以做到事前预算管理，事中费用控制，事后自动报销，极大的减轻了财务和行政的工作量。前提是分贝通需要提前去对接不同的供应商，比如酒店供应商、用车供应商等。在某些场景，分贝通还在建立自己的供应商体系，包括自营的酒店、自营的商城。经过六年多的发展，该模式得到了投资人和市场的认可，现在服务于数千家客户，业务增长迅速，融资的规模也比较可观，目前在企业服务领域算是独角兽的存在。 ▌大数据建设背景我们公司的大数据部门去年才成立，之前整个公司数据底层建设比较匮乏，所有数据都是通过业务研发团队去支撑，业务研发除了很多自己的产品功能迭代以外，还要排期去做数据支持。整体体验较差，一个业务上线需要一到两个月。这可能是所有ToB公司必经的一个阶段，ToB公司一开始的数据量可能不是特别大，不像ToC公司一开始就有自己的大数据团队，随着ToB公司的发展，数据量变大后，对大数据团队建设的需求是非常迫切的。   这是我们去年业务部门的需求，可以看到整个团队在底层数据方面的需求处于井喷的状态，未来可能有更多更细的需求。   对于一个ToB公司来说，基本上可以把客户旅程分为六个阶段：认知、教育、选择、支付、使用、增购。这是我们基于硅谷蓝图的SaaS获客模型优化后的划分，对整个国内ToB行业也有参考意义。认知：当我们想谈一个客户，首先要让客户了解分贝通。我们通过广告或者电销团队去做一个初步的接触，这个叫做认知。教育：当有一定需求，客户想起分贝通这个公司，会联系你做深度的交流和拜访，这时是深度教育的阶段，让客户了解我们能够解决他的什么问题。选择：通过多家的对比选择了分贝通。使用：交付使用。增购：发现有一些其他功能还不错增加购买，或者到了使用年限后继续购买。   分贝通整体可以归为三类部门，第一是业务部门，包括销售、渠道、市场、客户成功等；第二是运产部门，即运营+产品的业务研发部门，包括商城、商旅、费控、支付；第三是职能部门，包括产研、人力、财务。这三大部门对数据的需求不太一样，对各个阶段的需求也会有区别。业务部门对数据的需求是非常强烈的。其中一个场景是客户签约，客户购买了很多应用场景的模块，有些模块用得很好，有些模块用得很差，客户成功团队希望知道哪些应用场景重点在用，哪些开通了也不用，还有哪些用户在流失等等，这些都是对数据的需求。运产部门对数据的核心要求在整个业务过程中存在卡点，希望我们通过数据去告诉它。对于职能部门，产研关心的是产品上线后是否有人在用，用的怎样，是否能做ABtest。人力关心的是现在的员工关注的点是哪些，是薪酬还是福利。财务关注的是现在的财务报表，数据的准确性如何，跟流水是否对得上，需要很明确的被告知，以上这些都是公司对数据的需求，各种各样且非常强烈。        基于以上业务背景，我们需要选择合适的技术来满足业务的需求，从业务和技术两个角度来考虑。首先，从业务方面考虑，当时团队刚刚组建，人手比较匮乏，创业公司对人才的吸引力有限，因此我们的架构的应用成本要特别低，功能尽量简单，这样才能更多地进行业务思考和数据赋能。同时，由于业务已经发展到一定阶段了，对数据的需求已经比较迫切了，因此我们要快速的拿到结果。另外，从技术上考虑，原有技术数据已经上云，因此我们必须选择云端的解决方案，这样有利于数据的传输。同时，我们有很多的数据来源表，但是数据量还比较小，数据量在TB规模，对实时的要求没有那么高。在不考虑自建IDC的前提下，当时摆在我们面前有三个选择：第一个是比较成熟的云端的组建，阿里的MaxCompute+Hologres+实时计算Flink版+大数据开发治理平台DataWork，第二个是云上开源的组建EMR，第三个是什么都不用，在云上自建Hadoop集群。这三个方案各有优缺点，第一个方案的好处是应用成本嫁接给阿里云，但应用成本较高。第二个方案是比较折中的方案，有一定的灵活性，但是在运维上也需要一定的专业性。第三个方案需要招聘非常专业的应用团队来组建自己的Hadoop集群，这在当时来看不太可行。最后综合来看，我们选择了方案一。 ▌大数据建设方案技术架构选型结束后，我们开始从内部梳理大数据建设的整体体系，逐步进行大数据建设。与大多数大数据体系架构类似，底层是多源数据连接，往上做数据清洗，再往上进行离线和实时的数据存储与计算，到数据仓库的建设，再到上面的应用层的建设，左边是组织流程规范的一些保障。其中一些实践方面的细节和总结值得分享。比如数据分析，对于ToB的公司来说是很大的一个模块，这里的数据分析是指对外的数据分析，希望对现有的数据进行深入的分析。在组织架构上我们将数仓和数据分析分成两个团队，数仓团队负责整个ODS和DWD层的建设，数据分析团队负责上层的DWS层和ADS层的建设，这是横向的切分。这样做的好处是，数仓团队可以更好地关注底层数据的质量，需要更多地跟研发打交道，数据分析团队只需要对数据分析负责，而数据分析师可以更加关注整个数据的应用和业务的应用。这两个团队有着完全不一样的技能，而且可以互相监督。除此之外，实时和离线不分开的好处是对于大家的技术发展而言，技术栈比较完整。在流程和规范方面，我们当时面临的挑战是内部的业务线特别多，有十几个业务线，不仅多，并且复杂，比如用车业务线，与滴滴的业务线相似。每个业务线的表很多，每个业务之间又是独立开发的，规范需要统一，数据质量也有很大差异，是非常棘手的问题。但是同时我们也有先发优势——从零开始建设，所以我们当时确定一个原则，一定要边建设边治理而不是先建设后治理。我们摸索出了一套从业务需求到开发到上线的标准的动作，也就是所谓的SOP。比如将每周二、每周四作为固定的评审时间，评审的内容都是按照自己的内容自己的模板准备好，每次评审都有记录，上线的时候根据评审记录来看它是否完成是否需要修改，保证流程规范治理好。一件事情做到60分是很简单的，比如数仓的建立比较简单，但是要做到极致，真正做出一个好的数仓，90分的数仓其实是一件很难的事情。有了对于大数据整体体系的流程与思路以后，落地就需要工具的支持，下面介绍一下数据建模的工具。现在我们用的是阿里云的DataWorks智能数据建模，我们去年底参加了他们的公测，今年开始正式使用。DataWorks智能数据建模最大的好处是，我们会把整个数仓的规划和最终模型的产出做一个强关联，模型可以直接生成物理表，发布成功后也可以直接生成简单的ETL代码。之前我们在应用开发环境之前用SQL去建模，结果大家之间的标准不统一，就是一个人治的过程。有了DataWorks以后我们就变成了法治，通过工具实现了对整个数据的强治理，与原来相比，我们建模的便利性可能会差一些，比如想建一个数据汇总表，首先要建一个原始指标才能建立派生指标，然后搭建表模型，再关联数据标准，这个流程相对而言会变长，刚开始的时候大家会不太习惯。虽然单个点的流程变长，但是整体效率提升了，数仓团队都非常接受这种规范。对数据仓库的长期建设而言，一些标准与规范的事前投入是非常有必要的，往往可以起到事半功倍的效果。   上图是数仓整体架构。在技术架构方面，现在仍然是非常典型的一个lambda架构，离线与实时是分开的，结果在Hologres做了一层汇聚，有用到一些辅助的数据库如MySQL和ES来存储业务和标签的数据。这里有一些基于我们业务场景的使用建议，数据应用链Hologres与MaxCompute有离线实时一体化的能力，Hologres存在两种表存储的方法，一个是数据不导出，直接加载MaxCompute表作为外表，一个是数据导入Hologres成为内表。我们BI报表的业务场景是对外的，对我们来说是非常重要的，数据的稳定性是需要首要保证的，所以我们更多地采用Hologres内表方式去访问ODS的数据而不是外表方式，这样做的好处是一旦不小心将表的结果变更，如果是外表，BI工具只有在客户访问的时候才暴露出这种问题，但是采用内表的方式在推数的时候就会发现问题，就可以避免线下稳定性的问题。另外，我们每天都需要数据更新，我们不是每天都更新整个Hologres里面的表数据，因为这样效率会比较低，可能引起服务中断。我们的方案是建立一个临时的外表，生成临时的内表去替代线上表，这样速度是非常快的，因为整个Hologres做了线路的优化，效率非常高，直接去替代线上表，这样对线上几乎没有影响。   再来介绍一下算法方面的经验。先说一下Batch Mode的离线模型，我们目前使用的是阿里云的机器学习PAI来满足日常的建模场景，这个图是非常典型的数据流过程。首先样本经过实景化到ODS上面，在MaxCompute上进行清洗和加工，最后也会实景化到一些表，在模型训练阶段去开发、训练整个模型，训练完后有两种选择，一是不需要线上部署，只需要做一些离线的大表预测，可以通过Designer去做一些数据的部署数据湖到整个ODS的table里。第二是如果想做模型的线上服务，同样可以把模型输入到OSS层上面，通过EAS组件进行服务，这个是我们现在用的比较多的离线模型的数据流程。接下来是实时模型的流程，比如推荐等模型场景，对模型的实时性要求比较高。有一些比较通用的组件，比如Flink、kafka等进行数据的处理、特征的处理。模型的训练阶段先做一个模型的转化，离线的模型转化成实时的模型，然后进行训练评估，最后挂到线上去训练和替换，这里跟刚才的离线是不太一样的。 ▌ToB企业与ToC企业的技术选型区别分贝通是典型的ToB企业。ToB和ToC企业存在一些差异，可以从三个方面来了解。首先是用户群体，对于ToB来说，购买决策和使用性都是不一样的，买一个软件可能是财务的决策、KP的决策，但是员工在用。ToB企业的用户粘性更高，一般按年签约，公司已购买员工必须使用，同时对用户有很强的专业性要求，针对不同的企业、角色，整个系统的设计是完全不同的，甚至相同行业相同岗位的需求也是完全不同的。ToC的采购决策者是个人，用户不满意可以放弃使用，粘性相对较低，用户群体相对公众化，用户对软件的需求有非常多的共性。在应用场景方面，ToB的场景非常丰富，我们做的只能解决客户在生产过程当中某一个环节的问题，无法覆盖它所有方面的问题，因为专业性太强，一个问题的处理流程往往会很长，ToB在国内还没有千亿美金的互联网公司。ToC比较简单，满足大家日常生活中的需求，例如吃、穿、住、行、玩，很容易在这一领域诞生千亿美金的独角兽互联网公司，这决定了这两个企业的企业规模。在业务流程方面， ToB领域业务流程都很长，通常申请审批交易结算等等，一次交易涉及到很多环节，但是ToC相对简单，例如网购下单仅需几秒钟，非常简单。以上就是ToB和ToC企业的区别，也就决定了以下的技术特点，ToB的数据量相对较小，在做数字化转型的时候，包括我们自己，数据量还是TB级别，处于中小规模，但是业务相对复杂，对数仓的建模能力要求较高，需要了解业务后才能更好地去建模。整个作业的处理时间会比较短，我们现在的作业基本在分钟级别，因此我们的容错恢复很快，对于技术框架的选型要求会低一些，选错了后面还有翻盘的机会。但对于ToC来说，基础架构完全不一样，一旦选错了或版本需要升级，代价会非常高昂，这是在做数仓这两种模型的区别。未来展望，可以分为两个方面，一个是业务方面，希望可以识别公司更多的数字化转型场景，我们希望通过产品化和平台化更好地帮助公司去做业务化、智能化的事情；同时推进业务的BP机制，推动业务的紧密合作，数据中台也要深入到业务中去，去了解业务内在的东西而不是等着业务提需求；现在更多的是报表类的支撑，希望未来发展为报告、智能化产品的支撑；虽然分贝通是企业支付的场景，但更多的是差旅方面，差旅是很复杂的过程，比如说出一次差，要做很多的决策，我们希望探索更加智能的用户体验，降低决策成本。在技术层面，随着技术和数据的不断积累，对实时的数据要求越来越高，我们在实时与HTAP这块，会做一些深度的探索；现在的业务比较流行湖仓一体化，之前没有这种需求，现在我们需要管理语音、文本等大量数据，需要去解决非结构化数据储存和管理；第三是批流一体化，我们使用的是lambda架构，应用比较精简但是存在开发和运维上成本的重复，我们希望在这些方面继续探索来统一整个数仓，真正实现存储和数仓统一的架构，减少额外的成本，这将是我们未来探索的几个方向。 

　　PAI提供的服务：　　可视化建模和分布式训练PAI-Designer。　　Notebook交互式AI研发PAI-DSW(Data Science Workshop)。　　云原生AI基础平台PAI-DLC(Deep Learning Containers)。　　自动化建模PAI-AutoLearning。　　在线预测PAI-EAS(Elastic Algorithm Service)。　　PAI的优势：　　服务支持单独或组合使用。支持一站式机器学习，您只要准备好训练数据(存放到OSS或MaxCompute中)，所有建模工作(包括数据上传、数据预处理、特征工程、模型训练、模型评估和模型发布至离线或在线环境)都可以通过PAI实现。　　对接DataWorks，支持SQL、UDF、UDAF、MR等多种数据处理方式，灵活性高。　　生成训练模型的实验流程支持DataWorks周期性调度，且调度任务区分生产环境和开发环境，进而实现数据安全隔离。