阿里的onedata总体架构分为四层，从底层的数据采集层，到数据计算层、数据服务层再到上面的数据应用层。
数据日志采集是包括web端采集和app日志采集，通过日志文件到消息中间件 也就是日志中心；
数据库采集直接通过数据库同步工具提取数据库的数据，也就是数据同步中心；
数据计算层包括了离线计算和实时分析量大功能模块和上下衔接，当然最重要的是数据中心，包括数据管理、数据架构、构建方法和工具平台组成，ODS操作数据、DWD（公共明细）、DWS（公共汇总）、ADS（应用数据）。数据计算层将计算结果提供给数据服务层；
数据服务层将数据存储在MySQL和HBASE等库里，再继续封装到数据服务和基础工具层，然后给上层应用层。
数据应用层包括对内、对平台、对商家、对公众等的应用；
日志采集
浏览器日志采集
浏览器日志采集包括页面加载信息采集和页面交互日志采集
目前所有互联网产品的两大基本指标：页面浏览量（ Page View, PV）和访客数（ Unique Visitors, UV）的统计基础。
现在页面的交互设计也越来越好，比如很多都有介入推荐系统或是兴趣或是不再关注等等，系统会记录用户使用时候的访问动作，通过量化的方式得到用户兴趣点或者一些体验优化的点。这些不仅对数据算法和页面有帮助，而且对后台系统的优化也是有帮助。
采集流程
网页访问过程是以浏览器请求、服务器响应并返回所请 求的内容 （大多以 HTML 文档的形式）这种模式进行的，中间要经过http请求和http响应、文档解析等过程。而核心思路是在 HTML 文档内的适当位置增加 一个日志采集节点，当浏览器解析到这个节点时，将自动触发一个特定 的 HTTP 请求到日志采集服务器：
采集过程：
( 1 ）客户端日志采集
可以通过HTML里加载脚本来触发业务响应时采集，也可以开发人员手动加入采集代码
(2）客户端日志发送。
采集到的日志信息一般以 URL 参数形式放在 HTTP 日志请求的请求行内。
( 3 ）服务器端日志收集
(4）服务器端日志解析存档
阿里巴巴的页面浏览日志采集框架，不仅指定了上述的采集技术方 案，同时也规定了 PV日志的采集标准规范，其中规定了 PV日志应采 集和可采集的数据项，并对数据格式做了规定。
页面交互日志采集
阿里使用开发的一套开放的基于 HTTP 协议的日志服务-“黄金令箭”
（1）业务方把要采集业务和业务场景及采集点提交到元数据管理平台，平台注册后获取代码模板
（2）业务方将代码上传植入目标页面
（3）用户使用页面触发到指点采集点则开始采集
（4）采集代码完成采集通过http传递给日志服务器
页面日志的服务器端清洗和预处理
( 1 ）识别流量攻击、网络爬虫和流量作弊（虚假流量）
验：也就是合法性校验
(2 ）数据缺项补正
补：比如身份信息回补
(3 ）无效数据剔除
删：删除冗余和无效的数据
(4）日志隔离分发
隔：基于数据安全或者业务特性的考虑，某些日志 在进入公共数据环境之前需要做隔离。
具体比如flink日志有用logback来做隔离job
移动端日志采集
阿里使用一个称为UserTrack 的采集SDK完成
页面事件
每条页面事件日志记录三类信息 ： ①设备 及用户的基本信息：②被访问页面的信息，这里主要是一些业务参数（如 商品详情页的商品 ID、所属的店铺等） ; ③访问基本路径（如页面来源、 来源的来源等），用于还原用户完整的访问行为。
主要是三种埋点接口技术
调用页面展现的接口、调用页面退出的接口、添加页面扩展信息的接口 （如添加店铺id）
需要组合使用，比如1+2 可以计算页面停留时长
阿里系内，使用 SPM (Super Position Model ，超级位置模型）进行来源去向的追踪，在无线客户端 也同样使用 SPM, SPM 信息就可以通过透传机制带人到下一步甚至下 下一步的浏览页面，这样整个用户行为路径还原就轻松实现了。
控件点击及其他事件
控件点击事件比页面事件要简单得多，一般控件的逻辑简单，就把点击的基础信息和设备信息收集即可
其他挑战
考虑很多具体场景，比如还有日志大小、流量消耗、网络和服务器压力等因素，可以把日志归类，在客户端先做聚合技术，再传输；
还有回退的问题会影响数据分析，利用页面的生命周期，识别页面的复用 ， 配合栈的深度来识别是否是回退行为。
app有原生app和加入H5的混合APP，H5 和 Native 日志统一，比如阿里将 H5 日志归到 Native 日志。
日志传输
日志先在客户端存储，在等待时机上传，除了日志大小还要考虑时间；
客户端数据上传时是向服务器发送 POST 请求，服务器端处理上传 请求 ，对请求进行相关校验 ，将数据追加到本地文件中进行存储，存储 方式使用 Nginx 的 access_log, access_log 的切分维度为天，即当天接 收的日志存储到当天的日志文件中；
阿里使用消息队列（ TimeTunel, TT）来实现从日志采集服务器到数据计算的 MaxCompute。
日志采集的挑战
1.日志分流与定制处理
日志解析和处理 过程中必须考虑业务分流，阿里 PV 日志的请求位置（URL）是随着页面所在业务类型 的不同而变化的。尽可能靠前地布置路由差异，就可以尽可能早地进行分流，降低日志处理过程中的分支判断消耗，并作为后续的计算资源调配的前提，提高资源利用效率。
2.计算与采集一体化
日志采集方案必须将来集与计算作为一个系统来考量，进行一体化设计
数据同步
数据同步是更为通用的技术，比如在主库和备库做备份的时候，集群同步、主节点和从节点同步等。
同步方式可以分为三种 ： 直连同步、数据文件同步和数据库日志解析同步。
1.直连同步
比如通过统一API或数据库链路， 类似基于ODBC/JDBC则可以按照规范的SQL或函数调用来读取不同数据库的数据
2.数据文件同步
比如通过FTP方式直接传输数据库的数据文件
3.数据库日志解析同步
比如oracle可以通过归档日志文件收集变化的数据信息，并判断日志中的变更是否属于被收集对象，将其 解析到目标数据文件中。MySQL可以根据binlog判断。
阿里的数据仓库同步
针对不同的数据源类型和数据应用的时效性要求而采取不同的策略。
批量数据同步
考虑数据源的不同，将数据统一使用字符串类型作为中间状态，使用自研的dataX产品能满足多方向高自由度的异构数据交换。数据传输在单进程（单机模式）／多进程 （分布式模式）下完成，传输过程全内存操作，不读写磁盘，也没有进程间通信，实现了在异构数据库或文件系统之间的高速数据交换。
实时数据同步
常用日志类数据和数据应用，比如交易订单数据，通过解析MySQL的binlog文件，类似oralce的归档日志，来实时获得增量的数据更新，然后通过消息订阅模式实现数据的实时同步。
日志数据-> 日志交互中心->订阅了日志的数据仓库
Time Tunnel 支持主动、被动等多种数据订阅机制，订阅端自动负载均衡，消费者自己把握消费策略；
同时支持订阅历史数据，可以随意设置订阅位置，方便用户回补数据。
接下来就是最为核心的部分数据计算层，阿里的数据计算层包括两大体系：数据存储及计算平台，计算包括离线计算（MaxCompute）和实时计算（streamCompute），另一个是数据整合和管理体系。
离线数据技术
数据开发平台
为了进行更快速便捷的离线数据开发，建立 专门的数据开放平台
那就是要把开发的流程放到平台上，不用太多的导入导出等麻烦操作，那数据研发开发的工作有哪些：
了解需求→模型设计→ ETL 开发→测试→发布上线→日常运维→任务下线。
通过统一的数据开发平台、数据计算平台和数据模型和开发规范，帮数据开发者解决问题。
统一计算平台
统一计算平台是在云上的统一服务，将数据服务封装成各种编程接口和界面；
提供数据上传／下载通道、 SQL、 MapReduce、机器学习算法、 图编程模 型和流式计算模型多种计算分析服务，并且提供完善的安全解决方案。
客户端形式包括：web 、sdk、CLT 、IDE
接入层服务包括HTTP、cache 、负载均衡等
MaxCompute特点
(1 ）计算性能高且更加普惠
(2 ）集群规模大且稳定性高
(3 ）功能组件非常强大
(4）安全性高
统一开发平台
数据研发使用统一开发平台的流程
涉及到具体的开发和工具的就要多看些实际的场景和文档了。各自公司都有各自的产品和流程。
这里主要是一个云端开发平台（D2）和一个SQLSCAN
SQLSCAN 主要对sql语句的质量、规范、性能的审核
数据测试是一个叫做在彼岸的系统：
包括一些主要场景
(1 ）新增业务需求
(2）数据迁移、重构和修改
包含组件：
- 数据对比 ： 支持不同集群、异构数据库的表做数据对比。
- 数据分布：提取表和字段的一些特征值，并将这些特征值与预期值进行比对
- 数据脱敏：将敏感数据模糊化
任务调度系统
开发人员开发了一堆的应用都会转为一个运行的进程执行任务，很多是分布式的，就有非常多任务，而且类型繁多有 MapReduce、 Hive、 SQL、 Spark、 Java、 Shell、 Python、 Perl、虚拟节点等
这就需要开发一个统一的调度系统了，相当于智能调度中心。
调度系统有两个核心模块：
调度引擎根据任务节点属性以及依赖关系进行实例化，生成各类参数实值，并生成调度树
执行引擎的就是具体生成任务，并分配CPU、内存等资源。
特点及应用
自动配置
采用输入输出配置和自动识别相结合的方式
定时调度
周期调度
手动运行
补数据
基线管理
监控报警
实时技术
随着移动互联的时代到来，数据信息量暴增，越来愈多场景需要实时性更高的数据分析计算，比如推荐系统，直播系统上的识别等等，阿里最早是在双十一直播大屏上，直播大屏对数据有着非常 高的精度要求，同时面临着高吞吐量、低延时、零差错、高稳定等多方面的挑战。
数据时效性
按数据延迟分为离线、准实时、实时
离线：在今天（ T）处理 N 天前 （ T-N, N > I ）的数据，延迟时间粒度为天。
准实时 ：在当前小时（H）处理 N 小时前 （H-N, N>O，如 0.5 小时、 l 小时等）的数据，延迟时间粒度为小时。
实时：在当前时刻处理当前的数据，延迟时间粒度为秒；
一般hive为离线数据仓库，而spark 和新的kylin为准实时的开源方案，要实现实时更高的性能还需增加消息队列和各种优化配置，要形成一套流式方案。
流式数据处理特点：
时效性高、常驻任务、性能要求高、应用局限性
流式数据架构
看下具体的流程架构
这是一般的流程，主要包括数据采集、数据处理、数据存储和数据服务等过程。
流式数据模型
流式数据建模分为五个层次：（ODS、 DWD、 DWS、 ADS、 DIM）
ODS 层Operational Data Store
和离线数据一样直接从业务采集的数据，数据操作层
DWD层 Data Warehouse Detail
DWD 层是在 ODS 层基础上，根据业务过程建模出来的实时事实明细层
DWS层 Data Warehouse Service
数据仓库服务层，将数据明细层订阅的事实明细汇总到一个汇总层 ，主要是通用的维度数据，比如卖家信息，就是汇总到一个主题域，就是宽表。
ADS层 Application Data Store
就是个性化维度汇总层，针对不同业务部门的个性化需求制作的报表。
常用于一些垂直创新业务中，数据集市也是种狭义的ADS层。
DIM层
维度表层，一般就是存储关系和基本类目表的层，比如商品维表
具体例如
ODS层：到订单粒度的变更过程明细，每个订单都会有很多变更的过程，可以分解很多子单，这是真实业务场景数据显示不能改变。
DWD层：到订单粒度的支付过程，每个订单都有个是否支付和支付的结果明细，这个是唯一的一条记录。
DWS层：卖家实时成交金额，这是订单汇总的结果，一个卖家只有一个记录实时显示，实时刷新。
ADS层：外卖地区实时成交金额，针对的是外卖部的个性化需求
DIM层：比如订单商品类目和行业的对应关系维表。
多流关联
这是流式数据的关键问题，两个不同流来的数据时间可能不同，无法知道哪个新的，那么需要进行实时关联，
比如双流关联，只有匹配上的数据才会进入到下游，否则存到外部系统，有更新的时候再读取外部数据到内存中，比如订单有多个变更，就会找最新的变更，再和组后的支付关联。
数据服务
服务架构演进
DWSOA ->OpenAPI- > SmartDQ -> OneService
DWSOA是第一阶段就是传统SOA架构，面向需求，一个需求来了开发几个接口服务暴露出去给业务调用；
缺点是接口粒度比较粗，灵活性不高，扩展性差，复用率低
OpenAPI 阶段本质还是接口服务，但是会更加重视粒度和可扩展性，避免烟囱式开发。
将一些通用的数据组成服务做出开放的接口，可以其它接口调用
SmartDQ
在OpenAPI上再抽象一层，用领域专用语言描述取数需求，
同时也封装了标准 DataSource，可以使 用 ORM (Object Relation Mapping，对象关系映射）框架（目前比较主 流的框架有 Hibernate、 MyBatis 等）来解决对象关系映射问题
目标是接口尽可能抽象、收敛
最后SQL无法解决复杂场景问题，比如个性化的垂直业务场景、实时数据推送服务、定时任务服务。
所以就有了oneservice
主要是提供多种服务类型来满足用户需求，分别是 OneService-SmartDQ、 OneService-Lego、 OneService-iPush、 OneService-uTiming
最佳实践
性能优化
资源分配
将复杂计算逻辑剥离不用接口而使用底层公共服务处理
分开两个独立的Get 线程池和 List 线程池， 分别处理 Get 请求和 List 请求
执行计划优化
拆分查询到不同物理表，将list类型查询转为get类型查询
缓存优化
元数据缓存、模型缓存逻辑表查询到物理表查询的映射缓存、查询结果缓存。
查询能力
合并离线数据查询与实时数据查询，在离线数据无法查到结果的时候即时切换到实时查询。
对于需要轮询的数据，采用推送代替轮询。当监听到数据有更新时，推送更新的数据。
稳定性
元数据隔离
根据应用环境 设计了三套元数据：日常元数据、预发元数据和线上元数据
隔离发布
资源划分、资源独占、增量更新
隔离
机房隔离 、分组隔离
还有安全和监控，限流降级等
限流使用应用内QPS保护
降级主要有两种做法：
通过限流措施，将 QPS 置为 0，则对应的所有访问全部立即失败， 防止了故障的扩散。
通过修改元数据，将存在问题的资源置为失效状态，则重新加载 元数据后，对应的访问就全部失败了，不会再消耗系统资源。
数据挖掘
数据挖掘算法平台
2012年之前主要是数据量不大的SPSS 、SAS、 Clementine等，后期大数据时代引入分布式计算、Hadoop、spark、storm等，现在阿里基于自研的maxcompute和GPU上构建算法平台。
数据挖掘中台体系
针对数据挖掘过程中的工作抽象出三个层：
特征层（ Featural Data Mining Layer, FDM）、中间层和应用层（ Application-oriented Data Mining Layer, ADM ），其中中间层包括个体中间层（ Individual Data Mining Layer, IDM）和关系中间层（ Relational Data Mining Layer, RDM）
FDM：特征层，就是提取公共的数据特征，清洗处理等，提高数据清洗效率
IDM 层 ：个体挖掘指标中间层，面向个体挖掘场景，用于存储 通用性强的结果数据，主要包含商品、卖家、买家、行业等维度
RDM 层 ： 关系挖掘指标中间层。面向关系挖掘，比如店铺相似性，竞争关系等
ADM 层： 用户偏好 、品牌等个性化应用指标
常见数据挖掘场景
个体挖掘应用
用户画像、用户身份、业务指标预测、反欺诈发作弊
关系挖掘应用
相似关系挖掘、竞争关系挖掘、推荐系统
数据挖掘案例
用户画像可以分为基础属性、购物偏好、 社交关系、财 富属性等几大类。
互联网反作弊
(1 ）账户／资金安全与网络欺诈防控
(2）非人行为和账户识别
(3 ）虚假订单与信用炒作识别
(4）广告推广与 APP 安装反作弊
(5) UGC 恶意信息检测
