168大数据

标题: 穆晨的数据方法论_v2.0 [打印本页]
作者: 168主编    时间: 2019-6-25 19:54
标题: 穆晨的数据方法论_v2.0
1.0到2.0
去年八月中旬，笔者在公众号发表了篇《穆晨的数据方法论_v1.0》，分享了些大数据工程的心得。当初标注为1.0，便是相信很快会有2.0。毕竟技术本身也是会变化的，要学会去拥抱它~^ ^。
随着大半年工作下来，穆晨的确又有了不少新体会，在此一并整理分享给大家。

一、技术边界需明确
—— just SQL？

在当前互联网场景下，数据技术与数据工程的根本目的是以Table+SQL+AI算法模拟业务运转与大脑分析过程，为数据消费者提供及时准确的信息输入。其中消费者既可是研发或运营人员，也可以是客户端、网站、APP等。
确切来说，数据技术将涉及到：
若缺乏以上技术而暴力SQL，则随着迭代数增多会出现很多问题：如数据表关系混乱不堪，维护成本暴增；如输出数据新颖度不够，变现能力堪忧；如数据生产耗费资源飙升，产出时间越来越慢；如开发工作串行开展，工作效率不高等等。
那么回到副标题：数据技术就是写写SQL么？答案显然是否定的。

二、架构模型要三思
—— modeling

很多时候我们会听到一个术语：建模。所谓建模，是指为理解事物而做的抽象表述。当事物较为复杂时，我们要做的更是不止一级抽象，而是多维度的体系化建模。
大数据工程中，笔者常用一种三层建模法：架构建模-域建模-数据建模，接下来分别进行讲解。
首先是架构建模，即根据业务诉求与现有研发组件设计系统架构。该环节需遵循三大原则：满足业务诉求、发挥工具优势、避免烟囱开发。举个例子，当某业务场景下的可用组件有算法与BI引擎时，可采用如下设计：
以下是各层职能介绍：
然后是域建模。传统域建模中，由于数仓定义为面向主题，故通常直接划分数据域。这样的弊端是要做多次维度抽象，在快迭代型业务中会显得笨重。笔者建议采取数据域+业务域两级划分，快迭代型业务用业务域->数据域，成熟型业务则采用数据域->业务域，如下图所示：
最后是数据建模，即设置Table来模拟大脑思考或实际业务逻辑。其中维度模型类似前者，常用于构建数据域；类E-R模型则有似后者，可用于支撑业务域。维度数仓相比规范化数仓能很快投入使用，符合竞争激烈的互联网领域，但这种方式在业务频繁变更时表现很一般。
在快迭代场景下，星型、雪花、星座等维度模型由于仍要开发维度事实表，因此显得笨重。笔者常用一种逆规范化的类E-R建模，改面向主题为面向业务，将Table划分为枚举表、实体表、事件表、关系表......，同时增加时间戳和有效标签以解决维度变化问题。
以上便是架构模型的“三思”。而当模型设计好后，还有个很关键问题：“好”的标准是什么，如何评估？这里笔者建议从以下几方面着手：
架构模型设计好，就可以启动研发工作了。但也许你也曾听过这么一句话——“我们淹没于数据的海洋，却饱受知识的饥渴”。

  三、智能优化是亮点
—— knowledge

AI为数据赋能的过程，即为数据向知识升华的过程。如果说数据是精确描述事实，那当今火热的智能学习技术则对应另外两类问题：解释过去和预测未来。
从算法工程角度出发，数仓之上可架构算法引擎，进而支持商品推荐、智能定价、潜客圈人等业务场景，对应上节引擎层；从数据工程角度出发，算法引擎产出的数据可并入数据资产，对应上节资产层。听着似乎有点绕......下面分享个具体案例：线下商户画像。
首先YY业务场景——“某家大型连锁实体型商户，希望深入洞察每家分店情况，从而制定精细化营销策略。已知消费者大都已安装某款移动支付APP，它能自动上报用户交易与位置等信息。”
接着进行域划分，可将画像初步划分为基础域、流量域、交易域和经营域。对于基础标签与离线标签，可直接汇总APP上报数据。对于动态标签，则需接入在线计算引擎并考虑是否提升输入粒度，以精度换速度。对于算法标签——潜客群与显客群标签，下面分别来介绍。
潜客群标签，即最倾向进店消费的客群画像，可从社会影响力、购买力、购买偏好等方面描述。本方案预先接入第三方数据源，对全量用户打标，构建出用户标签库；然后采用智能学习算法对用户购买行为进行预测，将预测为真的客群中比例最多的用户标签记为店铺潜客群标签。
然而单单分析潜客效果并不好。举个栗子，若商家将分店开至香港，潜客画像很可能显示主流用户来自广东，而这并无任何参考价值，因为大家都知道香港地区广东游客最多。因此要通过所在地区或行业等大盘情况对结果逆向平滑，这也是引入“显客”概念的原因。
显客群标签计算可借鉴NLP关键词提取技术，将店铺显客群标签对应为文本关键词；将店铺所在地区对应为语料训练库。可用的关键词提取算法有很多，如tf-idf便可直接拿来计算标签显著度，详情见下图。店铺所有的标签显著度计算完毕后，取topN标签为其显客群标签。
至此还有两个潜在问题。其一，可能有的店铺很火，占了所在地区绝大部分交易，导致自身无显著标签；其二，新开店铺或新推广APP的店铺交易数据量小，无法用于计算idf值。对于前者可采取均衡采样，后者则可用潜客引擎为这类店铺“补”上部分交易用户。
以算法研究的角度回看本案例，笔者认为优化深度学习潜客引擎，以及引入多方数据源展开迁移学习会有较高探索价值，因此后续还会单独拟文分享。此外画像质量评估、画像业务建模也是很有趣的话题，本文因篇幅所限就不一一展开了。
本节最后，再来谈谈复用的话题。细心读者可能已经发现，潜客模型在本案例中用到了两次，用户标签库也会被多次到。因此可以将这两部分一同并入数据资产，进一步提升数仓的复用指数。


