Sql

14 posts

line4 min readCurated summary

Unifying Analysis Through the Power of Analytics Agents: Work Innovation and Role Transformation in the Generative AI Era at a Professional Organization

PJ One Piece is LY Corporation’s initiative to connect business questions, data analysis, insight generation, and next-action planning through generative AI. Its analysis agent reduced typical turnaround times from about two weeks to roughly 10 minutes, enabling hundreds of analyses each month and adoption by more than half of an early-adopter business unit. The project treats AI not as a chat interface, but as an analysis platform that connects data, knowledge, people, and organizational processes. ## Three Disconnects Behind the Project - **Business and data:** Even with a data warehouse and BI tools, business users still needed to understand SQL, tables, column definitions, KPI rules, and result interpretation. - **Within the analysis process:** Task definition, analysis design, execution, review, and action planning were often handled by different people or tools, causing context loss, rework, delays, and inconsistent quality. - **Across domains:** Useful analysis patterns and domain knowledge remained isolated because services used different KPIs, table structures, business assumptions, and review criteria. ## The Analysis Agent as a Connector - Users ask questions in natural language without needing to know SQL or database structures. - The agent: - Clarifies the business objective and missing assumptions. - Finds relevant data and creates an analysis plan. - Executes queries and specialized analyses. - Interprets results and produces visualizations or reports. - Suggests further analysis and possible next actions. - The platform consists of: - A user-facing application. - An LLM-based agent for reasoning and tool use. - Tools for SQL, Python, document search, and visualization. - A knowledge base containing domain information, skills, and table metadata. - Logging, feedback, monitoring, and evaluation systems. - Domain knowledge is added through a plugin-like structure, while logs and feedback continuously improve the system. ## Turning Business Questions into Analysis Requirements - Natural-language questions often leave important assumptions unspecified, such as: - Target population or campaign definition. - Analysis period and comparison group. - KPI definitions. - Aggregation level. - Exclusion conditions. - Rather than requiring users to write detailed prompts, the agent uses domain knowledge to determine what can be inferred and asks only about unresolved points. - Knowledge bases document service context, KPI definitions, aggregation cautions, policy information, and review requirements. - Table metadata explains available tables, columns, appropriate use cases, samples, partition requirements, and usage restrictions. ## Reaching Data Safely and Reliably - Table metadata is revealed progressively: - The agent first narrows down relevant tables. - It then retrieves detailed definitions and usage rules only for those tables. - Analysis-oriented wide tables or logical views combine transaction data with commonly needed attributes, reducing complicated joins and SQL-generation errors. - SQL is checked before and after execution to enforce: - `SELECT`-only access. - Approved tables and usage rules. - Required partition conditions. - Restrictions on sensitive or personal data. - Result-size limits. - These guardrails allow the agent to perform analysis flexibly without exposing data or infrastructure to unnecessary risks. ## Preserving Context Across the Analysis Process - PJ One Piece uses a supervisor-style multi-agent architecture. - A main agent maintains: - The user’s request and business objective. - The current analysis plan. - Findings and constraints discovered so far. - Remaining questions and decision points. - Specialized sub-agents handle tasks such as statistical testing, time-series analysis, clustering, and independent review. - This separates complex or specialized work from the main context while preserving overall continuity. - Progress updates expose discoveries, design decisions, data limitations, and constraints so users can adjust direction during longer analyses. ## Building Reusable Organizational Capability - Logs record agent actions, assumption checks, analysis designs, generated SQL, errors, and outputs. - User and analyst feedback helps identify whether improvements are needed in prompts, tools, data, or reusable skills. - Repeated workflows are formalized as skills, including: - General-purpose methods such as time-series and clustering analysis. - Domain-specific workflows such as monthly reporting or policy monitoring. - Skills document required assumptions, comparison axes, cautions, and interpretation methods. - Over time, isolated domain knowledge becomes reusable organizational analysis capability. ## Business Impact - In early deployment, the platform expanded data use beyond data scientists to product owners and frontline employees. - More than half of the participating business unit’s members use it. - Analysis turnaround fell from an average of approximately two weeks to about 10 minutes. - The platform now supports hundreds of analyses per month and serves as a daily starting point for business questions. PJ One Piece’s main recommendation is to design AI analysis as an end-to-end operating platform—not merely an automated SQL or chatbot tool. Combining structured domain knowledge, safe data access, contextual multi-agent workflows, reusable skills, and continuous evaluation can make analysis faster while steadily improving its quality and organizational reach.

Read original(opens in new tab)
kakao4 min readCurated summary

Automating KakaoTalk Recommendation Metric Analysis with an AI Agent

