企业最终的数据往往都隐藏在日志背后，如果从日志背后挖掘出有价值的信息，勾画出平台或网站的用户画像对精准化运营有着重要的帮助。阿里云技术专家祎休带来阿里在处理日志、构建数仓上的最佳实践分享。主要从数仓开发开始谈起，重点讲解了数据加工用户画像的五大步骤，最后进行了演示解析。
直播视频回顾请点击

以下是精彩视频内容整理：

数据融合加工-数仓开发

大数据仓库特殊引擎提供我们一站式的PB级大数据仓库解决方案，那么，我们如何基于MaxCompute去构建仓库，如何去帮数据进行清洗加工，然后去挖掘出有价值的信息？MaxCompute2.0推出了一些新功能，比如说非结构化数据的处理， MaxCompute支持非结构化数据存储在OSS上，以前的方式是通过数据集成工具或者自己去写一些任务，将这些数据周期性或者一次性同步到MaxCompute上来，既有开发成本，又有运维成本，在2.0里面我们支持直接创建外部表的方式连接数据源，直接对数据进行处理。

在数仓上的开发规范如图，从日志数据、用户基本信息数据等里面去挖掘出价值信息，然后涉及到数据开发人员做一些ETL的设计，包括我们的一些开发编码、设置，将任务提交到线上，在线上我们会遇到过去的一些数据运维工作，这些运维工作是不是可以在Dataworks里面去完成？下面我们一起来了解操作细节。

1. 需求分析

通常情况下会以一个这样的链路图去做用户画像，可以看到，用户画像通常情况下会包含两个部分，动态数据和静态数据。动态数据包括行为数据、页面行为、交易数据，比如说你的用户点击浏览数据等都可以放在动态的数据里面去，比如说在我们的网站整个的访问深度，是不是在页面上形成了时长有多少，在某一整个链路上注册开通再到数据开发的跳失率是多少等等；静态数据更多的是关于人的一些属性，比如说姓名、星座、年龄、长居地以及通常使用什么样的设备去访问我们的网站等等，所以有一些终端设备的偏好信息。

数仓创建

做数仓要进行数仓分层，底层是ODS层，通常情况下将原始的数据先采集到MaxCompute上来，对一些非结构化数据进行一定的结构化，包括一些数据的规范化， DWD层有我们的一些明细数据，我们要在这些数据之间能够产生一些价值，做一些数据清洁工作、数据交换工作，将数据进行打包，再向上我们要根据数据去做一些公共指标加工和应用指标加工，比如PVUV的访问、设备的访问等等。

2. 原始日志分析

原始数据可以通过这些字段里面去获得什么样的信息？一个日志信息里面，包含用户来访问网站或者平台IP地址、用户登录名，然后通过一些字段可以分析设备信息，比如说我们可以从用户真实的数据里面看到IP地址，包括什么时间去访问，访问了我们哪一个页面，使用了什么样的浏览器，浏览器内容是什么，有的直接用手机端等等，我们可以通过这些信息去挖掘出更多的信息，比如说可以通过IP地址知道用户长居住在哪个城市来访问我们网站，通过user_agent字段可以获取设备信息，因为我们去访问终端一些版本，设置可以通过这些数据进行一个结构化，然后把数据抽象处理。

用户信息表就是一张结构化的二维表，通常会包含一些用户的信息、性别、年龄、星座等等。

通过已有的这些数据，再去做用户画像时候可以看到，深色是已有数据，可以去刻画出用户在我们网站的浏览性，比如说整个网站的PVUV等等，通常访问哪个页面更高，然后在什么时候去访问。

3. 数据开发

接下来进入数据开发阶段，数据开发阶段要去实现如图逻辑，左边ods_log_info_d这张表存着我们的日志信息，我们要去公开一个结构，将用户IP地址解析出来一个一个地域信息。右边ods_log_info_d用户的基本信息已经是结构化了，这两个数据通过UID进行关联，JOIN成一张大表，原封未动的将我们的数据采集到MaxCompute上来，然后在DW层里面做更多的关联，关联出一张用户去访问我们广泛基本信息的宽表，然后基于这个宽表之上，我们有一个IP地址，要知道这个用户PV的具体数据，比如求平均值或者求在整个网站访问的最佳深度等。

