去年 6 月份在流利说提离职后，leader 问我为什么要走。我说，流利说有很健全的数据处理基础设施，但这不是所有的公司都会有的条件，所以我想看看在一个基建不全的创业公司我是否也可以像现在一样做的好。
7 月份正式离职到了现在的公司，一开始靠数着运营后台的订单，看着公众号后台的涨粉，配合友盟拿到的分享数据，拉了张 EXCEL 大表就开始预测着未来的营收支出。在业务蒸蒸日上的时候，给出的预测结果表现的也是很让人满意，隔壁公司的黄老板还天天跑来串门问怎么预测的。
预测的结果看起来十分的美好，但是它其实需要有很多的前提假设成立才能站得住脚，比如用户大体的表现是一致的，又比如投放成本不会过高，再比如微信不会打击朋友圈打卡。所以我迫切的希望了解事实是否像我们假设的那般美好，我开始提议希望能在这家公司建立第一套数据基建 —— 自采集埋点配合数据库查询。
我深知它的价值，只要有原始数据未来就可以拿它们计算出我们需要的结果。但是我又无法辩驳过 CTO 市面上已有那么多成熟的第三方数据平台可用，为什么一定要大费周章的自建埋点体系。我抛出的每个具体的理由都因为存在其他的解决方案而不成立，而当我抛出 它是为了解决未来可能会出现不确定问题 时又被要求给出具体的问题。
我又试图说服 COO 出面帮我说服 CTO，但是被几个理由驳回了：
创业公司都不知道能不能活下去，你花资源做这些基础建设万一公司倒闭了那不是浪费资源么？
数据能给我们反馈，但是不能告诉我们接下来该做什么 。
最后我选择了妥协，继续使用友盟看用户行为数据，业务数据需求需要提交给后端来开发输出到 BI后台。这样的模式弊端太明显了，因为数据需求一开始是不确定的，只有被证实过有价值且需要经常观察的数据才会被固化到 BI 报表里，而现在我们直接掠过了不同维度的数据观察，就直接跳到固化报表这一步，像极了还没学会走路就想要开始跑了。
BI 报表的设计到评审，全程都是非常痛苦的一件事情，因为我无法确定设计出来的这些维度、指标是否能够满足后续分析需求，过度设计的话又无法在评审上顺利地说服开发。外加上后端资源有限，每次提交的 BI 报表需求都需要协调后端资源，想看的数据往往要等上一两周才能看到，难受极了。业务方也不敢去想太多的数据需求，因为即使提了也不会被满足，还不如多花点时间想想自己该做什么。
如果业务没有受挫，这家公司的数据航线应该会一直朝着之前既定的方向前进。当数据持续下跌后，所有人开始焦虑到底发生了什么，寄希望于我能根据数据给出答案。但是我能看到的数据其实和其他人是一样的，那我唯一能表现出不一样的地方只有对相关业务动作的联想，但是这些联想出来的猜想又没有其他数据可以去验证，最后大部分只能不了了之。
为了尽可能在现有的数据条件下，搞清楚到底发生了什么，我说服了CTO和后端开发给我了 MongoDB 的查询权限。MongoDB 的语法写起来痛苦极了，因为 MongoDB 是非关系型数据库（NOSQL），它的主要应用场景是单表查询，如果需要频繁查询的关联信息往往会被开发冗余在表中。但是数据分析的不确定性数据需求，往往需要关联各式各样的表才能输出结果，所以我不得不开始生涩地使用 $match 语法。在被后端开发告知 MongoDB $match 的性能要比 $in 差很多 后，我后面通过 pymongo 结合 pandas 进行数据分析了，写起来也顺手多了。
然而仅仅依赖业务数据，还有很多问题无法得到解释，最后在 CEO 和 COO 的推动下公司终于决定自建埋点采集。期间其实还有尝试过友盟以外的第三方数据平台，但是最后都被否掉了。因为第三方数据平台往往是标品，他们能够满足的是众多公司共有的数据问题，而一些个性化的需求满足起来可能成本会比自建还要高的多。
我一开始以为自采集的埋点用户数据会直接进入数据库存放起来的，结果 CTO 调研了一圈最后选择了 阿里云的日志服务，这玩意儿有点类似 Kafka ，可以存放、加工日志类数据的地方。有些抵触但是还能接受，至少可以进行用户分层分析了。于是我们制定了一套自采集的框架，包含了：埋点文档规范、埋点数据字段、埋点上报时机等，会通过后端写入日志服务时补充一些用户标签数据。
虽然可以进行分层的用户行为分析了，也一定程度上解决了很多的问题。但是业务数据和埋点数据依旧是隔离的，如果需要用到标签以外的业务数据进行分层时，阿里云的日志服务有点捉襟见肘了。而老板们原计划的大数据团队建设是放在了 Q4，但是我觉得等不了那么久。因为当时正在招第一个数据分析师，如果招来了人却因为工具受限而无法发挥出他的价值，我会觉得很浪费。
无意间在 日志服务 的投递功能里发现了 MaxCompute —— 阿里云数加（DataWorks）平台的一款数据计算引擎，看了简介又去知乎、简书上了解了下相关评价，感觉可以一试。去找了 CTO，这回他很支持，我猜大概率是因为他比较倾向于使用第三方现成的工具，而不是自己搭建一套东西。开通 MaxCompute 后，我们先是把 日志服务 的数据投递到了MaxCompute表里，再通过 DataWorks 的数据集成功能把 MongoDB 的数据集成到 MaxCompute 表中。
就这样我们打通了我们的埋点数据和业务数据，我写了很多的配置脚本去同步 MongoDB 的数据，又花了大量的时间来构建一些中间表。数据库顶层的模型设计我直接照搬了流利说的—— ETL -> DW(Data Warehouse) -> DM (Data Market) -> DA (Data Analysis) ，这应该也是一个业内比较通用的做法。同时 DataWorks 提供的数据服务，很方便的能让后端调用 MaxCompute 表中的数据，一定程度上减轻了我们对后端资源的需求。
由于 MaxCompute 更像是结合 Hive 和 airflow 的产品，而数加配套的 QuickBI 似乎又没那么好用，我总觉得我们还是缺少了一个交互式分析工具。毕竟数据需求中总会有一些周期性但是又只持续一段时间的需求，如果将他们产品化吧似乎有点浪费，不产品化吧每隔一段时间跑来问你要也挺烦的。于是乎我就研究了下 Superset， 恰好看到 MaxCompute 的文档中提到过，MaxCompute Lightning兼容PostgreSQL接口，所有支持PostgreSQL数据库连接的客户端工具都可以用于连接MaxCompute Lightning，而 Superset 也恰好支持 PostgreSQL数据库连接。在本地测试成功后，我就去和 CTO 分享了一下并得到了支持，预计下周就可以用上了。
我对于 Superset 的期待是
数据赋能运营，让业务方可以在最短的时间内看到自己想看到的数据
释放后端资源，让后端同学可以更专注于他们更专业的地方
提升分析效率，短时间内可以看到更多的数据，不同维度的多项指标
这是一篇碎碎念，纯粹是因为有一种熬出头的感觉外带点兴奋写下的，发与不发纠结了两天。想表达的点就是创业公司想要搭建一套完成的数据分析基础设施，很难又很简单。难在这对创业公司的绝大多数人都是陌生的领域，外加眼花缭乱的第三方市场。虽然明知这件事的重要，但是很难作出一个正确的决策。简单的是，无论采用直接可用的第三方数据平台，还是用云厂商提供的封装后的一整套体系，又或是基于云厂商提供的服务自建一套，都有很多现成的可用的方案。
结尾再普及一下什么是埋点数据和业务数据，这两种数据其实都是原始数据：
业务数据往往是因为业务开展需要存储下来的，比如你的订单、昵称、头像、聊天记录等等，不难发现这些数据有个共性——它们都是你的行为产生的结果，所以业务数据可以简单理解为行为结果数据。
埋点数据只是想对用户行为加以分析而收集的，比如你打开了小王的朋友圈，你扫了一下二维码，你播放了某首歌曲等等，同样的埋点数据也有共性——它们都是你行为过程中采集的数据，所以埋点数据可以简单的理解为过程数据。
结合两类原始数据就可以给你赋予各种各样的标签，再把带有同类标签的用户聚合在一起观察业务表现的共性就是绝大多数的数据分析场景。
原创： 柯小一
公众号：柯一不等式
欢迎加入“MaxCompute开发者社区2群”