The post describes Kakao’s use of an AI agent to automate repetitive analysis of KakaoTalk recommendation metrics on an existing Hadoop environment. Rather than building a new platform or granting the model broad permissions, the team documented existing procedures, data definitions, and decision rules in Markdown-based agent skills and context files. The resulting system helps analysts produce draft reports and explore follow-up questions, while humans remain responsible for validating results and making final decisions. ## Repetitive Analysis Is an Ideal Automation Target - Recommendation analysis often begins with simple questions about CTR changes, experiments, or user-group anomalies. - Answering them typically requires: - Connecting to the analysis environment - Finding the right tables - Writing and executing queries - Interpreting results - Repeating the process across dimensions such as age, category, and time - Much of the effort lies in data preparation and extraction rather than interpretation. - The initial goal was for the AI to follow these steps and produce a first-pass analysis without requiring users to handle queries directly. ## Teaching the Agent to Use Hadoop - The team did not build a new analytics platform or add an MCP integration layer. - Existing Hadoop access scripts were sufficient; the missing component was documentation explaining how to use them. - These procedures were packaged as Agent Skills—Markdown files such as `SKILL.md` describing: - How to connect to Hadoop - How to submit queries - How to retrieve and organize results - The `hadoop-butler` plugin bundled these skills for internal use. - The main lesson was that existing infrastructure can often be extended by converting undocumented operational knowledge into instructions an agent can follow. ## Context Documents Improve Analytical Accuracy - Access to data does not guarantee correct analysis. - Context files such as `CLAUDE.md` or `AGENTS.md` documented: - Relevant tables and clusters - Feature definitions, such as `watch_length` and `valid_view` - User and session aggregation rules - Standard metric definitions - This prevented the agent from repeatedly guessing which tables, columns, or aggregation rules to use. - The documentation also captured institutional knowledge that could help new team members, not only AI systems. - Output quality was determined by the quality and precision of the available context. ## AI Produces Drafts; Analysts Continue the Investigation - Natural-language analysis was most useful for recurring tasks such as: - Detecting anomalies - Comparing experiments - Reviewing weekly performance - The agent’s first report helped identify areas for deeper investigation. - Analysts could then ask follow-up questions and refine the analysis conversationally. - AI-generated reports were treated as reviewable drafts, not final conclusions. - Query logic, selected columns, metric definitions, and interpretations still required human verification. ## Plausible but Incorrect Results The agent’s most dangerous errors were not syntax failures; they were queries that executed successfully but produced misleading results. - **Semantic errors** - To count users, the correct field was `user_id`. - The agent once selected the similarly named `session_user_id`, which represented a session-oriented identifier. - The query ran normally, but the resulting user count was wrong. - **Performance errors** - The agent combined several `COUNT(DISTINCT ...)` expressions in one Hive query. - Although valid SQL, this could force processing through a single reducer and make the query extremely slow. - The better approach was to split the calculations by column and run them in parallel. ## Documentation and Regression Testing - Explicit rules were added to context files and skills, including: - Which identifier to use for user-level aggregation - Wrapping column names in backticks - Splitting multiple `COUNT(DISTINCT)` operations into separate queries - Because natural-language instructions can break other behaviors when modified, the team tested them like software. - An MLflow-based end-to-end evaluation pipeline: - Defines expected behavior for each skill - Runs the agent headlessly with `claude -p` - Uses an LLM judge to evaluate tool-call order, execution traces, and final output - Runs regression scenarios before deployment - This made it possible to catch unintended behavior changes before release. The recommended architecture combines four elements: an AI model, precise domain context, an existing execution environment such as Hadoop, and a verification loop. Organizations should first document their established procedures and analytical definitions, then connect the agent to existing tools and test its behavior systematically.

Read original(opens in new tab)
spotify3 min readCurated summary

Encoding Your Domain Expert: The Context Layer Behind Spotify's Data Assistant | Spotify Engineering

Spotify’s data assistant, Vedder, relies less on model size than on carefully curated domain context. With more than 70,000 datasets, schemas alone cannot capture business definitions, data quality issues, or preferred query patterns. Spotify’s solution is a cluster-based context layer owned by domain experts, making AI-generated SQL more reliable, transparent, and maintainable. ## Why Schemas Alone Are Not Enough - Spotify has petabytes of data across more than 70,000 datasets, making it impossible to provide an LLM with the entire warehouse. - Even large context windows cannot represent all available schemas effectively. - Schema types and column names omit critical meaning, such as: - Which values represent test or legacy data - What “active user” means in a particular domain - Which tables or columns are authoritative - Without this context, an AI assistant may confidently choose the wrong dataset. ## Spotify’s Data Agent - Users ask questions in natural language, and the agent: - Selects the relevant context - Generates SQL - Executes it against the warehouse - Returns the answer, query, and sources - It uses a ReAct loop to reason, call tools, inspect results, and revise its approach. - Users can see how an answer was produced rather than receiving an opaque result. - The assistant is available through: - Slack - An MCP server for IDEs and AI tools - A dedicated web interface - Since August 2025, it has supported more than 2,100 users, 13,000 conversations, and 60,000 messages across 177 domain clusters. ## The Cluster Model Spotify organizes data domains into “clusters,” each owned by a named team of experts. A cluster contains: - **Datasets** - Relevant warehouse tables with schemas and profiling - Column cardinality, common values, and partition information - Details that help the model construct accurate filters and queries - **Pairs** - Expert-approved natural-language questions paired with SQL - Examples of both query patterns and domain semantics - **Docs** - Business terminology and definitions - Known data pitfalls - Guidance about which columns to use or avoid Clusters can represent organizations, initiatives, or specialized areas of interest. Domain experts decide what belongs in each cluster and which examples best represent correct practice. ## Why Human Curation Matters - Spotify considered automatically generating training pairs from historical query logs. - That approach produced unreliable results because query history contains: - Exploratory analysis - Debugging queries - One-off investigations - Incorrect table choices - Technically valid but misleading patterns - Cluster curators accepted only 12.5% of the proposed question-SQL pairs. - Experts therefore determine what is canonical and trustworthy, while the model uses that curated knowledge to answer more users. - The goal is not to replace data specialists, but to scale their judgment and expertise. ## Keeping Context Current - Data models and business logic change continuously. - Cluster health scores monitor signals such as: - Underlying data quality - Whether curated SQL still works after schema changes - Coverage of users’ real questions - Reproducibility of generated SQL - Renamed columns or deprecated tables can immediately reduce the validity of existing examples. - Cluster owners use health dashboards and recommended actions to prioritize maintenance. ## Learning from Every Conversation - Vedder records conversations, queries, answers, generated SQL, and user feedback. - Cluster owners use this information to identify missing documentation, weak examples, and emerging needs. - Each approved example or clarified definition improves future answers. - The system treats context as an ongoing product that requires ownership and maintenance, not a one-time upload of metadata. Spotify’s approach suggests that trustworthy enterprise AI depends on a maintained context layer: curated datasets, expert-approved examples, clear documentation, and continuous feedback. The model supplies reasoning and automation, but domain experts remain responsible for defining what the data means.