四、质量工程不能少
—— quality

“道路千万条，安全第一条”——数据研发也同样如此，保障数据质量是所有工作的最高约束。通常来说，质量问题又可分为狭义与广义两种，其中前者专指数据内容正确无脏数据，后者则还包括数据按时产出、存储健康、计算健康等方面。

狭义质量问题通常是由于业务系统或数据生产环节出现脏数据所致。其中，系统问题需系统人员承担，同时数据人员设好门禁，杜绝“病从口入”；加工问题则需数据人员落实好“代码告警->代码复查->规则监控->监测节点->定期巡检”等一系列数据保障工作。
广义质量问题的溯源则相对复杂得多，比如产出延迟原因可能是输入数据暴增，可能是平台资源不足，也可能是代码不规范导致的数据倾斜。对于此类问题，当前大都是通过读取元仓或解析日志获取各类元信息，再以平台化的形式呈现给数据工程师自行诊断。
上述为质量问题的发现与治理。此外预防也是一种很有效的手段，笔者建议编制并维护一份数据模型与编码规范，在所有开发人员之间形成共识。


  五、研发流程多并发
—— process

可以看出数据研发包含好些步骤，而到具体落地环节涉及的事务就更多了。以项目管理角度看，整个大数据工程将会由许许多多工作流节点构成，这也给项目管理工作带来了不小的挑战。
首先是要明确工作集内容。常见工作节点包含需求评审、架构设计、数据/算法建模、数据/算法开发、数据/模型线下测试、数据/模型发布、数据初始化/模型训练、数据回流、线上测试、质量工程、项目复盘等等。
然后是各工作节点的并发问题。显然算法与数据部分工作可并发开展，不同层级的编码工作亦可同步启动，即先将代码与测试代码开发完，这样一旦源数据就绪便可以开始自测了。
特别建议采用专业项目管理软件，或起码用甘特图来管理项目。这样做的一个好处是项目复盘时有据可依，而更重要的是将来若要启动类似项目，存档文件将具有很高的参考价值。


  六、团队协作有门道
—— cooperation

写到这突然想起个老梗——“我有改变世界的idea，就缺一个程序员了......”。啊哈，这逗逼想法显然是没看清简单需求背后的复杂细节。就好比想要手机上网快，需求看着简单吧，可这是人大半个通讯行业在做的事。
那么除了“一个程序员”，完整项目还需要什么角色呢？这里笔者大致梳理了下，常见的就有项目管理、商务拓展、产品经理、产品运营、数据开发、算法开发、后台开发、前端开发、测试团队、平台运维、专业美工......这哪是一个程序员cover得住的呢？
以上还只是粗略划分，仅就数据开发而言，还可续分为数据同步、中台数仓、数据资产、业务数据、元数据管理、实时数据、关系数据库等等。大型企业中一般会配置不同团队，而中小企业则往往一人身兼数职。
上图展示了一个小型数据项目的协作范例，可以看出项目的推进并非单凭几号人，而是多团队高效协作的结果。对于大型数据项目而言，协作关系就更是错综复杂了，通常需要专业PM从中统筹协调。

结 语
数据技术的本质是一门工程方法论，涵盖技术点较多，本文正是将它们串联起来，实现无序到有序的知识整理。然而笔者才疏学浅，偏颇之处也在所难免，欢迎同行朋友们后台交流、指正。

作者：穆晨  来源：拾光斋






欢迎光临 168大数据 (http://www.bi168.cn/) Powered by Discuz! X3.2