记得一个笑话, 说北大的保安见到陌生人会问三个极富人生哲学的问题:
- 你从哪里来
- 你来干什么
- 你到哪里去
对应数据平台来说, 也可以问三个类似的问题:
- 数据从哪里来
- 数据如何处理
- 数据到哪里去
1.数据来源
数据平台是数据的消费端. 作为数据链条的最底层, 数据的来源通常有一下几种:
1.1 业务数据库数据
业务数据库中的数据是数据平台的重要数据来源, 基本上在不引入开发额外工作的情况下, 将业务数据库导入到数据仓库便可以获得业务的最新状态, 性价比绝佳.
- 从数据库的类型来说, 常用的有MySQL/Redis/MongoDB
- 从数据获取的方式来说, 分为全量和增量两种:
1.2 用户行为打点/埋点
大多数产品都会使用打点的方式, 在用户发生某些行为的时候记录日志, 上传到服务端供后续用户行为分析.
有人会问既然有了业务的数据库数据, 为何还要引入耗时费力的打点方式收集用户行为? 因为业务数据库仅仅存储用户的写操作的状态, 无法获知用户读操作行为. 例如, 查看商品详情这一动作不涉及到任何数据的变化(Counter类型除外), 从业务数据库无法获知用户浏览了哪些商品, 哪类商品.
做用户行为采集, 最大的挑战是如何保证数据质量.
- 数据采集 SDK 要考虑到各个平台的各种 Corner Case, 保证数据能够上传到服务器.
- 每次打点需求如何管理, 如何做数据验证. 移动产品最大的问题是无法像 Web 一样随时发布, 因此一旦等分析数据时发现打点是错误的, 心中定会
万马奔腾. 要修复也只能等下次产品发布.
我的感受是:数据质量就好比锻炼身体, 一定要持之以恒的坚持才行.
这次版本发布数据打点没有 bug, 不保证下次不会有 bug
1.3 用户访问日志
通俗来讲就是应用系统前端 Web 服务器的 Access Log. 通过收集 Access Log 就可以减少很多打点的操作.
那打点和Access Log的区别是什么? 一个简单的比喻, 比如一个人在走路
- 打点就是时不时的问他: 你过去的1分钟里走了多少步? 因此他要自己边走边数数, 一旦数错了, 你获得的结果也必然是错误的.
- Access Log 就是他尽管走他的路, 你在后面数他的脚印. 随便按照你的规则数, 基本不会错. 而走路的人全然不管这个事儿.
还有一个问题是: 既然已经有了Access Log, 为何还要耗时费力的打点? 因为现在基本上都是移动端 App, 为了优化性能, 经常会客户端拉取一批数据后缓存在本地, 用户是否查看数据, 从 Access Log 根本无从分析.
1.4 第三方数据采集
- SaaS大行其道的今天, 基本上没有哪家公司会从0开始构建自己所有的系统, 因此会引入第三方服务. 而在评估这些第三方服务的时候, 可以考虑是否支持导出所有用户的行为日志, 以供后续分析.
- 有些业务需要在用户授权的情况下抓取用户其他平台的数据
1.5 非结构化数据
用户的语音/图片等非结构化数据, 也是一个数据平台的重要来源. 比如做图片鉴黄服务, 语音分析等. 感兴趣的可以参见之前文章 SQL Over S3 构建 SQL 查询非结构化数据的系统
2. 数据如何处理
辛辛苦苦搞来那么多数据, 第一个问题就是数据放在哪里, 然后就想这些数据如何处理, 转变成对业务有价值的东西.
2.1 数据存储
数据库可以分两种: OLAP 和 OLTP. 对于采集来的数据来说, 大多数情况下是要作为 OLAP 系统使用的. 因此存储也基于 OLAP 的思路来选择. 首先想到的就是 HDFS, 一个非常成熟的分布式文件系统. 基于 HDFS 的生态也非常完备, 大多数情况下使用 Hive. 不过 HDFS 也是要维护的, NameNode 虽然支持了 HA 一旦运维不好丢数据了也不能怨政府不是. 如果使用了云平台, 可以考虑类似 Amazon S3/Aliyun OSS 等存储服务, 降低运维成本.
不过后面会聊到数据平台的产出, 也会根据需求用到一些 OLTP 的产品, 比如 MySQL 用来存储报表数据等.
2.2 数据计算
终于到了数据计算这一节. 前面搞来的数据好比买回家的生菜, 需要通过加工才能变成桌上的满汉全席. 数据计算就是'厨房里的厨具'
笼统来说, 数据计算可以用 Spark/Hive/Hadoop/Storm/Presto/Druid..... 眼花缭乱. 分类总结一下, 可以分成如下几种:
- 批量计算(Batch): 通常是大数据量计算, 用于ETL等离线计算. 可以慢, 但要吃得下大数据量. 常用的有Hadoop MapReduce/Hive/Pig/Spark
- 实时计算(Realtime): 通常适用于对延迟要求低的场景, 例如实时统计. 现在基本上都是数据接入 Kafka 然后使用 Spark Streaming 或者 Storm
- 交互式查询: 对现有数据进行统计分析, 查询速度直接决定使用者的工作效率. Hive 太慢. 可选的有开源的 Druid, Presto, Impala, 商业产品可以选择Amazon的Redshift等
- 计算就要一堆服务器, 因此计算资源的调度就需要考虑. 常用的 Yarn 可以调度 Mapreduce 任务, 也可以调度 Spark 任务.
2.3 调度系统
有了那么多"厨具", 想要完成业务功能, 开发了一大堆计算, 最后发现一堆计算任务的依赖关系非常复杂, 例如A 任务要等 B 和 C 任务都完成才可以启动, 而 B 任务又依赖 C, D, E 任务. 一开始可以使用 crontab 启动任务, 预估每个任务的完成时间, 错峰启动. 但一旦中间一个任务失败或者延迟完成, 会导致后续任务计算由于没有前置数据输入而计算结果错误. 因此一个调度系统是必不可少的, 可以选择 Airbnb 开源的 Airflow , Linkedin 开源的 Azkaban
3.数据到哪里去
这里才是前面折腾的最终目的: 数据用来干嘛.
3.1 决策支撑
- Dashboard
- A/B Testing
- 分析报告
第一个想到的肯定就是各种业务的报表. 每个产品功能上线肯定会有一些指标衡量功能. Lean Startup 的经典图里面 Measure 的过程不就是我们数据采集后计算报表的过程.
除了报表, 还有 A/B Test 系统, 各种分析报告. 但总结来说, 这些都是为了做决策支撑.
3.2 基于数据的产品功能
有时也需要基于现有数据构建一些用户可以看到的产品功能.
- 产品功能: 比如推荐系统
- 运营活动: 有些运营活动会展现一些用户历史行为的统计数据, 比如过去你来了几天, 买了哪些东西等.
总结
之所以啰嗦这么多, 是读了一本大数据日知录 的书, 感觉思考一定要系统化, 才可以针对现状琢磨今后要在哪个比较弱的地方发力, 做到更好.
-- EOF --