Read original(opens in new tab)
cloudflare3 min readCurated summary

How we built Cloudflare's data platform and an AI agent on top of it

Cloudflare built Town Lake to unify data scattered across production databases, analytics systems, streams, and object storage behind one governed SQL interface. The platform combines Trino, Iceberg on R2, DataHub, and custom access-control and PII-detection services to make data fresher, more discoverable, and safer to use. Skipper extends Town Lake with a natural-language AI interface intended to provide fast, accurate, and auditable answers without requiring users to write SQL. ## The Data Sprawl Problem - Cloudflare processes over a billion events per second across a network spanning more than 330 cities and 120 countries. - Relevant data was distributed across: - Postgres - ClickHouse - BigQuery - Kafka - Google Cloud Storage and R2 - Numerous pipelines and production databases - Users needed separate credentials, query languages, retention expectations, and system knowledge for each source. - Sampled analytics data worked for dashboards but was unsuitable for billing, usage calculations, and security investigations. - External vendors created cost and dependency concerns. - Important data was difficult to discover because table locations, schemas, joins, and customer-ID mappings depended on tribal knowledge. - Data infrastructure had historically been treated as a back-office service rather than core company infrastructure. ## Goals for the New Platform Cloudflare wanted a single place where authorized employees could answer questions about customers, traffic, billing, security events, and support activity. - Support both: - Fresh, accurate, unsampled data for billing and investigations - Fast, downsampled data for dashboards and exploration - Provide built-in governance: - Automatic PII detection - Sensitive tables locked down by default - Auditable access - Time-limited permission grants - Build the system using Cloudflare’s own products, including R2, Workers, Access, and Workflows. - Eventually let employees ask questions in plain English rather than requiring SQL knowledge. - That natural-language interface became Skipper. ## Town Lake’s Lakehouse Architecture Town Lake is a lakehouse: a query engine combines data from object storage and operational systems while a metadata layer makes the data behave like a unified database. - **Trino** serves as the query engine. - A single query can join Postgres, ClickHouse, and Iceberg tables stored on R2. - Trino pushes filters into source systems and combines results without requiring intermediate materialization. - **R2 Data Catalog and Apache Iceberg** store warm and cold data. - Iceberg provides schema evolution, time travel, partition evolution, and compaction. - Data can be rolled from per-minute to hourly and eventually daily granularity as it ages. - Older data becomes cheaper to store while remaining queryable. - Parquet files on R2 cost less than retaining equivalent data in an OLAP database. - **DataHub** provides the metadata catalog. - It stores table and column descriptions, owners, lineage, and glossary terms. - Users can discover what a table contains, which teams maintain it, and how it relates to upstream and downstream data. ## Access Control and Privacy - **Lifeguard** manages access policies. - Rules are stored in D1. - User and group memberships are retrieved dynamically from Cloudflare’s internal access-management system. - Lifeguard produces JSON policies that Trino reads over HTTP. - It also supplies access information to Skipper and the Gateway, allowing users to be blocked before queries execute. - **Skimmer** continuously scans tables for PII. - It samples rows from columns across the data platform. - Workers AI classifies whether columns contain personally identifiable information. Cloudflare’s overall approach is to combine unified querying, durable low-cost storage, rich metadata, and policy enforcement so data can be broadly useful without sacrificing accuracy or governance.

Read original(opens in new tab)
aws2 min readCurated summary

Amazon Redshift introduces AWS Graviton-based RG instances with an integrated data lake query engine | Amazon Web Services