在创建表的时候怎么更全面？我们发现，所有工作流任务、节点任务，包括我们的表，命名其实都有一个规则，如果你的数据量很大，通常情况下包含数据库的仓库分层、业务域、数据域和数据分析时间，这张表属于DW层，这张表刻划了一个用户的基本信息，这就表示这张表的数据是一天更新一次的，通过这样一张表可以明确知道刻划什么样的业务价值，让依赖于这张表的下游同学可以快速认识这张表的数据分析时间，描述什么样的信息。

另外,我们的IP去转地域信息，在公共云版本上面函数是没有对外开放的，所以需要去解决自定义的函数，但有一些函数不能满足配置，比如说大写转成小写，将IP转成region如何去做，通常情况下我们会去写一些Java去做这样的事情。将这些函数、资源包注册到MaxCompute上来，通过堆头注册上来，然后去对函数进行解析。

4. 最佳实践

我们强调每一个节点里面最多输出一张表，当你有多张表的时候，比如说任务失败了，可能是因为其中某一条处理的逻辑失败了，当你去重跑的时候，可能整个任务都要重新去跑，另外，你的输出表表格一定要跟你的节点名称一样，这样可以快速从你的输出运维上，快速找到这张表的数据在哪个节点上没有产生，是因为哪一些任务失败了。
大家都知道，大数据里面可能会有预测的insert overwrite，比如说测试数据任务时候会加数据库，通常情况下会造成数据重复和数据产生，如果你去使用灰色的overwrite，或者是每一次的任务重跑或失败之后，你要去手工再把这个任务调动起来，会根据你的分区表数据批量进行。这样最多的好处是每一张表数据的产生，比如说代码加一些注释，比如说整个SQL逻辑是处于什么样的，一定要在前面去进行相关的注释。
在操作过程中，大家尽量去减少Select*操作，因为你的计算成本比较高，在2.0里面我们已经打开了全表推出，用户去进行一个选表，上个月去拜访什么客户，通常情况下每个月在平台上消费3千多，在所有查看数据的时候，没有加分区的全表扫的计算成本很高，所以建议大家在去使用的过程中多加一个分区排检，可以减少我们的计算成本。

在公共云上，我们有一些公共云的服务，还有一些私有化服务，比如说安全行业、金融行业，通常都需要将大数据部署稳定，我们的项目创建的一个或者两个如何区分？通常情况下会有开发和生成，开发就交给数据开发团队去把数据任务开发好、调试好，然后发布到生产环境上去，生产环境上更新一些配置的调度信息，比如说按天、周、月等等去运维，对他的数据开发流程要求特别严，通常情况下有更多的事情发生，包的开发、测试，还有一些预发环境和生产，整个代码环境都会去详细的进行运维，你去创建的时候，可以在项目配置中去调试，比如说在开发项目里面，通常情况是不打开调度参数，就是说你创建的客户提交之后，不会每天自动去调度，当你把任务发布到生产的项目上面，根据你的配置更新每天去同步。

调度参数方面，比如说将数据如何去写到一个最新的分区，比如说分公司24号对应的分区里面，25是新的一些事情，如何去起到新对应25号的分区里面去，我们提供这样的参数，当你配置这样的系统参数时候，每次在我们调度系统的时候会自动进行切换，一些日期不需要你每次手动去创建分区。

5. 实验操作

通常情况下，我们先去创建所谓的三张表，每张表简单去适应如何分层，比方说第一层ODS层，第二层是DW层，从结构上面也可以看出来，每一个节点都是相当规则，当这张数据要同步到MaxCompute上，肯定是要建一个目标表，同样有一张表可以存储这张数据。然后创建工作流节点，接着创建自定义UDF，最后配置SQL节点和测试运行。

本文由云栖志愿小组毛鹤整理，编辑百见