Amazon Redshift introduces RG instances powered by AWS Graviton, targeting lower-cost, higher-volume analytics for both human users and AI agents. RG instances can run warehouse workloads up to 2.2× faster than RA3 at 30% lower price per vCPU, while an integrated data lake engine enables faster SQL queries across warehouse tables and S3 data. The architecture also removes the need for Redshift Spectrum and its per-terabyte scanning fees. ## Performance and Cost Improvements - RG instances deliver: - Up to 2.2× faster data warehouse workloads than RA3. - 30% lower pricing per vCPU. - Up to 2.4× faster queries on Apache Iceberg data. - Up to 1.5× faster queries on Apache Parquet data. - The improvements are designed for: - Low-latency BI dashboards. - ETL pipelines and near-real-time analytics. - High-volume queries generated by autonomous AI agents. - AWS recommends using the AWS Pricing Calculator to estimate savings for specific workloads. ## Integrated Data Lake Query Engine - RG instances query warehouse tables and S3 data lakes through one engine. - Data lake queries run directly on Redshift cluster nodes rather than through Redshift Spectrum. - Existing external tables, schemas, Spectrum queries, and SQL syntax remain unchanged. - Customers do not need to recreate external tables or modify application code. - Queries remain inside the customer’s VPC, use existing IAM roles, and avoid Spectrum’s former $5-per-terabyte scanning charge. ## Migration and Setup - RG clusters can be created or migrated through: - The AWS Management Console. - AWS CLI. - AWS API. - The integrated data lake engine is enabled by default. - Migration options include: - **Elastic Resize:** In-place migration with approximately 10–15 minutes of downtime for compatible configurations. - **Snapshot and Restore:** Creates an RG cluster from an RA3 snapshot and is useful when configuration changes are needed. ## Availability and Pricing Options - RG instances are available across numerous AWS Regions in North America, Europe, Asia-Pacific, Canada, and South America. - Redshift Provisioned customers can choose: - On-Demand Instances with hourly billing and no commitment. - Reserved Instances for additional savings. RG instances are intended for organizations combining data warehouse and data lake workloads, especially those needing lower costs and fast response times at high query volumes. Customers should test compatibility and use workload-specific pricing estimates before migrating.

Read original(opens in new tab)
toss5 min readCurated summary

Introducing Toss Place's Data Bot 'PANDA': How every team member works like a data expert

PANDA, short for Place Analytics & Data, is Toss Place’s AI data-analysis assistant, designed to let employees retrieve and interpret approved data without waiting for analysts. It was created after the team found that 70% of data requests involved simple metric lookups rather than complex analysis. The project’s main conclusion is that reliable AI analytics depends less on prompting alone and more on standardized data, business definitions, controlled table selection, and iterative validation. ## Why Toss Place Built PANDA - Employees previously relied on analysts to search dashboards, write SQL, or manually investigate data requests. - PANDA provides self-service access within each employee’s security permissions. - It reduces routine extraction work for analysts, allowing them to focus on deeper analysis. - The goal is to establish a stronger culture of “data democracy,” where employees can access and use data immediately. ## Challenges with a Simple AI Chatbot Early experiments showed that asking an AI model to search all company data produced unreliable and expensive results: - Referencing thousands of tables and internal documents consumed excessive tokens. - The model sometimes selected different tables for identical questions, producing inconsistent answers. - It often misunderstood business definitions. For example, “active stores” could mean stores with completed installations or stores that had processed payments. - Inefficient SQL caused unnecessary Snowflake data scans and higher warehouse costs. ## Standardized Data Marts as a Single Source of Truth Toss Place collaborated across its Data Analysis and Data Platform teams to establish reliable standard data marts. - Core concepts, such as store information, were consolidated into standardized tables. - Naming conventions made table and column purposes easier for both people and AI to understand: - Tables follow `{mart_type}_{domain}_{subject}`, such as `fact_device_error_log`. - Columns follow `{prefix}_{entity}_{attribute}_{suffix}`, such as `is_merchant_active`. - Table and column descriptions were documented comprehensively. - The standardization effort reduced ambiguity by ensuring the same business concepts were represented consistently. ## Connecting Business Language to Data Data structures alone could not answer questions about terms such as “installed store” or “store category.” - Domain-specific terms and metric definitions were documented. - These business definitions were linked to the relevant standard data marts. - Data analysts helped reconcile differing interpretations and establish shared organizational definitions. - This gave PANDA the context needed to apply the correct business logic. ## Scoring and Ranking for Reliable Table Selection PANDA limits its search to well-managed tables and uses dbt tags to import selected metadata into a Manifest file. - Tables are ranked using: - **Similarity score:** Based on relationships between the question and table, including table-name matches and description relevance. - **Hierarchy weight:** Reflecting the reliability of the data layer. - The final score is calculated as: `similarity score × hierarchy weight` - Weights are assigned as follows: - Company-wide SSOT metrics: ×4 - Validated standard marts: ×3 - Domain analysis marts: ×2 - Raw bronze data and logs: ×1 - This improves accuracy, consistency, and trustworthiness while reducing unnecessary warehouse exploration. ## Agentic Loop for Querying and Validation Rather than expecting a correct answer in one attempt, PANDA uses an agentic loop. - It selects appropriate tools based on the question. - It explores tables, generates and executes queries, and reviews the results. - If the result appears inaccurate, it can inspect the schema again, modify the query, and retry. - If necessary, it asks the user for clarification. - This approach allows PANDA to handle exceptions dynamically instead of relying only on predefined rules. ## Answers Designed for Practical Use PANDA structures responses so users can understand and apply the results: - **Result:** The requested data or metric. - **Query criteria:** The period, filters, and aggregation method used. - **Insight:** An interpretation that can support practical decisions. This makes PANDA more than a number-retrieval chatbot; it also exposes part of the reasoning process normally provided by a data analyst. ## Adoption and User Response PANDA quickly became part of everyday work at Toss Place. - One-third of employees used it on its first day. - Half of the organization had tried it within a week. - More than 4,000 messages were exchanged during that period. - Current adoption is approximately 70%. - Employees reported feeling more comfortable asking small questions and using data while away from their desks. - Users particularly valued receiving insights alongside raw figures. - Unexpectedly, developers and even data professionals used PANDA actively, suggesting that its answers achieved a meaningful level of trust. ## Future Development PANDA was developed and launched in just one month, but the team plans further improvements. - Increase data coverage to more than 90%. - Raise answer accuracy above 97%. - Use real user questions, follow-up behavior, and abandonment patterns to identify unmet needs. - Expand beyond basic data retrieval to reduce more of the data team’s workload. PANDA’s central lesson is that effective enterprise AI does not require the most complicated technology. It requires solving a real business pain point with trustworthy data foundations, clear definitions, and a workflow that users can rely on.

Read original(opens in new tab)
datadog3 min readCurated summary

Designing MCP tools for agents: Lessons from building Datadog's MCP server

Datadog’s initial MCP server simply exposed existing APIs, but real-world agent use revealed major problems with context limits, inaccurate trend analysis, and tool overload. The team redesigned its tools around token efficiency, query-based analysis, and a smaller, more deliberate tool surface. These changes improved both answer quality and cost, though emerging agent features may eventually reduce the need for some optimizations. ## Context Efficiency Matters - Observability results can be extremely large: a log record may range from roughly 100 characters to 1 MB. - CSV or TSV is more token-efficient than JSON for tabular data, often using about half as many tokens per record. - YAML can reduce token usage for nested data by around 20% compared with JSON. - Removing rarely used fields from default responses, while allowing agents to request them when needed, further reduces output size. - Combined formatting and field-trimming improvements allowed some tools to return approximately five times more records within the same token budget. - Pagination by record count is unreliable when records vary greatly in size. Datadog instead paginates by token budget and returns a cursor when the limit is reached. - Tools such as Cursor and Claude Code increasingly write long results to disk, which could make response-format efficiency less important in the future. ## Let Agents Query Data - Retrieval-only tools forced agents to infer trends from incomplete samples, such as guessing which services generated the most errors. - Agents sometimes repeatedly fetched logs to compensate, wasting tokens and producing unreliable answers. - SQL lets agents aggregate and filter data directly: ```sql SELECT service, COUNT(*) AS error_count FROM logs WHERE status = 'error' GROUP BY service ORDER BY error_count DESC LIMIT 10 ``` - Agents can select only necessary fields, limit row counts, and calculate aggregates without loading raw data. - SQL improved correctness and reduced costs; some evaluation scenarios became about 40% cheaper. - Supporting SQL at Datadog’s scale required significant infrastructure work because traditional relational databases were insufficient. ## Tools Are Not Free - Exposing every API endpoint as a separate tool increases tool-selection errors and consumes context through tool descriptions. - Flexible tools can support multiple related workflows through carefully designed schemas, reducing the total tool count. - Toolsets provide a core collection by default while allowing users to opt into specialized capabilities, though users must anticipate their needs. - Layered tools can first explain how to accomplish a task and then execute it, keeping specialized functionality out of the initial context. - Layering introduces additional tool calls and therefore increases latency. - Improving agent context management, including tool search and dynamically loaded skills, may reduce the need for aggressive tool minimization over time. The practical recommendation is to design MCP tools for how agents actually reason: minimize and control output size, provide query and aggregation capabilities instead of raw retrieval alone, and expose a focused set of flexible tools rather than mirroring every API endpoint.

Read original(opens in new tab)
figma3 min readCurated summary

Redefining Impact as a Data Scientist | Figma Blog

Data science impact is not limited to experiments, forecasting, or optimization. In complex, high-stakes systems such as billing, data scientists can create value by making workflows understandable, validating correctness, and improving operational safety. Figma’s experience shows that effective data science may require domain modeling, cross-functional collaboration, instrumentation, and production-quality tools. ## Data Science as a Full-Stack Discipline - The role of data science varies by team: it may involve experimentation, product analysis, data modeling, instrumentation, or operational tooling. - Billing combines a user-facing product with backend infrastructure, so accuracy directly affects customer trust. - Supporting Billing required: - Building deep domain expertise - Partnering with engineers and other functions - Creating tools that explain and verify system behavior - Experimentation and opportunity analysis remained useful, but represented a smaller portion of the actual work. - Figma’s full-stack model encouraged the team to define the right data science support collaboratively rather than follow a fixed playbook. ## Explaining Complex Systems Beyond Charts and Models - Some of the most valuable data science work explains existing or historical outcomes rather than predicting future ones. - A single invoice seat charge may depend on: - Seat assignments and removals - Permission changes - Contract terms - Workspace state - Billing rules - The timing of state transitions - Figma built the **Invoice Seat Report** to reconstruct the complete reasoning behind each charge. - The application combines product events, contract metadata, billing rules, and historical state transitions, presenting the result in plain language. - Building it required: - Reconciling fragmented schemas and inconsistent historical data - Validating assumptions with engineers - Adding instrumentation where logs recorded what happened but not why - Translating billing rules into traceable and debuggable SQL transformations - The team also had to account for legacy multiyear contracts, sparse seat histories, early upgrades, and other cases that could create gaps in the data. ## Shaping Technical Direction Through Data - Data scientists can turn business rules into measurable checks that define expected system behavior. - These validations can detect drift, regressions, and anomalies in both development and production. - For Billing, automated verification is especially important because small errors in seat states or invoice calculations can affect customer charges and trust. - During Figma’s billing-model re-architecture, data science helped verify that: - Data moved correctly through pipelines - New pricing and billing logic produced intended outcomes - Customers did not enter unexpected billing states - The system could be monitored consistently across environments The practical lesson is to look beyond conventional analytics when assessing data science impact. In complex domains, building reliable data foundations, explanatory tools, and correctness checks may be more valuable than running another experiment.

Read original(opens in new tab)
tossOriginal article

Improving Business Data Literacy: (opens in new tab)

Toss’s Business Data Team addressed the lack of centralized insights into their business customer (BC) base by building a standardized Single Source of Truth (SSOT) data mart and an iterative Monthly BC Report. This initiative successfully unified fragmented data across business units like Shopping, Ads, and Pay, enabling consistent data-driven decision-making and significantly raising the organization's overall data literacy. ## Establishing a Single Source of Truth (SSOT) - Addressed the inefficiency of fragmented data across various departments by integrating disparate datasets into a unified, enterprise-wide data mart. - Standardized the definition of an "active" Business Customer through cross-functional communication and a deep understanding of how revenue and costs are generated in each service domain. - Eliminated communication overhead by ensuring all stakeholders used a single, verified dataset rather than conflicting numbers from different business silos. ## Designing the Monthly BC Report for Actionable Insights - Visualized monthly revenue trends by segmenting customers into specific tiers and categories, such as New, Churn, and Retained, to identify where growth or attrition was occurring. - Implemented Cohort Retention metrics by business unit to measure platform stickiness and help teams understand which services were most effective at retaining business users. - Provided granular Raw Data lists for high-revenue customers showing significant growth or churn, allowing operational teams to identify immediate action points. - Refined reporting metrics through in-depth interviews with Product Owners (POs), Sales Leaders, and Domain Heads to ensure the data addressed real-world business questions. ## Technical Architecture and Validation - Built the core SSOT data mart using Airflow for scalable data orchestration and workflow management. - Leveraged Jenkins to handle the batch processing and deployment of the specific data layers required for the reporting environment. - Integrated Tableau with SQL-based fact aggregations to automate the monthly refresh of charts and dashboards, ensuring the report remains a "living" document. - Conducted "collective intelligence" verification meetings to check metric definitions, units, and visual clarity, ensuring the final report was intuitive for all users. ## Driving Organizational Change and Data Literacy - Sparked a surge in data demand, leading to follow-up projects such as daily real-time tracking, Cross-Domain Activation analysis, and deeper funnel analysis for BC registrations. - Transitioned the organizational culture from passive data consumption to active utilization, with diverse roles—including Strategy Managers and Business Marketers—now using BC data to prove their business impact. - Maintained an iterative approach where the report format evolves every month based on stakeholder feedback, ensuring the data remains relevant to the shifting needs of the business. Establishing a centralized data culture requires more than just technical infrastructure; it requires a commitment to iterative feedback and clear communication. By moving from fragmented silos to a unified reporting standard, data analysts can transform from simple "number providers" into strategic partners who drive company-wide literacy and growth.

discordOriginal article

Overclocking dbt: Discord's Custom Solution in Processing Petabytes of Data (opens in new tab)

Discord scaled its data infrastructure to manage petabytes of data and over 2,500 models by moving beyond a standard dbt implementation. While the tool initially provided a modular and developer-friendly framework, the sheer volume of data and a high headcount of over 100 concurrent developers led to critical performance bottlenecks. To resolve these issues, Discord developed custom extensions to dbt’s core functionality, successfully reducing compilation times and automating complex data transformations. ### Strategic Adoption of dbt * Discord integrated dbt into its stack to leverage software engineering principles like modular design and code reusability for SQL transformations. * The tool’s open-source nature allowed the team to align with Discord’s internal philosophy of community-driven engineering. * The framework offered seamless integration with other internal tools, such as the Dagster orchestrator, and provided a robust testing environment to ensure data quality. ### Scaling Bottlenecks and Performance Issues * The project grew to a size where recompiling the entire dbt project took upwards of 20 minutes, severely hindering developer velocity. * Standard incremental materialization strategies provided by dbt proved inefficient for the petabyte-scale data volumes generated by millions of concurrent users. * Developer workflows often collided, resulting in teams inadvertently overwriting each other’s test tables and creating data silos or inconsistencies. * The lack of specialized handling for complex backfills threatened the organization’s ability to deliver timely and accurate insights. ### Engineering Custom Extensions for Growth * The team built a provider-agnostic layer over Google BigQuery to streamline complex calculations and automate massive data backfills. * Custom optimizations were implemented to prevent breaking changes during the development cycle, ensuring that 100+ developers could work simultaneously without friction. * By extending dbt’s core, Discord transformed slow development cycles into a rapid, automated system capable of serving as the backbone for their global analytics infrastructure. For organizations operating at massive scale, standard open-source tools often require custom-built orchestration and optimization layers to remain viable. Prioritizing the automation of backfills and optimizing compilation logic is essential to maintaining developer productivity and data integrity when dealing with thousands of models and petabytes of information.

datadog3 min readCurated summary

Timeseries indexing at scale

Datadog’s metrics volume grew 30× from 2017 to 2022, while customers began running increasingly complex queries. This growth exposed limitations in the Timeseries Index service, whose original indexing approach became a performance and maintenance bottleneck. The post introduces Datadog’s metrics architecture and explains how its indexing strategy evolved to handle large-scale workloads more reliably. ## Metrics Platform Architecture - **Intake** - Datadog Agents send data points through a load balancer to metrics intake. - Each point contains a metric name, timestamp, numerical value, and optional tags. - Tags such as `env`, `host`, and `service` provide dimensions for filtering, aggregation, and comparison. - Data is written to Kafka, allowing multiple consumers to process it for storage, indexing, analysis, and archiving. - **Storage** - The short-term storage layer has two services: - The Timeseries Database stores tuples of `<timeseries_id, timestamp, float64>`. - The Timeseries Index stores `<timeseries_id, tags>` mappings. - The custom Timeseries Index database is built on RocksDB and supports filtering and grouping during queries. - **Query Processing** - The distributed query layer contacts index nodes, retrieves intermediate results from the timeseries database, and combines them. - Filters such as `env:prod AND service:event-consumer` restrict results to matching data points. - Grouping by tags, such as `service`, produces separate timeseries for each group. - Aggregators such as `avg` combine values within each group. ## Why Timeseries Indexing Matters - Indexes prevent queries from scanning every timeseries associated with a metric, much like database indexes avoid full table scans. - Poorly designed or insufficient indexes can make queries slow and consume excessive CPU and memory. - As Datadog’s data volume and query complexity increased, the indexing system became a critical scalability concern. ## Automatically Generated Indexes - The original system generated indexes from live query behavior. - Slow or resource-intensive queries were recorded in a query log and analyzed periodically. - Index selection considered: - Query frequency - Execution time - Number of input timeseries identifiers scanned - Number of output identifiers returned - Highly selective queries—with a high input-to-output ratio—received indexes. - Obsolete indexes that no longer received queries were removed. - These indexes acted as materialized views, replacing expensive scans with efficient key-value lookups. ## Original Indexing Service Design - The service was written in Go and used embedded SQLite and RocksDB databases. - SQLite stored metadata, including: - Index definitions - Query logs - Query counts and timestamps - Input and output cardinalities - Query durations - Index definitions were read frequently, updated rarely, and cached entirely in memory. - Query logs were bulk-written in the background, keeping them out of the ingestion and query paths. - SQLite’s SQL interface made the metadata easy to inspect and modify manually. - RocksDB handled the high-volume write workload required to index trillions of events per day. Datadog’s experience shows that indexing strategies that work at smaller scale can become bottlenecks as data volume and query sophistication grow. Effective timeseries systems therefore need adaptive indexing, careful separation of query and ingestion workloads, and storage technologies suited to extremely high write rates.

Read original(opens in new tab)
datadog3 min readCurated summary

Scaling self-serve analytics: The tools empowering 5,000 employees

Datadog scaled self-serve analytics from 200 to 5,000 employees by building an open-source-based platform around three pillars: trusted data, accessible tools, and organizational knowledge. The goal is to let employees answer routine questions and make informed decisions without relying on a centralized Data & Analytics team. This approach combines a single source of truth, self-service data pipelines and transformations, data discovery, quality monitoring, and training. ## The Purpose of Self-Serve Analytics - Datadog’s mission is to “empower everyone at Datadog to make data-informed decisions on their own.” - Self-service allows Data & Analytics teams to focus on higher-value initiatives instead of handling every request. - The organization identified three primary user profiles: - **Analytics Explorers:** Need discoverable data and ready-made reports. - **Analytics Builders:** Create reports and run advanced queries. - **Analytics Experts:** Expose new data, maintain business logic, and manage quality. ## Data as a Single Source of Truth - Datadog centralizes product, operational, and business data so consumers work from the same version of reality. - Its “Bring Your Own Data” (BYOD) tool lets teams expose their own data for analytics. - The shared data layer supports BI tools, notebooks, data discovery, programmatic access, and machine-learning models. - Trust depends on: - Consistent naming and modeling conventions. - Comprehensive documentation. - Continuous data-quality monitoring. ## Self-Serve Data Intake - Teams can connect internal and third-party data sources through integrations and BYOD. - The platform provides scheduling and a user interface for exposing or requesting datasets. - Pipeline observability covers: - Pipeline execution. - Data quality. - Actionable alerts when failures occur. ## Self-Serve Transformation - Analysts manage their departments’ business logic using SQL and dbt. - The development environment integrates with workflow management, metadata, and pipeline-run systems. - Enforced conventions keep the shared modeling layer consistent and understandable as more analysts contribute. - Analysts can inspect lineage, pipeline runs, quality checks, and alerts. ## Data Discovery and Metadata - Every employee can browse datasets and fields in the central data platform. - Search capabilities help users identify which data can answer a particular question. - Metadata explains: - The dataset’s origin and owner. - Definitions and intended meaning. - Where the data is used. - Sensitivity and reliability. - This context helps employees determine whether data is both relevant and trustworthy. ## Supporting Adoption - Tools alone are insufficient; Datadog also provides data knowledge, support, and training. - The Data & Analytics organization acknowledges that self-service has limits and works to mitigate risks such as misunderstanding data or applying incorrect business logic. - Success is tracked through adoption and the effectiveness of the overall self-service strategy. Datadog’s experience suggests that self-serve analytics scales best when data is treated as a product: centralized, documented, observable, and accessible through tools designed for users with different levels of expertise.

Read original(opens in new tab)
datadog3 min readCurated summary

Engineering spotlight: Maël Nison

Maël Nison’s journey from learning DarkBASIC on La Réunion and in Toulouse to becoming Yarn’s principal maintainer illustrates how curiosity, open source, and a focus on solving practical problems can shape a career. His early experimentation with games, websites, forums, and content-management systems developed into a lasting interest in improving developer workflows. That path eventually led through EPITECH, startups, Facebook, and Datadog, while giving him broad experience across both software and community leadership. ## Early Programming on La Réunion and in Toulouse - Maël grew up on the remote Indian Ocean island of La Réunion, where he had little access to computers. - After moving to Toulouse, he discovered a school programming club and began creating games with DarkBASIC. - DarkBASIC simplified 2D and 3D Windows game development through built-in libraries, tutorials, and DirectX support. - Seeing code immediately produce something on screen made programming feel logical and compelling to him. - By high school, he was building PHP websites, working with SQL, and experimenting with multiple languages and platforms. ## Discovering Open Source and Workflow Automation - In the early 2000s, distributing software was much harder because platforms such as GitHub did not yet exist. - Maël shared source archives through online forums, reflecting the informal nature of early open source communities. - His interest in forum software led to work on content-management systems. - He focused on reducing repetitive administrative workflows, such as allowing users to edit content directly instead of navigating through multiple administration pages. - This pattern—identifying a problem, building a solution, and sharing it with others—became a central theme in his career. ## Education at EPITECH - Maël attended EPITECH in Paris, an institution centered on practical technical education and self-directed learning. - The school emphasized peer assessment and hands-on projects rather than traditional, theory-heavy instruction. - He also spent a year abroad in Québec. - During his final year, he combined his studies with his first full-time job, gaining professional experience before graduation. ## Joining Facebook and Yarn - In 2017, after several years in startups, Maël moved from France to London seeking opportunities at larger organizations. - He joined Facebook without specifically intending to work on a package manager. - Facebook’s onboarding “boot camp” identified his skills and connected him with the emerging Yarn project. - He welcomed the opportunity to work on open source during his regular working hours. - What began as a few pull requests became a multi-year role as a major maintainer and leader of the project. ## Yarn’s Technical and Community Evolution - Yarn was rewritten in TypeScript and re-architected into a more modular system. - It evolved from an internal Facebook tool into a genuinely community-driven open source project. - Maël’s responsibilities expanded far beyond coding: - Product management and roadmap planning - Team leadership and infrastructure - Customer support and community work - Web design, evangelism, and outreach - Defining the project’s broader vision - Although he left Facebook for Datadog in 2019, he continued leading Yarn while taking on new challenges at Datadog. Maël’s experience suggests that careers can grow from small, self-directed experiments into major technical leadership opportunities. Developers can follow a similar path by solving concrete problems, sharing their work openly, and being willing to take on the technical, organizational, and community responsibilities that accompany successful projects.

Read original(opens in new tab)
datadog2 min readCurated summary

Being a solutions engineer at Datadog

Solutions Engineers at Datadog combine customer support, technical investigation, and product improvement. They troubleshoot issues across configuration, dashboards, metrics, and alerting while collaborating with customers and engineers. The role also offers structured opportunities to build engineering skills and shape a career toward engineering, product management, or sales engineering. ## Role and Responsibilities - Serve as the technical point of contact for Datadog customers. - Handle tickets involving: - Agent and integration configuration - Dashboard and metric visualization - Alerting issues and bugs - Investigate customer needs, inspect source code, fix bugs when necessary, and coordinate with engineering teams. - Provide short-term workarounds and identify potential product enhancements. - Communicate with customers through chat and technical calls. ## Learning and Collaboration - New Solutions Engineers rapidly develop skills in technologies such as Linux, Ruby, and SQL. - The role requires multitasking while continuously learning new technical concepts. - Team members share knowledge through Datadog documentation and collaborative projects. - Customer feedback provides direct insight into how the product could evolve. ## Engineering Experience and Career Growth - During two-week “embedding” sprints, Solutions Engineers join engineering teams and work on projects alongside developers. - Embedding provides hands-on experience with: - Datadog’s internal technologies - Engineering and design challenges - Architectural decisions - Cross-team collaboration - Once fully trained, employees can pursue side projects such as improving demo environments or automating internal processes. - Career paths can be tailored toward engineering, product management, or sales engineering. Datadog presents the Solutions Engineer role as a strong fit for people who enjoy customer interaction, technical problem-solving, collaboration, and continuous learning. The company was hiring for these positions in New York, Paris, and remote locations.

Read original(opens in new tab)